メモランダム Rails tutorial　第3章

# Rails tutorial 第３章
## ほぼ静的なページの作成
- 自動化テストの雰囲気も掴む。

## 1. セットアップ
- サンプルアプリケーションの作成
- gemファイルの書き足し（testグループに注意）
- `bundle install`
-  `--without production`
-  gitリポジトリの初期化　`git init, add, commit in`
-  README 入るの更新。作業内容の記入。変更のコミット。
-  `git commit -am`
-  bitbucketにプッシュ
-  変更をコミット。Herokuにプッシュ。こまめにやること。

## 2.静的ページ
- コントローラ　＝　基本的に動的なWebページの集合を束ねるコンテナ。
- トピックブランチを使うのを忘れずに。 `git checkout -b static-pages` 
- コントローラーの作成。
-  `rails g`などの短縮形
-  controllerファイルをgitリポジトリに追加。こまめにプッシュするように。
-  `rails destroy` = 関連ファイルもろともやり直せる。
-  `rails rollback`=一つ前
-  `VERSION=0`＝　初期状態

## HTTPメソッド、 GET, POST, PATH, DELETEの四つ。

- 重要なのは「Railsのビューの中には静的なHTMLがある」という点
 - Railsの知識が無くてもHomeページやHelpページを修正できる

## 3.テストから始める

### 何らかの変更を行う際には、常に「自動化テスト」を作成して、機能が正しく実装されたことを確認する習慣を

- テストの目的
-- バグの防止
-- 安全にリファクタリング(機能変更をせずにコードを改善）ができる。
-- 設計、システムの他の部分のインターフェイスを決めるときに役立つ

--- 慣れてくるとテストを先に書くようになる。
 
## テスト駆動と、一括テスト
- テストコードがシンプルなら先に書く
- 動作の仕様が固まってない場合はあとに。
- セキュリティ周り、エラーなら先に。
- バグを見つけたら、それを再現するテストを先に。
- すぐに変更しそうなコード（HTML構造の細部）に対するテストは後に。
- リファクタリングする時は先に。エラーしそう、コードが詰まりそうなところは集中的に。

### コントローラーテスト、モデルテスト、総合テストの３つ

### 最初のテスト
- get = 普通のWEBページ
- 「Homeページのテスト。GETリクエストをhomeアクションに対して発行 (=送信) せよ。そうすれば、リクエストに対するレスポンスは[成功]になるはず」
- `rails test`
- GREEN = 成功
- RED = 失敗
- RED GREEN REFACTOR というサイクル
-- テンプレート　=　ビュー　

### Refactor
 -  アプリケーションの開発が進むと、コードのどこからともなく「腐敗臭」が漂い始める
 - コードや記法の統一が崩れて読みづらくなる
 - クラスやメソッドが何百行にも膨れ上がって読む気を削がれる
 - なぜこのコードがここにあるのか最早誰もその理由を思い出せなくなる
 - 同じコードがあちこちにコピペされて少しずつ書き換えられ手に負えなくなる
 - など。

### こまめにリファクタリングを繰り返してコードを常にすみずみまで美しくコンパクトに保ち、他の開発者や未来の自分の開発意欲を阻喪することのないようにしなければならない。

### 「一匹いれば30匹いると思え」、コードの腐敗臭はどんな小さな隙間からも忍び寄ってくる。

## こまめなリファクタリングの習慣をできるだけ早いうちに身につけるように！

## 4.少しだけ動的なページ
- タイトルをテスト
- HTMLの構造
- 色々とやる笑

### レイアウトと埋め込みruby(Embedded Ruby)
- DRY = don't repeat yourselfの原則

### 繰り返しを追放してよくDRY乾かす。
- 現在は「ほぼ」同じになっているページのタイトルを「完全に」同じにしておく
- Railsのprovideメソッド `<% provide(:title, "Home") %>`
- yieldメソッド `<title><%= yield(:title) %> | Ruby on Rails Tutorial Sample App</title>`
- コードの重複を大きく削減すべし。

### ルーティングの設定
- `root 'application#hello'`を書き換え
- `root 'static_pages#home'`
- 上のルールに置き換えるとコントローラ/アクションへの対応付けが変わり、ルート「/」へのGETリクエストがStaticPagesコントローラのhomeアクションにルーティングされる。

## 5.最後に
- 次の章に進む前に、差分をコミットしてmasterブランチにマージ.
- 習慣を身につける。

## まとめ
- 今回も必要なgemのインストール、リモートリポジトリへのプッシュ、production環境まで行った
- rails generate controller ControllerName アクション名 (省略可)
- 新しいルーティングはconfig/routes.rbファイルで定義
- Railsのビューでは、静的HTMLの他にERB (埋め込みRuby: Embedded RuBy) が使える
- 常に自動化テストを使って新機能開発を進めることで、自信を持ってリファクタリングできるようになり、回帰バグも素早くキャッチできるようになる
- テスト駆動開発では「red ・ green ・REFACTOR」サイクルを繰り返す
- Railsのレイアウトでは、アプリケーションのページの共通部分をテンプレートに置くことでコードの重複を解決することができる

## 6.高度なセットアップ
- テスト用設定
 - 成功/失敗の表示設定をする「minitest reporters ( 3.6.1)」
 - ファイルの変更を検出して必要なテストだけを自動実行してくれる「Guard (3.6.2)」
- の２つ。
- masterブランチで行うように！

### minitest reporters
- `require "minitest/reporters"
Minitest::Reporters.use!`を追加！
 - minitest-reporters gemを利用している。

### Guardによるテストの自動化
- Guardは、ファイルシステムの変更を監視し、例えばstatic_pages_test.rbファイルなどを変更すると自動的にテストを実行してくれるツール
 - 具体的には、「home.html.erbファイルが変更されたらstatic_pages_controller_test.rbを自動的に実行する」といったことをやってくれる。
- Gemfileでguard gemをアプリケーション内に取り込む
- `$ bundle exec guard init`
- tmuxをインストール
- `$ sudo yum install -y tmux` Cloud9を使っている場合に必要

### `guard :minitest, spring: "bin/rails test", all_on_start: false do`　に注意
- GuardからSpringサーバーを使って読み込み時間を短縮している
- Guard使用時のSpringとGitの競合を防ぐには、.gitignoreファイルにspring/ディレクトリを追加
- cloud9の操作
- Unixのプロセスなど