Weboo! Returns.

ここ半年くらいずっと取り組んできた例のモバイルのプロジェクトが、ちょうど一週間前にローンチしました。細かい不具合こそいくつかあったものの、何とか無事にリリースまでこぎ着けられて正直ほっとしています。ほぼ何もないところからのスタートで、設計から構築の部分まで自分がメインで関わったプロジェクトなので、本当に感慨深いです。

お陰様で、リリース当初より予想をはるかに上回るアクセスが来ています。このプラットフォーム上で動作するアプリを作っている方なら分かってもらえると思いますが、凄まじい量のアクセスです。一番人気は自分が前にいた会社「ウノウ」のアプリなのですが、ユーザ数の急激な増加で対処に苦労しているようです。リリースから5日で100万ユーザを超えるサービスなんてそうそうないわけで、技術力がないと対応は難しいかもしれません。機能制限をかけつつも安定して稼働させているあたりは、さすがウノウといったところ。一応、徐々にユーザに解放をしていく仕組みが用意してあるのですが、キャパを超えてもユーザを確保したいというところが多くて、うまく活用されていないのが少し残念です。

当然、プラットフォーム側にはアプリ数をかけた分のアクセスが来ているわけですが、弊社のインフラエンジニアが非常に強力で今は事なきを得ています。今後、より一層のパフォーマンス改善が求められていますが、ボトルネックとなっている部分がだんだんと見えてきたので、今はそんなに心配はしていません。

今のところ、いわゆるスコアを競うだけのアプリが多かったりするんですが、今後は海外SNSで流行っているようなソーシャル性を活用したアプリケーションがより一層伸びてくると思います。アプリケーションが複雑化することで、より技術力の高いエンジニアが求められてくるわけですが、そう簡単に人は集まりません。クラウドをうまく活用して、ユーザの急拡大にも対応できる仕組みを用意しているかどうかが鍵となってきそうです。

OpenSocial の Signed Request を Google App Engine で検証する方法についてです。Signed Request は、OpenSocial コンテナからのリクエストが正しいものであるかを検証するための仕組みです。OAuth Signature を検証することで、リクエストパラメータの不正な改ざんを検出することができます。この署名付きリクエストの検証方法については、mixi Developer Center に分かりやすいサンプルがあるのですが、PHP と Java と C# のみで Python がありません。

ヽ(`Д´)ﾉ

そこで mixiアプリからのリクエストを検証するサンプルを書いてみました。

• signed_request.py

利用するためには、次の2つのライブラリが必要です。

• oauth.py
• Crypto

これらを 次のように App Engine のプロジェクト直下に置いてください。

nantoka-project/
|-- Crypto/
|-- app.yaml
|-- index.py
|-- index.yaml
|-- oauth.py
|-- signed_request.py

Cryptoは、下のようにすると簡単に入手できます。

% svn export http://gdata-python-client.googlecode.com/svn/trunk/src/gdata/Crypto

準備ができたら、さっそく使ってみます。使い方は、モジュールをインポートして、署名を検証したいリクエスト・メソッドのデコレータとして指定します。動いているアプリケーションに下線部分を追加するだけです。

from google.appengine.ext import webapp
import wsgiref.handlers

from signed_request import signed_request

class Index(webapp.RequestHandler):
    @signed_request
    def get(self):
        # do something
        self.response.headers['Content-Type'] = 'text/plain'
        self.response.out.write('OK')

def main():
    application = webapp.WSGIApplication(
        [('/', Index),],
        debug=True)
    wsgiref.handlers.CGIHandler().run(application)

if __name__ == "__main__":
    main()

以上。

だけだと素っ気ないので、signed_request.py の中身を簡単に説明します。通常なら OAuth のクライアントライブラリを使って簡単にできそうなものですが、Google App Engine では openssl のライブラリが使えないので、多くのコンテナで採用されている RSA-SHA1 形式の署名を検証するには少し工夫する必要があります。外部サーバの呼び出し » mDCのページに記載されている公開鍵を mixi.cer という名前のテキストファイルに保存します。そして、この公開鍵を16進数表記に変換します。

% openssl x509 -modulus -noout < mixi.cer | sed s/Modulus=/0x/
0xC048F9DD595072FD561EF7D69533FE4F5957520F755BE6E0252B87003F3D3DD55FF548E78BDD
8491B8EA68B0F3038DFE53950B94AFF4E6344E9C6C050557484B150B81EBD2A624DF81B7C270A6
D15BB857AD34A68C5444A7B60EBDF953DEBAFBAAA36F8E6FB75C4D79EF3714DF74973081AF5F5B
901FF6387CDA44135A665FE5

signed_request.py 中の MIXI_CERT がこれに当たります。他のコンテナに対応させる場合も同様に変換すれば OK です。

関連リンク：
» Building an OpenSocial App with Google App Engine
» OpenSocial in the Cloud（日本語訳）

先日、goo と リクルートMTL 主催で開催された OpenSocial Hackathon に参加してきました。久しぶりに仕事と関係のない開発ができたのと、ここしばらく JavaScript と無縁の生活を送っていたのでリハビリができてかなり楽しかったです。

Hackathon はいくつかのグループに分かれて、それぞれが開発を行いました。僕はリクルートのAPIを使って、OpenSocialアプリケーションを作成するチームに加わりました。リクルート・メディアテクノロジーラボさんは会場を貸してくれた上に、お昼ご飯と懇親会のピザまで提供してくれました(MTL++)。

そして、この素晴らしいAPIを使って作ったのが、「チャンネー」というこのアプリ！
なんと、Hackathon参加者による投票で1 等賞を頂いてしまいました。

ひとことで言うと、自分の気に入った髪型をお取り置きしておけるアプリケーションです。ルールは簡単で、2人ずつチャンネーが表示されるので気に入ったほうを次々にクリックしていきます。ここではどっちの女性がタイプかではなく、必ず髪型で選んでください。想定外の使い方をしてAPIを止められたら元も子もないので、くれぐれもよろしくお願いします。ページ下部には、マイミクが選んだ好みの髪型も表示されます。
また、ホーム画面では下のように自分が選んだチャンネーがスライドショー形式で表示されます。

もちろん OpenSocial ということで、マルチ・プラットフォームに対応しています。mixiアプリ版とgooガジェット版がありますので、ぜひ試してみてください！

mixiアプリ版
http://platform001.mixi.jp/view_appli.pl?id=1357

gooガジェット版
http://sandbox.home.goo.ne.jp/gadget/K4FZzsNtd51b/detail

ここで、mixiアプリをまだ使ったことがない人のために、簡単に使い方を説明しておくと、まだmixiアプリはオープンβ段階なので特別なURLにアクセスする必要があります。既に多くのアーリーアダプタな方々が参加されているので、私のブログを読んでくれているような人たちはもう利用されているかもしれませんが、以下の手順に従ってアプリを登録してください。

１．「mixiアプリ オープンβ」コミュニティに参加

mixiアプリ オープンβ

※既に参加済みの方は必要ありません。このコミュニティに参加し、かつ platform001.mixi.jp にアクセスすることでアプリ関連の機能が利用可能になります。

２．アプリページにアクセス

チャンネー

上記のページにアクセスします。
ログイン画面が表示された場合は、ログイン操作を行ってください。

３．アプリを追加する

「アプリを追加する」をクリックします。

以降、これからは http://platform001.mixi.jp にアクセスすることで、mixiアプリを利用できます。勘違いしている人が多いようですが、アプリを使ってみるだけなら開発者登録は必要ありません。

関連リンク：
OpenSocial Hackathon in Aprilレポート！ - gooホーム Developer's Recipe

先日、Google 東京オフィスで開催された OpenSocial 1周年記念イベントの様子が Google Japan のブログと Asia Pacific 向けのブログで公開されています。

• Google Japan Blog: OpenSocial 1周年記念
• OpenSocial Celebrates 1st year Anniversary in Tokyo with new technical innovations

Chris さんに gumi Platform の説明をしたら、とても興味を持ってもらえたようで図入り写真付きで大きく取り上げていただきました。ありがとうございます！少し補足しておくと、Google App Engine については、アプリケーションのホスティング環境として使える＆使っているということで、Platform 自体が App Engine 上で動いているという意味ではないので誤解なきようお願いします。（Chris さんにはちゃんと伝わっているはず…）

海外の Facebook や MySpace, hi5, Orkut 等のソーシャル・プラットフォームの盛り上がりに対して、日本ではまだまだこれからの分野ですが、来年にはmixiアプリも始まってかなり面白いことになりそうです。よういちろうさんのOpenSocial本も発売されるようで今から楽しみです。

Google Friend Connectが利用可能になったので、さっそくブログ右側に設置してみました。

Google Friend Connectとは何かというと、あらゆるWebサイトをSNS化してしまおうという試みです。以前からMyBlogLogがこのようなサービスを行っていましたが、決定的な違いは既存のSNSの友達関係を使って友人を招待したり、同じサイトの利用者＋友人というフィルタをかけたりできることです。今のところ、ソーシャルグラフとしては、Google Talk, Orkut, Plaxoだけが利用可能なようですが、これから対応SNSはさらに増えてくるものと思われます。当然のように、これに対してFacebookはFacebook Connectという機能を開始しています。

先日、mixiが来年から招待制をやめるという話がありましたが、このような世界的なSNSオープン化の動きを見据えてのことだと考えておけば納得がいくのではないでしょうか。SNSに関してもガラパゴス化しつつある昨今の日本の状況ですが、来年はOpenSocial元年にしたいところです。

前に「OAuth Consumer Request の処理フローと実装」で紹介した 2-legged OAuth 処理のPHP版です。

通常の OAuth では、ユーザの確認画面を間に挟んでトークンのやり取りを行いますが、OAuth Consumer Request は既に信頼関係にあるという前提でトークン発行、承認の手順を省いたものです。コンシューマとサービスプロバイダ二者間での信任フロー（2-legged OAuth）になります。詳しい仕様については下記を参照してください。

まずは、実際の処理手順を説明していきましょう。コンシューマは次のパラメータをサービスプロバイダに送信することになります。 Consumer Key と Consumer Secret については、サービスプロバイダから提供されているものを使います。

ここで、 oauth_signature は以下のようにして生成されます。まず、ベース文字列を用意します。

1. GET
2. http://api.gu3.jp/v1/test/auth
3. oauth_consumer_key=yamashita.dyndns.org&oauth_nonce=c83b1847200
   bd25d918c3fb077aca16f&oauth_signature_method=HMAC-SHA1&
   oauth_timestamp=1219931263&oauth_version=1.0

次にこれらをURIエスケープした後に & で連結して、ベース文字列を生成します。

GET&http%3A%2F%2Fapi.gu3.jp%2Fv1%2Ftest%2Fauth&oauth_consumer_key
%3Dyamashita.dyndns.org%26oauth_nonce%3Dc83b1847200bd25d918c3fb0
77aca16f%26oauth_signature_method%3DHMAC-SHA1%26oauth_timestamp
%3D1219931263%26oauth_version%3D1.0

そして、このベース文字列を HMAC-SHA1 によってダイジェスト値を生成し、BASE64 でエンコードすることによってシグニチャを生成します（サービスプロバイダによっては RSA-SHA1 の場合もあります）。この際、利用する共有キーは cosumer_secret　と 空のToken Secret を & で連結したものになります。例えば、 consumer_secret が kd94hf93k423kf44 なら kd94hf93k423kf44& になります。こうして、シグニチャは以下のようになります。

M32qYtcaUD8b1Kb/AponRG5hrwI=

こうして生成されたパラメータをAPIリクエスト時の Authorization ヘッダに追加して、サービスプロバイダに送信します。

Authorization: OAuth realm="http://api.gu3.jp/",
               oauth_consumer_key="yamashita.dyndns.org",
               oauth_signature_method="HMAC-SHA1",
               oauth_signature="M32qYtcaUD8b1Kb%2FAponRG5hrwI%3D",
               oauth_timestamp="1219931263",
               oauth_nonce="c83b1847200bd25d918c3fb077aca16f",
               oauth_version="1.0"

実際のPHPスクリプトは次のようになります。なお、実行には Google Code にて公開されているPHP用ライブラリ(OAuth.php)が必要です。

<?php
require_once 'OAuth.php';
define('CONSUMER_KEY', 'yamashita.dyndns.org');
define('CONSUMER_SECRET', 'kd94hf93k423kf44');

function OAuthConsumerRequest($method, $url, $data=NULL) {
    $consumer = new OAuthConsumer(CONSUMER_KEY, CONSUMER_SECRET);
    $signature_method_hmac_sha1 = new OAuthSignatureMethod_HMAC_SHA1();

    // access protected resources
    $oauth_request = OAuthRequest::from_consumer_and_token($consumer,
                                                           NULL,
                                                           $method,
                                                           $url);
    $oauth_request->sign_request($signature_method_hmac_sha1,
                                 $consumer, '');

    $headers = $oauth_request->to_header();

    $ch = curl_init($url);
    curl_setopt($ch, CURLOPT_HTTPHEADER, array($headers));
    curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);

    $result = curl_exec($ch);
    if ($result === FALSE) {
        return curl_error($ch);
    }
    curl_close($ch);
    return $result;
}

$ret = OAuthconsumerRequest('GET', 'http://api.gu3.jp/v1/test/auth');
print($ret);

先日、モバイルSNS「gumi」が日本初となる携帯電話向けOpenSocialプラットフォームをリリースしました。実は、私もOpenSocialエンジン部分の開発に企画段階から関わっています。もともと gumi は、id:perezvon が Django で構築したサイトで、 OpenSocial エンジンの部分も Python で書いています。今回リリースされた gumi Platform の特徴としてはこんな感じです。

• RESTful API ベースで JavaScript および IFRAME は使用しない（というか使えない）
• APIへのアクセス制御には OAuth を採用
• Viewer, Owner, Friends 情報を利用してソーシャル・アプリケーションを構築可能
• 文字コードは UTF-8 を使用
• 絵文字はドコモのUnicodeテキスト形式で記述し、他キャリア向けに自動変換
• ホスティング環境として Google App Engine も利用可能（当然それ以外もOK）

下の画像を見てもらえれば、仕組みはイメージしてもらえると思いますが、携帯電話なので JavaScript が使えません。そこで、サードパーティ側から受け取った XML を gumi Platform 側で一枚の HTML にレンダリングして携帯電話に返すような構成になっています。

詳しくは、 Google Code にドキュメントがあるのでそちらを参照してください。

» gumi - Google Code

gumi Platformのリリースと前後して、2つほど検定/占い系のアプリも公開したのですが、一気にアクセスが来て大変な事になりました。やはりまだまだ世間はケータイなんだと実感しました。私も発売日に iPhone を手に入れたくちなのですが、使い勝手や安定性の点からいうと日本の携帯電話に一日の長がある感じがします。今は少し落ち着いたのですが、 Google App Engine のコンソールで見るとこんな感じです。

実際にソーシャルなアプリケーションを作ろうとすると、 OAuth の部分とかがかなり面倒くさいです。そこで、 Python 用には自動で OAuth 認証をして gumi API にアクセスするようなヘルパーライブラリを用意しています。他の言語用にも同様のライブラリも用意したいのですが、諸般の事情により今はそこまで手が回りません。

一番欲しいのはPHP用のライブラリなのですが。うーん、誰か作ってくれないかな…

Google Developer Day の午後はオープンソーシャル・コードラボに参加しました。コードラボとは何かというと、何人ずつかのチームに分かれてテーマを決めて開発をするものです。あるいはHackathonといったほうが分かりやすいかもしれませんが、Google社内でもこのような形式で定期的に行われているそうです。今回は事前申し込みが必要だったのですが、だいたい30名くらいの方が参加していました。

まずはじめに、Chris Schalk氏から OpenSocial についての概要説明がありました。今思うと、なかなか直接質問できるチャンスはないので、ここでいろいろ細かいことを聞いておけばよかったと後悔しています。

Tender Surrender のえーじさんと二人でチームを組んで、MyBlogLog のような「あしあと＋ともだちリコメンド」アプリを作ることになりました。えーじさんがガジェットを作って、僕がサーバサイドをGoogle App Engineで作るという役割分担。

ちょうどこの一週間前に OpenSocial 0.8 の仕様が公開されたのですが、現時点で実装しているコンテナはなく、0.7ベースで進めていくことになりました。最初は Orkut の Sandbox を使って開発していたのですが、どうもキャッシュし過ぎ問題（サーバ負荷を減らすために積極的にXMLをキャッシュしている）に悩まされて途中から Partuza! という Chris Chabot さんが公開されているオープンソーシャル・エンジンを利用しました。

そして、最期に各チームの成果発表会が行われました。結局、いろいろと想定外のトラブルが発生して2時間の時間内に完成させることはできませんでした。やはり事前準備が重要という感じがしました。くりすさん達の友達にタグ付けをするアプリとか、 aodag さんのフィードを集約するものとか、ユーザのプロフィール情報からカバラ占いをするというアプリの完成度が高かったです。

今回かなり楽しかったので、機会があったらぜひまた参加したいです。現時点で、 OpenSocial は日本では今ひとつ盛り上がりに欠ける感がありますが、サンフランシスコでの Google I/O ではかなりの注目を集めていました。これからのインターネットを考える上で一つのキーになる技術だと思いますので、今後も引き続きウォッチして行きたいと思います。

関連リンク：
» Google Developer Day 2008 Japan レポート (でぃべろっぱーず・さいど)
» CEO Blog » Blog Archive » Google Developer Day 2008 Android Hack-a-Thon
» "電脳網潜水" （"ネットダイブ" NetDive）: Android のハッカーソン
» Google App Engine コード ラボ （Hackathon）レポート － IT+

OpenSocial の RESTful API では、OAuth を利用して権限の確認を行います。ただし、コンシューマが完全にユーザに成り代わって処理をするため、コンシューマとプロバイダ二者間の信任フロー（2-legged OAuth）になります。この方法については、まだドラフト段階ですが次の文書に記されています。

» OAuth Consumer Request 1.0 Draft 1

処理フローを以下に説明します。コンシューマは次のパラメータをプロバイダに送信することになります。

ここで、 oauth_signature は以下のようにして生成されます。まず、ベース文字列を生成するために次の値を用意します。

1. GET
2. http://provider.example.net/profile
3. oauth_consumer_key=dpf43f3p2l4k3l03&oauth_nonce=kllo9940pd9333jh&oauth_signature_method=HMAC-SHA1&oauth_timestamp=1191242096&oauth_version=1.0

これらをURIエスケープした後に & で連結して、ベース文字列を生成します。

GET&http%3A%2F%2Fprovider.example.net%2Fprofile&oauth_consumer_key%3D
dpf43f3p2l4k3l03%26oauth_nonce%3Dkllo9940pd9333jh%26oauth_signature_method
%3DHMAC-SHA1%26oauth_timestamp%3D1191242096%26oauth_version%3D1.0

そして、このベース文字列を HMAC-SHA1 によってダイジェスト値を生成し、BASE64 でエンコードすることによってシグニチャが生成されます。この際、利用する共有キーは cosumer_secret　と 空のToken Secret を & で連結したものになります。例えば、 consumer_secret が kd94hf93k423kf44 なら kd94hf93k423kf44& になります（Token Secretは空のため）。こうして、ダイジェスト値は以下のようになります。

SGtGiOrgTGF5Dd4RUMguopweOSU=

こうして生成されたパラメータをリクエスト時の Authorization ヘッダに付加します。プロバイダ側でも同様にダイジェスト値を生成し、シグニチャが合っていればプロバイダが持つリソースへのアクセスを許可します。また、タイムスタンプが5分以上前の場合にはエラーとすることで、リクエストURLが漏れた場合でもセキュリティを確保しています。

Authorization: OAuth realm="http://provider.example.net/",
               oauth_consumer_key="dpf43f3p2l4k3l03",
               oauth_signature_method="HMAC-SHA1",
               oauth_signature="SGtGiOrgTGF5Dd4RUMguopweOSU%3D",
               oauth_timestamp="1191242096",
               oauth_nonce="kllo9940pd9333jh",
               oauth_version="1.0"

さて、以上の処理を Django で実装してみました。コンシューマ側は、普通のPythonスクリプトですので、コンソールから実行することができます。

プロバイダ側

import oauth
from django.shortcuts import *

class MockOAuthDataStore(oauth.OAuthDataStore):
    def __init__(self):
        self.consumer = oauth.OAuthConsumer('key', 'secret')
        self.nonce = 'nonce'

    def lookup_consumer(self, key):
        if key == self.consumer.key:
            return self.consumer
        return None

    def lookup_nonce(self, oauth_consumer, oauth_token, nonce):
        return None

def auth_test(req):
    os = oauth.OAuthServer(MockOAuthDataStore())
    os.add_signature_method(oauth.OAuthSignatureMethod_HMAC_SHA1())

    # build from request
    base_url = req.is_secure() and 'https://' or 'http://' + req.get_host()
    try:
        os.oauth_request = oauth.OAuthRequest.from_request(
            req.method,
            base_url + req.path,
            headers={'Authorization': req.META.get('HTTP_AUTHORIZATION')},
        )

        consumer, token, params = os.verify_request(os.oauth_request)
    except oauth.OAuthError, err:
        return HttpResponse(err.message, status=401)

    return HttpResponse('OK!')

コンシューマ側

import oauth
import urllib2

CONSUMER_KEY = 'key'
CONSUMER_SECRET = 'secret'

def oauth_request(method, url, parameters=None):
    consumer = oauth.OAuthConsumer(CONSUMER_KEY, CONSUMER_SECRET)
    signature_method_hmac_sha1 = oauth.OAuthSignatureMethod_HMAC_SHA1()

    # access protected resources
    oauth_request = oauth.OAuthRequest.from_consumer_and_token(
	                consumer,
			token=None,
			http_method=method,

			http_url=url,
			parameters=parameters)
    oauth_request.sign_request(signature_method_hmac_sha1, consumer, '')

    headers = oauth_request.to_header()
    
    r = urllib2.Request(url, headers=headers)

    try:
        print urllib2.urlopen(r).read()
    except urllib2.HTTPError, e:
        print e

if __name__ == '__main__':
  oauth_request('GET', 'http://localhost:8080/auth_test/')

Leah Culverさんが書いたOAuthライブラリを利用しているのですが、空の Token だとエラーになるので、一箇所だけソースに手を加えています。

--- oauth.py.org   2008-06-14 11:52:33.000000000 +0900
+++ oauth.py       2008-06-14 12:01:44.000000000 +0900
@@ -311,7 +311,10 @@
         version = self._get_version(oauth_request)
         consumer = self._get_consumer(oauth_request)
         # get the access token
-        token = self._get_token(oauth_request, 'access')
+        try:
+            token = self._get_token(oauth_request, 'access')
+        except:
+            token = ''
         self._check_signature(oauth_request, consumer, token)
         parameters = oauth_request.get_nonoauth_parameters()
         return consumer, token, parameters

6月10日にパシフィコ横浜で開催された「Google Developer Day 2008」に参加してきました。

基調講演は、Google Japan 村上社長の挨拶の後、サンフランシスコの Google I/O でご一緒させてもらった及川さんが登場。現在の状況とこれからどこに進もうとしているかを説明してくれました。内容は基本的に Google I/O での Keynote の資料を翻訳したものだったのですが、 Google らしいカジュアルな感じでとても分かりやすいものだったと思います。

• インターネットは生活にかかせないものになっている。
• クラウド・コンピューティング
  コンピューティングの場は過去にメインフレームからPCに移ったが、再びインターネット上に集約されつつある。
• Google流のエコシステム
  リッチなアプリ→ユーザー増→頻度増→収益向上(ウェブ開発者を巻き込む)

Android

Android のデモが Google I/O の時よりもパワーアップしていました。あちらでストリートビューのデモを行ったときは、会場から「おー！」という感嘆の声が上がったのですが、日本での反応は静かなものでした。皆さん、既にI/Oのビデオを見て知っていたからなんですかね…

• オープンソース（※まだソースは公開されていませんが予定）
• Webkit ベースブラウザで JavaScript, CSSは当たり前
• スライドとガジェット、ドラッグダウンによるインタフェース
• インターネットとのマッシュアップが可能
• 顔認識でコンタクトの写真を登録できる

Google App Engine

Google I/O でお世話になった鵜飼さんによる Google App Engine の紹介。こちらもI/Oでのプレゼンがベースのようでした。今までは、 Linux の設定をして、Apache の設定をして、 MySQL の設定をして、 PHP の設定をしてというのが必要で、サービスが成長してきたらサーバの台数を増やして負荷分散をしてという作業が必要でした。それが、Google のインフラを使うことで心配する必要がなくなります。そして、アカウント制限が撤廃され誰でも利用可能になったことと、今後予定されている新機能の説明がありました。登録フリーになったとは言っても、携帯電話 SMS での認証が必要で、現状日本ではほぼ登録不可能といっていい状態です。こちらは早急に改善して欲しいところ。
今後予定されている機能追加は次の通り。

• Offline Processing （スケジュールタスクなど）
• More Language （Python 以外の言語への対応）
• Rich Media Support （1MB以上の Large Object 対応）
• Additional Infrastructure Services

OpenSocial

OpenSocial は、昨年の発表から7ヶ月でユーザー 2億7500万、開発者 2万、アプリケーション数 5000万に成長中。国内での適用事例として、リクルートの方が「ドコイク？」を OpenSocial 対応したという話をされていました。現在は、自由にアプリケーションを登録できないが、将来的には対応したいとのことです。また、 OpenSocial に対する要望として、セキュリティの向上と仕様の明確化を進めて欲しいと言っていて、確かにそうだなと思いました。

Community

今回の全体テーマとして「Cloud, Connectivity, Client」を掲げていたのですが、某社のプレゼンに習って"One more thing."として「Community」を取り上げていました。 Google Japan のディベロッパー交流会への取り組みやエキスパート認定制度など。
下記のように日本語でのグループもできているので、興味のある方は参加してみるといいかもしれません。特に Google-App-Engine-Japan はこの日に開設されてホヤホヤなのでお勧めです。

• Google-App-Engine-Japan
• OpenSocial-Japan
• Android Developers Japan

少し話がそれましたが、知っている人も多く来ていて、初めて会った人とも多く名刺交換をさせてもらいました。実際に顔を合わせて話をするというのはとても重要で、Web系以外の人とも話をするとてもいい機会になりました。お話しさせていただいた皆さん、どうもありがとうございました。