2013年2月23日に東京・品川でRuby20周年記念パーティーが開催されました。Rubyアソシエーションと日本Rubyの会が合同で企画したものです。祝辞（というよりも、むしろ講演）が7本ほど続き、会場はずっと拍手と笑いに包まれ、和やかなムードでした。

　私は、Rubyの生みの親、まつもとゆきひろ氏のインタビュワーを務めさせて頂きましたので動画を公開します。

　インタビューは20分の予定でしたが、会場からたくさん質問が出て盛り上がったので延長していたようです。動画は38分ほどあります。

　以下、いくつかまつもと氏の発言を箇条書きでご紹介します。

• 20年前のRuby登場時、「ふつうのプログラマはオブジェクト指向は知らなかった。縁のないものだったと思う」。C++でCADを作るような人とか、アカデミックな世界以外ではオブジェクト指向は普及していなかった。
• Rubyの仕様について検討する「Rubyコミッティー」を作れという提案に対して。「未来をどうするかという話をコミッティーでやってうまく行ったことなんてないので、ちょっとは学習しろよと思います（笑）」
• 2004年に登場したRuby on Railsも、たくさん出てきたWebアプリケーションフレームワークの中の1つで、広く普及するとは正直予想が付かなかった。
• RubyはWeb言語と言われる／見られることもありますが？ 「そんなことを言う人はRubyに関心がないので、いいんですよ。Web言語じゃないと気が付かない人は別にいいんです」。
• CとRubyは9対1の割合でプログラミングしている。Rubyのほうが楽しい。ただ、「プログラマは怠惰なので、手を抜くためには努力を惜しまない。1の部分で気分良く書くために、私はCでゴソゴソ書いている」。
• いまから20年後のご自身の姿は？ 「私の生涯のテーマは、いまと同じ状態をずっと続けること。20年後も現役プログラマでいたいなと思います」。
• いま全力で潰しておかないといけない言語は？ 「Luaとは戦っているかもしれませんけど、私はあまりに言語ラブなので、（言語を）潰すというのは考えづらい」。
• （上記の発言の直後に）「人類のためにJavaScriptは何とかしたほうがいい」
• RubyはWeb分野は制覇した。mrubyで組み込み制覇できる？ 「いや、わかんないですよね、そんなの（笑） ただ、その目的で使いたいときに、そのテクノロジーがあるかどうかは大切。Rubyが使いたいというとき、ふつうの人はRuby作らないですよね。そこに選択肢を提供できればとは思います」
• 国産言語、日本発のプログラミング言語と言われることに違和感は？ 「方便で、日本産と言ったほうがウケがいいときには「日本産だ」と、しれっと言うんですけどね。特にスーツを着た人の前だと、日本から来たんですよーみたいなことをいうと嬉しそうな顔をされるので（笑）。ただ、プログラマとしての私のアイデンティティは、Unixプログラマとか言語好き。その辺でアイデンティファイされたい。そういう側面でいうと、私はたまたま日本に生まれてたまたま日本語が得意なだけ。所属はプログラマ、国籍はプログラマという意識のほうが強い」

　日本時間だと2013年2月7日未明のことですが、「Topaz」（トパーズ）と名付けられたPythonで実装されたRubyのバージョン0.1がリリースされました（リリースに関するブログ、プロジェクトのページ、GitHubのリポジトリ）。Ruby処理系はC、Java（JVM）、Ruby、CLI、JavaScript、Smalltalkなどによる実装がありましたが、Pythonというのは、ちょっと驚きです。ただ、Pythonといっても、Python言語で書くのが主眼なのではなく、Pythonエコシステムで高速処理を目指して作られた「PyPy（パイパイ）」の成果物の上に実装したというのがTopazのようです。現在のところコード作者リストに9人の名前が上がっていて、JRuby実装で知られるチャールズ・ナッター氏の名前も入っています。

　Topazは正確にはPythonではなく、RPythonと呼ばれるPythonのサブセットの言語で書かれています。RPythonは2.7.3互換をなるべく保ちつつ、速度向上を目指した仕様・実装のようです。RPythonとPythonの互換性のページによれば、Django、Flask、SQLAlchemyなども動くようで、サブセットといっても互換性は高そうです。

　【追記1】ライブラリの互換性が高いのはRPythonのほうではなくPyPyのほうでした。訂正してお詫びします。

　【追記2】なぜPyPyが速いのか、ということについては、Ryotaro Ikeda氏の「流行りのJITコンパイラは嫌いですか?」という文書がコンパクトで参考になります。@objectxplosiveさん、情報ありがとうございます！

　RPythonのRはRestricted（制約ありの）の意味で、Pythonを型推論による静的型付け言語のように扱うために作られたようです。RPythonで書かれたコードはCやJVM上のバイトコード、CILなどに変換でき、かつJITが効くので、RPythonは多くの場合、CPythonよりも高速だということです。以下、PyPyのマイクロベンチマークの表を1つ引用します。平均して5.6倍とあります。

　つまり、RPythonを使って実装したTopazというRuby処理系もCRubyよりも速くなる可能性があるということかと思います。すでにあちこちで「全く科学的とは言いがたい」という前置き付きのベンチマークの結果をブログなどに貼る人が現れています。例えば、havenwoodさんのGistにある、差が6となる素数ペアをリストアップする（割とRubyっぽい？）コードの例だと、以下のような結果のようです。

• Topaz-dev: 9.65秒
• Ruby-1.9.3: 44.81秒
• Ruby-2.0.0: 44.09秒
• JRuby-1.7.2: 42.14秒
• Rubinius-2.0.0: 82秒
• MacRuby-0.1.3: 36.29秒

　速度面では、だいぶ期待できそうです。

　ただ、TopazはRuby 1.9.3互換ということですが、今のところ、ライブラリの大部分、標準メソッドの多くが未実装であるほか、スレッドやファイバ、call/ccは未サポート、メソッドの可視性制御も未サポートなど本当に始まったばかりのプロジェクトです（それでもリリース前に10カ月ほど取り組んでいたということですが）。

　RubyとPythonは似たところの多い言語ですが、エコシステムはかなり違っています。特に自然言語処理や統計処理、機械学習など研究者方面ではPythonの利用が多く、ライブラリも充実しています。普及タイミングの問題もあったのかもしれませんが、この違いはかつてのRubyとPythonの処理速度の差から来ていた面もあるのではないでしょうか。RubyはWeb系では活発で大きなエコシステムを持っていますが、こうしたPythonの多様さには一歩及んでいないというのが私の印象です。

　Topazのような「（制約付きながらも）速いRubyを目指す」プロジェクトが出てきたことで、これまでRuby界隈ではあまり見かけなかったようなライブラリや、既存ライブラリの移植が見られるようになるなら、これはRubyistや、「研究でもRubyが使いたいなぁ」と思っているような人にとっては朗報になるのではないかと想像しています。

　Ruby on RailsのメジャーバージョンアップとなるRails4のリリースが近づいて来ました。先日、日本人（あるいはアジア人）として初めてRailsコアチームのコミッタとして迎え入れられた松田明氏によると、Railsの生みの親であるDavid Heinemeier Hansson氏（以下、通称のDHHを使います）は、プロジェクトをリードするという意味で活動が活発になっているそうです。

　そして最近のDHHは、ブログもよく書いています。彼は歯に衣着せぬ発言でも知られています。強い主張を持った（opinionated）なフレームワークの作者らしく、DHH自身もきわめてハッキリと物を言います。攻撃的とまでは言いませんが、IT業界や技術動向などでは割と何かをクソミソにけなしたりということをします。

　DHHが何かをけなすときは、だいたい何らかの鋭い洞察とパンチの効いた皮肉が含まれていて、Twitter上のつぶやきや、ブログは読んでいて非常に面白いです。たとえ話も上手で、印象に残ることが少なくありません。

　そんなDHHのブログを読んでいて最近なるほどなと思ったのが、

プログラミング地獄への道は、時期尚早に適用された“ベストプラクティス”で敷き詰められている――DHH

という言葉です（Winning is the worst thing that can happen in Vegasというブログエントリに出てきます）。

　これは「地獄への道は善意で敷き詰められている」という有名な言葉をもじったものです。この言葉、私はマルクスがオリジナルかと思っていましたが、どうも違うようですね。ともあれ、この言葉の意味するところは、善意から出てきた社会運動や政策提言でも、社会や人類に多大な害悪をもたらす結果になることがあるということです。社会主義は、人間が人間を搾取しない平等を目指すとした「善意」から起こった思想でしたが、結果として著しい停滞や貧困、独裁による地獄が現前したことは歴史に見るとおりです。しかし、それは元々は高邁な理想や人々の善意から起こった政治運動であり社会実験だったわけです。「地獄への道は善意で敷き詰められている」という言葉は、「善意ほど恐ろしいものはない、心せよ」という警句として読めます。

ラスベガスで起こり得る最悪のこと

　さて、DHHの言葉ですが、ブログエントリのタイトルは「Winning is the worst thing that can happen in Vegas」（ラスベガスで起こり得る最悪のこと）となっています。要点は以下の通りです。

　ラスベガスのカジノでは、割と早い段階で客に勝たせるようにできている。しかし、長い目で見れば、ちゃんとカジノ側がその分も含めて全てを取り戻すようになっている。

　ちょっとした勝利の高揚感がギャンブルに対して人を盲目にさせるのです。同様に、「すばらしいアーキテクチャで抽象化できた」という小さな勝利の高揚感によって、プログラマは「早すぎる抽象化」の罠に陥ることがあるというのがDHHの主張です。

　未来コーディングはカジノのルーレットで賭けをするのに非常に似ているとDHHは言います。未来コーディングというのはDHHの造語だと思いますが、将来に必要となることを考えながら設計やプログラミングをすることですね。将来こういう機能が必要だろうとか、こういう風に抽象化しておけば、プログラムの柔軟性が高くなって将来に変更が必要になっても対処できるというような「先を見越したプログラミング」です。これをやり過ぎるなというのがDHHの言っていることだと思います。YAGNI（You ain’t gonna need it. そんなもん必要にならねぇよ）という言葉もプログラマーの間では良く知られていると思いますが、「将来必要になりそうだから」と思って実装する機能は実際には不要なことが多いので実装のシンプルさを優先させるのが吉、ということですね。

柔軟性という名の技術的負債

　技術的負債というのは、整理がつかないまま汚いと知りつつしてしまったコミットや、クイックハックのことばかりではない。もっと潜在的に蓄積してくるのが「柔軟性」という名の負債だ、とDHHは喝破します。

　未来コーディングはルーレットで賭けるのに似て、当たるも八卦当たらぬも八卦。このため、「こういう感じのやつが、もっと増えたときのため」と思って行う、「早すぎる抽象化」「早すぎる抽出」（premature abstraction and extraction）というのは、全て少しずつ蓄積していって、技術的負債となるのだといいます。1970年台に「早すぎる最適化は諸悪の根源だ」と言ったドナルド・クヌース博士の警句に通じる話ですね。

　抽象化や抽出（メソッドやクラスを独立させるようなことでしょうか）、あるいはアーキテクチャー（デザインパターンのようなものでしょうか）といったもので、存在自体がイケてないものというのはほとんどない。「善意」と同じで、「ベストプラクティス」に、それそのものが悪いものというのはない。ただ、必要性がないのに適用されたベストプラクティスは、ほとんどすべて悪である――。これがDHHの指摘です。何の問題もないコードなのに、いきなり「ナントカファクトリー」という名前のクラスを足すとか、基底クラスを継承しているクラスが1個しかないという話でしょうか。DHHは、使わない引数を実装したメソッドや、どこからも呼ばれないパブリックメソッドに対しても「ノー」と言います。

　「設計の世界において最も難しく、そして最も重要なことは、“ノー”と言える信念だ」（DHH）

と、ブログを締めくくっています。

　先を見越した設計、行き当たりばったりでない設計の大切さは言うまでもないのでしょうけど、それがアダとなり得るというDHHの言葉は含蓄があるように思いました。

　2012年12月13日、HerokuがJRubyを公式サポート言語に加えたと発表しました。公式サポート言語、フレームワークは、

• Ruby
• JRuby
• Node.js
• Clojure
• Python
• Java
• Gradle
• Grails
• Scala
• Play

ということになりました。すでにScalaやClojureといったJVM言語をサポートしていたので、意外に対応が遅かったような印象もあります。RubyコミュニティがC実装のRubyとUnixのプロセス並列によるスケーリングを好む傾向にあって、JRubyがRuby側からはさほど普及していないことが理由として挙げられるかもしれません。

　Herokuは2011年8月にJava対応を開始していて、すでにJRubyを動かすこと自体はできました。今回は公式サポート開始ということで、特別な設定をすることなく利用可能となったということです。

　既存のCRubyをターゲットとしたRailsアプリをJRubyでHerokuにデプロイする方法は、「Moving an Existing Rails App to run on JRuby」というドキュメントに書かれていますが、

• ローカルにJRubyをインストールしてRailsアプリの動作を確認
• JRuby非対応のgemがあったら何とかする
• Gemfileにjrubyを使うむね、宣言を書く
• pumaなどJRuby対応のWebサーバを使うよう変更する
• Procfileの起動コマンドを書き換える
• PostgreSQLのドライバを pg から JDBC対応の activerecord-jdbcpostgresql-adapterに変える

というような流れのようです。

　ちなみに、サードパーティー製のHeroku向け言語サポートが「ビルドパック」という仕組みで存在しています（リンク）。言語によらず、gitでコードをpushするとHeroku側でslugというバイナリにコンパイルされますが、ビルドパックというのは、このコンパイル手順を書いたスクリプトです。標準サポートのRubyやNode.jsも同様の仕組みを利用しているそうです。サードパーティ製のビルドパックには、DartやGo、Erlang、Perl、Lua、Meteorといった比較的メジャーなものから、EmacsLispやPhantomJS、R、Elixirといったエキゾチック（？）なものまであります。EmacsLispでWebアプリが作れるんですね……。EmacsLispで書かれたNode.jsのような非同期Webサーバ「Enlode」を使うそうです。

　ともあれ、JRubyを使うメリットは、Javaのライブラリが使えることと、CRubyのようにGIL（Global Interpreter Lock）が存在せず、スレッドを使った並列化で高速化がやりやすいことでしょうか。公式サポートとなったことで、JRubyの利用が増えるかもしれませんね。

　「でも、ステージング環境ではちゃんと動いています！」

　こう言われてブチ切れた経験があります。業務アプリのバギーな動作を社内のエンジニアに指摘したところ、テスト用の環境では動いているというのです。「いや、ぼくら本番環境のアプリを使っていて現に困っているので、それを直してほしいだけなんですけど」というと、「でも、ちゃんとステージング環境では動いています。お使いになっているのがChromeのようですが、Chromeでの動作検証はしていません（キリッ」というようなやり取りに絶望しました。原因はブラウザではなく、バージョンアップしたアプリ自体にあったのですが、ステージング環境では問題が発現しなかったんですね。

　というように、開発環境、ステージング環境、プロダクション環境（本番環境）の3つは、大小いろいろな違いがあって、完全に一致させることは難しいものです。手元の環境で動いているアプリが、プロダクション環境にデプロイしたらなぜか動かない、というような経験はアプリ開発者ならお持ちだったりするのではないでしょうか。

　「手元と本番でDBのバージョンが違ってて、マイナーバージョンの違いだから大丈夫だろうと思ったら挙動がビミョーに違ったし！ うぎゃー」とか、「本番のデータだと負荷が高まったときに、このパッチでタイムアウトの例外が多発するようになっていた！ ウキーッ」とか、「Rubyを最新のパッチレベルにしたら、実はマーシャリングのフォーマットが変更になっていて、DBをダンプしてリモート環境にロードするgemが動かなくなっていたよ！ むぎゅぅ」とか、「サードパーティ製のJavaScriptがなぜかHTMLの最後にスペースを勝手に入れてくれていて、おかげでフッターのレイアウト崩れてたし！ そんな忍びの術みたいなもん気付かんし！」とか、「手元では昔設定した環境変数を参照してたまたま言語設定がうまく動いているだけだった…… 本番は文字が化け化け！ ていうか、DBのマイグレーション失敗だし、オレもう終電逃し確定だし！」とか、「動かねぇ……。うごご、本番環境はLinuxなのに、MacのUnixコマンドの出力前提に初期化スクリプト書いたの誰だよ！ リバート、プリーズ！」とか、「ローカルのWebサーバはオッケーでも、サーバ上のNginxではリバースプロキシがRailsのBasic認証と相性が悪かった！ サノバビッチ、スパシーバ！」

とか、そういうことです。

●12ファクターアップとは？

　こうした悲しい事態を避けるために必要となるのが、「開発・本番等価」という考え方です。できる限り、両者の環境を一致させろということです。

　「開発、ステージング、プロダクションをできる限り近づける」というのは、“12ファクター・アップ”が掲げるマントラの1つです。12ファクターアップというのは、ネット経由で配布・提供される現代のモダンなアプリ（ソフトウェア）が満たしているべき12個の原則を書きだした一種の宣言文のことです。12ファクターアップは、ちょうどアジャイル宣言のように、原則を並べた宣言文書なので、特定のプラットフォームや開発言語などを想定はしていません。ただ、この文書をまとめたのはHeroku創業者メンバーの1人、アダム・ウィギンズ氏で、Herokuプラットフォームの開発や、Herokuがホストする数多くのアプリケーションを観察していて到達した原則集ということですから、意地悪な見方をするとHerokuの宣伝文書、もしくは目標宣言のように読めなくもありません。例えば、アーキテクチャやツール、開発スタイルに大幅な変更を加えることなくスケールが可能なことというのは、HerokuのDynoを想起させます。スライダーバーをググっと上げれば、ハイ終わりという。実際、＠ITが提供・運営しているQ＆AサイトのQA＠ITはHerokuで動かしていますが、.初期に想定以上のトラフィックが来たために慌ててDynoの数を2つから5つに上げた、ということがあります。

　ともあれ、やや宣伝めいたところのある12ファクターアップの文書ですが、これをまとめた背景に明記されているように、12ファクターアップという文書は、モダンなアプリ開発に関わる課題を論じるための「共通語彙」、もしくは「方法論」を定義するものでもあります。そういう意味では議論のスタートとしても良いものではないかと思います。

●「開発・本番等価」というルール

　どうやって開発・プロダクション環境の等価性を高めるのでしょうか？

　例えば、Web系開発者の間で、開発用端末としてMacが人気なのは、デプロイ先がLinuxサーバであることが多く、同じPOSIXならミドルウェアや言語処理系、ツール類で、ほぼ同じ環境が再現できることが挙げられると思います。iOS開発がプラットフォームを選ぶ（Macのみ）一方、Androidは何でも良いということも影響しているかもしれません。また、Linuxサーバで作業することが増えた結果、viやcurl、tailなどのコマンドラインツールの価値が見直されているというトレンドもあるように個人的には感じています。だったらなぜRuby on Rails開発者はあまりUbuntuを使っていないんだというツッコミもあるかもしれませんが、それは「設定がしたいんじゃなくて開発がしたいから」というのが1つの答えだと思います。

　さて、このブログに本論に移る前に、12ファクターアップの12の原則を和訳しておきます。

1. コードベース：バージョン管理された単一のコードベース、多数のデプロイ
2. 依存管理：依存は明示的に宣言して分離する
3. 設定：設定は環境に保存する
4. 補助サービス：補助サービスはリソースとしてアプリに付随させる
5. ビルド、リリース、実行：ビルドと実行は完全に別ステップとして分離する
6. プロセス：アプリは１つ、もしくは複数のステートレスなプロセスとして実行する
7. ポートバインディング：ポートバインディングを通してサービスを露出する
8. 並行性：プロセスモデルを使ってスケールアウトする
9. 廃棄できること：速いスタートアップタイムと優雅なシャットダウンによって堅牢性を最大化
10. 開発・本番等価性：開発、ステージング、本番をできる限り近づける
11. ログ：ログはイベントストリームとして扱う
12. 管理プロセス：管理者・管理のタスクは、（起動して実行したら終了する）1回きりのプロセスとして走らせる

　Rails開発者なら、ああ、1はGitのmasterのことだな、2はGemfileだななどと思うかもしれませんが、ほかのフレームワークでも似たような仕組みがありますよね。6～8番あたりはUnicornを思わせますが、いやいやプロセスじゃなくてスレッドが答えだという人たちもいることでしょう。そういえば、大量のUnicornが走っている某社のRailsアプリでは、個々のUnicornの寿命が数分という話を聞いたことがあります。メモリリークがひどくて、少し動かすと反応しなくなるので、ガンガン殺してまたリスタートさせるという話です。これは6番の極端な例かもしれません。外部からそのアプリにアクセスして見ている分には、別に問題なく動いているように見えるということです（現場の人には当然それが良いという認識はなく、何とかしないと、という話でした）。

●Herokuが「データベースのフォーク」を実現

　さて、12ファクターアップという文書は洞察に富んでいるので、一読の価値はあると思うのですが、ここでは開発・本番等価性の話をしたいと思います。

　というのも、HerokuとEngine Yardが、前後して開発・本番等価性を高める新機能をリリースしたからです。それぞれに見ると、「へぇ、便利」という程度のことかもしれませんが、ともに12ファクターアップがうたうモダンな開発スタイルを前進させる「PaaS進化の最前線」だと思うからです。

　1つは、2012年11月8日にHerokuがリリースしたデータベースのフォーク機能です（Herokuの関連ブログ）。Herokuが指摘するとおり、GitとGitHubは「フォーク」（分岐）という、時としてネガティブなニュアンスさえあったアクションを、この上なくカジュアルに手軽にしてしまいました。Gitでブランチを切るのはSHA-1の生成と、その40バイトのデータのファイルへの書き込みだけなので動作としても一瞬です。分散レポジトリなので名前の衝突問題も小さく、ガンガン好きなだけブランチが作れます。GitHub以前は“フォーク”といえばコードの所有権やコミットの場（リポジトリ）、その主体がある日を境に分岐するという話でした。意見や目的意識の違いや、開発者間の仲違いによってフォークは起こりました。しかし、GitHubでは、フォークはもっと気軽なもので、別の意味も帯びています。とりあえず、自分のところへコードベースを持ってきて、そこで何か作業をして、その結果を元へ戻すというようなときにフォークしてしまいます。こうすることで、いきなり本家のレポジトリでブランチを切ったりすることなく自由に実験的な開発とコミットができるのです。これはGitがもともと持っているDVCの性質ですが、GitHubはボタン一発でフォークできる手軽さを実現したところがスゴイと思います。

　Herokuがリリースしたデータベースのフォーク機能も、GitHubのフォークに近いニュアンスです。HerokuはPostgreSQLをサービスとして提供していますが、本番環境のデータベースをボタンのワンクリックでフォークできるようになりました。例えば、本番環境のデータを、ステージングへとクローンすれば、「ステージング環境ではマイグレーションが通ったのに本番環境で失敗した」ということが減るはずです。負荷テストをするにしても、本番環境のデータをフォークして流用すれば精度が高いでしょう。ステージングのほうのデータベースは、検証が終われば破棄すればよく、使った分以上に課金されることもありません。クラウドっぽいですね。

　データベースのフォーク機能は、また一歩、12ファクターアップを体現した機能と言えると思います。GitHubのフォーク機能と同じで、「それ、これまでにもダンプしてロードすればできたやん」という議論があるかもしれません。でも、ちょっと違うと思うのですよね。ボタン一発（あるいはCUIのコマンド一発）でできる手軽さがいいのだと思います。

●Engine Yardは仮想環境向けの開発環境を提供

　さて、もう1つ。

　Herokuの競合であるEngine Yardは「Engine Yard Local」を2012年11月16日に無償でリリースしました。Engine YardはRailsやNode.jsの開発環境として、ミドルウェア、フレームワークを全て含む独自のスタックを提供していますが、これをローカルの仮想環境で動かすことができるそうです。仮想環境に開発環境をセットアップする「Vagrant」と、OSSの仮想化ソフトウェアの「VirtualBox」を組み合わせてEngine Yard Localは実現されています。Engine Yard Localを使うと、同社のクラウドインフラと同様のOS、Webサーバ、アプリケーションサーバ、ロードバランサなどが手元に再現されます。

　Vagrant（ベイグラント：意味は「放浪者、浮浪者」）の公式サイトに行くと、ズバリ「開発・本番等価」という言葉が書いてあり、12ファクターアップのサイトへのリンクが貼られています。いまや本番環境では、DBサーバだけでなく、0mqのようなメッセージングサービスが動いていたり、Redisのようなインメモリのキャッシュクラスタが動いていたりするわけですが、いくらMac OS Xが「POSIXだから、まあ動きますよ」と言っても、こうした個別のアプリ依存のソフトウェアをMacPortsやHomebrew、あるいは手動で手元のマシンにインストールして設定・管理するのがだんだんつらくなってきているように思います。特に複数アプリに関わっていて設定の切り替えが必要だと絶望的になるのではないでしょうか。

　最近のマシンは高速なので、開発環境は、それ専用の仮想環境に入れてしまえばいい、というのがVagrantの発想です。確かにスッキリ！ サーバ側と全く同じ環境を実現！ すばらしい！ もうMacPortsじゃなくて、apt-getでいいんや！ とも思えますが、もちろんマイナス面もあります。

　例えば、現実の開発者というのは、熱風を吹き出しうなり続けるMacBook Airをなだめすかしたり、ぐるぐる回る虹色バルーンを呆然と見つめながらメモリ2GBのマシンで開発していたりするわけです。そういう環境で「仮想環境にOSとミドルウェア一式をぶち込めば万事解決！」と言われても、そんな重たそうなもの……、何のために軽快な動的言語やviを使ってるのかワカランぞということになりかねません。なんだかんだ言ってPC上ではゲストOSは二級市民です。ゲストOSが動いていると、なぜかホストOSのレジュームが失敗して、延々と黒い画面を見つめて祈った経験があるという嫌な思い出がある人もいるかもしれません（私ですが）。

　Vagrantでは、IaaSにおけるChefのように、ローカルの仮想環境に対してChefやPuppetが使えるそうです。「ちょっと手元にHadoopクラスタを作って実験してみたい」というような用途でも使われているといいます。あるいは、チーム開発の場合でも新メンバーに対してMacBook Proを買い与えて「さあ、以下の手順に従ってRuby、Rails、Postgres、Redisあたりを入れてください。おっと、PostgreSQLは以下のエクステンションのビルドも忘れずに」とやるよりも、仮想環境にポコンとその開発環境を再現できるようにVagrantを使うほうが良いかもしれません。

　Engine Yard Localは、Virtual Boxを前提としたVagrantの設定レシピ＋CLIツールということですが、無償で利用できるので、これまで「Engine Yardのスタックって試してみたいけど、Herokuと違って無償で手軽にというのがないしなぁ」と思っていたRails開発者にとっては、試用してみるいい機会かもしれません。気に入らなくても、スッキリと跡形なく消せるのも仮想環境を使うメリットですよね。もしかすると、これからRuby on Railsの開発をやってみたいという開発者にとっても、「とりあえず全部入りのRails開発環境を作ってくれる選択肢」として、Engine Yard Localは使えるかもしれません。RubyもRailsも、バージョン管理ツール、ライブラリ管理ツールなどの周辺ツールの知識が結構必要で、とりあえずやってみたい人にとってそれがハードルになっているようなことがあると思うのですよね。

●継続的デリバリー実現のためにPaaSは進化中

　ずいぶん長々と書いてきましたが、HerokuもEngine Yardも、ともに「開発・本番等価」という課題に取り組んでいて、これは偶然の一致ではなくPaaS市場のトレンドと言えそうです。次のステップは開発環境がクラウドに移る（元々のHerokuの事業はそうでしたが）ということかもしれませんが、ネットワークのコネクティビティの問題が解決しない限りはそれはなさそうです。

　言うまでもないかもしれませんが、「何のために開発・本番等価を目指すのか？」ということですが、それはアジャイル宣言の背後にある原則の先頭に書いてあるとおり、「価値のあるソフトウェアを早く継続的に提供します」という“継続的デリバリー”の実現のためかと思います。

　2012年11月2日、Ruby 2.0.0-preview1のリリースがアナウンスされました。Ruby 2.0はRuby生誕20周年となる2013年の2月24日にリリースが予定されています。現在の安定版であるバージョン1.9系の次のメジャーバージョンアップとなります。ちなみに、1.9の正式版が初めてリリースされたのは2007年12月25日でした。

　Ruby 2.0のリリースマネージャ、遠藤侑介さんがメーリングリストに流したアナウンスによれば、2.0.0の主な新機能は以下の通り。

• Refinements
• キーワード引数
• Enumerator#lazy
• Module#prepend
• Hash への変換メソッド #to_h
• %i: シンボルの配列のリテラル
• 正規表現エンジンを Onigmo に変更
• DTrace サポート

　それぞれの機能について特に説明がなかったので、西村が分かる範囲で少し各機能について触れておきます。間違っていたらご指摘頂けると嬉しいです。

　Refinementsは既存クラスの挙動を変更したり、拡張するときの影響範囲を名前空間で限定する機能。Rubyはオープンクラスなので定義済みのクラスは、いつでも再オープンしてメソッドを追加・削除することができます。言語のコアライブラリの機能でも変更できて、Ruby on Railsのユーリティティライブラリ、ActiveSupportは割とやりたい放題というか、良い感じの拡張が入っています。例えば、ハッシュのmergeを逆方向にするとか、ディープにマージするというようなことはRuby言語の標準には入っていなくて、ActiveSupportに含まれます。こうした拡張機能は、Rubyコミュニティでゆるやかに共有されていて、小さなライブラリでもActiveSupportの一部を取ってきていたり、類似の拡張をすることがあります（多くの場合はlib/core_extとかlib/extといった辺りに入っていて、たいていはarray.rbとかhash.rbといったように標準クラスの挙動に手を入れています）。そうやって拡張したとき問題となるのが、名前の衝突です。名前が衝突するだけならまだしも、似たような挙動だったら嫌ですね。Refinementsは、オープンクラスの柔軟性と強力さを維持したまま、いわゆる“モンキーパッチ”の影響範囲を限定するために採用された機構です。

　キーワード引数は文字通り、メソッドの個々の引数に内容を示すキーワードを付与できる機能です。GitHubにミラーされているRubyのソースコードリポジトリのここにテストコードがあります。ちょっと抜き出すと：

def f1(str: "foo", num: 424242)
  [str, num]
end
 
f1                           # => "foo", 424242
f1(str: "bar")               # => "bar", 424242
f1(str: "bar", num: 111111)  # => "bar", 111111

という感じです。これまでRuby界隈ではハッシュのリテラルを引数の最後に渡すことで似たようなことはできていました。Rubyではメソッドの引数の最後では、ハッシュリテラルのブレースを省略でき、なおかつRuby 1.9からはハッシュはJSONぽく書けるので、以下のような記法が可能で、割と標準的な書き方でした。

def f1(value, options = {})
  if options.has_key?(:foo)
    foo = options[:foo]
  end
  # do something
end
 
f1(123, foo: "bar", bar: 111111)

　呼び出し側はいいですが、これだと呼ばれる側はoptionsのデフォルト値とマージしたり、個別に変数を取り出したりと面倒でした。キーワード引数が広まれば、こうした手間がなくなり、ずいぶん使いやすくなりそうです。

　Enumerator#lazyは遅延評価のための新しいAPIです。nagachikaさんのスライドを見ると分かりますが、mapやselect、zipなどコレクション全体を評価するようなメソッドの前に、(0..5).lazy.map などとして lazy を挟むことで遅延評価が可能になります。無限の要素を扱ったり、停止条件がいつ来るか個別にループしてみないと分からない（事前に調べるのが面倒）ようなケースでスッキリと書け、処理に必要なメモリ量も少なくて済みます。Rubyは1.8から1.9へのバージョンアップで、ずいぶん関数型の特徴を取り入れましたが、遅延評価が入ったことで、またそうした性質を強めているように感じられます。

　Module#prependは、既存クラスの挙動を変えるときに使えるようです。Railsの世界では長らく method_alias_chain を使って既存メソッドを呼ぶ前段階でゴニョゴニョっとやってからオリジナルのメソッドを呼ぶというようなことが行われていました。既存のライブラリに手を入れずに、ちょっとだけ動作を変更するということができます。Module#prependは、これをスッキリした形でRuby言語としてできるようにするもので、クラス（モジュール）の継承ツリーにモジュールを入れ込む仕組みです。Railsのソースコードの黒魔術感が減りそうな気がします。Module#include（ミックスイン）と似ていますが、この2つは継承ツリーの中でモジュールを差し込む場所が違っていますし、ミックスインは、どちらかと言えば多数のクラスに共通する挙動を引っ張り出してまとめておく仕組みとして使われています。

　シンボルの配列がリテラルに書けるようになりました（パッチ）。以下のような感じです。%w(apple banana) のような表記のシンボル版ですね。

%i[foo bar]  # => [:foo, :bar]

　ということで、Ruby 2.0の新機能のうち、いくつか紹介してみました。

【追記】アナウンスには含まれていませんが、Ruby 2.0ではVMの改善やFlonum採用によってパフォーマンスアップも図られているそうです（@unakさん、情報ありがとうございます！）。Flonumというのは、ここに議論がありますが、浮動小数点の埋め込み即値です。Rubyでは、これまでにも一定範囲に収まる整数（Fixnum）ではオブジェクトを生成せずに、ポインタにフラグを付けて値として扱う実装になっていましたが、64ビット環境では整数に加えて浮動小数点でも同じことを実現するようです。並の演算ならガッツリ速くなりそうですね！

　2012年9月に行われた札幌Ruby会議2012の基調講演の1つで、Rubyの生みの親のまつもとゆきひろさんが、最近あった面白いエピソードを混じえて“イノベーション”の本質について語っていました（44分の動画）。ポイントとなる部分をまとめてみました。まつもとさんの話はもちろん、統計的裏付けだとか学問的裏付けがある議論というものではありませんし、ご本人も楽しそうに話し、聴衆も楽しんでトークを聞くというゆるい感じのものでした。ただ、「イノベーションの本質は捉えがたい」というメッセージや、「だからあれこれ考えずにコードを書こう、われわれはコードを書くことにアイデンティティを感じているのだから、それこそがハッピーになる道だ」というメッセージは、参加していたRubyistたちの胸に響くものがあったのではないかと思います。

　以下、口語文体のまま、ポイントとなる前半のトークをまとめてみました。トーク後半では、多様性は善であるという話を引き継いで、JRubyやRubinius、MagLevを選ぶべき理由の話や、組み込み向けにmrubyを作っている理由などを話しています。そちらに興味がある人は是非オリジナルのトークをご覧ください。

●TwitterでPerl好きに絡まれた

　Rubyの開発を始めたのは1993年の2月です。Unixのスクリプト言語を目指しました。Unixのスクリプト言語が作りたかったというより、それが自分がいちばん使いそうなところだったからです。

　Perlの代替品というのを目指したのですが、ちょっとやり過ぎだったかな、と。（Perl由来の）ヘンな変数とか残ってますが、あれは失敗だった。でも、Perlの代替というのはRubyを作った本当の理由ではなくて、自分で作ったものが自分で使えるドッグ・フーディングが出来て楽しいというところで、実は代替しようとまでは思ってなかった。

　そう思って20年、（Rubyを）作ってきたんですね。

　で、最近Twitterで私に絡んできた人がいました。「Perlがあるのに、なんでRubyを作ったんだ」と言うんですね（笑）。PerlがあるのにRubyを作るなんて、重複だし、車輪の再発明だし、何より有限の労力の無駄遣いだというんですよ。だからRubyなんか存在しなかったほうが良かったのに、お前はなんてことをしてくれたんだ、と。多くのIT系の人たちはRubyのことをネガティブに思ってるよ、と胸を張って言われてですね……。

　……って、どう思いますか？ まあRubyカンファレンスでこれを言うって卑怯なんですけどね（笑） でも、かんべんしてよ、と思いましたね。

●リソースを集約できればコスト減、しかし失うモノは大きい

　確かに人類は70億人しかいないし、プログラマははるかに少ないんですね。プログラマの中で開発コミュニティに参加する、ライブラリを作る、CPANのモジュール登録者とか、となると、そういう人はさらに少ないんですね、確かに。で、当時、そうした人たちがみんなで協力して当時のPerlに対して努力する、集約ということを考えたら、“もしそれが可能だったら”、確かにそれはリソースを有効に活用したという話になりますよね。

　でもですよ、考えてみたら、われわれにとって最も大切なリソースはマンパワーではなくて、モチベーションだと思うんですね。

　モチベーションは誰かに制御されるようなものじゃない。世の中に新しいプログラミング言語を作ってみたいという人がいたとして、そういう人に「お前は新しいプログラミング言語を作るより、Rubyに貢献したほうが労力の無駄にならないよ」といって、プログラミング言語を作り出す夢を諦めさせたら、どうでしょう。それでリソースの無駄遣いは防げたかもしれないけど、われわれは大切なものを失っているのではないか、と思うわけですよ。

　われわれは機械ではないので、やりたいと思うときに、何かを達成できるんです。何かを達成するには、突き動かす内なる力が必要です。それはモチベーションによって現れるんですね。

　ある人はプログラミング言語に対して情熱を感じるかもしれないし、ある人はアプリに情熱を感じるかもしれない。ある人はスポーツかもしれません。何らかの情熱があって、それに突き動かされているときに偉大なことができるんじゃないかなという風に思うんですね。私の場合はプログラミング言語に対する愛です。世の中に存在するすべての言語を愛してるといっていいんですね。PHPも。

　モチベーションを笑ってはいけない。

　私は誰が何に情熱を持っても笑いません。まあ、「ちょっとそれは……」と言うことはあるかもしれないけど（笑） たとえそれが車輪の再発明であっても構わない。何でもやったほうがいいと思うんですね。それによって多様性が生まれます。私は多様性は良いものであると思っています。

●多様性はイノベーションに必要なコスト

　多様性にはコストがかかります。もしPerlしかなかったとしたら、Perlはより充実した言語になっていたかもしれません。そうやって理想の言語が作れるとしたら、そのときかかったコストは、Rubyのある世界より安かっただろうとは思います。でも、住みやすかったのか？ というと、そうではないのではないか、と思うんですね。

　何百、何千とあったはずの世に出なかったプログラミング言語、そうしたものは無駄だったのか？ それはイノベーションのコストではないか。

　この地上で、誰一人としてイノベーションのことを理解してないんですね。イノベーションを起こした人ですら、実は理解してない。

　よく私のところに来て、「なぜRubyは世界中で使われるようになったのですか」と聞く人がいるのですけど、内心は「分かりません」と答えたいんです。だけど、インタビュワーに嫌な顔をされるので、もっともらしいことを答えるんです（笑） 「コミュニティが～」とか適当なことをいろいろ言って。でも、分かりませんっていうのが正直な気持ち。分かりませんよ。

　再現性がないんですよ。イノベーションは再現できないんです。

　分かんないんだから、心配するのはやめて、コードを書いて幸せになろうと思うんですね。（日々コードを書くという）ミクロの世界で、“いま”充実して前に進んで行けばいい。中には成功するものもあるし、失敗するものもあるかもしれない。でも失敗しても「ぼくは幸せだったからいいや」と思えるんじゃないかと思うんですよ。楽しく野球をしている野球少年のところにいって、「きみはプロにはなれないよ」っていうのって、すごく暗い話じゃないですか。そういうことはしたくないですよね。日々楽しく野球すればいいじゃないですか。みんなにもハッピーになってほしいと思うんですね。

　（札幌Ruby会議2012のテーマである「We Code.」というメッセージにあるように）もし皆さんも、コードを書くということにアイデンティティを感じているなら、コードを書いているときが幸せですよね。アイデンティティのあるところに幸せがあるのですから。だから、つまんない議論とか、考察とか、調整とか、そういうめんどくさいことをやめて自由にコードを書きましょうよ。強制されずに、幸せに書きましょう。

　少し前の話ですが、Facebook CEOのマーク・ザッカーバーグ氏の発言が話題となりました。2012年9月11日に行われた米TechCrunchのイベントで同氏は、モバイル端末向けアプリを提供するプラットフォームとしてHTML5に賭けたのは同社始まって以来の戦略上最大の失敗だった、と発言したのです。

TechCrunch Disrupt SF 2012で話すマーク・ザッカーバーグ氏

ネイティブかHTML5かという対立軸

　モバイルアプリの世界では現在、「ネイティブアプリか、HTML5か」という構図で技術が語られることが少なくありません。実際、両者には一長一短があり、ケース・バイ・ケースで使い分けられています。機能面や応答性ではネイティブアプリが有利ですが、HTMLを取り巻く開発環境は急速に進化していて、中長期的にはHTML5の普及が進むと見るのが一般的です。それだけに、ザッカーバーグ氏の発言は一種の「揺り戻し」という風に捉えられたようです。

　ところが、実際に成功しているモバイルアプリの中には「第3のアプローチ」ともいうべきハイブリッド型も多数存在しています。

500万DL超のクックパッドアプリは第3のアプローチ

　レシピ共有サイトのクックパッドが提供するAndroid向けのモバイルアプリは、そうした第3のアプローチを採るアプリの1つです。配布パッケージとしてはネイティブアプリとして実装されていますが、アプリ本体ともいえるUIは、ほぼHTMLとCSS、JavaScriptでできています。

　クックパッドでは、JavaScriptから利用できるAndroidネイティブ機能のバインディングをAPIとして独自実装することで、HTMLでありながらネイティブアプリと遜色のない機能性を実現しています。重要なことは、そのことによってネイティブアプリでは得られない価値をユーザーに提供している、ということです。

　すでに500万ダウンロードを突破したクックパッドのモバイルアプリの実装と運用について、同社エンジニアでAndroid用の社内向けAPIを開発した濱崎健吾さんに話を聞く機会がありましたので、以下にまとめたいと思います（濱崎さんは10月5日にクックパッドを退職しています）。

WebViewを2つ使ってメニューとアプリ本体を実装

　クックパッドのAndroid向けアプリは、多くのユーザーにはネイティブアプリに感じられることでしょう。メニュー部分をネイティブ側でキャッシュするなどネイティブアプリに近いUIを実現しているからです。クックパッド社内ですら、それが本質的にHTMLアプリであると気付かなかった人もいたぐらいだと言います。AndroidアプリはGoogle Playで配布していますし、アプリとして起動し、終了ができる、ふつうのAndroidアプリです。

　ただ、その実装は少し変わっています。

　クックパッドのAndroidアプリは、左右2枚のWebViewから成り立っています。WebViewとは、プログラマがWebKitブラウザのレンダリング領域をアプリ内で利用するためのモジュール。カンタンに言えば、アプリにブラウザを埋め込むための仕組みです。AndroidではWebViewと呼び、iOSではUIWebViewと呼びますが、ほぼ同じ仕組みです。

クックパッドのAndroid向けアプリ。横位置で見ると、メニューと本体部分が表示されるが、この2つは別々のWebViewを埋め込んで実現している。HTMLアプリであるからこそ、新機能はリリースした瞬間にユーザーが使っている画面のメニューにすぐに現れるという

右上の音声検索など一部分だけがネイティブアプリとして実装されていて、コンテンツを表示している部分やボタン類の多くはHTMLアプリ

　ネイティブアプリ内でWebViewを使えば、そこにWebサイトを表示できます。ポコンとWebサイトをはめ込むようなイメージですね。例えば、Twitterアプリでツイートに含まれるリンクをクリックしたときに、URLをWebViewに渡すことで、そのTwitterアプリ内でWebページを表示させることができます。

　WebViewの本来の使い方は、アプリ内からWebページを参照のために開くというものです。しかし、一部のモバイルアプリは、この仕組みを推し進めて、アプリのいちばん外側の部分だけをネイティブアプリとして実装し、中身をHTML5アプリとして実装するというアプローチを取っています。

　つまり、モバイル端末向けのHTML5アプリと言った場合、

• 端末標準のブラウザでURLを入力して使うサービスとしてのHTML5アプリ
• WebViewを経由して配布されるHTML5アプリ

の2種類があるということです。後者のWebView利用によるHTML5アプリは、どこまでをネイティブで実装するのかという点と、ネイティブ機能のJavaScriptバインディングを利用するかどうかという点で、中間形態といえる“ハイブリッド型”が存在しています。

　単純にHTMLアプリとしたのでは実現できない機能があります。例えば画像を編集した上でアップロードする仕組みや、カメラ機能の利用などです。Androidの音声検索APIもそうですが、ネイティブアプリとして実装しないと呼び出せないAPIがあります。

　そこで、一部分だけをネイティブとして実装して、大部分をWebView上のHTMLアプリとするアプローチを取ればいいというわけです。クックパッドが提供しているAndroidアプリは、まさにこうしたアプローチを採用したハイブリッド型です。

　現在、HTML5ではデバイス系のAPIが次々と実装されていますが、それらの標準化や実装は、まだ開発現場で使えるほどこなれていません。そのためネイティブの機能やAPIを間接的に利用する方式が出てくるわけですが、このアプローチは、実はAndroid OSでは公式ドキュメントに実装方法まで書いてあるサポートされたアプローチだったりします。あまり気付かないだけで、かなり多くのAndroidアプリがハイブリッド型で提供されているそうです。

　ここには、あまり語られることのない、iOSとAndroidのプラットホームとしての思想の違いがクッキリ現れているように思います。

WebViewでアプリを作る方法に「抜け道」を用意

　Android OSでは、WebViewのドキュメントのBuilding Web Apps in WebViewにあるように、addJavascriptInterfaceというAPIを使って、任意のJavaオブジェクトをWebKit上のJavaScriptから呼ぶことができます。基本的にAndroidのネイティブコードでできることは何でもできるので、ここは注意して利用しないとセキュリティ上の問題になります。クックパッドアプリでは、ドメインなどの制限によって正式アプリ以外からのアクセスを排除しているという話です。

　クックパッドでは、AndroidアプリのためにAPI群を用意したそうです。例えば、OSネイティブのダイアログを開く、画像編集機能を呼び出す、OSネイティブのノーティフィケーション領域にメッセージを送るといったことが、サーバサイドのプログラミング（Ruby on Rails）だけで完結します。

APIの例。上はログインボタンを表示させるAPIをRailsのビューから呼び出す例

ネイティブ機能で実装した「つくれぽ」をRailsアプリのフォームのボタンから呼び出した例

　濱崎さんの設計・実装したAPIでは、例えばbuttonのclass属性にapp_login_form_buttonと書いておけば、ログインフォームが表示されるボタンを表示することができます。app_の接頭辞のあるclass属性名は、実行時にアプリ内でJavaScriptによって展開されて、Javaオブジェクトへのブリッジを呼び出すコードとなります。クックパッドはサービス開発にRuby on Railsを使っているので、このAPIはRailsのヘルパーから簡単に呼び出せます。例えば、「link_to “ログイン”, class: “app_login_form_button”」などと書けいておけば、ネイティブのログインダイアログを呼び出すボタンを設置できる、というわけです。

　以下、少し騒がしい環境ですが、濱崎さん自身によるデモの映像です（札幌Ruby会議2012の懇親会で撮影しました）。どういうAPIがあって、何ができるか分かると思います。

iOSよりもAndroidのほうが開発速度がはるかに速い

　クックパッドがAndroidアプリを最初にリリースしたのは2011年1月で、翌2012年4月にはハイブリッド版をリリースしています。ちなみに、Titanium Mobileを試験的に使ってみたこともあるそうですが、「Titaniumでは標準でパッケージに含まれるオブジェクトが大きすぎて効率が悪い」（濱崎さん）という問題があったそうです。Titaniumを使おうとしたのは、開発言語がJavaに制限されることでRailsエンジニアが手出しできなくなるのを防ぐためだったといいます。

　JavaによるネイティブアプリからWebViewへの切り替えに対しては、当初クックパッドの利用者からはネガティブな反応が少なからずあったそうです。やはり応答性ではネイティブアプリにかなわないわけですから、当然といえば当然でしょう。しかし、その後、HTML5アプリへのスイッチは想像以上の効果をもたらし、クックパッドのAndroidアプリは500万ダウンロードを超えるほどになりました。

　特定モバイルプラットフォームのための開発者を必要とせず、開発言語も1本化されるというのは、HTML5の分かりやすいメリットですが、濱崎さんによれば、この選択には、それ以上の意味があったようです。

　ネイティブ機能が含まれているとはいえ、クックパッドのAndroidアプリの本体は、事実上Webアプリです。この結果、「今はクックパッドのモバイル向けアプリは、iOSよりもAndroidのほうがはるかに開発速度が速い」（濱崎さん）という現象が起こっているそうです。ネイティブのモバイルアプリでは「ビルド→リリース→利用者側でのアップデート」という段階がありますし、iOSの場合、さらに審査のプロセスも入ります。この結果、新機能がユーザーの手に届くまでに時間がかかります。

　一方、Railsアプリのようにサーバで開発が完結するWebアプリなら、新機能をリリースしたら、それはその瞬間に利用者に届きます。新機能は、まずWebアプリとして実装されユーザーに届くわけです。そして、もしそれが良いものであれば、ネイティブのモバイルアプリのほうでも実装されるわけですが、Android版アプリは、もはやWebアプリに近い速さでアップデートが行える開発体制になっているということです。

細かなイテレーションこそがユーザーの利益になるという信念

　リリースサイクルを短くすることのメリットについて、クックパッドでディレクターを勤める五十嵐啓人氏は「第28回HTML5とか勉強会」で次のように説明しています（プレゼンテーション動画）。

　クックパッドでは、各機能ごとに、どの範囲の利用者にリリースするのかを管理する「Chanko」という内製ツールを利用しています。Chankoを使うと、自社開発者だけに限定して新機能をリリースするのか、利用者100人だけに限定して機能を試すのかといったことを機能ごとに制御できるそうです。特定の条件に当てはまるユーザーを数人（ときにはたった1人！）だけに絞り込み、その人たちだけに向けて新機能をリリースし、A/Bテストを繰り返し、最適なUI/UXを模索して改善するということをしているそうです。

　「ユーザーの反応や行動を見ながら、機能の追加や修正を速いサイクルで回すことができる」というのが、デスクトップアプリを含むネイティブアプリとWebアプリの大きな違いです。アプリが実際にどう使われているかが開発者に分かるというのは極めて大きな違いです。リーンスタートアップのような手法が確立して、普及してきていますが、その背景には、こうしたWebアプリの特徴があるのです。

　このサイクルがモバイルアプリでもそのまま成り立つのは、Webアプリとして実装した部分だけです。ネイティブアプリとしてリリースした場合、実際にユーザーがどの機能をどの程度使っているのかは分かりません。Webアプリの開発・運用で常識となった「仮説→計測→修正」というサイクルを素早く回すことができないのです。

　メリット・デメリットがあるネイティブ実装、Webアプリ実装ですが、クックパッドの場合、ハイブリッド型にしようと決断した背後にあるのは「細かなイテレーションこそがユーザーの利益になるという信念だった」（五十嵐氏）といいます。ネイティブ実装からハイブリッドへ移行したとき、できるだけ従来のUIを踏襲したものの、「重たい、使いづらくなったという言葉もあり、会社に行きたくなくなるぐらいお叱りの言葉も受けた」（五十嵐氏）といいます。そうした意見が来ることはあらかじめ予想できたそうですが、それでもなおハイブリッド移行を決断したのは、それが最終的にユーザーの利益になると信じたからだと言います。

　モバイル端末上のネイティブアプリというのは、ユーザーから見た使い勝手が良い反面、これまでWeb業界が培ってきた方法論が一気に通用しなくなるという点で、クックパッドのような企業にとって、失うものが小さくないわけです。ハイブリッド型とすることで「アクセス解析が可能で、ビジネス判断が早くできるようになった」（五十嵐氏）といい、ハイブリッド型に切り替えてUI改善を進めたことで、回遊率向上（関連するレシピを見たり、ほかのコンテンツをついでに見たりすること）や、課金コンバージョン率の向上につながったそうです。

ハイブリッド型移行によるメリット

　リリースサイクルの高速化以外にも、ハイブリッド型のメリットはあるようです。

　例えば、ネイティブアプリでは、新機能のリリース可否の判断がシビアで保守的になりがち、という違いがあるといいます。Chankoを使えば、特定の機能をオフにすることはサービス提供側で簡単にできますから、新機能提供に関してよりアグレッシブになれるというわけです。実際にユーザーが利用するサービスそのもの、いわゆるプロダクション環境で実験的なことができるというのは、ユーザー側の明示的バージョンアップが必要なネイティブアプリでは考えられない特徴です。

　また、ネイティブ実装に比べ、アプリのクラッシュが減って安定したという点も見逃せません。もっともこれは、アクティビティの数が単純に減ったためだそうですが。

　逆にWebアプリでは実現が不可能で、ハイブリッド型なら実装できることとして、五十嵐氏は、ちょっと意外なポイントを挙げています。

　例えば、ユーザーが料理のレシピを見ているときに、端末が省電力モードに入って画面が暗くなると困ります。クックパッドのユーザーは両手が小麦粉でいっぱいになっていて端末の画面に触りたくないようなことがあるからだそうです。これは純粋なWebアプリで制御できることではありませんが、ハイブリッド型なら可能です。アプリの右上にある音声検索ボタンの部分も、ネイティブ実装となっているそうです。

WebViewの扱いに見る、OSの思想の違い

　クックパッドではWebView利用のハイブリッド型への移行は成功だったということですし、良い妥協点に思えます。しかし、WebViewに対する見方は、プラットフォームや立場の異なる開発者の間で温度差があるようです。

　すでに書いたようにiOSとAndroidではWebViewを使ったアプリの扱いが違います。iOSではJavaScriptでネイティブ機能をブリッジする開発者向けの仕組み自体は用意されているものの、審査に通る見込みが低いことからクックパッドでは同様のアプローチによるiOS向けアプリのリリースには至ってないそうです。Windows 8では、アプリの大部分をWebViewを使って実現したものについてはストアの審査で落とされることになるようです。

　守る立場にしろ、追いかける立場にしろ、プラットフォームそのものがビジネスとなっているiOSやWindows 8では、ベストなUXを実現できるネイティブアプリをできるだけ多く作ってもらうのがマーケティング上重要なのでしょう。ここには開発者やアプリを囲い込む古いタイプのプラットフォーマーの発想があるように、私には思えます。「ネイティブアプリがほしい」という利用者の声を最大限に聞くのが「ネイティブアプリ以外は落とす」という論理になるので、表向きはユーザー体験を第一に考える正論です。しかし、ソフトウェアの開発プロセスや提供形態に疎い利用者の声を聞くことが、良いソフトウェアやサービスの提供につながると限りません。それはクックパッドの例からも明らかです。ここには「一見正論でユーザーのことを大切にしているように思われるプラットフォーマーたちの我田引水」というダブルスタンダードがあるのではないでしょうか。常にHTMLアプリが良いとは思いませんが、開発者に対して選択肢としてWebView活用の道を閉ざすのはやり過ぎだ、と思うのです。

　ソフトウェア開発のリソースは有限ですから、全てのプラットフォームでネイティブアプリを提供するというのは現実的ではありません。だからこそMacでもWindowsでもiPhoneでも使えるWebアプリが主流になってきたのですから、これと同じことがモバイル市場でも起こると考えるべきでしょう。今さら誰もデスクトップアプリ（Windowsネイティブ）の天気予報アプリやカレンダーアプリなんてインストールしませんよね？

　……、と思わず、私見を述べてしまいましたが、この辺は大いに議論の余地があるところでしょうし、開発者によって相当な温度差があります。濱崎さんも、Android開発者には、いわゆるWebサービス開発者とは違う畑の人が多いように感じてらっしゃるそうです。

　そうそう、AndroidのWebViewといえば、端末やバージョンごとの互換性に難があるわけですが、Android 4.1以降ではChromeが搭載されます。キャリアやメーカーがあれこれ手を入れた結果、プラットフォームとしては分裂気味になったWebKit[s]との格闘も、いずれ終わるかもしれませんね。濱崎さんによれば、例えば画像保存しようとAPIを叩くと、Androidでは端末によって違うフォルダが開いたりするということがあったそうです。Android 4.1時点では、WebViewとMobile Chromeは別実装として動いているといいますが、今後、レンダリングエンジンの違いによる互換性の違いは小さくなっていくのではないでしょうか。

　さて、西村の私見も交えながら、濱崎さんのAndroid向けブリッジAPIと、その実装であるクックパッドのAndroidアプリについて紹介しましたが、実は濱崎さんはクックパッドを10月5日に退職したそうです。濱崎さんの退職後もクックパッドでは引き続きAndroidアプリサービスの改善が続けられるそうですが、濱崎さんは今後、これまでに得た経験を生かして、OSSやWebサービスとしてWebアプリ専門の開発者に向けた還元を何か出来ないか、その上でそれがビジネスにならないかと考えている、とのことです。

　こんにちは、＠IT編集部の西村賢です。先日、札幌Ruby会議2012で、Ruby言語を使ってiPhone（iOS）アプリが開発できる「MobiRuby」を開発している増井雄一郎 (@masuidrive) さんにお話を聞くことができました。立ち話ですが、4分ほどの即席インタビュー動画をお届けします。

MobiRuby開発者の増井雄一郎さん

MobiRubyを使って開発したゲームの例

　動画の内容を簡単にまとめると、以下のとおり。

• MobiRubyはmruby環境でiPhone(iOS)アプリを開発できるSDK
• つまり、Rubyだけでアプリが書ける
• ネイティブ環境（Cocoa）のAPIが全て叩ける
• mrubyのVMをバンドルした形でアプリが配布される
• コンパイルしたアプリはAppStoreにも登録できる（すでに審査を通過したアプリもある）
• 現在はα版。来年のQ1にはプロダクションレベルに持って行きたい
• MITライセンスでオープンソースで進める
• マネタイズは全く考えていない
• RubyMotionとの違い
  • RubyMotionは有償の開発ツール
  • RubyMotionは完全にネイティブコードにコンパイルするので動作が速い
  • RubyMotionはRubyの動的な機能で使えないものがある
  • mrubyのほうはCRubyでできることは大体できる
  • mrubyはコアクラスについては含まれていないものもあるし、メソッドも少ないケースもある
• mrubyとCocoa環境のメモリ管理の整合性を取るのが現在の課題

MobiRubyアプリの概要

　mrubyというのは、Rubyの生みの親である まつもとゆきひろさんが開発中のRuby処理系の1実装です。フットプリントが小さく、処理系をアプリにリンクした形で利用することも想定されています。そういう意味ではMobiRubyはmrubyの正統な応用という感じです。mrubyの応用としては、ApacheのモジュールをRubyで書きたい、自動販売機の集計プログラムのようなものをRubyで書きたい、といったものがあるそうです。

　こんにちは、＠IT編集部の西村賢です。先日、弊社アイティメディアが主催するオンラインの総合ITイベントが開催されました。その1つのコンテンツとして、Twitter Japan ソフトウェアエンジニアの蓑輪太郎さんにインタビューする機会がありました。イベントの会期が終了しましたので、ここに、その時のインタビュー動画を公開します。

　箕輪さんといえば、id:higepon で知られるハッカーです。趣味でOSや言語処理系を実装したり、IPAの未踏ソフトウェア創造事業で天才プログラマーと認定される一方、はてなやサイボウズといった著名Web企業に勤めるなど転職歴も華やかです。そんな蓑輪さんは今、2012年初頭に転職したTwitter Japanで、本社エンジニアらと、グローバルなWeb企業でサービス開発の最前線に立っています。

　Twitterエンジニアの日常とはどんなものか？ 開発スタイルやツール、その開発プロセスとは？ また、どうやってエンジニアとしての腕磨きをしてスキルアップしていくのか？ オススメの勉強方法は？ そんなことをお聞きしました。何より私が驚いたのは、ツイートを蓄積してルーティングするようなバックエンドの部分は別として、フロントエンドが、意外なほど「ふつうのRailsアプリ」として実装されているというお話でした。

　以下が主な内容です。全部で1時間とちょっと長めなので、ぜひビールでも片手にご覧くださいませ！

• 蓑輪太郎さんの現在の仕事 00:00:00
• コードレビューにはReview Boardを利用 00:03:53
• 何億人に使われる機能変更の初仕事 00:04:58
• 自分のコードに対して残る不安 00:06:19
• Twitterエンジニアのローカル開発環境 00:09:41
• 意外に普通!? Ruby on Railsによる開発 00:11:58
• 蓑輪さんの典型的な1日 00:13:08
• ビッグデータもカジュアルに扱う 00:17:01
• Twitterが求めるのは「歌って踊れるエンジニア」 00:17:43
• システムをブラックボックスと見ないこと 00:20:24
• 「まだ自分ではハッカーだと思っていません」 00:24
• C言語のポインタで挫折した経験も 00:24:52
• 大学の研究室でJavaに熱中 00:27:36
• Twitterではテスト駆動開発してる!? 00:30:03
• 設計、実装ともエンジニアの裁量が大きい 00:31:41
• 知識ゼロからOS開発に挑戦！ 00:33:03
• OS開発を始めたのは危機感から 00:35:09
• はてなに転職したワケ 00:37:49
• はてなでプロダクトを企画してリリース 00:39:29
• 弱点克服のため言語処理系の開発にも挑戦 00:42:26
• IPAの未踏に採択：Schemeでシェルを作る 00:45:06
• 言語処理系的なシェルは普及しない？ 00:46:38
• 技術書を読む上で大切なこと 00:48:43
• 自分の時間を「天引き」して勉強しよう 00:53:10

　IaaSのクラウドサービスで国内で先行したニフティが、今度はPaaSのクラウドサービス「ニフティクラウド C4SA」（シーフォーエスエー）の正式サービス開始を発表しました。開始当初はRuby/PHP/Python/Perlなどをサポートしています。サイト自体はしばらく前から公開されていましたが、本日2012年7月31日に正式発表され、クローズドβから正式サービスとなりました。IIJのMogok、paperboy&co.のSqaleと国内で使えるRuby on Rails環境に、またひとつ選択肢が増えましたね。国内で正式サービスをうたって一般ユーザーに公開するのは、C4SAが一番乗りです。

※記事初出時、サービス名をC4SAとご紹介しましたが、正式には「ニフティクラウド C4SA」です。訂正してお詫びいたします。

キャンバスはアプリの開発・運用環境

　端的に言うと、C4SAはニフティクラウドというIaaS上に構築されたPaaS環境です。ただ、一般的なPaaSと異なるのは「開発」「運用」、そして開発チームの「コラボレーション」も、全てブラウザ上で完結しかねない勢いの新しい世代の「アプリ開発環境」を目指している、というところで、とても意欲的なサービスです。

　アプリの構築・運用環境は「キャンバス」という単位で管理されます。標準でメモリ512MB、ローカルディスクが1GB使えます。月額945円で、日割りで計算されます（現在キャンペーン中で9月末までは無料）。DBは共有のMySQLが用意されていて、今後は専用DBやPostgreSQL対応も検討中とか。ユーザーは好きなだけキャンバスを立ち上げられ、キャンバスごとに、言語処理系やフレームワークが選択できます。ちょうどAmazon EC2のAMIのように、プリセットされた「開発・運用環境」が用意されています。現在は言語として、Ruby/PHP/Python/Perlをサポート。フレームワークとしてはRuby on Rails、CakePHP、Djangoが使えます。サーバアプリがインストール済みの環境としてWordPress、PukiWiki、concrete5（CMS）、CandyCane（プロジェクト管理）などといったキャンバスもあり、手軽にアプリを立ち上げたいというニーズに対応します。

　キャンバスの環境は随時追加予定で、C4SAユーザーが作成した環境をサービスとして有償でほかのユーザーに提供するマーケットのようなものも考えているといいます。Node.jsやJava対応もリクエストに上がっているそうです。

　ニフティクラウドですからインフラはVMwareです。その上にかなり独自に手を入れたLinuxを載せて、個別環境をLinuxのユーザー名によるプロセス分離でキャンバスを実現しているそうです。アプローチが、ややAndroidっぽいですね。C4SAでは、これまた仕組みは良く分かりませんが、アプリや環境をリスタートすることなく、メモリやディスクが随時増やせるそうです。スケールアップですね。アプリを横に並べて展開するスケールアウトについても、８月中には対応予定だそうです。

開発もサーバ側の各種設定もCLIもブラウザで

　C4SAがユニークなのはブラウザ上に開発・運用に関わる全てを載せようとしていることです。ファイルブラウザで任意のファイルを編集できますし、nginxの設定ファイル編集も言語処理系のバージョン変更も、ブラウザで完結します。各種ログも見れますし、デーモンの再起動もブラウザ上のボタン一発です。

　Ruby on Railsでいえば、git、rake、bundleなどのコマンドは、ブラウザ上に専用のGUIが用意されているか、もしくはブラウザ上のターミナルエミュレータのようなCLIで利用可能です。このCLIはsshではなく、ホワイトリスト方式のコマンド仲介ターミナルといった風です。ちょっと使ってみた感じ、「git init」ができても、「git commit」などとすると、エディタが起動できずにターミナルの設定がおかしいと怒られたりしました。公言はしていないそうですが、「タブレットで開発できるようになるのが目標」（クラウド事業部クラウドビジネス部 五月女雄一氏）ということですから、今後に期待ですね。

　デプロイはGitなどのリポジトリからのチェックアウト、もしくはWebDAV経由で行えます。WebDAVはデザイナ向けの機能で、チーム開発を意識したものですね。キャンバスは複数ユーザーで共有できますが、コラボレーション機能として、今後はチャット機能やSkypeアドオンなどを検討しているそうです。GitのチェックアウトやWebDAVは手軽でいいですが、Capistranoのような自動化ツールが使えないのは、プロの開発者にはちょっと不便かもしれませんね。ただ、「ニフティのC4SA専用の知識がないと使えないという風にしたくない」（五月女氏）という話で、専用コマンドを用意するようなことは考えていないそうです。

　C4SAのターゲットとしては、

• アプリを勉強したいけれども環境構築の障壁を越えられない初心者プログラマやデザイナ
• アプリ開発に没頭したいサンデープログラマ
• 技術はあるが時間がないエンジニア。PHPエンジニアがRailsを使う、あるいはその逆で環境構築までやっていられない
• インフラや環境を意識することなくビジネスレイヤですぐに利用したいスタートアップ

というような層を狙っているということです。

　今後は、ニフティらしく顧客管理機能、課金・決済機能の提供も検討したいということでニフティクラウド同様に、国内でもビジネスでのPaaS活用が本格化するかもしれませんね。「IaaSほどは安くないですが、ビジネスユースでは使われている、本気で使えるPaaS、お金稼ぎしても大丈夫ですよ、ということを感じてもらえるようなサービスにしたい」（五月女氏）とのことです。

　SRS（Spaced Repetition System）と呼ばれる学習方法があります。復習する間隔を1日、2日、4日、1週間、2週間、1カ月と徐々に伸ばしていき、忘れたころに復習することで記憶の定着効率を高める方法です。

　SRSは外国語学習者の語彙習得などに威力を発揮します。実際、SRSを取り入れたソフトウェアやサービスは多くあります。ただ、自分が欲しいものがなかったので、「Reijiro」というWebアプリをRuby on Railsで作りました（GitHubのリポジトリ）。機能追加をしながら4カ月ほど使っています。個人的に作ったアプリですが、もしかすると英語など語学を勉強している他の人の役に立つかもしれないと思って公開してみることにしました。

　Reijiroでは辞書として主に「英辞郎」を使います。特徴は以下のとおりです。

• 182万エントリと、膨大な実例を収録する英辞郎を利用（CD-ROM、もしくはオンラインコンテンツの購入が必要です。英辞郎の辞書データの著作権はEDPに帰属します）
• 各単語・用例の復習間隔を自動管理。1日、2日、4日、1週間、2週間、1カ月……、と徐々に復習間隔を伸ばすことで、最小の学習時間で記憶を定着させるSRS（Spaced Repetition System）を採用
• アルクが独自に選定した基礎語彙1万2000語を、全12段階のレベル別に単語帳に順次登録可能（レベル別データはインストール時に英辞郎CD-ROMから抽出します）
• サーバにデプロイして空き時間にスマフォやタブレットで利用可能（CD-ROMを購入した本人以外に閲覧可能な状態とするのは著作権侵害になります。念のため）

なぜ作ったのか？

　英辞郎は大変に良い用例集ですが、株式会社アルクが提供するオンラインの「英辞郎 on the WEB」は使いづらいところがあります。有償のPro版も少し使ってみましたが、やっぱり私のニーズには合いません。私は、単語の意味を素早く知りたいとかメールを書くにあたって用例を調べたいのではなく、調べた用例を丸ごと覚えたいのですね。

　一度引いただけでは覚えられないので復習が必要です。英辞郎 on the WEB Proでも単語帳機能があるので、復習自体は可能です。でも、最小の労力（時間）で効率的に覚えたいんですね。そこでSRSです。

　当初はローカルのMac上でだけ動かすつもりで作り始めたのですが、VPSに置いてみると想像以上に便利でした。英語を聞いたり読んだりしているときには、Chromeの検索エンジンとして登録してあるReijiroで辞書を引くようになりました。Reijiroで引いておけば、その単語・熟語は自動でクリップされます。クリップされた単語は、1日後、2日後……、と提示されるので、通勤や移動の空き時間にスマフォで復習できるので、とても良い感じです。いま、スマフォ用にjQuery Mobileのビューを足そうかと考えています。

　英辞郎が良いのは用例が豊富なことです。単語を調べた時、関連する用例や文例を眺めて、声に出して読むことが重要だと思っています。多くの単語帳アプリは「英単語：訳語」というフラッシュカード形式で、訳語だけを提示します。しかし、これではその語が作るイメージが分かりませんし、他の語と形作るネットワークが見えてきません。用例や文例で覚えないと自分で使える語彙になるように思えません。

　ちなみに現在、私の英語の推定語彙数は1万2000～3000語程度だと思います。「読む・聞く」では、あまり困りません。でも、書いたり話したりすると、結構残念な英語になります。語彙力を増やしてどうにかなるものではないかもしれませんが、ともかく向こう3、4年ぐらいで8000〜1万語ぐらい上積みしたいと思っています。自分で言うのもなんですが、無理せず効率的に語彙学習を継続できるという意味で、Reijiroは、すごくいいですよ。

　詳しい説明は、「Reijiro」をどうぞ。

　ITエンジニア向けの質問・回答コミュニティ「QA@IT」で、「RSpec のテストがたくさんついたオープンソースの Rails3 アプリはあるでしょうか」という質問に対して回答したところ、少しはてブが付いたりしたようです。Railsに限らないかもしれませんが、ちょっとしたサンプルコードや簡易なアプリというのはたくさんあるのですが、そこそこの規模のアプリ、あるいは実運用されているアプリで参考にできるソースコードとなると、意外にパッと思い付かなかったりします。「Railsアプリなら、これを読め」というべきアプリのリストがあればいいのにと、よく思ったりしています。

　そんなわけで、いま読むべきだと私が勝手に考えてGitHubのウォッチリストに入れているRails3アプリを、10個ほどリストアップしてみたいと思います（全部で11個ですが）。ほかにオススメなどがあれば、ぜひコチラで情報をお寄せくださいませ。

Gitlab

https://github.com/gitlabhq/gitlabhq

　GitHubクローンの結構大きなプロジェクトです。RedisやGitoliteが必要なので、自分でインストールして動かすのはやや手間かもしれませんが、なんといってもGitHubクローンなので、GitHub利用者なら、app/models 以下を見ても、どのモデルが何をやってるのか分かりやすいです。

（※初出時、GitlabをGitHQと誤記していました。訂正してお詫びいたします）

Shapado

https://github.com/ricodigo/shapado

　StackOverflow.comのクローン実装です。MongoDB（Mongoid）を使っていたり、今どきのソーシャルっぽい機能があれこれ実装されていて、参考になるかもしれません。以前VPSで動かしてみたことがありますが、Mongoさえ入れれば動かすのは簡単でした。使っている Gem の一覧（Gemfile ）を見ると、割りと良く見かける「イケてるヤツ」が詰まっている感じで、それも参考になりそうです。

RefineryCMS

https://github.com/resolve/refinerycms

　名前はCMSですが、カスタマイズが前提で、CMS Frameworkと名乗っているプロジェクトです。テストコードはRSpecで書かれていますが、spec/ではなく、./*/spec に分散していたり、何かと素直なRailsアプリではないので、参考にするにはビミョウかもしれません。私はCMSとして注目しています。

Rubygems.org

https://github.com/rubygems/rubygems.org

　Rubyのライブラリである「gem」をホスティングしているRubygems.org　そのものです。Railsアプリとしては比較的シンプルに見えますが、Gemのホスティングの部分だけをSinatraで実装していたり、HTTPのリダイレクトのところをRackアプリのミドルウェアとして実装していたりして、アドバンストな構成のRubyアプリケーションというのが参考になります。

Rails3-Mongoid-Omniauth

https://github.com/RailsApps/rails3-mongoid-omniauth

　実用アプリではなくチュートリアルを目的として作られたアプリです。Userモデルしかありませんが、今やRailsアプリでデファクトスタンダードとなった認証ライブラリのOmniauthの使い方の実例を見るという意味で参考になります。

Spree

https://github.com/spree/spree/

　オープンソースのECサイト向けアプリです。かなり大きいRailsアプリですが、なんといっても、リアルに運用されている商用サイトが多いという意味で、これ以上の実用アプリはないかもしれません。サポートビジネスを展開しているだけあって、ドキュメントも充実しています。Spreeは海外サイトでしかメジャーでないと思っていましたが、国内にも採用事例はあるようです。メガネ・サングラス通販サイトのOh My Glassesは、Spreeを使って3カ月で構築されたサイトだそうです。9月に行われるSapporo Ruby Kaigi 2012で、開発をした白土慧氏が講演を予定しているようです。

Redmine

http://www.redmine.org/

　言わずと知れたバグトラッキングシステムです。CRubyの開発でも使われています。もしかすると、Ruby/Railsの外で最も知られたRailsアプリかもしれません。そのぐらい知られているアプリであるのに、生SQLを含む400行以上のメソッドがコントローラーに存在するプロジェクトだった時代があったそうですね。その混乱したコードベースをリファクタリングした体験をまとめたEric Davis氏の著書「Refactoring Redmine」を合わせて読むと勉強になります。Railsアプリに限らず、MVCはどうあるべきか、オブジェクト指向的にコードを整理するとはどういうことか、リファクタリングの定石にはどういうものがあるのか、という勉強になります。私は2年ほど前にこの本を読みましたが、いまこれを書きながら、もう1度眺め返してみようと思い始めています。

WhiteHall

https://github.com/alphagov/whitehall

　英国政府のポータルサイト「Gov.uk」は、なんと、オープンソースのRails3アプリで、GitHub上で活発に開発されています。実験的サイトとはいえ、すごいことです。人民の人民によるITシステムの所有、あるいはネット時代の参政権とは何かということを考えさせられます。というと大げさかもしれませんが、ソーシャルコーディング時代を感じさせます。ポータルサイトのような、かつてならテンプレート言語で対応していたものでも、今どきはアプリとして実装する時代なのだなということも思ったりします。手元で動作させるのはちょっと面倒そうですが、Gov.ukに行けば実物が見れるので、参考になります。ポータルサイトなので、そう複雑なことはなく、やっていることはユーザーやコメントの管理、イベント情報などの管理という感じです。コミットを見ていると、意外にダメなコードが入って誰かがそれを直したりしているような様子も伺えて興味深いです。

Typo

https://github.com/fdv/typo

　古くからあるブログアプリのようですが、Rails 3.2.6で動いているようです。APIとしてXML RPCのエンドポイントがあるなど、2004年頃を思い出します。実際イニシャルコミットを見ると、2005年1月20日となっています。さすがに歴史があるだけあってひと通りの機能が実装されているようです。ブログアプリといえば、Ruby on RailsのようなMVCフレームワークにとって「Hello world」のようなものですし、ブログの動作も良く知っているわけですから、そういう意味でTypoは読みやすいです。

Tracks

https://github.com/TracksApp/tracks/

　良く作りこまれたToDo (GTD) アプリです。GitHubクローンのように巨大ではなく、ほどよい規模です。Herokuで動作させることもできるようで、インストールして、コードを壊しながら遊んでみたいところです。開発も活発なようで、ドキュメントやフォーラムが妙に充実しています。実用アプリとして良くできていて、「開発者グループ＝ユーザーグループ」という古き良きオープンソースプロジェクトという印象を受けます。実は、これを書いている西村が、いま一番いじってみたいアプリです。コントローラーのアクションがいちいち長くて読むのが大変そうにも見えますが。

Fat Free CRM

https://github.com/fatfreecrm/fat_free_crm

　比較的クリーンでシンプルなCRMです。キャンペーンやリード管理といったCRMに必要な機能はひと通り揃っているようです。プロジェクトのゴールに「開発者が容易に拡張できるクリーンなコードベースを提供することで、CRMのイノベーションに拍車をかけること」とあります。その言葉どおり、コードが非常によく整備されている印象です。ライセンスにGPLではなく、AGPLを採用しているところにも志を感じます。開発スタートは2008年11月と、もう4年近く前ですが、現状ではCapybara、Travis、FactoryGirl、Pryと、最近のモダンなベストプラクティスを取り入れています。古いほうからコミット履歴を読んでみたい感じです。

　以上で11本です。まだほかにオススメがあれば、ぜひコチラで情報をお寄せくださいませ。

　Rubyを使ってiOS向けアプリが開発できる開発環境「RubyMotion」が登場しました。MacRubyプロジェクトの生みの親であるLaurent Sansonetti氏は7年間勤めたアップルを2011年暮れに退社して、新たにHipByteというスタートアップを立ち上げていたようです。

　FAQや動画ビデオを見て分かったRubyMotionの特徴を列挙します。

• Rubyを使ったiOSアプリの開発が可能
• ツールは有償で199ドル（現在キャンペーンで149.99ドル）
• 無償版やオープンソース版はない
• 作成したアプリはAppStoreでの流通が可能
• iOSのAPIの全てにアクセス可能
• C/C++/Objective-Cで書かれたRuby処理系のMacRubyベースで1.9対応
• Rubyコードをネイティブコードにコンパイル。AOTなどの最適化も
• 標準的なアプリなら1MB程度のサイズになり、元のRubyコードはアプリ本体に残らない
• リファレンスカウントによるGCを実装。メモリ管理が不要
• iOSのスレッドは「バーチャルマシンオブジェクト」と呼ぶものでラップされていて、並列実行も可能
• Grand Central Dispatchも利用可能
• サードパーティ製のObjective-CライブラリもCocoaPodsを使って利用可能
• ターミナルベースで開発。好きなテキストエディタが使える
• 「motion create Timer」などとすることでアプリのひな形が作れるのはRailsっぽい
• iOS向けに拡張されたRSpecによる単体テスト、統合テストが可能
• Rakeコマンドでアプリをビルドしたり、デバイスに転送したり、TestFlight（ベータユーザー向け配布プラットフォーム）での配布が可能
• REPL環境で動的にアプリに入っていってデバッグできる。例えば画面上のテキストラベルというオブジェクトがselfになる

　iPhoneシミュレータを立ちあげて、そこで実行しているアプリに「入っていって」、インタラクティブに環境とやり取りできるあたりが動的言語っぽくてステキです。

　もう1つ、Rubyっぽいところとしては、gemベースで機能を追加・拡張している点です。CoreData向けのDSLや、Objective-Cライブラリの依存管理ツールであるCocoaPodsをRubyMotionから利用するライブラリなどもgemとして提供しています。この辺、うまくRubyコミュニティを巻き込めれば、gemのエコシステムが出てきそうです。逆にCRubyを想定して作られているRubyのgemは動かないそうです。Pure Rubyのシンプルなものは動きそうなものですけど、どうでしょうね。

　エコシステムといえば、すでにCoCoaTouchのAPIをラップして、Ruby風のAPIにする「BubbleWrap」というようなライブラリもあるようです。使いやすいシンプルなAPIやDSLがどんどん進化してくるのがRuby文化だとすれば、こういう動きは期待できるのではないでしょうか。ArsTechnicaのインタビューでSansonetti氏も、画面設計を行うUIkitに対してDSLを使ったレイアウトシステムを薄いレイヤとして実装したと言いますが、こうした抽象化による開発生産性の向上こそRubyの真骨頂です。

　RubyMotionは、Rubyといわず、最近の軽量言語系のWeb開発者文化をiOSに持ち込んでいるように見えます。使い慣れたツールチェインが使えるというときに、テキストエディタとしてviを例に出していたりするわけですが、RubyMotionはXcodeに対してもちょっと否定的です。FAQには、アップル標準の開発環境「Xcode」は利用可能であるものの非サポートだとあります。それどころか、XcodeはRubyによる開発だけでなく、開発一般に適さないと考えているとまで書いています。

　すでに解説記事、動画、コードサンプルが大量にあって、とてもチェックしきれません。具体的な詳細は、以下が参考になりそうです。

• RubyMotionのオブジェクトモデルやObjective-Cのインターフェースなどを解説したドキュメント「RubyMotion Runtime Guide」
• RubyMotionで書かれたアプリのサンプルコード集のGitHubのレポジトリ

　Rubyの生みの親、まつもとゆきひろさんが、ついに新しいRuby実装である「mruby」のソースコードをGitHub上で公開しました！ 2012年4月20日です。ライセンスは、MITライセンスとなっています。

　以下にまつもとさんがmrubyについて語るインタビュー動画を貼り付けます。18分30秒のあたりからどうぞ。インタビューは昨秋の時点でのものです。

　公開されたmrubyのレポジトリから、Readmeの一部を引用します。

mrubyはISO規格に準拠したRuby言語を様々な環境で動作可能となるように軽量化したものです。モジュール構成によりインタプリタ実行形式やコンパイル＆VM実行形式でも動作させることができます。

2010年度の経済産業省の地域イノベーション創出事業により開発されました。

MRI(Matz Ruby Implementation)版との互換性

以下要修正
+ シンプルな文法
+ 普通のオブジェクト指向機能(クラス，メソッドコールなど)
+ 特殊なオブジェクト指向機能(Mixin, 特異メソッドなど)
+ 演算子オーバーロード
+ 例外処理機能
+ イテレータとクロージャ
+ ガーベージコレクタ
+ ダイナミックローディング (アーキテクチャによる)
+ 移植性が高い．多くのUnix-like/POSIX互換プラットフォーム上で
動くだけでなく，Windows， Mac OS X，BeOSなどの上でも動く
cf. http://redmine.ruby-lang.org/wiki/ruby-19/SupportedPlatformsJa

　要修正とありますが、イテレータやクロージャ、例外処理、GC、クラス、MixinなどRubyの基本機能は、すでに入っているようです。Cや、それに類する言語で開発するのと比べれば、ずいぶん生産性が上がりそうですよね。GCやVMは、本家Rubyが使っているものとは違うようで、GCは「Tri-color Incremental Garbage Collection」、VMはRiteVMという名称です。

　早速手元の32ビット環境のUbuntu上でコンパイルして動かしてみましたが、ごく簡単なコードはふつうにRubyっぽく動いているように見えます。拡張ライブラリのディレクトリは空っぽで本体のソースコードだけという感じです。テストコードも見当たりません（コード内にifdefでテストコードが存在していました）。コード行数はヘッダを含めても9万244行。コンパイル後のバイナリは1.6MBほどでした。最新版のRuby 2.0（開発版）は、エンコーディングや拡張ライブラリをのぞいても17万行程度あるので、やはりmrubyが小さいことが分かります。

　mrubyはフットプリントが小さいのが特徴でしょう。POSIXやそれに類するAPIを前提としたUnixサーバやPC向けに開発されたRubyとは違い、最初から搭載メモリなどでリソースに制約のある機器をターゲットとしています。デバイスへの組み込みや、モバイルアプリのSDKの一部として、あるいはゲームのスクリプティング用としての利用などが期待されます。デバイスというのは、スマートフォンはもちろん、組み込み市場が対象なので、クルマやテレビ、デジタル家電、ロボットというところでしょうか。福岡のまつもとさんの研究室（福岡県Ruby・コンテンツ産業振興センターにあります）にはロボットアームが置いてあったりして、「これ何のためにあるんですか？」とお聞きしたら「これをRubyで動かすんですよ」という答えで、私はかすかに驚いたりしました。

　現在、モバイル向けアプリのSDKという利用目的だとLuaやMono（.NETのOSS実装）が人気です。いずれもアプリ自体に処理系を付加してアプリと一緒に配布してしまえるのが特徴で、mrubyでも、すでに増井雄一郎氏による「MobiRuby」がアナウンスされています。

　Webアプリの世界では、Pythonにやや遅れてRailsとともに欧米へ普及したRubyですが、Pythonに拮抗するほど普及しました。一部のスタートアップ文化ではRubyが圧倒するとも言われていますが、それと似たようなことが、Lua vs. mrubyでも起こるのか、非常に興味があるところです。今後、成長が見込まれる市場ですし、日本の製造業と手を携えてmruby旋風が起こるといいですよね。

　Luaの成功は、程よい抽象度とポータビリティの高さにあったのでしょう。しかし、まつもとさんに言わせると、Luaは文法的にはイケてないということなので（例えばLuaではオブジェクト指向的な書き方ができるものの「内臓が見える感じ」（まつもと氏）という話です）、Rubyのときと同じように、もしRubyの使いやすさを開発者が認めるなら、今からでもmrubyの普及は大いにあり得るのではないでしょうか。

　もう1カ月前のことですが、2012年2月23日、24日と2日間にわたって福岡市・博多区を訪問し、「フクオカRubyフォーラム 2012」の第4回Ruby大賞の発表・授賞式を取材しました。24日には、パネルディスカッションが行われ、私（＠IT編集部の西村賢）はモデレーターを務めさせていただきました。パネルディスカッションには、

• Rubyの生みの親で、Herokuチーフアーキテクトのまつもとゆきひろ氏
• Ruby PaaSを提供する米Engine YardCEOのJohn Dillon氏
• 米VMwareで「Cloud Foundry」をピュアRubyで書いたDerek Collison氏
• Ruby PaaS「Mogok」を準備中のIIJの立久井正和氏

の4名が登壇しました。テーマは「Rubyとクラウド」でした。パネルディスカッションも含め、意見交換をしていて、改めてRubyについて気付くところがあったので、2つの論点で、まとめてみたいと思います。

論点1：クラウドとRubyの相性は良いか？

　まず1つ目の論点。「クラウドとRubyは相性が良いのか？」という点です。これはさらに2つの論点が含まれています。PaaSなどの上に載るWebアプリを書く言語としてのRubyという意味と、クラウド自体を動かすための言語という意味があります。

　クラウドといっても下はハードウェアに近いところから、上はWebアプリやPaaSまであるわけですが、上から下までRubyが活躍していると指摘したのは、フクオカRuby大賞の特別賞を受賞した「Cloud Foundry」の生みの親の1人、Derek Collison氏です。Derek氏はRubyの歴史を俯瞰して次のように述べます。

• 1993年に「より良い言語」としてRubyが登場した
• （ずいぶん空きますが）2005年には「より良いフレームワークとしてRails」が登場
• 2006年には、それまで煩雑だったデプロイ作業を「Capistrano」が刷新
• 2007年にはHerokuが登場し、さらにアプリ開発とデプロイ、運用が簡易化した
• 2008年にはNew Relicが登場してパフォーマンス管理も容易になった。

　このように、Rubyは実はサーバ上の自動化という面でも、各種ミドルウェアを統合するサーバアプリという分野でも活躍しているというわけです。

　Cloud FoundryはRuby「で」書かれたクラウドインフラです。処理系のVM（Rubyだけでなく、PHPやPython、Erlangも）をUnixプロセスとして起動したり、監視したりといったことからメモリ管理のシステムまで、Rubyでクラウドサービスを提供するためのクラウドオートメーションとかオーケストレーションと呼ばれる基盤を実装しています。クラウド時代には扱うリソースの種類や量が増えるので、これらをいかに運用するかが重要になります。

　「システムは年々複雑になり、SSDなど新技術も常に登場しています。Rubyはこうした複雑化するシステムの構築を容易にしてくれます。Rubyで速度に問題はないのかという問いもありますが、（クラウドのような）分散システムを構築するのに、純粋な言語の処理速度は、実はあまり関係がないのです」（Collison氏）

システムを取り巻くあらゆる部分が変化し続ける環境ではシステム構築の柔軟性が重要になるという

　変化が激しく多様化する環境に適用しなければならないのは、分散システムをRubyで作る場合だけではありません。いわゆるWebアプリも同様だといいます。

　「今後24カ月程度で企業の内製のWindowsアプリはWebベースへと移行するでしょう。問題は、サーバアプリが対応すべきモノは、すべてが流動的だということです。例えばハードウェアレイヤではSSDが登場してRDBMSについて考え直す必要があります。今後、1000コア、TB単位のメモリの時代が来れば、システム構築の方法を考え直す必要があります」（Collison氏）

　サーバアプリは今後、HTMLだけでなく各種モバイル端末やKVSなどの新しいストレージ技術にも対応していかなければならず、これらを統合する“アプリ”（サーバアプリ）は「生物のように自己継続できないといけない」というのがCollison氏の見立てです。もちろん、ハードウェアの真上で動くソフトウェアはC、C++、Javaなどで書かれるのでしょうが、全体を束ねて動かす言語としてクラウド時代にRubyが有効だということかと思います。

モバイル市場の急成長でJavaScriptによるアプリも注目されているが、サーバ側のWebアプリがやるべき仕事は実際には多く、こうした場面ではRubyが有効だという

なぜRubyなのか？

　なぜRubyかという問いにCollison氏は、「Rubyは、しばらくしてから読み直してもすぐに何をやっているかが分かる。これはほかのコードベース、例えばCやJavaでは困難なことだ」と答えます。「Rubyはもっとエレガントな言語だと思います。表現力が高いのに簡潔。自然に感じられるし、プログラムが楽しい。そしてパワフルなんです」（Collison氏）

　元Google社員のCollison氏は元同僚を誘い、2人がかりで3カ月でCloud Foundryを実装したといいます。このとき、こんな経験をしたそうです。

　「あるネットワークルーティングのコードを、彼はJavaで書き始めたんです。でも、すぐにRubyで開発する私のスピードに勝てないことが分かり、彼は週末を使ってRubyを学び、月曜日からはJavaからRubyに切り替えた。彼は非常に優秀な開発者で、私より遥かに優秀だと思うのですが、だから、そんな私に開発速度で負けることが嫌だったというのもあるのでしょう（笑）」

　Rubyの生産性については、米Engine Yard CEOのJohn Dillon氏も同様の証言をします。

　「スピードが要求されるアジャイル開発にRubyは適している。われわれの顧客でも、Rubyを使っている開発者は、ほかの言語の利用者よりも遥かに生産性が高い」（Dillon氏）

　ちなみにEngine YardはJRubyやRubinius開発のコアメンバーを抱えていることで知られているということ以外、まだ日本ではあまり知られていないかもしれませんが、すでに50の国や地域で2300の顧客を抱えていて、売り上げは年率100％で成長しているそうです。現在はRuby PaaSだけではなく、PHPのPaaSも提供しているほか、実験的にNode.jsのサポートを開始しています。数カ月以内に日本国内に拠点を設置し、日本市場への参入も計画しているといいます（福岡も候補地だそうです）。

　VMwareのCloud Foundy、そしてEngine YardのRuby PaaS、それからフクオカRuby大賞2012の優秀賞にも選ばれたIIJの「MOGOK」と、Ruby＋クラウドは花盛りといった感があります。MOGOK同様に優秀賞を受賞した株式会社あくしゅの「Wakame」もあります。WakameはRubyを使って“データセンターのHypervisor化”ともいうべき抽象化に取り組んでいるそうです。

　もちろん、Ruby関連プロダクトを表彰するのが目的のイベントですから「Rubyクラウドが花盛り」といっても、「当たり前だろ！」というツッコミもあることでしょう。しかし、PerlやPHP、Pythonで同様のイベントや実装ネタで盛り上がることがあるかと考えると、Rubyは一歩先を行っているように私には思われます。PHPもサポートするようになったEngine Yardですが、CEOのDillon氏は「Rubyからスタートしていなければ、われわれのビジネス自体が存在し得なかっただろう」とまで言い切ります。

　ちなみに、Cloud Foundryを作ったDerek氏は、PaaSよりも一歩進んだクラウドについて構想しているそうです。監査やビジネスプロセスといった業務アプリに必ず必要になる部分を、非侵食的にアプリとは独立した形で行えるような、そうしたクラウド、という話です。

JavaScriptが本命では？

　JavaScriptの普遍性は、今さら繰り返すまでもありません。いまやブラウザだけでなく、Node.js周辺ではサーバサイドで急速にエコシステムが発達してきています。Backbone.js、Ember.js、Spine.jsなどクライアントMVC戦争も過熱気味です。TitaniumやUnityといったモバイル、ゲーム関連でもJavaScriptが使えますよね。何よりも、GoogleのV8は今やスクリプト言語のなかでは最速の部類となっています（リンク）。

　こういう背景から考えると、サーバサイドやモバイルも含めて、JavaScript（ECMAScript 6）こそがスクリプト言語の最終勝者となる本命ではないのか？ 私はこの問いを、過去1年ほどさまざまな人に投げかけています。例えばNode.js創始者のRyan Dhal氏に2011年11月に話を聞きたときには、答えは明確にイエスでした。「動的言語に関して言えば、過去10年とか15年でいろいろなことを試してきたということです。Perlがあり、Pythonがあり、Rubyがありましたが、JavaScriptこそがこれらに勝って“スクリプト言語”の決定版となると思います」（Ryan Dahl氏）。

　JavaScriptが本命ではないのかという問いについて、Derek氏は、こう答えてくれました。

　「その問いに対しては、私は良くこういう質問で返すのです。もしRubyが今の10倍速くてブラウザ上でも使えるのだとしたら、RubyとJavaScriptと、あなたはどちらを選びますか？ 多くの人の答えはRubyと言いますよね。5年後に開発者がRubyを選ぶ理由というのは、いま開発者がRubyを選ぶのと同じ理由だと思います」（Collison氏）

　CoffeeScriptが典型ですが、「JavaScriptへコンパイルする」という“Transpiler”が一般化するのなら、ターゲットVMとしてJavaScriptエンジンが使われるような場面でも、引き続き人々はRubyを選ぶのではないかということです。

Rubyの課題

　べた褒めといってぐらいRuby好きを隠さないCollison氏ですが、その一方でRubyの課題も指摘しています。

　1つは「もし10倍速かったら」という“仮定”にあるように速度です。現在はストレージがボトルネックになっていて言語処理系の速度が問われないケースでも、今後SSDやインメモリのストレージが主流になれば前提が変わります。

　Cloud FoundryはRuby向けのノンブロッキングI/Oライブラリの「EventMachine」と、Ruby1.9標準のFiberを多用して書かれています。この時の経験から、Collison氏は、RubyにはEventMachineのようなイベント駆動で処理を記述するための標準APIが必須だと考えているといいます。EventMachineは非標準ライブラリで、メンテナンス状況もかなり悪いとのことです（リライトを検討せざるを得ないレベルといいます）。Collison氏はノンブロッキングI/Oだけでなく、マルチVMやScalaやErlangにあるアクターモデルなどの並列処理についても検討していく必要があるだろうといい、Collison氏は講演で、「美しい言語である、というだけで十分だろうか？（Is being a beautiful language enough?）」と反語的に問いかけていました。

論点2：Rubyはエンタープライズへ普及するか？

　Engine YardのDillon氏の証言は、発言する立場とRuby関連イベントでの発言という事実を割り引いて考える必要があると思います。しかし、IT業界で25年以上の経歴を持つDillon氏の言葉は傾聴に値するでしょう。Dillon氏は、もともとはEDSのエンジニアで、後にOracleやHyperion、SalesforceでCEOを務めたという経歴があります。

　そのDillon氏が講演で披露した次のようなパースペクティブは説得力があります。

　「現在、企業のIT予算の70～80％は、私が“ビッグIT”と呼ぶシステムの改修、保守に使われています。COBOLやJava、メインフレームといった古い技術で構築されたITシステムです」（Dillon氏）

“ビッグIT”のように投資を正当化できない領域で、小さなイノベーションを起こすのに使われているがRubyであり、クラウドであるという

　多くの企業では“ビッグIT”に予算の大部分が割かれるため、既存システム以外の新規プロジェクトには予算が割けません。各業界で小さなイノベーションを起こせる良いアイデアを持った現業部門は、使える予算が少ないからです。こうした部門こそが、Rubyやクラウド、外部の優秀な開発者を使って小さなプロジェクトを遂行しているのだというのです。

　IT関連サービスの成長率は業界全体で見れば低成長ということになるものの、この“スモールIT”というジャンルに限ってみれば、年成長率は40％にもなるというのがDillon氏の指摘です。2012年2月のEngine Yardのプレスリリースを見ると、既存顧客のEngine Yard Platformの利用率向上による収益向上が58％といいますから、確かに伸びているのでしょう。

　このジャンルは、企業内の技術部門に後回しにされがちです。

　開発依頼のチケットを切っても、ビッグITの隙間をぬってやるにはプロジェクトが大きすぎるし、たいていは作ったことのないアプリケーションだったりするので、技術部門はやりたがらないか、やれるだけのスキルセットがありません。だから、外部の優秀な開発者を使って、クラウドで作る。その時に選ばれている言語がRubyだというのです。

Rubyで起こす、正しく小さなイノベーション

　成長性の高い分野で顧客を獲得しているからこそEngine Yardは年率100％の成長ができている、というのがDillon氏の話のポイントです。同社の顧客リストを眺めると、グルーポンやTechCruncといったWeb2.0の申し子といったブランド名もあるものの、むしろ目に付くのはGAP、CAT、TOYOTAといった小売や製造業のブランドです。こうした企業がソーシャル機能を取り入れたような小さなプロジェクトでRuby＋PaaSを選んでいるというわけです。

　「クリティカルではない、小さな実験的なプロエジェクトのほとんどは失敗するでしょう。しかし、こうしたプロエジェクトこそが、イノベーションの正しいやり方です。成功例が増えていけば、いずれRubyも“ビッグIT”に普及していくでしょう」（Dillon氏）

　今年、フクオカRuby大賞の大賞に選ばれたのは、Rubyで書かれた帳票ソリューションの「ThinReports」でした。RubyやRailsでPDF形式の帳票を生成できるライブラリと、帳票レイアウト作成エディタ（WindowsアプリWindows、Linux、Macで動くアプリ）です。“帳票”といえば日本の業務アプリケーションを象徴するようなビジネス習慣ですが、こうしたソリューションが登場してきていることも、Dillon氏の予測を裏付けていると言えるのかもしれません。

　Rubyコミュニティの有志が定期的にパブリッシュしているオンライン誌の最新号、Rubyist Magazine 36号が11月28日に出ました。

　今回の注目記事の1つは、近藤うちお(@udzura)さんによる「Sinatra再入門、Padrino/Rack/その先の何か」でしょうか。Ruby on Railsの弟分と言われることもある、軽量Webアプリケーション向けライブラリの「Sinatra」の解説です。極めてシンプルな文法（DSL）で、Webアプリケーションが作成できるので、Railsはちょっと大げさだなぁというようなケースや、そもそもRailsが用意しているレールとは違う骨組みでアプリを作りたい、あるいはサーバサイドはMongoDBやRedisといったストレージをAPI化してクライアントに見せたいだけ、というようなケースで使われることが多いように思います。Ruby界だけでなく、ほかの言語にもSinatraに似たコンセプトのものが増えていますよね。ちなみに私は仕事で使うスクリプト群は、SinatraにくるんでHerokuに置いて使っています。50～60行なら全部1ファイルで済んじゃうところが気に入っています。

　Sinatraはシンプル過ぎて、結局車輪の再発明が必要になりがち――、その問題を解決したのが「Padrino」ということですが、どうも私は長らくこのPadrinoという存在が解せません（近藤さんのブログも結構読んではいるのですが）。だって、Sinatraにあれこれ盛り込んだら、結局またRailsになるんじゃないの？ と思うからです。

【追記】以下、ちょっと私の誤解だったようです。ツイートを引用させて頂きます。「というかちょっと違っていて、、、、、、Padrino は Sinatra の上に Rails を使いたいんではなく、あくまで Sinatra 拡張スイートのうちの一つで、その中でももっとも良いものの一つ、というのが僕の考えなんです」とのことです。失礼いたしました……。

【追記2】「ビュッフェ」というたとえ話について再度考察したブログを、近藤さんが別エントリとして公開されました。そもそも、Sinatra自体がビュッフェ的であるとのことです。皆さま、ぜひご一読を。

　近藤さんによれば、そうではないそうです。Padrinoの主眼はORMやテンプレートエンジン、テスティングフレームワーク、スタイルシートエンジン、JavaScriptライブラリなど、好きなモノを選んで使うことができる「ビュッフェスタイルの開発」を実現することだとのことです。好きなものを好きなだけお皿に載せるということですよね。このたとえで言えば、Ruby on Railsはフルコースとのことです。そういう説明をされると、なるほどという感じです。Merbが目指したモジュラリティーは、仕組みとしてはRails3に入っているけれども、実質的にはシェフのお勧めどおりにコースを食するのがRails的グルメという感じになっている面もあると思います。

　SinatraはRack層に最も近いこともあり、記事の中ではRack層の活用がSinatraやPadrinoによる開発のポイントの1つと指摘されています。RackはRubyの話ですが、いまやWSGI（Python）やPSGI（Perl）、JSGI（JavaScript）というように、各言語にRack層と同じものがあります。この“モダンなCGI”とでもいうべき考え方を学ぶという意味でも、Sinatraは結構良いのかもしれませんよね。

　そうそう、Sinatraといえば最近の話題を、もう1つ。Redis、Sinatra、jQueryを使って書かれたお手本のようなソーシャルニュースアグリゲーション実装の「LamerNews」が面白いです（GitHubのレポジトリ）。Redisの生みの親でイタリア人開発者のantirezさんがHackerNewsの編集方針を巡り、激昂した勢いで実装して運用をおっぱじめちまったもので、HackerNewsクローンです。ソースコードを見てみると、「この程度なら車輪の再発明でいいんじゃないの？」というような実装です。例えばHTMLテンプレートエンジンに相当するものを、いきなりKernel#Hとして定義してしまっていたりして、自前で必要なパーツを作って組み上げていくところに、Redis同様のミニマリズムを感じます。Sinatraの実例としては、もしかしたらいまいち（Sinatraのあれこれを使いこなしていない）のかもしれませんが、お皿の上に自由に盛って作る精神を見るという意味ではLamerNewsは参考になるかもしれません。全体が短いですし、私にはすごく面白かったです。

　恐らく2日ほど前のことだと思いますが、GitHub上で、Node.jsのウォッチャー数がRuby on Railsのウォッチャー数を超えてナンバーワンの座についたようです。NodeはJavaScriptエンジンのV8＋イベント駆動のWebサーバという「処理系＋サーバ」であるのに対して、Railsは言語処理系を含まないフルスタックのWebアプリケーションフレームワークという違いがあります。NodeにはExpressなどのWebアプリケーションフレームワークがあります。だから、RailsとNode.jsを比較するのも変な気がします。そもそも「ウォッチャー数に、意味あるの？」という皮肉な見方も可能でしょう。それにしても、ウォッチャー数でNodeがRailsを超えたというのは、JavaScript人気の高まりと、リアルタイムWebへの期待感を示すという意味で、これは象徴的な数字だと思います。Node.jsもそうですが、JavaScript界隈全体に勢いを感じる今日この頃です。

　ちなみに、GitHub全体のプロジェクトを言語別に見てみると、以下の通り。JavaScriptが全体の20％と1位で、これはずいぶん前からこうだったように思います。

　2011年10月19日、Rubyの生みの親で現在もCで実装されたRuby処理系の開発をリードしているまつもとゆきひろさんが、Ruby 2.0の開発開始を宣言しました（GitHubの関連コミット）。今のところ、

• 2012年12月24日のクリスマスにプレビュー版1をリリース
• 2013年2月24日にRuby 2.0正式版をリリース

というプランが描かれています。Ruby 2.0の正式版が出る2013年2月24日は、ちょうどRubyが20歳になる日でもあります。Rubyは20歳にしてRuby 2.0に、ということですね。

　ここ数カ月ほど、Rubyのコア開発者の間で、今後のバージョン付けと、その開発の射程、リリーススケジュールについて議論が続いていましたが、1つの決着を見た形です。2.0を出すことについての議論は平坦ではなく、2011年7月に行われたRubyKaigiでのまつもとさんの「（1.9.3の次の順当なバージョンである）1.9.4は出さない。なぜなら、それを2.0とするからだ」という発言に、内部のコア開発者の卜部昌平さんが驚いて、それってどういうことよ？ というチケットを投げたりしていたほどです。

　ここで、Rubyのバージョンについて少し整理してみます。

●1.8系

　互換性のための旧バージョンの系列。1.8.6に対して1.9の機能をバックポートした1.8.7は、今でも広く使われています。ただ、2008年にリリースされた1.8.7が1.8系の最後のリリースとなる予定です。2012年6月までは通常のメンテナンスが続き、2013年6月まではセキュリティフィックスも行われます。が、Rubyのコア開発者は1.8系は率直に言ってオススメしないとしていて、実際、New Relicの調査を見ても、1.8→1.9の移行はRails3.1の登場とも相まって、ようやく進み始めているようです。

●1.9系

　現行の安定バージョンは1.9.2です。1.9系は、1.8系に比べてVM方式に移行し、高速化し、文法もより洗練されています。現在は1.9.2が最新ですが、1.9.3が今にも出そうというところです。1.9.3ではガベージコレクタが新しくなり、リアルタイム性が求められるケースで性能改善が見込めるほか、Railsのスタートアップタイムが3割とか5割速くなるという報告が数多くあります。1.9系のリリースマネージャ、Yuguiさんによれば、1.9.3で1.9系は1つの完成バージョンとなるということです。ちょうど1.8.6に相当する感じで、1.9.3は使われ続けることになる、ということでしょうか。

●2.0系

　開発版バージョン。新機能が盛り込まれる予定です。

　もともと、Ruby 2.0は過去との互換性よりも、新機能を盛り込むバージョンとして、さまざまな新機能や実装、アイデアが語られてきました。ただ、今回始まったRuby 2.0の開発は、実はそうした「未来にある理想のRubyとしての2.0」ではなく、1.9.4となるはずだったバージョンがスライドしたような印象です。どうも、まつもとさんの意向としては、1.9.4を待ってから2.0の開発ブランチを切るというのだと、2.0の仕事に取り掛かるのが遅れるからということのようです。

で、Ruby 2.0の新機能って？

　さて、肝心の2.0の新機能って何？ というところですが……。世代別GCや、並列してVMを走らせるMVMといった言語の根幹に関わる大物の機能は入らない模様です。GILまたはGVLと呼ばれているロック機構を取り除くのも2.0ではやらないことが決まったようです。実装の継承（mixin）やメソッドのオーバーライド（モンキーパッチ）で、その影響範囲を限定するような仕組み（ClassboxとかRefinementsと呼ばれているもの）は……、どうなんでしょうか。まだこの辺りは揺れているようです。こうしたゴールをすべて入れて理想のRubyとなるはずだった、Ruby 2.0はRuby 3.0へと遠のき、1.9.3よりも新しい試みを入れるものがRuby 2.0となる、ということのようです。また、2.0で入れるべき機能や修正について、Ruby 1.9で採用されたVMを設計・実装した笹田耕一さんによるアンケートが始まっています。

　Ruby 2.0で確実に入るもので興味深い機能としては、「キーワード引数」があります。キーワード引数については、いきなり遠藤侑介氏が「実装してみました」と言って仕様の議論が始まったりもしているようです。元々Rails以降のRubyでは、引数をハッシュで渡すコンベンションが一般化していましたが、それがシンプルに書けるようになる、ということのようです。いちいちハッシュを評価するより、かすかに速くなったりもするのでしょうか。もちろん、速度よりも可読性や書きやすさによる生産性向上が主眼なのでしょうけど。

　もう1つ、利用者としてやや気になるところは、標準添付ライブラリのgem化でしょうか。Rubyのライブラリは標準添付のものは当然Ruby処理系のパッケージに含まれる形でインストールされますが、この場合、Rubygemsのようなアップデートの仕組みが使えません。このため、言語のバージョンアップに合わせてしか標準ライブラリのアップデートができず、セキュリティパッチの配布で困るケースがあるということです。これを解決するために、一部の標準ライブラリのgem化が進みそうです。ただ、すでに標準ライブラリの中でも、RakeやRDoc、Minitest、JSONなどはgem化されています（ruby/lib/rubygems/defaults.rbが、ruby/defs/default_gemsを参照するなどしてインストールしています）し、全部が全部gem化されるわけではないということですが。

　ともあれ、Ruby 2.0へ向けた取り組みが始まったということで、開発者の皆さま、おめでとうございます！

　Ruby on Railsの最新バージョン、Ruby on Rails 3.1.0が日本時間だと昨日（2011年8月31日）、リリースされました。今日（9月1日、米国時間だと8月31日）になってから公式ブログにもアナウンスが出ました。

　英語の情報源になってしまいますが、読むべきWebページを列挙しておきましょう。

• 公式ブログのリリースノート：変更点が簡潔にまとまっています
• RailsGuidesのRails3.1 リリースノート：ズラズラズラっと解説＋コード＋箇条書きで変更点がまとまっています。RailsGuidesのほかの項目同様に力作です
• RailsGuidesのAsset Pipelineの解説：Asset Pipelineについていちばん良くまとまっています

　このブログでも何度か取り上げていますが、今回のバージョンアップは非常に大きなものです。すでにRails 3.0系でメジャーバージョンアップは果たしているわけですが、3.0は、本当のRails3とも言うべき3.1への準備のステップでした。3.1に入った機能が枯れて落ち着くバージョン3.2こそが、Rails3の長らく使われるバージョンになるだろう、というのは、日本人としてRailsに最も多くパッチをコミットしている松田明さんの読みです。

　Rails 3.1の注目ポイントを簡単にまとめると、

• デフォルトのJavaScriptライブラリがPrototype.jsからjQueryに変更
• Asset Pipelineと呼ぶ仕組みの採用
• JavaScriptへコンパイルできるRubyっぽい文法のCoffeeScriptの採用

　といったところでしょうか。

実は体感速度が上がる？

　先日、松田さんとの会話で指摘されて気付いたことですが、Rails3.1では、開発者が使うAPIもいろいろと変わっていますが、何よりも「Railsで書いたWebアプリの体感速度が速くなる」のが大きな違いかもしれません。

　Rails3.1が速くなる最大の理由は、Asset Pipelineによって、ゴチャゴチャとたくさんあったサイズの小さなファイル群がまとめられることで、HTTPリクエストの数が大幅に減ると期待できるからです。「HTTPのリクエスト数を減らせ」というのは、Yahoo!のYslowチームがWebサイト高速化の最優先テクニックとしているものですよね。

　Asset Pipelineを使えば、JavaScriptやCSS、画像などのファイル（asset：アセットと呼んでいます）を、asset以下のサブディレクトリに整理して配置できます。“パイプライン”と呼んでいるのは、HTTPでこれらのアセットをサーブするときに、何らかの処理を施しつつ出せる「パイプ」の役割を果たすからです。処理というのは具体的には、CoffeeScriptのコンパイル、複数JavaScriptファイルの連結やminify、CSSテンプレート言語（SCSS）の変換、そしてCSSファイルの連結や圧縮（無駄な記述の消去）、CSSスプライティングといったことです。

　今までpublicの下に放り込んであって「Railsアプリの外」という感じで雑然と扱われていたファイルたちが、きちんと整理されるという意味で、スッキリします。開発時にはCSSファイルを意味的に分離しておいて、実際にサーブするときにはapplication.cssだけにまとめるという処理が自動的にできるようです。これまでのRailsにも連結機能があったものの、それを使わない開発者も多かったといいます。

　Asset Pipelineには「Sprockets」という既存ライブラリが使われていますが、同様の役割を果たすものは、ほかにも「Jammit」「Stitch」などがありました。それぞれに強みや思想が異なっていたようで、Sprocketsが本当にベストだったのかというような議論もあるようですね。特に、CSSスプライティングについては、今のところSprocketsでは上手く機能していないという話です（情報求ム）。であれば、Asset Pipelineも取り替え可能なモジュールであれば良いのに、という気がしなくもありません。

　ともあれ、Rails3.1になることでHTTPのリクエスト数が減りそうだということは間違いありません。

　もう1つ、体感速度の向上に貢献しそうなのは、HTTP Streamingです。HTTPセッションを維持したまま、チャンクで次々とクライアントにデータを送る方法ですが、Railsで使って何が嬉しいかというと、サーバ上でページのレンダリング（SQLによるデータのレトリーブやテンプレート適用）をしている最中にもJavaScriptやCSSをクライアントのブラウザに送り出し始められることです。場合によっては、100msecぐらい稼げてしまうかもしれませんよね。

　さて、やや無理矢理、Rails3.1ではWebアプリが速くなるかもしれないと書きましたが、Rails3.2では体感速度に影響しそうなPjaxの取り込みも控えていますし、「体感速度向上」は、1つの方向性じゃないかなと思います。Pjaxについては、以下の3つのブログ記事が参考になると思います。

• pjax こそが pushState + Ajax の本命 - punitan (a.k.a. punytan) のメモ
• githubのURLをうまく扱うオシャレなアレ = pjax @ val it: α → α = fun
• pjaxが便利過ぎて鼻血出そうになった（railsのサンプル付き） - SELECT * FROM life;

　RubyとRailsの両方のコミッタで、日本語も話せるAaron Pattersonさんが、Ruby on Rails Talkメーリングリスト上で次期バージョンのRails 3.1のリリーススケジュールを7月26日にアナウンスしました。以下の通りです。

• 8月 4日木曜日: Rails 3.0.10.rc1
• 8月 8日月曜日: Rails 3.1.0.rc6
• 8月 8日月曜日: Rails 3.0.10
• 8月22日月曜日: Rails 3.1.0

　米国時間なので、日本では8月23日火曜日にリリースということになりそうですね。

　ちなみに現在、すでにリリース候補版のRails 3.1.0 rc5が出ていますが、JavaScript実行環境がないとScaffoldなど一部のジェネレータが動かないようです。CoffeeScriptのコンパイラがJavaScriptで書かれているからですが、「イマドキ、Node.jsぐらい入ってるだろー」「いやいや、Ruby on Railsがそれを前提としたらイカンだろう」という議論があったそうで、Rails 3.1のファイナルリリースではRubyだけで動くようになる模様です。

　Rails 3.1の目玉機能の1つ、Asset Pipelineですが、オーストラリア人テクニカルライター、Ryan Biggさんが、RailsGuidesに1章分を書き足しつつあるようです。

　電子書籍に特化したオンラインの出版社、達人出版会から、『徹底解剖「G1GC」 アルゴリズム編』（中村成洋著、600円）が6月末に出ました。Java7（OpenJDK7）で採用されたG1GCアルゴリズムを、豊富な図を使って丁寧に解説した本です。A4換算で60ページほどです。

　島根在住の中村さんに、Skypeでお話を伺いました。

　GCアルゴリズムを網羅的に解説した前著とも言える『ガベージコレクションのアルゴリズムと実装』と併せて読むのがオススメだそうですが、私は中村さんが管理している「GCアルゴリズム詳細解説」のWikiと併せて読みました。GCの各種アルゴリズムって並行処理時の整合性確保のための実装や性能評価は難しいのでしょうけど、アイデア自体は、そこまで複雑じゃないものが多いですよね。ヒープメモリという部屋をどう区分けして、そこにどういう性質（生存期間や生き死に）のオブジェクト群を、どう配置し、どういうタイミングで再配置したり、廃棄するかという戦略の話なので、図を見ながら「へー、なるほど」と頷く程度なら、門外漢でも案外楽しめます。

図が豊富で分かりやすい解説

CRubyコミッタで、『徹底解剖「G1GC」 アルゴリズム編』の著者、中村成洋氏

　nari3のidで知られる中村さんは、CRubyのコミッタ（Ruby開発チームのコアメンバ）です。CRubyのコミッタには大きく2タイプがいます。Ruby全体を見ていて、あらゆる種類のパッチを書く人と、ある特定ジャンルをカバーする人です。中村さんは後者で、8月26日にリリースされる予定のRuby 1.9.3に搭載される新しいGC（Garbage Collector）のパッチを作成されました。これまでのRubyでは、GCにマーク＆スイープと呼ばれるアルゴリズムを使っていて、オブジェクトの参照のツリーをたどっていきながら参照がないオブジェクトを確定し、続いてメモリを一気に開放（スイープ）する仕組みでした。新たに中村さんが実装した「Lazy Sweep GC」では、この開放のプロセスを複数回に分けることによって、GC動作時の最大停止時間が短くできるそうです。

アイスクリーム工場からRubyコミッタに

　中村さんは、もともとアイスクリーム工場で流れ作業をやっていたそうです。ソフトウェア開発者という現在のお仕事からすると、ちょっと信じがたい経歴です。

　工場で働いていたある時、半年でプログラミングができるようになるという広告を目にして学校に通い、JavaでWebアプリを作る仕事を得て、プログラミングの世界に転身したそうです。その頃、Rubyistの間では有名な『Rubyソースコード完全解説』（青木峰郎著、まつもとゆきひろ監修）を読んだことがきっかけで、GCの世界に目覚めたそうです（Rubyソースコード完全解説は2002年刊行で、すでに絶版ですが、HTML版としてオンラインで読めます）。現在はRubyの生みの親であるまつもとゆきひろさんと同じく、島根県のネットワーク応用通信研究所にお勤めです。日頃はRailsを中心にWebアプリ開発をしていて、CRuby関連の仕事は基本的に業務外で取り組んでらっしゃるそうです。

最大停止時間を“ほぼ”一定に抑える「G1GC」

　さて、G1GCですが、これはメモリ容量が大きい最近のサーバ環境で、最大停止時間をなるべく一定時間に抑えたいというニーズに応えるアルゴリズムです。いわゆる組み込みなどでいうリアルタイム処理とは異なり、最大停止時間を超えることが“ほぼ”ない、というソフト・リアルタイム性を実現しているのが特徴だそうです。サーバアプリケーションで電話の着信をさばくようなケースを想定しているとのことです。

　G1GCでは、このソフト・リアルタイム性を実現するために、ヒープを小さなリージョン（領域）に分けて、それぞれのリージョンごとに小さなGCを走らせます。このとき、それぞれのリージョンのGCにかかる予測時間が、各リージョンごとに管理されています。中村さんの本の中では、「並行マーキング」と、リージョン内のオブジェクトのうち生きているものだけを空いている別リージョンに「退避」する仕組みについて詳しく解説されています。

　そんなG1GCですが、本書を読めばJava開発者なら今後チューニングに役立つ知識が身に付くかもしれません。残念ながらG1GCは特許が成立しているそうで、Rubyに搭載される見込みはありませんが、純粋に読み物としても面白いのでRubyistにもオススメです。

　ところで、中村さんはGCが本当に好きで、今や日本でも上から数えたほうがいいぐらいにGCに詳しいエンジニアですが、意外にも「Rails開発は難しい」と言います。

　「Webアプリケーションって、いい加減にやればすぐ作れちゃうでしょうけど、セキュリティとかチューニングとかちゃんとやろうと思うと幅広い知識が求められますよね。GCだったらGCだけ、あるいはOSの泥臭いところを勉強すればいいだけですけど、Webアプリは全然違う分野を勉強しないといけなくて大変すぎるなー、という印象があります」

　GCとWebアプリだと難しさの質が違うのでしょうか。

　Ruby on Railsは、バージョン2系から3系へと移行しつつあります。このメジャーバージョンアップは現在も進行中で、2010年8月29日に出たバージョン3.0は、その後、バージョン3.0.9までマイナーバージョンアップが進んでいますし、2011年5月22日にはRails 3.1のリリース候補版がリリースされ、正式リリースが目前に迫っています。そして、実はバージョン3.2や、4.0の話まで聞こえてきています。

　7月25日に発売される『Rails3レシピブック 190の技』（高橋征義／松田明／諸橋恭介著、ソフトバンククリエイティブ）の刊行記念イベントとして東京・池袋のジュンク堂で行われたトークイベント「最新のRuby on Railsの魅力を語る～3.0、3.1、3.2、そして4.0へ～」から、Railsの最新トピックに関連する気になる発言をピックアップしてお伝えします。

トークイベントで話す共著者ら。左から高橋征義氏、諸橋恭介氏、松田明氏

　このRails3レシピ本は、ほぼ同名の前著『Railsレシピブック 183の技』の改訂版という位置付けです。Rails2対応だったものをRails3に合わせて書き直し、レシピも追加されています。2→3への移行にともなって世代交代のあった定番プラグインも解説されています。また、CoffeeScriptの使い方などバージョン3.1に関するレシピもあり、「私が知るかぎり、紙の書籍でRails3.1に対応した本は世界初」（松田明氏）ということです。

　今回、著者として加わった松田氏は、朝起きたらまず新聞を読むかのように、時差のあるアメリカで前日に行われたRailsの開発のコミット履歴を読むといいます。その松田氏によれば、2→3への移行における各バージョンの関係は、以下の通り。

• Rails3.0は2系との互換性を保ったまま、徹底的にリファクタリングしたバージョン
• Rails3.1は、2.x系との互換性を完全に切り捨てる最初のバージョン。Rails2で書かれたアプリは動くなくなる
• Rails3.0には新機能はあまり入っていない。DSLが“おしゃれ”になった程度
• Rails3.1には新機能がいろいろと入っている。Asset Pipelineや、CoffeeScript、HTTP Streaming、Identity Mapなど
• Rails3.1で入った機能のうち、例えばIdentity Mapは極めて荒削りな状態で入っていて、「ほんとに実アプリで使うの？」という感じ。3.2になれば、使えるようになる
• 3.2は3.1の安定版という位置付け。3.1はコントローラ周りが遅い、Safe Buffer周りの実装がすっきりしないなどの課題がある。3.2ではパフォーマンスチューニングをガッツリやる
• 3.3は、出るかどうか分からない。たとえ出るとしても大きな機能は入らない
• これから出るパッチは、Rails 4に入ることになる。4.0の話はもう始っている
• Rails 4では、Ruby 1.9でないと動かなくなる
• 予言しておくと3.1は短命になる。しかし、3.1はとにかく面白いのでどんどん使うべき
• 3.1でjQueryが標準になった。rails-coreメーリングリストでアンケートを取ったら、すでに8割の開発者がRails3.0でjQueryを使っていた。だから3.0で間違ってprototype.jsを使っている人は、未来がないと思って、jQueryに乗り換えると良い

　直近のRails 3.1は、3系の中では大きく足を踏み出したリリースで、その次の3.2でひとつの完成ということでしょうか。となると、Rails2.1、2.2が短命で、2.3系が長く使われたのと同じで、Rails 3.2が長く使われるバージョンとなりそうですね。もちろん、3.1が短命といっても、CoffeeScriptやAsset Pipelineなど、かなり重要な機能が入っているので、使わない手はないのでしょうけど。

　さて、松田氏によれば、「Rails 3.2では、DHHが言っていたこととしてPjaxが入るっていうのがありますねぇ」ということです。トーク中ではGitHubを実例として示していました。GitHubでは、ページの真ん中辺りでフォルダ階層をたどっていくと、Ajaxのように画面の一部がスライドして切り替わります。ところが、よく見ると、URLがちゃんと切り替わっている。つまり、これはAjaxではない。「これは単に新機能というだけじゃなくて、とても使いやすくなる。明らかに速くて、明らかに快適。PjaxはAjaxの悪いところをなくしている」（松田氏）。

　Pjaxは、すでに3.1でもpjax_railsというプラグインを入れることで「使おうと思えば使える」（松田氏）のだそうです。

ActiveRecord横綱相撲で、NoSQL対応はどうなる？

　トーク後にイベント会場から、興味深い質問が出ました。

　せっかくRails3でモジュラリティが高まってプラガブルになったのに、永続化層としてActiveRecordが一強状態となっている。今後、ActiveRecordを置き換えるようなものは出てくるのか？ NoSQLとしてRDBと異なるものも出てきてるのに、ActiveRecordの強さが多様性を阻害しているのではないか？

　この質問に対して、諸橋氏は、「NoSQL的なところでしょうか。ActiveRecordを使わずに、Mongoid（MongoDBのRailsライブラリ）を使ったプロジェクトもある。そういう方向性は、あるかなと思う」と回答。

　松田氏は「RDBMSの部分をモジュールとして切り出していることを考えると、ActiveRecordをデフォルトにしようという意図はあまりないのではないかと思います。あくまでもActiveRecordパターンのRuby実装という位置付け。ただ、Rails2から3への移行でいちばん感動したのは、実はActiveRecord。ほんとに良く書けていて完成度が高いんですよね」と、むしろActiveRecordの完成度を強調していました。ユースケースを拾い切れないなら一強状態は好ましくないですが、本当に実力を伴った横綱なのであれば、それはそれでいいということかもしれませんよね。ActiveRecordを横綱とすると、NoSQLの中でもMongoDBだけは例外的に関取ぐらいにメキメキと頭角を表して昇進している、という感じでしょうか。

　さて、バージョン2から3.0→3.1→3.2へと変遷するに連れて、Rails自身も、それを取り巻く環境も大きく変わってきています。バージョンごとに変化の激しいRailsと、そのエコシステムのあり方について、高橋氏はこう指摘してトークを締めくくりました。

　「個人的にRailsを使っていたのは、バージョン2とか2.1のときです。しばらく間があって、今は3を使っています。途中の変化を見ていれば、どう進化してきたか分かるかもしれないけど、結構3になってガラっと変わっているんですよね。ただ、新しいバージョンは当然使いやすくなっているので、ぜひこの本を読んでRails3にチャレンジしていただければなあと思います」

　また1つ、Node.jsベースのWebアプリケーションフレームワーク「SocketStream」が登場しました。6月23日にロンドンで開催されたHacker Newsのミートアップで発表されたようです（@makoto_inoueさん、情報提供ありがとうございます！）。GitHubのレポジトリにはバージョン0.1のソースコードと、何ができるかというサンプルコードを含む長大なドキュメントが公開されています。

　このSocketStreamは、単にまたNode.jsでWebアプリケーションフレームワークが1つ増えたという感じではないようです。従来のものとは、設計がドラスティックに異なっています。

　まず、名前から自明なように、WebSocketを基本としていて、SPA（Single Page Application）が作りやすいように設計されています。SPAとは、1ページのHTMLを読み込んだら、後はAjaxでデータのチャンクをサーバからもらうタイプのWebアプリケーションのことで、Twitterが典型です。Twitterはヘルプや設定などを除いて、大部分のアクションは同じ1ページのHTMLが次々と書き換わるという設計になっていますよね。

　1ページのHTMLで作るSPAは、ページ書き換えが一部分であるため体感速度が早いわけですが、それでも現在の多くのAjaxを使ったWebアプリは、HTTPを使ってデータをやり取りしています。つまり、セッションが切れてる場合はハンドシェークがあるほか、毎回HTTPヘッダの送受信というオーバーヘッドがあるわけです。これがWebSocketでサーバとブラウザ間に双方向の通信経路が常時確立されるようになれば、相当スピードアップするはずで、また一歩、Webアプリがネイティブアプリとのギャップを埋めることになりそうです。SocketStreamでは、全てのデータはJSONにシリアライズしてやり取りされるようです。

　SocketStreamは応答速度にこだわっているようで、サーバ側のストレージには、インメモリのKVS「Redis」を使っています。RedisはCで書かれた高速なKVSですね。非同期の永続化やレプリケーションにも対応した変わり種（？）で、ハッシュやリスト、集合などのデータ構造、アトミックな加算ができる数値型、コレクション同士のちょっとした集合演算などができる高機能KVSでもあります。小さなデータをガンガンやり取りするWebアプリだと、応答性が良くなりそうですよね。StreamSocketの開発者たちは「Crazy fast!」（狂ったように速い！）と強調しています。

●サーバもクライアントもCoffeeScript

　SocketStreamがフレームワークとして面白いのは、サーバ側のコードと、クライアント側のコードの連携を、人間にとって分かりやすいAPIとしてまとめていることです。まず、両サイドともCoffeeScript（JavaScriptへコンパイルすることを前提とした言語）を使います（FAQを見ると、ほかの言語のサポート予定はないようです。この辺、opinionatedな匂いがします）。そして、ちょうどjQueryに「$」のように「SS」というグローバル変数を名前空間として、クライアント側からサーバ側のメソッドが呼べるかのようなAPIになっています。

　例えば、サーバ側のコードとして、/app/server/app.coffeeに、

exports.actions =
  square: (number, cb) ->
    cb(number * number)

などと書いておき、クライアント側のコードとして、/app/client/app.coffeeに、

exports.square = (number) ->
  SS.server.app.square number, (response) ->
    console.log "#{number} squared is #{response}"

と書けば、クライアントからサーバのメソッドを呼び出すかのように結果を持って来られるようです。クライアントのコードやHTML、CSSはサーバ側からブラウザに送られる際には、minifyやパッケージ化など自動で行われます。SocketStreamでは、これらのファイルに変更があると、

• CoffeeScript
• Uglyfi.JS（minifyするライブラリ）
• Jade（HAMLのようなHTMLテンプレートエンジン）
• Stylus（SASSのようなCSSプリプロセッサ）

などをキックして、ブラウザに送り出してくれるようです。

　SocketStreamは、まだ実験的な実装で、今後は複数CPUコアを活かしきる機能追加によってスケールアップ性能を上げることも検討しているといいます。ただし、Node.jsなので、2000～3000クライアントの同時接続ぐらいなら、すでに全く問題ないということですが。

　フルスタックのWebフレームワークだと言っていますが、SocketStreamは、いわゆるモデルを簡単に扱う仕組みはありません。スムーズな同時接続数を主眼としているだけあって、Userモデルが組み込みだったり、認証機構も用意されているようですが、ガンガンCRUDでモデルを作りたいという用途だと、ちょっと面倒かもねとFAQには書いてあります。ただ、これについては、「Real Time Model」という仕組みを内部的にテストしている最中で、期待して待っててねということだそうです。Real Time Modelとはずいぶん思わせぶりな命名ですが、どんなものが出てくるのか、ちょっと楽しみですね。

　HamlとSassのバージョン3.1が4月24日にリリースされました。元々両者は同じプロジェクトだったのですが、今回のリリースから別々のgemとなり、インストールも別にできるようになりました。

　Hamlはインデントを使ってシンプルにHTMLを生成できるテンプレートエンジン。SassはHamlとセットで誕生した、インデントを使ってCSSをシンプルに書ける独自のスタイル指定言語です。CSSを書くのが苦痛じゃなくて、楽しくなるという触れ込みです。

　Hamlのほうは、今回はSassの分離が大きなトピックである以外は変化はありません。変化が大きいのは「Brainy Betty」と名付けられたSass 3.1.0のほうです（brainyって脳みそが詰まっていて頭が良いという意味ですね。変な名前を付ける人たちです……。Sass自体も、生意気な女という意味で使われる「sassy girl」にかけているんだと思います）。

　Rails 3.1にはSassの弟分のSCSSが標準で入り、SassもHamlも選外（？）となりました。恐らく学習コストや扱いやすさ、既存のCSSとの互換性などを考えてのことだと思います。そうしたバランスを考えなくていいからか、Sassは妙に機能強化されている印象です。

　例えば、Sassでは元々関数が定義できますが、これがSassファイル内で可能となりました。

$grid-width: 40px;
$gutter-width: 10px;
@function grid-width($n) {
  @return $n * $grid-width + ($n - 1) * $gutter-width;
 }

　これはグリッドの各セルの幅を、セルの個数で動的に決めるという関数ですね。CSSとはエラい違いです。関数の中では条件分岐の「@if」というディレクティブも使えます。

　変数定義が可能で、関数定義や条件分岐もできるCSSというだけでも「極まってる」感がありますが、さらに今回、データ形式としてリストもサポート。CSSには「Helvetica, Arial, sans」とか「0px 10px 5px 10px」など、元々リスト的なデータ構造がありますが、こうしたデータに対して、

• nth($list, $n)
• join($list1, $list2)
• append($list, $val)
• length($list)

などの関数が使えるようになりました。リスト型ができたので、eachも定義されました。

@each $animal in puma, sea-slug, egret, salamander {
  .#{$animal}-icon {
      background-image: url('/images/#{$animal}.png');
      }
}

と書けば、

.puma-icon {
  background-image: url('/images/puma.png'); }
.sea-slug-icon {
  background-image: url('/images/sea-slug.png'); }
.egret-icon {
  background-image: url('/images/egret.png'); }
.salamander-icon {
  background-image: url('/images/salamander.png'); }

とコンパイルされます。CSSは繰り返しが多くなりがちで、こういうプログラミング的なアプローチがあるといいですよね。

　色の扱いについても、RGB値を反転させるinvertや、色の明るさを変える「adjust-color($color, $lightness: 10%)」なども増えているようです。

　こんにちは、＠IT編集部の西村賢（@knsmr）です。先日、地域Rubyコミュニティの「Asakusa.rb」の花見に参加しました。世界でただ1人のCRubyとJRubyの双方のコミッタである中村浩士（@nahi）さんに「CRubyではなくJRubyを採用すべき理由は？」という話をお聞きしました。中村さんの指摘で興味深いのは、本当はJRubyを使うべき人々が、その良さに気付かないままCRubyを使っているのではないか、という点です。

　以下、お花見気分がほとばしる動画（背後で子どもたちも走りまわっております）で、若干音声が聞き取りづらい部分もありますが、中村さんのお話の動画をお届けします。CRubyではなくJRubyを選ぶべき理由について説明しているほか、CRubyとJRuby、Rubiniusの関係についてもご意見をいただけました。

　中村さんの指摘をまとめると、

• CRubyのライブラリは処理系をブロックするものが少なくなく、Webアプリをスケールするのに工夫がいる
• プロセスを分けるなど自分で問題を同定して工夫ができるハッカーがいるなら、CRubyでもいい
• しかし、RailsもRubyのライブラリも最近はスレッド・セーフになりつつあるので、WebアプリでリクエストをさばくのにJRubyのスレッドを使ったほうが、CRubyでアプリケーションサーバを複数並べるよりも良いのではないか？
• そのメリットとはJVMにシグナルを送れば、すぐにスレッドのダンプを取ったり、パフォーマンス解析ができるツール群があるから。Nginx＋Unicornクラスタでもいいかもしれないけど、監視や分析ツールも自作するんですか？

　というところかと思います。

　JRuby採用の自明な理由について中村さんは述べていませんが、ちょっと付け加えておきます。

　JRuby採用の理由として大きいのは、元々Javaを使っている人々が、より記述力が高くて変更に強いRubyを併用するというケースでしょう。例えばLinkedInのBaq Haidriさんの以下のプレゼンが非常に参考になります。Haidriさんいわく、JVMは素晴らしい、その上、JRubyを採用してSinatraベースの独自DSLによって開発生産性が向上したといいます。LinkedInでは、すでに構築済みの認証モジュールなどはJavaのままで、それらを組み合わせて画面を作るロジックをDSLで書いているそうです。

　さて、CRubyではなくJRubyを使う理由として次に大きそうなのはライブラリです。Ruby／Railsのライブラリの世界も十分に大きいのではないかと私は思うのですが、例えばExcelファイルを読み込んで何らかの処理をする、というときにどの程度「使えるライブラリ」があるのかを比較すると、Javaの世界のほうが有利だということを指摘する人もいます。JRubyではJVM上の資産が使えますし、JRuby1.6からはCRuby向けのCエクステンションすら、インストールコマンド一発でコンパイルしてFFIで呼び出せるようになっていて、両方の世界の資産が使えるので、その意味でもJRubyにメリットがあるということかと思います。

　今のところRailsではCRubyを採用するケースがほとんどでしょうし、その理由はいろいろあると思います。でも、そろそろJRubyの採用事例も増えてくるのかなという気もしていますが、いかがでしょうか。

　そうそう、Rackspaceでは、RubyベースのDSLを使って、ホスティングサービス業務のオートメーションをやっているといいますが、この際、JRubyではなくCRubyを採用したといいます。その理由をRackspace関係者に聞いたのですが、CRubyなら普通のUNIXのプロセスなので、問題があったときに何をすればいいのかよく分かっているし、コミュニティのサポートが分厚いからという回答でした。結局、CやPOSIX、UNIXの世界の住人ならCRubyのほうが馴染みやすいという、ある意味当たり前のことかもしれません。JRubyは起動が遅いので、スクリプティング用途には使いたくないというのもあるかもしれません。

　あ、もう1つ付け加えておきます。Windowsサーバにデプロイする案件というのも世の中には少なくないようですが、この場合、JRubyが手っ取り早いというのも良く聞きます。JRuby guysの1人、チャールズ・ナッターさんは去年、JRubyのサイトにJVMを含むWindows向けバイナリインストーラを用意したら、もう圧倒的なダウンロード数でビックリしたという感想を漏らしていました。

　JavaScriptへコンパイルして実行することを前提としたスクリプト言語「CoffeeScript」がちょっとした注目を集めています。CoffeeScript自体は2009年末に登場し、その1年後の2010年12月にバージョン1.0がリリースされていますが、注目を集めたのは、数日前（2011年4月13日）にRuby on Railsの生みの親であるDHHが、次期バージョンのRails3.1でjQueryやSCSSと合わせて、CoffeeScriptをデフォルトとして採用するとTwitter上で発言して議論が巻き起こったからです。

　Rails3.1の標準とするというGitHub上のコミットに対しては、300を超える大量のコメントが付いていて、賛否両論、いろいろ出ています。2ちゃんのAAに通じる画像コメントも多くあって、ちょっと笑えます。

　茶化し系のコメントはさておき、コメント欄に出ている意見を大雑把にまとめれば、次の2つに集約されるでしょう。

　「CoffeeScriptは素晴らしい。今回の決定に大賛成」という意見と、「CoffeeScriptの良さは認めるけれども、だからといってデフォルトをCoffeeScriptにするのはやり過ぎじゃない？」の2つです。後者の様子見派は、RailsでCoffeeScriptを押し付ければ、JavaScript開発者に対して参入のハードルになると指摘します。

　これに対してDHHは「デフォルトだけど、簡単にオフにできるよ」と念押しした後に、興味深い指摘をしています。

　「男ならJavaScriptを直接書く。JavaScriptのフレームワークが登場したころに、同じことが言われてたのを思い出すね」という意味ですね。ハッシュタグには「argumentrecyclebin」（議論の再利用ゴミ箱）とあって皮肉がきいてます。その心は、jQuery（あるいはPrototype.js、Dojo、MochiKit、YUIなど）なしにJavaScriptを直接書く人が減ったのと同様に、CoffeeScriptも当たり前のように使われるようになるだろうけど、最初は反発が大きいだけだろうということですね。

●JavaScriptの3分の1のコード量にも

　CoffeeScriptはRubyやPythonぽい文法を持った独自言語で、セミコロンやブレースといったや記号類、functionという長い予約語など冗長になりがちなJavaScriptをシンプルにすること目的に設計されています。変数の宣言やオブジェクトのリテラル、イテレータ関連もJavaScriptよりもシンプルです。

　以下のサンプルを拡大して、じっくりご覧ください。

　CoffeeScriptの作者であるJeremy Ashkenas氏は、JavaScriptをバリバリに使ったWebアプリを長らく開発してきた経験から、冗長でストレスの貯まるJavaScriptをシンプルにするCoffeeScriptのような言語を作るというアイデアはずっと持っていたそうです。短かくシンプルに書けてJavaScriptの良い部分だけを利用できるようなものです（Ashkenas氏のインタビュー記事）。

　Ashkenas氏によれば、JavaScriptからCoffeeScriptに移植したあるライブラリは、元の1/3のコード量になったものがあるといいます。また、JavaScriptにある仕様上の欠陥や落とし穴の多くはCoffeeScriptによって避けられるとしています（欠点を知り、それらを避ける方法をまとめた「JavaScript: The Good Parts――「良いパーツ」によるベストプラクティス」という書籍もありますね）。

●CoffeeScriptはライブラリではない

　さて、jQueryやPrototype.jsだけでも、すでにレイヤを1つ重ねているのに、この上にCoffeeScriptを載せるのは屋上屋を架す感じではないかという批判がありそうです。でも、実はCoffeeScriptは2つの点でjQueryなどの「JavaSciptライブラリ」とは異なります。

　1つは、CoffeeScriptはライブラリではなくオーバーヘッドがないということです。コンパイル後はJavaScriptのネイティブコードになります。例えばforeachのようなループの抽象化はPrototype.jsではeachを動的に定義することで実現しています。一方、CoffeeScriptの配列内包表記は、素直なJavaScriptのforループに展開されます。実行時にオーバーヘッドがありません。当然、WebブラウザやほかのライブラリにもCoffeeScriptは見えませんから、競合することもないでしょう。

　JavaScriptにメソッドを追加するUnderscore.jsというライブラリがあります。Ashkenas氏はUnderscore.jsとCoffeeScriptは同じ問題に対する2つの異なるアプローチだといいます。Underscore.jsは足りないメソッドは動的に足してしまうというもので、CoffeeScriptはコンパイラとして実装したということですね。

　さてもう1つ、CoffeeScriptの重要な点。CoffeeScriptは独自言語ではありますが、JavaScriptと必ず1対1に対応させるのが設計ルールだといいます。表面上は別言語っぽく見えますが、背後にあるセマンティクスはJavaScriptそのもの。だから完全に別言語というわけではなく、Ashkenas氏は、「同じテクニックやティップスがほとんどそのまま適用できる」としています。CoffeeScriptの設計はRubyやPythonの影響は受けているものの、背後のあるのはJavaScriptそのものだといいます。

　最終的にコードがJavaScriptになるにしてもコンパイルが間に入ると、開発やデプロイが面倒になりそうです。この点については、Railsであれば、すでにHamlやSassの例があります。それぞれスッキリと短くHTMLやCSSが書ける独自言語（HamlはRubyコードを埋め込めるテンプレート言語）ですが、これらのファイルに更新があればターゲットのHTMLやCSSが再生成されるため、事実上変換のプロセスは意識する必要がありません。CoffeeScriptもこれと同様の扱いにすることはできるでしょう（すでに、Rails3.1でCoffeeScriptを試された方がいます。Willnetさんのedge rails(Rails 3.1)の新機能を調べてみるというエントリが参考になります）

　もう1つ、もっと期待できそうなアプローチとしてAshkenas氏が指摘するのが、CoffeeScriptのような「ソースコードをJavaScriptに変換して利用する言語」（実例リスト）に対するWebブラウザのサポートです。Ruby、Python、Java、Scheme、Haskell、Cなど、ほとんどどんな現存実用言語でもJavaScriptにコンパイルできそうなぐらい、いろんな実装が登場していますが、こうした言語をWebブラウザ上でシームレスに実行するような機能が、FirefoxのJavaScriptエンジンに追加される可能性があるようです。

●Railsはキュレーテッド・フレームワーク

　Ashkenas氏は、JavaScript開発者であれば1、2時間でCoffeeScriptは覚えられるとしていますが、マイナー言語をプロジェクトで採用するのは、学習コスト、コミュニケーションコストを考えると、そう簡単ではないでしょう。Ashkenas氏はDocumentCouldというベンチャー企業でJavaScriptを書いているそうですが、さすがに会社でCoffeeScriptを使うという案は正当化できない、とも言っています。

　ここでDHHの注目発言に戻ります。

　Railsの教義というのは「良いアイデアや技術を推奨する」というもので、AjaxやREST、Atom、テストがそうだった、Railsというのはキュレーションされた技術の詰め合わせだ、ということです。

　Railsはフルスタックのフレームワークなので、いろいろなモジュールについて代替案があり得ます。いろいろな好みや意見があるなかで、Railsコア開発チームはWebアプリ開発のニーズに最も広く応えられるベストな選択の結果を提供するということでしょう。

　CoffeeScriptのデフォルト採用は議論を呼びましたが、その陰に隠れたSCSSを見てみれば、キュレーションの意味が分かります。

　SCSSは、「ベターCSS」と呼ぶべきもので、セレクタが深くネストするようなときに、そのネスト通りの文法で書けるCSSという感じです。変数も使えますし、mixinもあります。例えば角丸や影付きのCSS指定の数行に名前を付けておいて、それをあちこちのdivで1行でインクルードするといったことができます。

SCSSの実例。左のSCSSが右のCSSに変換される

　SCSSは、もともとSassという兄貴分に当たる文法もあるのですが、こちらのほうは弟分のSCSSにお株を奪われた形です。Sassプロジェクトでも、むしろSCSSを標準として推しているように見受けられます。私はSassのほうが好きですが、過激だったのだと思います。Sassはブレースではなく、インデントの数に意味を持たせた独特の文法で、「よりDRY」という意味ではSCSSよりもいいと思います。でも、元のCSSと見かけが違うんですよね。何らかのエディタかIDEでインデントモードを使い分ける開発者なら良いかもしれませんが、そういうことに慣れないデザイナにとってSassはインデント調整地獄だったのかもしれません。インデントを1つ間違えただけで、いきなりWebアプリがクラッシュするSassは嫌われる理由がありそうに思えます。

ブレースや行末のセミコロンを不要として、代わりにインデント数に意味を持たせたSassは、スッキリとしている反面、扱いにくかった？

　Sassを入れずにCSSの自然な拡張に見えるSCSSのほうをRails3.1に入れる、という判断。これこそ、DHHが言うキュレーションなのだと思います。SCSSは素晴らしい。学習や変更のコストに見合うだけの利用メリットがありそうで、お勧めだというわけです。Hamlもインデントを基本とした独自文法で、やはりRails3.1には入りません。Hamlは入らないのかという質問に対してDHHは「それは可能性ないね。ない」と答えています。こうした塩加減もキュレーションということなのでしょう。

●CoffeeScriptはシンタックスシュガーのおもちゃ？

　同様に、CoffeeScriptをRails3に入れるのも、キュレーションの結果だとしたら、「Web開発で使うものとして十分に良い」というシグナルで、そこに違和感を感じた人が多いということなのだと思います。物議を醸しながら新技術を投入して古い技術を切るという点でアップル的なキュレーションとも見ることができますね。本当にRailsはopinionatedな（強い主張を持った）ソフトウェアだと思いますし、その中心にDHHが戻ってきた（Twitter上では激しく議論の応酬をしています）という意味で、なんだかワクワクします。ちなみに、DHHがパートナーを勤める37signalsの未リリース新モバイル向けフレームワーク「cinco」は、Bakcbone.js（JavaScript向けMVCフレームワーク）やCoffeeScriptを含んでいます。

　もう1つ、DHHの発言を引用しましょう。

　CoffeeScriptの対する批判的な意見の多くが、RailsでRubyを採用したときと同じ、「見た目はいい（cute）」「おもちゃ（toy）「文法だけ（just syntax）」であるということです。

　CoffeeScriptは文法だけのおもちゃと思われそうですが、私はAshkenas氏の以下の発言に大変共感しました。

プログラミング言語進化の歴史全体が、人間という読者のニーズにより直接的に応えられるようになるという歴史であり、コンピュータが高速化するにつれて、よりコンピュータに対して非直接的になることだった。われわれは（コンピュータが理解して実行できる）マシン語から、どんどん遠くへ離れることができるようになったのだ。

（かつて1970年代にドナルド・クヌース博士が提唱した）文芸的プログラミングとは、（人間とコンピュータという）二重の読者がいることをハッキリと認め、態度表明したものだ。われわれは人間という読者のニーズにできる限りのことをして応えるのだ、と。

（翻訳と括弧内の注記は西村）

　CoffeeScriptはおもちゃのように見えるかもしれません。しかし実際にはプログラミング言語の歴史観に立ち、確固たるポリシーと設計方針をもってJavaScriptハッカーによって作られた言語であることが分かります。

　CoffeeScriptは、もちろんRailsと関係なく使えますし、Node.jsとの組み合わせでサーバサイドのプログラミングにも使えます、念のため。CoffeeScriptが広く普及するかどうか今後も注目ですが、HamlやSCSS同様に、使いたければ今日から使えるというのがいいですよね。

　Ruby on Railsの生みの親、DHHが在籍する37signalsがMac OS X用のRackサーバ「Pow」をオープンソースで公開しました。ちょっとこれまでにない種類のプロダクトで、その使い勝手のシンプルさとアイデアに鼻血が出そうになりました。実装にNode.jsとCoffeeScriptを使っているというのも面白いです。

　Powの売りは、「Zero-configuration」（設定要らず）ということで、複数のRails/Sinatraアプリをローカルで動かして開発するようなときに、仮想的なドメイン名を手軽に割り当ててアクセスできるようにしてくれる、というものです。インストールはcurlのコマンド一発で、

$ curl get.pow.cx | sh

とするだけ。そして、RailsやSinatraなどのRackアプリのディレクトリをPowのディレクトリにシンボリックリンクを貼るだけです。

$ cd ~/.pow
$ ln -s ~/Projects/myapp

　これだけで、このアプリには「http://myapp.dev」というホスト名でアクセスできるようになります。Rails同様にConvention over Configurationの精神で、ホスト名は「ディレクトリ名.dev」と決め打ちです。Powはインストール時にlaunchd（Mac版のinit、inetdみたいなもの）を使ってファイアウォール設定を書き足していて、「ディレクトリ名.dev」というリクエストが来ると、powディレクトリ下のRackアプリを起動するという仕組みです。1アプリ当たり、最大2ワーカーが起動し、15分間アクセスがないとアプリを終了させます。

　「localhost」の代わりに名前を付けるために、これまでは「/etc/hosts」を手で書き換えたりしていて、これだと複数アプリを開発環境で動かすための設定が煩雑だった、ということです。37signalsは自社のオンラインのサービス群で共通して使う決済アプリなどがあり、開発に当たっては複数アプリを起動する必要があり、この設定が面倒だったということです。

　サブドメインを設定して違うアプリに割り当てたり、アプリのディレクトリトップに「.rvmrc」を書いておいて、異なるバージョンのRuby処理系を使って各アプリを起動したりもできます

　いろいろなアプリを同時並行で開発しているケースなどに便利かもしれませんね。「/etc/hosts」を手でいじるよりも良いアプローチのように思えますから、複数アプリを開発するわけでなくても、Powは使われていくようになるのかも、と思いました。

●CoffeeScriptの実例としての面白さ

　PowはCoffeeScriptで書かれていて、http://pow.cx/docs/を見ると、注釈付きでコードが見られます。CoffeeScriptはJavaScriptにコンパイルすることを前提とした言語で、JavaScriptよりもPythonやRubyに近い感じで書けて、例えばPythonのリスト内包表記のような配列内包表記で、

cubes = (math.cube num for num in list)

のように面倒なループがスッキリ書けたりするようです。このコードは、

cubes = (function() {
  var _i, _len, _results;
  _results = [];
  for (_i = 0, _len = list.length; _i < _len; _i++) {
    num = list[_i];
    _results.push(math.cube(num));
  }
  return _results;
})();
run: cubes

とコンパイルされます。オブジェクトの定義もブレースなしで

math =
  root:   Math.sqrt
  square: square
  cube:   (x) -> x * square x

のように書けば、

math = {
  root: Math.sqrt,
  square: square,
  cube: function(x) {
    return x * square(x);
  }
};

にコンパイルされるといった具合です（このへん、CoffeeScriptの公式サイトからサンプルを持ってきています）。打鍵数が多くて嫌われ者（？）のfunctionも不要で、「->」というのでラムダが書けるのってRubyっぽいですよね

　CoffeeScriptのリアルなコード例が見れるという意味でもPowは面白いなと思います。

　近ごろ話題のNode.jsですが、その理由は以下のようにいくつかあると思います。

1. イベント・ループを使った非同期処理で、同時接続クライアント数が多数となる高負荷時のスケーラビリティに優れる。急増中のNode.js向けライブラリは最初からすべてノンブロッキングであることもポイント。
2. クライアントで使われるJavaScriptと同じ言語でサーバサイドのアプリも作れる。
3. Google Chromeに搭載されるJavaScriptエンジン「V8」はバージョンが上がるたびに高速化していて、V8を利用したNode.jsもそれに伴い高速化している。
4. パッケージライブラリの充実。「時代の変わり目ならオレにも天下が取れるかも！」と思ったかどうか、新しい物好きの人々が、盛大な勢いでライブラリを書きまくっている。
5. シンプルさ。Webサーバとアプリケーションサーバ、処理系がすべて一体。ライブラリをrequireするだけで既存のミドルウェアやCライブラリも使える。
6. Cloud9のような「サーバアプリ＋WebSocket＋ブラウザ」で動くIDEが実用レベルに近付いている。サーバ側なのでオンラインストレージやGitHubのようなレポジトリとダイレクトにつながる上に、CI環境との統合にも期待できる。ローカルマシンのIDEよりもデータセンター上の開発環境のほうが強力になる可能性がある。

　2番をメリットと考える人は現時点では多数派ではないかもしれません。でも、プログラマ全体での学習コストを考えると、「C（POSIX）→C++（GUI）→Java（サーバ）」と進んできた「最もメジャーな言語」の変遷の先にあるものが、「JavaScript（ブラウザ）」である可能性は高いと思います。jQueryのように見た目やイベント処理を頑張るライブラリだけでなく、CoffeeScriptのようなものが普及すれば、ずいぶん状況が変わりそうな気もします。

　さて、本題は1番です。Node.jsやNginx、EventMachine、Twistedなど、イベント駆動モデルを使ったWebサーバが注目されています。スレッドやプロセスをたくさん用意して処理性能をスケールさせるのではなく、リクエストはキューに入れて、ワーカーで処理するというアーキテクチャです。リアルタイム性が高く、WebSocketやCometを使ってストリームとしてデータを吐き出すAPIを実装するようなケースで威力を発揮すると言われています。

コールバックのネスティングでメンテ困難に

　Node.jsの未来は明るいように見えますが、一方で、非同期処理を自然に記述する方法としてコールバックを多様したプログラミングモデルは、別の問題を引き起こすという指摘があります。コールバックが数百もネストし始めたときに増す複雑さにより、コードの見通しやデバッグ、メンテナンスが難しくなると、PostRankのCTO、Ilya Grigorik氏は自分たちの経験に基づいて論じています。PostRankはソーシャルネットワーク上での反応をアグリゲートして数値化するサービスです。収集データをリアルタイムに処理して、そのデータをビジネスパートナーであるメディア企業などにAPI経由で提供するのがビジネスモデルのようです。

　Grigorik氏はPostRankではNode.jsとは違ったアプローチを取ったといいます。それは、Ruby 1.9で取り入れられたFiberを使うことで、実際の処理は非同期で行いつつも、プログラマには従来通りに同期APIのように見えるRack対応のアプリケーションサーバ「Goliath」（ゴリアテ。英語読みならゴライアス）を実装することでした。PostRankは2008年からGoliathの開発をスタートして、現在の実装はバージョン4に当たるそうです。最新バージョンは1年ほど稼働実績を積んで十分な安定性が得られたので、2011年3月8日にGoliathをオープンソースで公開したといいます（ブログ）。Grigorik氏によればRubyのFiberは、スレッドに比べてオーバーヘッドが小さく、メモリ使用量も少なく済むといいます。現時点でGoliathはMRI、JRuby、Rubiniusで動作していて、MRI 1.9.2＋EventMachineが最も性能が良いということです。

　「継続」（コンティニュエーション）はSchemeなどでは広く使われている概念・機能で、「処理の途中の状態」を変数などにバインドしておいて、処理の流れを変えて、再び処理を再開するような使い方ができるようです。RubyのEnumerableもFiberで動いているといいます。継続それ自体は並行処理のためのプリミティブではなく、例外処理や相互再帰など大域ジャンプが必要な制御構造を実装するためのプリミティブというのが私の理解ですが、非同期処理も書きやすいということでしょうか。

【追記】YARV作者のささださんから、Fiberについての私の勘違いをご指摘いただきましたので当該箇所を消しました。詳しくはコメント欄をご覧ください。いい加減な理解で書いてスミマセン……。

　Grigorik氏はInfoQのインタビュー中で、「GoliathはRuby版のNode.jsか？」という質問に対して、基本的に同ジャンルだとしながらも、次のように答えています。

Goliathの3つのメジャーバージョンアップの過程で見出したのは、非同期のコード（RubyであれJavaScriptであれ）をコールバックを使って書いていると、読んだりテストしたりメンテするのが非常に難しいコードベースになってしまうということです。従って、Node.js人気を横目で見つつも、われわれは違うアプローチを取ったのです。すでにあるコードを“解きほぐす”方法を探したのです。“コールバック・スパゲティ”とRubyのエレガントさは、非常におかしな不調和にも思えましたし、正直、PostRankはJavaScriptも大好きなんですが、RubyやRubyの素晴らしいライブラリ、フレームワークを全部捨ててJavaScriptを選ぶ必要があるようには感じませんでしたね。

　コールバック・スパゲティとは具体的にどういうことで、Goliathの場合どうかという解説はコードサンプルとともに、このブログエントリで読めます。

　Node.jsのようなイベントループを基本としたフレームワークが時代の要請応えているのだとしたら、GoliathもRubyコミュニティで一定の支持を得ることになるのかもしれません。ただし、Goliathは高負荷が予想されるリソース公開用APIのエンドポイントなどで使うべきもので、RailsやSinatra、あるいはMongrelやThinといった既存のフレームワークやアプリケーションサーバを代替するようなものではない、ということですから、この意味ではNoSQLと似ていますね。ほとんどのケースでは従来通りの手法を使ったほうがよく、パフォーマンスやスケーラビリティの問題があるなら、NoSQLやイベントループ系のWeb・アプリサーバに目を向けるということでしょうか。

　Ruby on Railsの生みの親、DHH（David Heinemeier Hansson）らが、モバイル向けのフレームワーク「Cinco」（シンコ）を間もなくオープンソースで公開する模様です（思わせぶりなブログエントリ）。以下は、37signalsのCincoを使った最初のモバイルアプリ「Basecamp Mobile」のデモ映像です。

　Cinco自体はまだソースコードが公表されていません。準備が整うまでに数カ月かかるだろと言っています。Cincoはモバイル向けフレームワークで、「基本的には単一ページのJavaScriptアプリを扱うためのRailsだ」と説明されています。対応するプラットフォームは、

• iPhone 3GS
• iPhone 4
• iPad
• Motorola Droid X
• Motorola Droid 2
• Samsung Galaxy S
• HTC Incredible
• HTC Evo
• Palm Pre 2
• BlackBerry Torch

など、WebKitベースのブラウザを搭載するモバイル端末であれば動くよ、ということです。cincoはスペイン語でfiveの意味ですから、5種類の端末というイメージからの命名でしょうか。HTMLシンコということでHTML5を暗示しているのでしょうか。DHHは、eco、stitch、zepto、backbone.jsなどの名前で検索すると何かが出てくるかもね、とつぶやいているので、5つのモジュールからなるフレームワークという意味かもしれません。

●なぜ作ったのか？

　Basecampeは、DHHがパートナーを勤める37signalsのWebアプリの1つで、プロジェクト管理サービスです。今回、これのモバイル版を作るに当たって、フレームワークを作ったということです。

　すでに小規模向けCRMのHighriseというサービスではモバイル版としてiPhoneアプリを出したりもしていますが、ずっとiPhone開発者を雇い続けなければいけないのかという違和感を感じていたといいます。Android版のために、また別に開発者が必要になる？ えーっ、冗談でしょ、という。

　結局、37signalsでの結論は、自分たちがいちばん得意なWeb関連技術でやろう、そうすれば、37signalsの誰であってもコードの読み書きができるし、ワークフローも非常に慣れたもののままでやっていけるから、ということだったそうです。

　スキル習得や開発・維持コスト、プラットフォームの多様化、HTML5＋JavaScriptの成熟スピードのことを考えれば、モバイルアプリの未来のかなり大きな部分がネイティブアプリではなくHTMLアプリにあるというのは自明という気もしますが、37signalsのような会社がハッキリとそれを言って、フレームワークまで作ったというのはインパクトがあると思います。別の注目株として、jQuery Mobileも今日、3つ目のアルファ版を出してきたりしていて、この分野は盛り上がりそうです。

　先日、Sencha Touchも含めて、この辺りのモバイル・フレームワークをiPadやAndroidでまとめて触ってみました。触ってみると分かりますが、ネイティブアプリに比べるとユーザー体験はまだまだ……、というレベルです。ただ、すでに書いたメリット・デメリット、今後の技術の成熟を考えると、「もうモバイルでネイティブは特殊用途向けだけだよね」と誰もが考えるようになるのは時間の問題だと思います。プロセッサもまだ速くなりますし、JavaScriptエンジンだってガンガン最適化が進んでいます。

　DHHは、このへんの事情について、「2011年の今、iOSだけに向けてモバイルWebアプリを作るなんて、2001年の段階でIE4だけに向けてビジネスをWeb対応させるようなもんだ」と言っています。

　ちょっと意味が取りづらい発言ですが、特定の非オープンなOSやプラットフォーム向けに作れば、ほかの端末からアクセスできないという指摘のようです。

●Rails＋JavaScriptという未来

　CincoはサーバサイドはRailsで、クライアント側がJavaScriptのようです。もしかしたら、中島聡さんが1月末に公開した「JavaScript HTMLテンプレートエンジン SNBinder」と同様に、サーバサイドはMVCのモデルだけを担当し、「JSON over HTTP＋RESTful」なアーキテクチャでビューとコントローラはJavaScriptで書くということかもしれません。TwitterなどイケてるWebはそうなっていますし、こういうアーキテクチャは確実に増えているように思います。つまり、そろそろちゃんとしたフレームワークが求められているということではないでしょうか。

　すでに名前が明かされているCincoのモジュールのうち、Ecoはテンプレートエンジン、Stichはコンパイラだと言っています。ん!? コンパイラ？ RubyをJavaScriptにコンパイルするというのはあるかもしれませんか？ しれませんか？

　ここでRubyistでない人からの「だったら最初からJavaScriptで書けよ」という声が聞こえてきそうです。そもそもバックエンドもNode.jsにすれば、JavaScriptだけで終わりじゃんというのも、結構正しそうに思えます。これに対するDHHの反応は、次の通りです。

　つまり、「JavaScriptは良い言語だけれども、Rubyは素晴らしい言語だ。それで話は終わりだよ」ということです。先日のRubyConf2010でDHHは、「なぜRubyなのか？」について、非常にパンチのある感じのトーク（ほかの言語ユーザーや、言語なんてもうあんまり関係ないよねという達観したハッカーをムッとさせそうな感じです）をしているので、興味のある方は、こちらもご覧ください（とても面白いトークなので、近いうちにサマリを記事にしようかと考えています）。

　Rubyで書かれたターミナル用のTwitterクライアントの「termtter」や、MacのGrowlにメッセージを表示するRuby向けライブラリの「g」で知られる@jugyoさんが、Rails Shellという名前で「Rails-sh」をGitHub上に公開しました。文字通り、Rails向けのシェルっぽいもので、rails-shとして立ち上げるとRails環境をメモリに読み込んで、後は

• generate
• console
• server
• dbconsole
• new
• routes

などのサブコマンドが使えます。いちいちRails環境をロードしないので、ビックリするぐらい速いです（Railsの起動がビックリするぐらい遅いという言い方もできますが）。

　上記のコマンドに加えて、

というサブコマンドがあるようです。routes.rbを書き換えて、rails routesrake routesと実行して悶々としている人は悟りが開けるかもしれません。何となくコロンブスの卵っぽいですよね、シェルなのに、そこからさらにconsoleを呼んだって別にいいじゃーん的な富豪っぽさも感じます。これはスゴイ。

　特にJavaScriptやRubyの世界で使われる英語のITジャーゴンとして、最近「Ninja」というのをよく耳にするようになりました。hackerに似て、技術レベルが高いソフトウェアエンジニアのことです。どちらかというと自称する人が多いように思います。

オライリーメディアの新刊の1つ。Novice（初心者）からNinjaへとある

　hackerといえば、CPUのキャッシュラインのインバリデーションをイメージしながら、pthreadでゴリゴリと低レベルのソフトウェアを書き、自分で使う処理系は自分で書く人というイメージがあります（スミマセン、プロセッサ系のジャーゴンを使ってみたかっただけで、何を言ってるか自分でもよく分かっていません）。ninjaのほうは、これに対するカウンター的な言葉のように感じています。JavaScriptが最初に学んだ開発言語という若い層の人たちで、JavaScriptの細かな実装の違いやテクニックを数多く知っていて、ビックリするようなハックを披露したりします。例えば、Livedoor Readerの中の人であるmalaさんは、ninjaっぽいように思います。Webエンジニアの間では非常に有名なのに、あまり外の世界で知られていないという点でも忍者っぽいです。

　最近はjQueryなどの良いライブラリが登場して事情も変わりつつあるのでしょうけど、Webアプリの開発は、JavaScript ninjaがいるのといないのとで、全然最終クオリティが変わってくる、というようなところがあると思います。最近、英語圏の求人広告では、Ruby ninjaだのJavaScript ninjaだのを求めるというものをよく見かけます。

　これまで、JavaScriptはHTMLやCSSと同じでデザイナの領域に近く、サーバ系のエンジニアにとって「やらなきゃいけないけど、まあできれば書きたくないよね」という存在だったのではないでしょうか。私はRuby on Railsの生みの親であるDHH（David Heinemeier Hansson）が、Railsアプリのディレクトリ構成を説明するときに、public以下はHTMLだのJavaScriptだの、デザイナが作るゴミがたくさん突っ込まれる場所だということを言ってるのを聞いて、ちょっと驚いたことがあります。一方、app以下にはモデルやコントローラが入っていて、美しい世界だと（笑）。

　Rails3では、Unobtrusive JavaScript（このブログが参考になります）といって、これまでビューのヘルパーメソッドでJavaScriptをゴニョゴニョッと生成させていたのをやめて、HTMLの各タグの属性と値を使って、JavaScriptによる振る舞いを指定し、これを動的にJavaScriptというかDOMで見ながら実行するという方法に変わっています。HTMLからデザインをCSSという別レイヤに分離したのと同じように、HTMLに混じる振る舞い（JavaScript）を分離するという動きです。ASP.NET MVCの開発者ならmsdnのこのブログが参考になると思います。

　タグの属性活用はHTML5的でもありますよね。ブラウザが未実装のHTML5の機能も、こうしたアプローチならすぐに使い始めることができます。当面はJavaScriptで処理しておき、ブラウザがネイティブでハンドリングできるようになったら、そちらに任せる。このときコードをいじる必要がありません。このアプローチは、「Progressive Enhancement」と呼ばれていて、各ブラウザの実装レベルがチグハグするHTML5時代にふさわしい考え方だと思います。

　ともあれ、JavaScriptは軽んじられてきた歴史があります。サーバサイドJavaScriptの盛り上がりで事情が変わるかもしれませんが、少なくともWebブラウザ側は互換性の問題など頭が痛いこともあって、今も抽象化レイヤの向こう側に追いやられようとしているようにも見えます。ただ、JavaScriptは本当はすでに重要な技術となっていて、高度な技術と幅広い知識を持つ人材が求められているのに、なかなかそういう人が見当たらない。だから、表舞台で活躍しない裏方なのだけどクリティカルな役割を果たすという意味で、JavaScriptハッカー（ほら、違和感ありません？）のことをninjaという言葉で呼ぶのだろうなと想像しています。

　そういえば、英語における日本語語彙の借用には、ときどき驚くものがありますよね。始めて見たとき、かなり驚いたのですが、honcho（班長）というのが、アメリカ英語では結構使われているってご存知ですか？ 発音はホンチョです。日本の組織でいうリーダーに相当する言葉のようで、私は「What if your honcho was an idiot？」（もし自分の上司がマヌケだったらどうする？）という文脈で見つけ、辞書を引いてそれが班長のことだと知って仰天した記憶があります。オーストラリア英語で、「rippa（立派）」というのをgreat job!の意味で使ってると知ったときにも、ひっくり返りそうになりました。そういうのに比べると、ninjaはふつうにメジャーですが、新しいニュアンスを帯びて、Web開発者の間で使われているというのは面白いなと思います。

　Debian GNU/LinuxのRuby関連パッケージのメンテナだったフランス人のLucas Nussbaumさんが、Rubyパッケージの作成・管理に関わるのをやめると宣言しました。その理由を、やや感情的にブログに列挙したことをキッカケに、日本語・英語のコミュニケーションギャップの問題、OS（ディストリビューション）とRubyなどの言語処理系のパッケージシステムの不調和の問題、コミュニティ運営の成熟度など、さまざまな議論が巻き起こっています。

多くの論点を含みつつ議論が展開

　念のために先に指摘しますが、Debian上（Ubuntuでも同様）のRubyパッケージの今後については、Lucasさんのほかに、まだ2人、やまだあきらさんと、森脇大悟さんが関わっているので（リンク）、今回の騒動によってRubyパッケージがDebian上でメンテナンスされなくなったり、将来が不安だということはないと思います。ただ、多くのOSSプロジェクト同様に人的リソース不足のようで、Lucasさんも、特にRuby関連のライブラリやRubyベースのアプリケーションのパッケージについては、「先のことは分からない」と言っています。と、書いたところで、やまだあきらさんがブログにコメントを書かれているのに気付きました。状況把握中だそうですが、メンテナを続ける意思があるとのことです。

　さて、一連の騒ぎの発端はLucasさんの1月2日付けのブログ、「Giving up on Ruby packaging」と題したエントリです。

　コメント欄には、Rubyの生みの親のまつもとさんがコメントしているほか、Ruby 1.9系のリリースマネージャーであるYuguiさんも登場し、1月4日のお昼現在（日本時間）もまだ少しずつ議論やコメントが続いています。LucasさんはRubyGemsの抱える問題についても指摘しているため、RubyGemsの初期の開発者であるPaul Brannanさんもコメント欄に登場しています。

　関連する議論を追いたい方は、まずLucasさんのブログとコメント欄を読んで、次にまつもとさんのTLを見て、LinuxカーネルとRuby双方の開発者としても知られている小崎資広さんとのやり取りあたりにも注目しつつ、各方面からの発言を拾うと良いと思います。関連する論点が集まっているのは、Hacker Newsのこのスレッドです。RubyGems開発の経緯や、現状の問題点については、ミュンヘンのRuby User Groupで昨年10月にRoland Morizさんが発表した（と思われる）「RubyGems - behind the gems」というスライドが参考になります。

何が問題だったのか

　Lucasさんの論点を、ブログの登場順に列挙してみます。

1. Ruby開発コミュニティは成熟すべきだ
2. 日本語のメーリングリスト、ruby-devは閉鎖して、開発に関する議論はすべてruby-coreで英語でやるべきだ
3. Ruby開発コミュニティは、ブランチ（異なるバージョン）ごとの状況やリリース予定について理解を共有すべきだ
4. Rubyは単に1つの処理系だけの話ではない
5. Rubyコミュニティは、RVMやRubyGemsが万人向けツールでないことを認めるべきだ
6. Rubyコミュニティの何人かはクソのような振る舞いをやめろ

　思うに、Lucasさんがもう辞めたと宣言した理由は6が大きそうです。ボランティアでやっているのに、口さがなく文句を言うヤツが多くてウンザリした、というのが一番大きいのではないでしょうか。これについては、まつもとさんも、

残念に思う。私も過去15年にわたって、trollsにはウンザリさせられてきた

とブログに共感を示すコメントをしています。a trollは日本語で言えば「釣り」に似て、掲示板やMLなどで、わざと挑発的なことを述べてかまってもらいたがる人々のことです。まつもとさんが言うと、説得力がありますね。

　Lucasさんは、この点について、オンラインコミュニティで攻撃的な言動を示す人々というのは少数派かもしれないが、時々は声を大にして反論しないと、コミュニティ全体のイメージダウンにつながるとも言っています。

Debianのパッケージは古い？

　さて、ではLucasさんが受けた悪口（trolling）の中身はなんだったかというと、5なのだと思います。つまり、Ruby on Rails開発者の多くはRVMやRubyGemsを使っていて、プラットフォーム固有のパッケージシステム（yumやapt-get）のことを軽視する傾向が強まっているのだと思います。「DebianのRubyパッケージなんて使えない」という風に言う人がRubyコミュニティに少なからずいるのでしょう。実際、Debianに限らずOS付属のRubyパッケージはバージョンが古いものが多いように思います。

　「DebianのRubyパッケージは古い」と言われて、「おいおい！ ちょっと待ってくれよ！ 1.8系はちゃんと新しいものを出してるだろ！ そもそも……」という指摘が3番の「Ruby開発コミュニティは、ブランチ（異なるバージョン）ごとの状況やリリース予定について理解を共有すべきだ」なのではないでしょうか。昨年10月に出たDebianの安定版リリース、lennyに含まれるCRubyのバージョンは、

• Ruby 1.9.0.2
• Ruby 1.8.7.72

となっています。Ruby 1.9系の初の安定版であるバージョン1.9.1は2009年1月にリリースされていて、2010年8月にはRuby 1.9.2も出ています。ところが、DebianのRubyパッケージの1.9系の説明には「開発版」だと入っていて、バージョンも1.9.0と古いままです。RubyやRailsを気にかけている開発者の多くはすでにRuby 1.9系に移行しているか、少なくとも動かしてはいるのではないでしょうか。こういう利用者層からすれば、DebianのRubyパッケージは古く見えてしまいます。

　でも、実際のところ1.9系は「安定版」「開発版」の、どちらなのでしょう？ もし安定版だとしたら1.8.7って何？ 1.8.8もあるの？ というのが、Lucasさんが釈然としなかったポイントでしょう。この点について、まつもとさんは、

ご存知のように1.9は大きな飛躍だったので、1.8についてもより長期間維持する必要があったのです

とコメントしています。事実上、現在CRubyには

• 1.8.7（後方互換のためのバージョン）
• 1.9.2（安定版）
• trunk（開発版）

という3つのバージョンがあるのだということです。

今に始まった問題ではない

　外部から観察している私の目にも、Rubyのブランチに関するポリシーは、その場その場の空気で決まるもののように見えます。RubyKaigi2010の開発者会議で私は、1.8.8を出すのかどうかという議論を傍観していました。まず第一に、それを決めるプロセスや、何がどうなったら決まったことになるのかというのが、私には分かりません。日本的な緩やかな合意形成のように見えています。たぶん、IRCやオフラインでの雑談の中でも議論は成熟していくのでしょう。それはそれでいいのでしょうけど、Lucasさんが1や2の論点を指摘する気持ちも分かる気がします。このあたり、Rubyコミッタの1人である卜部昌平さんが去年の9月に「Rubyがそろそろ一回終わってみるべき10の理由」というtumblrのエントリで指摘されています。

　（日本語と英語という）言語の壁を超えられなかったという指摘と、ガバナンスの不在について、私は卜部さんの見立てが正鵠を射ていると思います。いずれも今回初めて指摘されたようなことではないと思いますが。

　Lucasさんの2つ目の指摘、「日本語のメーリングリスト、ruby-devは閉鎖して、開発に関する議論はすべてruby-coreで英語でやるべきだ」という点についてですが、まつもとさんは次のように反論しています。

Rubyのコア開発者のほとんどが英語を理解しますし、英語主体のruby-coreメーリングリストにも登場しています。すべてのドキュメント、ChangeLogが英語だし、英語を話す開発者が自分は二級市民だなどと思うことはありません。

　これ以上まつもとさんや日本のRubyコア開発者に対して歩み寄れというのは、筋違いの要求かもしれませんが、Lucasさんの指摘ももっともかなと思います。日本語と英語の壁はとても分厚い、という厳しい現実があるだけなのでしょう。

　Yuguiさんは日本語によるruby-devを閉鎖するメリットには同意するものの、そんなことをすれば、多くの日本人開発者によるライブラリやプラットフォームサポートを失うことになるだろうと現実的な問題点をコメントとして投稿しています。そして、それは鶏と卵の問題かもしれないとも指摘しています。日本語の開発メーリングリストを廃止して英語主体にビッグバン移行しても、ちゃんと開発体制は回っていくのかもしれない、という意味かと思います。

ガバナンス不在のほうがコミュニティは活発かもしれない

　ガバナンスというのは、例えばJavaならJCPがあり、PythonならPEPがあり、という話だと思います。この論点は「Rubyはどこへいくのだろう」というブログでも触れられています。

　ガバナンスとは明文化されたルールに基づいて議論や決定を運用するということですよね。私には、Rubyの開発が自然言語的にも、コミュニティの態度としても閉鎖的とは思いません。むしろ非常にオープンだし、日本発のプロジェクトとしてはほかに類をみないぐらいに英語を使っていて、そういう意味では活動がグローバルです。でも、外部からもそういう風に思われているでしょうか？

　明文化されたルールを作って、外部にも内部にも明示した上で「私たち」を形作っていくのだ、ということの価値に対する認識に、日本と西洋とでギャップがあるのかなと感じます。日本には文化はあっても文明がないと言った歴史学者の阿部謹也のような人の指摘が私には思い出されます。文明とは、異なる文化的バックグラウンドを持つ人々を対等に受け入れることで、そのための枠組みです。この意味では、日本にはまだ文明的でない面が非常に強く残っていると私は思っていて、Ruby開発コミュニティ問題も、これに通底しているように思えます。

　まつもとさんは、この辺のことについて、こうつぶやいてます。

改めて「ルール」と言われて感じたのは、そんなの決めようとする人はOSS(とコミュニティ)の本質を理解してない。そんなの決めたら、楽しくないじゃん。

　なるほどなぁと思います。Debianは1997年と早い段階から、「Debian社会契約」という一種の憲章を掲げていましたし、リーダー選出などのプロセスも非常に明文化した形で、投票システムが作られていると聞いています。

　追記：私の目は節穴でした。Debianには、ちゃんと日本語にも翻訳されたDebian憲章というものがあったのでした。この機会に一読しましょう！（読んでなかったのに偉そうにスミマセン）

　そんなことだからDebianはUbuntuの後塵を拝することになったのだ、という言い方はできるかもしれません。Debianプロジェクトの創始者で、DebIANと名前にも入っているIan Murdockさんが、Debianプロジェクトは民主的になり過ぎた、それが常態化したリリースの遅延の根本にあると指摘していたのを思い出します。

　まつもとさんも、小崎さんとのTwitter上でのやり取りで、

kosaki55tea kosaki @yukihiro_matz ええと、Debianはわりときっちりルール決めてると思いますよ。ただ僕の意見はそれは中の人間が決めた時のみに有効に機能すると思っているので反対なのですが ﾟ+.(･ω･)ﾟ+.ﾟ

Yukihiro Matsumoto @kosaki55tea だからDebianは(比較的)停滞してるのでは？ とか言ってみる。Debian好きだけど。

と指摘しています。JavaもJCPによって活動が活発になったかというと、むしろ逆に停滞したようにも思われます。それが成熟なのだという見方はもちろんできると思います。

　もう1つ、小崎さんが面白い指摘をされています。

kosaki55tea オレに言わせると日本語MLを閉鎖して議論を英語にしたぐらいで、コミュニティが「成熟」して意志決定の過程が透明化されると考えてしまうナイーブさには失笑を禁じ得ないのだが。LKMLを半年ROMってから出直すべき ﾟ+.(･ω･)ﾟ+.ﾟ

　Linuxカーネルが、活発で成功している開発コミュニティであるのは疑いようがありません。そのLinuxカーネルの開発コミュニティも、英語を主言語としているからといって、コミュニティが成熟していたり意思決定の過程が透明化されているわけではない、という意味かと思います。結局のところ、（国や会社と違って）OSSプロジェクトぐらいのサイズであれば、大事なのは明文化されたルールよりも、その場に関わる人間全体の人間臭い関係性を、当事者やトップが上手くまとめたり、まとめなかったりすることにあるのかもしれません。

　もう1つ、今回の騒動で重要な見方として、ここで付け加えておかないといけないと思うのは、LucasさんがRubyに対してあまり前のめりでなかっただけではないかという指摘があることです。RubyConfに参加したわけでも、まつもとさんの意見を聞こうとしたわけでもないという指摘です。これはLucasさんも認めていますね。

　追記：前のめりかどうかという論点については、Slashdot上のnaruseさんのコメントが参考になると思います。

パッケージ管理のインピーダンスミスマッチ

　RubyもRailsも進化が速く、RVMやRubyGemsといったツール類の消長も激しいです。そういう、ちょっとした混沌の中で進化を続けているホットな世界と、安定していてセキュアなコンピューティング環境を提供するべきディストリビューションとでは、自ずとポリシーやアプローチが異なってくる、ということかもしれません。

　Lucasさんの「Rubyコミュニティは、RVMやRubyGemsが万人向けツールでないことを認めるべきだ」という論点について、まつもとさんは、

RVM and gems. Conflict between packaging system for the language, and general purpose packaging system like Debian is common problem; Perl has CPAN, PHP has PEAR and Ruby has RubyGems. I am not yet sure there’s good solution for it. Probably we can work together.

とコメントしています。Rubyに限らず、PerlのCPAN、PHPのPEARのように、汎用パッケージシステムと、言語ごとのパッケージシステムが異なるのはよくある問題だと指摘した上で、じゃあほかに良い解決があるかというとよく分からないねと言っています。not yet sureとやんわりと言うあたりがまつもとさんの優しい独裁者としての真骨頂だと思います。文句があるなら代案を出せとか、ほかにやりようなんてないんだよッと顔を真っ赤にして反論するようでは、15年もRubyの開発は続いていなかったのではないかという気がします。まつもとさんは、Debianのようなパッケージシステムと言語ごとのパッケージシステムの開発者は、協力することで一緒にこの問題を解決していけるかもしれないよね、と前向きです。

　Lucasさんは「車輪の再発明をするな」と、RubyGemsに対してちょっと否定的です。もちろん、それが良いツールであり、ある種の人々には良い選択であるだろうと認めた上で、RVMやRubyGemsが万人向けツールであるかのように言う人々は笑止千万だと指摘しています。

　これはRuby on RailsにWordPressのような大ヒットアプリケーションなぜ存在しないか、というのに似た問題かなと思います。WordPressなどPHPの優れたツールが普及した理由は、システム管理者が簡単に導入、運用できたからでしょう。一方、Railsはどうでしょう。Ruby on Railsのイシュー・トラッキングシステムであるRedmineを入れて動かすために、一般的なシステム管理者にRVMやRubyGemsを使えというのは酷です。「apt-get install redmine」とやってパッケージが入って動き出すなら、それがベストですが、そういう感じではありませんよね。

　Railsなら15分でブログシステムを「作れる」のだと喧伝はしていますが、3分で立ち上げられるRailsベースのブログって、ちょっと思いつきません。それは、自分で作るものだからなのでしょう。

　RVM、RubyGems問題というのは「システム管理者というパッケージ利用者」と「Rails開発者」の間にあるギャップに、Rubyコミュニティはあまり自覚がないのではないかという指摘なのかなと思います。

車輪の再発明は必要不可欠？

　Rubyライブラリの次世代管理システム「Bundler」は、文字通り車輪の再発明です。多数のパッケージのバージョンの依存関係を解決するのは、実は計算量的に難しい問題で、組み合わせの数が膨大なために、高速なCPUを使っても、なかなか最適解が出せないのだそうです。Bundlerの開発者の1人、Carl LercheさんがRubyKaigi2010で講演されていましたが、実はBundlerはapt-getのアルゴリズムを真似たのだそうです。先に確定できるメジャーなパッケージの組み合わせを確定することで組み合わせ数を大幅に削減している、ということです。本当の意味で車輪を再発明していたのです。

　車輪の再発明は無駄かというと、そんなことはなく、まず、RVMについては解こうとしている問題が違うので比較はできません。RVMは異なるバージョンや実装のRuby処理系を同居させたり、gemsetsという機能により実験的にgem環境を切り替えたりできるツールです。これはOSディストリビューションのパッケージシステムでは解決できない問題です。

　もう1つ、gemは古いバージョンのものも明示的に消さない限り残ります。これは依存関係を解決する上での必要悪だったのでしょうか、私にはちょっと事情が分かりません。Debianにはalternativeというメタパッケージの仕組みがあって、これで複数バージョンのライブラリの共存ができそうに思えます。でも、やっぱり目的が違うのですね。例えば、あるソフトウェアパッケージが「MTA」に依存しているという場合、Debian上ではPostfixもSendmailもMTAの機能を満たすパッケージとして一方を入れれば依存関係を満たしているとみなされます。これは25番ポートを叩けば同じSMTPをしゃべるので、当然といえば当然です。とても賢い仕組みです。しかし一方、Rubyのgemだと、例えばTwitterクライアントの実装を取ってみてもAPIはどれも違いますし、同一gemでもバージョン間で互換性がなくなったりするのは普通です。

　こうした事情を考えると、cpan2rpmやgem2debといった言語ライブラリのパッケージをOSパッケージに変換するアプローチには限界があるのかなと想像します。

　データベースとオブジェクト指向言語の「インピーダンスミスマッチ」に似た話で、言語ライブラリと、OS上にインストールするライブラリにはミスマッチがあるのかなと思えます。進化速度やAPIの安定性、パッケージ間の依存関係の性質がだいぶ違います。

　さらに、マルチプラットフォームということを考えると、Debianのパッケージで上手くRuby関連のものがパッケージされていることよりも、WindowsでもMacでもLinuxでも、gemさえ動けばほぼ同じものが使えるという状況のほうが、Ruby／Rails開発者にはメリットが大きいという指摘もあります。Mac上で開発したRailsアプリであってもDebian上に持って行って「bundle install」と実行すれば、必要なライブラリがインストールされて、それで問題なく動くというのは大きなメリットですよね。

　という事情があるので、Debianで「gem update –system」を実行したときに出る「RubyGemsではなく、apt-getを使え」という以下のようなメッセージは、多くのRails開発者をがっかりさせたのかなと思います。

ERROR: While executing gem ... (RuntimeError) gem update --system is disabled on Debian. RubyGems can be updated using the official Debian repositories by aptitude or apt-get.

RubyGemsはプロトタイプだった。今後の発展に期待？

　RubyGemsはエコシステムの規模の割に、不思議なほど実装や運用が原始的だと思ったことがありませんか？ セキュリティにしても、ほとんど誰でもアップロードしてgemを公開できるのに、いきなりroot権限でインストールしていることがあるなど、チキチキマシーン的です（大げさ）。

　それもそのはず、私は今回の件で初めて知ったのですが、Paul Brannanさんによれば、RubyGemsは、もともと2時間程度で実装したプロトタイプだったそうです。今のように広く使われるようになるとは想像できなかったといいます。そういうわけで、LFS（Linuxの標準ディレクトリ構成を決める仕様）に準拠しない形で、単一ディレクトリにすべての関連ファイルを入るようなgemの導入方式も、プロトタイピングという意味では、ごく自然なデザインチョイスだったということです。

　上記で紹介したスライドによれば、RubyGemsにはミラーが1つもなく（GitHubはありますが）、Amazon S3上にだけバイナリがあるそうです。これはDebianのようにミラーが何百もあるプロジェクトとは好対照で、PerlのCPANともずいぶん違います。GitHubと同様に、SPOF（Single Point of Failure）になっているということですね。これは多くのミラーサイトがrsyncを使っている一方、S3だと同じやり方ができないからという理由が大きいそうです。

　こうした状況も、開発者のニーズと、より良い実装やサービスの登場によって、今後もダイナミックに変化していくのだろうと思います。そういう動きが出てくるのが、Ruby／Railsの活力であり面白さなのかなと個人的には思っています。そういうスピード感に、一時的にDebianのようなシステムがキャッチアップできていない（主に人的リソース不足により）のが、今回のような形で表面化したのかなという風にも思われます。

　Node.jsが使っているのと同じイベントループ・ライブラリ「libev」を活用し、Sinatra風のDSLが使えるRuby向けフレームワーク「Cool.io」のバージョン1.0が12月14日に登場しました（GitHubのレポジトリ）。

　Cool.ioの開発自体は2007年12月に始まったRevという前身プロジェクトまでさかのぼります。途中で名称変更をしたんですね。「Cool I/O」ということでI/Oバウンドなサーバ処理に「いい感じ」という風にも取れますし、Coolioというアメリカ人のラッパーの名前にも通じていて、ちょっとRubyっぽい響き（Javaなどに比べてやんちゃ）で、良いネーミングだと思います。

追記：Cool.ioはRevとは別プロジェクトでした。このコミットログをちらっと見て誤解しました。訂正してお詫びします。

　イベントハンドラを登録しておいて処理を継続し、実際にイベントが発生したときにコールバックで何らかの処理をする、というのはシングルスレッドでマウスやウィンドウオブジェクトを扱うクライアントサイドJavaScriptはごく普通のことでした。Webサーバでもこれと同様にイベント駆動にすることで、ロックが発生したり、ムダにプロセスやスレッドを生成しなくても多量の同時アクセスをさばける。それがイベントループを活用したNode.jsなどのフレームワーク。というのが私の理解で、最近の注目トレンドの1つですよね。特にリアルタイム性の高い、つなぎっぱなし系プロトコルのComet（プロトコルではなくハックでしょうけど）やWebSocketでは、自然な実装という気がします（WebSocketの解説記事）。

　WebSocketの登場で一気に注目を浴びた感もあるイベントループ系の実装ですが、RubyだとEventMachineというのがありました。Cool.ioは、EventMachine同様のことが、今風のDSLで書けるのが嬉しい、ということでしょうか。サンプルコードは以下の通り。

require 'rubygems'
require 'cool.io'
ADDR = '127.0.0.1'
PORT = 4321
cool.io.server ADDR, PORT do
  on_connect do
    puts "#{remote_addr}:#{remote_port} connected"
  end
  on_close do
    puts "#{remote_addr}:#{remote_port} disconnected"
  end
  on_read do |data|
    write data
  end
end
puts "Echo server listening on #{ADDR}:#{PORT}"
cool.io.run

　Sinatraのような衝撃には欠けますが、イベントループ系としてはちょっと要注目なのかもしれません。

　先日、salesforce.comによる買収が発表となったRuby on RailsホスティングサービスのHeroku向けの「Hero Scale」（恐らくヒーロー・スケールと読むのでしょう）というオートスケーリングのサービスが始まったようです。私は日本のHerokuユーザー会のおぐらじゅんやさんのメールで知りました。

　一瞬、Scala（スカラ）かと空目しましたが違います、スケールです。そういえば、Python版のHerokuが登場したり、node.js系のホスティングは雨後の筍のように増えているのに、Scalaってありましたっけ？ まあ、JVM語族はGoogle App Engineが使えるので、それでいいということかもしれません。GAEの次期バージョンアップではScalaやClojureが一斉に正式サポートになるという噂がありますね。すでにGAE上でClojureを動かしている人はたくさんいて、例えばBigTable向けにDSLをClojureで書いてWebアプリを作ったという話なんかは気になるところです。今はどの言語もクラウドにどう乗るかという競争が一斉に起こっていて、Ruby on RailsではEngine YardやHerokuが注目ですね。JVM系はVMwareとかGoogle、そしてそれ以外はAWSに乗せる形で出てきている、というところでしょうか。

　さて、そのHerokuですが、もともとWebサーバとしてリクエストをさばく「Dyno」と、クエリを処理する「Worker」を増やしたり減らしたりすることはできました。3つ方法があって、1つはWebページのスライダーバーでやる方法、もう1つはコマンドラインツール、そして当然のようにAPIも用意されています。スライダーバーで、ぐりっと増やせば、それでスケールするという手軽さです（私は1 Dyno/1 Workerしか使ったことがありませんが）。

　Dyno/Workerを増減するAPIがあるので、自分でオートスケーリング機能を作ることは可能でしょうけど、適当にやってくれるなら、それはそのほうが楽でいいよねということだと思います。

　PaaS上では分業がどんどん進みますね。HerokuはPostgreSQLを使っていますが、PostgreSQLの細かな知識がなくても、スライダーバーでスケールできてしまうという意味で、DBが得意なエンジニアを仲間に入れるより、もはやネット上でAPIベースで協業しようぜ、というのが今の動きなのだと思います。最近、自分でやってみてイヤというほど分かりましたが、MySQL1つ取ってみても、MyISAMとInnoDBはどう違うのか、InnoDBのバックアップって「とめてー、吐いてー、また吸う」みたいにライト・ロックをかける単純な方式じゃだめなんですね。「え、バイナリ向けバックアップソリューションは有料2000ドル？ じゃdumpでやるのかマジ勘弁……。え、漢ならLVM？」というように、そういうのを調べて設定するだけで2時間でも3時間でも時間がかかってしまいます。「Webアプリ作って公開したいだけなんだけどな……」という人にとって、DBなんて14万8000光年彼方のORM星雲まで抽象化してくれたほうが嬉しいのです。Herokuえらい！ git push heroku rocks！

　あ、言い過ぎました。抽象化には漏れが常にあるので、分かっておくべきことは、ちゃんと分かってないとダメですよね、ええ、ええ。

　さて、脇道にそれました。Hero Scaleは、Herokuと同じで、一番下の料金コースだとタダ！ イケてますねぇ。60分間隔で監視して最大3Dynoまで増減してくれます。Webアクセスは一時的に多くなるかもしれないけど、クエリは重たくないという静的な性質が高いWebサイトなら、これでいけちゃうのかもしれません。以下、料金表です。今はキャンペーン期間で上位コースがすべて20ドルのようですね。

　ところで、Herokuといい、その周辺の奴らといい、Webページデザインはよくできてるけど、登場キャラやサービスのネーミングが子どもっぽいですね……。Super Awesomeってなんだよって気もします。まあ、だからと言って、エンタープライジーなネーミングなら信用できるかっていうと、もうそんな時代じゃないと思いますけどね。

　それにしても料金体系がうまいですよね。だって、Dyno数の上限なんて恣意的で、サービスの開発難易度や負荷とか関係ないですよね、本来。API叩くときの数字が違うだけで……。でも、そこがビジネスマインドです。取れるところから取る。まったく正しいと思います。

　それにしてもすごいですね、Heroku自体がAmazon EC2/S3を使ったクラウド上のPaaSというエコシステムの広がりを作っていると思っていたのですが、いまやHerokuの周辺に非常に多くのサービスが集まり、生まれつつあります。KVSやNoSQL系のストレージ実装も、もはやサービスとしてくっつけて利用する時代がそこまで来てるのかもしれません。ここら辺は、TIS/SonicGardenでyouRoomを開発・運用されている松村章弘さんの講演「Rails Add-onsで楽々開発 - youRoomを題材に」（動画、スライド）が参考になるかもしれません。

　cronやcaptcha、全文検索エンジンみたいなOSレベルやCライブラリでやっていたことも、今やWebサービスでありますよね。そうなるとサービス間の連携というかネットワーク帯域、遅延が重要になってきて、ますますAWSの力が強まっていきそうです。12月にもAmazonクラウドが日本でスタートするという話でしたが、はっきり言って、こういうのが全部一斉に東京に来たら大激震ですよね。AWSがすごいのは、EC2とか仮想インスタンスのことではなく、こういうエコシステムのことですからね。

　そういえば、salesforce.comのHeroku買収に対して、DHH（Railsの生みの親です、念のため）はちょっと冷めていて、様子見だねということを言っていますね。

　こんにちは、＠IT編集部の西村です。

　RailsDevCon2010の講演動画が一気に公開されました（リンク）。記事のレポートはこちら。

　一番の注目は、ドリコムの大仲能史さんが行った、「とあるソーシャルアプリの開発運用」（講演資料）だと思います。Railsで大規模にスケールするアプリを作る、というのはRailsという文脈でも、Web開発という文脈でも興味深いものがあります。

　さて、その大仲さんにソーシャルゲームについて大変興味深い話をいくつもお聞きしました。私は（恐らく、これを読んでるガジェット系、IT系な人も？）、iPhoneやAndroid、iPad、Kindleは次々と買っていますが、今さらガラケーを2年契約しようという気にはどうしてもなれず、ソーシャルゲームについても、mixiで少し遊んだことがある程度で全然状況が見えていません。そんなにソーシャルアプリが話題なんだったら、ぜひとも遊んでみたいとはいつも思うのですが……。

　お話を聞いたのはRailsDevCon終了後に開かれた非公式懇親会でのことで、以下の話は大仲さんの許可をいただいて掲載しています。

　現在、ソーシャルゲームの開発・運用でビジネスをしている大仲さんですが、大学時代にはあまりにもオンラインゲームが好き過ぎて、学業がおろそかになる（もう少し正確に書くと、学業が続けられなくなる……）ほどだったそうです。大仲さんの大学当時にはCGIを使ったゲームが多く、ブラウザをリロードすることで、ゲーム内の最新状況を知るシステムだったそうです。なので、コンビニに行く時間すら惜しいほどリロードを繰り返し、ゲーム仲間たちの動向に遅れまいとするのが常だったといいます。完全な中毒ですね。

　そして、そういうオンラインゲーム好きは今でも変わらず、常時20個程度のゲームをしているそうです。その大仲さんが、リアルでコアなソーシャルゲームファンとして、またソーシャルゲームを提供する開発者、ビジネスマンとして、以下のようなことを教えてくれました。

• モバゲー、GREE、mixiには、それぞれ微妙に同期しているゲームの「はやり廃り」がある。探検系ゲームが流行しているときに、戦闘系ゲームや育て系ゲームを出しても、見向きもされない。後に振り返ると大ヒットとなったタイトルであっても、タイミングが違っていれば売れなかっただろう。そういうトレンドの読みも、ソーシャルゲーム市場でゲームを提供していく醍醐味。

• ソーシャルゲームは、知り合いの間で次々と「乗り換える」ものなので、自分だけ、いつまでも流れに遅れているわけにもいかない。どのゲームで遊ぶかは、ソーシャルな文脈で決まる（当たり前ですね）。

• 携帯課金上限額が月初でリセットされる。また、ユーザーの意識は「月の支払い金額」にあるため、月初は課金アイテムがすごい勢いで売れる。このため、アプリ運営側はそれに合わせて毎月必ずイベントを入れたり、前月の下旬からイベント予告を出したりしている。

• mixiにはだいたい1万人程度の熱心なソーシャルアプリのウオッチャーがいる。この人たちは新リリースのゲームを試し、もし気にいれば1人のウオッチャー辺り、20～30人にゲームが伝播するので、この1万人に認めてもらえるかどうかが、最初のカギ。うまくいくと、リリース後2、3週間で30万ユーザーということにもなる。

• 自分たちで開発・リリースしたゲームでも、数日やってみれば、はやるかどうかが分かる。自分がすぐにアクセスしなくなるゲームは、やっぱりはやらない。

• 「今やオレの方が都会に出て高給取りで成功しているのに、なんで地元で冴えなかったアイツがゲームではレベルが上なんだ！ 納得イカン！」というサモシイ競争心によって、可処分所得の多い大人たちは“お金で時間を買う”。つまり、アイテムを大人買いすることによって、無理に周囲のゲームレベルに追随しようとする。
  

　こういうのは、リアルなソーシャルゲームユーザーには常識の範疇なのでしょうが、ソーシャルゲームをほとんどやっていない私には新鮮でした。それにしても楽しそうですね。こういう話を聞くと、ますますソーシャルゲームをやってみたくなるわけですが、うーん、2年契約なぁ……。スマートフォン対応が進行中なので、それを待つ方がいいのかなと思ったりしています。