簡単に所感をまとめます。セッション資料はどこかで公開されるはず。
Selenide or Geb？ あなたはそのときどちらを使う？
- Selenide
Selenideのメリ/デメ
Gepのメリ/デメ
- Selenideより細かい制御ができる
- Groovy/Gradleの知識が必要
- IDEの補完は効きづらい
ローカルでは動くのにJenkins上では落ちることがある
- おそらく環境依存などが原因 (jsのロードが遅れるなど)
- Selenideは失敗して落ちるとスクリーンショットとHTMLが残る
マルチブラウザテスト
- GebConfig上でWebDriverの生成処理を変更することで対応
- Selenideも設定ファイルでWebDriverの生成処理を変更することができる
PhantomJSやChromeのヘッドレスモードを使ってテストする
- E2Eのテストなので実際は本物のブラウザでテストするべきという考えがある
読むのを楽にしたいか/書くのを楽にしたいか
- 書きやすさならSelenide
- 読みやすさならGeb
- SelenideはIDEのサポートがあるので取っ付きやすい
- Gebは学習コストがやや高め
- Selenideはテスティングフレームワーク (簡単なアサーションはある)
- GebはSpockなどと組み合わせる
最近、Selenide を試してみたところだったので話が聴けてよかったです。両方ともIDEのサポートはあるものの、Intellij IDEA との親和性が高そう。書くのをラクにしたいか、読むのをラクにしたいかで選べばよい、とのこと。確かに、Selenide は書きやすそうな印象。非同期処理に対する記述のところは調べておきたい。
Apache Camel + hawtio + Spring Boot によるモダンなインテグレーション・マイクロサービス
- インテグレーションマイクロサービス
Smart Endpoints and Dump Pipes
- マイクロサービス自体に他のサービスと連携する機能を持たせる
- ルーティングロジックがエンドポイント(各マイクロサービス)の中にある
- パイプはシンプルにする
マイクロサービス間が連携したらスパゲッティにならないか
- そのために Enterprise Service Bus がある
コンウェイの法則
- サービスと開発チームが小さくなる
- インテグレーションはスパゲッティになるが、個々の開発チームはシンプルになる
Apache Camel
Content-Based Router
- コンテンツの内容に応じてルーティング先を決める
- choice / when / to
hawtio
- Angular 1.x + Jolokia ベースの監視ツール
- HTTP/JSONで通信
- Spring Boot 連携 (監視用のポートで起動する)
- Camelサポートが豊富
- ルーティングがグラフィカルに見れる
- やり取りしているメッセージが見れる
Camelのテストフレームワークでルーティングのテストができる
- コンポーネントが多いので選定などは大変っぽい
マイクロサービスの開発自体あまりなく名前程度しか知らなかったんですが、Apache Camel はよさそうです。機会があれば使ってみたい。hawtio は初めて聞いた。
DDD × CQRS - コマンドとクエリでORMを使い分けた話
- CQRS
- コマンドクエリ責務分離
- 単独でも適用可能
- イベントソーシングと組み合わせる必要はない
書き込みと読み込みのモデルを分離する
従来は単一のデータストアで同じモデルが読み書きを担う
- 1モデルの処理が複雑になる
そもそも読み込みと書き込みの要件は異なる
- パフォーマンスを求められるのは参照系
1モデルに詰めるとどこかで無理がでてくる
モデルを読み書きで分離する
データストアを分離する
- 参照系は read-only なレプリカにするなど
イベントソーシング
- すべてのアクションをイベントとして記録する
- 既存のデータはupdateしない
- Writeモデルはイベントとして記録される
- Readモデルはイベントから変形される
- 読み込み書き込みそれぞれの要件に合わせてORMを選定する
- JOOQ
- Writeモデルの制約はコンストラクタと公開メソッドで実現する
CQRS についてはよく分かってないマンですが、読み込みと書き込みでモデルを分けるというのは参考になりました。特に要件に合わせてORMも分けるというのは思い付かなかった...。
劇的改善 CI４時間から５分へ〜私がやった１０のこと〜
- R-SET
CIは10分で終わらせるのがいい (遅くとも20分以内が望ましい)
レイヤごとにテストの責務を閉じる
- RepositoryとRDBはまとめてテスト
- Controllerのテストは
@WebMvcTestにする@SpringBootTestはすべてのBeanを登録してアプリケーションを起動するので遅い
- ServiceレイヤのテストではDIは使わない
- Springの機能は使わない (RepositoryはMock化する)
- RepositoryはFilterでBeanを選択する
@MyBatisor@MyBatisTestで必要なBeanのみを登録する- MyBatisに限らず必要なBeanをフィルタリングするのは大事
- テストサイズ導入, テストサイズによる実行タイミングの分割
たぶん、無駄なテストを改善する/除去するというのが最も効果ありそう。テストサイズについては初めて知りました。あとで調べてみよう。
Java SE 9の紹介: モジュール・システムを中心に
Maven, Gradle を使っても複数バージョン混在地獄は解決できない
- jarファイルの名前しか見ないため (中身までは見ない)
モジュールシステム
- モジュール単位で依存関係を整理する
- 内部パッケージの使用を制限する
- 複数のモジュールで同一パッケージが含まれる場合、JVM起動時点で検知される
module-info.java
- 外部に公開するパッケージは exports 命令で指定する
- 自分が使うモジュールは requires 命令で指定する
- requires したモジュールの exports されたパッケージの public なクラスが使える
- それ以外を使うとコンパイルエラー/実行時例外
標準ライブラリである java.base モジュールは暗黙的に requires される
モジュールシステムはリフレクションにも適用される
- opens 命令で外部からリフレクションでアクセスできるようになる
- モジュール宣言に open を修飾するとすべてのパッケージが opens 指定される
モジュールパスとクラスパスは別
無名モジュール/自動モジュール
ライブラリ提供者はすぐにモジュール化すること
- 使う側が requires 命令を書けない
Properties クラスは Latin-1 のまま
この日、最も聴きたかったセッション。モジュールシステムの概要が分かってよかった。要復習。なんとなく、ちゃんと作ってるライブラリであれば、モジュール化はそこまで難しくなさそうな印象。
その他
今年春のCCCは参加できなかったのですが、参加人数が多くてかなり混雑してた模様。今回は、前回より参加人数が少なかったのか、それほど混雑は感じられませんでした。というか、通路が一方通行になってたりいろいろ工夫されてたのがよかったのかも。移動がいつもよりずっとラクでした。
