パーフェクトRuby on Rails読書メモ

パーフェクトRuby on Railsを読んで学んだことをメモしていきます

パーフェクト Ruby on Rails

１章　Ruby on Railsの概要

rakeコマンド

rakeはmakeのruby版という覚え方をしているのですが、『実際のところその他の定型処理を実行するためのコマンドとして利用されることもよくあります。』という記載で理解が深まった気がしました。「rake task名」と思っておくと良いのかな、と。

そしてそのtaskを定義しておくのが、Rakefileで、

desc 'タスクの説明'
task タスク名(シンボル) do
  タスクの処理内容
end

という形で定義出来るようです。定義したtaskの一覧はrake -Tで確認出来ます。descの内容がrake -Tので出てくるタスクの#以降の記述になる、ということも知りました。

ちなみに、Railsで最初から出来てるrakeタスクの定義が見たいなーと思ったのですが、 Rakefileには

 require File.expand_path('../config/application', __FILE__)
 
 <%= app_const %>.load_tasks

こういう形でしか書かれていなくて、load_tasksを調べてもどこに定義されてるのか分からずでした。。。

migrationファイル

Railsチュートリアルの中でこれまでrake db:migrate などを実行したことはありましたが、migrationファイルの中身についてはあまり掘り下げたことが無かった気がします。

• migrationファイルはDBの操作を行うもので、作られるファイルは複数人での開発でもファイル名が重複しないようにファイル名に数値が付けられる
• 自分で定義したもの以外に「t.timestamps」が自動的に記述されていて、これは「created_at」と「updated_at」を作るもの
• さらにidがmigrationファイルに書かれることもなく定義される
• rake db:migrateを実行するとmigrationファイルの内容が実行されるが、migrateの実行状況はschema_migrationsテーブルで管理されているので、同じCREATE TABLE文が何回も実行されるようなことはない
• rake db:migrate:statusを実行すると状況が確認できる

sqlite3コマンドを使うと実際に流れたCREATE TABLE文が確認出来るということです。

sqlite3 db/development.sqlite3 ".schema テーブル名(複数形)"

sqlite3のコマンドについては全く触れたことすらないので、別途学習が必要です。。。

PATCHメソッド

よちよち.rbでも話題になったのですが、Rails4.0からupdateアクションに対応するHTTPメソッドがPUTからPATCHになったようです。

PUTとPATCH、何が違うの？というのがいまいち分かっていなかったのですが、この内容がコラムに書かれていました。

PUTは「リソースの置き換え」を意味して、PATCHは「リソースの部分更新」を意味するということで、大体のupdateアクションはリソースそのものを置き換えるというより、リソースの一部（例としてUserリソースのパスワードが書かれていました）を更新するものなので、PATCHの方が適切、ということなのかな、と理解しました。

2章　Ruby on RailsとMVC

とりあえずP54の「モデルを操作する」の前まで読みました。とりあえずモデルの話から。

ActiveRecord::Relation

正直、Railsチュートリアルもまだまだ途中の自分にとって、若干時期尚早感が初っぱなからありましたが、せっかくなので、とりあえず読んでみてます。

モデルのクラス（ActiveRecord::Baseを継承しているだけの今のところ空っぽのクラス）でもActiveRecordのメソッドを使ってデータの操作が出来ます。とりあえず出てくるメソッド名はほぼSQLそのまま感が強いので、抵抗なく使えました。

さらにこのメソッドたちは、重ねて使う（チェーンさせる）ことが出来て、これをQuery Interfaceと言うそうです。あとで読む

Query Interfaceによる操作結果は、ActiveRecord::Relationのオブジェクトとして扱われます。

ここからは、ちょっと自信なくて、今後いろいろやりながら理解を深めたいところですが、解説の文を読んだところでは、一度作ったActiveRecord::Relationのオブジェクトに、さらにQuery Interface（要するにSQL）を加えられるので、一気にSQLを書くのではなく、組み立てて最終的に出来上がったSQLを流す、みたいなことが出来るようになる、のかなと思いました。

若干内容についていけていない部分があったので、もうちょっと経験を積んだ後に読み直したいです。

scopeを定義する

よく使う条件などは名前を付けて呼び出すことが出来るようです。

Book.costly.written_about("Java")

みたいな書き方が例として記載されていました。これのcostlyとかwritten_about("")の部分を事前にモデルクラスに記載しておくことで、便利かつ可読性の高い書き方が出来る、ということのようでした。しかもこの結果もActiveRecord::RelationとなってQuery Interfaceの流れに乗れるみたいです。各モデルクラス用のメソッドを実装するみたいな感じなのかな、という印象でした。

ちなみにdefault_scopeという指定で常に適応される条件も指定出来るようですが、使いどころには注意とのこと。確かに落とし穴になりやすそう。。。