methoparaに触発されてDIコンテナを作成してみました。コンストラクタインジェクションとプロパティインジェクションをサポートしています。

   1  require 'object_injection'
   2  
   3  class Juicer
   4    attr_reader :fruit
   5  
   6    def initialize fruit
   7      @fruit = fruit
   8    end
   9  end
  10  
  11  class Fruit
  12  end
  13  
  14  container = ObjectInjection::Container.new
  15  container.add Juicer
  16  container.add Fruit
  17  
  18  juicer = container.get :Juicer
  19  p juicer.fruit # => #<Fruit:0x00000001059aa0>

詳細は、 http://github.com/takai/object_injection/ をどうぞ。

iPhone appのバージョンアップを申請後、時期verを開発継続している際にrejectされた、という場面があったので、タグ・ブランチでの運用を始めました：ezPhotoMail2度目のrejectを食らってしまいました orz

rails@githubの場合：命名

ブランチ：バージョン＋stable/unstableの形
http://github.com/rails/rails/tree/2-3-stable

タグ：タグ名はvが入っている形
http://github.com/rails/rails/tree/v2.3.2.1

railsを参考にezPhotoMailでの運用を決めました、下記。

ezPhotoMailでの運用：命名

appリリース後、新しいバージョンをリリースする場合はタグを付けます：タグは後付けも可能。 ブランチ名にはタグ名のvがない、数字だけのものを採用することにしました。

ex

• タグ名：v1.1
• ブランチ名：1.1

タグ名とブランチ名を同じにするとcheckoutやshowなどでrefspec(refs/heads/1.1, refs/tags/v1.1などの形式)を挙げねばならず運用が面倒。

ezPhotoMailでの運用：rejectされた

• タグ名のvを取ったブランチがあるか確認、なければブランチを作成して修正

     1  git branch -r
     2  git checkout -b 1.1 refs/tags/v1.1 #1.1ブランチを作成してcheckout
     3  git push origin HEAD:refs/heads/v1.1 #HEADはカレントブランチ。refs/heads/v1.1はサーバ上のブランチ名
  
• ブランチがあれば、checkoutして修正
• Info.plistのversionの末端を+1する：1.1→1.1.1
• 申請用のzip作成：appName_1.1.1.zip
• add, commit・push
• (各ブランチを最新にして)1.1ブランチをmasterブランチにマージ

     1  git checkout 1.1
     2  git pull --rebase origin v1.1:1.1 #v1.1=サーバブランチ
     3  git checkout master
     4  git pull --rebase origin master #サーバでもローカルでも同じ名前master
     5  git merge 1.1 #masterに1.1をマージ
  
• 申請作業

ezPhotoMailでの運用：申請が通った

ブランチのInfo.plist内のバージョンを確認して、タグを作成。

Rails-2.2以前とはちょっとやり方が変わったようなので、メモしておきます。 いままでは、:session_domainを指定すれば良かったのですが、 Rails2.3では、以下のように:domainを指定するようになったようです。

   1  config.action_controller.session = {
   2    :session_key => 'session_key',
   3    :domain => 'foo.com'
   4  }

See Also

• Edge (2.3.0) session_domain cookies problem

まだPokéDia-1.3のアップデート審査が通っていないのですが、 次期バージョンで実装予定のデータバックアップ・リストアについて、 実装方法を考えてみます。

データをバックアップする方法として最初に考えた方法は、 指定したメールアドレスにデータファイルを添付して送信するというものだったのですが、この場合、データをリストアするフローが以下のように面倒になってしまいます。

1. メールの中の添付ファイルをダウンロード
2. 添付されたデータファイルをどこかにアップロード
3. データファイルをpokedia://restore?url={url to data file}でPokéDiaにダウンロードしてリストア

次に考えた方法は、バックアップデータファイルをアップロードするアップローダサービス(例えば backup.s21g.com)を用意して、

1. PokéDiaからbackup.s21g.comに直接HTTP POSTでデータファイルをアップロード（メールアドレスをキーにする）すると、リストアURL(pokedia://restore?url={url to data file})を含んだメールがキーとして指定されたメールアドレスに届く。
2. 届いたメールの中のリストアURLをタップすればリストア完了。

という流れです。今の所これが良さそうかな。 汎用的なサービスになりそうなので、http://appli.st で提供する方が良いかもしれないですね。

会社設立以来ほとんど更新していなかったのですが、 iPhoneアプリ等の開発で製品を紹介するページを置く場所が必要になったので、 Rails-2.3.2がリリースされた事もあり、I18nを使って国際化仕様のサイトを作りました。

http://ja.www.s21g.com/ 日本語

http://en.www.s21g.com/ 英語

従来通り、http://www.s21g.com/にアクセスすると、ブラウザの設定に従って、自動的に日本語か英語のサイトに振り分けられます。 localizationファイルをもっと用意すれば、ISOで定義されてる言語なら何語でも大丈夫なのですが、とりあえずはjaとenのみサポートです。

I18nの使い方

ローカライズファイルは、デフォルトではconfig/locales/*.ymlに配置します。 mutohさんの、 locale、 locale_rails を使うと色々と便利です。 EdgeバージョンはRails-2.3.2でも利用出来ました。

自動的にロケールを判別するために、以下のようなコードを ApplicationControllerに書きました。

   1  class ApplicationController < ActionController::Base
   2    before_filter :set_locale
   3  
   4    (..snip..)
   5  
   6    def set_locale
   7      I18n.locale = @original_locale = fallback_locale(I18n.locale)
   8      if request.host =~ /^([\w-]+)\.#{HOST.split(':')[0]}/i
   9        I18n.locale = fallback_locale($1)
  10      end
  11    end
  12  
  13  private
  14    def fallback_locale(locale)
  15      locale = locale.to_s
  16      @available_locales ||= Set.new(I18n.available_locales)
  17      until locale.empty? || @available_locales.include?(locale.intern)
  18        locale = locale.split(/([-_])/)[0..-3].join
  19      end
  20      locale.present? ? locale.intern : I18n.default_locale
  21    end

実際にローカライズする手順は、以下のような感じになります。

文字列のローカライズ

*.ymlファイルで定義されているメッセージキーに対して、

   1  ja:
   2    "hello": "こんにちわ"

こんな感じにt(...)ヘルパーメソッドを使います。

   1    t("hello") #=> "こんにちわ"

時刻などのローカライズ

時刻の場合もほぼ同様で、以下のような*.ymlファイルで定義されている設定に対応して、

   1  ja:
   2    date:
   3      formats:
   4        default: "%Y/%m/%d"
   5        short: "%m/%d"
   6        long: "%Y年%m月%d日(%a)"

以下のようにl(...)ヘルパーメソッドを使ってローカライズします。

   1  l(Date.today, :format => :short) #=> "03/22"

テンプレートのローカライズ

Viewテンプレートを丸ごとローカライズする場合は、

• top/index.ja.html.erb
• top/index.en.html.erb

のようなファイル名すればOKです。

UL/LIタグを使ってリストを表示するときに、 コレクションが空の場合はULタグを表示したくない場合というのが頻繁にあります。

   1  <% if @posts.present? %>
   2  <ul>
   3    <% @posts.each do |post| %>
   4    <li><%= h(@post.body) %></li>
   5    <% end %>
   6  </ul>
   7  <% end %>

そういう時は、だいたいこんな感じにコードを書きます。 しかし、条件が複雑になってきたり、複数のコレクションを考えなければ行けない場合に、きれいに記述出来なくなってきます。 そんな時は、以下のようなヘルパを使って、分岐条件を遅延評価するようにすると、処理が簡潔になります。

   1  module ApplicationHelper
   2    def delayed_if(&block)
   3      flag = Object.new
   4      def flag.set; @value = true end
   5      def flag.reset; @value = false end
   6      result = capture(&proc{block.call(flag)})
   7      concat(result) if flag.instance_variable_get(:@value)
   8    end

利用法

   1  <% delayed_if do |flag| %>
   2  <ul>
   3    <% @posts.each do |post| %>
   4    <li><%= h(@post.body) %></li>
   5    <% flag.set %>
   6    <% end %>
   7  </ul>
   8  <% end %>

flag.setがよばれた時だけ、delayed_ifのブロックが表示されます。 この例だと単純すぎてあまり恩恵が分かりにくいですが、 複数のコレクションを一つのULで表示する場合などでも簡潔に記述出来るようになります。

リソースを新規に作成する場合に、既存のものを再利用して作成したい場合は良くあると思います。 そんな時は、newアクションで:idを受け取れるようにして、 以下のようにすると、簡単に実現出来ます。

   1    def new
   2      @post = Post.new
   3      @post.attributes = Post.find(params[:id]).attributes if params[:id]
   4      @posts = Post.for_user(current_user).all
   5    end

そしてposts/new.html.erbの中で

   1  <% if @posts.present? %>
   2  <form action=<%= new_post_path %> method="GET">
   3    <%= select_tag :id, options_for_select(@posts.map{|i| [i.title, i.id]}) %>
   4    <%= submit_tag '読み込む' %>
   5  </form>
   6  <% end %>

こんな感じに、テンプレートの読み込みフォームを作ります。 これで完了です。 Ajaxで posts/new/1 のようなURLにGETで遷移するようにした方が格好がいいかもしれません。

newアクションが:idで指定したリソースをテンプレートとして利用して新規にリソースを作成するというのは、標準的な挙動になっても良い気がします。

前回の申請がリジェクトされたため、再申請いたしました。 細かい点の修正だけだったので、機能的には前回お知らせした内容のままです。

またもう数日お待たせする事になってしまい、申し訳ありません。

久々にRailsモードが続いています。 APIを眺めていたら便利そうな機能を見つけたので紹介します。

layouts/application.html.erbの中などで、

   1  <%= javascript_include_tag :defaults %>

のように書く事があると思いますが、この:defaults というシンボルを指定することで、あらかじめ登録されている expansionが展開されてincludeされます。 この:defaultsのようなものを自分で登録したい場合、

   1  ActionView::Helpers::AssetTagHelper.register_javascript_expansion :foo => ["bar", "baz"]

のようにconfig/initializers/*あたりで登録しておけばOKです。 呼び出す時は

   1  <%= javascript_include_tag :foo %>

でOK。プラグインを作るとき等に、複数のjsフィアルをまとめてincludeできるようにしておくと便利ですね。

スタイルシートの場合は、register_stylesheet_expansionという同様のメソッドを使います。

昨日の時点でTwitterでは話題になっていましたが、 正式にRails-2.3.2のリリースがアナウンスされたようです。

Rails 2.3: Templates, Engines, Rack, Metal, much more!

Rails 2.3 is finally done and out the door. This is one of the most substantial upgrades to Rails in a very long time.

今回のリリースの主な特徴は、

• Templates: 自分好みのRailsアプリケーションのひな形を作る機能。 沢山Railsアプリを作ってる人には便利そう。
• Engines: Railsアプリをコンポーネント化して再利用する仕組み。MerbのSliceのような印象。render_componentが無くなったので、代わりにこれを使うと良いらしい。
• Rack: Rackに対応。
• Metal: 色々と省略して高速なレスポンスを実現する仕組み。
• Nested forms: 頭痛への処方箋。かなり嬉しい。

全体的な印象として、Merb-1.1との差が少なくなってきた感じですね。 Rails-3(あるいはMerb-2)への道筋が見えてきた気がします。

See Also

• Rails-2.3を手っ取り早く理解するための７つのサイト