1 of 35

The Future of Programming in Node.js

東京Node学園祭 2013 基調講演

東京Node学園祭実行委員長 清水 俊博@meso

2 of 35

about me

{

“name”: “清水 俊博”,

“twitter”: “meso”,

“github”: “meso”,

“communities”: [“nodejs_jp”, “java-ja”],

“work”: “dwango”

}

3 of 35

ドワンゴでは、

エンジニアを(ry

4 of 35

本題

  • The Future of Programming in Node.js
  • Isaac Schulueterが今年8月14日にMLに投げたメール
  • 今のところ日本語に翻訳されてない！！

5 of 35

ちなみに

  • ドワンゴでのNodeの活用事例
    • 社内システムで利用中
    • 新規サービスの開発で利用予定

6 of 35

Isaacs Schlueter

  • 言わずと知れた、Nodeの2代目リーダー
  • MLにメールを投稿した目的
    • 最近、NodeのコアAPIについての議論や意見、要望が多い
    • ここらで今後の計画についてハッキリさせておく
  • CallbackやStreamやAlt JSなど、11項目について記述
    • それぞれの項目に対する反応も含めて紹介
    • 超訳入ります。特にメールで会話してるとこ

7 of 35

1. Callback

  • callbackは非同期処理を記述するデファクトの方法であり続けます。
  • generatorやpromiseは興味深いですが、あくまでもユーザ拡張の領域のものです。
    • generatorとは？

8 of 35

1. Callback

  • Bert: callback地獄を根本的に解決するようなソリューションがでてきたらどうすんの？
  • Isaac: もし、ユーザ拡張の何れかのライブラリが明らかにデファクトとして使われるようになり、なおかつ、それを後方互換性を損なうことなくコアに取り込めるなら、そのとき検討しましょう。
  • Isaac: っていうかこの話この前したじゃん

9 of 35

2. Stream

  • Streamはより早く、かつ一貫性のあるものになります。
  • v0.10との後方互換性は100%保たれます。
    • 「互換モード」がAPIによってより隠蔽される
    • ストリームをpause()した後に、安全にread()することができる
  • StreamをコアAPIの中に隠蔽せずに外から見える状態にすることで、Streamを拡張したクラスをユーザが作ることを推奨している、その姿勢は変わりません。

10 of 35

2. Stream

  • Radford: `on(‘data’, …)`って書き方はそのまま使えんの？
  • Isaac: 使えるよー。v0.10では`on(‘data’, …)`があると互換モードになって、v0.12では、flowを開始するリスナが追加されるよ。

​

11 of 35

2. Stream

  • Nuno: 後方互換性あるって言ってるけど、v0.8のStreamのコードがv0.10で動かないんだけど
  • Isaac: 互換性があるのはv0.10とv0.12の話ね。この2つは一部例外（と早くなること）を除けば見分けがつかないはず。

​

12 of 35

3. Domain

  • Domainはリファクタリングすることで、より包括的にエラーを継続追跡できる仕組みにしていきます。
    • エラーハンドリングの仕組みをユーザ拡張で作れるように
  • 最終的にはDomainモジュールはユーザ拡張で補えるものになるかもしれません。
    • けどまあとりあえずNodeにバンドルされたままであり続けるよ

13 of 35

3. Domain

  • Bert: エラーハンドリングは本当に糞だよね
  • Issac: 糞だねー。何かいい感じに継続追跡出来るのがでてきたらいいのに。
  • Nuno: エラーハンドリングは確かに糞だけど、ぶっちゃけErlang以外の環境だとどこでも糞じゃね。
  • Arunoda: まあ、Callbackもエラーハンドリングも糞だけど、それでもアプリ作れるしまあいいんじゃん。

14 of 35

4. Module System

  • モジュールシステムには変更は加えません。
  • 一切加えません。モジュールシステムは完成されたものです。一年以上も前に。
  • 明らかに再現可能で、ドキュメントの修正程度じゃ対処できないバグの場合のみ、変更の提案を受け入れます。

15 of 35

5. Alt JS

  • TypeScriptやCoffeeScriptはコアには取り入れません。
  • モジュールシステムが（前述のように）変更されないので、現在動いているAlt JSで書かれたものは、今後も動作可能です。

16 of 35

6. Binary Addon

  • v0.12では、V8のAPIが*著しく*変わったため、基本的には全てのバイナリアドオンが動きません！
  • しかもopensslやzlibなどのライブラリと組み合わせることもとても難しくなった。
  • 今この問題に取り組んでいます。
    • 安定したCのAPI互換レイヤを追加します。
      • Cで書かれたバイナリアドオンがNodeの安定版のブランチ間で、同一コード（できれば同一バイナリ）で動作するように

17 of 35

7. New Language Features

  • V8には新しい言語仕様が取り入れられ、それらはNodeにもやってきます。
  • しかし、それらの仕様を自動的にenableにするつもりはありません。
  • その代わり、何を必要としているのかを検知して、わかりやすいエラーメッセージを投げるようにします。

18 of 35

8. VM module

  • VMモジュールはリファクタリングされ、contextifyモジュールの特長をコアに取り入れます
    • contextがみんなが望む形で動作するようになります
    • マルチコンテキストもサポートされます

19 of 35

9. Child Process

  • ついに子プロセスの同期実行が可能になります。

20 of 35

10. Roadmap

  • v0.12は完成に近づいています。
  • v0.12が出たらみんなに使ってもらいます（安定版だからね）。
  • v0.12の後、v1.0に向けてはAPIの変更は行わないつもりです。
  • v0.12とv1.0の間では、パフォーマンス改善とバグFixと安定性向上に注力します。
  • 今動くものが来年も、しかもより早く安定して動作するよう、最大限の努力をします。

21 of 35

11. OSS

  • これらの決定は民主主義的意思決定に基づくものではありません。しかし、皆さんの意見を取り込む多くの余地があります。
  • もし、Nodeコアにダイナミックな変更を加えたいと思い、npmモジュールを書くのに満足できなくなれば、joyent/nodeをforkして、新しい名前とロゴを作って、それに熱中すればいいのです。
  • OSS FTW

22 of 35

11.1. StrongLoop

  • Bert: StrongLoopはさらなる改善を加えていくよ。それはNodeとは呼ばれなくなるかもだけど。
  • Isaac: “StrongLoop Nodeディストリビューション”のことだよね。それはそれでOSSのあり方なんじゃない。
  • Bert: それそれ。StrongLoopのがコアへの新機能追加の実験場になるとは思ってないけど、何か他のものにはなるかもね。

23 of 35

11.2. Meteor

  • Arunoda: Bertが言うように問題に対するソリューションは必要で、でもそれはNodeとは別物だ。Meteorもそのいい例だよね。
  • Bert: というかユーザ拡張とかforkとかが正しいなら、なんでみんなそんなにMeteorに腹立ててんの？
  • Isaac: え、個人的にはMeteorに腹立てたりしてないよ。MeteorがNodeに対して何かスポーツマンシップに悖る不作法なことしたってのも聞いてないし。

​

24 of 35

11.2. Meteor

  • Isaac: 彼らのコミュニティの作り方については批判的だけどね、もちろん。彼らはやり方を間違った。けどそれは`悪い`とか`怒り`を含んだものではなくて、「ネット上に間違ったことを書いてる奴がいる（から正さないと）」的な反応に過ぎないよ。
  • Isaac: 彼らのmodule/packageシステムはnpmのデザインとは正反対なんだよね。Nodeのエコシステムが今のサイズまでになったのはそのデザインのおかげなのに。

25 of 35

11.3. 批判

  • Eldar: forkすりゃいいじゃんっていうのはアンフェアだと思うんだよね。
  • （色々とアンフェアじゃないと考える理由を挙げている）

​

26 of 35

11.3. Mikeal Rogers

  • コアAPIに対する何がしかの決定を嫌がるやつっていつもいるんだよね。結局、ML上で文句言ってる奴らって大した奴らじゃないんだよ。
  • 声のでかい少数のそういう奴らが貢献したコードなんてほんの少しだし、エコシステムを成長させてる圧倒的多数の人たちはここでは文句いわないよね。
  • なぜなら彼らはコードを書くのに忙しいから。

27 of 35

11.3. Mikeal Rogers

  • APIに対して文句いってる奴らがいる一方で、その何百倍ものライブラリをそのAPIを使って書いて、エコシステムやプラットフォームを成功に導こうとしている人たちがいるんだよね。
  • 批判的な姿勢はプロジェクトを前進させるのには重要だけど、批判があることが失敗を生むことの指標になると思うのは間違いなんだ。成功が批判を生んでるんだよ。

28 of 35

11.3. Mikeal Rogers

  • 声の大きい奴らの意見を聞くことにIsaacは時間を費やすべきだといいたいようだが、あいにく彼は世界で最も早く成長しているエコシステムを作り上げていっている物言わぬ大衆や、全てがNode.jsで作られた巨大なスケールのソリューションをデプロイしている人たちの声に耳を傾けているんだよ。

29 of 35

11.4. 流れ変わったな

  • Rouan: Issac、そしてNodeのコントリビュータの皆さん、ありがとう。
  • Nuno: Isaacありがとう。そしてNodeチームもNode.jsの信念に対して正直で在り続けてくれてありがとう。ユーザとして、貴方たちが何を望んでいるかをしれて嬉しいよ。

30 of 35

11.5. お調子者

  • Fedor: ヒャッハー！新たな火種を起こすぜ！安定性はいいことだよな？でもNodeのコアには明らかに修正すべき問題がいくつかあるよな！でもいいや！ビッグリリースである1.0を優先しようぜ！
  • Bert: いや、その火種全然熱くないんだけど。Isaacに合理的に反対できるやつはもういなくね。

31 of 35

そんなわけで

  • Nodeは民主主義的な意思決定をしているわけではない
  • が、それは当たり前で、MLで騒いでる声の大きい人達の意見を取り入れていたらAPIは安定なんてしないから
  • Isaacがgate keeperでいる限り、NodeのAPIは後方互換性を大切にしてくれる
  • さあ、安心してNodeを使いましょう

32 of 35

コミュニティのリーダー

  • コミュニティの段階に応じてリーダーが担うべき役割が変化する
    • Ryan -> Isaac
  • Node.js 日本ユーザグループも3年以上経ちました
    • そろそろ代表を交代しようと思います
    • 立候補、推薦の方法をMLで周知します

33 of 35

おまけ

34 of 35

Nodeの最近の面白い事例

35 of 35

Nodeの最近の面白い事例

    • Framework / Boilerplate
    • Service
      • http://glide.so/
    • Development Environment
      • http://noflojs.org/
    • Hardware
      • http://tessel.io/
    • OS
      • http://nodeos.github.io/