Eorzea Lounge

DBIx::ObjectMapperという、PoEAA(Patterns of Enterprise Application Architecture, エンタープライズアプリケーションアーキテクチャパターン)のthe Data Mapper pattern（データマッパーパターン）に則った新手のO/Rマッパーに興味を惹かれました。その一因は、現在進行形で開発しているAmikecoに於いて、the Active Record pattern（アクティブレコードパターン）指向であるDBIx::Classを用いて、ドメインモデルの細かな機微をどこまで表現するか悩んでいることにあります。

本稿では、現在の悩みの詳細、つまりDBIx::Classでテーブル継承系パターンを強引に実現している現状をご紹介しつつ、DBIx::ObjectMapperへ期待を抱くに至った経緯を簡単に記してみます。

追記 : tokuhiromさんに素晴らしいご指摘をいただきました！　本稿でSingle Table Inheritanceを実現できないと嘆いていたのは、Active Recordであることそれ自体が原因ではありません。パターンとモジュールをやや混同して書いてしまいましたので、お詫びします。また、その記事では、DBIx::ClassでもSingle Table Inheritanceを実現していたとのご紹介をいただいているので、（本文中にも弁解を書いていたように（弱気だなぁ））DBIx::Classの実装というよりも、私の使い方が今ひとつであることが原因のようです。愚直に書いただけでパターンを実現できない現状について、何が直接の原因となっているのかということを、落ち着いて・突き詰めてよく考えるべきであることを悟りました。拙い論考に対して鮮やかな反証をご提示いただいて、感激しています。本当にどうもありがとうございました！

追記 : nekokakさんやeiskeoishiさんたちの会話は、示唆に富んでいます。要件や現実世界が複雑だからといって、脊椎反射して腕まくりしてホイホイとモデリングをがっつりやるのは、多くの場合は再考の余地がある働き方だと感じます。いかに無理・無駄を省いてシンプルなものにしていくか、勉強を深めて参りたいです。

Here is a Japanese translation of the entry "The Future of Moose" on "Call of the Moose" which blogged by the Moose development team. The original text and the translation are licensed under a Creative Commons License.

Moose開発チームがブログ「Mooseの呼び声」に書いた「Mooseの未来」という記事の日本語訳です。原文とこの翻訳はCreative Commons Licenseでライセンスされています。

I knew that Moose will be modified greatly on the post via the tweet by lestrrat. It is so attractive for me who is an end-user. In a related matter, MooseX::* extensions will march greatly on modification, and I may have an unexpected injury in a case of that I put my codes into complicated with Moose. Fortunately, Moose seems to be proposed to such a release plan as Perl itself (as will be appreciated from the notation of version number), so I want to go over my codes radically before the actual release comes out.

Mooseに少なからぬ変更が入ることを、lestrratさんのtweetを経由して、この記事で知りました。エンドユーザーの私から見れば大変魅力的な変更です。MooseX::*拡張モジュールもこれに紐付いて変更への大行進が行われるようですし、自分のコードでMooseの込み入ったことをやっていると、思わぬ怪我をすることもあるかもしれません。幸いにして（バージョン表記法からも分かるように）Perl本体のようなリリース計画が敷かれるようなので、正式版が出るまでの間に徹底的にコードを見直すようにしたいものです。

I apologize for the fairly irresponsible translation. Any feedback on the translation are welcome.

訳は相当でたらめです。ごめんなさい。訳のツッコミがありましたら是非。

「文法最速マスター」というタイムリーなネタに半ば悪のりしてしまいましたが、はてブやLivedoorクリップなどで拙稿の「Moose & Mouse基本文法最速マスター/The Fastest Way to Mastering Moose & Mouse」が先週末にホッテントリ入りしたようです。ご覧いただきましてどうもありがとうございます。

日本ではYAPC::Asia 2008などが契機となったのか、2008年の半ばにMoooooooooooooooooooose!の潮流が大きく促進されました。そして2010年の現在、MooseはもうPerlハッカーの方々だけのものではなく、私のような一般のPerlユーザーにもとても近い存在になっています。そうした土壌があることも、奏功した一因かと考えています。

思い返せば、私がMooseを触り始めたのは2008年の後半でした。2009年2月に出たlestrratさんの『モダンPerl入門』には大いに感銘を受けました。5月には2万行くらいの私的な開発案件に投入して、その威力を再確認しました。7月にGitHubのJPAリポジトリにpushされたcharsbarさんによるMoose::ManualとMoose::Cookbookの邦訳版は、JPAのドキュメント和訳プロジェクトでの公開を待たずして、JPAの発表を知ったその日にPODをHTML化して印刷し、当初から印刷していた原語版共々愛読しています。これにはかなり助けられました。そして10月。YAPC::Asia特別研修「Moose入門」が開催され、中の人であるsartakさん直々の仕込みにひたすら感激しました。「最速マスター」を書けるようになったのも、ひとえにこうした方々の成果があったためです。私は日々皆さんに感謝しながらコードを書いています。

そうした感動を何とか還元したくて、スライドを和訳してみたり、クイックリファレンスシート（チートシート）を書いたりしました。今回の「最速マスター」もその一環として位置付けたつもりです。

二ヶ月弱もこのブログを放っておいたので、「最速マスター」をここで公開しようかとも考えましたが、先日書いた通り、perl-mongers.orgにお世話になることにしました。理由をもう少し捕捉しておくと、公益性が多少ありそうな入門記事を折角書いたのだから、ここのような「どこの馬の骨とも知れない場末ドメインのインチキブログ」で公開するよりは、「多くの方にご覧頂けそうで、かつ、公益性があって信頼の出来る場所」に公開したいと考えたからです。

公益性を感じられるドメイン名が既にあり、登録すれば誰でも寄稿出来る仕組みが既にあり、実際に多くの記事が既に投稿されている。この環境はとても素晴らしいものだと思います。perl-mongers.orgを立ち上げたvkgtaroさん、サイトを現在ホストしているworemacxさんに、とても感謝しているところです。

言語や処理系へ大会社のサポートがあるといっても、それらは実際には大して頼りにならず、そのうえ日々「バグだ」「いや仕様漏れだ」「何だと、瑕疵担保条項を発動するぞ」「そもそも要件定義からして腐っていたんだ」などと前から後ろから弾丸が飛び交う場所で設計・開発・試験して、祈りながら実行して飯を食べている私は、コミュニティーに感謝しながら楽しく設計・開発・試験して、実行結果を安心して見守れるPerlを心のオアシスとして生きているのかも知れません。

これは完全な私感になりますけれども、Rubyでプログラミングを楽しめる一方で、PerlにはCPANやコミュニティーを含めた楽しさや居心地の良さを他の言語よりも強く感じます。

Perlコミュニティーにはperl-users.jpや各地の*.pmもあります。基本文法やオブジェクト指向やXSなどの「最速マスター」シリーズも盛んです。勿論、こんな美味しい方法論が放っておかれるわけもなくて、他の言語の暖かいコミュニティーでもhogehoge-usersが出来たり、「hogehoge文法最速マスター」が公開されたりしています。でも、それらの嚆矢がPerlであったということは、Perlユーザーは誇ってもいいと思うのです。

私はそんなPerlが大好きです。

今般Moose/Mouseを使い始めようとする方に奉仕するのは、私の義務であり喜びでもあります。どうか、Moose/Mouseによる楽しいプログラミングを、Perlコミュニティーの体温を感じながら味わってください。

ところで、体温といえば、私は投稿した日に風邪を引いたらしくて摂氏37度になりました。ぎゃふん。

Moose & Mouseの私家版クイックリファレンスシート（チートシート）を作ってみました。

PDF版とODT版の両方を置いておきます。

• Moose & Mouse QUICK REFERENCE (PDF)
• Moose & Mouse QUICK REFERENCE (ODT: OpenDocument Text for OpenOffice.org Writer)

OpenOffice.orgは無料で入手出来ますので、オレオレチートシートの元ネタとしてもお使いいただけるかも知れません。

そもそもMooseにはOliver GorwitsさんによるMoose Quick-Ref Cardというチートシートが昔からあります。これは奥深いMooseの世界が端的にまとめられた素晴らしいものです。ただ、幾つかオレオレ仕様にしたい点がありました。

そんな日々を送っていると、『Web制作の現場で使うjQueryデザイン入門』の付録にフルカラーのjQueryチートシートが付いていることを知りました。これに触発されて作り始めたという経緯があります。

当初はこの2倍くらいの量があったのですが、だったら流行りの「基本文法最速マスター」に悪のりしてしまおうとしたのが「Moose & Mouse基本文法最速マスター/The Fastest Way to Mastering Moose & Mouse」という副産物です。

ところで、上述のjQuery本はプログラマー向けというよりは意匠デザイナー向けの本であるので、カラフルなチートシートで間口を広く取るのは大正解だと思います。一方、今回作ったMoose & Mouseチートシートは白黒灰の3色かつ無味乾燥な作りになっているので、初学者向けのチートシートにはなっていません。カラフルでA4両面くらに日本語の説明文をふんだんに盛り込んだ初学者向けのシートも併せて作りたかったのですが、意匠センスが決定的に不足しているので断念しました。

Moose/Mouseの素敵なプログラミングを体験する人が増えることを期待していますので、ナウなヤングにバカウケなイけてるシートを公開してくださる偉い人の登場を心待ちにしています。

とはいえ今回のシートも多少は物を考えて書いたつもりです。苦心した点を以下に簡単にまとめておきます。

二ヶ月弱のご無沙汰でしたが、あ、ありのまま起こったことを（略）。

MooseのMoose Quick-Ref Cardというクイックリファレンスカード（チートシート）へネイティブトレートによるヘルパーメソッドだけ追加して今風にするつもりで私家版チートシートを書いていたら、いつの間にか「Moose & Mouse基本文法最速マスター/The Fastest Way to Mastering Moose & Mouse」になってしまいました。

下書きをしていたら流行りの「基本文法最速マスター」のような内容になったので、折角なので各種の情報を参考にしつつ、説明文などを追加して公開してみました。「基本」文法でないものも少なからず混じっていますが、副産物なのでご容赦ください。また、Moose用語は可能な限り元の英語を併記していますが、Moose用語以外の英語への訳出はいい加減です。ごめんなさい。

誤っている点, ご不明な点, 冗長すぎてかえって初学者を混乱させかねないため削除すべき点などがありましたら、上記記事へのコメントやトラックバックなどでお寄せいただければ幸いです。適宜改訂します。また、CC-BYライセンスなので、「とても見ていられないので俺が全面的に書き直してしまえ」という企ても歓迎です。

まったく、時の経つのは早いもので、2009年の年の瀬も押し迫ってきました。夏休みの宿題を9月に入ってから終えるという悪癖があった私のことですから、今年を総括する記事をこんな時刻に書き始めるのも無理からぬ事です。

しかし、新学期の開始日と時間割を突き合わせ、例えば中学校では

• 理科Iは月・火・金に授業がある
• 新学期は9月1日水曜日に始まる
• 故に理科Iの宿題は9月2日木曜日中に片付ければよい

という嫌らしい打算で生きて来た私にとっては、むしろこのくらいが普通の生き様とも言えます。

ともあれ、今年2009年を一言で表現するのであれば、ただひたすら「感謝」の一年だった、ということになります。

アセトアルデヒドの勢いで変な物を書いたような気がします。書きかけですけれども。

Games::DateTime - A simple date and time object on any games

たまには脇道に逸れて、ff14.nameおよびff14.asia向けの部品的なモジュールを書くというのも、気分転換に良いかも知れません。何に対しての気分転換かというと、独り身の帰宅路で涙にむせぶ件といったところでしょうか。

上掲のスクリーンショットのような「時計」であればFlashやJavaScriptでもよく見掛けるのですが、「ローカルタイムな地球現在時→仮想世界の現在時」以外に

• 仮想世界の日時→地球の日時方向への変換
• ローカルタイム以外のタイムゾーンへの対応
• 地球日時もしくは仮想世界の日時の指定
• 時間計算（地球および仮想世界の両方）

などが出来る「日付時刻クラス」というのは寡聞にして知らないので、書きました。取り敢えずググって要件を見つけられたのはFF11だけでしたが、起点日時の対称が見付かれば、プレースホルダー的に置くだけ置いたEverQuestなどの実装にも対応出来るかも知れません。

ちなみにスクリーンショットの時計はライブラリー本体ではなくexamplesディレクトリー以下のおまけであるGames::DateTime::Clockです。ff14.nameやff14.asiaでは、最終的にはこれとGames::DateTimeをJavaScriptに移植することになります。

なお、Acme::*以下の名前空間にするかどうかは考え中です。また、テストは酔いが覚めてから書く予定です。などと書いていると肝臓が明日も泣きそうな気がします。

備忘録ですが、MooseX::AbstractFactoryで、ファクトリーメソッドに指定する具象クラス名（の一部）を指定する際にエイリアスを使えるようにしています。ただしHashRefを渡さずにエイリアスクラス名（の一部）を渡す際には、宝箱を開ける為の鍵が当該宝箱の中にあるような状態で、いまいちです。

Mooseの型制約を遅延設定するMooseX::Types::Games::DateTime辺りの小細工（実装クラスに依存してwhereブロック内の振る舞いを規定する、など）については、稿を改めようと思います。

• 1日24時間という世界の具象クラスではhourが0 <= $_ && $_ < 24の範囲になり、
• 1日30時間という世界の具象クラスではhourが0 <= $_ && $_ < 30の範囲になる

という要件があったときに、事前に（静的に）それぞれ別の型制約を作らずに、最大値を具象クラスから引っこ抜いて型制約で使うということです。これもまたいまいちな実装ですけれども。

追記: テストを薄く書いてバグを除いたほか、見本の時計はロケールにも対応させました。また、cp932でなくUnicodeなコンソールでの字詰めの問題等々を解消しています。上記スクリーンショットも差し替えています。全角半角の「文字幅」の取り扱い方については、（時間があれば）稿を改めて備忘録を起こす予定です。

JPerl advent calendar 2009 hacker trackの22日目を執筆させていただきました。

補足情報を簡単に記します。

本サイトはFF14のプレイヤー向けウェブシステムの開発日誌という位置付けですので、FF14の話題にも触れておきます。

遂にFF14のベータテスターの募集が始まりました。2010年の正式サービス開始予定を前に、開発も佳境に入っていることとお見受けします。大変期待の持てる作品であり、末永く愛されることを願ってやみません。

さて、応募に際しては必要事項を色々記入することになりますが、いくつか気掛かりな内容がありました。といっても、馬鹿正直に書いた内容が裏目に出たらどうしよう、という心配事でしかないのですが。

PerlのDIコンテナーであるOrochiは、作者である牧さん(lestrratさん)ご本人がFukuoka.pmのFukuoka Perl Workshop #14のスライドのp.46で「循環依存の解決は実装できてない」と書いていらっしゃいます（参考：平田さんの「Fukuoka Perl Workshop #14に行ってきた」の記事）。

ただし、これは私にとっては特段の制約事項とは感じません。循環依存するようなクラスは、場合にもよりますが、私の場合には大抵クラス設計を誤って陥る泥沼状態であるからです。

とはいえ、クラスが複雑に絡み合う事態は起こり得るので、依存関係には気を付ける必要があります。ただ単に依存がぐるぐる回ってバターにならないようにすることは勿論ですが、依存関係を実際に注入する処理でも気を付ける必要があります。この処理は、dannさんの記事の通り、Java界隈ではwiring（ワイヤリング）という用語が充てられます。

で、そのwiringで気を付けるというのは、具体的には、inject_classの実行順が依存の逆順であってはならない、という点です。当たり前といえば当たり前なのですが、うっかりしていました。

以下はその備忘録と解説です。