Help us understand the problem. What is going on with this article?

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

More than 1 year has passed since last update.

はじめに

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

最後

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

taumax
Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away