前回から引き続き、OpenIDの "関連付け" と OpenSocial の汎用データストレージについて

MySpaceでOpenSocialアプリケーション "OpenIDクライアント" ー (1)

MySpaceでOpenSocialアプリケーション "OpenIDクライアント" ー (2)

association（共有鍵の交換）

OpenIDのspecでは認証リクエスト前にOpenID認証局と共有鍵の交換を行うことが推奨されている。

参考：http://lab.koshigoe.jp/en2ja/openid-authentication-2_0.html#associations

本来、鍵交換にはDiffie-Hellman鍵共有アルゴリズムを利用するべき、と思うけど今回DH鍵交換アルゴリズムを実装するのが目的ではないのでsettion_typeは一番単純な "no-encryption" で実装する。

なお "no-encryption" の場合SSL（https）で通信するべきとのこと（"no-encryption" association sessions MUST NOT be used unless the messages are using transport layer encryption.）

まずOpenID RPからOPへ association リクエストを投げる、前回のHTMLベース探索と同様に OpenSocial API の makeRequest で通信を行い、認証結果を受け取る。

openid.association = function(request_option, callback){
  var self = this;
  var params = {};
  params.contentType = gadgets.io.ContentType.TEXT;

  //パラメータをクエリーストリングとして付加しURLを組み立てる
  var param = [];
  param.push(["openid.ns","http://specs.openid.net/auth/2.0"]);
  param.push(["openid.mode", "associate"]);
  param.push(["openid.assoc_type", "HMAC-SHA1"]);
  param.push(["openid.session_type", "no-encryption"]);
  var url = this.makeURL(request_option.provider, param);

  //association HTTPリクエスト
  gadgets.io.makeRequest(url, function(result){
    //association レスポンス解析
  }, params);
}

送る方は簡単 session_type は "no-encryption"

共有鍵のキャッシュ -> OpenSocial汎用データストレージ

associationレスポンスを解析し有効期限（expire）が切れるまでキャッシュしておく。

今回はキャッシュのために OpenSocial API の汎用データストレージを利用する。このストレージ領域には key & value で任意の文字列を保存することが可能で、各アプリケーションそれぞれ別の保存領域となり、ユーザ毎にユニークとなるというデータストレージらしい。

opensocial.DataRequest クラスの newUpdatePersonAppDataRequest(ユーザID, key, value) メソッドを利用する。

http://code.google.com/apis/opensocial/docs/0.7/reference/opensocial.DataRequest.html#newUpdatePersonAppDataRequest

下記のようにパラメータを解析し結果をJSON形式の文字列へ変換、それをvalue、OPエンドポイントURLをkeyとする。

gadgets.io.makeRequest(url, function(result){
  var results = {};

  //レスポンス結果を解析
  var params = result.data.split("\n");
  for(var i=0; i < params.length; i++){
    if(params[i].search(":") > 0){
      var param = params[i].match(/^([^:]*):(.*)/);
      results[param[1]] = param[2];
    }
  }

  //assoc_handle, mac_key, expires等必要な情報をJSON形式の文字列へ
  var value = this.toJSON({
    "assoc_type":results["assoc_type"],
    "expires_in":results["expires_in"],
    "mac_key":results["mac_key"],
    "session_type":results["session_type"]
  });
  
  //汎用データストレージへ保存、keyはOPエンドポイントURL
  var req = opensocial.newDataRequest();
  var key = request_option.provider;
  req.add(req.newUpdatePersonAppDataRequest(req.PersonId.VIEWER, key, value));
  req.send(function(data){
    callback(result, data);
  });
}, params);

本来のDH鍵交換でやる場合は・・・HTTPリクエストをやって、データストレージへ期限切れるまでキャッシュという大枠は変わらない筈。

今回の gadgets.io.makeRequest API のようにOpenSocialコンテナ（myspace / orkut等）がプロキシとして働くHTTPリクエストの場合でも、DH鍵交換アルゴリズムなら盗聴の危険性は無いってことで良いのかな。あ、でもOpenSocialコンテナによる改竄の危険はあるのか。

まあ実装実験ということで。

以上

ちょっとしたJavaScriptのアプリケーションを作る時に、ちょっとしたデータ保存領域が欲しい事は結構あると思う。（占いアプリで占い履歴とか、占い選択肢とか）

その時サーバを自分で立ててWebAPIでデータストレージを用意してやるのは面倒、かなり面倒。

OpenSocial標準のAPIで汎用的なデータストレージが用意されていて、key & value ペアで任意の文字列を保存できるのは結構使い所ありそうだと思う。JSONにしてやれば構造化もできるわけだし。

AmazonEC2上で動いて、Webブラウザから開発・運用できるRailsアプリケーションのホスティングサービスheroku.com

Herokuが、ブラウザー内でRuby on Railsの開発を可能に

Heroku.com

がGitによるソース管理 & ローカル開発に対応したそうなので、ひとつ試してみる。Macで

Gitとherokuクライアントのインストール

まずPCにGitが入ってないのでインストール。そういえばGitが海外のRubistの間で流行ってるらしいねー、Coderepos的なGithubってGitリポジトリ共有サイトもあるらしいし。で今回のherokuもソース管理にGitを使うのでインストール

% sudo port install git-core

その後、herokuのコマンドラインクライアントをインストール

% sudo gem install heroku

自分用のssh公開・秘密鍵が無ければ用意しておく

% ssh-keygen -t rsa

自分のherokuアカウントと、ssh公開鍵を関連付ける

% heroku list
Enter your Heroku credentials.
Email: mymail@example.com
Password: ********
Uploading ssh public key
=== My Apps
resttest

登録成功、この時点でWeb上から作成済みのアプリケーションがあると、表示される。

テストアプリケーション作成

コマンドラインから新しいアプリケーション "tktest" を作成

% heroku create tktest
Created http://tktest.heroku.com/

ブラウザで開くと確かに作成済み、次にリポジトリからローカルへ落とす

% heroku clone tktest

裏では git clone tktest@tktest.heroku.com みたいなコマンドを実行してるっぽい。ここで何故かssh-keyが見付からないと言われたので ~/.ssh/config を書いておいた、Protocol 1 は不要だと思う。

% emacs ~/.ssh/config
Host *
IdentityFile ~/.ssh/id_dsa
IdentityFile ~/.ssh/identity
Protocol 2,1

tktestフォルダ内に通常通りRailsアプリのディレクトリができている筈

% cd ./tktest
% ruby script/server

mongrelが立ち上がり、とりあえずローカル開発準備完了

編集、コミット、デプロイ

新しいコードを作って適当に編集

% ruby script/generate scaffold Post body:text
.........

とりあえずできた、localhostで確認してからコミットする

% git add .
% git commit

gitの使い方がよく判らないけど、とりあえずコミット完了。本番環境へ反映する

% git push
Enter passphrase for key '.ssh/id_rsa':
Counting objects: 43, done.
Compressing objects: 100% (29/29), done.
.........
HEAD is now at e6b0b72... test
NOTICE: CREATE TABLE will create implicit sequence "posts_id_seq" for serial column "posts.id"
NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index "posts_pkey" for table "posts"
(in /mnt/home/userapps/15472)
== 1 CreatePosts: migrating ===================================================
-- create_table(:posts)
-> 0.1817s
== 1 CreatePosts: migrated (0.1818s) ==========================================

herokuのリポジトリへPushと同時に rake db:migrate と mongrelの再起動までやってくれるぽい。確認してみる

http://tktest.heroku.com/posts

うむうむ、動いてる。

以上

まあちょっとしたアプリケーション作るには楽で良いなheroku.com。現在はベータ中で無料、正式サービスになると課金が始まるらしいけどAmazon EC2で動いているので、課金額もそれくらいになるのかな。Google App Engineと比べると面白い機能は無いけど、作ったサービスの人気が出て自分のサーバで運用したくなったときにheroku.comは良いな。Rails & mongrel & MySQL(?) という普通の環境なので。

例えば突然 heroku.com のサーバが爆発してサービスが止まっても、ローカルにソースコード一式がで揃っているので自分のサーバを用意して復旧できる。データのバックアップだけは気を付ける必要あるけど、ちなみに heroku.com 本番環境の管理はWebからやれ、というポリシーらしい

DB管理画面

コンソール画面（ruby script/console）

あと、rakeタスクを実行する画面もある。

そういえば、ちょうど昨日Google app engineでちょっとしたアプリケーションを作る話を読んで

Google App Engineの使い道、tiny web service

確かに「サーバサイドで処理しないとできないけど、わざわざサーバを用意するのは面倒だな」ってときに、Google app engine や heroku.com や appjet.com なんかの環境が便利だなと思った。

そういえば、半年ほど前からfooo.nameの監視にmuninを入れていて、muninプラグインを書いてRailsのパフォーマンスをモニタリングできるようしているのですが

その手順を書いておくと誰か嬉しい人がいるかなと思ったので、メモを残しておきます。サーバはAmazon EC2

muninのインストール

apt-getでmuninをインストール

% apt-get install munin munin-node
% /etc/init.d/munin-node start

Apache・MySQL・CPU / メモリ / ネットワーク / ロードアベレージ 辺りのモニタリングが始まる。実際にはcronが設定されていてデフォルト５分に１回モニタリング結果がHTMLとして出力される。出力される場所はconfigファイル /etc/munin/munin.conf にあるので、好みで編集

% emacs /etc/munin/munin.conf
dbdir /var/lib/munin
htmldir /var/www/munin
logdir /var/log/munin
rundir /var/run/munin

あとは /var/www/munin 以下をApacheで見えるように設定、Virtual hostを設定してBasic認証を掛けておいた

% emacs /etc/apache2/httpd.conf
<VirtualHost *:80>
  DocumentRoot /var/www/munin
  ServerName *********
</VirtualHost>
<Directory "/var/www/munin">
  AuthType Basic
  AuthName "Munin zone"
  AuthUserFile /etc/apache2/.htpasswd
  Require user ********
</Directory>

Railsのログをmuninでモニタリング

あとは、この↓サイトを真似してやればOK

Monitoring Rails Performance with Munin and a Mongrel

Railsの出力するlogから total / render / db の時間を見つけ max と avg の値を求め、muninでそれを監視する。Railsアプリケーションの scriptフォルダへ以下のスクリプトを置く

% emacs script/rails_log_monitor.rb
・・・・・・
h = Mongrel::HttpServer.new("127.0.0.1", PORT)
h.register("/avg_response_time", ResponseTimeHandler.new(:average))
h.register("/max_response_time", ResponseTimeHandler.new(:max))
h.run.join
rails_log_monitor.rb

上記スクリプトを実行すると port 8888 でmongrelが立ち上がる、muninはそこへアクセスし結果を取得する

% ruby script/rails_log_monitor.rb

次に、muninプラグインとして下記のスクリプトを /etc/munin/plugins 配下へ

avg_response_time

avg_response_time と max_response_time という名前で置いておく。結果muninが http://127.0.0.1:8888/#{ファイル名} へアクセスし結果を取得、グラフ化。

以上

基本このサイトを真似してやればOK、rails_log_moniter.rb を好きにいじれば ”特定のアクション・コントローラ・処理" 等をグラフ化してモニタリングできる筈。

↓ このエントリの続き

MySpaceでOpenSocialアプリケーション「OpenIDクライアント」を試す ー (1)

引き続き、OpenIDのIdentifier入力からOpenID Provider（以下OP） エンドポイントURLの探索までを実装する

input（入力）

UIとしてIdentifierを入力するフォームを用意、submitにイベントを追加する。今回この辺りはjQueryを使った。

<form class="rp">
  <input id="identify" type="text" name="openid_identifier" />
  <input type="submit" value="Sign in" />
</form>
<script type="text/javascript">
  $("form.rp").submit(function(){
    var ident = $("#identify").attr("value");
    openid.auth(ident, function(result){
      //something do
    });
  });
</script>

formの値を取得し、メインロジックopenid.authを呼ぶ。以後は normalize > discovery > association > authentication > response parse > verify の順に実行していく。

この辺りはまだOpenSocialに関係無く普通のHTML + JavaScript

ちなみに処理全体の流れは、大体以下のようになる予定。

var openid = {
  auth: function(request_ident, callback){
    var self = this;
    //IDの正規化、http://を補足（ 例：tkmr.myopenid.com => http://tkmr.myopenid.com/ ）
    request_ident = self.normalize(request_ident);
    //OpenID認証局のエンドポイントURLを探索（ 例：http://tkmr.myopenid.com/ => http://myopenid.com/server ）
    self.discovery(request_ident, function(request_option){
      //共有鍵の交換（任意） - 未実装
      //var assoc_handle = self.association();
      //discoveryで見付かったOpenID認証局エンドポイントURLへ認証リクエストを投げる（IFrameで代用）
      self.auth_request(request_option, function(response){
        //認証結果を確認、IFrameのURLから取得
        var res = self.auth_response_parse(response);//認証結果の署名を確認
        if(self.verify(res)){
          callback(res);
        }else{
          callback(false);
        }
      }
    }
  }
}

normalize（正規化）

参考：http://lab.koshigoe.jp/en2ja/openid-authentication-2_0.html#normalization

ユーザの入力したIdentifierの正規化を行う、正式な仕様としては XRI の正規化をサポートする必要があると思うが今回は未実装

とりあえずIdentifierが http で始まらない場合 http:// を付加しておいた。

openid.normalize = function(identify){
  var new_ident = identify.search(/^(http|https):\/\//) > 0 ? identify : "http://" + identify;
  return new_ident;
}

discovery（探索）

参考：http://lab.koshigoe.jp/en2ja/openid-authentication-2_0.html#discovery

正規化後、Identifier（例：http://tkmr.myopenid.com ）からOPエンドポイントURL（例：http://myopenid.com/server ）を知る必要があり、その探索方法として下記の３種類がある

　・HTMLベース探索

　・XRI （ XRIのリンク集 - Yet Another Hackadelic ）

　・Yadis （ 第3回　OpenIDプロトコルの特徴－DiscoveryとSREG ）

今回の実装では、HTMLベース探索 を試す（XRIとYadisによる探索は未実装）

openid.discovery = function(ident, callback){
  switch(ident.split("://")[0]){
  case "http":
    openid.html_discovery(ident, callback);
    break;
  case "xri":
    openid.xri_discovery(ident, callback);
    break;
  default:
    alert("error!!!!!");
    break;
  }
}

HTMLベース探索の実装

ユーザのIdentifier（URL）に存在するHTMLを取得し、OPのエンドポイントURLを探し出す。

例：
<html>
<head>
  <link rel="openid2.provider" href="認証局エンドポイントURL" />
</head>

まずIdentifier（URL）にあるコンテンツを取得する必要がある、今回はHTTPリクエストを OpenSocial APIの gadgets.io.makeRequest で投げる。

openid.html_discovery = function(identify, callback){
  var params = {};
  params.contentType = gadgets.io.ContentType.TEXT;
  gadgets.io.makeRequest(identify, function(res){
    //取得結果(HTML)のパース&解析処理
  }, params);
}

gadgets.io.ContentTypeは XML・JSON・TEXT・FEED の４種類が用意されていて、XMLならXMLHttpRequestのresponseXMLが返ってきたりと、それぞれ想像通りに動く。

・ContentType：http://code.google.com/apis/opensocial/docs/0.7/reference/gadgets.io.ContentType.html

・RequestParameter：http://code.google.com/apis/opensocial/docs/0.7/reference/gadgets.io.RequestParameters.html

また任意のヘッダをリクエストへ付けることも可能

・Header ：http://code.google.com/intl/ja_ALL/apis/opensocial/docs/0.7/reference/gadgets.io.RequestParameters.html#HEADERS

params[gadgets.io.RequestParameters.HEADERS] = {"Accept-Language" : "ja"};　

今回の対象はHTMLのため ContentType はTEXT に設定、単純なStringとしてHTMLが返ってくるので、そのHTML内にある目的の <link rel="openid2.provider" href="***" /> タグを探す

var results = {}
var links = res.data.match(/<link[^>]*>/g);
for(var i=0; i < links.length; i++){
  var link = links[i];
  if(link.search(/rel.*openid2.provider/) > 0){
    results.provider = link.match(/href="([^"]*)"/)[1];
  }else{
    if(link.search(/rel.*openid2.local_id/) > 0){
      results.local_id = link.match(/href="([^"]*)"/)[1];
    }
  }
}
callback(results);

ついでに rel="openid.server" も探しておいた方が良いかも。

おまけ：Yadis探索を実装

するためにはレスポンスヘッダの内容を知る必要がある、はず。OpenSocial / makeRequestのドキュメントには特に記述が無かったのでレスポンスヘッダへのアクセスは不明・・・

ただ、makeRequest の通信内容を見る限りでは取得可能なように見える。

レスポンスヘッダさえ取れれば、あとは x-xrds-location に設定されたURLにあるXRDS文章を取得し、XRDSの仕様に従ってOPエンドポイントURLを見つける、で良いのかな。

XRIは・・・、仕様から勉強しておきます：）

以上、今回はOpenID Providerの認証エンドポイントURLの探索まで実装しました。

それでは明日へ続く

先々週、MySpace JapanのOpenSocialプラットフォーム対応が発表された

マイスペースが開発者向けプラットフォームを発表 - OpenSocialに完全準拠

ということで、久しぶりにOpenSocialを色々といじってみようと思う。何かネタが無いとやりづらいので「OpenSocial上で動くOpenIDクライアント（Relying Party）」というネタで試してみよう。

OpenSocial ver 0.7

OpenSocial自体については Ver 0.5 の頃Orkut上で試したので、今回はそれを振り返りつつ Ver 0.7 までで新しくなった部分をMySpace上で試してみる。

Ver 0.7変更点

・外部サイトへHTTPリクエストを投げるAPI追加（XML・JSON・Text・Feed（RSS or Atom?））

　　http://code.google.com/apis/opensocial/docs/0.7/reference/gadgets.io.html#makeRequest

・取得可能なプロフィール情報の項目追加（性別・好きな音楽・本 等々）

　　http://code.google.com/apis/opensocial/docs/0.7/reference/opensocial.Person.Field.html

・各アプリケーション毎のデータストレージ API 追加（ 任意の key & value のペアでサーバへ保存される、アプリケーション + ユーザID + key でユニークとなる）

　　http://code.google.com/apis/opensocial/docs/0.7/reference/opensocial.DataRequest.html#newUpdatePersonAppDataRequest

・Activityが実装されつつある？（「○○さんが××をしました」みたいな通知API）

・環境情報が追加（実行中の画面やドメインが取れる、ホーム画面・プロフィール画面・専用画面、orkut.com・myspace.com）

・ネームスペース変更多数（gadgets）

他色々と。

外部サイトへのHTTPリクエストを行う makeRequest API がなかなか使い所ありそうなので、これを今回は試す。あとデータストレージも試してみよう。

ということで、無理矢理っぽいけど「OpenIDへのログイン→ログイン履歴保存」という流れで実験。

ちなみに、外部HTTPリクエストを行う makeRequest APIの仕様は、プロクシを経由することでクロスドメインAjaxが可能、といった代物で以下のようにリクエストが飛ぶ

　クライアント ＞ プロクシ（proxy.myspace.com等） ＞ 外部サイト

意外に細かい部分で気が利いていて、任意のヘッダが設定可能 & 任意のメソッドが設定可能（GET/ POST / PUT / DELETE）

Basic認証や無理矢理やれば WSSE認証も多分できそう。AtomPubクライアント in OpenSocialなんてのも面白そう。

MySpace Developer Platform

OpenSocial仕様外の部分で、MySpace独自API（ユーザの投稿写真・ビデオ等）もあり、リファレンスはこちら

MySpace Developer Platform

この辺りも将来的にはOpenSocial APIとして足並みそろえていくのかな。

個人的に写真・ビデオ・音楽といった一般的な情報はOpenSocialに含めてＯＫじゃないかと思う。逆に、株取引SNSの「注目の銘柄」や競馬SNSの「最近買った馬券」なんてサービスのドメインにべったり寄った情報は独自APIという方向に進む、のかな。線引きが難しい。

また、MySpaceとOpenSocialの関係については

OpenSocialとかどうよ？的な勉強会(!?)に参加してきた - Tender Surrender

こちらが、アプリケーション互換性の問題からマネタイズまで、判りやすくまとめられているので参考に。

MySpaceデベロッパー登録 ＞ アプリケーション作成

実際にMySpace上でアプリケーションを作成するには、デベロッパーとして登録する必要があるので登録。この辺り、登録から初めてのアプリケーション作成まで、こちらのサイトで分かり易くままとめられている

MySpaceアプリケーションを作ろう - ラーニング人生

この手順に従ってやれば簡単にできる、筈。

実装方針

・OpenIDの基本的な流れを実験する

　　・XRI や Yadis による探索は未実装

　　・関連付け（共有鍵の交換）は未実装

　　・OPから受け取った署名の照合も未実装・・

・処理フローはこんな感じで

　　・input （ユーザによるidentifierの入力）

　　・normalize（identifierの正規化）

　　・discovery（OP Endpoint URLの探索）

　　・association（共有鍵の交換）※未実装※

　　・authentication（認証リクエスト）

　　・response（認証結果のパース）

　　・verify（署名の確認）※未実装※

以上

それでは明日へ続く、次回は実装を

Google app engineのアカウントが申し込み間に合わなくてくやしいので、Dropboxについてでも書こう。　

rsync + Amazon S3 + subversion × 全自動 = dropbox

「気軽に複数PCでファイル共有できるオンラインストレージ」という触れ込みで登場したDropbox

Techcrunch - Dropbox: みんなが待ち望んでいたオンラインストレージソリューションかも

現在5GBまで無料のオンラインストレージで、実際のストレージにはAmazon S3を利用しているらしい。WindowsとMac用のクライントがあり、これが良くできていて

ファイルの変更を検知して全自動でオンラインストレージへ保存し続けてくれる。しかもソース管理ツール的な履歴機能付き、編集の衝突も検知して上手く回避してくれる。

さらに友人・知人と共有するSharedフォルダも作れてソーシャル的な展開も考えているみたい、試していないけど。

動作例

例えば、このフォルダへ

普通にメモ帳でテキストを保存する

ファイルが自動でオンラインストレージに同期される！

履歴管理・衝突回避・その他

プログラマならこの辺が気になるだろうと思うので補足。

履歴機能もしっかりしている、普通に個人で書くコードくらいなら履歴管理まかせても良いくらい

さあここで大変！自宅と会社で編集したファイルが衝突した！！

衝突したファイルはリネームされて保存される。上書きされて消えた！ってことは起こらない。まあ現実的な対応かな、しいていうなら「衝突ファイル一覧」を見たいくらいかな、RSSとかで。

あと基本的にインストール後現れる「Dropbox」フォルダ以下が同期される、でもどうせならホームフォルダ辺りをこのDropbox以下にシンボリックリンクでリンクさせとくと超快適

　・Windowsの場合 : file link -symbolic リンク先 リンク元

　・Macの場合 ： ln -s リンク元 リンク先

Macは普通だけど、Windowsにシンボリックリンクがあるのをこの件で調べて知った・・

Dropbox本当に細かい部分で気が利いていて良い、しかも何気に感動したのが全くストレスが無いこと。

今まで、WebDAVで複数PCを同期、なんて方法も試したけどどうも書き込み＆読み込みが遅くストレスになって結局やめた。Box.net とか。

でもDropboxの場合、ユーザはローカルのHDDを普通に読み書きする、その後バックグラウンドでゆっくり同期を行っているんだ思う。

あくまでも我々はローカルHDDを読み書きするので、本当に存在を忘れるくらい快適。

ローカルHDDをキャッシュに使う、という発想はWebDAVになかったんだな、まあWebプロトコルのWebDAVとクライアントアプリケーションのDropboxでは性質が全く違うので当然なんだけど。

全データをオンラインに保存する時代になると、ローカルHDDは只のキャッシュになるんだなと思う。

全データをオンラインに保存する時代 ＝「アクセス権限制御」の時代

「データをブログに書く」じゃなくて、「もうウェブにはのってて、パブにするかどうか決めるだけで情報は出る」べきだと思っていた。この「パブにするインターフェイス」みたいなものが効率化すればいいと。このためには文字列一致検索なり、属性絞込みなりについて、最高のインターフェイスがあって、筋肉運動くらい自由で詳細に（あるいはペンとか本のページをくくるくらい自由に詳細に）権限管理ができるべきだった。

ウェブ3時代は「アクセス権限制御」の時代だと思えてきた - tokubo.com

以前この↑文章を読んで、色々考えていた世界がDropboxで実現しそうな感じ。実際は5GBなんてちんけな容量なので「世界の片鱗が見えた」くらいだけどそれでも大きな進歩だ。

自分の書いたテキスト、写真、楽曲、メール、ソースコード、コンフィグファイル、ブックマーク、ブラウザの履歴、コンピュータの操作履歴、、、全部オンラインストレージへ同期されていて

API経由で自由に加工可能な世界がきっと来る。

実際、@ITでのDropbox開発者へのインタビューでもAPIの話が出ていて

同社は現在すでにいくつかのオンラインサービス提供者と協力して、DropboxをWebアプリケーションから利用できるようAPIを整備している。となれば、例えばデジカメの写真をFlickrにアップロードするのに、Webブラウザや専用アプリケーションを用いる必要はなくなり、ふつうにフォルダにファイルをコピーするだけで、写真を公開できるようになる。逆に、Flickrにアップロードしたファイルを、ローカルのPCの画像編集ソフトを使ってダイレクトに編集ができるようになる。

http://www.atmarkit.co.jp/news/200704/09/dropbox.html

写真は全てオンラインに載ってて、あとは共有したい写真・フォルダを選びFlickrへ権限を与えるだけでデータがFlickrへ流れ・同期され公開される。「自分は全てFlickrで公開する」なんて人は全権限Flickrに与えるんだろう。

または編集したい写真はPicnik（オンライン写真編集サービス）で編集する。Picnikに権限を与えて自動処理・一括処理も可能だろう。これはBox.netとPicnikで既に実現されている

ほかのサービスとくっつけられるストレージサービスOpenBoxを自分でくっつける - bits and bytes

Dropboxで写真をオンラインと同期し、APIが用意されていれば

・Flickrに権限を与え写真共有

・Evernoteに権限を与えておくことで画像検索

・Picnikに権限を与え写真編集

・基本のフロントエンドは今まで通りのアプリケーションでＯＫ（ iPhoto とか）

・ローカルHDDがキャッシュしているのでレスポンスもＯＫ

音楽なら

・Muxtapeに権限を与え、ミックステープ化＆音楽共有

・オンライン楽曲編集サービスに権限を与える

・楽曲検索サービスに権限を与える

・基本のフロントエンドは今まで通りのアプリケーションでOK（ iTunesとか）

テキストならさらに色々な二次加工・二次利用が可能だろう。

個人のライフログは全てオンラインに存在して、色々なサービスへ権限を与えることで過激に面白く加工してくれるんだろう、ブラウザのアクセス履歴はPathtraqへ、IMEの変換履歴はSocial IMEへ。

さらに、DropboxはWebDAVと違ってユーザを待たせない、というかシンボリックリンクや同期の設定等を済ませれば

普通に生活しているだけでオンラインストレージとデータが保存されている。あとはそれを見たい人 or 加工したいWebサービスへ権限を与えておくだけだ。

基本的にユーザの時間を邪魔しない、これは重要だと思う。

インターネットでどんなサービスを使うにしても、時間をかけないではできない。だからユーザが新しいサービスを使いはじめるには、今まで使っていた何かを止めないといけないし(自分はtumblrのdashboardをみはじめてdiggを見るのを止めた)、今使っているサービスを、新しいサービスを使うために使わなくなったりする(twitterをつかいはじめてmixiをやめた、とか)。

ゼロオーバーヘッド・ブロギングの時代

この話を見てから、悶々と考えていたゼロオーバーヘッドなサービス、Dropboxは何気に満たしているなと思う

今までもFTPを使ってファイルをサーバへアップロードすればオンラインストレージへ溜めておくことはできた、WebDAVでも良いけど、でも「全ファイル」するのはコストがかかりすぎてできなかったし誰もやろうと思わなかった。cronやスケジューラとスクリプトを頑張って書けば全自動も可能だろう、でもその手間は一般人にとって相当なコストだ。

でも現実に、近い将来全データをオンラインストレージへ保存することは可能になりつつある、これはAmazon S3でストレージ容量が劇的に下がったのも大きいだろうし、その土台はHDDやメモリ・CPUのチープ革命が支えてるんだろう。

ベータ中のOCRサービスEvernote ↓

Evernoteで自分の脳を拡張する（プライベートベータご招待）

のベータサービスアカウントが届いたので試してみた。サインアップページから本登録

CAPTCHAがある。。。

さっそく試してみよう、Evernoteのスキャン力とCAPTCHA、どっちが上か？

一文字目 "b" は認識

二文字 "b8" は無理。。：(

もう少し弱いCAPTCHAなら解けるかも、ってところか。色々試してみたけど、なかなか性能良い印象。

あとメールに写真を添付して投稿もできる。日本語は未対応ぽい。

ここから登録して、二週間待ちくらいでアカウント届いた。

で、関係ないけど最近読んだ本の話を少し

「しあわせの理由」はグレッグイーガンの短編集で、中身も面白かったけど文末の解説が面白かった。

　円周率というものを完全に記述するのに無限のメモリーが絶対必要かというとそんなことはない。「無限のメモリーさえあれば、無限に計算を続けられる円周率計算 のプログラム」は実は有限のメモリーに収められるからだ。「つまりこのプログラムで 計算した数」と定義することで、本来無限のメモリーの必要な情報を、有限の情報のみ で完全に記述できてしまう。

・・・・・・・

　ついでにもっと妙なことを考えてみよう、０から９までの数字とAからZまでの英大文字、それにスペースや記号であわせて四十文字ぐらいあれば英語の文章が作れる。 この文字に二桁の背番号を振る。０は「00」、9は「09」でAは「10」、スペースは 「36」という具合だ。円周率は数字がバラバラに並んでいて無限に続くのだから、その中には何兆桁目かもれないが、どこかに

「0200010009010136201022182010351436233436322912」

と続いている部分が必ずあるはずだ。この数字列を上の背番号表で解読すると

「20010911 KAMIKAZE NY WTC」

となる。すごいでしょ。この調子でいけば、いままでの人類の過去から未来までの悠久の歴史すべてを円周率の中に読み取ることができるだろう。たかだか有限のノストラダムスの詩文の中から無理してこじつけるより、はるかに確実な無限の大予言・それが有限のプログラムから生み出される。

（坂村 健）

と、そこから「円周率に意味を見いだすのは、見ている自分自身」という話から、イーガンの作品解説に繋がっていく（確かに順列都市なんてこの話そのもの）で、これはこれで面白かった。でも、その後に偶然読んだこれ ↓

の中の「バベルの図書館」この解説はネットに山ほど転がっていると思うので、乱暴に要約すると「無限の広さを持ち無限の本数の蔵書がある図書館」の話で、その中でも全く同じテーマが語られていて

ある天才的な司書が図書館の基本的な法則を発見した。この思想家のいうには、いかに多種多様であっても、全ての本は行間、ピリオド、コンマ、アルファベットの二十五字という、おなじ要素からなっていた。また彼は、全ての旅行者が確認するに至ったある事実を指摘した。

広大な図書館に、同じ本は二冊ない。彼はこの反論の余地のない前提から、図書館は全体的なもので、その書棚は二十数個の記号のあらゆる可能な組み合わせを、換言すれば、あらゆる言語で表現可能なもののいっさいをふくんでいると推論した。

思い返せば、昔読んだ「砂の本」も全く同じテーマだったのに、当時は気付かなかった。無限に続く本や図書館（や数字）があるとして、その中には人類の、過去全ての歴史だけでなく未来の出来事も全て書いてあるのか・・・「3/15 ブログでボルヘスについて書く」という文章も確実に書いてある！

で、その無限の知識を持つ「砂の本」でも「バベルの図書館」でも、結局人間は何もできずに翻弄されるだけってのが面白いな。「砂の本」も「バベルの図書館」にも索引（インデックス）が無くて、結局人間が扱えるものじゃなかった。

逆に言うともし「砂の本」に索引が付いてたり、「バベルの図書館」に全てを理解した司書（文中では「書物の人」と表現されている）がいれば、無限の知識を人間が利用することができる。「書物の人」は文中では

他のすべての本の鍵であり完全な要約である一冊の本が存在し、ある司書がそれを読みとおし、神に似た存在となった。

と表現されている。無限の情報を持つ「バベルの図書館」よりも、その要約である一冊の本の方に価値がある。

これ、Web上に無限に近い情報があっても Google が持つ索引（インデックス）を使って要約を提供してくれないと、上手く活用することができない。ってのに通じるし、AutoPagerizeやLDRizeが広まったことでメタデータの重要性が高まってきているのにも通じると感じた。無限のデータもメタデータがあって初めて価値がでる。

無理矢理話を最初のEvernoteに戻すと、、Evernoteの技術は面白いし凄い。ただ個人が持ってる少量のデータなんて大したことないんだから、Web全体の画像を対象にしてメタデータを付けてくれたら面白いな。

これ、半年後になってみたら、EvernoteがGoogleに買収されててGoogle Image searchとして実現されてたりして。