イトウ アスカ blog このページをアンテナに追加 RSSフィード

2008-05-26

言語を選ぶ基準

 前回のエントリで私は Ruby 党と言いながら Ruby を批判したかのようにもとれるので、改めて Web アプリにおける私の採用言語の選定基準(というほど厳密ではないが)について書いてみます。

 まず、本番稼動環境がどういうところなのかというのが最大のポイントです。当たり前ですね。



 それから、多人数(特に複数の会社)が関わるプロジェクトならばまず Java が選択肢にあがります。それは周辺ツールの充実さですね。Javaコーディング規約も「これ!」というのがありますし(私のオススメは↓の本)、そのチェックツール(CheckStyle)の入手性も良好です。

 JUnitMaven、Continuum、FindBugs などのテストツール、構成管理ツールで高品質なものも容易に入手できます。これが Java の強み。ある程度以上の規模になってくると、こういったツールの便利さが身にしみてきますね。

 逆にこういったツールを Ruby でも容易に入手できて、Eclipse などの単一の IDE から使用できれば、かなり Ruby on Rails がしめる割合が増えるだろうなと思っています。

2008-05-23

「今の」Java を見ていない人が「今の」Ruby を見て浮かれている(ようにしか見えない)

Ruby普及でNaClなど3社が提携、CodeGearのIDEを推奨 − @IT

 私はもともと Ruby 党でありますが(サーバ保守などに Ruby スクリプトを多用してます)、ここ最近の Rails ブームには眉をひそめたくなります。というか OSJ さんは、ちょっと前までは PHP に傾倒してたと思ったのになぁ(その辺は、私の過去のエントリが証拠)とあまりの宗旨替えの早さに「いかがなものか」と思ってみたり。まぁ、ビジネスですから売れないものをいつまでも売っていてもしょうがないでしょうけど。

 ということで、なんか OSJ さん叩きみたいになるかもしれませんが、相変わらずなんか言ってることがちょっと違うような気がする。

 「従来は顧客のほとんどは技術部門だったが、いまは企業のユーザー部門が直接お客様になるケースが増えている。企業内ではAccessVBを使った小さなアプリケーションが多く残っている。こうしたアプリケーションは開発担当者がいなくなるなど環境変化に弱い。こうしたものをWebアプリケーション化して提供するケースが増えている。Javaは開発フレームワークや稼働環境が大がかりになりがちだが、Rubyならシンプルだ

 RubyCGI ならそうかもしれませんが「Ruby on Railsインターネットにさらされるような本番稼動環境構築したことあるのかね、この人は」と思ってしまいます(たぶんないでしょう)。

 Webrick でテストでちょっと動かしてみるのはいいですよ。もうね、Rails サイコーって感じです。開発者に優しいみたいな。

 でも、そこそこまともな状態としてさらすとなると、けっこうめんどくさいっすよ。その辺は実際に稼働環境作ったことある人ならわかると思いますが、lighttpd 使うにしろ mongrel 使うにしろ(mod_rails はまだ試してません。スイマセン)Tomcat 使って war さらすのに比べてそれほど簡単でしょうか? むしろ難しいと私は思います。FastCGI がどうとか、めんどくさすぎる。というか gem って危ないですよね。複数の Rubyプログラムが動いているような環境だと、下手に gem update とかされた日にゃあ終了のお知らせが鳴り響くことも(まぁ、私が悲しい思いをしたことがあるだけですけど)。

 ということで、PHP プログラムなんかも私の場合、最近は Smarty を使ったら pear 使わずに Smarty ごと納品ってな按配なのですが、Rails だってそうしないと危なくてやってられない。でも、これって意外とめんどくさい(Maven でハッピーデベロッパーライフを送ってる人にとっては)。


 ということで、今の Java のいったい何を見て目の敵にしているのかさっぱりわからないんですよね。ということで行き着くのが、昔のダメだったころの Java なわけですよ。私も Java なんてクソって言ってましたし。たぶん、7、8年前に私と一緒に仕事をした人が Java に傾倒している今の私をみたらきっと驚くでしょうね。

 そんな昔の Java を見て Ruby on Rails いいよみたいなこというニワカ Ruby 支持者に私は言いたいですよ。バージョン 1.6.x → 1.8.x の悲劇知ってるかと。J2SE 1.4 → Java SE 5 の比じゃないぞと(互換性の話ね。主観だけどさ)。そんな時代の Ruby のとりまきのクソっぷり知ってるかと。Ruby 関係をググって行き着く先が Not Found や Internal Server Error がやたら多かったってことを知ってるかと。Ruby 自体のソースはすばらしいってことを棚に挙げて、そのとりまきも「ソースがドキュメントですw」なんてきたねぇソースさらして言ってたのを知ってるかと。公式のリファレンスにウソ書いてて一晩悩まなきゃいけなかったりしたことを知っているのかと。「Ruby 厨」がうざかったのを知っているのかと。……際限がないのでこの辺にしとくけど。まぁ、私もそのクソの一人だったかもしれないけどさ。

 で、やっぱりそんなのは過去の話で、今は今なわけですよ。じゃあさ、Java も今を見ようよ。Java だって守備範囲広いよ。私だって EJB 2.x とかってクソだと思うしさ。でも、Seasar とかいいですよ。革命ですよ。レボリューションですよ。





 ところで、この記事。まつもとさん以外は、「流れ着いた人」ってイメージがあるわー。CodeGear は、Borland の紆余曲折があって Delphi で迷走して PHP にちょっかい出して Ruby に来ました。って感じ。OSJ も Java はダメだっつって PHP マンセーって言ってたかと思ったら Ruby に来ましたって感じ。RubyPHP みたく適当に食い荒らしてまた宗旨替えしなきゃいいんですけどね。Java に戻ってきたらそのときこそ大爆笑しちゃうわ。












 今日のは、なんか暑さで頭がくらくらしながら勢いで書いたエントリです。……と逃げ口上を書いてみるテスト

2008-05-21

Radiant CMS 0.6.5 以下から 0.6.6 以上にアップデートする方法

 昨日のエントリのリンク先を見れなかった方、失礼しました。Radiant CMSアップデートにもろに失敗してました。0.6.2からアップデートしてなかったので久々にアップデートするかと思い、最新版は 0.6.7 で、最後の数字しか違わないし、まぁ、ちょちょっとできるべと甘く見ていたらかなりの変更が加えられていたのですね。

 その「かなりの変更」というのがずばりRuby on Rails 2.0系への対応です。これは、0.6.6で行われたことらしいのですが、このせいでハマってしまいましたよ。

 ということでやり方です(CentOS 4.6使用。たぶん他のOSでも同じようにできる)。

 まず、gemRadiant CMSアップデートします。

# gem update radiant

 次に Radiant CMSインストールしているディレクトリをカレントにして、インストール済みの環境をアップデートします。このとき config/environment.rb も更新されるので、何かカスタマイズしている人は要注意です(元のファイルは environment.bak という名前でバックアップされます)。

# rake radiant:update

 そして、ここがミソ。マイナーバージョンアップなのに DB 構造が変わっていますので、DBマイグレーションを行います。development 以外で動かしている私のようなひとは、下記の production のように稼動環境名を入れるのを忘れずに(忘れた私は大ハマり)。

# rake production db:migrate

 あとは、Radiant CMS を実行しているサーバ(私の場合は lighttpd)を再起動して完了です。

2007-09-04

本当は Seasar の講習会をやりたかった(笑)

 本日、山形県内の某所で、Ruby on Rails のハンズオン講習会の講師をやります。この講習会は二回目です。

 でも私は、言うほど Ruby on Rails って好きじゃないんです(笑)


 たぶん外国産だから(笑)

 Ruby 自体は好き(笑)


 正直、やるんだったら Seasar のハンズオン講習会やりたかったわー。まぁ、この講師の話は、発起人の手近にいた Rails に詳しい人間が私だったから来ただけなんで、贅沢はいえませんが。

 ところで、山形県内の某地銀のなんかのシステムに Seasar 使ってるらしいですよ。前回の Ruby on Rails の講習会を受けに来てくださった中の人が言ってました。


 あと、Click のハンズオン講習もやれます。Ruby に移植しようとしてソースを読みまわしたからそれなりに詳しいと自負してるんで。私自身は Click はあんまり使わないけど(笑)

 ちなみに Ruby への移植はほぼできたけど、なんか遅かったのでお蔵入りかもー。たぶん Click の構造はスクリプト言語向きじゃないですね。単純にソースのつくりをほぼそのまま移植したのが失敗。どうせなら Click に「インスパイア」されたものをフルスクラッチすればよかったー!



 なんにしても、このブログのとおり、私自身、試行錯誤の人なので偉そうに講釈をたれられるもんじゃないので、「ハンズオン」の講師止まりです。もっと「上の」の講習会を催すときは、ぜひとも関係各所(?)の先生に講師をお願いしたいなぁと思っています。っていうか、私自身がお会いしたいのであります。

2007-08-31

Rails や S2* を使うのは「スウィート」だから

 Java の Web アプリケーションフレームワークである「Click」はよくできていると思いますし、私はけっこう好きです。でも、その割には使う気になりません。それは、O/Rマッパや DI コンテナが別だからです。Click には Hibernate や Cayenne、Spring と連携する機能があるのは知っていますが、スウィートというほど一体化はしてませんよね?

 それに比べて Seasar Project は、Dolteng という Eclipse プラグインと、それによる Chura というスウィートを提案してくれています。なので、網羅的な学習効率および開発効率が良いと私は思います。

 また、Rails も様々なツール、フレームワークの集まりですが、渾然一体となって開発スウィートとして上手く機能しています。これもまた Rails の価値のひとつだと私は思うのです。

 より早く、より高機能なものをと求められ続けるのはどこの業界でもそうでしょうが、IT業界においては Web において特にその傾向が顕著に思えます。そのニーズに答えるためには、あらゆるものが違和感なく一体化した開発スウィートを上手く活かさなければならなくなるのは必死だと私は考えます。


 かつては表計算は「ロータス 1-2-3」、ワープロは「一太郎」と言われていたオフィス・ソフトウェアが、Word、Excel に押されてしまったのは、個々の機能もさることながら「スウィート」としてのパワーがあったればこそだったのではないでしょうか? そのように Web アプリケーションフレームワークもスウィートであるものこそが生き残っていくことでしょう。