2011-01-21

【重要発表】シックス・アパートは2月1日に、新しい体制に生まれ変わります！
http://www.sixapart.jp/news/2011/01/21-1700.html

早い話が身売りである。WordPressなどの競合を排して独自に日本市場を切り開く体力も技術的優位もないのがはっきりしたということだろう。
日本におけるSixapartと僕らの愛すべきMovableTypeの命運が絶たれたことを記念して少しばかり回想をしよう。

00年代の前半。MovableType2.2が「ブログ」という聞き慣れない言葉とともに日本にそれとなく入ってきたとき、当時駆け出しだった私はもちろん、日本のWeb業界でMovableTypeに度肝を抜かれなかったものはいなかったと思う。

垢抜けたインターフェース
洗練されたCSSベースのデザインテーマ
トラックバック、RSSといった後にWeb2.0と称される斬新な機能性
htmlページ生成という、技術的困難なテーマに果敢に挑戦する野心
ブログというCMSの一断面を切り裂いたような明快なアーキテクチャ

そして何よりも、ソースをダウンロードした私がぶったまげたのがその「美しさ」だった。コードはきちんとインデントされてモジュール化されており、$ATESAKIのようなグローバル変数はおろかmt.cgiにほとんどコードすらないのだ。

訝しる読者のために私はここで当時のWeb業界と私の状況を正直に告白しなければならない。

その頃、皆さんの大好きなrailsはなかった。ついでに言うとrubyもpythonもなかった（正確にはあったがWeb屋が使うものではなかった）
MVC フレームワークは辛うじてあったが、先進的なjava プログラマとWebObjectユーザーのものだった。
MySQLはトランザクションすらサポートしておらず、それが「フリーのRDBMS」としてもてはやされていたが、商用のレンタルサーバーのほとんどはMySQLなどサポートしていなかったので、どちらにせよ使えなかった。
Ajaxは「DHTML」という名前でIEの最新バージョン(IE5.5）でしか動かない、文字を太字にしたり画像にエフェクトをかけるような単なるギミックの扱いであった（というよりGoogleが「再発見」するまでそれで何ができるのか誰も知らなかった）
人々はKentWebを見てCGIの勉強をして、排他制御を理解していないプログラマが書いたアクセスカウンターが壊れた、といっては大騒ぎしていた。

そんな時代だったから、大学を中退した私が入った零細Web屋でも、その技術レベルはひどいものだった、私はそこでWebシステム、いや言い直そう、「CGI」だ。それもどっかで配られている掲示板のようなファイルベースのCGIを、リリースされたばかりのPerl5とjcode.plで書いて「CMS」としてリリースする。そんな日々を送っていた。

私は、はるか天上に位置するJ2EEとOracleで作られた大規模Webシステムに憧れ、顧客が専用サーバはおろかOracleのライセンス料すら払う気がないことを知って絶望した。そしておそらく自分が、一生うだつのあがらないKentを師匠と仰ぐような素人どもと一緒にされ続けるのだ、と思って日々涙していた。

そんなところにMovableTypeはやってきたのだ。もしこれが大規模な商用パッケージだったなら私は見向きもしなかっただろう。

そうMovableTypeは「CGI」だったのだ！

CGIなど、昨今の読者諸氏は触れることすらないのだから少し補足しておこう。CGIとは、単純にいえばHTTPのアクセスがあった時に起動される単なるスクリプトだ。つまり、誰かがCGIのURLにアクセスする、するとWebサーバーは内部でPerlやshなどのプログラムを「起動」する。そしてそのスクリプトを実行し、データベースに毎回つなぎなおし、標準出力をユーザーにリダイレクトして流しこむ。NCSA httpdを作った人間が、ついでにつけたような機能。それがCGIである。

これの何が問題か？一言でいえば「遅い」のである。クソのように「遅い」のだ。
PHPやmixiやはてなで使われているmod_perlはWebサーバーの一部として実行される。アクセスする度にインタプリタ本体を起動するようなバカな真似はしないし、データベースのコネクションも貼ったままだ。だから1秒もしないうちにページは表示される。これがCGIなら

インタプリターの起動
モジュールの読み込み
データベースへの接続
書かれたコードの実行

の４ステップが厳かに行われ、ユーザーが諦めてポルノサイトのブックマークをクリックした頃に出力結果が返されるというわけだ。

この状況下にあって、我々零細Web屋は涙ぐましい努力をしていた。RDBMSを使わずにISAM風のファイルフォーマットを作ってカリカリとブロック単位でデータを書き込んでみたり、モジュールが遅いのだ、と言ってモジュールを分割して動的に読み込んでみたり、そもそも全くモジュールを使わずに巨大なCGIファイルを作ったり、中にはスクリプトの改行や空白を全て削除するような奴までいた（そしてこれらの行為にはほとんど意味がなかった）。

そこまでしていたWeb屋がMovableTypeのソースを読むと、その理路整然としたモジュール分割とアーキテクチャの美しさに感心するとともにこう思うのだ「でもこれ、遅いんじゃねーか？」と。

しかし実行してみると、それは感動に変化する。「速い」のである。いや今でいう「速い」とはまた単位が違うのだが、そのへんの高校生が書いた掲示板スクリプトなみには、ちゃんと速かったのだ。

私は感動するとともに、ソースを隅から隅まで見た。するとそこには表面の美しい構造化思想とは対極の、狂人じみたリアリズムが溢れかえっていた。

例えば、これはMT2.5のXMLRPC部分のソースだ

    my $text = <<XML;
<?xml version="1.0"?>
<methodCall>
    <methodName>$method</methodName>
    <params>
    <param><value>$blog_name</value></param>
    <param><value>$blog_url</value></param>
XML
    if ($mt_key) {
        $text .= "    <param><value>$mt_key</value></param>\n";
    }
    $text .= <<XML;
    </params>
</methodCall>
XML

XML文書をそのままprintしてしまうというのは、当時ですらバカの発想だった。もちろん、MTの開発者であるベン・トロットが「まともな」処理方法を知らなかった筈はない。DOM、せめてエスケープ済みの変数をテンプレートで、と言う部分をベンは「printが一番速いんだよ。クソどもは黙ってろ」とばかりやってのけてしまったのである。そしてその覚悟こそが、CGIという足枷をはめられた零細Web屋のとるべき態度なのだ。

私は目を覚ました。

しがないCGI書きでも、天上世界のアーキテクトたちに恥ずかしくないプログラムで、顧客が満足できるような「システム」を作ることができるのだ、とMovableTypeのソースは誰よりも雄弁に語ってくれたからである。

MT3〜5の、どっかのアーキテクチャバカが入社してから何故かどんどん重くなって、WordPressにフルボッコにされるあたりの流れをこそ書きたいと思ったのだが、時間がないので、ここまで。

現在SAYメディアの社員である宮川達彦は1月31日付でシックス・アパート執行役員（非常勤/米国勤務）を退任する予定です。

※引用に他意はありません

megamouthの葬列

長い旅路の終わり

ソースでわかるSixapart転落の歴史