3.1のもっとも大きな新機能ですが、同時にもっとも混乱しやすい機能でもあります。PipelineがどのようにRailsアプリケーションのアセットを管理するかを見ることによって、少しその神秘性を取り除いていきたいと思います。Pipelineのページが多くの機能を説明しているので、まずそこから始めるのがいいでしょう。3.1アプリケーションを書いたことがある方なら、http://localhost:3000/assets/application.jsにアクセスすればアプリケーションのすべてのJavaScriptを含んだファイルがあることをご存知でしょう。これはどのような仕組みになっているのでしょうか?application.jsファイルには何も特別なことはありません。/app/assets/javascriptsディレクトリの下に置かれたファイルも同じくアクセス可能です。そのディレクトリにgreeting.txtというファイルを作成したら、ブラウザで同じようにhttp://localhost:3000/assets/greeting.txtにアクセスして中身を見ることができます。ファイルが/app/assets/javascriptsにあったとしても、アクセスするURLは/assets/greeting.txtになります。これは、/app/assetsの下のどのサブディレクトリにファイルを置いても同じです。任意の新規ディレクトリを作成してそこにファイルを置いたとしても、同じURLからアクセス可能です。新規ディレクトリを作成した場合は、その中のファイルにアクセスするためにサーバを再起動する必要があります。アセットを追加できる場所は/app/assetsディレクトリだけではありません。/libの下にassetsディレクトリを作成した場合、そこに追加したすべてのファイルは、メインの/app/assetsディレクトリに置いたかのようにアクセス可能になります。これは/vendor/assetsディレクトリ下のすべてのファイルにも当てはまります。現在のアプリケーションに固有ではない汎用的なアセットがある場合、/libか/vendorの下のassetsディレクトリにそれらを置くのが理想でしょう。アプリケーションがjQueryプラグインを使用している場合、そのJavaScriptファイルは、別の人が管理することになるので/vendor/assetsディレクトリにを置くのが適しています。自分で管理はするがアプリケーションに固有ではないアセットについては、/libディレクトリに置くのがいいでしょう。Pipelineはロードパスの一覧です。このリストを見るために、コンソールを実行してRails.application.config.assets.pathsを見ます。出力を読みやすくするためにYAML形式で表示させます。以下のすべてのディレクトリが表示されています。gemに由来する興味深いディレクトリがあります。openコマンドでその中身を見ることができます。jquery-railsこのコマンドは、シェルの環境変数のBUNDLER_EDITORかEDITORで定義されたテキストエディタでgemを開きます。Pipelineを介して読み込むことができるjQueryのファイルがいくつか含まれているのがわかります。Pipelineのロードパスに含まれるからです。gemが単にRubyコードを管理するためだけのものではないということを意味しています。Javascriptやその他のアセットも、gemの中で同じように管理することができるのです。gemの形式で公開される事例が増え、それによって、それらもBundlerの依存関係管理の利点を享受できるようになるでしょう。Sprocketsでアセットを管理するここでアプリケーションのapplication.jsファイルに戻って、中身を見ていくことにしましょう。.ファイルにはコメントしかありませんが、その一部は重要な意味を持っています。この種のファイルはmanifestとよばれ、内部的にはSprocketsに管理されます。そこに記述されているすべてのファイルを結合して、このファイルのコードの前にその内容をインクルードします。ここでもロードパスが機能します。jquery(拡張子の.jsは任意のため、省略できます)が含まれています。Sprocketsはロードパスの中からこのファイルを探し、今回の場合はjquery-railsエンジンのvendor/asset/javascriptsディレクトリからロードします。このロードパスに存在するすべてのJavaScriptファイルを追加できます。jquery-uiを追加すると、gemのjquery-ui.jsファイルがインクルードされます。これはCoffeeScriptファイルにも当てはまります。/app/assets/javascripts/home.js.coffeeファイルが解析されてインクルードされます。homeファイルを含める必要はありません。.があり、ここでのドット(.)はカレントディレクトリを表しているからです。これは、そのディレクトリやそのサブディレクトリにあるすべてのJavaScriptやCoffeeScriptのファイルが含まれるということです。階層の中の特定のファイルを除外したければ、それも可能です。サイトにadminページがあり、これらのページを見るときだけ特定のJavaScriptファイルが含まれるようにしたいとします。デフォルトではこれらのファイルはサイトのすべてのページに含まれてしまいます。含まれたファイルを見たい場合は、URLにdebug_assets=1パラメータを追加します。この指定によってJavaScriptファイルは結合されず、ページのソースを見ると、Sprocketsがインクルードするファイルがadminディレクトリの中のものも含めてすべて表示されます。この問題への対処方法はいくつかあります。require_treeの代わりにrequire_directoryを使用すれば、カレントディレクトリにあるファイルのみを読み込み、サブディレクトリのファイルは読み込みません。インクルードされるファイルをより詳細に制御したければ、ディレクトリ全体をインクルードするのではなく、個別のファイルをrequireすることも可能です。一つの方法として、すべてのページに含めたいJavaScriptファイルをpublicサブディレクトリに移動します。./publicを使用して、それらのファイルだけをインクルードできます。manifestにどのようなコマンドを使用できるかを知りたい方もいるでしょう。いいドキュメントがないのですが、directive_processor.rbファイルのソースコードのコメントには、動作の仕組みの説明とともに、使用できるコマンドが記載されています。Pipelineはプリプロセスにも対応しています。この仕組みを説明するために、新たに作成した/app/assets/anythingディレクトリにgreeting.txtというファイルを作成します。そのままでは、このファイルは単なる静的なテキストファイルですが、ファイル名にもう一つ拡張子を追加します。ここではこのファイルにERBコードを追加すると、それが処理されます。%>このファイルをブラウザで見てみるとERBコードが処理されているのがわかります。URLにはプロセッサの拡張子は含んでいません。基本的にこれがSASSとCoffeeScriptが動作するしくみです。プロセッサに渡されます。拡張子を連結して、例えば.scss.erbという拡張子をつけてファイルを作ることもできます。このファイルはまずERBプロセッサに渡され、その後SASSプロセッサに渡されます。プリプロセッサは自由に設定を変えることができます。独自のプロセッサを追加したり、既存のものと置き換えたりすることができます。gemによって処理されます。サイトには動作のしくみや利用できる拡張機能についての情報もあります。Pipelineの機能についての簡単な概要紹介は以上です。Pipelineは本番モードでの動作にいくつか相違点があるので、エピソードの残りを使って説明します。サーバを本番モードで起動します。productionアプリケーションのトップページにアクセスしてソースを表示させると、アセットが違う形で配信されていることがわかるでしょう。type="text/javascript"></script>ファイル名にハッシュ値が含まれていますが、これはキャッシュするためです。3.0で用いられていたクエリ文字列を追加する以前の方法と比べると、実際にファイル名を変えるこの方法の方が優れています。ファイル自身を見てみると、通信コストを少なくするためにJavaScriptが縮小化(minify)されているのがわかります。Cacheミドルウェアによって配信されるので速度はかなり速いです。代わりにWebサーバ自身にアセットの配信とホストをさせたい場合は、次のコマンドを使って事前にプリコンパイルします。assets:precompileこのコマンドで、アセットは/publicディレクトリにプリコンパイルされ、Webサーバから簡単にアクセスできます。Pipelineに関する今回のエピソードは以上です。Guideでより詳しい情報をチェックしてください。