JJUG CCC 2018 Fall に行ってきた #jjug_ccc

Java メモ

JJUG CCC 2018 Fall に行ってきました。簡単に所感をまとめます。

www.java-users.jp

セッション資料は以下で公開されると思います。

GitHub - jjug-ccc/slides-articles-2018Fall: JJUG CCC 2018 Fall 登壇資料まとめ

今回は午後からの参加だったのですが、GraalVM とか午前のセッションでいくつか気になるものがあるのであとで見てみようと思います。

今回参加したセッションは以下の通り。メモから抜粋。

思考停止しないアーキテクチャ設計

www.slideshare.net

  • Classicalなアーキテクチャ設計
  • 非機能要求からアーキテクチャ設計☆
  • 品質特性のシナリオ
    • 特に環境の観点が抜けがち
  • タクティクス☆
  • 品質特性間のトレードオフ☆
  • アーキテクチャパターンはタクティクスのパッケージ
  • 代表的なアーキテクチャパターン☆
  • アーキテクチャパターン間のトレードオフ
    • 例) レイヤードはアプリケーションが巨大になりがちで、アジリティやデプロイ容易性は下がる
  • アーキテクチャに時間をかけると手戻りのリスクは減る
    • 時間をかけすぎてもいいものではない
    • コード規模によって Sweet Spot は変わる
  • 品質特性シナリオを使ってアーキテクチャ設計が十分が評価する
  • アーキテクチャの課題をいろいろな視点から見ることが大事☆
  • Architecture Decision Records☆
  • Architectural Significant Requirements (アーキテクチャ要求)
  • 非機能要求からのアプローチではなく、機能要求パターンからASRのアプローチ☆
  • デグラデーション
    • サービス全体のダウンを防ぐ
  • 柔軟さとテスト可能性のトレードオフ
  • 予期しないデータパターンによる不具合
  • 適度な柔軟さ (インタフェース)
  • 柔軟すぎる実装かどうかの判断☆
    • データパターンを網羅するテストケースが作れるか
  • 技術的負債バジェット
  • 技術的負債を金額換算する (時価)
    • 開発時間全体に対する負債返済の時間比を決める
    • 時価額の高いものから対処する
  • アーキテクチャ設計は終わりのない仕事

参加者が多くて人気のあるセッションでした。改めてアーキテクチャ設計の難しさを感じました。定期的に読み直したい資料です。冒頭で紹介されていた起業クエストはこちら。

エムスリーでのKotlinへの取り組み

  • サーバー/モバイルに関わらず多くのプロジェクトで Kotlin を採用している
  • Better Java
  • 技術選定の方針☆
    • 習熟度、周辺ライブラリ、既存システムとの連携
  • 移行パターン
  • 新規開発分に適用、あとから徐々に既存部分を変更する
  • フルリニューアル (アーキテクチャ再設計、機能の棚卸し)
  • 自動コンバート (IntelliJ)
    • Kotlin らしいコードにはならないので、手動リファクタリングが必要
    • コンバートと機能開発を混在させない (差分が分からなくなる)
    • リグレッションテストで品質担保
      • 自動コンバートをコードレビューしても仕方がない
      • Golden file testing でテストを量産する☆
  • Swagger, OpenAPI
  • GraphQL
  • Objectives and Key Results (OKR) ☆
    • 工数の20%程度を使うなどして Kotlin 化を進めた
  • Lombok ⇒ data class 移行
    • Kotlin では Builder パターンの代わりに名前付き引数を使う
  • コードレビューの指摘内容を中心にWikiに解説をまとめる

Kotlin というより、どのように技術選定をしているのか気になって参加しました。OKR でリプレースやリファクタリングを進めるのはよさそうです。が、Key Results を客観的に判断できるように定量化するところがなかなか難しそうでキモかもしれません。ところで、Builder パターンの代わりに名前付き引数を使うというのは、なんかメリットの捉え方が少しズレてるような気がしますが、どうなんでしょう...。

Migration Guide from Java 8 to Java 11

www.slideshare.net

  • 互換性
  • 非互換性
    • 非互換性ポリシー☆
    • 6バージョンごとのLTSのみ使っている場合はいきなり消えることがある
    • OpenJDK コミュニティでは非互換性は厳しくチェックされるらしい
  • Compatibility & Specification Review (CSR) ☆
    • Release Notes にだいたいは書いてある
    • CSR を読むとなおよし
  • マイグレーション
  • だいたいは Java 11 の時点でモジュール化する必要性はないかもしれない
  • 実行時例外☆
    • Options, API, JDK Internal APIs, Reflection
    • Java EE は Java 11 以降はモジュール自体が削除されている
    • JDK モジュール化に伴い、リフレクションで JDK Internal API や private メンバへのアクセスが不可
  • 実行の動作不整合/パフォーマンス☆
  • コンパイル/テスト環境においてはほとんどのライブラリやプラグインを更新する必要がある
  • Java 11 では出力されるバイトコードに大きな変更が入ってる
    • JEP181 の影響が最も大きい
    • バイトコードを扱うツールは Java 11 対応を待つ必要がある
  • コンパイル時例外/警告
    • ソースレベルの非互換性
  • 動作の不整合のところは特に要注意

とても学びの多いセッションでした。ここまで資料がまとまってるというのは素晴らしい...。要復習。

GraphQL vs Traditional Rest API

www.slideshare.net

  • REST
    • クライアント/サーバー
    • ステートレス
    • キャッシュ
    • レイヤード
  • GraphQL
    • GraphQL is specification
  • Entity や Repository のコードは REST/GraphQL で同じ
  • REST
    • Schema Optional
    • Good practice, but still optional
  • GraphQL
    • schema is MANDATORY
  • REST
    • HATEOAS
  • Protect from abuse
    • Time out
    • Max Query Depth
    • Max Query Complexity
    • Throttling
  • GraphQL rich SDL

今回、最も聴きたかったセッション。なかなか graphql-java の話を聴くことがないので貴重でしたが、内容自体は割と基本的なところだったかもしれません。デモのリポジトリはこちら。要復習。

github.com

1番気になっている Subscription については少し触れていましたが、英語が聞き取れず...。悲しい。

「マイクロソフト牛尾さん渡米直前記念」外資系企業で働くエンジニアの生産性向上物語

  • アメリカではお客さんでも技術力が高い (バリバリコーディングできる)
  • 学んだことを自分の言葉で書くことで理解を深める
  • 日本とUSの違い
    • とにかくラクをする
    • 無駄なものはなくす
    • 技術に明るい
    • 意思決定のスピードがとても早い
  • 英語の読み書きの速さが世界のエンジニアとの差
    • 目的の情報にアクセスするスピードが違う

その他

今回、海外からのスピーカーが多くて豪華でした。参加できなかったセッションの資料はあとで見てみようと思います。

あと、JJUG だけではないですか、最近、Kotlin がテーマのセッションが多くなった気がします。数年前はこのポジションに Scala がいたような。ある意味、Scala は枯れてきたと言えるのかもしれません。先日の Spring Fest 2018 でも Kotlin サポートの話がありましたね。

Spring Fest 2018 に行ってきた #jsug - kntmr-blog

最後のセッションで、「英語の読み書きの速さの差が日本と世界のエンジニアの差」という話がありましたが、まさに直前のセッションで英語が聞き取れなかったところなので、身に沁みました...。英語の勉強をしなければ。