おっさん初学者のRailsチュートリアル学習記録(3章)

プログラミング年少組のど素人が、アウトプット用に素人目線の解説を書いていきます。
自分が自分に教えていることを想像しながら進めていきます。
下記と同じような境遇の方であれば参考になるかも

- まっさらなプログラミング初学者目線
- オール独学
- 勉強は得意じゃない
- 社会人のため、1日に勉強できる量は限られる。

電子書籍のwebテキスト(第６版)を購入して使用
Rails動画解説を見ながら学習
Progateの「Web開発パス」完走済
ドットインストールのプレミアム会員卒業
#3章 ほぼ静的なページの作成#
3章では本格的なサンプルアプリケーションの**静的ページ**から作成を進めていきます

**静的ページとは**
いつどこでアクセスしても毎回同じものが表示される、HTMLファイルで作成されたWebページのこと
**動的ページとは**
アクセスしたときの状況に応じて異なる内容が表示されるWebページのこと

本章は以下の流れで進めていきます

1. 静的ページの作成
2. テストを導入
3. 少しだけ動的なページにする
4. 以上

#3.1 セットアップ#
*まずは土台づくりからデプロイまで*

2章と全く同じ流れだけどとりあえず載せとく
(今回はワークスペース作りからはやってません)

サンプルアプリを作ります

```
$ cd ~/environment
$ rails _6.0.3_ new sample_app
$ cd sample_app/
```
ディレクトリからGemfileを開いて編集します
(今回もコピペしました・・・・)

```
$ bundle install --without production
$ bundle update
```

ここで**「bundle install」と「bundle update」について**少し触れますと
bundle install
現在すでに取り込まれているGemfileと比較して差分のある部分があったら、そこだけ更新する
(例)ファイルの一部分が少し変更されている時。
bundle update
現在すでに取り込まれているGemfileと比較してガッツリ変わっている部分があったら、そこを取り込む
(例)新たにファイルごと追加した時

Gitの設定を行います

```
$ git init
$ git add -A
$ git commit -m "Initialize repository"
```

ファイルツリーの下の方にあるREADME.mdを編集します
(内容はコピペしました・・・)
編集後は、Gitにコミットします

```
$ git commit -am "Improve the README"
```
これまでの内容をGitHubにプッシュします

```
$ git remote add origin https://github.com/<あなたのGitHubアカウント名>/sample_app.git
$ git push -u origin master
```
プッシュが無事に完了したら、GitHubを起動して、リポジトリを作成します。

お次はローカルサーバーが使えるように設定します
development.rbファイルを編集する
ここにある👉config>environments
最後の「end」の上に**「config.hosts.clear」**を加えるだけ

最後にコントローラーアクションとルーターを編集し、Herokuにデプロイする

```
$ git commit -am "Add hello"
$ git push
$ heroku create
$ git push heroku master
```

これで一通り土台が出来上がります。
ここまで何回もやるといい加減慣れてきますね
#3.2 静的ページ#
*この節の進め方とトピックブランチの作成*

トピックブランチは以下のようにして作成します

```
$ git checkout -b static-pages
```
これで「static-pages」という名前の新しいブランチができます
和訳すると「静的ページ」・・・そのままですね
##3.2.1 静的なページの生成##
*静的なページの生成*

静的なページを作成するには、まず「rails generate controller」を使ってコントローラーを作成するところから始めます。
なぜコントローラーなのか。。
コントローラーには2つの役割がありました。
**①ルーターに指定されたURLのアクションを実行する
②実行したアクションと同じ名前のビューを出力する**
この動きを利用して、①のアクションのコードを空にしておけば、ただ単に②のビューが表示されるだけの動作になります。

それでは今回「StaticPages(静的ページ)」コントローラーでも作りましょう。

```
$ rails generate controller StaticPages home help
```
「home」と「help」がくっついてますが、このコマンドで何ができるでしょうか。。
①StaticPagesコントローラー
②StaticPagesコントローラーの中に「homeアクション」と「helpアクション」ができます
③ビューフォルダの中にStaticPagesフォルダができます
④③の中に「homeアクションに対応するビューファイル」と「helpアクションに対応するビューファイル」ができます

コントローラーにできたファイルを見てみましょう

```static_pages_cotroller.rb
class StaticPagesController < ApplicationController
  def home
  end

  def help
  end

end
```
homeアクションは"app/views/static_pages/hone.html.erb”を返す機能が自動でついてます。
helpアクションは"app/views/static_pages/help.html.erb"を返す機能が自動でつきます
※それぞれのビューは「rails generate」した時に自動的に作られます。

コントローラーを追加する作業をしましたのでここでいったんGitHubのリポジトリに送信しときましょう

```
$ git add -A
$ git commit -m "Add a Static Pages controller"
$ git push -u origin static-pages
```
最後のコマンドで、**「トピックブランチ」である「static-pages」**からGitHubにプッシュしました
これはここまでで初めてのことです。
トピックブランチではなくて、マスターからですとこんな設定いりませんが、「トピックブランチ」の場合は必要です。
また、このコマンドで送信したあとは以下のコマンドで送信できるようになります

```
$ git push
```
###コラム3.1 取り消しについて（覚えておきたい！）###
ここでいきなり**<font color="red">永久保存版</font>**。**元に戻す方法**について解説が入っています。
「rails generate」などは、コマンド送信後にいくつものフォルダができたりと、多数の処理が入るものがあります。
それらについてコマンド送信前の状態に戻し、あたかも無かったことのようにしてくれる取り消し用のコマンドが存在します。

まずは**「rails generate controller」の取り消し**についてです
こちらの内容でコマンド入力してしまったが取り消して修正したかったとしましょう

```
$ rails generate controller StaticPages home help
```
そんな時、取り消すために以下のコマンドを入力します。

```
$ rails destroy  controller StaticPages home help
```
まさにデストロイです☠️破壊します☠️

続きまして**「rails generate model」の取り消し**についてです
入力してしまって取り消したい内容のコマンドを以下としましょう

```
rails generate model User name:string email:string
```
こちらも先程同様、デストロイしちゃいましょう

```
rails destroy model User
```
これでOKです。あれ？こちらはnameとかの部分(引数)が含まれていません。
その理由は6章になったら教えてくれるそうです。だいぶ後なので忘れてなけりゃいいですが・・・

最後に**「rails db:migrate」の取り消し**についてです
こちら、マイグレーションの変更を**確定**させるコマンドとも書いたような気もしますが、こちらも取り消して元に戻すことが可能です。

```
$ rails db:migrate
```
と入力してしまったが、時を戻したい場合は以下を入力すればOK

```
$ rails db:rollback
```
ここは、デストロイじゃないんですね。統一感ないですね。
また、これではコマンド1つ前までしか戻すことができません。
もちろん最初の状態にまで戻す方法はございます。

```
$ rails db:migrate VERSION=0
```
なんかそのままですね。何も無かったゼロの時代の初心に帰るといったところでしょうか。
以上が取り消しについてでした

**コラムはいったんここで終わり**
**ここから本題に戻ります**

ここで問題の**「ルーター」**について見ていきます
問題の部分がこちら

```config/routes.rb
Rails.application.routes.draw do
  get  'static_pages/home'
  get  'static_pages/help'
  root 'application#hello'
end
```
何が問題っていきなりまた新手のパターンになっているところです。
ルーターの中身ってそもそもがこんな形だったはずです

```
get  "URL" => "コントローラー名#アクション名"
```
これと比べると、「え？URLしか書かれてないやん？」てなりますよね
本来ならこう書かれてあって欲しいです

```
get  "static_pages/home" => "static_pages#home"
```
これなら納得いきます。Progateではこれで習ったはずです。。。
なので、無理くりこう変更してみました

```config/routes.rb
Rails.application.routes.draw do
  get 'static_pages/home' => "static_pages#home"
  get 'static_pages/help' => "static_pages#help"
  root 'application#hello'
end
```
おおおお。。。。なんとも初心者にやさしい感じになりました。

ちなみに、双方の形でローカルサーバーにて動作を試したところ
「/static_pages/home」というリクエストを送信すると同じページが表示されました。
また、2章でやりました、以下に記載しているルーティングを調べるコマンドで中身を見てみました。

```
$ rake routes
```
なんと、初めのルーターの中身も、書き換えたルーターの中身も結果が同じになったじゃありませんか。。

よって同じ意味を表している。という結論に至りました。私レベル的には後者の方がありがたいですがね。
むしろ**「get  "URL" => "コントローラー名#アクション名"」の方が一般的に使われている**みたいですので、テキストとは違う形ですがこちらで進めてみた方が良いかもしれません。

###コラム3.2 GETやその他のHTTPメソッドについて###
ここで少し**「get」**について触れときます
「get」が書かれてあるところには他にも**「post」「delete」「patch」**が入ることがあります。
それぞれに役割がありますが、
やはり「get」が一番頻繁に登場します
**主にWeb上のデータを読み取る時に使われ、ブラウザはWebサイトを開くたびにgetリクエストをサイトに送信します**
次に使用されるのが「post」です
**postリクエストは何かを作成するときに使われます。
例えば、ユーザーの作成などデータベースの内容に変更を加えたり新たにデータを登録するときなどです**
残りの「patch」と「delete」は削除や更新で使われますが、ほんとにあまり使われません。
ブラウザがこの2つのリクエストを送信することがほぼないからみたいです。
**とりあえずは「get」と「post」に関して、理解を深めときましょう！**

```routes.rb
Rails.application.routes.draw do
  get 'static_pages/home' => "static_pages#home"
end
```
よってルーターに書かれてある上記の部分の動きを再度順を追って説明すると

1. /static_pages/homeというURLにアクセス
2. RailsがStaticPagesコントローラーを参照し、homeアクションに記述されているコードを実行
3. そのアクションに対応するビューを出力する

といった流れになるということです。
今回は、homeアクションの中身が空になっているため、実行するコードがなく単にビューが出力されるだけ。ということになります。
##3.2.2 静的なページの調整##
*ビューファイルの中身を修正する*

静的なページの変更についてはビューファイルの中身をいじればいいということです。
とりあえずテキストをコピペしました。。。
#3.3 テストから始める#
*テストの種類やそれぞれの手法についての説明*

ついにやってきてしまいました。テストです。。。。
Progateにもドットインストールにも無かったフェーズなので、ここに関しては１から理解していかないといけません。。。
しかも難しい！余計な先入観をもつメリットはありませんが、難しいもんは難しい・・・
なのでじっくりやっていきます。。

**そもそもなんでテストをやるのか**
基本的には機能を搭載した際に、果たしてそれが正常に動作するのか確認するためです。
また、テストを行わずに開発を進めていく中でバグが生じた場合、その原因を追うために余分な時間がかかってしまうこともあります。
よってコード量は増えますがトータルの開発速度は確実に上がります。
（開発開始からリリースまで一つの小さなバグも出さずに開発が完了できるのであれば話は別ですが・・・そんなことできんの？）
Webサービスは人に使われることを前提にして作られることは当たり前のことであり、ユーザーが使っていて不具合だらけでは話になりません。よって**テストは重要であり作成する習慣を身に付けましょう**

###コラム 3.3 結局テストはいつ行えばよいのか###
テストのメリットをもう一度確認すると以下の3つが挙げられます

1. 回帰バグ（以前のバグが再発したり機能の追加/変更に副作用が生じたりすること）を防ぐことができる
2. コードを安全に機能を変更せずにコードを改善することができる
3. ユーザー目線の開発が可能になる

それぞれのメリットを活かすためにはテストを書くタイミングや手法が違ってくるとのことです。
手法についてはアバウトにまとめると２つあります
**①テスト駆動**
先にテストを書く手法です。
先に<font color="red">「正しいコードがないと失敗するテスト」</font>を書き、次に本編のコードを書いてそのテストがパスするようにする。
**②一括テスト**
後にテストを書く手法です。
①とは逆で、本編のコードを先に書いて最後にテストを書き動作を確認する手法です。

どちらを使うかはケースバイケースみたいですが、テストを書くのに慣れてくるとテストを先に書くようになるみたいです。
チュートリアルでは目安を決め、どういったケースでは、どちらの手法を用いるかを定めています

①の「先に書く手法」を用いるケース

- アプリケーションのコードよりも明らかにテストコードの方が短くシンプルになる
- セキュリティが重要な課題またはセキュリティ周りのエラーが発生した場合
- バグを見つけたら、そのバグを再現するテストを「先に」書き、回帰バグを防ぐ体制を整えてから修正に取りかかる

※①の手順で開発することをテスト駆動開発(TDD)と言います

②の「後に書く手法」を用いるケース

- 動作の仕様がまだ固まりきっていない場合
- すぐにまた変更しそうなコード（HTML構造の細部など）に対するテスト

最後にチュートリアルで登場する3種類のテストを紹介します。
＊先程紹介した手法とごっちゃになりそうですみません。手法はあくまで「いつテストを書くか」という観点から分類したものになります

**1.コントローラーテスト(3章から)・・・コントローラーのテスト
2.モデルテスト(6章から)・・・モデルのテスト
3.統合テスト(7章から)・・・モデル/ビュー/コントローラにまたがる機能テスト**
##3.3.1 最初のテスト##
*早速テストを動かしてみる*

早速先程紹介した**「コントローラーテスト」**に取り掛かっていきましょう
っと言いましても、実は「rails generate controller」を実行した際にそこに対応するコードはすでに生成されているのです。。。
今回「StaticPagesコントローラー」を作成しましたので、それに対応するテストファイル(static_pages_controller_test.rb)はここにあります
👉test>controllers

```test/controllers/static_pages_controller_test.rb
require 'test_helper'

class StaticPagesControllerTest < ActionDispatch::IntegrationTest
  test "should get home" do
    get static_pages_home_url
    assert_response :success
  end

  test "should get help" do
    get static_pages_help_url
    assert_response :success
  end

end
```
早速見ていくと「StaticPagesコントローラー」で設定した「homeアクション」と「helpアクション」に対応する2つのテストが生成されています
内容を見ていきましょう

```test/controllers/static_pages_controller_test.rb
test "should get home" do
    get static_pages_home_url
    assert_response :success
  end
```

**"should get home" do**
homeアクションをgetして(homeページが)正常に動作することを確認します
**get static_pages_home_url**
getリクエストをhomeアクションに対し発行(送信)せよ
**assert_response :success**
リクエストに対するレスポンスは［成功］になるはず！！・・・だよね？？

と、いう内容のテストとなります。
HomeページやHelpページがいわゆる「GETリクエストを受け付ける」普通のWebページであり、レスポンスがあれば「成功」ということです。

テストの実施方法は以下のコマンドを実行します

```
rails test
```
・・・そのまんまですね。
「assertで書いた部分が期待している動作」となれば「成功」し、「０ failures」が表示されます
##3.2.2 Red##
*先に失敗するテストを書く「テスト駆動開発」のサイクルを試してみる*

**テスト駆動開発**のサイクルをおさらいすると以下の内容でした
1.「失敗するテストを最初に書く」 = 未実装の機能が成功しますよね？というテスト
  これはもちろん失敗します。未実装なのだから。
2.「次にアプリケーションのコードを書いて成功させる（パスさせる）」
3.「必要ならリファクタリングする」

それでは実際に試してみましょう
「コントローラーテスト」ですので、Static_pagesコントローラーに新たに「aboutアクション」を追加する際のテスト設計について考えていきましょう
と言っても、形はすでに他のアクションで出来上がっていますので、アクション名だけ変えてコピペするだけでOKです

```test/controllers/static_pages_controller_test.rb
  test "should get about" do
    get static_pages_about_url
    assert_response :success
  end
```
これは「assert_response :success」となっていますので
リクエストに対するレスポンスは［成功］になるはず！！・・・だよね？？という内容のテストになります。

もちろんStatic_pagesコントローラーにはまだ「aboutアクション」は追加していませんので、リクエストを送ったところでレスポンス（回答）がないのは当たり前のことです。
よってこのテストは失敗します。ので、テスト実行のコマンドを送信して確認してみましょう

```
$ raisl test
　3 tests, 2 assertions, 0 failures, 1 errors, 0 skips
```
こういう結果が出るはずです。
見事に「1 errors」が出ています。成功です。あいや、テストは失敗ですけど期待する結果が出ているので成功です。
##3.3.3 Green##
*エラーを解消する*

先程のエラーの原因。それは、ありもしない「aboutアクション」の動作を見るためのテストだったからです。
なので、解消させるには「aboutアクションリクエストに答える一連の動作」を作る必要があります。
答えから書いていきますと。アクションに関わる部分は以下の3つです。
**①ルーティング
②コントローラーのアクション
③ビューファイル(Railsではテンプレートと呼ばれる)**

それでは①のルーティングから作っていきましょう
ヒントはhomeやhelpの形をそのまま使えばいいでしょう

```config/routes.rb
  get  'static_pages/about'
```
これでもいいですし

```config/routes.rb
  get 'static_pages/about' => "static_pages#about"
```
こちらでもいいです。私はペーペーなのでこちらを記載しました。わかりやすいし。

次に②のコントローラーです
ルーティング同様homeやhelpをヒントに書いていきましょう

```app/controllers/static_pages_controller.rb
  def about
  end
```
最後に③のビューですね
aboutアクションに対応するビューファイルを作成します
homeアクションに対応するビューはhome.html.erbですし、helpアクションに対応するビューはhelp.html.erbです。
ファイルがあるviewフォルダの場所はここです👉app>views
ここに新たにabout.html.erbファイルを作成します
viewsフォルダのところで右クリック→「New File」を選択して作成してもよいのですが
コマンドでカッコよく作ることもできます

```
$ touch app/views/static_pages/about.html.erb
```
about.html.erbを作成したら、空のままでは味気ないので、中身に内容を付け足しときましょう。
とりあえずテキストをコピペしときましょう

これで①〜③「rails test」してみましょう

```
$ rails test
3 tests, 3 assertions, 0 failures, 0 errors, 0 skips
```
先程とは違って「0 errors」となりましたので、テストは成功です。

これで「アクション」に対するテストを書くことができるようになりましたね。
##3.3.4 Refactor##
*リファクタリングの必要性について*

**リファクタリングとは**
書かれたコードの見た目を整えるということです。
コードの記法や統一が崩れてくると読みづらくなります。
コンピューター側からすれば、見た目がどうであれ関係ありません。そのままを実行するだけなので。
しかしコーディングし、開発の作業するのはあくまで人であり、基本的には複数人で行います。
よって<font color="red">誰にとってもシンプルで分かりやすいコードで書くということを常に心がける必要であります</font>
#3.4 少しだけ動的なページ#
*ページ内容を少し動的に変えていく手順の説明*

3章の始めで、動的ページについて以下のような説明を入れていました。
**動的ページとは**
アクセスしたときの状況に応じて異なる内容が表示されるWebページのこと

今回はページの内容に応じて(アクセスしたときの状況に応じて)、ページのタイトルを自ら書き換えて表示するようにします
具体的には「Homeページ、Helpページ、Aboutページをそれぞれ編集し、最終的にページごとに異なるタイトルを表示する」ということです

もちろんテストも行い、「Red ・ Green ・ REFACTOR」のサイクルを使っていきます。
手順は以下の通りです
1.**Red**「失敗するテストを最初に書く」 。
⇨各ページタイトルの簡単なテストを書く
2.**Green**「次にアプリケーションのコードを書いて成功させる（パスさせる）」
⇨3つのページにタイトルを追加
3.**REFACTOR**「必要ならリファクタリングする」
⇨レイアウトファイルを活用してコードの重複を解決
##3.4.1 タイトルをテストする(Red)##
*各ページタイトルの簡単なテストを書く*

内容としては、これまでに作成している「homeページ」「helpページ」「aboutページ」に指定した文言がちゃんと含まれてますよね？？というテストを書きます

ますよね？？といえば「assert」ですが
ここで新たに**「assert_selectメソッド」**というものが登場します
<font color="blue">これは特定の**HTMLタグ**が存在するかどうかをテストします。
指定したタグに指定した文言が含まれているかを確認します。</font>

```
assert_select "title", "Home | Ruby on Rails Tutorial Sample App"
```
こういう風に記載すると、<font color="red">「titleタグにHome | Ruby on Rails Tutorial Sample Appが含まれてますよね？？」</font>ということを確認する意味となります。
これをそれぞれのページに加えると以下のようになります

```test/controllers/static_pages_controller_test.rb
require 'test_helper'

class StaticPagesControllerTest < ActionDispatch::IntegrationTest

  test "should get home" do
    get static_pages_home_url
    assert_response :success
    assert_select "title", "Home | Ruby on Rails Tutorial Sample App"
  end

  test "should get help" do
    get static_pages_help_url
    assert_response :success
    assert_select "title", "Help | Ruby on Rails Tutorial Sample App"
  end

  test "should get about" do
    get static_pages_about_url
    assert_response :success
    assert_select "title", "About | Ruby on Rails Tutorial Sample App"
  end
end
```
もちろん各ページの内容は何も触ってないのでその通りになるわけもなく失敗になるなずです

```
$ rails test
3 tests, 6 assertions, 3 failures, 0 errors, 0 skips
```
##3.4.2 タイトルを追加する(Green)##
*3つのページにタイトルを追加する*

テストが通るように、
「assert」で、ありますよね？？と書かれてある文言をHTMLファイルに入れてやればいいだけです
Homeのtitleタグには「Home | Ruby on Rails Tutorial Sample App」
Helpのtitleタグには「Help | Ruby on Rails Tutorial Sample App」
Aboutのtitleタグには「About | Ruby on Rails Tutorial Sample App」
編集内容はテキストにありますのでコピペしちゃいましょう
正確に入れてテストすると今度は成功するはずです！

```
$ rails test
3 tests, 6 assertions, 0 failures, 0 errors, 0 skips
```
##3.4.3 レイアウトと埋め込みRuby(Refactor)##
*リファクタリングする（重複している構造や文言を整えていく）*

具体的に以下の3点において修正を加えていきます

- ページのタイトル
- 重複している「Ruby on Rails Tutorial Sample App」の部分
- HTMLで類似している部分

※Rubyにおいては同じコードを繰り返すことは原則としてよくありません。「DRY(Don't Repeat Yourself)」という言葉があるくらいです

それではまずは、重複している箇所を修正するところから始めていきましょう
該当箇所のhomeのビューをピックアップして見ていきましょう
＜修正前＞

```app/views/static_pages/home.html.erb
<!DOCTYPE html>
<html>
  <head>
    <title>Home | Ruby on Rails Tutorial Sample App</title>
  </head>
```
＜修正後＞

```app/views/static_pages/home.html.erb
<% provide(:title, "Home") %>
<!DOCTYPE html>
<html>
  <head>
    <title><%= yield(:title) %> | Ruby on Rails Tutorial Sample App</title>
  </head>
```

修正箇所は<% %>や<%= %>で囲まれた部分です
まずは**<% %>や<%= %>の意味について**見ていきましょう
これはビューのファイル名の最後が**「.erb」**となっていることに関係しています。
このファイル、見た目はHTMLの構造をしています。
その<font color="red">HTMLの構造したファイルに「.erb」をつけることでrubyのコードを埋め込む(取り入れる)ことができるようになるのです</font>
（元々は.htmlで終わっていて、HTMLのファイルだったものに、rubyの機能を付け加えたためファイル名に.erbが付け加えられた。とでも考えておきましょう）
ちなみにerbは「Embedded Ruby（埋め込みRuby）」の略となります。

**次は<% %>と<%= %>の違いについてです**
<% %>：出力しないタイプのコードを記入します
<%= %>：出力するタイプ（画面に出てくる）のコードを記入します
ここまでで、ああ、rubyのコードを入れたのが分かるようにしてたのね。。。ということがなんとなく分かりました。

では使用されているrubyのコード**「provideメソッドとyieldメソッド」**について見ていきましょう

1.provideメソッドの中に「:title」を入れる。
2.「:title」の中身を確認する(今回の場合は「Home」が入っている)
3.引き出したいところで「yield(:title)」とすると、「:title」の中身にあった「Home」が引き出される

「help」や「about」のページについても同じ原理で修正を行っていきましょう
すると！？すると！？

```
<% provide(:title, "The Title") %>
<!DOCTYPE html>
<html>
  <head>
    <title><%= yield(:title) %> | Ruby on Rails Tutorial Sample App</title>
  </head>
  <body>
    Contents
  </body>
</html>
```
「"The Title"」と「\<body>の中身」をのぞいて3つとも同じ内容になるじゃありませんか！
と、いうことでお次はここを整理していきます

ここで利用するのが、「application.html.erb」というレイアウトファイルです。
ここにあります👉app>views>layouts

これを有効にするにはtitle部分を差し替える必要があります

```app/views/layouts/application.html.erb
<title>SampleApp2</title>
```
こうなっていたものを・・・以下の内容に書き換えます

```app/views/layouts/application.html.erb
<title><%= yield(:title) %> | Ruby on Rails Tutorial Sample App</title>
```
さあこれで、この**<font color="blue">レイアウトファイルが有効になった**</font>ということみたいです
ここで重要な役割をするのが以下の部分です

```app/views/layouts/application.html.erb
 <%= yield %>
```
このコードで、各ページの内容がレイアウトに挿入されます・・・え？？どゆこと？？
**レイアウトを使う際に、/static_pages/homeにアクセスすると(「Home」のビューファイルにアクセスすると)「home.html.erb」の内容がHTMLに変換され、「application.html.erb」の<%= yield %>の位置に挿入される**
URLにアクセスした時に、画面表示されるのがhome.html.erbではなくて、application.html.erbってことでええとかいな・・・先程のレイアウトファイルが有効になったとはこういうことだったのですね
引数が指定されていない<%= yield %>はデフォルトが表示されます。

何がどうなってそうなるのかは不明ですが、「コードの詳細な動作を正確に理解する必要なし！」とテキストに書いてあるのであまり深く考えるのはやめときましょう

その他いろいろついている以下のものについて

```app/views/layouts/application.html.erb
<%= csrf_meta_tags %>
<%= csp_meta_tag %>
<%= stylesheet_link_tag ... %>
<%= javascript_pack_tag "application", ... %>
```
JavaScriptをページ内に含めたり、セキュリティ上重要な役割をしていたり、よく分かりませんが便利な機能を加えているということでサラッと眺めときます

いろいろと不十分な説明をしてきましたが、肝心の**重複した部分を整理する**ことができてませんでした
なのでチャチャッとやっちゃいましょう
とりあえずhomeページだけここに載せときます
（「"The Title"」と「\<body>の中身」だけがそれぞれに残るイメージです。それ以外がapplication.html.erbで統一されてしまったので）

```app/views/static_pages/home.html.erb
<% provide(:title, "Home") %>
<h1>Sample App</h1>
<p>
  This is the home page for the
  <a href="https://railstutorial.jp/">Ruby on Rails Tutorial</a>
  sample application.
</p>
```
だいぶスッキリしました。

以上で終了です！
最後にテストしときましょう！

```
$ rails test
3 tests, 6 assertions, 0 failures, 0 errors, 0 skips
```
##3.4.4 ルーティングの設定##
*トップページを変更する*

トップページはルーティングの「root」で設定していました。
今回は「static_pages/home」をトップ画面に設定したいと思います

```config/routes.rb
root 'static_pages#home'
```
#3.5 最後に#
*Gitにプッシュしてデプロイ*

それではいつもの流れでこの章を完了させましょう

```
$ git add -A
$ git commit -m "Finish static pages"
$ git checkout master
$ git merge static-pages
$ git push
$ rails test
$ git push heroku
```
#3.6 高度なセットアップ#
*追加で説明する２つのテスト用の設定について*

え？ついさっき最後に。って終わったんやないんかい！とツッコミを入れたくなりますが、もう少し続きがありました。。。

これから説明する2つのテスト用の設定
**minitest reporters：成功/失敗の表示設定をする
Guard：ファイルの変更を検出して必要なテストだけを自動実行してくれる**

設定はmasterブランチで行う必要があるので、そうでない場合はmasterに戻しときましょう

```
$ git checkout master
```
##3.6.1 minitest reporters##
*minitest reportersの導入について*

すでに3.2の時に設定したGemfileにはこのgem自体は組み込まれていたみたいですね。。
「test_helper.rb」というファイルにコードを入れることによりそれが動作するみたいです
ファイルはここにあります👉test>system
挿入するコードはテキストをコピペしました。。

果たしてこの設定を入れることで、何がどう変わるのか！？
ということで、試しに「rails test」を実行してみると・・・・

テストの結果がこれまでと違って表示され、色もついて少し見やすくなったような気がします！！
これが「minitest reporters」の設定です
##3.6.2 Guardによるテストの自動化##
*Guardの導入について*

コマンドでいちいち「rails t」と入力することすら面倒臭い！という人向けの設定です。
ファイルのコードを変更して保存した時点で都度勝手にテストしてくれます

こちらも先程同様に、3.2の時に設定したGemfileにはこのgem自体は組み込まれていたみたいです
よって、あとは同じように使えるようにする設定を進めます

1.guard gemを初期化します

```
$ bundle exec guard init
```
2.Guardfileを編集します
　とりあえず、テキストをコピペ
3.クラウドIDEで作業している場合は、全ファイルをGuardで監視できるようにする設定が必要

```
$ echo fs.inotify.max_user_watches=524288 | sudo tee -a /etc/sysctl.conf
$ sudo sysctl -p
```
4.<font color="red">新しいターミナルのファイルを開く</font>
5.コマンドを入力してGuardを開始する

```
$ bundle exec guard
```
これで設定は完了です！
試しにファイルを適当に更新して保存してみましょう。
自動的にテストが実行される様子が分かります。。テストを終了させたいときは「Ctrl + d」を押します

最後に忘れずにコミットしときましょう

```
$ git add -A
$ git commit -m "Complete advanced testing setup"
```

#3章の要約をようやく作り終えての感想#
長かった・・・これからさらに難易度が上がるというのに、まだまだ試練は続きそうだ・・・オラ、ワクワクすっぞ！！！と、おふざけはさておき、独学は自分との戦いですので挫折することなく継続させることを念頭において4章に挑もうと思います。。