様々な麻疹を発症して得たもの
これまで僕は、いくつか麻疹的な傾向をもって、いくつかのオープンソースなプロダクトを公開してきた。
このエントリでは、そんな麻疹的傾向のプロダクトといきさつを簡単に紹介しつつ、それらを開発/公開することで得たものを大まかに共有していこうと思う（人はそれを「オープンソース・プロダクトの法要」などと呼ぶかもしれないが、今もって実戦投入されている物もあったりするので、決して法要的なものでは『ない』）。
なお、紹介の順序は、時系列でもお気に入り順でもなく、思い出した順である。
Testament
これは、いまやすっかり大物となってしまった、moznionという若者との共同作品である。開発も『泥酔ハッカソン』などの最高なハックイベントなどを通じて行われていた。
何をするものかというと、sparcやia64のようなアーキテクチャ上でのPerlモジュールのテストを支援するもの（というか環境構築ツール）であり、当時ユニットテストに対して並々ならぬ情熱を注いでいたmoznionが、某桧舞台で発表題材の一部として取り上げていた。
技術的にはqemuのフロントエンドツールであり、コマンド一発でOpenBSDなどの仮想環境が構築できる。アーキテクチャもある程度指定可能で、qemuがサポートしている物であれば、大体利用できる（対応osによる）。
しかしながら、現在ではこのプロジェクトはすっかり沈静化しており、その原因は以下のとおり割と明らさまである。
VagrantやDockerがあるのでTestamentを使う必要が無い
ターゲットがものすごくレアなわりに開発労力がすさまじい
なお、このプロジェクトを通じて得た知見としては、以下のようなものがある。
需要はなさそうだが、気になっている人間は結構いた（事実、大元のプロジェクトにはスターが7つもついている！）
VagrantやDockerは使いやすかった
qemuでは、2GBを越えるメモリ割り当てを行うには64bitなホストOSでなくてはならない
マイナーなアーキテクチャーのテストは実機でやった方がよい
OpenBSDはシンプルなので、仮想環境向けには使いでが良い
自分一人で作るよりも完成度の高い物ができたし、楽しい。
Nephia
ミニサイズなWAFという触れ込みで、様々な方々にご協力をいただきつつ、開発・公開したものである。実際上記のリンクを見ても、様々なモジュールが関係しているのがわかると思う。
さて、Nephiaというのは当初、「JSON-APIを楽ちんに作る君」的なポゼッションを目指して開発したものであった。DSLを推奨しており（というかDSLしかない）、コントローラメソッドの返り値の型を見て、JSONで出力したり、生のレスポンスを返したりした。
しかし、内部構造があまりにもカオスとの評判から、それまでNephiaと呼ばれていたデジタルデブリをPrimalNephiaという名前に移し、新しくNephiaを作り直した。それはマイクロコア・アーキテクチャとも呼べる代物であり、拡張性が高く、魅力的に見えた。
だが、あまりにも拡張性が高すぎて、ドキュメンテーションが分散してしまい、およそ一見さんが利用できるような状況とは言い難い。一応個々のプラグインにはドキュメンテーションが整備されているので、使えないわけではないが、やはり体験的には苦しいものがあると思う。
反面、『メタ』なWAFと位置づけて見てみると、上記の分散指向は一気に利点へと変貌する。つまりNephiaは『オレオレWAFツクール』だったんだよ（迫真）！！！！
このような何とも捉えどころの無い代物ではあるけど、実は個人のプロジェクトでは結構便利に活用している。例えば現在開発途上のRainviewというwebアプリも、このNephiaを使って構築されている。セットアップフレーバーも何種類かあるが、僕はNephia::Setup::Plugin::Relaxを愛用している。このセットアップフレーバーこそがWAFと呼べるものだったのではないか。
さて、このプロダクトから得た知見は以下のようなものである。
不節操なDSLは人を殺す。クラスメソッドとインスタンスメソッドを使って人にやさしくしよう。
驚き最小の法則はすばらしい。
WAFというものは基本的に「お仕着せ」すべき立ち位置の物である。
WAFというものは『Router』『セットアップスクリプト』『コンテキスト』の出来で9割くらい使いやすさが決まってくる。
一緒に作ってくれる仲間がいると、とても捗るし、楽しい。
Otogiri
これについては、麻疹ドリブンで作ったわけでは無いけれど、ORMと呼ばれるものは大抵麻疹の類から発生するものらしいので、ここに列挙しておく。
そもそも僕は業務でもプライベートでもTengという最高便利なORMを使っているわけだが、こいつの唯一の弱点として、Schemaクラスの存在が挙げられる。シンプルな話、DB内の特定テーブルの情報をとってくるためだけに、わざわざアプリケーション側でスキーマを定義する必要があるわけで、頻繁なテーブル変更（年に3回以上のテーブル定義の追加・変更は頻繁であるという認識）はつまり、頻繁なスキーマ変更を伴う。もちろん、Teng::Schema::Dumperのような自動生成ツールもあったりするわけだが、カラムの型定義にはマジックナンバーが採用されているので、お世辞にも可読性が高いなどとは言えないし、Inflate/Deflateの定義がある時のことを考えると、自動生成も微妙というケースが多々ある。
上記のような不満から、僕は「そもそもスキーマなんてなくても使える『ORM的な何か』があれば、それで充分じゃないか」と思い立ち、クエリビルダーであるSQL::Makerと、数多あるDBI拡張の中でもとりわけ使いでの良かったDBIx::Sunnyを組み合わせて、このOtogiriを開発・公開した。
自ら主催するMachida.pmでこのOtogiriについて発表したが、概ねご好評いただいた様子だった。また、共同で開発してくれているtsucchiさんの力により、プラグイン機構と各種ユーティリティ（プラグインとして提供されている）がリリースされたりもした。
前述のNephiaのセットアップフレイバーの１つであるRelaxにも組み込んだし、__papix__君によってReplyから簡単に使えるようなReply::Plugin::ORMがリリースされたりと、本当に恵まれたプロダクトだと思う。
最近では、某気象関連のプロダクトで、設定移行作業にこのOtogiriを利用した。およそ200万あるレコードを高速に移行する必要が有り、そのままでは速度が伸び悩んでいたため、Otogiri::Plugin::BulkInsertを作って利用した。これは先ほどリリースしたので、cpanmでよしなに利用可能である。
このプロダクトを開発・公開した結果得られた知見は以下のようなものである。
DBスキーマの運用コストを意識できた。
MySQLやPostgreSQLを活用した最近のテスト手法を復習できた。
メソッドを追加する系のプラグイン機構はExporterで十分そうだと思った。
シンプルなプロダクトは使いやすいという認識の再確認ができた。
仲間がいると心強い。
まとめ
要するに、自分にそこそこの力があるなら、あとは『やりたいこと』と『仲間』がいれば、それなりの成果を残すことができる、ということです。
少なくとも上記のうち、Otogiriはとても役に立っているし、作ってよかったと思っています。