Nov 29, 2005

また狩られたーよ

先月末のこと。

From: Google AdSense <adsense-jp@google.com>
To: XXXXX@gmail.com
Cc: Google AdSense <adsense-jp@google.com>
Date: Oct 31, 2005 11:49 AM
Subject: Google AdSense へようこそ

Google からうれしいお知らせです。

お客様の Google AdSenseへのお申し込みが承認されました。アカウントを開始
すると、すぐにお客様のサイトでGoogle広告と検索向けAdSenseの配信が開始さ
れます。

以下略

そして今月末のこと。

From: Google AdSense <adsense-adclicks-jp@google.com>
To: XXXXX@gmail.com
Cc: Google AdSense <adsense-adclicks-jp@google.com>
Date: Nov 29, 2005 12:28 PM
Subject: *Google AdSense アカウントの非承認

Hirotaka Ogawa  様

お客様のウェブ ページに掲載された Google 広告に無効なクリックが発生いた
しましたので、お客様の Google AdSense は無効となりました。これは広告主の
利益を保護するための手段ですのでご理解ください。

以下略

早っ!! というよりも一度も報酬を受け取らせない作戦!? 新しい…新しすぎるよ、Googleタソ…

昨日なんだか妙にアクセス数が多かったのは確かです。でもどちらかと言えば、ある期間においてクリックしたクライアント(IPアドレス、UAなどのtupleで表現される)に著しい偏りが観測された時にRogue Accountとみなされるというのが妥当な実装で、そうなっていると思うのですけどね。

だったらそういうクリックを「グーグルが、グーグルの責任で」除外することもできるはずで、もちろんその方がより妥当な実装ですよね。そのような後からバッチ的に報酬から差っ引く方法は、(実装が面倒という話は別にすると)大口サイトの理解を得にくいのかもしれませんが、裏ではわっちらのような泡沫サイトが泣いているわけです。言ってみればジャニーズやavexには頭を下げるけどそっくりさんや地下系アイドルには厳しいテレビ局みたいなもんです。

また、折を見てみたび申し込みますのでそのときはよろしく>Googleタソ

2005-12-06:
その日のうちに再度申請しておいたのですが、やはり断られました。ある程度間をおくか、別のURLで申請する必要がありそう。

From: Google AdSense <adsense-adclicks-jp@google.com>
To: XXXX@gmail.com
Cc: Google AdSense <adsense-adclicks-jp@google.com>
Date: Dec 6, 2005 3:13 PM
Subject: Google AdSense アカウントのステータス

Hirotaka Ogawa 様

Google AdSense に関心をお持ちいただきありがとうございます。お申し込みを
審査させていただいた結果、Google のスペシャリストにより AdSense プログラ
ムの基準を満たしていないことが確認されました。このため、残念ながら現時点
ではお客様にGoogle のプログラムをご利用いただくことはできません。

Google では、広告主様だけでなくサイト運営者様にも Google の広告を効果的
にご利用いただけるように、いくつかのポリシーを設けております。Google で
はすべてのサイト運営者様を審査し、ポリシーに従っていない場合はお申し込み
を不許可とさせていただいております。今後、より多くのウェブ サイト運営者
様に、より幅広いウェブ コンテンツにおいて、Google のプログラムをご利用い
ただけるよう努力してまいります。

この結果に関する具体的な理由についてはお答えできないことがありますのでご
了承ください。お客様のご理解に感謝いたします。

よろしくお願いいたします。

Nov 28, 2005

経県値&経県マップ

経県値&経県マップ
はてなブックマーク - 経県値&経県マップ

現在のところ私の得点は176点です。挑戦者求ム!!

こういう会議ああいう会議に毎年出席していると高得点になります。あとバイク乗りは押しなべて高得点になることでしょう。ここから上げていくのは結構難しいですが、とりあえず宮崎と鹿児島の会議には積極的に参加していく方向です。

Nov 26, 2005

Gmail Capacity vs. Usage

11月24日でGoogle Mailを仕事用のメールツールとして使い始めてちょうど三か月になりました。下記エントリーは9月8日に書いていますが、8月24日から使い始めました。

Ogawa::Buzz: Gmailを本格的に使ってみる

今のところ使用量は約300MB(仕事以外のメールはこのメールアカウントには含んでいません)でまだまだ余裕いっぱいですが、メールボックスの「容量」と「使用量」の関係はこの先どうなるのかな、本当に一生使えるのかな、使い切るとしたらいつ頃だろう、と思ってちと調べてみました。

そのためには「容量」と「使用量」の予測値が求められる必要があります。とりあえず、「使用量」に関してはこのままのペースで線形に増加するものとし、次に「容量」を見積もることを考えてみます。

ログイン画面(Welcome to Gmail)には「Over 2668.XXXXXXX megabytes (and counting) of free storage」というメールボックスの「容量」が表示されていますが、これは1秒ごとに実際の「容量」を表示しているわけではありません。単に今年10月1日は2650MB、来年1月1日は2680MBとして線形補間して現在時刻に対する値を求めているだけです。ちなみに9月1日は2550MBだったようですから10月以降はそれ以前に比べて増加速度が約1/10になっていることになります(細かい計算は自分でしてね)。

ここでは、来年1月1日以降も今年10月以降と同じペースで増加するものと仮定します。

さて両方の予測値を元にCapacity vs. Usageをプロットしてみたのが以下です。

何となく2007年5月には使い切ってしまう感じですね。実際計算してみると私の場合、2007年4月27日にはUsage(2837.70MB)がCapacity(2835.87MB)を上回ってしまうようです。意外に早いです。

そんなわけでGoogleタソには是非ともGmailの増強スケジュールを見直してもらわないといけません(笑)。

Nov 22, 2005

Web 2.0 とかGeek 2.0とかについて

404 Blog Not Found:Geek 2.0

ArtistとArtisanに分けるという考え方も、議論のためにわざわざ単純化された二項対立を導入したのも理解できますし、Web 1.0に比べて2.0における相対的な(再)発明の質・量が小さいものに留まり、従って地味なものになるかもしれないことは大いに首肯するところです。

そうなのですが、釈然としないなと思える部分もあります。それは、そもそもソフトウェアにしろ自動車にしろ無数の階層から構成されるプロダクトであり、そのどの段階にもArtistもArtisanも要求されるのではないかと私には思えるからです。カンバン方式を発明するものはArtist、それを運用するものはArtisan、Web2.0のナイスな利用方法を発明するものはArtist、それをパターンとして利用するものはArtisanというようにです。これは小飼さんと同じことを別の言い方で言っているに過ぎないかもしれませんが。

そう考えると専門化とは要するにその階層の多層化ないし精緻化を意味し、ArtistとArtisanの仕事が乖離するのは、精緻化に伴って要求される知識の領域がより狭くしかしより深くなった結果として、副次的に生じることではないか、と。卑近な言い方をすれば、Artistは周辺の知識を俯瞰(できる|する必要がある)けれども、Artisanは(できない|する必要がない)というように。

さらに言えば、その後Artistが「すでに芸の場ではない」と判断する階層からは去ってしまうという現象が観測されるということでしょう。アカデミアにしろ、医療機器業界にしろ。

その理由には、本質的にはArtistの質・量が不足しているという事実(あるいはそれは神話かもしれませんが)があり、それらのリソースの効率的な配置が、Artistのごく情緒的な判断に委ねられたり、非情緒的な(端的には経済的な)事由に帰されたり、あるいはそうした効率性・機能性を一顧だにしない集団への土着性があったりするでしょう。つまりはArtistの質も量も、それゆえに効率的な配置もそれらへの十分な投資も運用も、何もかもない・なされない状態にあるのではないか、というのが私の印象です。念のため「Artistの質・量が不足している」という前提が成立しない場合、そもそもこの話は意味がありませんけれどね。

さて、それとはまったく関係なく、数多ある「Web 2.0が何なのか」という説明の中でも「geek向けのマーケティングである」という説明に対して妙に「ポジティブに」納得されている人を見かけるのは、私には俄かに承服しかねるというか、一種の驚きでもあります。

それってぶっちゃけgeekと彼・彼女の判断能力をあまりにも侮ってなくね?

どこかの本屋のインテリおやじの書いたものとか、masahikosatoh.com: WEB2.0は確実にやってくる波とか見ていると、Web 2.0のマーケティングというのはごく社会学的なアプローチを採っているようにしか見えないのですけれど。結論が先にあったり、定量的なデータを示さなかったり。例えば後者の図なんて掛け値なしに信用できる部分というのは、インフラ部分だけでしょう。なぜ納得できるのでしょうか、私には理解できません。納得してしまえる人だけが感応すればよいという仕掛けなんでしょうか。そのあたりがマーケティングだという証左なんでしょうか。結局のところトレンドに付いて行きたいあるいは付いて行かざるを得ないと思うgeekのメンタリティを利用した詐術なんじゃないですか、と言いたくもなりますよ、それは。いやまったくその通りなのかもしれませんが...。

むしろ宮川さんや伊藤さんがご自身のブログでごくごく現実的なメソドロジーやパターンを模索していることの方が遥かに有意義です。そのこと自体は車輪の再発明かもしれませんが、計算機科学に関わる諸技法はあらかた予め発明済みの事柄ばかりですし、発明済みだから無用ということはもちろんありませんから。

Nov 19, 2005

Shooting Oysters

牡蠣が食えない奥の人と衣食を共にしていることもあり、日本ではほとんど食べられないのだが、私は鮎、海老、蟹、ハッサクに加えて、生牡蠣も大好きだ。

せっかくSeattleに来ていることもあり、日頃の鬱憤を晴らすべく、なるべく生牡蠣を食事にincludeすることを心がけている。とはいえ、コンファレンスに参加してる以上、自由になる食事の回数は限られる。到着した日に食べるのは無理だし、朝食、会期中の昼食に導入するのは時間の制約上難しい。さらに夕食はほぼすべての日にレセプションがあり、立食か着席で食事をする必要がある。

そんな中でも3回ほど食べてみた。

11/13昼
Emmet Watson's Oyster House

Emett Watson'sはPike Placeに昔からある店。安いけど一種類の牡蠣しかない。Chowderも芋率が高いのでここはそろそろ行かないようにしよう。

11/17夜
McCormick & Schmick's Harborside Restaurant

どこにでもあるMcCormickにAIST Dinnerで行った。Oysterの1/2 Dozen Samplerが意外に安かった(9USDくらい)ので迷わず注文。おいしかったけど給仕の人が産地を教えてくれない。聞いてもゾンザイにしか教えてくれない。それがMcCormickクオリティ。

11/18昼
Elliott's Oyster House

Pier 56のところにあるOyster Barで高い方の1/2 Dozen Samplerを注文(16USD弱)。午後3時からHappy Oyster Hourというのをやっていて、一個あたり50cent(30分ごとに一個あたり20centずつ高くなる)で食べられるらしい。知らなかったのでとても損をした気分だったのだが、Sampler自体はとてもおいしかった。最初からここに来ておけばよかった、なるべく3時以降に。給仕の人がたいそう親切で、一人でふらっと入ったのにワインも教えてくれたし、フラッペ状のソースに何が入っているのか事細かに教えてくれた。

それとはぜんぜん一ピコたりとも関係ないが、Wayportには腹が立つ。1 day useだと一回のサインアップでは特定の無線LANステーションにしかコネクトできない。なので、複数のステーションが見えるところ(例: 私のホテルの部屋)ではどれかひとつにたまたまコネクトしている時しか通信できない。死ねばいいのに。

Nov 18, 2005

SOAPの高速化技法メモ

Differential Deserialization for Optimized SOAP Performance
Nayef Abu-Ghazaleh, Michael J. Lewis

SC|05のTechnical Paper。

個人的にSOAPを高速化することに(も)長らく興味を持っている。高速化の手法は概ね3種類に分けられる。

ひとつは専用ハードウェアを設けるというもの。結果は推して知るべしという感じだが、業務でものすごいリクエストをこなす必要がある場合には対費用効果に優れるのかもしれない。分からない。というか、インターナルサービスもどんどんWeb Services化してしまえという風潮を考えると費用的にはスケールしないだろう。

もうひとつはテキストベースのプロトコルを止めてしまって等価なバイナリープロトコルを規定すること。2年くらい前に私自身"Lightweight Web Services"という名前で実装したが、Sun Microsystemsでjwsdp: Fast Web Services and Fast Infosetがほぼ同じバイナリ表現で実現してしまったので今のところお蔵入りウェアとなっている。他にbnuxという独自のバイナリ形式を使う実装(Nux - Overview)も有名。Sunの実装はASN.1という一種の標準規格を用いているので(ASN.1機器が実現するinteroperabilityもメリットとなり得る)、bnuxの著者はbnux形式が定性的・定量的に十分優れていることを示す必要がある。これらの実装は既存のSOAPと比較すると圧倒的に高速であり、プロトコルの互換性はないがもちろんAPIレベルで互換性を維持することは不可能ではない。他にもXSBC (Extensible Schema Binary Compression)とかXBISなども参考になる。

念のため、これらはバイナリデータの交換を目的としたXOP (XML-binary Optimized Packaging)とは目的が異なることを付け加えておく。プロトコルの上位層ではテキストベースプロトコルとの互換性を維持することが重要なのである。

最後のひとつはDifferential Serialization/Deserializationと呼ばれている方法。ここで言うSerialization/Deserializationとは、インコアオブジェクトとXMLストリームを相互に変換することで、もちろんDeserializationの方が重要。プロトコルの互換性を維持するが、同じ種類のメッセージに対しては二回目以降、差分のみのパーズなどの処理を行うことで軽量化を実現する。差分情報の検出方法が問題。国内ではIBM TokyoやNTTデータでやっている。

Optimizing Web Services Performance by Differential Deserialization

A Differential-analysis Approach for Improving SOAP Processing Performance

どちらも受信側でメッセージのスキーマや以前のメッセージインスタンスをパーズした結果をDFAの形で記憶しておき、終端状態に到達できるメッセージは以前作ったオブジェクトを再利用して生成するという方法で似通っていたと思う。既知のメッセージもしくはスキーマから正常な、可能な限り多くのメッセージを検出できるDFAが構成できるかどうかが問題で、例えばクライアントによって改行や空白文字の入り方が違ったりすると、うまく処理できないことになる。うまく処理できなかったら(スペックが微妙に異なる)クライアントごとに別のDFAを構成し、次からは場当たりに適用してもよいのだが、そうすると検査に時間がかかるようになったり、スペース効率が悪くなったりすることになる。

冒頭のbSOAPもDifferential Deserializationを実現するのだが、定期的にParserとDeserializerの状態をチェックポインティングし、同時に処理中のメッセージのchecksumも計算しておく。次にincoming messageが同じchecksumを持っていたら、チェックポイントからリスタートすることで処理を大幅に軽減する。この方法では高速なリスタートが期待できる反面、上記の2件に比べると冗長な情報も記憶することになる。これはgSOAP/bSOAPのフレームワークがC++で実装されていることとも無関係ではないだろう。また、チェックポインティング戦略によってメッセージのゆらぎの問題を軽減できる(可能性がある)というメリットもある。

論文的にはgSOAPとの比較しか行っていないためかなりアレな感じだが、景気の良い性能評価値をついつい載せてしまうマッチポンプセンスは好感が持てる。

Nov 16, 2005

Google Analytics

Google Analytics

ちょっと前にGoogleに買収されたUrchin Softwareのアクセスログ解析ツールが看板をGoogleに変えてリリース、ということ。インタフェースがGoogleにしては凝っているのも、最初から多言語対応なのも、Urchin Softwareのもともとの設計がそうなっていたせいではないかと思う。

それにしてもKeyholeにしてもGoogleが買って無償で提供するという方式は、マイクロソフトがWindowsにWebブラウザだけでなく、買ってきたデフラグツールなどをバンドルしたのと同じ方式。

有償のマイクロソフトはまだしも、広告だけで無償で突き進むGoogle。ユーザーとしては無償なら何でもよいのかもしれないが、結果として競合相手の死体の山を見るという現実もある。忍者TOOLSとか広告収入で細々やってそうなところなどは大丈夫なのだろうか。

マイクロソフトのように独禁法訴訟を起こされたり、買ってきたソフトがたまたま他社の特許を侵害していたりなんていう問題がそのうち起こるのだろう。生暖かく見守っていきたい。

とりあえずこのブログにも仕掛けてみたのだがデータがちゃんと採れていない模様。

Nov 14, 2005

Ajaxで簡単リソースモニター

クラスタなどのリソースモニターをAjaxを使って実現すると、Ganglia Monitoring Systemみたいな味気なさ(最近はチェックしていないのでカッコヨクなっていたらスマソ)が解決したり、Centralized Serverで行う実質的なレンダリング(一般的にはHTML生成)のオーバーヘッドが抑制できたりするのではないかとふと思いついてしまいました。まあJava Appletを使えば済むと言えばまったくその通りなのですけれど。

ともかくやってみました。nantoさんのブラウザ上でお絵かき: Days on the Moonを利用します。描画ルーチンの利用方法に関してはこちらを参考にさせていただいています。

まず、簡単なAjax Client Libraryを用意します。AjaxClient.jsという名前にしておきます。いろいろブラウザごとの非互換性があるので、注意深くググればもっとよくできたライブラリが見つかるでしょう。

2005-12-13修正: Ajax Client Libraryをざっくり修正。ときどきいじっているので下から最新版をゲットしてください。

AjaxClient.js

// Ajax Client Library

AjaxClient = function() {}

AjaxClient.initClient = function() {
  if (window.XMLHttpRequest)
    return new XMLHttpRequest();
  var types = [
         "Microsoft.XMLHTTP",
         "MSXML2.XMLHTTP.5.0",
         "MSXML2.XMLHTTP.4.0",
         "MSXML2.XMLHTTP.3.0",
         "MSXML2.XMLHTTP"
  ];
  for (var i in types) {
    try {
      return new ActiveXObject(types[i]);
    } catch(e) {}
  }
  return null;
}

AjaxClient.call = function(param) {
  var uri = param['uri'];
  if (!uri) return;
  var c = AjaxClient.initClient();
  if (!c) return;
  var method = param['method'].toUpperCase() || 'GET';
  // add random bits to avoid caching in some UA
  uri += (uri.match(/\?/) ? '&' : '?') + '.r=' + Math.random(1);
  var content = null;
  if (param['args']) {
    var args = new Array();
    for (var a in param['args'])
      args.push(a + '=' + encodeURIComponent(param['args'][a]));
    content = args.join('&');
  }
  if (content && method == 'GET') {
    uri += '&' + content;
    content = null;
  }
  c.open(method, uri, true);
  c.onreadystatechange = function() {
    switch (c.readyState) {
    case 1:
      if (param['loading']) param['loading'](c);
      break;
    case 2:
      if (param['loaded']) param['loaded'](c);
      break;
    case 3:
      if (param['interactive']) param['interactive'](c);
      break;
    case 4:
      if (c.status && (c.status != 200)) {
        if (param['error'])
          param['error'](c, c.responseText);
        else
          alert('Error: [' + c.status + '] ' + c.responseText);
      } else if (param['load'])
        param['load'](c, c.responseText);
      break;
    }
  };
  if (content)
    c.setRequestHeader('Content-Type', 'application/x-www-form-urlencoded');
  c.send(content);
}

次にモニタリング用のインタフェースを用意します。ここでは簡単のためにマシンのuptimeを監視するものとし、例えば以下のような内容のCGIを用意します(uptime.cgi)。

#!/bin/sh
echo Content-type: text/plain
echo
uptime

最後にモニターをレンダリングするHTMLです。サーバーのuptime.cgiを5秒おきにポーリングしてload averageをプロットしてくれます。

<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title>Uptime monitor</title>
<script type="text/javascript" src="AjaxClient.js"></script>
<script type="text/javascript" src="DrawingCanvas.js"></script>
</head>
<body>
<div id="canvas" style="position:absolute;top:10px;left:10px"></div>
<script type="text/javascript">
var canvas = new DrawingCanvas(document.getElementById('canvas'), 600, 200);
canvas.parent.setAttribute('style', 'position:absolute;top:10px;left:10px');
canvas.setBgColor("#eee");
canvas.setLineColor("#800");
canvas.setLineWidth(1);
for (var y = 0; y <= 200; y += 50) {
  canvas.startLine(0, y);
  canvas.lineTo(620, y);
  canvas.endLine();
}
canvas.setLineColor("#888");
for (var x = 0; x <= 640; x += 20) {
  canvas.startLine(x, 0);
  canvas.lineTo(x, 200);
  canvas.endLine();
}

var loadList = new Array();

function drawCanvas(c, result) {
  if (!result) return;
  if (loadList.length) canvas.undo();
  if (loadList.length > 60) loadList.shift();
  result.match(/load average: ([\d.]+),/);
  loadList[loadList.length] = RegExp.$1;

  canvas.setLineColor("#f00");
  canvas.setLineWidth(2);
  var x = 0;
  canvas.startLine(x, 200 - loadList[0] * 100);
  for (var i = 1; i < loadList.length; i++) {
    x += 10;
    canvas.lineTo(x, 200 - loadList[i] * 100);
  }
  canvas.endLine();
}

function doClientCall() {
  AjaxClient.call({
    'load': drawCanvas,
    'uri': 'uptime.cgi'
  });
}

var timer;
function toggleTimer(o) {
  if (o.value == 'Start') {
    o.value = 'Stop';
    // set Interval Time by msec
    timer = setInterval('doClientCall()', 5000);
  } else {
    o.value = 'Start';
    if (timer) clearInterval(timer);
  }
}
</script>
<div style="position:absolute;top:220px;left:10px"><input type="button" value="Start" onclick="toggleTimer(this)" /></div>
</body>
</html>

プロットする値の系列が複数になってもdrawCanvasをちょっと変更するだけで済みますね。

それにしてもDrawingCanvas様様です。Firefox 1.0xではdivエレメントを山ほど生成してプロットされるので非常に遅いのですが、1.5RC2を使うと早速導入されたSVGエンジンで、Internet ExplorerではVMLでそれぞれレンダリングしてくれます。

というわけで(何が?)、SC|05でSeattleに来ています。OOPSLA 2002のときと同じWashington State Convention Center。誰か蟹のうまい中華レストランを教えてください。

Nov 8, 2005

自宅無線LANをIEEE 802.11aに移行

自宅で使っている無線LANアクセスポイントは、IEEE 802.11a/bg切り替え式のBuffalo WER-AMG54なのですが、この11aの方は5.2Ghz~5.3Ghz帯を利用する世界標準規格(W52/W53)にしか対応していません。一方で、自宅で主に使用するPCは、Panasonic CF-T4GW (Ogawa::Buzz: Panasonic CF-T4GWKAXP)とSony PCG-TR5PS (Ogawa::Buzz: VAIO type TR5S)の2台で、a/b/gデュアルバンド3方式に対応してはいるものの旧規格11a(J52)しか対応していません。そういうわけで、「屋内でしか使えないが性能上のメリットはある」11aの特権を行使することはあきらめて通常通り11gで自宅内LANを構築していました。

先月あたりからPC製造各社からアップデートプログラムのアナウンスが相次いでいて、うちはまだかな~と心待ちにしていたのですが、ようやく両PCの11aのアップデートプログラムが出揃ったので早速アップデートしてみました。

アップグレードプログラムによってどちらのPCもJ52対応からW52対応に排他的に切り替わります。面白いのは、Let's Noteの方はアップグレードすると11bの14chが使えなくなるようです。11gではもともと使用できないチャンネルだし、ほとんどデメリットはなかろうと判断して、えいやっとアップデート。

結果的には相当通信速度が向上したような気がしています(ちゃんと測定していません)。ひとまず他所のアクセスポイントなどとの干渉はほとんどなくなっているでしょう。あ~あと、飛行機内で11a(W52)を使えるご身分になりたいですね。

Nov 7, 2005

Personalized Homeってそんなに良いものなのか?

メタデータの共有という方法に関しては異論を挟むつもりはさらさらないが、いったいWindows LiveGoogle Personalized HomeのようなPersonalized Homeってそんなに具合の良いものなのだろうか。どうにもそうは思えないのでグダグダ書いてみる。

まず、Personalized Homeの有用性に疑問を呈したい。ここでPersonalized Homeと言っているのはユーザーがカスタマイズ可能なポータル、という程度の意味である。

私はブラウザの「ホームページ」をGmailにしているのだが、それはメールというツールを一番頻繁に利用するためという自明の理由に帰する。だからと言って自明な優先度を発見していない、あるいは優先度はさておきとりあえずの操作を欲するより多くユーザーがいることが理解できないわけではない。

そうした多くのユーザーは、ポータルサイトをホームページに指定しているのだろう。そうなのかもしれないのだが、あのコンテンツと広告のミクスチャというか混乱の中から必要な情報を得るには、あるいは次に必要な操作を行うには相当な注意力と習熟が必要ではないか。そう、ちょうどMicrosoft WordやPhotoshopの伝統的なボタンインタフェースから必要な操作を選び出すのが困難なようにだ。なぜニュースの情報を得るのにわざわざ10cm正方領域を注視せねばならないのか、さまざまなファンクションを実現するであろうリンクリストの中から路線検索を「発見」せねばならないのか。こんなインタフェースで実社会の、例えば駅の券売機が実現されていたとしたら、ストレス以外の何物でもない。

Personalized Homeは少なくともこうした問題を部分的には解決する。必要とあらばボタンの数を減らすことができる。しかし、実際にはどのような情報を表示すべきかに対する具体的な指針は示されないため、混乱を避けられるかどうかはユーザーの力量に委ねられる。また、(My Yahoo!などを見れば明らかなように)削除できないコンテンツや広告が表示されることに対してユーザーは抗する手段を持たない。Windows LiveやGoogle Personalized Homeになったからと言って前者の問題は依然残る。また、現状後者の問題はないが、それは単にベータ版だからかもしれないし、両社がたまたまユーザーを強制的に誘導したいというインセンティブを持つコンテンツやサービス(例えば、オンラインバンキングや証券取引)を持たないためだという見方もできる。MSNはショッピングサービスを持っているけどね。Googleの場合は今のところ広告表示を含む検索ページに誘導することが最大の目的だからPersonalized Homeに広告表示する必要はないのかもしれない(Gmailでも表示していない)。

要するにPersonalizedだろうとFully Customizableだろうと、情報を一覧する形態のレイアウトと広告の存在は、決してユーザーにとって快適でない体験しか与えない、というのは言い過ぎとしてもそういう体験をより多く与える可能性があるということだ。

もうひとつは「新しいユーザーエクスペリエンス」としてのpoorさを指摘したい。

ほとんどEmacs以来の感動を与えてくれたGmail、まったく何かの冗談かと思ったGoogle Readerとは異なり、Google Personalized Homeのインタフェースは保守的極まりなく、何の発明もない。マウスによるDrag & Dropでレイアウトを変更できるインタフェースは以前からあるものでAjax以降の産物ではない。だらだら表示されるメニューは出来損ないのFlashコンテンツを今更見せられているようだ。コンテンツをbrand newに保つために非同期にロードされるとかいったギミックもない。この点では、Windows Liveの方が圧倒的に面白い。start.comでの少なからぬエンジニアリングの蓄積があってこそ成し得るものだろう。

しかし、いずれにしろpoorであることに変わりはない。なにせRSSフィードをコーディネイトして表示するだけなのである。これでは従来のカスタマイズ可能なポータルサイトと何ら変わりがない。そう言ってよければ、RSSリーダーやGmailを使えば、もっとユーザーの直感に適合した形でよりリッチな情報を扱えるはずだ。

Windows Liveがメッセンジャーやメールのようなサービスとの統合を行っていることは、従来とは異なるユーザー体験を与えるという点で面白いのだが、例えばGoogleのページにFlickrのアップロード・ブラウズインタフェースが統合されることは、まず望み薄であることには気が付きそうなもの。つまりはポータルにサービスが統合されると言っても、それはRSSのようなメタコンテンツレベルでは進行しても、より高度なサービスへの適用までは波及しないか制限された範囲でしか適用されない。

どう転んでも「要するにポータルね」という感想以上のユーザーエクスペリエンスは得られそうにない。だからpoorだという他ない。

では、Yahoo! 360°はどうなのよということになるが、これはコミュニティツールにメタコンテンツや他のYahoo!のサービスを統合したものである。確かに異なるユーザーエクスペリエンスを与えるし、ポータルとしても機能するが、PCの「当初の目的」とは異なってしまう。辞書を引きたいだけなのにコミュニティからのメッセージを読まなくてはならないとかいった本末転倒も甘受しなくてはならない。それはストレスだ。

グダグダ書いてしまったが、新しいものを期待するがゆえ。

Nov 3, 2005

GEO@チャンネルの勧誘

先週秋葉原エンタまつりというイベントがあった。職場のある某ビルの地上階にも何やらテントが出ていたのだが、そこで鼓笛隊のようなユニフォームを着たおねいさんがやっていたアンケートに答えてGEO@チャンネル(rel="nofollow")の販促用レトルトカレーをゲットしてみた。

GEO@チャンネルというのは、セットトップボックスをテレビに接続して提供するオンラインレンタルビデオサービスというか、VODサービス。

…なのだが、私自身そもそもレンタルビデオのコンテンツにさほど興味がない(ケーブルテレビのコンテンツならともかく)。物理的なメディアを郵送するサービスである、ぽすれんとかTSUTAYA DISCASとかがそうであるように、所詮はアダルトコンテンツ配信用のサービスにしか思えない。しかも、貴重なバンド幅のうちの1~2MbpsをVODに奪われるというのは一エンドユーザーとしては飲めない条件だ。また、同様の(しかしセットトップボックスを使わない)livedoor ぽすれんBBが、「コアタイムのご利用はご遠慮ください」的なメッセージを掲示しているところを見ると、GEOのバックエンドがどこであれ、Centralized Serverのバンド幅がボトルネックになっていて、ISPがサービスしたりしない限り十分なサービス品質が実現できない可能性がある。かと言ってサービス元のGEOが各ISP向けにチャンネルを用意すれば過剰投資になる、少なくともそのおそれがある。つまりはサービスの品質と継続性に個人的には疑問を感じる。

というわけでまったく興味が持てず、(わずか一週間前のことにも関わらず)ほとんど忘れ去っていたところなのだが、なぜか昨日GEO@チャンネルのセットトップボックスが自宅に届いて思い出した。契約してないのによ、ぉぃ。秋葉原エンタまつりに出店していた代理店の仕業なのだろう。こういう商売の仕方をまだやっているんだね。その日のうちにコールセンターに契約していないし、その意思もない旨連絡して返送のための手続きを取った。20人に1人くらいは返送せずに使ってくれるのかしら。

教訓は、「無料で配っているカレーには気をつけろ、とりあえずアキバでは。」ということだ。

Nov 2, 2005

Google Mapsがgeocoderとして使えてしまう件について

Google Mapsで

http://maps.google.co.jp/maps?q=...&output=js

とか、

http://maps.google.co.jp/maps?q=...&output=kml

とかすると、実質geocoderとして機能してしまう上に住所の正規化までしてくれてしまうわけですが、これってgeocoderとして利用してしまうと利用規約上の問題があるのでしょうか。Google ローカルの利用規約を読んでも何も言及されていないようにも読めますが果たして...。

Google グループ: Google-Maps-APIにおいては、Google MapsのProduct ManagerのBret Taylorが「This is not allowed by the API terms of use. You should not scrape Google Maps to generate geocodes. We will block services that do automated queries of our servers.」と言明しています。しかしながら、機械的な方法で上記URLを叩くことがAPIの利用規約で禁止されているというのは意味不明な気もして釈然としません。とは言え、製品に責任を持つ人が「ブロックするよ」と言っている以上あえてするつもりはありませんけれど。

しかし...惜しいですね。もし使えるなら、RSSやAtom Feedをバータリーで食わせて自動的にBasic Geo (WGS84 lat/long) Vocabularyを付加するとか、極悪なサービスがいくらでも作れるのですけれどね。

追記: 一応、http://ogawa.googlecode.com/svn/trunk/gmaps-geocoder/にgeocoderサービスっぽいCGI/FastCGIスクリプトを作って置いてあります。動かす人はもちろんat your own riskで。

About Me

My Photo

つくばで働く研究者LV15

Total Pageviews

Amazon

Copyright 2012 Ogawa::Buzz | Powered by Blogger
Design by Web2feel | Blogger Template by NewBloggerThemes.com