• 【レビュー】Windows環境で手軽にBTRONの世界を体験できる「BTMemo」(1) - http://pcweb.mycom.co.jp/news/2003/04/25/22.html

WikiMemoに他のデータフォーマットを埋め込む仕組みをどう表現しようか考えていたんだけど、こういう方法は一つの解決策なんだよな。ただ、WikiMemoの基本コンセプトは、プレーンテキストベースで気軽に編集しつつ、表示時にはそこそこリッチな表現が可能となるってあたりだから、こういうサムネイル系の表現は使いたくない。

で、今のところInterWiki的表現かURL（プロトコル名://****）表現で他のデータフォーマットの埋め込みをサポートしようかと思っているんだけど、いまひとつきれいじゃないんだよなー。でもまあ、NTFSのハードリンクを使ってファイルの実体とは別に、リンクファイルだけを管理下のフォルダに集めることによって、テキストベースで簡便な表現を使ったファイルの埋め込みをサポート出来そうな気もしているんだけど。

• 米Apple音楽製品発表会(2) --- 1曲わずか99セント、iPodへの転送は無制限 - http://pcweb.mycom.co.jp/news/2003/04/29/51.html

うーん、困ったなー。マイクロソフトのアプローチよりもソニーのアプローチよりも、デジタル音楽配信に関してはアップルのアプローチの方が好みだ。Windows＋日本語対応iTuneが発表されたらアップル支持に転向するべきだろうか。そうなると、今まで出来るだけ見ないようにしてきたQuickTime関連技術もちゃんと追うようにしないといけなくなるな。というか、次のノートPCの選択肢として真面目にiBookを考えるようになってしまうのか。

• サンが「バーチャル秘書」を開発中 - http://www.zdnet.co.jp/enterprise/0304/30/epn07.html

メールソフトと連携し、シンプルなテキスト管理＆検索を中心に実装したPIMソフトが欲しいなーといろいろ考えていたんだけど、この記事を読んで思いついたアプローチ。Becky!なんかにはクライアントレベルでのメールの転送設定が用意されているけれども、それを有効活用するとさらにいい感じになるかも。

基本はテキストベースのPIMツールで、シームレスにメールの送受信が出来る（Emacsみたいだな）。で、メールの送受信に関するフィルタリングが常時裏で走っている。PIMへの各種登録は、メールを介して行うことによって、複数クライアントでの同期を行う。また、メールに各種コマンドを埋め込むことによって、より高度な機能も実現する。会社のマシンのローカルファイルの転送（ファイルサーバー的）とか、会社のアドレスを使ってのメールの返信とか。なんでも出来るようにするとセキュリティ的にぼろぼろになりそうなんで、開ける穴は慎重に選定する必要があるだろうな。認証回りの仕組みをそれなりにセキュアにするのが一番難しそう（でもまあしょせんあんまりセキュアじゃないメールベースだし）。マイクロソフトのExchangeとどこが違うのかというと、基本的にテキストベースの軽いデータだけを扱い、機能の実装はクライアント側の処理だけで行おう（サーバーはいらない）というところか。QuickMLみたいなアプローチとうまく連動させるともうちょっといろいろ可能性が拓けるかな。

• Villeneuve thinking about leaving F1? - http://www.f1-live.com/en/headlines/news/detail/030501175138.shtml

ジャックは嫌いじゃないけれど、今のBARのジャックはつまらない。チームもドライバーも契約に縛られてぐずぐずになっていた感じだったからな。チームは現状のマシンに高額なジャックを乗せるのは意味がないと知りつつも、デビュー1、2年でトップチーム入りしている予定だったのでジャックと長期契約を結んでしまっていて、その違約金を払うよりはまだジャックを乗せ続けた方がマシという状態だったんだろうし、ジャックはジャックで毎年毎年走らないマシンに不満を覚えながらも、CARTに戻る気にはなれないしBARよりもいいチームからは声がかからないし、消極的な選択として残留し続けてきただけだろう。BARが来年劇的にいい車を作れるとは（たとえホンダ純正チームになったとしても）思えないから、ジャックはあっさりチームを離れて欲しいな。どうせならば早めにチームを離れる決意をしてシーズン途中から琢磨にシートを譲ってくれたりしないかなー（←それが本音か）。

• Gartner Column：第91回 いいとこどりアーキテクチャのNUMAとRAC - http://www.zdnet.co.jp/enterprise/0305/06/epn28.html

メモリの大部分をDBアクセスが利用しているような場合ならば、NUMAみたいなアプローチで十分高速に動作させることが出来るのかな。エンタープライズ系でNUMAとRACは抑えておいた方がいいキーワードっぽいな。

• レコード会社、海賊行為“攻撃”ソフトを開発支援 - http://www.zdnet.co.jp/news/0305/06/xert_label.html

これはもう戦争ですか。いったいどのレベルに割り込んで監視して、それを海賊行為だと判断し、攻撃を実行するロジックを組むつもりだろう。正義のクラッカー支援中って感じ？　その正義は多分ごく少数にとっての正義だろう。

• RFID機能無効化のスイッチ導入へ - http://www.zdnet.co.jp/news/0305/07/nebt_11.html

勝手にRFIDを無効化するクラックとかの対策をするのが大変そうだな。普及させるためには実装コストを下げなければならず、そうすると対策もある程度シンプルにならざるを得ず、そうするとある程度破られるリスクのある実装にならざるを得ず……と想像してしまうのだけど。RFIDに依存したシステムが動いてしまうと、RFIDが必要な状況においてRFIDが無効化されてしまうリスクというのは結構大きそうだしな。「非接触読みとりは無効化されるが、接触読みとりは可能」とか出来るかな？　ってそれじゃーバーコード併用とかになっちゃうか。

ちょっとした思いつき。

Wikiみたいにリッチな機能を持つWebアプリケーションで、リッチな機能に対応するインターフェース（リンク、ボタン）を常時表示しておくのはうざい。かといって、いちいち認証を通さないとリッチなインターフェースが表示されないのはうざいし、リッチなインターフェースとプアなインターフェースのページをそれぞれ別に作るのは面倒くさいし、切り替えを簡便化するために権限認証Cookieを使って表示内容を変化させるのはちょっといやだ（認証Cookieはできるだけ狭い範囲で有効になるようにしておきたい）。

というときに、まるで認証Cookieのように動作するけれども、実際には認証とは関係ない、表示切り替え専用のCookieを使って表示内容を制御するというアプローチは有効そうだ。Cookieで表示するスタイルシートを切り替えられるようにしているサイトがあるけれども、あれみたいな感じ。

ただ、そこで切り替えられる表示内容には、権限との相関関係が強いインターフェースが多く、まるで「表示モード切替＝権限認証」のようにみえるだろう。具体的にいうと、モード切替で「一般ユーザーモード」を選択すると非常にシンプルなインターフェース（表示関連のリンク）しか表示されず、「編集者モード」を選択すると「編集」や「履歴」のような高度なインターフェース（リンク）も表示されるようになるイメージ。

しかし、内部的には権限認証と表示モード切替とは完全に切り離されている。だから、その表示モード切替のCookieが盗まれたところで、実際の権限認証とは無関係だ。一般ユーザーが「編集者モード」とか「管理者モード」を選択しても問題ない。ただ単に（一般ユーザーにとっては）不必要なインターフェースがたくさん表示されるだけだ。

いやまあなんてことない話なんだけど、Wikiでそういう風な実装をしている例ってあんまりないかなーと思って。Wikiに限らずWeb日記システムとかでも似たようなことが出来るよね。というかWebアプリケーション一般に適用できるか。要は、権限の実体とインターフェース（表示）は意味的には同じに思えるけれども、実は分離して管理してもいいよね、という話。Wikiのような、管理者・一般ユーザーの境目が不明確なシステムでは特に。

• Visual Basicがすたれていく - http://www.zdnet.co.jp/enterprise/0305/07/epn08.html

個人的にVB.NETの方がC#よりも好きなんで、VB.NETの利点・欠点を並べつつ宣伝しておこう。

VB.NETは、VBと名乗っていてVB文法とか昔のVB関数とかが使えるけれども、実際にはとてもちゃんとしたオブジェクト指向言語として作り直されている。もしも、VB.NET以前のオブジェクト指向サポート版VBを使ったことがあり、「あんな腐れオブジェクト指向もどき言語なんか使ってられるか！」と思っている人（過去の俺も含む）は、VB.NETはそれらとは別物であると認識し直して欲しい。とてもちゃんとしたオブジェクト指向言語に生まれ変わっている。C#がJavaを参考に新規に（後発で）作り直された洗練された言語であり、VB.NETはC#の記述力（言語仕様）をほぼそのままVB文法上に再現した言語だと考えると、その言語仕様の洗練度合いが想像できると思う。大元の言語仕様設計者はDelphi（Object Pascal）の人だし。

ただし、VB.NETはあくまでもC#が先にあって、それをがんばってVB文法に移植したものなので（多分）、C#と比べるとちょっとだけ劣る。C#で実現されている言語仕様のほとんどはそのまま使えるように移植されているんだけど、ごくわずかC#では使えるけれどもVB.NETでは使えない要素があったり、あるいは使えるけれども使い方が面倒くさかったり、あるいはC#ではちゃんと動くのにVB.NETではバグっている部分があったりする。でもまあそれは本当にごく一部でよほど運が悪くない限りはそういう要素に行き当たることはないだろう。

C#はJavaに似すぎている。そのため、Javaも使わなければならない人は、混同してしまう可能性がある。VB.NETの場合は言語仕様は似ているものの記述スタイルは全然違うので、混同してしまう可能性は少ない。というのは別の言い方をすれば、C#はJavaに似ているのでほとんど同じ知識を流用できる、ともなるけれども、俺の場合は違っていることの利点の方が大きい。でもまあ普通の人にとっては、似ていることの利点の方が大きいかな。

VB.NETはC#と比べると言語仕様的にコード量が少なく記述できるようになっている部分が多い。というのは、Visual Studio .NETの助けを借りることが前提なのだが、改行によって1命令が分離される言語スタイル＋Visual Studioの入力支援によって、非常に多くの場合C#よりも少ない打鍵数でコードが入力できる。これには、VB.NETが大文字小文字を区別しない（ケースインセンシティブ）ことも貢献しているだろう。VB.NETでは、かなりアバウトにコードの一部を記述するだけで、その後に続くコードを自動補完できる。ただし、Visual Studioを使わずに入力した場合は、ブロック構造を中括弧で済むC#と、IF〜END IFのようなVB.NETでは結構差が出そうだ。Visual Studioを使えばその手のコードはすべて全自動で入力されるのだけど。

と並べてみたけれども、読み返してみると自分でもC#とVB.NETを比べて特にVB.NETを選択する意義があんまり感じられない文章だなー。俺の場合、もともとはC#を使いたかったんだけど、仕事でVB.NETを使わなければならなくなったんで、しょうがなくVB.NETを使い続けているうちに、C#と両刀遣いする気力がなくなった（VB.NETで書いてうまく動かなかったコードを、試しにC#で書き直して動作確認したりする程度）のに、後付けで理由をつけている感じだからなー。でも個人的には今後もVB.NETを使うつもり（私物としても買っちゃったし）なんで、廃れないで欲しいなー。

• ウェブログに見る日米個人サイトコミュニティ事情 - http://www.zdnet.co.jp/news/0305/07/cjad_horikoshi.html

この記事における米国でのblogに関する歴史的経緯および現時点での多くの人々の認識というものがどれだけ正しいのかよく分からないけれども、blogの特徴が結局、

>ウェブログとは、リンクによって力を持たない個人が情報の伝播に関わることができる

というあたりにあるのならば、俺にとってはそれはblogでもなんでもなく、単に「Webの特徴」に過ぎないように思えるよ。あるいは「個人Webサイトの特徴（可能性）」か。どうもblogを持ち上げる人々がいうところのblogの利点は、「Web」あるいは「個人Webサイト」がはじめから持っていた可能性を、まるではじめて発見した（あるいは発明した）と言っているように見えるんだよな。

もちろん「blogはムーヴメントである」という捉え方をすれば、blogという言葉および現象が流行ることによって、「可能性が具体的な事例を伴って一般の目に触れるようになった」とか、「質的な違いではなく、量的な違いが現れてきた」ことは確かだろうけど、量の違いなんかで昔からあったものを「新発見」とか「発明」されちゃっても困る。

しかも、量的な違いというのも「メディアへの露出や（広告的な）名詞の頻出」という虚名が爆発しているだけのように見える。

もちろん実体（＝blog運営サイト）も増えているんだろうけど、それは単にblogという名前を冠したものが増えているだけで、別にblogなんて名詞を使わなくても、Webサイトあるいは個人Webサイトというくくりで語っても大きな違いはないものにみえる。日本でも今までblogと名乗らずに運営されていたサイトが（blog系CMSを採用するとともに）blogと名乗ってみたり、商用サイトのコラムとか編集後記的なものを（blog系CMS上で運営することによって）blogと名乗ったりする例が見られるけれど、それは単に「blogと名乗っているだけで昔からあったもの」に過ぎないだろう。

あと、個人Webサイトを集約してそこに集合としての意味を見いだそうという試み（というか、単にそういう使い方）については、日本でもWeb日記コミュニティやWeb日記リンク集を舞台にしてもいろいろ行われてきたわけだけど、セマンティックWeb的技術が実用化されつつある状況において、blog系CMSがその手の個人Webサイトの情報をデータベース的に集約する仕組みを積極的にサポートしようとしているあたりは、技術的な観点におけるblogの特徴として大きい気がする。あんまりきれいじゃない（仕様がまとまりきっていない）けれども使えるならば使っちゃえ的な。別にXMLなんてなくたってそういうものは作れるけれども（一応HTMLだって構造化文書だし）、あると便利なのは確かだからな。

と元記事の内容から離れた話を延々としてきたわけだけれども、最後の日米の違いについて、

>片や、ツールの登場によって同形態のサイトが一気に広まったために、企業をも巻き込んで1つの大規模なコミュニティとして社会的に認知されているウェブログ。片や、歴史が古いために小さなコミュニティが、統一されることなく独立して育った日本の個人サイト。

という分析は興味深い。それは大げさに言うと「blogムーヴメントの中核は、サイトの（デザイン）フォーマットが統一されていること」になるのか。

俺は個人Webサイトにおいてはblogツールが標準で提供するユーザーインターフェースはあんまりよくないと思っているんだけど（個人Webサイトレベルではリッチすぎて使いにくい）、大手商用サイトっぽいUIに統一することによって雑多なWebサイトに商用サイトっぽい雰囲気をもたせ（イメージ戦略）、それらに共通のブランド名「blog」を名乗らせる（CI戦略？）ことによって、ムーヴメントを作り上げることが出来る、とか。

最近のtDiaryのテーマファイルをサポートするCMSが増えて来つつある状況と照らし合わせると面白いな。そういうものにブランド名を付けて流行らせよう。