adiary開発日誌

• コメントの新着判別が特定条件下で誤っていたので修正しました。
• 記事keyや日付で記事を指定する[key:xxx]タグ[day:xxx]タグを作成しました。→詳細情報

今後カラム変更しないことを見据えて、カラム変更に関わりそうな改変を先行しました。β1を使用しているユーザーはまだいないと思いますが、「一度記事をエクスポートして日記を削除後インポートする」か、データベースの変更方法をお教えしますので、使用データベースの種類と共にお知らせください。

本レンタルサービス固有

• アルバムのフォーム処理関連を最新ソースに更新しました。（→詳細）
• アップロード画面にアップロード最大サイズを表示するようにしました。*1

コメントSPAMがやってきた

レンタルサービスを開始して３ヶ月ぐらい（？）ですか。やっと、SPAMがやってきてくれました（拍手）*2。何をそんなに喜んでいるのかという話になりますが、この手の対策は実際に来ないと分析しにくいのです。もちろん、ネット上で有効な対策として、

• 日本語を含まないものを弾く
• 禁止キーワード/URL

などなどがありますが、あれこれと無闇に対策をとるよりも、有効かつシンプルな手だてに絞って実装したいと考えています。そのためには詳細な手口（ログ）が必要で、こればっかりは実際にSPAMロボットにやってきてもらうしかない。

というわけで、トラックバックSPAMも早く来ないかな（笑）

key記法、day記法

記事keyおよび日付指定を指定する機能を付けました。例えばこの記事のURLは

(a)http://adiary.blog.abk.nu/060

(b)http://adiary.blog.abk.nu/xxx

ですが、このとき記事keyは 60 番になります（トラックバックURLでも分かります）。以下は例。

-(a)へのリンクは[key:060]や、ほかのタグと同様に[key:60:この記事へ]とも書けます。
-(b)へのリンクは[key:xxx]や[key:xxx:この記事へ]と書けます。
-他人の日記の場合は [id:kaede] や [id:kaede:158] とします。
-日付指定は [day:7:７日の記事] や [day:7/7]、そのほか[day:2006/6]とも書けます。
-その日を指定したい場合は単純に [day:] や [day:今日の日記] で行けます。
-他人の日記は、[day:kaede] [day:kaede:7/7] という風に書けます。
-アンカー指定は [day:kaede:0142:#p1] や [key:15:#p2] という風に書きます。
-当日の日記は [key:#p1] や [this:#p1] で指定できます（β７以降で対応）。

• (a)へのリンクは記事key指定機能、日付指定機能や、ほかのタグと同様にこの記事へとも書けます。
• (b)へのリンクはxxxやこの記事へと書けます。
• 他人の日記の場合は kaede や kaede:158 とします。
• 日付指定は [date:(format error)] や [date:(format error)]、そのほか[date:(format error)]とも書けます。
• その日を指定したい場合は単純に [date:(format error)] や [date:(format error)] で行けます。
• 他人の日記は、[date:(format error)] [date:(format error)] という風に書けます。
• アンカー指定は [date:(format error)] や 日記記法の説明 という風に書きます。
• 当日の日記は #p1 や #p1 で指定できます（β７以降で対応）。

追記。コメントで指摘された件、修正しました。

パーサーの単独配布？

adiaryのパーサー（入力記法システム）はかなり強烈かつ便利なわけですが*1、これをadiaryのためだけに使うには勿体ない。やってる内容的に、ちょっと書き換えれば standalone で動くモジュールになります（つまりSatsuki-systemなしで単独で使用可能になる。*2）。

はてな互換記法もそこそこ乱立してる上に、結構需要があるみたいなので。完全互換ではありませんが、非互換部を差し引いても余りある機能追加がありますので、要望があればテキストパーサー単独でLGPLライセンスぐらい緩い使用条件で配布してもいいかなとは思っています。

ただ記法の乱立（混乱）抑制が目的なので、実装済記法（機能）のいくつかをプロテクト（改変禁止）するかもだけど。

追記

本家のはてな記法がCPANにあるらしいよ（なんでだれも使わないんだろう……*3

余談。

例えば「id:jkondo」と書いた時にどこにリンクすればいいんだ、

adiaryでは id:xxxxx は、はてなインポーターで[hatena:id:xxxxx]に変換され、それを書くと最終的にはxxxxx となります。[id:xxxxx]は今のところ未定義です...

開発途上版、adiary Version 1.00β1を一般公開します。最新snapshotからの変更点は以下の通りです。

• 定義済リストが使用できないバグを修正しました。
• 時刻付き見出し記法が使えないバグを修正しました（＋追加修正）。
• 日記の書き込み日時を「初公開時」となるようにしました。

βリリース情報

• 基本的な機能としては十分使える程度に安定しています。
• デザインの細かい変更などが、web上から行えません。
• 一部仕様が決まっていない部分があります。
• ドキュメントが全く整備されていません（汗

今後の改変予定など、細かい部分はToDoを参照ください。β版についての質問、疑問、バグレポートなどはこの記事へどうぞ。

• 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