Satsuki-system技術情報 - adiary開発日誌

2006/07/08(土)Satsuki-system技術情報

Satsuki-systemの文法等はこちら参照

はてな技術者の naoyaさんのPerl技術記事見てたんですが

adiary関連の技術情報＝マニュアルも本格的にまとめ始めたほうかいいなぁーと思ったりしたりしました。数日中にもβ版公開しましすが、ソースみただけではわからないところが多々ありますし。

比較的短期間かつ少人数（一人か）でこれだけのシステムになったのかってのは訳があって、生産性を担保するシステム構成によるところがとても大きいのです。それを担保してくれる Satsuki-system（スケルトンシステム）がなかったらadiaryの開発は不可能でしたし、そもそも「自作のスケルトンシステムがあまりに便利かつ有用なので、これを有効活用する手だて」としてblog（adiary）を開発したという、なんとも本末転倒な話だったりします（笑）*1

Satsuki-systemとTemplate Toolkitの比較

スケルトンシステムというのは何度も申し上げているとおりで、Perlの変数埋め込みを一歩進めて簡単な命令を書けるようにしたものです。この考え方の有名な例として、~~Movable Typeにも使われている~~*2 Template Toolkitがあります。このTemplate Toolkitは変数置換の他、簡単な条件構文やループなどをHTMLテンプレート中に記述できます。

Template Toolkitでは読み込まれたHTMLファイルを、Perlで実行可能なプログラムとしてテンポラリに吐き出します。次以降は、そのコンパイルされたファイルを実行するわけです（mod_perlのときはキャッシュされるのかな？）。Satsuki-systemも紆余曲折の上、現在はその形に落ち着いています。

でも、Satsuki-systemとTemplate Toolkitは決定的に違うところがあります。Template Toolkitのキャッシュはperlプログラムとして実行することでそのまま出力HTMLが得られますが、Satsuki-systemのそれは、そのまま実行することは不可能なプログラムになっています。Satsuki-system本体とコンパイル済のプログラムの２つが合わさって初めて意味を持つわけです。

なんだ「使いにくいだけじゃないか……」と言われるかもしれませんが、実はそこが最大のミソなのです。Satsuki-systemはスケルトンシステムでありフレームワークでもあります。スケルトンシステムから参照する必要なルーチン（ライブラリ）は、システム本体に納められており、そのライブラリ部分を自由に拡張できることこそが最大の特徴です。

以下はスケルトンのコメント表示部分を抜き出したものです。

<p><span class="canchor"><a href="<@t.this_diary_url>#c<@t2.pkey>#">#</a></span>
<span class="commentator"><span<@if(t2.id, " title=<@t2.id>")>><@t2.name></span></span>
『<@t2.text_short>』　<span class="comment-date">(<@tm_printf('%Y/%m/%d %J:%M', t2.tm)>)</span></p>

強調表示のところが埋め込みです。大半はただの変数置換だと思って問題ありません。一番最後の、tm_printf が関数呼び出しとなっていて、この実体はSatsuki-system本体（Base.pm）に含まれます。この関数に相当するものを増やしていくことで、システム全体を構築します。*3

つまり、Template Toolkitキットでは「Perlプログラムの付属品としてのHTMLテンプレート」であったわけですが、Satsuki-systemでは「スケルトン(HTML)の付属品がPerlプログラム」なのです。

Satsuki-systemとPHPの比較

そこまで、スケルトン万歳ならはじめからPHPみたいな埋め込み言語を使えばいいじゃないかという話になります。PHPは使ったことはないのですが、一つそして決定的にPHPを使いたくない理由があります。プログラムとHTMLのソースが一緒になっててメンテしずらい。きちんと書かれた（？）PHPのソースならばそうはならないのかもしれませんが、１画面＝１HTML＝１プログラム主義のように感じます。

というわけで、もちろんSatsuki-systemだって同じだろうというツッコミもあります。adiaryの日記一覧のような部分は、実際にHTML内にPHPのようにプログラム的動作を記述してページ送りなどを実装していますから、同じといえば同じです。ですが、それは推奨される形ではなく、ほとんどの場合１ページに対して１つのPerlのサブルーチンが付属しています。

RoRのモデル・ビュー・コントローラー的な考えからいえば、Viewがスケルトンで、ControllerがPerlのコードということになります。PHPとの大きな違いはここですが、PHPのプログラム部を外部ファイルとして追い出したとしたら（本体には呼び出しのみ残る）、似たようなものだと思います。

Satsuki-systemと Ruby on Railsの比較

比較も何も……似たもの同士です*4。これは別にRoR的思想を取り込んだわけではなくて、Satsuki-systemの「変数埋め込みHTMLの拡張」を突き進めた結果、似たようなものにたどり着いたというわけです*5。もっとも、最初の思想からMVCなRoRとはスタート地点で負けているわけですが、そこを敢えて比較すると

Satsuki-systemはPerl用である。開発時点でRubyよりPerlの方が処理が速かったのがPerlになった理由ですが、Ruby 2.0 YARVが登場すると立場逆転しそうです（汗
RoRの方が思想的にOO（オブジェクト指向）として綺麗である。そもそもPerlのOOはやっつけなので、これもスタート地点で負けてます。

となります。勝ち目ないですけど（汗）　後ろ向きなアドバンテージは、

今この時点においては、Perlの方が速く動作する。*6
Perlの方が普及してるし、ユーザーも多い*7
必ずしも「データ（データベース）」対応でなくてもよい分、Satsuki-systemの方が汎用的かもしれない。
昔ながらのきついルールーより実用主義的なプログラマには…ry(^^;;

まとめると

んー……Perl版フレームワークのないRoRの出来損ない？（ぉぃぉぃ*8

もっとも、

可能な限り高速に動作するよう設計されている*9
mod_perl (prefork/worker)でもcgiでもSatuki-systemが差を吸収してくれる（ただし若干気を遣って書く必要はあり）

ですけども。早くマニュアル整備しろってことですね（汗）*10