読者です 読者をやめる 読者になる 読者になる

以下斜め読んだ内容

pseudo translation of useful posts, book reviews, remarks,etc. twitter: feeddict

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に色々意見があるらしく、一問一答にそのトピック何度も差し挟まれるんだけど、歯が立たない箇所が多し
以下斜め読んだ内容
  • 近刊の『Node.js in Action』
    • railsphpでの経験のあるエンジニアでnode使ってweb開発しようかと思ってる人向け
    • プラットフォームとしてのnodeの紹介をしてる本
  • 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』の中身。基本編の次
      • nodeのhttp API
      • アプリケーションのデプロイ
      • テンプレートシステム
      • ファイルシステムとの対話
      • tcp/ipサーバー
      • コマンドラインツール
  • 出版元のManningがInfoQ読者向けに3章の抜粋版をプレゼントしてくれた

TJ Holowaychuk、Mike Cantelonへ質問投げて答えてもらった。著書とnodeについて

  • Q:自己紹介よろしく
  • A:by TJ Holowaychuk
    • 24歳
    • カナダのBritish Columbia州Victoriaに住んでる
    • 教育系スタートアップLearnBoostチームのメンバー
    • 4〜5年前にグラフィックデザイナーとしてキャリアをスタート
    • その後ソフトウェア開発の世界に
    • ソフトウェアはもっとクリエイティブになる余地があると感じてる
    • オール独学。グラフィックデザインもソフトウェア開発も
    • 「最初の言語がphp」という「よくある間違い」を自分も犯した
    • 1〜2年はDrupalのモジュール開発やDrupal使ったアプリ開発やってた
    • それからphp以外の言語も見てみることにした
    • ようやく「phpは残念な言語」という認識に到達
    • 何個か言語を新たに勉強した結果、Ruby/Sinatraにしばらく落ち着いた
    • php時代には知ることのなかったコンセプトをrubyの勉強を始めた最初の1年で色々吸収できた
    • Rubyでの開発を続けていくとrubyが提供してるマジカルな挙動への嫌悪感が高まった
    • Rubyのマジカルな挙動は誤用され、成果ゼロで、頭痛の種を生むことが多かった
    • パーサーテクノロジーに興味を持ち始めた
    • 追っかけてたのはRagelとLemon
    • Ragel/LemonがRyan Dahlのebb(ruby/cで書かれたwebサーバ)を知るきっかけ
    • ebbはnodeのルーツの1つ
  • A:by Mike Cantelon
    • 39歳
    • カナダのBritish Columbia州Vancouverに住んでる
    • 10年くらいphp
      • 手がけてたアプリは色々
    • 小規模の会社でリードディベロッパーとして何年も働いてた
      • その会社でフルスタックのオレオレCMSを開発してた
      • CMS事業の売り上げが今一つ。受託仕事もやってた
      • 自分らのCMSを売り込もうとしたときがちょうどオープンソースが盛り上がってきた時期とぶつかった
      • 自分らのCMSが古ぼけた代物になっていった
    • オープンソースの世界にダイブすることにした
    • それからはDrupal使って仕事してる
    • 現職は新聞社の開発チーム。Drupal開発のサポートしてる
    • phpには色々と限界がある
    • 他の言語を知るにつれて自分が正気になれた
    • 数年くらいpython/rubyで色々試した。その後jsを再訪した
    • js再訪がきっかけでnodeに出会った。その魅力にとりつかれた
  • Q:nodeとは何か。nodeのここが好き。ざっくり説明よろしく
  • A:by TJ Holowaychuk
    • nodeを知ったのはnodeのircのメンバーが30人以下のころ
    • すぐにSinatraにインスパイアされたフレームワークのプロトタイピング始めた
    • Expressを開発しながら実感していったこと
      • Sinatra/rubyとnode/jsは別世界
      • node使うと、サーバーやwebアプリケーションがとても自然に書ける
    • 例えば、データマイニングにおけるloading系機能
      • nodeやる前。大量のruby workerプロセスが必要だった
      • node使うと自作のruby実装よりも多方面で改善した
        • 表現力、自然な記述、パフォーマンス
  • A:by Mike Cantelon
  • Q:どんなタイプのアプリが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
  • Q:インフラ全部をnodeで作るか。既存のインフラへのアドオンとしてnodeを使うか。どっちの利用法が正解?
  • A:TJ Holowaychuk
    • 両方とも正解。
    • DrupalRailsのようなフレームワークは堅牢
      • 弱点。リアルタイムアプリ向けにデザインされてないこと。
    • Drupal/nodeとか、Rails/nodeという使い方は「あり」
      • とはいえ。ロジックの複製、DBモデリング、セッション統合、等々にほとんど開発リソース吸い取られる
        • ありがちなところが併用のマイナス面
    • railsdrupalなど人気フレームワークやアクの強い(opinonatedな)フレームワークとnodeを組み合わせた開発例はみかける
      • チャットサーバ、リアルタイム統計、レポーティング、マッピング、etc..
  • A:by Mike Cantelon
    • TJに一票
    • 今後フルスタックでオープンソースのウェブアプリケーションがnodeの世界にも出てきたら。。。
      • cms、blogエンジン、etc..
      • nodeの経験が少ないエンジニアへもnoceが広まるはず
      • nodeを併用しようとするエンジニア、nodeに完全シフトするエンジニアが出てくるはず
  • Q:node導入における最大の障害は?node導入にあたって開発チームがやるべきこと
  • A:TJ Holowaychuk
    • とりあえずnodeの変化が速い。node本体もnodeモジュールもどんどん変化する
    • 現状の実装よりもより優れたパターンを発見、置き換え。これを絶えず続けてる
    • 継続的に追っかけることが必要になってくる
  • Q:nodeの世界に足りないもの。
  • A:TJ Holowaychuk
    • スクレイピングツール
      • rubyからやってきて「欲しいな」と思うものの1つ
      • もちろんnodeにはjsdomがある
      • まあたいていうまく動いてくれる
      • node製のhtmlパーサーもいい感じなもの。中にはある
      • rubyの世界と比べると見劣りする
      • 自分の場合、rubyでの開発ではnokogiriとかをテキストマイニングに使ってた
      • jsdomの持つ可能性は高い。jsdomはサーバー上のDOMツリー。
  • Q:nodeで開発をしてるエンジニア。よくあるパターンは?
  • A:by TJ Holowaychuk
    • たいていのエンジニアはjsに不案内。そのくせjsを再検討するための時間を取ろうとしない人が多い
    • jsを生成してくれる言語がたくさんある
    • jsはユニークな立場に置かれた言語。誰もが使わないといけないから
    • jsを学ぶ時間を取らずにこの手のjsへコンパイルされる言語へ飛びつくことは間違いの元だと思う
    • 同じパターンはnodeモジュール利用でも見かける
      • 学びたがらないエンジニアはいきなりconnectやexpressに飛びつく
      • ベーシックなnodeのhttpサーバーを試すとかしない
    • 全体としては、nodeがどういう段階にあるプロジェクトなのかは多く人が正しく理解してる
      • nodeのフレームワークのほとんどは他と比べる低レベル
      • いろんなことを勉強しながら使うことが必須
      • http、tcp、webサプリ全般。
      • こうした低レベルなトピックはRailsDrupalのような巨大なフレームワーク使うときは考えずに済む
    • クライアントサイドjsでも同じパターンが発生してる
      • たくさんのjqueryユーザ
      • DOMの理解をする手間を惜しむjqueryユーザの大群
    • こういうありがちなパターンが問題だと断言するつもりはない
      • だた、低レベルなトピックを楽しんで学んでいるというconnect/expressユーザだっている。
      • そういう感想に読んだ
  • A:by Mike Cantelon
    • 低レベルなトピックは習得にそれなりの時間がかかる
    • 過去何年も経験した他の言語での開発経験と比べると、nodeでの開発は学習しやすいと思う
    • nodeコミュニティからリリースされるモジュールはクリーンなものが多い
    • nodeには優れたパッケージ管理ツールがある
  • Q:nodeエンジニアにオススメのライブラリ、お気に入りのライブラリ
  • A:TJ Holowaychuk
    • node_redis
      • Redisクライアント
      • by Matt Ranney
      • 効率的でエレガントなモジュールデザイン
      • MattがCTOやってるVoxeriPhoneアプリで使われてる
      • プロダクション環境で利用・テストされてるモジュール
    • Socket.IO
      • 定番。知ってる人も多いはず。もし知らないなら必見。
      • クライアントサイドへのストリーミング機能の実装は超面倒
        • これを統一的、エレガント、高パフォーマンスに実装できるライブラリ
    • node-formidable
      • Felix Geisendörfeが開発
      • たくさんのユーザがマルチパートパーサーとして使ってる
      • FelixがやってるスタートアップTransloaditで利用・テストされてる
      • GB単位のデータアップロードで威力発揮する
    • node-http-proxy
      • nodejitsuが開発
      • 高性能で手軽に使える
      • リバースプロキシーとして超簡単にかんたん
      • nginxやHAproxyと比べるとセットアップの手間いらずなところに驚くはず
      • バーチャルホスト(vhosts)やおよそプロキシに求められてる機能のセットアップは一瞬で、jsでできる
  • A:by Mike Cantelon
    • すぐれたツールがたくさんある
    • express
      • webアプリ全般のバックボーンとして使える優れたモジュール
    • Connect
      • webアプリの低レベル機能が手軽に使えるようにしてくれるライブラリ
    • node_redis
      • TJの言った通り、Redisへのアクセスが手軽にできる
    • mongoose
      • MongoDBのデータへの高レベルインターフェースを提供。これもお気に入り
  • Q: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のおかげでコマンドラインインターフェース向けツール作るのが楽しくなった
  • Q:他の言語(javaとか)と比べたときのjsのツール群への満足度。常用ツールは?
  • A:TJ Holowaychuk
    • yesかつno
    • 他の言語の方がいい部分もあるし、nodeに軍配上がる部分もある
    • いちコントリビュータとしてはjs/nodeの世界にはキツイ部分あり
      • 「jsを生成する/jsへコンパイルされる」言語/DSLが使われてる現状
      • 「@」とか「#」とか「$」に出会った数だけ痛みが。。
      • しかもこの手の言語/DSLとnodeのモジュール。2つ統合して欲しいなどと期待される。これもキツイ
      • js/nodeにはこの手の言語/DSLがたくさんある
      • jsの文法に文句を言う代わりに、もっとjsがサポートする機能や特徴を学ぶ時間を取ればいいのに、と思う
      • タイピングがネックなんだったら間違ったやり方をしてるだけのこと
    • nodeには優れたパッケージ管理ツールがある。
      • npm。他の言語と比べてもベスト。
      • npmが特別優れてる訳
        • 多くのレガシーな機能をサポートする必要がない
        • グローバル/ローカルインストールは、作法としてすでに定着した
        • 初期npmにはなかった作法
        • この作法に従う/従わないは自由に選べる
    • パッケージ管理ツールによくある「今後このやり方でやりなさい」的な部分
      • npmにはこういうところがない
      • npmはnodeエコシステムを支えるソリッドな基礎となってる
  • Q:nodeの今後の進化について予想。nodeの今後に期待してることある?(新機能、安定性、パフォーマンス向上、etc..)
  • A:TJ Holowaychuk
    • nodeに限らず、nodeには安定してほしい
    • 今すぐに安定、迅速に安定してほしいとは思わない
    • 誰もがフレームワークに安定性を期待してる
    • 他方、nodeはレガシーなAPIのことをそんなに気にするべきじゃない
    • nodeに変化が必要なら、完全なソフトウェアを求めて変化し続けるべき
    • stream APIはもっと使いやすくできると思う
      • コンセプト自体はstream APIはシンプルで優れてる
      • 入り組んだシステムが絡んでくるとstreamのように振る舞い・操作できるオブジェクトを作るのがとても難しい
    • stream用のfilter APIについては前々から議論されてる
    • ファイル読み取り、データをパイプしていて出力する途中に、gzipフィルターを入れる、とか