Rails はフルスタック！

Rails

「Ruby on Railsのどこがすごいのかわからない」に遅レス。「あとで書く」つもりだったが、つい勢いでグダグダ書いてしまった。キレがないのはいつものことです。疲れてるのに眠いのに。土日に読まれるエントリ書いてもブクマ効果薄いのに。耐性がないからです。各種用語にリンクは貼らないよ。"rails" とセットでググってたもれ。


「Railsな考え方」3つの点、

  • DRY
  • 規約重要
  • 言語重要

のうち前2つは、今となってはほとんどのフレームワークでクリアされてます。最後のは特異で面白い点ですが、他の言語の方にとっては言っても栓ないことなんで控えます。その言語が好きで使ってるでしょうから。
この3つは今となっては、まぁ今となっては、声高に主張することではありません。高橋さんも残るのは言語重要と言ってましたから、ほとんどの Rails を嬲ってる人達の見解は一致しているのではないでしょうか。


http://d.hatena.ne.jp/nowokay/20051208#c1134105144

# nowokay 『「Railsな考え方」見たことあります。
で、「規約重要」というのは、「暗黙の了解」っていうのが学習コストを高くしてしまうのとフレームワーク自体の仕様変更に弱いのであまり好きではありません。「規約よりウィザードで設定生成」の方が好きです。
DBから動的にCRUDというのは、Hibernateベースで作ったりしてみたのですが、それだけではあまり素敵ではなかったです。カスタマイズがいかに簡単にできるかが大切かと。
マッピングの自動定義部分はこれです。
http://www.fk.urban.ne.jp/home/kishida/kouza/hibonrails.html
だから、そこの３点で同意できるのは、「Rubyはいい」ってところだけなんです。
もちろんいろいろな方向性を与えたということは素晴らしいと思うのですが、じゃあ、今どうなのかと思うんです。』

規約は「暗黙の了解」ではありません。規定されてるから規約。ちゃんとドキュメントを読めば書いてある。Catalyst のように自由度が高くいがやることが大体決まってくるなら「暗黙の了解」と言うべきかも知れませんが。
学習コストを問題にしてますが、どの人の Rails プロジェクトを見ても同じ構成・やり方というのは、学習・保守のコストを大きく下げます。あ、vendor に入っているから追加インストールしたんだなとか。


「フレームワーク自体の仕様変更に弱い」はちょっと意味がわかりません。MVC でなくなるとかそういうことを意味してますか？　それなら Rails を使うべきではないでしょう。Rails は「いわゆる Web アプリケーション」を想定してます。選定時に向いてなさそうなら対象から外すべきですね。
ある程度の「仕様変更」は Ruby の動的さがクリアしてます。高橋さんに密結合・疎結合の話でも聞いてください。私は Java は使ったことがないので言及できないんです。C# なら話できます。C# でこんなに簡単に拡張(既存クラスにメソッド追加とか！)はできない。達人がリフレクションのアクロバティックな技を使えばできるかもね。


「規約よりウィザードで設定生成」は何とも言えませんね。ASP.NET の開発経験ならあるのですが、それと同じようなものでしょうか？　その道でフルスタックのフレームワークを作ったら面白い？かも。良くわからんが期待 age！


さてと、やっと道半ば……。本題の私が一押ししたい点は、
Rails が「フルスタック」である
ということです。


まず、
1. コンポーネントがフルスタック！
Model, View, Controler それぞれに、ActiveRecord, erb, ActionPack(?) といった標準が存在します。標準は(言うまでもないですが)学習コストを大きく下げます。それだけ覚えれば作れますからね。選定ってかなり気を使って時間のかかる作業ですよねー。あーでもないこーでもない、一長一短・メリットデメリット…。悩む時間を節約できるっていい事です。Catalyst は多すぎです。
……話が逸れました(得意！)。コンポーネントはその他に Web サービスやメールに関するコンポーネントも標準で同梱されますので大抵のものは作れるでしょう。Catalyst は多すぎです(しつこい)。


フルスタックはコンポーネントに留まりません。
2. 開発環境がフルスタック！

  • ウェブサーバー
  • コードジェネレイター
  • デバッガ
  • テストツール
  • ベンチマークツール
  • プラグイン導入ツール

あと、prototype.js, script.aculo.us 同梱とかもね。sqlite とかまで付いてれば完璧ですね。


今回の趣旨(フルスタック)から外れますが、ツールの手触りや Rails に促される開発プロセスが Agile の触り心地です。Agile の匂いがプンプンです。玉緒ではありません。最初の Rails 本は、その名も『Agile Web Development with Rails』です。あの『達人プログラマー』Dave Thomas が共著なんですから、Agile にならないわけがありませんね。「Rails is Agile!」や「Is Ruby Agile?」の話題は他の人に譲りましょう。


達人プログラマー―システム開発の職人から名匠への道ちょっと休憩。


実は、今、私が最も Rails を押したい理由は、保守・運用を見据えた周辺ツール群にあります。アツイ！
3. 保守・運用もフルスタック！
この点が Catalyst やその他の類似フレームワークから(今のところ)一歩も二歩も抜きん出ていると思います。
具体的には、

  • rake
  • migrate
  • about

rake は Ruby 版 make ……と言われますが、もっと多機能なのでちょっと外した表現だと思います。
migrate は rake と generator に仕込まれていて、DB のスキーマ管理ができます。イイ！　今現在私がお仕事で開発している Catalyst プロジェクトにも使いたいほどです(依存が増えるので結局やめた)。
about は各種環境を報告するだけのスクリプトです。こんな：

$ ./script/about
About your application's environment
Ruby version                 1.8.2 (i386-cygwin)
RubyGems version             0.8.10
Rails version                0.14.3
Active Record version        1.13.0
Action Pack version          1.11.0
Action Web Service version   0.9.3
Action Mailer version        1.1.3
Active Support version       1.2.3
Application root             /cygdrive/e/home/babie/history/20051210/test
Environment                  development
Database adapter             mysql

たったこれだけの単機能スクリプトですが、私はこれこそが Rails が保守や運用を支援していく姿勢を端的に表していると考えます。

  • 運用・保守のドキュメントでまず必要なものは？　はい、一丁あがり。
  • バグがでました。Rails に原因がありそうなので ML に質問します。質問するなら環境書けとお叱りを受けます。はいOK。

何か良くね(イグネ)？　気が利いてね(キイデネ)？


あと、デプロイツールである SwitchTower も挙げておきます。同梱されてませんし開発途中ですが Rails での標準の多機能デプロイツールになると目されます(お膝元で作ってるからね！)。保守！運用！保守！運用！


終わったー！まとめー！　1, 2, 3 がフルスタックなのは Rails だけ！　総合的に考えてもらいたいです。もはや、フレームワークとは呼べない！「環境」(エンヴァイロンメント)とユいたいです！　いや、「世界」(ダ・ワールド)と叫びたい！


これ以上は触ってもらわないとなんとも言えませんねぇー。言を尽くしても無理。電波絞りつくしました。ていうか私なんかよりもっと経験豊富で語るに相応しい人がいるのですが、そんな人は言葉を出す暇があったら成果を出していくので私が書きました。とにかく次の話は触ってから。触って触って。


しかし、まぁ、なんだかんだ言って、他の言語でも頑張ればできるので、結局最後に残るのは「言語重要」かもね。


あ、これ忘れてたｗｗ。「Why Ruby on Rails?」リンク先はちょっとズルイですが、フルスタックってこういうことでもありますね。

Agile Web Development With Rails: A Pragmatic Guide (The Facets of Ruby Series)プログラミングRuby―達人プログラマーガイド