Ellinikonblue.net Devlosxom

　やっとフレーバーの見直しが何とか終わりました。 構造変更は一から考え直さないといけないことが判明して断念しました orz が、 訪問される方がアクセスされるページのフレーバーは .html に統一することは何とかできました (^-^;>

　次はサイドバー部分も含めて、レイアウトの見直しです。
　かなり以前に 楽天ダイナミックアド 、 Amazon.co.jp おまかせリンク を、 PukiWiki 側 に配置して、 試行していましたが、PukiWiki のような ? マークが含まれクエリーのように見える長い URL でページへアクセスするようなタイプの CMS(Contents Management System) に配置すると 「棚卸しセール」のような状態 （つまりはほとんどなんの脈絡もない商品を表示するだけ）になります。
　おそらくはなんですが、この手のツールは ページ内のキーワードを URL にくくりつけてデータベース化していると思われ、 その際くくりつける URL の文字列からクエリーを投げていると思われる ? から始まる部分は （ある程度以上の長さになると）削除しているのでしょう。 このためひとつ URL にくくりつけられるキーワードが多くなり、 必然適切な商品情報を選べなくなり、異なるページでも似たような商品しか表示できない という状況に陥るのだと思われます。
　先述の二つのツールと比較すると、 ブログであろうと PukiWiki であろうと ある程度ページ内容に合った広告を出す Google AdSence が いかにすごいかという話にもなるのですが…
# バックエンドで収集しているページ情報の規模がそもそも違うという話に帰結しますけど。

　しかしながら、この手のツールが目を引くのも確かで、 ブログ系の CMS と組み合わせた方がより機能すると思われ、 またやはり客観的にみて目を引くので、 Ellinikonblue.com Weblog で 採用することにしました。
　push_if_first プラグイン を 導入するなどして新たな設置場所も確保したので、 アフィリエイトとは関係のないガジェットなどを含めて配置を考え直します。

　ただいま Ellinikonblue.com Weblog の フレーバー構造を こちら の 構造を反映したものに変更中。 そのついでと言っては何ですが、 bsnap_hs プラグイン にもすでに対応済みです。

　しかしながら、 あちら は こちら と違って、 アフィリエイトバナーなどもすでにどっさり埋め込んでますので、 主目的であるフレーバー構造の反映にそもそも手こずっていて、 また こちら と同様、 人様がアクセスするページは .html フレーバーに統一するという大手術をすることにしたので、 一応そのことによる問題点を洗い出しながらやってますが、 切り替え時にも相当な混乱を伴いそうです。
　おまけにそう言いながら push_if_first プラグイン の導入まで一緒にやってしまっているのだから、 自分自身に恐れ入ってます orz

　作りなれない To Do リスト なんてものを作ったもんだから義務感になり始めているという話もあり。 やめときゃ良かった (T-T)
　こんな泣き言言うためのブログじゃないんですけどね、 こちら は… ま、らくがき と 言うことで…

　最近ちょっと本業のほうが忙しくて、 ホームページ群のメンテナンスがおざなりになっています。 gin プラグイン の実装の最終段階 entries_kache プラグイン の機能包含については手をつけ始めたのはいいのですが、 ここ数週間、同様におざなりで、既に書き始めたコードを自分が読めなくなり始めています orz

　これではいかんので To Do リストなどという、作りなれないものを作っておきます。

1. Ellinikonblue.com ドメインサイト
   • Ellinikonblue.com Weblog の フレーバー構造の変更
     　このブログ を 構築した際に従来のフレーバーを若干見直したので、それを Ellinikonblue.com Weblog に 反映して、サイドバー部分なども整理しなおしたいと思います。
   • Ellinikonblue.com Weblog への bsnap_hs プラグインの導入
     　そもそも Ellinikonblue.com Weblog へは bracket_fep プラグイン も導入していないという話が… orz
     　bsnap_hs プラグイン そのものはもうしっかりできているのにもったいない。
   • トップページ のお化粧直し
     　ほんとにあれで当面おしまいにする気はないので… とりあえずサイトサムネイルを HeartRails Capture にしてみたりとかしてみたいし。
   • Ellinikonblue.com PukiWiki の 古くなったコンテンツの更新
     　コンテンツより PukiWiki そのものの バージョンが古いという話が… orz
2. Ellinikonblue.net ドメインサイト
   　Ellinikonblue.net 回りとか このブログ とかでいくつか 実験したいことがあります。それは思いつくたびにエントリすることにして… Photolog の方も そろそろちょっと何とかしてみたい。
3. その他
   • gin プラグイン の実装 STEP2
   • asin_complex プラグイン の bracket_fep 化
   • WordPress を イジイジしてみたい

ぐえ orz
無理かも…

　10/5 に Ellinikonblue.com の トップページを大幅に更新したため、そろそろこの Ellinikonblue.net Devlosxom に 迷い込まれる方が出てくるかと思いますので。。。

　このサイトは最初のエントリ 「 はじめに」 にも書きましたが、 blosxom 関連の 開発を中心に様々な実験を行うために運用していますので、常に安定した閲覧は保証しかねます。
　また Ellinikonblue.com Weblog とは異なり、 rwbc プラグイン を 導入していませんのでトラックバック、コメントには即座に反応できませんし、 古いエントリへのトラックバック、コメントには気づかない可能性があります。 また wikieditsh プラグイン を導入していないためにこちらからトラックバックをお返しすることもできません。
　これらの未導入のプラグインに起因する問題はそのうち何とかするつもりですのでご容赦ください。

　またこちらで開発、実験を続けているプラグインですでにある程度完成しているものはありますが、 納得できる完成域に入ったら、 Ellinikonblue.com Weblog で 報告しますので、常にはそちらをご覧いただいていればよいかと思います。

　まぁ陰でこそこそこういうこともやっているんだと言うことを 頭の片隅にでもおいといていただければ十分かと思います。 以後、お見知りおきを m(_ _)m

小粋空間 「 WordPress で『続きを読む』の折りたたみ Web2.0 」

　ちょっと前からやってみたいと思っていた AJAX ライブラリを使った ナビゲーションの折りたたみ。上記のページを参考に（ぱく…？）すればできそうな感じ。
　メモっとこう φ(.. )

• script.aculo.us

　bsnap_hs/bsnap_tx プラグイン より先に手をつけていた gsitemap プラグイン を公開しました。
　entries_kache プラグイン のインデックスファイル出力タイミングとのかねあいで、 試行錯誤したために少々手こずった上、詰めの際に凡ミスを連発しましたが何とか entries_kache プラグイン のインデックス更新タイミングに同期して、 出力できるようになったので、ここで FIX しました。

　以下に 2007 年版 gsitemap プラグイン の 2007.9.16 時点の仕様をまとめておきます。

1. entries_kache プラグイン が出力するインデックスファイルをサイトマップファイルに変換するため、 このプラグインのインストールは必須です。 インデックスファイルの仕様上、entries_index プラグインファイルでも代替可能。
   　ただし、entries_index プラグインの場合は、アクセスごとにインデックスファイルが更新されるため、 サイトマップファイルもその都度更新されます。効率低下の原因になるため、 entries_kache プラグイン のインストールを強く推奨します。
2. タイムゾーンの設定は自動で行うようになっています。 国外のレンタルサーバなどではプログラム的に修正が必要かもしれません。
   （要望があれば、手動設定するように修正することは簡単なので用意します）
3. 本バージョンは blosxom の 動的生成の仕組みを利用していないために専用のフレーバは必要ありません。
   　その代わりに、出力されるサイトマップファイルの形式の変更には、 プログラム本体の変更が必要になります（そんなに難しい修正ではないですが…）。

以下、サイトマップファイルの出力例です。

<?xml version="1.0" encoding="utf-8"?>
<urlset xmlns="http://www.google.com/schemas/sitemap/0.84">
  <url>
    <loc>http://www.ellinikonblue.com/blosxom/</loc>
    <changefreq>daily</changefreq>
    <priority>0.8</priority>
  </url>
  <url>
     <loc>http://www.ellinikonblue.com/blosxom/blosxom/plugins/20070916gsitemap2007.html</loc>
     <lastmod>2007-09-16T17:30:01+09:00</lastmod>
  </url>
  ：（以下、繰り返し）
</urlset>

　Highslide JS を利用した 機能強化版 snap_in プラグイン の実装はほぼ終わりました。
　highslide プラグインと命名しようかと思ったのですが、 あまりにもひねりがないので、 bsnap_hs プラグイン とすることにしました。
　この bsnap_hs プラグインは bracket_fep プラグイン 用のプラグインとして実装していて、 これまでの snap_in プラグイン 同様、エントリ内で

[imagefile.jpg]

とした位置に画像を挿入します。 ただし、プラグイン内のパラメータで指定する画像ディレクトリと サムネイルディレクトリに同名の画像ファイルが存在すると Highslide JS が有効になり、 通常状態ではサムネイル画像が表示され、クリックすると画像ファイルに拡大されます。
　サムネイルが存在せず、画像ファイルだけが存在する場合は、 これまでの snap_in プラグインと同様の動きになります （単にエントリに画像を挿入するだけ）。

　以下は Highslide JS を 有効にした場合の利用例。 　無効にした場合の利用例。 　上記二つの画像は、エントリテキスト上は同じ表現になっていますが、 サムネイルディレクトリに同名のファイルがあるかないかで 動作が変化しています。

　さて、もともとの snap_in プラグイン は、画像を取り込む以外に、定型のテキストを取り込む機能を有しています。 この機能も bsnap_hs プラグインに取り込もうと思ったのですが、 コードが汚くなりそうだったので、突貫で定型テキストを取り込むだけの bracket_fep プラグイン 用プラグインも別途用意しました。
　以下、その bsnap_tx プラグイン のテストです。 　我ながらいい感じなので、さていつ公開しようかな。。。というとこです。
　なんせこの Devlosxom だけで こそこそやってることなんで気軽気軽 (^ε^)

　いきなり Highslide JS を 利用したサムネイル対応画像挿入プラグインの実装に入りました。
　このエントリが開発のためのテストエントリになります。
　進行状況は、下図の写真をいじっているとわかるかも… (^^;>

　…なんてことをしてみたい衝動に駆られました。 本当にできるかどうかなんてことまでは、今、考えが及んでません (>_<;>
　だいぶ前から、元絵とサムネイルを用意すればリンクして表示ができるように、 snap_in プラグイン を改良したいなとは思っていましたが、 とにかく 小粋空間 で Highslide JS が 使用されているのを見て一目惚れです。とにかくすてき )*^O^*(
　ちょっと時間ができたら、すぐに取り組みたいと思います。
# まずはきれいな実装ができるかどうかをじっくり考えるべし。。。

• 小粋空間 「 Highslide JS でサムネイル画像を拡大表示する」
• Highslide JS

　ひらめきました！ (^^)b
　なにをかというと、 gsitemap プラグイン の新しい実装方法です。

　そもそもこの gsitemap プラグイン はどういうものかというと、 名前から察することができる方もいると思いますが、 Google サイトマップ に 提供する XML ファイルを生成するプラグインです。
　意外にこのプラグイン、うちのいい加減にでっち上げたプラグインの中では、 ご使用いただいている方の多いプラグインではあるのですが、 開発（と言うほど偉そうなものではありませんが） 当時 、 即興で作ったために、エントリ数が多いと Internal Server Error を引き起こす 問題を解決しないまま、サイトマップに記載するエントリ数を制限するリミッタを設定するという 超いい加減な方法でアドホックに対処して、ほったらかしにしていました。

　後になって冷静に考えると、専用フレーバーを使って blosxom の フレームワークをそのまま利用して、 サイトマップデータをメモリ上に生成するので、 あまりにもエントリ数が多い場合、メモリがオーバーフローするだろうとすぐに想像がつきました。
　ではデータをファイルとして生成してしまえばよいのですが、 この生成するスクリプトをどう実装するかと言う問題になります。 CGI で作り込んでしまえば、さほど労せずできそうですが、 それは blosxom の スタイルではありません。「機能はプラグインで追加する」というのが正道です。

　と言うことで悩んでいたのですが、最近、 gin プラグインに entries_kache プラグイン の機能を取り込んでいくにあたって、 このエントリインデックスファイルをサイトマップファイルに変換するプラグインにする と言う実装方法を思いつきました。
　これなら gin プラグインが entries_kache プラグイン の機能を取り込んでも、 JSON 形式のエントリインデックスを読み込む部分だけをすり替えるだけで使えそうです。
　方向性が決まれば、実装はそんなに難しくなさそうですので、 この Devlosxom の方で、 早速実験して、うまくいくようでしたら早々に公開したいと思います。

　幸い 仕様変更した ことで gin プラグインも不具合なく動作するようになりましたので、 gin プラグインが生成するインデックス情報を元に動作する archives/categories プラグインも含めて、 Ellinikonblue.com Weblog の方にも導入し、 これらに関しても現状問題なく動作しているようです。
　ひいき目もあるかもしれませんが、 現在 1,000 弱のエントリ数がある Ellinikonblue.com Weblog への 導入効果は絶大で、表示のもたつき感がなくなったように感じます。

　一応、gin プラグイン開発の STEP1 だと思っていたところまでは、 成果を上げたと判断しましたので、今後、STEP2 （ entries_kache プラグイン の機能を取り込みが最大の目標。あわせて余裕があれば、 gin プラグインのインデックス情報を利用する calendar プラグインを開発する）は 少し時間をおきたいと思います。
　その STEP2 開始までに、 ここまでの gin プラグインのコードをもう一度見直して、 シェイプアップする傍ら、 この Devlosxom の公開を、 Ellinikonblue.com 側の トップページ更改とあわせて準備していきたいと思います。

　Devlosxom 側の作業として、 いくつかプラグインを付け足してから、 Google Analytics へ情報送信を 開始していきたいと思います。
# その後は、Ellinikonblue.com 側の トップページ更改へ集中したいと思います。

　対策を 施した にもかかわらず、また消えました。。。エイリアス情報 orz
　アルゴリズム的に消えないと思っていましたが、 ここは消えた現実を真摯に受け止めて、気合いを入れ直してコードを見直したのですが、 私の能力ではもう解決不能。。。

　と言うことで、仕様を変更することにしました。
　これまでは gin プラグインが出力したカテゴリ情報ファイル (categories_index.json) に直接、カテゴリに対するエイリアス情報を 書き込んでいましたが、エイリアス情報は別ファイル (categories.alias) とし、カテゴリ情報出力時にエントリ情報シーク結果とマージして、 出力するようにします。
　この仕様であれば、一度作成したエイリアス情報は基本読み込むだけですから、 消えることはありません。 また、gin プラグインが出力するカテゴリ情報を利用する categories プラグインを 作り替える必要もありません。名案！（自画自賛。失礼 (_ _"> ）

　エイリアス情報を記載する categories.alias ファイル（ファイル名はデフォルト）は 以下のようなディレクトリ名とエイリアス名をセットにして記載する JSON 形式ファイルとします。

{
  { "directory": "/home/public_html/devlosxom/data/About", "alias": "このブログについて" },
  { "directory": "/home/public_html/devlosxom/data/Doc", "alias": "ドキュメント" },
  { "directory": "/home/public_html/devlosxom/data/Doc/Idea", "alias": "アイデア" },
  { "directory": "/home/public_html/devlosxom/data/Doc/Resources", "alias": "参考資料・メモ" },
  { "directory": "/home/public_html/devlosxom/data/Plugin", "alias": "プラグイン" },
  { "directory": "/home/public_html/devlosxom/data/Plugin/Spec", "alias": "仕様" }
}

　現在、この仕様で gin プラグインを改装中です。
　そんなに難しい改造でもないので、時間さえとれればすぐにできると思います。 うまく動き始めたら即 Ellinikonblue.com Weblog の方でテストを開始するつもりです。

　blosxom に おけるエントリのメタ情報を JSON 形式で出力する gin プラグイン を Ellinikonblue.com Weblog の方で 最終的なテストしていたのですが、重大な一つ問題が見つかりました。
　実は Ellinikonblue.net Photolog で 実験していたときに一度だけ発現した問題で、 gin プラグイン はエントリのメタ情報の一つとして、 カテゴリ情報を一つの JSON ファイルとして出力します。 各カテゴリへのエイリアス（別名）は、このファイルに直接記述することで実現しますが、 この JSON ファイルに記述したエイリアスが消失すると言う問題です。
　Ellinikonblue.net Photolog で 発現した際もそのときは原因がわからず放置していたのですが、 うちの blosxom で 動作しているサイト群で、最大の PV を誇る Ellinikonblue.com Weblogで 三ヶ月テストして、たった一回と言う発生頻度も非常に少ない問題でした。
　ただやはりエイリアス情報とは言え、消失するということは大問題です。

　ソースコードとにらめっこした結果、 この消失問題が発生する条件は、ごく短いタイムスライスの間に gin プラグイン が多重起動した場合（通常、更新タイミングでない限り機能（起動）しない）、 entries_kache プラグイン と同期して、メタ情報を更新する際の JSON ファイル出力最中に、 同ファイルのオープンを要求することしか考えられません。 この条件を満たしてしまうと書き換え中の JSON ファイルの内容を 読み込まずに処理を先に進めるアルゴリズムになっています。
　上記の条件を熟考して、最初はロック機構を実装しようと思ったのですが、 gin プラグイン が機能しているのは、ごく短い時間で、 かつ機能する頻度も通常は１時間に一度なので、 万が一このタイミングでカテゴリ情報ファイルを開き損なった場合、 5 秒間スリープして、再度オープンを試みるか、それでもだめなら 機能を中断すると言う処理を入れ込みました。
　これでクリティカルなタイムスライスに多重起動しても、 リトライするか、最悪、エイリアス情報消失につながる書き込みをしません（そのはず…）。

　この対処を施した gin プラグイン でまた少々テストです。
　ここ の 公開がまた延びたな…これで orz

　一ヶ月くらい前の話になるのですが、 asin_complex plug-in が Amazon.co.jp の 商品画像へのリンクを作成する際、失敗することが目立って多くなっていることが 気になり始めました。

　これまでも商品画像が落ちることはあって、それなりに対策は打っていたのですが、 どうもこれまでとは違う「新商品でかつ商品画像が登録されていない 製品のものに限って落ちる」という規則性があることに気づきました。
　よくよく調べてみると、これまでは商品画像がまだ登録されていない新商品には、 ダミーの商品画像への URL が XSLT の問い合わせで返ってきたのですが、 新製品に関しては全く画像への URL を返さないようになっていました。 いつから仕様が変わったのかわかりませんが、 直近で登録されている商品については、 商品画像が登録されるまでは商品画像への URL は何も返さないようです。
　これに対しての対策と、商品画像があってもうまく判別できないことがあったので、 以下の対策を施しました。

1. 問い合わせの結果で商品画像の URL を返さないときの処理を追加
2. 商品画像の確認は 5 秒おきに 5 回までリトライを行って、成功した時点で 商品画像への URL を確定する

　半月くらい試した結果、安定性も向上したように思いますので、 Ellinikonblue.com PukiWiki でも 公開することにしました。 もしご使用の方がいらっしゃいましたら、アップデートをご検討ください。

「 ぐるなびが API 公開、全国約 4 万件の飲食店情報が利用可能に」 （ CNET Japan より）

　エントリを書いている際、まれに地図情報が必要になるときがあるので、 そのうち何らかのサービスもしくはその API を利用して、 blosxom のプラグインをでっち上げたいと思っています。
　いつかその日がきたときのために、 ちょっと今現在気になっている地図系ウェブサービスを整理しておきます。

• Google Maps/ Google APIs
• Yahoo! 地図情報/ Yahoo! デベロッパーネットワーク
• SimpleAPI 「 最寄り駅 Web サービス & 最寄り駅モバイル地図」
• HeartRails Express
  路線／駅名データサービス
• ちず丸
• ちず窓β
  Ellinikonblue.com Weblog 「 chizumado （ちず窓）」
• ぐるなび 「 ぐるなび Web サービス 開始！」

3ping.org 「 デフォルトスタイルの差異を無くす CSS 」

　blosxom の フレーバーを作るときなど、結構重要なテクニックになるそうな予感 (._.)φ

【ネタもと】

• KANGAROO-OASIS 「 デフォルトスタイルの差異を無くす CSS 」

「 バリューコマース、商品検索 API サービスをバージョンアップ -- システムも増強」 （ CNET Japan より）

　blosxom で エントリ中で取り上げる商品をアフィリエイトと連携させたい場合、 意外に多そうでそうでもない Amazon.co.jp だけでは、 商品ラインナップとして物足りなさを感じることがあります。 　楽天 API や、 バリューコマース ・ウェブサービス 2.0 などで、 asin_complex プラグインみたいなプラグインを作り込めないか研究したいと思っていますが、 やるとしたらちょっとまとまった時間が必要っぽい。
　asin_complex も 相当、手こずりましたし。。。

• バリューコマース・ ウェブサービス 2.0
• 楽天 ウェブサービスセンター
• Ellinikonblue.com Weblog 「 楽天 API …興味はある」

　blosxom における エントリのメタ情報を一括してインデクシングするプラグインを こつこつ作っていました。 gin(Generate INdex) プラグインと命名しました。 ジン (gin) は様々なカクテルのベースになるお酒なので、それにちなんでみました。
　この gin プラグインが、ある程度形になってきましたので、 とりあえずここまでの仕様とまとめておきます。

1. エントリの分類（カテゴリ）、エントリ日時を一括してインデクシングします
2. インデクシングされた情報は JSON 形式で出力されます
3. エントリの分類情報で、子カテゴリ数を親カテゴリに含めるかどうかは、 このプラグイン内で設定します
4. エントリの分類名に対するエイリアス（別名）は、このプラグインが出力する JSON ファイルに記述します
5. gin プラグインが出力する JSON ファイルを元にする archives/categories プラグイン互換のプラグインを用意しました
   （現在このページで使用中）

　分類情報の JSON ファイルは以下のようになります。

{
	{ "directory": "/home/public_html/devlosxom/data", "count": 7 },
	{ "directory": "/home/public_html/devlosxom/data/About", "count": 2, "alias": "このブログについて" },
	{ "directory": "/home/public_html/devlosxom/data/Doc", "count": 4, "alias": "ドキュメント" },
	{ "directory": "/home/public_html/devlosxom/data/Doc/Idea", "count": 1, "alias": "アイデア" },
	{ "directory": "/home/public_html/devlosxom/data/Plugin", "count": 1, "alias": "プラグイン" },
	{ "directory": "/home/public_html/devlosxom/data/Plugin/Spec", "count": 1, "alias": "仕様" }
}

　エントリ日時情報の JSON ファイルは以下のようになります。

{
	{ "year": 2007, "count": 7 },
		{ "year": 2007, "month": 5, "count": 1 },
			{ "year": 2007, "month": 5, "day": 4, "count": 1 },
		{ "year": 2007, "month": 4, "count": 2 },
			{ "year": 2007, "month": 4, "day": 18, "count": 1 },
			{ "year": 2007, "month": 4, "day": 7, "count": 1 },
		{ "year": 2007, "month": 3, "count": 3 },
			{ "year": 2007, "month": 3, "day": 24, "count": 1 },
			{ "year": 2007, "month": 3, "day": 3, "count": 1 },
			{ "year": 2007, "month": 3, "day": 2, "count": 1 },
		{ "year": 2007, "month": 2, "count": 1 },
			{ "year": 2007, "month": 2, "day": 26, "count": 1 },
	"count" : 7
}

　今後、さらに以下の機能を追加していく予定です（優先順位順）。

1. entries_kache プラグイン に同期して、メタ情報を更新するようにする
2. 最終的には entries_kache プラグインの機能を取り込んで、 entries_kache プラグインが出力するエントリに関するメタ情報も JSON 形式で出力するようにする

　entries_kache プラグインと同期して更新するところまでできれば、 Ellinikonblue.com Weblog の方でも紹介して、 そろそろこのブログもオープンにしようかな。。。

Ellinikonblue.com Weblog 「 nofound プラグイン」

　ずいぶん前に Ellinikonblue.com Weblog の 方に書きましたが、 徒書 製 notfound プラグイン をベースにした nofound プラグイン が何とかできました。
　これ以上手を加えることもないとは思いますので、 その改変した部分を仕様としてまとめておきます。

1. @noindex_flavours に設定したフレーバーに対して、インデックスページを要求する （例 index.writeback ）は not found を返すように設定可能にした
2. 設定値 @except_flavours, @noindex_flavours は正規表現形式ではなく、 リスト形式で記述できるように変更

　どこまで意味があるかは不明。
　イメージとして、iCal でエントリ日時のメタ情報をはけば、 例えば Google カレンダー のような オンラインカレンダーサービスとマッシュアップしておもしろそうなものができそうな気がする。。。
　何となく調べていると、iCalender 形式の仕様が出てきたのでとりあえずメモ (._.)φ

• iCalendar 仕様

　先般 から blosxom の エントリをインデックス化するプラグインを試作しているのですが手間取っています。
　インデックスを JSON 形式で出力すると決めたところまではよかったのですが、 何を思ったか（って一応、それなりに思うところはあったのですが…） この JSON 形式の ファイル入出力を CPAN の JSON モジュール を 使わないと決めたのが運の尽き。出力はそれなりにできたのですが、入力でこけてます。
　しかし、JSON モジュール は使わないという ポリシーは貫こうと思うので、もう少しこちらは時間がかかりそう。

　それと並行して、徒書 製 notfound プラグイン の改造をやっています。
　Ellinikonblue.com Weblog の方のことなんですが、 以前から妙な URL へのアクセスが頻発していて、一度、この notfound プラグイン を導入してみたことがあるのですが、 オリジナルのままではこのアクセスを排除できませんでした。
　ただ発想は同じ方法で排除できると思うので、本来インデックスページがあるはずのない フレーバー のインデックスページへのアクセスを排除する機能だけを付け加えようと思ったのですが、 とちくるって全面改装しています。 ということで、名前も nofound プラグイン と改名しようかと。 できあがればですけどね f^-^;

　いくらまだ人を見せることを意識していないサイトと言えど、 いつまでたっても CSS すら用意せず、べたのまんま放っておくのは どうかと思いまして、ちょっとレイアウトだけ整えました。
　最終的には、 JavaScript を駆使したりして、いろいろ フレーバー を試そうと思っているのですが、 とりあえず今は自分が見るときに見苦しくなければ、それで O.K. ということで。

　この devlosxom を開設して、 まず何から手をつけるかというと、 どの blosxom サイトにも 導入されていることの多い archives/ categories/ calendar プラグインの見直しです。
　この三つのプラグイン、blosxom.cgi から呼び出される filter サブルーチンで似たり寄ったりのことをやっています。 エントリの登録年月日、タグやカテゴリ、投稿者などのメタ情報の全件検索です。 これら三つのプラグインを導入するだけで、 1 ページの画面を作り出すために、三度もエントリの全件検索を やっているわけですから、効率の低下は明らかです。

　ところで、一般的なブログツールでバックエンドにデータベースを用意すると 何が便利になるかというと、記事の検索です。 それも本文の内容とかそう言う細かいことではなく、 各エントリに対するメタ情報に関する検索、統計が瞬時に引き出せます。 データベースでは登録されたデータに関してインデックス化しているので、 当たり前といえば当たり前なんですが、 逆にバックエンドにデータベースを持たない blosxom にとっては、 この機能がないことが弱点となっていることが少なくないわけです。

　しかしながら、非常に重要に見えるインデックス化の処理というのは、 ブログというツールにおいて、少なくともエントリのメタ情報に関しては 更新の頻度はそんなに多くありません。 その更新のタイミングは、ほぼ新規エントリが登録されたときか、 メタ情報そのものを編集したときだけです（…だと思います）。

　以上の思いこみを元に、 エントリに関するインデックス化を一手に引き受けるプラグインの作成、 そのプラグインの存在を前提とした archives/ categories プラグインと、時間があれば calendar プラグインまで見直したいと思います。

　develop + blosxom で Devlosxom と言うからには、 blosxom に 関する開発（と言うほどのことが出来るかはわかりませんが…） を行う意気込みででっち上げたので、一応開発方針など。
　頻繁に変わることがあるとも思いますので、 とりあえず 2007/3 版として。

• blosxom.cgi 本体には手を入れない

　blsoxom.cgi 本体に手を入れ出すと、最終的に blosxom とは 別物のブログツールの開発と変わらなくなってしまうので、 これだけは「禁じ手」と言うことにしておきたいと思います。
　とりあえず今はこれだけ。

　"Ellinikonblue" を冠する三番目の blosxom サイトを開設しました。
　Develop + Blosxom = Devlosxom とした （ネーミングセンスに関しては自分でも あまりいいとは思っていません f-_-;> ）このサイトは、 ちょっと大がかりなことをいくつかやろうと思いまして、 blosxom はもちろん、 JavaScript 、スタイルシートに関する実験を 主に行う目的で開設しましたので、常に安定した閲覧は保証しかねます。

　しかし、これから先のことは思いやられますが、久々に真っ白な blosxom サイトって気持ちがいいです。