Rails Tutorial意図せず2週目(第2章 Toyアプリケーション)

背景

1周目第13章途中でどうしても問題が解消できなくなり、gitでソースコードを戻してもDBの状態が戻らない、Herokuにデプロイはできるがアプリケーションが表示されない等の問題達にぶち当たったため、意図せず2周目を開始することに。
今回は丁寧にわからない用語等あれば拾いつつ復習していこうと思います。

第2章 Toyアプリケーション

この章では、1章同様シンプルなアプリケーションを作成〜デプロイまでを行いました。
その中で特徴的だったのが「Scaffold」コマンドです。これを行うだけでMVCアーキテクチャのModel, View, Controller全てが準備されるという強力なコマンドです。ここから先の章では強力過ぎて問題を切り分けられなくなるため使わなくなるほどの強力なものでした。1
今回の章で初めてDBにも触れることになり、初歩的ではありますがRails+DBというアプリケーション構成を作れるようになりました。

以下1周目はスルーしていた概念やコマンドの意味を調べる

bundler

本章では以下の形でbundlerを利用しました。 しかし、bundlerとは何なのかわからなかったので調べてみました。

$ bundle _2.2.17_ config set --local without 'production'
$ bundle install
$ bundle update

【結論】

  • bundlerは大量のgemを利用するRailsプロジェクトの中でgemの依存関係をきれいに整えるプログラムである2
  • 以下のような便利機能が沢山ある
    • bundleコマンドを利用することでGemfile中のgem設定をGemfile.lockに書き込み環境を整えることができる
    • bundleコマンドを利用することで一部のgemを本番環境だけに適用する設定ができる

また、古い記事ではあるもののbundlerについての整理がよくされていたため記事を貼っておきます。

qiita.com

Scaffoldコマンド

本章以降は使用禁止となったscaffoldコマンド、強力すぎる感覚はつかめたものの何が強力なのか改めて調べてみました。

本章では以下のようにUser table/model/controller/view を一行で作成しているように見えました。

$ rails generate scaffold User name:string email:string

Railsガイド v7によるとrailsにおけるscaffold(足場)とは以下のことを指すようです。以下引用です。

  • Railsにおけるscaffold(足場)とは、「モデル」「モデルのマイグレーションファイル「モデルを操作するコントローラ」「データを操作・表示するビュー」「それぞれのテストファイル」一式をさします。

【結論】

  • 1点私の勘違いがあり、railsのscaffold(足場)は「テストファイル」も含めたものだったことがわかりました。一瞬で大量のファイルが生成されるためにテストファイルの生成を見落としていたんでしょう。
  • 上記の定義を見ると、その後model, migration file, controller, test fileを別々にコマンド生成しているのがバカバカしくなるほど強力です。一方で、これに頼ってしまうと自身のミスの切り分けが難しくなるというrails tutorialの判断は正しいと私も思いました。
railsでのバリデーションについて

本章で初めて入力に対してRails側でバリデーション(制限)を設定しました。(以下、例)
バリデーションは入力される内容を制限することでアプリケーションのセキュリティ上の安全性を高めるものです。本章ではモデルでバリデーションが行われていましたがその理由やそもそものバリデーションの重要性を確認するために、調べてみました。

[例: /toy_app/app/models/user.rb]

class User < ApplicationRecord
   has_many :microposts
   #  name属性に空入力を許さない(入力必須にする)
   validates :name, presence: true
   #  email属性に空入力を許さない(入力必須にする)
   validates :email, presence:true
end

Railsガイド v7 「Active Record バリデーション」によるとモデルでバリデーションを行う理由は以下となります。(引用)

  • バリデーションは、正しいデータだけをデータベースに保存するために行われます。
    • モデルレベルでのバリデーションは、データベースに依存せず、エンドユーザーがバイパスすることもできず、テストもメンテナンスもやりやすいためです。

【結論】

  • バリデーションは重要!(当然)
  • モデル以外にもデータベース制約やクライアント側(フロントエンド)でのバリデーションも存在するようですが、上記Railsガイドによるとそれぞれのメリット・デメリットがあるようです。
  • 今回利用したモデルでのバリデーションがRailsにおいては一般的なもののように上記資料からは伺えます。
railsでのオブジェクト間の関連付けについて

本章でDBの関連付けのためにコード上に以下のような記載を行いました。
以下の例のようなコードを書きましたが、他にどのような書き方や関連付けがあるのかActive Recordについて調べてみました。

  • belongs_to
  • has_many
[例: /toy_app/app/models/micropost.rb]

class Micropost < ApplicationRecord
  # MicropostはUserに紐づく(多対一の関連付け)
  belongs_to :user
  validates :content, length: { maximum: 140 },
                      presence: true
end
[例: /toy_app/app/models/user.rb]

class User < ApplicationRecord
   # UserはMicropostのオブジェクトを複数保有可能(一対多の関連付け)
   has_many :microposts
   validates :name, presence: true
   validates :email, presence:true
end

これもまたRailsガイド v7「Active Recordの関連付け」にドンピシャの記事がありました。以下引用です。

  • Railsの「関連付け(アソシエーション: association)」は、2つのActive Recordモデル同士のつながりを指します。モデルとモデルの間には関連付けを行なう必要がありますが、その理由はおわかりでしょうか。関連付けを行うことで、自分のコードの共通操作がシンプルになって扱いやすくなります。

【結論】

  • オブジェクト間の関連付けはこれまでの感覚ではDBのテーブル間で行っていた印象があったが、Railsではモデル間で行うということを知ることができました。
  • たった一行のコードを書くだけで関連付けができる機能の強力さを実感して、Railsって便利だなと改めて思う次第です。

  1. 本当にこのコマンドが楽で勝手に必要なものを作ってくれるので依存するのは危ないなと思うほどでした。

  2. bundler.ioの紹介文「Bundler provides a consistent environment for Ruby projects by tracking and installing the exact gems and versions that are needed. 」から意訳。