たのしく生きたい

いつもニコニコゆるふわブログです

JJUG CCC 2018 Spring に参加した #jjug_ccc

はじめに

日本Javaユーザーグループ（JJUG）のイベント JJUG CCC 2018 Spring に参加してきました。

前回の 2017 Fall では初めての参加だったため、勝手がわからないまま朝イチから最後までぶっ通しでセッションを聞き、たくさん学びがあった反面たいへん疲れてしまっていました。

tobachi.hateblo.jp

今回はあまり疲れないように、気軽にゆっくりと過ごす気持ちで参加しました。前回は聞けなかったLTなども聞けてとても良かったです。

各セッションの感想やメモなどを残しておきます。

参加したセッション

Kotlin + Spring Bootでサーバー開発

www.slideshare.net

前回に引き続き、サーバサイドKotlin面白そうなので聞いてみました。

  • 「Kotlinだとシュッと書ける。いろんなことがシュッとできる」「for文を書いたら負けな気がしてくる。なるべくfor-eachで書きたい」とおっしゃっていたのが印象的だった。
  • 名前付き引数を指定できるので、引数の順番を間違えたりいちいち調べたりしなくて済む、というのが便利そう。
  • 引数のデフォルト値も設定できるので、それも便利っぽい。
  • IntelliJは補完がすごいだけじゃない。Kotlinっぽくない書き方をすると警告してくれる。
  • JUnitテストのときは@Autowiredがないと動かないので注意。

Kotlinは書きやすそうだし、個人プロジェクトでは積極的にKotlinを使っていきたいなあという思いを強くしました。

ざっくりわかった気になるモダンGC入門

speakerdeck.com

普段あまり意識しないが、GCのことはとても気になっています。JVMがいったいどのようにしてメモリを管理しているのかを知っておきたいという気持ちがあります。

低レイヤっぽいし、詳しくなれたらなんとなくかっこいいのではないかとぼんやり思っています。JVMの気持ちを理解できる人になりたい。

  • これまでのGC: メモリを世代別（young / old）に分けて管理する方式。コンパクションGCを採用しているので、アプリケーションスレッドが停止するフェーズが存在してしまう。
  • 新たなGCが必要になってきた背景: コンパクションGCをやめたい。
  • ShenandoahGC: 世代型メモリ管理→リージョン型メモリ管理。メモリ領域を細かく分割してメモリ管理する。
    • 並列コンパクションの難しさ: 参照を切り替えるのが難しい。
    • ShenandoahGCでは、オブジェクトのヘッダとポインタを比較することで、退避前／後の判別をしている。
  • ZGC: Linux 64bitのみで動作。「Javaの世界観から反したロックな感じで面白い。」
    • カラー・ポインタとLinux仮想メモリをフル活用する。
    • カラー・ポインタ: オブジェクトの状態をカラーとして表現する。
    • 64bitのアドレス空間をすべて使ってしまう。そこで、Linux仮想メモリの仕組みを使う。
    • フォワーディング・テーブルを使ってメモリ節約をしている。
  • Epsilon GC: なにもしないGC？？

[試して理解]Linuxのしくみ ~実験と図解で学ぶOSとハードウェアの基礎知識

[試して理解]Linuxのしくみ ~実験と図解で学ぶOSとハードウェアの基礎知識

ランチLT

ちょうどお昼の時間にスポンサー企業さんによるLTが行われていました。3分一発勝負とのことで、ゆるい感じと緊張感が同居していて面白かったです。

エムスリーさんが配っていたコーヒーを飲みながら聞いていました。

SendGridさん

  • 月間400億通のメールが送信されているサービス。（僕の職場でも使われてるっぽいです。）
  • メールを届けるのは難しい！正当なメールでも届かないことがある。
  • 自前でPostfixとか立てるのもいいけど、サービスを使った方が楽。

intra-martさん

  • Activiti: OSSのワークフローエンジン。
  • 華麗にセッションへ誘導。

Samuraismさん

  • テストしてますか？ CIサーバでテストしましょう。
  • テスト失敗に気づかないケース。通知来ても、通知多すぎて見れない。
  • TeamCityを使いましょう！IDEがテスト結果を通知してくれる。
  • LT中にIntelliJが固まってて、笑いが起こってました。

CDataさん

MoneyForwardさん

  • バックエンドはRuby on Railsだが、アカウントアグリゲーションはJavaを使っている。
  • Javaエンジニア足りてないらしい。

Pivotal認定講師が解説！ReactiveだけじゃないSpring 5 & Spring Boot 2新機能解説

www.slideshare.net

認定講師の方ということもあり、さすがの盛況っぷりでした。

新機能がとてもわかりやすくまとまっており、Spring5とSpring Boot2.0の変更点を頭に叩き込まれたような感覚でした。すごい。

  • Reactiveについては今回は対象外。
  • Core: JDK8ベース、9や10対応。
    • 8の文法で完全に書き換わった。
    • 9のモジュールシステムにも対応。
    • spring-jclによりloggingが便利に。Spring内部のログを、logbackを追加するだけで出力できるようになる。
    • spring-context-indexer: ビルド時のAnnotation Processorとして動き、コンポーネントスキャンの遅さを解消する。ただし、コンポーネントスキャンは元々そんなに遅くないので、大きいプロジェクトでないと効果を発揮しなさそう。
    • @NonNull/@Nullable: Kotlinっぽくね？
  • Web: HTTP/2などJavaEE8対応。
    • Bean Validation 2,0対応: 新アノテーション追加、Date and Time API対応、コレクション要素の検証（便利そう）。
    • Formをimmutableにできる: オブジェクト指向っぽい。javac の -parameters が必須。Spring Boot2.0 + Mavenだとデフォルトで有効（Gradleは不明）。
      • ただし、不具合あるので注意。Spring 5.1で改善されるらしい？
  • Data: 破壊的変更あり！
    • APIの変更: 大きく変わっている。Optionalの利用、メソッド名の変更。互換性なしと考えたほうが良い。
    • Spring Data JDBC ベータ版: JdbcTemplateを利用したSpring Data。MyBatisでも利用可能らしい。
      • CrudRepositoryを継承したinterfaceを作成するだけで、CRUDメソッドができる。
      • 僕の職場ではMyBatisを使っていますが、MyBatisでも利用できるのは便利かもなー。
  • Security
    • OAuth 2.0対応: 散らばっていたOAuth機能をSecurity本体にまとめて再実装された。
    • DelegatingPasswordEncoder追加: デフォルトで適用されるPasswordEncoder。従来だと、PasswordEncoderを指定しないと生のパスワードが保存されてしまっていた。
      • 新規開発なら、PasswordEncoderを明示的に指定したほうが良いかも。
  • Test: ほぼReactive対応。
    • JUnit5対応: 拡張機能がSpringExtentionにまとまった。
      • @ExtendWith(SpringExtention.class)
      • ParameterResolverでテストメソッドの引数にいろいろ持たせられる。
        • @AutowiredでBeanを受け取るとか、できる。
  • Boot2.0: Spring5対応＝JDK8ベース。Thymeleafがデフォルト3になったり。
    • セキュリティ設定の簡素化: JavaConfigに一本化。
    • Actuatorの改良: デフォルトでURLプレフィックス /actuator がつくようになった。
      • エンドポイントのセキュリティ設定。
    • spring-boot-properties-migratorで古いproperty名を新しいproperty名に変換・代入してくれる。
      • migratorを入れたままで本番環境には載せないこと。

Java10まとめと、どうなるJava11

www.slideshare.net

こちらのセッションも早くから満員となっており、椅子が増設されていました。

  • Javaのリリースモデル:新バージョンが6か月ごとにリリースされる。春分の日と秋分の日あたりに出る。修正リリースが3か月ごとに出る。
    • OracleJDKではなくOpenJDKを使う。2019年1月までに11にしよう。
  • ローカル変数の型推論。ローカル変数以外の型推論は今までもあった。
  • JITをJavaで書いたコンパイラ。java-on-java。ScalaですらJVMを書けるようになる？
  • G1GCのFullGCが並列化。FullGCはそもそも起こしてはいけないけど。
  • Class-Data Sharing
  • Thread-Local Handshakes
  • API変更: guavaのimmutableListなどの機能を取り込み。
  • Dockerサポート: CPUカウントやメモリサイズについて、Dockerのものを見るようになった。
  • JDK11: Single-File Single-CodeとかRaw String literalsとかSwitch Expressionsとか入ってほしい。
    • nested class はなんかいびつらしい。
    • StreamとCollectionは依存しないようにがんばってきた。
    • 平成をどうするか問題。
  • まとめ：みんながんばろう。

REST API に疲れたあなたへ贈る GraphQL 入門

www.slideshare.net

GraphQLってよく聞くけど全然わかってないので参加しました。

AWSの方なので、何気にスライドがAWSカラーですね。

  • AWSにはジェームズ・ゴズリングがいる。
  • AppSyncを使うと簡単にGraphQLが用意できる。
  • GraphQL: クライアント側のAPI用クエリ言語であり、サーバー側のランタイムである。
  • リアルタイム性が高い。購読（subscription）だとイベント駆動で処理できる。便利。
  • 注目されている背景: REST APIだとドキュメント作成や管理が大変。クライアント側からは、フルでイベント駆動として開発できないという不満。
  • クライアント・サーバ間のインターフェースがクリーンになる。
  • 型指定されたスキーマ。ドキュメントを自動生成できる。
  • クライアントからレスポンスの形式を指定できる。指定した値だけを取得したりすることができる！
  • ついでにAppSyncだと自動でスケールしてくれて楽。

GraphQLとAppSyncをとりあえず触ってみるかーという気持ちになりました。

DDDとクリーンアーキテクチャでサーバーアプリケーションを作っている話

今の職場ではドメイン駆動設計・DDDによる開発が行われています。DDD初心者の自分としては毎日学ぶことが多いです。DDDについてもっとよく知りたいと思い、参加しました。

何気に満員っぽかったです。DDDの関心度が高いのかな？

  • 突貫工事はうまくいかない。という経験から、DDDおよびクリーンアーキテクチャ採用へ。
  • ビジネスロジックの主体を用意する必要性。
  • ロバストネス分析: あらかじめユースケースを作成→シナリオを満たす機能をどう作るかを考える→バウンダリ（外部とのインターフェース）、エンティティ（保存するデータを格納する）、コントロール（処理）でそれを表現する。
  • コンテキストマップ: ロバストネス図で出てきた機能について、似たものを集めて「境界づけられたコンテキスト」を規定する。
    • コンテキスト間の関係を検討して規定する。
  • 新システムでは、機能ごとにRDBを分けて用意。Dockerコンテナで構築。コンテナ間のやりとりはREST APIで用意。
  • ユビキタス言語に基づき、システムとして用語を統一して、プログラム上の命名も行った。
    • DDD的には、コンテキスト内でユビキタス言語を定義する。
  • ルールを作りコーディング規約とコードレビューを徹底。
  • NULL問題はいろいろある。
  • クリーンアーキテクチャ: Interface/UseCase/Domain に層を分けた。
    • Interfaceのtranslatorで、ユーザが使う用語をプログラム内のユビキタス言語に変換した上で、UseCaseに渡す。
    • パッケージ構成も層に分けて定義。
  • Domain層はドメイン知識だけに集中する。データがどのテーブルにどう入るか、ということはInterface層に集約する。
  • 部品を小さく作ることの恩恵。
    • メリット？デメリット？→Interface/UseCase層の間では変換の嵐。
  • ただし……規約に書いたこと以外はみんなバラバラ。REST API通信の実装など。
  • ‪Exceptionの配置場所: いろんなところにある。それぞれの層で必要な例外は違ってくる。‬