Thinに期待

以前、Ruby on Railsの問題点について指摘した。
Mongrelの作者の記事「Rails Is A Ghetto」にも400回再起動するなどの逸話が掲載されている。
やはり、オリジナルのRailsは使えなかったのだと納得した。
しかし、MongrelやThinなど新たな「使える」Ruby版Webサーバが登場したのはうれしい。残念ながらMongrelについては今後の発展を望めそうにないが、Thinには期待している。

HotRuby

以前、「クライアントRuby」という記事で「JavaScriptで動くRubyは反則だ」と書いたが、それを実現した兵（つわもの）がいたようだ。
その名はHotRubyという。
心配していた実行速度は、それほど低下しないらしく、これなら反則とはいえない。
HotRubyが実現できた背景にはRuby 1.9のVMがある。サーバ側でコンパイルされたコードをクライアント側にダウンロードして実行するしくみらしい。確かに、この方式ならばある程度の実行速度を実現できるだろう。
クライアントRubyの記事では、インタプリタをJavaScriptで実現するのは速度的に無理があると判断たが、コンパイル方式なら無理ではない。
しかし、HotRubyでは一度サーバ側にソースを転送してコンパイルする必要がある。そのためオフラインでは使えない。その意味ではJavaScriptに対抗できるものではない。そもそもJavaScriptで実行するので対抗してもいないのだが。
HotRubyの使い方としては、マシンにRubyをインストールすることなく実行できることだろう。
しかし、そのためにはライブラリをネットワーク経由でrequireするしくみが必要だ。自分で書けばよいだろうが、それでは不親切だ。そのあたりのライブラリ管理も今後の課題だろう。
個人的にはHotRubyがGoogle Gadgetになって欲しい。

PythonをRubyに変換する

Rubyには足りないものが、まだまだ多い。
Rubyは純粋なオブジェクト指向言語であることを強調しているが、それは単なる見方にすぎず、実用上はあまり重要でない特徴だ。
Rubyの最大の弱点はライブラリだ。ライブラリが貧弱すぎる。
ライブラリの優秀さではPythonが突出している。
そこで、PythonをRubyに変換することができれば、あるいはPythonライブラリをRubyに移植できればRubyの実用性が高まる。
本当は、ライブラリだけでは不足で、ZopeやPloneなども欲しいところだ。
そのためには、ライブラリの移植より、Pythonを変換したほうが有用だろう。

Rubyの問題点

Rubyは作者が日本人なので日本での人気は高い。
しかし、Ruby人気はRails人気であり、Railsの凋落とともにRubyの凋落も始まる。
Railsは、なるほど開発は簡単かもしれないが、できた製品を実行させるのはかなり高いハードルがある。
作者自身がFastCGIを推奨しているが、これは過去の産物といってよい。
それでもきちんと使えればよいが、インストールがうまくいくかどうかは運のようなものだ。
よって、Railsで作っても実行できない。
これは笑えない冗談だ。しかし、多くの場合、本当の話だ。
では、これはRailsの問題点かといえば、Ruby側の問題点ではないかと考える。
そもそもRubyの実行速度が遅いためにCGIでは使えないのだ。また、ライブラリの読込みやApacheとの連携にも問題がある。
PythonにはZopeというすばらしいアプリケーションサーバがあるのにRubyにはない。そのため無理にFastCGIを使う。Ruby版ZopeができなければRubyはこのまま消えるかもしれない。

LL用ネットワーク対応モジュールローダー

LLとはLightweight Languageのことで、Perl, Rubyなどのスクリプト言語を指す。
これらの言語ではモジュールを動的にロードすることができる。
原理は簡単で読み込んだファイルをプログラムとして評価(eval)するだけだ。
例えば、Perl, Rubyにはrequireという命令がある。
しかし、これらはローカルなパスにしか対応していない。
これを一般的なURLにすれば特定のサーバ側にモジュールを用意するだけで済む。
つまり、モジュールのインストールが不要となる。
もちろん、サーバ側の負荷が高くなるので、キャッシュを用いる必要がある。
キャッシュさえあればオンデマンドにインストールされることと等しい。
便利そうに感じるが、まだない理由は、機種依存のコードにあると考えられる。
LLもJavaのように機種に依存しない中間コードがあれば、このような問題は解消される。
例えば、RubyにはJRuby(Javaで実装したRuby)がある。
Perlもバージョン6には中間コードに翻訳されると聞く。
インフラは徐々に整備されつつある。

クライアントサイドRuby

RubyはRuby on Railsによりサーバサイドで有名になった。
しかし、クライアント側ではぱっとしない。
（私が知らないだけかもしれない）
クライアント側ではJavaScriptの独壇場だ。
しかし、JavaScriptは大変癖の強い言語だ。
特に、オブジェクト指向ではなくオブジェクトベースである点が問題だ。
JavaScriptをオブジェクト指向という人もいるかもしれないが、それはオブジェクト指向風の書き方もできるという意味で、原理的にはオブジェクトベースに他ならない。
その点Rubyは由緒正しい？オブジェクト指向だ。
Smalltalkの生まれ変わりだと思っている。
RubyはJavaを凌駕するかもしれないが、JavaScriptに代わる方法は今のところない。
JavaScriptに対抗するにはブラウザ内でRubyを実行できなければならない。
この場合、性能も重要なので、JavaScriptでRubyインタプリタを書くというのは反則だ。
サーバサイドではRubyをJavaで実行するJRubyは反則どころか本命ではないかと思う。
元々サーバサイドでは機種に依存しない性質が求められていたが、Ruby自体は機種に依存する。
その点ではJRubyはRubyより優れている。
しかし、JRubyもJavaScriptの代わりにはならない。
アプレットは実行できるかもしれないが、それ以外は無理だろう。
今後、ブラウザに任意の言語をインストールするプラグインが開発されることを期待したい。

WindowsにRubyをインストールする

WindowsにRubyをインストールしたときのメモ
One-Click Ruby Installerをダウンロード
RubyGemも同時にインストールされる
ライブラリの更新
C:\> gem install rake
C:\> gem install rails

Ruby on Railsのインストール

Ruby on Rails(RoR)のインストールはOSに依存する。
OSごとのやり方は別途用意するが、ここでは基本的な方法だけ述べる。
1. RubyGemのインストール
RubyGemの最新版をダウンロード
$ ruby setup.rb
2. RoRのインストール
$ gem install rails --include-dependencies