しっぽのさきっちょ 2004年01月

今年も無事に年が明けました。 本年もよろしくお願いいたします。

早速ですが， ツッコミでのらDJさんよりインタビュー記事を紹介していただきました。

• お話聞きました・・・dkexさん編

「CCは看板つけただけみたいな感じ」 ってのは私も「言い得て妙」だと思った。 ここでは何度も書いてるけど， CC/CCPL に欠如しているのは（インフラを備えた）アプリケーションだと思う。 まぁ， でも， これからこれから。 新年早々ヤボは言うまい。

そうそうインタビューのお相手の dkex さんの Weblog も色々参考になる。

• RedDustRec :: weblog

「スゴいカウンタ」がぶっ壊れてるぢゃん。 アカウントまで消されていた。 何やってンだか。 再登録しろだとぉ！ 客をなめてるのか？

取り敢えず再登録したけど， 乗り換えた方がええかしらん。 カウンタもリセットしちゃったし。

「忍者TOOLS」のアクセス解析に乗り換えた。 運用についてはプライバシー・ポリシーを参照のこと。 もともとアクセスカウンタにはあまり興味がなかったので， これでもいいや。

突然でゴメン。 しかし （解析データが消失するのは無料サービス故に仕方がないかもしれないが） アカウントまで消され無かったことにされるのは， エンジニアの端くれとしてサービスそのものの運用に疑いを持たざるを得ない。

CeM をはじめ「二次的著作物」に対する面白い議論が色々あって， 私も少し書いてみたいのだが， その前に私の公開する拙文に対するライセンスについて私の考えを少し述べておこう。

私は CCPL を設定可能なコンテンツに対してはなるべく "by" ライセンスを設定するようにしている。 理由は単純。 CCPL のオプションの組み合わせのうち "by" が著作者によるコントロールが最も緩いライセンスだと思うからだ。 本家アメリカで著作者によるコントロールが最も緩いのは「パブリック・ドメイン」だが， 日本には「パブリック・ドメイン」という概念がない。 日本においては「著作物」は必ず特定の「誰か」に帰属するよう法的コードが設計されているのだ。

ある作品が誰にも属さない「パブリック・ドメイン」であり続けるためには， その作品が「パブリック・ドメイン」であることを公に示し保証する「システム」が必要である。 作品を作った人が「これはパブリック・ドメインだよ」と宣言するだけではダメなのだ。 だって作品が「パブリック・ドメイン」であるということは作品の作者にも属さないことを意味するから。 この件に関連する最近の例としてはギコ猫の著作権問題がある。

もし作品を「自由な流通と消費」のもとに置こうと考えるなら， 作品の帰属先（著作者）を明示し， その上でコントロールの範囲を宣言する方が合理的だ。 手綱を緩めるだけならいいが， 完全に放してしまったら， いずれ「それ」は他の「誰か」が掴んでしまうことになる。

しかし私自身に関しては "by" ライセンスをガチガチに運用する気はない。 運用ポリシーで 「再配布・再利用にあたり事前・事後の連絡も不要」 と明示しているのはそういうニュアンスも含んでいる。

余談だが， Syndic8.com という検索サイトがある。 ここでは RSS の内容ごとにコンテンツを分類して検索できるようになっている。 もちろん CCPL のライセンス種別ごとに検索することも可能だ。 これを見ると by オプションを含むライセンスを採用しているコンテンツは CCPL を採用するコンテンツ全体の 95.2% になっている。 （『iNTERNET magazine』 2004年2月号の特集記事で示された数値はこれのことかな？ − 特集記事で出た数値は独自のものらしい）

さて， Syndic8.com による統計を見ると， sa オプションを含むライセンスは 49.3% と約半分， nd オプションを含むものは 36.0% だ。 微妙な数字だが nd オプションの需要は意外に多いように思える。 （ただし，おそらくサンプルは Weblog に偏っているだろうから，そのまま鵜呑みにしてはいけない）

nd オプションを採用しているからといって派生を完全に禁止しているわけではない。 「派生作品を公開したいなら個別にオリジナルの作者と交渉しろ」ということである。 「交渉」することに積極的な運用を作者が行っているなら FlowerLounge さんが書かれたような派生の許可の仕方もできるのではないだろうか。

sa オプションについてだが， 以下の記事が参考になるだろう。

• 「K’s Diary @ hatena」 11/21 の記事

sa （Share-Alike）は明らかにフリーソフトウェアにおける「Copyleft」の思想を受け継いだものだ。 しかし「Copyleft」は諸刃の剣である。 いったん「Copyleft」宣言された作品はその枠組み内でしか派生を許されない。 sa を含む CCPL ライセンスも同様だ。（ただし CCPL の場合は「交渉」の余地がある）

私が気にするのは 「sa オプションを含むライセンスは利用者にとって本当に使い勝手のいいものだろうか」 ということだ。

二次的著作物を作るとき， オリジナル作品の利用の仕方には大きく2通りあるように思う。 ひとつはパロディ作品のような「オリジナルからの派生」として作る場合。 もうひとつはオリジナルを「素材として再利用」し自作品に取り込む場合。

前者の場合， 派生作品群を sa オプションを使って連鎖させることは意味があるように思える。 しかし後者の場合は sa オプションはかえって足枷になるのではないだろうか。 面倒なのは素材として公開したつもりはないのに作品（の一部）を素材として再利用されてしまう場合である。 格好の例は拙文「「クリエイティブ・コモンズ」について」だ。 この中のライセンスオプションの一覧表はおかげ様でいろいろな場所で再利用されているが， もしこの拙文のライセンスを "by" ではなく "by-sa" などにしていたら再利用しづらかったのでは， と想像する。

個人的に思うのだが， sa オプションを含むライセンスで派生作品群を構築したいなら， CCPL の上位レイアに何らかのフレームワークが必要になるのではないだろうか。 例えば「Copyleft」を組み込んだ GNU/GPL の場合， GNU やフリーソフトウェアという大枠が存在していたからこそ巧く機能したのだと思う。 そういう意味で CeM はちょっと面白いと思っている。 昨年末に CeM のドラフトが公開されたが， 単なるライセンスを超えたもう少し大きなフレームワークが見えるような気がしたからだ。 （もちろんそれは気のせいかもしれない。 まだ細かく読んでないのだ。 ゴメン）

私がこれから考えていきたいのは「素材」としてのコンテンツ群をライブラリとして集積することと， 集積したライブラリを「再利用」するための検索インタフェースだ。 エンジニア的発想かもしれないが需要はありそうな気がする。 ただしソフトウェアのライブラリとは違い （以前にも書いたとおり） 「もの」だけが流通するシステムでは破綻してしまうような気がする。 そこをどうするかだよな。

昨年は実家（松江）に帰らなかったので二年ぶりの初詣だった。 初詣は実家の氏神様へ。 そういや熊野大社には何年も参ってないなぁ。

クリスチャンな方もおられるでしょうから一応解説しておくけど， ここで言う「神」様は「God」ではない。 中国や日本などにとって「神」という存在は「God」ほどのことはない。 中国じゃ神は「仙人のなりそこない」だしねぇ。

話がそれた。 で， うちの氏神様というのがちと変わっていて， 三神二社なのだ。 しかも， 一つめの社には事代主命と木花咲耶姫が， 二つめの社には猿田彦命が祭られている。

ひとつめの福富神社の由来はよく分からない。 起源はそうとう古いという話もあるが， もしそうなら祭られている神様は明らかにおかしい。 何故なら二神とも厳密には出雲の神様ではないからだ。

事代主命は大国主命と三穂津姫命（木花咲耶姫）の間の御子神で「国譲り」神話の主役である。 島根半島の東端にある美保神社にも二神が祭られている。 結構あるのかな， このペア。

猿田彦命が祭られている貴舟神社は少し分かりやすい。 猿田彦命は「国譲り」神話にも出てくる神で水先案内人（または道祖神）としての性格が強い。 貴舟神社のあるあたりはかつて船着き場だったそうだ。 神社の名前や祭られている神様はそこに由来しているらしい。 これに関連する話は「忌部惣社神宮寺縁起」に書かれている。

大国主命は記紀での呼び名で「出雲風土記」では大穴持命と呼ばれている。 というより「出雲風土記」の大穴持命が記紀における大国主命と同一視されているというべきだろうか。 「出雲風土記」は他の風土記とは性格が異なる。 他の風土記は中央から派遣された国司が編纂しているが， 「出雲風土記」を編纂したのは在地の権力者である出雲国造（今でも子孫が出雲大社におられる筈）である。 従って記紀と「出雲風土記」との矛盾点も多い。

例えば記紀では大きな存在感を持つ素戔嗚（須佐之男）命だが， 「出雲風土記」では須佐能袁命は重要な神話にはほとんど登場しない。 例えば「八雲立つ」といったのは実際には八束水臣津野命（「国引き」神話（記紀にはない）の主役）だし， 八岐大蛇退治の話なんかそもそも存在しないのだ。 もちろん大穴持命や八束水臣津野命との関係もない。

八岐大蛇退治や「国譲り」神話に似ていると言われる話は大穴持命による越の八口平定のくだりにあるが， あまりに内容が違い過ぎる。

出雲には四大神二大社がある。 すなわち， 佐太大神，野城大神，熊野大神，そして大穴持命だ。 熊野大神がおわすのが熊野大社， 大穴持命がおわすのが杵築大社（出雲大社）である。 名前を見ると分かるが大穴持命のみ命（みこともち）であり神格としても熊野大神より下である。（従って地元民は出雲大社ではなく熊野大社に参る） ちなみに佐太大神と熊野大神は天神であるが（野城大神は不明）， 大穴持命は地祗である。

しかし「出雲風土記」における大穴持命のウエイトは圧倒的だ。 というより「出雲風土記」は大穴持命とその御子神たちの神話集だと言ってよいだろう。 他の三大神は名前と地名に深い関連があり， 在地で信仰されている神であるといえる。 特に熊野大神は「令義解」においては「出雲国造斎神」と呼ばれており， 「出雲風土記」の編纂者で出雲の権力者でもあった出雲国造の信仰する神である。 （大穴持命は「令義解」では出雲大汝神と呼ばれている）

これで出雲四大神の関係が分かるだろうか。 杵築大社のある出雲郡は出雲国造によって最後に併合された土地である。 ここで出雲国造は住まいを熊野大社のある意宇郡から出雲郡に移し， 大穴持命を「所造天下大神（天の下造らしし大神）」としてまつりあげ， 他の三大神のおわす土地も併せて治めようとしたのである。

つまり佐太大神，野城大神，熊野大神の三大神は「祭りごと」の神であり， 大穴持命はその三大神をも統べる「政（まつりごと）」の神なのである。 人間で言えば天皇に対する摂政のような関係だろうか。 これは大国主命（大穴持命）が縁結び（つまり人事）の神様であることからも分かるだろう。 （そういえば， 大穴持命の話には各土地の女神に求婚する話が多い。 ギリシア神話のゼウス神みたく「たらし系」だったのね）

余談だが， 出雲大社にカップルで参ると破局するという地元では有名なジンクスがある。 縁結びをお願いする方やお礼参りをする方はお気をつけを。

...あぁ， 長い戯れ言を書いてしまった。 でもいっぺんちゃんと書きたかったのよ。 「出雲」を「神話の古里」とか言って無理矢理ロマンチックに語ろうとする言説にはいい加減ウンザリしている。 あと記紀を無理矢理こじつけた「出雲神話」を語ったり， 酷いのになると卑弥呼と関連づけようとしたりとか。

「出雲風土記」ってのはもっと人間臭くて生々しいものなのだ。 実家の近所で弥生から古墳時代の遺跡とかがよく発掘されるけど， 矢じりで背骨が傷ついてる遺体とか沢山の武器とか戦争の匂いがプンプンする生々しいものも出てくるわけよ。 今の私達の「クニ」は数えきれないほどの民族・部族・部落の屍の上に築かれていることを忘れちゃいけないし， 私達はそういうものを繰り返して「生き延びてる」ことも忘れちゃいけない。 そういうものをスポイルして「神話」を語ってもまるで説得力がないぞ。

行きつけのお店（酒肴）より年賀状をいただく。 なんと Web サイトがあったのか。 気がつかなかった。 このお店に通うようになってからお酒の銘柄がおぼえられなくなってねぇ。 「中三郎」とか有名なやつならいくつかおぼえてるんだけど。

で， 先日帰省した際に「たまには自分でお酒を買ってみよう」と思って店頭に並んでるのを見て驚いた。 ラベルに「原酒」とか「吟醸酒」とか書いてるのにアル添なのよ。 いや， まぁ， 「吟醸酒」でアル添とかいう間抜けなお酒は時々見るけど， 「原酒」でアル添はないだろう。 意味ないぢゃん！

もちろんアル添が絶対ダメというわけじゃない。 ブレンディングによってはアル添でも美味い酒はある。 旭菊水の本醸造とかね。 酒問屋経由の日本酒ってのは味を一定にするためにたいがいブレンディングしてるっていうし。 でもラベルに「原酒」とか「生酒」とか書いてあったらブレンディング前だと思うじゃん， 消費者の心理として。

もう，すっごい騙された気分。 これから酒屋で日本酒買う気しないよなぁ。 何が入ってるか分からん。 これじゃそのうち本当に「日本酒」は滅ぶぞ。 大好きなのに。

原則として純米じゃないお酒は「日本酒」を名乗るべきじゃないよなぁ。 ブレンディングした「原酒」とか「生酒」も反則。 ビールだって「ビール」と「発泡酒」の区別があるんだから， 名前を変えてブレンディングの技で真っ向勝負して欲しい。

（日本酒を含め）醸造酒ってのは毎年味が違ってて当たり前なんだから， 買う方もおかしいと思わなきゃ。 ワインだって「○×年もの」とかあるじゃない。 日本酒の古酒は抜群に美味いぜぇ！

そうそう， 結局そのときはお神酒用に「月山」の純米酒を， そしてＫＢ！さんへのお土産には「國暉」の山廃仕込み原酒（もちろん純米）を買った。 もっともＫＢ！さんは二日酔い中で結局飲めなかったみたいだけど。 月山は甘口（月山って辛口じゃなかったっけ？）で國暉は若干辛口。 どちらも柔らかい味で日本酒に慣れてない人でもぐいぐいいけるだろう。

というほどのことはないんだけど... 最近の GnuPG は暗号化パケットに MDC を含める形式をデフォルトにしてるんだけど， --openpgp オプションを付加するとそれが無効になっちゃうというお話。

BkGnuPG のユーザの方から， 復号時に 「WARNING: message was not integrity protected （メッセージの完全性は保護されていません）」 というメッセージが出るという指摘を受けてちまちまと調べていたのだが， どうも --openpgp オプションを付加すると怪しい動きになるようだ。 BkGnuPG では， 設定で「OpenPGP に準拠した署名・暗号化を行う」をチェックすると署名・暗号化時に --openpgp オプションを付加するようにしている。

最近の GnuPG は暗号化時に MDC （Manipulation Detection Code）を付加するようになっている。 これを解除するには --disable-mdc オプションを付加しなければならない。（強制する場合は --force-mdc オプションを付加する） MDC を含む暗号化パケットは RFC2440bis （現在ドラフト段階）で Tag 18 （Symmetrically Encrypted and MDC Packet）として定義されているが， 現行版の RFC2440 には存在しない。 --openpgp オプションは（RFC2440bis ではなく） RFC2440 に準拠するようになっているため， MDC を付加しないのであろう。 この点について GnuPG のマニュアルには全く言及がないため気付くのに時間がかかってしまった。

ちなみに， 以下のように --openpgp と --force-mdc を並べて記述しても MDC は無効になる。

> gpg --openpgp --force-mdc -r spiegel@alles.or.jp -ea hoge.txt

かなり切ない。

暗号化パケットに MDC が必要なわけは一昨年のこの記事を読めば分かるであろう。

• PGPに理論的セキュリティーホールが存在、“ごみメール”には注意を

BkGnuPG に関しては， リリース当時に比べ GnuPG のオプション構成がかなり変わったのに全く追いついてないのが現状。 例えば動作モードも --rfc1991 と --openpgp 以外に， --rfc2440 （今のところ --openpgp と同じ）， --pgp2， --pgp6， --pgp7， --pgp8 ， --gnupg がある。 「サポートしなくちゃ」とは思うのだが， もうあのリソースファイルを弄りたくないんだよなぁ。 GPGrelay みたいに言語依存の部分を外出しにするとかしないとダメかなぁ。

nDiary に付属している rss.rb フィルタを弄って FoaF 情報を埋めこむようにした。

具体的には dc:creator の代わりに foaf:maker を使い rdfs:seeAlso で実際の FoaF ファイルにリンクするようにしたもの。 ndiary.conf で「FOAF_MBOX_SHA1SUM」と「FOAF_RDF」を定義すると FoaF 情報を埋めこむ。

FOAF_MBOX_SHA1SUM = 'fac755580a8e6edb5314a2b267ed60018a5366bc' # FoaF mbox_sha1sum 要素
FOAF_RDF          = 'https://baldanders.info/spiegel/profile/foaf.rdf.xml' # FoaF ファイル

上記の定義がなければ今まで通り。

うちのページの場合， FoaF Explorer でみるとこんな感じになる。 フィルタプログラムもアップしておくのでお好きなように使ってください。

なんか最近そゆのが流行ってる風味なので真似してみた。 「FoaF って何？」って方は以下をご参考に。

• メタデータによる知人ネットワークの表現
• FOAF-a-matic -- RDFを使って自己紹介してみよう

• 句読点の使い方 / 読点（、）はどこに打つか？句読点の使い方２

あっ面白そうな話題。 つっても「読点はどこに打つか？」という話はパスだな。 耳が痛すぎて (^^;)

前にも書いたことがあるような気がするが， 私は異常に読点が多い。 これは句読点の入力するタイミングで漢字変換するように IME を設定しているから。 気をつけるようにしてるんだけどねぇ。 ついそうなっちゃうときがある。

もうひとつ， 括弧類が多いのも問題。 これは直らないだろうな， きっと。 理由は分かってる。 頭の中で考えたことを文章に変換する「シリアライズ」に失敗すると異常に括弧類が多くなるのだ。 特にここの「戯れ言」は括弧を多用する傾向がある。 仕様書とかの技術文書じゃそういうことは少ないんだけどねぇ。 まぁ， 書く内容なんて決まりきってるし， それこそテンプレート文章に単語を当てはめていくだけの作業がほとんどだもんな。

文体の既定は（つまり客から特に要求がなければ）「ですます調」だ。 手書きでドキュメントを書いていた頃はそうでもなかったが， ワープロ／TeX を使いだしてからは自然に「ですます調」になった。 「である調」で書くのは特定の「読み手」を意識しない時かな。 ちなみに， ここの「戯れ言」は「「読み手」を意識しない」スタイルを意識して書いている。 「銀河通信」ってやつですな。

句読点は「，。」の組み合わせを使う。 横書きに限れば句読点は「、。」でも「，。」でも「，．」でもよいとされている。 ただし JIS の規格書の多くは「，。」を採用しているそうだ。 まぁこれも文体と同様「お客さん」次第なんだけどね。

そうそうリーダ。 私は半角のピリオドを三つ繋げる「...」書式。 英文タイプライタの入力方式やね。 文字の「…」はどうも慣れない。 つか，通常の文章でリーダの類いは使わないからなぁ。 数式表現ではよく使うけど。 TeX なら \ldots または $\cdots$ を使う。

ダッシュは難しい。 ハイフンも含めると英文では3種類かな。 ハイフン「-」とNダッシュ「--」とMダッシュ「---」。 日本語ではいわゆる倍角ダッシュ「−−」が多いか。 ハイフンは別として， ダッシュは使いどころが難しいよね。 使わないですむのなら使わない方がいいと思う。 「括弧類の多用」と同じくヘタに使っても読むリズムを崩すだけだし。

上記でダッシュをいくつか書いたけど， この表記はタイピング上のお約束に過ぎない。 文章作成時に「−−」と書いておけば組版時に二文字分の長さのダッシュ記号に置き換えてくれるということだ。

よく言われるのが単語や文の間の空白文字の数だ。 英文タイプでは文の切れ目を分かりやすくするため， 単語間は空白をひとつ分，文章の間は空白をふたつ分以上入れる。 もちろんこれも単なるお約束だ。 だって「省略」の意味のピリオドと「文末」の意味のピリオドがとっちらかったらマズいでしょ。

日本語の組版の場合「？」や「！」の後ろは一文字分空ける。 句読点の後ろは二分空きだ。 ただし約物が並ぶ場合は例外。 詳しくは JIS 規格書（JIS X 4051）を参照のこと。 pTeX ならこの辺の空きの処理を自動でやってくれるけど Web ブラウザでやってくれるのは見たことない。

「空き」と「空白文字」は意味が違う。 空きがいるからって空白文字を入れれば組版のバランスが崩れる。

英数字に全角と半角のどちらを使うのが見易い （そういえばうちの田舎では「簡単だ」という意味で「みやすい」と言う） かというのは， 突き詰めて考えれば書体と組版の問題だったりする。 pTeX で使われる手法だが， 日本語と英数字が混在する場合は， 英単語（または数字列）の前後にほんの少しだけ空き（pTeX では四分空き）を作った方が見た目がよくなる。 しかし pTeX 以外の組版処理系でこういうことを自動的にやってくれるものをあまり見たことがない。 大抵文字間を無理無理に詰めてしまうので英数字に半角を使うと酷く窮屈に見えてしまう。 で， 全角の英数字というのはその点上手くできていて， 普通に並べてもちゃんと空きができるようにメトリックが設計されているのだ。 ただし全角の英数字を並べると逆に文字間の空きがあり過ぎて間抜けに見えてしまう。 もちろんこの場合， 最終的にどう見えるかは選択する書体でも変わる。

Web ブラウザなんか典型的だが， 「文章を読む」ことに関して巷のドキュメントツールはユーザとの親和性が低いような気がする。 日本語の組版技術は， 欧米ほど歴史は古くないかもしれないが， それなりに完成されたものだし JIS 規格にもなっている。 人間はコンピュータのようにノイマン方式でインストラクション単位で文章を読むわけではない。 文字や単語や文や段落などの位置関係の全体を見て文章の構造を把握するのだ。 WWW や Web ブラウザが世に出てから随分経つのに何故日本語の組版に最適化された製品が出ないのだ。 日本語にあわせた組版ルールを持ったブラウザがあれば， 書き手はそれに合わせたタイピングを行うだろうし， 読み手は書き手の怪しいタイピングルールを「解読」しなくても自然にストレスなく文章を読むことができる。 そういうものを誰か作ってくれ！（TeX 以外）

kayakaya さんの日記で署名・暗号化メールの互換性について書かれてたので， PGP と GnuPG の互換性についていくつか挙げておく。

なお PGP はいくつかのバージョンがあるが， ここでは PGP 6.5.8 をベースに書く。 PGP の最新バージョンは 8.0.3 だが私は持っていない。 あしからず。

まずひとつめは， 使用するアルゴリズムの違い。 オリジナルの PGP 6.5.8 は使えるアルゴリズムが少ない。 対称暗号は CAST5， ハッシュは SHA-1 で決め打ちといっていい。 ただし ckt 版の最新ビルドでは GnuPG でサポートするアルゴリズムはほぼ使える。 ckt 版 PGP 6.5.8 の日本語版もあるので， そちらを使った方がいいだろう。 GnuPG 1.2.4 で使えるアルゴリズムは以下のとおり。

> gpg --version
gpg (GnuPG) 1.2.4
Copyright (C) 2003 Free Software Foundation, Inc.
This program comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to redistribute it
under certain conditions. See the file COPYING for details.
 
Home: ********
サポートしているアルゴリズム:
公開鍵: RSA, RSA-E, RSA-S, ELG-E, DSA, ELG
暗号: 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH
ハッシュ: MD5, SHA1, RIPEMD160, SHA256
圧縮: 未圧縮, ZIP, ZLIB

一方， PGP 6.5.8 ckt - Build:08 では対称暗号として IDEA が使える（GnuPG では外付けする必要あり）他， ハッシュアルゴリズムとして SHA512 まで使用可能（ただし DSA 署名では SHA-1 まで）だ。

ふたつめは電子署名パケットのバージョンだ。 OpenPGP では旧来の v3 パケットと新しい v4 パケットが定義されているが， PGP は v4 パケットを解釈できない（PGP の 7 以降で v4 パケットに対応しているかどうかは不明）。 ただし ckt 版の最新ビルドなら解釈可能。 GnuPG で強制的に v3 署名を行うには --force-v3-sigs オプションを付加する。 （BkGnuPG では「PGP 互換の署名・暗号化を行う」をチェックすれば自動的に付加する）

そしてみっつめだが， これは PGP/GnuPG の問題というより， それを利用するメールソフト（MUA）の互換性の問題といっていいだろう。 Sylpheed や Thuderbird+Enigmail のような最近の MUA は GPGME （GnuPG Made Easy）を組み込んでいる。 GnuPG の操作は全てこの GPGME 経由で行われるのだが， どうもこの構成の MUA は署名を canonical text mode で行っているようだ。 しかしこれでは PGP との互換性が取れない場合がある。

PGP/GnuPG の電子署名にはテキストモードとバイナリモードがある。 最大の違いはテキストモードでは署名前に「正規化」を行う点である。 具体的には改行コードの統一と行末スペース（改行コード直前の空白文字）の削除だ。 Sylpheed や Thuderbird+Enigmail では， おそらくマルチプラットフォームを意識して， テキストの正規化を MUA ではなく GnuPG/GPGME 側に任せているようである。

GnuPG は分離署名でもテキストモードとバイナリモードを選択できるが， PGP で分離署名を行う場合には必ずバイナリモードになる。 従って PGP/MIME 形式の署名付きメールを作成する際， GnuPG のテキストモードで署名してしまうと， 受け取る側が PGP だった場合に検証が NG になる可能性がある。 逆に送信側が PGP で署名した場合， 受け取る側がテキストを正規化せずに検証を行うと NG になる可能性がある。

PGP との互換性を考えるのなら安易にテキストモードで署名・検証を行うのは危険だ。 しかしそうなると署名・検証前に行うテキストの正規化を MUA で行う必要があるため処理が面倒になる。 テキストの正規化については RFC3156 に書かれているが対応している処理系はまだ少ない。 ちなみに拙作 BkGnuPG も厳密には対応していない。

WWW や Web ブラウザが世に出てから随分経つのに何故日本語の組版に最適化された製品が出ないのだ。

と書いたらツッコミで紹介していただきました。 感謝。

• T-Time

でも， 早速試してみようと思ったら... なんで QuickTime が必要なの？ 入れてないってば， そんなもん。 がっかり。 QuickTime は変な音源デバイスを入れようとするから嫌いなんだってば！

「FlowerLounge はてな版」 1/10 の記事経由：

• 私見ですが、文章中に読点（、）を多くうつ人は精神に障害を持つ人が多いと思います。そこで文体の癖を心理学的に解説しているサイトをご存じの方があればご教授願います。

って， 私のことかい！ つか， ノーマルである事にどれほどの意味があるんだ， と嫌味のひとつも言いたくなる。

根拠の有無に関らず言動をノーマルとアブノーマルに分類し， 自分がアブノーマルに入っていないというお墨付きをもらうことで安心感を得る。 こういう行動が顕れること自体アブノーマルの兆候なんじゃないのか？

やはり世界はよりセキュアな（つまり「心配」のない）システムを欲望しているのか。 セキュアへの欲望は再帰的に駆動する。 まるでファンタジー末期にあらわれたファンタジーを欲望する「はてしない物語」のように。

ここにある記事の最後にあるクイズ， 私も分かったけど敢えて書かない事にする。 「Google 八分」されたくないし。

• 読者調査結果 第9回 現場に見る.NET開発の浸透状況とは？

この手のアンケートはどうしても偏りが出るので鵜呑みにできないが， 少なくとも昨年の今頃に比べれば .NET は「現場に降りてきた」実感がある。 実はある案件で悩んでるのよ。 ASP にしようか ASP.NET にしようか。 気持ちとしては ASP.NET にしたいのだけど...

Java が単なる言語を超えた「プラットフォーム」としての地位を固めつつあるように， .NET も言語面から評価すると評価を見誤る。 これは WinFX の登場をもっていよいよ確固たるものとなるだろう。 それまで Microsoft 製品が市場に支持され続けていればの話だが。 これからは Windows プラットフォームで Java という選択はないような気がする。 （もちろんスタンドアロンのアプリケーションは別の話。 あと組み込み分野もね）

• オリコン→アマおめ→メタ多様化
• 米VeriSign、EPCglobalが推進するRFIDの“ルートサーバー”を運用

両者の記事は一見無関係にみえるが， 「多様化」をキーに読んでいくと同じ問題を異なるフェーズで扱っているに過ぎないようにみえる。

Google や Amazon が提供するサービスは「フィルタリング」サービスだ。 （扱うものこそ違っているが）ネット上の膨大な情報を独自のロジックでフィルタリングしユーザに照会するサービスだ。 そしてフィルタリングではじかれた情報は（そのユーザにとっては）「存在しない」ものとみなされる。 フィルタリングのパラメータを変えることでユーザ毎に個別のインタフェースを提供しているように見せているが， それはあくまでも「見た目」の問題に過ぎない。 バックグラウンドの「知識」はあくまでも中央集権的に管理されている。

しかしこのようなシステムはニーズがある。 一元管理された「知識」を共有しつつもインタフェースによる「かりそめの個性」を与えられることによって， ひとは「大きな物語」を疑似体験しているのかもしれない。 このシステムの脆弱性は明らかだ。 何しろ「かりそめの個性」の首根っこは他者（サービスプロバイダ）によってはじめから押さえられているのだから。 サービスが提供しない「知識」は（実在しようとしまいと）存在しないものなのだ。 クローラを拒否したり「Google 八分」されたコンテンツは Google 上には存在しない。 Amazon がわいせつ本を扱わないと言えば Amazon からその本を買うことは絶対にできないしお薦めリストにも乗らない。

EPC ネットワークの ONS は上記の場合とは逆に「知識」とインタフェースを過剰にリンクする。 端末となる RFID は様々なものに取りつけられ多様なインタフェースを見せるが， その管理は完全に一元化されている。 一元化されているということは検索（＝フィルタリング）も容易であるということだ。 「固有 ID」がプライバシー問題とリンクするのは， バラバラの個人情報が「固有 ID」をキーにデータベースをまたいで結合される場合だが， ONS はまさにそのようなシチュエーションを支援するシステムとして機能することになるだろう。

「知識は金なり」の時代だから， 知識が一元管理され独占が進んでいくのはむしろ必然的な流れだろう。 しかし， もしそのような独占から逃れたいと思うなら， もし与えられた「かりそめの個性」にかけられた首輪を外したいと思うなら， 知識をできるだけ分散しそれを扱うシステムも多様化させるしかない。

PKI もそう。 X.509 ベースの一元管理されたシステムより OpenPGP のようにユーザ毎に「信頼」を分散させた方がうまくいくこともある。 どちらが優れているとかいう話ではない。 常に「逃げ道」や「代替え手段」を用意し， 何時でも鞍替えできるように日頃から準備を怠らないことが「賢いユーザ」の振る舞いである。 もちろんそのためには多様化された（インタフェースではなく）システムが選択可能であることが必要条件だが。

メールソフト（MUA）やテキストエディタは「文房具」といって差し支えないだろう。 だから100人100様の「好み」がある。

私のメインプラットフォームは W2K なので， 「文房具」も当然 Windows 用のツールになる。 で， 困ったことに私は「秀丸」がないとモノが考えられない。 んでもって「Becky!」じゃないと山ほどのメールを処理できない。 しかしこれは必ずしも「秀丸」や「Becky!」が優れていることを意味しない。

そういえば， 私の「秀丸」はキーアサインをバリバリにカスタマイズしているのだが， 知らずにそれを使った人が「なんじゃこりゃ！」状態になってしまったことがあった。 キーアサインは大事だ。 私のコーディング・スピードは明らかに「秀丸」のカスタマイズに依存している。（私は素の「秀丸」を使えない） しかしそれは「私は特定の道具に対する依存度が高い」というだけに過ぎないのだ。 だから私は私の使っている「文房具」を他人に薦められない。

Becky! は MUA として高機能なんだろうか。 プラグインを外した「素の Becky!」はそれほど高機能ではないような気がする。 SSL にも対応してないしね。 好みのプラグインをいくつか組み込んだ上で他の有名 MUA と比較になるかどうか， というところではないだろうか。

私が Becky! を凄いと思うのは機能ではなく Becky! を支えるユーザ層だ。 何せ Becky! のユーザは世界中にいる。 BkGnuPG のようなマイナーなプラグインですら， イギリス，ドイツ，フランス，ロシア，韓国，etc. とあらゆる言語圏から問い合わせがやってくる。 ドイツ語版の Becky! のサポートページなんかすンごいカッコいいもんね。 そうそう， 日本語圏なら「Becky! JIS X 0213 プラグイン」なんてものもある。

こういう風にユーザが勝手にコミュニティを広げていって勝手にプラグイン・ソフトを作って拡張して... という動きが（どういうわけか）いい方向にまわっているのが Becky! の魅力のような気がする。

...ありゃ， 文房具の話から外れてしまった。

Becky! 用の spam フィルタプラグイン「BkASPil」が， ベイジアン・フィルタを組み込んだバージョンをα版として公開している。（厳密にはα版という個別のモジュールがあるわけではないのだが）

テスターを募集しているので私も参加して試してみることにした。 α版なので色々面倒臭いのはご愛敬としても， メール受信が劇的に遅くなるのには参った。 私だけなのかなぁ， これ。 非力なマシン使ってるからなぁ。

効果はまだ見えない。 IPBL を使ったフィルタリングの方が大きく効いてるし。 まぁノンビリとやるとしますか。

やはり MUA 側にフィルタリング機能を付けるのはあまり賢くないかもしれない。 だからといって POPFile を使う気はさらさらないが。（メールをリレーするツールは既に GPGrelay を導入してるし）

ちなみに私は ISP が spam やウイルスメールをフィルタリングするのには反対だ。 フィルタリング機能を完全にユーザに解放しコントローラブルにしてくれる（そしてそれを保証する）というのなら別だが。

なんと！ 野尻抱影さんの『星三百六十五夜』の文庫本が出てるってぇ！

• 『星三百六十五夜 秋 改版』 野尻抱影 著 （中公文庫 BIBLIO）
• 『星三百六十五夜 冬 改版』 野尻抱影 著 （中公文庫 BIBLIO）
• 『星三百六十五夜 春 改版』 野尻抱影 著 （中公文庫 BIBLIO）
• 『星三百六十五夜 夏 改版』 野尻抱影 著 （中公文庫 BIBLIO）

買うぅ！ 絶対買うぅ！ 今から本屋さんへ GO だ！ なかったら注文してでも買う！

『星三百六十五夜』は私が天文民俗学にハマるきっかけになった本だ。 通ってた高校の図書館で見つけて以来とりこである。 しかし， 実は既に当時文庫本版の『星三百六十五夜』は絶版になっていて買うことができなかった。 大学時代に豪華装丁版があると聞いて三度の食事を二度に減らして（少しウソ）買ったおぼえがある。 その豪華装丁版は今でも実家のガラスケースに鎮座ましましている。

野尻抱影さんの著書はどれも好きだが， 『星三百六十五夜』は私にとって特別な本なのだ。

でも当時は確か一冊だったよね。 季節ごとに分冊したのかな。 それとも内容が増えてる？

「FlowerLounge はてな版」の記事を参考にいくつか。

私は「流しのプログラマ」なので「自分のマシン」というものを持っていない。 強いて言えば自宅のマシンが「自分のマシン」だが， 客先で作業することが多いのであまり関係ないかな。 客先に行く時は「秀丸」や「Becky!」など最小限のパッケージを詰めた CD-R を持ち歩いている。

ノート型が嫌い。 特にあのキーボードの感触が嫌い。（建前） でもノート型の最も嫌な点は「何時でも何処でも仕事をしてしまう」ことだ。（本音） だからノート型は持たない。（H/PC は持ってる）

「秀丸」や「Becky!」が困るのはシェアウェアだということ。 従って客先で借りたマシンに入れられないことがある。 特に納入マシンはね。 とはいえ「メモ帳」はテキスト・エディタとしてはダメ過ぎる。 機能はともかく， あの（瀬戸内海の海質のように）もったりした操作感はどうにかならないものか。 もっとこうスパスパッと動いてくれなくちゃ。

そういう意味じゃ UNIX 互換機（Linux とかも含めて）は楽だな。 UNIX 互換機で私が最も使いやすいのは vi だったりする。 HJKL カーソルとか楽でいいよね。 vi が入ってない構成はないし。 （vi を使った後に他のツールを使うとスクロールしてるつもりで H キーを連打していることがある）

キーボードやマウスは大事。 あれこそまさに「文房具」だよな。 でも最近のはマシンに付属しているのでも感触自体はそう悪くないのであまりこだわらなくなってしまった。 どっちかというとアプリケーションをショートカット起動するためのボタン類のほうが気になる。 某 NEC のマシンに付属してるやつだったか， Insert キーの真上（106/109 キーボードでいう Print Screen キーの辺り）にリセットボタンがついているという世にも恐ろしいキーボードがあった。 つまり操作中に Insert キーや F12 キーを押し損ねると問答無用でマシンがリセットしちゃうのだ。 キーボードはよく考えて選びましょう。

色の話でいうと， 実は私， 黒地に白はダメだったりする。 色そのものというよりコントラストの強い配色がダメなのだ。 すぐに目が疲れてしまう。 でも白地に黒は大丈夫。 白地に黒ならモニタのコントラストを調整することで目の疲労感を抑えられる。

あと文字の大きさと書体ね。 ゴシック体は疲労感が大きい。 多少デザインがへたれでも ＭＳ明朝 の方がよかったりする。 MS 製の TrueType フォントは 10pt を超えるとかなり読みやすくなる。 Word などのワープロで， フォントサイズの既定値が 10.5pt とか中途半端な値になっているのはそのせいである。

ツッコミのレスポンスをこっちに書いておきますね。

なるほど， 視覚の問題（あるいは障害）にも色々あるなぁ。

先の記事に補足しておくと， 私は近視で乱視で弱視だ。 乱視は親父ゆずりなので諦めている。 弱視は「若干」という程度。 コントラストのキツいものを見ると疲れるのと， 天体観測に不便な程度（暗闇に目を慣らすのに時間がかかるのだ）。

ズボラな性格なのでコンタクトも NG。 最近は乱視用も安くなってるらしいんだけどね。 メガネレンズは特注品なので壊れると大変。

実は私が管理してる「Club-HUAA サポートページ」は個人的にあまり好みではなく， 実際に配色を変えたこともあるんだけど， メンバに大変不評だったので元に戻している。 (^^;)

まぁ「万人に優しいデザイン」というものがいかに難しく現実的でないか， ということだよね。 結局はターゲットを絞った上で， その範囲内でチューニングしていくしかないのだ。（← いいわけしてるつもり）

あ〜，いえいえ， インストールの面倒臭さとかじゃなくて， 他人のマシンに「私にライセンスされているツール」を入れるわけにはいかないのが問題なんです。

まぁ私が占有している開発用マシンなら終わった時点で削除すればいいことですが， 納入してユーザ側で運用するマシンに「私のツール」を入れるわけにはいかないのです。 もしどうしても入れるのなら， 対象マシンのユーザ（たいてい法人ですが）で「秀丸」をライセンスしてもらう必要があります。 最近の企業はこういうライセンス管理にうるさいので（まっ当然なのですが）， 「古き良き DOS 時代」のようにアバウトにはいかなかったりします。

ちなみに私は「秀丸」の使用ライセンスを1994年の終わりに買った。 当時は日経 MIX のアカウントしか持ってなくて， インターネット経由でメールを送った覚えがある。 思い起こせばあの時が私の「インターネット」初体験だったのかもしれない。 ちうことは， もう10年くらい使ってるのか。 どひー。 暗証コードは既に暗記済みです。

すみません。 この記事に関しては「全面削除」させていただきます。 ただし， この記事に書かれていた私の主張を覆すものではありません。 もし理由がご入り用でしたら「一身上の都合」ということでお願いします。

すみません。 この記事に関しては「全面削除」させていただきます。 ただし， この記事に書かれていた私の主張を覆すものではありません。 もし理由がご入り用でしたら「一身上の都合」ということでお願いします。

長考中。 いや， 時間が足りないんだってば。

• Javaでは食えなくなる？

なかなか面白い記事。 しかし職業エンジニアというのは「永遠に続く言語などあり得ない」ことを身をもって知っているので， 上記のような危機感はむしろ日常的なものなのではないだろうか。

実際問題として， ここ数年のスパンで考えた場合， 「Java では食えなくなる」というのはないんじゃないだろうか。 だって Microsoft の .NET （WinFX）に（スペック面で）唯一対抗できるのは Java プラットフォームでしょ。 この関係が続く限り Java も続くと思うな。（真に受けないように，念のため）

C/C++ 案件が増えてるって話もあるけど， そういう実感はあまりないな。 景気に連動した引き合いの増減というのは確かにあるけど C/C++ 言語そのものの流行り廃りは（少なくとも私がこの業界に身を置いているここ十数年の間には）感じない。 ただし C/C++ が使われる場は変わってきているように思う。 アプリケーションで C/C++ を要件とするものは今後減っていくのではないだろうか。 というより， 「アプリケーション・エンジニア」というものが不要になるのでは， という激しい危機感がある。

技術者と製造者の二極分化は昔からある。 「人月勘定」の呪縛から逃れない限り技術者は育たないし製造者は安く買い叩かれ続ける。 インドや中国への外注の増加は買い叩く相手が国内の派遣会社からシフトした結果に過ぎない。 だって日本人を一人月雇うお金で中国人を三人月は雇えるもの。 でもそれも今のうちでしょ。 そのうち中国の企業から「買い叩かれる」身分になれるよ， きっと。

まぁこの辺は私も耳が痛い話なのでここまでにしといてやろう！

ツッコミよりフリーのテキストエディタを紹介していただきました。 感謝です。 こんなのもあるのね。

• K2Editor （K2 Software's Page）

私はフリーのものとしてはサクラエディタを使ってる。 最近は使う機会がないけど。 フリーなら客先で作業終了後に万一削除し忘れても問題が少ないので便利。

「Easy Lazy Diary」の記事を見て気になったので， 私も調べてみた。 PageRank については以下を参照。

• Google の秘密 - PageRank 徹底解説
• PageRankは今何点？

ちなみにうちでは， このページと「Software Labo.」が5点， 「おうちでできる天文学」が4点， 「もっと辺境から戯れ言」が3点だった。 辺境にしちゃあいい点数である。 こういうのも権威付けになるのかな。 まぁ「権威」もあるから「八分」もあるんだけど。

多分ランクを 6 以上にするにはもっとお客を呼び込む必要があるだろう。 しかしそのために何かするのは限りなく面倒なので， うちのサイトでは 6 以上はあり得ないことになる。

今後「もっと辺境から戯れ言」のランクが変化することがあるのかないのか。 これは気になる。

• みんなのために？自分のために？

これを見て宮台真司さんの「ＣＤが売れなくても誰も困らない」を連想した。 普通「みんな」という場合には， それを指し示す有限の範囲が存在する。 「ＣＤが売れなくても誰も困らない」で示される「俺たち」と「みんな」は同じものを指すのではないだろうか。 「三銃士」に出てくる有名な台詞 「One for all! All for one! （ひとりはみんなのために，みんなはひとりのために）」 の「All」も有限の範囲を持つ「同胞」的なニュアンスがある。

だとすれば， 隠れ蓑的に使われている「みんな」という言い回しが変なのは， 「みんな」の範囲が示されていないからだと思う。 実際の世の中は， それぞれが特定のコミュニティにひきこもって外部との接続を断っているというのに（「越境できない蜜蜂たち」）， 範囲を持たない「みんな」を掲げてもリアリティはないしコミットできない（ワタシハ「みんな」デハナイ）のも当然だと思う。

まず「みんなのために」という同胞愛（博愛）の範囲を示し， その上で「みんな」の外部とどのように折り合うかが示されなければ「みんな」という言葉にリアリティは生まれないだろう。 「国益」という言葉も同様。 今は政治家やマスコミがそれぞれの立場で好き勝手に「国益」を叫ぶ。 そんなものに誰がコミットしてやるものか！

欧米では「みんなのために」という言葉が同胞愛としてちゃんと生きているように見える。 それが， 例えばイラク戦争において（良し悪しはともかく）立場をはっきり表明する欧米（または日本以外のアジア）と政治的思惑だけで「なんとなく」自衛隊を派遣してしまう日本との違いなどに表れている。

そういえば「みんな」という言葉にもう一つ連想するものがあった。 遠い昔の親子の会話。

子：	ねぇ，○×が欲しいよう。うちも買ってぇ！
親：	ダメ。うちにはそんな余裕はない。
子：	ええっ！ でも「みんな」持ってるんだよぉ。もってないのうちだけだよ！
親：	そんなことないでしょ。隣の○○ちゃんだってもってないでしょ。「みんな」って誰？
...

勝ち目のない親子間交渉...

時事ネタだけど， spam ネタはずっとこっちで書いてるので， こっちでフォローしておこう。

• 革新的なスパムフィルターを求めて――『スパム会議』報告
• 弊害も多くなってきたスパムフィルター

ベイジアン・フィルタが spam のフィルタリング手段として決定打になり得ないことは私も以前に書いた。 が， ベイジアン・フィルタが一般化する（権威化する）ことで普通のユーザの行動まで制限されてしまうことは指摘しなかったな。 まぁ私もベイジアン・フィルタがこんなに早く広まり， かつこんなに早く使えなくなるとは思わなかったし。

私のところに来る多くの spam なんか典型的だが， 最近の spam は既に文章の体裁になっていない。 これは spam の目的が「不特定多数に送信する」こと自体にあるからだ。

• スパムメールに返事を出したら――体験レポート

ベイジアン・フィルタなら単純なフィッシング程度は防げるかもしれないが， 中身のない spam にウイルス／トロイの木馬を組み合わせたメールの場合は防ぎきれない可能性もある。

• Opinion：フィッシング詐欺に釣られてはいけない
• 2004年展望――昨年のセキュリティ問題が拡大する
• 巧妙化するオンライン詐欺--トロイの木馬・ウイルス・フィッシングの「合わせ技」で
• トロイの木馬・ウイルス・フィッシングを組み合わせた詐欺メール

ベイジアン・フィルタは spam を完全には防げない。 しかもこれが権威的に働くとまっとうな利用者の行動が制限されることになる。 この点をしっかり頭に入れて慎重に運用（チューニング）を行う必要がある。（故に私は ISP によるメールのフィルタリングには反対なのだ。前にも書いたけど）

spam の問題は spam を受け取ってしまうことではなく， spam がネット上に流通することそのものにある。 そして spam の流通系路上にある全てのプロバイダとコンシューマはセキュリティの対象になってしまうのだ。 こうした認識なしに「臭い物には蓋」式で防ごうとしても解決するわけがない。

日付が変わっちゃったけど， ついでなので先日導入したベイジアン・フィルタ付き BkASPil についての雑感をいくつか。

BkASPil は本来 IPBL を使ったフィルタリングを行うが， 補助機能としてベイジアン・フィルタも使えるという位置付けである。 ちなみにベイジアン・フィルタの対象は今のところ英文メールのみだ。

私のところには現在1日あたり 200〜300 通程度の spam （と思われるメール）が来る。 そのうち一番多いのは spam の体裁をしたウイルス爆弾メールだ。 今までは振り分け機能でゴミ箱に捨てていたが， 試しにいくつか学習用に食わせてみたところ奇麗にフィルタリングしてくれるようになった。 なるほど， 確かにこれは癖になるわ。

今のところ spam 判定されたメールのうちベイジアン・フィルタによるものは半分程度。 残りは英語以外の言語かランダムな文字の羅列のみのメールである。 しかしこれらも IPBL によるフィルタリングでかなり防ぐことができる。 特に日本語の spam は IPBL フィルタでほぼ防げる。 数自体も少ないし可愛らしいものである。

冤罪はいくつかある。 問題なのは IPBL で spam 判定されてしまったメールが自動的にベイジアン・フィルタの学習対象になってしまうところ。 冤罪メールを学習してしまうとベイジアン・フィルタによる冤罪発生率も挙がってしまう。 クリーン学習すると緩和されるのだが， これでは運用が繁雑になってしまう。

海外のある ML で IPBL に載っているオープンリレーのサーバから投稿するユーザがやたらと多いものがある。 意図的なのか気付いていないのかは不明。 ML なので該当ユーザを BkASPil の WL に登録してしまえばいいのだが， これもまた面倒な作業である。

これまで， IPBL によるフィルタリングに漏れた spam で悪質っぽいのはその都度 abuse に通報していたのだが， ベイジアン・フィルタを使うとその辺の情報が目隠しされてしまう。 今後そこをどう運用するかである。

「羊堂本舗 脳ざらし紀行」の記事経由で

• 初心者はGoogleを使わないか？

実は昨日の PageRank 調査のために初めて Google ツールバーを導入したのだが（そもそも IE はほとんど使わない）， かなりおせっかいな代物のようだ。 色んな機能がついてるけど使いこなせている人はどのくらいいるのだろう。 Firebird に慣れてると Google ツールバーは「やりすぎ」に思えてくる。 普通の人は検索窓さえあれば充分ではないだろうか。

それはさておき Google キャッシュ。 確かに私も Google で見つけたページに直接飛ぶことはあまりない。 大抵はキャッシュから見る。 理由はふたつ。 ひとつはキャッシュページでは検索キーワードが色分けされているので読みやすいから。 もうひとつは対象のページに足跡（アクセス履歴）を残したくないからだ。

特にふたつめが重要。 自宅の常用ブラウザは Referer を無効にするようチューニングしているし， そもそもアクセスしていることが知られたからといってどうということはないのだが， 勤務先や客先ではそうはいかない。 調べものはしたいが歩き回った足跡は最小限に留めたい。 となれば Google キャッシュを使わない手はないのである。

ってな風に考えると， 私もかなり Google 依存度が高いということなんだよなぁ。

ツッコミより。 情報感謝。

pgpdump の 0.22 がリリースされていますが， venona さんによる Windows バイナリも公開されています。 （ページの下のほうにリンクがあります）

ところで皆さん TIGER ってどう発音します？ 私何故かつい「ティーガー」って発音しちゃうんですよねぇ。 我ながら何でドイツ語なんだろ。 ドイツ語なんて大学時代に一般科目で一年間習っただけなのに。 まぁそれをゆったら私のハンドルネームももろにドイツ語なワケだけど...

• 宇宙の切り取り方

これ読んで「あぁ！」と納得してしまう。 いや英語の話でも物理学の話でもなくて， この前の戯れ言の延長としてだ。

「母国語」による縛りというのは語学や他の学問に限らずあらゆる状況で見られる現象なのではないだろうか。 問題は「母国語」に縛られる人達がそのことに気づいているかどうかだと思う。 「気付いているか」どうかの目安となるのは， 「母国語」の機能範囲外の「世界」に対して接続可能な「プローブ」や「ソケット」を持っているかどうかだと思う。

「宇宙の切り取り方」を例に考えると， 「古典物理学」を「母国語」とする人達に対して 「「古典物理学」と「量子力学」が同じ宇宙を別々の切り口で見る「同根異相」な宇宙観に過ぎない」 ことを何故理解できないのかと嘆く別の人がいるとして， 嘆くだけのその人もやはり自身の「母国語」にひきこもっているに過ぎないということだ。（いろもの物理学者さんがそうだと言っているわけではない。ちゃんと学生を教えておられる学者さんなんだし。念のため）

（これって「相対化」を連呼する自称「SF者」に対する痛烈な皮肉のつもりなんだけど， 「理解」できます？）

世界を完全に「理解」している人などいない。 百人いれば百通りの「世界の切り取り方」があるはずだ。 しかしその切り取り方が「正しい（あるいはもう少し控え目に「妥当」）」かどうか確かめるには他者と比較するしかないのだ。 そしてそのためには相手の「母国語」を理解し， かつ自分の「母国語」を理解してもらわなければならない。

相手の「無理解」を嘆き「異端」とみなすことは簡単だし心地いい。 しかしそれはそこで終わりである。 範囲の示されない（隠れ蓑的な）「みんな」は一見当たり障りのない表現にみえるが， 「みんな」を叫ぶ「私」以外の存在を「異端」として否定するのと同じだ。

うちらの業界なんて様々な「国語」や「思想」や「生活習慣」を持つ人達の寄せ集めでプロジェクトを構成することが多いし， 相手を理解し自分を理解してもらうという基本的なことができないと仕事にならない。 もちろんそれは簡単なことではないけど， それでも「理解しよう」という気持ちを失うわけにはいかないのである。

• 天皇の勅・・・

いや，この記事でリンクされてる新聞記事の方なんだけどね。 天皇を天皇（すめらみこと）と読む時点で象徴天皇はあり得ないだろう。 言葉の意味が分かってないのか？

天皇（すめらみこと）ってのはすなわち皇祖（すめら： 天照大神のこと）の命（みこともち）という意味。 つまり人間じゃあない（現人神）ってことだ。 今時の学校はそのくらいのこと教えないのか？

あゆめみさんところのダウンロードページで， WinPT Tray 0.91 用のパッチが公開されている。 WinPT Tray の最新版は現在 CVS によるソースコードのみの提供になっているのだが， 「バイナリも提供してるっけ？」と思ってよく見てみたら CVS 版をバイナリ提供している方がおられるらしい。

• Quadrifoglio Technocraft: GnuPG on Windows

WinPT Tray のバイナリ公開も素晴らしいが， 「GnuPG の処理を行う中継ソフト GPGrelay の導入」 も非常に嬉しい。 GPGrelay について日本語で解説しているページは少ないのだ。

今後注目のサイトかも。

（1/29 追記） ツッコミより。 WinPT Tray 0.91 のバイナリは 「自家ビルドではなく開発者のTimo Schulzがビルドしたものをミラー」 しているのだそうだ。 訂正しておきます。 ...バイナリあったのか。

そろそろ出るだろうなぁ， と思ってたらやっぱり出てた。 いや， 雑誌の方は見ないもので。

• 『トランジスタにヴィーナス』 6 竹本泉 （メディアファクトリー）

だんだんイーナスが可愛らしくなっていくなぁ。 前巻（16歳編）に引きずられてる？ いや， 私は全然 OK なんだけど。 もっと少女マンガな感じでもよいくらい。

なるものがあるらしい。 っていうか友人に貰った。 一袋（100g）千円。 高ぁ〜！

なんでもダイエットに効果があるそうで， 私の体型を見かねた友人がタダで譲ってくれたのだ。 持つべきものは友達である。

味の方は， え〜っと， あ〜っと， ん〜っと， まぁ効きそうな感じ？

（そういや日本人ってのは苦〜いお茶とか痛〜いマッサージとかじゃないと「効果がない」と思うのだそうだ。 だからマッサージ屋なんかはわざと痛くしているとか。 マゾ体質？）

もう勘弁してくれ。 受信したメールからウイルスのメールを検出するのは結構な話だが， From フィールドのアドレスにクレームをよこすのはんたーい！

spam やウイルスメールが差出人を詐称するのはもはや常識である。 したがって Replay-To や From フィールドのアドレスにクレームをよこすのは意味がないばかりか， ネット上の負荷増大に荷担することにもなるのだ。

大体今回のウイルスだって大した脅威じゃないぢゃん。 手口だって目新しいものじゃないし， 日頃からやることをやっていれば防げる筈。 まだって方はこの機会にこそ対策を！

大抵のウイルスは対策を怠らなければ防止できる。 恐れることはない。 不用意に添付ファイルを開けるのなんてもってのほか。 予告なしの添付ファイルを拒否するのはマナー違反ではない。

合格おめでとうございます！

まぁ私達が口にするものは， 植物であれ動物であれ， 所詮は「生き物」なんだから安定供給されるって考える方がどうかしている。

でも今回の騒動に関しては別の点で「なんだかなぁ」という感じなのだが。

サイボーグ名を付けてくれるというので試してみた。 「S.P.I.E.G.E.L.: Synthetic Positronic Individual Engineered for Galactic Exploration and Learning」と命名してもらった。 かっこいい！

嬉しかったので画像をダウンロードして FoaF にも登録してみた。 向うの Weblog とこっちの本家両方に。 ついでに plink にも ping を打っておいた。

cocolog ではプロフィール写真を foaf:depiction ではなく foaf:img で指示してるんだね。 foaf:img を使う方が一般的なのかな？

• 若者はバンテージポイント（有利な場所）でキャリアを磨け

梅田望夫さんの記事。 なるほど， と感心しつつ読む。

これはコンピュータ業界に限らないよね。 仕事であれ研究であれ趣味であれ， ある分野に打ち込むにはその分野の最先端の「場所」にいて常に情報を「浴び」続けていないと， 知識や技術やスキルやそういったものがどんどん陳腐化してしまう。 大学時代にある教官がこのことを「情報浴」と呼んでいた。

ところでこの記事を読んで思ったのだが， 日本国内に業界の「バンテージポイント」と呼ばれる場所はあるのだろうか。 大手の企業ならそれなりに見晴らしはよさそうだが， 国内に限るような気がする。 はたして「世界」を見渡せる「場所」は日本にあるのか。

NTT 系列ならかなり見晴らしはよさそうかな。 下っ端の「Coder」をやってるうちはダメだろうけど。 あとは思いつかない。 ってか， 私が知らないだけか。

「Hena Hena Nikki」 1/29 の記事経由：

• MinGW 日本版プロジェクト

なんてのがあったのか。 特に「MinGW が抱える問題点」は非常によくまとまっていて参考になる。