はじめに
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
発表資料より抜粋
・Java 11でも似たような書き方をする。
・getPasswordAuthentication()メソッド（上のスライドで@Overrideしてるメソッド）が最終的に呼ばれるようになっている。
発表資料より抜粋
・JavaでSSL通信といえばSSLSocket
・SSL通信のVerifyのところで色々チェックしている
ApacheHttpClient
発表資料より抜粋
注意点：デフォルトでは、AcceptHeaderがない。
発表資料より抜粋
有名な検証サイト：http://httpstat.us/200
Java 11でどんなことができるか
発表資料より抜粋
発表資料より抜粋
注意点：java.net.http.HttpClient はデフォルトだとHttpResponse 302や303 が返ってきてもredirectしてくれないため、followRedirectsを指定する必要がある。デフォルトはNEVER。ALWAYSはクローラーする場合などに使用する。通常であればNORMALを使用する。
Valhalla, update and future(#ccc_e2)
発表資料のありか
メモした内容
Project Valhalla：Value Typesの実現を目指したプロジェクト。
発表資料より抜粋
Value Types（値型）：オブジェクトとプリミティブ型の合わさったようなもの。
- Generic Specification（ジェネリクスの特殊化）
- VarHandles（JDK 9でリリース済）
- Nestmates（JDK 11でリリースされた）
Nestmates
・Nested：Inner Classのこと
発表資料より抜粋
発表資料より抜粋
・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)
発表資料より抜粋
発表資料より抜粋
- 端数の扱いが四捨五入になっている。。。ひどい落とし穴。
・InputStream#skipNBytes
- エラー時に、-1かExceptionのどちらを返すべき？
・String#indent
- 指定した数分インデント追加
・Files#mismatch
notable APIs
・String#transform
・Collectors#teeing
発表資料より抜粋
- 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
発表資料より抜粋
発表資料より抜粋
- キャストしなくてもよくなるEnum
・JEP 305: Pattern matching for instanceof
発表資料より抜粋
- instance of の後にキャストする必要がなくなる
・JEP 355: Text Blocks
・JEP 349: JFR Event Streaming
SI現場のテスト自動化への挑戦〜フルコンテナ構成のCI/CD環境〜(#ccc_m4)
発表資料のありか
メモした内容
CI/CDを適用したプロジェクトについて
発表資料より抜粋
点線部分は未実装。Staging, Prodに対するCDは出来ていないのが現状。将来的にはオーケストレーションツール（k8sとか？）を入れて管理できるようにしたい。
Javaのテスト実装について
発表資料より抜粋
・実装コストと収益の損益分岐点のようなものがあるはず。これがどこなのかを見出したい。
・結合テスト(ITa)はCIでは正常系のみとした。
・C2カバレッジは結合テスト(ITa)で網羅的にテストする。
フルコンテナ構成のCI/CD環境について
発表資料より抜粋
・アプリのwarを含むDocker image を生成
・Jenkins Slaveをコンテナで立ち上げる
発表資料より抜粋
UT：DBコンテナを作ってDB接続含めたテストを実施した。
発表資料より抜粋
ITa：外部API、アプリ、DBコンテナを立ち上げて接続テストを行った。
発表資料より抜粋
CIが通っていないとMergeできないようにしていた（上図の赤枠部分。非活性にして押せないようになっている）
⇒テスト品質とテストプロセスが担保された。
2.1 できるだけ実行環境・テストツールにロックインされないこと
発表資料より抜粋
・すべてOSSで構成されている。OSSとコンテナを用いることで、ポータビリティとスケーラビリティを確保できた。
・オンプレ/クラウドに関わらず構築可能なものにした。
実践的なプラクティス
Docker実行方法
Docker outside of Docker (DooD)
課題：オーケストレーションツールの必要性。
①Port Binding
発表資料より抜粋
②コンテナおよびサービス稼働確認
発表資料より抜粋
オーケストレーションツールを用いた理想的な構成を作りたい
発表資料より抜粋
しかしいきなりオーケストレーションツールを導入するのもハードルが高い。まず第一歩としてコンテナ化ツールの導入から始めてみても良いと思う。
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個アクセスされてその機能が動くかどうかは別の話。
発表資料より抜粋
・whileし続けて無限ループになる。どうすればいいか？
発表資料より抜粋
wait()とnotifyAll()を使う。notify()はダメ。最近はフレームワークがうまいことやってくれてるから、直接これを書く機会は減った。
発表資料より抜粋
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
発表資料より抜粋
・普通の人はContinuationをダイレクトには使わない。Fiberを使う。
java.lang.Fiber
（ほぼ）Threadと同じように使える
・タスクの登録：schedule()
・タスクの中断：park()
・タスクの再開：unpark()
Fiber#toFuture()もできる
発表資料より抜粋
発表資料より抜粋
発表資料より抜粋
発表資料より抜粋
park()/unpark()はpachage privateなので、普通呼び出せない。ライブラリがコンテキストスイッチに使うだけ。
j.u.c.l.LockSupport：java.util.concurrent.lock.LockSupport
現状の制限
発表資料より抜粋
・JNIだと使えない
・synchronizeよりはReentrantLockの方が新しくて便利
・パラレルだからsynchronizeを使うというのは考え物。
現状の問題点
・ThreadLocal。FiberLocalみたいなものを入れると重くなってしまう。
・currentThread。Threadを返すと複数のFiberが止まってしまうので、暫定的にダミーのshadowThreadを返している。
・Windowsには未対応。
その他参考
JDKの中にテスト用のHTTPサーバがあるらしい。
マイクロサービス ４つの分割アプローチ(#ccc_g7)
発表資料のありか
メモした内容
（マイクロサービスアーキテクチャをMSAと略して書いたりしています）
ギルドワークスの増田さんの発表。
2019/3/22に参加したDevLoveのイベント（※）で語られなかった、マイクロサービスにおけるサービス分割の4つの軸について語った発表でした。
※
実証されたパターンではなく、増田さん自身が実践したこと、及び実践していないけどこうすればうまくいくかもという話も含まれているとのこと。
発表資料より抜粋
マイクロサービスを実現する技術は揃ってきた。
- クラウド
- コンテナ
- 設計スキル
⇒ソフトウェアをどう分割して拡張性をもたせるか
これらは必要条件であって十分条件ではない。
今回話すのは設計スキルの部分
発表資料より抜粋
マイクロサービス4つの動機
・ロードバランサで分散
負荷分散
リスク分散
データ分散
・異なるサービスの連携
機能分散
今回話すのは機能分散の部分
発表資料より抜粋
・MSAを考える時の増田さんの基本アプローチ
モノリスで作る→モジュール改善
↓
MSAの可能性を検討（部分適用を検討）
↓
移行の検討（部分適用を検討）
・モノリスでもマイクロサービスでも設計スキルの基本は変わらない
関心の分離
高凝集・疎結合
モジュール化
⇒モノリスでもマイクロサービスでも活かせる
サービスの模式図
発表資料より抜粋
・モノリスでも、1つのマイクロサービスでも同じ
インバウンドがあってアウトバウンドがある
データソースを経由してDBや他のサービスから取得
・MSAでは非同期でreceiveして非同期でsendしたり、非同期でsubscribeして非同期でpublishするなど、モノリスの時よりは非同期処理を当たり前に使うことが多い。非同期は、昔からある使い込まれてきた技術。クラウドのmessagingサービスでやりやすくはなっている。
・非同期メッセージングの技術は昔からあったし使われていたが、大規模アプリ向けに自分で mq を構築して運用する敷居は高かった、これがクラウドにより簡単に使えるようになった、結果として非同期メッセージングが昔よりコモディティ化された。
どこまで小さくできるか
発表資料より抜粋
・理論的にはJava APIのメソッド単位。
昔RMI(Remote Method Invocation)というものがあった。メソッド単位でやろうとしたが、、、まああまりうまくいかなかった。
CORBAなんてものも昔はあった。
・限界はクラウド／コンテナ／設計／運用の習熟度
経験を積みながらある程度分散し、習熟しながら次のステップに進んでいく。クラウド／コンテナ／設計／運用スキルの習熟度、経験値に依存している。
どこまで小さくするか
発表資料より抜粋
・論理的なモジュール分割
モノリスでも積極的に分割できるし、モノリスだからこそ大胆にできる。
MSA間の通信
8つの勘違いと真実
発表資料より抜粋
出典：Fallacies of Distributed Computing Explained
穴が開いている⇒必ず何かしらのセキュリティホールがある。
4つの分割アプローチ
発表資料より抜粋
4つの切り口とは
1. 業務機能で分割（ビジネスファンクション）
2. 動詞／ユースケース（ユーザーストーリーもここかも）
3. 名詞／リソース（データモデリングとか）
4. ドメイン駆動設計(DDD)
ビジネスファンクションによる分割
発表資料より抜粋
販売プロセスを21に分割。これくらいの数にはなる。
発表資料より抜粋
・大企業病がそのまま持ち込まれる。
・大企業の場合：業務機能で部門が分かれてサイロ化
・中小企業の場合：機能は分けられるが、人が少ないから兼任している。
・ユーザーが言っている「ここからここまでが業務の範囲」に合わせるとうまくいくのか？
・業務機能と組織は1つの大きなテーマ
・人のプロセスに合わせて分割できるが、逆方向への連携が必要になったときが課題になる
動詞／ユースケース
発表資料より抜粋
・モノリスでも伝統的なやり方
・機能要求、開発範囲として分割しやすい
・ロジックの重複・断片化が起きやすい。例えば、売上と請求を別チームが作ると・・・。
トランザクション単位のマイクロサービスになってしまう
サービス間でロジックの重複、断片化が起きやすい
分岐の条件などドメインのロジックが分断してしまう
・バッチが増える。夜間バッチで不整合を検出するとか、本来ここまでステータス変更すべきだったのをバッチでつじつまを合わせるということが起こりがち。
・対策：薄いユースケースサービス
ロジックを領域ごとに分割、整理
重複や断片化をなくす
これを複数のユースケースサービスが呼び出す
発表資料より抜粋
リソース指向
発表資料より抜粋
・異なる関心事が混在し、肥大化しがち。顧客番号にいろいろな情報を持たせることで肥大化してくるイメージ。
識別番号の世界
異なる関心事が混在して肥大化
⇒はじめは小さかった顧客が数百項目に
・MSAはJOINができない、外部キー制約が効かない世界。
・モノリスが、識別番号にいろいろな情報を持たせすぎていると考えている。管理単位を分ける必要があるのでは？関心事を分離する必要がある。
・モノリスでの捉え方が逆なのかもしれない。本来は同じIDでも分けるべきなのかも
DDD
わからない！（笑）
発表資料より抜粋
・エヴァンス流のドメイン駆動設計とバーノン流のドメイン駆動設計で、コンテキストとサブドメインの関係が異なっている。
・エヴァンス本の方が、設計のやり方に関しては情報が豊富な印象。
・エヴァンス流の定義
境界づけられたコンテキスト
チームのコミュニケーションの範囲
ソースやDBスキーマなど
・サブドメインは変化していく⇒サブドメイン単位での分割は危険。
・境界づけられたコンテキスト
目標
一つのコンテキストに一つのモデル
どっちに倒すかを検討していく
モデルを一つに維持するか
コンテキストを分割するか
ドメイン駆動設計の「モデル」
発表資料より抜粋
・モデル≒ビジネスルール
（正確な解釈ではないが、だいたい合ってる。こう解釈すると、エヴァンスの言っていることが見えてくる）
・ビジネスルールの領域毎にサービスを分けるのはかなり有効なアプローチ
トランザクション分解パターン
発表資料より抜粋
・詳細は資料を探してください
⇒と言われたので少し探してみました。
-
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
| タイトル | 発表者 | |
|---|---|---|
| 初めての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
| タイトル | 発表者 | |
|---|---|---|
| パッケージ管理していなかった既存システムに後付けで 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 （ランチセッション）
| タイトル | 発表者 | |
|---|---|---|
| JJUG ランチセッション | 鈴木雄介 | |
| Cloud Native時代の開発環境とアプリケーション基盤(仮) | 須江 信洋 |
13:30-14:15
| タイトル | 発表者 | |
|---|---|---|
| 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
| タイトル | 発表者 | |
|---|---|---|
| ドメイン管理サービスにおける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
| タイトル | 発表者 | |
|---|---|---|
| ゴールドマン･サックスにおける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
| タイトル | 発表者 | |
|---|---|---|
| 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
| タイトル | 発表者 | |
|---|---|---|
| Functional Spring Cookbook | Toshiaki Maki | #ccc_a7 |
| Serverless Java: Challenges and Triumphs | Shaun Smith | #ccc_c7 |
| マイクロサービス：４つの分割アプローチの比較 | 増田 亨 | #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
最後
資料追加されたら随時更新します