次世代 Web カンファレンスを開催しました #nextwebconf - Block Rockin’ Codes
intro 次世代 Web カンファレンスを開催しました。 名称: 次世代 Web カンファレンス 日時: 2015/10/18(日) 9:00-17:30 場所: 法政大学外壕校舎 4F 後援: 法政大学情報科学部 参加費: 無料 hashtag: 全体: #nextwebconf 405: #nextwebconf405 406: #nextwebconf406 407: #nextwebconf407 実施概要 概ね開催概要の通りです。 jxck.hatenablog.com やったこと やったことはシンプルです。 テーマ毎に、今 Web がどうなっていて、これからどうなっていくのか をひたすら議論するセッションのみのカンファレンス やらなかったこと 以下はこのカンファレンスではやりませんでした。 スポンサー募集 Tシャツ/ステッカー/チラシ作成 公式サイト作成/ドメイン取得 公式懇
「次世代 Web カンファレンス」を開催します #nextwebconf
Intro 2015/10/18(日) に、「次世代 Web カンファレンス」を開催します。 名称: 次世代 Web カンファレンス 日時: 2015/10/18(日) 場所: 法政大学 hash: #nextwebconf 公式: connpass 参加費: 無料 Motivation 「Web について話す場」 というか「Web そのものをテーマにした場」というのが、意外と少ないなとずっと思っていました。 (もちろん、結果として Web について話しているカンファレンスや勉強会はたくさんありますが。) そして、スライドなどを用いて何かを「発表する」ニュアンスではなく、進化の早い Web で「今何が起こっているか？」と「これからどうなっていくのか？」という、答えの無いもの、でもみんなが気になり考えていること、今だからこそ考えないといけないことを真っ向から議論する場というのが、もっとあって
HTTP2 時代のサーバサイドアーキテクチャ考察 - Block Rockin’ Codes
update 色々と twitter で議論が起こったのでまとめて貼っておきます。 togetter.com みなさんありがとうございました。 intro HTTP2 の RFC 化も目前ということで、そろそろ実際に HTTP2 を導入していくにあたってサーバサイドの構成についても、具体的にどう変わっていくかという点を考え始めていく必要があります。 そんな話を @koichik さんとしていたら、色々と考えが膨らんだのでメモしておきます。 前提 今回は、中規模のサービスを想定し、特に HTTP2 のサーバプッシュを踏まえた上でのコンテンツ配信などに、どういう構成が考えられるかを考えていきます。 また、本エントリ内では独自に以下の表記を採用します。 HTTP/1.1 = HTTP/1.1 (平文) HTTP/2 = HTTP/2 (平文) HTTPS/1.1 = HTTP/1.1 over
HTTPS 化する Web をどう考えるか - Block Rockin’ Codes
Update 2015/5/8: 指摘頂いたタイポや誤訳などを更新しました。 2015/5/8: 構成を一部修正しました。 Intro 4/30 mozaiila のセキュリティブログに下記のようなエントリが投稿されました。 Deprecating Non-Secure HTTP | Mozilla Security Blog エントリはそこまで長くないので、ここに翻訳の全文を記載します。 そして、元エントリのライセンスである CC BY-SA 3.0 に則り、 本エントリも同じく CC BY-SA 3.0 とします。 Deprecating Non-Secure HTTP 原文: Deprecating Non-Secure HTTP 今日は、 non-secure な HTTP から、徐々に廃止していくという方針についてアナウンスします。 HTTPS が Web を前進させる手段である
Fetch API 解説、または Web において "Fetch する" とは何か？ - Block Rockin’ Codes
Update [14/11/11]: Chromium での実装が M40 からあるそうなので、末尾に引用追記させていただきました。 [14/11/12]: この記事を書くにあたって、色々なかたにレビューや助言を頂いたのですが、謝辞などが一切抜けてました、本当にすいません。追記しました、ご協力頂いた方々本当にありがとうございました。 WHATGW Fetch Spec WHATWG のメンテナンスするドラフトに Fetch Spec が追加されました。 もうすでに日本語訳もあります、すばらしい。Fetch Standard 日本語訳 この仕様には二つのことが定義されています。 "Fetching": Fetch するとは何か? の定義 "Fetch API": fetch() の定義 後者の定義に基づく fetch() という DOM API の実装も始まっています。(詳細は後述) しかし
Stream API がブラウザにやってくる - Block Rockin’ Codes
Intro 今日は、フロントのプログラミングスタイルに、にまた一つ大きな変化をもたらすであろう Stream という API についてです。 この仕様は現時点でまだ策定中であるため、 API は変更される恐れがある点にご注意ください。 Stream API 以前 「Node.js の Stream API で「データの流れ」を扱う方法」 という記事を書きましたが、簡単に言うとあれがブラウザにもやってくるという話です。 非同期処理おさらい もう何度も書いた話なので駆け足で。 JS はシングルスレッドでイベント駆動な世界なので、何をするにも非同期であり、コールバックを登録することで完了した結果を受け取る API が基本です。 これは、ブラウザの DOM の API でも、 Node.js でも共通しています。 概念を疑似コードで書くと以下のような感じです。 console.log('1');
「for やめろ」またはイベントループと nextTick() - Block Rockin’ Codes
ものすごく遅レスですが、LLDiver で @esehara さんの LT であった話。 forやめろ、あるいは「繰り返し」という呪縛から逃れるために 簡単に言うと、 1~10 までを出力する方法を複数考えるというもの。 for, while, 再帰, goto etc.. と出て、途中で終わっちゃったので結論はよくわかりませんでしたが、 Node ではどれも使わずにできるな、と思ったのでちょっと例を出してみます。 ちなみに、タイトルでネタバレしている通りイベントループの話です。 そしてよくある「イベントループとは何か」「なぜ止めてはいけないのか」「process.nextTick() とは何か」「setImmediate() と何が違うのか」 などを解説する良い例だったので、書いてるうちに実はそっちがメインの解説となりました。 サンプルの実行結果は Node v0.11.13 です。(書
ハイパフォーマンス ブラウザネットワーキング書評 - Block Rockin’ Codes
Intro 執筆段階から、 Web で無料閲覧できた High Performance Browser Networking が、紙の本として出版され、その翻訳本が完成したということで、献本を頂きました。 原著には本当にお世話になったし、 HTML5Experts.jp で書いた Make the Web Faster の連載でもよく参考にした本なので、日本語で読めるようになったのは非常にありがたいですね。 本当はレビュアの依頼を頂いたのですが、色々あって他の方に振ったりしてしまったので、せめて全力で書評させていただきます。 やっと献本頂いたイリヤ本ゆっくり読める。日本語で読めるのは素晴らしい。 #http2study pic.twitter.com/Zy00OOy6ve— Jxck (@Jxck_) 2014, 5月 11 Make the Web Faster ところで、 Google
Go のスライスの内部実装 - Block Rockin’ Codes
History 14/05/09: Merge2 を修正しました。http://twitter.com/jbking/status/464659353945911297 Intro Go のスライスは、いわゆる LL 系の言語が持つ可変長配列の実装と似ています。 よって LL のような手軽な扱いをすることもできますが、その内部実装を知ることでより効率の良いメモリハンドリングができ、パフォーマンスを改善や、メモリーリークの防止などに繋がる可能性があります。 この辺は SWrap というライブラリを作りながら勉強したので、今回は、この Go のスライスの内部実装を解説します。 Go の配列 スライスを知るためには、まず配列について知っておく必要があります。 Go の配列は固定長のため、以下のように長さを指定して宣言します。 var arr [4]int func main() { arr =
なぜ html の form は PUT / DELETE をサポートしないのか？ - Block Rockin’ Codes
注意 内容については一切保証しません。 ここでは、主に W3C ML での議論や各種仕様などに基づいて書いています。 ここに書かれていることが正しいかどうかは、自身で判断して下さい。 事実としておかしいところなどは、コメントでどんどん指摘して下さい。遠慮はいりません。 ただし、このエントリでは「form が PUT/DELETE をサポートするべきかどうか？」の議論はしません。 「REST の是非」や「PUT/DELETE の意義」についても議論する気はありません。 ここでやっているのは、あくまでもどういった議論の末現状があるのかの調査です。 そうした意見がある場合は、 W3C などに投稿するのが最も有益だと思います。 History 2014/03/29: 公開 2014/03/29: XForm と XHTML の関係を明確化(thanx koichik) 2014/03/29: HT
markdown のリアルタイムレンダリングツール markup をリリースしました - Block Rockin’ Codes
intro 最近は Readme やら執筆原稿などで markdown を使うことが結構多かったりします。 markdown をレンダリングするツールは色々あるんですが、 エディタは好きなものを使いたいので、自分でレンダリングして、 ブラウザで確認できる何かがあればいいなぁと思ってました。 そんな時、 Github が markdown のレンダリングを API としてやっていたことを知りました。 Markdown | GitHub API しかも、サーバから叩くぶんには認証などもなく、 5000 回/時も叩けるということで、 それを使ってリアルタイムにレンダリングするツールを作りました。 使い方 インストールは $ npm install markup $ markup readme.md [3000]これだけです。 流行りに乗っかって?、ググラビリティの低い名前でリリースしてます。 m
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
