さて。以前からチェックだけしておいた Rails を今月に入ってちょこちょこいじり始めている。

春先に PHP でオレオレフレームワークのかけらほどを作ってみた経験があったので、以前のようにあまりにぼんやりと「なんか便利らしい。ふーん。」程度の認識ではなくなっており、半ばなんぼのもんじゃいという奢った気持ちで手を出してみたら、これが全然訳分かんない。

いや正確には手順に従えばいいっていうのは分かっていて、従った場合には何が起きているのかは分かる。でもなぜその動作をするのかと、示された手順から踏み外した場合にどうすればいいのかがよく分からない。甘く見てました。

そもそも手元のがすでに古くなってきている。1.0 前の記述であり、migration は付録扱いだし、migration は 1.1 で generate model とうまい具合に統合されているし、rake migrate は deprecated だし、この段階でかなり話が噛み合ない。おぉう。もちろん基本の構成は変わっていないので十分通用するんだけど、いちいち出てくる手順で mysql のコマンドを直叩きしてくれちゃっているので、雰囲気が結構違う。やばい、早くやっつけてしまわなければ。

以下、思ったこと。

• 最初のうちはまず model を generate しろ
  • migrate のひな形も作ってくれるので Rails の「意図」を理解しやすい
  • model は単数形
  • てことはやはり modeling がかなり重要な予感
  • 失敗した！と思ったら destroy model Modelname で ok
  • 逆に要るものをうっかり destroy すると結構悲しいのである程度の形になったらさっさとバージョン管理する
• scaffold は migration を書いて rake db:migrate してから
  • でないと旨味半減

• どういう便利メソッドがあるのかよく分からねぇ
• script/console チョー素敵
  • helper って特異クラスなのねチョーかっこいい
  • でも model の方は ActiveRecord::Base を、controller は ActionController の方を覗いて行く必要あり。まぁそれでいいか。

• database.yml の adapter は require するものを書く
  • sqlite3 が使いたければ sqlite3 と書く。sqlite だと使えない
  • この設定はサーバを再起動しないと反映されない
  • migration の際には ruby がゼロから起動するので反映される。気づきにくい。

• model でデータの絡む処理を、controller で URI の定義を行う
• flash にしびれるぅ、あこがれるぅ
  • 次のリクエストでサクっと使えるっつーのはニクいなぁ、こうきたか。