Railsチュートリアル(第四版)学習記録: 2章

cloud9であれば”rails tutorial”を選ぶのか、”rails”を選ぶのかにより変わるのですが、僕は”rails tutorial”の方を選んだので、またrailsのインストールから始める必要があります。インストールして、newで新しい骨組みを作ります。

続いてusersテーブルを作る準備をしていきます。usersテーブルにはid, name, emailの3つのカラムがあります。それぞれデータ型はinteger, string, stringです。この辺はpostgreSQLを勉強した時にもたくさん出てきたので記憶に新しい。続いてmicropostsテーブルにはid, content, user_idの3つのカラムがあります。このテーブル固有のカラムはcontent(つまりは投稿内容)だけなのですが、一人のユーザーに対して複数のcontentが紐づいている、ということを表す際にusersテーブルのprimary keyが必要になるのでこちらのテーブルではforeign keyとしてuser_idを使っているようです。簡単にいうと、user_idを含めることによって同じカラムを含むusersテーブルを参照しやすくなるという感じです。

scaffoldに関してはよくわからないんですが、とりあえずはデータモデルを作ってくれるようです。ですのでname:string, email:stringのようにデータ型を指定してモデルを生成した後、このデータベースをマイグレートする必要があります。簡単にいうと、先ほど打ったコマンドでモデルの骨組みを作ってrails db:migrateコマンドで実際に変更を実行するようなイメージです。

scaffoldの仕組みが今わかりました(笑)。試しにコントローラ・ビューを見てみましょう。先ほどのscaffoldによってこれらが自動で作成されるんですね。実際に、ルートだけではなく、(/user)や(/user/:id)などが追加され、表示されるようになりました。

この章のMVCの説明が本当にわかりやすいですね。まずはURLでリクエストを送り、ルーティングで適切なコントローラ・アクションに振り分ける。コントローラのアクションの命令によりモデルからデータが取り出され、アクション内のインスタンス変数に代入される。その代入されたインスタンス変数をビューに渡す。ビューが起動し、htmlを生成する。そして最後にビューに返す、という流れでした。

次にrestful構造っていうのが出てきましたね。これ一周目の時いまいちわかっていなかったんです。調べてみると、railsにおけるrestとはアプリケーションを構成するコンポーネント(今回だとユーザーやマイクロポスト)を「リソース」としてモデル化することを指す、そうです。ここでいうリソースとは「データモデルとwebインターフェイスが組み合わさったもの」でつまり、http経由(postやgetやpatchやdelete)経由で自由に作成や編集、削除ができるデータ群のことらしいです。

ここまではリソースの説明。ではrestとは??この記事(qiitaのrest記事)がわかりやすかったです。これによるとrestとはアプリを構成するコンポーネントをrdmsのcrudとhttprequestの各メソッド(post,get, patch, delete)に対応させてリソース(自由に作成・編集などができるもの)として扱うアーキテクチャのことらしいです。80%理解。。

おお、ここでまたルーティングに出てくる”resource” の意味が理解できました。これがリソースか!!このresources “microposts”の中に先ほど述べたデータモデル、httprequest、対応するアクションが含まれていたんですね。アハモーメントです。

そしてここも前回実は曖昧な理解だったみたいなので言語化しておきたいのですが、models/micropost.rbにvalidateを記述します。これはそもそもmodelsの中のファイルはマイクロポストモデルを弄るものなので(つまりはデータベースと直接やりとりが可能)、ここにデータベースにはどんなデータを入れるのか、入れてはいけないのかを記述する必要があるんですね。本日二度目のアハモーメント。

次もまたmodel関連ですね。user.rbにはhas_manyをmicropost.rbにはbelong_toを記述します。これも非常にわかりやすいですね。各ユーザーはたくさんのマイクロポストを持つことができますが(has many)、micropostは必ず一人のユーザーに属します。(belongs to)説明に何度か登場してくるactiverecord, 調べたけどいまいちわからないですね。 どうやらobjectとrdmsを繋ぐものらしい。SQLを意識せずにデータベースを扱うことを可能にしているそう。allとかdestoryとかもこのactiverecordによってできているらしい??一応理解の参考にしたのはこの記事です(qiita記事)

続いては継承についての説明ですね、中身がこい。まず今回のアプリケーションでのモデルの構造関係としては最下位にUserとMicropost、その上にApplicationRecord,さらにその上にActiveRecord::Baseがあります。activerecordを継承することによって作成したモデルはデータベースとやりとりできるようになります。コントローラも基本的な考え方は同じ。

無事2章の二周目も終わりました。一周目をやった時よりだいぶ一つ一つの理解に時間を割けているのでただの写経ではなく、コードの一つ一つの意味を理解し、わからないところをググりながらできている気がします。今後も理解を深めていくことを第一目標に、アハモーメントをたくさん味わいたいです。

シェアする

  • このエントリーをはてなブックマークに追加

フォローする