寝過ごしてしまって、シャワーを浴びて慌てて出掛ける。秋葉原に着くと、駅前で「完全メイド宣言」たらいうよくわからないグループが歌って踊り始めた。それを眺めながら参加者が集まるのを待つ。今回は参加者がちょっと少なめ。オープンセッション方式を採った。前半は3つのテーブルに分かれた。私は、「自分は経験が無いのだけれど、誰か詳しい人、Railsの国際化について教えてください」と言って国際化のセッションを開いた。私が今まで開発したアプリケーションは日本語だけ対応できればよかったのでjascaffoldがあれば十分だった。将来性を考えて国際化対応というのは考えなくてはならない点だ。マッチしなかった模様[rails:937]。[rails:937]における十河さんのようなニーズは非常に現実的で、重要な問題だと思う。してみたものの、正統なやりかたを知りたいと思った。それで、「誰か教えてほしい」とセッションを開いたのであった(hs9587メソッド)。3つのやりかた鈴木さんが前回までの国際化に関するセッションの結論を報告してくださった。プラグインが主流らしい。MVC構造のアプリケーションを国際化するにあたって3つのやりかたを考えられる。Controllerまで踏み込んだもっと奥深いやりかたView層の差し替えはrailsではテンプレートファイルを差し替えるだけである。私が書いたプラグイン程度の簡単なものでも取り合えず使えるだろう。gettextは「文言単位での対照訳」に相当する。gettextのruby版で、.moファイルから対照訳を取得する。Globalizeは、Modelまで踏み込んだ「奥深いやりかた」だ。データベースに専用のテーブルを設けて翻訳情報などをそちらに格納する。テンプレート差し替えには次のような利点がある。比較的気軽に適用できる速度は悪くない国際化対応というのは異なる文化慣習への対応でもあるから、単なる文言の修正では済まないこともある。テンプレートごと差し替えてしまえばそういうケースでも対応が楽。欠点としては次のようなものが挙げられる分離した各テンプレート間で修正を同期する問題テンプレートに流し込むデータのロケールについては、この手法単体では無力なケースがある。在庫表示における商品名とか。gettextには次のような利点がある。gettextには次のような欠点がある単なる文言の修正で済まないケースには無力データのロケールに付いてはテンプレート同様Globalizeプラグインには次のような利点があるString#tがgettextと似たようなことをしてくれる。違いは格納形式が.moではなくデータベースであることのみ。Model層まで踏み込んだ細かなサポート。データベースに格納された設定にしたがって出力時のフォーマットを調整する。Modelについても翻訳をサポート。ActiveRecordを拡張し、翻訳対象に設定した属性はロケールごとに別々にデータを保存する。ビジネスロジックからは透過的にロケール依存のテキストを処理できる。```欠点としては導入コストが高めかも。gettextと比べると重そうドキュメントが少ない実際、このセッションではここまでまとまった段階で「みんなで淡々とGlobalizeを試してみるよ」に以降したのだけれど、それぞれに引っかかって、時間内で動かせた人はいなかった。期待できるプロジェクトなのは確かである。情報豊富なgettextや、適当に書いてもそれなりに使えるテンプレート差し替えに比べると敷居が高いのは否めない。GetText開発者から2005-02-26追記。現実の開発ではテンプレート差し替えでは「修正時の同期の問題」が強く出てしまうという御意見。文言だけ翻訳(snip)を強くオススメします。GetTextの歴史を考えても、多くのGUIアプリはこれで十分なはずです。前述のテンプレート切替えプラグインの改良案も提示してくださった。他のセッションRailsのキャッシングRails内部のキャッシングについて調べたらしい。HTMLレベルでのキャッシングはしているようだけれど、DBクエリのキャッシングは不完全で、まだまだ改善の余地があるんではないかとのことらしい。Generatorを読んでみようすごいのは生成のためのテンプレートであって、generatorとしては普通ということらしい。前提としてのscaffoldの中身の説明を詳しくやったらしい。後半2つのセッションに分かれた。私ははてなSNSのほうに参加。クローンを作ったというので、そのソースコードを観賞する催し。約8時間で実装したという。とりたてて派手な訳ではないけれど、モジュールがセンス良く切り分けられていて、勉強になった。みんなでid:secondlifeさんに「クローンも一般公開してよ」と言った。公開してくれたようだ。中の人もいらしていて、クローンのほうに続いて、オリジナルのはてなSNSソースコードも観賞した。実に力強い実装であった。CGIプログラムにしてあのアクセス数をさばいているのは故無きことではない。後半は、主にお二人のソースコードを題材に、参加者皆で「こんなライブラリがあればいいのに」を語った。Atomを透過的に扱えるRSSパーサーがあればいいのにruby-feedparserがある。正規表現にマッチする部分を抜き出して配列化するスマートな方法があればいいのにやっぱり今はgsub使ってる?UTF8にも対応している文字コード変換のスマートなAPIがあればいいのに。-m0あたりは知らないとはまるKconvはUTF8に対応していない。UconvなんてのもあったねIconvは環境依存が痛い。APIダサいopenuriがキャッシングなどもサポートしてくれればいいのにキャッシングをデフォルトで有効にすべきか、無効にすべきか設計が難しい。別のメソッドにしてしまうのもアリか。require_dependencyは使える懇親会いぬビームの中の人と井上さんの間に座って、色々話した。いぬビームさんはお気に入りサジェスタといい、発想が素晴らしい人だ。各ポータルサイトの実装を語ったりとか。Continuation萌えるよContinuationとか。仕事でRails使ってますという人が段々増えてきた。私は、お客さんの目に触れるところにRails使った例としては割と早いほうらしいけれど、人の話を聞くにつれて「小規模システムだからやれたな」とか「うまくいったからいいけど、慎重さが足りなかったかも」とか痛感する。無謀上等ということで。月別アーカイブはてなブログをはじめよう!yuguiさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。