scaffold

MVCアーキテクチャではmodel,view,controlerが組み合わさって一つのリソースと考える。scaffoldを使うとリソース単位で自動生成してくれる。
scaffoldをしてサーバーを立ち上げると、その時点からuserリソースを扱える。/users/newとかできる。

migration file

これはrailsとDBが全く別物だから、migration fileに書いて〜を保存するスペース作ってくれない？とお願いをしなければいけない。なので、rails generate scaffold User name:string email:stringなどの指示を出した後はrails db:migrateをしないとDBにリソースを保存することができない。ちなみに、rails db:migrateをせずにrails sをすると、　migration pending(DBに何かお願いすることあるんじゃないの？）というエラーを出してくれる。rails db:migrateはべきとうせいである。つまり何度実行しても追加したmigration fileがなければ何も起こらない。

resources

これはルーティングのパッケージ版。本来　/users => user#indexなど基本のルーティングがパッケージングされてる。

actionのデフォルトview

例えばindexアクションを呼び出した時、renderなどのviewを呼び出す指示が書いてないことがほとんど。その場合は、アクション名からapp/views/users/index.html.erbが呼び出される仕組みになっている。

indexアクションの場合。

後半戦

bundle exec

このコマンドはgem fileを読み込んだ上でexec以下のコマンドを実行するというもの。 ex)bundle exec rails --version

テーブルの関連付け

class User < ApplicationRecord
  has_many :microposts
end

class Micropost < ApplicationRecord
  belongs_to :user
  validates :content, length: { maximum: 140 }
end

これによって、User.first.micropostsなどが実行できる。

そもそもなんで上記のコマンドでテーブルが結合される？

これはrailsのデフォルトによるもの。
micropostsテーブルにはuser_idというカラムがある。
model名_idというカラムがあり、結合すると、model名（ここではusersテーブル）のidカラムと自動的に結合してくれるから。

validation

class Micropost < ApplicationRecord
  validates :content, length: { maximum: 140 }
end

これによって投稿の文字数を140文字に制限することができる。

heroku注意点

上記のようにテーブルを作った状態でherokuにアップしようとすると、エラーになってしまう。
それはmigrationfileが開発用には適用されたが、本番環境では適応されていないから。開発環境用のDBと本番環境用のDBが違うことから起きる。

そのため、　heroku run rails db:migrate　としてあげる。

つまり、migrationfileを一つでも作ったら、git push heroku masterをした後に上記のコマンドを実行しなければいけないということ。

また、DBは違えど、Active RecordによってSQLが適切に書かれるのでそこを気にする必要はない。