「JJUG CCC 2024 Spring」に参加してきました

勉強会メモ

知名度は高くないけど便利なJavaライブラリ集

Jilt

  • Builderクラスを生成してくれる
  • Lombokのようなマジックはしない
  • Records対応してる
  • @Builderでbuilderクラスが生成される
  • builderは必須項目がセットされてなくてもエラーにならない
    • コンストラクタよりunsafe
    • Staged Builderで解決できる
    • @Builder の引数で設定できる

YAVI

  • Yet Another Validation
  • makingさんが作ってる
  • 依存なしのタイプセーフバリデータ
  • BeanValidationは型を間違えてバリデーション設定しても気付けない
  • 基本は自分でバリデータを呼んで実行する
    • Springと使う時は @Validated で実行できるようになる
  • Arguments Validator

Logbook

  • HTTPリクエストレスポンスをロギングする
  • サーバとクライアント両方に対応
  • カスタマイズしやすい
    • 自分でロガー作ってる人でも置き換えやすい
  • springのstarterがある

NullAway

  • ヌルポを検出する静的解析ツール
  • 起き得るコードをコンパイルエラーにできる
  • defaultで全部non nullな前提で動く
    • nullを許容する時に@Nullable をつける
    • 一度付けると連鎖的につけないといけない

Spring for GraphQL の実践

GraphQLの採用事例

  • リニューアルでGraphQLを採用
    • 最終的な規模や複雑さは見えている
  • バックエンド間通信でもGraphQL
  • フロントエンドからは1つのGraphQLサーバが見えている
  • 最初はマルチレポだったがモノレポにした
    • GraphQLのSchema管理が楽
  • コード生成
    • DGS(Domain Graph Service)
      • Netflixが作ってる
      • これのcodeget機能をサーバ側では使ってる
    • Apollo

PCI DSSの観点から見たセキュアなJavaアプリケーション

  • Yoshihiko Minamiさん

PCI DSS

  • クレカ業界のデータセキュリティ基準
  • Payment Card Industry Data Security Standards
  • QSAの訪問審査を受けて認定される
  • 他のセキュリティ規格よりも要件の具体性に特徴がある
    • 内容が具体的
    • 即実行しやすいアドバイスが多い
  • アプリケーションレイヤーでは
    • 適切なコードレビュー
      • 手動によるコードレビューが求められてる
      • セキュリティに問題のあるコードが本番に出ないように
    • シフトレフト
      • CIで静的解析をして脆弱性が入らないようにする
    • ライブラリの脆弱性管理
      • SpringBootのバージョンをあげないといけないときにまとめて上がって大変
      • メンテされないOSS

条件分岐の多さと紛らわしい命名、先にリファクタリングするなら？ - Java ソースコードをみんなで読んで比べた結果

リファクタリングの課題解決

  • 対象が多い時一括してリファクタするのは困難
  • 90%以上は構造的な問題化命名的な問題
    • どちらを優先的に取り組めばいいか明らかにする調査
    • どちらがより有害か
  • それぞれの問題を含んだコードを呼んでもらってクイズに答える
    • 調査を受けたのは57人
    • 正答率とかかった時間と事後アンケート
      • 正答率は構造的の方が高い
      • 速度は有意差なし
      • アンケートは命名の方がわかりやすい
  • どちらから取り組んだ方がいいかのアンケート
    • 命名からの方が73%
      • リネームは動作に影響がない
    • 構造からの方が26%
      • こっちの方が致命的なバグが起こりやすい

テストコードが根付くチームを立ち上げるために考えたいこと

テストコード

  • カバレッジ100%を目指して作った
    • 追加開発で追従できずにignoreしたり消したり
    • その後またテスト書いたりとか負のループ
  • テストコードが根付いたチーム
    • 全員が日常的にテスト書いてる
    • テスト落ちるとすぐに直す
    • 日常的にリファクタしてた
    • ミューテーションテストもしてた
  • なぜテストコードを書くか
    • 自分の書いたコードに自信が持てる
    • 単に楽しいから
  • ナイステスト
    • 落ちてくれてありがとうと思えるテスト
    • 修正がダメなことにすぐに気付ける
    • これが増えてくると楽しくなる
  • 顧客親近性
    • ビジネスに対する関心親密さの高さ
    • これが高いとコードにも反映されてテストにも現れてくる

Spring Boot vs MicroProfile - クラウドネイティブにおけるフレームワークの比較と選択

MicroProfileとSpringBoot

  • MicroProfile
    • JakartaEEベースのマイクロサービス向けAPIセット
    • Jakarta##の動きが遅いから短期間で機能をリリースしていく
  • DI/AOP
    • アノテーションの名前が違うけど使い方は一緒
    • SpringはJavaConfigや設定でbeanを切り替えられる
    • bean定義の柔軟性はSpringがいい
  • RESTサーバ
    • ほとんど一緒
    • バリデーションはどちらもBeanValidation使える
    • JWTを使った認証
      • Springの方が柔軟にいろいろできる
      • MicroProfileであればベンダーの独自実装を使うしかない

WealthNaviにおけるObservability実践と、サービス改善への活用

Javaアプリの監視

  • テレメトリデータ
    • メトリクス
    • トレース
    • ログ
  • 可観測性
    • visualization(可視化)
    • insights(洞察)
    • actions(改善)
  • ログ失敗事例
    • ERRORレベルを安易に出して通知が止まらない
    • メッセージが分かりづらい
    • INFO過剰出力でパフォーマンス低下
    • 複雑な計算の途中結果を出力しすぎた

WelthNaviの事例

  • 構成
    • アプリはECS
    • DataDogに集約
    • PagerDutyでアラート
    • Slackへ通知
  • FargateからCloudWatchに流れてFirehoseでDataDogへ
  • DataDogであらゆる可視化ができる
    • ただし利用料金

イベント駆動アーキテクチャ導入の手引と共通の落とし穴

イベント駆動

  • イベント
    • Message Brokerにイベントを送る
    • キューは処理が流れるだけなので流れたら消える
    • ストリームは処理が流れてもそのままデータは残る

イベント駆動の落とし穴

解決策