日本では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度になりました。ぎゃふん。

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の基本的な構文を「最速マスター」の水準で理解できていることを前提として記述しました。

いくつかの例を元にもう少し詳しく説明します。

自明な箇所の解説は除いた

端的な例はextends @superclassesです。

見ての通りsuperclassesをextendするので、class inherits superclassesなどという説明文は不要ですね。自明な処理はコメントしないという鉄則を守らないと、コードを逐行で日本語訳して立派な「クラス仕様書」をこしらえるどこかの会社の轍を踏んでしまいます。

Moose Quick-Ref Cardでもあまりにも自明な解説文は省いていますが、しかしどちらかというと親切な記述になっているようにお見受けしました。多少間口を狭くした方がかえって利便性が増す可能性があるのではないだろうか、と思います。

コードで書けるものは極力コードで書く

他にも、Moose Quick-Ref Cardではメソッドモディファイヤーのコードリファレンスに渡ってくる引数について

around is passed ($next_method, $self, @args).

と書かれていますが、これは以下のようにコードだけで書くこともできます。

around @methods => sub {
    my ($next, $self, @args) = @_; ...
};

ついでにmy @return_values = $self->$next(@args); ...という記述も追加して、override/super()との違いが分かるようにもしました。

元々甘いMoose

いかにもそれっぽい理由付けを書きましたが、こうでもしないと内容をA4へ収めきれないという切実な問題が一番の理由だったりします。

ただし、Mooseのシュガー関数はそれ自体が「甘い」ので、さらなる砂糖を振り掛けなくても美味しくいただけるということが分かります。宣言的プログラミングが病み付きになる所以ですね。

痒いところに孫の手を

Any::Moose対応

クラスやロールのスケルトンなどでAny::Mooseを使った書き方にしています。

Any::Mooseの仕様が分かっていれば、シートに相当してMoose, Moose::Role, MooseX::Typesを生でuseする記述も書けると思います。というか、流石にuse Moose;することを知らないとMooseクラスは書けないと思います。

MooseX::Types前提

Moose::Util::TypeConstraintsではなくMooseX::Typesを使うことを前提にしています。

My::App::Types以下の名前空間に勝手に入ってくれたりするので、あれやこれや気を遣ったり、注意を促す文言を書くよりは、すっぱりMooseX::Typesを使った方が楽だと思ったからです。

勿論Any::Mooseに対応した書き方をしています。

ネイティブトレートのヘルパーメソッドを網羅

私家版チートシート作成の動機は、ひとえに名前空間が深いMoose::Meta::Attribute::Native::Trait::Arrayなどをperldocすると疲れることでした。

ということで、4段組のうちまるまる1段を使ってヘルパーメソッドの一覧を羅列しました。

• absがアトリビュートの値を汚すこと（汚さないなら単にabs $obj->attr）
• sortがアトリビュートの値を汚さないこと（汚すならsort_in_place）

などという点で引っ掛かりそうだったので、相当する素のPerl構文も併記しています。

MooseX::*拡張モジュールに言及

モジュールの名前を羅列するだけでなく、空間が余ったので使い方をごく簡単に書きました。

use MooseX::Clone;なのかwith qw(MooseX::Clone);なのかと、拡張モジュールの呼び方をすぐ忘れてしまうからです。

そのモジュールで書けるようになる構文も、ほんの触りだけ記述しています。

hasオプションをカテゴライズしつつオレオレソート

これは「最速マスター」の意図としてもご紹介しましたが、hasのオプションをベタに羅列するのではなく、或る程度関連性のある内容を小分けにしています。

hakobe932さんによるKansai.pm #9でのMoose入門の発表「初めてのMoose」などでもネタにされるように、hasのオプションはかなり多いです。情報を鉄砲水のように浴びせられると心が折れてしまいかねないので、多少は考慮しました。

また、これは完全にオレオレルールなのですが、Mooseアトリビュートのオプション指定順についての私案の順番の通りに並べています。自分であんな記事を書いておきながら、まだ順番を手で覚えるまでには至っていないため、自分のためのアンチョコとして記述しています。

判型と組版

Moose Quick-Ref CardはA4縦で、上下方向に2つ折りにしてA5横両面で使うことを想定した組版となっています。私家版では以下のような点を考慮して変更しています。

A4横1片面1枚に収めた

キーボードの手前に空いているスペースはA4横の縦辺だったという理由ですが、「jQuery Cheat Sheet」など、色々なチートシートを見てもA4横が多かったので、この寸法を採用しました。

4段組にした

私は「机の天板に透明シートを敷いて、その下に資料を挟み込む」ということをしていません。トナーが裏移りするだとか、梅雨時にべたつきかねないだとかの理由によります。

従って、クリアファイルやアクリルケースに入れて使うことを想定していますが、場合によっては2つ折りや4つ折りで使うことも考えられます。さっと手にとって目を通せるという意味では、卒業式の答辞で手に持つような縦長の張扇型の方が好ましかったりするからです。

具体的にはオライリー刊『UMLデスクトップリファレンス』(A5変判)などのデスクトップリファレンスシリーズなどを想定しています。

日本IBM刊『エンタープライズ・システム体系/370便覧』(N:GX20-0406-00)という旧世紀の遺物を例示しようとしましたが、同僚以外に分かってもらえそうにありません。EBCDICのページだけコピーしてチートシートにしたことはいい思い出です......。

ということで、折っても見られるような均等4段組で割り付けることにしました。電車の中での読み易さなどを考慮してか、最近では毎日に続いて読売や朝日も偶数段で組版していますね。

などと書いてから実際に4つ折りにしてみると、左右のマージンの考慮が漏れていて、折り目を跨いでしまっていることが判明しました。機会があれば直しておきます......。

関係性を目で追えるようにした

ネタは以下のように割り付けています。

1. 基本的な内容
   • (題名)
   • CLASSES
   • ROLES
   • METHOD MODIFIERS
   • CONSTRUCTION AND DESTRUCTION
2. hasのオプション
   • ATTRIBUTE CONSTRUCTION OPTIONS
3. 型と、場所が余ったのでMooseX::*
   • TYPE CONSTRAINTS & COERCIONS
   • MooseX::* EXPANSION MODULES
4. ネイティブトレートのヘルパーメソッド
   • HELPER METHODS FROM NATIVE TRAITS

この構成は以下のようなシナリオを想定して意図しています。

• 1段目にあるクラスやロールのスケルトンでhasがあり、hasのオプションが見たくなる。cf. ATTRIBUTE CONSTRUCTION OPTIONSとして飛び先を指示されるが、それはすぐ右の第2段にあるので、目で自然に追える。
• 2段目のisaでcf. TYPE CONSTRAINTS AND COERCIONSとして飛び先を指示されるが、それはすぐ右の第3段にあるので、目で自然に追える。

ただ、流石にネイティブトレートは無理でした。それだけで第4段を占拠してしまっているので、handlesに関連する内容として飛ばそうと思っても、第3段の型とは相乗り出来ないためです。

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

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

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

出来上がったものをどこに晒そうか迷ったのですが、Perl界隈にはせっかくperl-users.jpやperl-mongers.orgという素敵なサイトがあるので、この場末ドメインのブログではない公の場に寄稿すことにしました。

昨年末にYappoさんにCodeReposのコミット権をいただいたのでperl-users.jpの方に書こうかとも考えましたが、

• ブログだとコメントやトラックバックなどを受け付けられ、perl-mongers.orgではすぐにでもブログ記事を書ける
• 今回のネタはperl-users.jpの単独コンテンツほど精錬されていないように思えた

などの事情に鑑みて、今回はperl-mongers.orgにお世話になることにしました。

苦心したこと・書くまで気付かなかったこと

• 何と言うこともないものですが、アトリビュート構築オプションを分類して記述してみました。羅列すると圧迫感を感じるのは人間として無理からぬことだと思うので、或る程度の関連性のあるものを小分けにしてまとめています。
• ネイティブトレートの引数と挙動を書きました。absを使ったことがなかったため、アトリビュートの値を汚すことは知りませんでした。
• 「設定」と「指定」の使い分け。アトリビュートの値をセットすることを（defaultなどでセットされること）を「設定」・コードに各種のメタ操作を定義すること、記述することを「指定」と書いていますが、結構曖昧ですね......。「格納」と「記述」とかでも良かったかも知れません。
• 「オブジェクト」と「インスタンス」の使い分け。これも微妙ですが、an objectとan instance of a classの関係を気にしました。
• handles指定時にisa指定が必須であることなどは知りませんでした。私は「Moose入門研修」で「型は動的チェックなので、多用すると遅くなる」というお話を伺ったにもかかわらず偏執狂的にisaをほぼ必須指定しているので、なかなか気付きにくい仕様でした。

余談

CodeRepos.orgやLivedoor.comのOpenIDだとサインイン出来なかったので（原因は追えていません）他の方を参考にMyOpenID.comにアカウントを作ったり、MarkdownフォーマットだとWide character in subroutine entryエラーが出たので素のフォーマットで書いたりと、色々ありました。

そしてさらに、細かな修正を行おうとしてもmt.cgiがしばらく503になって再ログイン出来ない状態を引き起こしてしまいました（当日の昼には復帰していました）。何か私が悪いことをしてしまったか心配です。ごめんなさい。

ということで、取り急ぎtwitterでvkgtaroさんへお詫びというかご報告というかを差し上げました。

目次（完全版）

目次が膨大すぎるとかえって読む気が失せそうなので、先方には簡略版の目次だけ掲げています。当初書こうとしていた目次は、もう少し階層を深く掘った以下のようなものです。単語だけ眺めると、Mooseのイロハは網羅できているのかな、と思っています。

role_type, duck_type, 無名型, handlesにロールを渡した場合の挙動, DEMOLISHALL, Moose::Exporter等々の記述を省いたくせにカリー化辺りが入っているのは私の独断と偏見によります。

Parameterized TypesがMoose 0.26+であるとか、かなり昔から存在する機能についてはバージョンを明記しないようにしています。ただ、その閾値の見極めは難しいです。

• クラス/Classes
  • プラグマの有効化とシュガー関数のインポート/Turning on Pragmas and Importing Sugar Functions
  • アトリビュート/Attributes
  • メソッド/Methods
  • スーパークラス/Superclasses
  • ロール/Roles
• ロール/Roles
• シュガー関数/Sugar Functions
  • アトリビュートの設定/Attribute Installation
  • クラスの継承/Class Inheritance
  • ロールの消費/Consuming Roles
  • インターフェース/Interfaces
  • メソッドモディファイヤー/Method Modifiers
• アトリビュート構築オプション/Attribute Constructor Options
  • アトリビュートの拡張/Attribute Extension
  • アクセッサーメソッドの生成/Accessor Methods Generation
  • 型制約と型変換/Type Constraints and Coercions
  • コンストラクター引数/Constructor Arguments
  • 値の遅延設定と設定状況/Lazy Building, Predication and Cleaning
  • デフォルト値
  • トリガー/Triggers
  • 委譲設定/Delegation Setting
  • 文書化/Documentation
• 型/Types
  • 型制約/Type Constraints
  • 組み込みの型制約/Build-in Type Constraints
  • パラメーター化された型/Parameterized Types
  • 自動生成された型/Automatically Created Types
  • 型結合/Type Unions
  • 独自の型の定義/To Define Your Own Types
  • 型変換/Types Coercions
  • MooseX::Types
• 委譲/Delegation
  • オブジェクトへの委譲/Delegation to an Object
  • メソッドのカリー化/Method Currying
  • Perlの通常データ構造体への委譲/Delegation to Common Perl Data Structures
  • ネイティブトレートによるヘルパーメソッド/Helper Methods from Native Traits
• インスタンスの生成と破棄/Construction and Destruction of Instances
  • コンストラクターのフック/Hooks into Constructor
  • デストラクターのフック/Hooks into Destructor
• その他の内容の触り/Other Tidbits
  • 名前空間の汚染への対策/Measures against Namespace Pollution
  • メタオブジェクトプロトコルとClass::MOP/Meta Object Protocol and Class::MOP
  • メタクラスの不変化による高速化/Speed Up by Immutabilizing Metaclasses
  • Mouse
  • MooseX拡張モジュール/MooseX Expansion Modules
  • oose
  • インターフェースの消費タイミング/Timing to Consuming Interfaces
  • メソッド衝突対策/Measures against Method Conflict
  • テスト対策/Measures against Testing
  • Mooseを使うか否か/To Moose or not to Moose
• 情報源など/See Also
  • Mooseマニュアル/Manuals for Moose
  • Moose関連のその他の情報源/Sources about Moose
  • Perl関連の基礎文法最速マスター/The Fastest Ways for Mastering Basic Perl Grammar
  • 基礎文法最速マスターのまとめ/Collection of the Fastest Ways for Mastering a Programming Language
  • 正誤一覧/Errata

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なコンソールでの字詰めの問題等々を解消しています。上記スクリーンショットも差し替えています。全角半角の「文字幅」の取り扱い方については、（時間があれば）稿を改めて備忘録を起こす予定です。

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

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

物理的資源と人的資源のいずれも、正直に回答しましたが心配の種を播いてもいます。

CPU

まず、CPUです。これはまずい。私が主に使っている環境は少々特殊で、何せラジオボタンの選択項目には使用しているCPUが存在しないという有様です。

サーバーおよびワークステーション用CPUの選択肢がないことは理解出来るのですが、これで「うげっ、こいつはもしかしてPentium IIとかで動かしているのか？」などと思われて落とされないか、戦々恐々です（一部誇張あり）。

OS

主に使っている環境は未だにWindows XP Professional SP3です。モバイルPCではWindows Vistaの荘重な......と言葉を飾っても仕方がないので正直に書きますと「緩慢な」動作に感銘を受けて、Ubuntuを入れたりしています。

一方で、運営側にとって一番ありがたいのは、やはりWindows 7でのテストでしょう。売り止められてサポート期限も切られているWindows XPなどより、サービス開始を起点として一番長い寿命を見込めるWindows 7の方が、テストの

4年前に構築した自作ワークステーションは、Super πなどではまだまだ会社で使っている最新のPCをも蹴散らす成績を残していますけれども、流石にそろそろマザーボードごと交換しようとも考えていますので、その時にはWindows 7を載せようと思います。

ただし、それはあくまで未来の話。現時点では正直にXPと書くしかないので、「何だかんだ言ってもまだまだサービス開始時点ではXPユーザーが一番多いのではないか」という希望的観測を展開することにしました。

貢献時間

テスターとして貢献出来る時間も、少々心配です。平日は21～25時に帰宅するとして、頑張って2時間くらいと計算します。休日は寝溜めをするような非生産的な時間が多いのですが、この生活を見直して4～5時間。しめて「週12時間以上～24時間未満」の枠に収まります。

かつてEverQuestなどで頑張っていた時代（といっても殆どが大学生時代ですが）とはかなり見劣りがするかも知れません。いわゆる廃人などと称されるハードコアプレイヤーの方々と、いわゆるカジュアルプレイヤーの間に位置する、私のようなミドルレンジのプレイヤーが一番多いのではないだろうかと勝手に想像しています。ただ、あくまでテストなので、システム実装的な問題点の確認および報告を行うためには、貢献時間の長さが物を言うことは言うまでもありません。

ということで不安は不安なのですが、設計面やバランス調整など、ミドルレンジのプレイヤーならではの視点で貢献出来る余地があるのではないかとも思いますので、

意向調査

「環境調査」に比べて「意向調査」の色合いが強い項目は、心配の種にならない分、熟慮して回答しました。

訴求点

• 他のプレイヤーとの交流
• 強い敵との戦闘
• 世界観

「上位3つまで」という質問でしたが、順番をさらに付けるとしたら上記の通りになります。伝統的EQプレイヤーの回答ですね。他のプレイヤーとの濃厚な交流を旨とし、それをよすがとしてレイドエンカウンターとの交戦を行うという（PvPではなく）PvE重視で、それらを緻密に織りなされた世界観に抱かれて満喫するという案配です。

FFシリーズに対する情熱

これは大変答え難い質問ですが、私は100点満点中99点としました。

オフライン作品には初代からお世話になって来ました。大学生・社会人になってからは流石に全作品に手を伸ばせている訳ではありませんが、安心して財布の口を開けられるシリーズだと思っています。

オンライン作品については、世間一般では色々な意見が（オフライン作品以上に）あることと思いますが、その運営品質は比較第一級に位置すると考えます。不正行為への厳正な対処は、「当たり前のことを当たり前にする」ことの難しさも相まって、高く評価したい点です。

しかし、いずれも完全というものはありません。そうした「伸びしろ」が満点への差分ということになります。ということで伸びしろは1点分ということになりましたが、今にして思えばもう少し差分を大きく取った方が良かったかも知れません。「テスターに必要なのは太鼓持ちではなくて、真摯な評価者だ！」と突っぱねられる可能性があるからです。

しかし、上記のような採点根拠をstring型で書けない以上、integer型の値でのみ表現する必要があるので、あまり低すぎると「嫌いな人にテストしてもらいたくないね！」と突っぱねられる危険性もあります。

今後の展望

大学生時代と違って、業務に於けるテストの重要性は骨の髄まで染みこみました。テスターに選出いただけた暁には、誠心誠意テストに励む所存です。また、FF14プレイヤー向けウェブシステム「Amikeco」も、ベータテストに後れを取らないよう、開発にさらに発破を掛ける所存です。

といっても、テスターに選出されたことの表明自体がNDAに抵触する可能性もありますので、未来は何とも言えませんが......。

Class::Unload->unload('Some::Unneeded::Class');

当初、木本さん(perlcodesampleさん)による「クラスをアンロードする方法」の記事や、そこで言及されているClass::MOP::Class::DESTROY()を参考にして、以下のようなアンロードメソッドも書いてみました。その後、用途に適合するClass::UnloadモジュールがCPANで公開されていることが分かったので、自分の場合はこれを活用させていただこうと思った次第です。

いつの日かClass::Unloadがどうしても使えない場面に立ち会ってしまったら、これを引っ張り出してこようと思います。「だが、私はCPANを使えない！」の全ての処方箋が通用しないという、あまりぞっとしない場面ですが......。

sub _unload_class {
    my ($self, $class) = @_;

    my @route_to_class = split '::', $class;

    # unload class in target library which is dump target of generated classes
    # cf. http://d.hatena.ne.jp/perlcodesample/20091101/1246274997
    # below codes stolen from Class::MOP::Class::DESTROY()
    {
        no strict 'refs';

        # delete inheritance information from @ISA
        @{
            $class . '::ISA'
        } = ();

        # delete class symbol from symbol table
        %{
            $class . '::'
        } = ();

        # delete class symbol from upper namespace
        delete ${
            join '::', @route_to_class[0 .. $#route_to_class - 1], q{}
        }{
            $route_to_class[-1] . '::'
        };

        # delete loading information
        delete $INC{
            (join '/', @route_to_class ) . '.pm'
        };
    }

    return;
}

なお、上記はとあるクラスのメソッドとして実装していますが、$selfは使っていないので、単なるサブルーチンにも出来ます。

ところで、普通に暮らしているだけではクラスをアンロードしたいと思う場合が殆ど全くありません。アンロードしたいという稀少な事例の一つとして、拙作のDBICx::Modeler::Generatorでクラスをリロードするという例を掲げておきます（該当箇所はfcf4b0de...コミットに於けるDBICx::Modeler::Generator::Classの147行目です）。

このモジュールについては稿を改めてご紹介するつもりです。

しかし、クラス定数（のように使うクラスメソッドの戻り値）が単純な値であればともかく、何かの値を元に計算して導出するような代物だった場合、クラス定数（のように......以下略）を使う度に計算されたのではたまりません。

こうした場合には、Memoizeによるメモ化(memoization)が定番の処方箋となります。また、（もはやメモ化の文脈での例としては定番である）フィボナッチ数の計算など、クラス定数として使うものでないメソッドについても、同様にメモ化は強力な最適化方法論です。

Mooseクラスでは単純にMemoizeモジュールを使えば良いのですが、Mooseロールでは少々込み入った手順で使う必要があることが分かったので、備忘録的に書いておきます。

まず、Mooseクラスの例です。素直にmemoize関数を使えます。

{
    package Foo;

    use Moose;
    use Memoize;

    use namespace::clean -except => [qw(meta)];

    memoize qw(bar);

    sub bar {
        warn "bar\n";
        return;
    }

    __PACKAGE__->meta->make_immutable;
}
{
    package main;

    my $foo = Foo->new;
    $foo->bar;
    $foo->bar;
}

Attribute::MemoizeによるMemoizeアトリビュートを使うことも可能です。なお、大変こんがらがり易いのですが、MemoizeアトリビュートというのはMooseのアトリビュートではなくて、Perlの（サブルーチンや変数に付与する）アトリビュートです。

# ...

    use Moose;
    use Attribute::Memoize; # またはuse Attribute::Util qw(Memoize);

    use namespace::clean -except => [qw(meta)];

    sub bar : Memoize {
        warn "bar\n";
        return;
    }

# ...

Mooseロールにあるメソッドのメモ化

ロール消費クラスからメソッドが見えない

ロールでは単純には行きません。以下はCan't locate object method "bar" via package "Foo"という例外を送出します。もう少し正確に定義すると、Foo->meta->has_method('bar')は偽になります。ロール内でメモ化したメソッドは、ロールを消費するクラスからは見えない状態にあるのです。

{
    package FooBase;

    use Moose::Role;
    use Memoize;

    use namespace::clean;

    memoize qw(bar);

    sub bar {
        warn "bar\n";
        return;
    }

    1;
}
{
    package Foo;

    use Moose;

    use namespace::clean -except => [qw(meta)];

    with qw(
        FooBase
    );

    __PACKAGE__->meta->make_immutable;
}
{
    package main;

    my $foo = Foo->new;
    $foo->bar;
    $foo->bar;
}

memoizeにサブルーチンリファレンスを設定する

上記のように嵌ったのでググってみたところ、moose@perl.orgメーリングリストでMemoizing role methodsという、そのものずばりの質疑応答がありました。

有名なMSTことMatt S Troutさんによると、

1. Memoizeのマニュアルには、memoize関数にはメソッド名だけでなくサブルーチンリファレンスも渡せると書いてある
2. memoize関数の戻り値として、メモ化でラッピングしたサブルーチンリファレンスが返るとも書いてある
3. __PACKAGE__->meta->add_method('foo_method' => memoize(sub { ... }));とすれば、メモ化ラッピングサブルーチンに名前を付けて、消費元のクラス(consumer class)にメソッドを生やせる
4. もしくはmemoize('foo_method')の戻り値であるサブルーチンリファレンスをSub::Nameのsubnameに食わせることで、元のメソッド名を乗っ取って、メモ化ラッピングサブルーチン自体が呼ばれるようにすることが出来る

ということです。

subnameの戻り値をさらにグロブリファレンスに入れる理由は、Sub::NameのPODに書いてあります。おまじないだと思って書くことにしましょう。

現在の私の実装

上記を踏まえて、私は現在のところ以下のように実装しています。別の話題（別途記事を設ける予定の「実行時まで遅延させてMooseの型を生成・適用する方法」）の実現可能性調査で使ったGist: #230058から例示します。

# ...

sub _memoize {
    no strict 'refs';
    foreach my $method (qw(
        _numbers            _names
        _names_to_numbers   _numbers_to_names
        to_number           to_name
        maximum_number      maximum_name
        minimum_number      minimum_name
    )) {
        *{$method} = subname __PACKAGE__ . '::' . $method => memoize($method);
    }
}

__PACKAGE__->_memoize;

# ...

メモ化したい対象をforeachのリストに突っ込むだけで、後はいい感じに動いてくれます。

MooseロールにあるメソッドにMemoizeアトリビュートを付与する

これだけでも基本的には満足出来るのですが、メモ化するメソッドの一覧を書くことは、少々面倒です。

希望としては、メソッド側にMemoizeアトリビュートを付与しつつ、各メソッドを列挙することなしに名前空間のマジックに連携させることです。

メソッドにMemoizeアトリビュートを付与すること自体は可能

まず、メソッド側にMemoizeアトリビュートを付与すること自体が出来る、という確認です。

# ...

sub _memoize {
    no strict 'refs';
    foreach my $method_name (qw(
        _numbers            _names
        _names_to_numbers   _numbers_to_names
        to_number           to_name
        maximum_number      maximum_name
        minimum_number      minimum_name
    )) {
        *{$method} = subname __PACKAGE__ . '::' . $method => \&{$method};
    }
}

sub _numbers : Memoize {
    # ...
}

__PACKAGE__->_memoize;

# ...

これで問題なく想定の挙動をしてくれます。しかし、これでは何の解決にもなっていませんね。かえって、各メソッドと_memoizeメソッドの両方でメモ化対象を指定することになるだけ、多重保守の愚を犯してしまいます。DRYでないということです。

メソッドにMemoizeアトリビュートが付与されているかを調査する

メソッド側でMemoizeアトリビュートを付与しさえすれば、後は何もしなくて良い......ということが理想です。そのためには、_memoizeメソッドに於いて全メソッドを見て回って、各々にMemoizeアトリビュートが付いているかどうかを確認し、付いていればsubnameの流れに乗る、ということが出来れば良いわけです。

# ...

use attributes qw();            # 流石にgetという名前はインポートしたくない
use List::MoreUtils qw(any);    # でもanyはいいんです（オレオレ二枚舌基準）

# ...

sub _memoize {
    my $clss = shift;

    foreach my $method ($class->meta->get_all_methods) {
        no strict 'refs';
        *{ $method->name } = subname $class . '::' . $method->name
            => $method->body
                if any { $_ eq 'Memoize' } attributes::get($method->body);
    }

}

# ...

ところが、上記の実装は動きません。ロールにはmetaメソッドがない（ロールはMoose::Objectを持っていない）ためです。

それでは、ロールを消費するクラスのメタオブジェクトを見ようとすると、$consumer_class->metaとなるようにロールを消費するクラスの側で__PACKAGE__->_memoizeする方法などが考えられます。

しかしその案も駄目です。クラス側で_memoizeを呼んだ時には、既にロールはコンパイルされていますので、ロールでMemoizeアトリビュートを付けたメソッドはforeachのリストには入ってきません。

なお、ここまでしれっと書いていますが、そもそもattributes::getは組み込みアトリビュート(locked, methodなど)以外のアトリビュートが帰ってこないようです。従って、実はメソッドがMemoizeアトリビュート付きかどうかを判別する方法が、本日現在の私には分からないというお粗末な事情があります。

サブルーチン定義時に何とかMemoizeする

後からメソッドを洗うことを諦め、メソッドを定義した時点でメモ化しつつsubnameの仕組みに乗っかる案もありました。

# ...

*foo = subname __PACKAGE__ . '::foo' => sub : Memoize {
    # foo本来の実装
};

*bar = subname __PACKAGE__ . '::bar' => sub : Memoize {
    # bar本来の実装
};

# ...

しかし、無名サブルーチンへのアトリビュートの適用は出来ない（と理解している）ため、これも動きません。

ここまで来れば別にAttribute::Memoizeを使わずとも良いわけで、以下のような形でなら定義出来ます。周り巡って出発地点に戻ったような、少々異様なコードになりました。

# ...

{
    no warnings 'once';
    *foo = subname __PACKAGE__ . '::foo' => memoize(sub {
        # foo本来の実装
    });

    *bar = subname __PACKAGE__ . '::bar' => memoize(sub {
        # bar本来の実装
    });
}

# ...

だったら素直に以下のようにした方が直感的かも知れません。いずれにせよ微妙ですが......。

# ...

{
    no warnings 'once';
    *foo = subname __PACKAGE__ . '::foo' => \&foo;
    sub foo : Memoize {
        # foo本来の実装
    }

    *bar = subname __PACKAGE__ . '::bar' => \&bar;
    sub bar : Memoize {
        # bar本来の実装
    }
}

# ...

まとめ ～ 敗北宣言

開き直ってロールを消費するクラス側でメモ化してしまう手もありますが、それでもやはりDRYではありません。Perlのアトリビュート周りも、MooseやClass::MOPの奥深い部分も、私は殆ど理解せずにブラックボックス的に使ってしまっているので、もう少し勉強をしてみたいです。

MSTさんも「Memoizeのマニュアルをちゃんと読まない人達のために、Mooseのドキュメントに追記が必要ですか？」と記しているように、もしかしたらご立腹されているのかも知れません。ごめんなさい、ちゃんとドキュメントを読みます。

機会があったら試行錯誤して雪辱を果たそうと思います。

例えば、初期化ハッシュキーを跨いだ検証などが挙げられます。triggerの使い方についての記事で説明用に作った、元号と西暦のアトリビュートを持つ昭和クラスで想定してみます。

元号と西暦の両方を指定された場合、その両方のアトリビュートが未指定になります。undefという値が入っているのではなく、has_imperial_eraなどのpredicateメソッドの戻り値が偽であるという意味です。

それでは困るので、コンストラクター引数に指定するのは元号と西暦のどちらか一方のみに制限する......という要件が出て来たこととします。その場合、ハッシュとハッシュリファレンスの両方でキーを見付ける処理をBUILDARGSに書くのではなく、親クラス(最終的な親はMoose::Object)のBUILDARGSを呼ぶようにすると、素直に書けます。

# ...

around BUILDARGS => sub {
    my $next  = shift;
    my $class = shift;
    # ここでは@_はハッシュかも知れないしハッシュリファレンスかも知れない

    # 親クラス(Moose::Object)のハッシュリファレンス化はBUILDARGSに任せる
    my $init_args = $class->$next(@_);  # ここではハッシュリファレンス

    confess 'Initialization argument must be '
          . 'any one of imperial_era or christian_era'
            if exists $init_args->{imperial_era} 
            && exists $init_args->{christian_era};

    return $init_args;
};

# ...

こんなものは常識なのでしょうけれども、意外とこういう初歩的なところの認識が甘くて、今までは（後述するように）ハッシュリファレンスのみを食べるような偏屈APIを撒き散らしていました。反省反省。

以下は補足情報です。

親クラス(Moose::Object)のBUILDARGSを修飾せず、自クラスでBUILDARGSクラスメソッドを定義しても、親クラスのBUILDARGSを呼べば同じ事です。

# ...

sub BUILDARGS {
    my $class = shift;

    my $init_args = $class->SUPER::BUILDARGS(@_);

    confess 'Initialization argument must be '
          . 'any one of imperial_era or christian_era'
            if exists $init_args->{imperial_era} 
            && exists $init_args->{christian_era};

    return $init_args;
}

# ...

親のBUILDARGSを使わない場合

Mooseのコンストラクターは、デフォルトではハッシュリファレンスかハッシュを受け付けます。自分のBUILDARGSクラスメソッド内で、コンストラクター引数がハッシュリファレンスであるかハッシュであるかを判断する処理を書くのは、とても面倒です。

# ...

sub BUILDARGS {
    my $class = shift;

    # @_がハッシュであるかハッシュリファレンスであるかを判別する処理は、
    # Moose::Object::BUILDARGSと同じことなので面倒
    # ...
}

# ...

自分のクラスではコンストラクター引数にハッシュリファレンスのみを受け付ける（ハッシュは受け付けない）と決めてしまえば、例えば以下のようにも書けるでしょう。

# ...

sub BUILDARGS {
    my $class = shift;

    if (@_ == 1 && ref $_[0] eq 'HASH') {
        confess 'Initialization argument must be '
              . 'any one of imperial_era or christian_era'
                if exists $_[0]->{imperial_era} 
                && exists $_[0]->{christian_era};
        return $_[0];   # もしくは$class->SUPER::BUILDARGS($_[0]);
    }
    else {
        return $class->SUPER::BUILDARGS(@_);
    }
}

# ...

ただ、ハッシュを敢えて拒否するような理由がない限りは、費やすべき労力はそれほど変わらないので、素直にMoose::Object::BUILDARGSを呼んだ方が良いと考えます。

余談: ハッシュやハッシュリファレンス以外の引数を使いたい場合

Moose::Manual::Constructionでは、それ以外の場合（例えばスカラー値など）の対処法が書かれています。今回の要件とは違いますが、後輩への説明用に余談として述べておきます。

Personクラスは、米国在住者の背番号（つまりは一意に識別出来る、id）である社会保障番号（ssn : Social Security Number）の文字列を渡すだけでオブジェクトを生成してくれると便利だ、という例です。

# ...

has 'ssn' => (  # 社会保障番号
    is          => 'rw',
);

# ...

around BUILDARGS => sub {
    my $next  = shift;
    my $class = shift;

    if (@_ == 1 && ! ref $_[0]) {
        return $class->$next(ssn => $_[0]);
    }
    else {
        return $class->$next(@_);
    }
};

# ...

昔のバージョンのMoose::Manual::Constructionでは、メソッドモディファイヤーで親を修飾するのではなく、自クラスでBUILDARGSクラスメソッドを実装するように書かれていましたが、これも要は同じ事です。

# ...

sub BUILDARGS {
    my $class = shift;

    if (@_ == 1 && ! ref $_[0]) {
        return {
            ssn => $_[0],
        };
        # 必要に応じて、以下のようにする方が良いかも知れません
        # $class->SUPER::BUILDARGS({ssn => $_[0]});
    }
    else {
        return $class->SUPER::BUILDARGS(@_);
    }
}

# ...

余談: BUILDかBUILDARGSか

BUILDの引数は、コンストラクター引数にハッシュを渡そうがハッシュリファレンスを渡そうが、一律にハッシュリファレンスとなっています。従って、技術的には以下のようにBUILDでバリデーションロジックを設けることも不可能ではありません。

# ...

sub BUILD {
    my $self = shift;

    confess 'Initialization argument must be '
          . 'any one of imperial_era or christian_era'
            if exists $_[0]->{imperial_era} 
            && exists $_[0]->{christian_era};

    return;
}

# ...

しかし、既にオブジェクトを作ってしまった後に、そのオブジェクトの初期化変数を検証するのは、順序が逆転しています。おかしな値を拒絶するのは出来るだけ早い段階の方が良いので、今回の場合はBUILDARGSでフックしています。

勿論、生成されたオブジェクトのアトリビュートを跨いだ検証などは、素直にBUILDを使えば良いです。

この辺りは、初期化時に行いたい処理によって、BUILDARGSにフックするのかBUILDにフックするのかを決めれば良いでしょう。迷ったら、早めに死ぬようにBUILDARGSを選ぶのが無難です（そして、きちんと検証出来ていることをテストで確かめましょう）。

まず、DIパターンやDIコンテナーを使うことの目的は、直接的には、モジュール間（より具体的には、例えばドメインモデルとORMというようなレイヤー間）の結合性を疎にすることです。

「Mooseのアトリビュートへ依存オブジェクトを持たせることでも疎結合に出来る」というdannさんの指摘（DIとは何か 番外編 - DIコンテナを使わずにModelのTestabilityを高める方法）が一つの具体例ですが、元々Perlは（動的言語であるので）イントロスペクション（オブジェクトの中身を実行時に参照すること）のみならず実行時のDI自体はお手の物です。従って、DIがなければ死にそうなくらい大変かというと、必ずしもその通りではありません。

ただ、あまり根を詰めずとも試験容易性（テスタビリティー）の向上という利益が得られるという点で、DIコンテナーのお世話になる費用対効果が大きいと判断しました。私は怠け者なのです。

さらに、DI採用によって将来的に（今回は使用を一旦留保した）新進気鋭のモジュールに切り替え易くするという狙いもあります。これは「新進気鋭のモジュールを活用する実装を一旦断念して、定番のモジュールを活用することにした」という自分自身の負い目に対する代償行動のようですが、これこそが今回DIコンテナーのお世話になることに決めた最大の理由だと自己分析しています。

ということで、何故突然DIコンテナーを実用してみようかと思ったのか、その辺りの事情についての補足でした。前段と後段の内容の結節点となるこの補足がないと、何が何だか分かりませんでしたね。補足があっても寝不足気味なので変なことを書いているおそれがありますが。