Google Developer Day 2009に行ってきた

去年に引き続き、今年もいってきました。パシフィコ横浜。

今年は募集が２週間で締め切りになるほどの盛況ぶりだったそうです。

最近、こういった勉強会系イベントは発表と同時に申し込むぐらいの気合いがないと参加できなくなってきましたね。

基調講演

世界中でGDD(Google Developer Day)をやっているけど、日本は中国に次いで２番目の規模。
- （って中国が１番なんだ。やはり勢いすごいなぁ。）

HTML5についていろいろ。
- 本日の主力テーマの１つ。
- 対応ブラウザが広まればプラグイン、たとえばflash無しでもいろいろできるようになるとか。
- (今までできたことがそのままできるだけじゃ、あんまユーザーメリットは無いような気もするけど、今後生まれるサービス次第なんだろうな。)
- 「よりネイティブアプリケーションのように」がテーマらしい
- 「Googleは標準化への活動を進めていくよ」とのこと

アンドロイドについて
- いよいよdocomoからアンドロイド携帯(HT-03A)でます。
- ここでサプライズ。なんと会場の皆様にプレゼント！太っ腹！
  - SIMがないから電話はできないけどね。ほかはみんな動く。wi-fiも。
- (頼むからアプリ開発を宜しくお願いします。とのメッセージと受け取りました。)

送信者 2009/06/09 GDD2009

オープンソーシャルについて
mixiもオープンソーシャル使っているらしい。
- mixiの社長がでてきた。
- mixiはPCより携帯のアクセスのほうが多い
- mixiアプリ、明日から開発者バージョンリリース。
- 日本最大のSNSで使えるよ
- PCとモバイルの同時展開は世界初
- ソーシャルアプリケーションプロバイダー向けビジネス支援プログラム
  - アドプログラム
  - mixiファンド
  - mixiペイメント
- アイディアで勝負できるフラットなマーケット、らしい。
- (だれでも参加しやすい分野ってすぐ追いつかれちゃうから、やる気は起きないなぁ。)
- (ベンチャー魂が溢れてて生涯走り続ける性格の持ち主には向いてるだろうな。)
- オープンソーシャルってやつはデバッグとか大変らしい。
  - たとえば本番環境でmixiアプリをデバッグしたらやばいよね
- eclipseをつかった開発環境がフリーであるよ
  - OSDE(Open Social Development Environment)

Google Waveについて
- HTML5で書かれたアプリケーション
- チャットとメールが合体したような感じ
  - テキストも画像も動画も共有可能
- (なんかいままでできたことをまとめただけのソフトのような。)
- (一般人には使いこなせない匂いがむんむんでした。)
- (こんなんに力いれはじめちゃったのか。なんかMSな香り。)

AdWords API now & then

会社でAdwordsに広告出してることもあって行ってみた。

案の定、他の華のあるコーナーと違って人が少ない。

写真はこちらから

http://picasaweb.google.co.jp/shikaku.g/GDD2009AdwordsAPI?feat=directlink

AdWords APIについて
- AdWordsを操作するためのAPI
- SOAPプロトコルを用いるwebサービス
AdWordsとは
- 広告配信するためのシステムの１つ
- 広告主様向けのシステム

広告主様が入札方式で広告を掲載
広告ランクが高いほど表示される
広告ランク　＝品質スコア　X　上限クリック単価
- 上限クリック単価
  - 入札金額が高いと上
- 品質スコアというのがある
  - 検索に置けるクリック率
  - キーワードと広告テキストの関連性

ページのテーマになるべくあった広告を出すようにしているよ

広告の出る場所
- サイト運営者
- 検索結果
- 検索パートナー
- GoogleMaps
- RSSフィード
- GMail

AdWordsシステムへのアクセス手段
- Adwords管理画面
  - Web UI
- AdWordsEiditer
  - 広告の投稿をしたりする
  - Adwords管理画面より高機能。
  - 実はAdWords APIで構築されている
- カスタムプラットフォーム
  - AdWords APIを使ったオリジナルのシステムのこと
  - 今回のテーマ！

AdWords APIの利用イメージ
- 人材派遣会社の場合
  - 人材が入ったら、その人材データを社内DBにUP
  - その社内DBのデータをみて、こんな人材いるよーとAdwordsAPIを使って広告を出す
  - 人材が売れたら、AdwordsAPI使って広告を削除する
  - 上記をリアルタイムに行うシステムが作れるよ！
- オンラインの小売時業者
  - 在庫DB参照して在庫切れで自動的に広告を止める
  - 在庫DB参照して季節のイベントごとに最適な商品を広告
  - 自動入稿管理環境の整備して自動入札することができる
- レポートの自動化
  - AdWordsAPI経由でレポートを自動取得
  - 広告結果をAPIを利用してオリジナルレポートを作成することも可能

技術情報
v13 API 情報
- Google Codeにあるよ
- 現在の最新バージョン
- SOAP
  - 要はXMLです
  - プログラム言語非依存
APIでできること
- 入札管理系
- レポート生成系
- 見積もり関連ツール系

v2009 API docs
- v13の次バージョン
- Google Codeにあるよ
- コードサンプルもあるよ
  - java
  - php
  - perl

APIユニットという単位がある
- APIの世界でのクレジット（お金）
- API呼び出すとお金かかる！！
  - 開発環境としてSandboxがあります
  - ここの中なら無償です

次バージョン情報
- v13
  - AdWords EditerもAPIで作ってました
  - Editerで入稿したものとWeb UIで入稿したものはシステムが違っていた
- v2009
  - すべてCommon layerを経由することになったよ
  - １回の呼び出しで多くの処理を行うための改善
  - 非同期オペレーション
  - バルク処理時のエラー対応を柔軟可
  - １つでもエラーあると、全部ロールバックしていた
  - エラー以外は入稿できるようにした

すぐ試したい人へ
Adwors APIのドキュメントのブログにApp Engine(python)から使うサンプルがあるよ

Google Chrome(クロム)の内部構造

写真はこちら

http://picasaweb.google.co.jp/shikaku.g/GDD2009GoogleChrome#

Chrome
- webの進化に会わせて進化させていく

設計思想
- 高速
- 安定
- 安全
- (あたりまえって言えば当たり前の設計思想だなぁ)

マルチプロセスアーキテクチャ
- 機能を分割し各機能にプロセスを割当てる
- (タスクマネージャ見るとchrome.exeがいっぱいでるらしい)

ブラウザプロセス
- 起動して開くウインドウを制御している
- マウス
- ウィンドウ
- ネットワーク
- ローカルリソースにアクセスする

描画プロセス
- ページの描画
- ローカルリソースへのアクセスできない

詳細

原則
- タブ１つについて、１プロセス
  - 違うドメインへのページ移動の際に、プロセスを破棄し新しく作り直す
  - (このほうがメモリ断片化対策的にもよいらしい)
例外
- 複数タブで１個の描画プロセス
- Javascriptのリソースを共有
- ポップアップ
- 最大プロセス数制限に到達
- ドメイン間でリソース依存可能性がある場合

プラグインプロセス
- ローカルリソースへのアクセス化
- ほんとはアクセスしたくないんだけど
- FlashとかActiveXとかが使うので

ワーカープロセス（開発中）
- HTML5のWeb Worker実行
- スレッド立ち上げたりするのです
- ローカルリソースへのアクセス不可

拡張機能プロセス（開発中）
- ローカルリソースへのアクセス不可
- プロセス間通信
- プロセス間通信専用スレッドを実装
- プロセス間通信の種類
  - 名前付きパイプ（非同期）
  - 入出力イベント
  - 描画イベント
- 名前付きパイプ（同期）
  - ウインドウ作成
- 共有メモリ
  - 描画結果転送
  - サムネイル転送

ロードマップ
- ver1.0と2.0ではネットワーク周り書き換えた
- 1.0
  - windowsべったり
  - WinINET(WinHTTP)を利用
- 2.0
  - HTTP:new HTTP
  - FTP:Portable FTP

開発中
- 対応プロトコルの追加
  - クライアント証明書
  - socksなど
- 高速化

サンドボックス
- 発想
  - いくら頑張っても乗っ取られるよ
  - のっとられること前提で作ろう
- 正体はライブラリ
- (Chromeのコードは必ずこのサンドボックスライブラリを使用してローカルリソースにアクセスするらしい）
- ローカルリソースへのアクセス権を制限
  - ファイル
  - ウインドウ
  - 入出力ウインドウ
- Untrusted processのIntegrity LavelをLowにする（Vista以降）
  - IE7,8でもやっている
- クラックしてくる人はまずwebkitを乗っ取ってくる
- でもサンドボックスはwebkitより下階層なので、webkit乗っ取ってもローカルリソースにはアクセスできないのだー

webkit
- 採用理由
  - シンプル！
  - 軽い
  - Androidでもつかえるくらいだもの

weblitへのGoogleの貢献
- 1.0
  - safari3で使っている物とほぼ同じ
- 2.0
  - wibkitの開発に直接参加
  - ３人のreviewers
  - 10人以上のcommiters
  - safari4とほぼ同じ
- 現在
  - Webkitの開発に積極的に参加
  - 設計段階から参加してた方が得と判断
- 新機能の実装
  - HTML5
  - CSS3
  - etc...
- 互換性の向上
- 高速化

V８について
- javascriptコードはどんどんでかくなるだろう
- 高速javascriptエンジン
- オープンソース（BSD）
  - 単独で利用可能
- ０から設計したので、やりたいことはなんでもつっこんだ

ガーベジコレクション
- ２つの区分け
  - ヤングジェネレーション
  - オールドジェネレーション
- 世代別ガーベジコレクション

ロードマップ
- 1.0
  - V8リリース
- 2.0
  - 新正規表現ライブラリ
  - レジスタ割当の改良
  - JSONオブジェクトの高速化
- 開発中
  - 頻繁に使われるコードの高速化
  - グローバルオブジェクトへの高速アクセス

ChromeとHTML５の関係
- 実装中
- safariでいけるのにChromeでできないことがあるのはなぜか
  - サンドボックスがあるから

課題
- サンドボックス
  - 描画プロセスはファイルへのアクセス不可だしー
- 拡張機能
  - HTML+CSS+Javascriptで作る
- グリースモンキーにあたるものも作ってます
  - ユーザースクリプト

Chrominumプロジェクト
- Chrominumに対する変更はGoogle Chromeに反映
- Chromiumのほうが更新頻度高い
- メタツリーという概念
  - 他モジュールのバージョン指定してツリー管理

開発ツール
- コードレビューシステム
- buildbot
  - 自動ビルド

送信者 GDD2009 GoogleChromeの内部構造

コードはテスト用データが圧倒的に多い
- (これはすごい！ものすごいテストに力が入っているんだなぁ)

質問コーナー
- testはどのようにやっているの？
  - レンダリングテスト
  - レンダリングパフォーマンステスト
  - UI操作テスト
- なるべくテストを入れていくようにしている
  - デグレはなんとしても防止したい
  - なるべく自動化する
  - （すばらしいな。真似しよう）
- テスト用の人はどれだけいるの？
  - テスト用のチームはいるけど
  - オープンソースのボランティアもいるし、正確に何人かは不明。
- メモリ容量が少ない環境への移植はどこまで考えている？
  - 具体的には考えてない
  - ぼんやりとは思っているけど

OpenSocialアドバンス

写真はこちら

http://picasaweb.google.co.jp/shikaku.g/GDD2009OpenSocial?feat=directlink

英語だったし専門外だったし話が速かったので、メモ不足。

大きなトラフィックが必要な世界では、ほんの数KBけずることが、こんなにコストに影響があるとは知らなかったなぁ。

そんなでかいサイト扱うことはないだろうけど。

画像をスプライトするってテクも新鮮だった。

- - -
eCPM
- 1000に対してどれだけ利益が有るか
- ソーシャルアプリケーションはこれが低い
ソーシャルネットワークは口コミで広がる
短期間で多くの人がアプリケーションにアクセスする可能性がある
なぜパフォーマンスを考えるのが重要なのか
レイテンシーの改善は重要だ
500ms表示が遅くなると20%の通信トラフィックを失うと言われている
- アマゾンも0.1秒増えると、利益1%失う
- Google mapから-30KB削減するとで30%成長できる

戦略
- ナイーブなバージョン
- 最適化したバージョン
- ホスティングコスト

計測ツール
YSlow!
- Firefoxアドオン
- Yahooを基準に値出すみたい
Web Inspector
- 読み込んだファイルサイズが視覚化される
Firebugs
- Firefoxアドオン

ページを軽くする方法
- JavaScriptの空白、改行を取り除く
  - これだけで55%もサイズ削減
- 画像をスプライトする
  - ゲームみたいに全部を１枚の絵にしてしまう
  - それをCSSで切り出して表示
  - パレットの数も減らすといい
- キャッシュヘッダを減らそう
  - アパッチならこんな感じ
  - cache-control "max-age=290904000 , public"
- CSSを最初に、JavaScriptを最後に
- batchingという手法があるよ
  - バッチね
  - リクエストやAPI呼び出しをまとめてバッチ実行するとリクエストの数が減らせる