Java
jjug
JJUG-CCC
enkan

「JJUG CCC 2016 Spring」に行った

More than 1 year has passed since last update.


概要

JJUG CCC 2016 Spring に参加してきました。「参加報告を投稿するまでがJJUG CCC」と JJUG の鈴木会長がおっしゃっていましたので恐れずに投稿してみます。

なお資料等がアップされ次第、追記予定です。

日時
2016/05/21(Sat) 9:30 - 19:30

場所
ベルサール新宿グランド
東京都新宿区西新宿8-17-3 住友不動産新宿グランドタワー

参加費
無料(要参加登録(doorkeeper))

公式サイト
http://www.java-users.jp/?page_id=2377

タイムテーブル
http://www.java-users.jp/?page_id=2399

セッション一覧
http://www.java-users.jp/?page_id=2396

Twitter のハッシュタグ

#jjug_ccc (セッションごとに個別のハッシュタグあり)

前回に引き続き、懇親会はスポンサー様のご好意により無料となったそうです。


JJUG? CCC? 2016? Spring?


  • JJUG……Japan Java User Group

  • CCC……Cross Comunity Conference

  • 2016……2016年

  • Spring……ばね


JJUG CCC


  • Java のユーザによるカンファレンス(年2回)

  • セッションのCfPを一般から広く募集、今回は一般投票も実施

  • スポンサーセッションやブースもあり

  • 内容は Java VM にかすっていればなんでもいい。Scala や Groovy や Kotlin のセッションもあり


今回から

いろいろと運営が改善されました。頭が下がります。


  1. セッション20分枠が追加

  2. 基調講演の裏番組が追加

  3. 昼休みが60分→90分に増加

  4. 40分休憩が午後に2回


追記

2016/05/24(Tue) の Java Day Tokyo 2016 で鈴木会長がおっしゃっていた今回のデータ


  • 1,380名申し込み

  • 810名参加

  • 初参加 43%

  • 20代の参加 36%



資料一覧

今回の資料や参加報告は下記の GitHub repository にまとめられています。

JJUG CCC 2016 Springの発表資料,ブログ記事まとめ



ワードクラウド

d3-cloud.js を使って作ってみました。参考程度にご覧ください。

wordcloud.png



聴講したセッションのメモ

以下、発表者は 敬称略 です。ところどころ私のメモが混じっていますのでご了承ください。


日本Javaユーザーグループ2016年定期総会

by
鈴木雄介(日本Javaユーザーグループ 会長) @yusuke_arclamp

time
9:30-10:00


活動報告


  1. 2015年の CCC は参加者666名、667名、登録はどちらも1,000名超え

  2. ナイトセミナーとハッカソンは16回開催

  3. 地方派遣……JavaOne 報告会が多め

  4. 国際会議参加……2回


会計報告

バランスシートと収支計算書をきちんと作っている


  1. スポンサー収入が主

  2. CCC の会場費が230万円かかっている


決議事項

櫻庭さんが副会長退任

出席者からの拍手で決を採る


活動方針


  1. イベント運営の高度化……1,000人規模のカンファレンスができる会場がなかなかない、Wi-Fi を設置するとなると結構いい料金になってしまうので断念せざるを得ない事情がある、等々

  2. Adapt-A-JSRへの参加

  3. Java SE 9と Java EE 7の普及

  4. 協業イベント実施


今回の JJUG CCC について

スマートフォン用タイムテーブルを有志が作成


F-1 広告システム刷新の舞台裏 - PHP から Java に変えてみました

by
森下大介(ヤフー株式会社)

time
10:00-11:00

Web企業の業務系システム開発を担当している方、4分割の自己紹介スライドが面白い


時に、2011年、当時の社内のシステム


  • PHPメイン、たまにバッチ系でPerlやShell

  • vim や emacs で開発……IDEはほとんどなし、個人の端末はサーバにログインするための踏み台状態

  • テストはブラックボックステストのみ

  • 自動化も大したことなかった

  • それでもFEとBEの分離は明確にできており、BEはきちんとAPI化

  • スケールも容易な設計


何が問題か?

やりたいことに道具が合っていない


何をやっても「何か妙につらい」

typoを直すことすらgrepとブラックボックステストでがんばらないといけなかった

* UnitTest がない

* コンパイラも型もない

* IDEもないからリファクタリング機能など使えない


ドキュメント


  • 手書きな上、書式が統一されていない

  • 利用側と提供側での認識が一致していない……PHPには連想配列しかないのに「配列」と書かれていると何言ってるのという


LLの柔軟さ

存在しないメソッドや間違った型での引数受けをしていてもそのまま動いてしまう!!!??!?!??!??!?

……本番で気づくケースも

大規模かつ複雑なシステムにPHPは適していない……面相筆で壁を塗るようなもの

お金を扱うシステムで型がないのはつらいとかいうレベルじゃない。むしろ今までよく運用できていたという感じ


ゆでガエルのジレンマ

危機を感じてはいるが、現状問題なく動いて売り上げを出しているし、手当てするなら根本的にやらないといけないので勇気が必要

こうした時に体制変更があり、新しい部長から「一から全部変えていい」と号令がかかる。ボトムアップでは無理なことだった。


取り組んだこと


0.体制をつくる


  • 部長直下のリードに異動……飲み会のメールが回ってこなくなる責任重大なポジション

  • 仲間集め

  • 部門長の宣言


1.プログラミング言語を変える

コストが極大化するリスクを負ってでも適切な言語を選ぶ


選定基準


  • 型がある

  • コンパイルできる


候補(当時)とデメリット


  • C++……メモリ管理が困難、言語自体が難解

  • Java……Web業界だと敬遠されがち

  • Scala……経験者が少ない、ビルドツールに癖がある、後方互換が厳しい

ということでJavaを採用


2.テストできるアーキテクチャにする


なんでテストできないか?

テストを動かす準備が大変

CI/CD対応ができない

ブラックボックステストせざるをえない


モノリシックなアプリケーション内部(p38らへん)

呼び出し先の実装クラスを new するとクラス同士が密結合する


モノリシックな例


モノリシックな例


/**
* Third と Second と自分のテストが必要
*/

public class First {
public void doFirst() {
Second s = new Second();
s.doSecond();
}
}

/**
* Third と自分のテストが必要
*/

public class Second {
public void doSecond() {
Third t = new Third();
t.doThird();
}
}

/**
* 単体テスト可能(ただしDBをモックにする必要あり)
*/

public class Third {
public void doThird() {
// access db......
}
}



解決策

基本アーキテクチャとしてSpring FrameworkでDIを導入


3.テスト向けDSLを採用する

Java にはテストを表現する文法がない→Spockの導入

Googleのテスト命名の基準に従う

* STest……UnitTest

* MTest……複数クラスでのテスト

* LTest……ほぼブラックボックステスト


4.CI/CDと静的解析をする

ようやく当たり前にテストできるようになった

1. SpockでのUnittTest

2. Cloverでのカバレッジ計測

3. Coverity Quality Analizer でのコード解析

4. Coverity Test Analizer でのテスト解析

5. Frisby による Web API のスモークテスト


5.インタフェイス定義言語を作る

BEの各機能は Web サービス(API)で提供……利用側と提供側での認識ずれを解消したい

→インタフェイスは宣言的に書けるはず→IDLを自作


なぜOSSではダメなのか?


  • Google ProtocolBuffer

  • Apache Thrift

理由:入力値のバリデーションやドキュメントの自動生成をサポートしていなかった


GH-2 Eclipse Collectionsで学ぶコード品質向上の勘所

by
伊藤博志(ゴールドマン・サックス テクノロジー部 ヴァイス・プレジデント) @itohiro73

time
11:00-12:00

今日は品質についての話がメイン、Eclipse Collectionsについてはブースセッションで


目的

オーディエンスがコードレビューする際に考えることを知る


理論編(10分)


コードの品質とは?


  • ソフトウェアの品質とは同義ではない

  • ビジネス的に説明しにくい部分


  1. 実装時点でソフトウェアの価値に直接影響を与える品質……インタフェイスの品質、実装の要求適合性・バグの存在、パフォーマンス

  2. ソフトウェアの価値の成長に影響を与える品質……保守性・拡張性・再利用性・コードカバレッジ


技術的負債

会計用語のアナロジー、ゆえに負債は資産の一部である。


P6より

------------------------------

| ソフトウェア | 技術的負債 |
| の価値 |_______|
| | |
| (資産) | 高品質コード|
| | (自己資本) |
------------------------------

開発リソースが有限ゆえに生まれる。開発者、スキル、期間、環境の充実度……


技術的負債は悪か?

コピペすれば一時的に機能は増えるのでソフトウェアの価値は上がる。保守性や変更容易性は下がる。

判断理由次第では必ずしも悪いわけではない。すべて否定すれば物事が進まないこともある。

負債を返済するのがリファクタリング


コード品質のバランス

ソフトウェアの特性と文化的な背景により、どこの品質に重きを置くかは変わる。

開発チーム内で認識が一貫していることが重要


実践編


汎用ライブラリとしての価値

API設計レベルでの一貫性、簡潔性、可読性、(機能の)発見容易性


  1. 一貫したファクトリメソッドの設計……Lists.immutable.of()

  2. Immutable インタフェイスによる型レベルでの安全性確保……UnmodifiableCollection と違い、実行時例外が出ない(破壊的代入が不可)

  3. Utility を介さずに操作可能(発見容易性)……Collections クラスなど不要

  4. APIの命名には細心の注意を払う(可読性)……文化的背景にもよるが、Eclipse Collections では select/reject を選んだ。コーディングの際は命名により時間をかけてディスカッション


コレクションライブラリとしての価値

パフォーマンスの最適化(メモリ使用量、実行速度)


例: HashSet と UnifiedSet

HashSet は Map のキーだけ使っている素敵な実装、

UnifiedSet は Objectの配列とChainedBucketを使って実装しメモリ効率とスピードの両面で最適化


パフォーマンス改善は計測することが最重要

しかしJavaのベンチマークは単純でない


  • GCの影響

  • JVMのウォームアップ


Memory Test Bench

Java Specialist News Letter #193 で紹介


JMH

OpenJDKで提供されているマイクロベンチマークツール


  • JVMのウォームアップをFrameworkがやってくれる

  • 設定をメソッドチェインで書ける


多数の開発者を必要とするOSSとしての生産性

割と誰でも考えないといけないところ

一貫したコード品質を保つための施策を追加

* コーディングスタンダード適用……議論すべきところでないところは自動化し、本質的なところに時間を割く

* バグの可能性の解析

* テストカバレッジの計測


  1. IDEA Inspection……素早い視覚的なフィードバック

  2. Checkstyle

  3. Findbugs

  4. Clover code coverage


「Eclipse CollectionsですけどIntelliJで作ってます」



DRY(Don't Repeat Yourself)

繰り返しや重複を避ける


インタフェイスのデフォルトメソッド(Java8)を使ったユニットテストの重複排除


  • APIのテストは様々なシナリオが共通……select()

  • コレクション特有のテストはグループ内でシナリオが共通

違うレイヤーのシナリオをmix-in可能

FastListのテストは初期化コードのみ!ほかの膨大なメソッドのテストは上位レイヤーで保持

ただし、JUnitではデフォルトメソッドを実行できないので、これを動かすためのJUnitRunner(Java8Runner)を独自実装


Primitive(int/long/double/float/char/byte) の Collectionを実装しているのは Eclipse Collectionsだけ!


  1. JDK の Primitive Stream は3種類(IntStream/LongStream/DoubleStream)のみ

  2. JDK の Primitive Stream は .collect(Collectors.toList) しても primitive の Collection としてメモリ上に保持することはできず、Box 型の Collection にしなければいけない


Primitive Collection のコード自動生成

すべてを手動で実装するのは非効率かつDRY違反なのでStringTemplate を利用してコードを自動生成


テストカバレッジの重要性

「テストがない」という技術的負債は、頻繁に変更されうるソフトウェアにおいて 最も利子が高い

TDDで成長してきた Eclipse Collections ではテストカバレッジ97%!!!(GS Collections7.0のとき)


  1. 新機能はすべてインタフェイスとテストに追加

  2. バグが発生したらユニットテスト上で再現

  3. リファクタリングが実装後に容易

  4. リグレッションテストとしての機能


さらに

コレクション用の独自 assertion Frameworkを実装(eclipse-collections-testutils)


技術的負債との付き合い方

技術的負債の完済は不可能だが、よいソフトウェアはこれをコントロールする


  • 費用対効果の見積もり

  • 優先順位をつけて戦略的に採用

  • 返済計画を立てる


UnifiedSetWithHashingStrategy は UnifiedSet のコピペで一部作ってしまったが、戦略的なディスカッションをした上での決定


  1. 限定的で保守性への影響も限定的

  2. 重複排除よりも別にリソースを投資した方がライブラリ全体として有益(戦略的な反DRYの許容)

  3. 存在を認識するためにIssue trackerに登録し、フォローアップ

  4. Version 7.0で重複解消


コードレビューのプラクティス


  • 開発者間でコード品質に関する共通認識を持つ

  • コミッター同士でも Pull Request を通してピアレビュー


GitHubだけだとコードレビューがつらいので IDE を通して見たい

ローカルにfetchしてマージしてソフトリセットすると手元でIDE使って Pull Request を見やすくなるというTips


重要なこと


  1. 「ソフトウェアの価値を最大化するための品質は何か?」を見極める

  2. コード品質に関する価値観を開発チーム内で共有する

  3. 高品質コードと技術的負債のバランスを戦略から考える

  4. 静的解析の自動化とテストカバレッジによりコード品質をコントロールする


Eclipse Collections の最終目標(オフレコ)

Javaに入れること、EDLがBSDライセンス準拠なのでJDKに入れられる


参考


  1. Eclipse Collection Javadoc

  2. GitHub: eclipse-collections

  3. Eclipse Collection 日本語ドキュメント


AB-3 Javaでつくる技術ドキュメントのバリデーション環境

by
伊藤敬彦(株式会社リクルートテクロノジーズ) @takahi_i

time
13:30-14:20

Redpen の開発者

ソフトウェア開発者はプログラム並みにドキュメントを作る。プログラムはツール使って品質管理するのにドキュメントは十分やってない(目で確認)。

今回は Java を利用したツールでドキュメントを検査しつつ作成していく


マークアップ言語とフォーマット変換

本格的なドキュメントは本文以外の要素(図表等)を含むのでマークアップ言語を使う


  1. Markdown……手軽に使える、本格的なドキュメントだとファイル分割や画像サイズが足りない

  2. AsciiDoc……オライリーが採用し、海外で勢いを増している。電子書籍プラットフォームで採用、本格的なドキュメントを記述する機能がサポートされている

  3. Re:VIEW……日本語書籍での実績、InDesign との連携が強力

  4. LaTex……研究者時代に使用

  5. restructuredText


非エンジニアにはフォーマット変換ツールで読みやすいフォーマット(ePub, PDF, HTML)に変換して配布

Markup language
Tool

Markdown
Jekyll, Pandoc

AsciiDoc
Asciidoctor

restructuredText
Sphinx


ドキュメント検査ツール


RedPen


  1. 句読点や用語の揺れ、文体等のチェック

  2. 設定が柔軟

  3. 日本語でも英語でも設定を変えれば動く

  4. マークアップ言語に対応(MarkdownやAsciiDocでも)
    5, インストール容易

設定はXMLベース……

コマンドラインで実行、結果はそのままでもJSONでも出力可能


RedPen サーバ


  • Heroku 上でも動く

  • ブラウザ上でリアルタイムに編集可能

  • REST API


エラーの抑制

無視したいエラーを @suppress で抑制……次のリリースで入れる


ルールでも機能を追加可能にする

プログラムを書けない人でもyamlで追加可能にする予定


エディタ

Java 開発者はドキュメントをどのエディタで書くか?IntelliJ IDEA!

Antonio Goncalves (JUGのすごいひと)もコース資料を書くのに使っている。


  • 各マークアップ言語のプラグインあり

  • リアルタイムプレビュー可能

  • RedPen プラグインもできた(Kotlin で実装)、プラグインマーケットで公開中

Emacs/Atom/vim の RedPen プラグインも作られている


CI

ドキュメント作成もCIする。


広告


「『ドキュメント作成システム構築ガイド』という本を書きました」



質疑応答


Q.図を書く上手いツールはないか?

A.Keynote で書いている


Q.今後も社内ベースで開発するのか、コミュニティベースで開発するのか

A.コミュニティベースにできたらなあと思うが、そんなツールいらないよと言われるのが怖いので踏ん切りつかない

コメント:設定ファイルを設定しないといけないのが面倒、GitHub連携とかを考えても Web サービス化が必要だと思う


E-4 Introduction to JShell: The Java REPL Tool

by
吉田真也(立命館大学 大学院1回生) @bitter_fox

time
14:30-15:20


  • OpenJDK コミッター、LambdaやKullaに参加、日本OSS奨励賞受賞

  • KDDIの平川さんではありません(タイムテーブルの修正漏れ)

  • 18卒なので「こんな超優秀な学生がいます!!!」と会社に持ち帰ってほしい。

  • 質問は Sli.do で受付

  • IDE は NetBeans


JShell

あなたのIDEのワークスペースに、適当なコードを実行するだけのクラスを持つだけのプロジェクトはないか?

Java Disりの1つ

Ideone のようなオンラインコンパイラもあるが……

* 新しいJavaがなかったり

* 手元のライブラリ使えなかったり

* 依存解決できなかったり


そこで JShell ですよ!!!

Java の REPL ツール、bin/jshell コマンドで起動する。JDK9 でリリース予定

JDK9はアーリーアクセスが使える。2017/03/23にGAされるので今のうちからキャッチアップしておくとよい


  • JShell は Java のどこから始めてもちゃんと動く

  • 入力末尾の ; は省略可能

  • クラスも定義可能

  • メソッドも宣言可能

  • final の概念はない

  • 一時変数($d)への格納

  • 前方参照(定義する前の参照)が可能……Scala の REPL ではサポートされていない


どういった場面で使える?


  • 言語仕様の確認

  • ライブラリやAPIの確認

  • 新人教育……でも実際の教育は IDE でやる必要ある

  • 高機能電卓…… Perl とか Python とか Groovy とかでやっていたことを JShell で


Java9 の新しい言語仕様


  • 識別子_が使用不可

  • 外部変数が try-with-resources の対象になる

  • 匿名クラスでもダイヤモンドオペレータ


  • @SafeVarargs on private methods

  • private interface method


JShellコマンド

/で始まる


  • /help

  • /vars

  • /methods

  • /classes

  • /imports

  • /list……ソースコード

  • /set start /tmp/start.jsh

  • /! 1つ前のプログラムを再実行

  • /drop 削除

  • /debug ヒミツのコマンド


Startup

最初に実行するプログラムの指定、streamやArraysのstaticメソッドをimportすると手になじんでくる


Feedback

JShell のプロンプトとフォーマットを自分で変えられる、が難しい。変更すればかなり手になじむ、が、こればっかりやり過ぎないように


補完機能


  • コード補完……TAB

  • import 補完……Alt+Enter

  • メソッド補完……Shift+TAB


JavaFX を JShell から使いたい

現状、例外が起こって使えない

→のでjfxshellを作った!!!


JShell with Maven

川島さんの try-artifact

その川島さんが「将来的に enkan は JShell で動く」という話を最後のセッション枠でするとのこと


Q&A


  • 補完はカスタマイズできないがフォークすればいい

  • .java はオンメモリで作成されている

  • Shebang は非対応


メモ

JShell API が ScriptEngine っぽい API として使える???リリースが待ち遠しい


追記:Java8Puzzler の確認

バグがなかった時の Java8Puzzler(p22) の答えはどうだったのかを確認してみました。

System.out.println(Stream.of("Hello", "Fizz", "Buzz", "JavaSE8")

.map(String::length)
.map(i -> Integer.toString(i))
.collect(Collectors.joining(", "))
);


出力

5,4,4,7


ちなみに、同じ内容を Eclipse Collections で書くとこうなります。

System.out.println(ArrayAdapter.adapt("Hello", "Fizz", "Buzz", "JavaSE8")

.collect(String::length)
.collect(i -> Integer.toString(i))
.makeString(", ")
);


出力

5,4,4,7



I-5 JavaデスクトッププログラムをふつーのWindowsプログラムのように配布・実行する方法とPCの動きが重くならないよう気を付けること

by
高橋 徹 @boochnich

time
16:00-16:50

JavaFX Advent Calendar 2015 のトップバッターを務めた方です。また、Java読書会BOFを主宰されていて、現在は「Java EE 7徹底入門 - 標準Javaフレームワークによる高信頼性Webシステムの構築」を読書中とのことでした。


わかりやすくしようとしたら、今回最も長いタイトルになってしまった。今回は『Java パフォーマンス』を読んでインスパイアされた。説明半分デモ半分の予定



ゴール


  1. Javaのデスクトッププログラムを別の人に使用してもらう方法を知る

  2. PCが重くならない配慮を知る


Java でもデスクトッププログラムは作れる

JavaFX でいろいろできる。が、配布やインストールや実行、CPUやメモリの配慮が課題


  • 動かすには Java を入れて

  • バージョンは8でないとダメです

  • 8u40でないとダメです

  • JAVA_HOME設定して

……

Windows インストーラだったら簡単なのに……!


javapackager(8-)

再配布用パッケージ(アプリケーションとJREをまとめたもの)を作成するコマンド


  • JDK8

  • WiX Toolset 3.10 MSのオープンソース第1号(2004年)

オプション多すぎてなかなか……なコマンド

64MBほどのmsiが1分程度で生成される。ダブルクリックでインストーラが起動する。

ちゃんとWindows10のスタートの一覧やコントロールパネルでのプログラム一覧に入る。


CPUとメモリの使用量を抑制

一般的なPCの仕様

* CPU 2コア4スレッド2GHz

* メモリ 8GB

* OS Windows10 64bit

ただし、JavaVMからはCPU 4と認識される。キャッシュが半減して競合が増える。


64bit のわがまま VM

CPU:64bit VMだと 7スレッド立ち上がる。

メモリ:64bit VMだと初期 128MB確保する


開発者なら Process Explorer ツールで使用メモリを測定しよう

64bitと32bitだと「仮想メモリ」の「プライベートバイト」が3倍以上違う


心遣い

簡単なプログラムなら、可能であれば 32bit JRE でパッケージングして配布するとよい


簡単に作る

のであればサポートの強力な NetBeans SDK がおすすめ、チェックボックス形式で設定可能


あれこれ注文をつける


javapackagerで不可なこと


  1. 非ASCII文字での属性値設定

  2. メジャーアップグレードのインストーラ作成……0.2を入れても0.1を消してくれない

  3. インストール先のカスタマイズ

  4. インストーラUI


WiX Toolset の世界で制御する


  • javapackager を -v オプション付きで実行

  • template.wxs をコピーして作った独自の wxs ファイルを javapackager を動かすフォルダに置く

メジャーアップグレードは MajorUpgrade タグで指定可能


質疑応答


Q.プロセス名はどうやれば決められるか?

A. exeファイルは自分で名前をつけられるので、その名前でタスク一覧に載る。目玉機能です!!!


Q.VMオプションはどこまで動的に指定可能?

A.作るときに指定できるし、インストール先にオプションファイル(xx.cfg)が生成されるのでそこで書き換えてもいい


Q.32bitで配るときのデメリットは?

A. 32bitではメモリを2GBまでしか使えない


GH-6 Seasar2 で作った俺たちのサービスの今

by
阪田 浩一 @jyukucho

time
17:00-17:50

関ジャバの会長


対象

S2で開発・運用している人


注意

ベストプラクティスではない


結果

Spring に移行

1機能を先行し、その後2機能をリリース


移行する必要はあったのか?


  • WebSocketやSSEを楽に使いたい

  • Java8 に移行したのでそれに対応したFrameworkにしたい

  • メンバーの飽きを防ぎたい


どんなサービス?

ピクトリンク……女子高生向けにプリントシール機で撮影した画像を取得可能


  • Webサイト、iOSアプリ、Androidアプリで提供

  • 課金は自前実装

  • 月間約1億PV


開発体制

開発チーム 23人

* サイトチーム 6人

* アプリチーム 7人

* ログチーム 3人

* HTML/CSS 2人

* インフラチーム 5人

全社的に10年ほどS2ファミリーを標準採用していた、が、ここ5年ほど他サービスではScalaを採用していた


前提


  • 言語を変えるのはやめよう……人数も工数も足りない

  • リプレイス以外の業務もあるのでフルコミットできない

All or Nothing の移行はリスク高すぎる


Framework 調査


  • Spring

  • JavaEE

  • Play

  • Spark Framework

  • Ninja

  • Doma

  • JOOQ

  • JBDI

何もかもトレードオフで判断するしかない


トレードオフで重視したこと


  • 考え方がS2から離れていない Framework にする

  • 今あるサービスクラスを利用できる Framework にする……資産の有効活用

  • Servletで動く Framework にしたい……監視を監視会社に依頼しているので


採用

Spring MVC2.4.3+Doma2.6.0+Spring2.4.3


Cubby -> Spring MVC

そのままコードを見れば理解できるレベルの差異


S2Dao->Doma

アノテーションは増えるが Interface の実装は書かなくていい。SQLテンプレートも同様


どのように移行したか?

JVMとTomcatは2014~5にすでに変えてあった。基盤のバージョンアップは先にやるべき

しかしJava8の機能を駆使したコードはまだなかった……1週間に1,2時間ほど集まって勉強会をし、知識は入れておく


移行後のアプリケーション


  • 1つのアプリケーションに2つのDIコンテナ、

  • warの中にS2Servlet と DispathcerServlet と JS/CSS/Template
    ** だいたいシングルトンだったのでパフォーマンスに影響はさほどなかった

  • 振り分けはweb.xml


「スライドはこの倍ある」



Method Validation

メソッド引数にバリデーションを書くタイプ……リクエストパラメータをModelに入れる方式に慣れていないメンバーが多かった

業務システムではないサービスという性質上、複雑なバリデーションはなかった。


Validation error の場合は?

Spring の Exception handlerを使用


既存のUnittTestが動かない!

S2TigerTestCaseクラスを継承

Lambda式を書いたらdjUnitの部分でエラー発生……単純にJava8(というかInvoke dynamic)に対応してない

それ以外なら動作する→「Lambda式を使った君はUnittTestを書き直す義務がある」→djUnitのところをJMockit+JUnit4で書き直し

→書き方が変わる程度で違和感はなし

ちなみに移行した機能の結合テストは手動実行


後の方で発覚

S2Velocityの移行も必要?……Springでも同様の仕組みが必要なので実装


ベストプラクティスではない

格好良くはないが現実解にフォーカスした結果


メンバーへのレクチャー

以前との差分/新しい書き方/意味を説明、ほぼ抵抗なく習得へ進む

レクチャーやコーディングの努力にフィードバックが少なくてリーダーの孤独を感じた


今後


  1. 機能単位での独立したサービスにする

  2. WebSocket を使うとユーザにどんな体験を提供できるか?……企画の人でなく開発者が考えて提案


結論


「S2からの移行、怖くないよ!」


この体験を踏み台にしてもっとよい移行をし、Fallに「いやあ、春はひどいのありましたね」と言ってほしい


CD-7 マイクロフレームワーク enkan(とkotowari)ではじめるREPL駆動開発

by
川島 義隆 @kawasima

time
18:30-19:20


今日の話

ENKAN(円環)……Clojure の Ring が名前の由来


なぜ作ったか?

主流の Java Framework で大丈夫か?

ミドルウェアパターンを実装した社内 Framework の設計の一貫性のなさ&粗が目立つ

「ミドルウェアパターンというのはこういうものだ!」というリファレンスモデルを示すために作ったら出来が良かったので公開

本当はClojureを触りたい人がJava使わなければいけない時の Framework として作った


要件


  • Java8以上

  • Maven3以上

name
description

Enkan
Middleware/Cpmponent

Kotowari
WebApp Framework based on Enkan


Framework のトレードオフ

暗黙的な便利機能<->理解のしやすさ


コンセプト


  1. 明示的であること

  2. 開発しやすいこと

  3. 保守運用が簡単であること


多数のミドルウェア

ClojureのRingから移植したりプラスしたりして

追記

Commons フリー


Predicate

適用するミドルウェアの条件をカスタマイズ可能


以下のPredicateが標準で利用可能


  1. None

  2. Any

  3. Path

  4. Authenticated

  5. Permission

  6. Env


合成も可能

negate(), and(), or() を使う


設定ファイルが1つもない上にアノテーション地獄を隠蔽

アノテーションってXMLの置き換えじゃないのか?→enkan では Java8 Syntax を使えばDSL的に書ける


使うアノテーション

コントローラを書くのに使うのはこの3つ

1. @Inject

2. @Named

3. @Transactional


黒魔術を使わない


「Proxyまでは白、バイトコードを触るのは黒」



開発を簡単にする仕組み


Hot reloading


  • REPLから /reset を実行したタイミングで再ロード

  • /autoresetするとクラスの変更を監視して自動Reset

  • 将来的にはJVM containerを使って、より高速かつ安全なリロードを可能にする(詳細は Java Day Tokyo 2016で)


Eady to realize misconfiguration

MisconfigurationException を用意……問題と対策を持った専用のException


「優しさを見せるため無理やり作り込んだ」


actionは Stringでないといけない、という事情


Trace the request / response

1リクエスト単位で可視化・表示


Ease of Operation


  1. 起動がとにかく高速(1-3sec)……通常はクラスのスキャンや設定のロード・パースが遅いので、それをやらない

  2. Metrics……Dropwizard metrics が REPL上で見られる

  3. REPL……サーバの操作、コンパイル、ルートの表示、メトリクスの表示、remoteのアプリケーションとの接続


ただし JShell では動いていない

動いているプロセスにアタッチできないため。多分Java10で対応予定


依存ポリシー

極力少なくする。コアは javaee-api と slf4j-apiのみ


Component

アプリケーションの状態を管理するもの、状態を安全に開始・終了できるもの


特徴


  • Singleton scope

  • Field injection

  • Start/stop lifecycle


利用可能 Component


  • Underrow/Jetty

  • HikariCP DataSource

  • Doma2 OR Mapper

  • Flyway DB migration

  • Freemaker/Thymeleaf HTML templating(Thymeleaf はテスト不十分)

  • Jackson Bean converter

  • Metrics Metrics


Controller


  • Field injection……Component

  • Parameter injection


Session


  • In-memory store

  • JCache

リクエストセッションとレスポンスセッションが分離されているのが特徴


Conversation

入力-確認-完了のような遷移でIDを発行し、それに状態を持てる


Routing

Rails-like


Content Negotiation

RESTful API を簡単に作ることも可能……JAX-RSの BodyWriter, BodyReaderがそのまま利用できる


Amagicman(アマジックマン)

Yeoman的なものをJVMで作った。テンプレートはPure Javaファイル


まとめ


  1. Java でもこれを使えば REPL-Driven できそう

  2. 仕事で Java 使わなければいけない Clojure 好きはぜひ

  3. JavaEE か Spring かという方もポートフォリオに加えてほしい


参考

enkanとkotowari 〜 Java9時代の新しいマイクロフレームワーク


質疑応答


Q.Component と Middleware の違いについてもう少し詳しく

A. enkan は基本 Middleware の chain だけで上手く動くが、グローバルな状態を持っておいてアクセスしたいときにComponentを定義する。

なので特化したものが主


Q. Transaction を宣言的にした理由は?

A. そこはまだちゃんと実装されていないところ、現在 Doma に依存しているので将来的に設計を直す。



感想

休憩が増えたおかげで、体への負担が大分減ってセッションに集中できました。今回も質の高いセッションが多く、いろいろと勉強になりました。スタッフと発表者の皆さん、ありがとうございます。秋の開催も楽しみにしています。



宿題


  1. Frisby

  2. Redpen

  3. javapackager

  4. ENKAN(円環)