世界線航跡蔵

Mad web programmerのYuguiが技術ネタや日々のあれこれをお送りします。

2006年05月18日

RailsとTuigwaaの競合関係

Seasar Conferenceの懇親会でちょっと話したんだけど、TuigwaaとRailsは競合するかどうかという話題。

私は競合しないと思うよ。

Ruby on Railsとは何かと改めて言うなら、「DBをバックエンドに持ってCRUDするようなありがちな中小規模ウェブアプリケーション開発をアジャイルに進められるフレームワーク」だろう。

どうしてアジャイルに進めやすいかというと、

  • 組み込みのテストサポート
  • Unitテストは勿論、Functionalテスト、Integrationテストまで。
  • scaffoldによって開発の極初期(着手後数分)からプロトタイプが手に入って、ここからインクリメンタルに開発可能
  • Convention over Configuration
  • ありがちなケースは簡単にできる。まれなケースでも対応できなくはない
  • 「なんでもできる」を目指していないから、簡単なことは簡単にできる

これってTuigwaaの「ユーザー手動型」コンセプトとはまったく違うと思う。

Railsはあくまでも「ありがちな中小規模開発のコストを圧倒的に削減するフレームワーク」なのね。開発者が携わるのが前提にある。確かに、Railsが出てきた当初、 これだけ開発コストを下げられるなら従来は採算があわずに見送っていた非定型業務のシステム化も可能となるのではないか、っていう議論もあったかもしれない。でもそれはあくまでもrailsにとっては周辺領域であり、「やってできなくはない」であり、アウェイである。

一方、Tuigwaaにとってはそういう非定型業務のシステム化が正にその問題領域な訳で。殊、その領域においてはTuigwaaの方がRailsより優れるだろう。だって、Railsでは開発者の実装コストは下げられても、結局ユーザーと開発者のコミュニケーションコストは必要なんだもの。Tuigwaaはユーザー主導開発によって、そのコミュニケーションコストを無くすのが売りでしょ。

だから、Tuigwaaの登場によって「Railsが登場した当初、ちょっと妄想してしまった違う使いかた」は完全に食われたと言って良い。Tuigwaaが浸透するにつれて社内向けのツールに関しては、それがある程度定型な業務であっても「それTuigwaaでよくね?」って言われるようになるだろう。でも、それでも当分の間は専門知識を持った開発者が必要な規模、領域というのは残る。そういう開発対象こそが、Railsの本来の用途でしょ?

トラックバック

http://yugui.jp/articles/435/ping

現在のところトラックバックはありません

コメント

blog comments powered by Disqus

ご案内

前の記事
次の記事

タグ一覧

過去ログ

  1. 2016年07月
  2. 2016年01月
  3. 2015年09月
  4. 2015年08月
  5. 過去ログ一覧

フィード

フィードとは

その他

Powered by "rhianolethe" the blog system