JJUG CCC 2019 Spring に行ってきました


はじめに

2019/5/18(土)に JJUG CCC 2019 Spring というイベントに行ってきました。これは JJUG(Japan Java User Group) というグループが半年に1回開催しているイベントで、 JJUG CCC yyyy Spring と JJUG CCC yyyy Fall があります。今回は2019年の春なので JJUG CCC 2019 Spring という名前です(イベントの詳細はこちら)。私は1年半前の 2017 Fall から毎回参加していて今回4回目の参加です。

発表資料は最終的には GitHubに集約されると思うのですが、自分が参加したセッションで今(2019/5/18)資料のありかがわかっているもののリンクと私がメモしたこと、一部twitterのつぶやきを抜粋したものをこの記事にまとめておきます。

また、最後に当イベントの全タイトルと発表者と資料のリンクとtwitterへのリンクを貼っておきます。


自分が参加したセッションのまとめ


Java 11 時代のHTTP(S)再入門(#ccc_g1)


発表資料のありか


メモした内容


今までの主なHTTPアクセスのおさらい

これまで、JavaでHTTP(S)アクセスするとしたら、以下3つが多かった。

- HttpUrlConnection

- ApacheHttpClient

- OkHttp


HttpUrlConnection

もう使ってる人はいない?

Java 11でも一部、これまでのクラスを使っている。Proxyとか。

Basic認証には2種類ある。

・Header認証

・java.net.Authenticator

image.png

発表資料より抜粋

・Java 11でも似たような書き方をする。

・getPasswordAuthentication()メソッド(上のスライドで@Overrideしてるメソッド)が最終的に呼ばれるようになっている。

image.png

発表資料より抜粋

・JavaでSSL通信といえばSSLSocket

・SSL通信のVerifyのところで色々チェックしている


ApacheHttpClient

image.png

発表資料より抜粋

注意点:デフォルトでは、AcceptHeaderがない。

image.png

発表資料より抜粋

有名な検証サイト:http://httpstat.us/200


Java 11でどんなことができるか

image.png

発表資料より抜粋

image.png

発表資料より抜粋

注意点:java.net.http.HttpClient はデフォルトだとHttpResponse 302や303 が返ってきてもredirectしてくれないため、followRedirectsを指定する必要がある。デフォルトはNEVER。ALWAYSはクローラーする場合などに使用する。通常であればNORMALを使用する。


Valhalla, update and future(#ccc_e2)


発表資料のありか


メモした内容

Project Valhalla:Value Typesの実現を目指したプロジェクト。

image.png

発表資料より抜粋

Value Types(値型):オブジェクトとプリミティブ型の合わさったようなもの。

 - Generic Specification(ジェネリクスの特殊化)

 - VarHandles(JDK 9でリリース済)

 - Nestmates(JDK 11でリリースされた)


Nestmates

・Nested:Inner Classのこと

image.png

image.png

発表資料より抜粋

image.png

発表資料より抜粋

・Inner classからOuter classのprivate method を呼び出すようなプログラムを書き、それをjavapコマンドで逆アセンブルすると、XXX$YYYという感じで見覚えのないメソッド(BridgeMethod(※))ができている。

 ⇒内部クラスから外部クラスのprivateメソッドをコールするために、javacがBridgeMethodをこっそり作成している。

・Bridge Methodsの弱点

 - バイナリとソースが一致しない

 - アクセス権限がことなる

 - ディスクとメモリの無駄遣い

・BridgeMethodはやろうと思えば外部からアクセス出来る。

 (Asmtools で jasm ファイルから class ファイルを作って bridge method を呼び出す)

  ⇒もともとInnerクラスで書いたものなのに外部からアクセス出来てしまう。

・Nestmates:JEP 181: Nest-Based Access Control

 JDK 11で導入されたこの機能を使うことでBridgeMethodがなくなる。

・JVMLSのセッションで詳細が書かれているらしい。

・発表資料に「逆汗」という単語があったが、逆アセンブラのことらしい。。



- https://nagise.hatenablog.jp/entry/20171220/1513780658

- https://www.atmarkit.co.jp/bbs/phpBB/viewtopic.php?topic=41129&forum=7

- http://wisdom.sakura.ne.jp/programming/java/java5_1.html

  ⇒最後の方

- http://www.ne.jp/asahi/hishidama/home/tech/java/covariant.html#isBridge


ValueTypes

・ValueTypesのプロトタイプ:Minimal Value Types プロジェクト(MVT)

・Derived Value Class

  - 従来の参照:Lタイプ

  - ポインタを使っていない参照:Qタイプ


Catch up Java 12 and Java 13(#ccc_g3)


発表資料のありか


メモした内容

Java 12で導入された新機能とJava 13で導入される予定(未確定)の機能の紹介。いっぱいあるので資料見た方が速い。。。


Java 12 で取りこまれたJEPs

JEP 189: Shenandoah: A Low‑Pause‑Time Garbage Collector(Experimental)

  - STW:Stop The World

  - GCは今7種類ある(G1GC, ZGC, シリアルGC, パラレルGC...)

  - 今はExperimental。正式版はまだ。

  - Shenandoah GC は G1GC の上位互換

JEP 230: Microbenchmark Suite

  - JMH:Java Microbenchmark Harness

  - 利用者的にはあまりうれしくない

JEP 325: Switch Expressions (Preview)

  - プレビュー版。機能としては保証されているが、どのように使うべきかは議論の余地があるもの。

JEP 334: JVM Constants API

  - Invoke Dynamic・・・?(メモしきれなかった)

  - 必要な時まで起動を遅延させることができるようになった。

JEP 340: One AArch64 Port, Not Two

  - コードの重複を消した。

JEP 341: Default CDS Archives

  - CDS:Class Data Sharing

  - プロセス起動中のクラスローディングを、アーカイブファイルから読み込むことで複数プロセス共有し、Javaプロセスの起動時間を短縮した。

  - FaaS等のような短命のプロセスを立ち上げるケースで特に有効。

JEP 344: Abortable Mixed Collections for G1

  - G1GCを使っていて困っていた人は助かる機能。

JEP 346: Promptly Return Unused Committed Memory from G1

  - Javaは一度つかんだメモリはOSに返さない仕組みだった。

    ⇒JEP 346の対応により、返すようになった。常駐プロセスを常駐させやすくなった。


Java 12で入ってきたAPI


bit notable APIs

CompactNumberFormat(JDK-8177552)

image.png

発表資料より抜粋

image.png

発表資料より抜粋

  - 端数の扱いが四捨五入になっている。。。ひどい落とし穴。

・InputStream#skipNBytes

  - エラー時に、-1かExceptionのどちらを返すべき?

・String#indent

  - 指定した数分インデント追加

・Files#mismatch


notable APIs

・String#transform

・Collectors#teeing

image.png

発表資料より抜粋

  - Lambdaにて、1つのデータに複数の処理を同時に加工できる。

・CompletableFuture#exceptionally{Compose}{Async}


Other enhancements

JDK‑8209923: Unicode 11

JDK‑8202286: Allocation of old generation of Java heap on alternate memory devices

JDK‑8211845: A new switch to control verbosity of hs‑err files

 -XX:+ExtensiveErrorReports

JDK‑8205517: JFR tool

 - jfr print --json --category xxx --event yyy zzz.jfr

 - フライトレコードをElasticにjsonで流すなどが可能に


Java 13で追加される予定のもの

・Project Amber

・Project Valhalla

・Project Panama

・Project Loom

・Project Metropolis

 - 要はGraal VM の話

・Project Skara

 - OpenJDKのソース管理をMercurialからGitHubへの移行するプロジェクト

 - 移行先:https://github.com/openjdk/jdk

 - 参考:http://nowokay.hatenablog.com/entry/20180917/1537206738

・Project Portola

 - サイズの小さいDockerイメージを作る試み


JEP: 35 Draft, 5 Submitted, 27 Candidate

JEP 350: Dynamic CDS Archives

  - 試運転しなくてもアーカイブされる。

JEP 351: ZGC: Uncommit Unused Memory

JEP 353: Reimplement the Legacy Socket API

  - Socket API の一新

JEP 352: Non‑Volatile Mapped Byte Buffers

JEP 301: Enhanced Enums

image.png

発表資料より抜粋

image.png

発表資料より抜粋

  - キャストしなくてもよくなるEnum

JEP 305: Pattern matching for instanceof

image.png

発表資料より抜粋

  - instance of の後にキャストする必要がなくなる

JEP 355: Text Blocks

JEP 349: JFR Event Streaming


SI現場のテスト自動化への挑戦〜フルコンテナ構成のCI/CD環境〜(#ccc_m4)


発表資料のありか


メモした内容


CI/CDを適用したプロジェクトについて

image.png

発表資料より抜粋

点線部分は未実装。Staging, Prodに対するCDは出来ていないのが現状。将来的にはオーケストレーションツール(k8sとか?)を入れて管理できるようにしたい。


Javaのテスト実装について

image.png

発表資料より抜粋

・実装コストと収益の損益分岐点のようなものがあるはず。これがどこなのかを見出したい。

・結合テスト(ITa)はCIでは正常系のみとした。

・C2カバレッジは結合テスト(ITa)で網羅的にテストする。


フルコンテナ構成のCI/CD環境について

image.png

発表資料より抜粋

・アプリのwarを含むDocker image を生成

・Jenkins Slaveをコンテナで立ち上げる

image.png

発表資料より抜粋

UT:DBコンテナを作ってDB接続含めたテストを実施した。

image.png

発表資料より抜粋

ITa:外部API、アプリ、DBコンテナを立ち上げて接続テストを行った。

image.png

発表資料より抜粋

CIが通っていないとMergeできないようにしていた(上図の赤枠部分。非活性にして押せないようになっている)

 ⇒テスト品質とテストプロセスが担保された。


2.1 できるだけ実行環境・テストツールにロックインされないこと

image.png

発表資料より抜粋

・すべてOSSで構成されている。OSSとコンテナを用いることで、ポータビリティとスケーラビリティを確保できた。

・オンプレ/クラウドに関わらず構築可能なものにした。


実践的なプラクティス

Docker実行方法

Docker outside of Docker (DooD)


課題:オーケストレーションツールの必要性。


①Port Binding

image.png

発表資料より抜粋


②コンテナおよびサービス稼働確認

image.png

発表資料より抜粋


オーケストレーションツールを用いた理想的な構成を作りたい

image.png

発表資料より抜粋

しかしいきなりオーケストレーションツールを導入するのもハードルが高い。まず第一歩としてコンテナ化ツールの導入から始めてみても良いと思う。


QA



Q:プロジェクトの規模は?


A:開発者9名程度。CI/CD担当は開発者と別に2名。


Q:テストデータの準備はどうやっている?


A:Postgresの起動時にDDLが流れるようにしている。


Q:1回のパイプライン実行にかかる時間は?


A:5分ぐらい。但し、実装できていないものもある。全部実装したら倍ぐらいかかると思う。


Q:(twitterより抜粋)ツールにロックインされなくてもossでこれだけ揃えてると長期的に維持が大変そう


A:おっしゃる通りでその懸念はあります。一つ銀の弾丸になり得ると思っているのは、テストツール類まで含めてコンテナ化してしまうことです(今はVMに直接インストールしている)
コンテナならばバージョンアップも比較的容易に出来るのではないかと考えています。

DevOpsなど最新の取組に積極的なお客様だった。そのため、DevOpsも進めやすく、今回の環境構築にも協力的だった。


Functional Programming Design using Morphisms(#ccc_i5)


発表資料のありか

2019/5/18時点で資料は公開されていない模様。


メモした内容

英語の発表。英語の発表を聞くには自分はまだ英語力不足だということがわかった・・・。


Project Loom - 限定継続と軽量スレッド(#ccc_a6)


発表資料のありか


メモした内容

sli.doで質問を募集しているらしい。

https://www.sli.do/

イベントコード:ccc_a6

櫻庭さんによるProject Loomの話。Project Loomがリリースされるのは3年くらい先の話なので、今日の発表はあくまで『今時点こうだよ』っていう話。リリースした時どうなっているかは当然わからない。

・Project Loom = Fiber(軽量スレッド) + Continuation(継続)

 - Thread:糸

 - Fiber:繊維

 - Loom:織機

・スレッドセーフでもスケールしないこともある。スレッドセーフがうたわれていても、1,000個アクセスされてその機能が動くかどうかは別の話。

image.png

発表資料より抜粋

・whileし続けて無限ループになる。どうすればいいか?

image.png

発表資料より抜粋

wait()notifyAll()を使う。notify()はダメ。最近はフレームワークがうまいことやってくれてるから、直接これを書く機会は減った。

image.png

発表資料より抜粋

wait()notifyAll()はObjectクラスに属するものであり、つまりOSのContextSwitchに依存してしまう。スイッチがいつ行われるかはOSのみぞ知る世界。

・JDKの保存領域(ワーキングメモリ)(※)

  - ヒープ:Javaプロセス内に存在するJavaオブジェクトを格納するための領域

  - メタスペース:Javaのクラス、メソッドなど、永続的に参照される静的オブジェクトを管理する領域

  - JVM Stack:StackTraceはここの情報を出力している

・OSに依存しない、JVMが管理するスレッドを作る必要があり、それがFiber。

Fiber は JVMが管理する軽量スレッドで、メモリ使用量もタスクスイッチコストも小さい。Threadと同じように使える。

http://software.fujitsu.com/jp/manual/manualfiles/m170006/b1ws1303/01z200/b1303-00-11-01-06.html

・Fiber = Continuation:中断と再開の仕組み + Scheduling:ExecutorService. デフォルトはForkJoinPool

・ExecutorServiceをFiberにしただけでスループットが倍になる(誇張あり)。

  - ThreadPoolExecutor:http://bit.ly/OCT19TH

  - FiberExecutor:http://bit.ly/OCT19FB


java.lang.Continuation

・処理の開始/再開:run()

・処理の中断:yield() 中断というよりは譲るイメージ

・タスク処理:Runnable

image.png

発表資料より抜粋

・普通の人はContinuationをダイレクトには使わない。Fiberを使う。


java.lang.Fiber

(ほぼ)Threadと同じように使える

 ・タスクの登録:schedule()

 ・タスクの中断:park()

 ・タスクの再開:unpark()

Fiber#toFuture()もできる

image.png

発表資料より抜粋

image.png

発表資料より抜粋

image.png

発表資料より抜粋

image.png

発表資料より抜粋

park()/unpark()はpachage privateなので、普通呼び出せない。ライブラリがコンテキストスイッチに使うだけ。

j.u.c.l.LockSupport:java.util.concurrent.lock.LockSupport


現状の制限

image.png

発表資料より抜粋

・JNIだと使えない

・synchronizeよりはReentrantLockの方が新しくて便利

・パラレルだからsynchronizeを使うというのは考え物。


現状の問題点

・ThreadLocal。FiberLocalみたいなものを入れると重くなってしまう。

・currentThread。Threadを返すと複数のFiberが止まってしまうので、暫定的にダミーのshadowThreadを返している。

・Windowsには未対応。


その他参考

JDKの中にテスト用のHTTPサーバがあるらしい。


マイクロサービス 4つの分割アプローチ(#ccc_g7)


発表資料のありか


メモした内容

(マイクロサービスアーキテクチャをMSAと略して書いたりしています)

ギルドワークスの増田さんの発表。

2019/3/22に参加したDevLoveのイベント(※)で語られなかった、マイクロサービスにおけるサービス分割の4つの軸について語った発表でした。




実証されたパターンではなく、増田さん自身が実践したこと、及び実践していないけどこうすればうまくいくかもという話も含まれているとのこと。

image.png

発表資料より抜粋

マイクロサービスを実現する技術は揃ってきた。

 - クラウド

 - コンテナ

 - 設計スキル

   ⇒ソフトウェアをどう分割して拡張性をもたせるか

これらは必要条件であって十分条件ではない。

今回話すのは設計スキルの部分

image.png

発表資料より抜粋

マイクロサービス4つの動機

・ロードバランサで分散

  負荷分散

  リスク分散

  データ分散

・異なるサービスの連携

  機能分散

今回話すのは機能分散の部分

image.png

発表資料より抜粋

・MSAを考える時の増田さんの基本アプローチ

  モノリスで作る→モジュール改善

   ↓

  MSAの可能性を検討(部分適用を検討)

   ↓

  移行の検討(部分適用を検討)

・モノリスでもマイクロサービスでも設計スキルの基本は変わらない

  関心の分離

  高凝集・疎結合

  モジュール化

   ⇒モノリスでもマイクロサービスでも活かせる


サービスの模式図

image.png

発表資料より抜粋

・モノリスでも、1つのマイクロサービスでも同じ

 インバウンドがあってアウトバウンドがある

 データソースを経由してDBや他のサービスから取得

・MSAでは非同期でreceiveして非同期でsendしたり、非同期でsubscribeして非同期でpublishするなど、モノリスの時よりは非同期処理を当たり前に使うことが多い。非同期は、昔からある使い込まれてきた技術。クラウドのmessagingサービスでやりやすくはなっている。

・非同期メッセージングの技術は昔からあったし使われていたが、大規模アプリ向けに自分で mq を構築して運用する敷居は高かった、これがクラウドにより簡単に使えるようになった、結果として非同期メッセージングが昔よりコモディティ化された。


どこまで小さくできるか

image.png

発表資料より抜粋

・理論的にはJava APIのメソッド単位。

昔RMI(Remote Method Invocation)というものがあった。メソッド単位でやろうとしたが、、、まああまりうまくいかなかった。

CORBAなんてものも昔はあった。

・限界はクラウド/コンテナ/設計/運用の習熟度

経験を積みながらある程度分散し、習熟しながら次のステップに進んでいく。クラウド/コンテナ/設計/運用スキルの習熟度、経験値に依存している。


どこまで小さくするか

image.png

発表資料より抜粋

・論理的なモジュール分割

モノリスでも積極的に分割できるし、モノリスだからこそ大胆にできる。


MSA間の通信


8つの勘違いと真実

image.png

発表資料より抜粋

出典:Fallacies of Distributed Computing Explained

穴が開いている⇒必ず何かしらのセキュリティホールがある。


4つの分割アプローチ

image.png

発表資料より抜粋

4つの切り口とは

 1. 業務機能で分割(ビジネスファンクション)

 2. 動詞/ユースケース(ユーザーストーリーもここかも)

 3. 名詞/リソース(データモデリングとか)

 4. ドメイン駆動設計(DDD)


ビジネスファンクションによる分割

image.png

発表資料より抜粋

販売プロセスを21に分割。これくらいの数にはなる。

image.png

発表資料より抜粋

・大企業病がそのまま持ち込まれる。

・大企業の場合:業務機能で部門が分かれてサイロ化

・中小企業の場合:機能は分けられるが、人が少ないから兼任している。

・ユーザーが言っている「ここからここまでが業務の範囲」に合わせるとうまくいくのか?

・業務機能と組織は1つの大きなテーマ

・人のプロセスに合わせて分割できるが、逆方向への連携が必要になったときが課題になる


動詞/ユースケース

image.png

発表資料より抜粋

・モノリスでも伝統的なやり方

・機能要求、開発範囲として分割しやすい

・ロジックの重複・断片化が起きやすい。例えば、売上と請求を別チームが作ると・・・。

 トランザクション単位のマイクロサービスになってしまう

  サービス間でロジックの重複、断片化が起きやすい

  分岐の条件などドメインのロジックが分断してしまう

・バッチが増える。夜間バッチで不整合を検出するとか、本来ここまでステータス変更すべきだったのをバッチでつじつまを合わせるということが起こりがち。

・対策:薄いユースケースサービス

  ロジックを領域ごとに分割、整理

  重複や断片化をなくす

  これを複数のユースケースサービスが呼び出す

image.png

発表資料より抜粋


リソース指向

image.png

発表資料より抜粋

・異なる関心事が混在し、肥大化しがち。顧客番号にいろいろな情報を持たせることで肥大化してくるイメージ。

 識別番号の世界

 異なる関心事が混在して肥大化

  ⇒はじめは小さかった顧客が数百項目に

・MSAはJOINができない、外部キー制約が効かない世界。

・モノリスが、識別番号にいろいろな情報を持たせすぎていると考えている。管理単位を分ける必要があるのでは?関心事を分離する必要がある。

・モノリスでの捉え方が逆なのかもしれない。本来は同じIDでも分けるべきなのかも


DDD

わからない!(笑)

image.png

発表資料より抜粋

エヴァンス流のドメイン駆動設計バーノン流のドメイン駆動設計で、コンテキストとサブドメインの関係が異なっている。

・エヴァンス本の方が、設計のやり方に関しては情報が豊富な印象。

・エヴァンス流の定義

  境界づけられたコンテキスト

    チームのコミュニケーションの範囲

    ソースやDBスキーマなど

・サブドメインは変化していく⇒サブドメイン単位での分割は危険。

・境界づけられたコンテキスト

 目標

  一つのコンテキストに一つのモデル

 どっちに倒すかを検討していく

  モデルを一つに維持するか

  コンテキストを分割するか


ドメイン駆動設計の「モデル」

image.png

発表資料より抜粋

・モデル≒ビジネスルール

(正確な解釈ではないが、だいたい合ってる。こう解釈すると、エヴァンスの言っていることが見えてくる)

・ビジネスルールの領域毎にサービスを分けるのはかなり有効なアプローチ


トランザクション分解パターン

image.png

発表資料より抜粋

・詳細は資料を探してください

 ⇒と言われたので少し探してみました。







VETRO





Camelデザインパターンの紹介

  ⇒VETROパターン

マイクロサービスにおけるCamelのVETROパターンの適用方法







saga





Camelデザインパターンの紹介

  ⇒Saga(サーガ)パターン

TCCパターンとSagaパターンでマイクロサービスのトランザクションをまとめてみた

  ⇒Sagaパターン

マイクロサービスの Saga パターンについて



マイクロサービスにおけるトランザクション【Saga】









状態更新の非同期化(EH-SM-DSQ)





ググってもあまり参考になるものは見つからなかったが、

 - EH:Event History

 - SM:State Materialize

 - DSQ:Domain Specific Query

のことで、イベントを履歴として記録しておいて、目的別にクエリを分けるパターンなんだと理解した。






・これまでの1トランザクションは、マイクロサービスにはでかすぎる。

・「受注登録と言えばそれは一つのトランザクションだよね」という固定観念を捨てる。本当にそうか?分割できるのでは?


セッション全タイトルと資料のリンクとtwitter

イベント全体のハッシュタグ:#jjug_ccc

10:00-10:45

タイトル
発表者
twitter

初めてのgRPC
前多賢太郎
#ccc_a1

Java Collections Framework + α 入門
持田真哉
#ccc_c1

現代に求められるJavaコミュニティとは
谷本心
#ccc_e1

Java11時代のHTTP(S)アクセス再入門
Kiyotaka Suzuki (@tamtam180)
#ccc_g1

OpenCensusで始める分散トレーシングと監視
Yoshida
#ccc_i1

How to Write Better and Effective Code in Java
ALTUĞ BİLGİN ALTINTAŞ
#ccc_l1

Eclipse MicroProfile提供機能に関する考察
高橋 博実
#ccc_m1a

Future と ThreadPool
庄司 重樹
#ccc_m1b

11:00-10:45

タイトル
発表者
twitter

パッケージ管理していなかった既存システムに後付けで Gradle を導入した話
矢崎 聖也
#ccc_a2

Big Data Exploration with Spark SQL and Java
Fernando Babadopulos
#ccc_c2

Valhalla, updates and future
David Buck
#ccc_e2

大企業運営の法人向けサービスにおけるOpenJDK移行事例
大中浩行
#ccc_g2a

開発リーダー1年目。メンバーのスキルアップのためにやっていること。
丹野 航
#ccc_g2b

What's new in Jakarta EE and Eclipse GlassFish (May 2019)
蓮沼 賢志
#ccc_i2a

ArchUnit で Java/ Kotlin アプリケーションのアーキテクチャを CI する
かわなみゆう
#ccc_i2b

デプロイから考える僕のWEBアプリ開発
井上 和宏
#ccc_m2a

売れてる SaaS へのオブジェクトストレージ導入にまつわる泥臭い話
西角知佳
#ccc_m2b

12:00-12:45 (ランチセッション)

タイトル
発表者
twitter

JJUG ランチセッション
鈴木雄介

Cloud Native時代の開発環境とアプリケーション基盤(仮)
須江 信洋

13:30-14:15

タイトル
発表者
twitter

Java 11へのマイグレーションガイド ~Apache Hadoopの事例~
鯵坂 明/浅沼 孝信
#ccc_a3

マルチテナントECシステムにおける拡張性と最新性の両立
水野謙
#ccc_c3

先行開発!Javaでクリーンアーキテクチャ -- ゼロから始める新規開発
成瀬 允宣
#ccc_e3

Catch up Java 12 and Java 13
KUBOTA Yuji
#ccc_g3

DevOps without Measurement is a Fail
Erno Venäläinen
#ccc_i3

Bulletproof Java Enterprise Applications for The Hard Production Life
Sebastian Daschner
#ccc_l3

俺たちのドメイン駆動設計はこれからだ!
本谷 亮介
#ccc_m3a

Java開発者のためのWebAuthn入門
Yoshikazu Nojima
#ccc_m3b

14:30-15:15

タイトル
発表者
twitter

ドメイン管理サービスにおけるJava活用のご紹介
小田 竜広
#ccc_a4a

入門: 末尾呼び出し最適化
宮川 拓
#ccc_a4b

ホットペッパービューティーにおけるモバイルアプリ向けAPIの
BFF/Backend分割
索手一平
#ccc_c4

テストエンジニアが教える JUnitを書き始める前に考えるべきテスト
風間裕也(@nihonbuson)
#ccc_e4

Java クライント実装におけるAPIスタイル頂上決戦! 野良REST vs GraphQL vs OData vs OpenAPI (Swagger)
杉本和也
#ccc_g4

Cloud (K)native Java Services -- Deploying your Java services in Serverless World --
Kamesh Sampath
#ccc_i4

SI現場のテスト自動化挑戦〜フルコンテナ構成のCI/CD環境〜
川沼 大輝/横山 夏実
#ccc_m4

15:45-16:30

タイトル
発表者
twitter

ゴールドマン・サックスにおけるApache Beamを用いたビッグデータ処理の紹介と実例
石井すみれ/Zhang, Xuefeng
#ccc_a5

Stateless Microservice Security via JWT and MicroProfile
David Blevins
#ccc_c5

1400万ユーザーのWebサービスを15年運用して考える、Javaである理由
鈴木 真生
#ccc_e5

LINEのBOT Platformの裏側の話
鈴木 真生
#ccc_g5

The 4 Rules of Simple Design In Functional Programming
Uberto Barbini
#ccc_i5

ソフトウェア設計の教育工学的な分析と育成へのアイデア
松下正嗣
#ccc_m5a

スキマ分野で生き残るための戦略
すずきただし
#ccc_m5b

16:45-17:30

タイトル
発表者
twitter

Project Loom - 限定継続と軽量スレッド
櫻庭 祐一
#ccc_a6

Javaで作るオレオレ仮想通貨ウォレット
明石 敬
#ccc_c6

JJUG会長と一緒に考えたSpring Boot x JavaScript x IntelliJ x アジャイルというモダンな新人研修を今まさにやっている話
多田真敏
#ccc_e6

ストラングラーパターンによるマイクロサービスマイグレーションの勘所
川上徹
#ccc_g6

Using Microprofile to develop microservices for IoT platform
skalster
#ccc_i6

今日から始めるカジュアルなソースコード解析
後藤 祥
#ccc_m6a

CDIポータブルエクステンションを作ってみよう
Fusayuki Minamoto
#ccc_m6b

17:45-18:30

タイトル
発表者
twitter

Functional Spring Cookbook
Toshiaki Maki
#ccc_a7

Serverless Java: Challenges and Triumphs
Shaun Smith
#ccc_c7

マイクロサービス:4つの分割アプローチの比較
増田 亨
#ccc_g7

Tools-in-action: WireMock + RestAssured
Ix-chel
#ccc_i7

Reladomoを使ったトランザクション履歴管理をプロダクトに適用した際のメリット/デメリット/課題など
渡邉 一夫
#ccc_m7


参加した人のブログとか

・JJUG CCC 2019 Springに参加してきました #jjug_ccc

https://www.grimrose.org/blog/2019/05/jjug-ccc-2019/

・JJUG CCC 2019 Springにいってきました #jjug_ccc

https://takeda-san.hatenablog.com/entry/2019/05/19/134053

・「JJUG CCC 2019 Spring」に参加しました

http://makopi23.blog.fc2.com/blog-entry-317.html

・JJUG CCC 2019 Spring ( #jjug_ccc ) - セッション資料の一覧

https://yujisoftware.hatenablog.com/entry/2019/05/19/040112

・2019-05-18JJUG CCC 2019 Spring #jjug_ccc

https://note.mu/suwash/n/n5f5937986b25

・[JJUG CCC 2019 Spring]先行開発!クリーンアーキテクチャ — ゼロから始める新規開発 というタイトルで登壇しました

https://nrslib.com/event-after-jjug-ccc-2019-spring/

・JJUG CCC 2019 Spring(#jjug_ccc)に参加してきました

https://chichi1091.hatenablog.jp/entry/2019/05/18/224111

・JJUG CCC 2019 Springに行ってきました

https://yachiy.hatenablog.com/entry/2019/05/18/221734

・JJUG CCC 2019 Spring で20分話したよ #jjug_ccc #ccc_m5b

http://tadashi.hatenablog.com/entry/2019/05/18/201644

・hondaYoshitaka/ccc_a6.md

https://gist.github.com/hondaYoshitaka/3eccf0686e9988e70c3a07cc9071809c#file-ccc_a6-md

・JJUG CCC 2019 Springの記録

https://miyakawataku.hatenablog.com/entry/20190520/1558358694

・JJUG CCC 2019 Springに登壇しました

https://www.project-respite.com/jjug-ccc-2019-spring/

・増田亨さん「マイクロサービス 4つの分割アプローチ」を聞きに行けなかったんだけど教えてもらったのでまとめてみる #jjug_ccc

https://taichiw.hatenablog.com/entry/2019/05/20/190605

・JJUG CCC 2019 Spring に行ってきた #jjug_ccc

https://kntmr.hatenablog.com/entry/2019/05/18/223621

・JJUG CCC 2019 Springで色々な工夫を凝らしつつ、テストについて発表してきました! #jjug_ccc #ccc_e4

http://nihonbuson.hatenadiary.jp/entry/2019/05/20/080000

・JJUG CCC 2019 Spring に行ってきた

https://itatyo.hatenadiary.jp/entry/2019/05/20/095324

・「Java 有償化」で誤解する人になるべく分かりやすく説明するためのまとめ

https://togetter.com/li/1343743

・JJUG CCC 2019 Spring 協賛・登壇レポート

https://engineering.linecorp.com/ja/blog/jjug-ccc-2019-spring-report/

・JJUG CCCにボランティアスタッフとして参加しました!!

http://acro-engineer.hatenablog.com/entry/2019/05/22/120000

・JJUG CCC 2019 Spring 親睦会 LT

http://www.tomokosugimoto.net/drum/other/jjug_ccc/index.html


最後

資料追加されたら随時更新します