Persica V1.00 公開

【Persica】

少しだけ使いやすくなったかも。
何となくだが make とか ant みたいな使い方ができるようになった。

1. アーカイブを展開し persica.rb にパスを通しておく。
2. 作業用ディレクトリを用意する。
3. 作業用ディレクトリに persica.conf と ｓｋｉｎ ディレクトリをコピー。
4. 作業用ディレクトリに persica.conf の $source_dir を作成。
5. $source_dir にテキストファイル配置。
6. 作業用ディレクトリで persica 実行。

こんな感じ。persica.rb はカレントディレクトリの persica.conf を読み込んで動作する。

ちなみに asagi box の場合、作業用ディレクトリは以下のようになっている。

作業用ディレクトリ/
|-- persica.conf
|-- skin/
|   `-- スキンファイルとか CSS とか
`-- src/
    |-- hermes/
    |   `-- テキストファイル
    |-- index.txt （トップページ）
    |-- note/
    |   `-- テキストファイル
    |-- program/
    |   `-- テキストファイルとか tar ボールとか
    `-- review/
        `-- テキストファイル

これを丸ごと Subversion に突っ込んでいるわけだ。
でも全然更新してないからあんまり意味ない。

eval

Persica は Javascript と相性が悪いことが判明。eval が消化不良を起こしてしまう。動けばいいやと良く分からないまま書いた箇所だ。とりあえず調査中。

トンネル工事

おれは CVS 大好き人間であり Persica の開発も asagi box の管理も CVS を利用している。

ところで Persica の開発は仕事場と自宅で行っているのだが、俸給生活者であり二児の父親でもあるおれにとってはそのどちらでもまとまった開発時間の確保は困難である。おのずと細切れの空き時間を寄せ集めて作業することになる。

ここで問題になるのは CVS リポジトリの扱いである。仕事場のファイアウォールはHTTPとHTTPSしか通さず、ネットワーク的に分断されているため、自宅の Linux サーバ上のリポジトリに仕事場からアクセスすることは出来ない。もちろんその逆も不可能である。

どちらの場所でも CVS を使う。それはおれの中では大前提である。しかし仕事場と自宅で別々にリポジトリを用意し、それぞれでコミットするなど論外もいいところで、一つのファイルを複数のリポジトリで管理した日には履歴が分散して CVS のメリットが損なわれてしまう。

なのでおれはミラーリングを行った。リポジトリそのものをコピーするのだ。手作業で。

具体的には帰宅前と就寝前にそれぞれの場所でリポジトリをアーカイヴし USB メモリに放り込み、出勤後と帰宅後にアーカイヴを展開してリポジトリを丸ごと入れ替えるのである。これなら一応編集履歴も一貫するし妙な衝突も起こらない。

しかし面倒は面倒なのだ。USB メモリを仕事場に置き忘れたりすると、その日が金曜なら週末丸々作業が停滞してしまう。というか一度実際に停滞した。これはストレスだ。

そこで業を煮やしたおれは仕事場から自宅にトンネルを掘ることにし、この度ついに開通に漕ぎ付けたのである。その立役者が stone だ。自宅サーバは固定 IP を持っていないので、その点で若干面倒を強いられているが、リポジトリを持ち歩く暴挙に比べれば屁でもない。

以下、その手順のメモ。

1.自宅 ADSL モデムの設定
　→ ポート X へのアクセスはサーバに回す
2.自宅サーバの設定
　→ stone はポート X への接続を ポート 22 に回す
　→ stone はトラブル対策として cron で定期的に起動
3.仕事場マシン設定（常時）
　→ Cygwin の $CVSROOT の設定
　　→ プロトコルは ext
　　→ ユーザ名は自宅サーバのもの
　　→ ホスト名は localhost
　　→ リポジトリパスは 自宅サーバのもの
4.仕事場マシン設定（利用時）
　→ stone はポート 22 へのアクセスを自宅 IP のポート X へ回す

これで仕事場のマシン上の Cygwin から cvs コマンドを発行すると、localhost の stone が自宅サーバのポート X に転送してくれる。そして自宅サーバの stone がポート X へのアクセスをポート 22 に回し、これで仕事場と自宅との間に SSH 通信が確立するわけだ。

不便があると言えば仕事場の stone を起動する際にいちいち自宅サーバの IP を調べて stone.cfg を書き換えなければならない点だが、そのくらいは我慢しなければならんのだろうな。

Persica V0.40 公開

【Persica】

果たして使う使わない以前にダウンロードした人がいるのだろうか。

Persica 改良案

Persica　の今後の機能追加についてつらつらと考えてみた。

0.30 に至ってなお面倒に感じるのは、Recent プラグイン使用ファイル（以下 Recent ファイル）の扱いである。このファイルは、Recent プラグインの機能と目的を考えれば、他に変更されたファイルがある限り、それ自体に変更が加えられていなくても毎回必ず変換しなくてはならない。

しかしながら現時点では、変更されていないファイルを変換するためには -f オプションを指定する必要があり、そうなると全てのファイルが変換されるので、ファイル数が多い状態で特定のファイルに細かい変更を何度も加えることになると、数秒のわずかな待ち時間であっても結構なストレスになるのだ。特に Amazon プラグイン使用ファイルの変換に掛かる時間が馬鹿に出来ない。

当初は最後の最後に -f 指定で実行すればいいと気楽に考えていたのだが、意外に -f 指定実行後に誤字や誤記に気付く（しかもそれを繰り返す）頻度が高いことが判明した。まあ、単におれがそそっかしいだけと言えばそうなのだが、考えてみれば -f オプションは本来スキンファイルに変更が加えられた場合への対応が目的であって、Recent ファイルの面倒を見るには挙動が大袈裟に過ぎる。

では今求められている機能は何か。突き詰めて考えれば、「-f オプションの有無に関わらず毎回必ず変換されるファイル」という概念の導入である。もう少し練りこむと、更に「他に変更の加えられたファイルがあれば」という条件を追加したくなるのだが、そこまで窮屈にしなくても実行時のストレスを軽減する効果は得られると思う。

実装レベルで考えると、変換元のテキストファイル内に常時変換を意味する何らかの記号を記述しても意味がない。変換対象ではないファイルはそもそも内容を走査しないからだ。ここはもちろん $source_dir/.status に書くべきだろう。このファイルには $source_dir 配下の全てのファイル名が記述されている。そして Persica は Recent プラグインに渡す情報を取得するために、起動後まず真っ先にこのファイルを読み込む。これ以上の適任はあるまい。

$source_dir/.status には現在、変換元ファイルの (1) $source_dir からの相対パス、(2) 更新日、(3) MD5値 が記述されている。この末尾に変換種別を示す記号を追加すれば良い。

しかしユーザが $source_dir/.status を直接編集するのは面白くない。個人的なこだわりではあるが、キカイが書いてキカイが読むものに人間が手を加える必要性も権限も認めたくはない。

となると変換種別を人間はどうやって指定するのか。上で「意味がない」と書いたものの、結局のところ、そのファイル自身に記述するしかなさそうである。それが一番簡単で確実なのだ。どんなファイルでも作成時と内容の変更時は絶対に変換される。その際に $source_dir/.status に記録してしまえば何も問題はない。タイトル行の先頭文字で判断するのが分かりやすくて良いだろう。無関係の文字であれば指定なしと判断するわけだ。

最大の難関はその記号を何にするか。おれはネーミングもそうだが、その辺のセンスがまったく欠如しているのだ。

……とりあえず「!」にしとくか。

Persica V0.30 公開

【Persica】

例によって変更点などは付属ドキュメントを参照のこと。

Persica V0.20 公開

【Persica】

変更点などは上記ページか付属ドキュメントを参照のこと。
まあどうせおれしか使わねえし。

一応おれが不便を感じない程度には機能も安定性も充実してきたが、逆に言えばおれがあまり必要性を感じていない「なんとなく」実装した機能はかなりヤバい。気をつけろ。

Net::HTTP

メモ。

Net::HTTP でハマっている。正確には Net::HTTP::Proxy である。いまいち良く分かっていないのだが、どうも start で刺さってしまっているらしく、しばらく待つと Timeout:Error が返って来る。

問題が発生するのは例によって Persica の Amazon プラグイン。しかしテスト（Amazon プラグインのインスタンスを生成して apply_block を呼び出すだけ）を書いて実行するときちんと正常な結果を返すのだ。

……と悩んでいたのだが、ふと思いついて amazon プラグイン使用ファイルだけを変換してみたら問題なし。ならば、とファイル単位でGC.startを実行するようにしたら、案の定、何事もなかったかのように正常に動作するようになったとさ。めでたしめでたし。

バージョン 0.11公開

【Persica】

簡単なものではあるがマニュアルを付けてみた。

プラグインに悩む

PersicaはPukiWikiと同様にプラグインで機能を拡張できる。

プラグインにはインラインプラグインとブロックプラグインがあって、ブロックの方はまあまあ安定したと思う。なにしろ一行にひとつしか書けないから簡単と言えば簡単だ。問題はインラインである。一行に複数書ける上に入れ子も可能でなければならない。その前提でインラインプラグイン記述の抽出処理を考えるとなるとどうしても複雑になってしまう。

さらにはURLの自動リンク機能とインラインプラグインのバッティングが厄介だ。具体的にはlinkプラグインである。これは明示的にリンクを埋め込むプラグインなのだが、プラグインが出力したアンカーのURLに、Persica本体でさらにリンクを張ろうとするので、既にリンク化したURLは無視しなければならないのだが、その判定がまた面倒なのだ。

今考えているのは、プラグイン記述を検出したらパラメータごと退避させておいて、Persica本体側でのURL処理が終わった時点でプラグインの出力と置き換える、という処理なのだが、具体的にどう書くか、じっくり検討している時間がない。

当面のトラブル回避策としては、使用者が極力一行を短く書くようにするしかない。ネストはまあ仕方がないにしても、一行に二つ以上のインラインプラグインが記述されないようにするわけだ。本来ならば使用者が自由に本文を書けるように、システム側で何とかするべき問題であるから居心地が悪い。

おれが何かまぬけな勘違いをしているだけで、実際はずっとシンプルな処理に出来るのであれば良いのだが。