CPANモジュールの contribute

ところで、livedoor のエンジニアあるいは元 livedoor の方々には CPAN Author が結構たくさんいらっしゃいます。はてなでも、Perl コミュニティあるいは CPAN にはかなりお世話になっているので、自分たちの成果をいくばくか還元できないか、と考えています。

目下の目標は、はてな記法の parser とはてなのウェブアプリケーションフレームワークのオープンソース化で、前者は少し進捗あり、後者は遅々として進まず...といったところです。

でまあ、会社として contribute するというのもアリなのですが、もう少し個人レベルで積極的に CPAN にモジュールをアップする文化を作りたいなあとも常々思っているのですが、なかなかそういう感じにもならない。

なんでかなあ、と考えていたのですがその原因の一つにはてなフレームワークのアーキテクチャやはてなでの開発手法が関係していそうだな、と感じている今日この頃です。

先日読んで面白かった記事に http://www.javaworld.jp/technology_and_programming/-/17501.html というものがあります。これは Java の Struts をはじめとする MVC フレームワークの話から始まるのですが、この中でフレームワークのアーキテクチャが Transition ドリブンなのか、Page ドリブンなのかといった話が出てきます。要は、そのフレームワークは、どういう開発手法に主眼を置いて定型化したフレームワークなのか、という話。Transition ドリブンは遷移(あるいはイベント)、Page ドリブンはウェブのページをベースに、ということ。

で、はてなフレームワークは Page ドリブンなフレームワークです。詳細は割愛しますが、例えば URL に対してクラス名が一意に決まる仕組みなどを持っていたり、ページへのリクエストを受け取ってからそれを書き出すまでの一連の処理を何段階に分けて抽象化していたりします。そのため、開発にあたっては、まず URL を決めて、このページにはこれこれこういう要素が必要だから、こういうプラグインを書いて...という具合で作っていきます。

はてなフレームワークによる Page ドリブン開発の利点は、該当ページの表示に関連する処理がどこに書かれているかを、フレームワークのアーキテクチャだけで判断できる点です。コードを見なくても、このページの処理はあのクラスに書いてある、というのが分かるため、修正箇所を容易に特定できます。

その反面、開発するにあたっての分析対象のスコープが、常にある特定の1ページの範囲内であるため、何か大きな一連の処理を、フレームワークに依存しない形で抽象化するというプロセスがなかなか生まれにくい。(各ページに共通している処理は、フレームワークに差し込むプラグインのような形で実装するため、それも汎用化モジュールになりにくい)

あとは、スピード優先で開発しているためなかなか腰を据えて汎用モジュールの開発に取り組む、といったことにはなりにくかったりもします。

このあたりのプロセスを少し改善して、記法 parser とかフレームワークよりももっと小さな単位のモジュールを、はてなの開発者個人個人の判断で CPAN に登録していけないかなあと、最近考えています。

と、いうことで CPAN Author としての活動をしながら働きたい方も、是非いちどはてな入社をご検討ください。(笑)