The Future of Programming in Node.js

東京Node学園祭2013 基調講演

Transcript

1. The Future of Programming in Node.js 東京Node学園祭 2013 基調講演 東京Node学園祭実行委員長 清水 俊博@meso
2. about me { “name”: “清水 俊博”, “twitter”: “meso”, “github”: “meso”, “communities”: [“nodejs_jp”, “java-ja”], “work”: “dwango” }
3. ドワンゴでは、 エンジニアを(ry
4. 本題 • The Future of Programming in Node.js • Isaac Schulueterが今年8月14日にMLに投げ たメール • 今のところ日本語に翻訳されてない！！ ◦ 最近ワザノバさんでNodeの話題が翻訳されすぎててネ タに困ってた ▪ Node.jsをサーバサイドのUIレイヤに限定するのか？ ▪ Issac Schlueterが語るNode.js v1.0へのロードマップ ◦ ドワンゴでのNode事例とか基調講演っぽくないし
5. ちなみに • ドワンゴでのNodeの活用事例 ◦ 社内システムで利用中 ◦ 新規サービスの開発で利用予定
6. Isaacs Schlueter • 言わずと知れた、Nodeの2代目リーダー • MLにメールを投稿した目的 ◦ 最近、NodeのコアAPIについての議論や意見、要望が 多い ◦ ここらで今後の計画についてハッキリさせておく • CallbackやStreamやAlt JSなど、11項目につ いて記述 ◦ それぞれの項目に対する反応も含めて紹介 ◦ 超訳入ります。特にメールで会話してるとこ
7. 1. Callback • callbackは非同期処理を記述するデファクトの 方法であり続けます。 • generatorやpromiseは興味深いですが、あくま でもユーザ拡張の領域のものです。 ◦ generatorとは？ ▪ 詳しくはConstなんとかさんのセッションで ▪ ECMAScript 6（Node.js v0.11.4以降）で使える ▪ https://github.com/visionmedia/co ▪ https://github.com/koajs/koa
8. 1. Callback • Bert: callback地獄を根本的に解決するようなソ リューションがでてきたらどうすんの？ • Isaac: もし、ユーザ拡張の何れかのライブラリ が明らかにデファクトとして使われるようになり、 なおかつ、それを後方互換性を損なうことなくコ アに取り込めるなら、そのとき検討しましょう。 • Isaac: っていうかこの話この前したじゃん
9. 2. Stream • Streamはより早く、かつ一貫性のあるものにな ります。 • v0.10との後方互換性は100%保たれます。 ◦ 「互換モード」がAPIによってより隠蔽される ◦ ストリームをpause()した後に、安全にread()することが できる • StreamをコアAPIの中に隠蔽せずに外から見 える状態にすることで、Streamを拡張したクラス をユーザが作ることを推奨している、その姿勢 は変わりません。
10. 2. Stream • Radford: `on(‘data’, …)`って書き方はそのまま 使えんの？ • Isaac: 使えるよー。v0.10では`on(‘data’, …)`が あると互換モードになって、v0.12では、flowを 開始するリスナが追加されるよ。
11. 2. Stream • Nuno: 後方互換性あるって言ってるけど、v0.8 のStreamのコードがv0.10で動かないんだけど • Isaac: 互換性があるのはv0.10とv0.12の話 ね。この2つは一部例外（と早くなること）を除け ば見分けがつかないはず。
12. 3. Domain • Domainはリファクタリングすることで、より包括 的にエラーを継続追跡できる仕組みにしていき ます。 ◦ エラーハンドリングの仕組みをユーザ拡張で作れるよう に • 最終的にはDomainモジュールはユーザ拡張で 補えるものになるかもしれません。 ◦ けどまあとりあえずNodeにバンドルされたままであり続 けるよ
13. 3. Domain • Bert: エラーハンドリングは本当に糞だよね • Issac: 糞だねー。何かいい感じに継続追跡出 来るのがでてきたらいいのに。 • Nuno: エラーハンドリングは確かに糞だけど、 ぶっちゃけErlang以外の環境だとどこでも糞 じゃね。 • Arunoda: まあ、Callbackもエラーハンドリング も糞だけど、それでもアプリ作れるしまあいいん じゃん。
14. 4. Module System • モジュールシステムには変更は加えません。 • 一切加えません。モジュールシステムは完成さ れたものです。一年以上も前に。 • 明らかに再現可能で、ドキュメントの修正程度 じゃ対処できないバグの場合のみ、変更の提案 を受け入れます。
15. 5. Alt JS • TypeScriptやCoffeeScriptはコアには取り入れ ません。 • モジュールシステムが（前述のように）変更され ないので、現在動いているAlt JSで書かれたも のは、今後も動作可能です。
16. 6. Binary Addon • v0.12では、V8のAPIが*著しく*変わったため、 基本的には全てのバイナリアドオンが動きませ ん！ • しかもopensslやzlibなどのライブラリと組み合 わせることもとても難しくなった。 • 今この問題に取り組んでいます。 ◦ 安定したCのAPI互換レイヤを追加します。 ▪ Cで書かれたバイナリアドオンがNodeの安定版のブ ランチ間で、同一コード（できれば同一バイナリ）で動 作するように
17. 7. New Language Features • V8には新しい言語仕様が取り入れられ、それら はNodeにもやってきます。 • しかし、それらの仕様を自動的にenableにする つもりはありません。 • その代わり、何を必要としているのかを検知し て、わかりやすいエラーメッセージを投げるよう にします。
18. 8. VM module • VMモジュールはリファクタリングされ、 contextifyモジュールの特長をコアに取り入れま す ◦ contextがみんなが望む形で動作するようになります ◦ マルチコンテキストもサポートされます
19. 9. Child Process • ついに子プロセスの同期実行が可能になりま す。
20. 10. Roadmap • v0.12は完成に近づいています。 • v0.12が出たらみんなに使ってもらいます（安定 版だからね）。 • v0.12の後、v1.0に向けてはAPIの変更は行わ ないつもりです。 • v0.12とv1.0の間では、パフォーマンス改善とバ グFixと安定性向上に注力します。 • 今動くものが来年も、しかもより早く安定して動 作するよう、最大限の努力をします。
21. 11. OSS • これらの決定は民主主義的意思決定に基づくも のではありません。しかし、皆さんの意見を取り 込む多くの余地があります。 • もし、Nodeコアにダイナミックな変更を加えたい と思い、npmモジュールを書くのに満足できなく なれば、joyent/nodeをforkして、新しい名前とロ ゴを作って、それに熱中すればいいのです。 • OSS FTW
22. 11.1. StrongLoop • Bert: StrongLoopはさらなる改善を加えていく よ。それはNodeとは呼ばれなくなるかもだけ ど。 • Isaac: “StrongLoop Nodeディストリビューショ ン”のことだよね。それはそれでOSSのあり方な んじゃない。 • Bert: それそれ。StrongLoopのがコアへの新機 能追加の実験場になるとは思ってないけど、何 か他のものにはなるかもね。
23. 11.2. Meteor • Arunoda: Bertが言うように問題に対するソ リューションは必要で、でもそれはNodeとは別 物だ。Meteorもそのいい例だよね。 • Bert: というかユーザ拡張とかforkとかが正しい なら、なんでみんなそんなにMeteorに腹立てて んの？ • Isaac: え、個人的にはMeteorに腹立てたりして ないよ。MeteorがNodeに対して何かスポーツ マンシップに悖る不作法なことしたってのも聞い てないし。
24. 11.2. Meteor • Isaac: 彼らのコミュニティの作り方については 批判的だけどね、もちろん。彼らはやり方を間 違った。けどそれは`悪い`とか`怒り`を含んだも のではなくて、「ネット上に間違ったことを書いて る奴がいる（から正さないと）」的な反応に過ぎ ないよ。 • Isaac: 彼らのmodule/packageシステムはnpm のデザインとは正反対なんだよね。Nodeのエコ システムが今のサイズまでになったのはそのデ ザインのおかげなのに。
25. 11.3. 批判 • Eldar: forkすりゃいいじゃんっていうのはアン フェアだと思うんだよね。 • （色々とアンフェアじゃないと考える理由を挙げ ている）
26. 11.3. Mikeal Rogers • コアAPIに対する何がしかの決定を嫌がるや つっていつもいるんだよね。結局、ML上で文句 言ってる奴らって大した奴らじゃないんだよ。 • 声のでかい少数のそういう奴らが貢献したコー ドなんてほんの少しだし、エコシステムを成長さ せてる圧倒的多数の人たちはここでは文句い わないよね。 • なぜなら彼らはコードを書くのに忙しいから。
27. 11.3. Mikeal Rogers • APIに対して文句いってる奴らがいる一方で、そ の何百倍ものライブラリをそのAPIを使って書い て、エコシステムやプラットフォームを成功に導 こうとしている人たちがいるんだよね。 • 批判的な姿勢はプロジェクトを前進させるのに は重要だけど、批判があることが失敗を生むこ との指標になると思うのは間違いなんだ。成功 が批判を生んでるんだよ。
28. 11.3. Mikeal Rogers • 声の大きい奴らの意見を聞くことにIsaacは時間 を費やすべきだといいたいようだが、あいにく彼 は世界で最も早く成長しているエコシステムを 作り上げていっている物言わぬ大衆や、全てが Node.jsで作られた巨大なスケールのソリュー ションをデプロイしている人たちの声に耳を傾け ているんだよ。
29. 11.4. 流れ変わったな • Rouan: Issac、そしてNodeのコントリビュータの 皆さん、ありがとう。 • Nuno: Isaacありがとう。そしてNodeチームも Node.jsの信念に対して正直で在り続けてくれ てありがとう。ユーザとして、貴方たちが何を望 んでいるかをしれて嬉しいよ。
30. 11.5. お調子者 • Fedor: ヒャッハー！新たな火種を起こすぜ！安 定性はいいことだよな？でもNodeのコアには明 らかに修正すべき問題がいくつかあるよな！で もいいや！ビッグリリースである1.0を優先しよう ぜ！ • Bert: いや、その火種全然熱くないんだけど。 Isaacに合理的に反対できるやつはもういなく ね。
31. そんなわけで • Nodeは民主主義的な意思決定をしているわけ ではない • が、それは当たり前で、MLで騒いでる声の大き い人達の意見を取り入れていたらAPIは安定な んてしないから • Isaacがgate keeperでいる限り、NodeのAPIは 後方互換性を大切にしてくれる • さあ、安心してNodeを使いましょう
32. コミュニティのリーダー • コミュニティの段階に応じてリーダーが担うべき 役割が変化する ◦ Ryan -> Isaac • Node.js 日本ユーザグループも3年以上経ちま した ◦ そろそろ代表を交代しようと思います ◦ 立候補、推薦の方法をMLで周知します
33. おまけ
34. • 既に紹介したもの ◦ http://strongloop.com/strongloop-suite/strongnode/ ◦ https://github.com/visionmedia/co ◦ https://github.com/koajs/koa • その他 ◦ ツール ▪ https://github.com/Unitech/pm2 ▪ http://commando.io/ ▪ http://www.opsmezzo.com/ ▪ https://github.com/creationix/jsgit ▪ http://brunch.io/ ▪ http://makebooth.com/i/1xkN1 Nodeの最近の面白い事例
35. Nodeの最近の面白い事例 ◦ Framework / Boilerplate ▪ https://github.com/airbnb/rendr ▪ http://actionherojs.com/ ▪ http://www.deployd.com/ ▪ http://www.mean.io/ ◦ Service ▪ http://glide.so/ ◦ Development Environment ▪ http://noflojs.org/ ◦ Hardware ▪ http://tessel.io/ ◦ OS ▪ http://nodeos.github.io/