Unicornのホットデプロイについて会社の方に書きました
Posted by irohiroki
去年の9月からKRAYで働いているのですが、そちらにエントリ書きました。
RailsのデプロイとUnicornのトラブルシューティング | KRAY Inc
UnicornのしくみはUnixらしくてきれいです。よかったら読んでみてください。
Posted by irohiroki
去年の9月からKRAYで働いているのですが、そちらにエントリ書きました。
RailsのデプロイとUnicornのトラブルシューティング | KRAY Inc
UnicornのしくみはUnixらしくてきれいです。よかったら読んでみてください。
Posted by irohiroki
お祭り騒ぎしてるだけのつもりだったのに、Twitterとか見ると“スタッフのみなさん、ありがとうございました”とか書いてあるんですよ。これは丸儲けなんじゃないかって
というのは私が最終日のチェックアウト(区切りをつけるための一言)で言ったセリフだ。RubyKaigi 2011に当日スタッフとして参加し、3日間、朝から夜まで働き、体力は尽きたが、そんなことはどうでもいいくらい楽しい思いをさせてもらった。
RubyKaigi 2011は7月16日から18日までの3日間、練馬文化センターで開催され、2つのホールで合計47のセッションと、無数のライトニングトークが行われた。参加者は約1,000人で、その中には海外から来た人も多い。しかし私の記憶には、そんな数では表し切れないとてつもなく強いインパクトを残した。
RubyKaigiは完全に非日常的な体験だ(あんなものが日常的にあってたまるか)。人の体験には、一緒に過ごす人が大きな影響を与えるように思う。そしてRubyKaigi中は普段とは全く違う人たちと過ごした。実行委員と当日スタッフのメンバーを合わせて約50人。主にネットを介してしか知らず、半分以上の人が初対面。そんな人たちと、初めての場所で、1,000人のお客さんを迎えるために働く。実行委員長が言っていたが、RubyKaigiは毎回違ったものになるので、毎回“初めてのRubyKaigi"であり、何が起こるか分からないのだそうだ。つまり、参加している全員にとってRubyKaigi 2011は新しい体験だった。
豪華なセッションの数々も印象的だった。基調講演をしたMatz、たこやき仮面、角谷さん、それから笹田さんやyharaさんをはじめとしたコミッター陣、wycatsやdrbrainといった海外のgeekたち、井上さんや朝里さんなどの海外で活躍する日本人Rubyist… 全員は挙げないが、魅力的なセッションが朝から晩まで続く目の眩むようなタイムテーブルだった。スタッフだったので1/4くらいしか生で見てないが、記憶に焼き付くような話がいくつもあった。我々スタッフはそれをホストし、1,000人の人たちそれぞれに、何かしら持って帰ってもらえたのではないかと思う。
いくら言葉を尽くしても足りないが、僕にとってRubyKaigiは素晴らしい体験だった。大変と言えば大変だが、もう一度やりたいと思う。でも知っての通り今回で“日本RubyKaigi”はおしまいだ。やりたければ、自分なりの形を見つけて自分でやらなければならない。それが“最後のRubyKaigi”の意義の一つであり、角谷さんの「答え合わせしませんか」は、それを促すメッセージだ。
RubyKaigiとは何なんだろうかと思う。なぜあんなに多くの人に支持されるのか。同じ会場で同じ人を集めて同じセッションを開けばRubyKaigiができるのか。ここで分析したり持論を展開したりはしないが、RubyKaigiをRubyKaigiたらしめるエッセンスがある。それを探求しつつ、自分のまわりに“答え”を作っていきたい。
RubyKaigiは楽しく、活気があり、出会いがあって、私を啓蒙してくれる。自分のまわりのものがもっとRubyKaigiっぽかったら素敵だと思う。例えば自分の会社やプロジェクトがもっとRubyKaigiっぽかったら。会社やプロジェクトを大好きになると思う。自分だけでなく、他の人も大好きになってくれるものならもっといい。そのためにはどうすればいいか?何をどうすれば、RubyKaigiっぽくなるのか?それを探求しながら自分のまわりに広めていきたい。
Posted by irohiroki
アプリケーションで発生する例外を捕捉し、適切な処理をするのは一般的なことだと思います。コントローラの中で発生する例外はbegin rescueで囲ったり、rescue_fromを使えば捕捉できますが、Rack middlewareで発生する例外はどうでしょうか?
例えばMySQLを使っていてデータベースサーバに接続できない場合、ActiveRecord::ConnectionAdapters::ConnectionManagementというmiddlewareからMysql2::Errorが発生します。
ActiveRecord::ConnectionAdapters::ConnectionManagementはrake middlewareすると10番目に出てきます。
$ rake middleware use ActionDispatch::Static use Rack::Lock use ActiveSupport::Cache::Strategy::LocalCache use Rack::Runtime use Rails::Rack::Logger use ActionDispatch::ShowExceptions use ActionDispatch::RemoteIp use Rack::Sendfile use ActionDispatch::Callbacks use ActiveRecord::ConnectionAdapters::ConnectionManagement use ActiveRecord::QueryCache use ActionDispatch::Cookies use ActionDispatch::Session::CookieStore use ActionDispatch::Flash use ActionDispatch::ParamsParser use Rack::MethodOverride use ActionDispatch::Head use ActionDispatch::BestStandardsSupport run MyApp::Application.routes
ウェブサーバはこの上にあり、自分のアプリケーションは一番下です。例外はrescueしなければ上へ上がって行きます。つまり、どうやってもアプリケーションではrescueできません。
ではどうハンドリングすればいいでしょうか?
スタックを見ると上から6番目にActionDispatch::ShowExceptionsというのがあります。ソースを見ると、例外のクラス名をステータスコードにマップしていることがわかります。
例えば、Mysql2::Errorを507 (Insufficient Storage)にマップするだけなら、config/application.rbに下の行を追加し、
ActionDispatch::ShowExceptions.rescue_responses['Mysql2::Error'] = :insufficient_storage
表示したいページをpublic/507.htmlとして置いておけば済みます。
しかしMysql2::Errorの原因が全てInsufficient Storageではありませんし、MySQLが無関係なInsufficient Storageも有りうるので、適切な措置とは言えません。
Rack middlewareで発生した例外はActionDispatch::Rescueというmiddlewareで捕捉できます。ActionDispatch::ShowExceptionsと違い、ActionDispatch::Rescueは例外クラスに対してハンドリングするRackアプリケーションを指定できます。
例えば、application.rbに下のように追加すれば、Mysql2::Errorに対して「Database failure.」と表示できます。
config.middleware.insert_before ActiveRecord::ConnectionAdapters::ConnectionManagement, ActionDispatch::Rescue do rescue_from Mysql2::Error, lambda {|env| [500, {'Content-Type' => 'text/plain'}, 'Database failure.'] } end
ステータスコードは500 (Internal Server Error)で十分でしょう。ポイントは、レスポンスボディとして任意の内容を返せることです。任意の内容を返せるということは、ユーザに適切なメッセージを見せたり、JavaScriptのフロントエンドにJSONなどで適切なステータスを返したりできるということです。
なお、上のrescue_fromはActionDispatch::Rescue#rescue_fromで、コントローラのマクロ風rescue_fromとは別物です。
しかし、前出の
lambda {|env| [500, {'Content-Type' => 'text/plain'}, 'Database failure.'] }
はapplication.rbに書くにはちょっと生々しい印象です。もっとコードらしい場所へ移動するにはどうしたらいいでしょうか。
ActionDispatch::Rescue#rescue_fromの第2引数はRackアプリケーションですから、Rackアプリケーションとして振舞うクラスを指定してやれば済みます。例えばActionController::Metalを継承すればそういうクラスを簡単に作れます。
class DatabaseFailure < ActionController::Metal def self.call(env) action(:respond).call(env) end def respond self.status = 500 self.content_type = 'text/plain' self.response_body = 'Database failure.' end end
application.rbには下のようになります。
config.middleware.insert_before ActiveRecord::ConnectionAdapters::ConnectionManagement, ActionDispatch::Rescue do rescue_from Mysql2::Error, DatabaseFailure end
Posted by irohiroki
大江戸Ruby会議01に参加してきましたので、そこで感じたこと、考えたことなどを、コミュニティへの感謝を込めて書き記したいと思います。
会場は深川江戸資料館のホールで、広すぎず狭すぎず、ちょうどよい大きさだと思いました。もちろんもっと大きな会場ならさらに多くの人が参加できますが、雰囲気が変わってしまいそうなので、開催規模としてちょうど良かったのではないかと。近くには隅田川の支流が流れ、河畔の桜並木が満開でした。
ホールは地下だったのですが、ユナイテッド・デザインワークスによる無線LANが設営されているという周到さでした。
最初の基調講演は松田明さんによる「100.times { Asakusa.rb.meetup! }」で、Asakusa.rbの趣旨や活動、歴史などが紹介されました。
印象に残ったのは「Rubyを良くしたい」というAsakusa.rb結成、活動の動機でした。この言葉は一見簡単なようで実は意味がわからなくて、というのはRubyは言語であってツールですが、別にCRubyにパッチを送るとかいう意味ではなさそうだからです。確かにAsakusa.rbにはコミッタが参加していますが、松田さん自身はそういう活動はしてません(よね?)
ではどういう意味かというと、もちろん松田さんにお聞きすれば答が返ってくるでしょうが、自分なりの解釈でAsakusa.rbに参加するのも楽しいように思えるんですよね。
例えばRubyを使うことは、Rubyの応用事例を増やして信頼度を上げるでしょうから、Rubyを良くすることになりそうです。Gemを作ったりすればもっと直接的に貢献できるでしょう。
さらに「Ruby」に「Rubyコミュニティ」を含むと解釈すると、範囲は大きく広がります。「Rubyコミュニティを良くする」というのはもう本当にいろいろな解釈がありそうですが、書くと野暮になりそうだし、探求を続けていきたい領域なのでここには書きません。
結局、「Rubyを良くしたい」の解釈は様々に可能ですが、いずれにしても自分以外の誰かに利することなので、「あなたを幸せにしたい(Rubyを通して)」ぐらいに考えておいてもいいのではないでしょうか。いずれにしても、僕はこの基調講演を聞いて、Asakusa.rbに参加してRubyを良くしたい(Rubyを良くすることを探求したい)という思いを強くし、参加する決心をしたのでした。
続いて笹田さんの基調講演と6人のAsakusa.rbメンバーによるNinja Talk (Lightning Talk)がありました。
他の言語の場合は知らないんですが、RubyのLightning Talkはデータを見せるものよりストーリーを語るものが多い印象です。自分が通信技術の会社で「◯◯プロトコルに☓☓機能を加えて受信特性を3 dB改善」みたいな発表ばかり見ていたせいかもしれませんが、RubyのLightning Talkはカジュアルで、感情に訴えてくるところが見てて楽しいですね(そうでない、データを見せるものももちろんありますが)。Regional Ruby会議は学会ではなく、交流会の意味合いが強いので、そういう発表の方が理にかなっているし、モチベーションの源になったりします。
個々の発表の感想は省きますが、今日も6人のNinjaに楽しませていただきました。ありがとうございました。
懇親会は桜鍋の店で、珍しい、美味しい料理をいただきました。よくある飲み会の大皿料理でなく、コース料理だったのも嬉しかった。また、座敷だったので人が移動しやすいのも良かったんではないでしょうか(実際には僕はチキンなので移動せず、移動してくる人を待ち構えていた)。ただ僕は体が大きいので、席が狭いのだけが少し辛かったんですが。
周りには左手側から@tyabeさん、@konk303さん、@nahiさん、@junyaさん、@jugyoさんという席。最初にnahiさんのhttpclientの話から、Railsのthreadsafe!関連の話へ。この辺は実はよくわからないので、優先順位の高いものが終わったら調べ直そうと思います。
そのうち(よく聞いてなかったんですが)Ruby 1.8.7でGCが解放したメモリをOSに返せないのかという話になったようで、@nahiさんが@shyouheiさんのところへ。"そういう研究もあるが、閉じた組織がやってるので状況はわからない"という回答をもらってきました。こういう風に、リアルなユーザの要望がその場でメンテナに届いて回答が返ってくるのが面白い。さすがAsakusa.rbです。
途中、角谷さんに社内でやった『アジャイルな見積もりと計画づくり』読書会の話をできたのが嬉しかったんですが、あまりに個人的なので省略。
その他にもリアルにRubyで商用サービスを動かしてる人たちから、JavaScriptのテストの方針や、負荷とDBの勘所の話を聞くことができました。自分はいつも職場でたった一人のRubyistとして仕事をしていて、またコンシュマー向けのアプリをリリースしたこともなく、レスポンスのほとんどない世界で漠然とした孤独を感じていました。でも懇親会で話を聞くうち、自分が作ったものを公開すれば必ず見る人がいる、使う人がいる、もしかしたら喜ぶ人もいると思えるようになってきました。これは仕事以外で開発をする上でとても大きなモチベーションになります。懇親会で話を聞かせてくれた方、大江戸Ruby会議と懇親会を開催してくれた方には心から感謝します。ありがとうございました!
Posted by irohiroki
MacにRVMでRuby 1.9.2をインストールしたとき、irbなどのReadlineのプロンプトに日本語を入力すると「???」に化けて、そのままEnterするとinvalid multibyte charなどのエラーになる問題の解決方法。
Bug #550によると、MacではGNU readlineの代わりにEditline Libraryが使われているそうで、GNU readlineを使えば解決するらしい。
RVMには簡単にGNU readlineを導入する機能があって、Rubyをインストールした後に修正する手順は下の通り(追記:一度Rubyを消さないとうまく行かないので修正。リンク先の丸写しです)。
rvm package install readline
rvm remove 1.9.2
rvm install 1.9.2 --with-readline-dir=$rvm_path/usr
cd $HOME/.rvm/src/ruby-1.9.2-p180/ext/readline
ruby extconf.rb -- --with-readline-dir="$HOME/.rvm/usr"
make install
なお、2行目のruby-1.9.2-p180の部分はインストールしたRubyのバージョンに合わせて変えてください。
追記
GNU readlineにしたら、Readline.refresh_lineがNotImplementedErrorになりました。refresh_lineを使う場合には向きませんね。
Posted by irohiroki
RSpec勉強会@万葉で発表してきたので、資料を公開します。
資料の22ページで、subjectのためにdescribeを切ることについて「議論ありそう」と書いたんですが、やっぱり@ukstudioさんからツッコまれました。
曰く、describeは振る舞いの主体を表すもので、処理の結果を指すものではないでしょうとのこと(と理解した)。確かにそうですね。
しかし同じcontextでsubjectを変えると書きやすくなる場合もやっぱりあって、この問題はまだまだ楽しめそうです。
TweetPosted by irohiroki
Autotestはテスト駆動開発において欠かせないツールです。しかし、特にRuby 1.9ではRspecの起動の遅く、イライラしている人も多いでしょう。
Rspecの起動を早くするツールにSporkがありますが、以下のような問題があります:
このエントリではこれらの問題を解決していきます。目指すのは次のような環境です:
まずはベースの環境から作りましょう。なお、ここで使うのはMac上のRails 3.0.3とRuby 1.9.2です。
gem install railsrails new my_app
最初にRSpecとautotest、sporkを入れるために、Gemfileに以下の行を加えます。
gem 'rspec-rails' gem 'autotest-rails' gem 'spork'
Gemfileを編集したらbundleしておきます。
bundle
RSpecをインストールします:
rails g rspec:install
Sporkに必要な準備をします:
spork --bootstrap
ここで、表示される指示に従ってspec/spec_helper.rbを編集します。下のようにしておけばよいでしょう。
require 'rubygems'
require 'spork'
Spork.prefork do
ENV["RAILS_ENV"] ||= 'test'
require File.expand_path("../../config/environment", __FILE__)
require 'rspec/rails'
Dir[Rails.root.join("spec/support/**/*.rb")].each {|f| require f}
RSpec.configure do |config|
config.mock_with :rspec
config.fixture_path = "#{::Rails.root}/spec/fixtures"
config.use_transactional_fixtures = true
end
end
Spork.each_run do
end
またSporkを有効にするため、rspec:installによって生成された.rspecファイルに--drbを加えておきます。
--color --drb
これで素のAutotestとSporkの環境はできました。適当なコードをscaffoldして試してみてもいいでしょう。
rails g scaffold user name:string rake db:migrate RAILS_ENV=test
sporkを起動し、別のターミナルでautotestも実行します。
spork
autotest
さらに別のターミナルでテストコードを失敗するように修正するとすぐさまautotestが赤くなります。しかし、製品コードを壊した場合、テストは走りますが緑のままです。
製品コードのリロードは、実は次の2つの問題に分けられます。
1はRuby on Rails Tutorial: Learn Rails by Example | Ruby on Rails 3 Tutorial book and screencasts | Static Pagesに回避方法が載っています。まず下のようにspec/spec_helper.rbのRSpec.configureのブロックに1行加えます。
diff --git a/spec/spec_helper.rb b/spec/spec_helper.rb
index 9fd4d4a..0d793e4 100644
--- a/spec/spec_helper.rb
+++ b/spec/spec_helper.rb
@@ -12,6 +12,8 @@ Spork.prefork do
config.mock_with :rspec
config.fixture_path = "#{::Rails.root}/spec/fixtures"
config.use_transactional_fixtures = true
+
+ ActiveSupport::Dependencies.clear
end
end
そしてconfig/application.rbも下のように修正します:
diff --git a/config/application.rb b/config/application.rb
index 590b85c..02b3ca4 100644
--- a/config/application.rb
+++ b/config/application.rb
@@ -38,5 +38,13 @@ module MyApp
# Configure sensitive parameters which will be filtered from the log file.
config.filter_parameters += [:password]
+
+ ### Part of a Spork hack. See http://bit.ly/arY19y
+ if Rails.env.test?
+ initializer :after => :initialize_dependency_mechanism do
+ # Work around initializer in railties/lib/rails/application/bootstrap.rb
+ ActiveSupport::Dependencies.mechanism = :load
+ end
+ end
end
end
これでapp以下を修正した場合でもリロードしてテストしてくれます。
app以外、例えばconfig/application.rbやconfig/initializersの中は、rspecの起動を速くするためにプリロードしているので、sporkの再起動で解決します。これを自動的にやってくれるのがguard-sporkです。まずguard-sporkとFSEvent APIのRubyバインディングであるrb-fseventをインストールします。ただしここで使うguard-sporkは、後述するruby-debugのために私が改造したものです。
gem 'guard-spork', :git => 'https://github.com/irohiroki/guard-spork.git' gem 'rb-fsevent'
加えたらbundleしてguard-sporkの初期化をします。
bundle bundle exec guard init spork
そしてguardを起動。
bundle exec guard start
sporkはguardが起動してくれます。config/application.rbなどを更新するとguardがsporkを再起動します。
ところでguardが監視してくれるファイルの中にはconfig/routes.rbがないのですが、これは下の修正をすることでテストに反映できるようになります。
diff --git a/spec/spec_helper.rb b/spec/spec_helper.rb index 6f6a223..cffc9f5 100644 --- a/spec/spec_helper.rb +++ b/spec/spec_helper.rb @@ -19,4 +19,5 @@ Spork.prefork do end Spork.each_run do + MyApp::Application.reload_routes! end
この時点では、rdebugを起動してコードの中にdebuggerと書いても止まってくれません。なぜなら、実際のテストはDRbサーバであるsporkで動いているからです(たぶん)。
この問題に対して、sporkの作者のTim Harper氏がrdebugのセッションをフォワードするプロキシを書いてくれました。これを使うと、debuggerが現れたときにsporkのターミナルにrdebugのプロンプトが出ます(autotestのターミナルではない)。ただし、一箇所RuntimeErrorが出るところがあるので、ここでは私の修正版を使います。まずcurlなどでプロキシモジュールをspecディレクトリに入れます。
curl https://gist.github.com/raw/814375/ccbe163559376e109e30574b1086a32fb626e374/spork-ruby-debug.rb > spec/spork-ruby-debug.rb
そしてそれをspec/spec_helper.rbからrequireします。
diff --git a/spec/spec_helper.rb b/spec/spec_helper.rb
index 0d793e4..6f6a223 100644
--- a/spec/spec_helper.rb
+++ b/spec/spec_helper.rb
@@ -1,5 +1,6 @@
require 'rubygems'
require 'spork'
+require File.expand_path("../spork-ruby-debug", __FILE__)
Spork.prefork do
ENV["RAILS_ENV"] ||= 'test'
もちろんruby-debugもインストールしておきましょう。Gemfileに下の行を加えてbundleします。
gem 'ruby-debug19'
bundle
これで完成です。bundle execを付けるのを忘れずにguardを起動してください。
bundle exec guard start
実はオリジナルのguard-sporkだとsporkのプロセスがbackgroundへ回されてしまってrdebugのプロンプトが取れないのですが、そこは私の修正版で回避してあります。
以上の手順で作った環境をgithubに置きましたのでよろしければ参考にしてください。
Posted by irohiroki
(このエントリは、第58回 Rails勉強会@東京で発表した内容をまとめたものです。)
OmniAuthは、TwitterやGoogleなど様々な認証サービスプロバイダを統一したインターフェースで使えるようにしてくれるgemです。非常に便利なのでさっそく使おうとしたのですが、テストの書き方がわからなくて躓いたので、調べてわかったことやサンプルコードを公開します。
なお、OmniAuthは単体でも使えるのですが、伝統的なユーザ名とパスワードによる認証もサポートすることを想定して、Deviseと併用する構成となっています。
ポイントは以下の通りです:
発表で使った資料を下に貼っておきます。最低限のことしか書かれていませんが、参考になれば。
Posted by irohiroki
RubyKaigi2010のA Metaprogramming Spell BookのスピーカーであるPaolo Perrotta氏が著し、@kdmsnr氏が訳した『 メタプログラミングRuby』を読みました。
大変面白かったのでご紹介します。
目次は以下の通り。第1部だけ少し細かく書いてあります。
本のタイトルは『メタプログラミングRuby』ですが、メタプログラミングに限らずRubyでスムーズにプログラミングするために必要な知識がどっさり載っています。例えば、複数のクラスに同じクラスメソッドを定義するにはどういう方法があるか?クラスインスタンス変数とは何か?クラス変数との違いは?など、曖昧に覚えていることや使うたびに調べているようなことが、整理されて論理的に理解できるようになりました。
Rubyのコードを論理的に読み解くには、オブジェクトモデルとスコープの理解が欠かせません。Rubyのオブジェクトモデルには"メタクラス"あるいは"特異クラス"と呼ばれる隠れたクラスが潜んでおり、重要な役割を果たしています。
例えばあるクラスAのインスタンスaを作り、その特異クラスにメソッドを定義すると特異メソッドになります。
class A end a = A.new class << a def foo p 'foo' end end a.foo # => "foo"
しかしaのクラスであるAにはfooメソッドがありませんし、Aのスーパークラスにも特異クラスは現れません。
a.class # => A A.instance_methods.grep(/foo/) # => [] A.ancestors # => [A, Object, Kernel, BasicObject]
では特異クラスはどこにあるのでしょうか?
次にスコープの例です。トップレベルでクラス変数@@aに値を入れたあと、適当なクラスAでも同様に@@aを使ったら、トップレベルの@@aは影響を受けるでしょうか?
@@a = 1 class A @@a = 2 end p @@a
答えは"受ける"です。上のコードの結果は2になります。では、インスタンス変数@aや、ローカル変数aだったらどうでしょうか?またそれはなぜでしょうか?
以上のような質問に答えるために、それぞれの場合の答えを丸暗記する必要はありません。単純なスコープのルールを覚えておけば済みます。スコープを理解すると、class_evalやinstance_evalの使いどころや、クロージャの意味まで明確になります。『メタプログラミングRuby』にはそれらを理解するための例や解説が豊富に載っています。物語形式になっていて、リラックスして読み進めることができると思います。
『メタプログラミングRuby』を読んだ一番の成果は、上述のオブジェクトモデルとスコープの理解が深まったことでした。これだけでプログラミングが楽になったと実感したほどです。そのほかの良かった点は、第5章の連続クイズが段階的な理解度テストになっていて手頃な腕試しができることや、Proc.new, proc, lambdaの違いなど、オフトピックも面白かったことです。以上、購入を考えている方の参考になれば幸いです。
Posted by irohiroki
Rails 3ではroutesのDSLが完全に刷新されました。特に、あの見難かったハッシュの塊が解かれて、:memberや:getなど予約語の役割をしていたシンボルはディレクティブになりました。例えばRails 2の以下の記述は
map.resources :users, :member => {:foo => :get}, :collection => {:bar => :post}
Rails 3では下のように書けます:
resources :users do member do get :foo end collection do post :bar end end
このように、Rails 2では"予約語"がキーになったり(:memberや:collection)値になったり(:getや:post)していたものが、Rails 3ではディレクティブになり、ユーザの与える値がシンボルとして残りました。
また、ActionController::Routing::RouteSet::Mapperインスタンスであるmapが必要なくなっています。
このエントリでは、8月21日のRails勉強会@東京第54回で@a_matsudaさんに教えていただいたことをベースに、Rails 3のroutesについてまとめます。
URLのパターンに対し、コントローラとアクションを指定する方法は、Rails 2では
map.connect 'friends/:id', :controller => 'users', :action => 'show'
でしたが、Rails 3では
match 'friends/:id', :to => 'users#show'
になります。mapが不要になったことと、コントローラとアクションを1つの値で指定できることで簡潔になっていますね。
逆に、オプションのパラメータは()で囲む必要があります。例えば、デフォルトルートは下のように定義されます。
match '/:controller(/:action(/:id))'
Rails 2では下の.friendのようにMapperインスタンスへ送るメッセージがルート名になったのですが
map.friend 'friends/:id', :controller => 'users', :action => 'show'
Rails 3では基本のmatchディレクティブに:asを付けます。
match 'friends/:id', :to => 'users#show', :as => 'friend'
root、つまり「/」に対するrouteは、Rails 2ではmap.rootというnamed routeが「/」に予約されていましたが、Rails 3ではrootというディレクティブを使います。例えば下のようになります:
root :to => 'home#show'
基本のmatchディレクティブでは、実は:toを省略できます。つまり、下の2つは同じことです。
match 'friends/:id', :to => 'users#show' match 'friends/:id' => 'users#show'
さらに、パスのノード名がコントローラ名とアクションに一致するなら、それも省略可能です。よって下の2つは同じです。
match 'users/summary' => 'users#summary' match 'users/summary'
特定のコントローラに対するルートは、controllerディレクティブでまとめることができます:
controller :users do match 'summary', :to => :short match 'pretty', :to => :pp end
RESTfulなルートを定義するのに便利だったmap.resourcesですが、Rails 3でもresourcesとして使用可能です。例を挙げます:
resources :users
さらに、複数のリソースを渡せるようになりました:
resources :users, :products, :shops
resourcesはブロックを受け取り、その中で冒頭で紹介したmemberやgetといったディレクティブを使用できます。
resourcesをネストした場合は、Rail 2と同様、has_manyの関係を定義できます。
resources :users do resources :items end # user.rb class User < ActiveRecord::Base has_many :items end
:onlyや:exceptといったオプションを与えて生成するルートを絞ることや、:constraintsオプションで受け付けるパラメータのパターンを制限するのもRails 2と同じです。
namespaceディレクティブを使うことで、パス(URL)とコントローラを任意の名前空間に入れることができます。例えば下のように書くことで、パスは/admin/users、コントローラはapp/controllers/admin/users_controller.rbに置かれたAdmin::UsersControllerになります。
namespace "admin" do resources :users end
もしパスだけに名前空間をつけてコントローラはapp/controllersに入れたければ、scopeを使います:
scope "/admin" do resources :users end
反対に、コントローラにだけ名前空間を付けたければ、scope :module => を使います:
scope :module => "admin" do resources :users end
Rails 3ではルーティングの機構自体がRackミドルウェアなので、別のRackアプリケーションを呼び出すようなルートも書けるようになりました。例えば:toの先にSinatra::Baseの子クラスを書くことができます。また、redirectというメソッドを使ってリダイレクトを指定することもできます:
match "/users/:id", :to => redirect("/accounts/%{id}")
講師をしてくださった松田さんがRails 3の特集を書かれました。