ククログ

モーショノロジー2012 #1: rroongaによる検索サービスの実装

注意: 長いです。

簡単まとめ: 検索サービスを作るにはrroongaが便利です。groongaサポートサービスをはじめます。

CROOZ株式会社が主催する「モーショノロジー2012 #1 全文検索&検索を利用したサービスの使命、利用プロダクト、事例紹介」が開催されました。今回のテーマは検索ということでgroonga開発チームに声をかけてもらいました。groonga関連の枠がいくつかあったのですが、ここではRubyとgroongaを使った検索サービスの作り方についての枠の内容を紹介します。

以下、多少省略しながらスライドの内容を紹介します。

概要

紹介する内容はrroongaを使った場合のメリット・デメリットと入力補完についてです。メリットは事例も交えながら紹介します。入力補完は「Ruby + groongaだからできる」という機能ではなくgroonga単体でも利用できる機能なのですが、最近の検索サービスでは当たり前になっている大事な機能なので、あわせて紹介します。

rroonga?

Rubyとgroongaを一緒に使う方法には以下の2つの方法があります。

• groongaサーバーを起動し、HTTPで通信してgroongaの機能を使う方法
• groongaをライブラリとして使用し、API経由でgroongaの機能を使う方法

全文検索システムはgroonga以外にもたくさんありますが、その中にSolrという全文検索システムがあります。Solrは全文検索エンジンとしてLuceneを利用したシステムです。groongaはLuceneと同じ全文検索エンジン機能もSolrと同じサーバー機能も備えています。groongaサーバーを起動する使い方はSolrのように使う使い方で、ライブラリとして使う使い方はLuceneのように使う使い方になります。

今回は後者のgroongaをライブラリとして使用する方法でのメリット・デメリットを事例を交えながら紹介します。

Rubyからgroongaをライブラリとして使うためにはrroongaというRubyのライブラリを使います。この方法ではアプリケーションがデータベースを持つことになります。

システム構成

groongaをライブラリとして使う方法ではアプリケーションサーバーがデータベースを持つことになります。これは、よくあるアプリケーションサーバーとデータベースサーバーが分離している構成とは異なります。このあたりがメリット・デメリットにつながってきます。

メリット

groongaをライブラリとして使う場合、以下のようなメリットがあります。

• 通信コストがないため、小さいコストで細かくデータを読み書きできる
• 低レベルのAPIから高レベルのAPIまで使えるため柔軟に演算を組み合わせた検索ができる

小さいコストで細かいデータの読み書きができるメリットを活かした例は後で紹介します。まずは、柔軟に演算を組み合わせられるメリットを活かした例を紹介します。

組み合わせ例: 多段ドリルダウン

組み合わせの例の1つが「多段ドリルダウン」です*1。「ドリルダウン」は「ファセット」と呼ばれることの方が多いのですが*2、ECサイトなどでよく使われている機能です。

amazon.co.jpなどで絞り込める条件がリンクになっているインターフェイスを見たことがないでしょうか。あれがドリルダウン（ファセット）です。

このスクリーンショットは「本」で検索した状態です。「本」カテゴリーのうち、さらに絞り込める項目（「コンピュータ・IT」、「ビジネス・経済」など）がリンクとしてリストされています。ここをクリックすると検索語などを入力せずに簡単に絞り込んでいくことができます。

また、各項目の横に「(5,248)」などヒット件数も表示されていることに気づいたでしょうか。これは「コンピュータ・IT」、「ビジネス・経済」などサブカテゴリーで絞り込んだ結果ヒットする件数を示しています。事前に検索システム側で検索して、0件ヒットする項目はそもそもこのリストに入らないようになっています。そのため、「絞り込んだけど0件ヒット」という無駄な検索を避けることができます。

このような点でより効率的に検索できるような機能なので、より広く使われるようになりました。

さて、多段ドリルダウンはどう違うかというと最終的な検索結果を求める途中でもドリルダウンをするという点が違います。

高レベルな検索機能しかない場合は、多段ドリルダウンを実現するために「全データ→途中結果」までの検索と「全データ→最終結果」までの検索を2回実施し、それぞれの検索結果に対してドリルダウンする必要があります。これは、高レベルな検索機能では検索の途中結果を保存しておいて再利用するような機能がないためです。

低レベルな検索機能も使えると「全データ→途中結果→ドリルダウン」をしてから「途中結果→最終結果→ドリルダウン」というように効率のよい処理を実現できます。

では、多段ドリルダウンが有用なケースはどのようなケースでしょうか。

多段ドリルダウンは、絞り込み後に値を変更することが多い条件に有用です。amazon.co.jpのカテゴリーの例でいえば『「コンピュータ・IT」で絞り込んだ後に、やっぱり「ビジネス・経済」に変更しよう』ということが多いかどうかということになります。多段ドリルダウンを実施しておけば「絞り込み→解除→再絞り込み」という操作ではなく「絞り込み→再絞り込み」という操作を実現でき、少ない手順で検索できます。

例えば、「価格帯」が再絞り込みをしたくなるような条件です。最初は安めの価格帯で絞り込んでいたけど、よいのがなかったからもう少し高めのものも見てみよう、ということはよくありますよね。

デメリット

デメリットはスケールアウトする標準的な仕組みがないことです。そのため、レプリケーションの仕組みを自分で作り込む必要があります。

開発事例

Rubyとgroongaでテレビ番組を検索するWeb APIを開発しています。別のシステムから提供される番組情報をrroongaを使ってgroongaのデータベースへ取り込み、番組情報を検索するためのHTTP + JSONベースのWeb APIを提供するシステムです。このシステムが直接視聴者から利用されることはなく、番組検索APIを利用した連携アプリケーションがユーザー用のインターフェイスを提供します。

このシステムは外部からの更新がないとてもシンプルな構成のため、番組情報ソースを各アプリケーションサーバーにコピーし、各サーバーでそのソースを元にデータベースを構築することで冗長化・スケールアウトを実現しています。

このAPIを利用したアプリケーションの1つがテレコ！です。地上波・BS放送・CS放送の番組をメディア横断で検索できるテレビ番組情報サービスです。ぜひ利用してみてください。

メタデータの抽出

番組検索Web APIではデータロードのときにもrroongaが活躍しています。その1つがメタデータの抽出処理です。

メタデータはドリルダウン条件として使えるため検索しやすいシステムを構築するためには重要な情報になります。番組情報の場合は出演者やカテゴリなどがメタデータとなります。メタデータは重要な情報なのですが、用意するにはそれなりの手間がかかるため、なかなか充実させることができません。そのため、ある程度機械的に抽出することで補うことが有効です。番組検索Web APIでは以下のようなコードで番組説明から出演者情報を抽出しています。

1
2
3
4
5
6
7
8
9
10
11

names = []
# 番組説明
description = "出演者: ビートたけし・所ジョージ"
# 人物テーブル
people = Groonga["People"]
# people.records -> ["ビートたけし", "明石家さんま"]
people.scan(description) do |record,|
  # 番組説明内に人物テーブル内の人物名があったら抽出
  names << record.key # "ビートたけし"
end
p names # -> ["ビートたけし"]

やっていることは「はてなダイアリーでのキーワード自動リンク」と同じことです。テキスト（番組説明）中から事前に用意した語（人物名）を抽出しています。なお、この処理のことを「multiple string matching」と呼ぶそうです。

これはgroongaの低レベルのAPIを使って実現します。ただ、この処理のときはデータベース内のデータを頻繁に参照することになるので、データロードするアプリケーションがデータベースを持っていないと時間がかかって実用的にはならないでしょう。

入力補完

最後に入力補完の実現方法について説明します。

groonga本体にはサジェスト機能があり、この機能は以下の機能を提供します。

• 補完: 一部分を入力するだけで完全な検索語を入力できるようにする機能（Googleの検索ボックスにもある機能）
• 補正: 検索語の一部が間違っていても修正して正しい検索語にする機能（Googleでいえば「もしかして」機能）
• 提案: 検索結果が多いときに絞り込み用の追加の検索語を提示する機能（Googleでいえば「他のキーワード」機能）
• ユーザーの入力から統計的に学習し↑の3つを強化する機能

このうち補完機能を使った入力補完の実現方法について説明します。

groongaの補完機能は補完候補そのものの字面（例えば「万葉集」が補完候補なら「万」など）でなくても、ローマ字やひらがな・カタカナで入力しても補完候補を提示できます。これはIMEがOFFの状態でも利用できて日本語を利用した検索システムではとても便利です。Googleでも同様のことをできますが、amazon.co.jpではできないようです。

補完方法には大きく分けて以下の2つの方法があります。

• コンテンツベースの方法
• 統計情報ベースの方法

コンテンツベースの方法ではすでにデータベース内にある既知の情報を補完候補とする方法です。番組検索Web APIの場合は番組名や人物名などが適切な補完候補になります。この方法ではデータベース内にある正しい補完候補のみを利用するので、間違った候補を出すことがないというメリットがあります。一方、候補数が少なくて思ったより補完してくれないということもありえます。例えば、「コナ」では「名探偵コナン」を補完してくれなくて「名探偵」と入力しないといけない、といったことがあります。

統計情報ベースの方法ではユーザーの検索履歴をアクセスログなどから収集・解析し、多くのユーザーが検索した語などを補完候補とします。この方法では「コナ」で「コナン」を補完候補とできる可能性があります。一方、ある程度の統計情報がないと適切な補完候補を抽出できなかったり、補完候補の精度が低くなってしまう可能性もあり、調整が必要になります。例えば、特定のキーワードをわざと多く検索してくるようなアクセスがあった場合はそのようなアクセスを無視するといったことが必要になるかもしれません。

まとめ

rroongaを使った検索システムの構成とその構成ならではのメリットとデメリットを紹介しました。メリットはメタデータの抽出などgroongaの低レベルのAPIも利用しながら検索システムを構築できることです。デメリットは標準的なレプリケーションの仕組みがないため冗長化やスケールアウトの仕組みを自作する必要があることです。

また、rroongaを使った検索システムの構成とは関係ないのですが、入力補完の実現方法についても紹介しました。

お知らせ

groongaの開発元である有限会社未来検索ブラジルとMySQLからgroongaを使うためのソフトウェアmroongaの開発に参加している斯波さんとクリアコードでgroongaのサポートサービスを提供することにしました。サポート開始は2/29の予定ですがすでにお問い合わせは受け付けていますので、groongaサポートサービスに興味のある方はぜひお問い合わせフォームからご連絡ください。

ツイートする

フォローする

デバッグしやすいHTMLのテストの書き方

注意: 長いです。

一言まとめ: withinとtest-unit-capybaraを使ってHTMLのテストを書くと問題を見つけやすくなる。あわせて読みたい: デバッグしやすいassert_equalの書き方

HTMLに対するテストに限らず、開発を進めていく中でテストが失敗する状況になることは日常的にあることです。HTMLの場合は、入力フォームのラベルを変更したり、項目を追加したら既存のテストが失敗するようになるでしょう。そのとき、どのようにテストを書いていれば原因を素早く見つけられるのかを説明します。ポイントは「注目しているノードを明示すること」です。

HTMLテストのライブラリ

さて、Rubyで処理結果のHTMLをテストするときにはどんなライブラリを使っていますか？The Ruby ToolboxにあるBrowser testingカテゴリを見てみると、Capybaraが最も使われていて、次にWebratが広く使われているようです。どちらも同様の機能が揃っているため、特別な使い方をしないならどちらを使っても困ることはないでしょう。もし、今から使いはじめるならCapybaraの方がよいでしょう。これは、Capybaraの方がより活発に開発されているためです。

ここでは、CapybaraでHTMLのテストを書いたときを例にして、どのようにテストを書けば失敗した時に原因をすぐに見つけられるようになるかを説明します。考え方は他のツールでも応用できますし、test-unitやRSpecなどのテスティングフレームワークにも依存しません。そのため、ここでは、もっともRubyらしく書けるテスティングフレームワークであるtest-unit 2を使います。

よくある書き方

まずは一般的なCapybaraでのHTMLのテストがどのように書けるのかを確認します。

まず、以下のようなRackアプリケーションがあるとします。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

class MyRackApplication
  def call(env)
    html = <<-HTML
<html>
  <head>
    <title>Welcome! - my site</title>
  </head>
  <body>
    <h1>Welcome!</h1>
    <div class="header">
      <p>No navigation.</p>
    </div>
  </body>
</html>
HTML
   [200, {"Content-Type" => "text/html"}, [html]]
  end
end

はじめにCapybaraでテストを書ける状態にします。include Capybara::DSLとCapybara.app=がポイントです。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

class MyRackApplication
  # ...
end

gem "test-unit"
require "test/unit"
require "capybara/dsl"

class TestMyRackApplication < Test::Unit::TestCase
  include Capybara::DSL

  def setup
    Capybara.app = MyRackApplication.new
  end
end

それでは、まずは期待した見出しが返ってきているかを確認してみましょう。

1
2
3
4
5
6
7

class TestMyRackApplication < Test::Unit::TestCase
  # ...
  def test_heading
    visit("/")
    assert_equal("Welcome!", find("h1").text)
  end
end

実行するとテストがパスするので正しい値が返ってきていることを確認できます。

% ruby test-capybara.rb
Loaded suite test-capybara
Started
.

Finished in 0.427469388 seconds.

1 tests, 1 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications
100% passed

2.34 tests/s, 2.34 assertions/s

ヘッダー部分も確認しましょう。テスト対象のHTMLの一部も再掲します。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

class MyRackApplication
  def call(env)
    html = <<-HTML
<html>
  <!-- ... -->
  <body>
    <h1>Welcome!</h1>
    <div class="header">
      <p>No navigation.</p>
    </div>
  </body>
</html>
HTML
   [200, {"Content-Type" => "text/html"}, [html]]
  end
end
# ...
class TestMyRackApplication < Test::Unit::TestCase
  # ...
  def test_header
    visit("/")
    assert_equal("No navigation.", find(".header p").text)
  end
end

これもパスします。

% ruby test-capybara.rb
Loaded suite test-capybara
Started
..

Finished in 0.419134417 seconds.

2 tests, 2 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications
100% passed

4.77 tests/s, 4.77 assertions/s

雰囲気はわかりましたね。

HTMLを変更

それでは、HTMLを少し変更してナビゲーション用のリンクをいれましょう。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

class MyRackApplication
  def call(env)
    html = <<-HTML
<html>
  <!-- ... -->
  <body>
    <h1>Welcome!</h1>
    <div class="header">
      <ul>
        <li><a href="/">Top</a></li>
      </ul>
    </div>
  </body>
</html>
HTML
   [200, {"Content-Type" => "text/html"}, [html]]
  end
end

HTMLの構造が変わったのでテストは失敗します。

% ruby test-capybara.rb
Loaded suite test-capybara
Started
E
===============================================================================
Error:
test_header(TestMyRackApplication):
Capybara::ElementNotFound: Unable to find css ".header p"
    /var/lib/gems/1.9.1/gems/capybara-1.1.2/lib/capybara/node/finders.rb:154:in `raise_find_error'
    /var/lib/gems/1.9.1/gems/capybara-1.1.2/lib/capybara/node/finders.rb:27:in `block in find'
    /var/lib/gems/1.9.1/gems/capybara-1.1.2/lib/capybara/node/base.rb:46:in `wait_until'
    /var/lib/gems/1.9.1/gems/capybara-1.1.2/lib/capybara/node/finders.rb:27:in `find'
    (eval):2:in `find'
    /var/lib/gems/1.9.1/gems/capybara-1.1.2/lib/capybara/dsl.rb:161:in `find'
    test-capybara.rb:40:in `test_header'
===============================================================================
.

Finished in 0.431328598 seconds.

2 tests, 1 assertions, 0 failures, 1 errors, 0 pendings, 0 omissions, 0 notifications
50% passed

4.64 tests/s, 2.32 assertions/s

さて、ここでどうしますか？よく使われる方法は以下のような方法ではないでしょうか。

• puts sourceを埋め込んでHTMLを確認する。
• assert_equalのメッセージにsourceを指定する。
• save_and_open_browserでブラウザで確認する。

それでは、それぞれの方法についてみていきましょう。

puts sourceを埋め込む

include Capybara::DSLするとsourceメソッドが追加され、アプリケーションが返した生のHTMLを確認することができます。

1
2
3
4
5
6
7
8

class TestMyRackApplication < Test::Unit::TestCase
  # ...
  def test_header
    visit("/")
    puts source
    assert_equal("No navigation.", find(".header p").text)
  end
end

テストを実行するとHTMLが出力されます。

% ruby test-capybara.rb
Loaded suite test-capybara
Started
<html>
  <head>
    <title>Welcome! - my site</title>
  </head>
  <body>
    <h1>Welcome!</h1>
    <div class="header">
      <ul>
        <li><a href="/">Top</a></li>
      </ul>
    </div>
  </body>
</html>
E
===============================================================================
Error:
test_header(TestMyRackApplication):
Capybara::ElementNotFound: Unable to find css ".header p"
...

出力されたHTMLと「Unable to find css ".header p"」というエラーメッセージと目CSSセレクタを活用して、どうしてCSSセレクタ".header p"がマッチしなくなったのかを考えます。

この方法はテスト自体を書き換える必要があるため、テストが失敗したらテストを修正してもう一度実行し直さなければいけません。テストがパスするようになったら変更を元に戻すことも忘れてはいけません。

assert_equalのメッセージにsourceを指定

assert_equalに限らずアサーションには失敗時に表示する追加のメッセージを指定できます。この方法では、失敗したときのみHTMLが表示されるため「失敗したときだけテストを変更する」といったことをする必要はありません。

1
2
3
4
5
6
7

class TestMyRackApplication < Test::Unit::TestCase
  # ...
  def test_header
    visit("/")
    assert_equal("No navigation.", find(".header p").text, source)
  end
end

実行してみます。

% ruby test-capybara.rb
Loaded suite test-capybara
Started
E
===============================================================================
Error:
test_header(TestMyRackApplication):
Capybara::ElementNotFound: Unable to find css ".header p"
    /var/lib/gems/1.9.1/gems/capybara-1.1.2/lib/capybara/node/finders.rb:154:in `raise_find_error'
    ...
===============================================================================
...

おや、エラーメッセージの中にHTMLが出力されていませんね。もう一度assert_equalを確認してみましょう。

1

assert_equal("No navigation.", find(".header p").text, source)

問題なさそうに見えますが、どうして出力されていないのでしょうか。

それは、assert_equalが呼び出される前にfindの中で例外が発生しているからです。Capybaraでは要素が見つけられなかったときはCapybara::ElementNotFound例外を投げるのでassert_equalは呼び出されなかったのです。

これを回避するためには以下のようにfindではなくhas_selector?で事前にCSSセレクタがマッチするかを確認する必要があります。

1
2
3
4
5
6
7
8

class TestMyRackApplication < Test::Unit::TestCase
  # ...
  def test_header
    visit("/")
    assert_true(has_selector?(".header p"), source)
    assert_equal("No navigation.", find(".header p").text)
  end
end

これを実行するとHTMLが出力されます。

% ruby test-capybara.rb
Loaded suite test-capybara
Started
F
===============================================================================
Failure:
test_header(TestMyRackApplication) [test-capybara.rb:40]:
<html>
  <head>
    <title>Welcome! - my site</title>
  </head>
  <body>
    <h1>Welcome!</h1>
    <div class="header">
      <ul>
        <li><a href="/">Top</a></li>
      </ul>
    </div>
  </body>
</html>
.
<true> expected but was
<false>
===============================================================================
...

しかし、今度は指定したCSSセレクタが出力されません。

そもそも、findする前に事前に存在を確認するようなテストの書き方になってしまうのでは、せっかくのCapybaraのすっきりした記法を活かせていないと言えるでしょう。

ちなみに、RSpecでは以下のように書くことになります。こちらもHTMLとCSSセレクタを同時に出力してくれないのであまりうれしくありません。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

require "capybara/rspec"

class MyRackApplication
  def call(env)
    html = <<-HTML
<html>
  <head>
    <title>Welcome! - my site</title>
  </head>
  <body>
    <h1>Welcome!</h1>
    <div class="header">
      <ul>
        <li><a href="/">Top</a></li>
      </ul>
    </div>
  </body>
</html>
HTML
   [200, {"Content-Type" => "text/html"}, [html]]
  end
end

Capybara.app = MyRackApplication.new

describe MyRackApplication, :type => :request do
  it "should have header content" do
    visit("/")
    page.should have_selector(".header p")
    find(".header p").text.should == "No navigation."
  end
end

実行すると以下のようにCSSセレクタのみが出力されます。

% rspec capybara_spec.rb
F

Failures:

  1) MyRackApplication should have header content
     Failure/Error: page.should have_selector(".header p")
       expected css ".header p" to return something
     # ./capybara_spec.rb:29:in `block (2 levels) in <top (required)>'

Finished in 0.60582 seconds
1 example, 1 failure

Failed examples:

rspec ./capybara_spec.rb:27 # MyRackApplication should have header content

ということで、この方法は「失敗したときだけ必要な情報を出力して原因を素早く見つけたい」という期待する結果を実現できません。メッセージの中にsourceとCSSセレクタを指定すれば実現できなくもありませんが、テストが書きづらくなってしまうため割にあいません。

save_and_open_browserでブラウザで確認

include Capybara::DSLするとsave_and_open_browserメソッドが追加され、アプリケーションが返した生のHTMLをブラウザで開いて確認することができます*1。

1
2
3
4
5
6
7
8

class TestMyRackApplication < Test::Unit::TestCase
  # ...
  def test_header
    visit("/")
    save_and_open_page
    assert_equal("No navigation.", find(".header p").text)
  end
end

ブラウザでHTMLを確認することによりFirebugなどHTMLの構造を視覚的に確認することができます。確認してどうしてCSSセレクタ".header p"がマッチしなくなったのかを考えます。

この方法もテスト自体を書き換える必要があるため、テストが失敗したらテストを修正してもう一度実行し直さなければいけません。テストがパスするようになったら変更を元に戻すことも忘れてはいけません。元に戻さないままコミットしてしまうと、他の開発者の環境でもテストを実行するたびにブラウザが起動してしまいます。

どの方法がよいか

ブラウザで確認する方法が視覚的で一番わかりやすいですが、ページの内容が増えてくるとページ全体から問題の箇所を素早く探すのは大変です。一方、コンソールにHTMLを出力する方法は視覚的ではありませんが、HTMLをテキストとして検索することができるところは便利です。しかし、やはりページ全体から問題の箇所を素早く探すのは大変です。

小規模のWebアプリケーションでもそこそこのHTMLになり、どの方法でもページ全体から問題の箇所を素早く探すのは大変です。ということで、どの方法も今一歩と言えます。

ページ全体ではなくする

どうして問題の箇所を素早く探すのが大変かというと、探索範囲が広いからです。探索範囲が狭くなれば素早く見つけやすくなります。ついでに言うと、テストの書きやすさを損なわずにできるだけ自然に狭くしたいという希望もあります。

ところで、Capybaraにはwithinというメソッドがあることを知っていますか？これを使うと検索範囲を限定できます。例えば、以下は同じ意味になります。

1
2
3
4
5
6

# これまでの書き方
find(".header p").text
# withinを使った書き方
within(".header") do
  find("p").text
end

withinを使ってテストを書きなおしてみましょう。

1
2
3
4
5
6
7
8
9

class TestMyRackApplication < Test::Unit::TestCase
  # ...
  def test_header
    visit("/")
    within(".header") do
      assert_equal("No navigation.", find("p").text)
    end
  end
end

テストを実行するとfindのところで失敗するのですが、この時点では".header"はマッチすることがわかっています。つまり、findはHTML全体ではなく、以下のHTML断片内で"p"がマッチすることを期待しています。

1
2
3
4
5

<div class="header">
  <ul>
    <li><a href="/">Top</a></li>
  </ul>
</div>

このくらいの量であればコンソールに出力されても解析しやすいでしょう。少なくとも「<p>はないが<ul>はある」ということはすぐにわかります。このヒントがあれば原因を特定するのにだいぶ役立つはずです。

では、withinのブロック内でマッチしなかった場合に現在マッチしたノードのHTMLを出力するにはどうしたらよいでしょうか。これを実現できると、失敗した時だけ必要最低限の情報を得られて素早く原因を見つけられそうです。しかもCapybaraの自然な使い方です。

test-unit-capybara

test-unit 2でCapybaraを便利に使うためのtest-unit-capybaraというライブラリがあります。これを使えば、これまで通りCapybaraの作法で書くだけで必要な情報を過不足なく表示してくれます。以下のようにrequire "test/unit/capybara"とするだけでtest-unit-capybaraを使えます。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

gem "test-unit"
require "test/unit/capybara"
# require "test/unit"
# require "capybara/dsl"
# ...
class TestMyRackApplication < Test::Unit::TestCase
  include Capybara::DSL

  def setup
    Capybara.app = MyRackApplication.new
  end

  # ...

  def test_header
    visit("/")
    within(".header") do
      assert_equal("No navigation.", find("p").text)
    end
  end
end

実行すると以下のようになります。

% ruby test-capybara.rb
Loaded suite test-capybara
Started
F
===============================================================================
Failure:
test_header(TestMyRackApplication)
    [/var/lib/gems/1.9.1/gems/test-unit-capybara-1.0.1/lib/test/unit/capybara.rb:77:in `raise_find_error_for_test_unit'
...
     test-capybara.rb:40:in `test_header']:
<"p">(:css) expected to find a element in
<<div class="header">
      <ul>
<li><a href="/">Top</a></li>
      </ul>
</div>>
===============================================================================
...

探索範囲であるHTML断片<div class="header">...</div>とCSSセレクタ"p"が表示されています。これがわかれば素早く原因を見つけられますね。

最近のCapybaraはfindメソッドでノードを見つけられなかったときの挙動をカスタマイズできます*2。test-unit-capybaraはその機能を使って必要な情報を収集して表示しています。同様のことは他のテスティングフレームワークでも実現できるでしょう。

まとめ

現状のテストの書き方・ツールではHTMLに対するテストが失敗したときの原因を素早く見つけることが困難であることを示しました。また、解決方法としてwithinを使って「注目しているノードを明示」し、テストツールとしてtest-unit-capybaraを使う方法を紹介しました。この方法は他のテスティングフレームワークでも実現できる一般的な方法です。

インターフェイスの改良や文言の変更などでHTMLのテストが失敗することはよくあることです。そんなときもすぐにどこが変わったかに気付けるようなテストだと変更を嫌がらずによいものを作ることに専念できますよね

あわせて読みたい: デバッグしやすいassert_equalの書き方

おまけ: assert_match問題

ここで取り上げた問題は「問題があるだろう範囲が広すぎて問題を発見することが困難になる」ことが原因です。同様の問題はtest-unitのassert_match、RSpecのshould matchにもあります。

以下はUser-Agentが任意のバージョンのbingbotであることをテストしています。このテストは失敗するのですが、どうして失敗するかすぐにわかるでしょうか？

1
2
3
4
5
6
7

def assert_bingbot(user_agent)
  assert_match(/;\s+bingbot\/[\d]+;/, user_agent)
end

def test_bot
  assert_bingbot("Mozilla/5.0 (compatible; bingbot/2.0; +http://www.bing.com/bingbot.htm)")
end

正規表現は少し間違えて書いてしまうとどこが間違えているのか見つけることが大変です。これを防ぐために、assert_matchではなく、以下のようにマッチ対象を正規化してからassert_equalで比較することをオススメします。

1
2
3
4
5
6
7
8

def assert_bingbot(user_agent)
  assert_equal("Mozilla/5.0 (compatible; bingbot/XXX; +http://www.bing.com/bingbot.htm)",
               user_agent.gsub(/bingbot\/[\d]+/, "bingbot/XXX"))
end

def test_bot
  assert_bingbot("Mozilla/5.0 (compatible; bingbot/2.0; +http://www.bing.com/bingbot.htm)")
end

assert_equalだと以下のようにdiffがでるので何が悪かったのかがすぐにわかります。

===============================================================================
Failure:
test_bot(TestMyRackApplication)
    [test-capybara.rb:50:in `assert_bingbot'
     test-capybara.rb:55:in `test_bot']:
<"Mozilla/5.0 (compatible; bingbot/XXX; +http://www.bing.com/bingbot.htm)"> expected but was
<"Mozilla/5.0 (compatible; bingbot/XXX.0; +http://www.bing.com/bingbot.htm)">

diff:
? Mozilla/5.0 (compatible; bingbot/XXX.0; +http://www.bing.com/bingbot.htm)
===============================================================================

バージョン番号を検出しようとしていた[\d]+が「.」を考慮していないことが原因ですね。

ツイートする

フォローする

Ruby関連のコンテストっぽいものへの応募例

Rubyに関する取り組みは無理のない範囲で応援しています。コンテストっぽいものもそのうちの1つで、ちょうど募集している時期にそれっぽいものがあれば応募しています*1。これは、応募者が少しでも増えると、次回の開催時には少しは盛り上がるのではないかという期待からです。「応募したくなる人が増えるには」という方向で考えた応援の仕方です。

逆に、応募する敷居を下げる方法もあるでしょう。その1つに「どのように応募すればよいかのヒントを提供する」ことがあるのではないでしょうか*2。ということで、Rubyアソシエーション：2011年度助成金公募への応募内容と第３回フクオカRuby大賞への応募内容を紹介します。Rubyアソシエーションの方は落ちた応募で、第３回フクオカRuby大賞は受かった応募なので参考にするときは注意してください。なお、どちらも現在（2011-12-12）は募集していませんので、気になった方は次回の募集時に応募してみてください。

Rubyアソシエーションの2011年度助成金への応募内容

目的が似ていそうな原さんの世界の誰でも読めるRubyリファレンスマニュアル(に向けて)が採択されています。その観点から、「この応募内容では何が足りないのか」を考えると参考にしやすいのではないでしょうか。なお、2011年12月18日(日) 13:00から秋葉原でRubyの次世代リファレンスマニュアルを構想する会あるそうなので、興味のある方は参加してみてはいかがでしょうか。

----
* 応募者名（個人名又は団体名）

株式会社クリアコード

* 担当者名

須藤功平

* 連絡先電子メールアドレス

kou@clear-code.com

* 略歴

  * 2006年7月25日: 設立
  * 2008年8月5日: 代表取締役を須藤に交代
  * 2009年6月: 日本Ruby会議2009にスポンサー・発表者として参加
  * 2009年10月: とちぎRuby会議02にスポンサー・発表者として参加
  * 2009年12月: 札幌Ruby会議02にスポンサー・発表者として参加
  * 2010年8月: 日本Ruby会議2010にスポンサー・発表者として参加
  * 2011年3月: 第3回フクオカRuby大賞でコミュニティ特別賞を受賞
  * 2011年6月: 本社移転
  * 2011年6月: 日本Ruby会議2011にスポンサー・発表者として参加

* プロジェクト名

Ruby用ドキュメントツールの国際化対応

* プロジェクトの詳細

以前のRubyは他のプログラミング言語と比較してドキュメントが弱
いと言われていたが、最近ではるりまプロジェクト(*1)や"Ruby
1.9.3 Documentation Challenge"(*2)などによりRubyのドキュメン
トが改善されている。

(*1) http://redmine.ruby-lang.org/projects/rurema/wiki
(*2) http://blog.segment7.net/2011/05/09/ruby-1-9-3-documentation-challenge

しかし、上記の2つのプロジェクトはそれぞれ独立に動いており、片
方の成果をもう一方が取り込む、といったことが難しい状況となっ
ている。ドキュメントを改善する作業はあまり人々の関心を得られ
ず、慢性的にリソースが足りない状況である。それにも関わらず
リソースが分散してしまっており、日本語のRubyのドキュメントも
英語のRubyのドキュメントもRuby全体を網羅したものにはなってい
ないのが現状である。

このような状態になってしまっているのは、ドキュメントツールが
国際化に対応していないことが問題であると考える。そこで、この
プロジェクトではRuby用のドキュメントツールであるYARD(*3)に国
際化機能を実装し、貴重なドキュメント改善作業のリソースを分散
せずに協力して作業できる仕組みを提供する。

(*3) http://yardoc.org/

なお、すでにこの作業は開始しており、YARDのメーリングリストで
国際化対応について議論を行なった(*4)。国際化対応作業の方向に
ついてYARDの作者から合意を得ており、実際にいくつかの機能は実
装済み(*5)である。これより、以下のことが言えるため本プロジェ
クトの実現可能性は高いと考える。

  * YARD開発チームとの関係が良好である
  * すでに方向性が決まっている
  * すでに動き出している

(*4) http://groups.google.com/group/yardoc/browse_thread/thread/9aecb2fe3c6c9d5
(*5) https://github.com/kou/yard

Ruby標準添付のRDocではなくYARDに対して国際化対応を行う理由は
以下のとおりである。

  * 国際化機能を実装するにあたり、RDocでは他のライブラリを利
    用しづらいため。
    （他のライブラリもRubyに標準添付しなければいけないため。）
  * YARDはRDocの上位互換であり、RDocで書かれたドキュメントも
    YARDで扱えるので、YARDの方が国際化機能を適用できる範囲が
    広いため。
  * YARDの方が拡張を意識した作りとなっており、実装しやすいた
    め。

YARDを国際化対応した結果、使い勝手がよく継続的に利用できるも
のであると判断できた場合はRDocへのポーティングも検討すること
を考えているが、本プロジェクトの範囲とはしない。

* プロジェクトの成果物

以下を成果物とする。

  * 国際化機能付きのYARD
  * 国際化されたYARDのドキュメント（日本語のドキュメント）

ただし、YARDのリリースはYARDの開発者が行うため、期間内に上記
のYARDがリリースされるとは限らない。

実装した国際化機能を用いて実際にYARD自体のドキュメントを国際
化する。これにより国際化機能が利用しやすいか・継続可能な仕組
みになっているかを評価する。Ruby本体や多くのライブラリは、一
度作ったら完成するものではなく、日々改良が続けられていくもの
である。そのため、ドキュメントも一度作成したら完成ではなく、
改良に追従していく必要がある。国際化機能そのものも重要である
が、ドキュメントの改良が無理なく続けられる仕組みであることも
重要であるため、その観点でも評価する。
----

第３回フクオカRuby大賞への応募内容

第３回フクオカRuby大賞は予備審査と本審査があり、予備審査は応募内容を使って審査するそうです。この応募内容で予備審査を通過しました。1年ほど前のものなので内容が古くなっていたりしますね。

----
○ 応募日

平成22年11月13日

○ ソフトウェア、取組等の名称

るりまサーチ

○ 応募者区分

法人・団体として応募

○ 応募者

○○ 応募者名

須藤功平

○○ 応募者名ふりがな

すとうこうへい

○○ 法人・団体 代表者名

須藤功平

○○ 法人・団体 代表者役職

代表取締役

○ 所在地

○○ ＜都道府県＞

東京都

○○ ＜市区町村名、番地＞

文京区本郷1-25-4

○○ ＜ビル名等＞

ベルスクエア本郷5F

○ URL

http://www.clear-code.com/

○ 連絡担当者

○○ 担当者　氏名

須藤功平

○○ 担当者　氏名ふりがな

すとうこうへい

○○ 担当者　所属部署

所属なし

○○ 担当者　役職

代表取締役

○○ 連絡先TEL

03-6231-7270

○○ 連絡先FAX

03-6231-7271

○○ 連絡先e-mail

kou@clear-code.com

○ 1.ソフトウェア、取組等の概要について

○○ （機能・特徴を簡潔に説明してください。）

るりまサーチはRuby本体のリファレンスマニュアルを高速に検索す
るWebアプリケーションです。説明文などテキスト情報から全文検索
して目的のマニュアルを検索する機能はもちろん、マニュアルの記
述対象の種類（クラスについて記述している、インスタンスメソッ
ドについて記述しているなど）など付加的な情報からも絞り込んで
いける機能を提供しています。この多角的に絞り込んでいく機能に
より、少ない労力で目的のマニュアルを見つけ出せることが特徴で
す。

○○ （ソフトウェア、取組等について、参考となるURLを記載してください。）

URL: http://rurema.clear-code.com/

○ 2.ソフトウェア、取組等の目的、ねらいについて

○○ （開発の目的や取組の動機、ターゲット等を記述してください。）

開発の目的:

目的は「Rubyのドキュメントが十分実用的であると評価されるよう
にすること」です。開発に用いる言語を選択する場合の指標のひと
つにドキュメントの充実度が挙げられることがよくあります。その
時、PHPやPythonなどは充実しているが、Rubyはそれほどでもない、
と評価されます。これは、せっかく充実してきたリファレンスマニュ
アルを十分に活用するためのインターフェイスがないことが原因だ
と考えています。

従来のリファレンスマニュアル閲覧Webアプリケーションにも検索機
能がありましたが、全文検索に数十秒かかる、全文検索以外の検索
方法がない、などの理由により、せっかく充実してきたリファレン
スマニュアルを十分に活用することができませんでした。るりまサー
チを開発することにより、検索機能を充実させ、リファレンスマニュ
アルを活用できる環境を提供することで目的の達成に近づくと考え
ています。

ターゲット: Rubyを用いて開発している開発者すべて

○ 3.Rubyを用いた理由、またはRubyに注目した理由について

Ruby本体のリファレンスマニュアルを検索するシステムにはRubyを
用いることが必然だからです。

○ 4.ソフトウェア、取組等の特徴について

○○ 1)優位性、セールスポイントについて、具体的に記載してください。

まず高速であることです。すぐに結果が返ってこないと格段に使い
勝手が悪くなります。処理に何秒もかかった上に「0件ヒット」と
なるようなシステムは使われなくなります。

次にリンクを辿るだけで絞り込んでいけることです。

キーワードがわかっている場合はそのキーワードを入力するだけで
目的のマニュアルをすぐに見つけることができますが、そうでない
場合の方がほとんどです。その場合は絞り込み条件を増やすことに
より、検索結果を絞り込んでいき目的のマニュアルを見つけていき
ます。この操作を簡単にできる仕組みを提供しています。

検索結果内にあらかじめ絞り込み条件をリンクとして挿入しておき
ます。例えば、エンコーディング関連を調べているとします。まず
「enc」というキーワードで絞り込みます。

  http://rurema.clear-code.com/query:enc/

このとき、ページ左のサイドバーには「インスタンスメソッド」や
「定数」など、種類での絞り込み条件を表示します。リンクの右側
に表示されている「（...）」は絞り込み後のヒット数です。アプリ
ケーション側は絞り込みリクエストを受け取る前にすでにヒット数
を知っているので、絞り込み後にヒット数が0になる条件はここに表
示しません。つまり、「絞り込んだ後にヒット数が0になる」という
無駄な操作をユーザがしなくても済むようになっています。

また、ページ本体の検索結果表示部分にも「Rubyのバージョンによ
る絞り込みリンク」、「インスタンスメソッドなどの種類」、「所
属するクラスなど関連する付加情報」などによる絞り込みリンク表
示しています。これにより、リンクを辿るだけでどんどん絞り込ん
でいけるため、少ない労力で目的のマニュアルを見つけることがで
きます。

上記のように高速である、リンクを辿るだけで絞り込んでいけると
いう機能が優位性、セールスポイントになります。

○○ 2)新規性、革新性について、具体的に記載してください。

上記の優位性、セールスポイントは先進的なECサイトや情報提供サ
イトではすでに導入されています。（例えば、amazon.co.jpやぐる
なびなどでも導入されています。）このような機能は今後の検索シ
ステムでは標準的な機能になっていくと考えています。

るりまサーチはそのような先進的な検索機能をRubyで実現できるこ
とを示した、実際に動くオープンソースソフトウェアであることに
新規性があります。先進的なECサイトなどの実装がオープンソース
ソフトウェアとして公開されることはないため、同様の機能を実現
するためには1から自分で調べる必要があります。しかし、るりま
サーチはオープンソースソフトウェアとして公開されているため、
どのように機能を実現しているかを参考にしたり、改変して利用す
ることなどができます。

○○ 3)社会的効果、インパクトについて、具体的に記載してください。

上述の内容と重複しますが、以下の2点が社会的効果となります。

  * Rubyのドキュメント環境が改善されることによりRubyの普及に
    つながる。
  * オープンソースソフトウェアとして公開されているため、同様
    の検索機能を実装する場合に有用である。

○ 5.ソフトウェア、取組等の実績について

○○ （具体的な実績、市場等からの評価があれば記載してください。）

Rubyのリファレンスマニュアルの公式検索サービスに採用されまし
た。（現在はメンテナンス中のようです。）

  http://doc.ruby-lang.org/ja/search/

るりまサーチをもっと便利に利用するためのソフトウェアを開発し
てくれた方がいました。

  http://codnote.net/2010/09/20/rurema-instant/
  https://github.com/sorah/rurema_instant

○ 6.今後の展開について

○○ （今後の目標や事業展開について記載してください。）

るりまサーチはRubyのリファレンスマニュアルを便利に検索する機
能を提供するという目的の他に、バックエンドで利用している全文
検索エンジンgroonga(*)のデモという目的もあります。

(*) groonga: http://gronoga.org/

クリアコードではgroongaを利用した検索システムの開発・開発支援
も行っています。groongaを利用した場合にどのような検索システム
を作ることができるか、ということを実際に動くるりまサーチとい
うアプリケーションでデモできます。

るりまサーチ自体はこれまで通り、groongaの機能を活かした使い
やすい機能を追加していきます。るりまサーチはデモとして使い、
新しい開発案件などにつなげていきます。るりまサーチ自体は今後
もオープンソースソフトウェアのままです。

○ 7.添付資料について（添付資料は返却しません。）

○○ （概要説明図やこれまでの発表資料、新聞・雑誌の記事等）

るりまサーチ: Rubyでgroonga使ってリファレンスマニュアルを全
文検索 - ククログ(2010-04-27):
  http://www.clear-code.com/blog/2010/4/27.html

日本Ruby会議2010発表資料: るりまサーチの作り方 - Ruby 1.9で
groonga使って全文検索 - ククログ(2010-09-01):
  http://www.clear-code.com/blog/2010/9/1.html

○ 8.ソフトウェアの動作環境について（ソフトウェアのみ）

○○ （OS、ソフトウェア、ハードウェア構成等について記載してください。）

OS: Linux 64bit
    （rurema.clear-code.comではDebian GNU/Linux lenny 64bitを利用）
ソフトウェア:
  * Ruby 1.9.x
  * groonga
  * Rack
  * rroonga
  * racknga
ハードウェア構成:
  * CPU: 64bit対応のもの
  * メモリ: 512MB以上
----

まとめ

Rubyアソシエーション：2011年度助成金公募への応募内容（落選）と第３回フクオカRuby大賞への応募内容（書類審査通過）を紹介しました。このようなコンテストっぽいものに応募しようとしている人の参考になり、応募者が増えたら、紹介した甲斐があるというものです。

ツイートする

フォローする

いらないキャッシュを消すとRubyスクリプトが速くなる

いらないキャッシュを消すことでRubyスクリプトが倍速で動作するようになった話です。

先日、るりまサーチをRackspaceのクラウドサーバー（メモリ1GB）からさくらのVPS 512（メモリ512MB）に移行しました。理由はRackspaceのサーバーが遠くにあるのでレスポンスがもっさりするからです。最速検索がウリなのにこれでは遅いのでないかと誤解されてしまいます。さくらのVPSにしたら近くにあるためサクサクとレスポンスが返ってくるようになりました。しかも、リソース（主にメモリ量）はスケールダウンしているのにです。

るりまサーチはバックエンドの全文検索エンジンgroongaが高速に動作するのとそれほどアクセスがない（！）ため、CPUやI/Oがネックになることはありません。それよりも、ほとんどメモリを搭載していないマシンで動かしているため、ボトルネックになるとすればメモリです。実メモリ以上にメモリを使おうとしてスワップを使い始めると遅くなります。

るりまサーチに一番負荷がかかるのは1日1回のるりまデータの更新です。もう少し言うとBitClustでHTMLを生成する処理が一番負荷が高いのです。このとき、BitClustのHTML生成プロセスはCPUを100%使い*1、500MB程度のメモリを使用します*2。Rackspaceのときのように1GBのメモリが載っているサーバーであれば耐えられますが、さくらのVPS 512のように512MBしかメモリが載っていないサーバーでは致命的です。スワップを使いはじめてI/O待ちが多発し、システムの応答性が著しく悪化します。

ということで、BitClustがHTMLを生成するときのメモリ使用量を改善したのですが、そのときに2倍くらい高速に動作するようになりました。その高速化の方法を一言でいうと「いらないキャッシュを消す」です。具体的な変更点でいうとr4873（4行）とr4874（1行）です。

いらないキャッシュを消して高速化

キャッシュはメモリを通常より使って処理時間を短くする方法なので、キャッシュを消すことでメモリ使用量が減るのは納得できます。しかし、処理時間も短くなるのは意外ですよね。

なお、メモリ使用量と実行時間は以下のようになりました。Ruby 1.8.7の場合も1.9.3の場合もメモリ使用量は半分以下、実行時間はほぼ半分になっています。

メモリ使用量が減って速くなった場合はだいたいGCに関係していると相場が決まっています。では、こんなときはどうやって確認したらよいでしょうか。Ruby 1.9.2以降にはGC::Profilerという便利なモジュールが追加されているのでこれを使います。

GCがどんな感じで実行されているかを調べたい処理の前でGC::Profiler.enableをし、処理を実行した後にGC::Profiler.reportで結果を表示します。

1
2
3

GC::Profiler.enable
# ... GCについて調べたい処理 ...
GC::Profiler.report

GC::Profiler.reportは以下のようにGCの統計結果を表示してくれます。

GC 445 invokes.
Index    Invoke Time(sec)       Use Size(byte)     Total Size(byte)         Total Object                    GC Time(ms)
    1               0.092               964640              2257680                56442         0.00000000000000000000
...

まず、いらないキャッシュを消さない場合の結果を見てみましょう。

GC 341 invokes.
Index    Invoke Time(sec)       Use Size(byte)     Total Size(byte)         Total Object                    GC Time(ms)
    1               0.080               964600              2257680                56442         0.00000000000000000000
...
   27               0.348              1893800              4057280               101432         4.00100000000003230838
...
   50               0.764              3283520              7296560               182414         8.00100000000003674927
...
   73               1.588              6627960             13120720               328018        12.00099999999992839150
...
  106               3.720             11035000             23607480               590187        32.00199999999986744115
...
  124               5.532             19510200             42486920              1062173        56.00399999999972067144
...
  151               9.741             36667720             44008400              1100210        96.00600000000092393293
...
  187              16.541             50259800             62249800              1556245       128.00800000000123191057
...
  237              28.470             61845360             72409360              1810234       176.01100000000258205546
...
  328              53.351             63548120             80262160              2006554       148.00900000000183354132

オブジェクト数が増える毎にGCにかかる時間が増えています。

次に、いらないキャッシュを消した場合の結果を見てみましょう。

GC 445 invokes.
Index    Invoke Time(sec)       Use Size(byte)     Total Size(byte)         Total Object                    GC Time(ms)
    1               0.092               964640              2257680                56442         0.00000000000000000000
...
   27               0.376              1893800              4057280               101432         8.00099999999997990585
...
   50               0.824              3283520              7296560               182414        12.00100000000004030198
...
   73               1.644              6627400             13120720               328018        12.00099999999992839150
...
  106               3.928              6736400             13120720               328018        20.00100000000015754154
...
  256              14.061             10642920             23607480               590187        32.00199999999853162080
...
  302              18.561             18979640             42486920              1062173        52.00299999999913325155
...
  432              36.330             25030040             42486920              1062173        48.00300000000135014488

トータルのGC回数は増えていますが、オブジェクト数の最大値が増えていかないため、1回のGCにかかる時間が短くなっています。この差が全体の実行時間に効いてきているんですね。

まとめ

速くするためにやみくもにキャッシュしていると、生きているオブジェクト数が多くなるためにGC時間が長くなってしまい、逆に遅くなることがあります。キャッシュしたのに思ったより速くならなかった場合は必要なくなったキャッシュを持ち続けていないか確認し、いらないキャッシュを消すことを試してみましょう。ただし、ある程度のオブジェクト数をキャッシュしていない場合はあまり関係がないでしょう。

ツイートする

フォローする

ApacheとPhusion PassengerでデプロイしたWebアプリケーションが不調になる問題と解決

ApacheとPhusion PassengerでWebアプリケーションをデプロイしている際に、たまにシステムが不安定になることがありました。調査したところ、原因はレスポンスの取得が遅いクライアントであるということが分かりました。この問題を発見し、原因を特定し、Phusion Passengerを修正するまでについて、紹介します。

発見の経緯

るりまサーチではApacheとPhusion Passengerを使っているのですが、たまに動作が不安定になることがありました。その不安定の原因を調査することにしました。

原因の特定

調査した結果、遅いクライアントがるりまサーチに接続するのが不安定になるトリガーになっていることが分かりました。

以下に、詳しく説明します。

Phusion Passengerは、遅いクライアントが接続していると、他のリクエストの処理を行いません。その間に、他のクライアントからのリクエストが処理待ちとして大量に溜まります。そして遅いクライアントがレスポンスを受け取り終わると、Phusion Passengerは、一斉に溜まった処理待ちのリクエストを処理し始めるため、システムのリソースを急激に消費します。そして、システムが不安定になります。

解決の方法

この問題の原因を解決するためには、遅いクライアントのリクエストを処理している際にも、他のリクエストの処理ができればいいということになります。

遅いクライアントの時の状況を詳しく説明します。遅いクライアントがレスポンスを受け取るのを待っている間は、サーバー側ではレスポンスの作成の処理は既に完了しているということになります。それにも関わらず他のリクエストの処理を行わないのです。つまり、その間、サーバーは実質的には何も処理を行っていません！

この時間は、無駄な時間と言えます。

なので、この無駄な時間をなくすようにする必要があります。具体的には、Webアプリケーションからの作成されたレスポンスを一旦Phusion Passengerがバッファに保存し、次のリクエストの処理に移ります。遅いクライアントには、そこのバッファから、ゆっくりレスポンスを返せばいいのです。

実は、このような挙動はNginxとPhusion Passengerの構成でデプロイされた場合には実現されています。ですが、ApacheとPhusion Passengerの構成の場合にはそうでは無いのです。

情報の収集

解決の方法が分かったので調べたところ、Phusion Passengerのバグトラッキングシステムにこの問題はすでに登録されていました。

さらにそこには、この問題の解決方法が記載されていました。コメント#3の情報によるとソースコードを書き換えればいいということが分かりました。ソースコードを書き換えることで、Nginxと同じように、Apacheでもレスポンスをバッファに保存する挙動に変更できます。

実際に、るりまサーチで検証したところ、問題は解決されました。遅いクライアントが接続してきた際にも、処理が止まらず、別のリクエストを処理するようになりました。

Phusion Passengerの修正

問題は解決されましたが、この問題を解決するためには、ソースコードを書き換えなければいけません。端的に言って、これは不便です。上のバグレポート内に書いてあるように設定ファイルからレスポンスをバッファに保存するかどうかを切り替えられると便利です。

なので、設定できるようにPhusion Passengerを修正したパッチを作成しました。そしてそのパッチをPhusion Passengerに取り込んでもらうように依頼をしました。

(追記: Fri Nov 25 03:05:28 2011 JSTにPhusion Passengerに無事に取り込んでもらえました。使えるようになるのは、まだリリースされていませんが次のリリースバージョンである、3.0.10からの予定です)

(追記: November 28th, 2011にこの修正が取り込まれたPhusion Passengerの3.0.11がリリースされました（3.0.10はバグがあったためにスキップされました）。

この修正によって、レスポンスをバッファに保存するかどうかを次のように設定することができるようになります。

<VirtualHost *:80>
  ServerName www.yourhost.com
  DocumentRoot /somewhere/public
  PassengerBufferResponse on
  # PassengerBufferResponse off # レスポンスのバッファへの保存をしたくない場合。
  <Directory /somewhere/public>
    AllowOverride all
    Options -MultiViews
  </Directory>
</VirtualHost>

レスポンスをバッファに保存する副作用

遅いクライアント問題はレスポンスをバッファに保存することで解決できます。半面、レスポンスをバッファに保存すると、次の副作用が発生するので注意が必要です。

• レスポンスをストリーミングで返せない。
• レスポンスが非常に大きいとメモリを逼迫する。

どちらも、Phusion Passengerがレスポンスをメモリ上のバッファに一旦保存してからクライアントに返すようになるためです。

まとめ

ApacheとPhusion PassengerでデプロイされたWebアプリケーションが不安定になるという問題を調査し、Phusion Passengerを修正しました。

同じような問題に遭遇している場合には、ぜひ試してみてください。

ツイートする

フォローする

tDiaryのRDスタイルにCodeRayを使ったシンタックスハイライト機能を追加

タイトルにキーワードを埋め込んでみました。ククログはtDiaryのRDスタイルで書いています。コードを貼り付けることも多々あるため、シンタックスハイライトもできるようにしてあります。今まではGNU Source-highlightでシンタックスハイライトをしていたのですが、CodeRayでシンタックスハイライトをするように変更しました。

設定方法

~tdiary/clear-code-tdiary/にクリアコードのtDiary関連Subversionリポジトリをチェックアウトしているとします。この状態でtdiary.confに以下のように記述すると、RDスタイルでシンタックスハイライトできるようになります。

1
2
3

clear_code_tdiary_base = "/home/tdiary/clear-code-tdiary"
require "#{clear_code_tdiary_base}/patches/after-load-styles-hook"
require "#{clear_code_tdiary_base}/patches/rd-syntax-highlight"

事前にgemでCodeRayをインストールしておくことを忘れないでください。

使い方

以下のようにverbatimブロックに「# source: ruby（言語名）」というようなヘッダーを入れます。

tdiary.confの設定:（←ここはパラグラフ。）

  # source: ruby （←ここは表示されない。）
  @style = "RD" （←ここがRubyプログラムとしてシンタックスハイライトされる。）

乗り換え理由

GNU Source-highlightからCodeRayに乗り換えたのは以下の理由からです。

• Rubyのライブラリとして使える。
• Rabbitで使ってみていい感じだった。

まとめ

ほとんど需要がないはずですが、tDiaryのRDスタイルにシンタックスハイライト機能を追加したので紹介しました。

ツイートする

フォローする

伝えることを伝えること

しばらく人前で話す予定がないので、講演者が本当に話したかったスピーチを残しておきます。

実は、日本Ruby会議2011で話したことは札幌Ruby会議02で話したことと札幌Ruby会議03で話しかけたことの続きでした。話の流れも札幌Ruby会議02と同じ流れにしました。一番伝えたいことは話しの真ん中に持っていき、その後に実例を伝えるという流れです。

札幌Ruby会議のころは「伝えること」について考えていました。

私がプログラミングを始めたのは大学のころ*1で、世間で活躍しているプログラマーよりだいぶ遅いです。でも、プログラミングが好きでたくさんプログラムを書いてきました。今では、プログラミングをはじめて10年くらい経ち、だいぶ上手くなってきました。でも、このままだとよくないなぁと思うようになりました。

私は独学でプログラミングを学んできました。本を読んだりコードを書いたり、他の人のよいところを盗んだり。でも、他の人も同じようにやる必要はないなぁと思うようになりました。自分がよいとわかったことを厳選して伝えられて、その分、他の人がもっと別のことをできるなら、そっちの方がいいなぁと思ったのです*2。

そのため、札幌では自分がプログラミングで大事だと思っていることを伝えようとしました。

それから、普段でもいろいろ伝えてみました*3。 そしたら、伝えるだけでも足りないと思うようになりました。「魚をあげるんじゃなくて、魚の捕り方を教えなよ」では足りないのです。これでは、魚を捕れる人は増えるかもしれませんが、「魚の捕り方を教えなよ」という人は増えないのではないかと思うようになりました。「伝えること」だけではなく「伝えることを伝えること」をしなければいけないのではないか。

「伝えることを伝えること」は日本Ruby会議2011では落とした話題ですが、拾ってくれた人がいて嬉しかったです*4。いつかリベンジしたい話題です。

まだ、「伝えること」も伝えきれていないので、「伝えることを伝えること」はもう少し先の話になると思いますが、実現できたらいいなぁと思っています。まずは、クリアコード内で「伝えること」をまとめて、ここで公開しようとしているところです*5。公開したものが誰かの役にたつといいなぁ。

日本Ruby会議2011のことはもう書いたので、ここに書くことは技術的な話に戻そう*6と思っていました。でも、日本Ruby会議2011関連のWeb日記を読んでいたら、「書いておかないと」と思ったので、書いてしまいました*7。

ツイートする

フォローする

日本Ruby会議2011: テスティングフレームワークの作り方

日本Ruby会議2011で「テスティングフレームワークの作り方」について話してきました。前に人前で話したのが2月のフクオカRuby大賞だったので半年くらい人前に出ていなかったのですね。

発表内容のこととRuby会議のことについて書いておきます。

発表内容

数年前なら自分がよいと思っている技術的なことを「これかっこいいでしょ！」みたいな感じで話したかったのですが、最近は自分がよいと思っている開発スタイルをまだそれを知らない人に「こういうスタイルもあるんだよー」と伝えたくなってきました*1。そのため、今回の発表内容は「自分が開発しているときに無意識のうちに考えていること」になりました。

発表内容についてざっくりまとめるとこんな感じになります。

• ライブラリやツールを作るときは、頭の中で考えていることをそのまま書けるような使い方にするといいよ。
• そのためには「だれが」「なんのために」「頭の中で考える」かを意識しよう。

キーワードは「判断基準」にしました。

「判断基準」はここ数年で意識することになったキーワードで、今まで無意識でやっていたことを改めて考えるきっかけになっていました。今のところ、1回の話で伝えられる程には自分の中で整理できているわけではなく、何度も繰り返し伝えていくことでしか伝えきれないと感じています。今回は1回だけの機会になるので伝えきれる気がしなかったのですが、せめてきっかけくらいになればいいなぁと思い、伝えようとしてみました。

本当は一緒に開発をしながら伝えていきたいことです。現状だとクリアコードに就職するしか方法がないのですが、別の方法でもなにか機会があるといいなぁと思っています。

Ruby会議のこと

Ruby会議ではセッションを聞かずにロビーなどをぶらぶらしながら誰かと立ち話をするのが好きでした。ふだんは直接会えない人と初めて会ったり久しぶりに会ったりできるのがRuby会議でした。会ったことがない人同士を引き合わせるのも好きでした。

今回のRuby会議ではクリアコード関係者が4人も壇上で話していました。クリアコードができた頃はこんなことになるとは思ってもいませんでした。とても嬉しいことです。

Ruby会議じゃない場所でもまた会えるといいなぁと思います。

ツイートする

フォローする

RSpecとtest-unit 2での抽象化したテストの書き方の違い

日本Ruby会議2011の3日目の「テスティングフレームワークの作り方」の準備をしていますが、30分だと詰め込み過ぎになってしまうので、話さないことを事前に書いておきます。それは、テストを抽象化するためのAPIの違いです。

RSpecとtest-unit 2でのAPIの違いというと、class UserTest < Test::Unit::TestCaseとdescribe Userやassertとshouldの違いの方が目に付きますが、抽象化するためのAPIにもツールの特徴が出ています。抽象化するためのAPIはテストの量が増えてくると必要になる大事な機能です。ここでは、その中でも「テストを共有するAPI」について考えます。

まず、ツールの考え方について確認し、その後、それぞれのツールでどのようなAPIになっているかをみます。

ツールの考え方

まず、それぞれのツールの考え方について確認しましょう。

RSpecの考え方

RSpecでの書き方を見る前に、RSpecがどういうことを実現するためのツールとして開発されているかを確認しましょう。

BDD is an approach to software development that combines Test-Driven Development, Domain Driven Design, and Acceptance Test-Driven Planning. RSpec helps you do the TDD part of that equation, focusing on the documentation and design aspects of TDD.

[RSpec Documentationより引用]

ざっくり訳すと、

BDDはテスト駆動開発とドメイン駆動設計と受け入れテスト駆動計画づくりとATDPを合わせたソフトウェア開発の方法で、RSpecはそのうちのテスト駆動開発の部分だけをお手伝いしますよ。もう少し言うと、テスト駆動開発の特徴であるドキュメントと設計の部分を特に重視しています。

となります*1。

ドキュメントと設計（とRSpecというツール名）を合わせて考えると、仕様をテストとして実行できる形にしながら開発を進めたいのではないかという解釈ができます。そうすると、仕様とテストを一緒に書きやすいAPIを目指しているはずです。

test-unit 2の考え方

test-unit 2はxUnit系のテスティングフレームワークです。Rubyで書かれたコードのテストをRubyで書けることを重視しています*2。そのため、Rubyとしてテストを書きやすいAPIを目指しています。

書き方

それでは、このような考え方を持つツールはどのようなAPIを提供するかを見てみましょう。

RSpecでの書き方

RSpecでテストを共有する場合はit_behaves_likeを使います。以下は、shared examples - Example Groups - RSpec Coreにあるコードです。「別途記述した動作通りに動くこと」と読めるAPIになっていますね。期待した動作を取り込むのではなく、参照しているように読めるところがポイントです。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

require "set"

shared_examples "a collection" do
  let(:collection) { described_class.new([7, 2, 4]) }

  context "initialized with 3 items" do
    it "says it has three items" do
      collection.size.should eq(3)
    end
  end

  describe "#include?" do
    context "with an an item that is in the collection" do
      it "returns true" do
        collection.include?(7).should be_true
      end
    end

    context "with an an item that is not in the collection" do
      it "returns false" do
        collection.include?(9).should be_false
      end
    end
  end
end

describe Array do
  it_behaves_like "a collection"
end

describe Set do
  it_behaves_like "a collection"
end

test-unit 2での書き方

test-unit 2でテストを共有する場合は共有したいテストを書いたModuleをincludeします。こちらは「テストの実装を共有する」と読めるAPIになっていますね。RubyではModuleは実装を共有する手段として提供されているため、それをそのまま「テストを共有」するために使っていることがポイントです。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38

require "set"

gem "test-unit"
require "test/unit"

module CollectionTests
  def collection
    @collection ||= collection_class.new([7, 2, 4])
  end

  def test_initilize
    assert_equal(3, collection.size)
  end

  def test_include_true
    assert_true(collection.include?(7))
  end

  def test_include_false
    assert_false(collection.include?(9))
  end
end

class ArrayTest < Test::Unit::TestCase
  include CollectionTests

  def collection_class
    Array
  end
end

class SetTest < Test::Unit::TestCase
  include CollectionTests

  def collection_class
    Set
  end
end

まとめ

テスティングフレームワークの作り方からもれた話題のひとつである「 RSpecとtest-unit 2の考え方の違いとそれが『テストを共有するAPI』にどう現れているか」をみてみました。

考え方としてRSpecとtest-unit 2のどちらがよいかではなく、自分がやろうとしている作業にはどちらが合っているかを考えるべきです。仕様としても使えるテストとRubyとして書けるテストのどちらが必要か・重要かを考えます。

例えば、すでにある仕様書や要望リストを実現するために作業している場合はRSpecの方が作業に合っているかもしれません。仕様っぽいAPIである程度Rubyと切り離して作業することにより、仕様を意識しながら作業を進めることができます。

そうではなく、内部で使うためのもので外部とのインターフェイスとなっていない部分であれば、test-unit 2の方が合っているかもしれません。RubyのそのままのAPIを使ってテストを書くため、仕様としてどうかということよりも、Rubyのプログラムとしてどのように動くのがよいかという部分に集中できます。

ツイートする

フォローする

日本Ruby会議2011でLDAPの話をしませんか？

日本Ruby会議2011のLightning Talkの締め切りが残り数日になっていますが、みなさんいかがお過ごしでしょうか。

去年開催された日本Ruby2010では、はRuby で扱う LDAP のススメ - 選択肢とその事例という企画があり、RubyとLDAPに関する情報を共有する場になりました。（企画を主催した高瀬さんのまとめ）

日本では「RubyでLDAPを使う」というケースを情報共有する場が無く、この企画はとても意義のあるものでした。今年も同じような場が設けられると有意義でしょう。ということで、RubyKaigi2011の講演以外の企画についてを参考に、日本 Ruby会議2011でそういう場を設けるための方法案をまとめてみました。興味がでてきた人はぜひ実現させてください。

Lightning Talk

自分が知っていることなどを発表して情報を共有できるでしょう。ただし、持ち時間5分のなかで質疑応答などをすることはできないので、別の機会で行うことを考慮した方がよいでしょう。

会期中は会場3Fの和室をハッカソンなどのために開放します

日本Ruby会議2010でやった企画のように、「数人の発表者 + 質疑応答」というスタイルを実現できるかもしれません。あるいは、その場で一緒にコードを書いたりすることもできるかもしれません。

または、Lightning Talkと組み合わせて質疑応答をこちらで行うということも考えられます。

会期中にアンカンファンレス、!RubyKaigi(NotRubyKaigi)2011を開催しておきます

Lightning Talkより自由度が高いので、この時間だけで「発表 + 質疑応答」ができるかもしれません。

RubyKaigi Advent Calendar 2011

日本Ruby会議 2011の会期中ではなく、それより前に場を設けるという方法です。他の方法より準備が大変そうですが、一番自由度は高くなります。いろいろやりたいことがある場合はこの方法がよいかもしれません。

まとめ

日本Ruby会議2011でRubyとLDAPの話をする場を設ける方法案を紹介してみました。興味が出てきた方は[activeldap:88] 今年も日本Ruby会議2011に参加しませんか？へどうぞ。

（どの方法案もLDAPに関係ないような気がします。）

ツイートする

フォローする

日本Ruby会議2011でるりまとテスティングフレームワークについて話します

日本Ruby会議2011のスケジュールが発表されました。クリアコードのメンバーはるりまに関することとテスティングフレームワークに関することを話します。面白そうだなと思ったら聞きに来てください。

ツイートする

フォローする

日本Ruby会議2011にGoldスポンサーとして参加

昨年に引き続き、クリアコードは今年も日本Ruby会議2011のGoldスポンサーになりました。

まだでていませんが、発表などでも参加する予定なので、会場で見かけたら声でもかけてください。

開催は2ヶ月後で、まだ少し時間がありますが、RubyKaigi2011の講演以外の企画についてやRubyKaigi Advent Calendar 2011など関連情報がいくつかでています。Online.kaigi.rbなど日本Ruby会議2011以前に行われるイベントもあるようなので、興味のある方はそちらにも参加してみてはいかがでしょうか。

ツイートする

フォローする

64bit版Windows用のRubyInstallerの作り方

WindowsにRubyをインストールする場合、どうやってインストールしますか？現在のところ、以下のようにいくつも選択肢があります。

• Ruby-mswin32 (ja)
• ActiveScriptRuby
• RubyInstaller for Windows
• Rumix
• 能楽堂
• ...

それぞれ特徴があるので自分の使い方にあったものを選ぶ必要がありますが、今回の話の趣旨は「これがオススメです！」というものを伝えることではないので、簡単に紹介するだけにしておきます。ピンときたものがあったら、それについてもう少し詳しく調べてみることをおすすめします。

• Ruby-mswin32: インストーラではなく、バイナリをzip形式のアーカイブで配布。展開すればそのまま使える。32bit版と64bit版の両方あり。1.8と1.9の両方あり。Visual Studioでビルド。
• ActiveScriptRuby: インストーラ形式。32bit版のみ。1.8と1.9の両方あり。HTML Application内でRubyを使うことができる。Visual Studioでビルド。
• RubyInstaller for Windows: インストーラ形式。ただし、メッセージは英語。32bit版のみ。1.8と1.9の両方あり。MinGWでビルド。
• Rumix: インストーラ形式。32bit版のみ。1.8と1.9の両方あり。バイナリはRuby-mswin32のものを利用。
• 能楽堂: インストーラ形式。64bit版のみ。1.9.3（2011/05/15時点では未リリース）のみ。Visual Studioでビルド。Rails実行環境入り。

今回の話ではRubyInstaller for Windowsを使います。では、どうしてRubyInstaller for Windowsを使うのでしょうか。

RubyInstaller for Windowsの特長

今回挙げたビルド済みRubyのパッケージの中で、RubyInstaller for WindowsのみがMinGWでRubyをビルドしています。これが、今回RubyInstaller for Windowsを選んだ理由です。RubyがMinGWでビルドされているとDebian GNU/Linux上で拡張ライブラリをクロスコンパイルすることができます*1。

GNU/Linuxなどでは64bit版Rubyが普通に使われていますが、Windowsではまだそうでもないようです。しかし、今後はWindowsでも64bit版Rubyの利用が進んでいくでしょう。そうなった場合、拡張ライブラリは64bit版Ruby用のバイナリ入りで配布することが求められます*2。

普段からWindowsで開発している拡張ライブラリであれば簡単に64bit版Ruby用バイナリを作成できるでしょうが、メインの開発環境がGNU/Linux*3という場合は難しいです。GNU/Linuxで開発している場合は、GNU/Linux上でクロスコンパイルして64bit版Ruby用バイナリを作成できるととても便利です。そして、MinGW-w64を利用すれば64bit版Windows用のDLLをクロスコンパイルできるのです。

しかし、RubyInstallerはまだ64bit版Rubyには対応していません。つまり、64bit版Ruby用の拡張ライブラリをクロスコンパイルしてバイナリを作っても、それを使うための64bit版Rubyの入手が困難な状況ということです。

64bit版Ruby対応RubyInstaller

RubyInstallerが64bit版Rubyに対応していないため、クロスコンパイルした拡張ライブラリを使える64bit版Rubyを簡単にインストールできない問題をどのように解決すればよいでしょうか？簡単ですね。RubyInstallerを64bit版Rubyに対応させればいいのです。

ということで、対応させたものがGitHub上のkou/rubyinstallerのmingw-w64ブランチにあります。これを使って作成した64bit版Ruby*4用のRubyInstallerと、Debian GNU/Linux上でクロスコンパイルしたrroongaのgemを以下に置いておきます*5。

• 64bit版Ruby用RubyInstaller for Windows
• 64bit版Ruby用RubyInstaller for Windows用バイナリ入りrroonga

rroongaのチュートリアルで、実際にきちんと動くことを確認できます。

というように、なんとなく動くようになっていますが、まだいくつかやらなければいけないことがあります。

• インストーラの64bit対応
• Ruby本体のMinGW-w64対応改善

ということで、Ruby 1.9.3がリリースされるまでにみなさんがこれらの修正できるように64bit版Ruby用RubyInstallerの作り方を紹介します。タイトルからは想像できなかった展開ですね。

64bit版Ruby用RubyInstallerの作り方

まず、初期設定の方法を紹介し、それからRubyをビルド・テストする方法とRubyInstallerを作成する方法を紹介します。

初期設定

必要なものは以下の通りです。

• Ruby 1.8.7の実行ファイル
• Inno Setup
• Cygwin
• Ruby trunkのソースコード
• RubyInstall for Windowsのソースコード

Ruby 1.8.7はすでにあるRubyInstaller for Windowsを使ってインストールします。Ruby 1.9.2では動作しないので注意してください。

Inno SetupはWindowsインストーラを作成するフリーソフトウェアです。ダウンロードページからisetup-5.4.2.exeをダウンロードしてインストールします。

本当はCygwinはなくてもよいのですが、初期設定が楽なのでCygwinを使います。まず、setup.exeをダウンロードしてCygwinをインストールします。追加でインストールするソフトウェアは以下の通りです。

• subversion
• autoconf
• git

必須ではありませんが、mingw64-x86_64-binutilsもあると便利でしょう。

CygwinをインストールしたらRubyをチェックアウトします。trunkのRubyを修正しないと取り込んでもらえないからです。また、作業は~/work/ruby/*6以下で行うことにします。

% mkdir -p ~/work/ruby
% cd ~/work/ruby
% svn co http://svn.ruby-lang.org/repos/ruby/trunk ruby
% cd ruby
% autoconf

RubyInstaller for Windowsのソースコードもチェックアウトします。mingw-w64ブランチの成果はオフィシャルリポジトリに取り込まれそうな雰囲気はあるのですが、まだ取り込まれていないのでmingw-w64ブランチを使います。

% cd ~/work/ruby
% git clone https://github.com/kou/rubyinstaller.git
% cd rubyinstaller
% git checkout mingw-w64

以上が初期設定です。ここまでの作業は最初に1回行うだけです。今後は~/work/ruby/rubyinstaller/で作業を行います。

ビルド

ここからはcmd.exe上で実行します。ただし、cmd.exe上で長いコマンドを打つのは大変なので、バッチファイルを作成します。

build.bat:

c:\Ruby187\bin\ruby.exe c:\Ruby187\bin\rake ruby19 LOCAL='C:\Cygwin\home\kou\work\ruby\ruby' ProgramFiles='c:\Program Files (x86)' dkver=mingw64-64-4.5.4 --trace > build.log 2>&1

これをC:\cygwin\home\kou\work\ruby\rubyinstaller\で実行します。

C:\cygwin\home\kou\work\ruby\rubyinstaller>build.bat

小一時間ほど待つとsandbox\ruby19_mingw\以下に64bit用Rubyが作成されているはずです。

C:\cygwin\home\kou\work\ruby\rubyinstaller>sandbox\ruby19_mingw\bin\ruby.exe --version
ruby 1.9.3dev (2011-05-14) [x64-mingw32]

ビルド時のログはbuild.logに保存されているので、問題が発生した場合はログを見て問題を解決し、RubyやRubyInstallerの開発チームに報告して解決内容を取り込んでもらいましょう。開発チームにコンタクトをとる方法など、関連リソースについては一番最後に書いてあるので参考にしてください。

パッケージの作成

パッケージの作成もコマンドが長いのでバッチファイルを作成します。

package.bat:

c:\Ruby187\bin\ruby.exe c:\Ruby187\bin\rake ruby19:package LOCAL='C:\cygwin\home\kou\work\ruby\ruby' ProgramFiles='c:\Program Files (x86)' dkver=mingw64-64-4.5.4 --trace > package.log 2>&1

これをC:\cygwin\home\kou\work\ruby\rubyinstaller\で実行します。

C:\cygwin\home\kou\work\ruby\rubyinstaller>package.bat

10分ほど待つとpkg\以下にRubyInstallerが作成されているはずです。このRubyInstallerにはsandbox\ruby19_mingw\以下にビルドされたRuby用が含まれています。RubyInstallerのファイル名はpkg\rubyinstaller-1.9.2-p180.exeになっていて、直さなければいけないものの1つです。ただ、このファイル名は後で直すことにして、まずは、試しにインストールしてみましょう。インストーラをダブルクリックするとインストールできます*7。

ここまでくればパッケージの修正作業はできますね。現在のところ、以下のような問題があります。

• インストーラのファイル名がRubyのバージョンを表していない
• インストーラの64bit対応

テスト

テストの実行もコマンドが長いのでバッチファイルとシェルスクリプトを作成します。テストはMSYS上で実行するため、まずはcmd.exeからMSYSのbashに入るためのバッチファイルが必要です。

shell.bat:

c:\Ruby187\bin\ruby.exe c:\Ruby187\bin\rake devkit:sh LOCAL='C:\Cygwin\home\kou\work\ruby\ruby' ProgramFiles='c:\Program Files (x86)' dkver=mingw64-64-4.5.4

次に、bash上でテストを実行するためのシェルスクリプトです。

run-test.sh:

1
2
3
4
5
6

#!/bin/sh

export PATH=$PWD/sandbox/ruby19_mingw/bin:$PATH
ruby --version
cd sandbox/ruby19_build
make test-all

以下のように使います。

C:\cygwin\home\kou\work\ruby\rubyinstaller>shell.bat
...
sh-3.1#$ ./run-test.sh > test.log 2>&1

テスト結果はtest.logに出力されます。この結果ですべてのテストがパスするようにしましょう。なお、r31560では「9486 tests,1877705 assertions, 29 failures, 8 errors, 82 skips」となりました。結果の詳細は以下にあります。

• '"make test-all" on ruby 1.9.3dev (2011-05-14) [x64-mingw32] (r31560) - Gist'

やりがいがありそうですね。

まとめ

MinGW-w64で64bit版Rubyをビルド・テストする方法と、ビルドした64bit版RubyのRubyInstallerを作成する方法を紹介しました。まだ、いくつか問題があるのでピンときた人はRuby 1.9.3がでるまでに修正してみてはいかがでしょうか？

関連リソース:

• RubyInstallerのリポジトリ
• RubyInstallerのメーリングリスト
• Inno Setupのドキュメント
• Rubyのリポジトリ
• Ruby開発者の手引き
• Ruby 1.9系ですでに報告されている問題（MinGW-w64でビルドした64bit版Rubyで発生している問題のいくつかはすでに報告済みです。すでに報告済みの問題はそのチケットに修正パッチなどを添付するとよいでしょう。）

ツイートする

フォローする

RDocとYARDの比較

リファレンスマニュアルの記述方法を検討し、埋め込み方式のドキュメントツールを採用したとします。Rubyで埋め込み方式のドキュメントツールを使うとしたらRDocかYARDになります*1。

RDocからYARDへの移行方法につなげたいのでYARDを使う方向で話を進めたいわけですが、その前にRDocとYARDの背景や機能の違いを確認しておきましょう。

RDocの背景

RDocはRuby 1.8.1からRuby本体に標準添付されています。Ruby1.8.1は2003年のクリスマスにリリースされているので、もう7年くらい前になります。Ruby本体や標準添付されているライブラリもRDoc用にドキュメントが書かれていますし、Rubyで標準的なドキュメントツールといえばRDocという存在です。

RDocは2004年くらいまではRuby本体のリポジトリ上で活発に開発されていましたが、それから数年は開発が停滞していました。その後、2008年頃より開発リポジトリをRuby本体のリポジトリからRubyForgeのリポジトリに移動して*2、再び開発が活発になりはじめます*3。RDoc 2.Xがはじまったのもこの頃です。2年後の2010年の12月にRDoc 3.Xがはじまるなど、今でも開発のペースは衰えていません。

と、こう書くとRDocでいいんじゃないかと思うところです。しかし、Ruby 1.9を使っていて日本語も含むドキュメントを扱っていた人はそんなことはないということに気づいているはずです。Ruby 1.9の大きな変更の1つがEncodingの導入ですが、RDoc 2はEncodingの対応が不十分です。RDoc 2でHTMLを生成しようとして、Encoding関連の例外が発生した人もいるのではないでしょうか。

そして、ハマリポイントなのが、Ruby 1.9.2に標準添付されているRDocは RDoc 3ではなくRDoc 2だということです。Encoding関連で問題が発生している人はgemでRDoc 3をインストールして、そっちを試してみてください。

RDocの機能

RDocではドキュメントのマークアップ言語として独自のマークアップ言語を作成しています。MarkdownやTextileなどといったマークアップ言語よりもシンプルで、機能が足りないと感じることが多いかもしれません。特に、Ruby用のドキュメントシステムとして開発されたのにも関わらず、コード用の専用マークアップがないことには驚くかもしれません*4。

クラスやメソッド用のメタ情報記述方法ではRuby用ドキュメントツールらしい記述がサポートされています。Rubyは動的な言語なので「メソッドを定義するメソッド」*5も定義できます。そのようなメソッドのドキュメントも記述できるようになっています。

例えば、以下のようにprotected_attr_readerという独自の「メソッドを定義するメソッド」を定義したとします。このとき、protected_attr_readerで定義したメソッドもattr_readerと同じように読み込み専用属性としてドキュメント化して欲しいですよね。RDocでは以下のように記述することによって、独自の「メソッドを定義するメソッド」で定義したメソッドにも適切にドキュメントを記述することができます。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

class CoveredBook
  class << self
    def protected_attr_reader(name)
      attr_reader name
      protected name
    end
  end

  ##
  # :attr_reader:
  # タイトルを返す。ただし、内部からのみから利用可能。
  protected_attr_reader :title

  def initialize(title)
    @title = title
  end
end

と、こう書くとRDocでいいんじゃないかと思うところです。しかし、DoxygenやGTK-Docなど他のドキュメントツールにはあるような専用マークアップがありません。例えば、メソッドの引数*6や戻り値*7のドキュメントを記述するための専用マークアップがありません。これらはメソッドのドキュメントを読みやすく整形するときに便利です。また、「バージョンいくつから追加された機能」*8や「非推奨のAPI」*9を記述する専用マークアップもありません。

現在も開発が継続しており、RDoc 3もリリースされ、継続的に改良されている*10のですが、まだ細かいところのサポートが不足しているという印象です。

YARDの背景

YARDは2007年から開発が始まっています。RDocの開発が再び活発になりはじめたのが2008年頃なので、あまり改良されていなかった当時のRDocに不満を持っていたのかもしれません。

YARDが重視していることは拡張のしやすさです。YARDのトップページにはアピールポイントとして「Preview As You Document」、「Easily Customize Templates」、「Support Your Own DSL」、「Extend, Extend, Extend!」の4つが挙げられています。このうち3つは拡張性に関することです。Rubyは動的な言語なので使われ方も様々です。様々な使われ方をしているときでもドキュメントを記述できるように拡張性を高くしているものと考えられます。

また、RDocとの互換性も重視しています。RDoc用に書かれたドキュメントを変更なしで処理できるため、RDocからの移行も容易です。

YARDの機能

YARDは複数のマークアップ言語をサポートしています。組み込みではRDoc由来のマークアップ言語だけのサポートですが、gemをインストールすることでMarkdownやTextileも利用することができます。チュートリアルや設計に関する文書など、ある程度長めの文書を書くときはRDocのマークアップではなく、より汎用的なマークアップ言語の方を使うのがよいでしょう。

YARDはメソッドなどのメタ情報の記述方法はRDocとは異なる書式を採用しています。YARDはDoxygenやGTK-Docなどと同様に@タグ名という記述方法を採用しています*11。YARDではこれをタグと呼んでいます。組み込みで利用できるタグにはRDocにはなかった、引数記述用タグ、戻り値記述用タグ、初出バージョン記述用タグ、非推奨API記述用タグなどライブラリのドキュメントを記述するために必要そうなタグが一通り揃っています。また、タグを追加することもできます*12。

また、ドキュメントとして抽出したテキスト情報やメタ情報を再利用しやすい形で提供しています。これを利用することでるりまサーチのようなドキュメント検索システムを作りやすくなりそうですが、これについてはまた別の機会にします。

今後はRDocも記述力が高まったりメタ情報の扱いが改良されていくのかもしれませんが、現時点ではYARDの方がより実践的な機能を持っているといえるでしょう。ただし、ドキュメント生成速度はRDoc 3の方が圧倒的に速いです*13。

まとめ

Ruby用のドキュメントツールであるRDocとYARDについて比較しました*14。YARDの方がよさそうに思えるように書いているので、YARDを使いたくなったかもしれません。次こそはYARDの使い方を紹介できるかもしれません。

ツイートする

フォローする

groonga関連リリース週間

今週は全文検索エンジンgroongaとその関連ソフトウェアがいろいろリリースされました。

リリースされたソフトウェア

以下がリリースされたソフトウェアとそのバージョンです。

groonga 1.2.0

全文検索エンジン。一部非互換があるためマイナーバージョンがあがっています。詳細はgroonga-dev MLでのアナウンスを参照してください。

groonga storage engine 0.5.0

ストレージエンジンとしてgroongaを利用するMySQLのプラグイン。まだベータ版です。このリリースにはMySQL 5.5への対応強化などが含まれています。

rroonga 1.2.0

groongaをRubyから使えるようにするためのRubyの拡張ライブラリ。groonga 1.2.0対応だけではなく、新機能もあります。詳細はgroonga-dev MLでのアナウンスを参照してください。

ActiveGroonga 1.0.4

Rails 3でrroongaを利用するためのRubyライブラリ。Rails 3用のページネーションライブラリKaminari（のViewの部分のみ）に対応しています。これも詳細はgroonga-dev MLでのアナウンスを参照してください。

ActiveGroonga Fabrication 1.0.0 [NEW!]

オブジェクト生成ライブラリFabricationにActiveGroongaサポートを追加するライブラリ。gemでインストールできます。

% sudo gem install activegroonga-fabrication

使うための準備はこれだけです。

1	require 'active_groonga_fabrication'

後は、通常のFabricationの使い方と同じです。

まとめ

今週リリースされたgroonga関連のソフトウェアを紹介しました。

そういえば、先日、groongaを使ったアプリケーションであるるりまサーチで受賞した第3回フクオカRuby大賞のコミュニティ特別賞の賞状が届きました。

ツイートする

フォローする

ソーシャルウィジェットtDiaryプラグイン

kdmsnrさんが設定していたFacebookコメントプラグインがうらやましかったので、ククログにもつけてみました。ククログはtDiaryを使っていますが、CGIやRackで動かすのではなく、オフラインで静的なHTMLに変換してからWebサーバーにアップロードしています。そのため、tDiaryが持っているツッコミ機能は使っていません*1。

追加でfacebook_comments.rbを使おうとしたのですが、section_footer2.rbと衝突するのでやめました。また、section_footer2.rbに以下のような不満がありました。

• 名前に「2」と入っていて名前付けとして不適切。
• （インラインCSSでスタイルを設定しているからなのか）一列に並んだウィジェットがガタガタになっている。

そこで、section_footer2.rbが提供している機能のうち必要なものだけと、facebook_comments.rbの機能を合わせたsection-footer-social-widgets.rbプラグインを作りました。上記の不満や衝突問題は解決しているのですが、設定画面には対応していないので、簡単には使えないでしょう。同じようなことをしたかったら参考になるかもしれません、という程度の扱いのものです。

興味があったら見てみてください。

ツイートする

フォローする

るりまサーチが第3回フクオカRuby大賞のコミュニティ特別賞を受賞

先日、第3回フクオカRuby大賞の本審査に行ってきましたが、その結果が発表されました。

応募していたるりまサーチはコミュニティ特別賞に入っていました。認めてもらえてよかったです。

るりまサーチでるりまが便利だと感じた人はるりまプロジェクトにも参加してみてはいかがでしょうか？また、何か最近Rubyで作ったシステムがあれば、来年のフクオカRuby大賞に応募してみてはいかがでしょうか？

ツイートする

フォローする

デバッグしやすいassert_equalの書き方

デバッグしやすいassert_equalの書き方とデバッグしにくいassert_equalの書き方があるのは知っていますか？*1

デバッグしやすいassert_equalの書き方を2パターン紹介します。

まとめたassert_equal

まず、1つ目のよくみるデバッグしにくいassert_equalの書き方です。

1
2
3
4
5

def test_parse
  assert_equal(29, parse_integer("29"))   # (1)
  assert_equal(29, parse_integer("+29"))  # (2)
  assert_equal(-29, parse_integer("-29")) # (3)
end

これがデバッグしにくいのは、(1)が失敗したら(2)、(3)が実行されないからです。すべてのassert_equalが実行されて、どのassert_equalが失敗したかを確認することでバグの傾向を見つけやすくなります。

例えば…(1)だけが失敗するなら符号が無い場合の処理が怪しいでしょう。(3)だけが失敗するなら、マイナス記号に対応していないのかもしれません。全部失敗するなら根本的におかしいのでしょう。

このように、どのassert_equalが失敗したかがデバッグのヒントになります。よって、↑のような書き方はデバッグがしにくいassert_equalの書き方といえます。

デバッグしやすく書くと、例えば、こうなります。

1
2
3
4
5
6
7
8
9
10
11

def test_parse_no_sign
  assert_equal(29, parse_integer("29"))
end

def test_parse_plus_sign
  assert_equal(29, parse_integer("+29"))
end

def test_parse_mius_sign
  assert_equal(-29, parse_integer("-29"))
end

まとめないassert_equal

続いて、1つ目のよくみるデバッグしにくいassert_equalの書き方です。

1
2
3
4
5

def test_parse
  bob = MyJSONParser.parse('{"name": "bob", "age": 29}')
  assert_equal("bob", bob["name"])
  assert_equal(29, bob["age"])
end

1つ目の書き方のように複数のassert_equalが書いてあります。1つ目の書き方と同じように直すならこうなります。

1
2
3
4
5
6
7
8
9

def test_parse_string_value
  bob = MyJSONParser.parse('{"name": "bob", "age": 29}')
  assert_equal("bob", bob["name"])
end

def test_parse_numeric_value
  bob = MyJSONParser.parse('{"name": "bob", "age": 29}')
  assert_equal(29, bob["age"])
end

でも、本当にこれでよいでしょうか。この書き方では値の型だけを注目しています。値の型に注目するならば以下のように書いた方がよいでしょう。こうした方が余計なものがなくなり、より注目できています。

1
2
3
4
5
6
7
8
9

def test_parse_string_value
  bob = MyJSONParser.parse('{"name": "bob"}')
  assert_equal("bob", bob["name"])
end

def test_parse_numeric_value
  anonymous = MyJSONParser.parse('{"age": 29}')
  assert_equal(29, anonymous["age"])
end

もし、最初のコードが「複数のキーと値をパースできること」を確認したい場合はassert_equalを複数のテストに分割するのではなく、複数のassert_equalを1つのassert_equalにまとめるべきです。

1
2
3
4
5

def test_parse
  bob = MyJSONParser.parse('{"name": "bob", "age": 29}')
  assert_equal({"name" => "bob", "age" => 29},
               bob)
end

1つのassert_equalにまとめると、失敗する場合でも、一部の比較だけが実行されるのではなく、すべての比較が実行されます。そのため、"name"はパースに成功しているけど"age"は失敗している、というように、失敗の傾向がわかります。失敗の傾向がわかるとデバッグしやすくなるというのは前述の通りです。

おまけ: Hashのassert_equal結果が見づらい

ところで、Hashのassert_equalの結果は見づらいですよね。これは、RSpecでも一緒です。

1

{"age" => 30, "name" => "bob"}.should == {"name" => "bob", "age" => 29}

この結果は以下のようになります。

expected: {"name"=>"bob", "age"=>29}
     got: {"age"=>30, "name"=>"bob"} (using ==)
Diff:
@@ -1,2 +1,2 @@
-{"name"=>"bob", "age"=>29}
+{"age"=>30, "name"=>"bob"}

一見しただけではどこが違うのかわかりません。

しかし、最新のtest-unit 2は一味違います。

1
2

assert_equal({"name" => "bob", "age" => 29},
             {"age" => 30, "name" => "bob"})

この結果は以下のようになります。

<{"age"=>29, "name"=>"bob"}> expected but was
<{"age"=>30, "name"=>"bob"}>

diff:
? {"age"=>29, "name"=>"bob"}
?         30

違いがわかりやすいですね。

まとめ

デバッグしやすいassert_equalの書き方を2パターン紹介しました。今度から、assert_equalを書くときは、単に数を増やしたりするのではなく、どうすれば有用なassert_equalになるかを考えてみてください。assert_equalが失敗したときにいかにデバッグしやすいかがヒントになるはずです。

ツイートする

フォローする

TDDきのたん

今日は年に一度の肉の日だからか、いろいろなソフトウェアがリリースされていますね。

• groonga 1.1.0
• rroonga 1.1.0
• Cutter 1.1.6
• ChupaText 0.9.0
• test-unit-rr 1.0.0
• test-unit-runner-gtk2 0.0.2
• test-unit-full 0.0.3

このうち、Cutter 1.1.6について紹介します。

Cutterとは

CutterはC/C++用の単体テストフレームワークです。スクリプト言語の単体テストフレームワークのように簡単にテストを書けること、テストが失敗した時にデバッグしやすいことを重視しています。どちらも「テストが苦痛」にならないために大事なことです。

Cutter 1.1.6ではテストをより頻繁に実行しやすくするための機能を強化しました。それがTDDきのたんのサポートです。

TDDきのたんとは

TDDきのたんとはMayu & Co.さんが描いた色違いのかさのきのこたちです。Cutter 1.1.6を使うとテストを実行するたびに愛らしいTDDきのたんに会うことができます。頻繁にテストを実行したくなりますね。

テストとグリーンとレッドとフィードバック

TDD（テスト駆動開発）ではテストの結果を色で表すことが多いです。グリーンならパスで、レッドなら失敗です。グリーンになったら気持ちいいよね、レッドは落ち着かないね、早くグリーンにしたいね、そんな風に色を使っています。色を使うことで、テストをすべてパスしている状態をキープしたくなる力を推進しています。

RSpecやCutterなど最近も開発が続いている単体テストフレームワークは結果を表示する時にグリーンやレッドなどの色を使っています。でも、それだけで十分でしょうか。

テストを頻繁に実行するようになると、開発の中で自然にテストを実行するようになります。それはもうlsコマンドを実行するように*1テストを実行します。そうなると、テストの実行中に違う作業をして、合間にテスト結果を見るようになります。そのため、テストの失敗に気付くのが遅れる場合があります。

それを解決するためには、これまで通り端末に色付きの結果を表示させているだけでは不十分ではないでしょうか。

通知

デスクトップ環境では多くのアプリケーションが動いていて、常にすべてのアプリケーションを見ていることはできません。そこで必要なときにアプリケーションから「通知」してきます*2。Linuxや*BSDではDesktop Notification、Mac OS XではGrowlなどを利用します。

テスト結果も「通知」した方がよいのではないでしょうか。

そういうわけで、Cutter 1.1.6では「notify-send」コマンドを使ってTDDきのたん付きの通知を行うようになりました。test-unit 2では2ヶ月くらい前からTDDきのたん付きの通知をサポートしています。test-unit 2で利用する場合はtest-unit-notifyを使います。こちらもTDDきのたんを使っています。

まわりくどかったですね。

まとめ

まわりくどくCutter 1.1.6の新機能である「テスト結果通知」を紹介しました。単体テストフレームワークに限らず、うるさくない程度に「通知」に対応するとより使いやすくなるかもしれません。

「通知」を使う場合は画像も入れることをおすすめします。画像を入れるとよりピンときます。例えば、Mayu & Co.さんのTDDきのたんは愛らしくて何度も会いたくなりますよね。それでは、テストを実行して会いにいきましょう。

ツイートする

フォローする

もっと知られてもいい人たち

るりまサーチという最近の検索技術を使ってRubyのリファレンスマニュアルを検索するWebアプリケーションがあります。表向きの存在理由は「手早く簡単にドキュメントを検索できるシステムを提供することで、Rubyユーザが楽しくプログラミングすることを妨げないようにする」ですが、実はもう一つ理由があります。それは、「Rubyのリファレンスマニュアルをよいものにしている人たちがいることに気づいてもらう」というものです。

ここを読んでいる人の中に、他の人が実装したプログラミング言語やライブラリのドキュメントを書いて、メンテナンスしている（アップデートに追従するなど）人がどれだけいるのかわかりませんが、この作業はとても大変で根気のいる作業です。しかも、その成果をなかなか実感してもらえません。Ruby本体に新しい機能（例えば、「バイト長」ではなく「文字長」を数える機能）が入ったら、プログラムが簡潔になるなど、すぐに便利さを感じることができます。しかし、ドキュメントの方は「いやぁ、今読んだドキュメントはいいドキュメントだったなぁ！」と感じることはあまりないのではないでしょうか。

るりまサーチでRubyのリファレンスマニュアルを利用する人が増え、何度もその恩恵を受ければ徐々に便利さを感じてくるのではないでしょうか。そして、そう感じた人たちがリファレンスマニュアルをよくするプロジェクトに参加して、さらによくしていくことができたらよい循環になるのではないでしょうか。「Rubyを開発している人たちだけではなく、リファレンスマニュアルをよくしている人たちがいる」、るりまサーチがそのことを知ってもらうきっかけになれば作った甲斐があるというものです。

以下は第3回フクオカRuby大賞の本審査用に作った資料です。

ツイートする

フォローする

プログラミング言語のドキュメント検索をもっとリッチに

昔から「Rubyはドキュメントが弱い」と言われてきました。「PythonやPHPはあんなにドキュメントが揃っているのに、それに比べてRubyは。。。」というわけです。でも、待ってください。ドキュメントは記述が充実しているだけで十分ですか？簡単に目的のドキュメントにたどりつけますか？

GoogleやBingなどの検索エンジンや、Amazonを筆頭とするECサイトは「探しものを見つけやすくする」ことにどんどん磨きをかけています。なぜ、ドキュメントの検索機能はそれほど進歩しないのでしょうか？

ドキュメントの検索機能が、検索エンジンやECサイトでも使われているような最新の検索パターンを取り入れ、もっとリッチになればプログラミングがもっと楽しくなるはずです。それをRubyのドキュメントで実現しようとしているのがるりまサーチです。

最近、るりまサーチがよりパワーアップしたので、どう変わったかを紹介します。↓は、第3回フクオカRuby大賞用に作ったるりまサーチの資料です。

よくある検索機能

PythonのドキュメントページはSphinxで生成されています*1。SphinxにはJavaScriptで実装された検索機能がついていて、キーワードによる検索のみが可能です。シンプルで検索サーバーを用意しなくてもよい手軽さはうれしいですが、よいキーワードを思いつかないと目的のドキュメントにたどり着くのは難しいです。

PHPのドキュメントページの検索機能は検索対象のカテゴリ化とYahoo!の検索機能を利用しています。Yahoo!の検索機能を使った部分ではHTMLのページだけではなく、Atomフィードのファイルもヒットしてしまっています。通常のWebサイト検索ではAtomフィードもヒットしてよいかもしれませんが、ドキュメント検索ではAtomフィードはノイズです。既存の検索機能を利用することもできますが、より精度をよくしたい場合はチューニングが必要だということです。

プログラミング言語のドキュメント検索は通常のWeb検索や文書検索などの自然言語の検索と傾向が違います。例えば、記号が含まれていたり、省略語が使われていたり、メソッド名・クラス名などキーワード（スコアを上げた方がよい語）となる語がわかりやすかったりといった具合です。このあたりをふまえた上でチューニングするとより探しやすいドキュメント検索機能ができあがります。

では、チューニングした結果は、どのようにユーザーに見せるとよいでしょうか。それには先進的な検索機能を提供するWebサイトが参考になります。よい検索機能がデザインパターンとしてまとめられています。

検索のデザインパターン

検索と発見のためのデザイン　―エクスペリエンスの未来へ
Peter Morville/Jeffery Callender/浅野 紀予
オライリージャパン
￥ 2,520

昨年末、「検索と発見のためのデザイン」という本がオライリージャパンから出版されました*2。この本の中で、実際のWebサイトのスクリーンショットと一緒に、「検索のデザインパターン」としてよく使われるよい検索機能をパターン化しています*3。パターンの数は少ないのですが、このように検索機能をデザインパターンとしてまとめているのがよかったです。検索に興味のある方はこの部分だけでも眺めてみるとよいでしょう。

パワーアップしたるりまサーチにもこの本で作っている検索のデザインパターンにでてくる機能が実装されています。るりまサーチが、ドキュメント検索にチューニングした結果をどのように見せているかを2つ紹介します。

入力補完（オートコンプリート）

検索のデザインパターンの1つとして入力補完（オートコンプリート）機能が紹介されています。デスクトップでもWebでもかなり広まっているので見かける機会が多いのではないでしょうか。

Web検索の場合はクロールした文書の中によく含まれている単語や、ユーザが多く入力する単語などを元データとして、ユーザーの入力を補完することが多いでしょう。しかし、ドキュメント検索の場合、クラス名やメソッド名など、補完対象とすべきキーワードがわかりやすく含まれているので、それを使います。これにより、ノイズが少ない補完候補を出すことができます。

Yahoo!など外部の検索エンジンを使っている場合はこのようなチューニングは難しいのではないでしょうか。

ちなみに、るりまサーチの入力補完機能はgroonga本体に組み込まれている「サジェスト機能」を利用しています。groongaのサジェスト機能はまだ仕様が固まっていないため、APIが変更される可能性が大きくあります*4。使用する場合はそのことに注意してください。

なお、るりまサーチの入力補完のUI部分はjQuery UIのAutocompleteを利用しています。

ファセット型ナビゲーション

groongaでは「ドリルダウン」と呼んでいる機能で、絞り込み候補を表示する機能です。るりまサーチでは「クラス名」や「ドキュメントの種類」（インスタンスメソッドのドキュメントや定数のドキュメントなど）など、いくつかのグループを作って、それぞれのグループ毎に絞り込み候補を表示しています。

この機能のよいところは、キーボードで入力しなくてもマウスクリックだけで絞り込んでいけることです。一昔前の検索では「よいキーワード」を自分で考えて絞り込んでいく必要がありましたが、この機能を使うことにより「提示されたキーワードから選ぶ」だけでよくなります。便利で探しやすくなりましたね。

まとめ

プログラミング言語のドキュメント検索システムはもっと便利になって、プログラマを助けるべきという話でした。そのためにるりまサーチが提供している今風の検索機能を2つ紹介しました。どちらも、ユーザーが探したいものを見つけるためのキーワードを完全に知らなくても見つけることができるようにするための機能です。今後は、これらの機能のように、ユーザーがそれほど頑張らなくても見つけたいものにたどりつける機能がより一般的になってくることでしょう。

みなさんもWebサイトに検索機能をつけるときは、テキスト入力フォームを1つ置くだけではなく、さらに別の方法も加えてより簡単に目的のものを見つけやすくできないかを考えてみてください。

ツイートする

フォローする

milter manager 1.6.4リリース

先日、milter managerのスケーラビリティ向上計画を紹介しましたが、そこに書いた内容を実装したmilter manager 1.6.4をリリースしました。（メーリングリストでのアナウンス）

スケーラビリティ向上のための主な追加機能は以下の3点です。

1. マルチプロセス対応
2. libev対応
3. writeの非同期化

このうち、「マルチプロセス対応」と「libev対応」は「実験的」な扱いということで、デフォルトでは無効になっています。「writeの非同期化」は有効になっています。このため、Postfixや子milterのreadが遅い場面では劇的にスループットが向上するでしょう*1。

また、スケーラビリティ向上に加えてRuby対応を強化しています。代表的な変更はRuby 1.9.2に対応したことです。Rubyでmilterを書くのがより便利になりますね。

まとめ

milter manager 1.6.4をリリースしたので代表的な変更内容を紹介しました。

ツイートする

フォローする

るりまサーチで第3回フクオカRuby大賞の本審査

Rubyのリファレンスマニュアルを高速に全文検索するるりまサーチを 第3回フクオカRuby大賞に応募したら本審査に呼んでもらえたので、2/3に福岡に行ってるりまサーチを紹介することにしました。

（おそらく、）一般の人は審査会場（？）には入れないので、ここで紹介して「興味があったら見にきてください」とは言えないのが残念です。（おそらく、）2/3は時間にたいへん余裕があるので、福岡の人たちと交流できると嬉しいですね。

ツイートする

フォローする

地獄のジェネレータ: Ruby Advent Calendar jp: 2010の24日目

これはRuby Advent Calendar jp: 2010の参加エントリです。前日はysakakiさんでした。

今年のAdvent Calender界隈では惚れさせを集めたり、惚れさせを作ったり、忙しい人でも惚れさせを見れるようにしたりしているので、もう一歩先を行くことにしました。

地獄の名札ジェネレータ

名札には名前を大きく書きましょうジェネレータに「地獄モード」が追加されました。

これを使うと札幌Ruby会議03のプロの無職を楽しむことができます。

地獄のコマンドラインジェネレータ

地獄の名札ジェネレータはTwitterのプロフィール画像や説明文から惚れさせ名札を生成します。フォームに自分のTwitter IDを（カチャカチャカチャ…）と入力して（ッターン！）と「生成！」できるのでお手軽ですが、もっと惚れさせるために試行錯誤したい場合は少し不便ですね。

ということで、ささたつさんが作ったmisawa gemを画像生成に対応させました。

% sudo gem install gtk2
% wget https://github.com/kou/misawa/raw/master/lib/misawa.rb
% wget -O misawa_background.jpg http://a2.twimg.com/profile_images/461389564/aaa.jpg
% ruby -r misawa -e 'misawa("俺ってそんなに\n唐揚げとたいやき食べてる\nイメージあるー？\n\nそれどこ情報？どこ情報よー？")'
% display misawa.png

縦書き

名言はPangoとcairoで描画しています。この2つのフリーソフトウェアを組み合わせることにより日本語の縦書きも描画できます。「ー」など単純に回転させるだけだと問題が起こる文字も、フォントが対応していれば*1きちんと描画できます。

ポイントはPangoGravityとcairo_rotate()です。

Pangoにはpango-viewというPangoのオプションを簡単に試せるツールがついています。これを使ってオプションの効果を確認します。

まず、そのまま描画した場合です。横書きになっていますね。

% pango-view --output normal.png --font "MotoyaLMaru 48" --text "つれーわー"

次に、PangoGravityにPANGO_GRAVITY_EASTを指定した場合です。横に転がっていますが縦書きになっています。

% pango-view --output east.png --font "MotoyaLMaru 48" --text "つれーわー" --gravity east

ここまでくればあとは実質回転させるだけだからつれーわー。最後に、-90度回転させれば縦書きが完成です。

% pango-view --output east-rotate.png --font "MotoyaLMaru 48" --text "つれーわー" --gravity east --rotate -90

この縦書き機能はPango 1.16からサポートされています。Pango 1.16は2007年にリリースされているので、4年くらい前に見て、一番先に飽きた人もいるのではないでしょうか。

もちろん、Ruby/PangoでもPangoGravityを使うことができます。具体的な使い方は名札ジェネレータかmisawa gemを見てください。misawa gemの方がシンプルでわかりやすいでしょう。

名言を描画するところでは、文字を縦書きで描画するだけではなく、縦書きの文字に白い影もつけています。そのあたりのやり方もソースを見ればわかるでしょう。

まとめ

惚れさせるために必要なRubyで縦書きを描画する方法を紹介しました。みなさんもRuby/Pangoとrcairoを使って縦書きなクリスマスカードや年賀状をRubyで生成してみてはいかがでしょうか。

明日のRuby Advent Calendar jp: 2010はtmaedaさんです。最後なのでとてもすごいのがくるはずですよ！

ツイートする

フォローする

デバッグ力 - 札幌Ruby会議03

12月4日に開催された札幌Ruby会議03に参加し、ライトニングトークで少し話しました。話さなかったことと感じたことを残しておきます。

文書検索ラングバの話をするつもりでしたが、もっと話したいことができたのでそっちを話すことにしました*1。それが「デバッグ力」についてです。

デバッグ力？

「デバッグ力」とは一般的な用語ではありません。実際、検索してもほとんど使っている人はいません。札幌で伝えたいことを表す言葉に一番しっくりくるのが「デバッグ力」だったので、そう呼ぶことにしました*2。

コンピュータの世界では、「バグ」は「不具合」とか「問題」といった意味で使われます。デバッグとはバグを取り除くこと、つまり、問題を解決する作業です。プログラマは問題を解決していくことで、徐々に目的を達成するプログラムに近づけていきます。「デバッグ力」には、目的のものへ近づくための力、前へ進む力という意味をこめています。

デバッグ力を発揮するために大事なことはひとつずつ問題を解決していくことです。便利なツールやtipsなどはいろいろありますが、一番大事なことはこの姿勢です。ひとつずつ、問題と向き合って、事実から目を逸らさずに、ていねいに、順番に、解決していきます。この姿勢で問題と向かい合えるようになったら、あとは、テクニックやツールなどを覚えながら少しずつうまくなっていけばよいのです。ひとつずつ、ひとつずつ、ひとつずつ。順番に解決していきます。簡単そうに聞こえますが、けっこう難しいことです。わりとすぐに忘れてしまいます。大変なことなのでなかなか勧めづらいくらいです。しかし、正しい方向に進んでいるかの判断基準になるくらい覚えておきたいことです。

このデバッグ力の基本はプログラムに限定されません。もっと広く応用できるものです。デバッグ力を使って、前へ進んで欲しい、誰かが前へ進むことを助けてほしい、誰かが前へ進むことを助けようとしている人を助けてほしい、そういうことはステージでは話しませんでした。まだ、自分ができていないというのもありますし、みんなの前で話すには少し恥ずかし過ぎました。もう少し自信がでてきたら、個別にもっとていねいに伝えたいと思っています。

札幌Ruby会議03

札幌Ruby会議03では、しまださんがよく使う「感極まった」を、多くの参加者も使っていました。冗談の意味合いも多くあるでしょうが、これは、参加者がしまださんと同じ視点に立ったからではないかと思っています。しまださんの想いが伝わったのだと思います。しまださんの発表者紹介はとても想いがこもっていますが、参加者も同じくらい想いをこめて誰かを紹介できるようになっているのではないでしょうか。だとしたら、これはとてもステキなことです。

ところで、札幌由来の人たちは頑張りすぎではないでしょうか。彼らを助けることができるようになりたいと思います。

先輩芸人より。

ツイートする

フォローする

「全文検索エンジンgroongaを囲む夕べ #1」のRuby枠の資料公開

先月の29日に、全文検索エンジンgroongaを囲む夕べ #1が開催されました。内容はgroonga本体について、groongaとRubyについて、groongaとMySQLについて、groongaとPostgreSQLについて、とgroonga三昧の内容でした。

groongaとRubyについての資料は以降で紹介します。groongaとPostgreSQLについてはすでに資料が公開されています（textsearch groonga v0.1）。参加できなかった方は参考にしてください。

それでは、groongaとRubyについての資料を簡単な解説付きで紹介します。

Ustreamで配信したものの録画もあります。Ruby枠は49分くらいからです。

リリース情報

開催日当日の29日、groongaの新しいバージョン1.0.4がリリースされました。もちろん、この夕べに合わせたものです。

さらに、groongaをRubyから使うためのライブラリrroongaも新しいバージョンがリリースされました。もちろん、これもこの夕べに合わせたものです。

興味がある方はぜひ最新版を利用してください。

話すこと

Rubyからgroongaを使う、ということが実に手になじむということを重点的に話します。これはgroongaをRubyらしく使えるライブラリが提供されているためです。そして、そのライブラリを提供しているのがラングバプロジェクトです。

ラングバプロジェクト

groongaをRubyらしく使えるライブラリや周辺ライブラリ・ツールなど、groongaとRubyに関連するソフトウェアなどを提供しているのがラングバプロジェクトです。WebサイトはRubyForgeにホスティングしてもらっていて、ソースコードはGitHubにホスティングしてもらっています。以降で紹介するライブラリ・ツールはすべてGitHub上にあります。

ラングバプロジェクトの目標は「使いやすい検索システムを手早く、簡単に」実現できるようにすることです。

そのために、ラングバプロジェクトは全文検索システムを提供します。しかし、1つの全文検索システムですべてのケースをカバーすることはできません。そのため、全文検索システムを作るために必要な部品も再利用できる形で提供します。部品を組み合わせることで環境に合わせた全文検索システムを構築することができます。

このようにして「使いやすい検索システムを手早く、簡単に」という目標の実現を目指します。

提供物一覧

まずは、ラングバプロジェクトがどのような名前のライブラリ・ツールを提供しているかを紹介します。それぞれのライブラリ・ツールが全文検索システムのどの部分の機能を提供するかは図で示します。

まず、全文検索システムにはどのような機能があるかを確認しておきましょう。

全文検索システムは、まず、「検索対象」から文書を収集します。これが「クローラー」と呼ばれる機能です。次に、収集してきた文書からテキスト情報やタイトル・更新時刻などといったメタ情報を抽出し、全文検索エンジンに登録します。この文書を登録する機能を「インデクサー」と呼びます。最後に、全文検索エンジンに登録されている文書を簡単・便利にユーザが検索できるインターフェイスが必要です。これが「検索インターフェイス」です。最近はWebアプリケーションとして「検索インターフェイス」を提供することが多いです。

それでは、ラングバプロジェクトが提供する機能の紹介です。

全文検索エンジンgroonga（ぐるんが）をRubyから利用するためのライブラリであるrroonga（るるんが）を提供します。

インデクサーで必要になる、文書からテキストとメタ情報を抽出するライブラリ・ツールがChupaText（ちゅぱてきすと）です。

ChupaTextをRubyのライブラリとして使えるようにするのがChupaRuby（ちゅぱるびー）です。

rroongaをRuby on Rails 3から簡単に使えるようにするのがActiveGroonga（あくてぃぶぐるんが）です。

Rails 3も含むRackアプリケーションで使えるユーティリティを集めたのがracknga（らくんが）です。

これらのライブラリ・ツールを利用した全文検索システムが文書検索ラングバです。プロジェクトが提供するライブラリ・ツールを集結したものなので、プロジェクトと同じ名前が付いています。

それでは、それぞれのツールについて紹介します。

rroonga

rronngaはRubyからgroongaの全文検索エンジンの機能を使えるようにするためのライブラリです。groongaの機能をRubyらしい書き方で書けることを重視したAPIになっていることが特徴です。

例えば、groongaのスキーマを言語内DSLとして書けるようになっています。groonga自体もスキーマを定義するための言語を持っていますが、rroongaではこのように通常のRubyの式としてスキーマを書けるようにしています。Rubyでスキーマを書けるため、新しくgroongaのスキーマ定義用の文法を覚える必要がありません。

検索条件も通常のRubyの式で書けます。Rubyでは「=~」は「マッチさせる」場合に使われる演算子ですが、rroongaでも「マッチ（キーワードを全文検索してキーワードが含まれる文書を返す）」という意味で使っています。自然な書き方ですね。

もう少し複雑な条件も自然に書くことができます。例では「タイトルか説明から本文に"Ruby"と"検索"という単語を含んでいる1ヶ月以内のサイト」を検索しています*1。この条件でもRubyで使われている演算子を同じ意味で使っているので、自然に書くことができます。

検索条件をRubyで指定すると検索が遅くなるのではと思うかもしれません。しかし、その心配は不要です。ブロックの中身は1度だけ評価され、groongaの条件式オブジェクトにコンパイルされます。groongaはそのC言語で記述された条件式オブジェクトを使って検索を行うので、rroongaを使わない場合と同様に高速に検索します。

ORマッパーでは検索条件はSQL文字列を組み立てることに相当しますが、rroongaでは直接groongaの条件式を作ります。検索エンジンがSQL文字列をパースする必要がないため、より少ないコストで検索のための下準備をすることができます。

rroongaは様々な場面で有用です。例えば、データを加工しながらgroongaに登録するインデクサーを作る場合です。サイト検索システムなら各ページで共通のヘッダー部分とフッター部分は検索対象から外したいでしょう。そのとき、Rubyでそのあたりの処理を実装してそのままgroongaに登録できると便利です。

他にも、groongaに入っているデータを利用しながら新しいデータを登録する場合もrroongaを使うと便利です。

rroongaはるりまサーチでも利用されているので、実際にどのように使われているかを調べたいときは、るりまサーチのソースコードを見てください。

rroongaは以下のコマンドでインストールできます。

% sudo gem install rroonga

groongaがインストールされていない場合は自動的にダウンロード・ビルドして利用します。便利ですね。

ChupaText

ChupaTextはテキスト抽出ツールです。「複数の入力形式を1つの操作方法」で扱えることを目標に開発が進められています。

ChupaTextはchupatextコマンドとC言語用のAPIを提供しています。chupatextコマンドは抽出したテキストをMIME形式で出力します。MIME形式を採用したのは以下の理由からです。

• 広く普及している形式である。
• メタデータとテキストを扱える。
  • メタデータはヘッダーとして表現。ヘッダーの項目は拡張可能なこともちょうどよい。
  • テキストは本文として表現。
• 複数のファイルを扱える。アーカイブからテキストを抽出した 場合にこれがうれしくなる。

入力形式はこれからも増えていくでしょう。それに対応するため、ChupaTextは拡張しやすい設計になっています。ChupaText本体を変更しなくても新しい入力形式に対応するためのモジュールを後付けで追加することができます。

現在はC言語で共有ライブラリを作成するか、Rubyスクリプトを作成して、所定の位置に置くことで入力形式を追加することができます。Rubyスクリプトでも拡張できるのは、ChupaText内にRubyインタプリタが組み込まれているからです。

ChupaTextはaptitudeでインストールできます。

% sudo aptitude install chupatext

詳細はChupaTextのインストールドキュメントを見てください。

ChupaRuby

ChupaRubyはChupaTextをRubyのライブラリとして使用できるようにします。ChupaTextをHTTP経由で利用するためのインターフェイスを追加する予定です。これが追加されると、「テキスト抽出Webサービス」を構築することができるようになります。

ChupaRubyは以下でインストールすることができます。

% sudo gem install chuparuby

ChupaTextは自動的にインストールされないので、事前にインストールしておいてください。

ActiveGroonga

ActiveGroongaはRails 3用のモデルライブラリです。groongaをモデルのデータストアとして利用することができます。ActiveRecordが提供しているような以下の機能を提供します。

• ActiveGroonga::Base（ActiveRecord::Base相当）
• rake groonga:*（rake db:*相当）
• ジェネレーション
• マイグレーション
• バリデーション
• リレーション

ActiveGroongaは以下でインストールすることができます。

% sudo gem install activegroonga

ActiveGroongaに関するより詳しいことは別の機会に紹介します。

racknga

rackngaは上記のパッケージに入れるには適切ではないな、というものが詰まっているユーティリティパッケージです。RackのミドルウェアやPassenger用Muninプラグインなどがここに入っています。

rackngaは以下でインストールすることができます。

% sudo gem install racknga

文書検索ラングバ

文書検索ラングバはこれまで紹介したライブラリ・ツールを利用した全文検索システムです。groongaの特徴を活かしたWebベースの検索インターフェイスを提供します。例えば、るりまサーチでも提供しているドリルダウン機能などです。

文書検索ラングバはそろそろリリースされる予定です。もうしばらくお待ちください。

まとめ

groongaのRuby関連の情報を紹介しました。便利なライブラリやツールが充実していっているので、ぜひ、Rubyとgroongaを使って全文検索システムを作ってみてください。

ツイートする

フォローする

Rubyでmilterを作れる - milter manager 1.6.2リリース

（まだMLではアナウンスしていませんが）milter manager 1.6.2をリリースしました。

このリリースではRubyでmilterを書くために必要な機能がすべて実装されました。これまではメールを拒否したり、隔離する機能は提供していたのですが、差出人を変更する、宛先を追加する、本文を変更するなどメッセージを変更する機能は部分的にしか対応していませんでした。このリリースからメッセージを変更する機能も提供されるようになったので、ほとんどのmilterはRubyでも実装できるようになりました。

Rubyでmilterを書くとどのようになるかはhbstudy#15の発表内容で紹介しています。

milter manager 1.6.2のインストール方法・アップグレード方法は以下にまとまっています。

• インストール方法
• アップグレード方法

milter managerを使ってRubyでメールフィルターを作ってみてはいかがでしょうか？

ツイートする

フォローする

「全文検索エンジンgroongaを囲む夕べ #1」のお知らせ

るりまサーチでも使っている全文検索エンジンgroongaとその周辺技術についての勉強会が開催されます。

• 全文検索エンジンgroongaを囲む夕べ #1 : ATND

現時点でもうすでに定員（50名）オーバーの98名が登録していますが、現在、参加人数を増やせるように調整中なので、諦めずに早めに登録しておくことをオススメします。参加人数が増えたときに定員に入れるかもしれませんよ。

内容は以下の通り、現在のgroonga関連のことが網羅できる内容になっています。

• groonga本体について。groongaの前身Sennaとの違いは？
• groongaのRubyバインディングrroongaと関連Rubyライブラリについて。
• groongaのMySQLバインディングgroongaストレージエンジンについて。
• groongaのPostgreSQLバインディングtextsearch_groongaについて。

1ヶ月くらい先ですが、今から楽しみですね。ぐるぐる。

ツイートする

フォローする

git-utilsをGitHubへ移動

git用のコミットメール配信システムであるgit-utilsのリポジトリをGitHubへ移動しました。こんなこともあろうかとGitHubにクリアコードアカウントを取得しておいたのです。

0.0.1以降リリースしていませんが、少しずつ機能を追加していて、GitHubのPost-Receive Hooksを用いたGitHub上のリポジトリのコミットメール配信にも対応しています。tDiaryのコミットメールやgroongaのコミットメールなどがgit-utilsを利用しています。GitHub上のリポジトリでコミットメールを配信したい場合はお問い合わせフォームからご連絡ください。（無償・無保証で対応しています。）

github-post-reciever/以下を利用して自分でPost-Receive Hooksを受け付けるサーバを立ち上げることもできます。具体的な手順のかかれたインストールドキュメントはありませんが、RackアプリケーションなのでPassengerなどを設定したことがある方は問題なく設置できるでしょう。

GitHubに移動したことでforkしたりpull requestを出しやすくなっているので、自由に利用したり変更したりしてください。改良やドキュメント作成などフィードバックは積極的に取り込んでいく予定です。ライセンスはGPLv3 or laterです。

ツイートする

フォローする

hbstudy#15発表資料: milter managerで簡単迷惑メール対策

hbstudy#15でmilterについて発表しました。

公開しているスライドの内容は実際に使ったものと異なっています*1。実際に使ったものや当日の雰囲気などが気になる人はUstreamの録画を観てください。

スライドのPDFやソース、当日使ったmilterなどはスライドページからダウンロードできます。milterはスライドのソースと同じアーカイブに含まれています。

スライドはRabbitというRubyで書かれたフリーソフトウェアで作成しています。Ruby界隈ではとても有名なプレゼンツールなのですが、インフラ界隈ではあまり有名ではないので、当日使ったRabbitの機能を簡単に説明しておきます。

スライドの下にでていたうさぎとかめは、うさぎがページ数を、かめが経過時間を示しています。うさぎが前を走っていればペースが速い、かめが前を走っていれば間に合わない、というようにプレゼンテーションの進み具合が視覚的に一瞬でわかるのがよいところです。「残り7:35」と出てもいい感じで進んでいるのかどうかがわからないですよね。また、タイマー用のテキストがスライドの中にあると不自然ですが、うさぎとかめがスライドの中にいても不自然ではないので、発表者用のビューではなく、表示用のビューに表示することができるのもよいところです。PCの画面とディスプレイの内容を同じ内容にできるので、ディスプレイ側の表示だけおかしくなっている、という状態を防ぐことができます。ただし、聞いている人が発表よりもうさぎとかめの方が気になってしまうという問題があります。ここは発表者の腕でなんとかする必要があります。

また、携帯電話でRabbitを遠隔操作していました。仕組みを図示したのものがとちぎRuby会議02の資料公開にあります。今回も大体これと同じ構成です。処理の流れは以下の通りです。

1. 携帯電話のi-modeブラウザで「次のページへ遷移」リンクを辿る ーHTTP→
2. サーバ上で動いているHTTPサーバ（Rabrick: Rubyで書かれている）がノートPC上のRabbitプロセスの「次のページへ遷移メソッド」をdRubyを使って呼び出す ーdRuby→
3. ーSSHトンネル→
4. ーdRuby→ ノートPC上のRabbitプロセスの「次のページへ遷移メソッド」が呼び出されて、次のページへ遷移

システムとしてはカッコイイのですが、目の前のノートPC上で動いているRabbitを操作するためにインターネットを経由しているので多少タイムラグがあります。

それでは、以下に発表内容を簡単にまとめておきます。省略している部分が気になる場合は上述のUstreamの録画を観てください。

概要

タイトルは「milter managerで簡単迷惑メール対策」でしたが、参加者がそれほどメール環境になじみの深い人ばかりではなさそうだったので、milter managerそのものの話は最後に少しする程度にしました。内容のほとんどはmilter managerがベースとしている技術であるmilterについてです。

milterを言葉や図だけで理解するのは少し大変なので、今回は実際にありうる例を動かしながら理解していきます。

milterについて

milterとはSendmailが作ったメールフィルターの仕組みです。実際には、この仕組みの中で使われるネットワークプロトコルや、メールフィルターを開発するためのAPI、メールフィルターそのもののことも「milter」と呼ぶことがあります。ただ、多くの場合は文脈からどれを指しているかがわかるので、それほど混乱することはありません。

milterは2001年9月にリリースされたSendmail 8.12.0から正式サポートされています。9年の歴史がある枯れた技術といえます。また、SendmailだけではなくPostfixでもサポートされています。Postfixでは2006年6月にリリースされた2.3.0からサポートされ、現時点の最新版2.7.1ではmilterのほとんどの機能がサポートされています。こちらも4年の歴史があり、もう十分に実践に投入できるほど使われています。

つまり、現時点ではmilter*2を用いてメールフィルター機能を実現することは「実験的な試み」ではなく「いくつかある有力な選択肢の1つ」といえます。

しかし、日本語でのmilterの情報が少ないことは事実です。milterに関する英語の情報はmilter.orgに集まっています。milter.orgにはmilter*3を検索する機能や開発者向けの情報なども載っています。

たとえば、Technical Overview - Control Flowに載っている以下の擬似コードを見れば、複数のmilter*4を同時に用いたときにどのような動作になるかはわかります*5。

For each of N connections {
  For each filter
    process connection (xxfi_connect)
  For each filter
    process helo (xxfi_helo)
  MESSAGE:For each message in this connection (sequentially) {
    For each filter
      process sender (xxfi_envfrom)
    For each recipient {
      For each filter
        process recipient (xxfi_envrcpt)
    }
    For each filter {
      process DATA (xxfi_data)
      For each header
        process header (xxfi_header)
      process end of headers (xxfi_eoh)
      For each body block
        process this body block (xxfi_body)
      process end of message (xxfi_eom)
    }
  }
  For each filter
    process end of connection (xxfi_close)
}

日本語でもこれと同じような情報を読むことができれば、milter利用の敷居が低くなるかもしれません。ここでは、実際に動かしながらmilter*6がどのように動くのかを確認していきます。

milterの挙動

上記のmilterの動作フローをざっくりとまとめると、以下のようになります。

• 本文は直列（前のmilterの影響を受ける）
• 本文以外は並列（前のmilterの影響を受けない）
• 詳細な結果は最後に返す

milterは迷惑メール対策に使われることがほとんどです。迷惑メールの手法は複雑化しているので、1つの迷惑メール対策方法で完璧ということは不可能です。複数のmilter（迷惑メール対策方法）を組み合わせて効果的な迷惑メール対策システムを構築する必要があります。

しかし、milterは上記のような動作のため、milter1の結果を使ってmilter2の挙動を変えるということが難しくなっています。milter1の詳細な結果を使いたければ、メール全体の処理が終わるのを待たなくてはいけません。milter2がエンベロープ情報（送信元や宛先）を取得した段階で実行する迷惑メール対策方法*7を採用している場合は、メール全体の処理が終わるまで待つのは効率的ではありません。

milterがどのように動作するかがわかれば、複数のmilterをどのように組み合わせることが効果的かを検討することができます。そのため、milterを用いて効果的な迷惑メール対策システムを構築する場合はmilterの挙動を理解しておく必要があります。

milterの挙動の詳細

miltrの挙動を理解するためには、以下の3つの要素があることを理解するのが早道です。要素の名前はここでの説明のために便宜的に付けたもので、milterで一般的な用語ではないので注意してください。

• ステージ: milterが処理を行うタイミング
• アクション: milterが処理を行ったときにメールサーバに返す結果
• メッセージ変更機能: メールフィルターとして行えること

milterが処理を行うタイミングはSMTPのコマンド+αだけあります。どのようなタイミングかを一言解説を付けています*8。

• connect: SMTPクライアントが接続してきたとき。
• helo: SMTPクライアントがHELO/EHLOコマンドを実行したとき。
• mail from: SMTPクライアントがMAIL FROMコマンドを実行したとき。
• rcpt to: SMTPクライアントがRCPT TOコマンドを実行したとき。
• data: SMTPクライアントがDATAコマンドを実行したとき。
• header: メールサーバがメールのヘッダー1つを解析したとき。ヘッダーの数だけn回発生する。
• end of header: メールサーバがメールのヘッダーをすべて解析し終わったとき。
• body: メール本文を処理しているとき。
• end of message: メール全体を処理したとき。

「メッセージ変更機能」は「end of message」のときしか実行できません。「メッセージ変更機能」は後述します。

milterは処理を行うたびにメールサーバに結果を返さないといけません。メールサーバに返せる結果は以下の通りです。

• continue: 処理を続行する。普通はこれ。
• accept: 受信する。このmilterは以降の処理を行わない。
• reject: メールを受信拒否する。SMTPレベルでは500番台の受信拒否になる。
• tempfail: メールを一時受信拒否する。SMTPレベルでは400番台の受信拒否になる。
• discard: メールを受信するが、配送せずにそのまま廃棄する。このmilterは以降の処理を行わない。
• quarantine: メールを受信するが、配送はしない。（本当はアクションではないので、end of messageステージのときしか使えない。）

以下のようなメッセージ変更機能があります。メールフィルターとしては十分な機能です。

• From変更
• To追加
• To削除
• 本文変更
• ヘッダー追加
• ヘッダー削除
• ヘッダー変更

それでは、以下、実例を元に実際の動作を確認します。

ケース1: mail fromでaccept

実例は5つ用意しましたが、ここでは1つだけ紹介します。他はスライドやUstreamの録画を観てください。

mail fromステージでacceptアクションを返した場合です。SMTP Authをしている場合は何も処理をしないmilterが多くあります。その場合はこのような動作になります。

mail fromステージでacceptアクションを返すmitlerはRubyで実装するとこのようになります。これはスライドのアーカイブの中のmilters/milter-accept.rbに入っています。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

require 'milter'

class MilterAccept < Milter::ClientSession
  def envelope_from(from)
    p from
    accept
  end

  def envelope_recipient(to)
    p to
  end
end

command_line = Milter::Client::CommandLine.new
command_line.run do |client, _options|
  client.register(MilterAccept)
end

このとき、SMTPクライアントがRCPT TOコマンドを送ったらどうなるでしょうか。

この場合、milterはacceptを返しているのでメールを受信します。ただし、SMTPクライアントがMAIL FROMより後のRCPT TO以降のコマンドを送ってもmitler側では何も起こりません。それ以降のステージではメールサーバがmilterに通知しないからです。

発表時には実際にSMTPを話しながら動作を確認しています。この様子はUstreamの録画を観てください。また、他の例もUstreamの録画やスライドページを見てください。

milter managerが便利なところ

例を使ってmilterの動作を確認した通り、milterを連携させることが難しいケースがあります。milter managerを使うことでそこを補うことができます。

例えば、「milter評価モード」機能を使うことによって、「milter1がreject/temp failを返した」という情報をmilter2で利用することができます。通常はend of messageまで待たなければ情報を利用することができませんが、reject/temp failはどのステージでも利用することができるので、もっと早い段階で情報を利用することができます。

以下、milter managerの利用例を1つ紹介します。他の利用例などはまた別の機会にでも紹介できるとよいですね。

milter managerを使うことによってユーザ毎に迷惑メール対策方法を変えることができるシステムを構築することができます。例えば、MySQLにユーザ毎の設定を格納しておきます。格納した情報は各milterではなくmilter managerが参照してmilterの挙動を動的に制御します。各milterがそれぞれMySQLの情報を参照するようなシステムにすることもできますが、そうすると、複数のmilterを使う場合に大変です。それぞれのmilterがMySQLに対応し、さらに、MySQL内の情報をどのように使うかを判断しなければいけません。milter managerを使うことにより、その部分を一括管理することができます。

まとめ

迷惑メールが多様化しているため、複数のmilterでそれに対応する必要があります。ただし、複数のmilterを利用した場合の挙動は少し複雑です。まるで理解しがたいというものではなく、少し落ち着いて考えれば理解できるものなので、milterを利用する場合は一度くらいは落ち着いてmilterの挙動を確認しましょう。

複数のmilterを利用する場合はmitler managerも一緒に導入するとより便利です。

宣伝1: クリアコードではプログラミングが好きな開発者を2名募集中です。興味がある人は応募してみてください。よさそうな人を知っていたら教えてあげてください。

宣伝2: クリアコードの開発者は全員オープンソースソフトウェアの開発に関わって磨いてきた技術力を持っています。オープンソースソフトウェアに関して技術的にお困りのことがあったらぜひご相談ください。もちろん、milterに関することもOKです。

ツイートする

フォローする

メタプログラミングRuby

日本Ruby会議2010でA Metaprogramming Spell BookというタイトルのRubyの魔術の話がありましたが、それはこの本の内容がベースになっています。

メタプログラミングRuby
Paolo Perrotta/角征典
アスキー・メディアワークス
￥ 2,940

Rubyはとても動的な言語で、ほとんどのことが実行時に決まります。このRubyの特徴はメタプログラミングと非常に相性がよいのです。「メタプログラミングとは、コードを記述するコードを記述すること」です。プログラムを実行して動的にプログラムを作っていくのです。

1冊まるごとRubyのメタプログラミング機能について書いてあります。RailsでWebアプリケーションが作れるようになってきて、少し余裕がでてきた人あたりにあっているのではないでしょうか。Railsはよくも悪くもメタプログラミングしまくっています。少しレールを外れたことをしようとしたらRailsの中に飛び込んで中を調べるようになるでしょう。そのとき、この本に書いてあることが役に立つでしょう。

この本のすごいところは、訳がとてもこなれていて読みやすいことと、サンプルコードがきちんと整形されていて読みやすいことです。

訳はMartin Fowler's Blikiの翻訳でお馴染みの角さんなので安心して読めるのは驚くことではありませんね。

コードがきちんとインデントされていて、スタイルが一貫しているのはとても好感が持てます。プログラミング関連の書籍にはきちんと整形されていなくて汚いソースコードが載っていることがあります*1が、コードもきれいに整形できない人が書いていることを誰が信用できるでしょうか。いくら役立つことを書いていたとしても、いくらすごいことをするプログラムであっても、信用することはできません。

この本は、日本語としてもRubyとしても読みやすくできているため、内容に集中することができます*2。Rubyのメタプログラミングについて知りたくなったら信用できるこの本を読んでみるとよいでしょう。Rubyをちゃんと知って、信用できるようになれば、「ダークサイド」に堕ちることもないでしょう。

ツイートする

フォローする

日本Ruby会議2010発表資料: るりまサーチの作り方 - Ruby 1.9でgroonga使って全文検索

注: 長いです。

日本Ruby会議2010でるりまサーチの作り方について発表しました。

2010-08-30 再生: 210 コメント: 20 マイリスト: 5

[rk10][29S06] るりまサーチの作り方 - Ruby 1.9でgroonga使って全文検索 (32:59) Kouhei Sutou (ClearCode Inc. / COZMIXNG)このトークではるりまサーチについてとるりまサーチの作り方について話します。るりまサーチはRubyリファレンスマニュアル刷新計画の成果物であるRubyのリファレンスマニュアルを高速に検索するWebアプリケーションです。るりまサーチはRubyインタプリタとしてRuby 1.9.1（MRI）、全文検索エンジンとデータストアとしてgroonga、Rubyとgroongaのインターフェイスとしてrroongaを使っています。作り方の説明では、特にこれらの技術の使い方について詳しく説明します。るりまサーチ: http://rurema.clear-code.com/ すごー buzztterはgrongaを使 rackngaが便利そう 検索:rrooonga HTTPでも出来るー 検索selec...

ステージから見た感じだと立ち見の人もいたようでした。セッションに参加してくれたみなさん、会場を担当してくれたりレポートしてくれたスタッフのみなさん、ありがとうございました。

時間の関係で省略したことも含めてまとめておきます。

話すこと

資料の中では、まず、るりまサーチについて説明し、その後、全文検索システムとしてのるりまサーチをどう作るのかを説明しています。

るりまサーチとは

るりまサーチはRubyリファレンスマニュアル刷新計画 (通称るりま)の成果物であるRuby本体のリファレンスマニュアルを全文検索するためのWebアプリケーションです。るりまサーチが必要とされていた理由は、既存のリファレンスマニュアル閲覧Webアプリケーションに組み込まれていた検索機能の速度が遅かった*1からです。せっかく有益なリファレンスマニュアルがあっても、目的のエントリにたどりつくのが難しければ、有効に活用することができません。検索機能の面からリファレンスマニュアルの有効活用を支援する全文検索システムがるりまサーチです。

ポイント: ドリルダウン

るりまサーチはRubyのリファレンスマニュアルに特化した小さな全文検索システムですが、最近の全文検索システムにとって重要なエッセンスが含まれています。全文検索システムを開発する場合はこれらのエッセンスを含めることを検討してみてください。

まず1つ目はドリルダウンと呼ばれる機能です。Solrなど他の全文検索システムによってはファセットと呼ぶこともあります。ドリルダウンとは、通常の検索結果に加えて、別のパラメータでの絞り込み結果も同時に提供する機能です。スライド中では「Rubyのバージョンで絞り込んだ結果、何件ヒットするか」という情報も表示しています。

この機能で嬉しいことは以下の2点です。

• 検索キーワードを入力しなくてもクリックだけで結果を絞り込んでいける。
• 絞り込み結果が0件になる条件を除外するので、「絞り込んだ後に0件ヒットになる」無駄な条件を指定せずに済む。

どちらもユーザの使い勝手を向上させるインターフェイスにつながります。ショッピングサイトなどでも使われているインターフェイスですね。

ポイント: URL

2つ目はURLのパスに絞り込み条件を含めることです。これは、内部ネットワーク用の全文検索システムではなく、インターネット上に公開する全文検索システム向けです。

最近ではURLにUTF-8でエンコードされたページ情報を含めることは一般的になってきました。WikipediaやAmazonでも行っています。Web検索エンジンはURLからも検索用の情報を抽出しているようなので、SEOになると考えられます。

ポイント: キャッシュ

3つ目はキャッシュです。より快適に検索・絞り込みを行うにはできるだけ速いレスポンスが求められます。レスポンスを高速化するためには、以下のような方法があります。

• アルゴリズムを改良し、少ない計算量で結果を計算できるようにする。
• 同じ結果を返す処理の処理結果を保存して、2回目以降の処理で結果を再利用する。

手軽に高速化する場合は後者のキャッシュ機能が便利です。キャッシュをする場合はキャッシュを無効化するタイミングを慎重に検討する必要があります。このタイミングを誤ると、期待した結果が返ってこないという問題が発生します。

キャッシュを無効にするタイミングはアプリケーションに依存します。一般的に、データが変更されるまでは同じキャッシュを利用できます。るりまサーチの場合は1日1回バッチ処理で元データを更新しています。そのため、同じキャッシュを1日使いまわすことができます。これにより高速にレスポンスを返すことができます。

また、キャッシュの効果を高めるためには、処理の内部よりもクライアントに近いところでキャッシュする必要があります。その方がより多くの計算を省略することができるからです。るりまサーチはログインせずに使えるシステムなので、同じ検索リクエストの結果はクライアントに関わらず同一になります。そのため、レスポンスをまるごとキャッシュすることができ、とても高い効果があります。

ログインが必要なシステムの場合は、クライアント毎に変更される部分のみJavaScriptで動的に生成したり、iframeを用いて別HTMLにすることにより、ログインによって変更されない部分ではキャッシュを利用することができます。それが難しい場合はもっと処理の内部でキャッシュをすることになります。この場合はキャッシュの効果が薄くなります。

キャッシュを用いることにより劇的にレスポンス速度を改善することができますが、キャッシュの有効期限とキャッシュする場所についてはよく検討する必要があります。

ポイント

るりまサーチに含まれている最近の全文検索システムに重要なエッセンスは以下の3つです。

• ドリルダウン
• URLに検索条件を含める
• キャッシュ

それでは、このようなエッセンスを含む全文検索システムるりまサーチの作り方について説明します。

全文検索システム

全文検索システムは以下の5つの要素からなります。

• 検索対象
• クローラー
• インデクサー
• 全文検索エンジン
• 検索インターフェイス

まず、検索対象からクローラーが検索対象とする文書を収集します。次に、それらからインデクサーがテキストやメタ情報を抽出して全文検索エンジンに登録します。全文検索エンジンに登録したデータからユーザが求めるデータを検索して提示するのが検索インターフェイスです。

るりまサーチの場合

るりまサーチの場合は以下のようになります。

検索対象

リファレンスマニュアル。

クローラー

リファレンスマニュアルはリポジトリからチェックアウトするので必要なし。

インデクサー

BitClustに含まれる機能を使ってリファレンスマニュアルの情報を全文検索エンジンに登録する。新規開発。

全文検索エンジン

groonga。

検索インターフェイス

Ruby 1.9とRackを用いたWebインターフェイス。新規開発。

この中で、るりまサーチの重要な部分である全文検索エンジンgroongaについて説明します。

groonga: 特徴

発表当日に初のメジャーバージョン1.0.0がリリースされたgroongaは、MySQLとの組み合わせで広く利用されているSennaの後継プロジェクトです。Sennaでのよいところを維持しつつ、さらに改良が加えられています。

Sennaは妥協しない転置索引実装と参照ロックしない更新アルゴリズムによるリアルタイム検索の実現が大きな特徴でした。Senna自体はデータストア機能を持たず、MySQLなど外部のデータストアと連携します。MySQLとSennaを連携させるソフトウェアはTritonnと呼ばれ、SQLで高速な全文検索機能を利用できることから広く使われています。しかし、MySQL側のロックモデルのため常に検索可能な状態で更新処理を行うことができません。そのため、せっかくのSennaの参照ロックフリーな更新アルゴリズムの特徴を活かしきれませんでした。

そこで、groongaでは独自のデータストア機能を提供し、外部のシステムによる制限を回避してgroongaの性能を発揮できるようにしました。データストアはドリルダウンを高速に実現できるカラム指向を採用しています。

また、HTTP/memcached/独自プロトコルなどのネットワークプロトコルも実装し、Solrのように検索サーバとして利用することもできるようになっています。

その他にも、より大規模な文書に対してもスケールするような性能改善や、モバイル端末の普及により重要性が増している位置情報データに対応するなど新規機能が含まれています。ただし、これらの改善のためにSennaとの互換性がなくなっています。Sennaの後継としてgroongaと名前を変更した理由はこのためです。

定義例: るりまサーチ

それでは、るりまサーチのケースを例にしてgroongaの使い方を説明します。手順は以下の通りです。

1. スキーマ定義
2. データ登録
3. 検索

RDBと同じようにgroognaでも、まず、スキーマを定義します。

スキーマはRDBと同じように以下の3つの要素から構成されます。

• テーブル
• カラム
• 型

RDBではさらに索引もでてきますが、groongaでは↑の3つの要素を使って索引を作成するので、RDBより特別な存在ではありません。

スキーマを定義するときは、まず、検索対象がなにかを考えます。そして、その対象がどのくらいの粒度で1エントリになるかを考えます。るりまサーチではリファレンスマニュアルが検索対象で、メソッドやクラスそれぞれが1つのエントリになります。検索対象全体をテーブルとし、エントリをテーブルの各レコードにします。るりまサーチでは検索対象全体を扱う「Entries」テーブルを定義しています。

テーブルには検索結果に表示したい内容と検索時に利用する内容をカラムとして定義します。るりまサーチの場合にはメソッド名やクラス名を格納する「name」カラムやドキュメントを格納する「description」カラムなどを定義しています。

検索対象用のテーブルを定義したら索引を定義します。ここがRDBと異なる部分です。全文検索用の索引では単語と文書を対応させる語彙表が必要になりますが、同じトークナイザー*2を利用している場合は同じ語彙表を共有して省スペース化したり、同じテキストに複数のトークナイザーを適用して検索精度や検索漏れのトレードオフを調整したり、といったRDBよりも細かい制御ができます。

単にヒットしたかどうかではなく、検索結果の重み付けも重要です。有用な検索結果を提供するためには、クエリに適していると思われる結果ほど上位に提示する必要があります。しかし、どのように重み付けをするのが適切かは全文検索システムに大きく依存します。そのため、groongaでは索引毎に重み付けをカスタマイズする機能を提供しています。

るりまサーチではメソッド名やクラス名に完全一致した場合はよりマッチしていると判断するように*3、名前と完全一致だけする語彙表「Names」テーブル*4を定義し、そこに「name」カラムの索引を定義します。検索時にはこの索引にマッチした場合は重み付けを大きくします。

ドキュメント部分（「summary」カラムと「description」カラム）はトークナイザーを設定した全文検索用の語彙表「Terms」テーブルを共有しています。こっちの索引にマッチした場合は重み付けを小さくします。

スキーマはgroongaが提供している組み込みのDDLで定義する方法と、groongaのRubyバインディングであるrroongaが提供するDSLで定義する方法があります。

groongaのDDL:

# 検索対象のテーブル
table_create Entries TABLE_HASH_KEY ShortText
# 全文検索用の語彙表。トークナイザーとしてN-gramを使用。
table_create Terms TABLE_PAT_KEY ShortText --default_tokenizer TokenBigram
# 完全一致検索用の語彙表。トークナイザーはなし。
table_create Names TABLE_HASH_KEY ShortText

# 検索対象のデータ格納場所
column_create Entries name COLUMN_SCALAR Names
column_create Entries summary COLUMN_SCALAR Text
column_create Entries description COLUMN_SCALAR Text

# 全文検索用の索引
column_create Terms Entries_summary COLUMN_INDEX Entries summary
column_create Terms Entries_description COLUMN_INDEX Entries description

# 完全一致検索用の索引
column_create Names Entries_name COLUMN_INDEX Entries name

rroongaのDDL:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32

Groonga::Schema.define do |schema|
  # 完全一致検索用の語彙表。トークナイザーはなし。
  schema.create_table("Names",
                      :type => :hash,
                      :key_type => "ShortText") do |table|
  end

  # 検索対象のテーブル
  schema.create_table("Entries",
                      :type => :hash,
                      :key_type => "ShortText") do |table|
    table.reference("name", "Names")
    table.text("summary")
    table.text("description")
  end

  # 全文検索用の語彙表。トークナイザーとしてN-gramを使用。
  schema.create_table("Terms",
                      :type => :patricia_trie,
                      :key_type => "ShortText",
                      :default_tokenizer => "TokenBigram",
                      :key_normalize => true) do |table|
   # 全文検索用の索引
    table.index("Entries.summary")
    table.index("Entries.description")
  end

  schema.change_table("Names") do |table|
    # 全文検索用の索引
    table.index("Entries.name")
  end
end

登録例: るりまサーチ

スキーマを定義したらデータを登録します。索引は自動で更新されるため、データ用のカラムにデータを登録するだけで動作します。

データの登録方法はgroongaのloadコマンドを使う方法と、rroongaを使う方法があります。

groongaのloadコマンド:

load --table Entries
[
  ["_key", "name", "summary", "description"],
  ["String#sub", "sub", "置換", "1つ置換"],
  ["String#gsub", "gsub", "置換", "全部置換"]
]

rroonga:

1
2
3
4
5
6
7
8
9

entries = Groonga["Entries"]
entries.add("String#sub",
            name: "sub",
            summary: "置換",
            description: "1つ置換")
entries.add("String#gsub",
            name: "gsub",
            summary: "置換",
            description: "全部置換")

Rubyで登録データの前処理を行う場合はrroongaを使う方がよいでしょう。Ruby以外で処理を行う場合はデータからJSONを生成し、groongaのloadコマンドを使う方がよいでしょう。るりまサーチはRubyで前処理*5をしているのでrroongaでデータを登録しています。

検索例: るりまサーチ

全文検索する場合は検索対象のカラムを指定する方法と、明示的に利用する索引を指定する方法の2通りあります。カラム単位で重み付けをしたい場合はカラムを指定し、索引単位で重み付けをしたい場合は索引を指定します。両方の指定方法を混ぜ合わせることもできます。

データの登録方法はgroongaのselectコマンドを使う方法と、rroongaを使う方法があります。

groongaのselectコマンド:

# 「description」カラムに「1つが」含まれているエントリを検索
select Entries description "1つ"
[[...],
 [[[...],
   [..., ["_key", ...], ["name", ...], ["summary", ...], ["description", ...], ...]],
  [..., "String#sub", "sub", "置換", "1つ置換", ...],
  ...]]
# 「sub」が含まれているエントリを検索。ただし、「name」が
# 「sub」だった場合は重みを大きくする。
select Entries "name * 100 | summary | description" "sub"
[[...],
 [[[...],
   [..., ["_key", ...], ["name", ...], ["summary", ...], ["description", ...], ...]],
  [..., "String#sub", "sub", "置換", "1つ置換", ...],
  ...]]

groongaのselectコマンド（HTTP経由）:

# 「description」カラムに「1つが」含まれているエントリを検索
% wget -O - 'http://localhost:10041/d/select?table=Entries&match_columns=description&query=1つ'
[[...],
 [[[...],
   [..., ["_key", ...], ["name", ...], ["summary", ...], ["description", ...], ...]],
  [..., "String#sub", "sub", "置換", "1つ置換", ...],
  ...]]
# 「sub」が含まれているエントリを検索。ただし、「name」が
# 「sub」だった場合は重みを大きくする。
% wget -O - 'http://localhost:10041/d/select?table=Entries&match_columns=name*100|summary|description&query=sub'
[[...],
 [[[...],
   [..., ["_key", ...], ["name", ...], ["summary", ...], ["description", ...], ...]],
  [..., "String#sub", "sub", "置換", "1つ置換", ...],
  ...]]

rroonga:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

entries = Groonga["Entries"]
# 「description」カラムに「1つ」が含まれているエントリを検索
result = entries.select do |record|
  record.description =~ "1つ"
end
# 「sub」が含まれているエントリを検索。ただし、「name」が
# 「sub」だった場合は重みを大きくする。
result = entries.select do |record|
  target = record.match_target do |match_record|
    (match_record["name"] * 100) |
      (match_record["summary"]) |
      (match_record["description"])
  end
  target =~ "sub"
end

PHPなどRuby以外の言語から利用する場合はgroongaサーバを立てて、HTTP経由で検索するのがよいでしょう。Rubyから利用する場合は、selectコマンドで十分ならselectコマンドを利用、より複雑なことをしたい場合はrroongaを利用するのがよいでしょう。selectコマンドでもドリルダウンはサポートされて入るので、多くの場合はselectコマンドで十分でしょう。

るりまサーチでは、selectコマンドが提供するクエリ書式を利用したくない、rroongaが提供するページネーション機能を利用したい、などの理由でselectコマンドではなくrroongaを使っています。rroongaを利用してドリルダウンを実現する例にもなっています。

るりまサーチを例にして、groongaを用いて全文検索システムを開発する場合の基本的な流れを説明しました。より詳しいことはGitHubのるりまサーチのリポジトリにあるソースコードを見てください。

racknga

るりまサーチの検索WebインターフェイスはRuby 1.9とRackの上に構築されています*6。るりまサーチを開発した際に、るりまサーチ以外でも使えそうな部分がでてきたので、rackngaという名前でるりまサーチと別パッケージとして公開しています。

rackngaにはRackのミドルウェアとMuninプラグインが含まれています。MuninのプラグインはPassengerの以下の情報を収集します。

• 処理したリクエスト数
• 処理中のリクエスト数
• プロセスの状態
• プロセスの起動時間

Rackのミドルウェアは1つずつ説明します。

エラー通知

アプリケーション内でエラーが発生した場合にメールでその内容を通知するミドルウェアです。RailsのException NotifierのRack用です。

以下のように利用します。

config.ru:

1
2
3
4
5
6
7
8
9
10
11
12
13

require 'racknga'

notifier_options = {
  "host" => 127.0.0.1,
  "from" => "rurema@example.com",
  "to" => "developer@example.com",
  "charset" => "iso-2022-jp",
  "subject_label" => "[るりまサーチ] ",
}
notifiers = [Racknga::ExceptionMailNotifier.new(notifier_options)]
use Racknga::Middleware::ExceptionNotifier, :notifiers => notifiers
# ...
run your_application

できるだけ多くのエラーを検出するためになるべく最初の方でuseしてください。

キャッシュ

主にサーバ1台や2台などで処理できる程度の中規模のPassenger環境で利用することを想定したキャッシュミドルウェアです。ヘッダーやボディを含めHTTPのレスポンス全体をgroongaのデータストアにキャッシュします。Passengerでは複数のインスタンスが別プロセスで起動しますが、groongaは複数プロセス間で同一のデータベースを操作することができるため、別のインスタンスがキャッシュした内容を他のインスタンスから参照することができます。以下のように利用します。

config.ru:

1
2
3
4
5
6
7
8
9
10
11

require 'racknga'
require 'racknga/middleware/cache'

# ...
# use Rack::Deflater
# use Rack::ConditionalGet
# ...
base_dir = Pathname.new(__FILE__).dirname.cleanpath.realpath
cache_database_path = base_dir + "var" + "cache" + "db"
use Racknga::Middleware::Cache, :database_path => cache_database_path.to_s
run your_application

他のミドルウェアと組み合わせやすいように、なるべくアプリケーションに近い部分に置くことをよいでしょう。

複数のサーバ間でキャッシュを共有したい場合は別の仕組みを利用することをオススメします。

条件付き圧縮

ネットワーク帯域を節約するためには、レスポンスを圧縮して返すことが有効です。しかし、Internet Explorer 6では問題があることがわかっています。そのため、Internet Explorer 6の場合は常に圧縮しないようにするのがこのミドルウェアです。Rack::Deflaterのラッパーです。以下のように利用します。

config.ru:

1
2
3
4
5
6
7

require 'racknga'

# ...
use Racknga::Middleware::Deflater
# use Rack::ConditionalGet
# ...
run your_application

JSONP

Web APIとしてサービスを提供する場合、JSON形式で結果を返すことが多くなっています。クライアント側でWeb APIにアクセスする場合はJSONPを利用することになります。

このミドルウェアはJSONPに対応しておらず単にJSONデータを返すだけのアプリケーションをJSONPに対応させることができます。また、以下のような配置にすることにより、キャッシュを有効にしたままJSONP対応にすることができます。

config.ru:

1
2
3
4
5
6
7
8
9
10

require 'racknga'
require 'racknga/middleware/cache'

use Rack::Middleware::JSONP

base_dir = Pathname.new(__FILE__).dirname.cleanpath.realpath
cache_database_path = base_dir + "var" + "cache" + "db"
use Racknga::Middleware::Cache, :database_path => cache_database_path.to_s

run your_application # "Content-Type: application/json"のレスポンスを返す

現在、るりまサーチはWebサービスを提供していませんが、将来の拡張を念頭においてこのミドルウェアがrackngaに含まれています。

まとめ

るりまサーチはドリルダウンやキャッシュを利用することにより、快適に目的のドキュメントへ到達できるような工夫をしています。るりまサーチ以外にもリファレンスマニュアルを利用するツールがあるので有効活用しましょう。

ドリルダウンを効果的に利用した高速な全文検索システムにはgroongaが適しています。Rubyとの親和性も高いgroongaで全文検索システムを開発してみてはいかがでしょうか。汎用ユーティリティであるrackngaも一緒に用いることにより開発・運用が改善されるでしょう。

最後にお知らせです。クリアコードではプログラミングが好きな開発者を募集しています。プログラミングが好きな人は検討してみてください。

ツイートする

フォローする

プログラミングRuby 1.9

前作プログラミングRubyのRuby 1.9対応版です。

前作: プログラミングRuby 第2版 言語編
Dave Thomas/Chad Fowler/Andy Hunt/田和 勝/まつもと ゆきひろ
オーム社
￥ 3,990
プログラミングRuby 第2版 ライブラリ編
Dave Thomas/Chad Fowler/Andy Hunt/田和 勝/まつもと ゆきひろ
オーム社
￥ 4,410

このシリーズはページ数からもわかる通り、Rubyについて細かいところまで網羅しているのが特徴です。例えば、Proc.newとlambdaの違いはわかりますか？以下のようなクラス定義の書き方による参照解決の違いはわかりますか？

1
2
3
4
5
6
7
8
9

module MyLibrary
  class MyClass
    # ...
  end
end

class MyLibrary::MyClass
  # ...
end

これまでのシリーズと同様、本書でもそのあたりの細かいところにも触れています。もちろん、1.8と1.9で変わった部分についても触れています。このシリーズでRubyを覚えたという人もわりといるようですが、それはこの網羅性が役に立ったのではないでしょうか。

おそらく、1回読んだだけではすべてを覚えることは無理でしょう。読んで、実際にRubyのコードを書いて、気になったところをまた調べ直す、そのサイクルができるのがこのシリーズです。このシリーズでRubyを覚えた人はこのようなサイクルを使ったのではないでしょうか。先日1.9.2がリリースされ、これから1.8から1.9への移行がより進むと考えられます。そのときに、つまずいたところを本書で調べて理解していくというサイクルに使えるでしょう。

Rubyは（わりと）読みやすいコードを（わりと）書きやすい言語仕様になっています*1が、複雑なこともいろいろできる仕様も多く含まれています。ほとんどの場合は複雑なことはしなくても済むはずですし、そのように書いておく方がよい場合の方が圧倒的に多いです。一度、（わからない部分があったとしても）全体を一通り読んでおいて、Rubyの動作はどうなっているかをざっくりと知っておくとよいでしょう。複雑なことをしそうになったときに、別の方法もあった気がする、と気付けるようになるくらいで十分です。気付けたら本書なりるりまなりで詳しく調べることができます。

本書は分量の多さから言語編とライブラリ編の2編構成になっています。言語編に比べてライブラリ編の内容が手薄になっているので気をつけてください。必ずしもそれぞれのライブラリの最新の情報に追従できているわけではありません。本書をきっかけにしてるりまやWeb上での情報などで補正する必要があるでしょう。

試しにRubyを勉強してみたい、という人には敷居が高いでしょう*2。しかし、Rubyを使いこなそうというくらいの気持ちがあるのであれば、助けになってくれることでしょう。

プログラミングRuby 1.9 −言語編−
Dave Thomas with Chad Fowler and Andy Hun/まつもとゆきひろ/田和 勝
オーム社
￥ 3,990
プログラミングRuby 1.9 −ライブラリ編−
Dave Thomas with Chad Fowler and Andy Hunt/まつもとゆきひろ/田和 勝
オーム社
￥ 4,620

ツイートする

フォローする

名札には名前を大きく書きましょうジェネレータ改: cairoとPangoでPDF生成

早いもので来週末は日本Ruby会議2010です。日本Ruby会議では、たくさんいる（会ったことはないけど名前を知っている）参加者がお互いを認識しやすいように大きな名札をつけることが恒例となっています。

RubyKaigi日記でも名札には名前を大きく書きましょうと呼びかけています。この中で、「あらかじめ太くて大きなフォントで、黒々と印刷してきたものを持参して、名札に貼り付けるのはいかがでしょう。」と提案しています。しかし、自分でデザインするのはわりと面倒なものです。

そこで、kdmsnrさんが名札には名前を大きく書きましょうジェネレータを作りました。これはtwitter IDを指定するだけでRubyKaigi日記で提案されているようなデザインの画像を生成してくれます。

でも、印刷するならPDFの方が嬉しいよね、ということでPDFを出力できるように改造したのが名札には名前を大きく書きましょうジェネレータ改です。

PDFも出力できるようにした他に、フォントを選べたり、細かく調整するためにSVGも出力できるようにしています。それでは、どのように実現しているかを説明します。

使っているもの

描画にはcairo、文字の配置にはPango、画像の読み込みにはGdkPixbufを用いています。どれもLinux、*BSD、Mac OS X、Windowsなど多くの環境で動作するライブラリです。ここでは、cairoとPangoだけ説明します。

cairo

cairoは2次元グラフィックを生成するためのライブラリで以下のような特長があります。

• ベクトルベースのAPI
• 描画処理のコードを変更せずに出力先を変えることができる

ベクトルベースのAPIとなっているということは品質を落とさずに拡大・縮小ができるということです。ジェネレータ改では、実際のサイズの画像とサムネイル画像を生成しますが、このようなことが以下のように描画処理を変更せずに実現できます。

1
2
3
4
5
6
7
8
9
10

def render(context)
  # 実際のサイズの描画
end

# 実際のサイズを描画するとき
render(context)

# 1/3サイズのサムネイルを描画するとき
context.scale(1 / 0.3, 1 / 0.3) # 描画処理の前にこれを呼ぶだけでOK
render(context)

描画処理のコードを変更せずに出力先を変えることができると、描画結果はPNGにしてブラウザで確認、印刷するときはPDF、編集する時はSVG、というように用途にあわせたグラフィックのフォーマットを提供することが簡単にできるということです。これは今回のようなWeb上で印刷物を生成する場合はとても便利な機能です。いちいちPDFで確認するのは面倒ですよね。サムネイルで一覧表示する場合もPNG+ブラウザの方が便利です。

cairoの詳しい使い方はRubyist Magazine - cairo: 2 次元画像描画ライブラリを見てください。

Pango

Pangoは多言語に対応したテキストの配置を行うライブラリです。フォントの扱いなどテキストの配置に関することを抽象化してくれるので、TTFやOTFなどフォントフォーマットの違いや、フォントファイルをどこに置くかなどをプログラム側で気にする必要がありません。

ジェネレータ改ではインストールされているフォントを列挙したり、できるだけ大きいテキストサイズを自動検出するためにPangoを利用しています。テキストを中央揃えにするのもPangoの機能を利用しています。

システムにインストールされているフォントの一覧は以下のように取得できます。

1
2
3
4

font_families = Pango::CairoFontMap.default.families.collect do |family|
  family.name
end
p font_families # => ["Mona", "梅明朝S3", "衡山毛筆フォント草書", ...]

残念ながらPangoを利用するためのまとまった日本語の資料はありません。興味のある人はソースコードを見てください。

まとめ

名札には名前を大きく書きましょうジェネレータ改をネタにしてcairoとPangoを紹介してみました。cairoとPangoはFirefoxやGTK+などデスクトップで使われることが多いライブラリですが、Webアプリケーションのようにサーバサイドでも有用なライブラリです。ジェネレータ改のように用途にあわせて画像のフォーマットを使い分けたい場合は、cairoとPangoを使ってみてはいかがでしょうか。また、日本Ruby会議2010に参加する人はジェネレータで作った名札を印刷して持っていってはいかがでしょうか。

名札には名前を大きく書きましょうジェネレータ改のソースコードはGitHubにあります。

ツイートする

フォローする

日本Ruby会議2010で発表します: るりまサーチの作り方 - Ruby 1.9でgroonga使って全文検索

毎年開催規模が大きくなっている日本Ruby会議に今年も参加します。今年も去年と同じくスポンサーと発表者として参加します。

発表タイトルは「るりまサーチの作り方 - Ruby 1.9でgroonga使って全文検索」です。

内容

発表内容はるりまサーチという、Rubyリファレンスマニュアル刷新計画 (通称るりま)の成果物であるRubyのドキュメントを全文検索するWebアプリケーションの関連技術を紹介するというものです。もう少し具体的にいうと以下のような話題になります。

• 全文検索エンジンgroongaを用いた検索サイトの作り方
  • 「情報を絞り込む」を主体としたユーザインターフェイス
  • 高速に検索するためのデータの持ち方
  • groongaの性能を落とさずによさを活かすには、どのようにRubyと連携すればよいか
• Ruby 1.9 + Rackで効率よくWebアプリケーションを作る方法
  • 運用時に発生した問題への対応
  • リソースを追加投入する前にやっておくべきスループット改善方法（中規模向け）
  • Webサービス用APIの提供

Twitterなどを見てもわかる通り、世界には情報がどんどん増えていきます。そうすると、その中から必要な情報を選ぶことが重要になっていきます。しかし、情報が溢れた世界では人力のみで効率よく情報を選択することは困難です。最近Twitterが提供をはじめた「おすすめユーザー」という機能も、溢れかえった情報の中から必要な情報を見つけることを支援するための機能と言えます。

必要としている人が必要な情報を見つけやすくしたい、そんなアプリケーションを作りたいと考えている人に聞いて欲しい内容です。もしかしたら、groongaが提供する必要な情報を見つけるための機能でそれを実現できるかもしれません。発表日時は最終日8/29（日）の13:30-14:00で、場所は中ホールです。同じ時間帯に、別の場所ではかずひこさんの外国で暮らすRubyistだけど何か質問ある？、TermtterKaigi、MSWin32版Ruby野良ビルダー養成塾などありますが、こちらは30分なので、こちらの発表の時間だけ抜け出すことも考えてみてください。

まとめ

日本Ruby会議2010で発表する予定の内容を紹介しました。面白そうだと思った方はぜひ参加してみてください。チケットはまだ少し残っているようです。また、チケットを譲りたいという方もいるので、まだチケットを持っていない方は連絡をとってみるのもよいかもしれません。

それでは、日本Ruby会議2010でお会いできることを楽しみにしています。

お知らせ

採用を再開しました。ソフトウェア開発者を2名募集しています。応募条件はプログラミングが好きなことだけです。学歴や年齢などは関係ありません。勤務地は東京都文京区または栃木県小山市になる予定です。詳しくは採用情報を見てください。日本Ruby会議2010の会場にはクリアコードの人が3人はいるはずなので、そのときに声をかけてもらえればその場でも説明します。

ツイートする

フォローする

Rails 3.0 beta4でDeviseを使ってOpenID認証

とあるRails 3を使っているたいやき用のCMSでDeviseを使ってOpenID認証をするようにしたので、そのやり方を紹介します。RubyはRuby 1.9.2 RC2も出ていますが、今回はRuby 1.9.1を使います。

Deviseとは

DeviseはRackベースの認証システムです。バックエンドにWardenを利用しているため、Basic認証やOpenID、OAuthなど認証方法を切り替えることができます。

ただ、以下の説明を読んでみてもらってもわかる通り、動き出すまでにそこそこの作業が必要になります。機能は豊富なので、動き出したらカスタマイズしてアプリケーションの要求に合わせていくことができるでしょう。日本語での情報もあまりありませんが、探せばいくつかはあるので、試してみてはいかがでしょうか。

とはいえ、今回はDeviseのデフォルトの認証方法ではなく、OpenIDでのみ認証することにします。また、未登録のユーザがログインしようとしたときは自動的に新規ユーザを作成することにします。このようにも使えるという例ということで読むとよいかもしれません。

インストール

まず、Rails 3.0 beta4をインストールします。

% sudo gem1.9.1 install rails --pre

サンプル用のアプリケーションを作ります。

% ruby1.9.1 rails new taiyaki
% cd taiyaki

次にDeviseをインストールします。

% sudo gem1.9.1 install devise --version=1.1.rc2

インストールしたDeviseを利用するため、以下のようにGemfileに追記します。

Gemfile:

1

gem 'devise', "1.1.rc2"

アプリケーションにDeviseが動作するために必要なファイルをインストールします。config/initializers/devise.rbなど主に設定ファイルです。

% ruby1.9.1 script/rails generate devise:install

いくつかは手動で設定する必要があります。それぞれ以下の通りです。

Deviseはパスワードの再設定をする機能もあり、そのときはユーザにメールを送信します。そのような機能を使うときはActionMailerのURL生成オプションを設定する必要があります。例えば、開発時のホスト情報を設定する場合は以下のようになります。

config/environments/development.rb:

1

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

Deviseはリダイレクト先のURLを生成するときなどにデフォルトではroot_pathを使うので、rootパスへのマッピングを追加します。以下の例ではwelcome#indexを指定しているので、後でWelcomeControllerを作ります。

config/routes.rb:

1

root :to => "welcome#index"

Deviseはnoticeとalertのflashを設定するので、レイアウトに追加しておくとよいでしょう。例えば、以下のようにyieldの前に追加します。

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

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

<%= yield %>
<%# ... %>

作成

これでインストールは完了したので、コントローラーやモデルを作成します。

まず、ユーザー用のモデルを作成します。

% ruby1.9.1 script/rails generate devise User

このとき生成されるスキーマは、以下のようにデータベース上にパスワードのダイジェストなどの情報を持ち、それを利用して認証することになります。

db/migrate/XXXX_devise_create_users.rb:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

class DeviseCreateUsers < ActiveRecord::Migration
  def self.up
    create_table(:users) do |t|
      t.database_authenticatable :null => false
      t.recoverable
      t.rememberable
      t.trackable

      # t.confirmable
      # t.lockable :lock_strategy => :failed_attempts, :unlock_strategy => :both

      # t.token_authenticatable

      t.timestamps
    end

    add_index :users, :email,                :unique => true
    add_index :users, :reset_password_token, :unique => true
    # add_index :users, :confirmation_token,   :unique => true
    # add_index :users, :unlock_token,         :unique => true
  end

  def self.down
    drop_table :users
  end
end

しかし、今回は自分では認証情報を持たずにOpenIDで認証するので、データベース上に認証情報を持たないようにします。代わりにOpenID用のカラムを追加します。

db/migrate/XXXX_devise_create_users.rb（変更後）:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34

class DeviseCreateUsers < ActiveRecord::Migration
  def self.up
    create_table(:users) do |t|
      t.string :email
      t.string :nickname
      t.string :identity_url
      t.string :fullname
      t.string :birth_date
      t.integer :gender
      t.string :postcode
      t.string :country
      t.string :language
      t.string :timezone

      t.rememberable
      t.trackable

      t.confirmable
      t.lockable :lock_strategy => :failed_attempts, :unlock_strategy => :both
      t.token_authenticatable

      t.timestamps
    end

    add_index :users, :identity_url,         :unique => true
    add_index :users, :email,                :unique => true
    add_index :users, :confirmation_token,   :unique => true
    add_index :users, :unlock_token,         :unique => true
  end

  def self.down
    drop_table :users
  end
end

変更したらスキーマを反映させます。

% rake1.9.1 db:migrate

モデルのコードにもデータベースで認証するためのコードが入っています。今回は必要のないユーザ登録用の:registerableオプションやパスワードの入力チェックなどをする:validatableオプションなどは外します。password_required?メソッドをオーバーライドしているのは、OpenIDで認証するためパスワードが必要がないからです。

app/models/user.rb:

1
2
3
4
5
6
7
8
9
10
11

class User < ActiveRecord::Base
  ...
  # devise :database_authenticatable, :registerable,
  #        :recoverable, :rememberable, :trackable, :validatable
  devise :database_authenticatable, :rememberable, :trackable
  ...

  def password_required?
    false
  end
end

Deviseではログイン画面などデフォルトのビューも提供してくれますが、今回はOpenIDを使った認証にするためビューをカスタマイズします。ビューをカスタマイズする場合は、コントローラーごとカスタマイズする方法と、ビューだけカスタマイズする方法がありますが、今回はコントローラーごとカスタマイズする方法にします。

コントローラーをカスタマイズするにはconfig/routes.rbに追加されたdevise_forで:controllersオプションを指定します。以下のように指定するとUsers::SessionsControllerコントローラーを使います。

config/routes.rb:

1
2

devise_for(:users,
           :controllers => {:sessions => "users/sessions"})

コントローラーを作成します。

% ruby1.9.1 script/rails generate controller Users::Sessions

コントローラーをカスタマイズする場合は、ApplicationControllerではなくDevise::SessionsControllerを継承します。

app/controllers/users/sessions_controller.rb:

1
2

class Users::SessionsController < Devise::SessionsController
end

ログインフォームではOpenID用の識別子を入力してもらうようにします。

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

<%= form_for(resource,
             :as => resource_name,
             :url => session_path(resource_name)) do |f| %>
  <p>
    <label for="openid_identifier" >OpenID URL:</label>
    <%= text_field_tag :openid_identifier %>
  </p>
  <p><%= f.label :remember_me %> <%= f.check_box :remember_me %></p>
  <p><%= f.submit "Login" %></p>
<% end %>

あとは、トップページを準備すれば画面を確認することができます。

トップページ用のコントローラーを生成します。

% ruby1.9.1 script/rails generate controller welcome index
% rm public/index.html

トップページではログインページに移動できるようにします。ログイン時はログイン中のユーザ情報を表示します。

app/views/welcome/index.html.erb:

<h1>Welcome#index</h1>

<% if user_signed_in? %>
  <p>ようこそ<%= current_user.nickname %>さん</p>
  <%= link_to("ログアウト", destroy_user_session_path) %>
<% else %>
  <%= link_to("ログイン", new_user_session_path) %>
<% end %>

サーバを起動します。

% ruby1.9.1 script/rails server

http://localhost:3000/にアクセスすると以下のような画面になります。

ログインページに行くと以下のようなフォームになります。

OpenID対応

それではOpenIDに対応します。DeviseからOpenIDを使うために、warden-openidを使います。

% sudo gem1.9.1 install warden-openid

Gemfileにも追記します。

Gemfile:

1

gem 'warden-openid'

WargenでOpenIDを使うようにします。

config/initializers/devise.rb:

1
2
3
4
5
6

Devise.setup do |config|
  ...
  config.warden do |manager|
    manager.default_strategies(:openid, :scope => :user)
  end
end

OpenIDの設定をします。warden-openidではOpenIDの認証が成功した時にコールバックが実行され、そこで認証情報に対応したアプリケーション用のユーザを返すことになります。今回は、ここで、ユーザが存在しない場合は自動的に新規ユーザを作成することにします。

config/initializers/openid.rb:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

Rails.application.config.middleware.insert(Warden::Manager, Rack::OpenID)

Warden::OpenID.configure do |config|
  config.required_fields = User.required_open_id_fields
  config.optional_fields = User.optional_open_id_fields
  config.user_finder do |response|
    user = User.find_by_identity_url(response.identity_url)
    if user.nil?
      user = User.new
      user.extract_open_id_values(response)
      unless user.save
        message = "failed to create user: "
        message << "#{users.errors.full_messages.inspect}: "
        message << user.inspect
        Rails.logger.error(message)
        user = nil
      end
    end
    user
  end
end

OpenIDの情報とアプリケーションのユーザ情報をマッピングする処理はモデルで行います。

app/models/user.rb:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47

class User < ActiveRecord::Base
  REQUIRED_FIELDS = {
    :nickname => "nickname",
  }

  OPTIONAL_FIELDS = {
    :email => "email",
    :fullname => "fullname",
    :birth_date => "dob",
    :gender => "gender",
    :postcode => "postcode",
    :country => "country",
    :language => "language",
    :timezone => "timezone"
  }

  class << self
    def required_open_id_fields
      REQUIRED_FIELDS.values
    end

    def optional_open_id_fields
      OPTIONAL_FIELDS.values
    end
  end

  def password_required?
    false
  end

  def extract_open_id_values(response)
    profile_data = {}
    [OpenID::SReg::Response, OpenID::AX::FetchResponse].each do |response_class|
      data_response = response_class.from_success_response(response)
      profile_data.merge!(data_response.data) if data_response
    end
    [REQUIRED_FIELDS, OPTIONAL_FIELDS].each do |fields|
      fields.each do |model_key, profile_key|
        unless profile_data[profile_key].blank?
          self.send("#{model_key}=", profile_data[profile_key])
        end
      end
    end
    self.identity_url = response.identity_url
    self.nickname ||= identity_url
  end
end

一応、ニックネーム情報は欲しいとリクエストしますが、もらえなくてもなんとなく動くようになっています。この状態でログインページにOpenID識別子を入力して、認証に成功するとアプリケーションにログインする事ができます。

ただし、現在リリースされているruby-openidはRuby 1.9のEncodingに対応していないため、認証中にASCII以外の文字列を含むページにアクセスすることになると失敗します。これを修正する方法はRuby 1.9.1 supportで報告済みですが、まだ取り込まれていません。

まとめ

Rails 3.0 beta4でDeviseを使ってOpenID認証する方法を紹介しました。Rails 3で認証まわりはどうしようか、と考えていている人は試してみるとよいかもしれません。ただ、betaやrcのものを使っているので、これから使い方は変わっていく可能性が高いと考えられます。注意してください。

そういえば、トップページにある会社紹介資料PDFを更新しました。エンジニア紹介ページなどが更新されています。

ツイートする

フォローする

ActiveLdap 1.2.2 - Rails 2.3.8対応

RubyらしいAPIでLDAPのエントリを操作できるライブラリActiveLdapの新しいバージョンがリリースされました。以下のようにgemでアップデートできます。

% sudo gem install activeldap

ActiveLdapについてはこのあたりを見てください。

• チュートリアル
• Rubyist Magazine - ActiveLdap を使ってみよう（前編）

今回のリリースではRuby on Railsの最新安定版2.3.8に対応しました。ActiveLdapは国際化対応のためにRuby-GetText-Packageを使っています。そのため、ActiveLdapをRailsで使う場合にlocale_railsと一緒に使っている場合も多いでしょう。しかし、locale_railsの最新版はRails 2.3.8に対応していないので、locale_railsを利用している場合はアップデートするかどうかよく検討してください。（locale_railsのリポジトリ上では2.3.8に対応しているので、locale_railsのリリース版ではなくて未リリースのものを利用するのも対応策の1つです。）

LDAPといえば、日本Ruby会議2010では「Rubyで扱うLDAPのススメ」という企画があります。[ANN]RubyKaigi2010 企画 "Ruby で扱う LDAP のススメ" にご協力頂ける方を募集しています - tashenの日記ということなので、ぜひ、ご協力をお願いします。

ツイートする

フォローする

最後の行から順番に読み込む小さなRubyのクラス

Muninのプラグインを作るときなど、大きなサイズのログファイルを解析する必要がたまにありますよね。そんなとき、ファイルの先頭から処理をしていくとファイルサイズが増加するにしたがって処理時間も増えていってしまいます。Muninのプラグインの場合は最近5分間のデータだけあれば十分なので、ファイルの先頭からではなく、最後から処理する方が効率的です。最後から処理すると、ファイルサイズが大きくなっても処理時間にはほとんど影響がありません。

ということで、ファイルの最後から1行ずつ読み込む小さなRubyのクラスを作りました。groongaのリポジトリに入っているので、groongaと同じライセンスで利用できます。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53

class ReverseLineReader
  def initialize(io)
    @io = io
    @io.seek(0, IO::SEEK_END)
    @buffer = ""
    @data = ""
  end

  def each
    separator = $/
    separator_length = separator.length
    while read_to_buffer
      loop do
        index = @buffer.rindex(separator, @buffer.length - 1 - separator_length)
        break if index.nil? or index.zero?
        last_line = @buffer.slice!((index + separator_length)..-1)
        yield(last_line)
      end
    end
    yield(@buffer) unless @buffer.empty?
  end

  private
  BYTES_PER_READ = 4096
  def read
    position = @io.pos
    if position < BYTES_PER_READ
      bytes_per_read = position
    else
      bytes_per_read = BYTES_PER_READ
    end

    if bytes_per_read.zero?
      @data.replace("")
    else
      @io.seek(-bytes_per_read, IO::SEEK_CUR)
      @io.read(bytes_per_read, @data)
      @io.seek(-bytes_per_read, IO::SEEK_CUR)
    end

    @data
  end

  def read_to_buffer
    data = read
    if data.empty?
      false
    else
      @buffer.insert(0, data)
      true
    end
  end
end

以下のように使います。

1
2
3
4
5
6

File.open("/var/log/groonga/query.log", "r") do |file|
  ReverseLineReader.new(file).each do |line|
    break if no_more_need?(line)
    # ...
  end
end

ログファイルから直近のログだけを取り出して処理したいときなどに利用してみてはいかがでしょうか。

ツイートする

フォローする

Passenger用Muninプラグイン

みなさんはPassengerの管理下にあるRails/Rackプロセスをどのように監視しているでしょうか。

Muninを使った方法もあり、Dan Manges's Blog - Rails Application Visualization（gist: 20319 - munin plugin for passenger- GitHub）で公開されていたりします。このプラグインはpassenger-statusの結果をグラフ化しています。passenger-statusの結果はこんな感じになります。

----------- General information -----------
max      = 6
count    = 3
active   = 0
inactive = 3
Waiting on global queue: 0

----------- Domains -----------
/home/rurema/rurema-search: 
  PID: 17128   Sessions: 0    Processed: 38      Uptime: 4m 54s
  PID: 30722   Sessions: 0    Processed: 543     Uptime: 1h 14m 32s

先述のプラグインではこのうち「General information」の情報だけをグラフ化しています。でも、「Domains」の情報もグラフ化したいですよね。「Processed」を見れば妙にたくさん処理しているプロセスを見つけることができるかもしれませんし、「Uptime」を見れば長生きしすぎているプロセスを見つけることができるかもしれません。

ということで、るりまサーチのリポジトリrackngaのリポジトリに「Domains」もグラフ化するMuninプラグインを入れておきました。

インストール方法

Debian GNU/Linux前提です。

まず、るりまサーチをcloneします。

% git clone git://github.com/kou/rurema-search.git

プラグインを/usr/share/munin/plugins/にコピーします。

% sudo cp rurema-search/munin/plugins/* /usr/share/munin/plugins/

プラグインをroot権限で動かすようにします。

/etc/munin/plugin-conf.d/passenger.conf:

[passenger_*]
  user root

プラグインをインストールします。autoconfに対応しているので、自動検出してくれます。

% sudo -H /usr/sbin/munin-node-configure --shell --remove-also | sudo sh

munin-nodeを再起動します。

% sudo /etc/init.d/munin-node restart

5分もすればグラフに反映されるでしょう。

まとめ

Passenger用のMuninプラグインを紹介しました。

PassengerとMuninを使っている場合は導入してみてはいかがでしょうか。

ツイートする

フォローする

クリアコードの公開gitリポジトリ

すでにお気づきの方もいるかもしれませんが、先日から、クリアコードで開発したフリーソフトウェアが入ったgitリポジトリの公開を始めました。

リポジトリ内にはgit用のコミットメール送信スクリプトを含むgit関連ユーティリティ集「git-utils」やCPUの使用率を表示するFirefoxアドオン「システムモニター」も含まれています。中には試し作りしただけのものなども含まれています。それぞれのソフトウェアはリポジトリ内に同梱されているライセンスにしたがって自由に利用できます*1。

クリアコードは既存のフリーソフトウェアプロジェクトの開発に参加するだけではなく、新たにフリーソフトウェアプロジェクトを立ち上げたりもしてきました。中にはプロジェクトを立ち上げるほどでもないような小さなソフトウェアもあり、それらのソフトウェアはこのようにひっそりと開発していたりします。これらはフリーソフトウェアなので、有用だと思うものがあったのなら、ソースコードにアクセスし、自由に利用してください。

もっと自由にソフトウェアを利用できる世界になるとよいですね。

関連: クリアコードの公開Subversionリポジトリ

ツイートする

フォローする

日本Ruby会議2010スポンサーと発表・企画のお知らせ

今年も夏に日本Ruby会議が開催されますが、昨年に引き続き今年もスポンサーになりました。

日本Ruby会議2010のトップページで微妙に公開されていますが、るりまサーチについて発表する予定です。

いくつかの企画にも参加します。今のところ、るびまでActiveLdapの記事などを書いている高瀬さんのLDAPに関する企画とRuby 1.9コミッタQ&Aに参加する予定です*1。

日本Ruby会議2010でのクリアコード関連情報のお知らせでした。

Ruby関連といえば、最近、クリアコードもAsakusa.rbデビューしました。

ツイートする

フォローする

るりまサーチ: Rubyでgroonga使ってリファレンスマニュアルを全文検索

先日、るりまの成果物であるRubyのリファレンスマニュアルを検索するWebアプリケーションるりまサーチを公開しました。

OpenSearchにも対応しているため、Firefoxの右上の検索窓から検索することもできます。

これまでも、るりまの成果物はBitClustを使ってWebブラウザから見ることができました*1。しかし、BitClustのWebインターフェイスは検索機能が弱く、目的の情報にたどり着くのが難しいと感じたことがあったのではないでしょうか。例えば、全文検索ができなかったり、そもそも検索がとても遅かったりしました。

るりまサーチでは全文検索エンジンとしてgroongaを利用することにより、高速な全文検索機能と使いやすい絞り込み機能を実現しています。それでは、るりまサーチの機能とその実装について簡単に紹介します。

機能

るりまサーチは多くの情報を絞り込んでいきながら目的の情報に到達することを意識したインターフェイスになっています。そのため、できるだけ簡単に絞り込んでいけるような機能を組み込んであります。

ここでは、絞り込みに関する機能を2点だけ紹介します。

ドリルダウン

groongaの得意な機能の1つはドリルダウンと呼ばれる、検索結果の中から特定の値をグループ化し、それぞれのグループのレコード処理を数える処理です。るりまサーチでもこの機能を利用して絞り込みやすいインターフェイスを提供しています。

るりまサーチではページ上部にそのときに絞り込める条件を表示します。例えば、トップページではマニュアルの種類によって絞り込めるリンクを表示しています。

このとき、事前に絞り込んだ後のレコード数も表示しています。この時点で絞り込み後のレコード数を数えているので、絞り込んだ後にレコード数がないリンクを表示しないことができます。つまり、「リンクを辿ったけど絞り込んだらマッチするレコードがない！」という状況を防ぐことができます。

便利に絞り込めるリンクを提供し、その一方で、無駄な絞り込みを行わずに済むようになっています。

条件解除

簡単に条件を絞り込めるようにするだけではなく、簡単に条件を解除することもできます。これは様々な絞り込みを行いながら目的の情報に辿りつけるようにするためです。

ページ上部にはどのような条件で絞り込んでいったかが表示されるようになっています。それぞれの絞り込み条件は条件の横にあるリンク*2を辿るだけで簡単に解除することができます。

絞り込みすぎてしまったときは、これで条件を解除して違う条件で絞り込んでいくことができます。

実装

るりまサーチはRuby 1.9.1とRackとrroongaを用いて実装されています。rroongaはgroongaをRubyから利用するためのRubyバインディングです。るりまサーチではgroongaをサーバとしてではなく、ライブラリとして利用しています。

rroongaはgroongaの高速な機能を活かしたまま、より使いやすいRubyらしいAPIを提供しています。るりまサーチはそんなrroongaを使って、すっきりとした記述で実現されています。ここでは、rroongaを使ったコードを2つ紹介します。

スキーマ定義

groongaはRDBと同じようにデータの格納場所毎に型を持っています。groongaにデータを格納する前に格納場所を用意する必要があります。

rroongaでは格納場所の定義（スキーマ）をより宣言的に記述するためのAPIを用意しています。以下は検索対象の情報を保存する「Entries」テーブルの定義です。RDBなどのスキーマを見たことがあるなら、この定義からgroongaがどのようなデータを格納できるようになるかを想像できるのではないでしょうか。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

Groonga::Schema.define do |schema|
  schema.create_table("Entries",
                      :type => :hash,
                      :key_type => "ShortText") do |table|
    table.short_text("name")
    table.short_text("local_name")
    table.short_text("label")
    table.text("document")
    table.text("signature")
    table.text("description")
    table.reference("type", "Types")
    table.reference("class", "Classes")
    table.reference("module", "Modules")
    table.reference("object", "Objects")
    table.reference("version", "Versions")
    table.reference("visibility", "Visibilities")
  end
end

このように、Rubyでは宣言的に処理を記述することがわりとよく行われます。これは、内部DSLとも呼ばれ、やりすぎる人も出るほどです。例えば、上記のような記述を以下のようにすることもできますが、これは少しやりすぎではないかと感じます。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

Groonga::Schema.define do
  create_table("Entries",
               :type => :hash,
               :key_type => "ShortText") do
    short_text :name
    short_text :local_name
    short_text :label
    text       :document
    text       :signature
    text       :description
    reference  :type, :Types
    reference  :class, :Classes
    reference  :module, :Modules
    reference  :object, :Objects
    reference  :version, :Versions
    reference  :visibility, :Visibilities
  end
end

検索条件

rroongaでは検索条件をクエリ文字列ではなく、Rubyの式として記述することができます。

例えば、「name」カラムの値が「Regexp」であるレコードを検索するときは以下のようになります。

1
2
3

entries.select do |record|
  record.name == "Regexp"
end

「name」カラムの値が「Regexp」あるいは「description」カラムに「正規表現」が含まれているレコードを検索するときは以下のようになります。

1
2
3

entries.select do |record|
  (record.name == "Regexp") | (record.description =~ "正規表現")
end

「name」カラムか「description」カラムに「encoding」を含むレコードを検索するときは以下のようになります。ただし、「name」カラムにマッチした場合はスコアをあげて、より上位に表示するようにします。

1
2
3
4
5
6
7

entries.select do |record|
  target = record.match_target do |match_record|
    (match_record.name * 100) |
    (match_record.description)
  end
  target =~ "encoding"
end

DataMapperやSequelなど文字列ではなくRubyの式で条件を指定できるようにするORマッパーはいくつかありますが、最終的にそれらはSQLになります。しかし、rroongaの場合はRubyで書いた式がそのままgroongaのネイティブな条件式になります。カッコいいですね。

また、ORマッパーも少しやりすぎてしまう傾向がある分野ですが、rroongaはやりすぎることなく、Rubyらしさを保ったまま条件式を指定できているのではないでしょうか。少しやりすぎてしまうと、Symbolにメソッドを追加してしまったりします。

まとめ

Rubyのリファレンスマニュアルを検索するWebアプリケーション「るりまサーチ」の機能と実装を簡単に紹介しました。

るりまサーチを使うことでるりまプロジェクトの成果物であるRubyのリファレンスマニュアルをより便利に活用することができます。

また、るりまサーチの実装はgroongaのRubyバインディングであるrroongaのよいサンプルでもあります。groongaをRubyから利用しようと考えていた方はGitHub上にある、るりまサーチのソースコードを読んでみるとよいでしょう。ライセンスはLGPLv3+です。

るりまサーチはSinatraなどのフレームワークを使わずに、直接Rackを使っています。そのような場合にどのようにテスト環境を構築するか、というのもいつか紹介できるとよいですね。今、興味のある人はソースコードを見てください。

このように、るりまサーチにはまだおもしろいところが色々あるのですが、今回はこのへんにしておきます。

ツイートする

フォローする

Ruby 1.8.7/1.9.1どちらでも使えるWindows用バイナリ入りgemをDebian GNU/Linux上で作る方法

groongaのRubyバインディングrroonga 0.9.3がリリースされました。rroonga 0.9.3に関することはメーリングリストでのアナウンスを見てください。

rroonga 0.9.3ではWindows用のgemも提供するようにしました。このgemにはgroonga/rroongaのビルド済みのバイナリが含まれているのでビルド環境がないことが多いWindowsでも簡単に使えるようになっています。

さて、このgemですが、1つのgemでRuby 1.8.7にもRuby 1.9.1にも対応しています。そもそも、gemにはWindowsや32bit環境などのプラットフォームを指定することはできますが、Rubyのバージョンは指定することができません。そのため、Rubyのバージョン毎にgemを用意することはできません。用意する場合はgemのパッケージ名を"rroonga187"や"rroonga191"などと変えなければいけません。これはカッコワルイですね。

解決法は、1つのgemの中に1.8用のバイナリと1.9用のバイナリを両方いれ、実行時にどちらを使うかを切り替える、です。

まず、以下のようにバイナリを配置します*1。

lib/1.8/groonga.so # <- Ruby 1.8.7のWindows用バイナリ
lib/1.9/groonga.so # <- Ruby 1.9.1のWindows用バイナリ

そして、groonga.soを読み込む部分を以下のようにします。

major, minor, micro, = RUBY_VERSION.split(/\./)
require "#{major}.#{minor}/groonga.so"

これで、適切なバイナリを読み込むことができます。

この他に、rroongaのように依存しているDLL（libgroonga.dll）がある場合はそのDLLがあるフォルダをPATHに入れなければいけない、などといった注意点がありますが、それはまたいつか機会があったら触れるかもしれません。

それでは、1.8.7でも1.9.1でも使えるWindows用バイナリが入ったgem*2をDebian GNU/Linux上のMinGWで作る方法を紹介します。

rake-compiler: Ruby 1.8.7と1.9.1をクロスコンパイル

まず、Windows用のRuby 1.8.7と1.9.1をMinGWでクロスコンパイルします。これにはrake-compilerが便利です。

% sudo gem install rake-compiler

まず、MinGWをインストールします。

% sudo aptitude install -y mingw32

それでは、Ruby 1.8.7-p249をビルドします。

% rake-compiler cross-ruby VERSION=1.8.7-p249 EXTS=--without-extensions

クロスコンパイルしたrubyはextconf.rbを実行してMakefileを作れればいいだけなので、拡張ライブラリなどはいりません。環境変数として「EXTS=--without-extensions」を指定すると拡張ライブラリはビルドされないのですが、もっとカッコイイ方法がありそうな気がします。

同様にRuby 1.9.1-p378もビルドします。

% rake-compiler cross-ruby VERSION=1.9.1-p378 EXTS=--without-extensions

ただ、これは失敗します。失敗したら以下のパッチを当てます*3。

1
2
3
4
5
6
7
8
9
10
11
12

diff -ru ruby-1.9.1-p378.orig/win32/win32.c ruby-1.9.1-p378/win32/win32.c
--- ruby-1.9.1-p378.orig/win32/win32.c        2009-12-05 18:40:53.000000000 +0900
+++ ruby-1.9.1-p378/win32/win32.c        2010-04-20 23:10:13.000000000 +0900
@@ -4604,7 +4604,7 @@

     ret += written;
     if (written == len) {
-        (const char *)buf += len;
+        buf = (const char *)buf + len;
         if (size > 0)
             goto retry;
     }

このパッチは以下のように適用できます。

% cd ~/.rake-compiler/sources
% patch -p0 < /tmp/ruby-1.9.1-build-fix.diff

もう一度、同じコマンドでビルドすると成功します。

% rake-compiler cross-ruby VERSION=1.9.1-p378 EXTS=--without-extensions

Rake::ExtensionTask: gem用バイナリをクロスコンパイル

Windows用のRuby 1.8.7とRuby 1.9.1ができたので、これを利用してgem用のバイナリをクロスコンパイルします。これには、rake-compilerが提供するRake::ExtensionTaskが便利です。

Rake::ExtensionTaskの使い方を紹介しますが、ここでは、もうすでにRakefileがあり、その中でGem::Specificationを作っているものとします。

specがGem::Specificationだとすると、Rakefileに以下を追加することでcrossタスクが定義されます。

1
2
3
4
5

require 'rake/extensiontask'
Rake::ExtensionTask.new("groonga", spec) do |ext|
  ext.cross_compile = true
  ext.cross_platform = 'x86-mingw32'
end

Rake::ExtensionTask.newに"groonga"を指定していますが、このようなRakefileを使うときは、以下のようなファイル構成になっている必要があります。

./
+-- ext/
|    +-- groonga/
|        +-- extconf.rb
|        +-- rb-grn.c
|        +-- ...
+ Rakefile
...

ext/の下にRake::ExtensionTask.newで指定した名前と同じディレクトリを作り、その下にextconf.rbを置きます。

crossタスクを使って1.8.7用のバイナリと1.9.1用のバイナリをクロスコンパイルするには以下のようにします。

% rake cross compile RUBY_CC_VERSION=1.8.7:1.9.1

うまくいくとlib/1.8/groonga.soとlib/1.9/groonga.soができます。

これらを両方含んだgemを作るには以下のようにします。

% rake cross native gem RUBY_CC_VERSION=1.8.7:1.9.1

これでpkg/rroonga-0.9.3-x86-mingw32.gemができます。あとは、このgemをrubygems.orgにアップロードすれば完了です。

% gem push pkg/rroonga-0.9.3-x86-mingw32.gem

まとめ

Ruby 1.8.7/1.9.1のどちらでも使えるWindows用のgemをDebian GNU/Linux上で作成する方法を紹介しました。もし、拡張ライブラリをWindows上でも簡単に使えるようにしたいのであれば、Ruby 1.8.xと1.9.xの両方をサポートしてみてはいかがでしょうか。

この話とは関係ありませんが、Ruby Summer of Codeの学生の応募の締切りは今週の土曜日だそうです。（参考: [ruby-list:47029] [ANN] Ruby Summer of Code）

Rubyとオープンソースに興味のある学生の方は応募してみてはいかがでしょうか。本家のSummer of CodeやRuby Summer of Codeはフリーソフトウェアの開発に関わるよい機会といえます。Rubyベストプラクティスの著者が開発しているPDF生成ライブラリのPrawnなど、いくつものRuby関連のフリーソフトウェアがSummer of Codeのおかげで開発が進んできました。（参考: Summer of Codeと須藤さんとSubversionのRuby bindings - 角谷HTML化計画(2005-10-26)）

ぜひ、このような機会を活かして、フリーソフトウェアの開発に積極的に参加してみてください。

Rubyベストプラクティス -プロフェッショナルによるコードとテクニック
Gregory Brown/高橋 征義(監訳)/笹井 崇司
オライリージャパン
￥ 3,360

ツイートする

フォローする

Ruby 1.9.xでRange#include?を高速に動かす方法

Ruby 1.9.xではRange#include?の実装が変わり、Ruby 1.8.xよりも圧倒的に遅くなるケースがあります。これは、Ruby 1.9.xへ移行したときの有名なハマりポイントの1つでしょう。

例えば、こんなケースです。

1
2
3
4
5
6
7
8
9
10

require 'time'
require 'benchmark'

Benchmark.bm(10) do |bm|
  march = Time.parse("2010/03/01")...Time.parse("2010/04/01")
  march_15 = Time.parse("2010/03/15")
  bm.report("include?") do
    march.include?(march_15)
  end
end

2010年3月15日が2010年3月に入っているかを調べています。

これをRuby 1.8.7で動かすとこうなります。

% ruby -v /tmp/range-include.rb
ruby 1.8.7 (2010-01-10 patchlevel 249) [x86_64-linux]
                user     system      total        real
include?    0.000000   0.000000   0.000000 (  0.000011)

一瞬ですね。

Ruby 1.9.1で動かすとこうなります。

% ruby1.9.1 -v /tmp/range-include.rb
ruby 1.9.1p378 (2010-01-10 revision 26273) [x86_64-linux]
                user     system      total        real
include?    1.360000   0.030000   1.390000 (  1.766556)

1万倍以上も遅くなります。

原因

どうしてこうなるのかというと、1.8.xのRange#include?と1.9.xのRange#include?では引数の値の見つけ方が異なるからです。

1.8.xでは引数が範囲の最初の値より大きいかつ最後の値より小さい、ことだけを確認していました。1.9.xでは範囲の最初から最後まで順に繰り返し、その中に引数と==な値が含まれるかどうかを確認します。コードで表すとこんな感じです。

1
2
3
4
5
6
7
8
9
10
11
12
13

def range_include_18(range, value)
  range.begin < value and value < range.end
end

def range_include_19(range, value)
  range_value = range.begin
  loop do
    return true if range_value == value
    range_value = range_value.succ
    break if range_value >= range.end
  end
  false
end

Time#succは1秒先の時間を返します。そのため、一回のRange#include?で最大2678400回ループをまわすことになります（範囲に入っていないとき、つまり、falseを返すとき）。

1

(Time.parse("2010/03/01")...Time.parse("2010/04/01")).to_a.size # => 2678400

真ん中あたりのTime.parse("2010/03/15")でも1209601番目なので、1.8.xのRange#include?と比べてだいぶ遅くなるというわけです。

1

(Time.parse("2010/03/01")..Time.parse("2010/03/15")).to_a.size # => 1209601

解決法

1.9.xには1.8.xのRange#include?と同じように比較するメソッドRange#cover?が追加されているのでそれを使うとよいでしょう。

1
2
3
4
5
6
7
8
9
10

require 'time'
require 'benchmark'

Benchmark.bm(10) do |bm|
  march = Time.parse("2010/03/01")...Time.parse("2010/04/01")
  march_15 = Time.parse("2010/04/01")
  bm.report("cover?") do
    march.cover?(march_15)
  end
end

実行するとたしかに速いです。

% ruby1.9.1 -v /tmp/range-cover.rb
ruby 1.9.1p378 (2010-01-10 revision 26273) [x86_64-linux]
                user     system      total        real
cover?      0.000000   0.000000   0.000000 (  0.000010)

ただし、1.8.xにはRange#cover?はないので、Range#cover?を使うと1.9.x専用のスクリプトになってしまいます。

高速なRange#include?

実は、1.9.xのRange#include?も、数字の範囲または文字の範囲、の場合は高速に動作します。この場合だけ特別扱いされていて1.8.xと同様の比較方法を用いているからです。つまり、どうにかして数字の範囲か文字の範囲に落としこめば1.8.xでも1.9.xでも高速に動作するようなスクリプトを書けるということです。

Timeの場合はTime#to_iで数値にしてしまうのがよいでしょう。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

require 'time'
require 'benchmark'

Benchmark.bm(10) do |bm|
  march = Time.parse("2010/03/01")...Time.parse("2010/04/01")
  march_15 = Time.parse("2010/03/15")
  bm.report("Time") do
    march.include?(march_15)
  end

  march_integer = (Time.parse("2010/03/01").to_i)...(Time.parse("2010/04/01").to_i)
  march_15_integer = Time.parse("2010/03/15").to_i
  bm.report("Integer") do
    march_integer.include?(march_15_integer)
  end
end

結果は一目瞭然です。

% ruby1.9.1 -v /tmp/range-include-integer.rb
ruby 1.9.1p378 (2010-01-10 revision 26273) [x86_64-linux]
                user     system      total        real
Time        1.230000   0.030000   1.260000 (  1.504888)
Integer     0.000000   0.000000   0.000000 (  0.000009)

まとめ

徐々にRuby 1.9.xを使う人が増えているかもしれない、ということで、Ruby 1.9.xを使った場合にハマりそうなポイントとその解決法を紹介しました。1.9.xでは変わったことがたくさんあります。1.9.xのことをもっと知って上手に付き合ってみてはいかがでしょうか。

ツイートする

フォローする

るびま0029号

るびま0029号がリリースされていますね。おめでとうございます。

せっかくなので少し紹介します。

ActiveLdapを使ってみよう

今回のるびまにはRubyでLDAPを操作するための便利ライブラリActiveLdapの記事の後編ActiveLdap を使ってみよう（後編）が入っています。

後編では今まではあまり文書化されていなかったフィルタのことや関連性のことにも触れています。全てのエントリを扱うクラスは、知る人ぞ知るのノウハウではないでしょうか。（ActiveLdap付属のサンプルアプリケーションでは使われていますが文書化はされていなかったはず。）LDAPサーバの設定やデータを確認する場合にはLDAP のスキーマ情報を ActiveLdap から参照するあたりの情報が役に立ちます。ldapsearchなどではなく、irbでLDAPサーバの情報を確認できるので、環境構築時やデバッグ時にとても便利です。（irbの補完機能を有効にするとより便利です。）

記事を書いている高瀬さんはActiveLdapのチュートリアルの翻訳もしている頼もしい方です。ActiveLdapに興味はあるけどまだよく知らないという方は、まず、 ActiveLdap を使ってみよう（前編）を読んでからチュートリアルを読んで、最後に後編を読むのがよいのではないでしょうか。

0029-RubyNewsにもActiveLdap 1.2.1のリリースが載っていますね。

とちぎRuby会議02

発表者として参加したとちぎRuby会議02のレポート記事RegionalRubyKaigi レポート (10) とちぎ Ruby 会議 02もあります。レポートにもありますが、とちぎRuby会議02のお題が他のRegionalRubyKaigiと違ったものだったので、独特な内容になっていましたね。

Rubyベストプラクティス

0029 号 巻頭言で紹介されているRuby 1.9向けに書かれたRubyベストプラクティスという本がそろそろ発売するようです。テストまわりの章だけレビューに参加しました。

少しくせがある印象なので、Ruby初心者の方にはつらいかもしれません。自分で判断できる程度にRubyを知っている方ならいろいろ考えながら読むとおもしろいかもしれません。

まとめ

るびまがリリースされていたので紹介しました。

ところで、みなさんは編集後記は読んでいるのでしょうか。たまにおもしろかったりするので、読んでいない方は読んでみてはいかがでしょうか。短いのでさっと目を通せます。

ツイートする

フォローする

test-unit 2.0.7とCutter 1.1.1をリリース

先日、Ruby用のxUnit系テスティングフレームワークtest-unit 2.0.7とC・C++用のxUnit系テスティングフレームワークCutter 1.1.1がリリースされました。

どちらも、テストの書きやすさ（テストをキレイに書けるとテストを保守しやすい）だけではなく、テストが失敗した時に「できるだけ素早く問題の原因にたどり着ける」ことも重視しています。

Rails/Rack界隈ではCucumberやWebrat、capybaraなどを使って、「"ログイン"ボタンをクリックする」とか「click_link("ログイン")」などと、直感的にテストを書けるようになっています。では、テストが失敗したときの結果はどのように表示されるでしょうか。HTML全体やテキスト全体が表示されて、「"ログイン"というボタン（リンク）はなかったよ」と言われたらどうでしょう。あなたのコードはどこが悪かったのでしょう。

そういうときに、失敗結果を見て、すぐに「あぁ、ここが悪いかも！」と作業を進めていけるようなテスティングフレームワークにしたいものです。開発はデバッグの連続なのですから、よりスムーズにデバッグ作業を進める手助けとなるツールを使って開発したいですよね。

test-unitやCutterはWebアプリケーション用に特別なサポート機能は提供していないので上記のようなことをうまい具合に解決できるわけではないのですが、ライブラリのテストでは上記のようなことをうまい具合に解決する機能を提供しています。

Cutterのインストール方法がより簡単に

一応、リリースで変わったことを少し書いておきます。

機能面でもよくなっているのですが、インストールまわりだけにしておきます。

Cutterプロジェクトでは、これまでDebian, Ubuntu用のapt-lineとMacPortsのPortfileを提供していましたが、今回のリリースから、FedoraのYumリポジトリも提供するようにしました。以下でインストールできます。yumの管理下に入るのでアップデートも簡単ですね。

% sudo rpm -Uvh http://cutter.sourceforge.net/fedora/cutter-repository-1.0.0-0.noarch.rpm
% sudo yum install cutter

test-unitの方は変わらずgemをサポートしているので、こちらもインストール・アップデートが簡単ですね。

書きやすさだけではなくデバッグしやすさも重視したテスティングフレームワークに興味のある方は使ってみてはいかがでしょうか。

ツイートする

フォローする

LDD '10 Winter: メールフィルタの作り方 - Rubyで作るmilter

先日、LOCAL DEVELOPER DAY '10 WinterでRubyでmilterを作る方法について話してきました。どのタイミングでどのmilterプロトコルのコマンドが発行されるかについても説明しているので、Rubyではなく（libmilterを使って）Cでmilterを実装する場合にも参考になる部分があるはずです。むしろ、Rubyとmilterの組み合わせについて話している部分は薄めです。これは、Rubyそのものとmilterの仕組みを理解していればRubyとmilterを組み合わせることは容易だからです。

少しgroongaについてもふれています。

それでは、ダイジェストで資料の内容を紹介します。完全版はリンク先を見てください。資料のPDF・ソースもリンク先にあります。

内容

具体的にRubyでmilterを作る話に入る前に、まず、前提となる知識を確認します。

はじめにメールフィルタ、次にメールフィルタの仕組みの1つであるmilterについて簡単に説明します。その後、一度milterから離れてSMTPについて説明します。これはmilterの動作を理解するためにはSMTPの動作も知っておく必要があるからです。SMTPの動作を確認したらそれをふまえてmilterの具体的な動作を説明します。

ここまできたらRubyでmilterを作るための下準備は整っているはずです。実際に1つRubyでmilterを作ってみます。

ゴール

説明の途中にいくつか確認ポイントがあります。それぞれの技術は他の技術をベースになりたっているので、ベースとなっている技術をおさえていくことが、理解してしっくりくるためのコツです。

それぞれの確認ポイントをゴールとして最終的な「Rubyでmilterを作れる」ようになるゴールまでたどりついてください。

メールフィルタ

メールシステムとは外部とユーザ間でメールを配信するシステムです。すべてのメールシステムではそのままメールをやりとりするのではなく、メールを配信するまでのあいだに、メールに対してなんらかの処理を実行します。つまり、すべてのメールシステムにはメールフィルタ機能が備わっています。

MTAのプラグインとする方法

メールシステムでメールフィルタを実現する方法はいくつかありますが、その1つがMTA（メールサーバ）のプラグインとして実現する方法です。この方法のメリットはMTAを変更せずにメールフィルタ機能を変更できることです。milterはこのタイプで動作するメールフィルタです。

メールフィルタのまとめ

メールフィルタはメールシステムが持っている必須機能の1つです。その実現方法としてMTAのプラグインとして実現する方法があり、milterもその方法で実現されているメールフィルタです。

それでは、milterの概要について説明します。

milterについて

milterの名前の由来は「mail filter」です。milterは汎用的なメールフィルタの仕組みのため、同じメールフィルタを異なるMTAと一緒に使うことができます。

Sendmailを用いているメールシステムではmilterを利用していることが多く、milterをサポートした商用のメールフィルタも多く存在します。最近ではPostfixのmilterサポートがリリース毎に改善されていっているため、Postfixを用いたメールシステムでもmilterを利用するケースが徐々に増えています。

milterシステム

「milter」は文脈によって異なるものを指すことがあります。そこで、ここでは混乱を避けるために異なる名前で呼ぶことにします。

まず、メールフィルタそのものを「milter」と呼びます。

メールフィルタとMTAは別プロセスで動作するため、プロセス間通信でフィルタ対象のメールやフィルタ結果などをやりとりする必要があります。そのやりとりのきまりを「milterプロトコル」と呼びます。

そして、「milter」と「milterプロトコル」をサポートしたMTAを含んだメールフィルタの仕組み全体を「milterシステム」と呼びます。

「milter」といった場合は「メールフィルタそのもの（ここでいうmilter）」という意味で使う場合と、「メールフィルタの仕組み（ここでいうmilterシステム）」という意味で使われる場合が多いです。「milter」という単語が使われている場合はどちらの意味かを判断できるようになってください。

milterプロトコルはSMTPと密接に関連したプロトコルです。そのため、milterプロトコルについて説明する前に、SMTPについて確認します。

SMTPの概要

SMTPは以下の4つのコマンドが基本となるシンプルなプロトコルです。

• HELO
• MAIL FROM
• RCPT TO
• DATA

まず、「HELO」で接続したSMTPクライアントの情報を伝えます。以下の例ではSMTPサーバ（MTA）からのメッセージは先頭に「<」をつけて示します。SMTPクライアントのメッセージは先頭に「>」をつけて示します。

% telnet localhost smtp
< 220 note-pc.example.com ESMTP Postfix (Ubuntu)
> HELO localhost.example.com
< 250 note-pc.example.com

挨拶が済んだらSMTPセッションのスタートです。1つのSMTPのセッションで複数のメールを送ることができます。「MAIL FROM」、「RCPT TO」、「DATA」で1つのメールを送ります。

まず、「MAIL FROM」で送信者を伝えます。

> MAIL FROM: <kou@example.com>
< 250 2.1.0 Ok

次に、「RCPT TO」で宛先を伝えます。

> RCPT TO: <info@example.com>
< 250 2.1.5 Ok

同じメールを複数の宛先に送ることもできます。その場合は「RCPT TO」を複数回実行します。

最後に「DATA」でメールの内容を伝えます。メールの最後は「.」だけの行になります。

> DATA
< 354 End data with <CR><LF>.<CR><LF>
> Subject: Hello
> From: <kou@example.com>
> To: <info@example.com>
> 
> This is a test mail!
> .
< 250 2.0.0 Ok: queued as 054C624FB

これで、1通のメールを送信できました。続けてメールを送信する場合はまた「MAIL FROM」から始めます。

SMTPセッションを終了する場合は「QUIT」です。

> QUIT
< 221 2.0.0 Bye

これで1つのSMTPセッションが終了しました。

milterプロトコルはSMTPと密接に関わっています。それでは、milterプロトコルの詳細を説明します。

SMTPとmilterプロトコル

milterプロトコルにもSMTPと同じようにコマンドがあります。そして、そのコマンドはSMTPのコマンドと対応したものになっています。まずSMTPのコマンドを説明したのはそのためです。

例えば、SMTPで「HELO」というコマンドが実行された場合、「HELO」に対応する「helo」というmilterプロトコルのコマンドが発行されます。このとき、SMTPクライアントが指定したHELOコマンドの引数がmilterに渡されます。

MTAはmilterにコマンドを送った後、milterからの返答があるまでSMTPクライアントには返答しません。つまり、milterが「helo」でrejectを返すことで、SMTPクライアントの「HELO」コマンドへの返答をrejectとすることができます。これにより、MTAがSMTPレベルでできることとほとんど同じことをmilterで実現できます。

milterプロトコルのコマンドとSMTPのコマンドの対応

mitlerプロトコルのコマンドはほとんどSMTPのコマンドに対応していますが、milterプロトコルのコマンドの方がより細かくなっています。例と一緒にコマンドの対応を説明します。

SMTPでの最初のコマンドは「HELO」ですが、milterプロトコルでは「helo」よりも前にコマンドが発行されます。それが、SMTPクライアントがSMTPサーバに接続したときに発行される「connect」コマンドです。

「connect」コマンド以外はSMTPのコマンドとmilterプロトコルのコマンドは1対1で対応します。「envfrom」の「env」は「envelope」の略で、「封筒」という意味です。「envfrom」で「差出人」という意味、「envrcpt」で「宛先」という意味です。「rcpt」は「recipient」の略で「受信者」という意味です。

SMTPでは1つのメールを複数の宛先に送信できます。この場合、複数回「RCPT TO」を指定します。STMPで複数回「RCPT TO」が指定されるので、milterプロトコルでも「envrcpt」コマンドが複数回発行されます。

SMTPの「DATA」コマンドはmilterプロトコルではより細かいコマンドに分解されています。

まず、「DATA」コマンド時にはmilterプロトコルの「data」コマンドがすぐに発行されます*1。その後、SMTPクライアントはメール本体を送信しますが、「header」などのイベントはすぐには発生しません。SMTPクライアントがデータの終了を示す「.」のみの行を入力するまでは何も起きません。「.」のみの行が入力されると、MTA側でメール本文をパースして「header」、「eoh」（end of header: ヘッダーの終わり）、「body」、「eom」（end of message: メッセージの終わり）コマンドを発行します。もちろん、ヘッダーもパースしてあるので、MTAは「ヘッダー名」と「ヘッダー値」と分解した状態で情報を渡します。

このようにmilterプロトコルはSMTPと密接に関わっています。milterプロトコルのコマンドがわかれば、自分が必要な機能を持つmilterを実現するためにはどのコマンドを利用すればよいかを考えることができるでしょう。

milterサンプル: メール検索

説明用のサンプルとしてメール検索を実現するmilterを作成します。今回はSubject、From、Toと本文のみを扱うことにします。

メール検索を実現するために、全文検索エンジンとしてgroongaを、milterライブラリとしてmilter managerのRubyバインディングを使います。

groonga: カラム指向データストア

groongaは全文検索のためのインデックス作成機能だけではなく、データストアの機能も持っています。groongaのデータストアはカラム指向で、リレーショナルデータベースとは違い、レコード（行）毎にデータをまとめて持つのではなく、カラム（列）毎にデータをまとめて持っています。

このようにデータを持つと、同じカラムの複数の値へのアクセスを高速に行うことができます。このため、カラムの値を使った集計処理を高速に実行できます。集計処理とは、例えば、SQLでいうGROUP BYのような処理です。

集計処理を用いると絞り込み検索をしやすいユーザーインターフェイスを提供することができます。例えば、ショッピングサイトで商品に複数のタグがついているとします。このとき、同じタグがついている商品が何項目あるかを表示してリンクにします。1つも商品が属していないタグは表示しないようにすれば、ユーザは無駄な絞り込み操作を行わずにすみます。

全商品（123件）
タグ
  スポーツ（58件）← リンクにする
  映画（45件）    ← リンクにする
  食べ物（36件）  ← リンクにする
  旅行（0件）     ← 表示しない

この状態で「スポーツ」をクリックしたとします。

全商品（123件） > スポーツ（58件）
タグ
  スポーツ      ← 選択済みなので表示しない
  映画（26件）  ← リンクにする
  食べ物（0件） ← 表示しない
  旅行（0件）   ← 表示しない

このように、絞り込んだ後にがっかりするような操作を示さないことにより、絞り込み検索をしやすいユーザインターフェイスを作ることができます。がっかりするような操作かどうかを判断するために、同じ値を持つレコードの個数を数える、といった集計処理をしています。

groonga: バイナリパトリシアトライ

groongaはキー管理のためのデータ構造としてハッシュテーブルとバイナリパトリシアトライを採用しています。バイナリパトリシアトライはパトリシアトライの一種です。

ここにB+木とパトリシアトライの説明を書く予定でしたが、もう、だいぶ長くなっているので省略します。また別の機会があれば紹介します。

パトリシアトライを利用すると効率よく最長一致検索を実現できます。これを試してみるためのサンプルアプリケーションを用意しました。

リンク先ではキーワードを変えて試すことができます。

最長一致機能を利用してキーワード検出している部分のソースは以下の通りです。

1
2
3
4
5
6
7
8
9
10
11

target_text = "..."
keywords = request["keywords"].split

words = Groonga::PatriciaTrie.create(:key_type => "ShortText",
                                     :key_normalize => true)
keywords.each do |keyword|
  words.add(keyword)
end
tagged_text = words.tag_keys(target_text) do |record, word|
  "<span class='keyword'>#{word}</span>"
end