モジュール世界観考 - ぱいぱいにっき

とりあえずメモがてらに記述しておく。

対象読者

LLを使ったサーバサイドWebアプリケーションエンジニア

tl;dr

この記事に結論はない。思いを馳せたことを記述するのみである。
あと長いのでだらだらしたのを読みたくない方はブクマせず閉じるボタンをどうぞ。
ポエムなのでそういう苦手な方はブクマせず閉じるボタンをどうぞ。

ポジション

仕事ではPerlを使ったネイティブアプリケーションのサーバサイドAPIを書く。
趣味ではPerlを使ったWebアプリケーションやGolangを使ったライブラリやミドルウェア等々
Ruby on Railsは触ったことがない。

rapid developmentというコンテキスト

僕がWebアプリケーションフレームワークなるものを初めて触ったのはCakePHPで、それまではPHPでベタッと書いていたのを覚えている。Traditional PHPと言われる手法である。
当時はPHP5系が出始めでclassとかPHPで意味あんの？とか思っていてオブジェクト指向もあまり理解していなかったのだけれど、CakePHPを触ることでオブジェクト意味あるやんって思ったし、あらかじめ用意されている部品を使って素早く見れるレベルのWebアプリケーションを作ることが出来た。なるほど、と思った。
で、CakePHPが「rapid development framework」と当時も掲げていたし今でも掲げているわけで、うりとしては高速に開発できますよということらしい。

micro frameworkというコンテキスト

僕がCakePHPの次に触ったのがPythonのFlaskというフレームワークでこいつはCakePHPのようなフルスタックではなくルーティングとテンプレートエンジンのみを提供したまさにマイクロなフレームワークだ。
Flaskが提供していない部分、例えばORMapper等はSQLAlchemyとかを使っとけとか書いてある。僕はFlaskでDBアクセスをしたことがないのでこのあたりはよく知らない。この文脈から出たRubyのSinatraなんかもそうだったりするらしい。つまりこれらを使うにはモジュール/パッケージソムリエなる職能もしくは役割が必要である。

Webアプリケーションフレームワークの3要素

ここで僕が思うフレームワークの要素を書き出してみる。もちろん世の中のフレームワークにはこれらを搭載していないものもあるし、僕がいいたいのはそれらが不完全なフレームワークだということではない。

ルーター
ORMapper
テンプレートエンジン

もしかしたらJSONを吐くAPIのサーバはテンプレートエンジンを必要としないかもしれないし、そもそもDBにアクセスをしない場合はORMapperは要らない。先ほどFlaskで必要なかった理由はそれはGoogle App Engine上で開発しており、データベースはCloud Datastoreを使っていたからである。ここでORMapperの定義も必要になってくるかもしれないけれど、SQLをその言語のインターフェイスで組み立てるだけでは不十分で、MapperたるにはそのSQLをDBに投げて帰ってきた結果をその言語に合うObject形式に変換するということろだと思う。

思うところこれはフレームワークとはただの糊である。ルーターやORMapper、テンプレートエンジンは複雑なWebアプリケーションを作るにあたってほぼ必須と言える要素だけれど、なにもこれをフレームワーク内に内包する必要はない。糊としての繋げる仕組みがあれば十分なのである。

仕事

僕が今の職業についてからもっぱらWebフレームワークはPerl5のArkというものを使っている。ArkはCatalystというフルスタックフレームワークを部品に分けて再構成したものである。
ルーター部分にはPath::AttrRouterを使い、テンプレートエンジンはText::MicroTemplate、ORMapperはDBIx::Classを用いている。であるがあくまでこれらは標準構成である。
僕の関わったプロジェクトではテンプレートエンジンをText::Xslateに、ORMapperをTengに置き換えたものが多かった。今ではDBIx::Classを使っているけれど、そこの組み換えも自由である。

ときどきプライベートではPerlを使ってWebアプリケーションをさくっと書くことがあるのだけれど、そういうときにはAmon2を使っている。Amon2はText::Xslate + Tengの組み合わせを推奨していて、さらにルーターは過去のバージョンではRouter::Simpleが使われていたが今ではRouter::Boomが使われている。

Mojo

で、最近PerlではMojoliciousというフレームワークが興ってきていて、MojoConfという専門のカンファレンスも開かれたらしい。で、Mojoliciousというのはフルスタック中のフルスタックで、cpanm Mojoliciousとかするといろんなツールが入ってくる。開発用サーバも本番用サーバも入ってくるし、非同期系のモジュールやスクレイピングに使うDOM操作のモジュールまで入ってくる。あとMojo::*空間が広大だ。Mojoに使われることを想定したプラグインやモジュールが大量にある。

Mojoに(モジュール|人)が依存することの是非

で、僕は以前Promisesというモジュールを非同期環境で使おうとしたことがあったのだけれど、そのときのPromisesはMojo::IOLoopに依存しており、Mojo::IOLoopは単独で存在するモジュールではなくMojoliciousに内包されているパッケージだったので、cpanm Promises::DefferedとするとMojoliciousまで入ってきて、お、おうということになったことがある。
WAFは他のものを使っているのにそのモジュールを使いたいだけでMojoliciousを入れるのはなかなか抵抗がある。厳しい。
最新のバージョンでPromisesはMojo::IOLoop依存がなくなっているので思う存分使えるっぽい。ので今度試してみたい。

でもこれはある面から見たMojoの難点であって、他のいくつかの面ではモジュールを内包することがスバラシイという場合もある。
たった一つの依存で #yapcasia のトーク応募ソーシャルランキングをつくる - ゆーすけべー日記
この記事を見たときにそう思った。Mojo入ってたらこういうスクレイピングするアプリケーションがそれだけで書けるのである。テンプレートエンジンやルーター、サーバも入っているのでここではcliアプリケーションになっているのをWebアプリケーション化するのもMojoだけで可能である。
これはすごいメリットで、先ほど言ったモジュール/パッケージソムリエが必要ないのである。

例えばCPANにはXMLを操作するモジュールは以下のものがある。

XML
XML::LibXML
XML::Simple
XML::XPath
XML::TreePP
XML::Diver
その他いっぱい

だいたいXML::LibXML使っとけば良いらしい。XML::XPathは破綻しているらしい。
とまあそんな感じでソムリエの意見を聞く必要がある。もしくは自分で地雷を踏みに行く必要がある。そして地雷を踏み抜いても耐えられる何本かの足が必要である。

で、MojoはMojo::DOM使っとけば良い。それだけでたいてい事足りるようである。
そういうわけでフルスタックなフレームワークは面倒臭いこと考えずにrapidに開発できる。これは非常に大きいメリット。

しかし、Mojoみたいな全部あるフレームワークを常に使っとけば良いというわけではないのがこの世の中である。

フレームワークが出来ないことがある

フレームワークはスイスアーミーナイフであってもスイスアーミーナイフが金を生み出すわけではない。スイスアーミーナイフはその鋭利な切っ先で物を切ったり缶切りで缶を開けるといった想定されていることにしか利用できない。
フルスタックフレームワークもそうで、当然提供されている機能しか使えない。
そういうときに結局ソムリエが必要になってくる。そういった時に人はどうするか？　コミュニティに聞くしか無いのである。もしくはその道のプロフェッショナルを雇ってお金で解決するしか無い。
さもなくは、再発明である。個人的に再発明は悪だと思っている。でも必要悪だと思っている。しかし避けなければならない。その再発明品は自分、もしくは社内にしか目に触れられないのであれば、OSSのものよりもはるかに実績がない。
万人が使えるものは万人に使われるので、それだけの場数をこなしていると僕は考える。もちろん万人に使ってもらわないといけないので、宣伝も必要だし、使われやすい工夫も必要だ。でもそれ以上に様々な環境で使われるプロダクトは強い。
で、強いプロダクトかどうかを判断するのにソムリエが必要で、これまた経験が必要。
自分には経験がない人はどうするか。コミュニティに入ってプロフェッショナルたちとコミュニケーションを取るしか無い。お金は必要ない。TwitterとかYanchaとかLingrとかIRCとか、そういうところで聞けば良い。もしあなたが自分でコードを書く気があって、それをコミュニティのチカラで解決しようと思うなら、それ以上の代償は必要ないだろう。