東京Node学園祭2017 レポート

東京Node学園祭は、Japan Node.js Associationが主催する、日本最大のNode.jsのカンファレンスです。昨年までは有志団体日本Node.jsユーザーグループによって開催されていましたが、今年は同団体がJapan Node.js Associationとして法人化され、法人格として初めての開催となりました。

今年「東京Node学園祭2017」は11月25日、11月26日の2日間開催され、1日目は法政大学、2日目はリクルートテクノロジーズを会場としました。本レポートでは、いくつかの注目講演や、セッションをピックアップしてレポートします。

1日目カンファレンスデイ、オープニングトーク

1日目はカンファレンスデイとなっていて、主に講演で構成される内容になっています。

まず古川代表（@yosuke_furukawa）より今年のNode.js及びコミュニティについての進捗について発表がありました。また今年のスローガンが、Be More Global and InteractiveとTo grow with biginnersであることに言及しました。

Joyee Cheung氏「アリババでのNode.js」

Joyee Cheung氏（@joyeecheung）は中国アリババ社のエンジニアです。アリババ社では現在500人以上のNode.js開発者が在籍し、1,000以上のNode.jsアプリケーションが稼働しています。講演ではアリババ社におけるNode.jsアプリケーション開発・運用の様子を紹介しました。

中国でこのように大規模にNode.js開発を展開する上での大きな問題の一つは金盾 (国家レベルのファイヤーウォール) です。中国国内から、公式のnpmレジストリに接続することは可能ではありますが、非常に低速であり、開発や運用で求められるスピードを満たせません。そこでアリババではcnpmというツールを開発し、この問題を回避しています。cnpmとはエンタープライズ向けの専用のnpmレジストリを立ち上げるためのツールです。アリババではcnpmで構築した独自のレジストリを社内で運用しており、そこから専用のコマンドラインツールを用いてNodeモジュールをインストールすることで、高速なNodeアプリケーションのインストールを実現しています。

アリババではアプリケーションスタックのコア部分でEgg.jsというフレームワークを利用しています。Egg.jsはKoaをベースにしたフルスタックのフレームワークです。 Egg.jsはコア部分はOSS化されており、その上にプロプライエタリなプラグインを構築することで、アリババの各サービスを構成しています。

資料：https://github.com/joyeecheung/talks/blob/master/node_fest_2017/nodejs_at_alibaba_tokyo.pdf

Myles Borins氏「OSSガバナンスモデル: BDFL型からコンセンサス探索型へ」

Myles Borins 氏（@mylesborins）はGoogle Cloud Platformチームのデベロッパーアドボケイトであり、NodeのBoard of Directorsの1人です。講演では、Nodeの現在のガバナンスモデルと、その歴史的な変遷について発表がありました。

Node コミュニティは現在、11人のBoard of Directors, 20人のTSCメンバーと, 108人のコラボレータによって運営されています。Board of Directorsの役割は、人事面、金銭面などのNode Foundationの運営方針についての判断・決定を行うことです。TSC （⁠Technical Steering Committee）の役割は技術的な方針についてのハイレベルな判断・決定をおこなうことです。コラボレータは個々の具体的な開発・変更に対して具体的な判断を行います。コラボレータ同士が特定の問題に対して、合意に至れない場合はTSCが判断します。TSC内でも合意に至れない場合は、TSCの中での投票によって決裁します。ただし、合意に至れないことはかなり稀です。

ところで、Nodeは過去にはBDFLモデルによって運営されていた時期がありました。BDFLとはBenevolant Dictortor for Lifeの略で、Python言語コミュニティにおいて作者Guido van Rossumの肩書きを表す言葉として造語されました。BDFLはその名前が示すように、プロジェクトの意思決定に関して最終的な決裁権を持った1人の人間です。

世の中には、何名かの有名なBDFLがいます。例えば、リーナス・トーバルズは長年LinuxのBDFLです。ラリー・ウォールはPerl言語のBDFL、そして、まつもとゆきひろはRuby言語のBDFLです。

Node.jsは過去に3名のBDFLによってガバナンスされた時期がありました。1人目のBDFLはRyan Dahlです。彼は2009年のJSConf EUでNode.jsを初めて発表し、そこから現在のNodeプロジェクトが始まりました。2人目のBDFLはIsaacs Schlueterでした。3人目のBDFLはTJ Fontaineでした。この頃からNode.jsはJoyentによってスポンサーされるようになりました。

企業によるスポンサーが始まってからNode.jsは動きが止まってしまいました。0.10.0がリリースされてから、0.12.0がリリースされるまでに、非常に長い時間がかかってしまいました。その影響で2014年12月にNode.jsはio.jsとしてフォークされました。io.jsはその後v1, v2, v3とリリースされ、v4になった時に、再びNode.jsにマージされました。

この時Node.jsはコンセンサス探索型（Consensus-seeking）の意思決定プロセスを採用しました。具体的には、すべての変更はPull Requestを通して行われる必要があります。そして十分な時間、コミュニティーによるチェックを受ける必要があります。チェックの結果、反対意見が無いことがマージされるための条件になります。

また、後方互換性を切る変更（Semver Major Changes）については、すべてTSCのレビューを受ける必要があります。これらはTSCのミーティングで議論されますが、理想的にはPull Requestの議論の中で自然なコンセンサスに至ることが好ましいです。

Nodeでは、よりコミュニティに力を与えることに最適化されているコンセンサス探索型を採用しています。しかしBDFL型と比較して、双方ともメリット・リスクがあり、それを理解した上でガバナンスモデルを選択していくことが重要となるでしょう。

資料：https://kni.sh/osls-2017/

Franziska Hinkelmann氏「Node.jsのJSエンジン: TurbofanとIgnition」

Franziska Hinkelmann氏（@fhinkel）はGoogleのV8チームのエンジニアです。講演では、Node 8から採用されているコンパイラーTurbofanとIgnitionについての発表がありました。

従来のV8のコンパイラはFullCodegenという最適化前のマシンコードを出力するコンパイラと、Crankshaftという最適化を行うコンパイラの2つから構成されていました。かつては、この2つの構成は非常に良い結果を生み出していましたが、時間とともに問題が出てきました。例えば、Crankshaftはtry catchをうまく最適化できません。また、ES6以降の機能については基本的にうまく最適化ができません。読みやすいコードがCrankshaftにとっては最適なコードとならない場合が多く、時として、Crankshaftに向けて最適化されたソースコードは人間にとって読むに耐えないものになることがあります。

これらの問題を解決するために、V8チームは全く新しいコンパイラパイプラインを構築しました。それがIgnitionとTurbofanです。Ignitionはベースラインコンパイラと呼ばれ、従来のFullCodegenに相当するものです。FullCodegenとの違いはIgnitionはASTを入力として受け取り、bytecodeを出力することです。Turbofanは最適化コンパイラで、従来のCrankshaftに相当するものです。TurbofanはSpeculative Optimizationという機能を実装しています。Turbofanはコードがどのように実行されるかを観察し、プログラムの構造に対する予想（speculate）を行います。例えば、add (obj) { return 1 + obj.x }という関数があり、add({ x: 12 }), add({ x: 123 })のような呼び出しがランタイムに行われたとすると、Turbofanはこの関数がadd({ x: int })というシグネチャを持っていると「予想」し、add関数に対して大胆な最適化を行います。このような最適化を行うことで、マシン語レベルで見たときに命令数が10分の1以下となるような、極端に最適化されたコードを出力できます。

この時add({ y: 17 })のような呼び出しが行われた場合はどうなるでしょうか。この時Turbofanはこの関数を、脱最適化（deoptimize）します。つまり、この場合、先の大胆に最適化されたコードは破棄され、上のケースに適応できる、少し遅いコードに変換されます。Turbofanのこのような性質のため、静的に型付けされているかのようなJavaScriptコードが、Turbofanで最も速く動くコードとなります。

Turbofanで最も速く動くコードをまとめると、以下のようになります。

静的に型付けされているかのようなコード
ESNextを使っているコード
人間にとって読みやすいコード

スライド：https://fhinkel.github.io/JSEngines-HowDoTheyEven/NodeFest/assets/player/KeynoteDHTMLPlayer.html

Rob Howard氏「ロボットと関数型プログラミング」

Rob Howard氏（@damncabbage）はオーストラリアAmbiata社のエンジニアです。オーストラリアではトイロボットシミュレータという有名なプログラミングの問題があり、面接試験などで良く使われているそうです。それは、4x4マスの盤面上に配置されたロボットに、いくつかの命令、例えば「前に進め」「⁠右に回れ」を与えて、最終的にロボットが盤面上のどこにいるかを出力するという問題です。この講演では、Nodeで実装されたトイロボットシミュレータを、素朴な実装から、徐々に洗練された実装へとリファクタリングしていく様子を披露しました。その過程において、関数型プログラミングの考え方が如何に重要な役割を果たすかを、具体例と共に示しました。

素朴な実装では、ロボットは命令のかたまりの文字列を受け取って、最終的に自分の位置をコンソール出力するという振る舞いが、そのままプログラム上に列挙されます。この時最大の問題は、ロボットの最終的な出力が、コンソールへの出力という副作用によって行われることです。副作用をテストするのは難易度が高く、煩雑になりがちで、本来テストすべきロジック部分からフォーカスが外れてしまいます。redux-sagaに見られるような、副作用を命令オブジェクトとして抽象化し、外部のインタープリータ部分に実行を委譲する設計を採用することで、そのような問題をエレガントに解決できることを示しました。

スライド：http://robhoward.id.au/talks/2017/11/a-toy-robot-and-a-functional-pattern.pdf

スポンサートーク

スポンサートークセッションでは、ゴールドスポンサーの6社、ドワンゴ、リクルートテクノロジーズ、メルカリ、Yahoo! JAPAN、日産自動車、Auth0からの発表がありました。各社ともプロダクト／社内ツールなどでNodeを利用しており、Node及びJavaScriptのエンジニアを強く募集しているという内容でした。

1日目アフターパーティ

講演終了後は会場をfreee株式会社に移し、アフターパーティが行われました。パーティ中はプログラミングを用いたライブDJパフォーマンスが披露されました。

2日目インタラクティブデイ

2日目はインタラクティブデイとないっていて、主にハンズオンやワークショップ形式のイベントで構成される内容になっています。

Node Discussion

Node Discussionは、NodeコミュニティのCore Value（Node コミュニティにとって価値があるもの⁠）⁠、Bad Points（Nodeの悪いところ⁠）⁠、Wishlist（これからのNodeに期待すること）について話し合う場です。会場にはNodeコアコントリビュータのMyles Borins, Franziska Hinkelmann, Joyee Cheungを迎えて、盛んに議論が行われました。

Core Valueとしては、NPMコマンド及びエコシステムが素晴らしいこと、Nodeの非同期プログラミングの性質が優れていること、コミュニティーがオープンであること、安定したリリースを維持していることなどが会場から挙げられました。Hinkelmann氏は他に、サーバーサイドとクライアントサイドの相互運用性があるという点を加え、Cheung氏はドキュメンテーションに比重が置かれている点を挙げました。

Bad Partsとしては、わかりやすいビジョン・ロードマップをNodeが持っていないという点が指摘され、Martin Heidegger氏（@leichtgewicht）とMyles Borins氏との間で熱い議論が交わされました。Heidegger氏は、Nodeが何のためのツールであるかという明確なビジョンを持たず、今後どのようなロードマップを敷いているのかも外から見えないことが、外部のユーザーにとって問題であるという点を強調しました。それに対し、Borins氏はNodeはサーバーだけではなく、現在ではフロントエンド・エレクトロン・React Nativeなどを支えるフレームワークとなっているため、そのようなNodeの使い道を限定するようなビジョンの設定は必要とされていないと反論しました。また、Hinkelmann氏は、全体としてのビジョンのようなものは持たないが、各ワーキンググループが各自のプランを持っており、そのようなプランによってプロジェクトが進行していると主張しました。そのような進め方の成功例としてES moduleとPromiseが挙げられるとBorins氏が付け加えました。

質問のコーナーではAyo.jsは何であるか、Ayo.jsには意味があるのか、という質問がされました。それに対して、Borins氏はAyo.jsは、TSCとCTCの問題が始まる前から始まっていること、つまり、TSCの問題がきっかけでAyo.jsが始まったのではないことを指摘しました。また、Ayo.jsのコントリビュータの多くはNodeにも継続してコントリビュートしており、Ayo.jsだけにコントリビュートしている訳ではないこと、また、Ayo.jsへのコミットは順次Nodeへチェリーピックされていることを取り上げ、以前のio.jsのフォークのような敵対的なフォークではなく、Nodeコミュニティーの一部として、Nodeの開発が行われるもう一つの場所という性質が強いことを指摘しました。

他にも様々な質問や指摘が会場参加者からされました。それに対し、コアコントリビュータや古川代表のコメント・補足が行われ、Nodeコミュニティの現状を具体的に知ることができる貴重な議論となりました。なお議論自体は、基本的には英語で行われ、区切りのついたタイミングで古川代表とHeidegger氏によって、逐次日本語に翻訳されるという形式で進行されました。

Code And Learn

Code And Learnはオーガナイザーからのインストラクションを受けて、Nodeのリポジトリ本体に参加者が実際にコントリビュートを試みるというワークショップ形式のイベントです。なお、この形式のCode And Learnは、世界中のNode関連イベント、例えばJSConf EUやNode Interactiveなどでも開催されており、本ワークショップはその日本版という位置づけになります。

古川代表のブログ記事を参照しつつ、Node本体にコントリビュートする際のインストラクションが述べられた後、あらかじめオーガナイザーが用意したコントリビュートしやすいトピックが列挙されました。参加者はそこから自分にあったテーマを選んで Node本体へコントリビュートを試み、実際に13人の参加者によって16本のPull Requestが作成されました。普段は一方的に受益しているOSS利用者がプロジェクトに還元できる貴重な機会となりました。

バリエーション豊かなワークショップ

恒例となったNode Schoolでは、メンターからの指示を受けながら、workshopperというコマンドラインツールを使ってインタラクティブにNodeのチュートリアルを進めてゆき、Node/JavaScriptの基本の理解を深めるワークショップが行われました。

LINE Bot hands-onでは、オーガナイザーからのインストラクションを受けて、参加者がその場でLINE botの作成を試みました。参加者のうち7名がワークショップ中にBOTを完成させてLTで発表することができました。

Data Visualization Workshopでは、海外ゲストのShirley Wu氏（@sxywu）からのインストラクションを受けて、D3.jsを用いたインタラクティブなデータビジュアライズアプリケーション作成のワークショップが行われました。

Auth0ワークショップでは、Auth0社の古田秀哉氏（@furuhide1）からのインストラクションを受けて、実際にNode.jsとReactで構築されたアプリケーションにAuth0の認証を組み込むチュートリアルが行われました。

まとめ

本レポートでは、東京Node学園祭2017より、著者が注目する講演と、セッションをピックアップして紹介しました。この他にも多くの発表が行われ、全体では、スピーカー28人による37の講演（うちLT14本）と、6種類14コマのワークショップ形式のイベントが開催され、大盛況のうちに幕を閉じました。