東京Node学園 5時限目に行って来ました。

いや〜、今回もすごく面白かった、東京Node学園 5時限目。
終わるとなにか作りたい気分になるので、今回学んだ事を活かしてまたなんか作ってみよう。

今回3点でまとめるとこんな感じ。
1. meteorすごい。大胆にして野心的。特にクライアント-サーバの関係を独立にしている所はかなり新しいフレームワーク。
2. Domains超楽しみ。エラーハンドリングとかのベストプラクティスが出てきそう。地味に楽しみなのは新しい Cluster かな。
3. Redis, RedisStoreをみんなが使っていて、こんなに便利なものだとは知らなかった。スケーラブルなこともちゃんと考えて使っていこう。

本題へ行きます。

「node-gyp を使ったネイティブモジュールの作成」 by @jovi0608

スライド ： Nodegakuen5 ohtsu

node.jsのモジュールビルドシステムは今まで、WAFと呼ばれる管理システムだったけど、gypと呼ばれる新しいビルドシステムに変更されたため、それのhowtoと hello world デモの紹介でした。

GYPの話を聞いて、嬉しいと思ったのは以下の点：
1. 設定が書き慣れているJSON。
2. プラットフォーム依存の設定も簡単に書ける、ので、デスクトップアプリとかもビルドするのが楽になる。

nodeのライブラリとか書ける位までどっぷり漬かってみたい！
と思いました。今年の抱負にしよう。デスクトップアプリとか作成しちゃうのも楽しいかも。

「flowering-node, router-line」 by @KOBA789

KOBA789/flowering-node · GitHub
KOBA789/router-line · GitHub
flowering-node : Nodeの関数実行を遅延評価を使ってなるべく並列に、かつコードがキレイに
書けるように拡張したものの紹介。
router-line : httpアクセスを高速処理することが可能な新しいwebアプリフレームワーク。

router-lineの特徴は以下の通り。
1. 早い。みそは正規表現を使っていない事。
2. 複雑なパターンを事前に展開。
3. とにかくシンプル

router-lineを使って作った webアプリケーションと express と httpライブラリ直のそれぞれを比較していた。

router-line: 3kreq/sec ☆ Good!!
express: 700req/sec
http hello world: 4.5kreq/sec
httpのhello worldにほとんど近い量のリクエストを捌けるのは嬉しいですね。
expressがダメだと dis ってましたが、毎回切れ味鋭いツッコミが面白かったです。

毎回ある KOBA 君の名言：
☓ 重くて学習コストの高いフルスタックなフレームワークを使う
○ フレームワーク的なものをその都度自分で作る(手軽に)
つまり、フレームワークなんていらなかったんや！！

「Socket.IOでテレビ連動システム」by @kazutoyo

テレビ連動システム：We're sorry, but something went wrong (500)
Socket.IOとスケーラビリティの話。
RedisStore恥ずかしながら知らんかった。
Socket.ioをスケーラブルにするのってどうやるんかなって思ってたけど、
RedisStore使ってやるやり方が一般的みたい。

「Node.js v0.8 最新事情-いつでる?どうなるDomains?」by @koichik

Domainsの機能と最近のNodeの状況を中の人から簡単に紹介。
Domainsの機能自体は公開されて即記事にされた @jovi0608 さんのブログが参考になります。
node.js Domain 時代のエラー処理のコーディングパターン - ぼちぼち日記
もともと複数形だったのが正式には単数になったみたいですね。
「Domains」 -> 「Domain」
例外処理をキレイに書けるのはかなり嬉しい機能です。

また、スライドによれば、v0.8のメインは以下の通り。
V0.8の目玉
1. Domain
2. GYP
3. Cluster2
4. UTF-16 サロゲートペアあり

この中でDomain, GYPは説明が今回ありましたが、個人的に一番気になるのは Cluster2ですね。
Isolatesが実質やらなくなってしまったということもありましたが、Nodeのスケーラビリティはかなり気になるところです。

「Introduction of Meteor」 by @Jxck

スライド：Node Academy 5 | "shallow inside meteor"
最近かなり話題のmeteor。
その中身を紹介した資料でした。meteorの考え方は大胆にしてアクティブ。
以下のクライアントとサーバの独立性を全面に出した考え方が大胆だと思いました。

f:id:yosuke_furukawa:20120421022100p:image

クライアント側で更新系のリクエストがあると一度クライアントだけでClient Cacheの情報を使って
成功したかのように見せかけてレスポンスを返します。
そのあとで、サーバへデータを非同期で送信するという大胆な手法を選択しており、
同時書き込みが発生した場合でも予約等の機構はなく、最後に書き込んだ人が勝つという方式を採用しています。

見せかけかもしれませんが、高速に見えることが重要な意味を持っています。

聞いていて思ったのは、これなら「バルス」でTwitterを落とさなく出来るんじゃねー？とかちょっと思いました。クライアント側で成功させたように見せかけておいて、裏側の処理は同時に送信されないようにサーバー側でキューイングしちゃうことも可能なんじゃないかと。

個人的に一番驚いたのは今の話ですが、他にもHTMLのボディを持たずに全てjavascriptで制御する話とか、
コードが更新されたらクライアント側も同時に更新する hot code spotの話しもあり、ぜひスライドを
一読しておくことをオススメします。

LT大会

以下のような題目が上がっていました。

タイトル	発表者	内容
「groonga をつかった検索APIサーバを nroonga でつくる」	@darashi	Speakerdeck
「顔とNode」	@nulltask	Speakerdeck
「Nodeで動くFacebookアプリ瞬間作成」	@dekokun	heroku/facebook-template-nodejs · GitHub
「Socket.IOでタイピングゲームを作った(デモ)」	@uchida75cm
「JSON API」	@jedschmidt	jed/sajak · GitHub
「LINQ on Node.js」	@tanaka_733