2006-02-18 (Sat) [長年日記]

_ WebObjects versus Ruby On Rails! はてなブックマークに追加 del.icio.usに追加 MM/Memoに追加

WebObjects versus Ruby On Rails!

CAWUG(Cocoa And WebObjects User Group) のミーティングで出た WO vs RoR の話。

詳しい話は後日資料がアップされるらしいので、待ちましょう。

で、ここで取り上げられてる Rails の欠点は

  • Rails はデフォルトではセキュアじゃない
    • 全ての public メソッドが Web 経由でアクセス可能
    • フォームから情報を受け取るとき params という Hash を経由するので is_admin みたいな属性があることを予測されるとそれを inject されて admin 権限でアプリにアクセスできちゃう
  • SQL っぽい言語を使って Model を手書きせにゃいかん (has_many とか migration で使う create_table とかのことだろうか)

ということだそうな。

最初の話は、注意深く使うなりチェックするなりすれば済む話だなぁ。

そんなこと行ったら WO だってデフォルトではセッション ID が URL に 表示されるのでセッションハイジャックの危険性があるし。

WO は生成される URL とかフォームの name が何だか意味不明の 数字の羅列(Context ID とか Component ID って言うの?) なので変なデータを流し込むのは難しいのだけど、その分 URL が汚かったり URL に "WebObjects" って入るのが嫌。 rails みたいに意味がわかりやすい URL の方が多少セキュリティ的に 気をつける点が増えたとしても絶対良い。

WO の話じゃないけど、 commons の BeanUtils.populate とか使うときも 同じ問題はあって、ここも楽した分の自己責任で、必要に応じて 変なデータが来てないかをチェックする必要が出て来る。

2 番目の話も善し悪しだなぁ。エディタだけで書けちゃうってのは利点でもあるし、 エディタで書かなきゃいけない割にはかなり記述量少なくてがんばってる方だと 思う(まぁ、Convention に従っていれば、という制約つきなので、状況によっては ものすごく記述量が多くなって rails のメリット全く発揮できないこともありますが)。 WO は EOModeler やら WOBuilder やら Xcode/Eclipse が動く環境じゃないと 使い物にならんし。そして、 WOBuilder は不安定だし。

個人的に Rails を業務で使う上で問題となりそうだと思う点は やはり View がモロに ERB なところだと思う。デザイナーとの分業が 非常にやりにくいんじゃなかろうか。 Amrita2をRuby On Railsで使用する方法とかを使わないといかんね。

WO には一応 10 年の実績とか蓄積とかがあるので、 その辺の(なんの根拠もないけど)安心感があるのが良いけど、 何度も言うように、WO は Java の制約を受けてしまう点とか そもそも Apple に放置されてさっぱり新しい仕様などに対応できてない点が 今後どんどん問題になりそうな気がする。

私の現時点での印象。 今はまだ WO の方が安心して使えるけど、あと数年したら完全に rails かな、 って感じ。 Apple さん、お願いだからがんばって。XHTML/CSS 対応とか Java 5(6?)対応とか AJAX 対応とか開発/テスト/デプロイで簡単に DB を 切替えられる機能とか。

追記

あぁ、そのプレゼンやったのって、 15分で作る WebObjects Blogの人じゃん。

Permalink | このエントリを含むはてなブックマーク | このエントリをはてなブックマークに追加 | このエントリを含むMM/Memo | このエントリをMM/Memoに追加 | このエントリを含むdel.icio.us | このエントリをdel.icio.usに追加 | Tags: wo rails

_ Joel on Software はてなブックマークに追加 del.icio.usに追加 MM/Memoに追加

Joel on Software ジョエル・オン・ソフトウェア Joel on Software ジョエル・オン・ソフトウェア

印象に残った点

  • 打ちながら前進(援護射撃)重要。また、相手の「打ちながら前進」 に翻弄されないことも重要。
  • 「スクラッチから書き直し」は厳禁
  • 客にとっては見た目が命。見た目がしっかりできていたら、 中身が全然できてなくても「もうほとんどできた」と思われる。 まだ中身の実装ができてないうちは、中身ができてないことを わからせるために、仕様書などでは敢えてショボい見た目を見せるべし。
  • 新しくプロジェクトを始めるには、その分野やツール/ライブラリに 少なくとも 3 年は経験がある人を 1 人でも入れるべし。
  • 過去との互換性重要
  • 車輪の再発明は悪いことではない。自分の個性を発揮するキモになる 部分はたとえ再発明であっても自分で作らないといけない。
  • マニュアル化は平均的なものを作るのには大事だが、平均以上のものを 作れないとか能力のある人間をいらつかせるという欠点がある
  • 付属物の値段が下がると、中心となるものの需要が上がり 値段が上がる(可能性がある)

感想

結構くだらないというかしょーもない話もあるのだが、 C とかアセンブラなどの下の階層の話から、コンピュータ業界の 世間話とかマネジメントとか経営とかの上の層の話まで非常に 話題が広範囲に渡り、タメになる話もいっぱいあった。

というわけで、プログラマーにもマネジメント層にも経営者層にも オススメの 1 冊。

Permalink | このエントリを含むはてなブックマーク | このエントリをはてなブックマークに追加 | このエントリを含むMM/Memo | このエントリをMM/Memoに追加 | このエントリを含むdel.icio.us | このエントリをdel.icio.usに追加 | Tags: book
[]