iso tank - blosxom 2007年

以前にちょっといじった entries_kache プラグインについて、あるサイトで言及されいたのを発見したです。

はてなブックマーク - 徒栞 / blosxom

iso tank - entries_kacheプラグイン改造

[blosxom]改造されてた。/ 「blosxom本来のentriesサブルーチン」は毎回全ファイルをfindで探索して更新時刻を取得するので、その改造だと却って遅くなっているような気が。

( ∵)・・・

Σ(∵)アッーーーー！！！

どうもmixiにRSSを直接指定して外部blogとリンクさせる方法だと、うまいとこ最新日記が表示されなかったり 変になったりする現象があるらしい。mixiの仕組みにいまいち不安があったこともあり、広大なネットの海を泳いで プラグイン漁りの旅に出たところ、10分かからないで mixipostというイカスプラグインに出会った。

このmixipost、単純な話、記事データを読み取ってmixiに内容をアップロード「し直す」仕組みである。 この「mixiにアップロードし直す」という部分には、 WWW::Mixiという これまたイカスモジュールが使われている。このモジュールは早い話mixiにアクセスしたり色々なデータを読み取ったりと mixi「だけ」に特化したモジュールだ。簡単に言うとこのプラグインを使ってログイン→日記書き込み→ログアウト を自動化して行っている。

mixipost上で記事を書き、それをblosxomとmixiへ同時に投稿する機能もある。

ただ、やはり俺としては（さもしい自己主張かもしれないが）blosxomがメインと考えているので、mixiへUPするのは よっぽど短い記事を除いて冒頭部分（要約のみ）としたい。そんなわけでまたプラグインをぽちぽちいじって、 整形・出力部分（具体的にはsub sanitizeとsub storyの後半）で自分の好きなように整形。置換連発。チカンチカン。

一つだけ悩み事を挙げるならば、このプラグインの実行に必要なWWW::Mixiを導入するために、サーバー上に 「./WWW」などというディレクトリを作らなければならなかったことだ。つまりモジュールとして「WWW::Mixi」なのであって ”::”とは境目を示す。「WWWの中のMixi」ということになる。これをblosxom本体からアクセスできるようにするため、 CGI本体の位置から相対的な位置に「WWW」ディレクトリを作成して、その中に「Mixi.pm」を物故無（ぶっこむ）ことで このモジュールを実行できるようにした。つまりモノはイカスのに見た目がおよろしくない。これなんとかならんのか。

same_categoryプラグインは、 ある記事と同じカテゴリ（話題）に投稿された、最近の記事のリストを提供するプラグインです。 というのが本来の使い方です。

本来の使い方、というのは、俺は本来の使い方から逸脱した目的でこのプラグインを導入したからです。 つまり、ブログのＴＯＰにおいてはすべての投稿された記事の最新の数件をリスト化するようにしたです。 他のプラグインを導入することなく、ひとつのプラグインで複数のことができるのなら、いいのかなと。

というか元々はJavaScriptを利用してこの機能を実現していたんですけど、俺正直Javaとか苦手なんっすよ。 なんかあるだけでソワソワしてくるんっすよ。尤も、 Google Analyticsの統計だけは仕方ないなぁと 入れておったわけなんっすが。

そもそもこの機能自体が必要かどうか（それほどまでにこのサイトに需要／閲覧者がいるのか）という 俺のアイデンティティを心底揺るがすような思考は俺の寿命を早めるので考えることをやめた。

曉に死すさんとこのlamitapプラグインを 導入。ようするにサイトの内容に変更がなければ304 Not Modifiedを返してやるという仕組み。 304が返るとどうなるかって？　ま、まぁブラウザによってはサーバーのデータを一々取得にいかないで キャッシュを読み込んだりしてくれるんじゃないかなー。と。そ、そこんとこわかってよ！　もう！

flavourdirにあわせて少々コード変更。

先々週の日曜から恩師に頼まれて高校生ドモにスキー教えてたら、最終日に熱出した。 なんとかスキー教習終えて家に帰って熱測ったら38度2分とかでてんの。ふざけてる。 オイラは恩師の頼みで仕方なく（会社にナイショで）無償奉仕で高校生にスキー教えた。 仕方なくである！　キャホホーイ！　その見返りが38度2分とはコレどういうことか。 キャホホーイ！　納得いかん。キャホホーイ！　まあそんなわけで死んでました。今は生きてます。

さて本題に入ろうか。このブログのメインプログラムは言うまでもなく blosxom（ブロッサム）です。blosxomには Movable Type(以下"MT") と似たような「テンプレート機能」があります。ただし「テンプレート」と呼ばずに 「フレーバー」と呼びます。風味とか味つけとかいう意味らしいです。MTのテンプレートや 「テーマ」などのシステムがどういうものかは正直知らないですが、blosxomの場合は、 整形されたHTMLファイルとCSSとそれらに関連づけられた画像等を一セット用意すれば HTMLファイルを分割するだけでそれがフレーバーになる感じです。

で、ここに長所とも短所ともとれる特徴がある。blosxomの「フレーバー」システムは、 テンプレートといえるHTMLデータを、「content_type」「head」「date」「story」「foot」 の５つに分割して管理・保存しなければならないのです。例えば「cupy」というフレーバー （フレーバーの名前は自由につけることができる）を作成したとして、cupyフレーバーは 「content_type.cupy」「head.cupy」〜「foot.cupy」と、最低でも５つのファイルを作る 必要があるのです。つまりフレーバーの数が増えればそれに×５倍してファイル数の増える増える。 CSSや画像を別に用意する必要も（場合によっては）あるわけで。さらにその上、 フレーバーを設置するディレクトリは基本的に記事を設置するディレクトリと同じなの。 つまり記事データとフレーバーファイルがゴッチャ混ぜになってアララ大変なことにもなりかねぬ。

と、いうわけで例によってプラグインでこれを解決するのです。幸い、既に考案されてる プラグインに「flavourdir」という、記事を設置するディレクトリとフレーバーを設置する ディレクトリを分割してしまえるプラグインがあるのです。さらにその上、「theme」という わざわざ５分割して保存することなくフレーバーをひとまとめのファイルにして管理する プラグインもあったのです。ここにきてようやく表題に追いついた。

ようはこの二つのプラグインを合体さして「別ディレクトリに追いやりつつ見やすく、 管理しやすくしてしまおう」という魂胆。ソースを眺めて大体アタリをつけてれっつら ガチャン。プラグイン、バグった。当たり前やがな。そんなポン付けで動いたら誰も苦労せん。 それはさておきなんで動かないのだろうか。いつもここから俺のPerlのおべんきょうがはじまる。 ポン付けでも文法的にはさして問題なかった気はするのだが。む、む。 content_typeのフレーバーだけがなぜか適用されている事に気づいた。ということはアレか、 いやコレか。

色々考えてるうちに「後方参照」という単語に行きついた。

だれかまじめに教えてほしいんですけど、

do {
    処理
} while (条件文);

という処理があったときさー、

do {
    $q =~ /(foo)(bar)/;
    $a = $1;
    $b = $2;
} while ($p =~ s/(PATTERN)// and $1);

みたいなふうなコードがあったとしてさー、whileの条件文内でマッチした場合、 do内の処理の$a=$1にはPATTERNが入っちゃうわけでしょうか？　とすると$2はfoo？　 とりあえずなんとかはしたしうまいとこ動いてるようだけど、なんかしっくりしない。

とりあえず改造版flavourdir。

1/30追記。ちゃんと使い方ぐらい書いておこうかと思った。

フレーバーを入れておきたいディレクトリを$flavour_dirに、フレーバーファイル の拡張子を$extに（フレーバー名でなくファイルの拡張子。）設定して、フォールバック の有無（もし$flavour_dirに希望のフレーバーが無かった場合、元のテンプレート機能、 つまり$blosxom::datadir内を漁ってフレーバーを探すかどうか）を指定したら、 $flavour_dirで指定したディレクトリにフレーバーを入れるだけ。フレーバーファイルの 書式は<!-- blosxom content_type text/html; charset=UTF-8 -->とか <!-- blosxom head --><!-- blosxom date --><!-- blosxom story --> <!-- blosxom foot -->を、それぞれのブロックの先頭に書いておけばOK。 というか本当に単純にflavourdir+themeしただけなのでここまで書いておきながら やっぱ別に説明とかいらなかったなーとか後悔。