某日記

．RIDS ^*1*2に目鼻が付いたので、 1 年とちょいぶりに日記を書きはじめてみたりして。

．いやぁ、前々から復活しようかどうしようかは 悩んでたのだけど、システム上の理由により共存(謎)が難しかったので RIDS ができるまで放っておいたのであった。

．まだ動きがちょっとおかしいけど、何とか動いてる。 柔軟性と引き替えに速度性能を犠牲にしてるのだが、 なかなかマニアックな仕上りだ。 でも、ソースがちょっとまだこなれてないので、 ちょっと公開は先になると思う。

．マニアックさの一例は、たとえばこの日記のコンフィグファイル：

これはコンフィグファイルであってプログラムではありません :-)。

．こんなコンフィグ、万人向けじゃないよなぁ。でもいいのだ。 こういう超合金合体ロボみたいなシステムを作って悦に入るのも 男のロマンなのだから。 まだいまひとつ機能が少なくてアレなのだが、 柔軟性が高いので、たとえば verbatim の translator を実装すれば上のプログラムコンフィグファイルが カラフルになったりするわけさ。

．あと、理屈では Scheme を差し替えれば HTML に限らずいろんな フォーマットで出力できるはずなのだが、でも、そのためには RuleSet が圧倒的に足りないので、今は単なる HTML ラッパーくらいの 意味しかなかったりして。

．いやまぁ、でも、なんというか、ruby さまさまやね。 こういうのを書こうっていうモチベーションというか勇気を 与えられる言語だよ、ホント。

．昨日はどうやって帰って来たのか憶えてないぞ…。 とりあえず抱き抱きっ(謎)。

．今の RIDS の実装は、日ごとのファイルを読んで daily コンテナに格納し、 これを Translator で(普通は HTML に)変換し、出て来た結果を もう一度 daily コンテナに格納して Marshal::dump して 日ごとにキャッシュしてある^*1。 本当なら変換前にキャッシュしたいのだけど、 どーも parser は大して重くないし、 それと比べて圧倒的に HTML translator が遅いので、 それじゃ使い物になんなかったのであった。

．以前私が使っていた日記システムでは、もともと parse したら片っ端から 出力していて、内部で日記のソースファイル全体を保持するようなことは してなかったのだけども、今回は parser と translator を 分離してある。Translator を分離した理由は、別に roff とか TeX で 日記を出力したいからじゃなくて、同じソースからいろんなブラウザ向けの HTML ファイルを自動生成したい、という昨今の要求をスマートに解決するために 他ならない。つまり、これを活かすには動的生成が不可欠だし、 そのためには今の Translator は重すぎるのね。

．何で遅いのか、というと、多分 cascading なオプション処理を やってるからかな、とか思う。今の configurator の実装では、 コンフィグファイルの Config モジュールをいちいち retrieve してるので、 階層の深いところから浅い所へと遡る処理が非常に重くなりがちなんですな。 よって、この辺を改良しないといけないのだろうな。

．まだ結構実装できてない部分が残っているなあ。 たとえば、過去日記のリストを生成する部分が全く存在しない、とか。

．台所用洗剤 は効果がありますなぁ。うちの妹もゴキブリには滅法弱くて、 その時は私の出番だったり。 そもそも、殺虫剤はどんどんゴキちゃんの方に耐性ができちゃうのだけど、 台所用洗剤は物理的な窒息死なので、あれに耐えられるゴキブリは千年たっても 出て来ないような予感^*1。

．そうそう、ゴキブリ出た時に、殺虫剤無かったんで、 とりあえず制汁制汗スプレーをかけてみたことがあるが、 結構苦しがってたぞ。結局逃げられたので、その後どうなったかは知らないが :-)

．段落の id の生成方法にバグがある。 というか、これ、文書構造の自由度を売りにしている RIDS ではスマートに解決するの難しいなぁ。 というわけで、しょうがないのでとりあえず Section に カウンターリセットを追加。うう。

．どっかの誰かがメーリングリストのメールを携帯電話に 転送してるようだ。どうも、どっかの携帯電話転送用 perl スクリプトを 使って転送してるらしいのだが、エラーメールを読んだ感じだと、 これがむっちゃくっちゃダメ(not 誉め)なソフトのようだ。 なぜ To いじって転送する? recipient を知らんのか? おかげで電話番号がどどバレだぞ。 Subject はコードが変だし、そもそも俺にエラーを戻すなって。 まあ ML にリターンメールがポストされなかっただけ この人は好運だったと思うけど。 SMTP と RFC822 を知らずにこんなソフト書くなっちゅーねん。

．マスコット。ぎゃははは、これ McKusick さんに 怒られるような気がするな^*1 :-)

．ちうことは、やっぱり libc も含めて移植せねばなるまい :-)

．今週末は、某 n の l の原稿を書かんといかん。 raw デバイス。 まあふつーの UNIX でもそうなんだけど、 Linux の raw デバイスは要は strategy に read/write を丸投げ してるだけ。 でも Linux の raw デバイスは

1. util-linux の raw(8) を使って動的に割り付けられる。
2. メモリがブロックサイズで align されていないといけない。

という点で微妙に異なっている。 前者はともかく後者はすごく疑問だなぁ。

．ま、ちょっとデザインが変だけど、 これで Linux もふつーの UNIX に一歩近付いたというわけだ :-P

．具体的な話は避けますが。

．なるほど。車輪の再発明が何故戒めの対象になるのか。

1. それは、多くの場合従来からある車輪に対する誤解からはじまる。
2. えてして、従来の車輪の発展途上のものがでてくる。
3. 往々にして、従来の車輪の発展過程で起こった失敗を繰り返す。
4. なんといっても、なまじ動くものが容易に作れてしまうため、 従来の車輪と無用の競合を引き起こすことがある。

．これらの性質は、えてして、実際に見えている以上の労力の浪費を 引き起こすから質が悪い。 よって、何か従来のものの代替物を作る場合には、 「なぜそれが必要なのか」という「必然性」を示す必要がある。 でも、車輪の再発明というのは、往々にして上の 1 から 始まっているため、「利点」を示すことはできても、 「必然性」は示せないんだな、これが。 で、「必然性」が示せないときに、再発明した側がどういう態度を 取るかによって、結末はいろいろと変化する。

．回り始めてしまった車輪は、もうどうやっても止まらない。 回り始める前に壊さなきゃいけなかったのだ。 しかしながら、それは結果論なので、もはや言ってもしかたがない。 重要なのは、「回り始める前に壊す」ということを、将来似たような 事例で起こりつつある場合に、どう実践すればいいのか、 ということだと思う。しかしながら、これは難しい。 多くの場合、それは不可能なんじゃないか、とすら思う。 結局、教訓になりうるとすれば、 「再発明してしまった落し前をどう付けるか」 という部分の教訓だけだと思うのは私だけかな。 しかしながら、その教訓を得るのは、えてして、 再発明した側ではなくて、再発明によって迷惑を被った方の側だ、 というのが皮肉なものよ。

．最近、「newconfig が採用されずに new-bus が採用された経緯」に関して、 newconfig メーリングリストで話されています。 感情的な部分は抜きにして、どういう流れで new-bus が採用されたか、 という「歴史」を知っておくことは、開発者だけではなく利用者にとっても 大切な事でしょう。というわけで、ポインタだけ示しておきます：

• newconfig-jp メーリングリストのアーカイブ

．教訓ネタをもう一つ。

．日記を書いてなかった間に、非常に強く印象に残るほど大爆笑だったのが、 何ヵ月か前の某 users メーリングリストで出てた、 某お子様対応ネタだな。ま、あれは起こるべくして起こった 人災なので同情しないけど、でも、教訓としては興味深い。

．まあ、お子様対応してしまう会社は(以下略)として、あそこで気になったのが、 「ろくすっぽ貢献してないくせに、えらそうな事を言うな」 って旨の発言ね。ほら、そういうことを言ってるから勘違いヤローの集団だ、 って言われてしまうのだよ。本当のハッカーは、手柄を誇ったりはしないし、 他人に貢献を強要したりもしないもんですよん\ 。