Node学園祭で日本とアメリカの距離について考えた
普段 Perlに囲まれて生活している僕ですが東京Node学園祭2015参加してきました.
@yosuke_furukawa さんはじめ運営の方々、素晴らしい発表を行ってくれた発表者の方々に深く感謝です。どのセッションも素晴らしかったのだが、特に午前中B会場で行われたNode Discussionにて深く考えるところがあり、つらつらとエモいことを書きたくなった。
Node Discussion？
Node.jsの良いところ悪いところ？みんなでNodeの未来を考える！Nodeディスカッション #nodefest #nodefestB https://t.co/dwKaS2Z0za pic.twitter.com/u1gpAcJcHL
— zcqpo (@zcqpo) 2015, 11月 7
上記のような感じで会場に集まった参加者が、Node.jsのGood Point、Bad Point、Wish List をホワイトボードに貼り付けていき、これについてNode.jsの中の人たちがコメントをしていくという形進んだ座談会（？）的なセッションだった。
会場からの意見に応えるパネリストは以下の4名。改めて見てもすごいメンバーだなあ、と。
日本で生活していると普段Node.js、(に限らずコンピュータ業界でトレンドを作っているプロダクト）、の中の人の声を直接聞ける機会はそうそうあるものではないので会場は満員御礼。一部の議論しかメモできてないが自分のメモは以下のような感じ。なんとなく会場の雰囲気が伝われば嬉しい。
Native Moduleのサポートについて
- nanを使いなさい。https://github.com/nodejs/nan
- nan自体はCoreには入らない
- nanはTop Level ProjectにあるのでActiveにメンテされている
Node Source (Enterprise向けNodeを提供する会社)について
- https://nodesource.com/
-
Node.js だけで食べていけるのはよいこと
-
Enterprise Node.jsのあり方はまだ手探りな状態だが成功させたい
ES6とか未来のjavascriptについて
- Promiseが入ってCallbackは過去のものになるのは決まっている
- ES6はブラウザ向けの仕様なので、直接Nodeに入れると性能がガクッと落ちるものも多い.
- ES6の最終仕様についてはまだ揉んでいる最中. Babelが予測で勝手にサポートしていることものをES6だと思うのは時期尚早。
- BrowserサイドとClientサイドで無理してまで同じAPIを提供する必要はないだろう
Node.jsに関して中級者レベルの資料がほとんどないことについて
- 初級者とか上級者向け(Node開発者)の資料はある
- 企業での実例が増えて、それがシェアされているくことが大事.
Node coreのあり方について
- 無理にcoreを大きくする必要はないが
- 例えばnpmはユーザーランドにあるがうまくいっている.
- とはいえ、エコシステム全体のためにはcoreに強いリーダーシップが必要との意見も. 例えば、http2サポートははコアがリードしてやった方が良いなど
などなど。多岐に渡る話題についてDiscussionがおこなわれた。パネリストの間でも、個々のトピックについて意見が分かれたりしてその場でパネリスト感の議論が始まるなど、非常に聴きごたえのあるセッションだった。
本題：日本とアメリカの距離について
このDiscussionのあと大学院時代に書いた自分の以下のブログエントリをふと思い出した。
研究など... : 国際会議(ICPP'13, ICCD'13) に参加してきました
内容としては、個々人としてみれば日本人とアメリカ人の間に能力の差ってそんなに大きくないように見えるのにもかかわらず、
- 日本のCS系研究者の国際会議でのプレゼンスのなさ
- 日本から世界的に認められる研究が出てこない
ことについて、1. 日本人はほとんど国際会議の運営に携わっていない、2. どこにもPublishされていない最先端の情報に触れる機会がない、3. 結局、研究自体の質も上がらないのでますます国際会議での発表や運営に関わる機会がなくなる、という卵が先か鶏が先か、という非常に苦しい日本のCS研究界隈の状況について書いたものだ。
大学院を卒業してWeb業界で働くようになったが産業界やOSSの世界でも、全く同じことが起きているんだな、ということを感じている。つまり、GoogleやIntel級のように技術的に強いプレゼンスを持つ企業は日本に存在していないし、世界中で使われるプロダクトも(ほとんど)ない。企業内で利用されるシステム技術にしても、アメリカで流行っている技術について一生懸命キャッチアップしては、キャッチアップした瞬間には、すでに新しいものがアメリカで流行っている、ということが繰り返されているように見える。おお、これはまさに自分が日本の大学の研究室で見た光景と全く同じではないか、と。
つまり、すでに公になっている技術をキャッチアップしているだけでは「永遠に縮まらない距離」が日本とアメリカの間に確かに存在しているのだろう。
じゃあ、どうすればいいの？
この「鶏・卵」問題に取り組む上の一つの答えが、今回のNode Discussionの試みの中に見え隠れしていたように思う。「鶏・卵」問題を解決するには、今この瞬間にトレンドを作っている人たちが
- 漠然と考えていること
- これから標準仕様になるかもしれないこと
- 逆にアイディアとしては出ているけどボツになること、
等々について知り、トレンドを単純においかけるのではなく、トレンドを作っている人たちと同じ目線に立って技術を突き詰めていくことしかないと思う。
トレンドを作っている人たちと同じ目線に立とうとするときに、今回Node Discussionで行われたような生の議論、例えばTC39 Memberの@domenikが、Node.jsの中心人物の@rvaggに異を唱える場面を目の当たりにする、というのは(少なくとも自分には)気持ちの問題も含めて非常に効果的だった。
自分は今回のNode Discussionにおいて、積極的に意見したり議論したりはできなかったがこの議論の中に入りたい、入れるように努力したい、と強く思った。それは、あのDiscussionの参加者全員が強弱の差はあれど、感じたんじゃないかなあ、と思う。
そういった意味で、単純にES6がどうなるの？今後のNodeがどうなるの？というは技術的な話を越えて、Node Discussionのセッションは自分の心に残るものになった。
第二回 Hivemall Meetup
今、関わっているサービスで簡易的なレコメンドみたいなものを実装したくなっている関係で、「第二回 Hivemall Meetup」に参加してきた。
回帰分析という言葉を聞いて、そういえば昔はシステムの性能とか電力のモデリングなどやってたなあ、っていうのを思い出した。そのときの経験上、業務知識を多少無理やりでもシンプルなモデル(線形モデルとか)に落としこむのが結局実用的だと思うのだが、Hivemallはそういうニーズをいい感じに満たしてくれそうに見えた。
Hivemall
もう学習モデルとか特別に記述するの大変だから、SQL(というかHive)で学習モデルも記述してしまいましょう、というアイディアで作られているOSSの機械学習ライブラリ. Hive上で動作するようで使い始める敷居が低いのが売りな様子。Treadure Dataでも使えるそうで、以下のブログ記事が(英語だけど)Hivemallを使うときの雰囲気がわかりやすかった。
利用事例
Livsenseさん、OISIXさんからサービス内でのHivemallの利用事例の発表があった。
こちら、新規事業として最近リリースされたサービスだそうで、中古住宅の価格査定をオンラインで行えるサイトだそうです。裏でHivemallを利用して中古住宅の価格を査定しているそうです。
Hivemallを使った感想としては機械学習モデルがSQLだけで完結するのがとてもありがたい、とのこと。ただし、サービスとして意味のある結果を取り出すにはデータの前処理がかなり重要で、学習用データのチューニングは頑張る必要があるそう。まあここらへんの問題はライブラリ側ではどうしようもない気がする。
OISIXさんでは、定期会員の中で解約する人を予測するためにHivemallを利用する予定とのこと。解約しそうな人を見つけることができれば、ポイントを付与したり、ユーザが知らないであろうサービスをレコメンドしたりして解約を防ぐことができる、でしょうという狙い。こちらの事例では、過去の解約会員の行動データをHivemallで分析することで、定期会員の解約行動を予測できそう、という話だった。発表内容は機械学習の話というよりは、事業の中で機械学習を取り入れる意味や、事業担当者の知識を以下にモデルに落とし込めるかが大事、といったプラクティカルな話題が多く非常に参考になった。そういった中で効果があるかわからないけど、とにかく一回トライアルで機械学習やってみる、ということができるのがHivemallの強みだ、という話。
Go オールスターズに行ってきた
以前、mercariのブログ
を読んでGoが気になっていたのだが、著者の@cubicdaiya さんが渋谷でお話しされるということで行ってきた.
Go オールスターズ
dotsさんで開催されたイベントです。渋谷のイベントスペースは駅からも近いし、すごく綺麗なのでいいですね！
Push通知 worker
詳細は冒頭のブログに詳しいので割愛するが、自分が運用しているサービスでも諸々存在するworkerの中で、APNs/GCMを利用したpush通知関連のwokre群はスループットの要求水準がかなり高い。また、APNs/GCM側の問題でQueueが詰まってしまったり、といろいろと頭を悩ませることがしばしばあった。
なのでGoで改善できたらいいなー、と思っている。
具体的には
- Go実装に切り替えることでどの程度スループットが改善するのか
- APNs/GCMが落ちてるときとか、worker自体が落ちたときの復旧とか実際どうしてるのかなあ、という運用のノウハウ
の2点が気になっていた。
Go のメリット
@cubicdaiya さんはじめ登壇者の方はGoのメリットについて以下の3つを挙げている。
1. 単一バイナリ: buildが簡単. deployも簡単.
2. Go Routine/Channel: マルチコアを利用した並行プログラミングが容易に書ける.
3. システムプログラミングができるのに書きやすい: C, Shell Script, LLの代替としてほぼ機能する
自分はGo初心者だが、この3つだけでもGoの人気の理由は分かった気がした。push通知のworker系は要求されるスループットや可用性の水準が非常に高い。このため、キュー処理だったり、並行処理だったり、リカバリ処理だったりをまじめに実装しなければならないのだが、理屈的にもGoのメリットがぴったりマッチする。
とにかくPerlとかでプロセスたくさん立てて並列数を稼ぐのは、メモリ等諸々リソースのオーバーヘッドが大きい。これをGo Routinesで書き換えるだけでかなり良くなるよ、とのことでした。面白かったのが、Goの並行処理は非常に堅牢で、CやらPerlやらで並行処理を実装したときよりもworkerがクラッシュすることは少ない、とのこと。ブログで紹介されているリカバリ機構はあるけど、なにせ堅牢なので半年運用してて一度も使ってない、というような話をしていてすごいなと思った。
YAPC Asia Tokyo 2015に参加してきました
昨年に引き続きYAPC Asia Tokyo 2015参加してきました。楽しかったです。まずは運営の方々・講演者・参加者全ての方々に感謝です。
会場は東京ビッグサイトの会議棟でした。トークは5並列、5つの講演会場で行われておりどの部屋もかなりの収容人数なんですが、それでも立ち見だったり入室できなかったりが出る盛況ぶりでした。合計2130人が参加したそうな。
トークの内容はコアなPerl の話はもちろん、Web開発のケーススタディ、CI、クラウドやらデータベースやらのインフラ、データ分析基盤とPerlの枠を越えてWeb界隈のテクノロジ全般を扱う、非常に層の厚いカンファレンスだったと思います。
ベストトーク賞
参加者の投票によって決定するベストトーク賞ですが今年は以下のような感じでした。
１位はPerlカンファレンスっぽくPerlの話で落ち着きました。良かったw
２・３位に両方ともHTTP/2の話が入ってきているところは、講演の素晴らしさはもちろんですが、HTTP/2それ自体への関心の高さの表れでしょうか。@kazuho さんの講演曰く、ブラウザ・サーバともにHTTP/2への対応はかなり進んでおり、今年の秋から年末にかけて一気にHTTP/2化が進むだろう、とのことだったのでHTTP/2への期待は高まります。
感想とかとか
- 若い人とか外国からの参加者が昨年より多かったような気がしてる。
-
二日目のトラックAでやっていた Profiling & Optimizing in Go - YAPC::Asia Tokyo 2015 が個人的にすごかった。Go 1.5の新機能の宣伝をかねて、Go プログラムをLive Codingでゴリゴリ最適化していくって内容なんですが、カジュアルに逆アセンブルしてみたり、Goのデータレイアウトの説明しつつメモリアロケーションを最適化したり、ハードコアな最適化をさくさくっとしていて「ワーオ」って感じで見れました。
- 無限コーヒー美味しかった.
- LT、CONBUチームのLive設営すごかった！
- YAPC 2015 Closingも最後の最後、これでYAPCも最後かあ、というところで@lestrrat さんが指し示した http://builderscon.io/ というページ。No Promises !!! と強く主張されてましたが、熱い！と感じました。YAPC自体は今年でラストってことですがYAPCのコミニティの力って本当にすごくて、これからも形を変えて受け継がれていくんだろうし受け継いでいきたいな、と感じました。
とにもかくにもYAPC長い間お疲れさまでした！
Thank You YAPC Asia Tokyo ! ! !
