Ganerated by nDiary version 0.9.4
『Interface』 3月号が懐かしい感じでなかなか面白かったので， 私も少し真似して以前社内向けに書いたドキュメントを再構成してドキュメント倉庫に置いてみる。
1998年にTeXで書いた文書なので PDF のみの公開。 「虎の巻」って程の内容じゃないし（「虎の巻」ってのはもともと『封神演義』でお馴染み「太公望」姜子牙が著したとされる兵法書『六韜』を指すらしい）， 今となってはあまり参考にならないだろうけど， 「仕事くれアピール」のネタくらいにはなるかもしれない。 これからプログラミングを勉強しようっていう若い人達は， この程度のことは基礎知識としてあってもいいだろう。
私にとってプログラミングってのはこういう作業なんだよね。 コンパイラのスペックを調べることじゃないよ。 つまり， どのように設計しようとどんな言語を使おうと， 最終的に「インストラクション」としてどのように落とし込まれる（実装される）かってこと。 私にとってプログラミングの「母国語」はアセンブラだ， と言ってもいいかも知れない。 だから設計の美しさ（オブジェクト指向がどうとか）やコードの美しさ（言語やデザインがどうとか）なんてのは二の次になっちゃう。
上記のドキュメントを書いていた頃なんか 20MHz という CPU サイクルの中で10μ秒単位のスケジューリング設計をやっていて， 言語がどうとかデザインがどうとか言っていられる状況ではなかった。 もちろん OS なんて「およびでない」である。
それを考えたら今は楽な時代だよねぇ。 好きなように「書ける」んだもの。 まぁ私には流行の「スクリプト言語」なんかは逆に「外国語」みたいで慣れるのに一苦労だけど。（しかも使わないとすぐに忘れる）
「MIDletプログラミング入門」（PDF）も公開しよ。 これは2002年に MIDlet 関係の仕事をした時に， 資料用に作りかけて途中で止めちゃったやつ。 本当は続きにサンプルプログラムとか書いて色々説明しようと思ってたんだけど， もう旬を外しちゃてるのでこのまま公開してしまおう。
ひょっとしたらプレゼンテーション用としては使えるかもしれないが， 技術的な説明は一切なし。 これこそ「仕事くれアピール」用のドキュメントだな。
他に出せるものは... なさそうだな。 雑文置き場にあるものを整理してドキュメント倉庫に移したいんだけど， いつになるやら。
Unicode のこういうところが嫌い。 どんな革新的な文字セットを作り出そうと過去のしがらみからは逃れられないし， こうやってうっかりや誤解が伝搬していけばせっかくの規格も台なしになる。
もうこれについてはあまり書きたくないがウォッチは続けるつもり。 専門家が何も語らず（または二項対立的な状況を作り出してそれを維持しようとし）， 技術者が傍観者の立場をとるなら誰も止めようがない。 そういうことだよね。 まぁ今の日本ってのは全てにおいてそういう状況だし。 北朝鮮問題にしたってイラク戦争参戦にしたって。 まぁ私も後何年生きられるか分からないし， どうでもいいか， 先のことなんて。
『日経コンピュータ』って読む機会がないんだよな。 「日経なんとか」という名前のコンピュータ関連雑誌の中では位置付けが中途半端なんで， 定期購読してないところも多いみたいだし。 もちろん自分で定期購読する気はない。
「バカの壁」の話は面白い。 そういう使われ方をしてるのか。 著者の養老孟司さんはこの状況をどう思っておられるのだろう。 使われ方に着目して考えると「バカの壁」は「ゲーム脳」と同じだ。（もちろん中身は全く違う。念のため） 「バカの壁」も「ゲーム脳」もそれ自体スティグマになっている。 それを貼り付けてやることによって相手との「接続」を切るわけだ。（オマエハナンニモワカッチャイナイ） 接続を切られちゃ何も語れないよな。
「へぇ，面白そう」 と思ってモニタ登録ページを見たら，
は， まだ何とかなるとして，
とか言ってくれる。 おまけに「一般的なHDD容量は80GBです」なんてダメを押されては...
どうせ私のマシンは一般的じゃないよ。 貧弱でゴメンね。 ちうわけで， 止め止め。
敢えてこっちに書く。
書かれている内容にはおおいに納得するものがあるが， なぜ「「お返しTrackBack」はやめよう」なんだ。 お返し Trackback が嫌なら「「お返しTrackBack」はやめて」でいいじゃないか。 「やめて」とした上でお返し Trackback の非合理性をちゃんと説明できていれば（上記記事では説明できていると思う）みんな納得するのに， 「やめよう」という他者を巻き込み「世論」化しようとする意図がみえみえの文体が気に入らない。
現在， 続々とサービス・プロバイダが Weblog サービスを立ち上げている。 かつての「ホームページ・サービス」が大流行した時のような感じだ。 ということは， 今まで自前でやってきた人達とは明らかにメンタリティの違う「Weblog ユーザ」がたくさん発生することを意味する。 「「お返しTrackBack」はやめよう」というお題目は， 今もなお根強くある「「ホームページ」と言うのはやめよう」というあのお題目に通じるものを感じる。
「Trackback が何かよく分からない初心者」みたいな言い回しもよく聞こえる。 私は今だに Trackback を理解していない初心者だ。 もちろん技術的な仕掛けは理解できるが， その仕掛けの上に乗っけている「blogger」と呼ばれる人達の倫理観めいたものが理解できない。
私が理解している「Trackback」というものは， 「他人のサイト／記事に任意のリンクを張らせる（貼らせる）しくみ」 でしかない。 それ以上のものがあるようにはとても思えない。 だから（仕掛けとしては） spam だって許容されるのだ。 「Trackback」の上にどんな意図を乗っけてこようが送り側の勝手ではないのか。
もちろん受け手にだって来て欲しくない「Trackback」はある。 来て欲しくないなら（「やめよう」ではなく）「やめて」と言えばいいのだ。 （spam のように）言って通じないなら（対処してくれるかどうかは別だけど）上流のプロバイダにでも通報すればいい。 他のサービスでもみんなそうじゃない。
以前「勝手に Trackback」でも似たような議論がされてるような気がするが， もう Weblog も Trackback も「blogger」のものではないのだ。 私を含めて「blog って何？」ってなノリの様々なユーザが流入してくる以上， Weblog の様々な仕掛けを（古参者には）予想もつかない使われ方をするのは当たり前だろう。 かつての「blog」はより大きな受け皿としての「Weblog サービス」に変わったのだ。 そういう意味じゃ， これまで繰り返されていた blog に関する数多くの「べき論」は全てひっくり返されるだろう。
（追記） あっ， もう反応リンク集ができてる。 早い早い。
ひらのあゆさんの「島の人」より：
私も基本的にはこうなんだけどねぇ。 仕事で呑気になれないのは， 悩んで煮詰まっても寝させてもらえないからに違いない。 と， あまりにご無体な仕打ち（仕様）に早くも泣きそうになっているのであった...
「正しい」ということにどれだけの意味があるか（どこまで適用されるのか）， ということなんだよね。 デファクトがどうとかいうのではなく， ハナから別の価値観や倫理観を持っている人達に自分の「正しさ」を適用させることは意味がない， ということだ。 例えば「ユーザ」に対する「消費者」のような， だ。
だから問題なのは「何が正しいか」ではなく， 自分と違う「正義観」を持っている人達とお互いにどう折り合うかだろう。 そのためには相手と接続するための「ソケット」と「プラグ」が必要だってこと。 相手が（自分向けの）ソケットを持っていないのなら持っている人経由でもいい。
見方を変えれば， そういったお互いに「異質」な人達を受け入れる器（規範や法律やアーキテクチャなど）をどう設計するかってことになる。 異質を受け入れないのなら「ゲーテッド・コミュニティ」をつくるしかない。 （本来の意味ではない）巷で言うところの「バカの壁」ってやつだ。
おおおっ， アクセス履歴見たら（うちにしては）凄いことになっている。 言及していただけるとは恐縮です ＞ たださん
今回は「お返し Trackback」をだしに書いてるけど， 言いたいことはいつも同じ。 上で書いたようなこと。
私は cocolog は利用していても cocolog 内で形成されているらしいいくつかのコミュニティには関っていないので， そもそも「お返し Trackback」なんてものがあること自体知らなかったが， たとえそれが日常的に広範に使われているとしても， それは「消費者」の勝手だ。 もしかして「作者」や「ユーザ」はそれを快く思わないかも知れないが， それも「消費者」の勝手だ。 「消費者」が好き勝手絶頂に使うのが気に入らないなら「消費者」が使えないようにすればいい。 バッドノウハウをてんこ盛りにすれば簡単に「消費者」は去っていく。 あるいは「nif者」が嫌いなら cocolog からの Trackback を拒絶すればいい。（CNET のTrackback 機能も一時そういう状態になっていたし実装は簡単だろう）
そのうち「お返し Trackback 禁止」みたいなバナーが出まわって， もっと過激に「お返し Trackback を送るのはマナー違反です」みたいな奇天烈なネチケットが流布すれば， 現象としては面白いけど， それ自体は「壁」を積み上げる行為でしかない。 （実際にはそうならないかも知れないが）あの記事は， 有名人が書かれているだけに， それを予感させる（個人的には）スリリングな記事に見えたのだ。
（追記） ツッコミありがとうございます。 「TrackBackの「環境問題」」という言い回しは面白いです。 うまい言葉で切り返そうと色々考えたのですが， 世間からひんしゅくを浴びそうなものしか思い浮かばなかったので止めときます。
MIDI ファイルを着メロに変換する凄いツールがあるというので早速試してみた。
Ｍａｇ．さんのところにある MIDI データから 「Inspiration」（ジプシーキングスの曲。「鬼平犯科帳」のテーマともいう） を選んで変換してみる... おおっ， 素晴らしい！ ちゃんと変換できるじゃないか。 あの独特の「キュイーン」って音階が変化するアレンジも何とか再現されてるみたい。
曲が長いので実際には着信音代わりに使うというわけにはいかないけど， これでいつでも「Inspiration」がケータイで聴けるっちうわけだ。 自作の曲を MIDI で公開している人は30秒くらいの短い奴を作って公開したら面白いかも知れない。
SSD には演奏機能もあるのだが， これがヘボい。 私のマシンが貧弱なせいとは思うけど， MIDI Espressivo では難なく演奏できるのに「何で？」って感じ。 （MIDI Espressivo はシェアウェア（しかも作者は既に鬼籍）だが， 保存機能に制限があるだけなので， 演奏するだけなら「試用」モードで充分使える）
...ああ， そうか。 これ MIDI 演奏じゃなくて SMAF 演奏をソフトウェアでエミュレーションしてるのか。 じゃあしょうがないな。
サイドバーに大阪弁変換プロキシへのリンクを貼り付けていたのだが， 今日見たら見事にリクエストが拒否されていた。 こういう使い方はしてはいけなかったらしい。 反省。 キッズ goo でも， お子様には読ませてはいけない表現があるらしくフィルタリングされたままである。
ので， もう両方ともリンクは外しちゃおう。 今までお世話になりました。
ツッコミより：
ＣＰＵに、私の意図した通りに動かないのは、お前が誤っているからだ。
と１度説教してみたい。
さすがに CPU 相手に説教したことはないですが， 似たようなシチュエーションはあります。 勤務先は制御系の会社なんで H/W 担当と S/W 担当の間で
S/W 担当： これ動かないよ。設計か基盤が悪いんじゃないん？ H/W 担当： え〜，プログラムが悪いんじゃないの？ ...
なんてやり取りはしょっちゅう。（最近の私はすっかりアプリケーションプログラマなので縁遠くなってしまったが） そしてその日の晩飯代を賭けて壮絶なバトルが繰り広げられるわけですな (^^;)
では， もう少しマジメに。 また「お返し Trackback」をだしに使っちゃいます。 申し訳ない。 考えてみたら「お返し Trackback」というタイトルであるにもかかわらず， 実は「お返し Trackback」そのものについては全く言及していなかったりする。 我ながらズルいと思うが， 「blog とはなんぞや？」みたいな議論やその上で形成される規範に対しては全く興味がわかないのである。 そういうものを期待して読んでおられる方には重ね重ね申し訳ない。
今回の「お返し Trackback」に関する言及を各地で（一部だけど）見てまわって思ったことだが， Trackback について考える際には「プロトコル」としての Trackback と， その上に形成されるアプリケーションやコミュニティやその規範とを分けて考えないと議論にならないのではないだろうか。
先日も書いたが， いまや blog／ウェブロはより大きな器としての「Weblog サービス」に変貌しており， その上に形成されるアプリケーションやコミュニティも多岐にわたっている。 これは単に「昔を知らない」というだけではなく（私なんかがそうだが）「昔のことなんか知ったこっちゃない」というユーザやコミュニティも誕生しつつあることを意味する。 つまり古参ユーザが形成した規範（あるいはもっと明示的なコンセンサス）は数あるユーザやコミュニティの中の「ローカルルール」のひとつでしかなくなっているのだ。 まずこの前提を押さえておかないとユーザ間あるいはコミュニティ間の水掛け論になってしまう。
「どちらが正しい」のではなく「どちらも正しい」とした上で両者のリスクとベネフィットのバランスをはからなければならない。 私が「やめよう」と「やめて」との違いにこだわるのはこの点に依る。 私は「どちらが正しい」といった二項対立的な状態に陥りがちな戦略よりもこのような「リスク・コミュニケーション」を好む， と言った方がいいかもしれない。 この世の中は解のある命題より解のない命題の方がずっと多い， ということだ。
もちろんツッコミで jouno さんがおっしゃったように（ツッコミありがとうございます）， お互いに自分の立場と主張を表明することは大事。 しかし立場や主張を表明するだけでは十分条件とはいえない。 自分の立場や主張を表明することは相手の立場や主張を（程度の問題はあるにしても）受け入れることと対になってなければならない。
そういう意味では， たださんの主張は「表明」ではなく（ご本人も書かれているように）「提言」または「啓蒙」なのだ。 つまりハナから相手の主張を拒絶しているのである。（← 文字どおり受け取らないように。「拒絶する」というパフォーマンスを行っているということだよ） 見方を変えれば， 相手が「提言」または「啓蒙」してくるなら， それを拒否する（つまり「気に入らない」と主張する）のも私の勝手， ということになる。 これではコミュニケーションには（もちろん議論にも）ならない。 （「啓蒙」（またはその手段としての「説得」）というのは議論の前段階で行われる「教育」的な意味合いが強い。 従って「啓蒙」が「議論」に絡まないのはむしろ当然なので， 上のような書き方はちょっとズルいかも）
Trackback の話に戻るが， 私が Trackback を面白いと思うのは， それを有効にしているユーザにとっては「他者からの Call を受け入れる」と宣言していることに他ならない， ということだ。 これは単に「批判を受け入れる」とかいうレベルではない。 もっと「異質」な spam や「お返し Trackback」も受け入れるということだ。 どこまで受け入れるのか。 もちろん Trackback というプロトコルとそれを実装するアプリケーションが許す範囲で， である。
Trackback はコミュニケーションを行う上で大きなベネフィットをもたらす。 しかし一方で「異質を許す」というリスクももたらす。 もちろん誰だって可能であればリスクは排除したいと思うだろう。 また同質の価値観を共有するコミュニティ内でなら排除は可能かも知れない。 しかしそれを「外部」にも広げようとするのには問題がある。（何が問題なのかはこれまで書いたとおりだ）
面白いことに全く同じ現象が今世界規模で起こっている。 アメリカを中心とした「グローバライゼーション」だ。 もうひとつある。 環境問題における「南北問題」だ。（ツッコミでたださんが書かれた「TrackBackの「環境問題」」を私が面白いと書いたのはこれを連想したからだ。 ひょっとしてたださんもそれを分かった上でそう書かれたのかも知れないが）
「リスクの再配分」という言葉は環境の「南北問題」で使われはじめた， と聞いたことがある（うろ覚え）。 強力に環境リスクを排除しようとするあまり， 「南」（つまり弱者）にそのしわ寄せがきてしまったからだ。 リスクを排除するために「他者」を巻き込むのではなく， みんなで（できる範囲で）ちょっとずつリスクを引き受けるよう「調整」しなければならない。 それが「ポストモダン」における私達のとり得る戦略だと思う。
ちょっち身内に不幸がありまして， 週末はネットから離れておりました。 2日程度なのに随分おいてけぼりを食らってるなぁ。
なかなか面白いと思うが， よく考えたら cocolog はテンプレートを弄れないし， このサイトはライセンス設定の関係で他者の記事を無条件に展示できないので， 私にとっては無用の長物（もしくは猫に小判）なのであった。
なんでもそうだが， あるリスクを回避する一番簡単な方法は， 常に「代替え手段」を用意することである。 まして Google なんてのは手段そのものである。 であるなら， 回避方法なんて実はいくらでもあるのだ。
これの素晴らしいところは， 中国製（？）である点であろう。
例えば国内の圧力で「Google 八分」が発生するなら， 国内の圧力から自由なサービスを利用すればいい。 特定の検索サービスによる意図的なフィルタリングが行われているというなら， そのフィルタリングから自由なサービスを利用すればいいのだ。
ここで重要なことは， そうした「消費者」による「選択」の余地を常に残しておくことだ。 なるほど「あり過ぎる選択」はかえって「消費者」に不自由をもたらすかも知れない（それこそが「検索サービス」の存在する理由なのだが）。 しかし選択の余地がない「不自由」はそれ以上に悪い。
検索サービスは淘汰・独占の時代を終えようとしているのではないか。 これから私達「消費者」が求めるのは複数の検索サービスを（新聞記事を比べるように）「読み比べる」ことができる環境ではないのだろうか。 ...などと漠然と考えてみる。
ちうわけで， 「Search Service Collection」 なる Wiki ページを作ってみた。 試しに「Google」と「百度」を挙げてみたので， 興味のあるかたはガンガン追加・修正してください。
CCPL が近々バージョンアップするらしい。 日本版の正式版が延期になったのはこの影響なのかな？ CC-jp はなんだか中ぶらりんのまま様子が見えないので気になってるんだよね。 なしくずしだけは勘弁して欲しい。 （2/10 追記： 真紀奈さんのところ（2/6 の記事）で状況について書かれていた。 定期巡回コースなのに見落としてました。 ゴメンペコン）
さて何かと噂の「表明保証条項」だが， ドラフト版を見た方はご存じのとおり， 日本版では表明保証条項は既に削除されている。 私は法律には詳しくないのだが， CCPL に書かれている表明保証条項は日本の法律下では過剰スペックである， という判断になっているように思われる。
WinPT Tray 0.92 を導入してみる。
0.9 からの追加機能としては，
があるらしい。 OpenPKSD との相性は相変わらず悪い。 ソースからのビルドに挑戦している方もおられるが， うまくいってなさそうな感じ。
INTERNET Watch の記事より気付いた点をいくつか。 いや， まぁ， 揚げ足取りみたいな話なのだが...
最初の記事の最後にこっそり東風フォント騒動について言及されているが， 正確さに欠いているように思われる。 東風フォント騒動については， 最初のアナウンスに誤解を招く表現があったため， かなり混乱があったが， 上の記事はそれを引きずってしまっているようである。（岡村久道弁護士がどうというより，この記事を書いた記者が混乱してしまっているのではないだろうか）
確かにフォント（厳密には書体（タイプフェイス））の著作権は現時点では認められていない。
しかし， フォント作者はこの状況に必ずしも満足しているわけではないのだ。 「東風フォント」には書体の意匠性・作家性あるいは美術性というものに配慮しつつ誰もが使える「公有フォント」を構築しようという狙いがあった。 だからこそ無断複製の発覚はそのポリシーに反するものとして取り除く必要があった。 そのための作業や交渉が今回の東風フォント騒動の全容と言える。
東風フォント騒動を単なる「著作権絡みのトラブル」と考えることは， 問題の本質を見誤ることになる。 書体の作家性を著作権として認めずフォントデータのみを取り引き可能な「知財」として認めることは， それを利用する私達にとっても不利益をもたらすのではないのか。
私は以前「今回の件は書体の著作権について考えるいい機会である」と書いたが， それはつまりこういう事なのだ。
もうひとつ。 個人情報保護法の話。
これも最後の方に
「法律施行まではまだ期間があるが、消費者側の意識の高まりが早いことから、今のうちに自社で保有する個人情報の洗い出しを進めた上で、今年4月以降に各省庁が公表する業態別のガイドライン等に従って早期に管理体制の整備を進める必要がある」
とあるが， 企業側から見てこれでは遅すぎるだろう。 個人情報について真面目に考えている企業は昨年の夏あたりから社内でガイドブックを配ったりして啓蒙・周知をはじめている。
こういう呑気なことをいうのはやはり役人や学者の感覚なのであろうか。
首相官邸からウイルス入りメールを頂きました。 てへっ
（From フィールドがそうだっていうだけのことだからね。念のため）
こういう記事を見るとウイルスや spam に対する本気度の違いが分かる。 アメリカなんかじゃ間違いなく「社会問題」なんだけど， 日本ではせいぜい「うちに来なけりゃ OK」「フィルタリングすればいいんでしょ」ってな感じだし。 長閑だねぇ。
昨日あたりからBkASPil が起動時にデッドロックする。 理由は不明。 IPBL を GET した直後に何かおこってる感じ。 取り敢えず IPBL の自動取得を無効にして運用してみる。
「Phoenix 情報局」にアナウンスがなかったので気付くのが遅れてしまった。 既に JLP もあるようなので私も入れてみる。
見た感じは特に変わりなし。 ダウンロードマネージャが使いやすくなっている。
www.textfile.org の記事を見ていろいろな Reader （Aggregator と言うのが正しいのかな？）を試しまくる。
今使っているのは Sharpreader で， 機能面では特に不満はないのだが， とにかく遅くてメモリを喰いまくる！
もうひとつ。 以前 glucose を使っていたのだが， 当時のビルドはよく落ちるので止めてしまっていた。 新しいビルドが出ていたのでもう一度試してみる。
内部の DB エンジンを変えたせいだろうか。 かなり安定しているようだ。 でも相変わらずフォルダの管理がダメダメ。 全然言うことを聞いてくれないんだけど， 何かコツがあるのか？
今回フリーの HepCat と RThReader も試してみる。 HepCat はちょっと... 画面レイアウトや操作感覚が私の好みにあわないらしい。 RThReader は好み。 スクリーンショットを見るとちょっとうるさいようにも思えたが， 好きなようにレイアウトを整理できるのでこれでもよい。 ただマウス操作中にエラーが出まくるのは（落ちるまでには至らないが）ちょっと勘弁して欲しい。 もう少し様子見なのかも。
で， 更に， シェアウェアではあるが， NewsGlue も試してみる。 これがいいのだ！
私は今まで Sharpreader が遅いのは .NET Framework 上で動いているせいだと思っていたが， どうもそうではないらしい。 確かに Sharpreader も NewsGlue も起動に時間がかかるが， メモリの消費量がかなり違う。 特に NewsGlue では， 物理メモリの消費が抑えられている（つまりアプリケーション内のヒープ管理がちゃんとしている）のが大きいように思う。 久し振りに「軽い」デスクトップを堪能できて幸せである。
ここ数年くらいオンラインソフトにお金を払うなんてことはしなかったけど， 今回は久し振りにちゃんとお金払ってみようかな。 あぁ， また高級文房具が増える。
NewsGlue で面白いと思ったのは， RSS のリストを記述した OPML 形式のファイルを「チャンネル リスト」として構造ごと（フォルダとして）読み込んで同期をとっている点である。 これはいわゆる「インポート」とは異なる。 （インポートはその場限りの操作だが， NewsGlue の場合は常に最新の状態を保とうとする）
そうかぁ， OPML ってこういう風に使うのかぁ。 もの知らずでゴメン。
というわけで， 私のサイトで公開している RSS のチャネルリスト（rss.opml）と， 私の巡回コース上にある RSS のチャネルリスト（rsslist.opml）を公開してみる。 インポートするなりフォルダとしてリンクさせちゃうなり好きに使ってください。
rsslist.opml の方は巡回コースを全て網羅していない。 アンテナで補足しているサイト・コンテンツは基本的にチャネルリストに載せる予定。 まぁボチボチやります。
山根信二さんの「What's New or What's going on」の RSS を取りたいんだけど， 文法エラーで怒られてしまう。 パーサのエラーメッセージを見ると， どうも ESC コードがあるのがいけないって怒っているように見える。 文字エンコーディングの指定がないので， UTF-8 か Latin-1 (ISO/IEC 8859-1) で処理しているのかも知れない。 でも， RSS ファイルをダウンロードしてエディタで開くと中身が文字化けしまくってるんだよなぁ。 なんで？
もうひとつ。
FlowerLounge さんとこと結城浩さんの日記を見て気付いたんだけど，
channel 要素の rdf:about 属性にコンテンツの URI を書くのは 間違い。
RSS への URI を記述しないといけない。（2/13 追記： すみません，間違いじゃないです）
こんな感じ。
<channel rdf:about="http://www.alles.or.jp/~spiegel/rss.xml.rdf">
...
</channel>まぁここが間違っているからといってエラーになる RSS Reader はないと思うので， 気にする程のことはないかもしれないけど。 RSS への URI を記述するのが難しいなら空文字列にするという手もある。
<channel rdf:about="">
...
</channel>空文字列にするとコンテンツ（この場合は RSS）自身を指す。 可搬性を考えれば空文字列にした方が便利なのだが， 空文字列を上手く解釈できない処理系がたまにあるんだよねぇ。
って， あぁ， うちの Wiki もそうなってる。 直さなきゃ。 そういや 2.1.0 がリリースされてたな。 入れようかな。 どうしようかな。
あぁ， また（うちにしては）大量のアクセスが。 しかし， たださんのこの記事に反応しちゃっていいのかなぁ。 不毛な気がする。 まぁいいや。
まず直接的なレスポンスから。 「その先に進んでいない」のではありません。 「その先」の内容に興味がないのです。 私はオープンソースな方々がよくされる「啓蒙」的な態度に懐疑的なだけです。 気付いていないなら知らせればいいというスタンスには賛成だけど， そのための手段として「啓蒙」を選択するのは果たして効果があるのか， ということです。 従って話が噛み合わないのは当然ですし， ハナから「啓蒙」を目論む人に議論を仕掛けるほどマヌケではないつもりです。
ちなみに私個人で言えば「お返し Trackback」どころか普通の Trackback でさえ送っていいかどうか悩んでるくらいなので， 今のところ殆ど関係がない。 もちろんよっぽど嫌いな相手でも「お返し Trackback を止めて」という相手にあえて送ったりなんかしないし， 逆に「お返し Trackback を下さい」と言われれば喜んで承るだろう （笑）
相手（達）に対しあるアクションをおこした時， それがどのように受け止められるかを想像するのはとても難しい。 理由のひとつは「想像力」というのは常に自分に都合のいい方向に流されがちなものだから。 もうひとつは「想像力」の基盤となる「視界の相互性」とでも言うべきものが（足り）ないから。 私達が「理解」していると思いこんでいるものは， 実は多くの前提条件の上に成り立つものだ。 （「増殖を想像する力」もそういうことだよね，結局）
以前， 「啓蒙」というのは議論以前の教育的な意味合いで行われるものだと書いた。 ということは「啓蒙」の発信者は何らかの「権威」を纏っている必要がある。 そして更に， ここが重要だが， 「啓蒙」はその権威が届く範囲内（特定の組織・コミュニティ，あるいは同質の価値観を共有するもの同士）でしか影響を与えられないのだ。
「権威」は何によって担保されるのか。 知識？ 経験？ 知名度？ そういうものもあるだろう。 しかし一番重要なのは， その対象が「信頼」できるかどうかである。 ではその「信頼」は何によって得ることができるのか。 それは「信頼」にたるものから「信頼」されること， である。 分かりにくい？ こう言い直そうか。 「信頼」を保証するものは「信頼」である。 つまり「Web of Trust」だ。 「信頼」というのは相補的で帰納的な構造をしている。 （情緒的な話を抜きにするなら）「信頼」を保証する絶対的かつ普遍的なものは存在しないのだ。
喩え話をしよう。
ある村がある。 そこではみんな高度な道徳意識を持ち平和に暮らしている。 そこへ「新参者」が大量にやってきた。 何か事情があるのだろう。 村人達は快く受け入れた。 しかしそれからがさぁ大変。 「新参者」は好き勝手絶頂に振る舞いはじめた。 しかし従来の村の掟では彼等を裁くことはできないし， 一度受け入れてしまった以上今更拒否することはできない。 つまり法的コードによってもアーキテクチャ・コードによっても彼等を規制することができなかったのだ。
ここで一人の人間が立ち上がる。 古参の村人から厚い信頼を受ける彼（彼女でもいいのだが，彼としておこう）は， 「古き良き」村の道徳意識を取り戻すべく大々的なキャンペーンを打ち出したのだ。 当然のように古参の村人達は諸手を挙げて彼を応援する。 そして更に「新参者」のうち何割かは彼のキャンペーンに同調したのだ。 結局転向した「新参者」がキャスティングボートとなり村の「世論」は逆転することになる。
その後， 新しい「掟」が作られ， その掟に従うことのできない「新参者」達は村を出ていき， 再びあてのない旅を続けることになった。
めでたしめでたし。
まぁ， リアルでもネットでもよくある話だよね。 「啓蒙」するということはつまりこういうことなのだ。 異なる「Web of Trust」にいる人（達）に対して， 「啓蒙」で「説得」することはできても「納得」させることはできない。 「わたし」は「あなた」になることはできない。 決して。
あぁまた「お返し Trackback」をだしに使ってしまった。 でも最近「啓蒙」というキーワードをよく目にするので， このくらいは書いてもよかろう。
読んでないのが結構あった。 週末にでも読んでみよう。
やぁ， 世間は面白いなぁ。 こんなにボコボコ規格出してどうするつもり， ってな気もするが。
以前公開した yarss.rb を改造して Atom ファイルも吐き出すようにしてみた。 出力例は atom.xml を参照のこと。 FEED Validator は通ったのでおそらく問題ないと思う。 実は Atom を RDF の中に入れた形でも実装してみたのだが FEED Validator で怒られてしまった。 トップ要素に rdf:RDF が来ると RSS だと思いこんでしまうらしい。
フィルタ本体は yarss.rb.txt をどうぞ。 ndiary.conf で ATOM_FILENAME を指定すると Atom を吐くようになります。
RDF が使えないと CCPL や FoaF との連携ができなるのでつまらない。 何とかしてください， どこかの偉い人。
やっちゃいました。 先日書いた RSS の話， 大ウソです。
FlowerLounge さんおよび結城浩さんには大変失礼しました。 公開されてる場なんだからちゃんと裏をとって書くべきだったのに， うろ覚えのまま書いてしまったのは完全にわたしの間違いです。 言い訳のしようもありません。
このお詫びはいずれ， ということで勘弁していただけると幸いです。
（ううっ， ただただしさんにツッコまれたときより痛い！）
買っちゃいました， NewsGlue。 今日銀行に振り込んだのに， その日のうちにライセンスキーをいただけるとはかたじけない。
これから私の RSS reader の評価は偏るかもしれないので参考にしないように。 いや， 迅速な対応は十分プラス査定ですよ。
まぁ色々考えることがあって Yahoo Messanger を導入しちゃいました。 Yahoo! ID は私の FoaF を参照のこと。
奥村晴彦さんの「それはそれで住民票コードのように人を（ほぼ）一意にラベル付けできてしまうが」という危惧はごもっとも。 しかし大事なことは「知られないこと」ではない。 「知られている」ことをどの程度コントロールできるかだと思う。
現時点で「メールアドレス（およびそのハッシュ値）」はその人にとって一意な情報ではない。 つまり人はネット上においてメールアドレスごとに「私」を使い分けることができるのだ。 この「使い分ける」ことができるかどうかがプライバシーを考える上で重要だと思う。
という風に考えると「データベース情報の連結」がいかに恐ろしい結果を招くか想像できると思う。
XMP (eXtensible Metadata Platform) とやらを使うらしい。 TeX レベルで埋めこめないかな。 hyperref パッケージを調べる必要があるか。
βテスト開始。 個人的には現時点でも不満なし。 当初， プラグインに複数のアルゴリズムを組み込むのはオーバースペックではないかと思っていたが， 最近は考えが変わった。 先日の件もあり（デッドロック状態はその後回復した）， いざという時に（補助的ではあっても）代替手段があるというのは安心感がある。
私の場合， spam が1日あたり 100-200 通。 うち半分は IPBL でふるい落とされる。 更に残りの 4/5 以上は Bayesian で落とされる。 フィルタリングに失敗する spam が 10% 近くもあるのは効率が悪いようにみえるかも知れないが， 殆どは英語でも日本語でもないメール（そもそも読めない）なので気にするにあたわず。 よっぽど酷いのは abuse に通報するけどね。
そうそう， IPBL は SmallSize （20,000件）を使用。 フルサイズ（500,000件）の IPBL を使えばもっと捕捉率が上がるだろうけど， 受信動作が遅くなる方が嫌なので SmallSize でよい。
まぁ， 日に何百通と spam を受け取る人にはもっと強力なフィルタが必要かもしれないけど。 しかし， いつも書いてるが， 最近の spam は送信すること自体が目的化しているためフィルタリングは根本的な問題の解決にならないことを常に意識する必要がある。
おそらく昨日は全国津々浦々の歓楽街でバレンタインイベントが催されたと想像するが， 私も例にもれずいつものお店に行ってみる。 本当はショットバーに行く予定だったのだが， お休みだったのだ。
私は甘いものに目がないので日本のこの奇習については（少なくとも太巻きの一気喰いよりは）大歓迎なのだが， お店のイベントとなると少し事情が変わってくる。 なんか妙に張り切る女の子がいて「手作り」のチョコをくれたりするのだ。
この時期に私は敢えて主張したい。 素人はお菓子作りに手を出してはダメ。 つくるならちゃんとレシピを守ってくれ！ 数年前に激甘（海藍さん風にたとえるなら「初孫にはじめて会った祖父」）のチョコボールを貰って以来少しトラウマになっている。 チョコレートは甘さと苦さのバランスが重要なのだ。
ちなみに今年のチョコは普通でした。 感謝！ コーンフレークをくぐらせてかき揚げ風にしたのは美味かった。
うちのボスとおんなじこと言ってるなぁ。 やはり技術者あがりの経営者は感覚も似てくるのだろうか。 記事では最近の傾向のように書かれているが， エンジニア（ここでは職業エンジニアに限定する）がユーザ（顧客）に対して説明責任を持つ， というのは今も昔も変わらないと思う。 （厳密にはエンジニアが責任を持つのではなくエンジニアが所属または参加している企業が責任を持つのだが， 細かいことは言いっこなし）
まぁアプリケーションのコモディティ化や XP 手法の登場などによりユーザが開発の現場に更に歩み寄ってくるようになったので， 状況が変わっているようにみえるのだろう。 私が新人の頃って直接エンドユーザと打ち合わせる仕事が多かったような。 そう考えると私は恵まれた新人時代を過ごしていたのかも知れない。（しんどかったけどね）
エンジニアにはユーザに対して大きくふたつの責任があると思う。 品質保証と説明責任だ。 前者については誰もが言ってることだし， 大抵は工程の中に最初から組み込まれているので今更言う必要はないだろう。 しかし実は後者の方がより重要ではないかと思う。 「何故このプラットフォームを選択したのか」 「何故この言語を選択したのか」 「何故このシステム構成を選択したのか」 「何故このロジックを選択したのか」 ユーザなら当然抱いている筈のこれらの疑問に私達は「ユーザの言葉」で応えているだろうか。
説明責任を果たすことは両者間のリスク・コミュニケーションにも重要だ。 医療現場では医者と患者との間でインフォームド・コンセント（説明による同意）を実施することが常識になっているが， 開発現場でもエンジニアとユーザとの間のインフォームド・コンセントは必要条件なのだ。（「啓蒙」や「説得」は「説明」ではない）
もっとも， それが一番難しいんだけどね。 自分の考えていることを誤解なく相手に伝えるようになれれば， そして相手の言うことも正しく理解できるようになれば「人生極めた！」も同然なのではないだろうか。 「プログラマってのは客商売だ」。 そう悟ってからはこんなことばかり考えている。 社内向けに山ほど私文書を書いたり（最近はしないけど）， こんなところで戯れ言を書いたりしてるのも「客商売」の為のトレーニングである。 なかなかうまくいかないけどね。
「誰か」のためにものを作るのなら， その「誰か」にとって役に立つものでなければならない。 どの世界の「職人」にとってもこれは究極の目標である。
神崎正英さんのこのコンテンツの存在自体は少し前から知っていたが， こんなに濃い内容だとは思わなかった。 早速 RSS 巡回コースに入れる。
個人的に気になる記事をいくつか挙げてみる。
ここの RSS の記事をちゃんと読んでおけばこの前のような失礼な記事を書かずにすんだのに。
最近「有名人」な方々の間で噂の Orkut とやらもやっと分かってきた。 Social Networking についてはもう少し調べないといけないな。
例えば plink みたいな仕組みは面白いけど， 考えてみたら FoaF 自体は誰にでもどんなものでもつくれるのだから， 「Home Page」や「Blog」から任意のサイトへ誘導させるよう記述して ping を飛ばせば， あっという間に FoaF spam の出来上がりだな。 plink は基本情報しか載せてないから救いようもあるけど， foaf:currentProject や foaf:interest のような詳細情報まで使うサービスがあれば， 片っ端からマージしちゃうわけだからきっと物凄いことになる。
ちなみにうちの本家の FoaF には WOT 語彙を使って OpenPGP 電子署名を添付している。 まぁ試みとして， だけど。
「サブリミナル」がトンデモの扱いを受けていることすら知らなかった。 やっぱ某 A 教団の影響？（あっシャレちゃった） サブリミナル「効果」を「技術」と結びつけようとするからおかしな話になるんじゃないのかなぁ。 よう分からん。
最初タイトルだけみて平安時代末期の「禿（かぶろ）」を連想しちゃった。 私は essa さんのこの提言を「セキュリティリスクを金額に換算する方法論」と受け取った。
他の分野（例えば環境リスクなど）ではリスクを金額に換算して査定する方法はよく見られるが， コンピュータ・ネットワークのセキュリティリスクについてはそういった査定がされないため， ずいぶんとバランスが悪いような気がする。 もしセキュリティリスクを正しく金額に換算できれば， 普通の「消費者」でも対処の仕方が変わってくるのではないだろうか。（希望的観測）
でも大抵こういう時って自称「アナリスト」な人達がしゃしゃり出て， 手前勝手な計算方法で水増し請求しちゃったりするんだよなぁ。
以下妄想...
そういや， 「禿」というのは元々7歳までの子供の髪型（おかっぱみたいなやつ）を指すらしい。 従って「禿」という言葉は「子供」のイメージに結びついていくのだが， もちろんただの子供を指すわけではない。 みんなが知ってる「金太郎」の髪型は「禿」だし， 有名な「酒呑童子」も40歳にして「禿」だったそうだ。（だから「童子」と呼ばれるのだが）
日本では「子供」というのは「子供」という主体があるわけではなく「大人（＝人）ではない」という風に解釈される。 あるいは， 「とおりゃんせ」の唄など典型的だが， 「七つまでは神の子」という考え方もあるのだそうだ。 七つになってお参りをしてやっと人の親の下に「来る」のである。 故に子供はしばしば「神」または「鬼（もの）」とみなされるのだ。
ソフトウェアベンダにとって製品の中身をこじ開けて脆弱性を晒してしまう「連中」は， まさに「禿」であり「童子」であり「鬼」なのかもしれない。 しかし「脆弱性」という「鬼」を退治できるのもまたそうした「連中（＝鬼）」なのだ。
ある昔話では「桃太郎」という名の「鬼」が鬼が島の「鬼」を征服し略奪品をもって凱旋した。 また日本の神話で有名な「ヤマトタケル」は熊襲という「順（まつろ）はぬ鬼神（かみ）」を滅ぼした「鬼」である。（ヤマトタケルの元の名前は「日本童男（ヤマトヲグナ）」という） してみると， アメリカをしてイラクという「鬼」に派兵せしめた日本（自衛隊）もやはり「大人でない」存在（＝鬼）なのか。
なるほど， そうか。 Social Networking から Network Operating System に発展するのか。 前にチラッとインターネット上の Network Operating System がどうとかいう記事を見て， 「それって BOINC と何が違うん？」なんてなことを思っていたのだが， やっと得心した。
しかしそうであるとするなら， Orkut 等の Social Networking を「サンプル」として議論するのならともかく， Orkut という局所的な話に終始するのは勿体ない， というか拙いんじゃないのか。
仕事で Visual Studio .NET 2003 を使うことになった。 早速 Professional 版（MSDN が一緒についてる奴）を購入して導入したのだが...
いや， もともと私は「統合環境」って奴が大の苦手なのだ。 お仕着せで我慢できるくらいなら「流しのプログラマ」なんかやってない， ってなもんだ。 そんな私でもようやく Visual Studio 6 に慣れてきたところだというのに， なんだこの妙ちきりんなインタフェースは。
何故メニュー構成を変えるんだ。 また最初から操作を覚えなきゃならんだろうが。 私はもう「不惑」目前で脳みそも老化に向かって大爆走中なんだよ。 こんなくだらないスキル習得に時間をかけてる暇などないんだ！
一番ビックリしたのは ATL ベースで COM コンポーネントを作った時。 なんと VS.NET では C++ のヘッダファイルに IDL 記述を埋めこむ仕様に変わっているのだ。 こんなことが許されるのか。 ちっとも直感的じゃないぞ。 そうでなくても COM って頭で（インストラクションベースで）イメージするのが難しいのに。
もう間違いない。 MS は従来の C/C++ エンジニアを排除しようとしている。 彼等（私を含めて）は C# に転向するか河岸（プラットフォーム）を変えるかしなければ生き残れないだろう。
まったくもう， 「くたばってしまえ！」と悪態をつきたくもなろうというものだ。
といってもナニがアレになることではない。
さる方面から知ったのだが， 結構有名なツールなのかな， これ。 これ自体の機能よりも， 「「ＥＤ」について」に書かれていた
例えばＰＧＰに見られるように、テキストの暗号化機能や公開鍵暗号などがごっちゃになっていて初心者には非常に使いづらかったり
といった記述のほうが気になる。 やっぱ「使いづらい」と思われているのか ＞ PGP/GnuPG
私なんかは対称暗号のみの暗号化ツールより PGP のようなハイブリッド暗号の方が鍵の取り回しも楽だし便利だと思うのだが， それは世間一般の感覚ではないらしい。
今日も仕事をしながら妄想をめぐらす。 最近妄想が多いのは仕事がしんどいから。 愚痴は外に吐き出して初めて愚痴になる。 中に溜め込むと妄想になる。 だからここで妄想として書いたことは， 書いた瞬間に愚痴になるのである。 あーよかったよかった。
思うにエンジニアというのは「状態」とその変化を引き起こす「イベントロジック」を記述するのには長けているが， 「変化」そのものを説明するのが下手なのではないだろうか。 変化の前と後の状態をそれぞれ記述しても変化そのものを記述したことにはならない。
一方エンジニアでない人は「変化」そのものを説明するのには長けているが， 「状態」と「イベントロジック」に切り分けて考えるのが苦手なように見える。 この両者のすれ違いが仕様上の不備となって顕れる。
従って今エンジニアに必要なのは「変化」そのものを相手に分かるように説明できること。 「それで結局どうなるの？」という問いの意味をちゃんと受け止めて応えることだ。
もうひとつ思いついた。
エンジニアは多態性は許容しても多様性は許容しない。 何故なら多様性を許容することは， 想像を超える「状態」を扱わなければならないから。 多様性を拒否し代わりに多態性を提供することで状態管理を（つまりコードを）シンプルにできる。 しかも困ったことにそういうコードを「美しい」と思ったりするのだ。
ユーザが真に欲しているのは多態性ではなく多様性を許容するシステムだ。（「管理者」はそう思わないかもしれないが） しかしエンジニアが状態遷移表やオブジェクト指向設計などにとどまってる限り， ユーザが真に望むシステムは登場しないだろう。 というより「システム」という枠組みをはめた時点で多様性を拒否しているのだが。
まさに「想像もできないものは創造できない」だよな。
向うの Weblog で Hidemarnet Explorer をべた賞めしてしまったわけだが， Web ブラウザの機能としてはまだまだこれから詰めていく必要がありそうな。 まぁでも現時点でも便利には違いないけどね。
で， このお試しのために秀丸を現在β版の 3.10 に更新したのだが， こいつがなかなかよろしい。 秀丸も遂にタブが付いたか。 あったらいいなぁ， とは思ってたんだよな。 他のテキストエディタでそういうのがあったので。
秀丸のいいところは通常の SDI ウィンドウ群とタブで集約されたウィンドウとの切り替えが簡単にできること。 タブ機能って便利だけどタブが増え過ぎるとかえって使いづらくなったりするので， そういう時は従来の単ウィンドウのほうがよかったりするのだ。
あぁまたこれで当分「秀丸依存症」からは抜けられそうもない。
私も遂に Bloglines に登録した。 Bloglines ってのは Web サービスとして提供される RSS アグリゲータだ。
（「アグリゲータ」とか「アグリゲーション」という言葉に何となく抵抗感があると思ったら， COM の機能である「アグリゲーション（集約）」を連想するからだと気がついた。 この辺さんざん苦労したからねぇ）
いや， 客先とかちょっとした場所でニュースをチェックする際に便利かなぁ， と思って。 あと， 自前で RSS アンテナを用意するのが面倒だからというのがある。
Bloglines はアカウントごとに収集する RSS を設定するのだが， それらを一般に公開することもできる。 私の場合は http://www.bloglines.com/public/Spiegel で公開している。 こうなるとはてなアンテナの RSS 版という感じかな。
国内にも似たようなサービスはあって， 特に PAIPO READER! あたりは面白いと思うんだけど， 残念ながらこっちは OPML に対応していないので， チマチマと登録していく作業に飽きてしまって途中で投げてしまったのだった。 でもせっかくこちらもアカウントを取ったので， 本公開の際に使い勝手等よくなっていればまた乗り換えてもいいかなと思ったり。
この信頼度評価の実験を読んで OpenPGP の信用モデル「Web of Trust」を連想してしまった。 本当は向うの Weblog に書きたかったんだけど， どうにも頭の中でまとまらないので， 思いつくままここに覚え書の形で残しておく。
PGP/OpenPGP の Web of Trust については以下のページが参考になる。
気をつけなければならないのは OpenPGP における「信用」とは鍵（公開鍵または秘密鍵）に対してのものであり， 鍵の所有者に対するものではないということだ。 たとえ鍵の所有者がどれだけ人間的に素晴らしく「信用に足る」人物だとしても， OpenPGP の仕組みに無知な人ならばその人の持つ鍵を全面的に信用するわけにはいかない。 また何かのプロジェクトなどで複数の人間が使う使う鍵は完全に個人が管理する鍵とは扱いが異なる。 たとえそのプロジェクトが完全に極秘に行われているとしても。
では FoaF をベースにした信用モデルはどう考えればいいのだろう。 そもそも「ある人が別の人を信用する」という事象をモデル化することなんてできるのだろうか。
まず第一に考えなければならないのは， ある FoaF 情報が本当に本人によるものかどうか証明する方法だ。 おそらくこれを徹底させるには電子署名と組み合わせるしかないだろう。 しかし FoaF を利用するアプリケーションで「情報の本人性」を重視したものがあるのだろうか。
もうひとつは knows 要素の扱いだ。 FoaF において， ある人を「知っている」と宣言することにはどの程度意味があるのだろう。 例えば私は結城浩さんを knows リストに入れてるし結城浩さんも私をリストに入れて下さっているが， 私と結城浩さんの間に面識があるわけではないのだ。 そして FoaF が Weblog の中に組み込まれるようになると knows 要素は更に軽くなっていくような気がする。 相手の Weblog を「知っている」というだけで（その著者が誰かに関りなく） knows リストに入ってしまうのだから。
こうした曖昧なリレーションシップが張り巡らされている状況で FoaF をベースにした Social Networking やプラットフォームとしての Social Network Operating System が登場したらどういうことがおこるのだろう。 気になるのは FoaF 情報の本人性や knows リストの曖昧さに関係なく， それらの情報が Social Networking のもとに権威化されていくのではないかという懸念だ。 つまり本人の意志とは関係なく「キャラクタ」が構築され交友関係が形成されてしまうのではないかという不安なのだが， その辺実際に Social Networking に参加している人達というのはどのように考えておられるのだろう...
バージョンが上がった YukiWiki をやっと導入。
今回も HowToSetUpYukiWikiAtNifty にお世話になった。 オリジナルからの差分情報は YukiWikiInstallMemo を参照のこと。
Yuki/RSS.pm に dc_date を追加したという話だったが， 何故か中身が空だったので， 適当にいじって時刻を出すようにしている。（Perl の言語仕様がよく分かってないので記述が妙なのは勘弁）
例の channel の rdf:about の話だが， やっぱり RDF 的に気持ち悪いので RSS への URI に変えた。 つっても後ろに「?RssPage」って付けただけだけど。
Verbatim 機能は便利。 これがあるだけで Wiki への敷居が更に下がるのではないだろうか。
早速こちらもアップデート。（詳しくは YukiWikiInstallMemo を参照）
dc_date の件についても早速対応していただいている。（ツッコミも頂きまして恐縮です） なるほど，あんな風に記述すればいいのか。 他人のソースコードってのは参考になる。 RSS Autodiscovery 用のヘッダ情報もついているぞ。 作者の結城浩さんに感謝です。
さて NewsGlue を使うようになって少し経つわけだが， この RSS Reader， 結構形式にうるさいようである。 まぁ厳密に RSS の構文を解釈してるってことなのかもしれないけど。
まず， 記事を全く取得できないのが Noras の RSS。 他の Reader では取れてるので「おかしいなぁ」と思っていたが， RSS の中身を見てみると item 要素の rdf:about 属性が記事の URI ではなく RSS への URI になっているせいらしい。
あと時刻情報（dc:date）がうまく取れないのが Creative Commons の Weblog と MIYADAI.com Blog。 MIYADAI.com の方はそもそもフォーマットが違うのでしょうがない部分もあるが， Creative Commons の方は秒の単位が抜けてるだけでエラーにしてるっぽい。
確かにそれぞれ構文としては間違ってるのかもしれないが， ユーザとしては「それくらいうまく解釈してよ」と言いたい。 ほら， メールなんかでよく言うじゃない。 「送信は厳密に，受信は寛容に」ってさ。 これはインターネットの基本精神だと私は思う。 色んな人がいて色んなコミュニティ（ネットワーク）があるんだから。
そういや全然関係ないが， Outlook 系の MUA が今だに RFC2231 に対応していないのは本当に勘弁して欲しい。 まぁうっかりとはいえ日本語名のファイルを添付した私が悪いんだけど。 RFC2231 については対応している MUA の方が少ないみたいだし。
「高木浩光＠茨城県つくば市 の日記」の 2/22 の記事はなかなか考えさせられる内容である。 是非一度読んでみるべきだろう。 しかし今回は， 少し焦点をずらして「パスワードリマインダ」について考えてみる。
パスワードリマインダについては高木浩光さんの他の記事で詳しく書かれている。
最近パスワードリマインダを使う Web サービスをよく見かけるようになった。 実は cocolog もパスワードリマインダを登録させ「パスワードの再発行」で入力させる仕組みになっている。（ただし cocolog はパスワードを画面に表示するようなマヌケな事はしない） しかしパスワードリマインダというのはそんなにいいものなのだろうか。
日常的に使うパスワードと違いパスワードリマインダはトラブル時にしか使わない。 しかも「質問」と「答え」の両方を覚えなくてはならない。 パスワードを忘れたのならパスワードリマインダだって忘れているのが普通なのではないだろうか。 しかもパスワードリマインダは意味のある文字列になってしまうことが多い。（つまり辞書攻撃もどきで簡単に破られる） それではパスワードリマインダはパスワードより「弱い」ということになるのではないか。
意地の悪い見方をするなら， パスワードリマインダというのはサービス提供側が「パスワード」というセキュリティリスクを回避し， そのツケをユーザ側に押しつけるためのものと言っていいのではないだろうか。 はっきり言おう。 パスワードリマインダではセキュリティは強化されない。 単にユーザの（余計なものを「覚える」という）負担が増えるだけだ。 私は cocolog のパスワードリマインダなんてとっくに忘れている。 使わない／使えない機能はシステムを弱くするだけだ。 真剣にセキュリティを考えるならパスワードリマインダなど止めた方がいい。
アンテナとチャネルリスト（OPML）を整理。
アンテナで捕捉しているサイト・コンテンツのうち RSS を提供しているものについてはチャネルリストに載せ， アンテナからは削除した。 また RSS を提供しているサイト・コンテンツについては Bloglines で捕捉するようにした。 手書きのサイト以外はだんだんこういう風になっていくのかねぇ。
こうやって RSS でチェックするのが当たり前になってくると， 直リンクがどうのと言ってた時代が遠い昔のようだ。 となると最後まで RSS を採用しないのは新聞系マスコミサイトになるのかな （笑）
遠い昔の話だ。 私のときはバブル絶頂期だったし親もあきれるほどの放蕩ぶりだったので， こんな話には全く無縁だった。
でも， まぁ， 就職や転職について（当人にしろその親にしろ）戦略の甘い人ってのは今でもごろごろいるよな。 例えば面接で「いくら欲しい？」と言われて「年収1000万は欲しいです」と答える場合。 その1000万を稼ぎ出すのにどれだけのことが必要か分かった上で答える人はあまりいないような気がする。 常識で考えたってデスクに座って与えられた仕事だけをこなしているだけで年収1000万など「絶対に」稼げるわけはないのだ。 単に前の会社（きっと大企業だったのだろう）でそのくらい貰ってたから今回もきっと貰える筈だ， 程度の甘い期待で就職活動をする人達。
っていうか「自分でお金を稼ぐ」という感覚がないから自分の力量を正確に見積もれないのではないか。 自分を見積もれない人は永遠に「就職」なんてできない気がする。 「就職」ってのはあくまでも「職に就く」ことであり「入社」（もしくはそれに類する行為）は手段に過ぎない。 まぁ「入社」した先で「就職」できればそれはそれで幸せなことだけど。
なんてなことを今の学生さんに言うのは酷な話か。 私だって自分のことをそれなりに見積もれるようになったのは三十路に入ってからのような気がするし。 つまり私がちゃんと「就職」できたのは三十路以降ということか。 はっはっは。
ここのところ修羅場で毎日午前様なのだが， 頭は逆に冴えてしまって（ていうかナチュラルハイな状態）あまり眠れない。
無理矢理寝ようと思ったのだがうまくいかないので， おもむろに洗濯をはじめてみたり。 こうやってダラダラ書いてたら眠くなるかもしれん。 ってもう朝だけど。
SEO（検索エンジン最適化）は最近、「企業努力」として認められつつあるようだ。特に日本では、Webの改善の重要な方策のひとつとしてSEOが浸透してきているようだ。SEOを悪いこと、スパムだと考えるのは昔のことになりつつあり、Googleも日本市場ではSEOを認めつつあるようだ。
なんだそうだ。 「認める」って誰が誰に対して？ とかツッコみたい気もするが， それはともかく， 検索サービスにおける「ランク」というものがある程度操作可能なものでありサービス提供者もそれを許容する方向である， という解釈でいいのかな。
故に「自作自演サイト」も「Google 八分」も「Amazonの託卵戦略」も「アリ」なのだ。 ってぇことは， 「ランク」によるソート表示はそれ自体が（少なくともクリッカブル広告よりは効果的な）コマーシャルメッセージである， ということもできるな。 今更だけど。
結城浩さんがおっしゃる感覚は私にもある。 書いてる「私」と読んでる「私」が同居する感覚。 特にこの戯れ言において最も意識する読者は「私」だったりする。
対して cocolog の方はもう少し「外部」を意識するように努めている。 文体が「ですます調」なのもそのせい。 まぁ cocolog の方はこっちの本家より更に読んでる人は少ないと思うけど（統計をとってないので分からないが）， cocolog という（「コミュニティ」よりもう少し緩やかな）「場」を意識することで私も「外部」を意識し続けられるのだと思う。 いつまで続くのかは分からないけど。
他の Weblog サービスのことはよく分からないけど， cocolog って「ココロガー」みたいな感じで十把一絡げにされることが多いよね。 でも cocolog の本質って（NIFTY-Serve の時代からそうだけど）サービスの内部にいくつものコミュニティが重なり合って存在する「インターコミュニティ」ではないだろうか。 だからこそ「誤配」もあり得るわけで， そこが（分断された「島宇宙」なんかより）断然面白いと思うのだけど。
コミュニティてのは常に「外部」からの擾乱を意識し続けることに「存在理由」があるのであって， 閉じた世界で整然とした規範のもとに行動するなんて「終わってる」と思わない？
だからさ， 忙しいんだってば。 仕事ってのは谷があるから「山を登ろう！」って気になるんだ。 「山あり山あり山あり」じゃ疲れちゃうじゃない。 あと一ヶ月もこのペースで登り続ける自信はないぞ。
JIS X 0213 の話とか， オープンソースの話とか， 気になることはいっぱいあるけどもうどうでもいいや。
なんとWeb Matrix 日本語版が出てるのか。 あと一ヶ月早く出してくれれば... まぁそれでも採用はしなかったろうけど。
仕事で ASP.NET で Web アプリケーションを組むにあたり Web Matrix も試してみたんだけど， やっぱコード・ビハンドにできないのは致命的。 ASP.NET の構造って UI のコードとロジックのコードを物理的に分離できて初めて理解できるような気がする。
あと入門用に Web アプリケーションはヘヴィ過ぎないか。
Web アプリケーションって単独の技術じゃないよね。 HTML/XML が書けるだけではダメで， 少なくとも HTTP のプロトコルは知ってないといけないし， DBMS が絡まないアプリケーションは少ないだろうから DB の設計もできなきゃいけないし， そもそも3層の M/W 構造が理解できないと設計できないだろう。
また Web のセッションと DB のセッションについてもちゃんと設計しないと大変なことになる。 特に DB セッションの設計は頭の痛いところだよね。
更に ASP.NET ならサーバサイドの言語として VB.NET, C#, J# 等々を選択（または組み合わせ）しなくてはならないし， クライアントサイドには VBScript や Javascript がある。（まぁ今時 VBScript の必然性はあまりないと思うが） .NET Framework は言語に依らない開発スタイルを「売り」にしているが， それはつまりユーザ側が言語を「選択」しなくてはならないことを意味する。 「選択」できるためにはそれらを知っていなければならない。 趣味でやるなら好きな言語を選べるかもしれないが， 業務なら「選択」の根拠を（上司やエンドユーザに）示す必要がある。 そうそう DB を使うなら SQL も使えなくちゃ。
そうそう， ASP.NET ならオブジェクト指向の設計が要求されるし（ASP みたいな五月雨式のコードは書けない）， イベント・ドリブンだからシステムの状態遷移を設計し把握する必要がある。
これだけのことが「入門」レベルで果たしてこなせるのか？ しかも上の例示はセキュリティに関する検討が一切含まれていない。 もしこなせるのならその人はかなり優秀だと思うが， その頭脳を Web アプリケーションのような繁雑なシステム設計に使うのは勿体ないと思ってしまうのであった。
よく「Web アプリケーションで開発期間を短縮」なんて宣伝文句があるけど， とんでもないよね。 短縮できるのはせいぜいフロントエンドまで。（何故ならスキルのみで技術が不要だから） M/W からバックエンドにかけては従来よりむしろ繁雑になっているように見える。 したがって要になるエンジニアが繁雑なシステムをちゃんと見渡して把握していないと簡単にプロジェクトが破綻する。
これからプロのエンジニアを目指す方々へ。 無理しなくていいから， まずは個々の要素技術を身につけて経験をしっかり積み上げることだ。 得手不得手があってもいい。 「何事もそこそここなせる」だけの器用貧乏じゃ（バブル時代のように）「30歳定年」に追い込まれるぞ。
逃避して『日経バイト』 3月号を読む。
RFID の特集記事があるのだが， なかなか面白い。 主に技術面における課題が挙げられているが， これを見るだけなら「実証実験」から「実運用」までの道のりはかなり厳しいように思える。 プライバシー関連の記述はなし。 まぁ経産省や総務省で色々動きがあるようなので， 今後はその辺をベースに議論が展開されるのだろう。（物凄く楽観的な見解）
そういやここのところたて続けに「ウイルス警報」（NAI のメールニュースを利用しているもので ← Web バグが仕掛けてあるので注意）が出るのはどうしたものか。 発病後の動作は悪質なものが多いが感染経路はいたってオーソドックスなものだし何で大流行するのか分からん。 『日経バイト』 3月号には最近のメール媒介のウイルスにはソーシャルエンジニアリングを巧みに使っているといった記事が書かれているが， うちに来た奴は「いかにも」なメールで分かりやすかったけどなぁ。
「Eメール禁止令」（実際には電子メールそのものではなくファイル添付を禁止するらしい）なんて話もある。 ウイルスは対策可能なのだ。
中国の外注と打ち合わせを行うために MSN の IM を入れさせられてしまった。 とほほ。
これで IM のアカウントがふたつになってしまった。 でも MSN の方は内緒。 仕事で使う奴だからね。 Yahoo! のは結局全然使ってない。 そういえば ICQ の時もすぐに飽きちゃって止めたんだよなぁ。
よかったと思う職業エンジニアの方々は結構いるに違いない。 いつもの年度末の風景。（週末なのに出勤してるあなたですよ）
って， 既に破綻してるプロジェクトにとっては1日くらい増えたからって大して影響はないんだけどねぇ。（他人事じゃない）
ISBN ってあんな短い数字列でどうやって管理しているんだろうと思っていたが， なんだやっぱ全然足らないんじゃん。 だから最近の本ってすぐに絶版になるのか。（ちょっと違う？）
NBN ってのもあるらしい。 面白そうだな。
（追記） 記事の続きが出てた。
オープンソース絡みの話が盛り上がってるなぁ。 私は昨年夏ごろに（失礼な発言も含めて）さんざん書いたので， もうお腹一杯だけど。
ある人達にとって唯一または至上の定義・基準・規範・価値観であっても別の人達にとっては（空間および時間において）局所的なステータス（状態）に過ぎない。 言葉の問題は特にそう。 「これは SF じゃない」とか「そんなのはオタクじゃない」とか「ハッカーはクラッカーじゃない」とか， 過去にあったその手の論争と本質的にかわらないのではないか， と思ったり。
で， そういった状況を排除しようとして「啓蒙」したりするのだが， 啓蒙が有効な範囲というのは（今や）身内周辺でしかない。 もちろん一時的に目につかなくすることはできるだろうが， ある日突然「黒いたんぽぽ」がいっせいに芽を吹き出したりするのである。