JavaOne2014 4日目メモ (10/1)
サンフランシスコ市街地のスーパーに水を買いにいったら、キャベツ太郎が売ってたので思わず写真を撮る。2.49ドル、日本でいうとポッキーよりも高級なお菓子になっている。
以下のようなセッションに参加。
Everything You Wanted to Know About Writing Async, Concurrent HTTP Apps in Java [CON3712]
非同期でかつノンブロッキングI/Oを行うHTTPクライアントをどうやって書くか紹介するセッション。
非同期およびノンブロッキングに関する振り返り
- 非同期
- I/O中のスレッドはブロックされるが、完了前に応答を返してくれるので別の仕事が並行でできる
- javaではFutureが帰ってくるような実装で実現
- ノンブロッキング
- I/O中にスレッドをブロックしない。selectorに登録し、データ利用可能時に通知をもらうモデル
- javaではNIOパッケージで実装できる
今のところの実現手段
- 元々はSNSサイトのNing社が作ってたライブラリ async-http-client
- Apache HttpCompoinentにある機能 HttpAsyncClient
いろんなREST APIから情報を持ってきて組み立てるシステムでは、毎回同期でかつブロックして待ってたら遅いので、非同期かつノンブロッキングが比較的簡単に実装できるのはとても大切。
Principles of Evolutionary Architecture [CON4580]
継続的にアーキテクチャを進化させていく上での原理・原則を紹介するセッション。
進化するアーキテクチャの原則
- 最終責任時点 (last responsible moment)
- その時点で集まる最大限の情報を集め、複雑性による技術的負債は最小限に
- 優先度を重視して、早めに決断する
- 発展的なアーキテクトと開発
- データのライフサイクルとオーナーを明確にする
- 軽量なツールとドキュメント
- ソフトウェアの内部品質は変更が容易かどうかで評価すべき
- ポステルの法則
- 送信側は慎重に、受信側は寛容に。バリデーションは必要な範囲で。
- 設計に対するテスタビリティ
- テスタビリティを向上させることで、より最適な設計に近づく
- メッセージングシステムは、あくまで通信のために使い、ビジネスロジックとしては使わない
- 振る舞いや性能だけでなく、規約もテストする
- コンウェイの法則
- それぞれの組織がデザインするシステムは、その組織間のコミュニケーション構造を反映する
- コミュニケーションの欠落は、複雑な統合に繋がる
- 製品は組織と同じ形になるので、変えたければ組織か製品自体を変える
実現のためのテクニック
- データベースリファクタリング
- 大きな変更を小さく分割して、バージョン管理もする
- 継続的デリバリー
- デプロイって作業は本来退屈じゃなきゃいけない！
- システムインタフェース規約のテスト
- 個々のシステムが独立して作業できるようなインタフェース規約
- ポステルの法則も意識しながら
- 古来よりアーキテクトが持つ役割の一つ
今後の仕事で判断に迷ったときの参考にしようと思う。
Plugging into the Java Compiler [CON4265]
Googleが作ってるValueObject実装のAutoValue、Squireが作ってるDIの実装daggerと、それぞれの技術の基となっているアノテーションプロセッサの話
AutoValue
- イミュータブルなValueObjectのコード記述を簡潔にすることが目的
pom.xmlには以下を追加
<dependency> <groupId>com.google.auto.value</groupId> <artifactId>auto-value</artifactId> <version>1.0-rc1</version> <scope>provided</scope> </dependency>
@AutoValueを付与する
@AuthValue public abstract class Address { public abstract String streetAddress(); public abstract int postCode(); public static Address create (String atreetAddress, int postCode) { return new AutoValue_Address(streetAddress, postCode); } }
ValueObject生成時にはcreateメソッドを実行する
Address a = Address.create("some address", "xxx-xxxx");
lombokの@Value異なり、AutoValueではコンパイラの処理に割り込んでバイトコードを追加したりなんてことはせずに、シンプルにソースコードを生成する。実際にNetBeansで試してみると、以下のようにソースファイルが出てくる。
AutoValueを使うとあくまでソースを生成しているだけなので、仮にAutoValue自体にバグがあってもすぐわかる。lombokで得る効率よりも、バイトコード生成の黒魔術感への不安が勝るプロジェクトで使えそう。
dagger
dagger1.0のコード例についてはマニュアルが詳しい。
Debt and Deprecation [CON6377]
Java Day Tokyo 2014やJJUG CCC 2014 Springでもラムダ式やストリームAPIについて講演されたStuart Marksさんが、Dr.Deprecator(非推奨博士？)として登場。
内容はJavaの『@Deprecated - 非推奨API』に関する振り返りと、現在複数の意味合いを持つDeprecatedを新しい言葉に置き換える提案を紹介するセッション。
今までの非推奨の振り返り
既存の『非推奨』の使い方
非推奨を新しい言葉を使って再カテゴライズする提案
陳腐化(Obsolescence)したAPIは現在の非推奨API以外(例 Vector)にもたくさんある。非推奨と一つに丸めてしまうのではなく、適切な用語を再定義してカテゴライズする。
- Condemned : 将来のリリースで削除や無効化するもの
- Dangerous : バグやデータ損失を招くAPIであるもの
- Superseded : 危険ではなく、削除される予定もないが、新しいコードでは新機能に置き換えた方が良いもの
- Unimplemented : 実装されてないことを示す。UnsupportedOperationExceptionをランタイム例外としていきなり返さずに、ドキュメント上でわかりやすくする
例えば、Superseded(廃止)として現状は非推奨になっていないが、VectorやHashTableなどの古いコレクションクラスや、java.util.Timer/TimerTask(タスクが長時間かすると次の実行がずれるシングルスレッドモデルなので、ScheduledThreadPoolExecutorに置き換えた方が良い)がある。
