JJUG CCC 2018 Fallにいってきましました #jjug_ccc
はじめに
JJUG CCC、3回目の参加でございます。
前日から部屋割りのスプレッドシートをみながら朝から最後まで見たいのばっかりだなぁとワクワクしていたのですが、
朝方までスマブラをしていて11時頃に起きるという高度社会性ムーブをキメさせていただきました。
朝からすごい落ち込みました。
というわけで、13時会場到着。
(ビルの一階でオシャレ生クリームドリンクを飲んでたのでさらに時間ギリギリになった)
今回はちゃんとパソコン持って行ったので、セッション毎に聞いていた時の感想を無編集でそのままお届け。
(懇親会でビールを沢山いただいたので早く寝たい)
思考停止しないアーキテクチャ設計
思考停止しないアーキテクチャ設計 ➖ JJUG CCC 2018 Fall
一番広い部屋のはずですが、立ち見が出るほどの人気でございました。
最近、新規のWebアプリ全体のアーキテクチャ設計をする機会があって、見よう見まねでとりあえずそれっぽいものを作ったのだけれども
これでいいのだろうか…と思っていたので非常に惹かれるセッション。
非機能要件…品質特性シナリオのフレームワークで定義する
可用性の戦術、異常の検知、リカバリ、防止の手法を検討する "software archtecture in practice"という書籍からの引用
品質特性間のトレードオフ、すべてを取りに行くのは難しい
アーキテクチャパターンとは戦術のパッケージ。MVC マイクロサービス
WebでMVCやろ、マイクロサービスにするほどドメイン領域広くないから1サービスでやってこ！みたいな決め方をしていたけど、
本当はこのように段階を踏んで評価をしないといけなかったんだな…これがなんとなく自分の決断に不安がある原因なのかな
archtecture decision records ソースリポジトリと同じところに1つの意思決定単位に記録
意思決定の経緯を残すのは大事だなぁ…
リリース後しばらくたった時に技術環境がかわって、なんでこんなダサイことしてんんだコレって時に貴重そう
ドキュメント類、ソースリポジトリと同じところに置くというは私もやってて、これはすごく便利
判断ポイント
求人サイトのメニューのカテゴリごとの件数の例
これって、機能設計というか機能要件というかを詳しく聞かないとならんですよね
何をやりたいのかを知らないとアーキテクチャが決まらないというは分かるのだけれども、どこまで機能を聞き出せばアーキテクチャ設計をできるレベルになるのかな
アーキテクチャ要求のパターンを「アーキテクチャ大全」として執筆中
すごいほしい…まれによく見る柔軟な設計
これ、あるあるですね…
そもそもマスタのメンテ職人が発生するのでよくない
頻繁にかわるマスタはユーザでもメンテできるレベルにしたいよね
データパターンが網羅的にテストできるか
よくわからないけど、いろんなデータが入れられるよ。はつらいのでこの判断基準はよさそう
技術的負債を金額換算する
サービスにとって価値があるものにGOが出やすく、こういったタスクは後回しになりがちなので、金額換算はとても分かりやすくてよさそう
やらないことによって起こる不都合を説明してもイマイチ、プログラマー以外にはわかってもらえないので悩みだった
顕在化する確率、この計算式が納得してもらえるのかがカギっぽいですね
複雑なドメインに泥臭く立ち向かう
複雑なドメインに泥臭く立ち向かう - Speaker Deck
タイトルに惹かれまして。
簡単な図なのにすでにウッってなる関連だ…
これが複雑なというものドメイン…レベルが違いすぎる
一本道を見つける。
ドメインの最小単位、実現したいことの最小単位をみつける変化を当たり前にする
常に変化している状態にして体を慣らす
確かに一度リリースしてしばらくたつと、変更するのがちょっと怖くなる
毎月少しずつ変更しているアプリは抵抗感があまりない
カスタマーサポート、運用の人、業務に近い人と仲良くしていくことでドメインに詳しくなる
これは思う。実際に使ったり、使われ方を理解している人に聞いてみると意外過ぎる事実が明らかになることが多々ある
ユーザーストーリーマッピング
あとで読む
課題管理、すぐに残す
忘れがち…
ドメイン モデルベースで考える。 複雑なものは、どんなアプローチで設計しても複雑なまま 人間に理解できるようにコードを書くのが大事。 モデルベースにするとドメインの理解ができてないとコードが書けない
モデルの抽出
私の場合(ユーザ側から要望がある場合編)
* 現状の観察(ユーザが使ってるスプレッドシート、道具をひたすらに観察する)
* 単語の抽出 -> 単語の意味の確認
* 観察の結果の発表 -> ツッコミをもらう
* ドメインの知識として書き出す
これを繰り返してドメインの設計書を鍛えていく方法をやっている
設計のためのテスト
モデルベースは実現したいことを見失わないことが大事
たしかに、なにがゴールなのかを事前に考えるのは必須だと思う
命名
第二言語への置き換えをすると、ドメインへの理解が加速する
主語の明確化を意識する(誰にとっての行動なのかを固定する…？)データと情報
ちょっと理解できたか不安なのです
データは見る人(立場)によって変わるというのは理解できました
円形の席環境
すごおおおおおおおおおおおおおおい、うらやましい…
島になっていて立ち上がらないと集えないし、狭いし大きいディスプレイないし…
会議室つねにパンパンだし…
モブプロ
練習で一回やってみたのですが、進め方を工夫しないととか、口を出したがりがいないと難し印象
一番得意な人がだんまりだと、全員の最大が出せないことがある
短いサイクルでイテレーティブに区切る
軌道修正がとりやすい
1週間単位でできるタスク単位を見切るのが難しい
どうしても積み残しが増えがち
動くものをつくらねばならない、振り返りでデモをする
モデリングを延々とやるのは楽しいからやっちゃうんだけど、価値をださないとねということ？
デモをみんなに説明することで、OKRとかでやっている金曜日に成果をドヤリングするやつにも繋がりそうですね。
Migration Guide from Java 8 to Java 11
AWSで動かしてたり、Dockerで動かしてたり、Kotlin書いてたりすると、何をどうすればいいのかよくわからなくなってくるけど、少なからず影響あると思うのですよね。
趣味のプログラムとかで、調子に乗って11とかにするとスナック感覚で動かないですし…
非互換性
@Deparcated指定から期間を置いて削除されるが、LTSから次のLTSに変更する場合は数バージョンを飛ばすのでいきなり消えるように見える。
8から11みたいに飛ばすといきなり消えるぞということか…
とくにこだわりがなければ各バージョンごとにリリースノート読んで、バージョン上げたほうがよさそうだなぁ…
コンパイルしないで動かす
オプション
削除されたもの、廃止されたもの、非推奨、GCログにおいて対応が必要
GCログ以外は代替がないので、削除するCORBA ModulesとJava EE削除
代替ライブラリを使う
--add-modulesでの対応は、Java11以降モジュールごと削除されているので使えない
JAXBを使ってるところがあるので、JAXBとJAFを入れる必要がありそう
JavaFXの削除
悲しいなぁ…
Internal APIsの削除
sun.,com.sun.,java.awt.peer
根本的には使わない、代替手法に切り替える
しかし、Java 8、Java 9以降両方で使えるようにするためには、リフレクションで移行前を読んで例外吐いたら代替手法
つらそう…下位互換を維持しつづける限りInternal APIsの削除を追い続けないといけないのか…
Applet、Java Web Startさようなら
悲しいなぁ…
最近GC種類多すぎやんな…
コンパイルしなおす場合
ライブラリ、プラグインの更新
うん、バージョン最新以外動かないとか結構あって大変なんですよね…
ライブラリ、プラグイン更新によってさらに、別の更新が必要になって…という連鎖がアツい。
FindBugsは悲しい事件でしたね
ジョナサン
すんごい眠くなってきたので、懇親会までジョナサン。
懇親会
相変わらずの孤独の懇親会。
個人的にはこのビールカップが素敵で気に入りました。
余っていたカップをいただいてしまうほどでございます。
会社の勉強会でありがたく使わせていただきます。
申し訳程度にビールのスポンサー殿のリンクを貼っておきますです…
