えー、Wicketいいとか、Tapestryやろっかなーとか言いながら、結局Railsやってるわけで。
 でもイイものはイイ！やらなきゃわからん。
危うく人生の無駄な時間を増やすところだった。
とか言い過ぎかもしれないけど、そのくらいいいです、Rails。

でも実はDjangoとTurboGearsにも目が行ったり。
パフォーマンスがねー、Railsはねー、ていうかRubyはねー。
その点Pythonならまだ大丈夫そう。
これはかなり衝撃的な結果↓
FasterCSVのベンチマーク

ここでもRubyは遅いと言われちゃってますね。10倍とか50倍ですか。まあそうでしょうね。
Rubyはパフォーマンス懸念がなければ、日本発言語としてぜひ推したい。
だけにちょっと悩ましい。でもまあ、きっと使いますけど。
ていうかある案件でRubricksというCMS（これも日本発。推したい）を
使うことを決定したのは私ですが何か？

以下、またもや○×メモ。最近こればっかだなー。

とりあえずRuby on Rails、Djangoを思いつきで比較してみます。

■Ruby on Rails（一部Rubyの特徴）
○　フルスタック（プレゼンテーション〜DB、テストまでカバー）
○　ActiveRecordが潔い。迷うことなく代理キー（複合キーも対応できますが。別で書きます）
○　プラグイン機構が素敵（LoginEngineは感動。RadRailsのPluginビューのGoボタンも）
○　情報量（というか人？）が多い＝人を調達しやすい
○　Active Web Serviceが楽チン
×　1プロジェクトで複数アプリケーションを作ろうとすると困る（ARだけ共有したいとか）
×　シンタクティック・シュガーが多い＝同じことやるのに書き方いっぱい
　　ある意味よいのだが、保守性は下がる
×　パフォーマンス遅い。Webアプリならインフラ／NW構成と共に回避できそうだけど、
　　単一サーバとかだと絶望的？ていうか今回そうなりそうなんですが。。。
×　ARは参照整合性を張ってくれない（新規作成ならあんまり困らないけど）


■Django（一部TurboGearsにも言える）
○　フルスタック（Railsのような機能テスト、統合テストがあるかは未確認）
○　SQLObjectがイイ！ちゃんとリレーションを参照整合性制約として張ってくれるっぽい
○　パフォーマンスの心配はなさげ。こことか
○　1プロジェクトnアプリケーションが最初から考慮されてる
？　Ajax対応が楽そう？（特にTurboGearsにはMochiKitが組み込まれている）未確認
？　複合キーイケる？未確認
？　Railsのプラグインみたいのは？未確認
×　情報量（というか人？）がまだ少ない＝人を調達しづらい


まだまだ知識の少ない状態で書いてる&途中で眠くなったので、とんちんかんなことを言ってる可能性アリ。
ツッコミ大歓迎ですので、指摘・反論ください。