最後に3.4.2のテストを実行して、タイトルを壊していないことを確認します。上の話と一見矛盾するようですが、最初にコードを若干追加して、現在は「ほぼ」同じになっているページのタイトルを「完全に」同じにしておきます。この方が、コードの重複を一括で取り除けるからです。Home、Help、Aboutページには可変要素があるので、Railsのprovideメソッドを使ってタイトルをページごとに変更します。(これで、HTMLビューのファイルの拡張子が.html.erb.)となっている理由をおわかりいただけたと思います)。ERBはWebページに動的な要素を加えるときに使うテンプレートシステムです13。%>」という記法が使われており、その中からRailsのprovideメソッドを呼び出しています。メソッドの引数では、"Home"という文字列と:titleというラベルを関連付けています14。%>」というよく似た記法を使い、その中でRubyのyieldメソッドを呼び出しています15。このメソッドによって、テンプレートのその部分に実際のタイトルが挿入されます。App</title>この2つのERBの違いは次のとおりです。%>と書くと、中に書かれたコードを単に実行するだけで何も出力しません。%>のように等号を追加すると、中のコードの実行結果がテンプレートのその部分に挿入されます。ERBでビューをこのように書き換えても、ページの表示結果は以前とまったく同じです。タイトルの可変部分がERBによって動的に生成されている点だけが異なります。greenになるはずです。</body></html>タイトルの可変部分をERBを使って置き換えたので、現在それぞれのページは次のような構造になっています。</body></html>こうして見ると、HTMLの構造はtitleタグの内容も含めてどのページも完全に同じです。異なる点があるとすれば、bodyタグの内側のコンテンツだけです。これはもうリファクタリングしてHTMLの重複した構造をDRYにするしかないでしょう。ご想像のとおり、Railsにはそのためにapplication.html.erbという名前のレイアウトファイルがあります。最初3.4でこのレイアウトファイルの名前をわざわざ変えておきましたが、いよいよ次のコマンドでファイル名を元に戻すことにしましょう。app/views/layouts/application.html.erbこのレイアウトファイルを有効にするには、前述のデフォルトのタイトル部分を次のERBコードに差し替えます。3.35のようになります。</body></html>上のコード内にある、次の特殊なコードにご注目ください。%>このコードは、各ページの内容をレイアウトに挿入するためのものです。ここでは、このコードの詳細な動作を正確に理解することは重要ではありません。%>の位置に挿入される、ということだけ理解しておけば問題ありません。Railsのデフォルトのレイアウトでは、次の行が追加されていることにもご注目ください。%>上の3つのERBは、それぞれスタイルシート、JavaScript、csrf_meta_tagsメソッドをページ内で展開するためのものです。CSRF)を防ぐために使われるRailsのメソッドです。3.34のビューには、レイアウトと重複するHTMLがまだ残っているので、それらを削除して、内部のコンテンツだけ残します。3.38のように実に簡潔で美しいコードになります。tutorial.</p>上のように定義されたビューは、Home、Help、Aboutページの表示は以前と変わりませんが、コードの重複が大きく削減されました。この節で行ったようなちっぽけなリファクタリングですら、実際にやってみると大小さまざまなエラーが発生します。ベテラン開発者ほどこのことを骨の髄まで理解しており、どんな小さなリファクタリングでもあなどったりしません。テストスイートをきちんと整備しておくことがいかに重要であるか、皆さんにもご理解いただけると思います。開発のごく初期の段階なら全ページを目視で1つ1つ確認して回ることもできるかもしれませんが、そんな方法ではじきに手に負えなくなります。greenになることを確認するだけでOKです。skipsもちろん厳密に言えば、テストがパスしたというだけではそのコードが本当に正しいのかどうかの証明にはなりません。正しいコードに確実に近づくことができ、正しい可能性も上がります。何よりも、テストがあれば今後発生するバグを防ぐためのセーフティネットになります。App」というタイトルが存在するかどうかを確認するテストを最初に作成しましょう。3.40のコンテンツを表示してみましょう。ルーティングの設定サイトのページのカスタマイズが終わって、テストスイートも軌道に乗ってきたので、今のうちにアプリケーションルートのルーティングを設定しておきましょう。1.3.4と2.2.2でやったように、ルーティングを設定するにはroutes.rbファイルを編集して、ルート「/」とWebページを結び付けます。(3.1でApplicationコントローラにhelloアクションを追加した場合は、今のうちにアクションを削除しておくことをおすすめします)。'application#hello'次のコードに置き換えています。'static_pages#home'上のルールに置き換えるとコントローラ/アクションへの対応付けが変わり、ルート「/」へのGETリクエストがStaticPagesコントローラのhomeアクションにルーティングされます。3.7のようになるはずです。(以前、static_pages_home_urlが使えるようになったときと同じです)。3.42のFILL_INと記された部分を置き換えて、rootルーティングのテストを書いてみてください。このような場合、テストを変更する前から成功していたのか、変更した後に成功するようになったのか、判断が難しいです。(なおRubyのコメント機能については4.2.1で説明します)。なることを確認してみましょう。最後にはたから見れば、皆さんがこの章で結局どんなことを達成できたのかさっぱりわからないかもしれません。最終的にほぼ静的なページにしただけなのでしょうか。そんなことはありません。皆さんはこの章でRailsのコントローラ、アクション、ビューの開発をひととおり行ったことで、これから動的なコンテンツをどしどしサイトに追加するための準備がすっかり整ったのです。残る課題は、皆さんがこのチュートリアルをいかに最後までやりぬくか、それだけであると言ってよいでしょう。次の章に進む前に、差分をコミットしてmasterブランチにマージしておきましょう。3.2では、静的ページの開発のためのGitブランチを用意しました。ここまでの作業内容をコミットしていない場合、作業の区切りをつけるためにもコミットしましょう。pages"次にmasterブランチに移動し、1.4.4と同じ要領で差分をマージします17。(1.4.3の手順に従っていれば、リモートリポジトリにはBitbucketを使うことになるでしょう)。pushまた、この時点でHerokuにデプロイしてみてもよいでしょう。herokuデプロイする前にテストを走らせていますが、こういった習慣を身につけておくと開発に役立ちます。本章のまとめ新しいRailsアプリケーションをゼロから作成したのはこれで3度目。高度なセットアップこの追加の節は、テスト用設定について解説します。(3.6.2)」の2つです。この節で参考までに示したコードはそれなりに高度なので、今すぐ理解できるようになる必要はありません。このセクションで紹介するセットアップはmasterブランチで行う必要があるので、今のうちにブランチをmasterに切り替えておきましょう。3.44のコードをテスト用ヘルパーファイルに追加するだけです18。gemを利用しています。testコマンドを使うとき、テストをしようとする度にエディタからコマンドラインに移動して、手動でコマンドを打ち込み、実行しなければならないという点が面倒ではありませんでしたか。この不便さを取り除くために、Guardを使ってテストを自動的に実行させるようにしてみましょう。Guardは、ファイルシステムの変更を監視し、例えばstatic_pages_test.rbファイルなどを変更すると自動的にテストを実行してくれるツールです。具体的には、「home.html.erbファイルが変更されたらstatic_pages_controller_test.rbを自動的に実行する」といったことをGuardで設定することができます。gemをアプリケーション内に取り込んでいます。したがって、あとは初期化をするだけで動かすことができます。Cloud9を使っている場合は、Guardの通知を有効にするためにtmuxをインストールする必要があります。Cloud9をお使いの場合は次のコマンドでtmuxをインストールしてください。controller_test(resource)end上のコードにある次の行にご注目ください。(SpringはRailsの機能の1つです)。開始時にテストスイートをフルで実行しないようGuardに指示しています。Guard使用時のSpringとGitの競合を防ぐには、.gitignoreファイルにspring/ディレクトリを追加します。.gitignoreはGitの設定ファイルの1つで、ここで指定されたファイルはGitリポジトリに追加されなくなります。クラウドIDEでは次の操作を行います。files./spring/*.pidSpringサーバーは本節の執筆時点では若干不安定な点が残っていて、Springのプロセスが起動したまま多数残留すると、テストのパフォーマンスが低下してしまうことがあります。(process)」と呼ばれる、一種のコンテナの内部で実行されています。システム上で動いているすべてのプロセスは、psコマンドにauxオプションを付けて実行することで確認できます。auxプロセスの種類を指定してフィルタするには、psの結果をUnixの「パイプ」|でつないで、パターンマッチャーであるgrepに渡します。ago表示結果の中で重要なのは最初の列の数値です。これはプロセスid、略してpidと呼ばれるものです。12241行儀の悪いRailsサーバーなどのプロセスをkillする際には、上のように1つずつkillすることをおすすめします。server)などと実行します。時には特定の名前を持つプロセスをまとめてkillしたいこともあります。しつこいspringプロセスたちを1つずつkillするのは大変面倒です。一括killを行うには、最初にspringコマンドそのものでプロセスを停止しておく必要があります。stopこのコマンドが効かないことも多いので、そのときはいよいよpkillコマンドでspringの名前を指定してkillします。<プロセス名>で整理してみましょう。(1.3.2でやったようにRailsサーバーのターミナルと別にするのがポイントです)、次のコマンドを実行します。3.45のルールは本チュートリアルに最適化したものなので、例えばコントローラのファイルを変更すると、Guardは即座にそれを検出して、そのコントローラの統合テストを自動実行します。(このとき、Springサーバーに接続できないなどのエラーが表示されることがあります。問題を修正するには、もう一度Returnキーを押します)。Guardを終了するにはCtrl-Dキーを押します。これで高度なセットアップは終了です。次の章に進む前に、ここまでの変更を忘れずにコミットしておきましょう。「hello」アプリ「toy」アプリ「sample」アプリには同じファイル名が多数あるため、これらのアプリを同じプロジェクトに置くとファイルを見つけにくくなることがあります。「Gemfile」というファイル名を検索すると、GemfileやGemfile.lockを含め、候補が6つも表示されてしまいます。そこで、この先に進む前に先の2つのアプリを思い切って削除しておくとよいでしょう。(その必要があればですが)。productionオプションを一度実行すると「記憶される」ことにご注意ください。installを実行すると、このオプションが暗黙的に適用されるようになります。最終的には皆さんがPostgreSQLをdevelopment環境にインストールして設定できるようになるのが理想ですが、今は時期尚早であると考えます。(クラウドIDEの場合は<自分のシステム>にLinuxと指定します)。Appの実装例には、READMEにLICENSEファイルに対するリンクがありますが、詳細なLICENSEの内容はREADMEには加えていません。完全なLICENSEファイルが欲しい場合は、こちらからダウンロードしてください。完全なLICENSEファイルがなくても本チュートリアルを完走することはできます。ここで静的なページを作るために採用した方法は、おそらく最もシンプルな方法です。他にも方法はあります。最適な方法は状況によって異なり、例えば極めて多数の静的なページを1つのStaticPagesコントローラだけまかなおうとすると重荷になる可能性があります。今回はいくつかの静的なページを作るだけなので、重荷にはなりません。呼ばれるショートカットを作っています。rと実行するとrailsコマンドが実行される、といった具合です。sとコマンドを打つだけでRailsサーバーを立ち上げられるようになります。filesを読んでみてください。テスティングよ栄えよ。testでテストが失敗すると赤色で表示しますが、テストが成功しても緑色で表示しません。色もちゃんと表示したい場合は3.6.1をご覧ください。HTMLの仕様は時とともに変わる可能性があると思っておく方がよいでしょう。今後もブラウザでなるべく正しくページを表示できるように、doctypeを明示的に宣言しています。html>」は、最新標準であるHTML5の特徴です。利用可能なアサーション』を読んでみてください。3.6では代わりにSafariを使っています。3.6のようにページタイトルのみを表示していました。3.6で実際にアクセスしているURLは「<ドメイン名>/static_pages/home」ですが、Safariはドメイン名のみを表示している点にも注意してください。開発環境によって違いはあると思いますが、少なくともCloud9とSafariでアクセスするとこのように表示されます。筆者は個人的にHamlの方が気に入っています。残念ながら十分に普及していないため、初級者向けチュートリアルの採用は見送りました。Pipelineと併用すると正常に動作しないことがあります。provideメソッドはcontent_forの代替です。Rubyを勉強したことのある方であれば、Railsはブロックの内容をyieldしていると推測することでしょう。その推測はおそらく正しいでしょう。Rails開発のためにこれらの詳細を知る必要はありません。この演習は5.3.1に解答があります。*.pidを実行してpidファイルを削除してください。両方が含まれています。reportersのドキュメントではダブルクオーテーションを使っていることが原因です。Rubyでは、この2つのクオーテーションを併用することが一般的です。詳しくは4.2.2で解説します。testコマンドが使われています。testに読み替える必要があります。株式会社によって運営されています。基づく表記プライバシーポリシーお問い合わせTIPS原著者からのメッセージ目次コードサンプルみんなのつぶやきRailsガイド。