JJUG CCC Fall 2017に行ってきました
JJUG CCC Fall
まえがき
自分用のメモではありますが、役に立つ人がいるかもしれないと思いメモったことと簡単な感想をブログに乗せておきます。 間違いに気づいたら後から訂正しますが、速度優先と自分用メモなので正確な情報は登壇者があとからあげているスライドを見ることをおすすめします。
Selenide or Geb ? あなたはその時どちらを使う？
はじめに
Codezin
- selenideとgebの本が出る
概略
Selenide
- エストニアのcodeborne社のandreiが作ったJava製WebDriverラッパー
- DSLを用いたjQuery風セレクタ
- IDEによる補完機能を駆使
- 要素取得時の待ちを暗黙的に行う
- AJAXなどの非同期処理の返りの処理記述が容易
- 呼び方は？
- せれないど？せれにど？
- 英語だと「せれにど」、ロシア語だと「せれないど」
- 製作者的には「どっちでもいい」
- 日本語だと「せれにど」だからせれにどでいいのかなぁ
- 英語だと「せれにど」、ロシア語だと「せれないど」
- せれないど？せれにど？
Geb
- 読み方は「じぇぶ」
- Groovy製のSeleniumラッパー
- バージョンは2.0
- DSLを用いたjQuery風セレクタ(selenideと一緒)
- groovyの機能をふんだんに利用した、簡潔な記述が売り
- selenideよりもより簡潔にかける
selenide Pros and Cons
Pros
Cons
ちょっと質問
geb Pros and Cons
Pros
- 簡潔な記述
- 豊富な機能
- 豊富なエコシステム
- 特にgradleか
- 日本語情報はselenideよりも多め
- 簡単に利用できる
Cons
体験談
初めてのSelenium(Selenide)
Jenkinsで不安定
- 手元で通るのにJenkinsだと失敗
- デフォルトで待ち処理が入ってるのに。
- 録画機能などを使わないと原因追求が困難
- 生のSeleniumよりましだけど、安定化はやはり大変
- 画面キャプチャが残る
- キャプチャじゃわからないような原因でfailしていたりする
- waitがうまく入らない、でハマる事が多い
- 都度都度waitを差し込んで対策していく
geb/selenideが話が出て来る文脈
- レガシーなシステムのQAコスト下げたい、とか
- QAは6時間が20分になるかもしれないけどシナリオのメンテナンスはしなきゃなので、それはそれで辛い
- シナリオを作り込むのにも時間かかる
マルチブラウザテストの導入
- マルチブラウザのテストがしたい
- クラウド上のブラウザでやりたい
- sauce labs
- GebConfigの書き換え(Driverの生成処理の変更)で実現でき、対応が楽
- Selenideも似たようなことができる
- Configと起動引数のどちらかが使える
- Selenideも似たようなことができる
ちょっとQA
- phantomjsが早い？
- seleniumはE2Eテストなんだからユーザが使う本物のブラウザを使いなさい
Selenide or Geb
外的要因
- groovyが使えるか
- 知名度／利用実績
- 実績はある
- Selenideは弱い
- 商用サポートの有無
- Selenideは日本語ではないが、商用サポートがある
- 今は問合せベースなので、サポートプランが具体的にあるわけじゃない
- gebはまったくない
- Selenideは日本語ではないが、商用サポートがある
読むか書くか
学習コスト
テスティングフレームワーク
さくっと動かす
- 対話環境
- Gebはgroovysh
まとめ
- コンテクストはさまざま
- その時時で良し悪しは変わる
感想
- 学習コストの低さという意味ではSelenideのほうが導入しやすそう
- jQueryライクということなので、どちらを使うにしてもそこは勉強すべきか
- QAコストを下げるために導入したとしても今度はメンテナンスコストが発生する
- ただし、シナリオが変わればテストケースも変更が入るのだからそこは相殺な気がする
- ただ、シナリオをコードに落とし込むところが時間がかかりそう
- エクセルでテストケース書くのに比べたらそれすらも楽しい気はする
Aapache Camel + howtio + Spring Bootによるモダンなインテグレーション・マイクロサービス
howtio
- 「ほーとあいおー」と読むらしい
AGENDA
- インテグレーションマイクロサービス
- Apache Camelとは
- インテグレーションマイクロサービスの作り方
- howtioによるモニタリング
インテグレーションマイクロサービス
- 賢いエンドポイント単純なパイプ(Smart endpoints and dumb pipes)
- マイクロサービスの中に連携するためのロジックが入り込んでくる
- 連携するためのプロトコルにはhttpやメッセージキューイングなどのパイプ役をライトウェイトな技術をを使っていく
- SOAはEnterpriseService Busと言われるプロセスが間に入って、各サービスを統合する
- MSAでは各サービスの中にルーティングのロジックが入ってる
- 他のサービスをいろいろ叩いて一つのサービスを提供するようなものを出て来る
- そういうのを指してインテグレーションマイクロサービスと呼んでいる
- SOAではインテグレーションスパゲッティと揶揄されてアンチテーゼだった流れからESB導入された
- 揺り戻しっぽい
- 他のサービスをいろいろ叩いて一つのサービスを提供するようなものを出て来る
- MSAを推し進めると各サービスが十分小さくなり、それを担当するチームなら十分複雑さに立ち向かえるだろうという流れがありそう
Apache Camel
- 軽量なインテグレーションフレームワーク
- camel-core.jar 4.8M
- 直感的なルーティングDSL
- 流れるようなインターフェース
- Enterprise Integration Patterns
- 軽量だが汎用性も高い
- 280+の接続コンポーネント
- まだ日本で流行ってないようなものでも既に公式サポートされてたりする
- GUI開発環境(Eclipse)
- マイクロサービスのサポート
Camelでできることの例
Java DSL
- RouteBuilderを継承してconfigure()メソッドをoverrideする
- fromは一つ、toは複数書ける
- ルートの定義は、fromから始まるメソッドチェーンをまた書けば良い。
- 別のクラスを書いてもよい
- ALT JAVAでもOK
- Scalaとか
- Spring XML DSL
Enterpise Integration Patternsをサポートしてる
- システム間連携のベストプラクティス
- 65のパターン
例えばCONTENT-BASED ROUTER
- choice/whenで条件分岐できる
280+のコンポーネント
- 殆どの物があるので見つかると思う
ECLIPSE プラグイン
- Intellijにはない
インテグレーションマイクロサービスの作り方
CAMEL Spring Boot
- Spring Bootプロジェクトを作成
- CamelコンポーネントStarterを依存に追加
- @ComponentをつけたCamelルートを定義
ComponentをつけたCamelルートを定義
- RouteBuilderをかいて@Componentをつければよい
- xmlでやるときは@ImportResourceで。
howtioによるモニタリング
JVMの監視といえば
howtio
howtio x Spring Boot
- 依存に追加するだけ
Demo
- Camelのサポートが充実している
- グラフィカルにルートを見ることができる
QA
- 単体テストのサポートはどんなふうになってる？
- あるよ。CamelTestSupport
- 失敗談や落とし穴は？
- コンポーネント毎に癖がある
- 認証コードをどうやって渡すかとか、そこが超えなきゃいけないハードルではある
- コンポーネント毎に癖がある
感想
- パイプとなるprotocolを強く意識せずに透過的に扱えそう
- 調べる価値がある ‐ちゃんとCamelのサポートが熱い監視ライブラリの紹介があったのがとてもgoodだと思った
DDD x CQRS - コマンドとクエリでORMを使い分けた話
感想
- モデルが参照に引っ張られるって話は、「そうだよね！」って思った
- 参照にモデルが引っ張られてるな‐と思ったらCRQS（チックな）パターンを導入してみようと思う
劇的改善 CI4時間から5分へ〜私がやった10のこと〜
スライド
対象のアプリ
テストクラスの責務の明確化
Controllerテストのアノテーション変更
- こんな感じの表があった
| @SpringBootTest | @WebMvcTest | |
|---|---|---|
| 概要 | Spring applicationを起動してテストする | Spring MVC infrastructureをAuto-configurerdしてテストする |
| bean | 全てのBean | @Controller,@ControllerAdvice,@JsonComponent, Filter,WebMvcCOnfigurer,HandlerMethodArgumentResolver |
| テスト時間 | Webサーバまで起動するため非常に遅い | Spring MVCに必要なBeanしか登録されないため早い |
| 類似 | - | @JsonTest, @DataJpaTest, @JdbcTest ... etc |
ServiceテストでDIを使わない
- Service層はアプリケーション外とのやり取りがないようにする
- Springを使わない、シンプルなJunitテスト
- 依存しているオブジェクトはMock
RepositoryはfilterによるBean選択
- @MyBatisTestで必要なBeanのみを登録できるようになった
- 必要ならBeanをフィルタリングする必要はあると思う
負債となったテストの改善
- テストはある程度の規模の開発では爆発的に増える。結果、負債となる。
- ひとつひとつ潰すしかないよ
テストの削除
- 時にはテスト自体を削除する決断も必要
- 不安定
- 保守しにくい
- テスト責務が広すぎる
- 過度なもの
CIの再構築＆並列テスト環境の構築
- 性能が良くない社内サーバからWAWSへ（性能＆安定性UP）
- ジョブ数に応じて、AMIからNodeを自動生成するようにして自動でスケール
- RDS内部でスキーマを切り、Node毎に別の仮想DBを用意
- テストの並列実行が可能に
テストサイズの導入
- こんな感じの表があった
| Small | Medium | Large | |
|---|---|---|---|
| 時間的目標（メソッドごと） | 100ms未満で実行 | 1s未満で実行 | 出来る限り高速に実行 |
| ネットワーク | モック | localhostのみ | ○ |
| データベース | モック | ○ | ○ |
| 他システムへのアクセス | モック | 非推奨 | ○ |
| 実行タイミング | プルリクエストごと | ベースブランチにマージ | 任意、またはリリース毎に |
$ mvn -P Small $ mvn -P Mediam $ mvn
プルリクエストFeedBack
- プルリクエスト単位でCIの結果をフィードバックできるようにした
- Lintの指摘(lint-review)
- カバレッジの可視化(CodeCov)
- 負債の指摘(SonarQube)
- チーム独自のルール(Danger)
感想
- テストサイズという概念を知ることができてよかった
- 普段テスト書くときにモックするかどうか悩んだりするけど、自分がどのサイズのテストを書きたいと思っているのかで判断してもいいかも
Spring Securityにできること・できないこと
- スライドが既に公開されているので細かいメモは割愛
感想
- とても良くまとまっていて自身の知識の整理になった
- Spring Securityが具体的に何に対してよしなにやってくれてるのか把握してなかったが、そこが明確化された
- opengl 8080さんのQiitaの存在をしれたことも良かった
- いろいろなことをよくまとめてあるので、眺めると勉強になりそう
入社してから運用しているサービスの運用改善奮闘記
- スライドが既に公開されているので細かいメモは割愛
感想
- The Twelve-Factor Appという言葉をしれたことが良かった
- frontend maven pluginなるもののgradle版はあるのか疑問
- あとで調べてみる
- guageが良さそう
- 部品をエンジニアは書くけど、それを組み合わせたシナリオを日本語で非エンジニアにシナリオ書いてもらえたりする
- それでも抵抗はあるだろうけど、非エンジニアにテスト参加させられる
- まだベータなのが残念
- 部品をエンジニアは書くけど、それを組み合わせたシナリオを日本語で非エンジニアにシナリオ書いてもらえたりする
Spring BootとKafkaでCQRSなアプリを動かしてみる
CQRS
- Command and Query Responsibility Segregation
- コマンドクエリ責務分離
- named by Greg Young
- だいたいマーチン・ファウラーがかかわってる
- コマンドとクエリを別のオブジェクトに分ける
- 更新するやつはvoid、クエリは副作用無いようにする
- クラスを分ける
- コマンドとクエリを分けるという点だけがCQRSの定義
今日のお話
- 業務で使いたいことを勉強してることを発表
今日のゴール
- CQRS面白そうっておもらいたい
第1話：僕とDDD
DDDの印象
- 依存関係を切り離して複雑さを閉じ込めているっぽい
境界づけられたコンテキスト
- コンテキストを切り離す
ドメインモデル
- DBやUIに関係することを切り離す
集約
- 他のモデルから切り離す（トランザクションの単位）
まとめ
- 複雑さを凝縮
感想
- DBからの開放、最高
- UIからの開放、むずい
- 複数の集約を繋いだ情報が必要だったり
- 集約から導出した値で検索が必要だったり
第2話：CQRS
- 書き込みも参照も一つのモデルにとらわれる必要がない！
- DB分けても良いし
- Query側にはDomain Modelを置かないという方法も取れる
- 書き込み用のモデルが参照のモデルに引っ張られてたな、というのはある
- クエリからの開放！
第3話：僕とDomain Event
- コンテキストや集約を切り離したら、これまでトランザクションで繋いでた情報をどうやって伝えよう？
- ドメインイベントでつなぐのが良さそう
- 何かが実際に起こった、という事実をモデル化
- CoffeeOrdered
- CoffeeBrewed
- CoffeeDelivered
- 発生したイベントを受け取って情報を更新していく
- 内部の動きを想像するんじゃなくて起きた事象をベースにするとビジネスの人とでも会話できそう
- ドメインイベントでつなぐのが良さそう
第4話：僕とEvent sourcing
- 状態自体を書き換えるのはステートソーシング
- きっとみんながやってる方法
- イベントの積み重ねによって今の状態があるという考え方がイベントソーシング
- でもこれやるとクエリ困る
- ここでCRQSが出てくる
- イベントストアにイベントを入れてき、そのイベントを拾って今の状態を持つデータベースを持つ
A Decade of DDD, CQRS, Event Sourcing
- CQRSはEvent SourcingへのStepping-Stone
- CQRS/Event Sourcingを全体に適用しない
- いろんな実現方法が合って良い
- 複雑なので実現にはコストがかかる
- 必要な箇所だけに局所的に適用していったほうが良さそう
CQRSとEvent Sourcingはセットなの？
- 共生関係にはあるけど、別々の考え
- 組み合わせると2PCなくて良さそう
第5話：僕とCQRS
- 似たようなことやってる
- クエリ油のDB
- レポート用のテーブル
- サーチは別のシステム
- トリガーはさまざま
- DBに保存するときに頑張る
- 定期実行のバッチ
- APIを呼び出したり
- それもいいね
- ドメインイベント駆動型でもやってみたい
第6話：CQRSとKafkaとSpring Boot
Messagin System
- kafka
- 過去の分も残ってるのがなんかいいなって。
感想
- domaはDDDと親和性が低いかと思っていたが、コマンドとクエリを分ける方法なら逆に親和性が高そう
- 2PCを回避する方法って何かないかな
CPUからみたG1GC
感想
- 難しくて正直ついていけなかったが、よくわからない（デフォルトだから）G1GCにしとこうという安易な考えは危険だってことだけはわかりました。
以上。
