[Rails3] コントローラの namespace を取得する

実行環境：
ruby 1.9.3
Rails 3.1.3

コントローラの名前は controller.controller_name で取得できますが namespace までは取得できないので、UsersController の場合も Admin::UsersController の場合も同じ users が返ってくる。

namespace まで一緒にとりたい場合は controller.controller_path を使います。 admin/users が返ってきます。

  def namespace
    controller.controller_path.split('/')[-2]    # admin
  end

もしくは controller.class.name でも Admin::UsersController のように namespace 付きで得られます。

  def namespace
    controller.class.name.split('::')[-2]        # Admin
  end

どちらも namespace がついてない場合は nil が返ります。

[Rails3] 汎用的なScaffoldを作ってみる

実行環境：
ruby 1.9.3
Rails 3.1.3
ActiveRecord 3.1.3

複数の Scaffold を作っていて、それらの動作や見栄えを変更しようとすると View テンプレートをいちいちテーブルのカラムを１つ１つちくちく直したりというのが結構面倒です。

１つアプリの中に多数のモデル（DBのテーブル）を作っている場合、管理画面は変更が面倒という理由でデフォルトの Scaffold のままだったりします。ちょっと思いたって少しいじろうかなと思っても、修正するファイルが多すぎてすぐにへこたれてしまいます。なにせ1つの Scaffold に対して Controller が1ファイル、Viewが5ファイルあるので、20の Scaffold があると120ファイルくらいあるわけですから。 (>_<)

どの Scaffold でも Controller 名と Model 名、カラム名が違うだけでファイルの構成もやってることもたいてい同じなので、Controller 名やら Model 名やらカラム名やらを動的に取得して共通化してやれば、たくさんのファイルを管理しなくてもよいんじゃないか？

そんなことを考えて Controller と View のファイルから個別のモデルに関する記述を取り除いて、どの Scaffold でも継承するだけで使えるようなものを作ってみたいと思います。

基本方針

Controller について

ApplicationController を継承した CommonScaffoldController（名前はなんでもいいですが）を作り、index や edit などのアクションメソッドを汎用性を持たせた形で書きこみます。各 Scaffold （以下では例として Users で説明します。）のコントローラは CommonScaffoldController を継承させるだけで中身を空っぽにします。アクションは全て CommonScaffoldController で定義するという作戦です。

/app/controller/common_scaffold_controller.rb
class CommonScaffoldController < ApplicationController
  def index
    # ここできっちりと定義しておく
  end

  # アクションは全てこのファイルで定義します
 
end

/app/controller/users_controller.rb
class UsersController < CommonScaffoldController  # 個別のコントローラは継承するだけ
end

View について

デフォルトの View ファイルの構成をそのまま使います。ajax を使えばもうちょっときれいにまとめられると思いますが、今回の趣旨とは関係ないので今回はそのままです。app/views/ の直下に common_scaffold フォルダを作り、その中に index.html.erb やら _form.html.erb やらを入れます。

/app/views/common_scaffold/
[common_scaffold]
   ├ index.html.erb
   ├ show.html.erb
   ├ new.html.erb
   ├ edit.html.erb
   └ _form.html.erb

上記の CommonScafffoldController の中でこのディレクトリの中の View ファイル達を render に使います。つまりどの Scaffold でも同じ View ファイルが使われるようにします。

具体的なコード

CommonScaffoldController

各 Scaffold のコントローラがこの CommonScaffoldController を継承します。controller_name で個別のコントローラ名が取得でkるのでそれを元に対応するモデル名、モデルクラスを取得します。

/app/controller/common_scaffold_controller.rb
class CommonScaffoldController < ApplicationController

  before_filter get_model_class  # @model_class, @model_instance_name を取得

  def index
    @objects = @model_class.all
 end

  def show
    @object = @model_class.find(params[:id])
    # @object = @model_class.where("? = ?", @model_class.primary_key, params[:id]).first
  end

  def new
    @object = @model_class.new
  end

  def edit
    @object = @model_class.find(params[:id])
  end

  def create
    @object = @model_class.new(params[@model_instance_name])

    respond_to do |format|
      if @object.save
        format.html { redirect_to @object, notice: "%s was successfully created."%(@model_instance_name) }
      else
        format.html { render 'new' }
      end
    end
  end

  def update
    @object = @model_class.find(params[:id])

    respond_to do |format|
      if @object.save
        format.html { redirect_to @object, notice: "%s was successfully updated."%(@model_instance_name) }
      else
        format.html { render 'edit' }
      end
    end
  end

  def destroy
    @object = @model_class.find(params[:id])
    @object.destroy

    respond_to do |format|
      format.html { redirect_to :action => :index }
    end
  end

private
  def get_model_class
    @model_class = controller_name.classify.constantize        # モデルクラス（Userなど）を取得
    @model_instance_name = @model_class.model_name.underscore  # モデルのインスタンス名を取得
  end
end

common_scaffold/*.html.erb

Viewファイルの中身からも個別の Scaffold に関わる名前を駆逐します。

index.html.erb

app/views/common_scaffold/index.html.erb
<h1>Listing <%= @model_instance_name.plurarize %></h1>

<table>
  <tr>
    <%- @model_class.columns.each do |column| -%>
      <th><%= @model_class.human_attribute_name(column.name) %></th>
    <%- end -%>
  </tr>

  <%- @objects.each do |object| -%>
    <tr>
      <%- @model_class.columns.each do |column| -%>
        <td><%= @model_class.send(column.name) %></td>
      <%- end -%>
      <td><%= link_to 'Show', object %></td>
      <td><%= link_to 'Edit', :controller => controller.controller_name, :action => :edit, :id => object.id %></td>
      <td><%= link_to 'Destroy', object, confirm: 'Are you sure?', method: :delete %></td>
      <td></td>
    </tr>
  <%- end -%>
</table>

<%= link_to "New %s"%(@model_instance_name), :controller => controller.controller_name, :action => :new %>

show.html.erb

app/views/common_scaffold/show.html.erb
<p id="notice"><%= notice %></p>

<%- @model_class.columns.each do |column| -%>
<p>
  <b><%= column.name.humanize %></b>
  <%= @object.name %>
</p>
<%- end -%>

<%= link_to 'Edit', :controller => controller.controller_name, :action => :edit, :id => @object.id %></td>
<%= link_to 'Back', :controller => controller.controller_name, :action => :index %></td>

new.html.erb

app/views/common_scaffold/new.html.erb
<h1>New <%= @model_instance_name %></h1>

<%= render 'form' %>

<%= link_to 'Back', :controller => controller.controller_name, :action => :index %>

edit.html.erb

app/views/common_scaffold/edit.html.erb
<h1>Edit <%= @model_instance_name %></h1>

<%= render 'form' %>

<%= link_to 'Show', @object %>
<%= link_to 'Back', :controller => controller.controller_name, :action => :index %>

_form.html.erb

app/views/common_scaffold/_form.html.erb
<%= form_for(@object) do |f| %>
  <% if @object.errors.any? %>
  <div id="error_explanation">
    <h2><%= pluralize(@object.errors.count, "error") %> prohibited this <%= @model_instance_name %> from being saved:</h2>

    <ul>
    <% @object.errors.full_messages.each do |msg| %>
      <li><%= msg %></li>
    <% end %>
    </ul>
  </div>
  <% end %>

  <%- @model_class.columns.each do |column| -%>
  <div class="field">
    <%= f.label column.name %><br />
    <%= f.text_field column.name %>
  </div>
  <%- end -%>
  <div class="action">
    <%= f.submit %>
  </div>
<% end %>

個別の Scaffold の設定

Controller は CommonScaffoldController を継承するだけ、Model は標準の Scaffold で作られるもののまま、View ファイルは削除します。

Controller
Controller は CommonScaffoldController を継承するだけで、メソッドの定義は一切不要。

/app/controller/users_controller.rb
class UsersController < CommonScaffoldController
end

Views
すべて app/views/common_scaffold/ の中のファイルを見るので、個別の Scaffold 用の Views ディレクトリ（app/views/users）は削除します。View ファイルを探す際に app/views/users/*, app/views/common_scaffold/* の順に探されるので消しておかないと app/views/common_scaffold/* のファイルを使ってくれません。

Model
デフォルトの Model ファイルのまま、特に変更する必要はありません。

/app/models/user.rb
class User < ActiveRecord::Base
end

まとめ

一部妄想で書いている部分があるので動かないところがあるかもしれませんが、大まかな考え方はこんな感じです。Viewファイル１セットを変えれば全て変わるので管理画面の変更も簡単です(^_^)
※今回は rails generate scaffold したまんまの View を使いましたが、そのうち Ajax 版も作ってみたいと思います。

[Rails3] 現在のURLを取得（request オブジェクト）

実行環境：
ruby 1.9.3
Rails 3.1.3

Rails アプリケーションの中で現在処理中（アクセス中）の URL を取得するには request オブジェクトを参照します。

プロトコル名（http://）を含めたフル URL を取得する。

request.url                  # http://example.com/users/search?q=hoge&p=1

URL のホスト名以降の文字列を取得する。

request.request_uri          # /users/search?q=hoge&p=1

URL のホスト名以降のパス文字列を取得する。クエリ文字列（?以降）は含まない。

request.path_info            # /users/search

requestオブジェクトについて

URL 以外にも request オブジェクトを使うと HTTP_REQUEST に入っている様々な情報を取得できます。

request.auth_type            # AUTH_TYPE
request.content_length       # CONTENT_LENGTH
request.content_type         # CONTENT_TYPE
request.gateway_interface    # GATEWAY_INTERFACE
request.path_info            # PATH_INFO
request.path_translated      # PATH_TRANSLATED
request.query_string         # QUERY_STRING
request.remote_addr          # REMOTE_ADDR
request.remote_host          # REMOTE_HOST
request.remote_ident         # REMOTE_IDENT
request.remote_user          # REMOTE_USER
request.request_method       # REQUEST_METHOD
request.script_name          # SCRIPT_NAME
request.server_name          # SERVER_NAME
request.server_port          # SERVER_PORT
request.server_protocol      # SERVER_PROTOCOL
request.server_software      # SERVER_SOFTWARE
request.accept               # HTTP_ACCEPT
request.accept_charset       # HTTP_ACCEPT_CHARSET
request.accept_encoding      # HTTP_ACCEPT_ENCODING
request.accept_language      # HTTP_ACCEPT_LANGUAGE
request.cache_control        # HTTP_CACHE_CONTROL
request.from                 # HTTP_FROM
request.host                 # HTTP_HOST
request.negotiate            # HTTP_NEGOTIATE
request.pragma               # HTTP_PRAGMA
request.referer              # HTTP_REFERER
request.user_agent           # HTTP_USER_AGENT
request.raw_cookie           # HTTP_COOKIE
request.raw_cookie2          # HTTP_COOKIE2
request.request_uri          # REQUEST_URI

[Rails3] 国際化 I18n のまとめ（その３：辞書ファイルの使い方）

実行環境：
ruby 1.9.3
Rails 3.1.3
I18n

Railsアプリで表示を担当するのはビューなので国際化するのは当然ビューですね。ページに表示される文字すべてが対象となります。

ページに表示される文字をざっと分類してみましょう。

1. DBに格納されている文字列
2. HTMLに直接書く単語や文章
3. モデルの名前や属性の名前などモデルに関連する文字列
4. Railsのエラーメッセージ

1. DBに格納されている文字列

DBに格納されているデータを国際化（多言語化）する場合は、各ロケールごとのデータを用意する必要があります（日本語だけなら不要です）。
シンプルな方法としては、テーブルに複数のロケール用データをカラムを増やして各ロケールのデータを格納します。

TABLEの構造
+------+----------+------------+
|  id  | hello_en |  hello_ja  |
+------+----------+------------+
|   1  |  Hello   | こんにちは |
+------+----------+------------+

もしくはハッシュの形で各ロケールのデータを１つにまとめて（＝シリアライズして）DBの１つのカラムに突っ込むという手もあります。

#{RAILS.ROOT}/app/models/greetings.rb
class Greeting < ActiveRecord::Base
  serialize :data, Hash
end

  @greeting.data = {:en => "Hello", :ja => "こんにちは"}

いずれの方法にせよ、表示の際にロケールにあわせて表示し分けるようにします。

2. HTMLに直接書く単語や文章

とりあえず自由に辞書を定義する

HTMLテンプレートに書くタイトルや文章などを辞書ファイルで定義していく、というのがとりあえず思いつくところでしょうか。辞書ファイルはハッシュの形で定義します。基本的にキーを自由につけることができますし、整理のために自由に階層をつけることができます。

#{RAILS.ROOT}/config/locale/ja.yml
ja:
    hello: こんにちは
    foods:
        vegetables:
            cucumber: きゅうり

参照するには I18n.t メソッドを使います。
Controllerの中では

#{RAILS.ROOT}/app/controllers/users_controller.rb
  I18n.t('hello')
  I18n.t('foods.vegetables.cucumber')

Viewの中では

#{RAILS.ROOT}/app/views/users/index.html.erb
  <%= t('hello') %>
  <%= t('foods.vegetables.cucumber') %>

という形で参照します。

「きゅうり」のように階層になっている用語については、上位の階層をscopeと見ることもでき、

#{RAILS.ROOT}/app/views/users/index.html.erb
  <%= t('cucumber', :scope => 'foods.vegetables') %>
  <%= t('vegetables.cucumber', :scope => 'foods') %>

という書き方も可能。

キーの指定は文字列だけでなく、シンボルでもいけます。

#{RAILS.ROOT}/app/views/users/index.html.erb
  <%= t(:hello) %>
  <%= t(:foods, :scope => 'vegetables.cucumber') %>
  <%= t(:foods, :scope => [:vegetables, :cucumber]) %>

ビュー別の定義

特定のビューで使用する辞書定義は、ルールに従って定義するとビューファイルの中で簡単に参照できます。

#{RAILS.ROOT}/config/locale/ja.yml
ja:
  user:        # コントローラ名
    index:     # アクション名
      title: ユーザー一覧
    show:      # アクション名
      title: ユーザーの詳細

このように定義するとビューファイルの中で <%= t('.title') %> で参照でき、index.html.erb と show.html.erb でそれぞれの定義が使われます。

ロケール別のHTMLテンプレート

単語・文章レベルで表示を差し替えればよいだけであれば上記の方法で対応できますが、ロケールによってページ内の構成が大幅に異なる場合などはロケールごとに別々にHTMLテンプレートを用意しておくこともできます。

#{RAILS.ROOT}/app/views/users/
[users]
  |-- index.en.html.erb
  |-- index.ja.html.erb
  |-- index.de.html.erb

ロケールにあわせて適切なHTMLテンプレートを選択してくれます。

3. モデルの名前や属性の名前などモデルに関連する文字列

モデルに関連する名前は次のように辞書ファイルに書きます。

#{RAILS.ROOT}/config/locale/ja.yml
ja:
  activerecord:
    models:
      user: ユーザー             # モデル名
    attributes:
      user:                      # モデル名
        name: 名前               # モデルの属性名 
        password: パスワード     # モデルの属性名 

モデル名、モデルの各属性名は

User.model_name.human            # モデル名
User.human_attribute_name(name)  # モデルの属性名 

のように簡単に参照できます。もちろん通常通り I18n.t('activerecord.models.attributes.name') でも参照できます。

form の中ではモデルの属性値を表す label が自動的に辞書ファイルの内容で置き換えられます。

#{RAILS.ROOT}/app/views/edit.html.erb
  <%= form_for(@user) do |f| %>
    <%= f.label :name %>    # 「名前」
  <%= end %>

※個人的には、毎回 User.model_name.human、User.human_attribute_name(name)とか書くのは若干面倒だなぁと思うので、こんなヘルパーメソッドを作ってモデル名やモデルの属性名が超簡単に拾えるようにしてます。

#{RAILS.ROOT}/app/helpers/application_helper.rb
def t_ar(label)
  arr = label.split(/./)
  if arr.length <= 2 then
    begin
      model = arr[0].constantize
    else
      if arr.length == 1
        return model.model_name.human
      else
        return model.human_attribute_name(arr[1])
      end
    end
  end
  label
end

  t_ar('User')        # モデル名（User.model_name.human）
  t_ar('User.name')   # 属性名（User.human_attribute_name(name)）

4. Railsのエラーメッセージ

エラーメッセージも辞書ファイルで定義することで日本語化できます。

#{RAILS.ROOT}/config/locale/ja.yml
ja:
  activerecord:
    errors:
      messages: ユーザー一覧
        blank: "が記入されていません。"   # ①
        invalid: "が不正な値です。"
        confirmation: "が一致しません。"
        ...

エラーの種類に対応したエラーメッセージをこのように定義します。この定義はすべてのモデルのエラーをカバーします。

一方、特定のモデルや特定の属性について別のエラーメッセージを指定するには次のようにします。
特定のモデル用のエラーメッセージ

#{RAILS.ROOT}/config/locale/ja.yml
ja:
  activerecord:
    errors:
      models:
        user:
          blank: "が記入されていません。"   # ②
          ...

特定のモデルの特定の属性用のエラーメッセージ

#{RAILS.ROOT}/config/locale/ja.yml
ja:
  activerecord:
    errors:
      models:
        user:
          attributes:
            name:
              blank: "が記入されていません。"   # ③
              ...

より細かいところでの定義が優先されます。
Userモデルのname属性についてのvalidationが以下のように定義されていてnameに値にblankエラーが発生した場合、③ → ② → ① の順に探して最初に見つかった定義が使われます。

#{RAILS.ROOT}/app/models/user.rb
class User < ActiveRecord::Base
  validates_presence_of :name
end

[Rails3] 国際化 I18n のまとめ（その２：ロケールの切り替え）

実行環境：
ruby 1.9.3
Rails 3.1.3
I18n

文字列を国際化する I18n の使い方のまとめです。
今回は、その２としてロケールの切り替えについて考えてみたいと思います。

表示ロケールを決定する流れ

複数のロケールを定義している場合、表示するロケールがアクセス毎に判断することになります。それをどうやって（どの情報を使って）判断するか、というお話です。

1. ロケール値が明示的に指定されていたら、そのロケールで表示
• ロケール値を URL のクエリ（パラメータ）で指定
• ロケール値を URL のパス名で指定（実態はクエリと同じ）
• ロケール値をセッション情報で指定
2. アクセス先のURLのドメイン名で判別（複数のドメイン名で運用している場合のみ）
• TLD（Top Level Domain）で判別
• サブドメインで判別
3. 接続元の情報に応じて、適切なロケールで表示
• HTTP_ACCEPT_LANGUAGEから判断
• IPアドレスから判断
4. （とりあえず）デフォルトのロケール（config.I18n.default_locale）で表示

1.〜4.の方法を適当に組み合わせてやります。（4.は方法と呼べるものでもないが。） ミニマムにやるなら 1. と 4. 、ちゃんとやるんなら1. と 3. と 4.の組み合わせが一般的だと思います。 2. は「yoursite.com と yoursite.jp」（TLDで判別）、あるいは「ja.yoursite.com と fr.yousite.com] （サブドメインで判別） など複数の（サブ）ドメイン名で運用している場合のみ可能な技です。
# 純日本語なサイトでロケールを全く切り替えないのであれば、当然のことながら I18n.locale の値をデフォルト（config.I18n.default_locale）のまま変更しなくてOKです。

ロケールの切り替えのざっくりイメージは

• ミニマムにやる場合（1. と 4.）
  　- サイトに最初にアクセスするとデフォルトのロケールで表示
  　- 途中で日本語での表示に変更したいユーザーは日の丸アイコンをクリック
  という感じ
• ちゃんとやる場合（1. と 3. と 4.）
  　- 接続元の情報から定義済みのロケールがあれば、そのロケールを使用して表示
  　- なければデフォルトのロケールで表示
  　- ユーザーが別の表示に変更したい場合は、表示したい言語の国旗アイコンをクリック
  という感じ

ロケール値の受け渡し

複数のロケールをユーザーが切り替えられるようにするには、同じユーザーの連続したアクセス（同一セッション）ではロケール値を引き継げないといけません。じゃないと、一度ロケールを切り替えてもアクセスする度にロケールの設定が元に戻ってしまうことになります。

ロケール値の受け渡しの方法のあれこれ（もないけど…）

session情報（または cookie）でロケール値を受け渡す

現在のロケール値を session 情報に格納し、以降のアクセスについては session 情報から取り出して使用します。

ロケール値が切り替わった時に session 情報に格納
session[:locale] = I18n.locale

アクセスの度に session 情報から locale 値をセットする

#{RAILS.ROOT}/app/controller/application_controller.rb
ApplicationController < ActionController::Base
  before_filter :restore_locale

private
  def restore_locale
    I18n.locale = session[:locale] if session[:locale]
  end
end

同一セッション内で共有する情報なので、session 情報としてとっておく、というのはストレートな考え方です。やり方も簡単。 でもあまり推奨されないらしいです(^^;
RESTful な考え方だと同じURLでアクセスしたら基本的に表示される内容は同じであるべき、ってことらしい。
# 個人的には「ま、いいんじゃない？」って気がするけど。

URLのクエリのパラメータとして毎回ロケール値を渡す

基本となるシンプルな考え方です。
アクセスする時のイメージはこんな感じ

URL の例
http://www.yoursite.com/topics?locale=ja

アクセスの度に params から locale 値をセットする
#{RAILS.ROOT}/app/controller/application_controller.rb
ApplicationController < ActionController::Base
  before_filter :restore_locale

private
  def restore_locale
    I18n.locale = params[:locale] if params[:locale]
  end
end

URLのパラメータで渡すということは、別のページに移動したりする際に毎回 locale の値をパラメータに含めてあげる必要があります。

#{RAILS.ROOT}/app/views/people/show.html.erb
  <%= link_to people_path(:locale => I18n.locale) %>

と、こんな感じでいけるでしょう。
ですが、これをすべてのリンクに追加してまわるのはちょっとイケてないので、常にパラメータに locale を追加してもらえるように ApplicationController で設定をします。

#{#RAILS.RPPT}/app/controllers/application_controller.rb
def url_options
  { :locale => I18n.locale }.merge(super)
end

これでOKです。

でも URL に毎回「?locale=ja」とかくっついてあんまし格好よくなくね？と思った方は、もう一手間を加えて URL のパスの一部としてロケール値を渡すようにしましょう（次項へ続く）

URLのパスの一部でロケール値を渡す（実質的にはクエリで渡すのと同じ）

前項のパラメータでロケール値を渡すの続きです。Rails3の強力なルーティングの力を借りてクエリの形をしているパラメータをパスの一部の形に変えることができます。config/routes.rb をちょいと変更するだけです。

ルーティング変更前↓

#{RAILS.ROOT}/config/routes.rb
  resources :people

ルーティング変更後↓

#{RAILS.ROOT}/config/routes.rb
  scope "/:locale" do
    resources :people
  end

これで URL が以下のように変わります。
URL変更前↓

http://yoursite.com/people?locale=ja

URL変更後↓

http://yousite.com/ja/people

ルーティングの設定は、アクセスされたURLの解析だけでなく、Railsアプリケーション内でリンクを作る場合にも使用されるので <%= link_to 'People', people_path %> で作成されるパスも自動的にかわります（めちゃ便利！）

これで完璧ですぅ(^^)

ドメイン名（サブドメイン名）からのロケールの判定

ホスト名の一部からロケールとして使用する文字列を抜き出します。

TLD名からロケールを判定

#{RAILS.ROOT}/app/controller/application_controller.rb
ApplicationController < ActionController::Base
  before_filter :set_locale

private
  def set_locale
    I18n.locale = extrace_locale_from_tld
  end

  def extract_locale_from_tld
    request.domain.split('.').last
  end
end

サブドメイン名からロケールを判定

#{RAILS.ROOT}/app/controller/application_controller.rb
ApplicationController < ActionController::Base
  before_filter :set_locale

private
  def set_locale
    I18n.locale = extrace_locale_from_subdomain
  end

  def extract_locale_from_subdomain
    request.subdomains.first
  end
end

こんな感じでやればOKです。とりあえず引っ張ってきた文字列のロケールはRailsアプリケーション内に用意されているという前提です。そこんとこをチェックする場合は次項参照。

接続元に応じたロケールの判断

接続元の情報ですので HTTP_REQUEST の内容で判断します。

HTTP_ACCEPT_LANGUAGE で判断

HTTP_REQUEST の中の HTTP_ACCEPT_LANGUAGE の最初の言語名（＝最初の２文字）をとってきます。
HTTP_ACCEPT_LANGUAGE にはカンマで区切って複数の言語が優先度とともに書いてあるので、優先度の高い順にロケールの準備の有り／無しを判定しながら決めていくのが筋のような気がしますが、ここでは省略。

#{RAILS.ROOT}/app/controller/application_controller.rb
ApplicationController < ActionController::Base
  before_filter :set_locale

private
  def set_locale
    extracted_locale = extract_locale_from_accept_language
    I18n.locale = (I18n::available_locales.include? extracted_locale.to_sym) ? 
                    extracted_locale : I18n.default_locale
  end

  def extract_locale_from_accept_language 
    request.env['HTTP_ACCEPT_LANGUAGE'].scan(/^[a-z]{2}/).first
  end
end

I18n::available_locales 配列の中に定義済みのロケールのリストがあるので、そこと比較して定義されていればそのロケールを、なければデフォルトロケールを使用します。

IP アドレスで判断

HTTP_REQUEST の中のリモートIPアドレスをとってきます。
IPアドレスから国を判断する必要がありますが、MaxMind 社の GeoIP ライブラリが使えます。 ruby のライブラリや Apache モジュール（mod_geoip）、Gem も複数存在するようなので好みの方法を使用してください。
以下は cjheath/geoip の Gem を使ったサンプルです。

#{RAILS.ROOT}/Gemfile
  gem 'geoip'

#{RAILS.ROOT}/app/controller/application_controller.rb
ApplicationController < ActionController::Base
  require 'geoip'
  before_filter :set_locale

private
  def set_locale
    extracted_locale = extract_locale_from_ip
    I18n.locale = (I18n::available_locales.include? extracted_locale.to_sym) ? 
                    extracted_locale : I18n.default_locale
  end

  def extract_locale_from_ip
    geoip ||= GeoIP.new(Rails.root.join(“lib/GeoIP.dat”)) 
    country_location = @geoip.country(request.remote_ip) 
    country_location.country_code2.downcase
  end
end

まとめ（＝全部盛り）

ロケールの判定を上記の諸々をまとめてやる場合は以下のように書けばよいかと。上で説明したきたロケールの取得方法をそれぞれ準備してあげて、優先順位を決めて１つめの方法で取得できなければ、次の方法、次の方法…といった感じで extracted_locale 変数にセットします。取得したロケールが定義済みロケールのリスト（I18n::available_locales）にあるかどうかをチェックし、なければデフォルトを使う、という流れです。

#{RAILS.ROOT}/app/controller/application_controller.rb
ApplicationController < ActionController::Base
  require 'geoip'
  before_filter :set_locale

private
  def set_locale
    extracted_locale = params[:locale] ||
                       extract_locale_from_subdomain ||
                       extract_locale_from_tld ||
                       extract_locale_from_accept_language ||
                       extract_locale_from_ip
    I18n.locale = (I18n::available_locales.include? extracted_locale.to_sym) ?
                    extracted_locale : I18n.default_locale
  end

  def extract_locale_from_subdomain
    request.subdomains.first
  end

  def extract_locale_from_tld
    request.domain.split('.').last
  end

  def extract_locale_from_accept_language 
    request.env['HTTP_ACCEPT_LANGUAGE'].scan(/^[a-z]{2}/).first
  end

  def extract_locale_from_ip
    geoip ||= GeoIP.new(Rails.root.join(“lib/GeoIP.dat”)) 
    country_location = @geoip.country(request.remote_ip) 
    country_location.country_code2.downcase
  end
end

必要のないものは抜いてくださいまし。

[Rails3] 国際化 I18n のまとめ（その１：準備編）

実行環境：
ruby 1.9.3
Rails 3.1.3
I18n

文字列を国際化する I18n の使い方のまとめです。
ここでいう国際化とは、要するに複数言語表示対応という意味です。
※ちなみに I18n というのは、I で始まり、間に18文字を挟んで、nで終わる文字列という意味で Internationalization の略称です。

「おらぁ日本語しか使わねーから関係ねえだよ」と思う方もいるかと思いますが、View 用の日本語文字列をコードと切り離しておく場合、I18n の枠組みに乗っかると便利です。

今回は、その１として I18n を使った国際化の大まかなイメージを説明しつつ、日本語ロケールを使えるように設定します。

ロケールとは使用する言語の設定であり、１つの Rails アプリケーションの中で英語(:en)、日本語(:ja)、スペイン語(:es)などなど複数のロケールを定義することができます。

表示する時点のロケール値（I18n.locale）によって表示する言語を切り替える仕組みになっています。I18.locale の値が :en なら英語表記、I18n.locale の値が :ja なら日本語表記で表示される、という具合です。

動作確認のテスト１

適当な scaffold を作って（ここでは book とします）、View の中で以下のように書いてみて下さい。

#{RAILS.ROOT}/app/views/books/index.html.erb
  <%=t :hello %>

I18n が働いていれば

hello world

と表示されるはずです。
なぜこうなるかと言えば、既に #{RAILS.ROOT}/config/locales/en.yml の中で「hello: hello world」と書かれているからです。

#{RAILS.ROOT}/config/locales/en.yml
en:
  hello: hello world

I18n.translation というのがキーと値の対応付けをしてくれるメソッドで :hello（もしくは 'hello'）を渡すと 'hello world' を返します。
t というヘルパーメソッドが、この I18n のメソッドの別名として定義されています。

en.yml は辞書ファイルと呼ばれ、このファイルの中にロケールの定義を書いていきます。
通常、ファイル名のベースネーム部分（拡張子より前の部分）はロケールを表すアルファベット２文字にします。日本語なら ja.yml、英語なら en.yml、ドイツ語なら de.yml、フランス語なら fr.yml という具合です。こうすると１つのファイルには１つのロケールについての定義を記載し、複数のロケールについて定義する場合はそれぞれのロケール名に応じたファイルを作成することになります。
※実際にはファイル名は何でもよいです。複数のロケールの定義を1つのファイルにまとめて書いてもOK。どのロケールの定義かは、ファイル名ではなくymlファイルの中身（ハッシュ定義の最上位のキー）で判断されます。どのファイルを読み込むかも「*.yml」って感じで設定されているので拡張子さえあっていればなんでもいいのです。

デフォルトロケールの設定

I18n は表示をする際にその時のロケールの値、I18n.locale の値をみて表示するロケールを判断します。 ロケール値はコードの中で明示的に変更しない限り、デフォルトの値が使用されます。 ロケールのデフォルトは通常 :en、つまり英語になっています。 そのため上記のテスト１ではロケール値が :en となり en.yml の中で設定した内容が表示されたわけです。

動作確認のテスト２

先ほどのテスト１と同じファイルで日本語ロケールのテストをしてみましょう。 まず en.yml を同じディレクトリにコピーして ja.yml という名前にし、テキストを以下のように変更します。

#{RAILS.ROOT}/config/locales/ja.yml
ja:
  hello: こんにちは、世界

続いて View ファイルを編集します。

#{RAILS.ROOT}/app/views/books/index.html.erb
  <%= "[%s]:"%(I18n.locale.to_s) >
  <%=t :hello %>
  <br />
  <% I18n.locale = :ja >
  <%= "[%s]:"%(I18n.locale.to_s) >
  <%=t :hello %>

サーバを再起動してから実行します。（辞書ファイルを更新した場合はサーバの再起動が必要です）

[en]hello world
[ja]こんにちは、世界

と表示されたでしょうか？このようにロケール値を変えることで表示する文字列を変えるわけです。

日本語をメインで使用するので日本語をデフォルトのロケールに設定したいと思います。config/application.rb を下記のように編集します。

#{RAILS.ROOT}/config/application.rb
config.i18n.default_locale = :ja

これでデフォルトのロケールが日本語(:ja)になりました。

辞書の置き場所

辞書ファイルはたいてい各ロケールごとにymlファイルを作成します。まじめに国際化をしようとすると１ファイル内に書くと定義する項目が多くなってきて見通しが悪くなりますので、１つのロケールの定義を複数のファイルに分割したりします。ディレクトリをきってロケールの分割された辞書ファイルを格納することも可能です。

#{RAISL.ROOT}/config/locales/ 以下のディレクトリ構成（例１）
[locales]
  |-- defaults.en.yml
  |-- defaults.ja.yml
  |-- models.ja.yml
  |-- models.en.yml
  |-- views.ja.yml
  |-- views.en.yml
 

#{RAISL.ROOT}/config/locales/ 以下のディレクトリ構成（例２）
[locales]
  |-- [defaults]
  |     |-- en.yml
  |     |-- ja.yml
  |-- [models]
  |     |-- [defaults]
  |     |     |-- en.yml
  |     |     |-- ja.yml
  |     |-- [users]
  |     |     |-- en.yml
  |     |     |-- ja.yml
  |     |-- [books]
  |     |     |-- en.yml
  |     |     |-- ja.yml
  |-- [views]
        |-- [defaults]
        |     |-- en.yml
        |     |-- ja.yml
        |-- [users]
        |     |-- en.yml
        |     |-- ja.yml
        |-- [books]
              |-- en.yml
              |-- ja.yml

辞書ファイルの格納場所は標準では #{RAISL.ROOT}/config/locales/ の直下となっていて locales 以下のサブディレクトリの中までは読んでくれません。locales 以下のサブディレクトリの中までをすべて読むように設定します。
変更前

#{RAILS.ROOT}/config/application.rb
config.i18n.load_path += Dir[Rails.root.join('config', 'locales', '*.{rb,yml}')]

変更後

#{RAILS.ROOT}/config/application.rb
config.i18n.load_path += Dir[Rails.root.join('config', 'locales', '**', '*.{rb,yml}')]

これで準備完了です。

辞書ファイルの中身についてはその３以降でまとめていく予定です。

[Rails3] コードに日本語を書くとエラーになる件

実行環境：
ruby 1.9.3
Rails 3.1.3

Controller や Helper など ruby のコードの中に日本語を書くと

invalid multibyte char (US-ASCII)

というようなエラーが出ます。

変数名やメソッド名だけでなく、文字列として埋め込んでもダメです。
うっかりデバッグ用に日本語を埋め込むとはじかれてしまいます。

このエラーを回避する方法は、日本語を書いたファイルの先頭に

# encoding: utf-8

もしくは

# -*- encoding: UTF-8 -*-

というおまじないを書けばOKです。

※Rails2 の時は大丈夫だったのに… というか ruby 1.9.x になってからか。

ちなみに、コメント文であれば日本語問題なく通ります。
View のファイルの中（HTMLなパート）も大丈夫です。


ま、そもそもコードの中にがっつり固定文字列を埋め込むのはよろしくないので、 「i18n 化をきちんとやりなさい」というありがたい天のお告げだと思うことにします。(^^)

[Rails3] I18n による日本語化の最低限の設定

実行環境：
ruby 1.9.3
Rails 3.1.3
I18n

日本語でサイトを作る場合、目に見えるところという意味でViewのhtmlファイル（のテンプレート）はさささっと日本語にしたいと思うわけですが、モデル１つについて index ビューやら show ビューやらがあって全部日本語にしていかないといけません。頑張って直したとしても、エラーメッセージが英語で出てきたりします。Railsに標準で備わっているI18nの機能を使って、モデルの属性名を日本語化（日本語名を１箇所で設定）できる（DRYの原則）し、同じものなのにページによって呼び方が違うみたいなことも防げます。エラーメッセージも日本語化することができます。

サクっと日本語化する

手っ取り早く日本語化の設定をする場合、デフォルトのRailsアプリに以下の２つの変更を加えます。日時表現やエラーメッセージが日本語化できます。

デフォルトロケールを日本語にする
config/application.rbの中に以下を追記します。ちなみにこの設定をしないと標準では英語になっています。

#{RAILS.ROOT}/config/application.rb
config.i18n.default_locale = :ja

日本語の辞書ファイルを頂いてくる
標準的な日本語の辞書ファイルを公開されていらっしゃる方がいるので、それをありがたく頂戴しちゃいます。ダウンロードしたファイルは /config/locales/ 直下に置きます。

#{RAISL.ROOT}/config/locales/
[locales]
  |-- en.yml    # もともとあるファイル
  |-- ja.yml    # 頂戴してきたファイル

これで準備完了です。あとは個別のビューやモデルを日本語化していきます。

[Rails3] コントローラ名から対応するモデルオブジェクトを取得する

実行環境：
ruby 1.9.3
Rails 3.1.3

コントローラ名からモデル名を取得します。

#{RAILS.ROOT}/app/controllers/users_controller.rb
class UsersController < ActionController::Base
  def index
    @model_name = controller_name.classify           # モデル名の取得
    @all = @model_name.constantize.find(:all)        # モデルオブジェクトの取得
  end
end

コントローラ名を classify するとモデル名が得られます。
モデル名を constantize するとモデルオブジェクトが得られます。

ただし、これは Rails の規約に則って推測しているだけです。
つまり「規約に則って作られていれば対応する名前はこの名前でしょ？」という具合です。 実際にモデルオブジェクトが取得できたかどうかを判定してあげる必要があるかも。

[Rails3] Oracle DB と SQlite3 を併用した場合にエラー？

実行環境：
ruby 1.9.3
Rails 3.1.3
sqlite3 1.3.5
ruby-oci8 2.0.6
activerecord-oracle_enhanced-adapter 1.3.2, 1.4.0

１つのRailsアプリの中で SQlite3 DB と共にレガシーな Oracle DB を使おうとしてちょっとはまったのでメモ。

SQlite3 DBでアクセス（create）しようとすると、以下のようなエラーを頂戴いたしました。

undefined method `virtual?' for #<ActiveRecord::ConnectionAdapters::SQLiteColumn:0x1a477b8>

github に Connection to multiple database なんて書き込みがあり、先人がいた模様。
activerecord-oracle_enhanced-adapter 1.3.2では大丈夫だったのに 1.4.0 にあげたらエラーになった、ということなので、 1.3.2 に落としてみると SQlite3 DB への create も無事にOKになりました。


が、ここで新たな問題が発生。

set_primary_key を設定している Oracle DB のモデルに対して .find(params[:id]) とやると、

OCIError: ORA-01036: 変数の名前/数が無効です。: SELECT * FROM (SELECT "USER".* FROM "USER" WHERE "USER"."UID" = ? AND ....

と、引数で与えている id が SQL 文の中で展開されずに「?」のまま残っている模様…

しょうがないので、find ではなく where を使って Rails3 っぽく書き換えてみることに。

Rails2 的な書き方
@user = User.find(params[:id])

これを以下のように書き換える

Rails3 的な書き方
@usr = User.where("uid = ?", params[:id]).first

とりあえず動きました。

set_primary_key の意味があんまりないのでどうかな…
あと、今回は参照オンリーで検証してないので、更新作業とか問題ないのか不明です (^^;;;

※ちなみに 1.4.0 では上側の Rails2 的な書き方で通るので、そっちが正しい動きのような気がします。

[Rails3] ログイン認証の要・不要をコントローラーによって使い分ける

実行環境：
ruby 1.9.3
Rails 3.1.3

ログイン認証を実現する際、認証が必要なコントローラー内に before_filter を書いてコントローラーを実行する前にログイン状態をチェックします。

たいてい、認証が必要なコントローラーが複数あります。それぞれに before_filter とそのメソッドを書くのはダサいので、before_filter を書いたコントローラークラスを作って継承させるのですが、認証させるコントローラーの数が多いと面倒になってきます。

すると「ええぃ、全てのコントローラーの親である ApplicationController に書いてしまえ！」と思うわけですが、逆に認証させたくないコントローラーが１つ２つあると、どうしてやろうか？と悩むことになります。

実現方法は色々あると思いますが、例としていくつかパターンを上げてみたいと思います。

ここでは例として
　・CustomerController ⇒ 認証が必要（他にもいくつもある、という想定）
　・LoginController ⇒ 認証が不要
という状況で説明してみようと思います。


① 認証用の before_filter を組み込んだコントローラーを作って継承させる（正攻法その１）
認証用の before_filter を組み込んだコントローラー（ここでは AuthController）を作り、認証が必要なコントローラーには AuthController を継承させます。

継承のイメージ
ApplicationController
　　├─→ AuthController → CustomerController
　　└──────────→ LoginController

このような感じで継承させます。
以下がコードの大枠です。AuthController に認証の before_filter を仕込みます。

#{RAILS_ROOT}/app/controllers/auth_controller.rb
class AuthController < ApplicationController
  before_filter :login_required

private
  def login_required
    # ログインしていなければログイン画面へリダイレクト
  end
end

#{RAILS_ROOT}/app/controllers/customer_controller.rb
class CustomerController < AuthController
end

#{RAILS_ROOT}/app/controllers/login_controller.rb
class LoginController < ApplicationController
end

② 認証用のメソッドだけを ApplicationController で定義し、認証が必要なコントローラーだけで before_filter をセットする（正攻法その２）
before_filter にセットするプライベートメソッド（ここでは login_required）を ApplicationController で定義し、認証が必要なコントローラーには、個々のコードの中で before_filter をセットする。逆に認証不要なコントローラーにはセットしない。

継承のイメージ
ApplicationController
　　├─→ CustomerController
　　└─→ LoginController

継承関係はデフォルトのままです。
以下がコードの大枠です。ApplicationController で認証用のプライベートメソッドのみを定義します。

#{RAILS_ROOT}/app/controllers/application_controller.rb
class ApplicationController < ActionController::Base
  # before_filter のセットは個々のコントロール内に書くのでここには書かない

private
  def login_required
    # ログインしていなければログイン画面へリダイレクト
  end
end

#{RAILS_ROOT}/app/controllers/customer_controller.rb
class CustomerController < ApplicationController
  before_filter :login_required    # 認証プロセスを踏ませる
end

#{RAILS_ROOT}/app/controllers/login_controller.rb
class LoginController < ApplicationController
  # 認証は不要なので、before_filter のセットはしない
end

③ 認証用の before_filter を ApplicationController に組み込み、認証が不要なコントローラー内で before_filter をスキップする

継承のイメージ
ApplicationController
　　├─→ CustomerController
　　└─→ LoginController

このような感じで継承させます。
以下がコードの大枠です。ApplicationController に認証の before_filter を仕込み、LoginController 内で before_filter の適用をキャンセルします。

#{RAILS_ROOT}/app/controllers/application_controller.rb
class ApplicationController < ActionController::Base
  before_filter :login_required

private
  def login_required
    # ログインしていなければログイン画面へリダイレクト
  end
end

#{RAILS_ROOT}/app/controllers/customer_controller.rb
class CustomerController < ApplicationController
end

#{RAILS_ROOT}/app/controllers/login_controller.rb
class LoginController < ApplicationController
  skip_before_filter :login_required  # before_filter を適用しない
end

LoginController 内に skip_before_filter を書いていますが、認証不要なクラスが複数ある場合は、skip_before_filter をつけた NoauthController クラスを作って、LoginController に NoauthController クラスを継承させるといいでしょう。

④ 認証用の before_filter を適用する・しないの条件付きで ApplicationController に組み込む
上記の②と似たようなやり方ですが、before_filter の適用・非適用の条件を ApplicationController 内で設定します。

継承のイメージ
ApplicationController
　　├─→ CustomerController
　　└─→ LoginController

②と同様、このような感じで継承させます。デフォルトのままですね。
以下がコードの大枠です。ApplicationController に認証の before_filter を適用条件をつけて仕込みます。

#{RAILS_ROOT}/app/controllers/application_controller.rb
class ApplicationController < ActionController::Base
  before_filter :login_required, :if => :auth_target?  # auth_target? が true の時のみ適用

private
  def login_required
    # ログインしていなければログイン画面へリダイレクト
  end

  def auth_target?
    self.controller_name != 'login' 
  end
end

#{RAILS_ROOT}/app/controllers/customer_controller.rb
class CustomerController < ApplicationController
end

#{RAILS_ROOT}/app/controllers/login_controller.rb
class LoginController < ApplicationController
end

注意点としては、:if => の後ろはメソッドにしないといけません。直接 true や false を書いたり、true/false を返す式を書いてもエラーになります。
:unless も使えます。

before_filter の適用条件については前回まとめてます ⇒ [Rails3] before_filter に条件を設定する


namespace を使って（例えば :adminとか）認証の要る・要らないを分ける、というのもよくやられますね。あくまでも認証の要るもの要らないものを区別しているだけなので、実現するには実質的に上のどれかの方法を使うような形になると思います。

結論としては、めんどくさがりな人（＝自分？）には④が楽ちんですが、お勧めは②です。
④と違って各コントローラー内のコードで認証の要る・要らないが判断できるのが良いと思います。

まあ、どういうやり方にするかは後は趣味の問題、かな。

[Rails3] before_filter に条件を設定する

実行環境：
ruby 1.9.3
Rails 3.1.3

ログイン認証なんかを実現する際におなじみの before_filter に適用条件をつけてみようというお話です。

① アクション名で制限をかける
:only、:except オプションを使うと、アクション名で適用条件を設定できます。

#{RAILS_ROOT}/app/controllers/application_controller.rb
class ApplicationController < ActionController::Base
  before_filter :my_filter1, :only => 'index'
  before_filter :my_filter2, :except => ['index', 'show']

private
  def my_filter1
  end
  def my_filter2
  end
end

親コントローラーに設定する場合は、継承する全てのコントローラーで「参照は誰でも可、更新・削除操作はログインが必要」なんて場合には効果的に使えると思います。


② 自由な条件で制限をかける
:if、:unless オプションを使うと、もっと自由に適用条件を設定できます。

#{RAILS_ROOT}/app/controllers/application_controller.rb
class ApplicationController < ActionController::Base
  before_filter :my_filter1, :if => :my_condition1?
  before_filter :my_filter2, :unless => :my_condition2?

private
  def my_filter1
  end
  def my_filter2
  end
  def my_condition1?
    return true
  end
  def my_condition2?
    return false
  end
end

:if や :unless の後ろはフィルタと同じようにメソッドにする必要があります。単純に true や false、あるいは真偽値を返す式を置いてもエラーではじかれてしまいます。

使い方としては、コントローラー名で判定をしたり、URL のパス文字列で判定したり、というのが一般的だと思います。

例）コントローラー名で判断する場合

#{RAILS_ROOT}/app/controllers/application_controller.rb
class ApplicationController < ActionController::Base
  before_filter :my_filter, :unless => :my_condition?

private
  def my_filter
  end

  def my_condition?
    self.controller_name == 'login'
  end
end

例）URLのパス部分の文字列で判断する場合

#{RAILS_ROOT}/app/controllers/application_controller.rb
class ApplicationController < ActionController::Base
  before_filter :my_filter, :if => :my_condition?

private
  def my_filter
  end

  def my_condition?
    request.path_info.match(/^\/admin\//)
  end
end

[Rails3] モデルにメソッドを追加する

実行環境：
ruby 1.9.3
Rails 3.1.3

Rails3でActiveRecordのモデルにクラスメソッドを追加します。
といっても、モデルだからどうだとかいう話は全然なくて、単純にクラスにメソッドを追加するだけの話なんですが、うっかり忘れてしまったのでメモ。

#{RAILS_ROOT}/app/models/user.rb
class User < ActiveRecord::Base

  def instance_method  # インスタンスメソッド
    return
  end  

  def self.class_method  # クラスメソッド
    return
  end

  private
  def private_method  # プライベートなインスタンスメソッド
    return
  end

end

というようにモデルにメソッドを追加します。

クラスに対して使おうとするとこんな感じ

× User.instance_method
○ User.class_method

インスタンスに対して使おうとするとこんな感じ

user = User.find(1)
○ user.instance_method
× user.class_method
× user.private_method

使い分けとしては、 インスタンスの状態（インスタンスが持つ変数たち）によって結果が変わるようなメソッドはインスタンスメソッド、 インスタンスに依って変わらないクラスに共通の処理を行うような場合はクラスメソッド、という感じでしょうか。

[Rails3] belongs_to で関連づけたモデルの属性値でソートするには :include を使うのだ

実行環境：
Rails 3.1.3

Rails3で、belong_to で関連付けられたモデルが持っている属性値でソートするには？

例として以下のように「本(Book)」モデルと「著者(Author)」モデルがあったとします。

{$RAILS_APP}/app/models/authors
class Author < ActiveRecord::Base
  has_many :books
end

{$RAILS_APP}/app/models/books
class Book < ActiveRecord::Base
  belongs_to :Author
end

２つのモデルは、has_many, belongs_to で関連づけられています。
本(Books)のリストを取得する際に著者(Author)の名前の順にソートしたいと思います。

まずは試しに

{$RAILS_APP}/app/models/books
class Book < ActiveRecord::Base
  belongs_to :Author

  default_scope :order => "author.name"
end

と、has_many / belongs_to の関連付けの力を信じて、うまくやってくれるだろうと期待してみる訳ですが Book.find すると「そんなカラムは知らんぞ！」とエラーが出て怒られます。

ログを見ても Book リストの取得の際の SQL 文に Author テーブルが全く登場しません。
author.name を order by のキーとして与えているところを汲んで欲しいところですが、そこまでは面倒見てくれない、ということでしょうか。

こんな時、他のテーブルを強制的に join させる素敵なコマンドがあります。 :include です。

{$RAILS_APP}/app/models/books
class Book < ActiveRecord::Base
  belongs_to :Author

  default_scope :include => "author", :order => "author.name"
end

としてやると、authorテーブルを強制的に join してくれるので上記のソートもうまくいくようになります。

[Rails3] 外部の Oracle DB に接続する（その３：Passenger対応編）

実行環境：
centOS 5.7
ruby 1.9.3
Rails 3.1.3
ruby-oci8 2.0.6
activerecord-oracle_enhanced-adapter 1.4.0

Rails3で外部のOracle DBにアクセスします。
その３：Passenger対応編。Passengerでデプロイする場合に必要な対応について、です。

環境変数の設定について

Passengerでデプロイする場合、環境設定がうまくセットされません。
Oracle のアダプタを使う場合 LD_LIBRARY_PATH 環境変数が必要なため、Mongrelサーバで動いてもPassengerではうまく動かないということが起こります。その回避方法です。

まず ruby の wrapper となるシェルスクリプトを作成します。シェルスクリプトの保存場所はどこでもOKです。

/usr/local/bin/ruby_wrapper_for_passenger
#!/bin/sh
export LD_LIBRARY_PATH='/usr/lib/oracle/11.2/client/lib'
"/usr/local/bin/ruby" "$@"

もちろん忘れずにこのスクリプトを実行可能にします。

# chmod 755 /usr/local/bin/ruby_wrapper_for_passenger

今作った wrapper を httpd.conf の Passenger が起動する ruby として指定します。

/etc/httpd/conf/httpd.conf
PassengerRuby /usr/local/bin/ruby_wrapper_for_passenger

これで無事に動くと思います。(^^)

[Rails3] 外部の Oracle DB に接続する（その２：Railsモデル編）

実行環境：
ruby 1.9.3
Rails 3.1.3
ruby-oci8 2.0.6
activerecord-oracle_enhanced-adapter 1.4.0

Rails3で外部のOracle DBにアクセスします。
その２：Railsモデル編としてRailsで接続できるようなモデルを作成します。

Oracle DBアダプタ（Gemファイル）のインストール

Railsアプリ内の Gemfile に以下の２行を追加します。

#{RAILS_ROOT}/Gemfile
gem 'ruby-oci8'
gem 'activerecord-oracle_enhanced-adapter'

bundlerでインストールします。

$ bundle install

接続設定（database.yaml）

データベース接続の設定を行います。

①標準のDB（developmentやproduction）として外部のOracle DBを使う場合
デフォルトで Sqlite3 を使う設定になっているところを Oracle 用の設定に変更します。

#{RAILS_ROOT}/config/database.yml
development:
  adapter: oracle_enhanced
  database: [サービス名]
  username: [ユーザー名]
  password: [パスワード]

production:
  adapter: oracle_enhanced
  database: [サービス名]
  username: [ユーザー名]
  password: [パスワード]

ここで書くサービス名などはローカル・ローミング・パラメータ、つまり tnsnames.ora ファイルで設定したものになります。詳しくは前回の記事 [Rails3] 外部のOracle DBに接続する（その１：準備編） を見て下さいね。

②標準のDBは内部のSqlite3を使い、特定のモデルだけで外部のOracle DBを使う場合
development:, test:, production: などは残しておいて、下記内容を追記する。

#{RAILS_ROOT}/config/database.yml
oracle_db:
  adapter: oracle_enhanced
  database: [サービス名]
  username: [ユーザー名]
  password: [パスワード]

外部DBへの接続のやり方については以前まとめました ⇒ [Rails3] ActiveReocrdで外部DBを使う

Scaffoldの作成

通常の Scaffold と同様に作成する。

$ rails generate scaffold user uid:integer name:string comment:string

既存のテーブル（レガシーDB）を使う場合は migration と timestamps をスキップするオプションをつけて作成するとよいと思います。

$ rails generate scaffold user uid:integer name:string comment:string --skip-migration --skip-timestamps

ここで指定するカラム名は使用するものだけでよい。（内部的にはテーブルのカラムを全て取ってくるので、ここで指定しなかったカラムでも view 等でアクセスできる。）

モデルの修正

①標準のDB（developmentやproduction）として外部のOracle DBを使う場合
特に修正の必要はありません。

②標準のDBは内部のSqlite3を使い、特定のモデルだけで外部のOracle DBを使う場合
接続先を通常のdevelopment/productionのDBではなく、oracle_dbで定義したものを使うように設定する。

#{RAILS_ROOT}/app/models/user.rb
class User < ActiveRecord::Base
  establish_connection(:oracle_db)

  set_table_name "[Oracleのテーブル名]"
  set_primary_key "uid"
end

endの前の2行はOracleのテーブルがRailsの規約に従っていないときの措置です。テーブル名がモデル名（ここではusers）と一致しない場合は set_table_name で実際のテーブル名を指定する。主キー名がidでない場合は、set_primary_key で主キーとなるカラム名を指定する。

サーバーとして立ち上げて

$ rails server

ブラウザからアクセスしてみましょう。

[Rails3] 外部のOracle DBに接続する（その１：準備編）

実行環境：
centOS 5.7
ruby 1.9.3
Rails 3.1.3
ruby-oci8 2.0.6
activerecord-oracle_enhanced-adapter 1.4.0

Rails3で外部のOracle DBにアクセスします。
その１：準備編として Oracle Instant Client のインストール・設定をします。

Oracle Instant Clientをインストール

OracleのサイトからInstant Clientをダウンロードします。Instant ClientはORACLEが提供しているORACLE接続用クライアントソフトウェアです。外部のOracle DBに直接接続できたりします。DB接続の下地を作ってくれるのでRailsでもその恩恵をあずかろうというわけです。まずはInstant Clientのうちのsqlplusコマンドで目的のOracle DBに接続するのが今回の目標です。

以下の3つのRPMファイルをダウンロードします。無料ですが、ユーザー登録しないとダウンロードできません。

• oracle-instantclient11.2-basic-11.2.0.2.0.i386.rpm
• oracle-instantclient11.2-devel-11.2.0.2.0.i386.rpm
• oracle-instantclient11.2-sqlplus-11.2.0.2.0.i386.rpm

の3つです。

Rails3でOracle DBに接続するだけであれば basic と devel だけでいいようなのですが、sqlplus で目的のDBに接続できるかのテストもしたいので sqlplus も入れておきます。

# rpm -hiv oracle-instantclient11.2-basic-11.2.0.2.0.i386.rpm
# rpm -hiv oracle-instantclient11.2-devel-11.2.0.2.0.i386.rpm
# rpm -hiv oracle-instantclient11.2-sqlplus-11.2.0.2.0.i386.rpm

環境変数の設定

Oracle用の環境変数の設定を行います。

/etc/profile.d/oracle.sh
export ORACLE_HOME='/usr/lib/oracle/11.2/client'
export C_INCLUDE_PATH='/usr/include/oracle/11.2/client'
export LD_LIBRARY_PATH='/usr/lib/oracle/11.2/client/lib'

これでsqlplus用にはOKです。※Passengerを使ってデプロイすると環境変数の設定がうまくできないないので後で別途設定をします。

ライブラリの設定

以下のように記載してファイルを保存します。

/etc/ld.so.conf.d/oracle.conf
/usr/lib/oracle/11.2/client/lib

ローカル・ネーミング・パラメータ（tnsnames.ora）の設定

ローカル・ネーミング・パラメータというのは、要するにOracle DBへの接続情報（ホストアドレスやポート番号、データベース名）をサービス名でタグづけして、接続する際に接続先の情報をサービス名で一発で指定することができる、というものです。

/etc/tnsnames.ora
サービス名 =
  (DESCRIPTION =
    (ADDRESS_LIST =
      (ADDRESS = (PROTOCOL = TCP)(HOST = IPあるいはホスト名)(PORT = 1521))
    )
    (CONNECT_DATA =
      (SERVICE_NAME = サービス名)
    )
  )

複数のOracle DBがある場合は、１つの tnsnames.ora ファイルの中に、上記の「サービス名 = (...)」を繰り返し記載することで複数のサービス名を定義できます。

SQL*Plusで接続のテスト

※上記の設定をしてから、設定を反映させるために一旦は端末を立ち上げなおして下さい。

$ sqlplus [ユーザー名]/[パスワード]@[サービス名]

でOracle DBに接続します。

SQL> select * from [テーブル名] where rownum <= 5;

SQL> select table_name from tabs;

などとSQL文を叩いてみます。

問題なく結果が返ってくれば接続の設定はOKです。

「苗字」カラムと「名前」カラムを「フルネーム」に集約する

実行環境：
ruby 1.9.3
Rails 3.1.3

composed_of宣言を使うとテーブルの２つのカラムを疑似的に１つのカラムにまとめることができます。
DBのテーブル上は、「苗字」カラムと「名前」カラムが別になっているが、Rails上はフルネームで扱いたい、なんて場合があります。あるいは住所情報が「都道府県」、「市区町村」、「それ以降の住所」と３つに分かれてテーブルに保存されているのを「住所」という1カラムとして扱いたい、なんて場合もあります。

集約によるデータの合成

例としてこんなテーブルがあったとします。

usersテーブル
カラム1	id
カラム2	myoji
カラム3	namae
カラム4	myoji_yomi
カラム5	namae_yomi

【目標】：「myoji」と「namae」カラムをスペースでつないだ文字列が「fullname」で参照できるようにする

集約のためのFullNameクラスを定義する

集約のためのルールを定めるクラスを作成します。とりあえずmodelの定義ファイルの中で定義します。

#{RAILS_ROOT}/app/models/users.rb
class User < ActiveRecord::Base
end

class FullName
  attr_reader :family_name, :given_name

  def initialize(family_name, given_name)
    @family_name = family_name
    @given_name = given_name
  end

  def to_s
    [@family_name, @given_name].compact.join(" ")
  end
end

テーブル上のカラムとの対応付けを行う

composed_of宣言を使ってfullnameという名前のプロパティ(?)を定義します。元々のテーブルのどのカラムが指定したFullNameクラスのどの変数に対応するかをマッピングします。

#{RAILS_ROOT}/app/models/users.rb
class User < ActiveRecord::Base
  composed_of :fullname,
              :class_name => "FullName",
              :mapping => [
                  [ :myoji, :family_name ],
                  [ :namae, :given_name ]
                ]
end

class FullName
#  省略
end

こうすることで、user.fullname という形で参照することができます。

#{RAILS_ROOT}/app/views/users/show.html.erb
<%= @user.fullname %>

FullNameクラスのインスタンス変数（family_name, given_name）にアクセサメソッドを定義しているので以下のような参照も可能です。

#{RAILS_ROOT}/app/views/users/show.html.erb
<%= @user.fullname.first_name %>
<%= @user.fullname.given_name %>

もともとのカラムにもアクセスできます。

#{RAILS_ROOT}/app/views/users/show.html.erb
<%= @user.myoji %>
<%= @user.namae %>

集約したfullnameに値を代入することはなんだかできないようです。値を変更する場合は、もともとのカラムの値を変えるようにすればいいのかな…？

集約に使うクラスを使い回す

定義したFullNameクラスを「myoji」と「namae」カラムの集約に使いましたが、「myoji_yomi」と「namae_yomi」カラムの集約にも使えます。

#{RAILS_ROOT}/app/models/users.rb
class User < ActiveRecord::Base
  composed_of :fullname,
              :class_name => "FullName",
              :mapping => [
                  [ :myoji, :family_name ],
                  [ :namae, :given_name ] ]
  composed_of :fullkananame,
              :class_name => "FullName",
              :mapping => [
                  [ :myoji_yomi, :family_name ],
                  [ :namae_yomi, :given_name ] ]
end

class FullName
#  省略
end

参照はこんな感じで。

#{RAILS_ROOT}/app/views/users/show.html.erb
<%= @user.fullname %>
<%= @user.fullname.first_name %>
<%= @user.fullname.given_name %>
<%= @user.fullkananame %>
<%= @user.fullkananame.first_name %>
<%= @user.fullkananame.given_name %>

複数のモデルでFullNameクラスを使い回すこともできそうです。そうなってくるとFullNameクラスの定義をする場所はもっといい場所があるかもしれません。（例えば#{RAILS_ROOT}/config/initializers/の中とか??）

結合した値の参照だけならメソッドでいいんじゃない？ composed_of の使い方を書いてきましたが、単に fullname を参照するだけならモデルの中にメソッドを定義すればよいような…

#{RAILS_ROOT}/app/models/users.rb
class User < ActiveRecord::Base

  def fullname
    "%s %s"%([self.myoji, self.namae])
  end
end

デバッグ用の文字列をログファイルに書き出す

実行環境：
ruby 1.9.3
Rails 3.1.3

Rails3 でデバッグ用の文字列を書き出す方法。めっちゃ基本事項ですが、久々に Rails に触ったらまるっきり忘れていたのでメモ (^^;

ログファイルに書き出す

Railsの実行時に処理されるコードの中で

logger.debug("ログに吐き出す文字列")

と書いておけば、ログファイル（#{RAILS_ROOT}/log/**********.log）に書き出されます。
「************」の部分は実行モード名が入ります。
developmentモードならdevelopment.log、productionモードならproduction.logちうわけです。
ただし、デフォルトの設定だとproductionモードでは logger.debug は記録されません。
ログの内容にはレベルがありproductionモードでは実行に影響ないものは残さない、ということなのでしょう。

ログレベル

• logger.fatal
• logger.error
• logger.warn
• logger.info
• logger.debug

productionモードで無理やりlogger.debugをログに残す場合はproductionモードの環境設定ファイルで設定します。

#{RAILS_ROOT}/config/environments/production.rb
config.log_level = :debug

オブジェクトの中身を記録する

デバッグしていると、このオブジェクトの中身はどうなっているんだろう？ってことがよくあります。
文字列や数字の変数ならそのまま var.to_s や "%s"%var で文字列化してしまえばいいですが、オブジェクトでそれをやると #<ClassName:0xXXXXXXX> みたいな訳分からん文字になってしまいます。
そんなときは .inspect を使うと便利。

logger.debug(var.inspect)

これまたド忘れしてたのでメモしておくのであります。

Passenger で development モードで動かす

実行環境：
ruby 1.9.3
Rails 3.1.3

Passenger で Rails アプリケーションを動かすとデフォルトでは production モードで動きます。

開発中であれば development モードで動かしたいところです。
開発中のテストも、rails server だと変更の度に再起動しなければならないけれど、passenger ならリロードするだけなので簡単ですね。

development モードで動かすときは httpd.conf に指定します。

/etc/httpd/conf/httpd.conf
RailsEnv development

httpdサーバ再起動。

# /etc/rc.d/init.d/httpd restart

これで development モードで動きます。