マキノ式ブログより

その上、J2EEをコアとするSOAやWebServiceは、正直に言って自分だけでは手に負えない複雑な手順を踏まねばならず、本来開発を行うための労力の多くを周辺技術へ割かざるを得ません。（要するに何か作るにも腰が重いんですよねJ2EEだとw）

http://blog.makino-style.org/item/160

マキノさんと話す機会があったときに少し話したかもしれませんが。

仕事で使う言語・環境として、javaが、安い(易い)選択肢ではなくなっていることは感じつつ、現時点で ruby on rails(を含めLL系フレームワーク)を仕事で使うための準備を躊躇しているという人は、自分も含め多そうですね。そのような空気感だから、「JavaからRubyへ ―マネージャのための実践移行ガイド」という本は読んでみたいです。

仕事で複数人で開発を行なう場合に、なぜ10年前javaだったか、今rubyなのかというのは、理解した上で移行しなければrubyを使って状況を改善するのは難しいでしょう、多分。#勿論、仕事でなければ、phpでもlispでも、楽しいのでいいんですが。

稚拙な分析能力で分析

10年前javaだった理由

• 異常に経営陣に人気があった(流行った)こと
• オブジェクト指向言語(この言葉は今でも扱いにくい言葉ですが)
• 習得が容易なこと。C++の問題点を改善した言語であり、文法的にもC++に似ていて、移行しやすかった
• コーディング方法を縛りやすいことので複数人の開発に適していること(フレームワークが適応しやすい。○○専用(ry)

なんか、全部雇用者側の理由だorz.

今、rubyの理由

• ruby on railsという良くできたall in one の事実上標準があること
• 簡単なことは簡単に実装するという思想
• コーディングが楽しい
• 流行ってる
• オープンソース

ruby on rails は、scaffoldを実行しただけしか知らないので、「JavaからRubyへ ―マネージャのための実践移行ガイド」を読んで勉強します。。。。。

不安

現時点でruby on railsに懐疑的になってしまうのは、以下のようなことです。

• ruby関連
  • 文法が柔軟すぎる。
    • 様々なレベルの開発者で構成されるプロジェクトで品質が凸凹にならないか？
    • 関数型言語の側面を理解しないとrubyの強みを十分利用できない
    • どこでもクラスを拡張できると見つけにくいバグが入る可能性が高い
  • 経営的問題
    • お金を出す人に気に入られるか？(もっとjavaみたいに流行れば解決?)

• ruby on rails関連
  • 知識不足
    • 現時点でruby on railsの例外的な問題が起こったときに対処できるノウハウを持っている人がいない。
    • 問題があった場合に、メンバーに「ソース嫁」と言えるか？

否定的なのは、仕事でやる場合のことを考えた場合です。個人的には、rubyでコードを書いてみたいし、楽しいだろうということは容易に想像できます。(ほんとはperlでやりたい…)

とはいえ、マキノさんと仕事でrubyをいじる機会がくるのを楽しみにしてます。