BPStudy#33に参加しました

勉強会 gae

人のブログをみてしまったら、書けなくなるので（ajnは他の人の内容のレベルがすごすぎるので・・・）、スピード勝負です。
（おそらく）誰よりも早いBPStudy#33のブログ記事のはず（終わった直後にあげるので）。

BPStudy#33 第１部テーマ：Google I/O 2010 App Engineセッションレポート

第１部のMCは佐藤一憲さん（[twitter:@kazunori_279]）

以下は、自分のメモがきです。
@kazunori_279のブログみればすむって話もありますが。。。

資料

App Engineでcomet

  • これまでpushを行うには、XMPPプロトコルorURLFetchを用いて外部のpushサーバーとか使うしかなかった
  • でも、XMPPクライアントの実装は容易ではない（Flashとかだと通信ができない）
  • しかし、Channel API が登場したんでpushできる！（これまで大変だったが、基本cometなのでFlashとかからでも通信できるはず-google談）
  • Channel APIは、チャネル型の双方向非同期通信サービス
    • sdkは手に入るけど、現状ではRPCの制限がかかっているのでprodにあげても動作はしない（@shin1ogawa情報）
  • GTalkサーバーのインフラを使っているので、スケーラビリティはきわめて高い
  • つまりは、鬼スケーラブルなメッセージングサービスがただで使えるのがメリット！
  • デメリットは、データセンターが北米にあるので、レインテンシが問題
    • 対戦型ゲームとかは厳しい
  • 現時点では、課金関連、SDKのリリース時期の情報は出ていない

Google Storageとあわせて発表されたBigQuery

  • 何100億件のデータも数秒〜数10秒で集計できる、大規模並列クエリサービス
  • MapReduceとは違い、SQLっぽいクエリ言語で表現できる集計処理しか実行できない
  • Google StorageとBigTableとは互換性がない（と思われる）ので、BigQueryでBigTableのデータを検索できるわけではない
    • App Engineとは別プロダクト
    • BIの世界にもクラウドによる価格破壊がくるかも

感想

  • BigQueryは最初すごいと思ったけど、個人が趣味で使うって感じではなさそうな印象
  • Channel APIはアイディアによってはすごいものがつくれそうなので、腕に覚えがある人はHTML5とjavascriptを勉強して全裸待機しる。
  • データセンターを日本に設立するために、これまで以上に日本の盛り上がりを世界に伝える努力が必要かな

BPStudy#33 第２部のテーマ：Slim3がすごいトコ

第２部のMCは小川信一さん（[twitter:@shin1ogawa]）

以下は、自分のメモがきです。

資料

  • まだ見つけられてません

slim3とは

slim3を使いはじめる環境の構築

  1. slim3のサイトからブランクプロジェクトをダウンロード
  2. Eclipseからアーカイブファイルをインポート
  3. Aptの設定

slim3のいいところ

  • 単体テストのサポート
  • テスト環境を整えるユーティリティがある
    • Controller層のテストも簡単
    • データも消してくれるので、同じテストを何回も実行できる（これはすごい便利）
    • デモでは、low level apiを使っていたように、slim3のtestcaseはslim3に依存していない（はず）
  • Kotori Web JUnit Runner というプロダクション用のテストツールも使える

タイプセーフクエリ

  • アノテーションを使って、metaクラスを自動生成
  • フィルタの条件値も型チェック
    • 型を間違ってもエラーで教えてくれる
  • IDEの親和性が高いメソッドチェインによる記述

グローバルトランザクション

  • エンティティグループをまたいだ排他制御ができる
  • 最後の最後に使うというのがshin1ogawaさんのスタンス
    • もしかしたら自分の表現には語弊があるかも・・・設計段階では頼らない方がいい、って意図だと思う
    • 最初はない前提で設計をすすめて、開発の最後の方に設計レベルで対応できない時につかう伝家の宝刀（？）

高いパフォーマンス

  • APTによってコンパイル済み状態のメタ情報を使う。リフレクションは使わない
  • 内部的にプロトコルバッファ（いわゆるバイトコードの世界）を使うところまでチューニング
    • 大量の涙ぐましい努力（ギリギリのチューニング）
    • ライブコーディングでmakeSyncCallの紹介もあり！
    • ライブコーディングでジャーナルのパフォーマンスチューニングも紹介！

気がきいた仕組み

  • 自動リトライがある
    • GAEでは、エラーはさけられないのでリトライ必要
  • スキーマバージョンがある
  • 楽観的排他制御用のバージョン
    • スキーマバージョンも含めた排他制御をやってくれる（getのときにversionをチェックして例外をなげてくれる）
  • deleteAll（key ancestor）
    • エンティティグループにひもづくすべてのデータを消してくれる
    • 使う機会は少ないけど、いざ必要となった時にはとても助かる
  • controllerのヘルパーメソッドがすごい便利（セッションとかとか）

Kotori Web JUnit Runner

感想

  • 今日も神コーディング堪能しますた（幸せな気持ちになれます。完全にファンですな）
  • 説明とコードの紹介がセットになっていたので、とてもイメージしやすかった