トップ «前月 最新 翌月» 追記

2002|01|02|03|04|05|06|07|08|11|12|
2003|01|02|03|04|05|06|07|08|09|10|11|12|
2004|01|02|03|04|05|06|07|08|09|10|11|12|
2005|01|02|03|04|05|06|07|08|09|10|11|12|
2006|01|02|03|04|05|06|07|08|09|10|11|12|
2007|01|02|03|04|05|06|07|08|09|10|11|12|
2008|02|03|04|07|

2003-04-02 [長年日記]

_ 終わりの始まり (13:49)

自由時間は終わりを告げ、再び地獄の日々が始まった模様です。もうちょっと後になるかと思っていたのに、昨日打ち合わせに行ったらそのまま8時間拘束コース＆明日からよろしくとなってしまったよ。今度の出向は前にも増して長そうだ。最短三ヶ月、最長六ヶ月ですか。でもまあ今回は仕事内容に関してまったく責任を感じる部分はないので、出来るだけがんばらないようにがんばろう。

_ 何もできん (13:49)

出向モードになったら見事に何もできなくなったのー。ローカルWikiは地道に作って、ひとまず最低限の機能は動くようになったんだけど、隙間隙間で細切れに作っているせいで細部の詰めがゆるゆるだ。でも普段のメモをWiki記法で書いたり出力したり出来るのは結構便利っぽい。ローカルWikiのデータをWeb上のWikiLikeと同期を取れるようにしようかなー。公開フラグを立ててそれで同期を取るか、それとも公開用の別プロジェクト（ディレクトリ）を用意する方法にするか悩むな。とか思っても実装できるのはまだまだ先だ。ひとまずローカルでのメモ用途で使いやすいレベルまでは作ってしまおう。

_ VB.NETのWebBrowserコントロールのバグ (13:49)

どうやらVB.NETではWebBrowserコントロールのBeforeNavigate2イベントがきちんとハンドリング出来ないらしい。その他のイベントは普通にハンドリングできるのに。

下記が公式バグ情報で回避方法も載っている。

[ツッコミを入れる]

2003-04-04 [長年日記]

_ 夜の青山墓地 (13:49)

昨日は出向先の花見で青山墓地へ。スタートがずるずると延びて21時半頃にスタート。寒い。酒を飲んでも体が冷える一方。途中で抜けて帰る頃には、花粉症とは別の鼻水が出始めたのでした。こんなんでみんな風邪を引いたら、ただでさえ間に合いそうもない仕事がさらにやう゛ぁくなるね（はぁと）。

[ツッコミを入れる]

2003-04-05 [長年日記]

_ 2003F1ブラジルGP (13:49)

予選1日目

今回は雨なのね。現在のレギュレーションにおける予選1日目の意義としては、本来の（軽い燃料＆予選専用セッティングでの）フルアタック時の各マシンの能力差が比較できるってことくらいしかないのに、それが雨だとその意義もほとんどなくなっちゃうな。しかも、路面状態がどんどん変化していっちゃうし。と思ったらミハエルが出たとたんに大雨になったの。本当に今回はマシンの実力が出にくい予選方式だな。

バトンがインテル（の宣伝発泡スチロール兼ドライバー側から見ればブレーキングポイント表示）を破壊した。インテル的には目立ってうれしいのか壊されて悲しいのか？　予備の看板って用意されているのかな？　特注品っぽいけど。

なんなんだろう。路面状態がよかったとしても、ジャガーが変によかったなー。

予選2日目

あら、晴れちゃったのね。話がややこしくなるなー。

なんかモントーヤがあまり速くないのはなぜだろう？　戦略なのかセットアップの方向なのかセットアップの失敗なのか、予想できないなー。

おお、フィジケラ、トップタイムだ。ラルフも今回はがんばったな。

ルノーはえーなー。トゥルーリ−ルノーって組み合わせは、ちょっとティレル−アレジを思い起こさせるものがある。ハンドリングカーと速いドライバーって組み合わせは見ていて面白い。

おや、ミハエル3番手か。マシンの能力的にはもはや突出したものはなくなったんだな。

クルサードはえー。というかマクラーレンが速いのか。ライコネンも最終セクションの速さがめちゃめちゃだな。

おお、バリチェロがんばった。ミハエルと全然違う戦略をとったんだな。ミハエルは天候が崩れても大丈夫な確実性を取って、バリチェロは天候が崩れたらぐだぐだになりかねないリスクを背負っている感じか。

ウェバーがんばったなー。でもどうせならポール取っておけばよかったのに、もったいない。どのくらい燃料が少ないのか知らないけれども、走っている雰囲気から基本的にバランスがいいことは確かだし、これでスタート時の燃料が少ないことがマイナスにならない天候になったら、優勝できるマシンではありそうだ。

決勝

あら大雨だね。スタートまでディレイになった。セーフティカースタートか。ピットスタートで満タンを選んだマシンは本当にいい結果が出るかな？　1周目からピットストップして満タンにする車もいるのか。

セーフティカーラップなげー。眠いー。

おやフィジケラ中途半端なタイミングで動いたな。

9周目でようやくセーフティカーが消えた。とたんにクルサードが抜いたか。バリチェロというかブリジストンがきついのかな？　クルサードとの差はおおきいなー。おお、ライコネンも抜いてきた。マクラーレン1−2か。

おお、クルサードとライコネンの闘い熱いなー。モントーヤも絡んでくるし。というあたりを見ると、やっぱりブリジストンがダメなのか。

あら、ラルフとルノーが絡んだのか？　それとも単独スピンをよけただけか？

バリチェロ、ミハエルにまで抜かれたのか。そういやバリチェロって予選の時にウイング寝かせ気味なセッティングだったっけ。その辺が関係しているのかな？

コースコンディションがよくなってミハエルが速くなってきた。ミハエルはこうやって後方から追い上げる展開の方が面白いな。

ファーマンどうした？　突然タイヤが外れたけど。うわー、本当に車が勝手に壊れたのか。ウイングが飛ぶパターンは何度か見たけれども、フロントサスペンションが突然砕けるってのは始めて見たな。パニス不運だ。ってところでまたペースカーか。

うわー、モントーヤとピッツォニアのリタイアもわけわからねー。モントーヤが先に単独でコースアウトリタイアしているところに、たまたま後ろからピッツォニアがまた単独でコースアウトしてつっこんでいったのか。

あら、ミハエルまでモントーヤとピッツォニアのお友達になってしまった。ミハエルがこういう自滅するのって珍しー。というわけでまたペースカーが入る。

フェルスタッペンとバトンもお友達。そして再びペースカー。面白いんでこのまま最後まで見ちゃうのかな。明日つらそうだ。

ウェバーあとちょっとでお友達。

おお、バリチェロ、クルサードを抜いたか。いいところ見せれたじゃないか。あとは自滅しなければって感じかな。いや、ドライタイヤに交換するタイミングでまだまだ変わるか。

あららららら、バリチェロ残念。なんで？　バリチェロってなんでこう、ここで勝っておけばグレイトドライバーになれるってところで必ず勝てないのかなー。

おお、フィジケラおいしいポジションに来たな。

フィジケラとうとうトップ。と思ったらウェバーすげークラッシュだ。ストレートに向かって加速しきったあたりでどかんか。と思ったらそこにアロンソがフルスピードでつっこんできてさらに激しいクラッシュかよ。アロンソ怪我をしたっぽいな。意識はあるけどひどい打撲かな。骨折くらいしちゃったか。で、結局赤旗中断＆レース成立なのね。

ライコネン、フィジケラ、アロンソ、クルサード、フレンツェン、ヴィルヌーヴ、ウェバー、トゥルーリか。荒れたレースだったなー。でもマクラーレンがポイントをきっちり稼いでいるなー。

フィジケラ運が悪いというべきか。せっかく実力で抜いたのにね。まああのまま最後までトップをキープできたかどうかは微妙だし、2位というポジションまであがれたのは運が良かったからだしなー。

アロンソ2戦連続表彰台か。でもこうやって病院に運ばれちゃうと、絶好調のときに骨折して、その後いまいちになってしまったパニスを思い浮かべてしまう。

あーあ、もう5時過ぎてるよ（タイムスリップ録画で見ていた）。今日は会社で寝よう。

_ TrackBackの図解 (13:49)

www.textfile.org（http://www.hyuki.com/tf/）に

>ところで、誰かTrackBackを図解してほしいなあ

とあったので試しに図解しようと試みてみた。

TrackBackの概要図:http://mylog.ishinao.net/img/trackback_fig.gif

けれども、想定読者が設定できない状態で図解するのは難しいや。ということで、作りかけで放置（多いな、このパターン）。ある程度分かっている人が見れば多少わかりやすくなるかな？

ちなみにExcelで作った図をhtml形式で出力したデータなんで、HTML版は最新のブラウザじゃないと読めない可能性大。WindowsのIE6と-[Mozilla7]-Mozilla 1.3では読めていたっぽい。

[ツッコミを入れる]

2003-04-06 [長年日記]

_ WikiMemo (13:49)

ローカルWikiはWikiMemoという名前に変更。この土日でなんとか個人的な実用には耐えられるレベルまで来たかな。

ちなみに動作環境は相変わらずWindows 98以降＋.NET Framework。って環境を用意してまで使いたい人っているのかな？　ソースも公開してもいいけど、VB.NETで書いたソースなんかを使いたい人っているのかな？

ひとまず画面だけ公開して反応を見てみることにしよう。

WikiMemo開発版。WikiMemo030406.gif

[ツッコミを入れる]

2003-04-07 [長年日記]

_ 日本語WikiNameのURL from yuco.net/diary (13:49)

>「新現実」に「ローレンス・レッシグ情報」として載っていたURLはこれである。 > >http://www.yuco.net/wiki.cgi?%A5%ED%A1%BC%A5%EC%A5%F3%A5%B9%A1%A6%A5%EC%A5%C3%A5%B7%A5%B0 > >こんなURLを載せることに情報価値があるとは思えない。誰がこれを見てキーボードから入力しようとするね。でも他にどうしようもないしねぇ。これは日本語WikiNameを使う場合の問題点だなと思ったのでいちおうメモ。

WikiのページをWeb以外の媒体で紹介してもらう場合には、Wikiの検索ページのリンク＋検索キーワード文字列（＝ページ名）として紹介してもらうのがスマートだろうなー。

うちとかだと、適当に右上の検索ボックスにページ名を入れてもらえば、完全一致すればそのページの内容が出てくるし、部分一致ならばページ一覧が出てくる。たいていのWikiには検索機能はあるだろうから、それに単独でも（そこへ直接飛んできたWikiを知らない人が）使えるようなナビゲーションを用意してあげる感じにしておくのが、ユーザビリティが高いかな。

あるいは、うちみたいに内部管理用のシンプルなID表現も持っておいて、Web以外の媒体で紹介する場合はそちらを使ったリンク文字列を使ってもらうという手もあるな。Wikiにはエイリアス（別名）を使えるものも結構あるから、それを使ってわかりやすい表現のURLを用意するというのも似たような対応か。わざわざ静的なHTMLで紙メディア向けリンク集ページ的なものを用意しておくという手もあるけど、Wikiを使っていてわざわざそんなものを用意するのはちょっとバカらしい気もする。

といった感じで、現時点でもいろいろ対応方法は思いつくけれども、今後はWikiEngineを作る際にこういう事態への対応方法をあらかじめ意識しておいた方が良さそうだ。

[ツッコミを入れる]

2003-04-09 [長年日記]

_ 塚烈婦利 (13:49)

昨日はなんだかえらく疲れた。一番面倒くさい対人折衝系をパスして、ひたすら設計とコーディングをしていただけだったのに、この塚烈婦利はなんだろう。ってATOKすごい変換するな。「疲れっぷり」ね。23時前には家に帰り着いて飯を食ってそのまま寝たら、朝まで身動き一つせずに熟睡した。体の体重がかかっていた側が重い。いや体重が重いからじゃなくてね。

[ツッコミを入れる]

2003-04-10 [長年日記]

_ やっぱり暇がない (13:49)

この状況は今週いっぱいくらいで済むのかなー。それともまさか6月末くらいまでかかる？　冗談じゃねーよなー。

一応個人Webページ系は最低限チェックできているんだけど、面白そうなネタがあっても反応する余力がない。いろいろ興味深いネタはあちこちに転がっていたのに。あと、TrackBackの図解をしたことによって、現状のTrackBack仕様の欠点をわかりやすく説明できそうなんだけど、それも書いている暇がないなー。とか書いている間に書けばいいって？

ニュース系のチェックなんてもう何日分もたまったままだ。自動収集データベースにはもう300件くらい記事がたまっている。目を通す価値がない記事はタイトルレベルで削除済みなんで、残っているのは最低でも目を通すネタか。そんなんいつ見ていられるんだろうなー。

そんな中でもWikiMemoは地道にちょっとずつ改良＆機能強化中。でも、肝心のレンダリングエンジンの書き直しはまだ手をつけていられない。これが出来たらWikiLikeにもフィードバックする（移植して使い回す）予定だからきちんと設計して作りたいんだけど、最近は仕事で設計脳を使い切っているんで、余暇にはメソッド単位の設計脳しか働かないや。

[ツッコミを入れる]

2003-04-12 [長年日記]

_ ところではっつぁん、なんだいくまさん (13:49)

tdiary、Wiki、関心空間のほかには、ishinaoに注目しています。

と書かれると、まるでishinaoという組織あるいは団体があるみたいだなー。なんでばれちゃったんだろう。

本当のところをいうとishinaoってのは実は複数人からなる団体なんです。中心となっているのは開発系を担当している1号で、その他書評を担当している2号、ニュース記事を担当している3号と4号、あとグループのマスコットであるロリータ108号もときどき日記を書いています。みなさん驚きました？　私も初耳だったんでびっくりしました。

というわけで、この文章はishinao1号によってお届けしました。じゃあ3号と4号、あとはよろしく。おお、まかせろ。と一人芝居をやっていると高座に座っている気分になれますね。ところではっつぁん、なんだいくまさん。

_ Linux搭載のROMカートリッジ「Magic NC」のノートPC版が発売 from MYCOM PC WEB (13:49)

大容量バッテリーを搭載したmobioが余っているから、あれにこれを搭載すると結構良さそうだな。有線・無線LANカードも余っているし。と思いつつも、具体的に何に利用するといいのかいまいち思いつかないなー。しいて挙げれば、普通のPCが置きにくい場所（キッチンとか）に設置しておいて、常時Google検索マシンみたいな感じにするとか？

_ 乗りこなすより売る方が難しいSegway HT from ZDNet (13:49)

技術的には画期的だけれども、しょせんは車輪で走り（荒れた路面に弱く）、一人乗りで、屋根がない（悪天候に弱い）乗り物だからなー。となると現在使われている乗り物の中では、自転車やバイクの代替あたりがターゲットになるわけだけれども、値段が違いすぎてその土俵では戦えない。

自転車やバイクと戦える価格帯まで下りてくるか、あるいはセグウェイならではのメリットを活かせる新しい市場（用途）を開拓する必要があるだろう。

今のところセグウェイならではの用途として一番使えそうなのは、目新しさ＆乗り心地を活かしたエンターテインメント市場だろうけれども、その市場であの価格帯だとどう考えても数が出ることはなさそうだよなー。

_ Javaがわかるはずがない from 圏外からのひとこと (13:49)

オブジェクト指向のいやらしさは、howとwhyがつながらないことだ。classやinterfaceを教えられた時、最初は、それがどういう動きをするのか悩むだろう。確かに、これはifやforよりはややこしい。単純なサンプルでも長くてなかなか追えない。だが、howに徹してじっくり読めば初心者にもわからないものではない。

なるほど初心者にはそのあたりが分からないのだという認識を持っておけば、コミュニケーションを取りやすくなるのかな？

となるとオブジェクト指向入門的な文章を書く場合には、オブジェクト志向のプログラミング技術的な使い方よりも先に、その作業上の具体的なメリットを実例で紹介するのがよさそうだ。DogクラスがNameというプロパティとRunメソッドとWalkメソッドを持つとか言われたところで、「だから？」って感じだもんな。

それよりも、まず「Pochiという名前と1次元の位置情報を持つ犬がいる。位置情報を+3する。名前をChobiに変更する。さらに位置情報を+1する」コードを書けという例題を出す。するとまあ、

$name = "Pochi";
$x = 0;
$x = $x + 3;
$name = "Chobi";
$x = $x + 1;

みたいなコードが出てくる。

それを今度は、「犬を5匹に増やせ」とか「犬に生年月日と性別と……という情報を持たせろ」という。すると、多分配列を使ってn匹の犬を表現したり、構造体を使って1匹の犬あたりの情報をまとめて扱えるようにしたりする話が出てくる。

structure struct_dog {
  $name = "Pochi";
  $x = 0;
  $gender = "male";
  $birth = "2002/3/4";
}

var $dogs[5] as struct_dog;

$dogs[0]->x = $dogs[0]->x + 1;
$dogs[3]->name = "Chobi";

for each $dog as $dogs {
  $dog->x = $dog->x + 3;
}

んでもって今度はさらに、「位置情報を+3することをRunという関数で表現し、位置情報を+1することをWalkという関数で表せ」とかいうと、機能を関数単位で記述しつつ、処理したい対象となる変数を引数として渡す話が出てくる。

var $dogs[5] as struct_dog;

Run($dogs[0]);
Walk($dogs[1]);

function Run($dog) {
  $dog->x = $dog->x + 3;
}

function Walk($dog) {
  $dog->x = $dog->x + 1;
}

んでもって、結局犬に対して処理を行う関数をたくさん用意するのならば、構造体で変数をまとめるだけでなく、関数をまとめる仕組みもあった方がわかりやすいよねってことで、

class class_dog {
  $name = "Pochi";
  $x = 0;
  $gender = "male";
  $birth = "2002/3/4";

  function Run() {
    self->x = self->x + 3;
  }

  function Walk() {
    self->x = self->x + 1;
  }
}

$dog = new class_dog();
$dog->Run();
$dog->name = "Chobi";
$dog->Walk();

みたいな感じになってくる。

という流れを踏まえた上で、それぞれのスタイルにおいてさまざまな仕様変更、仕様追加などを実装させてみる。多分初期のステップにおけるコードに仕様変更、仕様追加をするのがうんざりすることは十分に体感できるだろう。あと、犬以外の処理単位も同時に利用する実例も体感させていくといい。そのあたりで変数のスコープの話も混ぜておいた方がいいな。

そうやって非構造化→構造化→オブジェクト志向という流れのメリットを実感させた上で、ようやくオブジェクト指向言語の基礎知識の話をやりはじめると、それを学習する意欲＆理解がついてきてくれそうな気がする。

インターフェースとか抽象クラスとか継承とかデザインパターンとかの応用的要素の話も、具体的な体感できる仕様変更・仕様追加を使った実例を挙げつつ伝えていくと効果的だろうな。

ところでこのサンプルコードはいったい何語？　VB.NETとPHPとObjectPascalを足して4.2で割った感じかな？

_ 過去ログ管理専用CMS (13:49)

しかし、過去ログがいろんな形式で山のようにあり、だんだんわけわかんなくなってきた。

ってのを見て反射的に思いついたネタ。

いろいろなWeb日記システムや掲示板、あるいはベタHTMLなどを使って作ってきた過去ログデータがある。ベタHTMLならともかく、動的生成システムなどを使って作ったデータに関しては、そのシステムを使わなくなると見れなく（動かなく）なってしまう。またベタHTMLに関してもサーバーやディレクトリを移動すると、内部リンクなどがつながらなくなってしまう。

というあたりを解消するための、複数システムで生成された過去ログデータを管理するためだけのCMSってのもあるといいかもね。新しもの好きな人々に最適。

システム構成としては、

  • さまざまなフォーマットのデータをそれなりに管理・表示してくれるドキュメント管理機能
  • コンテンツ内のリンクなどある程度自動的に修正可能な要素を管理してくれるドキュメント修正機能
  • 古いシステムで使われていたリンク（QueryString付き）が呼び出された場合にも、本システム上の該当ドキュメントを適切に呼び出せるようにするリダイレクタ

あたりが中心かな。俺的な優先順位はものすごく低いんで作るとしてもはるか先の話だろう。誰か作って。ベタHTMLと主だった日記システム、掲示板システムあたりに対応していると喜ばれそうだ。

_ WebサービスとセマンティックWeb from 山岸広太郎のBlog（ブログ） (13:49)

だからRSS/RDF（データ記述の記述法）はセマンティックで、TrackBack（サービス層のモジュール化）はWebサービスなのね。

俺のアバウトな把握によれば、セマンティックWebというのは「Web構造をコンピュータが直接認識できるようにしよう」という話で、XML Webサービスというのは「コンピュータ同士がWeb（HTTP／HTTPS）を介した機能呼び出し・データ交換を出来るようにしよう」という話。どちらかというと理念とか方向性の話であって、具体的な技術仕様とは切り離すことが可能な、いわば思想。

で、それらを具体的にどのような技術を使って実現しようかとしたときに、RSS／RDFなどの標準フォーマットを使ってWebサイトなどの情報を表現しようとか、TrackBackを使ってWebサイト（を管理するCMS）同士が自動的に通信できるようにしようとか、具体的な技術の話が出てくる。

XML Webサービスの場合は、それ用に作られたSOAPとかXML-RPCなどの技術を使って実装された場合のみXML Webサービスと名乗るべきだ、という原則論的なポリシーを持っている人もいるかもしれない（規格や仕様、実装の方から詰めていけば、そう捉えた方が話が早い場合もある）。けれども、大まかな思想の話で言えば、HTTP／HTTPSごしにコンピュータ同士が直接機能・情報をやりとりするための公開規格全部をWebサービスと言ってもいいと思う。そこでデータ形式としてXMLが使われていれば、より反論の余地は少なくなる。

セマンティックWebの技術だって、日本で昔からあるアンテナ情報配信フォーマット（LIRSとかHINA-DIとか）なんかもセマンティックWebの技術だといえる。人間やエディタが適当に書いたHTML＋リンク文字列（機械的な抽出＆認識を行おうとしてもノイズが大きい）ではなく、コンピュータできちんと自動処理出来る程度に規格化されていればそれで十分だ。

ただし最近では、コンピュータが認識できる汎用フォーマットとしてXML関連の技術が主流になっており、XML Parserがさまざまな言語で実装されているため、XMLをベースとした技術仕様の場合は（最近のプログラミング言語では）簡単に実装（ポーティング）できるというあたりから、XMLベースの技術じゃないとセマンティックWebとかWebサービスとかいう言葉でくくりたくないと言う人もいるだろう。

以上の認識は、技術仕様に基づくものではなく、俺ルールの認識なのでそのあたりを割り引いて読んでくだされ。俺教においては上記のような定義になっている、と理解しても可。

_ Montoya criticises new regulations from F1-Live.com (13:49)

I believe it is very important for the public to see who is really the fastest of all and this format doesn't really help.

確かに純粋にマシンの最高性能を比べる場がなくなってしまったことによって、F1のおもしろみは減ったと思う。でも、FIAが狙ったとおり決勝における面白さは従来よりも増している（特に強いマシン、ドライバーがハッキリしている状況でもマギレがおきやすいという点で）ことも事実だ。あとはその面白さ面白くなさの天秤がトータルでどちらに傾くかの話になってくるんだろう。

_ 検索に力を入れるMS――Overtureとの関係に影響？ from ZDNet (13:49)

ブラウザ戦争に勝利したにもかかわらず、いまだにインターネットで勝利することが出来ないマイクロソフトが次に目をつけたのが、検索システムってことかな？　ああもちろん技術方面では.NET FrameworkおよびXML Webサービスへのコミットメントが強力だけど、一般ユーザーにはあまり関係ない話だしね。あとMicrosoft Passportもいまいちダメそうな雰囲気が漂っているし。

でもマイクロソフトが下手に検索システム関連の開発を強化すると、インターネット上にさまざまな迷惑（主に規格違反系）を巻き起こしそうな気がするな。

_ Officeの「脇」に立つOneNoteとInfoPath from ZDNet (13:49)

OneNoteはどのエディションにもバンドルされず、InfoPathは「Office 2003 Professional Enterprise Edition」にバンドルされる。

InfoPathがバンドルされないのは、InfoPathがNotesに対するDominoみたいな位置づけだから一般ユーザー向けに配布しても、サポートの手間ばかりかかって仕方がないからだろうな。

OneNoteがバンドルされないってのは、Visioがバンドルされないのと同じ理由なのかな？　すなわちそこで扱われるデータはWordやExcelほど一般的ではないので、数を配ってデファクトスタンダード化を進める必要がなく、必要な人はバンドルされていなくても購入するだろうって感じかな？　いやVisioがバンドルされない理由も知らないんだけどさ。

_ USBポートはなぜ“後ろ”にあるのだろうか from ZDNet (13:49)

USB端子は、今となってはちょっとでかすぎるよね。デジカメとかで使っているミニUSB端子（規格名は知らない）の方が標準だったら、前面にたくさん置いてもそれほど邪魔にならなかっただろうし、ノートPCなんかでも複数装備することが難しくなかっただろうに。VAIOノートを使っていると、スペックの劣るUSB（1.1）がIEEE1394（iLink）よりも接地面積を取っているのがアホくさく感じる。

[ツッコミを入れる]

2003-04-13 [長年日記]

_ Mozillaが“不死鳥”Phoenixになる――？ from ZDNet (13:49)

確かに最近のMozillaはまるでマイクロソフトアプリみたいに巨大になっていたからなー。安定性やメンテナンス製が高い小さなモジュールの組み合わせによって、トータルで高機能を実現するアプローチを取った方が、IEとの差別化も進むし、オープンソース文化との親和性も高いだろう。

_ メタデータを付与することの意味 (13:49)

>リソースを公開する人が、それにメタデータを付与する努力をする必要がある。しかしその努力の見返りに、その人はどんな利益を受けられるのだろうか。この質問に答えられなければ、メタデータをつけようとする人がいないことは自明である。

俺個人が思い描くところの、Webサイトにメタデータを付与することによって何が起きうるか、各サイト運営者にどのようなメリットがあるのか、を語ってみる。

Web上に公開されているリソースというのは、それ単独で意味があるコンテンツであると同時に、WWWという巨大なコンテンツの中の部分でもある。たとえば、個人ニュースサイトなどが作成した「ある話題の関連リンク集」によって、さまざまなサイトに分散された情報が編集され、別のコンテンツ（リンク集）の一部としての意味合いを持つ、というような事例が挙げられる。

Web上（あるいはインターネット上）に公開されたリソースは、すべて「ハイパーテキストによって接続される」＝「他のコンテンツの一部として編集される」可能性を持っている。そして、その可能性は個人が個人としてコンテンツを作成しているときには思いも寄らなかった、新しい可能性を見いだしうる。あるコンテンツとあるコンテンツを接続することによって、新しい別の意味（コンテンツ）がそこから生まれたり。

現在のメタデータをほとんど持たないWeb上のコンテンツでも、人間が人力でその意味を解釈して再編集すれば、新しい意味を付与したコンテンツを生成することが出来る（関連リンク集の例のように）。しかし、人力で意味を解釈して再編集をするという作業には、マンパワー的な限界がつきまとう。そのマンパワー的な限界を突破する道具がメタデータの付与だ。

もちろん、メタデータによってマンパワー的な作業量が減じたからといって、人力がすべて必要なくなるわけではない。編集の結果として新しく意味があるコンテンツを作成できるかどうかは、あくまでも人力にかかっている。ただし、そこにおける単純労働的な要素を限りなく自動化することは可能だろう。

メタデータの付与が一般化したときに、最初にその恩恵を受けるのはいわゆる検索エンジンシステムだ。現在のキーワード一致検索などと比べると、圧倒的に高度な検索システムが実現されるだろう。単なるキーワード一致検索では、そのキーワードがそのコンテンツにおいてどのような意味を持つかまでは（コンピュータが）認識できなかったが、メタデータによってキーワードの意味が取得できるようになると、キーワードの各コンテンツにおける意味（重要度、使われ方）までを加味した検索処理が可能になる。

また、Amazonのようなネット書店の例で言うと、メタデータ（を取得するためのインターフェース）を提供することによって、自分のサイトよりも安価なサイトに客を取られうるというネガティブな可能性ももちろんあるのだが、それよりもAmazon自身が用意できる販売サイト（コンテンツ）以外にも、いろいろなユーザー（および同業他社）によって新しく魅力があるコンテンツ（販売サイト）が登場しうる可能性がある。

実際Amazon Webサービスを利用し、独自のコンテンツ（インターフェース）によって書籍の販売を行っているサイトも存在する。それがAmazonにどれだけの利益を生み出しているかは知らないけれど、ukでも同様のサービスを開始した（Amazon、Web サービスプログラムをイギリスでも実施参照）と言うことは、少なくともAmazonは今まで実際に運営してきた結果として、そういうサービスを今後も運営し続ける価値があると認識しているのだろう。

Web上のコンテンツにメタデータを付与するということは、自らが作成したコンテンツがその単独としての意味を持つだけではなく、WWWの一部として新しい意味を持ちうる可能性を、積極的に肯定することだ。

そのようなポリシーを誰もが是とするわけではない（自分のコンテンツには、自分以外からはリンクすらされたくない、という人もいるわけだし）ことは承知しているが、WWWという仕組みを積極的に活用しようと考えたときに、このような思想に至るのは私にはごく自然なことのように思われる。

とここまで書いてきた感想としては、メタデータを付与することによって個人Webサイト運営者が受ける直接的なメリットというのはほとんどない。ただし、「個人Webサイト運営者」＝「WWWのディープな利用者」であると考えると、「メタデータの付与によって、巡り巡ってWWWの仕組み自体が便利になる」という「風が吹けば桶屋が儲かる」程度のマクロなメリットはあるだろう。即物的な利益を求める人には向いていない思想かも。

_ コピーできないCD、米国以外ではメインストリームに？ from ZDNet (13:49)

>「（これら地域の）人々は、（コピープロテクトCDの）コンセプトに慣れてきている。これらの国の消費者は、米国の消費者ほど口やかましくないということだと思う」とMacrovisionのCEO（最高経営責任者）、Bill Krepick氏は語る。

へー、そうなんだ。俺は慣れていないし、個人的には（個人用途ですらコピーすることに制限があるCCCDは）絶対に買わないつもりだけれど。でもセカンドセッションに収録されているデジタルデータが、音質を落としすぎない（最悪でも96kbpsか？）もので、データフォーマットがMP3（WMAとかATRAC3なんて使いたくない）で、個人用途ではコピー制限がないようなものだったら買うだろうな。エンコードの手間が省けて逆にうれしいし。

_ ROBODEX2003“エージェントAIBO”と一緒にドライブに出かけよう from ZDNet (13:49)

>「お家でいつも遊んでいるAIBOが、一緒にドライブに行ってくれる。それも、ただ横に座っているだけでなく、車の情報を伝えてくれたり、カーナビの情報をしゃべってくれる。カーナビの液晶ディスプレイに3D化したAIBOが同様のことをするぐらいは今でもすぐにでも可能だが、リアルなAIBOがパートナーとして同乗してくれることで、ドライブが一層楽しくなる」（ソニー）。

なるほど確かに機能の問題ではなく、人間向けのインターフェースとしてAIBOみたいなロボットが、いつでもどこでも共通に使えるってのはいいかもね。

別にロボットまでいかなくても、PDAみたいなものに汎用（共通）のインターフェースアプリを入れておいて、一般的な処理（PIMやナビゲーション的な機能）はそのインターフェース越しにアクセス出来るようにしておくと、人間の使い勝手が結構変わるだろう。実際に問い合わせを行う先は、別サーバーにあるのかもしれないし、PDAローカルにあるのかもしれないけど、ユーザーはそんなことは気にせずに、マスコット的な共通インターフェースに対して操作をするだけでいいようにして。

_ サーバートラブル中 (13:49)

ただいまサーバートラブル中。共通ライブラリの細かい手直しをしているタイミングで、ユーザーのhomeディレクトリ用ドライブがディスクフルになりやがった。ここは基本的にquotaはゆるゆるにしかかけられていないサーバー（ディスク容量と帯域に関しては、「性善説のUNIXサーバ」みたいな感じ）なんで、分かっていないユーザーがいるとそういうことが起こりうる。

/home以下にはファイルの上書きすら出来ないんで、「サーバートラブル中」のメッセージを表示させるにも一苦労。/tmpは別ドライブで唯一アクセス権があるディレクトリだったんで、そこにメッセージファイルを置いてシンボリックリンクを張れば表示できるかも、と試していると一瞬だけディスク使用量が99%に落ちたんで、その隙に必要なファイルをアップロード。

というわけで、なんとかぱっと見は動く状態に戻ったけど、キャッシュファイル回りとかが腐った状態だ。まあWikiLikeはデータをDB（これも別ドライブ）上にしか持たず、ローカルファイルはキャッシングにしか使っていないから、エラーメッセージを表示しなければちゃんと動いているように見えるに違いない。

という状態なんで、しばらくの間は微妙にいろいろ不具合があるかも。

お、ディスク容量が1Gくらい一気に空いた。誰かのアカウントが丸ごと停止になったかな？　これでキャッシュ回りもちゃんと動くようになったはず。

_ アスペクト指向プログラミング (13:49)

「アスペクト指向プログラミング」という言葉を「AOP読書中（http://www.sgtpepper.net/hyspro/diary/?date=20030413#p02）」で知って、ちょっと調べてみたところ見つけたページ。

ざっと読んだだけで全然理解できてはいないんだけど、OOPでもうまく独立したきれいなモジュールとして構成することができないようなプログラミング要素を、もっと抽象的なモジュール＋実行時の特性に分割して管理し、実行時に（あるいはコンパイル時に）コードを動的に再構成することによって、抽象性（汎用性）を保ったコードのまま複雑な状況に対応できるようにしようって感じなのかな？

ひとまず上記のような理解があっているとして、そういうアプローチはインターフェースをばりばり使ったら既存のOOP言語でもなんとか表現できそうな気がするなー。あるいはスクリプト系でOOP対応の言語なんかで、自己書き換えとかevalとかを使ってもそれっぽいことが出来そうな気がする。

抽象クラスやインターフェースを（普通に）使っても結局あまりきれいに書けないようなモジュールを、そういうアプローチによって解決できるかどうか今度試してみよう。

[ツッコミを入れる]

2003-04-14 [長年日記]

_ 504iがクレジット代わりに - 赤外線によるカード決済トライアル開始へ from MYCOM PC WEB (13:49)

携帯で決済をするんだったらクレジットカードじゃなくて、ドコモ自体の課金システムに請求が行くような仕組みの方が便利だろうな。クレジットカードが使えるような場所での決済ならば、わざわざ携帯を使わなくても普通にクレジットカードで決済すればいいし。

_ 「Oyster」でノートPCを究極のデスクトップ仕様!? キーボードがスタンドに from MYCOM PC WEB (13:49)

デスクトップ代替のハイパワーノートなんかをメインマシンとして使う場合、デスクトップ上ではこういうのを使うと結構良さそうだな。最近ではもはや、ミニタワーとかをメインマシンにしている意味がほとんど感じられなくなってきたし、次に会社用マシンを買い換えるときにはこういうのを検討しよう。

_ 「オランダでファイル交換サービス」にだまされたニュースメディア from HOT WIRED JAPAN (13:49)

>著作権保護法に敢然と立ち向かうファイル交換サービスを立ち上げると発表していたオランダのインターネット・サービス会社の幹部が、2日(米国時間)になって、これがただの作り話だったことを明らかにした。

あらそうだったのか。てっきり本当だと思っていたよ。でもまあ、それが意識的な嘘だったとしても、本当にやろうとしていた計画が頓挫したのだとしても、大した差はないな。あんまり面白くない。というか、普通にネット上でありそうな嘘をつかれても、嘘をつかれた方は「あらそう」としか思えないよなー。この人、対企業的にはずいぶんと評判を落としたみたいだし、リスク対効果の面でもいまいちだったんじゃないか？

_ 「システム化」進むOffice、ポータルソフトも飲み込む from ZDNet (13:49)

WikiMemoをWindows用のメモソフトであると同時に、Webサーバー上で動作するWikiEngineのクライアントとしても使えるようにすると、SharePointと対抗できるようにならないかなー。まあWikiMemoを.NET Framework上で作っているあたり、俺のポリシーは不明な感じなんだけど。せめてJavaベースで作っていれば説得力も増すんだけどな。

ただ、高機能WikiEngine＋Wikiベースのクライアントソフトってアプローチは、チープなシステム環境で高度な情報管理をする基盤としては、悪くない仕組みだと思う。

_ 簡易版も登場、新Acrobatが目指す「PDFによる標準化」 from ZDNet (13:49)

Acrobatも技術としては嫌いじゃないんだけど、Adobeのものだと思うとどうしても強く推す気にはなれないよなー。でも、さまざまな書類データを共通のデジタルデータとして保存・管理するフォーマットとしては現時点ではベストかな。紙書類をスキャナーで取り込んでそのままPDF化できるってのが大きいよな。組版表現の制限も少ないし。

_ モノを識別する"ユビキタスID"の技術を解説 - ユビキタスIDフォーラム開催 from MYCOM PC WEB (13:49)

>ユビキタスIDセンターは、あるuIDがどんな製品を指すかという情報は蓄積せず、どのデータベースに問い合わせれば製品の情報が得られるかという、データベースアドレスの解決のみを行う。

>店で製品を販売するときに任意のビットをマスクすることで、製品の種類を示すアドレスは残すが、製品1個1個のユニークなアドレスは読みとれなくするといったセキュリティ確保の方法が考えられている。

いろいろ応用が利きそうな考え方だなー。

問い合わせ先がどこなのかを問い合わせる層と、具体的な情報を問い合わせる層の二階層を用意することによって、どういうメリット・デメリットがあるのか考えてみよう。

あと、アドレスの一部をマスクして表示するってのは、トリップキーの半分を公開して目で確認するためのキーとして利用し、残り半分を非公開にして認証用に使っているのとちょっと似ているかな。ただ、マスクする・しない部分の意味づけを明確にして使うと、さらに用途が広がるかもしれない。

_ 特集: 生活に役立つネットワーク保育園でライブカメラ 〜愛娘をチェック from ZDNet (13:49)

こういうソリューションって、価格的にはもはや大してかかるわけではないよな。専用ハードウェアもいくつかでているし、あとはADSL系の常時接続＋ダイナミックDNSに、ユーティリティ＋セキュリティソフトを組み合わせる感じで、導入10万円＋維持費1万円/月くらいでなんとかなりそう。ちょっとしたモーター制御とかと組み合わせて、ペットの監視＋えさやりをネット越しにやったりも出来そうだし。ソフトウェアよりの部分は大しておもしろみがないけれども、USB経由でロボット制御みたいなことをいろいろできるようにすると面白そうだなー。

_ はてなの投げ銭を汎用の投げ銭システムとして使えないか (13:49)

2003/12/19

実際にはてなポイントを汎用決済システムとして利用する例が現れた模様＆そういう利用方法をはてな側でも承認した模様。こういう利用例がある程度増えて、はてなポイントの流通量が増えれば、以下に書いたような展開も現実的になってくるかな。関連ネタとして、「「へぇ」で投げ銭」もどうぞ。

2003/4/13

今までいろいろな投げ銭システムが考案されては、ほとんど使われないままに消えていった（あるいは消えていないけれども流行りもしない）わけだけど、はてな（http://www.hatena.ne.jp/）で新しく作られた投げ銭システムを、汎用の投げ銭システムとして（はてな以外でも）使うことは出来ないだろうか。

まずは、はてなのポイントシステム自体の概略を説明しておく。公式ヘルプはhttp://www.hatena.ne.jp/help/help0501。

ポイントは500円単位で購入できる。購入手段は、郵貯・銀行振込、eBANKによる振り込み。換算レートは1円＝1ポイント。振込手数料はユーザー持ち。ポイントははてなのメインコンテンツである質問システムにおいてユーザーの質問に答えたり、あるいは投げ銭を受け取ったりすることで増やすことが出来る（逆に質問をしたり、投げ銭を投げることで減る）。

ポイントは換金することも可能。ただし、換金するためには2000ポイント以上を保持している必要があり、しかも1000ポイント単位でのみポイントを換金することが出来る。換金時の換算レートも1ポイント＝1円。この場合の振込手数料も基本的にユーザー持ち。eBANK口座を持っていれば、振込手数料はかからなくなる（はず）。

質問をしたり投げ銭を投げたりするために、最低限持っているべきポイント数が定められているため、初期プレゼントポイントを悪用することがやりにくくなっているし、換金の方はさらに敷居が高いので、リアルマネーとして扱うよりもはてなポイントとして扱う方が扱いやすく出来ている。

というような、はてなのポイント＆投げ銭システムを、汎用の投げ銭システムとして利用する利点はいくつかある。

まず、はてなの持つ投げ銭システムは、もともとはてな内で稼働していたポイントシステムをベースにしているので、新規に（専用に）作られた投げ銭システムのように、それが使われなければシステムの運営が成り立たないというものではない（はず）。はてなの（人力検索を中心とした）ビジネスモデルがうまく回っていさえすれば、投げ銭システムを稼働させ続けることができる（といいな）。

また、はてなのアカウントは誰でも簡単にオンラインで取得できるので、受け取る側も送る側もアカウントの準備は容易だ。特に受信側のコストがかからないところは大きい。投げ銭システムのためだけにeBANKなどに口座を開くのは面倒だが、ひとまずはてなのアカウントを取れば投げ銭は受け取れるようになるし、送るときにも振り込み手数料がかかることを厭わなければ普通の銀行振込経由で行える（オンラインバンキングを使えば簡単）。もしもばりばり使おうと思ったときにだけ、eBANKに加入して振込手数料を節約するなどという対処をすればいい。

はてなの投げ銭システムでは、1ポイント（＝1円）単位での投げ銭が出来る。少額決済ではそのお金のやりとりにかかるコストを誰が吸収するかがもっとも大きな問題となるのだが、はてながもともと持つ、購入は500円単位、支払いは1000円単位、はてな内でのポイントのやりとりには（投げ銭の場合は5％の）手数料を課金、振込手数料などはユーザー持ち、という仕組みによってそのあたりは吸収されることになる（規模が大きくなったときにも、現行の仕様でうまく回るのかはちょっと不安。あと20円よりも少額の投げ銭では、5％の手数料がどうなるのかも気になる。まあ普通は切り上げか）。

ともかく、はてなの投げ銭システムを使うことによって、1円単位の少額な投げ銭が可能なため、「ちょっと面白かったら5ポイント投げ銭（＋はてなに1ポイントの手数料）」みたいな、気軽な投げ銭ができるようになる。そのくらいの金額ならば、お金のやりとりという感じもしないし、ちょっとした投票程度の気分で投げ銭ができるだろう。

ただ、投げ銭可能ポイントがある人でもない人でも同じように投げ銭ボタンを押せるように、投げ銭可能ポイントがある人の場合は投げ銭を行うことになり、ない人の場合は別の意味を持つ（それことランキング投票とか）にした方が、ボタンを押すことに対する敷居は低くなるかも（という話は本論ではなく、実際に運用が始まった後に考えればいい応用的話）。

ネットにおける投げ銭を推進しようと考えている方々、試しにこういう方向ではてなのシステムに乗っかってみたらどうでしょう？　ひとまず5ポイントの投げ銭リンクを表現したければ、「投げ銭する:http://www.hatena.ne.jp/sendpoint?name=ishinao&price=5」なんて感じで可能です。ちょっとセキュリティが強化されて、初期の仕様みたいにボタン一発で簡単に投げ銭は出来なくなったみたいだけど。

本当は、はてながオンラインショッピングサイトみたいなばりばりお金が絡むシステムも運営していて、そのあたりを使ってうまく「リアルマネー」→「はてなポイント」変換の敷居を低くできると、流行らせることも難しくなくなるんだけどなー。はてなポイントの流通量が増えないとなかなかうまく回らない。ショッピングサイトとかがあれば、購入額の5％をはてなポイントでキャッシュバック、みたいなことができるのに。

[ツッコミを入れる]

2003-04-15 [長年日記]

_ 車上荒らし (13:49)

車上荒らしにやられちゃいました。

朝、雨が降っていたんで、ムスコを車で保育園まで送ろうかと思ったら、車のインパネ回りがぐちゃぐちゃでカーナビとオーディオがない。ひとまず歩いてムスコを保育園まで送って行ってから、警察へ連絡。原チャリでやってきた警察官（×1）に口頭で被害内容を答えて被害報告書に捺印して終了。かかった時間は1時間くらいかな。雨が降っていたので指紋の取得はしない（粉がだまになってちゃんと取れない）と言っていた。

ここ最近ずっと車に乗っていなかったんで、いつやられたのかは不明。最悪2週間くらい前って可能性もあるけれども、車のリア（荷室）のドアが小さく空けっぱなしになっていて、リアの車内灯がついていたのに、バッテリーは上がっていなかったので、そんなに前ではないと思う（根拠は薄いけど）。

被害状況は、まず運転席の鍵がドライバーみたいなもので壊されていた。表向きは鍵穴の上部に小さな傷（2ミリくらい）が付いているだけだったけど、中身はぐちゃぐちゃで普通に鍵を回せない状態。ただ、キーレスエントリーで開けるぶんには問題なかった。あと、カーナビとカーオーディオ一式。そこそこきれいに外されてはいるんだけど、配線回りを外すために内装をちょっと汚く破られたりもしていた。あと、パネル回りのケーブルが露出していてちょっと危険。あと小銭入れの小銭少々もなくなってたな。書類（車検証とか）はなくなっていなかった。

まあしょせんは金で換算できるものが失われただけなんで、切実な被害というわけではないけれども、もしも原状回復をフルにしようと思ったら結構金がかかるだろうなー。盗難保険とか車両保険には入っていなかったし、その他保険で車上荒らしをカバーできるものも見あたらないみたいだ。少なくとも鍵は直さなければならない（修理というより交換か。いくらくらいかかるんだろう？）だろうなー。あと最低限のオーディオくらいは入れておきたいところだ。

はじめからナビをつけちゃっていて、ナビがあるのが前提に運転していたところがあるんで、ナビがなくなったのは結構痛いんだけど、さすがに同じ状況でもう一度ナビをつけ直す気にはなれない。かといって、今の車にわざわざ防犯系の機能をばりばりに追加する気にもなれないしな。次に車を買い換えるとき（っていつだ？）までは現状維持かなー。

こんなくそ忙しくて消耗している時期にやられたんじゃなければ、中古のパーツとかを買って装着してみたりするいいきっかけになっただろうに。

そういやCDチェンジャーに入っていたCD12枚も取られたんだな。あと、思ったよりも鍵を壊されたってのは被害が大きいなー。運転席の鍵（シリンダー）だけを交換すると、運転席の鍵だけが別ってことになってしまって面倒だ。かといってすべての鍵を交換すると金もかかるし、エンジンキーとドアキーが別ってことになってしまう。どうせならば、ガラスを割って盗んでくれた方が後腐れがなくて良かったかも、とか思ったり。

あといろいろ調べてみたけれども、現状では車上荒らしに対するコストパフォーマンスがまっとうな対策って見あたらないなー。一番ましそうなのはココセコムかな。ココセコムって振動感知で電話通報とかもやってくれるみたいだから、警報なんかよりも対策がしやすそう。

あと、ナビはパイオニアのAirNaviにしておけばいいかと思ったけれども、あれはまだスペック的にいまいちっぽいなー。あの手のナビとしてもう数世代たたないと洗練されてこない気がする。でもまあ一応、最後にナビが起動された位置情報を取得できるみたいだから、盗まれた後に犯人が電源を入れてくれればその位置は取得できる。でも、犯人が誰かに売り払った後にその人が電源を入れたんじゃ、善意の第三者って話になっちゃうんだろうな。まあそこから足がつく程度のまぬけな犯人だったら有効かもしれないけど。

[ツッコミを入れる]

2003-04-16 [長年日記]

_ XMLにおける「ボヘミアンと貴族の階級闘争」 from @IT (13:49)

XMLの意義はボヘミアン方面と貴族方面の二つともにあると思っているけれども、個人的には、

  • ローカルなデータ
    • 汎用的ではなく、少数のアプリケーションからしか使われない
  • データ仕様が完全にフィックスしていない、あるいは気軽に拡張したい
    • 拡張する際には、XMLフォーマットを活かしたい
      • 子階層で配列が持てる
      • 各項目で使用できる文字に制限が少ない（改行なども使える）
      • 文字コードの扱いが明確
      • 異バージョンデータ形式の扱いが楽
        • ノードが見つかったら使い、見つからなければ使わない（あるいはコード側でデフォルト値を設定する）
  • 複数のレコードを串刺し検索したりすることはさほど多くない（RDBにした方がいいかどうか）
  • XMLが扱いやすい言語プラットフォーム上で使う

というボヘミアン的な用途で、適当（アバウト）に使えるデータ形式としての意義を活かして使うことが多い。

もう一つの意義である、

  • 汎用的なデータ
    • そのデータの読み書きは、さまざまなアプリケーションから行われる
  • 仕様が明確に決まっており、ノード単位の正当性チェックまで自動で行われる
  • XMLフォーマットの拡張性ではなく、基本的な表現能力を重視する

という貴族的な使い方については、すでに仕様が決まっている技術に乗っかりたいときだけ意識するけれども、そういうデータを扱いたい場合も自分のコードでは結局ボヘミアン的な扱いをしている（用途に合致する貴族的高機能ライブラリが存在した場合は、それを使うだろうけど）。

という現状においては、最低限プリミティブなXMLライブラリさえ存在してくれれば（なくなることはないだろうけど）、今後のXMLの主流がどうなろうとも（貴族方面に推し進められようとも）、俺にとってはあまり影響がないかなーという気もする。

XMLみたいな夢が大きい（やろうと思えばなんでもできる）仕組みに対して、その可能性を最大限にいかそうとしたときに、「なんでもできる」＝「混沌」へと流されないように、きっちりとした枠組み（秩序）に基づいて使うことを義務づけたい（＝貴族）という意図と、工数をかけずにちょっとした用途でも便利に使えるのならば使いたい（＝ボヘミアン）という意図の対立。

その秩序は本当に必要な秩序なのかそれとも不必要な締め付けなのか、という問題なのかな。

_ 【IDF-J Spring 2003レポート】シンプルなアプローチで実用化の期待高まるUWB from MYCOM PC WEB (13:49)

>最近では、UWBの消費電力がBluetoothと大差ないレベルになる見込み(カーン氏によれば、UWBの消費電力はBluetoothの2〜3割増でおさまるという)であり、一般への普及が当初の予想より遅れているBluetoothを捨ててUWBに乗り換えようという動きが一部で見られるようだ。

うーん、Bluetoothは流行る前につぶれかねないな。ようやく普及する雰囲気が出てきたけれども、それでも爆発するようには全然見えないし、こんなのんびりした調子でやっていたら、後発技術に簡単に追い抜かれてしまいそうだ。というか、後発技術もそれほどパワーがなかったりすると、追い抜かれてもBluetoothが消えたりせずに微妙に並立したりして、結局この手の短距離お手軽無線技術は標準がないままにずるずるいってしまいしそう。

_ “甘味”を増すハニーポット、誰でも導入可能に from ZDNet (13:49)

わざと侵入させて、その侵入者の行動を監視するのか。確かに有効そうな仕組みだなー。専用サーバーを用意するのだと数がそろわないから、一時的にそういう機能のサブセットを通常のサーバーでも運用できるようにするといいかも。って、そんなに手軽にインストールできるものじゃないか。OSの深いレベルで対策しているんだろうし。まあ数が少ないとしても、クラッカーのリスクを増すのには有効だろう。人が作ったツールを使ってクラックして遊んでいるやつらを捕まえるにはいいかも。

_ 誕生から10年、ブラウザはまだまだ進化する？ from ZDNet (13:49)

そろそろWebブラウザーとかメールクライアントとかP2Pクライアントとかばらばらにするのではなく、インターネット統合クライアントってものが出てきてもいいんじゃないかな。MSNとかAOLのクライアントがそれに近い感じだけど、ああいう特定のサービスに囲い込むのではなく、インターネット標準プロトコルに準拠した、軽いやつがいいなー。Eclipseみたいな統合環境にプラグイン拡張性があるプラットフォーム上で作るといいかも。ってのに現状で一番近そうなのは、モジュールベースで軽く作り直される予定のMozillaかな。

[ツッコミを入れる]

2003-04-17 [長年日記]

_ “サイバー万里の長城”に穴を掘るソフト from ZDNet (13:49)

>IBBのソフトのコンセプトは、ファイアウォールを回避しようとするユーザーが、ファイアウォールで遮断されていない第三者のコンピュータを介して抜け道を作れるようにするというもの。このソフトをインストールしたユーザーは、Secure Socket Layer（SSL）を使って小型Webサイトを設置でき、ファイアウォール内のユーザーはこのサイトを介してファイアウォールの外のサイトにアクセスできる。

なんだかよくわからない説明だなー。SSLを使ったプロキシーサーバーとそれへの接続ソフトで構成されているってこと？　でもって、プロキシーサーバーはあらかじめアクセス制限を受けていないマシン上に構築しなければならないってこと？　LAN内とかの話ではなく、インターネット越しに他人が設置したプロキシーサーバーに接続する