JJUG CCC 2019 Spring に参加した

Java自体は殆ど書いていないので、どちらかというとコミュニティの雰囲気と、設計論的なところを見てみようと思って、参加した。

2019年05月18日なので、結構前の事っぽい。

www.java-users.jp

あとスライド情報はこちらから得られました。ありがとうございます。

sun0range.com

当日の振り返り

体調が悪くて、起きれなかったので午後入り。時間も微妙だったので、15時すぎに到着してちょっとスポンサー回ったけど、あまり印象に残っていない。

ただ、懇親会が1000円であることと、会場のスケールを考えると結構スポンサーがお金出してるんだろうなあとはなんとなく思いつつ、どういう会社が出ているのかはもう少しちゃんとチェックしておけばよかった。

セッションを聞き終わったあとは、懇親会に軽くでてスタッフの話を聞きつつ、久々に遭遇した人もいたので、ゆっくりと話して帰路についた。

聞いたセッションの感想

LINEのBOT Platformの裏側の話

スライドリンク： https://speakerdeck.com/line_developers/behind-the-line-bot-platform

これ全然知らなかったのだが、LINEのプラットフォームはJavaがメインらしい。ちょっと意外だった。あと、5ページ目のリポジトリ数が本当にやばくて、こんな数あるのかとびっくりした。あとは国際的に展開する会社なので海外拠点が複数あったりするのもグローバル感あってすごいなあと思った（あんまり想像がついてない）。

提供してる機能もそうだが、サービスを実現するためのアーキテクチャ構成がすごかった。（22ページ目）

以降は用語を拾いつつ聞いていたので、箇条書き。

SSE (Server-Site Event) by Spring WebFlux が重要っぽい
- リアルタイムな通信を実現するため（双方向通信でないので、WebSocketではない）
- WebFluxはNon Blocking Webフレームワーク
- Requestスレッドを専有しないので、Requestスレッドの数に通信数が制限されない（通信数が非常に多いアプリケーションなので、スケールが大事）
- 再接続時は最後に送ったもののリクエストを使う
- 全体的に賢い…！なるほど…！みたいな気持ちになる
Kafkaというミドルウェアがあるらしい
- 初めて聞いた
- https://kafka.apache.org/
- これをぱっと読んだ感じ、分散キューイングシステムらしい？ https://qiita.com/sigmalist/items/5a26ab519cbdf1e07af3
- 対障害性は高いが、それでも障害が起こったときのためにPrimaryとSecondyで冗長化
- Data Hubとしても使っていて、複数のConsumerグループにタスクを投げられるようだ
  - これがないと通信失敗を考慮してバッチで整合性を取る羽目になるが、もはやこの規模ではバッチで修正するのは無理
  - これなしでServiceAからServiceBにデータを投げるような形にすると密結合が進んでしまう
HBaseというミドルウェアがあるらしい
- 初めて聞いた
- https://hbase.apache.org/
- NoSQL系らしい https://www.publickey1.jp/blog/10/facebookmysqlcassandrahbase.html
- Facebookでも使われているっぽい（最新の記事は見てないので現在も使われてるか不明）
- 均質ではない、大量に書き込みされるが、あとでアクセスされることが少ないデータ管理に向いているらしい
モニタリングメトリクスはテストコードがないアプリケーションより怖い
- PrometheusでExportしてGrafana
- この辺は名前を聞いたことがあるが、いまいち使い方を知らない
- あとモニタリングメトリクスという名称を知った（概念としてこういうの図らないといけないなっていうのは理解していた）
- 概念の名前を知ることの重要性を再認識
ライブラリのアップデートの際にはついでにアップデートされるライブラリも見る
- かみ合わせが悪くなり、不具合が起こることもある
- 最新に追従しつつ、業務的な問題が起こらないように適切に上げていく

大規模システムを支えるためのものをワードレベルで拾いつつ、知見を高めることができたので非常に良かったです。

小さいアプリケーションでも立ててモニタリングメトリクスをどう確認するかとかもちょっと意識してみようかなあ。。。。

JJUG会長と一緒に考えたSpring Boot x JavaScript x IntelliJ x アジャイルというモダンな新人研修を今まさにやっている話

スライド： https://speakerdeck.com/masatoshitada/modern-new-employees-training-spring-boot-javascript-intellij-agile

研修をどうやるか、そしてなぜこの技術を採用したのか？みたいな話が中心だった。私自身は新卒時代（前の会社）で、いわゆるここに乗っている従来型研修に近い形のものを聞いていたが、いろいろ思っていることもあり、学びが多かった。

なぜ研修を刷新したいか？
- 現場で使っている技術との乖離が激しいため
- Webサービスを始めとして、いわゆるモダンな環境で開発する会社が増えつつあり、従来の研修では実用に即していない
  - 従来： Java 1.5, Stなんとか, JDBC, JSP, Excel ....
  - 現場: Java (新しい)、Spring boot, Git
- ExcelはやめてGitをちゃんとやりましょうね
- エンジニアとして成長するためには自分で学んでいくスキルが大事で、研修でのタスクをこなすことがゴールとしてはいけない
  - 研修の課題が終わったらあとはOKというのはあんまり望ましくない
  - 課題が終わったら互いに教え合うとか、応用したものを試すとか、そういうのが大事
技術スタック
- React + Spring boot
- フロントもバックエンドも両方体験してみるのが大事
- どちらの面からも考えてみる
- サーブレット、JSP、JDBCは扱わない
  - むしろこれを使うのは、ライブラリへのラッパーを作るような中級者以上
  - 研修で学ぶ学習者のレベルでは厳しい
進め方
- フロントエンド（10日前後） → バックエンド（13日前後） → 開発演習（スクラム、3イテレーション）
- 最初にフロントをやるのはCUIよりもGUI的に動いたほうが初心者の感動が大きいから
- プロダクトオーナーは受講者、スクラムマスターは講師で回した
Linterを入れよう
- ESLint, CheckLintを入れたら、例年の受講者よりコードが劇的にきれいになる
この研修を受けた人がどうなるか？
- Gitをはじめ、スクラム、チケット駆動開発も理解した状態で現場に入れる
- 学ぶ意欲が高いエンジニアになる
- リファレンスも読めるようになる
- まだレガシーな環境でやっている人には向いていないかもしれないが、良さそう

マイクロサービス：４つの分割アプローチの比較

スライド： https://www.slideshare.net/masuda220/ss-146325870

ちらっと面白そうだったので入ったが、上級者向けだったらしい。Javaの話はなかったが。

設計スキルに重きをおいた話
分散と言っても4つほど考えられる
- 負荷分散、リスク分散、データ分散、機能分散
- 機能分散メインの話
モノリスでもマイクロサービスでも設計スキルは一緒
- モノリスから、マイクロサービスに向かうこともよくある話らしい
- 関心の分離、高凝集・疎結合、モジュール化がキーワード
どこまで小さくするか
- コードレベルと、ミドルウェア・ハードウェアレイヤで異なる
- コードレベルならJavaはメソッド呼び出しレベルまで小さくできる
- ミドルウェア・ハードウェアレイヤ・運用レベルは構成要素レベルまでしか小さくできない
- よってコードは大胆に小さくしていき、ミドルウェア・ハードウェア・運用レベルは慎重に変えるべきである、ということ（非常に納得できる）
分割アプローチ4種類
- ビジネスファンクション（業務機能）
- 動詞（ユースケース）
- 名詞（リソース）
- 境界づけられたコンテキスト・ドメイン
- ちなみに正解は存在せず、これらをただ適用するだけでは大体実現不可能になる
ビジネスファンクションで考える
- 業務の活動単位を落としやすくなるが、サービス間が現実並みの複雑さを持ってしまう
- 組織を反映したような形になってしまう
ユースケースで考える
- 機能要求や開発単位の定義はやりやすい
- ロジックの重複や断片化が起こり、バッチ処理などで整合性を取る必要が出てくる
- 薄いユースケースサービス（入力を軽くして、サービス側で全部吸収する形）だとロジックの重複も減らせるかも、ってのは良さそう（図がわかりやすい…）
リソース単位で考える
- エンティティ＋CRUDでイメージがしやすい、データ更新に責任を持つサービスの明確化
- しかしリソースをまたがった参照は複雑になりがちで、異なる関心ごとの混在も起こり、肥大化する
- （普段僕が考えるときはここに行きがちな気がするので、もう少し別のアプローチも意識しようと思った）
境界づけられたコンテキスト・ドメインで考える
- これ実は非常に曖昧らしい
- エヴァンズの図と、パーノンの図が同じ言葉を使いつつも、完全に別のものを指している
- 他の人も概念レベルで話していて、ずれている可能性が高そう…
- （これは僕はあまり知らないので、エヴァンズの本を読まなきゃという気持ち）
ドメイン駆動設計のモデルを考える
- モデルとはビジネスルールである
トランザクション系の話
- うーん、難しい（あんまり理解できてない）
- 当日も時間が押していてサラッと行ってしまったので、じっくり読む