先日のDeNA Technology Seminarの資料を公開しました

先日、開催された DeNA Technology Seminar #1で「Inside mixi Platform」と題して、mixi Platform(主にモバイル版mixiアプリ)の裏側がどうなっているかという話をさせて頂きました。その時に使った資料を公開します。

あっという間に定員80名が埋まってしまったようで、参加したいけどできなかった方の参考になれば幸いです:-) 自分としてもZIGOROuさん、hidekさんの話を聞いて大変参考になりました。
どうもありがとうございました。

関連リンク:
OpenSocial Blog: Japan's mixi adds mobile support with its OpenSocial RESTful API
リリース | Weboo! Returns.

リリース

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

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

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

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

OpenSocial Signed Request を Google App Engine で検証する

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

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

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

これらを 次のように 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(日本語訳)

「チャンネー」という OpenSocial アプリを作りました

先日、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にアクセスする必要があります。既に多くのアーリーアダプタな方々が参加されているので、私のブログを読んでくれているような人たちはもう利用されているかもしれませんが、以下の手順に従ってアプリを登録してください。

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

mixiアプリ オープンβ

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

2.アプリページにアクセス

チャンネー

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

3.アプリを追加する

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


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

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

Google Blogで紹介して頂きました

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

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

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

Google Friend Connectが利用可能になりました

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

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

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


PHP で OAuth Consumer Request (2-legged OAuth)

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

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

» OAuth Consumer Request 1.0 Draft 1

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

oauth_consumer_keyコンシューマキー
oauth_signature_methodHMAC-SHA1 or RSA-SHA1
oauth_signatureシグニチャ
oauth_timestampUNIXタイムスタンプ
oauth_nonceランダムな文字列
oauth_version1.0 (オプション)

ここで、 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);

ケータイ向け OpenSocial プラットフォーム「gumi Platform」

先日、モバイル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用のライブラリなのですが。うーん、誰か作ってくれないかな…

OAuth Consumer Request の処理フローと実装

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

» OAuth Consumer Request 1.0 Draft 1

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

oauth_consumer_keyコンシューマキー
oauth_signature_methodHMAC-SHA1
oauth_signatureシグニチャ
oauth_timestampUNIXタイムスタンプ
oauth_nonceランダムな文字列
oauth_version1.0 (オプション)

ここで、 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

Google I/O 第2日目

Google I/O の第2日目は,特に集合したりはせず,一人で会場に行って朝食を取りました。下の写真のようなビュッフェ形式の朝食でなかなか美味しかったです。

Google I/O Lobby  Breakfast

ここで,たまたま隣に座った人と話をしたのですが,彼はサンフランシスコのエンジニアで,これから OpenSocial 関連のプロジェクトを立ち上げたいと言っていました。また,JavaScript に関して,僕は jQuery がお気に入りだという話をしたのですが,彼は jQuery を知らないようで,「何だそれ。何がいいんだ?僕はDojoを使っているよ。」と言っていました。jQuery のすばらしい点を説明しておいたんだけど,うまく伝わったかなぁ…
他に何人かと話した感じでは,日本ではあまり話題に上らない OpenSocial の動向について,こちらでは多くの人が注目しているようです。それと LinkedIn の評価が高いようで,彼らはスマートだと口々に言っていました。

Marissa Mayer
Keynote from Marissa Mayer at Google I/O 2008
Photo by jwowens

この日のキーノートは,副社長の Marissa Mayer さんでした。とても美しい女性で鵜飼さんによると,新しいプロダクトは必ずこの人の承認を受けなければならないとか。彼女については,a2cさんがブログにまとめているので参考にしてください。全く持って同感です!「マリッサは大変なものを盗んでいきました」 後から聞いたら,自分と同い年だそうで,軽くショックを受けました。

少しだけ僕が分かった範囲で補足しておくと,Google Products の UI について語っていました。"Split A/B Testing"の手法を使って,ユーザごとに微妙に異なるデザインのページを表示して変化を調べているそうです。サンプルとして挙げていた検索結果ページのデザインの場合だと,微妙にロゴの周りのスペースが違うだけなのですが,このレベルでテストを行っているようです。また,検索トップページを作ったのはセルゲイ・ブリンで,彼に聞いたら "We didn't have a Webmaster, and I don't do HTML." (参考)と答えたそうです。会場は爆笑。

Even Faster Web Sites by Steve Souders

Steve Souders

キーノートの後は,『ハイパフォーマンスWebサイト』の著者で,YSlow を作った Steve Souders のセッションを聞きました。なるほど,この人,Yahoo! から Google に転職してたんですね。会場に対する「みんな YSlow を使っているかい?」との問いかけに,20%くらいの人しか手をあげていなかったのが意外でした。 YSlow は全人類が使うべきだと思います。

内容については,箇条書きで申し訳ないですが,次のような感じでした。 Facebook を名指しでパフォーマンスが悪いサイトの例に出していたのに驚きました。さすがアメリカ。

  • iGoogle ではほとんどページのレンダリングに時間がかかっている
  • empty cache と prime cache の違いを知る
  • Google と LiveSearch は 0% になる
  • 80-90% はフロントエンドにかかっている
  • Facebook はほとんどスクリプトの読み込み。ひどい
  • JavaScript のブロックを回避することが重要
  • cuzillion ← Webページ構造によるパフォーマンス・テストツール。これ面白い!
  • スクリプトはレンダリングに必要なものとそれ以外を分けるべき
  • MSN はスクリプトを動的に挿入してパラレル読み込みを実現している
  • evalよりscript挿入の方がいいよ
  • <script defer> IE only, different domain
  • document.write only IE パラレル
  • パフォーマンス測定には IBM Page Detaierを使っていた
  • 実行順序とインジケーターで切り分けを行う
  • don't scatter inline scripts

OpenSocial

OpenSocial に関するセッションも slide.com の人のプレゼンなどいくつか聞いたのですが,残念ながら,あまりピンと来るものはありませんでした。一応,こちらもメモ程度のものをあげておきます。以前からブログを読ませて頂いていたえーじさんと,こちらで初めて会うことができた(Twitterのおかげ)のですが,やっぱり目新しい情報はあまり無かったと言っていました。OpenSocial に対する日本とは違った盛り上がり方を肌で感じることができたのが一番の収穫かなと思います。

  • lane liabraaten's opensocial - appengine
  • save users from re-registration hell
  • ユーザは,どのSNSにするか選ぶ必要がない
  • 適用範囲はSNSだけじゃないよ
    • profiles,homepage
    • personal dashbords
    • site based social object
    • corporate CRM systems
    • aay web site
  • profile pages - owner,
    home pages - owner is viewer (must be logged in)
    のパターンで表現できる
  • viewer friends are your firend to visit the web site
  • 言語には依存しない Pythonも歓迎
  • socialsite by SUN (powered by shindig)
  • Orkut, Myspace, hi5, Netlog open to 200M useres now
  • container to containerの通信はRESTful APIで実現可能になる

発表の中にFacebookの話題が全く出てこなくて,質問タイムに誰かが「Facebook?」と質問していたのですが,スピーカーの人の答えは「Next questions.」のみ。これには会場の皆も苦笑い。後から少し補足はしていましたが。
Plaxo の Joseph Smarr 氏のプレゼンは,別のを聞きに行っていて見逃しました。えーじさんによると,これは面白かったそう。残念ですが,a2cさんのブログに YouTube とスライドのリンクがあるので,後で見ようと思います。

# MySQL のことをみんな「マイシーケル」って呼んでいた。