第3章 ほぼ静的なページの作成
3.1 セットアップ
本章から本格的なアプリケーション（ツイ◯ターに似ているやつ）を作成するらしい。
Webページといえば、HTMLやCSSというイメージだが、Railsでも実装できるのは知らなかった。
早速、rails newとかbundle installを実行していく。
進めていくと、演習に。
BitbucketがMarkdown記法のREADME (リスト 3.3) をHTMLとして正しく描画しているか、確認してみてください。
自分はgithubを利用しているが、HTMLとして描画しているようだ。
本番環境 (Heroku) のルートURLにアクセスして、デプロイが成功したかどうか確かめてみてください。
できたっぽい。
3.2 静的ページ
次にgit checkout -b static-pagesをしろとのこと。
どうやら、「static-pages」というブランチを切り出しておくことで、このブランチで作業できるようになるようだ。
このおかげでmasterに意図せぬ影響を与えることを防げるのだろう。
次にrails generate controller StaticPages home helpというコマンドを実行する。
これによりhomeやhelpといったページを作成できるらしい。よくわからないけど、便利っぽい。
ちなみに、単語の頭文字を大文字にしてつなぎ合わせた名前のことを「キャメルケース」と呼ぶらしい。
単語間にアンダースコアを加えて繋ぎ合わせた名前は「スネークケース」と呼ぶらしい。
Fooというコントローラを生成し、その中にbarとbazアクションを追加してみてください。
手動で作成した。
コラム 3.1で紹介したテクニックを駆使して、Fooコントローラとそれに関連するアクションを削除してみてください。
rails destroy controller コントローラー名 アクション名でいけた。
3.3 テストから始める
「テスト」という工程を加えるとコードを書く手間が増えるらしい。
しかし、手戻りが減り開発速度は上がるらしい。
ちなみに、rails generate controllerで勝手にテストファイルは生成されていたっぽい。
テストでは、
「失敗するテストを最初に書く」
「次にアプリケーションのコードを書いて成功させる (パスさせる）」
「必要ならリファクタリングする」
といった具合に進むらしい。なんのこっちゃ。
リファクタリングとは「外部から見た時の挙動は変えずに、プログラムの内部構造を整理すること」です。リファクタリングによりシステムを長く使い続けることや、トラブル時の対応を早めることが可能です。
そういえば、GETリクエストってなんだろう。
テストを進めていくと、「テンプレートがないようです」とかいってくる。Railsでは、テンプレートとはすなわち「ビュー」を指すらしい。
3.4 少しだけ動的なページ
この章では少しだけ動的にしたページを作成するようだ、。
動的とは、ページの内容に応じて表示が変わる挙動を指すっぽい。
反対に静的とは、固定的、のような意味合いに近いかもしれない。
今度は「red ・ green ・ REFACTOR」のサイクルをすべて行うらしい。
- ページタイトルの簡単なテストを書き (red)
- 3つのページにタイトルを追加し (green)
- レイアウトファイルを活用してコードの重複を解決する
とのこと。
assert_select "title", "Home | Ruby on Rails Tutorial Sample App"というコードは、
今度の演習は、長い...。
StaticPagesコントローラのテスト (リスト 3.24) には、いくつか繰り返しがあったことにお気づきでしょうか? 特に「Ruby on Rails Tutorial Sample App」という基本タイトルは、各テストで毎回同じ内容を書いてしまっています。そこで、setupという特別なメソッド (各テストが実行される直前で実行されるメソッド) を使って、この問題を解決したいと思います。まずは、リスト 3.30のテストが green になることを確認してみてください (リスト 3.30では、2.2.2で少し触れたインスタンス変数や文字列の式展開というテクニックを使っています。それぞれ4.4.5と4.2.2で詳しく解説するので、今はわからなくても問題ありません)。
中身はよくわからないが重複するコードはsetupを利用することで効率化できるっぽい。同じコードを繰り返すのはイケてないってことだろう。
読み進めていくと、
同じコードを繰り返すことはRubyの「DRY」(Don’t Repeat Yourself: 繰り返すべからず) という原則に反します。
とあるので、やっぱ繰り返しはいけていないっぽい。
次に、繰り返しを排除すべく、provideメソッドを利用すべきとのこと。
<% provide(:title, "Home") %>と<%= yield(:title) %>を利用することで置換できるっぽい。
演習も難しくなってきた。
サンプルアプリケーションにContact (問い合わせ先) ページを作成してください16 (ヒント: まずはリスト 3.15を参考にして、/static_pages/contactというURLのページに「Contact | Ruby on Rails Tutorial Sample App」というタイトルが存在するかどうかを確認するテストを最初に作成しましょう。次に、3.3.3でAboutページを作ったときのと同じように、Contactページにもリスト 3.40のコンテンツを表示してみましょう。)。
とりあえず、testファイルにcontactページが存在し、タイトルに「Contact」が含まれることを確認するコードを追記。その次にroute.rbを編集。最後に
touchコマンドでcontactページを作成。テストしてgreenになったことを確認。
リスト 3.41にrootルーティングを追加したことで、root_urlというRailsヘルパーが使えるようになりました (以前、static_pages_home_urlが使えるようになったときと同じです)。リスト 3.42のFILL_INと記された部分を置き換えて、rootルーティングのテストを書いてみてください。
test "should get root" do get static_pages_home_url assert_response :success end
と書いてテストしたら通ったので正解したかと思いきや、static_pages_home_urlではなく、root_urlらしい。どこからでてきたんだ...。
実はリスト 3.41のコードを書いていたので、先ほどの課題のテストは既に green になっているはずです。このような場合、テストを変更する前から成功していたのか、変更した後に成功するようになったのか、判断が難しいです。リスト 3.41のコードがテスト結果に影響を与えていることを確認するため、リスト 3.43のようにrootルーティングをコメントアウトして見て、 red になるかどうか確かめてみましょう (なおRubyのコメント機能については4.2.1で説明します)。最後に、コメントアウトした箇所を元に戻し (すなわちリスト 3.41に戻し)、テストが green になることを確認してみましょう。
これは本当に修正箇所が正しかったんだっけ？を確認するためにやるっぽい。