高橋征義です。

akira yamada / やまだあきら <akira@a...> wrote:
> Masayoshi Takahashi wrote:
> > なお、DebianとRailsの情報については、
> > http://wiki.rubyonrails.org/rails/show/RailsOnDebian
> > http://wiki.rubyonrails.org/rails/show/HowtoInstallCompleteRubyOnDebian
> > http://wiki.rubyonrails.org/rails/show/RailsOnDebianUnstable
> > などがあるようです。
> 
> どうしてDebianなのかよく分かってませんが
> これらの情報はunstable環境については古くなってきています。

どうしてDebianなのかは、たださんが[rails:91]で、

TADA Tadashi <sho@s...> wrote:
> 環境はDebian sargeです。

と書いていたからで……というのはさておき、Unstable環境の
話は上記の三番目のURLのページ冒頭で触れられている内容で
合ってますか？

> > ↑この資料に従って説明をしたあと、どうしてRailsがこういう風になって
> > いるのか(なぜData MapperパターンではなくActive Recordパターンを
> > 使っているのか、なぜテンプレートエンジンではなく素のERbを使って
> > いるのか、等々)、weblogやMLの情報を思い出しながら推測も交じえて
> > しゃべってきました。
> 
> 「どうして」から「交じえて」までの内容が気になります。
> どこかにレポートはありますかね?

かずひこさんのメールにもありましたが、この辺はアドリブで
しゃべっていたこともあり、私自身手元に記録がないのでした。
詳しいレポートもないようですね。

あやふやな記憶を頼りに箇条書にすると、

・Ruby on Railsはとにかく「DRY(Don't Repeat Yourself)」が
  重要とされている(トップページでもそう書いている)。
・例えば、DBのスキーマに修正があった場合、設定ファイルも
  プログラムも修正が入るようなものはDRYじゃないから駄目。
・そのため、プログラムはDBのスキーマ情報を読みとって
  dynamicに変更されるべき。
・でも、Data Mapperだと設定ファイルが必要なこともある。
  DBのテーブルとObjectが1:NとかN:Mとかだと設定ファイルと
  プログラムをDBの変更に追随させることは困難。
・そこで発想を転換する。Data MapperではなくActive Record
  にすれば、テーブルとObjectが1:1対応になるので問題は
  解決する。
  (Data MapperとActive RecordについてはPoEAA参照。)
・でも、テーブルとObjectを1:1にするのは可能か？
  --Web Applicationであれば、かなりの場合対応可能ではないか。
  そもそもWebアプリは既存のDB設計に引きずられにくい。
  純粋なWebアプリではクラスもDBも新規に設計できるし、
  バックエンドに基幹系があっても密結合は普通避けるはず
  (バッチかなにかを使って同期させるのであればそこで
  ギャップを吸収するとか)。もちろんそれでは駄目な場合も
  あるけど、2割:8割の法則は適用できそう。
・だから、ActiveRecordは「あらゆるDBをあらゆる
  クラス構造にマッピングさせるためのツール」では
  ありえない。
・それでも、RailsのActiveRecordは、PoEAAのそれよりリッチ。
  テーブル間の関連なども表現できるし、before/afterで
  テーブル固有の処理も加えられる。
・さらに、「Convetion Over Configuration」に基づけば、
  設定を極限まで(場合によってはゼロにまで)減らせられる。
・(もっとも、テーブル名の複数形の規約はどうかと思うけど)
・しかし、いつでもゼロになるわけではない。DBで全ての情報を
  記述できるわけではない以上、それ以外の場所で設定を
  記述する必要がある。
・とはいえ、そもそもプログラムのコードが設定であるべき
  なのでは？
・しかし、通常のコードは設定ファイルほど見やすいもの
  とは言えない。
・でも、Rubyなら設定みたいな見やすさでコードが書ける。
  一種のDSL(Domain Specific Language)風味。
  これはJavaなどの言語ではできない。言語重要。
・だからJavaでRailsをやる試み(Trailsとか)は、Rails
  ほどは成功しない。また、S2Daoは、ActiveRecordほど
  見やすくはなれない(Seasarの限界というより、Javaの
  限界)。

……といった感じだったはずです。

そういえば、これを書いて思い出しましたが、Railsでは
関数風メソッドをいろいろ使っていて、その「見やすさ」こそが
Rubyの重要なメリットである、と認識しているような気がします。
例えば↓こういうの、ですね。

  class Project < ActiveRecord::Base
    belongs_to              :portfolio
    has_one                 :project_manager
    has_many                :milestones
    has_and_belongs_to_many :categories
 
    validates_presence_of   :name, :description
    validates_acceptance_of :non_disclosure_agreement
    validates_uniqueness_of :key
  end

Ruby2.0の議論は追いかけきれていないのですが、こういうのに
「self.」をつける必要が生じるとすると、大問題になりそうです
(私の誤解かもしれませんが……)。

高橋征義 (Masayoshi Takahashi)   E-mail: maki@r...

--
ML: rails@r...
使い方: http://QuickML.com/