JJUG CCC 2018 Fall 行ってきた ｜ Advent Calendar 2018
IT系の勉強会行ってきた Advent Calendar 2018 - Adventar の24日目！
あなたとJAVA,
今すぐダウンロー
ド
Spring Boot の Web アプリケーションを Docker に載せて AWS ECS で動かしている話
- Javaの話というよりAWS ECSなお話
- 複数のDockerで開発するならPCのメモリは16GB以上欲しい
- デプロイしてすぐに使えるわけではなくdrainingにかかる時間を考慮する
- プロファイルによる切替 + 環境変数の利用でそれぞれの環境に対応
GraalVM超入門
- Graal/GraalVM ： 多言語用の仮想マシン
HotSpotVMのC2部分がGraalというものに置き換わってる - Polyglot ： 多言語間でのやり取りを可能にする
- NativeImageを作れる。OneBinaryが出来る。起動速い
- リフレクション等を使っているものだと外部指定項目が多く辛みがある
- まだRC版なので進化の途中
思考停止しないアーキテクチャ設計
- 非機能要求からアーキテクチャ設計、品質特性(6項目)
- 品質特性間のトレードオフ、アーキテクチャパターン間のトレードオフ
- プロジェクトの時間 = 開発時間 + アーキテクチャとリスク軽減時間 + やり直し時間
- アーキテクチャ設計の評価 → Rubrics
- Architecture Decision Records、アーキテクチャの意思決定を記録しておく
- 教科書どおりの手順を踏んでいても漏れが発生してしまうことはあるので思考停止しない
- 現代においてアーキテクチャ設計は終わりのない仕事である
複雑なドメインに泥臭く立ち向かう
- 複雑な要素色々、アンコントローラブルで自分たちで制御不能な要素の存在
- 複雑なドメインにどう立ち向かうか？
一本道を見つける - Not 要求の洗い出し、価値提供の単位
But ドメインの最小単位 - ドメインの学習、実務のロールプレイ や ユーザーストーリーマッピング
- 課題管理、必ず残す。考えるのを後回しにするならそのことを明記
- モデルベースのアプローチ
要求 → 概念 → モデル 設計実装の抽象化
複雑なものはプログラミングにしても複雑になってしまう - 設計のためのテスト
実現したいことを見失わない、動作するものを改善していく
品質保証のテストではない。テストを書くことで最初のユーザになれる - 命名について
英語への置き換えて説明がわかるか確認。主語を明確にし単位数は何か - 複雑なものは知識ギャップが生まれやすい
→ モブプログラミング。最高速度が出しやすい。新人の受け入れに強い - ときには腐敗防止層を設ける
汚れ役の層を持ってキレイな部分を保つ
既存アプリケーションでKotlinを導入してみた
コードをどまんなかに据えた設計アプローチ
- 設計：作るものがないと作り始められない
コード：設定もコードだと思えば必要
ドキュメント：必ず？いつ？なぜ必要か？
手戻りしないようにドキュメントで合意してから進めたい
メンテナンスの為に、伝える為に必要 - ドキュメントの代わりにコードではダメなのか？
- コードに軸足を置く、コードで設計したい
- 設計には意図がある
コードは動くことが前提のもので設計意図を100%が反映されてないときもある - Java Instant-document Gazer 作ってみた
- 型に意図をこめる
Javaを使うのだから静的に決定させコンパイラに全力で仕事をさせる
DRYじゃなくなる。クラス作るの面倒。大量に増える。
→ 業務で扱うものは複雑なもの！
全体的に学びがあるセッション多かった。
帰るときに気づいたけど、近年はJava要素が殆どないセッション聞いてる。
