基調講演は飛ばして午後から参加．android携帯もらえました．これが目的と言っても過言ではない．
##App Engine
- Fred Sauer @fredsa
いかに scale out するかということについて，データベース的な話
list properties
- storage overhead を回避するために使う(?)
- CPU を使う -> serializing/desirializing
- order はプロパティが1つだけの時に使える
- ex) Microblogging
- 要するに twitter
- Fan-out
- 投稿が他の人の timeline に現れるってことか？
- RDBMS なら JOIN する
- Google App Engine なら
- list properties を使う
- Bigtable で分散されている
- linear に scale するらしい
- 5000 indexed properties per entity
- ストレージ的にはRDBMSと同程度
- それで scale するならすごいな
- CPU cost 削減のために(serialization)
- 一般的な RDBMS のように，本文などのデータと，replatinship のみのインデックスデータに分割する
- MessageIndex から KEY のみを取得して，k.parent() で Message の key を生成することで，CPU cost を削減できる
- write は同程度， read は 10x 程度
- low CPU/storage cost
- million-fan-out problem への解(like twitter)
Merge-join
- ベン図の重なり合っているところを取得するイメージ
- 例としては， Gmail の query
- 全ての property が indexed
- リアルタイム merge-sort する
- Zig-Zag Algorithm
キーの検索時のアルゴリズム．マッチして候補の多い部分をあとから or あとで検索しなおす感じ
ex) Social graph
mixi graph のような感じ
RDBMS では inner join とか使うが，AppEngine では
list property なので，検索したい 2人 がその list に含まれていることが条件となり，GQL ならそれを 1 query で検索できる
Wrap-up
- list property と merge-join を使うと scale out するのではないかな
##O3D
- Safari on Mac でかなり高速に動作してた．
- Game できるぐらい高速
- JavaScriptなのでどこでも動く
- shader 使えるらしい．multipass rendering とか texture とかも．
- Immediate vs. Retained mode
- Immediate mode = DirectX などの毎フレーム描画
- Retained mode = 位置を変えるだけなど
- O3D は z-sort 等は native code を使ってる
- Assets(いわゆる素材) + Codes(プログラム)
基本的に，JavaScriptで書ける．当たり前と言えば当たり前だけど，そこは確かに有用そうだ．
- View Control に handler 使える
- onRender で per frame の処理を書く
- カメラの遅延追尾描画とかもお手の物．
- 3D オブジェクトを読み込んで，それを描画可能
- アニメーション付きで描画もでき，motion に会わせた animation を切り替えなど
Javascript を使って 3D 表示を高速化する API
- 今風の 3D API と同じぐらいの構成で，同じようなことはできるらしい．
- よく見たら光源も反映してた．
- 3D のことをある程度理解していると，かなりお手軽にプログラムできるし，しかも高速に動作するのは素晴らしい．
Windows は DirectX & OpenGL で，MacOS は OpenGL に対応
##Google Web Toolkit(GWT) : Best Practices
- MVP(Model/Presenter/View)
- DI(Dependency Injection)
- RPC Service を使った Java App で，GWT を使うことによる利点の紹介
- MVC ではなく MVP を使う．
- EventBus を経由することで Model との密結合を排除する
- Google Wave が GWT を使ってる
##OpenSocial パネルディスカッション
パネリスト
- OpenSocial でアプリ開発している人が結構いる
- 川岸＠mixiさん
- 川崎＠リクルートさん
- 北村＠NTTレゾナンドさん
- 及川＠Googleさん
テーマ
- ソーシャルWebとは
- mixiではmixiアプリなどを通じて展開中(？)(川岸さん)
- SocialGraphを元にして様々なサービスに生かしたい(北村さん)
- goo は SocialWebPortal
- 外部の Activity Feed を集約して SocialNet につなげることができる
- バイラルに広がっていくプラットフォーム．OpenSocialによって低コストに参入できる場所(川崎さん)
- SocialGraph は持ったもの勝ち(北村さん)
- なので，mixiから持ってきて，「あっちでも友達だからこっちでも友達だよね」をやれる．
- mixiのコアな部分はSocialGraphだけど，それを提供してエコシステムを作り出そうとしている(川岸さん)
- ソーシャル化を進めるに当たっての課題
- 日本ではコンテンツプロバイダーの確立したビジネスモデルがない(川崎さん)
- mixiアプリ30本宣言したので，社内は大変．社内啓蒙も含めてやっているが，回収できる見込みは不明．
- 試行錯誤中の模様
- mixiアプリ(川岸さん)
- マーケティングコストがかからないので，アイデアで勝負できるフラットなマーケット
- 広告支援(Ad)，課金プラットフォーム，運転資金支援がある．
- Goo Homeはポータルとしてトラフィックを上げるような，うまく強調できる関係がいいと思ってる(北村さん)
- ソーシャルとして生かすアイデア
- Activity streamをSocialNetを通じて広めていくような感じ(？)(北村さん)
- セグメントしたコミュニティに対して広告を提供をするようなシステムがいいのでは(川崎さん)
- 「個人消費型」から「人間関係消費型」への転換(川岸さん)
- 「EC -> ギフト」のような感じ
- 啓蒙活動について
- 自分がやっているコミュニティを通じて啓蒙して行ければ(北村さん)
- 日本で成功する事例が出てきて欲しいな(川崎さん)
- mixiとしてmixiアプリの支援をすることで，成功事例を作っていくのがいいのでは(川岸さん)
##Google Wave API PCのバッテリー切れにより，デジカメでスライドを撮影．
- 基本的にJavaScriptのみでコントロール．
- 外部サービスも Robot / Gadget を使って内部に取り込むことも可能．
- 簡単そうには見えた．
##おまけ
