マキノ式ブログ

RubyOnRailsで作られたWBSに基づくプロジェクト管理システム９ArrowsをUbuntu8.04.1で動かしてみました。
ちょっといじってみた感想として、残念ながら実際の現場に導入するのは、まだちょっと無理っぽいです。特に、タスクの階層レベルでの追加時の振る舞いと、タスクの移動の機能不足が重なって非常にまどろっこしいため、ウチの短気な人達はおそらく使ってくれなさそうです。


良いところ

• 見やすい、デザインが素敵


• 最大4階層までのタスクも逆にシンプルで良い

悪いところ

• タスクの追加時の動作
  → タスクを階層追加すると最下部に追加されてしまう。


• タスクの移動
  → 右クリックして上、上、上・・・・を繰り返す必要がある。


• 重い
  → Java畑の人間が言うのも何だが同スペックで動作するPHPと比べると格段に遅い


• ドキュメントがWebrickだけ・・・・
  → RoR系で超気になるのがここ、実際の運用時パフォーマンスってJavaやPHPと比べてどうなんだろう・・・・


• Airのセットアップってどうしたら良いの？？？？

とりあえず、Ubuntu8.04.1 JeOSに9Arrowsを一からセットアップするドキュメントを書きました。9arrows特有の部分を読み替えれば、他のRoRで仮想イメージ配布するのに役に立つかもしれないです。

裏・マキノ式: 9Arrows on Ubuntu8.04.1 JeOS
http://www.makino-style.org/ura/index.php?9arrowsOnUbuntu8.04.1JeOS


参考記事：
RubyやAjax，AIRなど活用した国産タスク共有システム「9arrows」，オープンソースとして公開へ
http://itpro.nikkeibp.co.jp/article/NEWS/20080724/311423/

オープンソースで無償で公開
Rubyで作った国産タスク共有システム「9arrows」
http://www.atmarkit.co.jp/news/200809/09/9arrows.html

下記の記事から、これはどっかで既出だったけど、SunがJRuby開発者を雇ったのとNetBeansでRubyをサポートするそうです。
あと、先日マイクロソフトがIronRubyを発表しました。
これは.NETのCLR上で動くDLR（DynamicLanguageRuntime）上で動作する実装のようです。
先のIronPythonも同じ原理で、DLR上ではRuby、Python、JavaScript（JScript）、VBが動作すると書いてあります。
つまりCLR上で構築するんではなくスクリプト言語用のプラットフォームをDLRに共通化してあるみたいです。
＃VBって動的型言語だったのか・・・ｗまあそういえなくもないか

これらはMicrosoftMIXで発表されたSilverlightに伴って明らかになった話で、Microsoftのブログでは.NETライブラリをこれらの動的言語から利用できて、Silverlightのアプリがクロスプラットフォームでかけるよーみたいなことを言ってます。

Microsoft Announces IronRuby
MIX 07 - Silverlight shines brighter!

ところで、そのSilverlightって何だと・・・ｗ
紹介ページを見ると、クロスプラットフォームで、.NETで、リッチでインタラクティブなアプリケーションをスクリプト言語（AJAX, VB, C#, Python, and Ruby）で書けますぜ！と言ってます。<嘘クセエ
要するに、Flashに対抗する物で、FlashではActionScriptだけだけどMicrosoftは色々いけちゃうよって物だと理解しました。

あ、あとSunがJavaFX Scriptという新しいスクリプト言語を発表するそうです。もちろんJDK6のScriptエンジンで動くはず。
これはまあ、出遅れた感があるような気がしなくもない・・・・

こうしてみると.NETとJavaで言語プラットフォーム戦争が始まってますね。

読み終わりました。
久々に一息で読みました。
↑空いた時間をつなぎ合わせつつだったので時間が掛かってしまった。

ここまでドキドキして技術書を読んだのはEffectiveJava以来でした。
細かな技術的説明はさておき、何が得られるか、どうやるべきかにおいて多くの道しるべを与えてくれました。
また最初の印象通り、全体としてRubyが全て！という訳でもなく非常にバランスがとれた内容でした。

感想として、今現在LAMPとJavaで行なわれているWEB開発の中間部分は、ごっそりとRails（Ruby）に移行していくと思いました。
つまり、PHPはよりラピッドな簡易構築、Javaはよりエンタープライズな重量級インフラ系に押しやられ、いわゆるWEBアプリケーションと呼ばれる本流部分はRailｓに置き換わるだろうということです。

もちろん、全てがRails一色になるとは思いませんがかなりの部分がRailsに取って代わられると思います。

当面の目標として、（本書で言うところの）政治的リスクはあるものの、ちょうど良いサイズのアプリケーションをRails化してみようと思います。また中期的にはRubyのできるオフショアを目指して行きます。
↑よりコストを低減させ競争力を強化する助けになると確信しました。

Rubyに興味を持つ人にとって、この本は非常に対費用効果が高いと思います。経費でも何でも使って是非購入すべきです。

では

遅ればせながら、角谷さんが翻訳をされた「JavaからRubyへ —マネージャのための実践移行ガイド」を入手しました。
全てを読み終わらないうちに、待ちきれずに書いてしまいます。今ちょうど第3章を読み終わったところですが、その内容は私を打ちのめすのに充分でした。

まずはRubyが如何にすばらしいのかという点よりも、私が愛してやまないJavaの見て見ぬふりをしていた点をズバリ指摘している部分に衝撃を受けました。


１，Javaは生産性が低いという事実
２，WEBアプリを作るに当たって最適解ではない事実
３，Javaの再利用性の幻想

これらについて私は以下のように感じました。
１について、これは認めたくない事実であり、事実と直感的に知りながら目をそらしていた事実です。実際、Javaにおいては厳密な型定義と規格の準拠に多くの時間が費やされます。
特にそれに伴うコンパイルと複雑なデプロイ、またはビルドツールの設定作業は、宗教めいた儀式と化して私のテックマン（*1）としてのプライドに安心と尊厳を与えてくれます。
その点を除けば、残念ながらこの崇高な時間は明らかに無駄であり開発プロセスから省かれるべき儀式です。
恥ずかしながら、私は周辺技術をマスターしそれを扱えることが、大事な仕事であると勘違いをしていました。

ある中国人エンジニアの言った「Javaは面倒くさいですよ。」という言葉が深く突き刺さります。私はそのとき単にそれを「技術が低いからでる言葉」であると切り捨てました。
しかし確かに、Springの設定も、WARのデプロイも、Mavenによるビルドも面倒であり本質的では無いことを認めます。


２については否定のしようもありません。むしろ、しばらく前から自分でも社内において下記のような（私的には）敗北宣言を出していました。
「少なくともWEBサイトの構築においてJavaはPHPより向いているとは口が裂けても言えません。個人的にはJavaでやりたいが、この案件は明らかにPHPでやるべきです。」

そして３，私は、時々インタフェース主義は全てを達観したスーパーエンジニアでなければ対応できないのではなかろうかと思うことがあります。つまり「精兵主義の軍隊に精兵がいなかった事（*2）」というわけです。
少なくとも私は今に至るまで、ミクロな規模を除いて有効な再利用がされているところを見たことがありません。
反論される人がいると思います。でもよく考えてみてください、インタフェースを修正したことはありませんか？絶対にあるはずです。
どんなにDAOとServiceを綺麗に分離してDIコンテナによりシンプルにしても、開発中WEB層からの呼び出し時にインタフェースの修正をしたことがあるはずです。（そもそもバイトコードインジェクションによるAOPという技術がそれを証明しています。）

ミクロな視点でのインタフェースの利用に文句はありませんが、これを業務ロジックに適用すると破綻をきたしているのに疑いはありません。なぜなら業務ロジックは生き物であり外的容認により変化し、また新たに発見されるからです。

本書でも繰り返し述べているように、Rubyが全ての最適解にはなり得ないでしょうが、少なくともこれまでJavaだけを見ていた私にとっては開発の本質を取り戻す良い機会になる事だけは間違いないです。

さて、続きを読まなければ・・・・ｗｗ
＃上海までこの本を持ってきてくれたH君、ありがとう。

*1 アイザック・アシモフのファウンデーションシリーズにおいてホーバー・マロウが訪ねた銀河帝国の原子力発電のエンジニア、ホーバー・マロウは下記のように表現している。
「かれらはもはや自分たちの巨大技術すら理解できなくなっているんだぞ。」

*2 山本七平による「日本はなぜ敗れるのか」で引用されている小松真一による敗因21ヵ条の第一条より
「精兵主義の軍隊に精兵が居なかった事。然るに作戦その他で兵に要求される事は、全て精兵で無ければできない仕事ばかりだった。武器も与えずに。米国は物量に物言わせ、未訓練兵でもできる作戦をやってきた」

角谷さんが翻訳をされた「JavaからRubyへ —マネージャのための実践移行ガイド」の第一章が無料公開されたので早速読んでみました。

角谷HTML化計画　『JavaからRubyへ以下略』の見本PDFが公開されました
http://kakutani.com/20070410.html

その中で、かつて「軽快なJava」を書いた著者は、Javaの限界というよりむしろ閉塞感を見事に指摘しています。

もちろん、Ruby万歳、すべてはRubyで！みたいな内容ではありませんでした。JavaからRubyへ行くにあたり何がリスクであり、いまどのような状況なのかが説明してあります。非常に抵抗なく読むことができました。

実際、私も最近はこれまでの自分の時間や能力を投資したJavaに対する熱意が、変化を拒むような保守的なものへと変容していました。
その上、J2EEをコアとするSOAやWebServiceは、正直に言って自分だけでは手に負えない複雑な手順を踏まねばならず、本来開発を行うための労力の多くを周辺技術へ割かざるを得ません。（要するに何か作るにも腰が重いんですよねJ2EEだとw）

Javaをスキルのひとつにする、良い機会だと思いました。
この本、発売されたら是非購入しようと思います。

#RubyOnRailsで疑問な点がひとつ、もう凄くしょうもないのですが先ほどの「JavaからRubyへ —マネージャのための実践移行ガイド」の第一章にも記述されている「ログイン用のモデルを切り離して扱うことができる」の部分、これどうやるんだろう？？（はい、超初心者決定w）