Seasar Conference 2009 Autumn

勉強会 BigTable DBFlute Slim3 GWT GAE Java Seasar

http://event.seasarfoundation.org/sc2009autumn/

とてもとても勉強になった！！4つもセッションを見れたのもあるかもしれないが、あんなに勉強になるとは思わなかった。今まで損していた気分になるぐらい。とりあえず、見たものについて簡単に書いておく。

ファウンデーション活動報告

認定試験制度を作成中とのことだった。受けてみようかな。

Slim3入門

概要
  • 前半はSlim3のコンセプトである「less is more」に関する説明。less is more は省略の美とのこと。西洋的な more is better つまり機能は多ければ多いほど良いに対して、必要最小限で効果を上げるという考え方。
  • Slim3をプログラマの手に馴染む道具にしたい。具体的にはTDDをサポートしたい。そのためSlim3では以下の3つをサポートしている。
    • TDD：テストクラスを含めたクラスの自動生成
    • ホットリローディング：クラス変更時にサーバーの再起動を不要にすることで、開発のリズムを崩さない
    • タイプセーフクエリ：スペルミスの早期検知、DB変更時にリファクタリングで対応可能
  • Slim3のblankプロジェクトを使ったデモ
感想など
  • ひがやすをは大学教授のような雰囲気だった。哲学的な雰囲気をまとっていた。
  • less is more は共感。機能が多いと把握するのも大変だし、あらゆるケースに対応しようとすると複雑になりすぎる。基本的なパターンのみサポートし、例外パターンは抜け道を用意するのはフレームワーク作成の原則だと思う。
  • Slim3の特徴はSlim3のページに書いてあった。http://sites.google.com/site/slim3appengine/Home
  • デモの内容も同じくSlim3のGetting Startedに書いてある。http://sites.google.com/site/slim3appengine/getting-started
  • 開発手順が明確化されているのがよいと思った。
    1. ブラウザでページを表示。404NotFound
    2. そのページのパスからクラスを自動生成
    3. 自動生成されたテストクラスをとりあえず実行
    4. ブラウザも確認
    5. 画面の実装
    6. 遷移先が404NotFound
    7. 2に戻る

GWTではじめるFull Ajaxアプリケーション

概要
  • Slim3でのGWTの利用手順
  • デモを交えたGWTの仕組みに関する説明
    • モジュールがクライアントサイドでのエントリポイント。サービスはサーバサイドのJavaでJavaScriptに変換されない。
    • JSに変換可能なのはjava.langとjava.utilパッケージのみを使用しているクラス。
    • HostedModeではモジュールはJavaとして実行されており、WebModeでJavaがJavaScriptに変換されている。
    • JSNIでJavaの中にJavaScriptを書ける。
    • warの中にコンパイルされたJavaScriptがある。最初は難読化されているが、GWTの設定を変えることで読みやすく出来る。
    • 変換されたファイル名は MD5 + cache.js となっている。ブラウザのキャッシュが利用でき、少しでも変更した場合に MD5 が変わるため、確実にリフレッシュされる。このファイルを呼び出すのは nocache.js。
    • GWTはリファードバインディングを利用しているため、JavaScriptのサイズを小さくし高速化している。
  • GWTとHibernateを連携する場合は、Hibernateで生成したクラスはJavaScriptに変換できないのでDTOを用意するとよい。
  • GWTとJDOを連携する場合はデタッチしておけばクライアント側に渡せる。
感想など
  • GWTはGAEのチュートリアルで触っただけだったので概要がつかめてよかった。
  • 仕組み中心で具象物がそれほどなかったが他の人は理解できていたのだろうか。まぁ、参加するのだから皆レベルが高いのかな？個人的にはとても楽しめた。

SQL脳からBigtable脳へ

概要
  • BigTableの機能と仕組みを説明。背後のGFSについても触れる。
    • BigTableは要は巨大なHashMapのようなもの
    • Keyを使ってオブジェクトを取得する
    • スキーマレス
    • Keyがソートされている
    • データはバイナリ
    • すぐにGFSに書き込まれるのではなく、Bigtableのメモリ上で処理される。
  • DataStoreの機能
    • Table
      • Get(parallel)
      • Put(parallel)
      • Delete(parallel)
      • Prefix Scan(ancestor query)
    • Index
      • Prefix Scan
      • Range Scan
  • Indexの種類
    • kind Index：select * from kind つまりあるクラスを全件検索する場合に利用されるIndex
    • single property index：select * from kind where name = 'aaa' つまりある1つのプロパティ（ここではname）をつかって検索する場合に利用されるIndex
    • composite index：kind Index、single property index を利用できない場合に利用するIndex。ただし自動生成されないためメンテナンスが困難な上、デプロイ時の生成コストおよびIndexのデータ量の観点で使用を勧めない。
  • joinや aggregate query （グループ関数）は利用できない。
  • GAEで以下を実現する方法について説明
    • single property index を利用できない：最も件数を減らせるプロパティで検索した結果をJava側でさらに絞る
    • join：kind毎に検索し、Java側で連結したり絞り込んだりする
    • aggregate query：sort と RangeScan を組み合わせて取得する。
    • count：キーのみ指定して検索すると1000件の制限が解除されるので、取得したリストのサイズを取得すればよい
  • まとめると、single property index で間に合う範囲まではデータストアで処理し、間に合わない範囲はJava側で処理する。また、開発者全員がDataStoreやBigTableに精通するのは困難なため、このようなロジックはDAOに閉じ込めるようにする運用がよいのでは。
感想など
  • これを聞きたくて参加したのだが、とても勉強になった。時間が足りずトランザクションについて聞けなかったのは残念。
  • スライドは公開しないとのこと。もっとちゃんとメモして置けばよかった。
  • 要はデータストアで出来ないことはJavaですればよいというだけ。そう考えるとそんなに難しくない気がする。ただ、RDBというかSQLに慣れた人には抵抗感があるだろうな。ただ、分散処理を前提としたGoogleのインフラだとJava側で処理するのは逆に妥当な気がする。
  • プログラムが書けないと言っているDB屋さんはBigTableはつらいかも。仕組みは理解できてもJavaのコードが書けないので担当する部分が無くなってしまう。
  • スキーマレスってスキーマを定義しなくても勝手に定義してくれてるみたいに聞こえるけど、要はHashMapなのでvalueのオブジェクトをそのまま放り込んでいるだけ。そもそもBigTable上にスキーマと言う概念そのものが存在しない（まぁ、キーを作る際にオブジェクトの型を利用しているが、でもこれって単に一意にするために利用しているだけ）。どちらかというとノンスキーマと言った方がよいのでは？
  • RDBはスケールアップ、BigTable（KVS）はスケールアウトを前提にしている。そこを押さえればアーキテクチャや実装方法についても分かってくるのではないだろうか。例えばRDBは単一のインスタンスだからこそDB側でjoinした方がよいけれど、Bigtableはそれ自体が分散されているからメモリ空間が単一になるのはクライアントのJavaのみ。よってここで処理するのが一番早い。OracleはRACでメモリ空間を広げられるけど、それは仮想的なものであってネットワークがボトルネックになる。BigTableはそもそも分散しているから台数を増やすほど早くなる。
  • 各種制限に関してはGAEのドキュメントに書かれている。サポートされていない JDO の機能、クエリに対する制限、インデックスの定義と設定。なお、composite indexは開発サーバーでそのクエリを実行すれば自動的にインデックスを自動生成してくれる。ただ、ひがさんが勧めるようにJavaでやった方がよいとは思うけど。なぜってメモリが足りなければ勝手にスケールアウトしてくれるんだから。
  • Googleを支える技術を読んでいなければ理解できなかったかも。読んでおいてよかった。

DBFlute ライトニング外だしSQL

概要
  • DBFluteとしてはConditionBeanと外だしSQLの両方を同じぐらい重要だと考えている。どちらかではなく、両方を上手く使い分けて欲しい。
  • 外だしSQLを考える際のポイントは以下の3点
  • 2WaySQLを採用しているためSQLクライアントで文法チェックが出来る。
  • EMechaを利用することでSQLファイルの雛形を自動生成できる。
  • EMechaを含めたデモ。SQLファイルから戻り値とバインド変数のオブジェクトを自動生成できる。
  • SQLファイルの指定に関しても自動的に定数を生成するようにしてタイプセーフにしている。これでタイプミスを避けることが出来る。
  • ページングやカーソルもサポートしている。ページングでは単一のSQLファイルにRownum用のSQLと実際のSQLの両方を書ける。
  • 全外だしSQLの構文チェックを出来るツールも用意している。こうすることで、カラム名を変更する際の影響度を事前に調べたりも出来る。
  • 構文エラー時のエラーメッセージはS2DAOやiBatisでは分かりにくいが、ここも分かりやすくしている。
感想など
  • DBFluteはおろかS2DAOも全く知らなかったのでとても勉強になった。
  • DBFluteというか久保さんの使いやすくしようという意欲は打たれるものがあった。どうせならやれるだけやりたいよね。素晴らしいと思う。見習いたい姿勢だ。
  • 2WaySQLも本当に便利だと思う。iBatisは知っていたけど、ちょっと微妙だと思っていて、とてもよいと思った。使いたいなぁ。DBチームのSQLレビューもしやすいだろうな。
  • メタ情報を使って戻り値のオブジェクトを作っているとのことで、この辺は似たようなことをしたことがあるので面白かった。微妙に正確な情報を返さないことがあって苦労したことがあるけれど、DBFluteはどうしているのだろう？こんど見てみよう。

ライトニングトークス

みなさん勢いがすごくて刺激を受けた。バッチFWを作ろうとしている方がいたが、現場では必要なので頑張って欲しい。