JJUG CCC 2016 Spring (Japan Java User Group Cross Community Conference) に参加したので，聴講したセッションや話した内容のメモ．
以下，自分の参加したセッションについて，スライドの箇条書きと言うより，自分が重要だと思った箇所を中心に要旨をメモ．
スライド内容を正確にはメモしていないので，コード例も発表のものとは微妙に違う可能性があります．
GH-1 Type Annotation for Static Program Analysis by 櫻庭祐一さん
Java SE8 で追加された Type Annotation について．
どんな機能？
この機能は，これまで型やフィールドや変数の宣言の箇所にのみ付与することができた Annotation が，Java SE8 からは型を利用する場所や型パラメータに付与することが出来るようになった．
背景
この仕様の策定には，以下の様な背景がある．
- Annotation が担っていたシンタックスチェックという役割が充分にワークしていないこと，例えば
@Overrideや@Deprecatedなどだが，その効果にはやや疑問． - 各種静的解析ツールによるソースコード解析に限界がある．例えば，以下のコードは明らかに NPE が発生するが，静的解析的には振る舞いに関する判定は出来ないので潜在バグは検出できない．
public class NpeOccurs {
public String getMessage() { return null; }
public String formatYourMessage(String yourName) { return yourName + ", " this.getMessage(); }
}
- Eclipse や IntelliJ IDEA では，独自にメソッド引数やローカル変数に付す
@NonNullや@NotNullといったアノテーションがあり，実行時に警告を出すことが出来る．ただし，標準機能でないために普及しなかったり，以下のコード例のようにソースコードがアノテーションだらけになるため実用しづらいデメリットがある．
public class Container<T> {
private T value;
public Container<T>(@NonNull T value) { this.value = value; }
@NonNull public <T> T getValue() { return this.value; }
public <T> void setValue(@NonNull T value) { this.value = value; }
}
これらの問題を克服するために，例えば以下の様なコードがかけると，静的解析ツールも作れそうだし，コードの見通しも良くなりそう，という話．これが Type Annotation.
// このやり方で Eclipse NonNull アノテーションはワークしないはずなので注意．Just a Concept.
public class Container<@NonNull T> {
private T value;
public Container<T>(T value) { this.value = value; }
public <T> T getValue() { return this.value; }
public <T> void setValue(T value) { this.value = value; }
}
Checker Framework
現在，Java 標準ライブラリに静的解析用の Type Annotation は定義されていない．
しかし，Type Annotation の JSR のリードの一人である Michael Ernst による Checker Framework がある．(Java SE7 でも動く！)
雑感
- 櫻庭さんのお話を直接伺ったのが初めてだったので感激．
- Java SE のスペックリードを務めている人の顔と名前を覚えよう！という話が印象に残った．自分はマーティン・ファウラーやジョシュア・ブロックのような古典的名著を書いた人物はある程度覚えているものの，リアルタイムのリードエンジニアについては素人もしていなかったなぁと思ったので．
GH-2 Eclipse Collectionsで学ぶコード品質向上の勘所 by 伊藤博志さん
ゴールドマン・サックス (以下，GS) がオープンソースとして公開していた Java 汎用コレクション・フレームワーク GS Collections が，今年1月に Eclipse 財団に移管されてEclipse Collections となった．今回のセッションでは，Eclipse Collections の機能ではなく，開発に於けるコード品質についての GS の考え方や Eclipse Collections に於ける実践が取り上げられた．
GS に於けるコード品質とは？
GS では，「コードの品質」と「ソフトウェアの品質」はオーバーラップする部分があるものの等しいものとは考えておらず，コードの品質には以下の2種類があると定義している．
- ソフトウェアの価値に直接寄与するコード品質
- ソフトウェアの価値に直接は寄与しないが，ソフトウェアの後々の成長に影響するコード品質
このような文脈で「技術的負債」という言葉があるが，会計的に言うと 資産 = 負債 + 自己資本 であり，負債も資産の一部であるので，技術的負債は常に悪とは言えない．
ただし，時間の経過と共にソフトウェアの品質向上に寄与できるのは自己資本 (つまり品質の高いコード) であり，負債は利子をつけて返す必要がある．つまり，「リファクタリングとは，資産は増やせないが自己資本比率を高める」活動であると言える．
技術的負債の返済はプロジェクトの成長や機能の提供とを天秤にかけて判断をすることが重要であり，抱えている技術的負債はイシュートラッカーなどではっきりと認識し，後続のリリースタイミングで返済するのが良い付き合い方である．
Eclipse Collections でのコード品質担保
自分のメモベースで列挙になってしまうが…
Eclipse Collections ではメモリ効率が良く速いライブラリとするために，ベンチマークを [Memory Test Bench] (http://www.javaspecialists.eu/archive/Issue193.html) や Java Micro Benchmark Harness (JMH) を用いて取得している．
コードフォーマットやインスペクションは IntelliJ IDEA の Inspector を用いて各開発者のローカル開発環境でチェックしているが，本来はビルド環境でチェックを行いたいとのこと．
Eclipse Collections は TDD で成長してきたライブラリであり，GS Collections 時代の最後のビルドは 97% のテストカバレッジを誇っていた．
Eclipse Collections は様々な種類のコレクション API を提供しているが，ロジックが共通するクラスが多いので，テストコードを DRY にするのに苦労する．実際には，Java8 のインターフェイスのデフォルト実装でテストロジックを書き，実際のテストクラスはこれらのインターフェイスをミックスインするかたちで宣言している．
現在の JUnit の標準的な TestRunner はインターフェイスのデフォルト実装をテストメソッドとして実行出来ないので，Eclipse Collection 独自でテスト実行できる TestRunner を実装ている．現在，JUnit の本体に取り込んでもらえないかと動いているとか．
その他
GS Collections を Eclipse Collections に移管したのは，コミュニティからのコントリビューションを受け入れるため．GS のレポジトリで公開している限りでは，オープンソースとは言え外部の開発者の書いたコードを自分たちのライブラリとして取り込むことに問題があり，よりオープンソースとしてプロジェクトを進められる方向にかじを切ったとのこと．
雑感
- コード例を見た感じだと，Java SE8 の Stream API のビミョーなところが Eclipse Collection だと良い感じに可読性が高そうだなという感想．以前計算系のライブラリを Java で作った時に GS Collections をほぼ検討せず Guava を使ってしまったが，ちょっと後悔．
- 金融機関である GS はセキュリティーポリシーが厳しいことは想像に難くないが，それでもオープンソースに理解があるのが素晴らしいなぁと思った．ただライブラリを公開するのみならず，JUnit へのコントリビューションを検討しているといった話も含めて．
- Eclipse 財団に移管したのに IntelliJ IDEA を使っているという話はちょっと面白かったw
E-3 Spring Boot で Boot した後に作る Web アプリケーション基盤 by 吉田朋也さん
Spring を「機能開発 Ready」な状態にするのに，どういう基盤を機能開発前に準備すればよいか，という話．
正直，Spring Boot プロジェクトを最初から作った経験のない自分にはピンと来ない話が多かった…これからもう一回プロジェクトを initialize して仕事をする際にこの資料は参照することが多くなるんだろうな…という感じです…
F-4 セットアップをスマートにすればJava開発はもっと速くなる！ by 桑原雄一さん
㈱モノクレアの SI Toolkit を使った「初日から継続的デリバリーを回そう」という話．
Maven の Archetype を使って初期化されるプロジェクトにデータベースコンポーネントや Selenium による e2e テストも含めて，開発環境構築も Jenkins 上でのビルド・テスト・デプロイも mvn コマンドで一発にする，というもの．
継続的デリバリーの言うステージのうち，Programing stage もビルドパイプラインの一部であることを意識することが大事であり，ビルドパックにデータベースや e2e テストを含めることは Java の "Write Once, Run Anywhere" の精神を Java コードのみのスコープからプロダクト全体にまで当てはめることであり，方向性として間違ってない，という話が興味深かった．
F-5 Javaプログラマーももう逃げられない。マイクロサービスとAPIの世界。 by 田中孝清さん
IBM の Websphere 関連ソリューションもマイクロサービススタイルのアーキテクチャに対応できるよ，という話．
世の中での
- モバイルアプリ対応
- モダンブラウザ対応
- 仕様レベルでの脆弱性露呈
等の外的要因により，レガシーシステムを使い続けることも難しく，マイクロサービスアーキテクチャを採用して部分ごとのアプリケーション更改ができるようにしなきゃいけないね，という話．
その中で，マイクロサービスアーキテクチャは SOA (サービス指向アーキテクチャ) の進化系であると言え，SOA はシステムコンサルによる「絵に描いたあるべき像」に過ぎなかったのに対し，マイクロサービスは実際に成功した企業を分析した結果見えた「ベスト・プラクティス」であるという話が興味深かった．
また，マイクロサービスを考える上でのポイントは，最初から分割をしようと頑張るのではなく，「これが使えたら良いな」を API 化していくところから始めるのが大事，というのもナルホド感．
CD-6 SmartNews のニュース配信を支えるサーバ技術 by 瀬良和弘さん
SmartNews のアーキテクチャのうち，ニュース配信および配信内容を決めるエンジン，そして開発環境に関しての話．
社内ではデータ解析や画像解析などのスペシャリストはそれぞれの特技に注力できるようにして，Site Reliability Engineer がサービス全体のエンジニアとして，アプリケーションのモダン化や生産性の向上を行う，という役割の明確さが良いなぁと思った．
（Swagger 知らんかった！）
アプリケーションからのアクセスの矢面に立つ部分は LB 越しの複数台の EC2 であり，記事分析の部分は適切な粒度に分かれたマイクロサービスになっているとのこと．もともとは Seesaa2 ベースのモノリシックなアプリケーションだったが，徐々にマイクロサービス化していったとのこと．
DevOps 系は Ruby が中心となっており，Itamae でのプロビジョニングや Route53 の設定を行っている．
開発は github.com と CircleCI が中心．CircleCI がビルド成果物を S3 にプッシュしたうえで CodeDeploy をキックする．CodeDeploy は S3 に成果物を取りに行くようにできている．
監視は Datadog でのインフラ監視と New Relic でのパフォーマンス監視．New Relic ではバッチ処理の所要時間などまで計測ができる．
雑感
- スペシャリストエンジニアと SRE の役割の明確な分かれ方が良いなぁと思った．
- 個別に立ち話的にマイクロサービスの開発方法などについても質問できて非常に有意義でした！
CD-7 マイクロフレームワーク enkan(とkotowari)ではじめるREPL駆動開発 by 川島義隆さん
@kawasima さんが発表したフレームワーク enkan の紹介．
Spring をはじめとする「暗黙的に便利な機能を動かす」フレームワークではなく，「すべてを明示的に Java のコードとして書く」というコンセプト．
基本的に発表資料の通りなのだけれども，ルーティングの部分だけは型安全に書けないので，URI 間違いで例外が起きた時には Ruby の did_you_mean 的なスペルサジェストを出している，というのが印象に残ってます．
雑感
- 12 Factor App とか Rails とかの世界だろ−，と勝手に他人事だと思ってたのだが，明示的に設定を Java のコードとして書くことで気楽・直感的に実現できそうだなぁ，という小並感．