１ 各ディレクトリの概要
appディレクトリ：ビュー、コントローラ、モデルなどのファイル。configディレクトリ：ルーティング、いろんな設定ファイル。db: マイグレーションファイル。 マイグレーションファイル、データベースを作成する.ymlファイル、 appディレクトリ：モデル、view、controller、helperファイル、アセットファイル configディレクトリ：初期設定用のファイル、環境ごとに設定するファイル、データベースの設定 (database.yml) dbディレクトリ：スキーマファイル、マイグレーションファイル
２ layoutファイル
layoutファイルとは？HTMLのどの様な部分をレイアウトファイルに切り出しますか？（head header footer その他 sidebar）
・application.html.erbは、<head></head>タグや<body></body>タグの中で <%= yield %> で読みこんだりするファイル。 ・毎回読み込むHTML
3 cssの種類
cssとscssってどう違う？
cssは拡張子が.cssでブラウザで読み込むことができるが、SCSSファイルは拡張子が.scssでブラウザでは読み込むことができない。なので、SCSSで書いたコードは、CSSのコードにコンパイル（変換）する必要がある。Railsでは「アセットパイプライン」という仕組みが勝手にやってくれる。SCSSはCSSを入れ子構造で書けたり、mixinというものや、変数っぽいものが使えて、レスポンシブ対応などがしやすい特徴がある。
4 Railsにおける処理の全体像
クライアント→HTTPリクエスト→ルーティング→コントローラ→モデル→DB→ビュー→HTTPレスポンス→クライアント form_withは「ビュー→HTTPレスポンス→クライアント」で対応する。
5 セッション / クッキー
HTTPリクエストはステートレスなので状態を保持できない セッションとは：サーバー側で保存される小さな情報、または領域 Cookieとは：ブラウザ側で保存される小さな情報、または領域 ログインとは：ユーザーにセッションとCookieの情報を持たせて、前後の情報間で繋がりを持たせた状態のこと
6 バリデーション
saveとsave!メソッドの挙動の違いは何ですか。それぞれのメソッドはどう使い分けますか。
saveは失敗したら「false」 が返り、save!は「例外」が返る。 saveは失敗することを想定している処理に使い、save!は失敗しないはずの処理に使う。 ex saveを使用するとき：掲示板など save!を使用するとき：絶対に成功する。（もしもの時に・・・・）
def create
if @board.save!
else
# エラーハンドリング
end
end
def destroy
@board = Board.find(params[:id])
@board.destroy!
end
def create
# Stripeに課金する処理
# Userの有料会員フラグをオンにする処理
ActiveRecord::Base.transaction do
@user.update!(yuryo: true)
contract = Contract.new(user_id: @user.id)
contract.save!
end
end
7 デバッグ
paramsに入っている値を確認する。
Railsのアプリケーション内で複数の言語を併用する仕組み。config/locales下にymlファイルを作成する。（英語であればen.yml、日本語であればja.yml)。userクラスにlocaleという属性を設定し、beforeアクションにてcurrent_userのlocaleを確認するメソッドを定義すればユーザーごとに言語を切り替えられる。
9 decoratorとは
decoraterは何のために必要ですか？Helperと何が違いますか？ロジックをViewに書くことの問題点は何でしょうか？
・decoraterはモデルと関連しないメソッドを記述し、Helperはモデルと関連するメソッドを記述する。ロジックをviewに記述するとviewファイルが肥大化し、可読性が低下してしまう。 ・decoraterオブジェクトで既存のオブジェクトをラッピング（包み込む）ことで、既存のオブジェクトを変更することなく、機能（メソッド）を追加したりできる。decoraterはdecoraterオブジェクトでラッピングしたオブジェクトでのみ使えるが、Helperは制限なくどこでも呼び出せる。 ・Helperはグローバルな領域であり、例えばapplicationやuserで同じメソッドを定義したらバッティングして動かない可能性がある。 dccoraterの場合、そのような心配はない。
10 アソシエーション(has_many, belongs_to)
UserとBlogモデルがあるとした場合、1人のユーザーは複数のブログを投稿できるので、Userモデルにhas_many blogsと記載する。 逆に１つのブログは1人のUserが所有するので、Blogモデルにbelongs_to :userと記載する。 そうすると、下記のように使える。
# ユーザーオブジェクトを取得 user = User.first # userオブジェクトが blog_id という外部キーを持っているので、その外部キーを使って、userオブジェクトが作成したblogオブジェクト（Blogモデルのidを参照する）を取得できる。 user.blogs
11 dependent: :destroy
モデル間のリレーションが設定されている場合、この設定をした親モデルが削除される時、関連する子モデルも同時に削除され、参照先が存在しないというバグを防ぐ。例えば、UserとBlogモデルがあるとした場合、1人のユーザーは複数のブログを投稿できるので、Userモデルにhas_many blogs, dependent: :destroyと記載する。そうすると、Userが削除されると、削除したユーザーが作成したBlogも消える。
12 DB側の制約（not null制約、外部キー制約）
モデルのバリデーションだけでなくDBの制約もかけたほうがよい理由を説明してください
SQLから直接データを入力するとバリデーションをすり抜けて登録されてしまう。
13 ルーティング（REST）
ユーザーを新規作成する際、どんなURL, どんなHTTPメソッドでリクエストを送りますか？ RESTfulの考え方を用いて説明してください。
ユーザー新規作成時は、 URL：users/:id httpメソッド： POST /users
上記のURLにある表は暗記！or rails routesで確認。
14 includes（N+1問題）
関連付けを持つあるモデル(A)について、検索をかける際に外部キー参照により関連するテーブル(B)の値も合わせて取得しようとした時、「まずAのレコードN件を取得するクエリが１回、次に各Aレコードに対して関連テーブルの値を引っ張ってくるクエリがN回発行されてしまう」という問題。
ex ・掲示板一覧を出す。 (1個) ・その掲示板一覧に記載している掲示板の個数。（N個)
15 フォームヘルパー(form_with)
Railsではform_withメソッドが提供されていますが、例えばどんな嬉しいことがありますか？
「新規作成時」「編集時」 ・モデルのインスタンスを渡すと、よしなにPOSTかPATCHを判断してくれる。 ・action属性を振り分ける。 ・persisted（永続化）出来るかどうか判断してくれる。
16 ストロングパラメータ
ストロングパラメータの存在意義は？仮にこれがなかった場合何がまずい？マスアサインメント（一括代入）という言葉を使って説明してください
マスアサイメント機能を使うと意図せぬ属性が紛れ込んでいるときに想定外の属性についても登録・更新されてしまう（勝手にadminとか作ったりできちゃう）ので、ストロングパラメーターで特定のパラメータを決めると安心！
余談
・サイト内検索 site.〇〇でもできる
・テスト環境でのメールアドレスはexample.comでやる。
