オレマトペ

Webエンジニアを目指し学習中のデブアラサーによるほぼ擬音ブログ

Ruby on Rails チュートリアル第5章を終えて

f:id:Npakk:20200610222322p:plain

はじめに

このエントリーでは、Railsを勉強している私がRuby on Rails チュートリアルを学習した感想などを、
各章毎に述べていきたいと思います。
このチュートリアルを学ぶ方法は動画、電子書籍など色々な媒体で提供されておりますが、
ここではWebテキスト(第6版)を使用しております。

目次

第5章 レイアウトを作成する

今回はサンプルアプリケーションにレイアウト・スタイルを追加して見栄えをよくしていきます。
Bootstrapというフレームワークを組み込むみたいで、それを前提にHTML要素を追加します。
Bootstrapは聞いたことはあるのですが、使用するのは今回が初めてです。

nav要素、div要素、img要素などを追加して、Rubyの埋め込みソースの説明が続きます。
HTML要素に全て変換されるので、実行してどんなものが生成されるのか確認してみるといいですね。

ひとつ面白いと思ったのは、Railsはアセットパイプラインという機能を利用して、
画像などをHTMLに表示してくれるのですが、そのときに高速化を施してくれるらしい。

画像自体は、app/assets/imagesディレクトリに保存しているのですが、
アセットパイプラインを利用して書き出されたHTMLを見てみると、assetsディレクトリに保存されているようにリンクが張られているんですよ。
もちろん裏の処理で本来のディレクトリに紐付けているのですが、こういったフラットなディレクトリ構成にすることによって、より早くブラウザに表示できるみたい。
HTML自体を書くことはこれまでもあったのですが、いやー知りませんでした。 Railsとは関係なくこうすることによって早くなるのかな、どうなんだろ。

いくつかBootstrapで利用するCSSクラスを適用したHTML要素を配置したら、
RailsアプリケーションにBootstrapのgemを組み込みます。
BootstrapではLESS CSS言語を使用しているのですが、Railsのアセットパイプライン機能はデフォルトではSass言語をサポートしています。
どちらかに合わせる必要があるため、Bootstrap-sassというLESSをSassへ変換するgemを利用することにします。

これで環境的にはSass言語で統一されます。 ただし、Sass言語には2つの記法(書き方)があります。
SASS記法と、SCSS記法です。
どちらを使ってもいいのですが、筆者はSCSS記法のほうが、波括弧でCSSを括れる点が視覚的にわかりやすいので好きです。

またRailsのビューは、ERBファイルと1:1の関係というわけではなく、パーシャルという機能をつかって、
1つのビューファイルに他のERBファイルを埋め込むことが可能です。 別管理したい情報などはこの機能を使って、ファイルを分けていると修正時の影響範囲が少なくなるので、
どんどん使った方がいいと思います。

アセットパイプラインの他の機能

上記で少し紹介したアセットパイプラインですが、他にも機能があります。

アセットパイプラインでは、アセットディレクトと呼ばれるデフォルトのディレクトリにある静的ファイルを目的別に分類して利用しています。

  • app/assets:現在のアプリケーション固有のアセット
  • lib/assets:ライブラリ用のアセット
  • vendor/assets:サードパーティ用のアセット

それぞれのアセットを分類して配置してあげるのですが、このディレクトリにはサブディレクトリも存在します。

  • config
  • images
  • stylesheets

画像ならimages、CSSならstylesheetsに保存してあげるわけですね。

また、これらに配置した静的ファイルをどのように一つにまとめるかをRailsに指示するためにマニフェストファイルを利用します。 実際にまとめるのはSprocketsというgemですが、これを利用することによってひとつの静的ファイルの塊にどの要素を加えるのかを決定することができます。

様々なアセットをアセットディレクトリに配置し、プリプロセッサエンジンによって実行され、
ブラウザに配信できるようにマニフェストファイルに沿って結合され、テンプレート用に準備されます。
どのプリプロセッサエンジンを使って実行するかは拡張子によって、Railsが判断してくれます。

つまるところ、アセットパイプラインのすごいところは、
開発環境では複数あるCSSファイルを本番環境ではひとつにまとめてくれて、かつ圧縮も行ってくれるところです。
これによって高速化を図ってくれます。
圧縮された場合は見にくくなるのですが、開発者がみるときは圧縮前のファイルを見れるわけですから、
かなり便利な機能なわけです。

さて、今までつくったアプリではここのページへのアクセスを下記のURLでアクセスしていました。
/コントローラー名/help

少し省略して下記のように変更します。
/help

これを実現するにはルートファイルを編集します。

#get 'static_pages/help'
get '/help', to:'static_pages#help'

上記の変更を加えることによって、GETリクエストが/helpに送信されたときに、
コントローラーのhelpアクションを呼び出してくれます。 また、同時に名前付きルートを使用できるようになります。

そして、統合テストについても軽く学びました。
ブラウザによるページ間の遷移をもシミュレートすることができ、
これまでは特定ページが応答を返すかどうかだけだったテストが、複数ページ間で正しく遷移されるのかという点をもテストすることができます。
またページ中に特定のhtml要素が存在するかどうかもテストできるようになります。

あとがき

4章もむずかしかったですが、5章ではすでに作成しているアプリケーションを効率的にするために、
修正を加えていくためより難しい印象でした。
残り9章と先は長いですが、がんばります。