Perl on Railsの話

英国放送協会(BBC)がPerl on Railsを名乗るMVCフレームワークを開発したという話が一部をにぎわしていたので、簡単なまとめ。英語で話を追える人は下記を（コメント欄含めて）順に読んでいけばOKです（これ以外にもスラッシュドット（本家）をはじめ、いくつかのソースに情報が分散していますが、必要な流れはだいたいこの三つで把握できるはず）。

さて、本題。2007年11月30日に「BBCが自社フレームワークとしてPerl on Railsを開発した」という情報がBBCラジオラボのブログで公開されました。ここでいうBBCというのは「英国放送協会」のこと。訳語をあげておくだけで十分だと思いますが、BBCはフットワークの軽いベンチャー企業ではありません。当然ながら、大企業には大企業の苦労があるわけでして、その記事によると、もともとBBCのサイトの大部分は静的HTMLを本番サーバにFTPでアップするという形で運営されていたのですが、サイトが大きくなって管理も大変になったし、番組表を用意するときに静的ファイルのままでは管理しづらいといった理由から動的生成できるフレームワークが必要になった――のですが、残念ながら既存のフレームワークは機能が足りなかったりBBCのサーバ上では動作しなかったりしたので、各種制約と移行コストの兼ね合いも考えて、すでに内部アプリケーションの開発で十分な利用実績があったRuby on Railsの流儀を真似たPerlフレームワークを自社開発することにした、と。また、これまでBBC内部では横のつながりが弱くコードの共有が十分に行われていなかったので、このPerl on RailsではBBCとつきあいのある開発チームにも積極的にコードを提供してもらおうと思っているということも語られています。

名前の問題をさておけば、特にどうという話でもないでしょう。そのBBC製Perl on Railsのコードが広く公開されるかどうかはさておき、これに、たとえばJiftyやSoozyのような独自の名前がついていれば、よくある「自社フレームワークを作成しました」という話で終わっていたものと思われます。

ところが、これにPerl on Railsという名前をつけて公開してしまったがために、一部から「なんで素直にCatalyst（ないしRuby on Rails）を使わないんだ」「なんで車輪を再発明するんだ」という横槍が入ります。実態はぜんぜん違うわけですが、Ruby on Railsに対する対抗馬という程度の意味でCatalystはPerl on Railsであるという評判が立っていた時期があったことも一部の人々に過剰な反応をさせた原因となったのでしょう。

その横槍の根拠はさまざまでしたが、翌日、同じくBBCでエンジニアをしている人が明かしてくれた理由は実に身も蓋もないものでした。

On the live environment we were told at the time we had Perl 5.6, and a few BBC approved perl modules. Nothing more! So that meant that catalyst a other solutions were out.
（本番環境に入っていたのはPerl 5.6とBBC公認のいくつかのモジュールだけだったから、CatalystやJiftyを使うわけにはいかなかったんよ）

念のために書いておくと、BBCとPerlのつきあいはそれほど浅いものではありません。CPANを見ればわかる通り、BBCは少なくとも2004年からCPANにモジュールを提供してくれていますし、初期バージョンがだいたい安定版を越えているところから見てもそれ以前から開発が続けられていたことは容易にうかがえます。モジュールの品質についても、たとえばPod::Xhtmlには星五つがついていますし、星一つのPod::Usage::CGIにしてみたところで評価を読んでみると、ものが悪いというより、一般の用途までは対応し切れていない部分があるという程度ですから、少なくとも現場レベルの技術力に疑問を呈する必要はないでしょう。

また、最新技術に関心が薄いわけでもなく、YAPC::Asia 2006の際に来日してプレゼンテーションしてくれたLeon Brocard氏（とLeo Lapworth氏）のMighTyVは2005年にBBCが開催したTV Listings competitionの成果物でしたし、London.pmのワークショップに参加してライトニングトークをしてくれるようなメンバーもいるとのこと。Andy Lester氏の記事によると、Perl Hacksの共著者でもあるCurtis "Ovid" Poe氏も現在はBBCの仕事をしているそうですね。

その辺を承知でなお「それならPerl5.8にすればよかったんじゃないの」とか「ローカルにモジュール突っ込めばいいじゃないの」と食い下がる人もいましたが、今度はBBCがサーバを含めたもろもろをSiemensに売却・移管してしまっているため、ひとつのモジュールを追加するだけでもえらく苦労させられる（稟議を通してテストしてもらって……で何日、下手をすると何週間、何ヶ月、何年もかかってしまう）という話が出てきます。それもまた大企業の場合はありがちな話ですが、移管先のSiemensが悪いのか、それとも依頼元のBBCのセキュリティポリシーに問題がありすぎるのか、

Yes, that’s right, Siemens forks Perl to remove features that their engineers don’t like.
（その通り、Siemensは自分のところのエンジニアが嫌がる（システムコールやなにやの）機能を全部取っ払ったPerlを作って（顧客に使わせて）いるんだ）

とか

The recent deployment of Template Toolkit to the BBC servers is one such example - Siemens took years and objected to this constantly, and when finally they assented to provide the single most popular template language for Perl, they removed all code execution functions from the language.
（最近ではTemplate Toolkitの例がそうだ。Siemensは何年も駄目だと言い続けていたんだが、ようやく納得してこいつを入れてくれることになったと思ったら、コードを実行できる機能を全部取っ払ってしまったんだから）

という徹底ぶりとあっては、そりゃあ既存のものを使うより自分たちで枠内に収まるものを作った方が早いという気持ちにもなりましょうし、社内や出入りの業者向けにはソースを公開・共有しても、一般にまで公開するかどうかはわからないというのも、結局はその制約がある以上、どんなコミットでも受け入れられるわけではありませんからごく自然な流れでありましょう、と。

もちろん現場の方もただ手をこまねいているわけではなく、亀の歩みながら事態を改善しようとしているようですし、今回のポイントはそのような制約のもとで新しいフレームワークが生まれた結果、BBCのサイトが便利になりつつあるよ、ということですから、部外者のわれわれとしては、名前に苦笑しつつも今後の動向を生暖かく見守っていればよい話です。