要は、私のように英語力が無い人間が dojo を使えるようになるにはどうしたらいいか考えてみました。

dojo といえば、豊富な機能を持った人気の JavaScript フレームワークです。しかし、マニュアルが豊富ではなく、日本語情報が少ないなどの理由から、使いこなすのはなかなか大変です。リファレンスは存在しますが、正直これを見て使えるようになるものでもありません。（あるいは、これを見て使えるスキルがあるのなら、dojo を使いこなすことに苦労するとも思われません。）

特に、dojo の widget はプログラムから生成する方法もあれば、DOM 要素に特定の属性を定義してやることで、自動的に生成する方法もあります。リファレンスだけを見て使えるような代物ではありませんが、The Dojo Book を参照するのも英語力が無いとしんどいでしょう。

そこでどうするのかというと、リリースをダウンロードしたら、テストコードを参照します。dojo.widget のテストは親切で、テストコードを見ると、5 分で使えるようになります。ドキュメントが豊富ではない、あるいは日本語ではない場合はまずはテストコードを見る、これはどんなオープンソースプロダクトにも言えることかもしれませんね。

たとえば、dojo のタブを調べる場合は以下を参照します。
/tests/widget/test_TabContainer.html

あるいは、プログラムから widget を生成する例は、以下です。
/tests/widget/test_createWidget.html

ちなみに、最近は日本語の情報としては以下が良さげです。dojo のまとめサイトっぽくなっています。
Dojo/JavaScript Toolkitのメモ

Kodougu の機能を追加し、サーバーにアップロードしました。ぜひ、いろいろといじってみてください。

新機能・改善項目一覧
(1) 属性、操作を編集可能にした。
(2) パッケージを追加した。ただし、パッケージの中に要素を追加する機能は追加していない。
(3) 図上の要素のサイズ変更をできるようにした
(4) キャッシュの適用で図の読み込みが軽くなった
(5) 図のサイズを可変にした（Firefox）

最新の Kodougu（IE/Firefox で動作。Firefox 推奨。）


既知のバグ
(1) 属性、操作の追加、編集が図に反映されないことがある
回避策：クラス名を変更すると反映される
原因：描画情報のキャッシュが、属性、操作編集時に消去されない
状態：解決（2007/7/19）

(2) 図を表示したときに関係線がずれて描画される
回避策：図上の要素を少し移動すると、再描画されて正しい位置に表示されるようになる
原因：関係線は要素の中心と中心の間に引かれるが、中心点の計算時に要素のサイズ変更を反映しないことがある
状態：解決（2007/7/19）※ ただし、図の読み込みが少し遅くなる副作用があるため、改善中。

(3) 属性、操作編集のユーザビリティ（画面遷移）が非常に悪い
がんばって修正します。。。
状態：改善（2007/7/19）

バグ報告等は当面はこのブログのコメントにお願いします。

■ 2007/7/17 22:59 追記
バグ報告を追記します。

(4) IE で、他のユーザーが図上で操作を行うと、スクロールバーが初期位置に戻ってしまう（Firefox では発生しない。）
回避策：なし
原因：図の再描画時に図のサイズが小さくなり、スクロールバーが消えてしまうため。
状態：解決（2007/7/19）

このサイトは、Ruby, Rails, JavaScript などプログラミング系の話題を取り扱っているせいか、アクセスされるブラウザの傾向が一般とは違うのだろうと考えていました。

7/1 ～ 7/9 までのアクセス結果（Google Analytics）を見ると、セッション数 2160 に対して Firefox は 1210（56.02%）、IE は 671 （31.06%）でした。技術系サイトなので Firefox の割合が多いことは当然ですが、もう一つ傾向がありました。Firefox ユーザは 90% 以上が最新版（現時点で 2.0.0.4）を使っているということです。IE ユーザは、75% 以上がいまだに IE6 を使っていました。
（ちなみに、Windows ユーザーは 80% 程度です。OS によらず、Firefox が浸透していることがわかりますね。）

バージョンアップにかかる手間が Firefox の方が少ないという事情もあるでしょうし、こんな辺境（？）のブログを見に来るような技術屋は、総じて新しい物好きが多いということもあるのかもしれません。あるいは、Firefox は最新版に対する信頼性をユーザから勝ち取っているといいうことかもしれませんね。

Firefox ユーザのこうした傾向は Web アプリの開発者としてはなかなかありがたいものです。テスト対象のブラウザのバージョンを絞ることができますから。

私は Sleipnir + Trident ユーザなので、大きく見ると IE ユーザですが、Web アプリは最初は Firefox でテストをしています。

まあ、結論としては、「世の中全部 Firefox になっちゃえばいいのにな！」ってところで。(^^;

最近は、Kodougu のモデリング言語設計機能の、多重度が多のメタ属性に関する実装を行っています。ちょっとわかりにくいですが、UML のクラス図に登場する属性や操作を実現するための構造を作っているという感じです。

スクリーンショット（単なる画像です。）


なぜか、属性が中央寄せになってる！ orz

こういうのは、普通のモデリング言語として実装する場合は簡単なのですが、メタモデリング言語として実装しようと思うと、いろいろと難しくなります。主に表記の自由度に関する難しさで、メタモデル上は多重度多のメタ属性として表現できても、パッケージに含まれるクラスや、クラスに含まれる属性や操作のように、メタモデル的には似たような構造でも表記はまったく異なる場合があります。モデリング言語設計機能の開発には、極力このような自由度を保持しつつ、実装が複雑にならないよう気をつけて実装しなくてはなりません。

・・・愚痴モードですが。(^^;

再来週くらいにはこの実装をアップロードしたいところですが・・・。

トホホ。とうとう、このブログにもコメントスパムがつき始めたようです。以前、Nucleus を使っていたときはコメントスパムが大量についたのですが、自作のスクリプト（Rails）に変更してからは、コメントスパムはついていなかったのですが・・・。

今は、チェックボックスにチェックを入れないとコメントできないようにしていますが、これはどの程度効果があるのやら。英数字のみのコメントは無視するとか、それともブラックリストや単語ではじくことなどを考えだした方がいいのかも・・・。あるいは、半年以上経ったエントリにはコメントできないとか。

トラックバックスパムは言及リンクチェックを入れているせいか、あまり問題は発生していません。が、最近は言及リンクチェック対策をしたスパムもある（トラックバックする前に、URL をリンク先に含めるなど）ので、油断はできませんが。

スパムのおかげで余計なコストが増えて迷惑千万なのですが、法律の整備もままならない世界なので、当面は技術的に対処するしかないんでしょうね。はぁぁ・・・。

「Ruby なんて遅くて使えない」という意見が出ます。（昔、Java も似たようなことを言われましたっけ。）これに対して、Ruby 好きな人からは、「大抵の Web アプリではボトルネックは IO になるからアプリの言語は遅くても構わない」「CPU 時間よりも開発者の時間の方が重要」というような反論が展開されます。

Rails 厨にならないためにも、ここは Ruby に批判的な目を持って、この問題を考えてみたいと思います。

■ 前提
Ruby を採用するとなると Rails 絡みで Web アプリでしょうから、Web アプリについて考えてみます。（でも、DLR とか話に出てくるわけですから、クライアントで使う場合もそろそろ検証した方がいいと思いますけどね。）

■ Ruby は遅い
以下のサイトを見るとわかりますが、場合によっては、C 言語の数十倍から数百倍遅くなります。（Ruby 1.9/YARV が出てくれば、少しは事態は改善されるに違いない・・・と信じていますが。）

The Computer Language Benchmarks Game
http://shootout.alioth.debian.org/

本当に Web アプリでは言語の速度は問題にならないのでしょうか？ Kodougu（Rails で開発している Web 上で動作するモデリングツール）で図を開く処理を計測してみました。Rails のログを見ると、サーバの処理時間のうち、40% は DB 待ちでした。一回のアクセスで、少なくとも数十の SQL が乱れ飛びます。html や javascript の生成は 40% 程度を占めています。残りは、フレームワークやコントローラで消費されています。（このログは、Rails がとっているログなので Rails の中しか計測されません。）

この手のアプリは、ネットワークがボトルネックになることが多いのですが、今回は ab（Apache Bench）を使って、並列性 1 でベンチマークをとっているので、ネットワークはそれほどボトルネックになっていないと考えています。（処理は重いので、CPU はいっぱいいっぱいでした。Kodougu がそこそこ人気が出たら、今のサーバは即パンクしますね。パンクすると困るのですが、人気が出なくても困るので・・・どうしよう。）

言語の処理速度は一概には言えないのですが、上記のベンチマークによれば、Python だと Ruby の 2 ～ 3 倍、Java だと 20 ～ 30 倍になります。たとえば、Kodougu をそのまま Java で実装すれば、パフォーマンスは今の 2.5 倍くらいにはなります。（プログラミング言語の処理速度の向上がそのままトータルなパフォーマンスには現れないところがミソです。）

もっとも、サーバを 3 台余分に準備すれば（運用コストはサーバ代、人手も合わせて年間 100 万増くらい？）、Ruby のままで同等のパフォーマンスを得られるということでもあります。最近のアプリはステートレスなので、台数はわりと簡単に増やせます。DB サーバは増やすのは難しいですが。

実際のところ、Web アプリはキャッシュを使ったりして高速化をするので、言語のパフォーマンスはアプリのトータルなパフォーマンスの中ではそれほど大きな位置を占めません。まじめに最適化してしまえば、Kodougu を Java で実装してもパフォーマンスは 20 ～ 30% 位の差しか出ないのかなと考えています。Kodougu はモデリングツールということもあって、Web アプリの中では例外的に計算的な（≒ Ruby に不利な）種類のアプリです。通常の Web アプリではもっと言語間の差が小さくなるんじゃないかなと感じています。

■ Ruby の生産性
以下のような意見があります。

日本 Ruby 会議 2007 の Dave Thomas のスピーチのログより

ある研究によれば、生産性はそれぞれのプログラマでそれぞれ違う。でも、あるプログラマに着目すれば、そのプログラマが時間あたりに書けるコードの行数は、プログラミング言語によらず決まっている、たとえば一年に50,000行なのだそうだ。行数が決まっていたら、どの言語で一番多くのことを達成できる？そう、Rubyだよね。

なるほど。そういう意味では、Ruby の生産性は高いです。通常、モデリングツールのコード行数は Java や C# で 10 ～ 100 万行程度（製品コードのみ）になります。Kodougu は 5000 行程度（製品コードのみ）です。Kodougu は Web であるがゆえに、機能的に優れた面とそうでない面とがあるので単純に比較することはできません。少なくとも生産性が 10 倍になることはありませんが、50 ～ 100% 程度の向上はあると思います。

（ただ、アプリの規模が大きくなればなるほど、Java でも Ruby でも変わらなくなる気がしますが。）

■ トータルなコストパフォーマンス
Java を使った場合と比較して、サーバ運用コスト増が開発費の 20% ～ 30% 位に収まってくれるなら、Ruby はアリだと私は考えています。保守フェーズに入ったら、サーバ運用コスト増がもっと大きくても大丈夫なんじゃないかとも考えています。

■ まよめ
さて、破滅的に遅い Ruby ですが、Web アプリで Ruby が許される本当の理由は、Web アプリの負荷の質にあります。たとえば、ゲームのリアルタイム 3DCG の処理を Ruby で書くのは自殺行為です。こうしたアプリは常に CPU に負荷をかけるアプリです。（CPU でやらせること自体が自殺行為といううわさもありますが。）Web アプリは、動的コンテンツとの割合次第ですが、キャッシュなどを仕掛ければ、たまに CPU に負荷がかかるけど、いつもは比較的 CPU が暇なアプリに分類されます。今のところ、Ruby はそういう負荷の質を持った用途で使うべきものです。

クライアントでも、Ruby が使えるかどうかの判断基準は、結局負荷の質をどうとらえるかという問題に落ち着くのかもしれません。ただ、総じていうと、サーバの CPU はいつもそこそこ忙しいですが、クライアントの CPU はいつも暇です。ゲームとかやってない限り。CPU の高速化に伴い、多くの処理が負担でなくなってきていることも事実です。Web アプリのクライアントが JavaScript でも書けることから、クライアントで Ruby が活躍できる範囲はむしろ大きいのではないかなと感じています。

そうそう、Twitter もRails を使っているそう（参考）です。リクエスト数が多そうなサービスなので、Rails を使うのはチャレンジャーだと思うのですが、意外といけているようです。凄い・・・。

長いこと積読になっていた「JavaからRubyへ」をようやく読み終わりました。（※ この本を買ったのは 4 月か 5 月。）この本は、日本で Java の案件をこなしているマネージャが読んでピンを来るものなのでしょうか。マネージャ級の人に聞いてみたいところです。

大筋要約してしまえば以下の通り。
・ Java で対処するとコストが大きくなるプロジェクトもある。なんでも Java じゃリスクが高いよ
・ Ruby（というか Rails）はその中のいくつかのプロジェクトに対処できる
・ Ruby の導入にあたって、パイロットプロジェクトの実施方法
・ Ruby の導入手順（教育、リクルーティングなど）
・ そのほか Ruby や Rails の紹介（ある意味、どうでもいい）

多分、そこそこの規模のある SI 企業であれば、将来有望そうな新技術のパイロットプロジェクトを走らせて、定量的、定性的なデータの収集を行っていることでしょう。この本の位置づけとしては、その対象に Ruby（というか Rails）を含めた方が良いという啓発本なのかも。

Amazon のレビューより（tDiary のたださんがかいてらっしゃる？）：

だいたいマネージャ層には、本書に登場するDave ThomasやMartin Fowlerの名前などなんの威光も持たない。

この本がこうしたヴィジョナリーを挙げているということは、海外では威光をもつということなのでしょうか。ちょっと気になります。誰かわかる人いないかな。

日本ではこうした改善はボトムアップに上がっていくところがあるので、この本は末端の開発者が手にとったらいいのかもしれませんね。

■ 追記（2007/6/28 5:41）
はてブにコメントがついていました。どうやら、訳者の方のようです。

はてブコメントより、「この本は、日本で Java の案件をこなしているマネージャが読んでピンを来るものなのでしょうか。」：

弊社経営陣にはリーチしました

これは素晴らしい話ですね。確かに、永和システムマネジメントさんは、Ruby に対して非常に熱心（会社として熱心）という印象があります。まったく同じというわけにはいかないのでしょうが、この本で書かれているような段階を踏んで、会社として「Ruby やりますよ」って宣言しているわけなのでしょうから、やはり凄い話です。

Rails を使ったアプリに限った話ではありませんが、ファイルをアップロードする機能を Web アプリにつけたときに、ファイルを DB に入れるか、Web サーバにファイルを保存するかについてです。

私は Web サーバに保存すべきと考えていました。Web サーバとアプリケーションサーバ（Rails のサーバ）を分けている場合、静的ファイルはWeb サーバが処理して、動的コンテンツはアプリケーションサーバが処理してというようなことをする場合があります。DB に入れると、アプリケーションサーバを経由しなくてはならないので、こうした構成が取れなくなります。ただ、Web サーバを複数台にする場合、ファイルアップロード時に全ての Web サーバにファイルをコピーする手間がかかるというデメリットがあります。（バックアップの手間も一手間増えます。）

もともと私は、DB に静的コンテンツをいれると、Web アプリのレスポンスが遅くなるという問題が発生すると考えていました。ただ、この問題は Rails のキャッシュ機構を使えばある程度回避できます。この場合、静的コンテンツも全てアプリケーションサーバが処理することになります。それぞれのサーバが DB からファイルを取り出してキャッシュをするので、ファイルの管理は楽になります。

もっとも、動画アップロード＆配信サイトとか、データ量が多い場合は、ファイル置き場とアプリケーションサーバは分けざるを得ない（ストレージにも IO にも問題が発生する可能性があるので）ので、この方法はとりづらいですが。

所詮はケースバイケースですが、一つあたりのファイルがそれほど大きくなくて、ファイルの総容量が 100GB 以内に収まるのなら（最大容量は適当）、DB に入れるというのもアリかなと思うようになりました。Kodougu では、アイコン画像などがアップロード可能なのですが、今は DB に入れています。

Ruby.NET Compiler ですが、C# などの言語との相互接続性（interoperability）を確立したようです。つまり、Ruby 上で C# で宣言したクラスのインスタンスを生成したり、C# 上で Ruby で宣言したクラスのインスタンスを生成したりできるようです。継承などがどうなるのかは試していません。

eval、パフォーマンス、日本語はどうなるのかなど、気になる点は多いですが、5 月には VS.NET 上での開発も実現しており、機能的には使えるレベルまできた気がします。

Rails を移植するつもりもあるようです。個人的には全然うれしくないですけど。長期的には意味があるかもしれませんが、向こう数年間では、.NET で Rails が動いてもそれほど意味がない気がします。Mono があるとはいえ動作する OS が制限される、gem は？、数々のプラグインは？、などなど心配事は尽きません。メリットがあるとすれば、ウェブインタフェース（オンライン処理）は Rails、バッチは C# というような使い分けかもしれません。

それに、Ruby はパフォーマンスがあまり良くないのでマシンを並列することも多いと思いますが、有料の OS はマシンごと or CPU ごとに課金することが多いので、そういう意味でも難しいと感じています。

個人的には、クライアントに可能性を求めて欲しいところです。ただ、.NET DLR の Ruby（IronRuby）との位置づけはどうなるのでしょうか。（処理系が増えること自体は、歓迎すべきことでしょう。）

（相反することをいうようですが、個人的には JRuby 上では Rails は動作して欲しいです。Kodougu を移植したいので。EMF とか使いたいものがたくさんあります。）

ま、今後に期待ということで。

いまさら、Rails の Scaffold の話です。

コントローラの宣言時に以下のように書くと、アクション（メソッド）にモデル名をサフィックスとして追加してくれます。（edit なら、edit_model_name になります。）

scaffold :model_name, :suffix => true

便利ですね・・・。AdminController とか作って、一時的に各種データの出し入れの管理画面を作るときに使用しています。

そもそも、私は Scaffold はコード生成時にしか使っていませんでした。サフィックスをつけられるなんてことも知らずに今まで過ごしていました。なんて損していたんだろうか。(--;