井上 研一 今やっている仕事が比較的使い捨てチックなリクエストだったので、試しにRuby on Railsを使ってみることにした。このリクエストを受けた当初はJava＋Seaser2＋Doltengでやっていたのだけど、なかなか生産性が上がらないので途中で切り替えた。
私はRubyでLinuxZaurusアプリを開発していたりもするので、Railsを知ったのも早かった。しかし、いつかやろうと思ったまま何もやらずに今に至る。それで、この数日はRailsの勉強をしながら開発に熱中した。その感想。ちなみに、環境はふつうのRubyではなく、JRubyをWindows上で動かして開発した。本番環境はLinux＋Tomcatである。
たしかにRailsの生産性は高い。Seaser2＋Doltengも、ふつうのJavaとかHibernate＋Springとかに比べると結構生産性が高いのではないかと思うのだが、Railsは明らかに上回る。Seaser2＋Doltengで2日くらいかかった作業をRailsだと1日で終わる。
Seaser2＋Doltengでの開発では、テーブル設計をEclipseプラグインのERMasterを使って行い、そこではき出したSQLでMySQLにテーブルを作り、DoltengでScaffoldを作るという順序をとった。これが最も生産性が高いように思う。ただ、テーブル定義を少し見直すとScaffoldを作り直すか、ソースのあちこちに手を入れなければならない。これが生産性を下げるネックだった。で、Viewの方はAjaxを含めてTeedaを使う予定だったのだが、そこに取りかかる前にRailsに切り替えたので、よく分からない。
一方、RailsではScaffoldを作るときにモデルのデータ項目と関連を決める。Scaffoldではテーブルを作るSQLもはき出すので、それをMySQLに反映（マイグレーション）する。テーブル定義を変える場合、それが大がかりならScaffoldを作り直した方が速いが、数項目の追加程度ならMySQLのテーブル定義を直接変えた方が速い。Railsで出来るモデルのソースには項目名が記述されないのでモデルの書き換えはいらない。（もちろんViewの書き換えは必要だが）
Seaser2＋Doltengは自動生成とは言ってもそれはソースの自動生成に留まる（いまのところ）。一方、Railsの自動生成はソースの自動生成と併せて実行時の自動生成まで含むので、そこが生産性の違いに直結する。
私は、今やっている仕事をどうやら期日中、いや期日より少し早くやり遂げられそうだ。それは、Railsのおかげによるところが大きい。とはいえ、Railsでもはまるポイントはある。それはまた、次回書くことにしよう。