【感想】第25回Ruby勉強会

大阪国際大学で開かれた第25回Ruby勉強会の感想を書く。

【1】JavaEEでRailsを動かす

紅月さんの講演。
一番興味があった。

理由は、ファウラーの下記の記事「ファウラーがRubyに抱く感慨」が気になっていたから。

(前略)若いテクノロジーには新しくて重要な特筆すべき点がいくつもある。だが、私にとって最も重要なのは、JRubyだ。現在、JRubyは最終的なRCの段階だ。 Java VM上で動くスクリプティング言語を提供するだけでなく、 Rubyプラットフォームの完全な実装をJVM上で行おうとしている。 ThoughtWorksで我々が行っていること、そして、多くのRuby/Rails開発者たちにとって、（たとえ"include java"をしたことがなくても）これはかなり重要なことである。

我々のRubyチームが開発中に直面した最も大きな問題はデプロイだ。 Rubyのアプリケーションを実践投入するには、非常に多くの新しいテクノロジーが必要となる。それに、データセンターはこういったことに保守的だ。我々のRubyWorksもこの点をシンプルにしようと努力している。 JRubyはこの点について、Javaコンテナにデプロイすればよいので、 Railsアプリケーションもwarファイルとして簡単にデプロイできると主張している。これにより、Ruby on Railsが多くのエンタープライズ環境における選択肢となる得るのではないかと私は思っている。（後略）

Rubyはスクリプト言語なので、プログラムそのものがアプリケーション。

でも、本来、プログラムの目的は、実行可能なバイナリモジュールを作ることにある。
Cobol、C/C++からJava、C＃へ至るプログラミングの歴史と同じぐらい、ビルドの歴史も長い。

例えば、Windowsアプリは、小さな実行モジュールであるexeファイルと、複雑な業務ロジックや共通ライブラリを分離した複数のDLLから構成されるのが普通。
その思想は、プログラムを論理的に分割するだけでなく、物理的にも分割し、複雑性を制御しようとする所にある。

同様に、JavaのWebアプリも、war/earファイルという一つのWebアプリをAnt/Mavenでビルドして作る。
warファイルの構成は、JSPなどのViewがrootの直下に配置される。
Controllerが含まれるWEB-INF。
そして、複雑な業務ロジック、共通ライブラリは複数のjarファイルへ分離する。

Windowsアプリと同じく、この設計思想も、複雑なプログラムを物理的にjarファイルへ分割するやり方に受け継がれている。

だから、RubyやRailsの弱点はビルド＆デプロイにあるのではないか？というファウラーの指摘は的を得ている気がする。

紅月さんが紹介してくれたやり方の発想は、下記の仕組み。

Rails(warファイル)
↓
JRuby
↓
RailsServlet
↓
Servlet Container(Tomcat等)
↓
JVM

つまり、RailsServletがRailsをServletコンテナにラッパーして、Tomcat上で動かせるようにする。

RailsをTomcatで動かす利点は、JavaのWebアプリケーションサーバーは枯れた技術で性能もいいから。
Tomcat上でRailsが動けば、JBossを初めとして、WebSphere、WebLogicのような大規模なJavaのWebアプリケーションサーバーでも動作可能になるだろう。
そうなれば、より大規模で複雑なWebアプリをRailsで作ることが容易になるだろう。

紅月さんのデモはうまく動作しなくて残念だったけれど、この思想はファウラーの指摘以外にも、もう一つの重要な指摘を含む。

それは、JVMがインフラであること。
JDK6以降では、JRubyだけでなくJavaScriptのような殆どのスクリプト言語がJVMで動作可能になっている。
つまり、JVMさえあれば、RubyもPythonもJavaScriptも動いてしまうのだ。

最近は、Scalaのような関数型言語さえJVMがあれば動作する。
このScalaは、Liftという興味深いWebフレームワークもあるようだが。

実際はパフォーマンスもあろうが、特にWebシステムはスケールアップしやすいので、近い将来、JVM上でRailsを動かすのも実用的になるだろう。

まだ、Tomcatの上でRailsを動かすのは不安定だが、要注目の技術だと思う。

【2】角谷さんのRSpecライブコーディング

　角谷さんは本来、関西人だったそうで、ライブコーディングでは関西弁が随所に出て、聞いていて楽しかった。
　僕自身はJUnitに慣れているので、RSpecよりもRubyのTestUnitの方が理解しやすい。
　yu-yaさんに尋ねたら、TestUnitの方がassertEqualsだけで書けるので簡単ですから、と言っていたのが印象的だった。
　
　角谷さんが、ユニットテストのプログラミングの重要性を下記の図で説明した。
＃縦軸：ソースの綺麗・汚い
＃横軸：プログラムが動く・動かない

┌─────┬───┐
│　　　　　　　│　　　　　│
│　お花畑　　│理想　　│
│　　　　　　　│　　　　　│
├─────┼───┤
│　　　　　　　│　　　　　│
│　終了　　　│現実　　│
│　　　　　　　│　　　　　│
└─────┴───┘

　つまり、理想は、綺麗で動くプログラム。
　でも、現実は、動くけれど汚いプログラム。
　
　綺麗だけれど動かないプログラムは、お花畑。
　汚くて動かないプログラムは、既に終了している。

　角谷さんによると、リファクタリングとは、終了→現実→理想へのルート。
　
　池上さんは、終了→お花畑→理想　のルートもないだろうか？と質問していた。
　角谷さんによる明示的な回答はなかったけれど、数学者である池上さんらしい指摘。
　Haskellはまさに、コンパイルが通れば確実にバグなしで動く。
　Haskellは、終了→お花畑→理想　のルートなんだろうな。

　今日のRuby関西は、Flexユーザーグループ関西の夜桜と重なり、ちょっと人が少なかったのが残念。
　でも、懇親会、2次会も盛り上がって楽しかったです。

　ちなみに、角谷さんの本にサインしてもらいました。
　角谷さんの本は下記が有名かなぁ。