経緯
いつも参加しているので、もう定例行事みたいなものになっているので、見かけたら取り合えす参加。
いつものことだけど、新しい視点を手に入れられないかという気持ちで参加した。
また、今回は久々のオフラインのイベントだったので、空気感を味わってみたくて現地に足を運んだ。
自分は、午前中だけ現地に行って、午後は自宅に帰宅してyoutubeで見てた。
水星の魔女を早く見たかったのと、推し活のために帰った。
公式サイト
JJUG CCC 2023 Spring - 日本Javaユーザーグループ/Japan Java User Group | Doorkeeper
JJUG CCC 2023 Spring（会場開催）｜EventRegist（イベントレジスト）
参加したセッション
- 金融系子会社でレガシーシステムしか作ったことないけど、モダン開発に挑戦してみた
- Apach Commons Mathを使って機械学習
- GraalVMでのFlight Recorderを使ったパフォーマンス解析
- SpringBootでメッセージキュー&非同期処理を使ったノウハウ紹介
- AI を利用した Java 開発の最新情報
- Virtual Threads - 導入の背景と、効果的な使い方 -
まとめも
金融系子会社でレガシーシステムしか作ったことないけど、モダン開発に挑戦してみた
独自FWで開発 リファクタリングもあまりしなかったため、技術的に置き去りになる現場になっていた 開発者の能力向上に寄与できない現場だった
顧客承認が必要で、不要な変更を避けがち 結果、技術的な遅れ、開発者の向上心の阻害していた
取り込み内容
- 技術調査から着手
- 大事なこと
- 知識の習得と実践はセットで実施
- 考え方を変えるのが辛かった
- 手続型⇨DDD
- 文化の壁
- 学ぶ文化の醸成
- 公式ドキュメント
- 資格取得
- チャレンジャー
- 専任化
- 学ぶ文化の醸成
- 文化の変更
- １年サイクルでは難しい
- マイクロサービスが銀の弾丸ではない
チーム構成
- 20代後半
- マネージャー層１名
プロジェクトの開始は、上層部が感じてた危機感
進め方
感想
自分もレガシーシステムの入れ替えの現場に参加中
きっかけは、上層部のセキュリティリスクを考慮から始まった。
一番苦労してるのは、現行の機能を落とさずに移行すること。
機能が古すぎて、ツールによる以降ができないのが、むちゃくちゃ大変。。。
テストで担保しようとしているけど、かなり厳しい。
また、現行の理不尽ロジックで泣かされそう。。。
進捗管理等のマネジメントもしてるけど、メンバーの習熟度がすごく気になってる。
次期のシステム構成とかの構成図がなかったから、自分でなんちゃってUMLを作って展開資料作ったけど、理解しているのかすごく不安になる実装だったりドキュメントが多いのが気になる。。。
おそらく、共通認識を確立して進めないと、結構問題になるような気がするってのを、聞いてて感じた。
銀の弾丸を、シルバーヴァレットって読んでたのがカッコよかった。
中二病の琴線に触れた。
遊戯王VRAINSのリボルバーが使ってるカードにありそう。
今度から、俺も銀の弾丸って言うときは、シルヴァーヴァレットって言おう。
Apach Commons Mathを使って機械学習
やってみた感想
- コード量はpythonと比べて多い
- 可読性はそこまで悪くない
Javaで数学
- Apatch
- Math
- Numbers
- Geometry
- DeepLearning4J
- MOA
- Weka
Apatch Common Math
- 行列演算、確率・統計機能もある
- クラスタリング
- 数理最適化
- 最終更新が2016で終わっていて、メンテされてなさそう。。。
アヤメの分類
登壇者がやってみての感想と質疑応答の内容
感想
Javaにも図の描画ライブラリなんてあったんだな。。。
初めて知った。
たぶん、自分がやるなら、エクセルとかつかってやりそう。
もしくは、画面表示周りは、npmライブラリ使って、描画は他に任せる気がする。
悪用すれば、図形で絵がかけそう。
ソースをチラ見していたが、recordクラスは、入れ物として使っていたのを見て、やっぱりそう使うよねって思った。
GraalVMでのFlight Recorderを使ったパフォーマンス解析
GCのパフォーマンス
解放されないオブジェクトを追加して検証
- Native化したものは、ヒープの使用状況が見れなかった
- 見えない理由：GraalVMのイベント出力が対応されてないため
- 大替手段：GClogで代用可能
ロックに関する分析
- マルチスレッドで、排他制御を実施
ロック時間を長めで検証
Native化
- すべて同等の出力で検証可能
IOパフォーマンス
- GraalVMだと出力が未実装
コード実行パフォーマンス
バブルソートの処理時間が長めになる実装で検証
native化
チューニング手法
いま時点だと、Javaでチューニングしてからnative化になりそう
イベントの出力対象が今後増えれば、Javaの解析手法がそのまま使えるということが分かった
感想
GraalVMは、知っていたけど、ログの出力に差があるのは、初めて知った。
言っていた通り、native化する前で再現させて、パフォーマンスチューニングさせるのが正解だろうなとは思う。
使うには、もう少し時間を置いてからかもしれない。
SpringBootでメッセージキュー&非同期処理
アーキテクトの働き - 開発の維持 - 構造的な問題解決 - システムの安定稼働
非同期導入の背景
- メッセージキューを用いた非同期処理の話
メッセージキューのメリット
- 好きなタイミングで処理できる
- デプロイをタイミングを分けられる
- 疎結合になる
- メッセージキューの仕組みが高い品質で保たれている必要がある
- 考えることが増える
- エラー処理
- 再実行
- スケールしやすい
- 導入のハードルを下げて、実装難易度を下げる必要がある
非同期処理
- 指針の説明は、既存の設計方針から似通ったものを流用
- ネーミングも現行にある設計しそうから流用
SpringBoot+Amazon SQS
Amazon SQS：Amazon SimpleQueueService
ポーリングの仕組みの選択肢
Spring Cloud AWSについて
- プール数があるので、状況に応じて設定する
プロジェクト構成
- WebAPIのレイヤー構成は揃えた
- Controller
- Service
ノウハウ
- 扱いやすさの代償
- 一部システムで非同期を無視した実装ができてしまった
- 呼び出す側は、APIを叩くだけなので、非同期という認識が薄くなった
- 実装の簡略化はできたが、設計不備ができやすい状況になってしまった
- 一部システムで非同期を無視した実装ができてしまった
- 監視・スケール
- メッセージキューの状況がパフォーマンス状況になる
- メッセージキューの状態は監視する必要がある
- 水平スケールをやることで処理遅延の解消ができる
段階リリース
処理状況の確認
- 現在鋭利対応中
- ステータスの管理テーブルだけ作る構成をしている
感想
キューイングは、そんなに難しいものではないと思うが、開発者のレベルがバラバラなのだろうか？
抽象化とUMLによるしつこいくらいの説明でなんとかなりそうな気もするが、外野と当事者とは違うから、問題の見え方が違う気がした。
キューイングは、キューを見れば状況が分かるのがいいところだと思った。
監視対象があきらかになっているので、状況分析はやりやすそうだと感じた。
疎結合にしたことで、段階リリースが可能だったというのは、勉強になった。
疎結合のメリットはいろいろあるけど、リリースのメリットは、初めて理解できた気がする。
AI を利用した Java 開発の最新情報
デモで色々見せてくれたので、感想だけ書く。
やっぱり、指示の仕方が良くないと、結果が想定と違うみたいだな。
github copilotは、使ってもいいとは思うが、まだ業務で使うのは怖いな。。。 github copilot chatは、使っても良さそうだが、やっぱり情報漏洩等のセキュリティリスクが問題になってきそう。
問い合わせ部分は、AIチャット導入は進みそうだな。 少なくとも、いくつかのサイトでは、もう導入されてそうなUIだったりしている。
Virtual Threads - 導入の背景と、効果的な使い方 -
virtual thread
Threadの問題点
- 例外処理が難しい
デバックしにくい
threadの問題点を解決するためのvirtual Thread
- Virtual Threadの生成：Executors#newVirualThread
- 直生成もできるが、やらない方が無難
VirtualThreadの注意点
- synchronizedはなるべく使わない
- synchronized=モニタロック
- ボトルネックになる可能性大
- イミュータブルのクラスを活用し、状態の変更をを止める
- Callableを使う
- ReentrantLockを使えないか検討する
- ThreadLocalを使わない
- ミュータブル、ライフタイムが不明確
- ボトルネックになる可能性大
- FWの対応を待つ
- ミュータブル、ライフタイムが不明確
- スレッドを使い回さない
- 使い捨て
- スレッドプールは、ExecutorServiceに任せる
おすすめの本
Java並行処理プログラミングを勧めていた
