β5は不具合修正がメインです。今回も adiary.conf.cgi は、変更なしで引き継げます。
余談。だからどうしたという話ですが adiary は aDiary*3 とは全く関係ありません(^^;;
「やっぱり普及するには、見た目（デザイン）は大切ですよ」
と言われたこともありまして、Serene Bachをいじってます。もちろんインポート／エクスポートで対応しているぐらいだから一度インストールしてるんですが。Amazonのオススメがスクリプト上から選べるのは楽でいいなぁ……とか思いながら、いざのテンプレート機能。ブラウザからアップロードできるのは楽でいいです。
Serene Bach/JUGEM系のテンプレートは、（ある意味でかたい感じのする）はてなのテーマに比べて愉快で楽しそうな感じのテンプレートが結構ありまして*1、使えるようにできたらいいなあと検討しています。
adiaryでテンプレートに相当するスケルトンは本当に何でもできるので*2、十二分にカバー可能なのですが、その一方で「なんでも出来すぎて普通に人にはいじりにくい」から「スケルトン（テンプレート）を生成するためのテンプレート機能が必要ではないか？」なんてお話を頂いたりしてました*3。たしかにそうかもしれない。
規格乱立はリソースの無駄遣いに他ならないので、その場合はやっぱりSerene Bach/JUGEM系互換を狙うのかなあとか考えております*4。すぐに対応というわけにはいきませんけど、検討は重ねておきます。意見とかありましたらどうぞ↓
SPAM対策ですが、JavaScriptということで落ち着きました。一応チェックはしていますが、不具合などありましたら遠慮無くご連絡ください。これを突破するspammer（ロボット）が現れたらまた何か考えましょう。
追記。今回から対応したFastCGIですが、念入りに確認してみるとイマイチ動作不安があるので、β４でのFastCGIの導入はお勧めしましせん。さらに追記。問題なく安定して動作するようになりました。β５以降をお待ちください。
要するに人間に認識しやすく、ロボットに認識しにくい方式を考えればよいのですが、JavaScriptや質問文その他の方策をいくら取ったところで、adiary向けの専用対策を取られたら太刀打ちは無理（イタチごっこ）になります。ですから逆に開き直って、とりあえずは JavaScript＋JavaScriptがない環境では簡単なキーワード入力を促すという方式にしました。
あまりテストしていないので誤動作する or 特定ブラウザでうまくコメントを書き込めない*1ようならご連絡ください。
http記法のimageで遊んでみる。
おまけにTeX記法を使ってみる。
この記事はVer2以前のものです。Ver3は無関係です。
skeltonを直接カスタマイズしたいという要望があるようなので、カスタマイズの仕方を説明します。スケルトンカスタマイズにはプログラム的知識が多少必要になります。
※2007/01/24 大幅に加筆しました。バージョンアップ時の手間を考えた場合、_main, _sidebarスケルトンの変更はあまりお勧めしません。「詳細デザイン」＋トラストモードで済む場合はそちらを検討してください。
adiaryの機能はほぼすべてこの中に納められています。adiaryのスクリプトに対する引数
adiary.cgi?diary_edit
であれば、diary.skel/diary_edit.html が呼ばれます。カスタマイズしたい機能をみつけたい場合は、その画面のURLに着目すればよいことになります。なおセキュリティ上の制約で、"_" ではじまるスケルトンおよびサブディレクトリにあるスケルトンは引数では直接呼べません。
なお、スケルトンをカスタマイズする際は、diary.skel のを書き換えるのではなく、diary.user.skel にコピーしてから書き換えるようにしてください。こうすれば diary.skel より優先して読み込まれます。
ですが同時に、バージョンアップをしても常にユーザースケルトンが優先されてしまうので、オリジナルが大幅に書き変わっている場合など多少注意が必要です。後述する特殊スケルトンのうち _main, _main_onelog, _sidebarスケルトンは比較的よく改変されます*1。この３つについては、変更点をバージョンアップアナウンス時にアナウンスしていますのでご注意ください。
diary.user.skel などにおいたユーザースケルトンでは
<$continue()>
という関数（コマンド）を使うことで、本来の diary.skel 内の該当スケルトンに処理を引き継ぐことができます。theme/hatena/_skelton/_frame.htmlなどで使用しています。
まず重要なのが外側のフレームを生成するスケルトンです。通常、adiaryの画面は、該当スケルトンを処理し、その結果を埋め込む形でフレームスケルトン（_frame.html）が呼ばれます。サイドバーは、フレームスケルトン内から呼ばれています。
その他特殊なスケルトンは以下の４つです。
| _main | 日記本文を生成するスケルントンです。 |
|---|---|
| _main_onelog | 日記本文生成ですが、記事ID指定時の表示に使われます。 |
| _sidebar | サイドバーを生成するスケルトンです。 |
| _multiuser_top | マルチユーザーモード時のトップ画面です。 |
このblogレンタルサービスでは、_multiuser_top.html をカスタマイズして diary.user.skel/ に置いてあります。
スケルトンをテーマディレクトリに置くことで「表示画面テンプレート」を作ることができます。例えば、携帯電話用テンプレート（HTMLの元）はtheme/_phone/_skelton/ に置かれています。
デザインテンプレートを作成する際は、theme/ 以下に任意のディレクトリを作成してください。この場合、テンプレート名と同名のテーマ（CSS）が必要になります。中身が空っぽでもいいので必ず置いてください。
theme/my_design/ ならば theme/my_design/_skelton/ に任意のスケルトンを置き theme/my_design/my_design/my_design.css というテーマファイルが必要
（選択中の）テーマディレクトリのスケルトンはユーザースケルトンよりも優先されます（しかしシステムモードではテンプレート（テーマディレクトリスケルトン）は無視されます）。
adiary は Satsuki system という独自のスケルトンシステムにより作成されています。膨大な機能があるシステムですが、文法を簡単に説明しておきます。プログラム経験のある人ならさほど悩まないとは思いますが。
<@> コメント
<@> で始まる行はコメントです。現在の仕様では、行の途中に <@> を書いてもコメントとして扱われますが、今後の仕様変更の可能性がある部分ですので、必ず行頭に書いてください。
<$xxxx> <@xxxx>
これらは「式」として評価されます。コマンドと言ったりもします。<$～>は実行されますが何も出力されません。<@～>は実行後の結果が出力されます。<@～> は次のような変数置換の形で最もよく使われます。
<li><a href="<@v.this_archive_dir><@v.rss_file>">RSS</a> <li><a href="<@v.myself>?diary_list">過去日記の一覧</a> <li><a href="<@Myself2><@v.path_info>?theme/_print/_print">印刷用の表示</a>
<#$xxxx> <#@xxxx>
このように、コマンド内の先頭に # をつけることで、該当コマンドをコメントアウトできます。コメントアウトしても構文内の ( ) 対応や " "対応はチェックされます。
<@20> 最適化on
コンパイル最適化を指示します。基本的に書き換えないでください。
Satsuki-systemでは、変数の名前空間をピリオドで区切ります。変数名は大文字小文字で区別されます。
<@Myself> <@v.rss_file>
前者は、ルートの中の Myself という変数を、後者は v の中の rss_file というものを示します。
Satsuki-systemでは、小文字で始まる変数名（名前空間）はユーザーに解放されていますが、設計時からの慣習で利用時のメインシステム（この場合adiary）を変数 v の中に入れることになっています。adiary のスケルトンではこのほか、変数 s に各ユーザーの日記帳情報（日記帳の設定情報など）を入れる約束になっています。
このことから、vとs以外の小文字で始まる変数はカスタマイズ時に自由に使うことができます*2。
これについては、せりかさんの解析記事を参考にしてください。
この項目は Perl のオブジェクト指向に理解のある方以外は読まないでください（混乱するだけです）。
Perl では、無名のハッシュリファレンスにライブラリ名（ライブラリ名前空間）を結びつけることでオブジェクト指向を実現しています。Satsuki-system の名前空間というのは、adiary.cgi*3 で生成される Satsuki::Base のオブジェクト $ROBJ の中身そのものです。そしてよく見かける loadpm の実体は new そのものです（ライブラリをロードしてオブジェクトを new して返す）。
Satsuki-system名前空間と実体の対応関係は、次のようになっています。
| Satsuki-system | 実体 |
|---|---|
| <@Myself> | $ROBJ->{Myself} |
| <@v.rss_file> | $ROBJ->{v}->{rss_file} |
| <@call("sub/sub")> | $ROBJ->call("sub/sub"); |
| <$v=loadpm("XXX")> | $ROBJ->{v} = $ROBJ->loadpm("XXX"); |
PerlのTemplateライブラリなどではスケルトンに対しハッシュをバインドできるようですが、Satsuki-system では、システム全体をスケルトンシステムの中に配置しています。Satsuki-system の驚異的な柔軟性と開発効率の要はここにあります。*4
| Templateライブラリ | システム ->テンプレート |
|---|---|
| Satsuki-system | スケルトン ->システム |
実際、adiary.conf.cgi というスタートアップスケルトンを用意しなければ、Satsuki-system はまったく動きませんし、逆にスタートアップスケルトンだけでもある程度のCGIスクリプトを記述するも可能です。
ちなみに adiary.conf.cgi に <$Compile_log_dir="data/log/"> を定義すると、スケルトンが perl スクリプトへコンパイルされる様子をログとして見ることができます（遅くなるので通常はオフにしておきましょう）。
FastCGI対応は書き間違えだったのですが、どうせならということで対応してみました（対応版の配布はβ４以降になります）。
気づいたらあれこれ対応しすぎた感じがありますが、せっかくなのでどれが一番速いのか試してみしまた（笑） いずれの設定も全くチューニングも何もしていませんので、参考程度にお願いします。
CPU : Pentium3 800MHz (133*6/Coppermine) OS : FreeBSD 6.1-PRERELEASE Web : Apache 2.2 (prefork) ETC : DBキャッシュON TEST : ab -n100 -c4 http://127.0.0.1/xxx/adiary.cgi/user/
テストしたページには適当な日記が数件表示されています。結果は数回実行して頻出値に近い値を取りました。
| 動作モード | Req/sec | ms/Req |
|---|---|---|
| cgi | 2.10 | 477.270 |
| speedycgi | 15.19 | 65.825 |
| mod_speedycgi | 26.41 | 37.863 |
| mod_fastcgi | 21.28 | 46.990 |
| mod_fcgid | 21.21 | 47.157 |
| mod_perl2*1 | 26.69 | 37.473 |
| text-file | 196.7 | 5.084 |
mod_fastcgiとmod_fcgidは差がなくて、mod_perl/mod_speedycgiが一歩前に出てるという感じですね。worker動作（スレッドモデル）となると、対応しているのは mod_perl2 vs mod_fcgid だけ。mod_perl2 はいかんせん導入が面倒くさいので、手軽さでは mod_fcgid の方がよいのかもしれません。
本格的にパフォーマンスを求めたり、高負荷時のメモリ消費量の少なさを考えると mod_perl2 on worker MPM に優る選択肢はないのですが個人では必要ないでしょう。*2
ただ、どれも Apache にモジュールを組み込まないとならないので、お手軽に高速化したい場合はSpeedyCGI（ソースコード）をオススメします。パフォーマンスも（個人で使うには）十分ですし、Apacheからは完全にcgiとして見えるので（プロセスが完全に分離するので）、精神的にもよいです。
誰か同じことをMTの管理画面で試さないかなぁ（笑）
せっかくなので、簡単に仕組みと特徴を説明。
通常のcgi動作。Apacheが、該当のcgiプログラムを fork し実行します。Perl/cgiでは、cgiファイル（使用ライブラリファイル群）のコンパイル時間がとても長く、度々問題となります。*3以下の方式は、どれもこのコンパイル時間を減らすことで大きな高速化を果たしています。
Apacheからみたら通常のcgiプログラムですが、スクリプト１行目にPerlではなくSpeedyCGIを起動するための
#!/usr/bin/speedy
を記述することでSpeedyCGIが動作します*4。SpeedyCGIは内部的にPerlを呼び出し、実行終了後もそのプロセスを常駐させ（バックエンドと言う）、続いてリクエストが来たときに空いたバックエンドがあればそれに処理を行わせます。
スクリプト側から見た場合、Apacheプロセスと分離されることを除けば*5、全体的な動作はほとんどmod_perlと同じです。
歴史が浅いのか何なのかいまいちマイナーだけど、導入も容易で、mod_perlでは動作しないスクリプトも動作し、Apacheとは別プロセスになるので使うのも気楽です。SpeedyCGIをインストールしてあるレンタルサーバもみかけます。
mod_speedycgiはSpeedyCGIの管理プログラム起動コストを押さえるためApacheにモジュールとして組み込んだものです。それによりかなり高速化されますが、worker MPMには非対応なので注意が必要です。
SpeedyCGI的な考え方をより推し進めて、Apache内部にバックエンドプロセスを管理する機能をモジュールとしてインストールしたものです。SpeedyCGIでは、いくらバックエンドがあるとはいえ結局は別プロセスである SpeedyCGI（/usr/bin/speedyそのもの）を fork して実行する必要がありましたが、FastCGIではバックエンドを直接操作するため fork のオーバーヘッドがありません。
mod_fastcgi(FastCGI)とmod_fcgidの差ですが、前者をスレッド動作のApacheに組み込むのはあまりよろしくないとのことです。また巷の噂によると後者の方が速いとかなんとか。なお、FastCGIをスレッド動作のApacheに組み込んだとしても、CGIプログラム（Perlなど）自体は１プロセス＝１クライアントとなります。
cgiスクリプトはFastCGI向けに改造する必要があります。
use FCGI;
my $count = 0;
my $request = FCGI::Request();
while($request->Accept() >= 0) {
print("Content-type: text/html\r\n\r\n", ++$count);
}
バックエンドどころか、「Perl自体をApacheに抱え込んでしまえばいい」という荒技的な解決策を提示するのが、mod_perl。荒技なだけに、もっともオーバーヘッドが少ない*6方式です。mod_perlの特徴として、Apacheの内部動作をスクリプト側から事細かに制御できますが、移植性（配布性）を考えたソフトではあまり使うことはありません*7。
mod_perlには、Apache 1.x系向けのいわゆるmod_perl（以下mod_perl1と表記）と、Apache 2.0/2.2系向けのmod_perl2があり全く互換性がありません*8。この互換性が度々問題となって、mod_perl1向け書かれたcgiをmod_perl2で動かそうとすると誤動作して厄介な問題を引き起こします。その代表選手とも言えるものがMovable Type*9。
スクリプト側から見た場合、mod_perl1やスレッド動作でないApache2ならば、およそSpeedyCGIと同じような感じです。ただ、Apache2が真価を発揮する worker（スレッド）動作でのmod_perl2は、Perlスクリプト自体もスレッド動作することで高い効率が得られる一方、カレントディレクトリを指定出来ない（chdir()できない）こと*10、あらゆるスクリプトがマルチスレッドでライブラリ空間（メモリ空間）を共有すること*11が大きなネックになります。後からこの対応を行うことは困難であり、これがmod_perl2向けスクリプトがほとんど存在しない原因になっていると思われます。
Apache2(Prefock) + mod_perl2 のときは、次のようにすると自動で chdir されます（いずれか１つ選択）。
PerlResponseHandler ModPerl::RegistryPrefork PerlResponseHandler ModPerl::PerlRunPrefork