D.G.Synodinos「TJ HolowaychukとMike Cantelonへのインタビュー（『 Node.js in Action』作者）」
InfoQ 2011.10.11のエントリ
InfoQ: Node.js in Action: Interview and Book Excerpt
- 普段スピーカとかやらないTJ Holowaychukがざっくばらんな感じで面白い
- 24歳、オール独学、グラフィックデザイン畑出身、phpを最初に学んだのは不運、rubyなみに堅牢なスクレイピングツールをnodeにも欲しい、などなど
- 具体的に名指ししてないけど、pyjamasとかGWTのような「jsを書かずに済ませる、jsを生成してくれる」系の言語/DSLに色々意見があるらしく、一問一答にそのトピック何度も差し挟まれるんだけど、歯が立たない箇所が多し
- 追記：TJはCoffeescriptいらない派らしい
以下斜め読んだ内容
- 近刊の『Node.js in Action』
- Node.jsおさらい
- サーバーサイドJS
- スケールするハイパフォーマンスなウェブアプリケーション開発に強い
- http、tcp/ipネットワーキング機能へアクセスをサポートした非常にミニマルなjsインターフェース
- 非同期プログラミングモデル
- リアルタイムアプリケーション開発と相性がよい
- チャット、オンラインゲーム、リアルタイム統計ツール、などなど
- 『Node.js in Action』の狙い
- 具体例を交えたチュートリアル本
- nodeを何も知らない段階からスタート
- 読者は、順番のnodeの機能、テクニック、コンセプトを学ぶ構成
- この本で学べる機能・コンセプト・テクニック
- プロダクションレベルのnodeアプリケーションを開発するレベルに設定されてる
- 『Node.js in Action』の中身。基本パート
- 開発環境のセットアップ
- nodeコミュニティで開発されたモジュールの利用方法
- 何個かデモ用プログラムを書いて実行するチュートリアル
- nodeアプリケーションのよく見られるパターンの基礎を学べるようになってる
- 非同期プログラミングの世界へのダイブ
- アプリケーションのボトルネックを軽減させるためにnodeが採用してるプログラミングモデル
- 『Node.js in Action』の中身。基本編の次
- 出版元のManningがInfoQ読者向けに３章の抜粋版をプレゼントしてくれた
TJ Holowaychuk、Mike Cantelonへ質問投げて答えてもらった。著書とnodeについて
- Q：自己紹介よろしく
- A：by TJ Holowaychuk
- 24歳
- カナダのBritish Columbia州Victoriaに住んでる
- 教育系スタートアップLearnBoostチームのメンバー
- 4〜5年前にグラフィックデザイナーとしてキャリアをスタート
- その後ソフトウェア開発の世界に
- ソフトウェアはもっとクリエイティブになる余地があると感じてる
- オール独学。グラフィックデザインもソフトウェア開発も
- 「最初の言語がphp」という「よくある間違い」を自分も犯した
- １〜２年はDrupalのモジュール開発やDrupal使ったアプリ開発やってた
- それからphp以外の言語も見てみることにした
- ようやく「phpは残念な言語」という認識に到達
- 何個か言語を新たに勉強した結果、Ruby/Sinatraにしばらく落ち着いた
- php時代には知ることのなかったコンセプトをrubyの勉強を始めた最初の１年で色々吸収できた
- Rubyでの開発を続けていくとrubyが提供してるマジカルな挙動への嫌悪感が高まった
- Rubyのマジカルな挙動は誤用され、成果ゼロで、頭痛の種を生むことが多かった
- パーサーテクノロジーに興味を持ち始めた
- 追っかけてたのはRagelとLemon
- Ragel/LemonがRyan Dahlのebb（ruby/cで書かれたwebサーバ）を知るきっかけ
- ebbはnodeのルーツの１つ
- A：by Mike Cantelon
- Q：nodeとは何か。nodeのここが好き。ざっくり説明よろしく
- A：by TJ Holowaychuk
- nodeを知ったのはnodeのircのメンバーが30人以下のころ
- すぐにSinatraにインスパイアされたフレームワークのプロトタイピング始めた
- これがExpress
- Express - node web framework
- Expressを開発しながら実感していったこと
- 例えば、データマイニングにおけるloading系機能
- A：by Mike Cantelon
- Simon Willisonのブログ記事がnodeの魅力に取りつかれたきっかけ
- 2010年のはじめくらい
- 色々驚かされた
- jsでwebアプリが書けてしまうこと
- 低レベルのTCP/IPアプリケーション、プロトコルも実装できること
- Ｑ：どんなタイプのアプリがnodeと相性抜群か。さらにnodeからしか得られないメリットはあるか。
- A：by TJ Holowaychuk
- ネットワーキングプラットフォームとしてnodeはデザインされてる
- この点を踏まえて、既にnode導入が広まってると思う
- nodeはwebサーバー開発の堅牢な基礎部分を提供してくれる
- nodeの利点として他にはコードの再利用可能性
- クライアント／サーバーサイドでの再利用。同じjsで書かれてる
- 大量の同時接続（concurrency)が必須要件になってるアプリやシステム
- ここでもnodeは大活躍
- ircサーバー、mailサーバ、webサービス、ジョブキュー、チャット、log reader、etc.
- いずれも「リアルタイム」性が必須要件のサービス、アプリ、システム
- 膨大な数のモジュールがnodeにはある
- エンジニアが思いつくものなら何でも開発できるツールになりつつある
- コマンドラインツール、amazon s3クライアント、プロキシ、etc..
- A：by Mike Cantelon
- TJに同意
- nodeとコミュニティベースのnodeモジュール群の存在はでかい
- やっつけ仕事なモジュールは少ない。クリーンなモジュールが多い。モジュールを利用してなんか作るのは楽しい
- Q：node利用の現状。TJとMikeの観測範囲でどんな導入例あるか。ざっくりと。
- A：by TJ Holowaychuk
- 若いプロジェクトでnodeを使うのは、本当に驚くような経験になる思う
- nodeくらいのスピードで成長するプロジェクトは見たことがない
- 2年前。nodeのircに参加してる人もMLの登録してる人も数えるくらいの規模だった。
- 今やnodeの規模は数千人規模。Google/Yahoo/Facebook/Twitterのような大企業からも注目されるプロジェクトに成長
- nodeの面白い使われ方もたくさんみてきた
- なかなかの完成度のリアルタイム解析ツールがいくつかリリースされてる
- よくある利用例
- チャットサーバー、ユーザのインタラクションをリアルタイムに表示するヒートマップ、マルチプレイヤーゲームサーバ、 etc.
- A：by Mike Cantelon
- Ｑ：インフラ全部をnodeで作るか。既存のインフラへのアドオンとしてnodeを使うか。どっちの利用法が正解？
- A：TJ Holowaychuk
- A：by Mike Cantelon
- Ｑ：node導入における最大の障害は？node導入にあたって開発チームがやるべきこと
- A：TJ Holowaychuk
- とりあえずnodeの変化が速い。node本体もnodeモジュールもどんどん変化する
- 現状の実装よりもより優れたパターンを発見、置き換え。これを絶えず続けてる
- 継続的に追っかけることが必要になってくる
- Ｑ：nodeの世界に足りないもの。
- A：TJ Holowaychuk
- Q：nodeで開発をしてるエンジニア。よくあるパターンは？
- A：by TJ Holowaychuk
- たいていのエンジニアはjsに不案内。そのくせjsを再検討するための時間を取ろうとしない人が多い
- jsを生成してくれる言語がたくさんある
- （補足）：List of languages that compile to JS - GitHub
- jsを学びたくないエンジニアはそのどれかに飛びつく
- nodeを使いたい。でもruby/pythonライクにコード書きたい。二兎を追う
- jsはユニークな立場に置かれた言語。誰もが使わないといけないから
- jsを学ぶ時間を取らずにこの手のjsへコンパイルされる言語へ飛びつくことは間違いの元だと思う
- 同じパターンはnodeモジュール利用でも見かける
- 学びたがらないエンジニアはいきなりconnectやexpressに飛びつく
- ベーシックなnodeのhttpサーバーを試すとかしない
- 全体としては、nodeがどういう段階にあるプロジェクトなのかは多く人が正しく理解してる
- クライアントサイドjsでも同じパターンが発生してる
- こういうありがちなパターンが問題だと断言するつもりはない
- だた、低レベルなトピックを楽しんで学んでいるというconnect/expressユーザだっている。
- そういう感想に読んだ
- A：by Mike Cantelon
- 低レベルなトピックは習得にそれなりの時間がかかる
- 過去何年も経験した他の言語での開発経験と比べると、nodeでの開発は学習しやすいと思う
- nodeコミュニティからリリースされるモジュールはクリーンなものが多い
- nodeには優れたパッケージ管理ツールがある
- Q：nodeエンジニアにオススメのライブラリ、お気に入りのライブラリ
- A：TJ Holowaychuk
- node_redis
- Redisクライアント
- by Matt Ranney
- 効率的でエレガントなモジュールデザイン
- MattがCTOやってるVoxerのiPhoneアプリで使われてる
- プロダクション環境で利用・テストされてるモジュール
- Socket.IO
- 定番。知ってる人も多いはず。もし知らないなら必見。
- クライアントサイドへのストリーミング機能の実装は超面倒
- これを統一的、エレガント、高パフォーマンスに実装できるライブラリ
- node-formidable
- Felix Geisendörfeが開発
- たくさんのユーザがマルチパートパーサーとして使ってる
- FelixがやってるスタートアップTransloaditで利用・テストされてる
- GB単位のデータアップロードで威力発揮する
- node-http-proxy
- nodejitsuが開発
- 高性能で手軽に使える
- リバースプロキシーとして超簡単にかんたん
- nginxやHAproxyと比べるとセットアップの手間いらずなところに驚くはず
- バーチャルホスト(vhosts）やおよそプロキシに求められてる機能のセットアップは一瞬で、jsでできる
- node_redis
- A：by Mike Cantelon
- Ｑ：webサーバ以外でもnodeは重要なテクノロジーだと思う？
- A：TJ Holowaychuk
- yes
- 他と比べてnodeだと独自プロトコルや高速tcpサーバ書くのかんたん
- （typo??）” you really have to try to make them slow”
- nodeを熟知してないエンジニアでもすぐれた結果を得られるものを作れるところ
- これまでに使ったことのあるネットワーキングフレームワークの中でnodeが一番自然にデザインされてる
- コールバックへの不満は多い
- でもコールバックを使うことは非同期プログラミングの考え方の習得を助けてくれる
- コールバックが使われてるコードでは、「今発生中のもの」「非同期なもの」「後で発生するもの」それぞれが別物であることがビジュアルで分かるから
- A：by Mike Cantelon
- 自分の場合、コールバック習得に結構時間かかった
- 身につけてしまうと、コールバックスタイルは自然な書き方だと感じてる
- nodeは用途限定・サーバー向けのテクノロジーじゃない
- nodeのおかげでコマンドラインインターフェース向けツール作るのが楽しくなった
- Ｑ：他の言語（javaとか）と比べたときのjsのツール群への満足度。常用ツールは？
- A：TJ Holowaychuk
- yesかつno
- 他の言語の方がいい部分もあるし、nodeに軍配上がる部分もある
- いちコントリビュータとしてはjs/nodeの世界にはキツイ部分あり
- 「jsを生成する／jsへコンパイルされる」言語/DSLが使われてる現状
- 「@」とか「#」とか「$」に出会った数だけ痛みが。。
- しかもこの手の言語/DSLとnodeのモジュール。２つ統合して欲しいなどと期待される。これもキツイ
- js/nodeにはこの手の言語/DSLがたくさんある
- jsの文法に文句を言う代わりに、もっとjsがサポートする機能や特徴を学ぶ時間を取ればいいのに、と思う
- タイピングがネックなんだったら間違ったやり方をしてるだけのこと
- nodeには優れたパッケージ管理ツールがある。
- npm。他の言語と比べてもベスト。
- npmが特別優れてる訳
- 多くのレガシーな機能をサポートする必要がない
- グローバル／ローカルインストールは、作法としてすでに定着した
- 初期npmにはなかった作法
- この作法に従う／従わないは自由に選べる
- パッケージ管理ツールによくある「今後このやり方でやりなさい」的な部分
- npmにはこういうところがない
- npmはnodeエコシステムを支えるソリッドな基礎となってる
- Ｑ：nodeの今後の進化について予想。nodeの今後に期待してることある？（新機能、安定性、パフォーマンス向上、etc..）
- A：TJ Holowaychuk
- nodeに限らず、nodeには安定してほしい
- 今すぐに安定、迅速に安定してほしいとは思わない
- 誰もがフレームワークに安定性を期待してる
- 他方、nodeはレガシーなAPIのことをそんなに気にするべきじゃない
- nodeに変化が必要なら、完全なソフトウェアを求めて変化し続けるべき
- stream APIはもっと使いやすくできると思う
- コンセプト自体はstream APIはシンプルで優れてる
- 入り組んだシステムが絡んでくるとstreamのように振る舞い・操作できるオブジェクトを作るのがとても難しい
- stream用のfilter APIについては前々から議論されてる
- ファイル読み取り、データをパイプしていて出力する途中に、gzipフィルターを入れる、とか
