ASCIIcasts - Full Episode Feed

Draper

Sun, 16 Oct 2011 22:26:42 +0000

今回のエピソードではDraperを紹介します。Draperはpresenterパターンに似た形でRailsアプリケーションのビューにdecoratorを追加できるようにするgemです。テンプレートやヘルパーメソッドに多くの複雑なビューロジックを持っているような場合に、Draperを利用してよりオブジェクト指向のアプローチをとることでコードをすっきりと整理できます。今回のエピソードでそのしくみを紹介します。

対象のアプリケーションを下に示します。ユーザプロファイルのページにそのユーザに関する各種の情報が表示されています。その内容は、アバター画像、フルネーム、ユーザ名、Markdownで記述された簡単な略歴、WebサイトとTwitterフィードへのリンクです。ユーザがWebサイトの情報を入力した場合は、アバター画像とフルネームはそのサイトへのリンクになります。

ページは単純な構造のように見えますが、MrMysteryさんのようにあまり情報を入力していないユーザについても正しく処理しなくてはいけません。

このユーザはユーザ名を入力しただけなので、フルネームの代わりにユーザ名、デフォルトのアバター画像、その他のフィールドには代替テキストを表示しています。このように情報量に応じてユーザを正しく扱うために多くのif条件を持つことで、このページのテンプレートはより複雑になっています。このロジックの一部をどこか他に移すことができれば、このテンプレートをずっとすっきりした形に変えることができるでしょう。

/app/views/users/show.html.erb

<div id="profile">
  <%= link_to_if @user.url.present?, ↵ 
  image_tag("avatars/#{avatar_name(@user)}", class: "avatar"), ↵
  @user.url %>
  <h1><%= link_to_if @user.url.present?, ↵
    (@user.full_name.present? ? @user.full_name : ↵
    @user.username), @user.url %></h1>
  <dl>
    <dt>Username:</dt>
    <dd><%= @user.username %></dd>
    <dt>Member Since:</dt>
    <dd><%= @user.member_since %></dd>
    <dt>Website:</dt>
    <dd>
    <% if @user.url.present? %>
      <%= link_to @user.url, @user.url %>
    <% else %>
      <span class="none">None given</span>
    <% end %>
    </dd>
    <dt>Twitter:</dt>
    <dd>
    <% if @user.twitter_name.present? %>
      <%= link_to @user.twitter_name, ↵
  "http://twitter.com/#{@user.twitter_name}" %>
    <% else %>
      <span class="none">None given</span>
    <% end %>
    </dd>
    <dt>Bio:</dt>
    <dd>
    <% if @user.bio.present? %>
      <%=raw Redcarpet.new(@user.bio, :hard_wrap, :filter_html, ↵
        :autolink).to_html %>
    <% else %>
      <span class="none">None given</span>
    <% end %>
    </dd>
  </dl>
</div>

このロジックはビュー関連のため、モデル側に抽出する訳にはいきません。解決策としては、ヘルパーメソッドを使うことが考えられます。このテンプレートではすでに、アバターを表示するためにimage_tagというヘルパーを使っています。その中身を見てみましょう。

/app/helpers/users_helper.rb

module UsersHelper
  def avatar_name(user)
    if user.avatar_image_name.present?
      user.avatar_image_name
    else
      "default.png"
    end
  end
end

このヘルパーメソッドは現在のユーザがアバターを持っているかどうかを判断して、持っていない場合にデフォルト画像のファイル名を返します。ビューからさらにロジックをヘルパーメソッドとして抽出することもできますが、この方法の問題はそれらがグローバルな名前空間の単なるメソッドでありまったくオブジェクト指向ではないという点です。

Draperのインストール

このケースはpresenter(Draperの用語ではdecorator)を使う例として適しているので、このアプリケーションにDraperを追加してみましょう。Draper gemは通常の方法でインストールします。Gemfileに参照情報を追加してbundleコマンドを実行します。

/Gemfile

source 'http://rubygems.org'

gem 'rails', '3.1.0'
gem 'sqlite3'


# Gems used only for assets and not required
# in production environments by default.
group :assets do
  gem 'sass-rails', "  ~> 3.1.0"
  gem 'coffee-rails', "~> 3.1.0"
  gem 'uglifier'
end

gem 'jquery-rails'
gem 'redcarpet'

gem 'draper'

Draperがインストールされたら、Userモデルに対してdecoratorを作成するためにdraper:decoratorジェネレータを実行します。

$ rails g draper:decorator user
      create  app/decorators
      create  app/decorators/application_decorator.rb
      create  app/decorators/user_decorator.rb

これが初めてのdecoratorなので、application_decoratorも同時に作成されます。作成されるdecoratorはすべてApplicationDecoratorを継承するので、すべてのdecoratorで共通の機能はすべてそこで定義します。

UserDecoratorクラスは見た通り単純で、ほとんどがそのしくみを説明するコメントになっています。それではこれを使って、テンプレートの整理を始めましょう。

プロファイルページを整理する

プロファイルページでDraperを使うためにはまずUsersController内のshowアクションを修正する必要があります。このアクションは、現状では通常の方法でUserを取得します。

/app/controllers/users_controller.rb

class UsersController < ApplicationController
  def index
    @users = User.all
  end

  def show
    @user = User.find(params[:id])
  end
end

このユーザをdecoratorでラップ(wrap)するために、User.findをUserDecorator.findで置き換えます。

/app/controllers/users_controller.rb

def show
  @user = UserDecorator.find(params[:id])
end

これでこのコードはUserDecoratorインスタンスを返すようになりました。UserDecoratorはUserレコードをラップして、デフォルトではすべてのメソッドをUserに委譲します(これについては後ほど詳しく説明します)。UserではなくUserDecoratorを対象にするように変わったにもかかわらず、アクションは以前と同じように動作します。それではビューの整理を始めますが、まずはユーザのアバターを表示するコードを修正します。

/app/views/users/show.html.erb

<%= link_to_if @user.url.present?, image_tag( ↵ 
  "avatars/#{avatar_name(@user)}", class: "avatar"), @user.url %>

ビューのこの部分を次のように置き換えます。

/app/views/users/show.html.erb

<%= @user.avatar %>

このコードはUserDecoratorのavatarメソッドを探すので、次にそのメソッドを書きます。このメソッドを書くときに注意しなくては行けないことがいくつかあります。decoratorからヘルパーメソッド(例えばlink_to_ifメソッド)を呼び出す場合は、hメソッド(helperの略)を介する必要があります。モデルを参照したいときは、今回の場合でいえば@userではなく、modelを呼び出します。

ビューからavatarにコピーしたコードでは、avatar_nameヘルパーメソッドを呼び出しています。decoratorからavatar_nameを呼び出しているので、avatar_nameをUsersHelperクラスからdecoratorに移動します。これで同じクラス内にメソッドがあるので、Userを渡す必要はなく、userの呼び出しをモデルに置き換えることができます。

/app/decorators/user_decorator.rb

class UserDecorator < ApplicationDecorator
  decorates :user
  
  def avatar
    h.link_to_if model.url.present?, h.image_tag("avatars/#{avatar_name}", class: "avatar"), model.url
  end
  
  private
  def avatar_name
    if model.avatar_image_name.present?
      model.avatar_image_name
    else
      "default.png"
    end
  end
end

次にユーザ名を表示するコードを整理します。ビューのこのコードを置き換えます。

/app/views/users/show.html.erb

<h1><%= link_to_if @user.url.present?, (@user.full_name.present? ? @user.full_name : @user.username), @user.url %></h1>

これを次のように書き換えます。

/app/views/users/show.html.erb

<h1><%= @user.linked_name %></h1>

UserDecoratorにlinked_nameメソッドを書かなくてはいけません。テンプレートから取り出したコードと前に書いたavatarメソッドには似ている点があります。どちらもリンクを表示させますが、その内容はユーザのURLが存在する場合はそれに依存して変わります。今はひとつのクラスの中にあるので、この重複は簡単にリファクタリングできます。

リンク生成処理を扱うためにsite_linkというプライベートメソッドを新たに作成します。このメソッドにはパラメータとしてcontentを渡します。これで、avatarとlinked_nameの両方のメソッドからこのメソッドを呼び出すことができ、きれいに整理できます。前と同じように、linked_nameの中の@userの呼び出しはすべてmodelに置き換えます。これらの修正がすべて終わると、decorator は以下のようになります。

app/decorators/user_decorator.rb

class UserDecorator < ApplicationDecorator
  decorates :user
  
  def avatar
    site_link h.image_tag("avatars/#{avatar_name}", ↵
      class: "avatar")
  end
  
  def linked_name
    site_link(model.full_name.present? ? model.full_name : ↵
      model.username)
  end
  
  private
  def site_link(content)
    h.link_to_if model.url.present?, content, model.url
  end
  
  def avatar_name
    if model.avatar_image_name.present?
      model.avatar_image_name
    else
      "default.png"
    end
  end
end

ここでユーザのプロファイルページを読み込み直すと、前とまったく同じように表示されるでしょう。

テンプレートは十分きれいになったようですが、まだ改善の余地があります。次はビューコードの中のより大きな部分をリファクタリングします。ユーザのWebサイトへのリンクを表示する部分のコードです。

/app/views/user/show.html.erb

<dt>Website:</dt>
<dd>
  <% if @user.url.present? %>
    <%= link_to @user.url, @user.url %>
  <% else %>
    <span class="none">None given</span>
  <% end %>
</dd>

これを下の内容で置き換えます。

/app/views/user/show.html.erb

<dt>Website:</dt>
<dd><%= @user.website %></dd>

前と同じようにメソッドをdecoratorクラスの中に作成します。ビューから削除したコードを見ればわかりますが、ユーザがurlを持たない場合はあるHTMLが表示されます。これを単に文字列として返すこともできますが、生のHTMLをRubyプログラムの中に置きたくありません。別の解決法として、コードを部分テンプレート(partial)に移動して表示させるというやり方がありますが、たかだか一つのHTML要素を出力するだけなので、content_tagヘルパーメソッドを使うほうが合理的でしょう。

/app/decorators/user_decorator.rb

def website
  if model.url.present?
    h.link_to model.url, model.url
  else
    h.content_tag :span, "None given", class: "none"
  end  
end

Twitterの情報とユーザの略歴をそれぞれ表示するテンプレートの部分についても同じ手法をとることができます。ここでは詳細は述べませんが、修正後のビューのコードはずっときれいになります。

/app/views/users/show.html.erb

<div id="profile">
  <%= @user.avatar %>
  <h1><%= @user.linked_name %></h1>
  <dl>
    <dt>Username:</dt>
    <dd><%= @user.username %></dd>
    <dt>Member Since:</dt>
    <dd><%= @user.member_since %></dd>
    <dt>Website:</dt>
    <dd><%= @user.website %></dd>
    <dt>Twitter:</dt>
    <dd><%= @user.twitter %></dd>
    <dt>Bio:</dt>
    <dd><%= @user.bio %></dd>
  </dl>
</div>

decorator内の新しいtwitterとbioの各メソッドは次のようになります。

/app/decorators/user_decorator.rb

def website
  if model.url.present?
    h.link_to model.url, model.url
  else
    h.content_tag :span, "None given", class: "none"
  end  
end

def twitter
  if model.twitter_name.present?
    h.link_to model.twitter_name, ↵  
      "http://twitter.com/#{model.twitter_name}"
  else
    h.content_tag :span, "None given", class: "none"
  end
end
  
def bio
  if model.bio.present?
    Redcarpet.new(model.bio, :hard_wrap, :filter_html, ↵
 		:autolink).to_html.html_safe
  else
    h.content_tag :span, "None given", class: "none"
  end
end

2つの新しいメソッドはとても似ていて、前に書いたwebsiteにも似ています。3つのメソッドの多くの部分、特にelse節が重複しています。そこでこの部分を独立したメソッドとして抽出するのがいいでしょう。

そのためにはブロックが役に立つでしょう。else節を独立したメソッドとして抽出し、handle_noneという名前にします。存在を確認したい値とブロックをこのメソッドに渡します。値が存在したらブロック内のコードが実行され、なければspanタグを表示します。このhandle_noneを使って、website、twitter、bioの各メソッドを整理します。

/app/decorators/user_decorator.rb

def website
  handle_none model.url do
    h.link_to model.url, model.url
  end  
end
  
def twitter
  handle_none model.twitter_name do
    h.link_to model.twitter_name, ↵ 
      "http://twitter.com/#{model.twitter_name}"
  end
end
  
def bio
  handle_none model.bio do
    Redcarpet.new(model.bio, :hard_wrap, :filter_html, ↵
      :autolink).to_html.html_safe
  end
end
  
private
def handle_none(value)
  if value.present?
    yield
  else
    h.content_tag :span, "None given", class: "none"
  end
end

もう一つ修正できる点として、Markdownの表示処理をApplicationDecoratorに抽出して、今後作るかもしれない他のdecoratorから呼び出せるようにします。新たにmarkdownメソッドを作成し、そこで渡されたテキストを表示処理します。

/app/decorators/application_decorator.rb

class ApplicationDecorator < Draper::Base
  def markdown(text)
    Redcarpet.new(text, :hard_wrap, :filter_html, ↵ 
      :autolink).to_html.html_safe
  end
end

これでUserDecorator内でbioメソッドからmarkdownを呼び出すように修正できます。

/app/decorators/user_decorator.rb

def bio
  handle_none model.bio do
    markdown(model.bio)
  end
end

モデルを修正する

decoratorが正しく機能するように設定できたので、ここでモデル層を一度見渡してみて、もしビュー関連のコードがあったらそれを対応するdecoratorに移動させます。例えば、Userモデルにはユーザが作成された時間をフォーマットするmember_sinceメソッドがあります。このコードは、フォーマットされた文字列を返すだけなのでビュー関連だと見なされます。これをdecoratorに移動します。

/app/models/user.rb

class User < ActiveRecord::Base
  def member_since
    created_at.strftime("%B %e, %Y")
  end
end

作業としてはメソッドをdecoratorに移動して、created_atの前にmodelを付けるだけです。

/app/decorators/user_decorator.rb

def member_since
  model.created_at.strftime("%B %e, %Y")
end

`allows`メソッドを用いてモデルへのアクセスを制限する

UserDecoratorを修正している間に、Draperのもう一つの機能であるallowsを紹介します。デフォルトではUserDecoratorはすべてのメソッドをUserオブジェクトに委譲しますが、Userモデルに委譲されるメソッドを選択して指定することも可能です。それにはallowsを使って委譲したいメソッドの名前を渡します。

/app/decorators/user_decorator.rb

class UserDecorator < ApplicationDecorator
  decorates :user
  allows :username

  # Other methods omitted
end

ここではusernameのみの委譲を許可し、これによってusernameメソッドだけがUserに委譲されます。これが、decoratorになくてビューから呼び出される唯一のメソッドなので、委譲しなくてはいけないメソッドはこれだけです。これによって、decoratorのインタフェースをより細かく制御できるようになります。

decoratorに必要なものを抽出するリファクタリング作業がすべて終了したので、ユーザのプロファイルページを再度読み込んですべてが変わらず表示されることを確認します。

正しく表示されています。念のため他のユーザを見てもすべて同じように表示されていますが、ビューコードは以前よりずっときれいに整理されました。

decoratorを使用することで、1050バイト、34行だったshowテンプレートは382バイト、16行になったので、サイズを2/3削減したことになります。見た目もずっときれいになり、ページのレイアウトを変更したい場合の編集作業もずっと簡単にできるようになりました。

Spork

Sun, 16 Oct 2011 22:24:20 +0000

食器の一種と同じ名前であるSporkは、アプリケーションのテストスイートの読み込みを高速化するRuby gemです。今回のエピソードではこのSporkを使ってアプリケーションのテストの速度を向上させる方法を紹介します。

通常Railsアプリケーションのテストスイートを実行すると、数秒間の停止状態のあとテストが開始されます。対象のアプリケーションのテストで、timeコマンドを使ってこの停止時間を計測してみます。

$ time rspec .
.........

Finished in 1.98 seconds
9 examples, 0 failures

real	0m11.090s
user	0m9.735s
sys	0m1.306s

RSpecの表示ではテストの実行時間はせいぜい1〜2秒となっていますが、rspecを実行してからコマンドプロンプトに戻るまでの時間はそれよりもずっと長く、11秒を超えています。余分にかかっているのはRailsアプリケーションを読み込むための時間で、今見たようにこれはテスト自体を実行する時間よりも多くかかっています。Sporkはこの問題を解決するのに役立ちます。

Sporkのインストール

Sporkは他のgemと同じようにインストールできますが、テストのみで使用されるためGemfileのtestグループに追加します。Rails 3アプリケーション用には、このgemのプレリリース版(現状は0.9.0.rc)をインストールします。

/Gemfile

gem "rspec-rails", :group => [:test, :development]
group :test do
  gem "factory_girl_rails"
  gem "capybara"
  gem "guard-rspec"
  gem "spork", "> 0.9.0.rc"
end

いつもと同じく、Gemfileを修正してbundleを実行すると、記述されたgemがインストールされます。

次にSporkのbootstrapコマンドを実行してヘルパーファイルを準備します。

$ spork --bootstrap
Using RSpec
Bootstrapping /Users/eifion/auth/spec/spec_helper.rb.
Done. Edit /Users/eifion/auth/spec/spec_helper.rb now with your favorite text editor and follow the instructions.

上の出力からわかるように、RSpecを使用していることをSporkが検知してspec_helperファイルを修正しました。修正箇所を確認してみます。

/spec/spec_helper.rb

require 'spork'

Spork.prefork do
  # Loading more in this block will cause your tests to run faster. However,
  # if you change any configuration or code from libraries loaded here, you'll
  # need to restart spork for it take effect.

end

Spork.each_run do
  # This code will be run each time you run your specs.

end

Sporkがspec_helperに2つのメソッドを追加していて、それぞれがブロックを持っています。1つ目はpreforkで、Sporkサーバが起動するときに実行されます。もうひとつはeach_runで、テストスイートを実行するたびに起動されます。spec_helperのコードをできるかぎりpreforkに移して、なるべく一度実行されるだけで済むようにするのがいいでしょう。一度すべてのコードを移動してみて、それでもテストが正しく動作するか見てみます。

/spec/spec_helper.rb

require 'rubygems'
require 'spork'

Spork.prefork do
  # This file is copied to spec/ when you run 'rails generate ↵
  rspec:install'
  ENV["RAILS_ENV"] ||= 'test'
  require File.expand_path("../../config/environment", __FILE__)
  require 'rspec/rails'
  require 'capybara/rspec'

  # Requires supporting ruby files with custom matchers and ↵
    macros, etc,
  # in spec/support/ and its subdirectories.
  Dir[Rails.root.join("spec/support/**/*.rb")].each {|f| ↵
    require f}

  RSpec.configure do |config|
    config.mock_with :rspec
    config.use_transactional_fixtures = true
    config.include(MailerMacros)
    config.before(:each) { reset_email }
  end
end

Spork.each_run do
  # This code will be run each time you run your specs.
end

Sporkを利用するには、sporkコマンドを実行してサーバを起動します。

$ spork
Using RSpec
Preloading Rails environment
Loading Spork.prefork block...
Spork is ready and listening on 8989!

サーバが起動するとpreforkメソッド内のコードが実行されるので、このコードは一度だけ実行されるだけですみます。続いて別のターミナルウィンドウを開いて、テストスイートを実行します。テストはSporkサーバを介して実行しなくてはいけないので--drbオプションを指定します。

テストをSporkを介して実行すると、specスイートはより早く実行されます。timeコマンドの下で再度実行してみると終了までの時間が短くなっています。これによって得られる時間は、Railsアプリケーションの規模が大きくなるほど増えていきます。

$ time rspec . --drb
.........

Finished in 2.21 seconds
9 examples, 0 failures

real	0m4.125s
user	0m0.342s
sys	0m0.097s

Sporkはとても便利なツールです。テスト環境でアプリケーションを一度起動して、テストを実行するたびにアプリケーションを読み込みなおすことなく、何回でも好きなだけ実行できます。

SporkとGuardの連携

Guardは、アプリケーションのテストスイートのコードが修正されるたびにテストを自動実行してくれるgemです。エピソード264[動画を見る, 読む]でその詳細を紹介しました。そのGuardをguard-sporkというgemを使ってSporkと連携させることができます。このgemはSporkのときと同じ方法でインストールできます。Gemfileのtestグループにgemを追加してbundleを実行します。

/Gemfile

gem "rspec-rails", :group => [:test, :development]
group :test do
  gem "factory_girl_rails"
  gem "capybara"
  gem "guard-rspec"
  gem "spork", "> 0.9.0.rc"
  gem "guard-spork"
end

gemがインストールされたら、guard init sporkを実行してGuardfileにSporkを追加します。Guardfileの中を見てみると、RSpecセクションの下にSporkセクションができています。

/Guardfile

guard 'spork', :cucumber_env => { 'RAILS_ENV' => 'test' }, :rspec_env => { 'RAILS_ENV' => 'test' } do
  watch('config/application.rb')
  watch('config/environment.rb')
  watch(%r{^config/environments/.+\.rb$})
  watch(%r{^config/initializers/.+\.rb$})
  watch('spec/spec_helper.rb')
end

この部分は他のテスト関連のguardよりも先に実行されなければいけないので、このセクションをRSpecセクションの上に移動します。さらにRSpec guardを修正して、:cliオプションを追加して値として--drbを渡します。これによってspecがSporkを介して実行されるようになり、他の、例えばCucumber用のguardにも適用されます。

guard 'rspec', :version => 2, :cli => '--drb' do
  # Content omitted.
end

これでSporkサーバを手動で起動する必要がなくなりました。Guardを開始すると自動的にSporkがバックグラウンドで起動され、アプリケーションのRubyファイルに変更が加えられるとテストスイートを実行します。

$ guard
Please install rb-fsevent gem for Mac OSX FSEvents support
Using polling (Please help us to support your system better than that.)
Please install growl_notify or growl gem for Mac OS X notification support and add it to your Gemfile
Guard is now watching at '/Users/eifion/auth'
Starting Spork for RSpec 
Using RSpec
Preloading Rails environment
Loading Spork.prefork block...
Spork is ready and listening on 8989!
Spork server for RSpec successfully started
Guard::RSpec is running, with RSpec 2!
Running all specs
Running tests with args ["--color", "--format", "progress", "--format", "Guard::RSpec::Formatter::NotificationRSpec", "--out", "/dev/null", "--require", "/Users/eifion/.rvm/gems/ruby-1.9.2-p180@rails31/gems/guard-rspec-0.4.5/lib/guard/rspec/formatters/notification_rspec.rb", "spec"]...
.........

Finished in 4.29 seconds
9 examples, 0 failures
Done.

これはSporkを別で管理するよりもずっと簡単です。アプリケーションのファイルかspecを変更して保存すると、関連のspecが1〜2秒後に実行されます。

Sporkの設定

次にSporkの設定を変更する方法を見てみます。アプリケーションのファイルを修正したときに、Sporkが変更を検知せず手動で再起動しなくてはいけない場合があります。この原因は、ファイルがpreforkブロックで読み込まれ、each_runでは再読み込みされないからです。これはFactory Girlを使用している場合に発生するときがあります。その場合にファクトリはpreforkで読み込まれるので、テストスイートが再実行されるときにそこでの変更は検知されないからです。すべての変更が自動的に検知されるようにするためには、each_runでファクトリを再読み込みする必要があります。Factory Girlの最新版にはこれを行うreloadメソッドがあるので簡単に対応できます。

/spec/spec_helper.rb

Spork.each_run do
  FactoryGirl.reload
end

ファクトリに対して行ったすべての変更は、次回のテスト実行時に自動的に検知されます。

同じような問題が/spec/supportディレクトリ内のファイルでも起こる可能性があります。これらのファイルもpreforkブロックで呼び出されるので、変更をしたとしてもテストが実行されるときに検知されません。ファイルを読み込むコードをeach_runに移動させる方法もありますが、コードを移動させた分だけ、テストが実行される前の遅れの時間が長くなってしまいます。コードはpreloadブロックの中に置いたままで、/spec/supportの中のファイルが変更されるたびに自動的にSporkが再読み込みされるようにできればその方がいいでしょう。

このためにはguard-sporkが役に立ちます。Guardfileのsporkブロックにはファイル名のパターンが含まれ、それによって監視するファイルが定義されています。パターンにマッチするファイルのいずれかが変更されるとSporkが読み込み直されます。ここにspec/supportディレクトリを追加するだけです。

/Guardfile

guard 'spork', :cucumber_env => { 'RAILS_ENV' => ↵
  'test' }, :rspec_env => { 'RAILS_ENV' => 'test' } do
  watch('config/application.rb')
  watch('config/environment.rb')
  watch(%r{^config/environments/.+\.rb$})
  watch(%r{^config/initializers/.+\.rb$})
  watch('spec/spec_helper.rb')
  watch(%r{^spec/support/.+\.rb$})
end

これでspec/supportディレクトリ内のファイルへの変更がGuardに検知されてSporkが読み込み直されるようになります。

Guardfileを見ているついでに、速度の遅いテストスイートに対応するための簡単なチップを一つ紹介します。実行時間が1分以上かかるようなテストはあまり何度も実行したくないでしょう。そのような場合にrspec guardに渡す、役に立つ2つのオプションがあります。all_on_startとall_over_passです。これらの両方をfalseに設定します。

/Guardfile

guard 'rspec', :version => 2, :cli => '--drb', ↵
  :all_on_start => false, :all_after_pass => false do
  
# watch commands omitted.
end

これらのオプションが設定されると、Guardは前回失敗したspecが成功した場合にすべてのspecを再実行しません。これによって、すべてのspecが実行される場合の挙動を細かくコントロールできます。Guardターミナル(Guardの最新版を使用している場合)でリターンキーを押すとすべてのspecを実行します。

もうひとつのチップは、Sporkとは直接関連しませんが大きなテストスイートを扱う場合に役に立ちます。RSpecの設定ブロックに3行(以下に示すブロックの最後の3行)を追加します。

/spec/spec_helper.rb

RSpec.configure do |config|
  config.mock_with :rspec
  config.use_transactional_fixtures = true
  config.include(MailerMacros)
  config.before(:each) { reset_email }
    
  config.treat_symbols_as_metadata_keys_with_true_values = true
  config.filter_run :focus => true
  config.run_all_when_everything_filtered = true
end

これで、あるspecに:focusタグを追加すると、そのspecだけが実行されるようになります。例えばUserモデルをテストするspecに:focusを追加します。

/spec/models/user_spec.rb

require 'spec_helper'

describe User do
  describe "#send_password_reset" do
    let(:user) { Factory(:user) }

    it "generates a unique password_reset_token each time", ↵
      :focus do
      user.send_password_reset
      last_token = user.password_reset_token
      user.send_password_reset
      user.password_reset_token.should_not eq(last_token)
    end

	# Other specs omitted.
  end
end

上のファイルを保存すると、Guardは変更を検知しますが:focusタグによってそのひとつのspecだけが実行されます。

Running: spec/models/user_spec.rb
Running tests with args ...
Run filtered including {:focus=>true}
.

Finished in 1.93 seconds
1 example, 0 failures
Done.

意図に反してSporkのpreforkブロックで一部のコードが呼び出される場合がありますが、それをeach_runに移動するのは簡単ではありません。このようなケースに対処するためにSporkはtrap_methodメソッドを提供しています。このメソッドは、トラップされたメソッドがすぐに実行される代わりに、プロセスがフォークされた後に実行するようにします。これはMongoidやDeviseを使用する場合などに有効です。どちらも、ロードされてほしくないpreforkブロックの中身をロードするからです。これについてはSporkのwikiページでより詳しく説明されています。

Sporkについての今回のエピソードは以上です。Sporkはテスト駆動開発のプロセスを加速させる優れたツールで、上で紹介したチップスと組み合わせることで、大規模なRailsプロジェクトにも対応することができます。

Active Admin

Sun, 02 Oct 2011 22:21:54 +0000

今回のエピソードではActive Adminを見ていきます。このgemを使うとRailsアプリケーションに管理用画面を簡単に追加できます。見栄えのする管理用画面を作成できるだけでなく、自由にカスタマイズ可能です。ライブデモで実際に動作する様子を見ることができます。

今回のエピソードでは、既存のRailsアプリケーションにActive Adminを追加します。対象のアプリケーションは簡単なEコマースアプリで、複数の商品があり、それぞれが価格を持ちカテゴリに属します。Active Adminを使って管理用画面を作成して商品を管理できるようにします。

Active Adminをインストールする

Active Adminはgemとして配布されていて通常の方法でインストールできます。Gemfileに参照情報を追加しbundleコマンドを実行します。このアプリケーションはRails 3.1で作成されるため、Active Adminが依存するsass-rails gemも忘れずにインクルードするようにします。Rails 3.0の環境ではこの問題は存在しないためインクルードする必要はありません。

/Gemfile

gem 'activeadmin'

Bundlerが終了したら、ジェネレータを実行してアプリケーションにActive Adminを追加します。このジェネレータが、実行後に追加で行なわなくてはいけない設定作業についての指示を与えてくれます。開発環境のMailer設定でホストオプションを追加する必要があります。また、root URLを設定することとアプリケーションのレイアウトファイルでnoticeとalertのフラッシュメッセージを追加することを忘れないようにしてください。

$ rails g active_admin:install
      invoke  devise
    generate    devise:install
      create    config/initializers/devise.rb
      create    config/locales/devise.en.yml
  
==================================================================

Some setup you must do manually if you haven't yet:

  1. Setup default url options for your specific environment. Here is an example of development environment:

       config.action_mailer.default_url_options = { :host => 'localhost:3000' }

     This is a required Rails configuration. In production it must be the actual host of your application

  2. Ensure you have defined root_url to *something* in your config/routes.rb.
     For example:

       root :to => "home#index"

  3. Ensure you have flash messages in app/views/layouts/application.html.erb. For example:

       <p class="notice"><%= notice %></p>
       <p class="alert"><%= alert %></p>

今回のアプリケーションではこれらすべてについて対応したので、次に進みます。

コマンドがマイグレーションをいくつか生成したので、それをここで実行します。

$ rake db:migrate

Active Adminを利用する

Active Adminのドキュメンテーションを見ると、インストール時にユーザが新規作成され、ユーザ名がadmin@example.com、パスワードがpasswordに設定されるとあります。この認証情報を使ってログインします。(ユーザ名とパスワードをカスタマイズしたければ、マイグレーションの実行前にdevise_create_admin_users.rbを編集します。) Railsサーバを起動してhttp://localhost:3000/adminにアスセスするとログインフォームが表示されるので、先ほどの認証情報を使ってログインします。

ログインするとActive Adminのダッシュボードが表示されますが、まだあまり見るべきものはありません。

商品を管理できるようにしたいので、次のコマンドを実行してProductリソースをActive Adminに追加します。

$ rails g active_admin:resource product
      create  app/admin/products.rb

このジェネレータがアプリケーションのapp/adminディレクトリの下にproducts.rbファイルを作成します。管理用ダッシュボードを再度読み込み直すとProductsリンクが表示されます。このリンクをクリックすると商品を管理するのに必要なものがすべて入ったページが現れます。

このページは、属性によって商品を並べ替えたり絞り込むことができます。さらにActive AdminはCategoryに対してbelongs_toの関係が設定されていることを検知して、商品をカテゴリで絞り込むためのドロップダウンメニューを表示してくれます。これは新しい商品を作成するときにも機能します。それぞれのデータ型によって、カテゴリはドロップダウンリストとして表示され、その他の属性は入力フィールドが表示されます。

この機能は簡単にカスタマイズできます。まず最初に商品カタログページをカスタマイズして、表示される列数を減らします。そのためには、生成された/app/admin/products.rbファイルを修正します。indexメソッドをオーバーライドして、カタログページを変更します。このメソッドにはブロックがあり、そこでcolumnを呼び出してページに表示する列を指定します。

/app/admin/products.rb

ActiveAdmin.register Product do
  index do
    column :name
    column :category
    column :released_at
    column :price
  end
end

商品ページを再度読み込むと、希望する列が表示されています。

Categoryとの関連が自動的に検知されて、それぞれの商品に正しいカテゴリが表示されています。

カスタマイズをさらに進めて、columnの1つ目の引数としてタイトルを渡して列のタイトルを変更します。この方法で、released_atフィールドの名前を変更します。

/app/admin/products.rb

ActiveAdmin.register Product do
  index do
    column :name
    column :category
    column "Release Date", :released_at
    column :price
  end
end

列の値を変更したい場合は、columnにブロックを渡します。価格フィールドには今のままでは通貨記号が表示されていないので、これを修正します。columnメソッドはブロックをとることができ、それを追加することで現在のモデルインスタンス(この例ではProduct)がブロックに渡されます。そしてブロックから返される値がその列に表示されます。ここでヘルパーメソッドにアクセスすることができるので、number_to_currencyを使って価格を正しく表示できます。

/app/admin/products.rb

ActiveAdmin.register Product do
  index do
    column :name
    column :category
    column "Release Date", :released_at
    column :price do |product|
      number_to_currency product.price, :unit => "&pound;"
    end
  end
end

ページを再度読み込むと、タイトルが「発売日(Release Date)」に変わり、商品の価格が正しい通貨の表記で表示されています。

価格フィールドから返される値をカスタマイズしているので、このフィールドは並べ替えることができなくなりました。また各項目の編集と削除のリンクもなくなっています。これを修正します。ブロックを使って値をカスタマイズする場合は、常に合わせて:sortableオプションでActive Adminに対して並び替えの方法を指定するようにします。この修正を行い、加えてdefault_actionsを呼び出して編集と削除のリンクを元のように表示させます。

/app/admin/products.rb

ActiveAdmin.register Product do
  index do
    column :name
    column :category
    column "Release Date", :released_at
    column :price, :sortable => :price do |product|
      number_to_currency product.price, :unit => "&pound;"
    end
    default_actions
  end
end

価格フィールドには通貨記号が表示されるようになりましたが、右寄せされていたらより見やすいでしょう。これはCSSを使って対応可能ですが、そのためにはまず列を参照する方法が必要です。Active AdminはMarkabyによく似たHTML生成の方法を提供します。必要な作業は、メソッドを呼び出して生成したいタグの名前を指定するだけです。:classオプションを一緒に指定して、CSSから参照できるようにします。

/app/admin/products.rb

ActiveAdmin.register Product do
  index do
    column :name
    column :category
    column "Release Date", :released_at
    column :price, :sortable => :price do |product|
      div :class => "price" do
        number_to_currency product.price, :unit => "&pound;"
      end
    end
    default_actions
  end
end

これでactive_admin.css.scssファイルを修正してこの列のスタイルを変えることができます。

/app/assets/stylesheets/active_admin.css.scss

// Active Admin CSS Styles
@import "active_admin/mixins";
@import "active_admin/base";

// To customize the Active Admin interfaces, add your
// styles here:
.price {
  text-align :right;
}

価格の列が正しく右寄せされました。

スコープ

Active Adminのもう一つの優れた機能がスコープです。あらかじめ用意されたフィルタのように動作し、2段階の作業で作成できます。まずproductsのActive Adminの設定ファイルでスコープの呼び出しを追加し、スコープの名前を渡します。

/app/admin/products.rb

ActiveAdmin.register Product do
  scope :unreleased
  index do
    column :name
    column :category
    column "Release Date", :released_at
    column :price, :sortable => :price do |product|
      div :class => "price" do
        number_to_currency product.price, :unit => "&pound;"
      end
    end
    default_actions
  end
end

次にProductモデルにそのスコープを記述します。

/app/models/product.rb

class Product < ActiveRecord::Base
  belongs_to :category
  scope :unreleased, where(:released_at => nil)
end

商品の管理用画面を再度読み込むと、スコープのリストが表示されています。クリックすると、そのスコープでフィルタがかけられた商品のリストが表示されます。

ダッシュボードをカスタマイズする

次にダッシュボードのカスタマイズ方法を見ていきます。デフォルトでは空になっているので、最近の商品を表示するように修正します。そのために/app/admin/dashboards.rbファイルを編集します。このファイルのコメントに役に立つドキュメントがあり、いろいろなカスタマイズ方法が説明されています。

ダッシュボードにセクションを追加するにはsectionメソッドを使用します。表に最近の商品をリスト表示したいのですが、そのためにはtable_forコマンドを使用します。そのブロックで、商品カタログの管理用画面をカスタマイズしたときと同じ方法で、表示したい列をcolumnを使って指定します。また、すべての商品を表示するページへ戻るためのリンクも追加します。

/app/admin/dashboards.rb

ActiveAdmin::Dashboards.build do
  section "Recent Products" do
    table_for Product.order("released_at desc").limit(5) do
      column :name
      column :released_at
    end
    strong { link_to "View All Products", admin_products_path }
  end
end

ダッシュボードを再度読み込み直すと、最新発売された商品5件がリンクと一緒に表示されます。

一覧中の各商品にそれぞれの管理用画面へのリンクがあればより便利でしょう。そのためには、価格の列を編集したときのように、columnメソッドにブロックを渡します。

/app/admin/dashboards.rb

ActiveAdmin::Dashboards.build do
  section "Recent Products" do
    table_for Product.order("released_at desc").limit(5) do
      column :name do |product|
        link_to product.title, admin_product_path(product)
      end
      column :released_at
    end
    strong { link_to "View All Products", admin_products_path }
  end
end

link_toにはパスを定義するより簡単な方法があります。admin_product_path(product)を使う代わりに、配列で1個目の要素にシンボルを、2個目にproductを指定して渡します。

link_to product.title, [:admin, product]

ダッシュボードを再度読み込むと、各商品のタイトルがリンクとして表示されます。リンクのひとつをクリックすると、その商品の管理ページが開きます。

スタイルシートを修正する

Active AdminをRails 3.1の環境で利用する場合に注意しなくてはいけない問題があり、トップページに戻るとそれを確認できます。

Active Adminのスタイルシートがすべてのページにインクルードされているため、ページの体裁が前と違って表示されてしまいます。Rails 3.1では、 application.cssマニフェストファイルのrequire_tree .の行の影響で、デフォルトではすべてのスタイルシートがインクルードされます。これは希望する形ではないので、アプリケーションのスタイルシートをより細かく制御できるように、とりあえずこの行を削除してしまうのがいいでしょう。メインのアプリケーションにもう一つのスタイルシートがあるだけなので、require_tree .をrequire productsに置き換えます。

/app/assets/stylesheets/application.css

/*
 * This is a manifest file that'll automatically include all the stylesheets available in this directory
 * and any sub-directories. You're free to add application-wide styles to this file and they'll appear at
 * the top of the compiled file, but it's generally better to create a new file per style scope.
 *= require_self
 *= require products 
*/

/* Rest of file omitted */

より優れた解決策は、SASSのimportコマンドに切り替える方法です。アプリケーションのメインのCSSファイルのファイル名に拡張子の.scssを追加してSASSに切り替えます。その上でファイルの最初にあるマニフェスト(上のコードで示した部分)を削除して、ファイルの最後にimportコマンドを追加します。

/app/assets/stylesheets/application.css.scss

/* Styles omitted */

@import "products";

ここでトップページを再度読み込むと、正しいスタイルシートだけが読み込まれるので、ページは正しく表示されます。

グローバル設定

Active Adminには/config/initializersディレクトリにもう一つの設定ファイルがあります。今回のエピソードの残りを使って、これを見ていきます。ファイルには多くの設定オプションが含まれ、そのほとんどはコメントアウトされています。唯一有効になっているのが管理用サイトのタイトルで、これを変更してみます。

/config/initializers/active_admin.rb

ActiveAdmin.setup do |config|

  # == Site Title
  #
  # Set the title that is displayed on the main layout
  # for each of the active admin pages.
  #
  config.site_title = "Eifion's Store"

  # Other configuration options omitted.
end

変更を反映させるためにサーバを再起動すると、新しいタイトルが表示されます。

今回のエピソードは以上です。今回触れることができなかった点がたくさんあるので、ドキュメンテーションを参照してその他の機能を確認することをお勧めします。Active Adminのすべての画面は目的に合うように外観と機能をカスタマイズできるので、Railsアプリケーションに管理機能を付加したい場合には強力な解決策になります。

Sorceryで認証

Wed, 28 Sep 2011 18:43:16 +0000

エピソード250[動画を見る, 読む]で、Railsアプリケーションにゼロから認証機能を追加しました。既存のサードパーティ製のツールを使いたい場合は、一部の機能を自動化してくれるgemがいくつかありますが、今回のエピソードではSorceryを紹介します。

Sorceryはシンプルなツールです。わずか20のメソッドを持つだけですが、およそ必要な認証機能のすべてを提供します。そのシンプルさに反してフル機能を持ち、またモジュール方式をとっているため、例えばパスワードの初期化、活動ログなど、必要な部品のみを選択して有効化できます。Sorceryは他の認証用gemと比較するとより低いレベルで動作し、コントローラ層やビュー層のコーディングは開発者にゆだねられています。今回のエピソードではこのSorceryを使って既存のRailsアプリケーションに認証機能を付加していきます。

はじめに

対象とするアプリケーションはいたってシンプルです。ウェルカム画面を持っていて、そこには秘密のページへのリンクがあります。現時点では秘密のページは誰でも見ることができますが、ログインしたユーザのみがアクセスできるように制限をかけようと思います。このためにはアプリケーションに認証機能を追加する必要があり、ここでSorceryが登場します。

Sorceryはgemとして提供され、通常の方法でインストールを行います。Gemfileに参照情報を追加し、bundleコマンドを実行します。

/Gemfile

gem 'sorcery'

Bundlerが終了したら、Sorceryの初期化ファイルを追加するために次のコマンドを実行します。(この詳細は後ほど説明します。)

$ rake sorcery:bootstrap

次にsorcery_migrationを作成します。これを使って、追加したいSorceryモジュールを選択します。ここでは、単純なパスワード認証に必要なcoreモジュールと、remember_meモジュールをインクルードします。すべてのモジュールのリストを参照するためには、SorceryのREADMEをチェックしてください。

$ rails g sorcery_migration core remember_me
      create  db/migrate/20110914221626_sorcery_core.rb
      create  db/migrate/20110914221627_sorcery_remember_me.rb

コマンドを実行すると、選択したモジュールに応じていくつかのmigrationファイルが生成されます。sorcery_coreのmigrationを見ると、新しいusersテーブルに追加される属性が確認できます。

/db/migrate/20110914221626_sorcery_core.rb

class SorceryCore < ActiveRecord::Migration
  def self.up
    create_table :users do |t|
      t.string :username,         :null => false  
      t.string :email,            :default => nil 
      t.string :crypted_password, :default => nil
      t.string :salt,             :default => nil
      t.timestamps
    end
  end

  def self.down
    drop_table :users
  end
end

デフォルトではmigrationはusernameフィールドを作成します。usernameフィールドはemailフィールドと同じく必要ないため、該当行をコメントアウトします。

/db/migrate/20110914221626_sorcery_core.rb

class SorceryCore < ActiveRecord::Migration
  def self.up
    create_table :users do |t|
      # t.string :username,         :null => false  
      t.string :email,            :default => nil 
      t.string :crypted_password, :default => nil
      t.string :salt,             :default => nil
      t.timestamps
    end
  end
end

Sorceryの設定を変更して、 usernameの代わりにemailを使用するよう指定します。このためにSorceryの初期化ファイルを修正します。このファイルの最初で、有効化したいモジュールを特定します。coreモジュール以外で使用するのはremember_meモジュールだけですが、ここでそれを追加します。

/config/initializers/sorcery.rb

# The first thing you need to configure is which modules you need in your app.
# The default is nothing which will include only core features (password encryption, login/logout).
# Available submodules are: :user_activation, :http_basic_auth, :remember_me, 
# :reset_password, :session_timeout, :brute_force_protection, :activity_logging, :external
Rails.application.config.sorcery.submodules = [:remember_me]

# Rest of file omitted.

他にもここで指定できる設定オプションがあり、それらはファイル内でわかりやすく説明されています。ほとんどは変更する必要はありませんが、ひとつだけusername_attribute_nameは変更する必要があります。このオプションを有効化して、その値をユーザを特定するのに使うフィールドである:emailに変更します。

/config/initializers/sorcery.rb

config.user_config do |user|
  # -- core --
  user.username_attribute_name = :email                                          
	# change default username
	# attribute, for example, 
	# to use :email as the login.                                                                                                                                                                          

	# Other options omitted.
end
# This line must come after the 'user config' block.
config.user_class = "User"                                                          	
# define which model authenticates                                                                   	
# with sorcery.
end

ファイルの最後には、Sorceryが認証に利用するモデルの名前を指定するための設定項目があり、デフォルトではUserになっています。このアプリケーションにはまだUserモデルがないため、ここで作成することにします。すでにUserのフィールドを定義するmigrationファイルがあるので、Railsに対してモデル作成時にそれを生成しないように指定します。

$ rails g model user --skip-migration

UserモデルでSorceryを有効化するために、コードを一行追加します。

/app/models/user.rb

class User < ActiveRecord::Base
  authenticates_with_sorcery!end

これにより、Userモデルで認証を扱えるようにいくつかのメソッドが追加されます。しかし、検証(validation)や属性を保護する機能は追加されません。それらを追加するかどうかは開発者にゆだねられます。

/app/models/user.rb

class User < ActiveRecord::Base
  authenticates_with_sorcery!  
  attr_accessible :email, :password, :password_confirmation
  
  validates_confirmation_of :password
  validates_presence_of :password, :on => :create
  validates_presence_of :email
  validates_uniqueness_of :email
end

ここでmigrationを実行し、usersテーブルを作成します。

$ rake db:migrate

コントローラとビューを追加する

Userモデルの準備ができたので、対応するコントローラを設定します。まず登録手続きを処理するUsersControllerを作成します。

$ rails g controller users new

ログイン処理をおこなうSessionsControllerも作成します。

$ rails g controller sessions new

これは、エピソード250で認証機能をゼロからに作ったときの作業に似ているので、ここは簡単に触れるだけにします。UsersControllerは標準的なもので、newアクションでUserを新規作成し、 createアクションでは渡されたパラメータからUserを新規作成します。

/app/controllers/users_controller.rb

class UsersController < ApplicationController
  def new
    @user = User.new
  end
  
  def create
    @user = User.new(params[:user])
    if @user.save
      redirect_to root_url, :notice => "Signed up!"
    else
      render :new
    end
  end
end

newテンプレートも標準的なもので、新規ユーザを作成するフォームにemail、password、password_confirmationの各フィールドと、検証エラーを表示するためのコードが含まれています。

/app/views/users/new.html.erb

<h1>Sign Up</h1>

<%= form_for @user do |f| %>
  <% if @user.errors.any?%>
    <div class="error_messages">
      <h2>Form is invalid</h2>
      <ul>
        <% for message in @user.errors.full_messages %>
          <li><%= message %></li>
        <% end %>
      </ul>
    </div>
  <% end %>
  <div class="field">
    <%= f.label :email %>
    <%= f.text_field :email %>
  </div>
  <div class="field">
    <%= f.label :password %>
    <%= f.password_field :password %>
  </div>
  <div class="field">
    <%= f.label :password_confirmation %>
    <%= f.password_field :password_confirmation %>
  </div>
  <div class="actions"><%= f.submit %></div>
<% end %>

SessionsControllerの中身は、より興味深いものになっています。newアクションがありますがコードを追加する必要がないので、次にテンプレートを見てみます。ここでは、簡単なログインフォームで、emailとpasswordのためのテキストフィールドとremember_meフィールドのためのcheckboxを持ったものを作ります。

/app/views/sessions/new.html.erb

<h1>Log in</h1>

<%= form_tag sessions_path do %>
  <div class="field">
    <%= label_tag :email %>
    <%= text_field_tag :email, params[:email] %>
  </div>
  <div class="field">
    <%= label_tag :password %>
    <%= password_field_tag :password %>
  </div>
  <div class="field">
    <%= check_box_tag :remember_me, 1, params[:remember_me] %>
    <%= label_tag :remember_me %>
  </div>
  <div class="actions"><%= submit_tag "Log in" %></div>
<% end %>

ログインフォームを処理するためのcreateアクションを作成します。Sorceryではloginというメソッドが提供され、 3つのパラメータをとります。ユーザ名かメールアドレス、入力されたパスワード、remember_meチェックボックスの値です。このメソッドが認証を行い、一致するものが見つかった場合にそのUserを返します。これを確認して、ユーザが見つかったらトップページにリダイレクトします。見つからなかったら、フラッシュメッセージと共にログインフォームを再度表示します。

/app/views/controllers/sessions_controller.rb

class SessionsController < ApplicationController
  def new
  end
  
  def create
    user = login(params[:email], params[:password], ↵
      params[:remember_me])
    if user
      redirect_back_or_to root_url, :notice => "Logged in!"
    else
      flash.now.alert = "Email or password was invalid."
    end
  end
end

ユーザが見つかった場合にトップページにリダイレクトさせるときに、redirect_toを使う代わりに、Sorcery が提供するredirect_back_or_toというメソッドを使います。このメソッドはredirect_toと同じように振るまいますが、SorceryがURLを保存している場合は、コードで指定したURLではなく保存されたURLにリダイレクトします。これで便利なのは、あるページにアクセスしたユーザをまずログインさせたいという場合に、Sorceryがそのユーザをログインページに誘導し、ログインが成功したら最初に訪れようとしていたページに戻してくれる点です。

ユーザがログアウトする手段も提供しなくてはいけないので、コントローラにdestroyアクションも追加します。Sorceryにはlogoutというメソッドがあり、これを呼び出すことでユーザをログアウトさせることができます。ユーザがログアウトした後は、トップページにリダイレクトします。

/app/views/controllers/sessions_controller.rb

def destroy
  logout
  redirect_to root_url, :notice => "Logged out!"
end

次にroutesファイルを開いて、すべてをつなげるために、デフォルトの自動生成されたアクションを次のルートで置き換えます。

/config/routes.rb

Auth::Application.routes.draw do
  get "logout" => "sessions#destroy", :as => "logout"
  get "login" => "sessions#new", :as => "login"
  get "signup" => "users#new", :as => "signup"
  resources :users
  resources :sessions
  get "secret" => "home#secret", :as => "secret"
  root :to => "home#index"
end

認証に関連する機能を処理するいくつかの名前付きルート(named routes)やリソース(resources)があります。

新しく作成したこれらのページにユーザがアクセスできるように、新規にリンクが必要です。それらをレイアウトページに追加して、アプリケーションのすべてのページから見えるようにします。current_userメソッドを使って、ユーザがログインがしているかどうかを確認できます。もしログインしていたら、メールアドレスをログアウトのリンクと一緒に表示します。もし現在のユーザがいない場合は、登録かログインをさせるためのページへのリンクを表示します。

/app/views/layouts/application.html.erb

<!DOCTYPE html>
<html>
<head>
  <title>Auth Example</title>
  <%= stylesheet_link_tag    "application" %>
  <%= javascript_include_tag "application" %>
  <%= csrf_meta_tags %>
</head>
<body class="<%= params[:controller] %>">
  <div id="container">
    <div class="user_nav">
      <% if current_user %>
        Logged in as <%= current_user.email %>.
        <%= link_to "Log out", logout_path %>
      <% else %>
        <%= link_to "Sign up", signup_path %> or
        <%= link_to "Log in", login_path  %>.
      <% end %>
    </div>
    <% flash.each do |name, msg| %>
      <%= content_tag :div, msg, :id => "flash_#{name}" %>
    <% end %>
    <%= yield %>
  </div>
</body>
</html>

サイトをテストする準備ができました。トップページにアクセスすると、登録とログインのリンクが表示されています。

登録をクリックすると登録フォームが表示され、そのサイトに対してユーザ登録を行うことができます。その後、ログインをクリックして、登録した情報でログインすることができます。

権限を与える

サイトにログインしたので、秘密のページにアクセスすることができます。ログアウトしてから秘密のページにアクセスしてみると、まだページを見ることができます。そこで権限を付与する機能を追加して、ログインユーザだけがページにアクセスできるよう制限をかけます。

秘密の(secret)ページは、HomeController内のアクションです。Sorceryが提供するrequire_loginというbefore_filterを使えば、アクションへのアクセスを制限することが可能です。これを使ってsecretアクションへのアクセスを制限します。

/app/controllers/home_controller.rb

class HomeController < ApplicationController
  before_filter :require_login, :only => :secret

  def index
  end

  def secret
  end
end

このフィルターが起動されると、Sorceryはnot_authenticatedメソッドを呼び出します。ApplicationControllerでこのメソッドをオーバーライドするのがいいでしょう。そうすることによって、権限が付与されなかったときの動作を制御することができます。ログインページにリダイレクトして警告メッセージを表示します。

/app/controllers/application_controller.rb

class ApplicationController < ActionController::Base
  protect_from_forgery
  
  private
  def not_authenticated
    redirect_to login_url, :alert => "First log in to view ↵
    this page."
  end
  
end

ログアウトした状態で再度秘密のページにアクセスしてみると、ログインページにリダイレクトされてそこには警告メッセージが表示されています。

ログインすると秘密のページにリダイレクトされます。これはログインページにリダイレクトされたときに見ようとしていたページをSorceryが憶えているからです。

Sorceryに関する今回のエピソードは以上です。今回紹介した以外にも多くの機能があるので、ドキュメンテーションを参照してください。少し低いレベルで動作する認証ソリューションを探している場合は、Sorceryを検討してみる価値があるでしょう。

Rails 3.1へのアップグレード

Sun, 18 Sep 2011 21:10:55 +0000

Rails 3.1がついにリリースされました。新機能についての優れた概要説明がRailsGuidesサイトのリリースノートにあります。また新機能のいくつかについては、Railscastsサイトとこのサイトでも紹介されています。今回のエピソードでは、Rails 3.0アプリケーションを3.1にアップグレードする方法に焦点をあて、Railscastsサイトを例として説明していきます。

サイトを準備する

サイトをRails 3.1にアップグレードする前に、いくつかの準備作業が必要です。現在のサイトがRails 3.0の最新バージョン(現時点では3.0.10)で動いていなければ、更新を行います。これには、Gemfileでバージョンを設定してbundleを実行します。

/Gemfile

gem "rails", "3.0.10"

次にアプリケーションのテストスイートを実行して、テストがすべて成功することと非推奨エラー(deprecation error)が出ていないことを確認します。もしエラーがある場合は、それらを修正してからこの後の作業に進みます。Railscastsのコードはテストがすべて成功したので、引き続きアップグレード作業に移ります。

アップグレード

サイトのアップグレード作業を開始する準備ができました。これを、rails31という名前の新しいGitブランチを作成してその中で行うことにします。

$ git checkout -b rails31

Rails 3.1へのアップグレードは至ってシンプルです。ただ単にアプリケーションのGemfileを開いて、バージョン番号を3.1の最新リリース(現時点では3.1.0)に変更します。

/Gemfile

gem "rails", "3.1.0"

bundle updateを実行して新バージョンをインストールします。唯一もう一ヶ所修正が必要なのが設定ファイルのdevelopment.rbで、次の行を削除するかコメントアウトします。

/config/development.rb

# config.action_view.debug_rjs = true

テストを再度実行すると、すべて成功します。Railsサーバを正常に起動することもでき、ブラウザから参照できます。

Asset Pipelineを使用するためのアプリケーションの修正

Asset PipelineはRails 3.1の主な新機能のひとつですが、今回のアプリケーションでは画像ファイル、スタイルシート、JavaScriptファイルがまだ/publicディレクトリの下にあるので、その機能をまだまったく活かせていません。Asset Pipelineは完全にオプションの機能であるため、有効化させない限りはその機能は現れません。そのため、それを使うのかどうかまだわからない時点であっても、Rails 3.1へのアップグレードを思いとどまる必要はありません。アップグレードがいかに簡単かということを考えたら、それを今行わない理由はありません。

もしAsset Pipelineの機能を使いたければ、有効化する必要があります。そのためには次の行をGemfileに追加します。(これらの行は、新規にRails 3.1アプリケーションを作成したときに生成されるGemfileに入っています。)

/Gemfile

# Gems used only for assets and not required
# in production environments by default.
group :assets do
  gem 'sass-rails', " ~> 3.1.0"
  gem 'coffee-rails', " ~> 3.1.0"
  gem 'uglifier'
end

gem 'jquery-rails'

このコードがassetsグループを作成し、そこにいくつかのアセット関連のgemを入れます。また、jquery-rails gemをインクルードしてjQueryが使えるようにします。(もしPrototypeを使いたい場合は、代わりにprototype-rails gemを使用します。)さらに/config/application.rbのコードの以下の部分：

/config/application.rb

# If you have a Gemfile, require the gems listed there, including any gems
# you've limited to :test, :development, or :production.
Bundler.require(:default, Rails.env) if defined?(Bundler)

を以下のように書き換えます。

/config/application.rb

if defined?(Bundler)
  # If you precompile assets before deploying to production, 
    use this line
  Bundler.require *Rails.groups(:assets => %w(development test))
  # If you want your assets lazily compiled in production, 
    use this line
  # Bundler.require(:default, :assets, Rails.env)
end

このコードは、Bundlerで要求されるグループにassetsグループを追加します。続いてAsset Pipelineを有効化するためにこのファイルのApplicationクラスの中に次のコードを追加します。

/config/application.rb

# Enable the asset pipeline
config.assets.enabled = true

# Version of your assets, change this if you want to expire all your assets
config.assets.version = '1.0'

このコードがAsset Pipelineを有効化し、バージョン番号を設定します。アセットに有効期限を設定したい場合はこの値を変更します。

合わせてenvironmentの各設定ファイルの設定を変更します。まず最初はdevelopment.rbです。いくつかの箇所を変更して、アセットを圧縮せず、asset debuggingを有効化するよう設定します。

/config/environments/development.rb

  # Do not compress assets
  config.assets.compress = false
  
  # Expands the lines which load the assets
  config.assets.debug = true

次にproduction.rbを変更します。

/config/environments/production.rb

# Compress JavaScript and CSS
config.assets.compress = true
   
# Don't fallback to assets pipeline
config.assets.compile = false
   
# Generate digests for assets URLs
config.assets.digest = true

本番モード(production mode)ではアセットを圧縮したいのですが、compileをfalseに設定して、プリコンパイル時にはAsset Pipelineが機能しないようにします。またdigestをtrueに設定して、アセットのURLがfingerprintされるようにしました。もちろん、作成するアプリケーションが本番モードでどう振舞ってほしいかに合わせて、これらのオプションを違うように設定することも可能です。

最後にテスト環境を修正します。ここではオプションを追加して、静的なアセットが返されキャッシュされるようにして、かつasset debuggingを有効化します。

/config/environments/test.rb

# Configure static asset server for tests with Cache-Control for performance
config.serve_static_assets = true
config.static_cache_control = "public, max-age=3600"

# Allow pass debug_assets=true as a query parameter to load pages with unpackaged assets
config.assets.allow_debugging = true

アプリケーションのソースコード管理にGitを使っている場合、.gitignoreファイルも修正して、無視する項目のリストに.sass-cacheディレクトリを追加します。これはGitではSASSのキャッシュは不要だからです。

/.gitignore

.sass-cache/

アセットを移動する

Asset Pipelineが設定できたので、app/assetsディレクトリを作成します。そしてimages、javascripts、stylesheetsの各ディレクトリを/public から/app/assetsに移動します。

$ mkdir app/assets
$ mv public/images/ app/assets/
$ mv public/javascripts/ app/assets/
$ mv public/stylesheets/ app/assets/

移動したファイルのうちのいくつか、例えばjavascriptsディレクトリのjQuery関連のファイルはもはや必要ありません。これらはjQuery gemに含まれているので、jquery.js、jquery.min.js、rails.jsは削除します。ここで、エピソード279[動画を見る, 読む]で行ったのと同じように、jQueryプラグインなどのファイルを/lib/assetsか/vendor/assetsに移すかどうかを決めておくのがいいでしょう。

次にmanifestファイルを作成します。このアプリケーションにはすでにapplication.jsファイルとapplication.cssファイルがそれぞれ対応するディレクトリに存在するので、新たに作成する必要はありません。ではCSSファイルから始めることにします。これをmanifestファイルにするために、最初の部分にコメントを追加してSprocketsに対してどのファイルをインクルードするかを指示します。(Sprocketsの記法についてもエピソード279で紹介しました。)Sprocketsに対して、そのファイルの残りの部分と、stylesheetsディレクトリとそのサブディレクトリ以下のその他のすべてのファイルをインクルードするように指示します。

/app/assets/stylesheets/application.css

/*
*= require_self
*= require_tree .
*/

/* rest of file omitted */

application.jsファイルについても同じように指示できますが、ここではjQueryをインクルードしたいので、少し違う方法で行います。

/app/assets/javascripts/application.js

//= require jquery
//= require jquery_ujs
//= require_self
//= require_tree .

/* rest of file omitted */

ここでも、ファイル自体にコードが含まれるのでrequire_selfを追加し、同じディレクトリの他のファイルがインクルードされるようrequire_treeを追加します。

またアプリケーションのレイアウトファイルを開いてstylesheetファイルとJavaScriptファイルをインクルードしている行を修正して、関連するapplicationファイルだけを参照するようにします。というのも、その他のファイルはmanifestを介してインクルードされるからです。

/app/views/layouts/application.html.erb

<%= stylesheet_link_tag "application" %>
<%= javascript_include_tag "application", "http://cdn.sublimevideo.net/js/3s7oes9q.js" %>

アプリケーションが必要とするJavaScriptファイルには、Asset Pipelineを介して読み込まれない外部ファイルも含まれます。この場合もやはり上のファイルのリストに含む必要があります。

ではここでブラウザからアプリケーションを見てみて、変更点がうまく動いているか確認します。その前にbundleを再度実行して、追加したgemをインストールします。インストールが完了したらサーバを起動します。

$ rails s

ほとんどはうまくいきますが、一部の画像、例えば画面上部のロゴが正しく表示されません。

この問題の原因は、画像のURLがレイアウトファイルに直書きされていることにあります。

/app/views/layouts/application.html.erb

<img src="/images/railscasts_logo.png" width="423" height="56" alt="RailsCasts = Ruby on Rails Screencasts"/>

アプリケーションの画像はもう/public/imagesディレクトリにはないので、これはうまくいきません。一番簡単に解決する方法は、画像のURLを/images/railscasts_logo.pngから/assets/railscasts_logo.pngに変更することのように思えますが、開発モードではうまく行っているように見えても、本番モードでは問題が発生します。assets.digestオプションを有効化すると、名前の後ろにハッシュ値が追加され、それによってファイルへの静的な参照は機能しなくなります。代わりに常にヘルパーメソッドを使用するようにします。これで、開発モードと本番モードの両方で画像に正しくリンクが貼られます。

/app/views/layouts/application.html.erb

<%= image_tag("railscasts_logo.png", :size => "423x56", :alt => "RailsCasts - Ruby on Rails Screencasts") %>

アプリケーション全体で検索して、静的に参照されているアセットすべてについて、上の画像のようにヘルパーメソッドを使用するよう修正します。ページを再度読み込むと画像が表示されるので、Asset Pipelineが正しく機能していることがわかります。

これでアプリケーションをRails 3.1にアップグレードする作業は終わりです。他にも便利な新機能がいくつかあるので、自分のアプリケーションの役に立つかどうかを確認するためにRails 3.1に関する他のエピソードも見てみることをお勧めします。

Foreman

Sun, 04 Sep 2011 20:59:59 +0000

Ryan Batesが最近Twitterで、Railsアプリケーションの開発モード(development mode)で、依存するバックグラウンドプロセスを管理する最善の方法は何かと質問を投げかけました。何人かがForemanを推奨していたので、今回のエピソードで紹介します。

例えばRyanのGoVsGoアプリケーションを開発に利用するには、事前にいくつかのバックグラウンドプロセスを起動する必要があります。この中には、Beanstalkd、script/workerプロセス、Fayeサーバが含まれます。開発でこのアプリケーションを使用するたびに、これらすべての起動作業が発生します。これらのプロセスすべてを簡単に管理する方法があればとても便利でしょう。そこでForemanの登場です。

Foremanのインストールと使用

Foremanはgemの形で提供され、通常の方法でインストールします。

$ gem install foreman

Foremanは管理対象のプロセスを、 RailsアプリケーションのrootディレクトリにあるProcfileというファイルから読み込むので、このファイルを作成します。このファイルに、Foremanに管理させたいプロセスのリストを記述します。各プロセスの定義は、名称、コロン、起動したいプロセス名という形式なので、今回の対象の3つのプロセスを以下のように記述します。

/Procfile

beanstalk:  beanstalkd
worker:     ./script/worker
faye:       rackup faye.ru -s thin -E production

Procfileが完成したら、内容が正当かどうかをforeman checkコマンドを実行してチェックします。

$ foreman check
valid procfile detected (beanstalk, worker, faye)

名称とコマンドの間の区切りをスペースではなくタブにするとdeprecationエラーが表示されるので、Procfileを記述するときは留意しておいてください。ファイルが正当であることが確認できたら、foreman startコマンドでForemanを起動してみます。

$ foreman start
20:06:35 beanstalk.1  | started with pid 23140
20:06:35 worker.1     | started with pid 23141
20:06:35 faye.1       | started with pid 23143
20:06:36 faye.1       | >> Thin web server (v1.2.11 codename Bat-Shit Crazy)
20:06:36 faye.1       | >> Maximum connections set to 1024
20:06:36 faye.1       | >> Listening on 0.0.0.0:9292, CTRL+C to stop
20:06:38 worker.1     | [2011-08-29 20:06:38 +0100] Working 1 jobs: [ Game.move ]

するとProcfileで指定した各プロセスが実行され、その出力と一緒にターミナルにリスト表示されます。ターミナルウインドウでCTRL+Cをタイプするとプロセスが停止します。

Foremanには便利なマニュアルページがあり、機能や指定できるオプションについての説明があるので、ここでいくつか見てみます。プロセスを1つだけ起動したい場合はその名称を直接指定します。

$ foreman start faye
20:35:41 faye.1       | started with pid 23322
20:35:41 faye.1       | >> Thin web server (v1.2.11 codename Bat-Shit Crazy)
20:35:41 faye.1       | >> Maximum connections set to 1024
20:35:41 faye.1       | >> Listening on 0.0.0.0:9292, CTRL+C to stop

プロセスのコピーを複数起動させたい場合は、-cフラグを使用します。例えば4つのworkerプロセスを起動したい場合は、foreman start -c worker=4を実行します。

$ foreman start -c worker=4
20:39:41 beanstalk.1  | started with pid 23366
20:39:41 worker.1     | started with pid 23368
20:39:41 worker.2     | started with pid 23370
20:39:41 worker.3     | started with pid 23372
20:39:41 worker.4     | started with pid 23374
20:39:41 faye.1       | started with pid 23376
20:39:42 faye.1       | >> Thin web server (v1.2.11 codename Bat-Shit Crazy)
20:39:42 faye.1       | >> Maximum connections set to 1024
20:39:42 faye.1       | >> Listening on 0.0.0.0:9292, CTRL+C to stop
20:39:46 worker.3     | [2011-08-29 20:39:46 +0100] Working 1 jobs: [ Game.move ]
20:39:46 worker.1     | [2011-08-29 20:39:46 +0100] Working 1 jobs: [ Game.move ]
20:39:46 worker.2     | [2011-08-29 20:39:46 +0100] Working 1 jobs: [ Game.move ]
20:39:47 worker.4     | [2011-08-29 20:39:47 +0100] Working 1 jobs: [ Game.move ]

このコマンドで、すべてのプロセスが1回起動され、workerのみ4回起動されます。

プロセスをエクスポートする

Foremanにはexportコマンドがあり、本番のサーバで使用できるフォーマットでプロセスのリストをエクスポートするときに便利です。現在はinittabとupstartフォーマットがサポートされています。foreman export upstart .を実行すると、Foremanがカレントディレクトリにいくつかのupstart 用設定ファイルを書き出します。その一つを見てみると、そのファイルがbeanstalkdを起動するコマンドを実行しログを処理することがわかります。

/govsgo-beanstalk-1.conf

start on starting govsgo-beanstalk
stop on stopping govsgo-beanstalk
respawn

exec su - govsgo -c 'cd /Users/eifion/govsgo; export PORT=5000; beanstalkd >> /var/log/govsgo/beanstalk-1.log 2>&1'

Foremanに関する今回のエピソードは以上です。今回はいつものエピソードよりも短めでしたが、Foremanは特定の問題を解決するシンプルなツールで、その仕事をうまくこなしてくれます。Railsアプリケーションを、開発モードで稼働状態にするためにいくつものプロセスを起動させなくてはいけないというときには、Foremanの利用を検討する価値があるでしょう。

RailsでPry

Sun, 18 Sep 2011 21:07:22 +0000

PryはIRBの代替となるツールで、 IRBと同じようにRubyコードを実行するためのプロンプトを提供します。IRBと比較して、多くの付加機能を持っています。今回のエピソードでは、PryのしくみとRailsアプリケーションに統合する方法を紹介します。

Pryはgemで提供されるのでインストールは簡単です。pry-doc gemも一緒にインストールしますが、これについては後ほど説明します。

$ gem install pry pry-doc

RVM gemsetを利用しているので、すべてのgemsetから使用できる形でPryをインストールします。そのためには次の2つのコマンドを実行します。

$ rvm gemset use global
$ gem install pry pry-doc

Pryがインストールできたらpryコマンドで起動し、irbコマンドでおこなうのと同じようにRubyコードを実行します。

$ pry
pry(main)> 1 + 2
=> 3

Pryは単なる電卓以上の機能を提供しますが、機能の説明の前に、Railsアプリケーションから利用できるように設定する方法を見ていきます。使用するアプリケーションは、今までも何回か使用したおなじみのブログアプリケーションです。

アプリケーションのディレクトリからrails cを実行するとIRBが起動します。代わりにPryを使うためには、Railsのenvironmentファイルを指定してpryコマンドを実行します。これによって、標準のRailsコンソールと同じように、アプリケーションのモデルにアクセスできるようになります。

$ pry -r ./config/environment
pry(main)> Article.count
=> 3

これでPryの準備ができたので、その機能について見ていきます。helpとタイプすると、Pryがサポートしているすべてのコマンドの一覧が表示されます。もっともよく使うコマンドは、cdとlsの2つなのでこれらのコマンドを見てみましょう。cdコマンドは現在のスコープを変更します。cd ArticleとタイプするとArticleクラス内に移動し、selfを実行することでいつでも現在のスコープを確認できます。

pry(main)> cd Article
pry(#<Class:0x1022f60e0>):1> self
=> Article(id: integer, name: string, content: text, created_at: datetime, updated_at: datetime, published_at: datetime)

Articleクラス内にいるので、どのメソッドでも呼び出すことができます。firstとタイプすると最初の記事が返されますが、これはArticle.firstを指定するのと同じ意味になります。

pry(#<Class:0x1022f60e0>):1> first
=> #<Article id: 1, name: "What is Music", content: "Music is an art form in which the medium is sound o...", created_at: "2011-08-24 20:35:29", updated_at: "2011-08-24 20:37:22", published_at: "2011-05-13 23:00:00">

またあらゆるオブジェクトにcdすることができるので、Articleスコープ内でcd firstを実行するとその記事にスコープが移ります。そこでまたメソッドやプロパティを呼び出すことができるので、nameとタイプします。

pry(#<Class:0x1022f60e0>):1> cd first
pry(#<Article:0x102300c98>):2> name
=> "What is Music"

記事のnameにcdしてその文字列に対してメソッドを呼び出すことも可能です。

pry(#<Article:0x102300c98>):2> cd name
pry("What is Music"):3> upcase
=> "WHAT IS MUSIC"

Pryは移動の履歴を覚えていて、nestingを呼び出して参照することができます。

pry("What is Music"):3> nesting
Nesting status:
--
0. main (Pry top level)
1. #<Class:0x1022f60e0>
2. #<Article:0x102300c98>
3. "What is Music"

このコマンドは、それまでに訪れたオブジェクトのリストを返します。exitとタイプすると、直前にいたオブジェクトの中に戻されるので、今回の場合は最初の記事に戻ります。再度exitとタイプすると、Articleクラスに戻ります。

もっともよく使用されるもうひとつのコマンドはlsで、これは変数とメソッドをリスト表示します。デフォルトでは現在のスコープのすべての変数をリスト表示します。今Articleクラスの中にいたとすると、これを実行するとメソッドの一覧が表示されます。

pry(#<Class:0x1022f60e0>):1> ls
[:_, :_pry_, :inp, :out, :@_create_callbacks, :@_defined_class_methods, :@_save_callbacks, :@_update_callbacks, :@_validate_callbacks, :@arel_engine, :@arel_table, :@attribute_methods_generated, :@cached_attributes, :@column_names, :@columns, :@columns_hash, :@finder_needs_type_condition, :@generated_attribute_methods, :@inheritable_attributes, :@inheritance_column, :@parent_name, :@quoted_primary_key, :@quoted_table_name, :@relation]

Pryコマンドにはフラグをサポートするものがあり、その場合は-hオプションをつけてコマンドを実行するとコマンドのフラグの一覧が表示されます。ls -hを実行すると、サポートされているすべてのオプションが表示されます。その中の-mを指定するとクラスが持つメソッドのリストが表示され、-Mを指定するとインスタンスメソッドのリストが表示されます。現在のスコープの代わりにオブジェクトやクラスを渡すと、それが持つメソッドのリストが返されます。

もうひとつの便利なPryコマンドはshow-docです。例えばArrayクラスのin_groups_ofメソッドの動作を知りたいとします。その場合はshow-doc Array#in_groups_ofを実行して調べることができます。

pry(#<Class:0x1022f60e0>):1> show-doc Array#in_groups_of

From: /Users/eifion/.rvm/gems/ruby-1.9.2-p290/gems/activesupport-3.0.10/lib/active_support/core_ext/array/grouping.rb @ line 19:
Number of lines: 15

signature: in_groups_of(number, fill_with=?)

Splits or iterates over the array in groups of size number,
padding any remaining slots with fill_with unless it is false.

  %w(1 2 3 4 5 6 7).in_groups_of(3) {|group| p group}
  ["1", "2", "3"]
  ["4", "5", "6"]
  ["7", nil, nil]

  %w(1 2 3).in_groups_of(2, '&nbsp;') {|group| p group}
  ["1", "2"]
  ["3", "&nbsp;"]

  %w(1 2 3).in_groups_of(2, false) {|group| p group}
  ["1", "2"]
  ["3"]

オブジェクトに対して直接show-docを呼び出すこともできます。現在のスコープはArticleクラスなので、allを指定すると記事の配列が返されます。show-doc all.in_groups_ofを実行しても、上と同じドキュメンテーションが返されます。

もうひとつの便利なコマンドはshow-methodです。このコマンドはあらゆるメソッドのソースコードを表示します。これを使ってin_groups_ofのソースを見てみます。(ここで念のため触れておきますが、Pryにはコマンドの入力時に自動補完の機能がありタブキーを押すことで呼び出すことができます。)

pry(#<Class:0x104e63de0>):1> show-method all.in_groups_of

From: /Users/eifion/.rvm/gems/ruby-1.9.2-p290/gems/activesupport-3.0.10/lib/active_support/core_ext/array/grouping.rb @ line 19:
Number of lines: 19

def in_groups_of(number, fill_with = nil)
  if fill_with == false
    collection = self
  else
    # size % number gives how many extra we have;
    # subtracting from number gives how many to add;
    # modulo number ensures we don't add group of just fill.
    padding = (number - size % number) % number
    collection = dup.concat([fill_with] * padding)
  end

  if block_given?
    collection.each_slice(number) { |slice| yield(slice) }
  else
    groups = []
    collection.each_slice(number) { |group| groups << group }
    groups
  end
end

また、これと似たedit-methodというコマンドがあります。メソッドに対してこのコマンドを実行すると、関連するソースコードのファイルをテキストエディタで開き、対応する行を表示します。

コマンドの前にピリオドをつけることで、シェルコマンドを実行することもできます。Pryの中で.lsを実行すると、シェルコマンドのlsが実行され、カレントディレクトリのすべてのファイルがリスト表示されます。

Pryはデバッグ時にも役に立ちます。Articleモデルにはword_countというメソッドがあり、記事のcontentに含まれる単語の数を返します。しかしこのメソッドにはバグがあるため、記事のcontentが何であっても常に0を返します。メソッドを調べるために最初のArticleにcdして、edit-method word_countを実行します。メソッドの内容は以下のとおりです。

/app/models/article.rb

class Article < ActiveRecord::Base
  attr_accessible :name, :content, :published_at
  has_many :comments

  def word_count
    words = content.scan(/\\w+/)
    words.size
  end
end

binding.pryを呼び出すことで、コードの任意の場所にブレイクポイントを追加できます。上のコードのwords.sizeの行の直前にブレイクポイントを追加してファイルを保存してword_countメソッドを再度呼び出すと、binding.pryの場所で停止してPryプロンプトに戻ります。

> word_count

From: /Users/eifion/blog/app/models/article.rb @ line 7 in Article#word_count:

     2:   attr_accessible :name, :content, :published_at
     3:   has_many :comments
     4: 
     5:   def word_count
     6:     words = content.scan(/\\w+/)
 =>  7:     binding.pry
     8:     words.size
     9:   end
    10: end

メソッドのすべてのローカル変数にアクセスできるので、wordsを呼び出すとwordsという配列の内容を見ることができます。

pry(#<Article:0x1008c3f38>):3> words
=> []

配列は空になっているので、内容をスキャンする正規表現に何か問題があると思われます。調べてみると、バックスラッシュが1つであるべきところが2つになっています。これを修正するために再度edit-method word_countを実行し、正規表現を修正し、binding.pryの行を削除してファイルを保存します。

/app/models/article.rb

class Article < ActiveRecord::Base
  attr_accessible :name, :content, :published_at
  has_many :comments

  def word_count
    words = content.scan(/\w+/)
    words.size
  end
end

修正部分をテストするために再度word_countを呼び出すと、今度は期待通りに動作します。

pry(#<Article:0x1008c3f38>):3> word_count
=> 55

アプリケーションのコントローラ層やビュー層の何かをデバッグするときはコンソール経由でなく作業したい場合もあります。この場合もPryが役に立ちます。まずGemfileにPryへの参照を追加します。

/Gemfile

source 'http://rubygems.org'

gem 'rails', '3.0.10'
gem 'sqlite3'
gem 'nifty-generators'
gem 'pry', :group => :development

bundleを実行してgemをインストールし、rails sでサーバを起動します。これで、コントローラのどこにでもbinding.pryの呼び出しを追加することで、ブレイクポイントを設定できます。

/app/controllers/articles_controller.rb

def index
  @articles = Article.all
  binding.pry
end

プラウザでそのページを開くと、読み込みが途中で中断し、一方ターミナルではそのブレイクポイントで停止した状態のPryプロンプトが表示されます。モデルでの場合と同じように、ローカル変数やインスタンス変数を検査(inspect)できます。作業が終わったら、exit-allとタイプしてリクエストを完了させることができます。

From: /Users/eifion/blog/app/controllers/articles_controller.rb @ line 4 in ArticlesController#index:

     1: class ArticlesController < ApplicationController
     2:   def index
     3:     @articles = Article.all
 =>  4:     binding.pry
     5:   end
     6: 
     7:   def show
     8:     @article = Article.find(params[:id])
     9:   end

Pryに関する今回のエピソードは以上です。とても便利なgemで、ここで紹介しきれなかった多くの機能を持っています。wikiにはそれらの機能の説明や、Joshua Cheekによる非常に参考になるスクリーンキャストのリンクもあります。

Asset Pipelineを理解する

Thu, 08 Sep 2011 21:21:49 +0000

Asset PipelineはRails 3.1のもっとも大きな新機能ですが、同時にもっとも混乱しやすい機能でもあります。今回のエピソードでは、このAsset PipelineがどのようにRailsアプリケーションのアセットを管理するかを見ることによって、少しその神秘性を取り除いていきたいと思います。もしAsset Pipelineについてまったく知識がない場合は、Rails GuideのAsset Pipelineのページが多くの機能を説明しているので、まずそこから始めるのがいいでしょう。

Rails 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ディレクトリに置くのがいいでしょう。

もっとも基本的な部分では、Asset Pipelineはロードパスの一覧です。このリストを見るために、コンソールを実行してRails.application.config.assets.pathsを見ます。出力を読みやすくするためにYAML形式で表示させます。

> y Rails.application.config.assets.paths
--- 
- /Users/eifion/store/app/assets/images
- /Users/eifion/store/app/assets/javascripts
- /Users/eifion/store/app/assets/stylesheets
- /Users/eifion/store/lib/assets/greeting.txt
- /Users/eifion/store/vendor/assets/stylesheets
- /Users/eifion/.rvm/gems/ruby-1.9.2-p180@railspre/gems/jquery-rails-1.0.13/vendor/assets/javascripts

出力には、app/assets、/lib/assets、/vendor/assets 以下のすべてのディレクトリが表示されています。リストの最後に、アプリケーションに含んだjquery-rails gemに由来する興味深いディレクトリがあります。bundle openコマンドでその中身を見ることができます。

$ bundle open jquery-rails

このコマンドは、シェルの環境変数のBUNDLER_EDITORかEDITORで定義されたテキストエディタでgemを開きます。gemのファイルを見ると、vendor/asset/javascriptsディレクトリにAsset Pipelineを介して読み込むことができるjQueryのファイルがいくつか含まれているのがわかります。

予想される通り、ブラウザからこれらすべてのファイルにassetsパスの下でアクセス可能ですが、それはそれらのディレクトリがAsset Pipelineのロードパスに含まれるからです。

興味深いことに、つまりこれはRuby gemが単にRubyコードを管理するためだけのものではないということを意味しています。Javascriptやその他のアセットも、gemの中で同じように管理することができるのです。おそらく今後は、JavaScriptライブラリがRuby gemの形式で公開される事例が増え、それによって、それらもBundlerの依存関係管理の利点を享受できるようになるでしょう。

Sprocketsでアセットを管理する

ここでアプリケーションのapplication.jsファイルに戻って、中身を見ていくことにしましょう。

/app/assets/javascripts/application.js

// This is a manifest file that'll be compiled into including all the files listed below.
// Add new JavaScript/Coffee code in separate files in this directory and they'll automatically
// be included in the compiled file accessible from http://example.com/assets/application.js
// It's not advisable to add code directly here, but if you do, it'll appear at the bottom of the
// the compiled file.
//
//= require jquery
//= require jquery_ujs
//= require_tree .

ファイルにはコメントしかありませんが、その一部は重要な意味を持っています。この種のファイルはmanifestとよばれ、内部的にはSprocketsに管理されます。このファイルへのリクエストを受け取ると、Sprocketsはmanifestを見て、そこに記述されているすべてのファイルを結合して、このファイルのコードの前にその内容をインクルードします。

ここでもロードパスが機能します。このファイルにはrequire jquery(拡張子の.jsは任意のため、省略できます)が含まれています。Sprocketsはロードパスの中からこのファイルを探し、今回の場合はjquery-railsエンジンのvendor/asset/javascriptsディレクトリからロードします。

このロードパスに存在するすべてのJavaScriptファイルを追加できます。そのため、ファイルにrequire jquery-uiを追加すると、gemのjquery-ui.jsファイルがインクルードされます。これはCoffeeScriptファイルにも当てはまります。require homeを含めると /app/assets/javascripts/home.js.coffeeファイルが解析されてインクルードされます。

しかしhomeファイルを含める必要はありません。というのも、ファイルの一番下にrequire_tree .があり、ここでのドット(.)はカレントディレクトリを表しているからです。これは、そのディレクトリやそのサブディレクトリにあるすべてのJavaScriptやCoffeeScriptのファイルが含まれるということです。

階層の中の特定のファイルを除外したければ、それも可能です。例えば、サイトにadminページがあり、これらのページを見るときだけ特定のJavaScriptファイルが含まれるようにしたいとします。デフォルトではこれらのファイルはサイトのすべてのページに含まれてしまいます。

含まれたファイルを見たい場合は、URLにdebug_assets=1パラメータを追加します。この指定によってJavaScriptファイルは結合されず、ページのソースを見ると、Sprocketsがインクルードするファイルがadminディレクトリの中のものも含めてすべて表示されます。

この問題への対処方法はいくつかあります。require_treeの代わりにrequire_directoryを使用すれば、カレントディレクトリにあるファイルのみを読み込み、サブディレクトリのファイルは読み込みません。インクルードされるファイルをより詳細に制御したければ、ディレクトリ全体をインクルードするのではなく、個別のファイルをrequireすることも可能です。もう一つの方法として、すべてのページに含めたいJavaScriptファイルをpublicサブディレクトリに移動します。その上でrequire_tree ./publicを使用して、それらのファイルだけをインクルードできます。

Sprockets manifestにどのようなコマンドを使用できるかを知りたい方もいるでしょう。まだいいドキュメントがないのですが、directive_processor.rbファイルのソースコードのコメントには、動作の仕組みの説明とともに、使用できるコマンドが記載されています。

プリプロセス

Asset Pipelineはプリプロセスにも対応しています。この仕組みを説明するために、新たに作成した/app/assets/anythingディレクトリにgreeting.txtというファイルを作成します。そのままでは、このファイルは単なる静的なテキストファイルですが、ファイル名にもう一つ拡張子を追加します。ここではこのファイルにERBコードを追加すると、それが処理されます。

/app/assets/anything/greeting.txt.erb

hello world <%= 1 + 1 %>

このファイルをブラウザで見てみるとERBコードが処理されているのがわかります。URLにはプロセッサの拡張子は含んでいません。

基本的にこれがSASSとCoffeeScriptが動作するしくみです。もしファイルに.scss拡張子がついていたら、これがプリプロセッサ拡張子として扱われて、ファイルはSASS プロセッサに渡されます。拡張子を連結して、例えば.scss.erbという拡張子をつけてファイルを作ることもできます。このファイルはまずERBプロセッサに渡され、その後SASSプロセッサに渡されます。

プリプロセッサは自由に設定を変えることができます。独自のプロセッサを追加したり、既存のものと置き換えたりすることができます。これはすべてTilt gemによって処理されます。サイトには動作のしくみや利用できる拡張機能についての情報もあります。

本番モード(Production Mode)での相違点

Asset Pipelineの機能についての簡単な概要紹介は以上です。Asset Pipelineは本番モードでの動作にいくつか相違点があるので、エピソードの残りを使って説明します。まずサーバを本番モードで起動します。

$ rails s -e production

アプリケーションのトップページにアクセスしてソースを表示させると、アセットが違う形で配信されていることがわかるでしょう。

<link href="/assets/application-412fe22651f4486c51e54176003a9f57.css" media="screen" rel="stylesheet" type="text/css" />
  <script src="/assets/application-3e3a5167191afa70c7b72440eee7dd40.js" type="text/javascript"></script>

ファイル名にハッシュ値が含まれていますが、これはキャッシュするためです。Rails 3.0で用いられていたクエリ文字列を追加する以前の方法と比べると、実際にファイル名を変えるこの方法の方が優れています。またファイル自身を見てみると、通信コストを少なくするためにJavaScriptが縮小化(minify)されているのがわかります。

これらのアセットは自動的にキャッシュされ、Rack Cacheミドルウェアによって配信されるので速度はかなり速いです。もし代わりにWebサーバ自身にアセットの配信とホストをさせたい場合は、次のコマンドを使って事前にプリコンパイルします。

$ rake assets:precompile

このコマンドで、アセットは/publicディレクトリにプリコンパイルされ、Webサーバから簡単にアクセスできます。

Asset Pipelineに関する今回のエピソードは以上です。忘れずにRails Guideでより詳しい情報をチェックしてください。

Sunspotで全文検索

Sun, 04 Sep 2011 20:57:35 +0000

SunspotはRubyアプリケーションに全文検索機能を追加するためのソリューションです。バックグラウンドでSolrを利用し、多くの優れた機能を提供します。今回のエピソードでは、過去のエピソードで使用したブログアプリケーションを例にして、Sunspotを使ってRailsアプリケーションに全文検索機能を追加します。

このアプリケーションは複数の記事を表示するページを持っており、それらを横断して検索を行う機能を実装していきます。これをSQLを使って行うのは困難になりやすく、多くの場合最善のアプローチとは言えません。Sunspotのような専用の全文検索ツールの方が、この機能を実装するにはずっと適した方法です。

Sunspotのインストール

Sunspotはgem形式で提供されるので、通常のようにGemfileに追記してbundleを実行することでインストールされます。

/Gemfile

source 'http://rubygems.org'

gem 'rails', '3.0.9'
gem 'sqlite3'
gem 'nifty-generators'
gem 'sunspot_rails'

gemとその依存関係がインストールされたら、Sunspotの設定ファイルを生成するために次のコマンドを実行します。

$ rails g sunspot_rails:install

このコマンドによって/config/sunspot.ymlにYMLファイルが作成されます。このファイルのデフォルト設定に修正を加える必要はありません。

Sunspotはgemの内部にSolrを組み込んでいるので、別途インストールする必要はありません。つまりインストールした素の状態で機能するので、開発時にはとても簡単に作業できます。起動させるために次のコマンドを実行します。

$ rake sunspot:solr:start

OS X Lionを利用していてJavaランタイムをまだインストールしていない場合、このコマンドを実行したときにランタイムをインストールするようプロンプトが出るでしょう。同じく非推奨の警告(deprecation warning)が表示されるかも知れませんが、これは無視しても問題ありません。このコマンドにより、詳細設定のための追加の設定ファイルが作成されます。それらについてはここでは触れませんが、ドキュメンテーションにこれらのファイルの修正方法の詳細情報があります。

Sunspotの利用

Sunspotをインストールできたので、Articleモデルから利用します。全文検索機能を追加するためにはsearchableメソッドを使用します。

/app/models/article.rb

class Article < ActiveRecord::Base
  attr_accessible :name, :content, :published_at
  has_many :comments
  
  searchable do
    text :name, :content
  end
end

このメソッドはブロックをとり、その中で検索したい属性を定義してSunspotにどのデータに索引を設定すればいいかを知らせます。textメソッドを使用して、全文検索を実行する対象とする属性を定義します。今回の記事の検索のためには、nameとcontentのフィールドを指定します。

Sunspotは自動的に新しいレコードに対して索引を作成しますが、既存のレコードに対してはそれを行いません。Sunspotに対して既存のレコードに索引を作成し直させる場合は、次のコマンドを実行します。

$ rake sunspot:reindex

これですべての記事がSolrのデータベースに入って検索できる状態になったので、indexページの一番上に検索フィールドを追加します。

/app/views/articles/index.html.erb

<% title "Articles" %>

<%= form_tag articles_path, :method => :get do %>
  <p>
    <%= text_field_tag :search, params[:search] %>
    <%= submit_tag "Search", :name => nil %>
<% end %>
<!-- rest of view omitted -->

このフォームはGETを用いてindexアクションに送信されるので、入力された検索パラメータがすべて検索文字列に追加されます。では次にコントローラを修正して、searchパラメータによって記事を取得するようにします。Sunspotで検索を行うには、モデルでsearchを呼び出してブロックを渡します。ブロック内では複雑な検索を処理するためにいろいろなメソッドを呼び出すことができます。ここではfulltextメソッドを使用して、それに対してフォームからの検索パラメータを渡します。最後にこの結果のすべてを@searchに割り当てます。これの結果を呼び出して、一致した記事のリストを取得します。

/app/controllers/articles_controller.rb

def index
  @search = Article.search do
    fulltext params[:search]
  end
  @articles = @search.results
end

ここまでの部分をテストするために記事のページを再読み込みしてキーワードで検索を行います。すると一致する記事のリストが返されます。

検索は、それが記事のnameかcontentかに関わらず、検索語を含んだ記事のリストを返します。

Articleモデルのsearchableブロックでは、これ以外にも多くのことが可能です。例えばboostを使って、タイトルが一致する記事の方が本文が一致する記事よりも重要性が高いというように、結果に重み付けをつけることができます。

/app/models/article.rb

class Article < ActiveRecord::Base
  attr_accessible :name, :content, :published_at
  has_many :comments
  
  searchable do
    text :name, :boost => 5
    text :content
  end
end

これは、結果をrelevance(適合度)で並べたい場合に重要です。今回の場合はタイトルに検索語を含む記事が本文に検索語を含む記事よりも検索結果リストの上位に現れます。

searchableブロックで指定する属性はデータベースの実際の列名である必要はなく、モデル内で定義するメソッドを使用することもできます。記事が発行された月と年を含む文字列を返すpublish_monthという列を作成し、データベースの列と同じようにそのメソッドに対して検索を行います。

/app/models/article.rb

class Article < ActiveRecord::Base
  attr_accessible :name, :content, :published_at
  has_many :comments
  
  searchable do
    text :name, :boost => 5
    text :content, :publish_month
  end
  
  def publish_month
    published_at.strftime("%B %Y")
  end
  
end

この新しい列で検索できるようにrake sunspot:reindexを再度実行してレコードに索引を設定し直す必要がありますが、そうすることで月名で記事を検索することができるようになります。

メソッドを作成する代わりに、ブロックを渡してブロックの戻り値に対して検索を行うことができます。記事には多くのコメントがついているので、ブロックを用いてコメントの内容を検索する機能を追加します。

/app/models/article.rb

class Article < ActiveRecord::Base
  attr_accessible :name, :content, :published_at
  has_many :comments
  
  searchable do
    text :name, :boost => 5
    text :content, :publish_month
    text :comments do
      comments.map(&:content)
    end
  end
  
  def publish_month
    published_at.strftime("%B %Y")
  end
  
end

ブロック内のコンテキストはArticleのインスタンスなので、その中で記事に対するコメントを取得して各コメントの本文にマッピングすることができます。これは配列を返しますが、Sunspotはコメントのすべてに索引を作成し検索可能にします。

属性に対する検索

単純な全文検索以上の検索機能を、ある特定の属性に対して追加したい場合はどうすればいいでしょうか。このためには、検索対象にしたい属性のタイプ(文字列か整数か浮動小数かタイムスタンプか)を渡します。検索フィールドにpublished_at属性を追加するので、timeメソッドを利用します。

/app/models/article.rb

class Article < ActiveRecord::Base
  attr_accessible :name, :content, :published_at
  has_many :comments
  
  searchable do
    text :name, :boost => 5
    text :content, :publish_month
    text :comments do
      comments.map(&:content)
    end
    time :published_at
  end
  
  def publish_month
    published_at.strftime("%B %Y")
  end
  
end

ArticlesControllerでこれを利用して、検索対象をpublished_atの日付が現在の時刻よりも前のものに制限します。そのためにwithメソッドを利用します。

/app/controllers/articles_controller.rb

def index
  @search = Article.search do
    fulltext params[:search]
    with(:published_at).less_than(Time.zone.now)
  end
  @articles = @search.results
end

これを設定することで、発行されていない記事は検索されなくなります。渡すことができる属性に関する優れたドキュメンテーションがSunspotのwikiページにあります。

ファセット検索

ファセット検索を使用すると、ある属性、例えば記事が発行された月で検索結果をフィルタリングできます。例えば、発行された記事が存在する月のリンクの一覧リストを追加したいとしましょう。リンクをクリックすると、記事のリストにフィルタがかけられて、その月に発行された記事だけを表示します。

これを行うためにまず、publish_monthメソッドのsearchableブロックにstring属性を追加します。

/app/models/article.rb

class Article < ActiveRecord::Base
  attr_accessible :name, :content, :published_at
  has_many :comments
  
  searchable do
    text :name, :boost => 5
    text :content, :publish_month
    text :comments do
      comments.map(&:content)
    end
    time :published_at
    string :publish_month
  end
  
  def publish_month
    published_at.strftime("%B %Y")
  end
  
end

ArticlesControllerのsearchブロックでfacetを呼び出すことでこれをファセットに変えることができます。

/app/controllers/articles_controller.rb

def index
  @search = Article.search do
    fulltext params[:search]
    with(:published_at).less_than(Time.zone.now)
    facet(:publish_month)
  end
  @articles = @search.results
end

以下のコードを検索ボックスと記事の一覧の間に追加することで、indexページにこれらのファセットを表示できます。

/app/views/articles/index.html.erb

<div id="facets">
  <h3>Published</h3>
  <ul>
    <% for row in @search.facet(:publish_month).rows %>
      <li>
        <% if params[:month].blank? %>
          <%= link_to row.value, :month => row.value %> (<%= row.count %>)
        <% else %>
          <strong><%= row.value %></strong> (<%= link_to "remove", :month => nil %>)
        <% end %>
      </li>
    <% end %>
  </ul>
</div>

このコードで、publish_monthの各ファセット項目をループして表示しています。@searchオブジェクトで.facetを呼び出して、ファセットの並び順として指定する属性を渡します。今回の例で言うと:publish_month、そしてそれに対して.rowsを呼び出すと、その属性でのファセットオプションを返します。

row.valueを呼び出すと、その属性の値、例えば「January 2011」を返します。またrow.countを呼び出せば、その値に一致する記事数が返されます。もし検索文字列にmonthパラメータがあったら、その値を、パラメータを削除するための「remove(削除)」リンクと共に表示します。これによって、与えられたファセットを選択して、それをmonthパラメータを介して渡すという便利な機能を利用できます。

ここでページを読み込み直すと、レコードの索引を設定し直したので、パネルにファセットのリストが月名とその月に発行された記事数という形で表示されます。月を選択すると、検索文字列にmonthパラメータとして表示されますが、記事はフィルタリングされません。これを修正するために、コントローラのsearchにもう一つwithパラメータを追加して、monthパラメータが存在したら月でフィルタリングするようにします。

/app/controllers/articles_controller.rb

def index
  @search = Article.search do
    fulltext params[:search]
    with(:published_at).less_than(Time.zone.now)
    facet(:publish_month)
    with(:publish_month, params[:month]) ↵ 
      if params[:month].present?
  end
  @articles = @search.results
end

月を選択すると、その月に発行された記事で正しくフィルタリングされたリストが表示されます。

「remove」リンクをクリックすると全リストが返されます。検索結果もこれに合わせて動作します。検索語を入力すると、一致する記事がある月がリスト表示されます。

ファセットは検索と合わせて利用できる優れた機能です。

Sunspotに関する今回のエピソードは以上です。SunspotはRailsアプリケーションに全文検索機能を追加する優れた方法で、ここで触れることができなかった多くの追加機能を持っています。さらに情報を得るために、忘れずにwikiを参照してください。

マウント可能なエンジン

Sun, 28 Aug 2011 21:38:29 +0000

先週末Rails 3.1 HackFestが開催され、参加者の努力によってRails 3.1のリリース候補第5版が公開されました。このリリースには、マウント可能なエンジン(mountable engine)に関する重要な修正が含まれています。マウント可能なエンジンによって、任意のRailsアプリケーションを別のアプリケーションにマウントできるようになることについて、今回のエピソードで紹介します。

エピソード104で紹介したException Notificationプラグインを覚えている方もいるでしょう。このプラグインをアプリケーションに追加することで、アプリケーションが発生させた例外をデータベースに蓄積することができました。ユーザインタフェースも提供され、例外の情報を表示することができました。今回のエピソードでは、このプラグインをマウント可能なエンジンとして作り直します。

はじめに

エンジンを書き始める前に、Rails 3.1 RC5以降を使用していることを確認してください。次のコマンドを実行することで、最新版をインストールできます。

$ gem install rails --pre

Railsの正しいバージョンがインストールされたら、マウント可能なエンジンの作成に取りかかりましょう。すでにあるRailsアプリケーションの中から作業する必要はありません。エンジンの作成は、新規のRailsアプリケーションの作成と同じで、rails newコマンドを使用します。唯一の違いは、rails plugin newを実行するという点です。今回作成するアプリケーションは例外を扱うため、uhohという名前にします。マウント可能なエンジンとして作成するために--mountableオプションを指定します。

$ rails plugin new uhoh --mountable

エンジンのディレクトリ構造は、通常のRailsアプリケーションの構造にとても似ていて、別のアプリケーションの中にマウントされるように設計されているという点を除けば基本的には同じであるといえます。しかし実際にはいくつかの違いがあります。アプリケーション全体で、名前空間を設定されたディレクトリがいくつかあります。例えば、application_controllerファイルが/app/controllers/uhohの下にあり、同じく assets、helpers、viewsの各ディレクトリの下にそれぞれファイルが置かれます。これによって、組み込まれる先のアプリケーションからエンジンのコードをきれいに切り離すことができます。assetsディレクトリを持つということは、エンジンがアプリケーションにマウントされるときにpublicディレクトリにいちいちアセットをコピーしなくてもいいということです。asset pipelineによってこれらはすべて自動処理されます。

アセットもディレクトリに名前空間を設定されるので、それらにリンクする場合はそのディレクトリを介する必要があります。これはlayoutsディレクトリにも当てはまりますが、RC5にはバグがあるようで、application.html.erbファイルが2つ存在します。ここでは、uhohディレクトリの外にある方を削除しましょう。もう一つの方を見てみると、その中のアセットへの参照はすべてuhohディレクトリが追加で含まれています。画像やその他のアセットにリンクする場合は、その名前空間を含む必要があります。

/app/views/layouts/uhoh/application.html.erb

<!DOCTYPE html>
<html>
<head>
  <title>Uhoh</title>
  <%= stylesheet_link_tag    "uhoh/application" %>
  <%= javascript_include_tag "uhoh/application" %>
  <%= csrf_meta_tags %>
</head>
<body>

<%= yield %>

</body>
</html>

次にエンジンのキーとなるファイルのひとつである、/lib/uhohディレクトリ内のengine.rbを見てみましょう。

/lib/uhoh/engine.rb

module Uhoh
  class Engine < Rails::Engine
    isolate_namespace Uhoh
  end
end

これはRails::Engineから継承されたクラスで、設定をカスタマイズする場合の中心的な場所になります。このクラスには最初からisolate_namespaceの呼び出しがあり、つまりこれはエンジンが独立した単位として扱われ、マウント先のアプリケーションを気にしなくてもいいということを意味します。

エンジンについてのこの簡単な概要で紹介する最後のパーツは、/testディレクトリです。/test/dummyの下にはRailsアプリケーションがあり、それを見ると、アプリケーションにマウントされたエンジンがどういう仕組みで動くかを理解することができます。アプリケーションのconfigディレクトリにはroutes.rbファイルが含まれています。ここにはmountの呼び出しが含まれ、パスに割り当てられているエンジンのメインクラスが渡されます。

/test/dummy/config/routes.rb

Rails.application.routes.draw do
  mount Uhoh::Engine => "/uhoh"
end

この、適当なパスを決めてマウントする作業は、エンジンをアプリケーションにインストールした場合には誰かが行う必要があります。これはRackアプリケーションなので、/uhohに対してリクエストが来た場合はEngineクラスに渡されます。この行を、エンジンのREADMEファイルのインストール手順の中に含むようにすれば、アプリケーションのユーザがルートファイルの中でどのようにマウントすればいいかがわかって便利でしょう。

このダミーのアプリケーションは/testディレクトリ内にありますが、手作業でテストを行うときにも役に立つでしょう。エンジンのディレクトリからrails sを実行すると、ダミーのアプリケーションが起動します。http://localhost:3000/uhoh/にアクセスすると、その場所にマウントされているエンジンの画面に導かれます。しかしそのページにアクセスすると、対応するコントローラを記述していないため、エラーが表示されます。

そこで、エンジン内にfailuresコントローラを作成します。通常のRailsアプリケーションの場合と同じように、Railsのジェネレータを使用できます。エンジン内にいても、コントローラを名前空間で指定する必要はなく、すべて自動処理されます。

$ rails g controller failures index

このコマンドによって、通常のコントローラの場合と同じファイルが作成されます。ただ違うのは、すべてが正しいディレクトリに名前空間を指定されます。次にエンジンのルートを修正して、コントローラのindexアクションにrootのルート(route)を設定します。この修正は、エンジンの/config/routes.rbファイルに対して行われます。

/config/routes.rb

Uhoh::Engine.routes.draw do
  root :to => "failures#index"
end

http://localhost:3000/uhoh/にアクセスすると、アクションのビューが表示されます。

このページでは、発生した例外のリストを表示します。この情報を保存するためのモデルが必要なので、メッセージフィールドを持った簡単なFailureモデルを作成します。

$ rails g model failure message:text

モデルを作成しましたが、どうやってマイグレーションを実行すればいいのでしょうか。エンジン内では通常通りrake db:migrateを実行でき、すべては期待通りに動作します。しかし、誰かがエンジンをアプリケーション内にマウントしようとするとうまく行きません。これはrakeコマンドが、マウントされたエンジン内のmigrationを認識できないからです。エンジンのユーザに対して、代わりにrake uhoh:install:migrationsを実行するように指示する必要があります。このコマンドによって、エンジンのmigrationをアプリケーションにコピーした上でrake db:migrateを通常のように実行できるようになります。この情報をエンジンのインストール手順書に入れておくのがいいでしょう。

Railsコンソールも、エンジン内で期待通りに機能します。これを使ってFailureの例を作成してみます。

Uhoh::Failure.create!(:message => "hello world!")

クラスを参照する場合はつねに名前空間を含まなくてはいけない点に留意してください。Failureのレコードができたので、それをFailuresControllerのindexアクションで表示します。

/app/controllers/uhoh/failures_controller.rb

module Uhoh
  class FailuresController < ApplicationController
    def index
      @failures = Failure.all
    end
  end
end

コンソールにいる場合と違い、ここではすでにUhohモジュールの中にいるので、名前空間を指定する必要はありません。ビューで、すべてのfailureをループするコードを書き、リスト表示させます。

/app/views/uhoh/failures/index.html.erb

<h1>Failures</h1>
<ul>
  <% for failure in @failures %>
  <li><%= failure.message %></li>
  <% end %>
</ul>

ページを再度読み込むと、追加したFailureが表示されます。

例外をとらえる

これでfailureを記録するメソッドができたので、エンジンが組み込まれたアプリケーションが例外を発生させたときにfailureを生成するメソッドを作成します。これをテストするためにダミーアプリケーションで例外をシミュレートする方法が必要です。このためにエンジンのdummyアプリケーションのディレクトリに移動し、simulateというコントローラとその中にfailureアクションを作成します。

$ rails g controller simulate failure

アクション内で例外を発生させます。

/test/dummy/app/controllers/simulate_controller.rb

class SimulateController < ApplicationController
  def failure
    raise "Simulating an exception"
  end
end

ブラウザでそのアクションにアクセスすると、期待通りに例外が表示されます。

ここでエンジンを修正して、例外の発生を待機するようにして、発生したら新規のFailure作成させるようにします。この解決策は効率的ではないかもしれませんが、シンプルで今回の場合には十分役に立ちます。ではまずエンジン内に初期化ファイル(initializer)を作成します。エンジンのconfigディレクトリにはinitializersディレクトリはありませんが、自分で作成してそこに初期化ファイルを置くと認識されます。このディレクトリにexception_handler.rbというファイルを作成します。

/app/config/exception_handler.rb

ActiveSupport::Notifications.subscribe ↵
  "process_action.action_controller" do ↵
  |name, start, finish, id, payload|
  if payload[:exception]
    name, message = *payload[:exception]
    Uhoh::Failure.create!(:message => message)
  end
end

このファイルで、notificationを購読設定します(notificationについてはエピソード249[動画を見る, 読む]で詳しく解説しています)。対象は、アクションが処理されたときに通知してくれるnotificationです。アクションが処理されたら、payloadに例外が含まれるかどうかをチェックします。もし含まれていたら例外が発生したということで、そのメッセージを新規のFailureに保存します。

これをテストする前にサーバを再起動します。そして再度http://localhost:3000/simulate/failureにアクセスして例外を発生させます。例外が表示されたら、http://localhost:3000/uhohにアクセスしてそれを見ることができます。

エンジンでURLを扱う

エンジン内で使用するURLヘルパーは、そのエンジン向けのURLを生成します。例えばfailuresのindexページからroot URLへのリンクを追加すると、このリンクはエンジンのroot URLを指定していて、組み込まれた先のアプリケーションのrootではありません。

/app/views/uhoh/failures/index.html.erb

<p><%= link_to "Failures", root_url %></p>

このリンクはhttp://localhost:3000/uhohを指しますが、これはエンジンのroot URLです。これは、リンクがあるのと同じページです。というのもroot URLはルート設定でFailuresControllerのindexアクションを指すように定義されているからです。アプリケーション自体へのリンクを作成するには、次のようにmain_appのURLヘルパーを呼び出します。

/app/views/uhoh/failures/index.html.erb

<p><%= link_to "Failures", root_url %></p>
<p><%= link_to "Simulate Failure", main_app.simulate_failure_path %></p>

これによってアプリケーションのSimulate Failureページへのリンクがhttp://localhost:3000/simulate/failureに作成されます。

これの反対で、アプリケーションからエンジンにリンクを設定したい場合はどうすればいいでしょうか? まず最初にすることは、アプリケーションのルートファイルを修正して、エンジンをマウントしてそれに:asオプションで名前を与えます。

/test/dummy/config/routes.rb

Rails.application.routes.draw do

  get "simulate/failure"

  mount Uhoh::Engine => "/uhoh", :as => "uhoh_engine"
end

これで、uhoh_engineのメソッドとして呼び出すことで、エンジンのURLヘルパーにアクセスできます。これを実際に見てみるために、failureアクションを一時的に修正して、例外を発生させる代わりにエンジンのroot URLにリダイレクトします。

/test/dummy/app/controllers/simulate_controller.rb

class SimulateController < ApplicationController
  def failure
    redirect_to uhoh_engine.root_url
  end
end

http://localhost:3000/simulate/failureにアクセスすると、engineヘルパーを使ってエンジンのURLにリダイレクトするように設定しているため、http://localhost:3000/uhohにリダイレクトされます。これも、エンジンのREADMEファイルで言及しておくべき機能でしょう。

これでエンジンの機能はほぼ出来上がりましたが、failureを表示するリストが質素なので、アセットを使って少し味付けします。まず画像を追加します。あらかじめ適当な画像を見つけて/app/assets/images/uhohディレクトリに置いてあります。それをページに追加するために、他の画像と同じようにimage_tagを使うことができます。

/app/views/uhoh/failures/index.html.erb

<%= image_tag "uhoh/alert.png" %>
<h1>Failures</h1>
<ul>
  <% for failure in @failures %>
  <li><%= failure.message %></li>
  <% end %>
</ul>

<p><%= link_to "Failures", root_url %></p>
<p><%= link_to "Simulate Failure", ↵
  main_app.simulate_failure_path %></p>

CSSも少し設定します。SASSとCoffeeScriptは、デフォルトではエンジンでは利用できませんが、依存関係として追加することができます。failures.cssファイルにCSSを追加すると、自動的にincludeされます。

/app/assets/stylesheets/uhoh/failures.css

html, body {
  background-color: #DDD;
  font-family: Verdana;
}

body {
  padding: 20px 200px;
}

img {
  display: block;
  margin: 0 auto;
}

a {
  color: #000;
}

ul {
  list-style: none;
  margin: 0;
  padding: 0;
}

li {
  background-color: #FFF;
  margin-bottom: 10px;
  padding: 5px 10px;
}

JavaScriptも同じです。failures.jsファイルに記述されたコードは自動的にincludeされます。

/app/assets/javascripts/uhoh/failures.js

$(function() {
  $("li").click(function() {
    $(this).slideUp();
  });
});

ここでページを再度読み込むと、見た目はずっとよくなってクリックして例外を隠すことができるようになり、JavaScriptが有効になったことがわかります。

今回のエピソードは以上です。マウント可能なエンジンはRails 3.1の優れた新機能なので、一度見てみることをお勧めします。

ASCIIcasts - Full Episode Feed

Draper

Draperのインストール

プロファイルページを整理する

モデルを修正する

allowsメソッドを用いてモデルへのアクセスを制限する

Spork

Sporkのインストール

SporkとGuardの連携

Sporkの設定

Active Admin

Active Adminをインストールする

Active Adminを利用する

スコープ

ダッシュボードをカスタマイズする

スタイルシートを修正する

グローバル設定

Sorceryで認証

はじめに

コントローラとビューを追加する

権限を与える

Rails 3.1へのアップグレード

サイトを準備する

アップグレード

Asset Pipelineを使用するためのアプリケーションの修正

アセットを移動する

Foreman

Foremanのインストールと使用

プロセスをエクスポートする

RailsでPry

Asset Pipelineを理解する

Sprocketsでアセットを管理する

プリプロセス

本番モード(Production Mode)での相違点

Sunspotで全文検索

Sunspotのインストール

Sunspotの利用

属性に対する検索

ファセット検索

マウント可能なエンジン

はじめに

例外をとらえる

エンジンでURLを扱う

`allows`メソッドを用いてモデルへのアクセスを制限する