Ruby on Railsチュートリアル　第6版　メモ

<h3>第１章　ゼロからデプロイまで</h3>
npm install -g c9

ターミナルはcontrol +　l(エル)でクリア
変更をcommand+s で保存

rails serverはターミナルタブをもう一つ開いて、そこで実行することで、最初のタブでは引き続きコマンドを入力できる
rails serverはCtrl-Cでシャットダウン

-mフラグを使うと、コミットメッセージをコマンドラインで直接指定できます。-mフラグを使わない場合はシステムのデフォルトのエディタが開き、そこでコミットメッセージを入力します（本チュートリアルでは常に-mフラグを使っていきます）

<h5>何か起きる前にリポジトリをデフォルトでprivateにしておく用心深さが大事です</h5>

git commitには現存するすべてのファイル（git mvで作成したファイルも含む）への変更を一括でコミットする-aフラグがあります。このフラグは非常によく使われます。

<h5>-aフラグは慎重に扱ってください。最後のコミット後に新しいファイルを追加した場合は、まずgit addを実行してバージョン管理下に置く必要があります。</h5>

コミットメッセージは現在形かつ命令形で書く

<h3>第2章　Toyアプリケーション</h3>

Gemfileを編集したらbundle install

Modelは単数形(ケーキの雛形で何個も作るイメージ)
ControllerとかViewは複数形

bundle execは複数バージョンのrailsがインストールされていても、Gemfileの内容に従ってrails db:migrateを実行する

rails consoleはexitかCtrl+Dで終了

herokuでデータベースマイグレーションなどのコマンドを実行するには、通常のRailsコマンドの前にheroku runを追加する

<h3>第3章 ほぼ静的なページの作成</h3>

<h5>cloud9でcommand+P(Goタブ→Go to Anything)→文字列(Gemfileなど)を検索すると便利</h5>

bundle installはGemfile.lockとGemfileの差分をインストールする
bundle updateはGemfile.lockの内容がほとんど変わっているor役に立たない場合に、１からインストールするもの

終わったら、次のように変更をコミットしてGitHubとHerokuにプッシュします。

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

<h5>アプリケーションをこまめにプッシュ/デプロイすることをオススメ。こうすることでリモートバックアップにもなり、production環境でのエラーを早めに確認することもできる。なお、Herokuに展開するときにエラーが発生した場合は、次のコマンドを実行して本番環境のログを取得してください。このログは、問題を特定するときに役立ちます。</h5>

$ heroku logs         # 直近のイベントを表示する
$ heroku logs --tail  # イベント発生のたびに自動表示する（Ctrl-Cで終了）

<h5>masterブランチは、エラーのない安定したver.を常に残しておく</h5>
<h4>rails tutorialでは、セクションごとにgit add -A, git commit -m "", git push -u origin 
 static-pages などを実行すべし</h4>

<h4>キリのいいところまで達したらリモートリポジトリ(GitHubなど)にアップロードしておくと良い</h4>
<h4>デプロイする前にテストを走らせる！</h4>
<h4>というかちょっと変更するごとにテストを走らせる！</h4>

<h5>章末にRED GREENと、自動化テストGuardについて高度な設定として書いてある.Guardの終了はCtrl+D</h5>

はっきりした原因がないのにテストが失敗する場合は、次のようにGuardをいったん終了し、Spring（Railsの情報を事前読み込みしてテストを高速化するツール）を止めて再起動してみましょう。

$ bin/spring stop    # テストが原因不明で動かなくなったら、このコマンドを実行してみる
$ bundle exec guard

<h3>第4章 Rails風味のRuby</h3>

rails consoleがおかしくなったらCtrl-Cで強制的に抜け出せる
Ctrl-Dで正常に終了することもできる
なお、一般的なターミナルと同じで、Ctrl-Pまたは上矢印キーで以前に実行したコマンドを再利用することができる
時間の節約になる

nanoエディタはCtrl-Xで終了 保存するときはy(yes)

rails consoleの代わりにpryを使用(gem install pry)

ダブルクォーテーションは式展開
シングルクォーテーションはそのまま文字列
ダブルクォート文字列の中では、バックスラッシュ文字そのものは2つのバックスラッシュによって表されます

ブロックであることを示すには波カッコで囲みますが、doとendで囲んで示すこともできます

オブジェクトを表示するためにinspectを使うことは非常によくあることなので、 pメソッドというショートカットがあります

>> p :name             # 'puts :name.inspect' と同じ
:name

Ruby では丸カッコは使用してもしなくても構いません。次の2つの行は等価です。

 メソッド呼び出しの丸カッコは省略可能。
stylesheet_link_tag('application', media: 'all',
                                   'data-turbolinks-track': 'reload')
上は以下のように書いても同じ
stylesheet_link_tag 'application', media: 'all',
                                   'data-turbolinks-track': 'reload'
ちなみに、mediaにクォーテーションが無く、data-turbolinks-trankには有るのは、-を用いてシンボルは別の意味に解釈されるので、意図的に後者にはシングルクォーテーションがついている


次に、media引数はハッシュのようですが、波カッコがない点が不思議です。実は、ハッシュがメソッド呼び出しの最後の引数である場合は、波カッコを省略できます。次の2つの行は等価です。

最後の引数がハッシュの場合、波カッコは省略可能。
stylesheet_link_tag 'application', { media: 'all',
                                     'data-turbolinks-track': 'reload' }
上は以下のように書いても同じ
stylesheet_link_tag 'application', media: 'all',
                                   'data-turbolinks-track': 'reload'

<h3>第5章 レイアウトを作成する</h3>

パーシャル
ファイル名_shim.html.erbの先頭にあるアンダースコアに注目。このアンダースコアは、パーシャルで使う普遍的な命名規約であり、また、一目見ただけでディレクトリ中のすべてのパーシャルを識別することが可能になります。

<h6>assert_selectは柔軟でパワフルな機能で、ここでは紹介し切れないほど他にも多くのオプションがあります。しかし著者の経験的には、このメソッドで複雑なテストはしない方が賢明です。今回のようなレイアウト内で頻繁に変更されるHTML要素（リンクなど）をテストするぐらいに抑えておくとよい</h6>

git merge fill~の場合、fillあたりまでタイピングした後にTabキーを押せば補完してくれる。

<h3>第6章　ユーザーのモデルを作成する</h3>
モデルは単数形だが、テーブル名は複数形

メールアドレスの重複・大文字小文字の問題

本番環境でUserモデルを使うためには、heroku runコマンドを使ってHeroku上でもマイグレーションを走らせる必要があります

<h3>第7章 ユーザー登録</h3>

デバッグ情報は開発環境のみで表示

privateキーワード以降のコードはインデントを一段深くする

integration testはストーリーで考える

<h6>仕事でHerokuを使ったアプリケーションを動かす場合はGemfileでRubyのバージョンを明示しておいた方が賢明である。これによって開発環境と本番環境の互換性を最大限に高めることができるので、（バージョンの差異による誤作動やエラーなどが無くなり）オススメ</h6>
<h3>第8章　基本的なログイン機構</h3>

バグを見つけたら、まずテストで再現！

flashの仕様は、1回目（次）のリクエストが来たときまでは生き残る
flash.nowは次のリクエストが来たら消えてください

configのどのファイルを変更したかにもよるが、rails serverを再起動して初めて適用されるconfigもあるので注意

<h3>第９章 発展的なログイン機構</h3>

ハッシュ化は不可逆
暗号化は複合できる

rails testが通っても、連続ログアウト問題などの目立たないバグが存在することもある
cookies暴走問題→BCryptのエラー→BCryptの外側でなんとかする

raiseメソッドは強制的にバグを起こして、テストの網羅性を確かめるもの

assert_equalの引数は「期待する値, 実際の値」の順序で書く

<h3>第10章 ユーザーの更新・表示・削除</h3>

Rubyではメソッドを書くときは基本シンボル

<h4>セキュリティに関してのテストは思いつく限りこれでもかというぐらいで、先に書く！</h4>

<h5>Gemfileを更新したらrails serverを再起動</h5>

paginationのデフォルトは30

リファクタリングを行う場合には、アプリケーションのコードを変更する前と後で必ずテストを実行し、いずれも GREEN になることを確認する

booleanはdefaultをfalseにしておくと、if文の中にif文の中に　...みたいにしなくて済む

<h3>第11章　　アカウントの有効化</h3>

<h4>booleanはdefault値を！</h4>

Rubyが用意しているsendメソッドは文字列の中では式展開できる。（シンボルの中では無理）

<h3>第12章　パスワードの再設定</h3>

<h3>13章　ユーザーのマイクロポスト</h3>

user:references←user_id=integerの省略形
belongs_to :userも自動生成してくれる
migarateファイルにはnull: falseやforeign_key: trueも生成されている

次のコードで使われている疑問符は、セキュリティ上重要な役割を果たしています。

Micropost.where("user_id = ?", id)
上の疑問符があることで、SQLクエリに代入する前にidがエスケープされるため、SQLインジェクション（SQL Injection）呼ばれる深刻なセキュリティホールを避けることができます。この場合のid属性は単なる整数（すなわちself.idはユーザーのid）であるため危険はありませんが、SQL文に変数を代入する場合は常にエスケープする

rails db:seedは開発環境用のサンプルデータ
fixtureはテスト環境のサンプルデータ（fixtureの場合は埋め込みRuby）

f.objectでformを作るときに参照したデータを引っ張ってこれる

<h3>第14章　ユーザーをフォローする</h3>

has_manyはメソッドを生成するメソッド

routes.rbでもresourcesなどを使えば入れ子構造を使用できる ex. #GET /users/1/following

SQLの世界では問い合わせは一回が正義！　サブセレクト