Day 2: Clack - 八発白中

これは fukamachi products advent calendar 2016 の2日目の記事です。

今日はClackについて話します。

YAPC Asia 2010 keynote

僕が最初に学んだプログラム言語はPerlでした。その後PHPでのアルバイトを経験しましたが、好きな言語はやはりPerlでした。

最初に参加したカンファレンスはYAPC::Asia 2009だったと思います。まだPerlを始めて数年の若者で、技術力なんて吹けば飛ぶほどのものです。

当時はPerlにもまだ勢いがあり、YAPCは日本最大規模のカンファレンスでした。いろんな人が入れ替わりでPerlの話をし、ある人は自分のプロダクトのこと、ある人は会社での運用について、またある人はPerlの言語自体のことなど、内容はさまざまでした。そのとき受けた刺激は僕のプログラミング活動に大きく勢いをつけ、いつか自分も壇上に立てたらいいなと憧れていました。

特に僕に影響を与えたのは翌年YAPC::Asia 2010のmiyagawaさんのKeynoteスピーチでした。

最近のmiyagawaさんはrebuild.fmのオーガナイザーとして知っている方も多いかもしれませんが、その頃はPSGI/Plackの作者として、サンフランシスコにいながらPerlコミュニティの中心人物です。

彼のKeynoteは今でも動画で見ることができます。

The Tale of Plack : Talks | トーク - YAPC::Asia Tokyo 2010

これを聞いて、彼がWSGIやRackから影響されてPSGI/Plackを作ったように、僕にも何かができるのではないか。そういう単純な無邪気さで僕は、彼がPerlコミュニティにしたことを、Common Lispコミュニティでも目指すことに決めたのです。

6年前のCommon LispのWeb事情

6年前のCommon LispのWeb周りの状態は、今考えると悲惨なものでした。

Webフレームワークと呼ばれるものはいくつかあった *1 のですが、どれもメンテナンス状態がとても悪い。ドキュメントも不完全。RDBMSとの連携方法もわからない。デプロイ方法もわからない。実績もないため、実際に作ってみてパフォーマンス上の問題が出る可能性もあります。

軽量なWebアプリケーションであれば、ピュアCommon Lispで書かれたHunchentootというアプリケーション・サーバーを使うことも有力な選択肢でした。しかし、Hunchentoot上に構築するアプリケーションはHunchentootに依存したものになってしまうため、当然ながらアプリケーションがHunchentootにロックインされてしまいます。もしHunchentootに問題があったときにmod_lisp *2 やFastCGIに移行したいとなっても手がありません。

今だから言いますが、新しいWebサービスを作りたいとなったときにこの状態でCommon Lispを使おうというのは正気ではありません。

Hunchentootは当時でも「速い」と評判でしたが、まともなベンチマークなどありませんし、最近取ったベンチマークではRubyのUnicornより遅いことがわかっています。各リクエストでスレッドを作るために、同時に捌けるリクエストは100までという制約もあり、大規模なWebサービス運用には不安が大きいです。

Clackで目指したもの

RubyやPerlに当たり前のようにあって、Common Lispに足りないものは明白でした。安定して開発されていてカスタマイズ性があり、それなりの速度で動いて、ドキュメントが豊富な、運用実績のあるWebフレームワークです。

ではそのために何をするべきか。僕はPlackをCommon Lispに移植することに決めました。

ただ作るのは簡単です。難しいのは、開発を続けることです。さまざまな人に使ってもらい、地道に改善を続けることです。

僕はこのプロダクトを、少なくとも5年は続くものにしたかった。安定して開発を続けるためにしたのは、主に4点です。

テストが完備されている
ドキュメントが豊富にある
GitHubでオープンに開発する
リリースを続ける

CL-TEST-MOREを使ってテストを書き、それをJenkinsで自動テストするようにしました。また、ドキュメントをすべての関数はもちろん、パッケージにも書きました。開発はGitHubでオープンに行いました。Issueでの議論を残し、新たなコントリビューターを得たときに改良の経緯がわかるようにするためです。そして、何かしらのリリースを毎月行いました。改善が続いているというのは安心感があるものです。

すべてが思い通りにいったわけではありません。Common Lispコミュニティに歓迎されたかと言えばそれほどでした。けれどそれもある程度予想していたことですし、当時の僕はいつか皆が振り向いてくれるだろうということを楽観的に信じていました。

Clackの思想

Clackが"異質"だったのは新しいというだけでなく、それがとても「思想的な」プロダクトだったことだと思います。

Clackをリリースしたときの僕のブログエントリはそれなりの反響がありました。

ここではHunchentootが密結合のアプリケーションを作ってしまうことを「そびえ立つクソ」だと形容しました。それに対してClackは疎結合を奨励します。裏側のWebサーバーに依存せず、Webフレームワークやアプリケーションコードも小さなコンポーネントの組み合わせによって構築します。

疎結合にすることはアプリケーションのテストを簡単にし、他人との協力した開発を容易にします。他のライブラリとの依存性も減らせるため、他のライブラリが朽ちたときに致命的な影響を受けません。結果的に開発の継続性が高まることが期待できます。

面白いと思ったのが、このエントリに肯定的なコメントをしているのはLisp プログラマではない人ばかりであることです。コミュニティの外にいる人がこの記事を読んで、Common LispでもWebアプリケーションを書けるのか、魅力的だな、と思ってもらえたのだと考えれば喜ばしいことですし、そういう人を取り込んでいくことはLispコミュニティにとっても重要なことでした。

もちろん、Clackがあるだけで大きくWeb開発の環境が改善したわけではありません。その点僕の当時の態度はただの虚勢ではありましたが、それでもいつか本当に楽園を作ってみせようという強い決意はありました。そして現在それはかなりの割合達せられていると感じています。

v2のリリースと、Lackへの分離

年月は過ぎて1年半前、Clackはv2.0.0をリリースしました。

このリリースではWebアプリケーションの構築部分 (ミドルウェアなど) をLackという新しいプロジェクトに分離し、Clackはバックエンドサーバーの抽象化ライブラリになりました。ただ分離しただけでなくLackはスクラッチから書き直し、Clack v1とは後方互換性はありません。主に高速化を意図して行い、結果としてさらに疎結合性が高まりました。