日本Ruby会議2011のスケジュールが発表されました。クリアコードのメンバーはるりまに関することとテスティングフレームワークに関することを話します。面白そうだなと思ったら聞きに来てください。
来月7/11に本社を移転します。場所は今の本社から歩いて5-10分くらいのところです。
人数が増えて手狭になってきたことが移転の理由です。人が増えることで、これまでよりもクリアコードを目にする機会が増えるかと思います。
これまでと同様に移転後もクリアコードはフリーソフトウェアを開発していきますので、これからもどうぞよろしくおねがいします。
日本Ruby会議2011のLightning Talkの締め切りが残り数日になっていますが、みなさんいかがお過ごしでしょうか。
去年開催された日本Ruby2010では、はRuby で扱う LDAP のススメ - 選択肢とその事例という企画があり、RubyとLDAPに関する情報を共有する場になりました。(企画を主催した高瀬さんのまとめ)
日本では「RubyでLDAPを使う」というケースを情報共有する場が無く、この企画はとても意義のあるものでした。今年も同じような場が設けられると有意義でしょう。ということで、RubyKaigi2011の講演以外の企画についてを参考に、日本 Ruby会議2011でそういう場を設けるための方法案をまとめてみました。興味がでてきた人はぜひ実現させてください。
自分が知っていることなどを発表して情報を共有できるでしょう。ただし、持ち時間5分のなかで質疑応答などをすることはできないので、別の機会で行うことを考慮した方がよいでしょう。
日本Ruby会議2010でやった企画のように、「数人の発表者 + 質疑応答」というスタイルを実現できるかもしれません。あるいは、その場で一緒にコードを書いたりすることもできるかもしれません。
または、Lightning Talkと組み合わせて質疑応答をこちらで行うということも考えられます。
Lightning Talkより自由度が高いので、この時間だけで「発表 + 質疑応答」ができるかもしれません。
日本Ruby会議 2011の会期中ではなく、それより前に場を設けるという方法です。他の方法より準備が大変そうですが、一番自由度は高くなります。いろいろやりたいことがある場合はこの方法がよいかもしれません。
日本Ruby会議2011でRubyとLDAPの話をする場を設ける方法案を紹介してみました。興味が出てきた方は[activeldap:88] 今年も日本Ruby会議2011に参加しませんか?へどうぞ。
(どの方法案もLDAPに関係ないような気がします。)
Sphinxの国際化機能を使って複数言語用ドキュメントを用意する方法(概要)で示した複数言語用ドキュメントを用意する仕組みの使い方を紹介します。本当は仕組みについて説明するつもりだったのですが、使い方を書いていたら長くなったので分けることにしました。この仕組みは実際にgroongaで使っているもので、以下のような使い方になります。
まずファイル構成を紹介して、その後、実例を示しながら具体的な作業を紹介します。
まずファイル構成です。これで概要を掴んでください。
groongaはAutomakeなどのGNUビルドシステムを利用しているため、このような構成になっています。違うビルドシステムを利用している場合は違う構成にした方がよいかもしれません。その場合でも英語を特別扱いせずにdoc/locale/
以下に各言語毎のディレクトリを作るという方法は真似した方がよいでしょう。この方が規則を単純化できるため、ビルドシステムが単純になるはずです。
. |-- build | `-- makefiles (doc/locale/#{言語}/以下で共有するMakefile) | |-- LC_MESSAGES.am (doc/locale/#{言語}/LC_MESSAGES/Makefile.amでinclude) | |-- gettext-files.am | |-- gettext.am | |-- locale.am (doc/locale/#{言語}/Makefile.amでinclude) | |-- sphinx-build.am | `-- sphinx.am `-- doc |-- Makefile.am |-- locale (各言語用ディレクトリ置き場) | |-- Makefile.am | |-- en (英語用ディレクトリ) | | |-- LC_MESSAGES(翻訳テキストなし。単なる置き場所。) | | | |-- Makefile.am | | | |-- *.po | | | `-- *.mo | | |-- Makefile.am | | |-- html/ (生成された英語のHTML) | | |-- html-build-stamp (HTMLが生成されたことを示すだけのファイル) | | |-- man/ (生成された英語のman) | | `-- man-build-stamp (manが生成されたことを示すだけのファイル) | `-- ja (日本語用ディレクトリ) | |-- LC_MESSAGES (英語→日本語の翻訳テキスト) | | |-- Makefile.am | | |-- *.po | | `-- *.mo | |-- Makefile.am | |-- html/ (生成された日本語のHTML) | |-- html-build-stamp (HTMLが生成されたことを示すだけのファイル) | |-- man/ (生成された日本語のman) | `-- man-build-stamp (manが生成されたことを示すだけのファイル) |-- source/ (ドキュメント本体) `-- sphinx/ (最新のSphinx)
Sphinxの国際化のドキュメント(英語)ではsource/
以下にtranslated/#{言語}/LC_MESSAGES/
というディレクトリを作って、そこに*.mo
を置くような例になっています。しかし、上記の構成ではsource/
の下ではなく、source/
と同じディレクトリにlocale/#{言語}/LC_MESSAGES/
を作っています。これは、source/
以下に*.mo
など自動生成するファイルを置かないようにするためです。
source/
以下にファイルがあるとデフォルトでsphinx-build
の処理対象となってしまいます。そのため、source/
以下にtranslated/#{言語}/LC_MESSAGES/
を置く場合はconf.py
内でexclude_patternsを使って処理対象でないことを明示する必要があります。明示的に処理対象外とするくらいなら、はじめからsource/
以下ではなく場所に置いた方がよいのではないか、ということでsource/
の下ではなく、同じディレクトリにlocale/#{言語}/LC_MESSAGES/
を置いています。
それではこの仕組みを使ったドキュメントの作成方法です。
ドキュメント作成の流れは以下のようになります。ここでは、new-document
というドキュメントを追加するという例で話を進めます。
doc/source/new-document.txt
を作成し、英語でドキュメントを書く。doc/locale/ja/LC_MESSAGES/
へ移動する。make init
を実行する。new-document.po
ができるので、それをリポジトリへ追加する。new-document.po
を翻訳する。doc/locale/ja/
へ移動する。make html
を実行する。doc/locale/ja/html/
以下に翻訳されたHTMLが生成されるので確認する。ドキュメントの作成はこの作業を繰り返すことになります。実例を以下に示します。
まず、英語でドキュメントを作成します。以下の内容のドキュメントにしたとします。
doc/source/new-document.txt
:
New Document ============ Hi! This is new document.
次に、既存のページからリンクを張ります。こうしないとどこからも辿れないページになってしまいます。
doc/source/index.txt
:
... * :doc:`new-document` ...
これでオリジナルのドキュメントができました。
次は、翻訳テキストを書くファイルであるPOファイルを作成します。
[groonga]% cd doc/locale/ja/LC_MESSAGES [groonga/doc/locale/ja/LC_MESSAGES]% make init ... ユーザが翻訳に関するフィードバックをあなたに送ることができるように, 新しいメッセージカタログにはあなたの email アドレスを含めてください. またこれは, 予期せぬ技術的な問題が発生した場合に管理者があなたに連絡が取れる ようにするという目的もあります. Is the following your email address? kou@clear-code.com Please confirm by pressing Return, or enter your email address. kou@clear-code.com ← 入力 http://translationproject.org/team/index.html を検索中... 完了. A translation team for your language (ja) does not exist yet. If you want to create a new translation team for ja, please visit http://www.iro.umontreal.ca/contrib/po/HTML/teams.html http://www.iro.umontreal.ca/contrib/po/HTML/leaders.html http://www.iro.umontreal.ca/contrib/po/HTML/index.html new-document.po を生成. [groonga/doc/locale/ja/LC_MESSAGES]%
上記のコマンドで以下のような内容のPOファイルが作成されます。
doc/locale/ja/LC_MESSAGES/new-document.po
:
# Japanese translations for 1.2.2 package. # Copyright (C) 2009-2011, Brazil, Inc # This file is distributed under the same license as the groonga package. # Kouhei Sutou <kou@clear-code.com>, 2011. # msgid "" msgstr "" "Project-Id-Version: 1.2.2\n" "Report-Msgid-Bugs-To: \n" "POT-Creation-Date: 2011-06-19 19:18\n" "PO-Revision-Date: 2011-06-19 19:18+0900\n" "Last-Translator: Kouhei Sutou <kou@clear-code.com>\n" "Language-Team: Japanese\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" "Content-Transfer-Encoding: 8bit\n" "Language: ja\n" "Plural-Forms: nplurals=1; plural=0;\n" #: ../../../source/new-document.txt:2 msgid "New Document" msgstr "" #: ../../../source/new-document.txt:4 msgid "Hi! This is new document." msgstr ""
翻訳対象のメッセージはmsgid "New Document"
とmsgid "Hi! This is new document."
の部分です。
内容を確認したらリポジトリに登録しましょう。
[groonga/doc/locale/ja/LC_MESSAGES]% git add new-document.pot [groonga/doc/locale/ja/LC_MESSAGES]% git commit
(ここでbuild/makefiles/Makefile.am
の中にあるpo_filesやmo_filesなどを更新する必要があるのですが、ここでは割愛します。)
生成されたPOファイルはmsgstr ""
とmsgstr
の部分が空文字列になっています。ここに翻訳後のテキストを入力します。
doc/locale/ja/LC_MESSAGES/new-document.po
:
... #: ../../../source/new-document.txt:2 msgid "New Document" msgstr "新しいドキュメント" #: ../../../source/new-document.txt:4 msgid "Hi! This is new document." msgstr "わーい!新しいドキュメントだよー。"
以下の手順で翻訳され日本語ドキュメントとなったHTMLを出力できます。
[groonga/doc/locale/ja/LC_MESSAGES]% cd .. [groonga/doc/locale/ja]% make html [groonga/doc/locale/ja]% firefox html/new-document.html
以下のようなHTMLがブラウザで表示されたはずです。
... <h1>新しいドキュメント...</h1> <p>わーい!新しいドキュメントだよー。</p> ...
groongaで採用しているSphinxの国際化機能を使って複数言語用ドキュメントを用意する方法の使い方について紹介しました。なお、新しい言語の追加方法についてはgroongaの翻訳方法のドキュメントで説明しています。
次こそはこの仕組みについて説明できるはずです。
肉の日なのでgroongaとその関連プロジェクトがリリースされました。
このうち、mroongaの変更点が大きめなので、mroonga 0.7の変更点について紹介します。
mroonga*1はMySQLにgroongaの全文検索機能を追加するストレージエンジンです。ストレージエンジンというのはMySQLのデータストア機能・検索機能を担当するモジュールのことです。ここがプラグインとして後から追加できる仕組みになっています。groongaをバックエンドとしてストレージエンジンを実装しているのがmroongaです*2。
mroongaを使うと使い慣れたRDBやSQLを使って全文検索機能が得意なアプリケーションを開発できるようになります。既存の資産を活かしながら本格的な全文検索機能も使えることが嬉しいことですね。
現在は、RDBとSolrを組み合わせて全文検索機能付きのアプリケーションを実現していることも多いかもしれませんが、そうすると管理対象が増えたりデータが分散したりして管理コストが上がってしまいます*3。
mroongaはこれまでと同様にMySQLサーバーを管理するだけでよいので、新しく管理対象が増えたりしません。
mroonga 0.6までは、データストア機能も通常の検索機能も全文検索機能も提供するひとり立ちしたストレージエンジンでした。このように動くモードをストレージモードと呼びます。図にすると以下のようになります。MyISAMやInnoDBと同じように扱える1つのストレージエンジンとしてmroongaが存在しています。
このモードではカラムストアであるgroongaの特性を活かすことができるため、 不必要なデータアクセスを避けた高速な動作ができるというメリットがあります。しかし、データストアの信頼性という点では、実績のあるInnoDBなどには及ばないというデメリットがあります。
このデメリットを解決するために追加されたのがラッパーモードです*4。
mroonga 0.7では新しくラッパーモードという動作モードを追加しました。このモードでは、他のストレージエンジンと連携して動作します。mroongaは全文検索機能だけ実現し、データストア機能や通常の検索機能は他のストレージエンジンに任せます。図にすると以下のようになります。MySQLからはmroongaしか見えませんが、mroongaの後ろにMyISAMやInnoDBなど既存のストレージエンジンが存在します。mroongaはMySQLと既存のストレージエンジンの間に入り、全文検索機能関連のみ処理し、それ以外は既存のストレージエンジンに処理してもらいます。
このモードでは任意の既存のストレージエンジンにgroongaの高性能な全文検索機能を追加できるというメリットがあります。例えば、信頼性のあるInnoDBに全文検索機能を追加して、便利で高速で安心なRDBを実現できます。
今月も*roonga族がリリースされました。今回は特にmroongaについて紹介しました。
ラッパーモードの使い方についてはmroongaのラッパーモードのドキュメントを参照してください。なお、同じページに現時点での注意点も説明してあるので、そちらも確認してください。
*1 正式名称は「groongaストレージエンジン」で、「mroonga」は開発コードネームという位置付けだったのですが、最近は「mroongaの方がいいやすいよね?」、「正式名称もmroongaでいいんじゃない?」みたいな流れもでてきています。1.0がリリースされるまでにはどうなるかが決まるはずです。
*2 groongaのSQLインターフェイスと考えてもよい。
*3 Sphinxという選択肢もありますが、構成上それはそれで管理コストが上がってしまいます。
*4 ストレージモードがなくなるわけではありません。