_ 個人Webサイト系コミュニケーションに関する展望 (20:18)

• Trackbackへの抵抗感 - http://www.otsune.com/diary/2003/03/09.html#200303092

に対するレスポンスを書こうと思ったのですが、このあたりに関しては、具体的な話よりも私の持つそのあたりの思想を語った方が早そうな気がしたんで、個人Webサイト系コミュニケーション一般に関してまず書いてみます。

初期の日本の個人Webサイト（Web日記、テキストサイト、ニュースサイト）系コミュニケーションは、コミュニティの内輪で閉じた形のものが多く、それ以外とのコミュニケーション（コミュニティ以外からのリンク）に対しては抵抗感を持つ人が多かったという印象があります。

最近ではそういう閉鎖的な印象はずいぶん減ってきたように思いますが、それでもまだ内輪以外からのリンクを、何か特別なもののように扱う人は珍しくありません。Webサイト自体は開かれている（誰でも同じように見ることができる）のに、そこでのコミュニケーションがやけに閉じられているという現状に、私は不満があります。

どうして不満があるのかというと、「ソフト開発者、ハーバード大学に「ブロッグ活用法」を指南 from ZDNet」で書いたような「公開された場（Web）での複数の個人活動が集まった結果として、そこに個人ではできなかった何かが生まれる」可能性が面白いと思うから。というのが、パブリックな（建前的な）理由かな。「text/plainじゃなくてtext/htmlを使うならば、その仕様をきっちり使い切れよ（じゃなきゃrtfでも使ってろ）」という技術者（マニア？）的な嗜好の方が実は大きいのかも。まあ「俺はそれが好きだから」というジャイアニズムでも構いません。理由なんてどうでもいい。

で、そういう状況を変えるために、個人Webサイト同士がリンクしあう状況をもっと加速してしまいたい。そして、Webサイト内で閉じている状態、あるいは狭いコミュニティ内のリンクのみで閉じている状態を、Webサイト全体がリンクでつながっていくような状態に変えてしまいたい。

そういう状況に持っていくための方法として、まずサイト同士の言及リンクを図式化してわかりやすくする更新報告型リンク集（http://ishinao.net/diary/?200201c&to=200201281#200201281）みたいなものをイメージしました。ですがこの方向は宣伝広告にコストがかかりすぎるし、しょせん新しい内輪（コミュニティ）を作るレベルで終わってしまう可能性が高いのでやめました。コミュニティの垣根を越えたリンク集としてのtextmaniaがその核となるファーストステップだったのですが。

また、blogmapのように外部からコミュニケーションを加速させる仕組みを用意する方法も考えましたが、これはどうもCPUやネットワークリソースがかかりすぎます。データ量を多く・解析を細かくしないといいものはできないのだけれど、その端緒となるテストデータの段階ですでに私の使えるリソースの限界が見えてしまった。規模が小さく、解析が単純なレベルでは、単なるランキングリンク集にしかならない（現在のもの）。

その他、根本的に異なるアプローチとして、2chをはじめとする匿名掲示板系のコミュニケーションの可能性もいろいろ考えてみたんだけど、そちらに関しての話は省略。具体的な話としては、個人Webサイト系コミュニケーションと絡む部分がさほど大きくないし。マクロな話をすれば絡んでくるんだけど。

で、現在の手持ちのリソース内で、個人Webサイト系コミュニケーションを加速する手段として一番有望なのが、TrackBackなわけです。TrackBackというのは結局のところ、Webにおいてリンクする・リンクされることは当たり前であると周知し、しかもそのリンク状況を第3者にも公開する仕組みです。同じ意味をもつ仕組みであれば。技術的にはTrackBackでなくても構わないとも思うのですが、MovableTypeユーザーがそれなりに増えつつある現状においては、実践で試せるということもあってTrackBackを実装するのが一番手っ取り早い。

ちなみに、tDiaryのようにREFERERを第3者に公開する仕組みは、同様の仕組みをローコストで実装する手段としては悪くないと思います。ただ、REFERERはあまりにもノイズが大きすぎて、その情報を有効活用するのが面倒すぎるし、そこからは思想としてのリンクの自由があまり感じられない（単なる公開アクセス解析として捉える人が多いだろう）。ただし、TrackBackと比べると圧倒的にかかるコストが小さいので、REFERERを有効活用するというアプローチはありだとは思います（んで、WikiLikeのTrackBackページではREFERERも並べて表示している）。

さらに余談ですが、アンリンクフリー宣言（http://ishinao.net/ruins/text/unlinkfree.html）というのも基本的には、「リンクをする・されることに関する煩わしさをすべて取り去ろう」という意志を、ちょっと諧謔的に表現したつもりでした。が、その言葉があまりにも字義通りに受け取られ、「リンクを外すことが自由」という意味でだけ取る人があまりにも多すぎたり、あるいは「アンリンクフリー。だけど、リンクしたら報告ください」みたいな人がいたり、私の意図とはかけ離れて言葉だけが暴走している感があります。

さらに再び余談ですが、現在のところは言葉交差点というWebサイトをまたがった関心空間的アプローチ、あるいはWebサイト管理者がインデックス化されるキーワードを選択できる検索エンジン的アプローチも試しています。これとblogmapを組み合わせつつ匿名掲示板的なシステムも融合させると、個人Webサイトと匿名掲示板とがクロスオーバーしたコミュニケーションツールができないかなーと夢想したりしているんですが、まあまだこれはたたき台をテストしている段階。

というわけで、長文を読解することに疲れた人のために簡単にまとめると、「TrackBackは個人Webサイト（の記事）同士をリンクで結びつけるための技術であると同時に、そのような相互言及が当たり前のものであるという思想を周知するための仕掛けでもある」ので、現時点で私はTrackBackを推しているわけです。

ちなみに

>記事の本文中にa hrefでリンクタグが有ったら、そのリンク先にXMLなりなんなりでTrackbackが出来るかどうかを調べて「Trackbackしますか？」というチェックボックスで聞いてくる。

というのはすでにPingBack（http://www.hixie.ch/specs/pingback/pingback）という仕様ができていますね。ただこれはTrackBackよりもさらにコストがかかる（リンク先がPingBack対応か調べるコストがかかる）ので、実用上はいまいちかなーと思います。TrackBackですら、記事を投稿する際に自サーバーだけでなくTrackBack先のサーバーにもHTTP接続する必要があるため、ネットワークの状況によってはかなりレスポンスが悪くなる。実際、TrackBackを使っていて不便だと思うことは結構ありますし（相手サーバーが落ちていたり）。まあそのあたりは非同期処理＆リトライありにすればいいんだけど。

_ っぽいかもしれない飽きっぽい人のためのペン、ぱらぱらウインドウ、面白いものがいっぱい from ZDNet (20:18)

• っぽいかもしれない飽きっぽい人のためのペン、ぱらぱらウインドウ、面白いものがいっぱい - http://www.zdnet.co.jp/news/0303/07/cjad_kobayashi.html

>課題をこなすと灯が増えるってだけが本質

RPG的な自分が徐々に成長していく感じとか、あるいは他の人の状態が漠然と認識できることによる無意識的な競争とか、そのあたりを刺激することによって飽きさせないってのは確かに使えそうだな。レベルアップ掲示板（書き込みが多い人はレベルが上がってできることが増える）みたいなものも、女子中高生とかに昔人気があった（今も人気があるのかどうかは知らない）もんな。

>パソコンにつないだスライダーを動かすと、重なっているウィンドウが、手前のものから順番にぱらぱら消えていく

確かに実用性が高そうだな。でもわざわざ1次元量入力デバイスを別に使わなくても、仮想的なGUIパーツでなんとか表現できそうな気もする。快適度はハードウェアデバイスを用意するのに劣りそうだけど。

_ MSの企業向けIMはオフィスに入り込めるか？ from ZDNet (20:18)

• MSの企業向けIMはオフィスに入り込めるか？ - http://www.zdnet.co.jp/news/0303/07/ne00_msim.html

俺もずいぶん昔に、会社でIMを使おうって方向に持っていったことがあるんだけど、なんか面倒なんで自分から使わなくなってしまった。いちいち着席状況とかを変更するのが面倒だし、IMだとリアルタイム性の高い応答を期待する・期待されるけれども、実際にはそれほどレスポンスがいいとは限らない。だったら急ぎは内線電話か直接会いに行く方向で、そうじゃないならばメールベースのコミュニケーションで済む。

IMが有用な職場ってのもきっとあるんだろうけど、メールじゃダメだってのは具体的にどういう場合なんだろうな。ゴミメールが多いんだったら、アカウントを複数用意するかうまいフィルタリングを考えればいいだけだろうし。

_ RFIDの携帯組み込みはなるか？〜六本木ヒルズ from ZDNet (20:18)

• RFIDの携帯組み込みはなるか？〜六本木ヒルズ - http://www.zdnet.co.jp/mobile/0303/06/n_roppongi.html

ちょっと興味があるもののそばに携帯を近づけてボタンを押すと、それに関する情報がメールで降ってくるってのは確かに便利そうかもね。情報収集オタクならば、常時オン（自動的にボタンを押す）にしておいて、自分が通った軌跡にあるものすべての情報を収集したりとか。

_ SCOの対IBM訴訟、Linux全般への影響は？ from ZDNet (20:18)

• SCOの対IBM訴訟、Linux全般への影響は？ - http://www.zdnet.co.jp/news/0303/10/ne00_sco.html

>何らかの影響があるとすれば、それは主にFUD（不安、不確実性、疑念）だ。しかしその状況から恩恵を受けるのは、SCOではなくMicrosoftや、おそらくSunだろう

SCOの主張に利があるのかどうかは分からないけれど、確かにこの動きによって一番利益を得るのは競合OSメーカーだろうね。

_ 「この記事へのリンク元」を追加 (20:18)

今までTrackBackページにしか表示していなかった「この記事へのリンク元」を通常表示ページにも表示するようにしてみた。tDiaryみたいにカウント数にリンクを張る形式で。

_ いつの間にかJavaサポート？ (20:18)

いつもこっそりと機能が追加されるこのレンタルサーバー。さっきふと見たらコントロールパネルに「Servletを有効にする」なんて選択肢が追加されていた。試しにオンにしてみたらちゃんと設定されたっぽい。けれども、有効になったという情報以外はまったくなし。

いろいろセットアップしてやるけどノーフォロー・ノーサポートだから、自力で使える奴だけ使っていいよってことか。相変わらずおっとこ前なやり方だなー。今のところ、JDKは1.4.0_01だということしか分からない。ServletエンジンってきっとTomcatだよね。Servletが使えるとなるといろいろやれることが増えるなー。何やろうかなー。

と書いてからもうちょっと調べてみたけど、HelloWorldがうごかねーなー。っつーかよく見たらmod_jservが効いてない（コメントアウトされている）ような気が。Servletエンジンらしいプロセスも見あたらないし……。ぬぐぁっ！　ぬか喜びかっ！（スタパ風）

_ Web日記のコミュニティは閉鎖的 from 脳ざらし紀行 (20:18)

• Web日記のコミュニティは閉鎖的 - http://sheepman.parfait.ne.jp/20030310.html#p01
• ネットの話つづき - http://sheepman.parfait.ne.jp/20030310.html#p02
• Webコミュニティからの退場は可能か - http://sheepman.parfait.ne.jp/20030310.html#p04

個人Webサイト系コミュニケーションに関する展望の反応への反応。

コミュニティが存在するのも、その内輪でのやりとりが活発なのも全然問題ないのですが、その結果として、内輪以外からのアクセスに対して構えられてしまうという状況が、私はいやなのです。

>「個人Webサイト系コミュニケーションを加速する」ためには、2ちゃんねるの匿名性のような、人の出入り、流動性の高さ、参入と退場の容易さを保証するような仕組みが必要

sheepmanさんが、Webサイト系コミュニケーションを加速するためには、上記のような仕組みが必要だと思ってしまうのは、（内輪の）コミュニティを越えたコミュニケーションを何か特別なものだ（内輪のコミュニケーションとは違う）と考えているからでしょう。しかしその前提は、各人が自分の心の中に築いてしまった障壁に過ぎないと思うのです。

Webに公開している以上、内輪以外からアクセスがあるのは当たり前で、それは全然特別なことではないし、アクセスがあったからといって特別な対応をしなければならないというものでもない。「人の出入り、流動性の高さ、参入と退場の容易さ」などの障壁は、自分がそんなものはどうでもいいと思いさえすれば、とたんに消滅してしまう程度のもののように思います。

そして、そういう行動がWeb一般で当たり前になっていけば、各人の中に作られた壁は連鎖的に崩れていくのではないでしょうか。そのためには、そういう意識が当たり前であるという事実をWeb上で積み重ねていけばいい。そういう道具としてTrackBackという仕組みが使えるのではないか。

>TrackBackを使ってみた。心理的な障壁はポンポン山よりも高い。リファラの方が気楽で良い

というのもまだTrackBackが珍しい代物で、しかもシステム内蔵ではないTrackBackの使い勝手が面倒くさいからでしょう。もしもtDiaryにTrackBack送信機能が内蔵されていれば、普通に記事を更新する際にTrackBack先URLをフォームにコピペするだけで、自動的にTrackBackが送信されるようになります。a hrefタグを記述して、動作確認＆REFERER残しのために1回クリックするのと大して手間は変わりません。

>さて、Web上のコミュニティから退場するために、自分のサイトを閉鎖しなくてはいけないというのは、非常にコストが高い。

というのも、コミュニティというものが無意識に形成する障壁が、現状では非常に高いことを表している気がします。私は特にどこかのコミュニティに属していませんが、それでもあちこちに適当に顔を出して（アクセスして）います。私にとっては、どこかのコミュニティに入場するコストも退場するコストも非常に低いものです。

もちろんどこかのコミュニティと深く関わるのもいいでしょう。しかし、コミュニティへの入退場のコストをそこまで高く設定することはないのではないでしょうか。そういう壁も結局のところ個人の意識が作り出しているだけだと思います。

>何か議論して、とんちんかんなことを言って、ネットウォッチされて、2ちゃんねるでスレが立って、サイトが閉鎖されるのを防ぐような仕組みが必要

2chのウォッチ系スレというものが、個人Webサイト管理者に与えている影響力というものは、かなり大きいものなのでしょう。しかし、個人Webサイトを使っての相互言及行為の事例が少ないからこそ、2chのような匿名での言及行為の価値（重み）が上がってしまうのだとも考えられます。個人Webサイト同士でもっと自由に言及しあうようになれば、その影響力は低くなりそうな気がします。

_ 今日はひどいな (10:23)

いや、昨日からか。久しぶりに我慢できなくなって、ときどき目の周りを抑えたりしている。去年はほとんど目に来ることはなかったのになー。薬を飲んで顔を洗ってしばらく経ったら、ようやく治まってきたけど、なんかもう花粉飛びまくりって感じだな。でも、まだこの間ひいた風邪の続きもありそうだから、鼻水とくしゃみのどの程度が花粉のせいなのかよくわからん。

_ 表示の変更とAjaxでの保存 (19:53)

サムネイルを表示したら画面がうるさくなりすぎたんで、要素ごとに表示・非表示を切り替えることができるようにしてみました by JavaScript＋CSS。んでもって、実験君的にAjaxが有効な環境では、非同期で変更した設定を保存しています。

が、なんかFireFoxでしか動いてないなー。いろいろ初めて試したことばかりなんで、なにが原因なのかよくわからない。そのうち互換性を高めていきます。「表示・非表示切り替え機能が動かない」以上の不具合があったら外しますんで、教えてください。

あらFireFoxでもちゃんと動いてないや

デフォルトで外しておこう。

多分

IEとFireFoxでは動いている気がする。

_ HTML_AjaxHandlerのプロトタイプ

昨日言っていたHTML_AjaxHandlerのプロトタイプ版を作ってみた。

• 動作デモ
• HTML_AjaxHandlerのソース
• デモのソース

デモのソースは複数のデモをまとめて書いてあって読みにくいんで、2行目に表示されている平方根の計算に関連する部分だけ抜き出して、解説してみる。

デモの内容としては、テキストボックスに数字を入れると、その右側にリアルタイムで平方根の計算結果が表示される、というもの。平方根の計算はサーバーサイドで行い、XmlHttpRequestでデータをやりとりしている。Ajaxのデモなんで、平方根なんてJavaScriptで計算すればいいじゃん、ってツッコミはなしね。

HTMLとして必要な要素は、以下。

<script src="prototype.js" type="text/javascript"></script>
平方根: <input type="text" name="rootnum" id="rootnum" value="" /> = <span id="rootnum_result"></span>

ここでは特にイベントハンドラー等は定義していないし、prototype.jsを読み込んでいる以外は、JavaScriptコードは書いていない。

続いて、PHPコード部分は、以下。

require_once 'HTML/AjaxHandler.php';
$ajax =& new HTML_AjaxHandler();
$ajax->addHandler(
	'rootnum',
	'keyup',
	array(
		'url' => 'api.php',
		'method' => 'get',
		'parameters' => 'command=root',
		'container' => 'rootnum_result',
	)
);
echo $ajax->toJavaScript();

これでイベントハンドラーの定義を行っている。

HTML_AjaxHandler::addHandlerの引数は、

• $elementId - 対象となる要素のID
• $eventName - ハンドリングするイベント（prototype.jsの仕様に合わせる）
• $ajaxOptions - その他オプションいろいろ

となっている。$ajaxOptionsに関しては、基本的にprototype.jsのAjax.Request、Ajax.Updater、Ajax.PeriodicalUpdaterのオプション（およびパラメータ）を受け付ける。それ以外にも、HTML_AjaxHandler独自のオプションをいくつか受け付ける。

上記の例だと、以下のような感じ。

• url - XmlHttpRequestするURL。
• method - リクエストメソッド。
• parameters - 初期パラメータ。対象の要素がフォームやフォーム要素の場合は、その内容も自動的に追加される。
• container - Ajax.Updaterで更新される要素のID。containerが指定されている場合、Ajax.Requestではなく、Ajax.Updaterが呼ばれることになる。containerに加えてfrequencyが指定されている場合は、Ajax.PeriodicalUpdaterが呼ばれることになる。

で、最後のecho $ajax->toJavaScript()で、実際のイベントハンドラー等のJavaScriptコードを自動生成して出力している。どういうJavaScriptコードかというと、以下のような感じ。

<script type="text/javascript">
<!--
function AjaxHandler_autoParameters(e, params)
{
	if (params == undefined) {params = '';}
	if ($(e).value != undefined) {
		params += (params != '' ? '&' : '') + Form.Element.serialize($(e));
	} else if ($(e).tagName.toLowerCase() == 'form') {
		params += (params != '' ? '&' : '') + Form.serialize($(e));
	}
	return params;
}

function AjaxHandler_autocreated_rootnum_keyup(event)
{
  var url = 'api.php';
  var options = {
    method: 'get',
    parameters: 'command=root',
    asynchronous: true,
    container: 'rootnum_result',
  };

  options['parameters'] = AjaxHandler_autoParameters('rootnum', options['parameters']);
  var ajaxRequest = new Ajax.Updater(
    'rootnum_result',
    url,
    options
  );
  Event.stop(event);
}

function AjaxHandler_autocreated_441130d9062b1_onInit()
{
  Event.observe('rootnum', 'keyup', AjaxHandler_autocreated_rootnum_keyup, false);
}

Event.observe(window, 'load', AjaxHandler_autocreated_441130d9062b1_onInit, false);

-->
</script>

その他のデモは、

• load時にAjax.PeriodicalUpdaterに登録して、現在時刻をAjaxで取得＆表示する。loadの処理が微妙（DOM要素単位でもloadイベントがあると勘違いして作っていて、あとでそんなイベントはないことに気づいて、あわててごまかした産物）。
• 二つのテキストボックスに入力された数値を、フォームのsubmitをフックして、足し算した結果を表示する（フォーム投稿処理をAjaxで代替するイメージ）
• 二つのテキストボックスに入力された数値を、入力欄の更新をフックして、足し算した結果を表示する（パラメータの付け替えとか、複数のイベントハンドラで同じコールバックを使ってみたりとか）

なんて感じ。

まだ全然細かいところまで練れていないけれども、ひとまずこんな感じのアプローチで、Ajax対応が楽になるかどうかいろいろ使って試してみよう。一応HTML_AjaxHandlerのライセンスはLGPLにしてあるけど、まだプロトタイプレベルなんで、コードは全面的に変更される可能性がある。

ちなみに

なんで初期化（イベントハンドラの登録）をwindow.onload経由でやっているかというと、JavaScriptコードをHTMLヘッダ部に出力した場合、イベントハンドリングする対象のDOM要素がまだ生成（HTMLとして出力）されていない可能性があるから。

あと、XmlHttpRequestリクエストを実行する前に呼ばれる独自のコールバックオプションとして、parametersCallback、urlCallback、optionsCallbackが使える。それぞれ、Ajax.*を呼び出す直前に、JavaScriptコードでparameters、url、optionsを書き換えたいときに使う。

本当はもう一個、XmlHttpRequestを行うかどうかを選択するためのコールバックも必要かと思っていたんだけど、基本的な処理の流れ自体を分岐するオプションに関しては、それ以外にもいろいろなパターンがありそうだから、もっといろいろ具体的なパターンを考えてから実装した方が良さそうに思えたんで、今のところつけていない。