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

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-02-04 [長年日記]

_ 風邪からシームレスに花粉症へ (20:11)

ってことなのかなー。先週いっぱい苦しんだ風邪もこの土日で治ったかなーと思っていたのに、昨日の夕方くらいになってまたひどい頭痛と鼻水が始まった。風邪がぶり返したんだと思っていたんだけど、どうも周りの話によるとすでに花粉症が始まっているらしいね。確かに頭痛と鼻水ってのは花粉症の症状でもあるからなー。うーんどっちなんだろう。

_ DirectXも楽しそうだ (20:11)

そういやDirectXって、もう.NET Frameworkに対応しているのか。.NET系言語でDirectXゲーム書くのって楽しそうだなー。半年以上仕事でVB.NETやってきたけど、仕事にとらわれないのならばC#を使った方がいろいろ良さそうな気がするし、C#に慣れるためにちょっとDirectXで遊んでみようかなー。

[ツッコミを入れる]

2003-02-07 [長年日記]

_ PostgreSQLのデータ復旧 (20:11)

PostgreSQL（バージョン6.x）をしばらく運用しているとlogファイルが巨大になってくる。logファイルなんだから消してもいいだろうと、適当にmvしたりする人がまれにいる。が、PostgreSQLのlogファイルは人間が目で見るためのテキストlogファイルではなく、PostgreSQLの動作に必要なバイナリファイルであり、それを消すとPostgreSQLがまともに動かなくなる。

という状態になってしまったデータを復旧させてくれないかと頼まれていろいろ調べてみた。

PostgreSQLはupdateなどでデータを書き換える際に、実際にデータを書き換えるのではなく、既存のデータに無効フラグを立てて見えなくしつつ、新規に新しい内容のデータ領域を作成してそちらを有効にする。updateをかければかけるほどデータ領域はひたすら増え続けていく。そのため、定期的なvacuumを行って不必要なデータ領域を削除したりする必要がある。

PostgreSQLではすべてのSQLコマンドはトランザクションで囲まれているものと見なされる。明示的にbegin;commit;で囲まれていないSQLコマンドも、内部的にはその前後がbegin;commit;で囲まれているものとして処理する。そして、すべての処理は32ビット連番のトランザクションIDが割り当てられている。ある処理で変更があったデータには、その処理のトランザクションIDが記録される。

先ほどの「書き換えられたデータに無効なフラグを立てる」という処理には、このトランザクションIDが関わっているようだ。ある行の内容を書き換えた場合、その行には古いデータと新しいデータの二つが存在することになる。それぞれには、そのデータが生成された処理のトランザクションIDが記録されている。現在のトランザクションIDと比較して、より現在のIDに近いトランザクションIDをもつデータが、その行の最新のデータとなる。

logファイルはどうやらトランザクションを管理するデータらしい。logファイルを削除するとトランザクションIDがリセットされてしまう。実データは別ファイル（baseディレクトリ以下）に記録されており、logファイルがおかしくなってもそちらは影響を受けない。しかし、トランザクションIDがリセットされると、実データファイル側に記録されているトランザクションIDとの間に矛盾が生じるため、データが見えなくなってしまう。たとえばトランザクションIDが1000の状態で記録されたデータは、トランザクションIDが100の状態では見えない。

そのようになったデータを再び見えるようにするためには、現在のトランザクションIDを、実データファイルに記録されている最新のトランザクションIDよりも大きくしてやればいい。トランザクションIDを直接操作する方法は見つけられなかったが、SQLコマンドを1回発行すれば現在のトランザクションIDが1増えるので、特に意味のないSQLコマンドを必要な回数だけ発行してやればトランザクションIDを増やすことができる。

データに記録されている最新のトランザクションIDを知る方法も見つけられなかった。もしもDBの利用頻度が分かっているのならば、たとえば「1日の平均トランザクション数×運用日数」などでトランザクション数を予想して、その回数分SQLコマンドを発行してやればいい。利用頻度が分からない場合は、oidを使ってトランザクションIDが最新に追いついたかどうかを類推する方法がある。

害がなさそうな適当なテーブルに対して、1行新しい行を作成し、その行のoidを見る。トランザクションIDはリセットされても、oidはリセットされないようなので、oidはリセットされる前の最新のoidよりも新しいものが割り当てられる。その値を基準として使うことになる。

トランザクションIDを進めていくと、少しずつデータが復旧していく（古いトランザクションIDをもつデータから見えるようになってくる）。そこで既存テーブルの中で新規行の作成が頻繁であったと思われるテーブルのもっとも大きなoidをチェックする。データが復旧していくとそのoidの値が大きくなっていく。その値が先ほど得た基準となるoidの値に限りなく近くなる＝データが元の状態に復旧した、ということになる。

トランザクションIDがリセットされると、システム管理テーブルの内容も見えなくなるので、テーブルのスキーマ情報なども得られなくなる。が、トランザクションIDを進めていくことで、システム管理テーブルの内容も回復し、スキーマ情報も得られるようになる。ただし、sequenceやindexなどのデータは完全に回復できないこともあるようだ。それらはスキーマと実データを使って、再生成・設定すればいいだろう。

私の場合は「select 1;」を100万回実行するたびに、oidをチェックし、対象テーブルの最新oidが増えなくなってからさらに念のため200万回ぶんトランザクションIDを進めた辺りで、だいたい元のデータが復旧したと判断した。そのあたりの判断はDBの設計によって異なるだろう。

_ 書評リンクの話 (20:11)

あちこちでやっていてポイントを抑えてリンク張るのが難しいんで、興味がある方は上記からあちこちたどってみてください。

で、俺の場合は、「さまざまな個人Webサイトにおける各自ばらばらな行動の中から、ある一定のベクトルをもつデータを抽出して整理して見せること」一般に対して興味があって、そういうベクトルの一つとしての「書評リンク」に興味があるという立場なんで、この手の話をしようとすると話が発散する方向に向かう可能性が高い。風呂敷がでかくなりすぎるというか。という言い訳をしてから話をはじめてみる。

まずは、個人Webサイトにおけるさまざまな情報を、Webサイト同士でやりとりするための、RSSみたいなXMLベースの汎用データフォーマットを決める。んでもって、主だったWeb日記システムやコンテンツ管理システムが、そのフォーマットのデータを自動的に生成できるようにする。

それから、Webサイト間でそのデータをやりとりするためのインターフェース仕様を決める。できればシンプルな（実装しやすい）ものから、汎用性・機能性の高い（けどちょっと実装が面倒な）ものまで数パターンあるといい。あと、インターフェースの起動方法も複数用意しておいた方がいい。個人Webサイト側から送信するパターンとか、集約サーバー側からデータを引っ張ってくるパターンとか。起動に人間が必要なパターンと、必要ないパターンのどちらも用意しておいた方がいい。

そのあたりはアンテナ（サイト更新情報リンク）文化のやり方とかblog系システムのやり方を参考にすると良さそう。アンテナ文化ではLIRSとかDIとかみたいな、個人Webサイトで生成したデータを他のサイトで二次利用するという仕組みを実践的に使ってきている。あと、MovableTypeにおけるTrackBackを使ったサイト間をまたがったやりとりの仕組みとか、RSSを使ったデータ配信の仕組みとかが参考になる。

あんまり深く考えずに適当な仕様を試しに書いてみると、たとえば各個人Webサイトでは、書評を書いたら、各Web日記システムなどが以下のようなフォーマットのデータもはき出せるようにしておく。

<?xml version="1.0" encoding="utf-8" ?>
<bookreview>
 <site>
  <title>ishinao.net</title>
  <url>http://ishinao.net/</url>
 </site>
 <item>
  <updt>2003-01-20 23:54</updt>
  <isbn>4150306931</isbn>
  <title>ムジカ・マキーナ</title>
  <author>高野史緒</author>
  <comment></comment>
  <url>http://ishinao.net/WikiLike/?sid=147</url>
 </item>
</bookreview>

このあたりの項目に関しては、必須項目とオプショナル項目をいろいろ設定しておいて、あったらそれをちゃんと使うし、なくてもそれなりに扱えるようにしておくといい。上記は書評関連しか考えてないけど、本当はベースとなる汎用フォーマットを決めて、その上にジャンルごとの拡張フォーマットが乗ってくるようにするときれいだろう。

んでもって、それをどこかの書評リンクサイトに送信するインターフェースを用意する。実際にやりはじめると認証とかいろいろ絡んでくるけれども、ひとまず情報を受け渡すだけなら簡単だ。個人Webサイト側からPOSTしてもいいし、個人Webサイト側からはこういう情報を得るためのURLだけを渡してやって、実際のデータは書評リンクサイト側から引っ張っていってもいい。

あ、Web日記システムを使っていない人向けに、集約サイト側の方で普通のフォームから必要な情報をその場で入力してPOSTするようなインターフェースも用意しておいた方がいいだろうね。

書評リンクサイト側の内部では、受け取ったデータをどういう形式で保存管理しても構わない。けれども、書評リンクサイト側でも必ず同様の形式でデータを出力できるようにしておく。んでもって、各個人サイト側からの要求に応じて、必要なデータを個人サイト側にも返してやると、個人Webサイト側で他のサイトのデータを再利用することも可能になる。ってのはあくまでもデータの二次利用性を高めるための仕組みであって、もっともメインとなるのは書評リンクサイト上でそこに集約されている情報を見せるリンク集ページ部分だろう。

んでもって、書評リンクサイト上に集約された情報に含まれるキーワード（＝ISBNもしくは著者名もしくは作品名）をベースにしたコミュニケーションツール（それがWikiであってもBBSであって構わない）とかを用意すると「はてなダイアリー的なものをグローバルに（http://d.hatena.ne.jp/ishinao/?date=20030203#p1）」な感じになってくる。書評に限らずノンジャンルで情報を集約するようにすればそのままはてなダイアリーっぽいし、各ジャンルごとにさまざまな集約サーバーを立てて独自の文化圏を作っていっても面白そうだ。

ってな感じのものを（ひとまず動くように）作るのはそんなに難しくないけれども、将来性のあるまともな仕様を決めたりとか、各Web日記システム用のプラグインを作ったりとか、参加者を集めたりとか、本気でやろうとすると結構大変そうだね。いろんな言語用のサンプルコードを書いたりとかも必要だし、まじめに集約サーバーを運用するとなるとお金の心配とかもしないといけないし。

[ツッコミを入れる]

2003-02-08 [長年日記]

_ 書評リンクの話 2 (20:11)

書評リンクの話の続き。もうちょっと具体的な運用イメージを考えてみる。

リンク参加希望サイト側での参加イメージ。

  • Web日記システムを使用している場合
    • Web日記システムを拡張して、汎用フォーマットのデータを出力できるようにしておく
      • オンラインで動的生成するタイプならば、CGIなどでいつでも動的に必要項目を汎用フォーマット化できるようにする
      • オフラインで動的生成するタイプならば、Web日記上の該当項目を汎用フォーマット化したデータも別途オンラインにアップロードしておき、該当項目そばにリンクを置くことによって、誰でもダウンロードできるようにしておく
        • 新規記事の汎用フォーマットURLを集約サイトに通知する
          • 簡単にQueryStringで渡してもいいし、複数記事ぶんをまとめてPOSTしてもいいし
          • 通知タイミングは、新規記事作成タイミングでもいいし、あとで適当にでもいい
          • あらかじめ集約サイト側にメンバー登録しておき、そのサイトのRSS URLを登録しておけば、集約サイト側から新規記事の存在確認をしに来る
    • 汎用フォーマットに対応できない場合は、Web日記システムを使用していない場合と同様
  • Web日記システムを使用していない場合
    • 自力で汎用フォーマットデータを作って、それをWeb上にアップロードしておく
    • 集約サイトにいって、必要情報を投稿するフォームに各項目を入力する

集約サイト側の運用イメージ。

  • メンバー登録されているサイトに対して、
    • RSSなどから最新の記事一覧を取得。記事一覧中に未取得の書評記事を見つけた場合、その記事に汎用フォーマットデータを取得
    • 各サイトの新規記事の汎用フォーマットURLの通知を受け取る。サーバーからその実体を取りに行く（オンタイムもしくはある程度まとめてから定期的に）
    • 各サイトから直接ポストされた汎用フォーマットデータを受け取る
    • サイト内に用意した投稿フォームからさまざまな形式での投稿を受け付ける

集約サイト側は、書誌データと書評データは分けて管理した方がいいだろうな。書誌データの方はAmazon Webサービスみたいなものが日本でも始まることを期待しつつ、基本的にはみんなで使い回せるイメージで。逆に集約サイトが書評サイトに書誌データを配信できるようにすることも考えた方がよさそう。

そうなると書評データの方は、ISBN＋各サイト独自の部分だけを集約サイト側に渡せばよくなる。書評の内容をどこまで集約サイト側に渡すかは、各サイト運営者の意志によっていろいろだろうな。少しも渡さないパターンもあれば、さわりの部分だけ渡すところもあれば、全文渡しちゃうところもあるだろう。どうせなら、サイトをもたない人が集約サイトにだけ書評を投稿できる仕組みももった方がいいんだろうな。

あと、集約するしたときの面白さのために、書評データには評価ランクみたいなわかりやすい項目もオプションとして用意した方がいいだろう。そうすると、評価ランクの平均とかいろいろ面白い見せ方ができるだろうし。

[ツッコミを入れる]

2003-02-11 [長年日記]

_ 書評リンクの話 3 (20:11)

ISBNはキーとして使えるのか、という話について。以下ISBN絡みについてのまとまった資料へのリンク。

まれに同一のISBNが別の書籍に振られている場合があるらしいけれども、楽天みたいに「出版日が新しいものを優先」ってことで、古い方は対象外にしてしまって構わない気がする。どうしても扱いたいならば、存在しないはずのISBN（風コード）を生成して無理矢理それで代替させるとか。

目的が「完璧な書誌データDBを作成すること」ではなく、「書評リンク集の基盤として使えるレベルの書誌データDBが欲しい」ならば、ISBNをキーに作成した書誌データDBでも十分に実用に耐えるだろう。イレギュラーなデータに対しては、運用でカバー（イレギュラーな対応を用意）で問題なさそう。

ISBNが不明な段階での書誌データ（主に新作を想定）に関しては、別テーブルにいったんデータを蓄えて、ISBNが定まった時点でメインのテーブルにデータを移行。ただし、書名や著者名による検索に関しては、そのテーブルに対してもメインテーブルと同様に（透過的に）行えるようにする。なんて感じでどうだろう？

あと、データフォーマットの話。タブ区切りテキストとかCSVとかだと、1フィールドに複数の情報をもたせるのがやりにくいのがガンなんだよな。適当なフィールド内区切り文字を予約して、それを使って表現することは可能だけど、そういう拡張をごちゃごちゃ考えるくらいだったら、はじめからその辺りまで吸収できるフォーマット（XMLとか）を採用した方が幸せになれる気がする。

というのは、そのデータフォーマットを再利用性のあるものとして扱いたい場合の話で、そこまで考えないならば、タブ区切りテキストとかCSVでも十分だと思う。その場その場で必要な情報を盛り込んだデータフォーマットを使うのは問題ないけれども、バックエンドで管理するデータに関しては多少リッチな情報をもっておいた方がいいよね、という話。いつでもリッチな表現（＝解釈にかかるコストが大きい）を使うのはバカらしいけど、後付けで必要になってずるずる仕様を拡張するのも大変だしね。

_ Amazon.com Webサービスを試してみた (20:11)

Amazon.comのWebサービス（XML Webサービスの方ね）を試してみた。PHPからアクセスするのも簡単そう、というか環境設定の敷居が低そうなんで、いろんなサーバーで使えそうだ。Amazon.co.jpでも始まってくれたら、自前のDBに情報が見つからなかった場合は、自動的にAmazon.co.jpにアクセスして必要な情報をもってくるような、書誌データ集約サーバーとか簡単に作れそうなのに（という利用法はグレイっぽいけれども、まあ言い訳を用意するのもそんなに難しくないだろう）。Amazon.co.jpの方でWebサービスをはじめる予定はないのかなー。

_ 特に使うあてのないWiki (20:11)

特に使うあてのないWikiをPukiWikiで立ててみました。使いたい方がいれば適当に使ってください。情報集積所とか意見交換所とか。

[ツッコミを入れる]

2003-02-12 [長年日記]

_ SH2101Vが来た (20:11)

うひゃひゃ、某仕事で使うテスト機のSH2101Vが来たよ。店頭以外でこんなもの触ったことがある人は世界でも100人単位のオーダーでしかいないに違いない。っつーか、まったく興味がない機械だったから、まったく情報をもっていない状態で触りはじめたりしたんで、使い方がさぱーり分かりませんよ。しかもこの機械、基本的にものすごく使いにくいインターフェースの持ち主だし。機械ものでここまで使い方にとまどったのは、は・じ・め・て（はぁと）って感じですよ。

ちなみにSH2101Vってなんなのかいまだに分からない方のために簡単に説明しておくと、NTTドコモさんのFOMAとかいういまいちな次世代規格機において、さらに異端児的な存在であるPDA風（？）端末のことです。なんかPDAみたいなでかい本体があって、それとBluetoothで接続するスティックタイプの受話器がついてくるんですよ。本体のOSが（旧）ザウルス系だってのは本当なのかな？

せっかく遊んでいい機械なんだから、しばらく持ち歩いて遊ぼうかと思ったんだけど、本体部が思ったよりもずいぶんでかくてじゃまなんで、普段から持ち歩いて使うってのはちょっと無理っぽい。っつーか、これだけ使い勝手が悪い機械じゃ、どっちにしろ三日でいやになりそうだ。

まあともかくSH2101Vで作ったasfファイルはffmpegでまともにデコードできるみたいでほっと一安心。なんかちまたに出回っているmpeg4エンコードされたasfファイルって怪しげなエンコードがされているものが多いのかな？　昔のシャープ製エンコーダが悪いのか？

[ツッコミを入れる]

2003-02-14 [長年日記]

_ Wikiの思想 (20:11)

ウムイの「凡人はつらい（http://www.ag.wakwak.com/~mai_u/umui/200302b.html#200302121908）」に書いたWikiに関するコメント。自分のところにもログとして残しておこう。

ishinao：Wikiは「Webの再開発」的な意味ももっていて、あまりにもサポート範囲が広い（夢が大きい）んで、まだまだこなれてませんけど、そのうちWikiの延長に普通に使いやすい何かが出てくるんじゃないでしょうか（技術者の遊び道具レベルで終わる可能性もあるけど）。Wikiって（現状では）一般的なWebのサービスよりもWebDAVとかと比べて語られるのが似合っている気がする。（2003/02/13 09:15）

ishinao：子門さんの言葉を借りると、Wikiは「プラットホーム」であり「アプリケーション」でもある（まだその辺りの切り分けが明確ではない）ので、プラットホームとして捉えるとWebDAVとかの仲間になるし、アプリケーションとして捉えるとblogシステムとか関心空間の仲間になる、って感じじゃないでしょうか。作る人はアプリケーションよりの意識で作るんだけれども、「プラットホームとしてのWiki」の定義が定かでないので、ある程度プラットホーム構築的な部分も意識せざるを得なくなる。Wiki Wayなんて言葉が出てくるくらい思想的な面白さもあるし。（2003/02/13 15:08）

ishinao：Wikiには「何もかもユーザーの自由にさせたい」という思想が背景にあり、しかし「あまりにも自由である＝使いにくい」ので、「使いやすいインターフェースを用意したい＝自由を制限したい」という葛藤が出てきてしまうのです。既存のWikiクローンは自由を尊重しすぎているため、その思想を理解した人が用途を限定して使わないと、すぐにぐちゃぐちゃなコンテンツができあがってしまう。（2003/02/14 09:17）

_ 想定ユーザーの引き上げ (20:11)

サイト改革を考えているうちに、自分の中で結構大きな心境の変化が出てきた。というのは、「想定ユーザーの引き上げ」というか「基本サポートするブラウザスペックの見直し」。

自分でもテキストWebブラウザ系は使うことが多いので、私が自分で作るページに関しては「テキストブラウザで支障がない」というのが基本だった。また、標準ブラウザについて「Netscape Navigator 4.xでも標準機能は一通り使える」あたりを想定していた。

けれども、ユーザビリティと機能性をどうするかをつらつら考えた結果として、もうちょっと想定ユーザー層を引き上げてしまってもいいように思えてきた。

「テキストブラウザでも支障がない」ではなく、「テキストブラウザでも最低限は見える」程度にしてしまっていいのではないか。同様に「NN 4.xでも最低限は見える」程度にしてしまっていいのではないか。テキストブラウザやNN 4.xのサポートは、あまりにも後ろ向きの作業の割には、それにかかるコスト（および削らざるを得ない機能）が大きい。現在と将来を見据えると、テキストブラウザおよびNN 4.xは最低限まで縮小してしまって構わないのではないか（完全に拒否するのはダメだけど）。

これからサイト改革を具体的に進めていく上で、いろいろな項目に関する具体的なスペックは決まっていくだろうけど、ひとまず決意表明。テキストブラウザおよびNN 4.xをきちんとサポートするためにかけるコストは、今後現在標準的な環境および将来主流になると思われる技術をサポートする努力にあてることにします。とかいいつつ、結局表面的には何も変わらないかもしれないけどね。俺の意識だけの問題かも。

_ CowardじゃないAnonymous (20:11)

ネット上で匿名で発言する利点はいろいろある。よけいな気遣いをせずに発言できるし、記名発言に付随する後腐れがないので、発言に対する敷居が低い。そのため匿名を許容する場においては、非常に活発な発言が期待できる。その具体的な事例は2chで多数目にすることができるだろう。

ネット上で匿名で発言する欠点はいろいろある。無神経・誹謗中傷発言によって傷つく人・怒る人が現れ、場が荒れることが珍しくない。また発言者の責任が追及できないため、場の責任者が代わりに責任を負う羽目になることもある。また発言者が特定できないためその発言にまつわる著作権の処理が曖昧になる。その具体的な事例は2chで多数目にすることができるだろう。

匿名の欠点は承知しつつも、匿名の利点を活かしたいので、私個人としては匿名の場は許容する方針をもっている。掲示板やWikiを作る際には基本的にAnonymousを受け入れる方針にするし、スラドみたいに匿名者をAnonymous Coward（いくじなし）と蔑称で呼ぼうとは思わない。

けれども、やはり匿名を許容する場にはAnonymous Cowardと呼んだ方がいい人も出てくるんだよなーと、「死にたいと思ったことがない人（http://www.ag.wakwak.com/~mai_u/umui/200302b.html#200302131803）」 のコメント欄を見ていて思った次第。

同じ匿名でも、単なるAnonymousとAnonymous Cowardは別物だ。Anonymousで発言するのは構わないけれども、Anonymous Cowardで発言するくらいならば、その発言は胸の奥で飲み込んでおくか、あるいは公でない場所で発言しよう。というのが俺のポリシー。他人に無理矢理押しつけようとは思わないけれども。

[ツッコミを入れる]

2003-02-15 [長年日記]

_ EclipseをEUC-JPで使う場合 (20:11)

Windows環境の話なんでほかのOS上だと違うかもしれないが、Eclipseのエディターエンコード設定をEUC-JPで使用する場合に、以下のような問題が生じるかもしれない。

  • 適当なテキストファイルを作り、エディタ上で「−」（全角のマイナス）を入力して、保存する。
  • それを別のエディタ（たとえば秀丸エディタ）で開いてみる。
  • 先ほど入力した「−」が「?」（認識不可能な文字）になっている。

Windows XP Professional＋Eclipse 2.0.2ではそうなる。これはおそらく、Windowsは基本がSHIFT_JIS、Windows XPの内部はUTF-8、Eclipseの内部はUTF-8、Eclipseのエディタ設定はEUC-JPという文字コード変換を経る中で、SHIFT_JISにおける全角マイナスの文字コードが失われてしまったということなのだろう。ただし、Eclipse上のエディタで確認する限りは、そのことに気づかない（一度ファイルを閉じてからエディタで開き直すとわかる）。

最近実験的に、仕事も私用もほとんどのファイルをEclipse上のプロジェクトとして管理している（Windows環境でのCVSへの登録が楽なんで。WinCVSはあんまり使い良くないし）ので、こういう問題が出てくるのはかなり痛い。エンコードをUTF-8に統一すればなんとかなりそうだが、まだUTF-8を日常作業の標準として使うのはキビシイし。

[ツッコミを入れる]

2003-02-16 [長年日記]

_ ばーびー (20:11)

最近車でずっとBarbee Boysを聞いていたのは、いわゆるシンクロニシティってやつですかね。この間突然Barbee Boysが聞きたくなって、保存状態が悪いうちのCD置き場（あちこちに散逸）を探したんだけどBarbeeのCDは見つからなくて、しょうがないからもう一回買い直すかと思いつつも、でも新譜で買うのは悔しいから渋谷のディスクユニオンに行ったら、バービーボーイズの中古CDなんてほとんど置いてなくて、新譜のベスト（と俺の知らないその後に出たらしいベスト。でも最初のベストはベストと言うよりは主だった曲をほとんど全部収録した単なるコレクションだったから、ちゃんと曲を絞ったベストを出す意味はあるよな）は置いてあったけれども、今さら5000円出してもう一回買い直すのもばからしいしと思って、もう一回家の中をくまなく探したら、唯一見つかったのは車の中に死蔵されていたBEST版のMDで、でも今さらMDが聞ける機材なんて車にしか積んでいなかったもんだから、しょうがなく毎朝ムスコを保育園に送っていくときにそれをかけながら歌っていたのですよ。この1週間ずっと。今日ようやく別のに入れ替えたちゃったけど（で入れ替えたのはBOOMのベストだよ。これもいいよねー。なんかおまえらイカテン出身やろ！　そうやろ！と意味なく関西弁でつっこみたくなる時代の空気を感じるよねー。と書いてから調べたら、BOOMはイカテン出身じゃないみたい。同時代ではあるけれど）。それにしても懐かしいやねー。この音域はカラオケとかで歌うとかなりきついんだよなー。でもコンタの声っぽく（いまいち響きが足りない高音域）歌うのは喉の調子がいいときには好きなんだよなー。ああ話を戻す（どこに？）と、グレコローマンかたぎ:http://www.chowchow.gr.jp/~sone/の2003-02-16 00:59で「バービーボーイズ復活？」的なことを知って、反射的に「いまみち」でググって見たら微妙なお宝ゴミを見つけたんですよ。これって新録なんだよね。もうずいぶんブランクも長いはずだけど、ギターもボーカルも昔のままだなー。でもこんだけ録音状態悪いと普通の音源としてはゴミだよな。ミュージシャンな人がこういう活動するのも過渡期な現在では大変そうだね。そのうちいわゆるゲイノージンとかイッパンジンとかの垣根がなくなって、発信する人−受け取る人がもっと自然にうまくやっていける（主にネットで）世の中になるから、それまでがんばってね。ってそういう時代はまだずいぶん先かな。特に日本では。もしも新譜を出すんだったら買うからがんばってね。

_ JBAの人たちって (20:11)

あたり関連のネタ。JBA（http://jba.ja.bz/）の方にもリンクを張っておくと、

とか。

本当にあの人達は、自分たちがあまりにも視野が狭すぎる（ほかの類似システム・技術・他の人たちがやってきたことに関して無知をさらけ出している）くせに、「俺たち（の着眼点）はすごいんだぜ」的な放言をするもんだから、JBAの主旨（だと思われるもの）に対して意味を見いだせる（興味を持つ）人たちも、現状のJBAの活動およびそれを構成する人たちに対しては「なま暖かく見守る（ウォッチする）」対象としてしか捉える気になれないんだってことがわからないのか。

JBAの人たちの中に、「今までの日本のWeb日記、テキストサイト、ニュースサイトにおける事例」をまともに調べた人はいるのか？　「既存のさまざまなWeb日記システムおよびコミュニケーション系システム」についてまともに調べた人はいるのか？　今まで様々な形で実用・実験的に行われてきた「Webサイトを通じたコミュニケーションの事例」に関してまともに調べた人はいるのか？　自分たちのやっていることのどこからどこまでが「車輪の再発明」に過ぎないもので、どれが「新しい発明（および発見、および活動）」として意味を持つのか把握できているのか？

私は、MovableTypeおよびその他blog系システム自体や、blog系システムを使った個人Webサイトが増えることによって起きうる革新の可能性などについては、とても興味があるけれども、そういうものに興味をもち可能性を感じている人間にとって、そういうものに対しての誤解や偏見を助長するようにしか思えない現状のJBAは、逆に迷惑な存在だ。現状のJBAなんて存在しない方が、MovableTypeや日本におけるblogの可能性がよほど増すんじゃないかとすら思っている。JBAの活動に意味があるとすれば、それは単に「広告塔的に目立っている」ことだけだろう。

ちなみにこういうテキストをJBAに書き込まないのは、Otsuneさんとほぼ同じ理由＋JBAの人たちが管理権限をもっているところに書き込む気になれないから。あと、今までの日本におけるWeb日記系コミュニケーションにおいては、他サイトへの言及を自サイトで公開するのは当たり前の行為だし（という文章に関して、そういうコミュニケーション形態を取る上で必要な技術や、それによって生じる問題点などについてすぐに理解できる人はJBAにいるのか？）。だいたい俺に関する言及はすべて俺の庭（システム）上でやれ、なんて俺様ルールが世の中一般（Webに限らず）に通じるかよ。「やってください。お願いします」としか普通は言えないんじゃないか？

せっかくだから、JBAの記事に対してTrackBackを送ってみたけれども、「TrackBackを送れよ」とか言う割には、「2バイトコードを送るときにどうやればいいのか」とかの説明がないんだな。JBAのサイトはUTF-8みたいだから、UTF-8にエンコードしてからURLエンコードして送らなければならないのかな？　まあそこまで試してあげる気にはなれないから、urlしか送らなかったけど。

もしかしてあの人たちは、TrackBackを送っても全然見てないんじゃないのか？　少なくとも表側に見えているインターフェース上は、新着TrackBackの有無が非常にわかりにくくなっていることは確かだけど、でもそれってたぶんJBA（の誰か）がMovableTypeを設定したときにそうしたんだよな。なんだかなー。

http://www.otsune.com/diary/board.cgi?act=read&msgid=571より

>最近は JBA の Blog では、発起人のJOI 氏、ENO 氏、Takemura 氏たちはおろか、NEOTENY や MESH のスタッフすらもあまり発言していないんですよ。せっかく、Blog を使って、個人が Web で発言するムーブメントを盛り上げようという趣旨でグループを立ち上げたんだから、続けろよって感じです。 >趣旨には賛同するけど、今のJBAのサイトの荒れようからすると入会したくねーよなー。っていうのがMTは便利だから使ってるけど、傍目で生暖かくヲォッチしてる人たちの本音だろうなーってつくづく思います。 >がんがん批判して皮肉ってネタにしておちょくって誹謗中傷して結構です。それも含めて Blog の連鎖になってくことでしょう。そもそも、Blog に中心となる協会とか連盟みたいな団体が必要なのかどうかももうわからんですよ。日本MovableTypeユーザー会っていうのはあってもいいと思うけど。

goyou氏の言葉は、mpm氏およびa77a氏にはさっぱり通じていないみたいだけど、JBA内で彼らにまともに意見できる（そしてまともに応対してもらえる）人はいないのか？　それともJBA内云々というのではなく、誰が言ったとしても彼らには言葉が通じないのか？

まあ内部の人間にも見放されつつあるのならば、そのうち勝手につぶれてくれるだろうから、放っておいてもいいんだろう。わざわざ「王様は裸だ！」とふれて回る必要もなさそうだ。いや、JBAは全然王様なんかじゃないんだけれども、王様じゃないものを王様だと（お偉いさんやマスコミに）思わせることが得意そうな人がいると、放っておくとあんなんでも王様扱いされかねないし（というか、一部そんな扱いをしているところがすでにあったっぽいし）。

心ある方たちはJBAのことはなかったことにして、日本MovableTypeユーザー会とか作ってがんばってください。その際には、TrackBackの国際化対応とかもよろしく。

結局JBAは、JBAの方針（として書かれていた文章）もろくに読んでいなかった方達が、去ったり記事を引っ込めたりした結果、goyouさんが一人で立て直すモードに入ったらしい。goyouさんのやりたいことは、たぶん多くの人が思っていたであろうJBAっぽい活動ではあるんだけど、今からこれをはじめて間に合う（人が戻ってくる・やってくる）んだろうか？　JBAの名前を使わずにやった方がよほどいいと思うんだけど。wikistmaniaを作るついでに日本のMovableTypeユーザーのサイトをいろいろ回ってみたけど、日本MovableTypeユーザーグループ的な活動をしている人たちって結構いるみたいなのに、その人たちがあまりJBAに近寄ってきていない現状を改善できるのか？

と思ったら結局元の鞘に戻ったらしい。joi氏やtkm氏がそちらを支持しているからだ、と理解して構わないんだよな。

このセクションに対するはてなブックマーク

[ツッコミを入れる]

2003-02-17 [長年日記]

_ RSSとTrackBackを実装 (20:11)

RSSとTrackBack（もどき）をWikiLikeに実装中。

RSSについては、上部メニューのRSSをクリックすると表示される。やっつけで実装したんで不具合があるかも。一応RSSビューアでは見えていたような気がする。

TrackBackについては、微妙に独自実装。ページメニューにあるTrackBackをクリックすると、通常のTrackBack Ping Urlが表示される。たぶんMovableTypeとかでこのURLを指定すれば、通知が来るんじゃないかな？　動作テストはしていない。送信側の文字コードが分かっている場合は、各文字コード用のPing URLを叩いてもらった方が文字化けのおそれが少ないはず。

あと、その下にあるフォームからTrackBackを送ることもできる。これはTrackBack非対応なCMSなんかから送信するための補助的存在。

で、実際に送信されたTrackBack通知については、WikiLikeではコメントとして保存している。TrackBack用のテーブルとか用意してもいいんだけど、まあこの実装はあくまでテスト実装だしね。現在のWikiLikeのコードは破棄して作り直すことが確定しているんで、今さらこのコードをまじめに拡張してもしょうがないし。

あとは、こちらの記事更新時に他のサイトのTrackBack Ping URLを叩きに行く部分を実装して、RSSとかに各記事のPing URLを掲載すればいいのかな？　ただ他のサイトのTrackBack Ping URLを叩きに行くときの文字コードとかどうすればいいのかな？　いちいち確認する？　気にしない？

RSSにTrackBack Ping URLを掲載してみた。こんな感じでいいのかな？　あとそういえば、この記事に関するTrackBack一覧をRSSで返すインターフェースも必要なんだっけ。それは面倒くさいからよほどやる気があったら実装しよう。

2003/03/14追記

各ページにTrackBack Ping URLを通知するためのRDFを埋め込んだ。一応これでMovableTypeから半自動的にTrackBackを送ることもできるのかな？　PingBack Serverの情報も埋め込んでおいたけれども、こっちはまだ受信側を作っていないので送っても届きません。

っつーか、PingBackの受信側は作ってもいいけど、送信側を作りたいと思わないんだよなー。記事をPOSTするたびに記事中に使われているリンク先を片っ端からHEAD＆GETするなんていやだもんなー。

[ツッコミを入れる]

2003-02-18 [長年日記]

_ TrackBackコードサンプル (20:11)

せっかくだからWikiLikeをTrackBack対応にした部分のサンプルコードを載せておこう。PHP 4.2以降＋マルチバイト関数環境用。本物は、すでに廃棄処分が決まっている古い自作ライブラリを使っているんで、その部分を普通のコードに書き直してある。あと、TrackBackで受け取ったデータを保存する部分（SaveTrackBack）の中身は削ってある（実装するシステムに依存）。その他できるだけ汎用的に直してあるつもり。まったくノーコメントだけど、まあ何となく分かるよね。もともとはライブラリ側でやっていた、外部からやってきた変数のstripslashesみたいな一般的な処理は端折り気味。

以下長いんで別ファイルにした。 http://ishinao.net/dev/trackback.php.txt

_ Snoopy v0.94 (20:11)

Snoopy v0.94というUserAgentがRSSファイルにやたらとアクセスしているみたいなんで、なんだろうと思って調べてみたら、Snoopy（http://sourceforge.net/projects/snoopy/）ってPHP用のWebブラウザシミュレーションクラスがあるんだね。PerlのLWPモジュールみたいな機能があるのかな？　PHPではその手の用途にはCurlを使うもんだと思っていたんでちょっと勉強になった。今度試してみよう。ところでこのアクセスって、誰かがPHPを使ってRSSMixみたいなことをしているのかな？

_ 雑誌サイト (20:11)

Snoopy v0.94のコメント欄のやりとりで出てきた話が面白かったので、こっちにも書いておこう。

RSSみたいな各サイトの情報を機械的に取得できるようにする技術は、複数サイトにまたがった情報の共有を加速する。

アンテナや更新チェックツールを駆使して、タブブラウザで複数タブをがしがし開きながらさまざまなサイトを巡り、面白そうなコンテンツを見つけたらそれをクリッピングしコメントをつける。日本の個人ニュースサイト系の人たちはそんなことをしているんだろう。

海外のblog系の人たちも基本的には同じだけれども、RSS配信が日本よりも広まっているため、RSSクライアントツールに自分がチェックしたいサイトのRSS URLを登録しておけば、直接そのサイトに行かなくてもそのサイトの更新状況および更新された記事の要約を得ることができる。ずらっと表示された要約付き一覧の中から、面白そうな記事を選び出してコメントをつけると、気がきいたblog系ツールならばそれをそのまま自分のサイトにアップロードしてくれて、さらにコメントをつけた先のサイトに自分がコメントをつけた旨を通知してくれる（TrackBack）かもしれない。

どういうやり方にしろ、そこで行われているのは基本的にWeb上に存在するさまざまなコンテンツを、独自の視点で選択・編集し、さらに自らの記事をも追加して、新しいコンテンツとして成立させるという作業だ。複数のサイトにまたがったコラボレーションともいえる。

ただし、現在のところはそこで編集に使われる素材は、コンテンツのタイトル・URLおよび必要最低限の引用程度に過ぎない。そのため、個人ニュースサイトやblog系サイトのコンテンツは、データの羅列的なものになってしまう。

しかし、RSSでは通常記事の要約（サマリー）も配信することが多い。それはすなわち、コンテンツ作者がコンテンツの一部について他のサイトでの二次利用を許諾しているようなものだ（このあたりはきちんとコンセンサスを得る必要がある）。もしも要約テキストだけでなく、画像などのデータの二次利用も許諾されるようになれば、それらのコンテンツを二次利用するサイトでは、現在のデータの羅列以上の表現が可能になるだろう。それはまるで雑誌の編集作業のようだ。

雑誌サイトという言葉を聞いて私の中にわき上がったイメージは上記な感じ。個人ニュースサイトおよびblog系サイトの行き着く先としてなかなか面白いかも。

_ RSS版textmania (20:11)

データ収集元にアンテナ系サイトではなく、RSS配信サイトを使ったtextmaniaを作ってみようかなー。そうすると、更新時刻だけでなくもっとリッチな情報（サマリーとか）もまとめて表示できるようになる。mylistみたいなカスタマイズリストを表示すると、まるではてなアンテナの詳細表示モードみたいな感じになるんだろうな。

とかいくつも作りかけのネタを放置しているくせに、よけいなことをたくさん思いついてしまうのでした。でも、これはたぶんそんなに作るの大変じゃなさそうだよなー。

[ツッコミを入れる]

2003-02-19 [長年日記]

_ 白痴ズ (20:11)

ミーティング中、なにかの話題で白地図という言葉が出た瞬間に、私の頭に思い浮かんだのは、最近週刊マガジンで始まったお笑い芸人マンガに、白痴ズというコンビ名の芸人が出てきて、すったもんだの末テレビに出たけどやっぱり放送禁止になって「言葉狩りだ！」と騒いだりするストーリー。（私の頭の中の）白痴ズはあいにくあんまり面白い芸人じゃなかったので、彼らは放送禁止になったって構わないんですけど（って何妄想に妄想を重ねているんでしょうね、この人は）。ああそれにしてもATOKはなぜ変換すらさせてくれない？　危うく白恥を選択しそうになったじゃないか。

_ wikistmania (20:11)

RSS版textmania。RSSを提供しているサイトを定期的に巡回し、記事単位の更新情報（ある場合は要約も）を取得し、更新時刻順に表示する。チェックしたいサイトを選択（カスタマイズ）することも可能。

wikistmaniaといっても別にWiki系サイトだけを対象としているわけじゃなく、blog系サイト、Newsサイトなども対象。Newsサイトに関しては、Bulknews（http://bulknews.net/）経由でRSSを取得しています（2003/7/22〜）。

[ツッコミを入れる]

2003-02-20 [長年日記]

_ MagpieRSS (20:11)

PHP用のRSSライブラリ。XMLサポートされたPHP4以降で動作する。

基本的な使い方は、

require_once("rss_fetch.inc");
$rss = fetch_rss($url);

だけ。ただし、定数宣言でカスタマイズしておいた方がいい。詳細はrss_fetch.inc内のinit関数を参照。デフォルト設定は以下。

define('MAGPIE_CACHE_ON', 1); //キャッシュ有効
define('MAGPIE_CACHE_DIR', './cache');  //キャッシュディレクトリ
define('MAGPIE_CACHE_AGE', 60*60); //キャッシュ有効時間（秒）
define('MAGPIE_CACHE_FRESH_ONLY', 0);
define('MAGPIE_DEBUG', 0);  //デバッグ情報出力
define('MAGPIE_USER_AGENT', 'MagpieRSS/0.3 (+http://magpierss.sf.net)' ); //RSSファイルを取得する際のUserAgent名
define('MAGPIE_FETCH_TIME_OUT', 5);	//RSSファイルを取得するときのタイムアウト時間

RSSを取得したときに、そのRSSがキャッシュから取得されたかどうか判別したい場合は、

$rss = fetch_rss($url);
if ($rss->from_cache == 1) {//キャッシュから取得した場合}

といった感じで。

微妙に不便なのは、設定を定数でやっちゃっているせいで、アクセスするサイトごとに違う設定でアクセスしたいとかができない。可変にしたい部分（キャッシュの有効期限とか）だけでも変数から取るように変えようかな。

[ツッコミを入れる]

2003-02-21 [長年日記]

_ 日本IBM、次世代グループウェアを開発表明――携帯電話から利用可能な“Next Gen Mail”を第2四半期に出荷 from ASCII24 (20:11)

>具体的には、“WebSphere”はオンライントランザクションシステム”からe-ビジネス統合インフラへ、“DB2”はリレーショナルデータベースからインテグレーションインフォメーションインフラストラクチャへ、“Lotus”はメッセージング/メールからアドバンストコラボレーションおよびeラーニングへと変貌する

よく分からない。Notes/Dominoのバージョンアップなのか、まったく新規なのか、Notes/DominoをJavaベースに移植したものなのか。Notes/DominoをJavaベースに移植しつつ、バックエンド周りはDB2に置き換えて、フロントエンドはNotesよりもむしろWebベースを中心に考える、って感じかなー。

なんにしろこの分野はまだまだ可能性がある。今のところ、ExchangeとNotesとサイボウズが一応大手なんだろうけど、どれも大していいできだというわけではないし。

_ ワイヤレス・ブロードバンドを急拡大？ 『メッシュボックス』 from HOT WIRED JAPAN (20:11)

アンテナの依存性を低くして、端末 to 端末の通信をサポートしつつ、さらに直接端末 to 端末通信ができない場合は、届く範囲の端末が仲介役になるって感じかな？　モバイル用途を考えると、帯域幅と電力消費量に不安を感じるんだけど、これは単にワイアレスってだけでモバイルが主用途ではないんだろうか。

_ blog化計画？ (20:11)

ああ、俺はいったい何をやっているんだろう？　書評リンク集とかキーワードリンク集とかblogmapの改良とかいろいろやろうとしていたことがあったはずなのに、shiroさんが面白そうなことをやってみせるもんだから、ついついつられてwikistmaniaなんてものに手を出してしまって、その情報収集にあちこちのWikiとかblog系サイトを回っているうちに勢い余って、TrackBackのテスト実装とかに手を出したら、思わずここをblogっぽくしてみようかとか思ってしまい、もともとhnsと連携するように作っていたNewsWatchのバックエンドインターフェースをWikiLikeにつなげるように変更して、いかにもblogっぽい記事をがしがし書けるような仕掛けをもってみたりして、あとはデザインをなんとなくblog（というかMovableType）っぽくすればいいのかな？　ああ、破棄する予定のコード（現在のWikiLike）にこんなに手をかけるなんて不毛だ。でもここまで行ったら、データ形式だけは現状のものを維持するか、最小限の手間でコンバートできるようにしておくしかないな。

そうだ思い出した、なんでblog化しようかと思ったのか。直接的な原因は、D-Point（http://www.ryu-sei.com/d-point/）の右側にあるメニューでこのページが「ウェブログ」ってカテゴリーに入っているのを発見したからだった。えーっ、俺ってウェブロガーだったの！と反射的に拒否したい気持ちになりながらも、どうやら体は拒否できなかったようでした。

WikiLikeは基本的にテンプレートベースでカスタマイズしやすくしていたはずだったんだけど、CSSデザインされることを前提の設計にはしていなかったし、場当たり的に拡張した部分も多かったんで、結局コードの方にもそこそこ手を入れる必要があった。で、想定ユーザーの引き上げ以来のポリシーとして、Netscape 4.xおよびテキストブラウザサポートは最低限のレベルまで落としてデザインしているんだけど、思ったよりもNetscape 4.xでちゃんと見えるな。まあNetscape 4.xではダメっぽいものを忌避する本能が体に染みついているからかもしれない。

_ 【IDF Spring 2003レポート】2日目基調講演 - Centrinoのパフォーマンスを披露 from MYCOM PC WEB (20:11)

VAIO SRX7を買い換えるのは、こいつの値段がこなれてきた頃かな。それにしても、

>Bluetoothでファイルを転送しながら、スムーズに802.11bでストリーミングビデオを受信できるソリューションを披露して、次世代システムでは接続性もさらに向上することを示した。

ってどうやってそんなことをやるんだろう？　ソフトウエア制御で可能ならば、うちのSRX7でも対応して欲しい。そろそろBluetooth機器がいろいろ出始めて来たけれども、干渉が気になって同時にONにする気になれない。

_ 「日本MMOの何が問題だったか」　〜JASRAC顧問、田中弁護士 from ZDNet (20:11)

せっかくJASRACの顧問弁護士が出てきたというのに、特に有意な情報は含まれていない気がする。特に明確な基準もポリシーもないけれども、日本MMOは「灰色の色が濃かったから有罪です」って感じなのかね。

>予測される権利侵害を制御するシステム（技術）を開発した上で当該ビジネスを開始するというのがあるべき姿だろう

ってのも微妙な話だ。制御っていってもその範囲は広いしね。既存の権利自体を制御するって手もあるし。

_ 覚醒剤の助けで戦闘に臨む米軍兵士たち from HOT WIRED JAPAN (20:11)

>「泣き言は止めろ。軍医のところに行って『行くか行かないか決める』薬をもらってこい」

とか

>デキセドリンを受け取ったパイロットが署名する「インフォームド・コンセント」の書類には、服用が自由意志に基づくということが最低7回書かれていると指摘する。ところがこの書類には、パイロットが服用を拒否する権利を行使した場合、地上勤務を命じられることがあるとも記されている。

とか、まるで小説のようだね。この手の薬品は（アメリカで／日本で）法律で禁止されていないのか気になってちょっと調べてみたけれども、覚醒剤系の薬ってのはいろんな種類があって市販されているものもたくさんあるみたいだ。

_ 800万件のクレジットカード番号盗難、FBIが捜査 from ZDNet (20:11)

>ハッキングに遭った米オマハのData Processors International（DPI）は、VISA、MasterCard、American Express、Discover Financial Servicesのクレジットカードによる決済処理を請け負っている。

このDPIって会社は大手データセンターなの？　それともクレジットカードデータを管理する専門の会社なのかな？　それにしても、3万人の情報が盗まれたときの被害額が270万ドルだとすると、800万人の情報が盗まれたときの被害額は単純計算で7億2000万ドルですか？　実際にそれより少なくなるのか多くなるのかの見当もつかないけど。

>「米国では、クレジット詐欺の被害額はクレジットカードによる買い物額のわずか7％にすぎない」

ってその数字は十分に大きい気がするんだけど。でもわざわざそんな数字を出したってことは、他の国ではもっと多いってことなんだよね。クレジットカードを使うということは、その数字を上乗せされたぶんの金を払わされているってことか。

_ ソニー・コンピュータエンタテインメントPlayStation BB Unitなどを5月から店頭販売 from GAME Watch (20:11)

ちょっと前まで欲しかったんだけど、結局いまいち盛り上がらない（ゲーム数が増えない）感じなんで、どうでもよくなって来ちゃったな。

_ 腕時計型“SPOT”の可能性――シチズン開発者に聞く from ZDNet (20:11)

なるほど、SPOTの雰囲気がようやく分かったよ。Webで失敗したプッシュ型コンテンツ（ちょっと前に復活しそうな気配があったけど、また聞かなくなったな）を、UIと回線を変えて、腕時計＋FM電波でやろうってのね。確かに常時身につけている何かにパーソナライズされた必要な情報がどしどしたまっていくってのは悪くないイメージだ。

でもそういう目的だったら、俺ならばメールベースに実装する方向で考えるな。適当なメールアドレス（サーバー）に必要な情報をどしどし収集して、それをさらにフィルタリングしてユーザーが現在受信できるメールアドレス（携帯とか会社とか家とか）に転送する感じで。日本だったらUIとしては腕時計よりも携帯メールの方が当たり前な気がするし。一次サーバーからどういう情報を発信して、それを二次サーバーでどうフィルタリングしてユーザーの手元に転送するかが肝だな。

このセクションに対するはてなブックマーク

_ CentrinoとDothan、燃料電池の最新情報――IDF2003レポート from ZDNet (20:11)

>Intelが投資している燃料電池技術のベンチャー企業、PolyFuelが開発したPC向け燃料電池を紹介。現在は最大で50時間しか駆動できないが、近い将来にはより小型で無補給150時間の稼働が実現できるとしている。

バッテリーがそのくらいもつようになるとPC云々というレベルを超えて、ライフスタイルが変わってきそうだな。時計みたいに常時持ち歩いていても、滅多に電源が切れることがない機械が、もっとハイスペックになっていく感じか。たとえば常時無線通信を行うPDAが、普通に使っても一ヶ月くらい電池がもつようになったらどうなるだろう？

_ グレーマーケットによるハイテク業界の打撃は「年間50億ドル」 from ZDNet (20:11)

メディア系コンテンツの著作権侵害ネタかと思ったら、ハードウェアの非公認ルート販売ネタなのね。

>正規ルートを活用しないと、消費者は破損品や保証のない商品を購入するリスクを背負うことになる。このことは消費者にマイナスというだけでなく、顧客／投資家間での企業の評判を落とすことになりかねない

とか言われてもそっちの方は素直にうなずく気にあまりなれないなー。正規ルートが盛り込んでいる配送＆サポート費用ぶんを削ることによって利益を出せるんだとしたら、それは非正規ルートで販売している業者の企業努力って気がしないでもない。まあちゃんと「正規なメーカーサポートは受けられませんよ」と言って売っているのならば、の話だけど。

メーカーさんはトータルな企業戦略として、目先の損失等は度外視して地域ごとの値段を決めたりすることもあるだろうから、その辺りの裏をつかれるととても困るというのは分かるけれども。

_ FIA unconcerned by Williams/McLaren threat from F1-Live.com (20:11)

>including one lap qualifying and no refuelling between qualifying and the race

1ラップ予選は知っていたけど、予選から決勝まで無給油なんてルールも追加されたんだっけ？　1ラップ予選に関しては、ドライバーのコメントとしては歓迎する方向のものしか見かけなかったけど、チームとしてはウィリアムズとマクラーレンが反対していたんだね。きっとフェラーリも反対なんだろうけど、フェラーリは今は何も言えない（言わない方がいい）立場だし。

_ National Semi、「Geode」売却へ from ZDNet (20:11)

Geodeはまだナショナルセミコンダクターがもっていたんだっけ？　VIAにCyrix資産を売り払うときにそれだけ残したんだったかな？　旧10x系FIVAユーザーとして、一時期はああいうミニノートPC向けCPUの期待の星と見ていたんだけど、バギー（組み込み周辺チップ機能周り）だし遅い（クロックと比較して）し全然開発が進まない（まだ500MHzを超えていないんじゃないか？）し、結局そのうちトランスメタが出てきたりインテルが本気になったりしてくれたから、今さらもうどうでもいいやって感じだ。

_ ニュース系blogにWikiLikeのコンセプトはよく似合う (20:11)

と思った。特にニュース系に限らず、個人Webサイトのコンテンツ管理ツール（CMS）として、キーワード検索を中心にコンテンツを管理するWikiLike的な思想は似合っているんじゃないかとは思っていたんだけど、ニュース系の記事をいくつか投稿してみたらその連携具合がとてもいい感じだ。

ジャンル分けとかタイトル付けとか、その辺りを真面目に管理するのはとても面倒くさい。理想的に正規化された情報をコンテンツとしてPOSTしていくシステムを作るのはそう難しくはないけれども、それを運用するのがとても大変だ。特に個人Webサイトのようなルーズに更新するコンテンツが多いものの場合、いちいちそのコンテンツのデータの正規化なんて考えていられない。

で、WikiLikeの場合はデータの正規化を投げ出して、すべてキーワード検索で実装する方針にした。ただし、全文検索は負荷が高くなりがちでいやなので、コンテンツごとにきちんとキーワードインデックスを用意する。キーワードインデックスの生成方法としては、日本語の形態素解析を行ったりする方法もあるけれども、WikiLikeではそれは使わない。ユーザーが意識してキーワードインデックスを作成する方針をとる。ただし、入力方法が面倒くさいのはいやなので、日本語対応Wikiでよく使われているブラケットネーム（二重大括弧でキーワードを囲む）を採用した。WikiLikeにおいてブラケットネームは、そのコンテンツのキーワードを指定する意味と、同じキーワードをもつコンテンツを検索するリンクと言う二つの意味を持つ。本文中に出てこないキーワードを明示的に追加することも可能になっているので、メタキーワード的なものはそちらに入力しておけばいい。

というシステムでニュース系記事を投稿していく場合、ひとまず正規化しやすい情報については自動的にメタキーワードとして放り込んでおく。で、本文を適当に書いていくときに、この文章で重要そうだなと思った部分はブラケットネームで囲んでおく。そうすると、類似キーワードをもつコンテンツが自動的に結ばれていく。

ちょっとユニークなメタキーワードを用意しておけば、それはジャンル検索用のキーワードとして使える。一般名詞すぎるものはキーワードとして登録しなければ、たまたま同じ単語を使っていただけの関係ないコンテンツは検索されないし。

と自画自賛を書いているうちに疲れてきたので、本日の講釈はこれにて終了。

_ 「人は一人では生きられない」 from 環和我話わわわわ (20:11)

に書いたコメント（ツッコミ）を転載。

>「電話の声」もそうだけど、「相手や状況に応じて自分（の見せ方）を変える」ってのは当たり前のことで、Web人格は不特定多数の正体不明の人を文字ベースメディアで相手にするときの自分の見せ方に過ぎないと私は思います。 > >その人格の変化を「違う自分」だと思えば「ネットでの知人とリアルでの知人は別物」になるし、「自分の一部」だと思えば「ネットでの知人もリアルの知人も一緒」になるのかな？

俺の前のnijimuさんのコメントを受けて書いているので、そっちも参照。こういうのってやっぱりTrackBackを使って表現したいよなー。

_ ［WSJ］ 米、イラク攻撃に“電磁パルス爆弾”使用の可能性 from ZDNet (20:11)

>この「e-bomb」と呼ばれる新兵器は、高速で電磁パルスを放出するというもので、まだ実戦でのテストは行われていない。

>この兵器のもたらす損害は恒久的なものであるため、紛争解決後のイラクの経済復興にはかなりの費用がかかるだろう。

さすがアメリカ。現代の社会インフラに対する原爆みたいなものを作ってきたね。ある程度の範囲に渡る電子機器を恒久的に破壊する電磁波兵器って、人間に害がないとも思えないんだけど、その影響範囲にいた人間はどうなるのかな？　生き物だけ殺す中性子爆弾の方がまだかわいい気がする。一応現代社会の戦争の大義名分としては、戦闘行為に直接関わっているものだけを攻撃しようってことになっていたんじゃなかったっけ？

_ マイクロソフトがまったく新しいIMソフトを投入! - その名も「3°(ThreeDegrees)」 from MYCOM PC WEB (20:11)

技術的にも実用的にもとても面白そうだけれども、いろいろと危うそうなものを出してきたなー。

ひとまずこのWindows Media系でよく使ってくる外観が嫌いだ。こういう非矩形ウィンドウアプリケーションって、リージョン使って透過ウィンドウを作るだけだから、やってみると簡単に作れる割にはインパクトが大きい（今はそうでもないかな）んで作る側としては面白い（営業的に）んだけど、実用上はじゃまくさいことが多いしな。

>3°musicmixは、プレイリストにアップした音楽をグループ内で共有鑑賞できるという機能だ。

>実際の共有は、あるメンバーが希望する曲をプレイリストから選択すると、その曲を追加したメンバーのハードディスクから音楽ファイルが再生するようになっている。このため、ファイル共有ソフトなどで問題となっている違法な音楽ファイル交換はできない仕組みになっている。

って、これは全然OKじゃない気がするんだけど。データの保存を（表向きは）できないようにしているからOKなの？　そうなると今度は公衆送信権の方と関わってきそうだけど。そういうのがOKだったら、自分がもっている音楽・動画ファイルをWeb上のクローズドなスペースにアップして、友達に自由に再生されてもOKってことかな？　ダウンロード保存される可能性があるとダメなら、ストリーミング形式で配信すればOK？（それでもダウンロード不可能なわけじゃないけど）

ところで「Microsoft Windows XP Peer-to-Peer Update」ってもしかして、Grooveと何か関係あるのかな？　それともWindowsの基本機能として取り込んだのか？

_ Ralf eyeing Toyota switch? from F1-Live.com (20:11)

トヨタってそこまで有望かなー。ラルフはモントーヤに押され気味な自分をごまかそうとしていないか？　どちらかというとモントーヤよりはラルフの方が好きだから、ラルフには実力でモントーヤを打ち破って、実質ファーストドライバー的な地位を得てもらいたいもの。

_ 思いがけず姿を現したOneNote from ZDNet (20:11)

別に何も目新しいことはないよな。今までのWordとかExcelでもほとんど同じようなことは（技術的には）できた気がする。ただ、インターフェース的にそういう用途（ドキュメントを作成していく過程での素材をとりまとめる用途）では使いにくかったから、下書き専用のWordを出してきたって感じかな。あと、Tablet PCを出したんでそれ系のインターフェースも標準装備して（こっちの意味の方が大きいかも）。さらに、今までのWordとかで似たようなことをしようとすると、処理が重いOLEとかを使って複数機能（アプリケーション）連携する羽目になったから、その手の機能を一つのアプリケーションに取り込んで動作速度を速めたって意味もありそう。

まあ悪くはないけれども、俺的にはマイクロソフト的なリッチなインターフェースよりも、テキストベースでちょっと人間側が工夫をすることでいろいろできる、Wiki的なアプローチの方が好きだ。

_ しょぼーん（´・ω・｀） (20:11)

この間会社の飲み会で2chの話題が出ているのを他人事のように聞いていたら、「そういえば石川くんの名前もよく見かけるよ、三鷹ういスレッドとかで」と言われてしまいました。しょぼーん。でもその単語はその人と私以外には通じなかったみたいでした。っつーか、みんな知ってたら怖いよ。

_ ホンダ『フュージョン』、人気に応えて復活 from auto ASCII (20:11)

フュージョンは好きなんだけど、フュージョンに乗っている若者たち（主に渋谷近郊）のファッションが嫌いなんだよな。なんであんた達はそろいもそろって似たような半ヘルですか？

_ photo journalist blog from On Off and Beyond (20:11)

>blog型個人情報発信社会では、その情報は玉石混交だが、とにかく絶対量が多いから、玉の量も多くなるはずだ。その中から、信頼できる情報をピックアップして、さらにその情報を周囲に口コミ的に伝えて流布させるかどうかは受け手側の責任となる。優れた情報を広めるかどうかの責任が「発行側」から「読み手側」にシフトする、と言ってもいいだろう。

blog（というか個人Webサイト）による個人レベルでの情報発信が一般的になることで、今までマスコミ系メディアに握られていた情報のコントロール権が、一般の人々の手にうつってくることになる。

マスコミによる情報の恣意的な（と感じることがある）操作は気に入らないが、それでもマスコミによる発信においては複数人による編集という過程が存在しており、それが最低限の一般性のある安定したクオリティを保証していた。しかし、個人レベルの情報発信においてはその過程が省かれるため、従来的な意味でのクオリティは落ちることになる。しかし、従来とは異なる新しい価値観――たとえば速報性、多様性、局所性などに重きをおけば、それが即情報自体のクオリティダウンを意味することにはならないだろう。情報に対する価値観自体が変わることになるのだから。

という理想を思い描きつつも、情報のコントロール権を一般の人々の手に取り戻した結果が、衆愚を晒す結果にならないことを祈ろう。最悪のパターンとしては、せっかく手に入れたメディア（ネット）で愚かしい事件がたくさん起こった結果、ぎちぎちに法的な規制がかけられてしまい自由を失うという展開か。

[ツッコミを入れる]

2003-02-22 [長年日記]

_ ［ウェブログ関連］ 23：25 from チャッピーのおまけ日記 β (20:11)

DBを使わない、「導入しやすいblogツール」を作ってくれたらなあと思っているようです。

導入しやすい日本製のblogツールを新規に作るよりも、既存のWeb日記システムにblogツールと接続する機能（RSS、TrackBack）を拡張した方がいい気がする。

単純にコンテンツを作成・更新・管理する機能は日本のWeb日記ツールも十分優れているし、ユーザーも慣れている。blogツールが優れているところは、サイト間をまたがった情報の連携が考えられているところくらいで、それは別に既存のWeb日記ツールに互換機能を搭載することも難しくない（ここのWikiLikeにRSSとTrackBackが実装できたし）。

ひとまず私は今hnsにRSSを組み込もうと試してみている（→wikistmaniaのコメント欄参照。追記：HNSにRSSをでだいたい実装完了）し、tDiaryの方はすでにRSSプラグインの実験をしていたり、たださんが「ところで、誰かtDiary用のtrackbackプラグインを書かないかね;-)」（http://sho.tdiary.net/20030216.html#p02）とか言っていたりするので、実装する価値があると思える状況になったらいつの間にか実装されていることでしょう。

Web日記システムをblogツールに置き換えるというのではなく、Web日記システムがblogツールのいいところだけを消化吸収してしまえばいい。理念的な話については、特に向こうから学ばなければならないことはなさそうだし（参考にはするけど）。

_ #2 [web_memo] wikistmania from Mint Julep (20:11)

ところでいしなおさんのところのPukiWikiはdetailまで出力されるのにうちはそうじゃない…って、これはなにか手を加えてるのでしょうか？

自分用に適当に変更したんで、細かいところまで覚えていないんだけど、ひとまず思い出しつつ変更箇所を。

pukiwiki.ini.phpに内部文字コードを明示する

$inner_encoding = "euc-jp";

を追加。

index.phpの

else if(arg_check("rss"))
{
  if(!arg_check("rss10"))
    catrss(1);
  else
    catrss(2);
  die();
}

を

else if(arg_check("rss"))
{
  catrss(2);
  die();
}

に変更。これはかなり場当たり的な修正なんで、本家に取り込んだりするならばこういうやり方はやめた方がいい。

あと、rss.phpはあちこちいろいろいじったんで、ソースを丸ごと載せておく（http://ishinao.net/dev/rss.php.txt）。

これでRSSの各記事アイテムで、<dc:date>に更新時刻情報を<description>に要約を掲載するようになる。ちなみにmb_string系関数必須。要約の文字数は、rss.phpの45行目の

$desc = htmlspecialchars(mb_substr($desc,0,200));

で200文字にしてあるんでこの数字を変えればいい（本当は設定から文字数をもってくるようにした方がいいんだろうな）。PukiWikiのコード（の全体像）はほとんど見ていないんで、非効率的な実装かもしれない。

あとで追加しようと思っていた機能としては、本文の最初に出てきたURL文字列を<dc:references>に追加、本文の最初に出てきたISBNナンバーを<dc:identifier>に追加、とかしたいところ。

_ コンピュータと通信の融合、その最新状況は？ from ZDNet (20:11)

CMOS集積回路にワイヤレス機能を実装する技術の最新状況を報告し、802.11、Bluetooth、UWBなど通信方式を自動認識して自動的にネットワークに接続する技術を開発していると話した。

モバイルでの通信の理想型はそれだろうな。もはや通信方式なんでどうでもよくて、現在の状況における最適な通信方式を自動認識して勝手にそれにつながる状態。現状でも、PHSと無線LANがシームレスに切り替わるようなハードウエア＆ソフトウエアをどこかが提供してくれればできそうだけど。

_ 次世代PC Audio、“Azalia”とは？ from ZDNet (20:11)

同時に15ストリームのオーディオを同時並行処理可能で、リンク帯域も必要十分なレベル（毎秒48Mビット）に引き上げられる。これにより、24ビット/192KHz、8チャンネルのオーディオにも余裕で対応できるようになった。

ってスペックはすごいけど、たいていの人にとってPCの（あるいはCDの）サウンド機能ってもはや向上させる価値がないものになっている気がする。スペックが高くなったところで、それをスペック通りにきちんと再生する装置（スピーカー）が一般的じゃない以上、実用上意味がないし。

現状のPCおよびCDのサウンドを、そのスペック通りに再生できる環境をもっている人って、かなりのオーディオマニアかプロだけじゃないかな。たいていの人はPCのおまけスピーカーを使っていたり、普通のミニコンポとかカーオーディオとか携帯プレイヤーで聞いているもんだろう。そういう人は現状のCDオーディオクオリティもフルスペックで再生できていないと思う。

邪推すると、最近ではCPU、メモリ、ビデオ関連の新技術のネタ（主に営業トーク向けに使えるもの）が尽きつつあるんで、まだ手つかずだった（＝手をつける価値がさほどなかった）オーディオ方面にネタを求めてきたんじゃないか。オーディオはビデオ系と比べるとスペック的な革新の余地がまだまだあるし（それに意味があるかは別として）。

_ “正直な泥棒”――ファイル交換取り締まりに新たな脅威 from ZDNet (20:11)

米国の音楽業界は、米国で訴訟を起こすことで