Intro Google が SPDY の開発を始めたのは 2009 年で、 2012 年に HTTP2.0 のドラフトとして採用されたあたりからちょっと話題になりました。 翌 2 月には新たなプロトコル QUIC の存在が Chromium のソースからリークしたのですが、しばらくは音沙汰なく。 6 月に入ってやっと Google から公式アナウンスとドキュメント類が出ました。 去年から今年にかけて立て続けに出てくる新しいプロトコルの話。 なぜ今 Web のプロトコルが見直されるのか？ 何が問題で、なぜ Google はそれらを作り変えるのか？ SPDY や QUIC は Google の独自プロトコルだけど、それは本当にただの独自プロトコルで終わらせていいのか？ 20% ルールで作ってみた Play プロジェクトでしかないのか？ こうした新しい動きには、かならず「それまで」と「今」を踏

intro ちょっと時間が経ってしまいましたが、 Go研 vol.03 では、 Google I/O 2013 で行われてた Go のセッションの 1 つである下記をテーマに研究しました。 Advanced Go Concurrency Patterns 資料は以下です。 https://github.com/goken/goken/blob/master/goken03/goken03.md また、ここから順に実装しながら解説をしますが、その完成品はこちらにあります。 (commit 履歴も、本記事にある程度沿っています。) https://gist.github.com/Jxck/5831269 スライドにそってやったのですが、セッションの内容は結構重ためだったので、 2 時間の Go 研だとちょっと消化不良ぎみだったのが反省点です。 そこで、このセッションの要である、並行処理に関する

intro 先日の Go のカンファレンス GoCon で、 Go の並行処理周りについて発表させて頂きました。 Go Conference 2013 spring - connpass 具体的には Goroutine や Channel の話ですが、これらの機能は結構面白くて、いじって遊んでるだけでもわくわくします。 Go の並行処理は、設計方針がわりと特殊だと思うのですが、設計がシンプルなので分かるとそこまで難しくはないです。 (使いこなすのは、経験が必要そうですが) 今回話すにあたって色々調べましたが、発表時間の都合上省いたものもあるし、質疑応答で聞かれて応えられなかったこともあるので、 ここでまとめて置こうと思います。 発表資料 今回の発表資料はこちらです。 このブログの内容は、これをベースにします。 http://jxck.node-ninja.com/slides/gocon-

history 13/3/31 Tag について追加 intro Go を触ってて interface を用いた設計がまだまだよくわかってなかったので、一旦まとめることにしました。 Go には明示的な継承の機能は無く、 interface も例えば Java のそれとはかなり毛色が違うので、(Class ではなく) Struct の設計に結構癖があると感じます。 Go の interface は言語設計的にもかなり尖っていて、 Go という言語を強く特徴付けていると同時に、 Go 言語自体の開発者たちもこの機能をかなり重要視しています。 例えば、 Go の開発者の一人である Russ Cox 氏によれば Go's interfaces―static, checked at compile time, dynamic when asked for―are, for me, the most

追記 2013/02/13 パッチが本家に取り込まれました https://code.google.com/p/go/source/detail?r=71409a1c89f0&repo=net レビューでもの凄くお世話になった mikio 先生には頭が上がりません。 本当にありがとうございました。 intro あけましておめでとうございます。 このお正月は、ずっと Go を触りながら、 Go の準標準モジュール? である SPDY パッケージのアップグレードをやっていました。 もともとは、 HTTP2 のサーバを書いてみようと思い、色々あって Go を選んだら、spdy パッケージがあるけどバージョンが古かったというのが始まりです。 SPDY の知識はある程度ありますが、 Go 自体はほとんどはじめてなので、こっから Go にも詳しくなれればというモチベーションです。 Go の SPDY

intro この記事は、 Web Music Developers JP Advent Calendar 2012 の 22 日目の記事です。 今日は、モジュラーシンセサイザーの仕組みと、それがアーキテクチャ的にはモジュールの集まりで、 しかもそれらモジュールは Stream であると解釈できる点について紹介する。 このブログでは基本的に技術的なトピックしか扱わない。今回も限りなく音楽ネタに近い技術ネタ？だというつもりで書き始める。 "音" とは何か？ 「音」とはなにか。 さて、ここから始めねばなるまい。 (と、書き出したかっただけで、読み返すとあまり必要はなかった) 音の世界の深淵に潜り込むと出てくる前に左小指が腱鞘炎になってしまうので、 ここはひとつ、音の「三大要素」にご登場願おう。(理科の時間に習ったよね？) 音圧 音程 音色 まず、音圧だがこれは面倒だから音量(大きさ) と同じだと

intro 最近は Readme やら執筆原稿などで markdown を使うことが結構多かったりします。 markdown をレンダリングするツールは色々あるんですが、 エディタは好きなものを使いたいので、自分でレンダリングして、 ブラウザで確認できる何かがあればいいなぁと思ってました。 そんな時、 Github が markdown のレンダリングを API としてやっていたことを知りました。 Markdown | GitHub API しかも、サーバから叩くぶんには認証などもなく、 5000 回/時も叩けるということで、 それを使ってリアルタイムにレンダリングするツールを作りました。 使い方 インストールは $ npm install markup $ markup readme.md [3000]これだけです。 流行りに乗っかって?、ググラビリティの低い名前でリリースしてます。 m

intro なんだかんだ WebSocket を使ってるのに、 WebSocket サーバを自分で書いたことが無かったので、RFC も落ち着いてきたここらで、仕様を読みながら実装してみようと思いました。 "WebSocket サーバ 実装" とかでググると、 Socket.IO とか pywebsocket で WebSocket アプリ作って、「WebSocket サーバを実装」みたいなタイトルになってることが多いみたいですが、 (Apache に PHP で HelloWorld して、「HTTP サーバ実装しました」とは言わないよね。) この記事では、 WebSocket プロトコルをしゃべるサーバ自体を実装します。 といっても、全部やるのはちょっと大変だったので、基本的なテキストメッセージのやりとりの部分だけやって、エコーサーバができるところまでやりました。 完成版のソースは以下で

つまみぐい勉強法 [追記]まちがった情報を載せていました、「つまみぐい勉強法の」正式な発売は5月7日でした。なんか勘違いしてました、すいません。 Shibu's Diary: ぼちぼち『IT業界を楽しく生き抜くための「つまみぐい勉強法」』が本屋に並びはじめます。 ちょっとこの本の話が出たときに「写経」の話になり、 普段どんなふうに写経をしているか？的な話題になりました。 聞いてみるとそれぞれ色々方法があるようなのですが、自分が実践してることや使ってるものが色々と受けたようなので、 ちょっとさらしてみたいと思います。写経に限らず普段実践してることの一部です。 というか便利グッズ紹介的な安いエントリです。 紹介するもの タイトルが釣りっぽいと思われるとあれなので、先になんの話か書いておきます。 ちなみに全面糊ポストイットはおすすめです。 本の固定 BoardPlus 全面糊ポストイット ミニホ