Seasar Conference 2009 Springに行ってきた
SeasarConに行ってきました。
プレゼン聞きながらTwitter眺めたい!!イーモバイルが欲しくなってきた今日この頃。
自分用のメモ書きを残しておきます。
Slim3 on Google App Engine/Java
- BigTable = 老害かどうかのリトマス試験紙
- 年をとっているから老害なのではなく、新しいもの・経験のないものを使いにくい、と排除してしまうのが老害
- GAEでは既存のアプリ・フレームワークが使えない、制限が多い
- 使いにくい、使わないと判断してしまったら老害の可能性
- デメリットという代償を払うことで、アプリケーションがスケールするメリットを得られる
- 制限を楽しんで、乗っかることでHappyになれる
Slim3
TDDの話
- リファクタリングによって、設計を良くする、だけじゃなくて…
- Red(ストレス),Green(爽快感)の繰り返しによって、開発者のモチベーションと潜在能力を高める
- 開発のリズム重要
- 普段なら適当にコード書いて適当にテスト書いて…
- TDDでは目的を先にはっきりさせてから、短いサイクルでフィードバックを得る
- これの繰り返し
デモ
TDDがサポートされているということで、TDDで足し算アプリを作る様子がライブで見ることが出来ました。
個人的には、TDDってまだまだエッジの利いた技術者が集っている現場/プロジェクトでは当たり前に行われているけど、自分が属しているような労働集約型の典型的な現場ではまだまだ知られていない開発手法なので、これが浸透するにはどれくらいかかるんだろう、と余計なことに思いを巡らせてしまいました。
TDDは、あくまでも開発手法であって、品質を保証するものではないので品質テストはまた別途必要だよ、ってことがマネージャ陣に理解されてないと、
- テストするのにプログラム書くの?
- そのプログラムは品質保証されてるの?
- そのテストプログラムのテストはどうするの?
- テストプログラムを作るための工数はどうするの?
- お客さんに提出する成果物はプログラムじゃわからないよ
- テストケースがプログラムじゃレビュー時に本質が見えなくなるだろう
- etc...
なんて言われてしまうことが容易に想像できる。まずは理解させるところから始めないとなーとか思うと、めんどいなぁって思ってしまいました。
老害を説得するのに、無駄な労力を使うよりかは、そういうことに理解がある人・組織へ移った方が絶対早い。
Cubby in Action
Cubbyは興味があったけど、前回のセッションが見れなかったので今回は参加。
Actionの設計
- デフォルトのActionはほぼ何もしない
- 汎用的な機能を持つ既定クラスを設計する
- AbstractAction…ログや認証情報など
- AbstractAction
- AbstractPagerAction…ページング処理
- AbstractMobileAction
- とか
- AbstractAction
基本コンポーネントの拡張
秘密の機能コンバータ
- エンティティとパスのバインディング
後半
Cubby2.0の機能や特徴について
- Spring/Guice Integration
- POJO Action
- JUnit4
- Annotationベース
- Validation with Oval
- improvement of type conversion
実際のコードなどは後日公開されるセッション資料を参照。
45分で動かせるBuri/escafeFlow入門
セッション資料が公開されているので詳細はそちらへ。
BigTableとJDOの勝ちパターン
BigTableの話だけで終わってしまうかも。JDOは時間があれば。
BigTable Structure
- chubby
- 分散ロックサーバ
- キーの取得時にアクセスされ、ルートのTabletサーバのIPアドレスを取得し、そこからデータのある別のTabletサーバへ
- Tablet Server
- それぞれ分散されて存在
- Root Tablet
- MetaData Tablet
- そのデータがどこのTabletに属するか
- User Tablet
- データが存在するTablet
- データが増えると、Tabletそのものが分割される
- 各Tabletへ3回問い合わせされる
- 10ms位でアクセス
- memtable
- 最初Indexだけ読み込まれる
- キーをmemtableで検索して、なければGFSから読み込んでキャッシュする
- GFS
- SSTable(index, data),log
- ReadOnly
- ディスクに格納
- indexをmemtableにソートされた状態で保存する
- SSTable(index, data),log
- 書き込み
- ジャーナル(log)→メモリに書き込む→GFSへ書き込む
- メモリ上のデータが大きくなってくると、memtable→SSTableに書き込みを行い、logをクリアする
- マイナーコンパクション
- スケジューラでディスクに書き込む
- メジャーコンパクション
BigTableへのアクセス
- Read
- Write
- Delete
- 上は全てキーによるアクセス
- Scan
- Prefix Scan
- 先頭10バイトとか
- Range Scan
- From,To
- これらはキーがソートされているから可能
- Prefix:B
- A
- B1(Hit)
- B2(Hit)
- B3(Hit)
- C
- Range B,D
- A
- B(Hit)
- C(Hit)
- D(Hit)
- E
- Prefix Scan
- キーのイメージ
- Parent:aaa
- Parentの部分をkindと呼ぶ(RDBMSのTableのようなもの?)
- aaaがキー
- Parent:aaa/Child:bbb
- Parent:aaa/Child:bbb/GrandChild:ccc
- Parent:xxx
- Parent:xxx/Chile:yyy
- Parent:aaa
- キーの切り方をEntity Groupと呼ぶ
- BigTableはトランザクションはサポートしない
- 行へのアクセスをAtomicに保障する
- Scan時には一貫性は保障されない
- ログには親のキーのみ書き出す
- BigTableはRDBMSの考え方とは全く違う
- トランザクション
- データの持ち方
- 過去の資産をそのまま流用するのは難しい
BigTableのIndex
- kind index
- single property index
- composite index
- 推奨しないから話さない(使ってない)
- kind index
- select * from GrandChild(SQL的に)
- と同義なのはprefix:GrandChild
- kindからGrandChildをサーチして、物理的なキーを返す
- 物理的なキー→Parent:aaa/chile:bbb/GrandChild:ccc
- select * from GrandChild(SQL的に)
- single property index
- where name = 'aaa'(SQL的に)
- と同義なのはprefix:Parent name aaa
- |kind|property|value|
- where age > 20 && age <= 30(SQL的に)
- <>な検索はRange Scan→keyをget→valueをget
- where name = 'aaa' && age = '30'(SQL的に)
- name = 'aaa'でprefix scan
- age = '30'でprefix scan
- それぞれのprefix scanをマージするイメージ(SQLでいうところのmerge join)
- それぞれのprefix scanはパラレルに行われる
- single property index+order byするときはインデックスが必要
- その場合はクライアントでSortした方がよい
- where句は=以外使わない
- =以外のデータを拾いたいときは、ガッサリ拾って=以外をフィルタリングする
- order byはwhere句を使わないときだけ制限を受ける
- where name = 'aaa'(SQL的に)
- 一回のアクセスで1000件までしか取得できない
- ページング処理でカバー
- Googleの中の人曰く、
- 非正規化を怖れるな*1
ライトニングトークス
全体的にはすごくHeavyweightなLTでしたww
*1:!!w