0040 号 巻頭言
なぜそんなにも（Rails アプリ開発者にとって）mruby は重要なのか
Rubyist Magazine 第 40 号をお届けする。
今号は、 咳さんの書かれたコードを、須藤さんが「咳さんらしさ」を丁寧に読み取りながら添削していく Ruby コードの感想戦 【第 1 回】 WikiR、 前鼻さんが札幌 Ruby 会議 2012での（すごい規模の）レポート班のすべてを記した レポートチーム史上最大の作戦、 そして各所での地域 Ruby 会議レポートとして RegionalRubyKaigi レポート (30) 岡山 Ruby 会議 01、 RegionalRubyKaigi レポート (31) 松江 Ruby 会議 04、 RegionalRubyKaigi レポート (32) 札幌 Ruby 会議 2012 と、地域 Ruby 会議中心のコンテンツとなった。
本稿の表題について、「Rails アプリ開発者にとって」と言ってしまうと 無駄にターゲットが狭いようだが、もちろん Rails 開発者に限った内容ではなく、 Ruby の好きな Web アプリケーション開発者、くらいに読み替えていただいても構わない。 さらに Rails を触ったことのない人にも、mruby のポジショニングとその将来性について 考えていただければと思う。
なお、最初に断っておくと、まつもとさんや九州福岡方面、あるいは軽量 Ruby フォーラム等々の方々には、 それぞれ様々な考え方があるとは思っている。そういった方々とはほとんど意見のすり合わせを していないので、これは実際の mruby の設計・開発方針とは全く関係がない、外野から見た視点でしかない。 が、現実の様々なしがらみを抱えつつ、具体的な課題の設定とその解決を行わなければならない mruby 関係者の方とは異なり、 てきとーなことを吹いてもさほど支障がない立場だからこそ書けることもあるだろう。 Web アプリ屋さんから見た mruby、というかなり珍しい一意見としてご笑覧いただければ幸いである。
周知のように Ruby on Rails は Web アプリケーション開発におけるフレームワークとして、 2000 年代後半の Web アプリ開発を考える上で最重要とも言えるソフトウェアとなった。 2000 年代半ばの Web 開発は Struts 全盛の時代であり、 一方で Struts の欠点を克服するべく他のフレームワークも多数生み出され、 「Struts の次」あるいは「次の Struts」に位置する「第 2 のフレームワーク」がどうなるのか、 開発と議論が盛んに行われていた。 まさか(日本を除いて)誰も知らないスクリプト言語でしかなかった Ruby によるフレームワークがその位置に立ち、 いわゆる「Web 2.0」ムーブメントの興隆とともに世界的に広まることになるとは誰も想像していなかっただろう。
さて、では、現在 Rails はどのような位置にあるのか。
やや贔屓目かも知れないが、Struts、そして Rails を超えるほど大きく Web 開発を変える Webアプリケーションフレームワークはまだ現れていないのではないか。その意味では、 Rails は今現在でも現役で Web アプリ開発を主導する位置に立ち続けている。 それはとても素晴らしいことだ。
ただ、Rails が今でもトップである、というのは単純に喜べる話ではない。 それは、Rails が素晴らしいというだけではなく、 Web アプリケーションフレームワークそのものが現在はかつてほど重要なコア技術に なっていないせいではないか、という懸念をも呼び起こす。乱暴に言ってしまえば、 今では Web アプリケーションフレームワークというジャンル自体が一般化・コモディティ化してしまって、 個別の言語や環境やジャンルに応じて新しいフレームワークの開発は行われるにしても、 そこを頑張ることでアプリ開発全体をドライブしていくという発想が弱まっているのではないだろうか。
(なお、敢えて言うなら「第3のフレームワーク」、つまり「Rails の次」の位置に立っているのは WordPress ではないか、というのが持論なのだが、WP はもちろん普通の意味での Web アプリケーションフレームワークとは大きく異なるものであるし、 ある意味「Web アプリケーション開発そのものの地位の低下」 とも言える話になってしまうので、そこを詳説するのは稿を改めたい。)
Web アプリケーションフレームワークの位置づけが弱まったとしたならば、現在重視されていることは何か。 ここ数年、2010 年代の Web 開発のトピックと言えば、「クライアントサイドの多様化」 「サーバサイドの仮想化、IaaS/PaaS/SaaS 化」「リアルタイム性の強化」といった辺りが挙げられるだろう。
クライアントが PC とケータイという大きな 2 つの種類に分けられ、ケータイはその特殊性・ 閉鎖性からあまり大上段には取り上げづらい(が収益性は地味にとても高い)、という 2000 年代とは異なり、 スマートフォン・タブレット・PC という大きな枠がありつつも、それらが微妙に交じり合い、 さらに「モバイルファースト」の掛け声とともにスマートフォンアプリとスマートフォン Web が PC 以上に注目されるようになった。さらにスマートフォンアプリの中でもサーバサイドと通信したり、 場合によっては HTML レンダリングも行う Web クライアントライブラリが埋め込まれ、 さらに PC などによる JavaScript での通信も混ざりあう。サーバとクライアントは単純な 「Request and Response」のモデルからはるか遠く離れた複雑な関係になっている。
一方のサーバサイドは、アプリ開発者にはこれまでとあまり変わらない、 素朴なアプリケーションサーバの体裁に見せつつも、内部では仮想化された OS の上で仮想化されたミドルウェアが動いていたりする。 そして必要とされる能力はクライアントの増加とリアルタイム化により、 限られたリソース内でももっとたくさんの処理がさばけるようになっている。
これを Ruby、というかプログラミング言語の立場から考えるとどういうことになるのか。
大まかに考えると、PC アーキテクチャ的なハード上で OS が動き、OS の中の 1 プロセスとしてプログラミング言語実行系が動く、 という基本的な構成がサーバサイド・クライアントサイドの双方にあり、 それらが通信することで Web のサーバ・クライアントモデルが実現する、 というシンプルなモデルが(これまで以上に)変わりつつある、失われつつあるということが思い浮かぶ。
以前からスクリプト言語はグルー(糊)言語と呼ばれていたが、 現在のスクリプト言語はより強い意味で「糊」であることが求められている。 それはプロセス A とプロセス B をつなぐグループロセス、というだけでは済まされない。 もっと細かい単位で、「ここを後から(動的に)変更・拡張可能にしたい」という要求があり、それを実現できる能力が期待されている。 欠けている部分を、その形に合わせてつなぎ合わせるという、より細かく柔軟なグルー言語、 それが理想のスクリプト言語と言えるのではないか。
さらにもっと先の将来を考えると、クライアントの多様化は、スマートフォンレベルにとどまらず、 より小さなデバイスにまで浸透していくことはほぼ確実だろう。一頃話題となりながら、 あまり広まらないうちに静かになっていた「ユビキタス・ネットワーク」が、おそらくはハードの高機能化・ 省電力化や Wi-Fi の普及により、「センサーネットワーク」や「IoT」「M2M」などと名前を変えて、 往時の夢を現実化させつつある。そこでの通信は、小さいが大量のものとなり、 現在の Web サーバサイド技術とはまた異なるサーバサイドを求めるようになるだろう。
そのような背景を踏まえれば、Web が mruby (的な技術)に期待する未来が見えてくる。
mruby は一つのアプリケーション、POSIX な OS のレベルでのプロセスではなく、 アプリケーションの一部として動作する言語処理系である。全体として小さく、 OS や標準入出力などの存在しない場所でも動くという性質から、様々な規模での クライアントサイドで使えるようになるだろう。そしてクライアントサイドのみならず、 サーバサイドにおいても、複雑化するアーキテクチャのグルー言語として、 今までではできなかった、やりにくかったことが実現しやすくなる可能性がある。 Web のあらゆる層で、mruby が活躍する可能性を容易に見出すことができる。 Rails 開発者、Web に関わる技術者にとって mruby が重要である理由はここにある。
もちろん、mruby がこのように広く使われるようになるかはまだ何とも言えないだろう。 あらゆる層に需要があるということは、まったくばらばらな、一面では当然のように矛盾する要求が mruby に集中するということでもある。それを mruby 開発者グループとそのコミュニティが 上手に取りまとめて実現し洗練させていくのは多大な困難がある。 メモリへの要求一つをとってみても、数 MB でも「多い」と感じる世界と数 GB でも「少ない」と感じる世界とでは絶望的な距離があるわけで、その両方で使われる言語処理系、というものを適切に設計・実装することは非常にチャレンジングである。 しかしながら、同様のことはこれまでの CRuby にも多かれ少なかれ当てはまっていたことでもあるので、ここは外野としては楽観的に考えておきたい。
現時点での mruby は、現在の Web、あるいは Rails に対して大きな影響を与えるものではない (そもそも mruby の完成度がまだまだ高くないという点はおいておくとしても)。 今日明日の Web を知るためには、mruby を知る必要はまったくないだろう。 しかしながら、Web が一般に使われるようになってまだ 20 年もたっていないにも関わらず、 何度も大きく変化してきたことを考えると、遠くない将来の Web 技術の中に mruby が含まれている未来を想像するのも、十分に現実的なことではある。 mruby のコミットログを読みながら、そんなことを考えていたりする。
(るびま編集長 高橋征義)