まだ重たいCMSをお使いですか?
毎秒1000リクエスト を捌く超高速CMS「adiary

2006/04/25(火)adiaryの開発

adiaryの開発ですが一段落してしまいました。困った(苦笑) いやまだ必要な機能(ToDo)はありますけど。

  • RSSの出力と更新通知 Ping
  • 画像アップロードへの対応*1
  • モバイル対応(モバイル更新とモバイル用skelton)
  • TypePad (Movable Type)形式、はてな形式、tDiary形式のデータインポート
  • データエクスポート(とりあえずTypePadと、……はてなかな)

これ以外の部分=基本的な機能は全部できてまして。開発者向け(プラグイン作者・改造者)に説明しておかなければならない、内部仕様がとんでもなくありましてドキュメントの整備を始めようかなぁと。

はじめは perlpod を使おうと思ったのですが、イマイチ機能不足な気がして*2、この構文解析を使って書けばいいかなぁ……とか悩み始めたのが運の尽き。ドキュメント整理用のシステムとかあったらいいよなぁ……とか。どんどん違う方向に(笑)*3 ほんとはシステム丸ごとCPANに起きたいところですが、blogシステム自体には日本でしか(?)意味のない文字コード機能がとても強化してあったり、基本システムには日本語コメントが沢山。とりあえず諦めよう(^^;;

ただ language ファイルシステム(メッセージをファイルに収めて他言語対応するシステム)は公開前に作っておいた方がいいのかなぁ~とか、本筋と関係ないところで悩み満載

*1 : 半分完成。某アルバム待ち

*2 : 日本語のセクションタイトルつけるとアンカーが変になったりとか

*3 : まあ元々このシステム自体、必要は発明の母的な発想で出来てるので間違ってないんですけど(苦笑)

2006/04/19(水)高機能化

プログラムというのは基礎工事さえしっかりしてれば、高機能化は比較的容易です。というわけではてな記法に似た簡略記法が使えるようになって、Amazonアソシエイトも自動挿入など無駄に高機能かつ使いやすくなっています。が、……このblogプログラム、はたして普及するんでしょうか?(^^;

たぶん普及するとしたら、ある時点でどこかで紹介されてその後が指数的になると思われるのですが……。んー読めないなぁ。tDiaryとかMovable Typeとかからのデータインポーター作ればいいのかもしれないけど、それこそ誰かサードパーティー(?)ツールとして任せたいのココロ。

そのためには、こちらのシステムの仕様書をきちんとつくらないとですか(苦笑)

2006/04/18(火)はてな記法の実装

はてなテーマを使用して*1、はてな記法まで実装したら、はてな盗作疑惑ですか(笑) まあどちらも完全互換ではないし、そもそもプログラムはフルスクラッチですから。*2

テキストパーサーの実装は結構頭を使いました。perlの正規表現を使ってこれだけ悩むのだから、Cで構文解析とかやりたくないですね(苦笑) こうやって実際に使い始めるとまともなテキストパーサーはほぼ必須でした。というか、ないと使い物にならなかったです、はい(汗)

テキストパーサーはプラグイン式でいくらでも拡張可能にしてありますので、みなさんお好みのパーサーをご用意くださいませ。TeXライクパーサーとかあったらそれもいいかなと思ったり思わなかったり。

*1 : はてなのCSSはほとんどがGPLなので、それを有効活用しただけなんですけど

*2 : はてなにしてもtDiaryテーマ+wiki的記法がベースにあるので、オープンソース的な循環みたいなもんかと。そのうちadiaryベースの何かがでるかもですね

2006/04/14(金)開発のつぶやき

一応使える状態になったので、サイトの日記をこちらに転記したいところ。自動化スクリプトでも書いた方がいいかもしれませんけどね(苦笑)

mixiの方には書きましたけど、元もとblogシステムのベースとなっているcgi用HTMLスケルトンシステム(Satsukiシステムと命名)が非常によく出来ている(自画自賛)ので、それを示すために作ったblogシステムと本末転倒気味ですけど(笑) 目標としてはRubyで動くtDiaryに対する、Perlで動くadiaryぐらいの位置づけになれればいいなーと思っております。Perlといえば、MovableTypeがありますが、あれはmod_perl2非対応なので(そしてDB必須だし、アホみたいに重たいし…)。

Perlは起動が遅いといいますか、インタプリタのPerlスクリプトをコンパイルしている時間が、起動時間の大半(本システムで約80%)を占めます。mod_perlやSpeedyCGIを使えば起動は早くできるのですが、レンタルサーバではそれは無理。データベース(BerkeleyDB含む)必須もレンタルには辛い。

使用するモジュールを徹底的に絞って、不必要なモジュールを直前までロードしないようにし、cgiとしての動作の高速化にはかなり気を使っています。環境非依存も、自前のテキスト型擬似データベース(GROUP BY が発行できちゃう(笑))を作成しました(テキスト型なので万が一の事態にも比較的安心です)。速度の方は、現状データ数がさほど多くないと、本格的なデータベースシステムよりよっぽど高速に動作してます(まだ逆転したことはないです)。個人で(シングルユーザーモード)で使う分にはまったく問題ないと思います。

2006/04/14(金)トラックバック - adiary拡張仕様(日本向け)

トラックバックの技術仕様 Version1.1に対する拡張です。

予備規定

  • 文字コードの表示。日本語の文字コードは「EUC-JP」「UTF-8」「Shift_JIS」「iso-2022-jp」のいずれかの文字列を指定すること。

トラックバックフォーム(POSTデータ)の拡張

  • トラックバックを受信する場合、未知のパラメータ(key)に対するデータは無視すること(規定外のフォームデータを送信してもよい)。
  • charset パラメーター。トラックバックの文字コードを示す。トラックバックが日本語文字を含む場合、必ず含まなければならない
  • x_author パラメーター。その記事を書いた人の名前を x_author として送信することができる(optional)。

トラックバック送信時のヘッダ拡張

  • トラックバックを送信時、クライアントはHTTPの定める「User-Agent」ヘッダを送信し、このときblogシステム(など)を名乗ることができる(optional)。

トラックバックURLへのGETの規定

  • トラックバックURLをGETした場合、サーバソフトは Content-Type ヘッダに、charset を付加し内部文字コードを示さなければならない。ここで示す内部文字コードでトラックバックを送信した場合、文字化けしないことを保証しなければならない

例)Contenet-Type: text/xml; charset=EUC-JP

  • トラックバックURLをGETした場合、サーバソフトは拡張ヘッダ「X-TB-Accept-Charset」を出力し、トラックバックとして受信可能な文字コードをカンマ区切りで示すことができる(optional)。

例)X-TB-Accept-Charset: EUC-JP, UTF-8, Shift_JIS, iso-2022-jp, iso-8859-1

updates

  • 2006/04/14 初版
  • 2006/07/24 author を author_name に変更(WordPressでの問題に対応)
  • 2006/08/01 WordPressへの対応のため、author_name を x_author に変更(fix)*1

*1 : Wordpress が author も author_name も特殊処理をした挙げ句、Queryを消去してくれるお茶目さんなので。おそらくセキュリティがらみだと思いますが……