JJUG CCC 2019 Fallに行ってみた

JJUG CCC 2019 Fallに参加したので、そこで得た気付きや感想をまとめたいと思います。
自分が見た発表は以下の通りです。
![IMG_8150.jpeg](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/538251/514856ad-e877-e2a3-9dac-4996ca619f6b.jpeg)



# Gradle を完全に理解した人が、何も分からなくなるための第一歩
### 発表資料
https://qiita.com/opengl-8080/items/c482998fa15ce738e2ba

### 気付き
* Gradleでタスク管理が行える。
* Gradleは依存関係で考える必要がある。
    - depedsOnで制御できるらしい。
* mustRunAfterで制御もできる。
* コードを書く際には宣言的な記述で記載すべき。その心は作り手の意図を端的に表し、ソースの可読性を上げるため。
* filetree()を利用して、include とAntパターンの組み合わせで任意のファイル・ディレクトリ単位で取得できる。

###感想
Gradleがよくわかってなかったことを痛感した。
そもそもビルド順を指定する必要性ってな〜に？
Gradleを利用することで解決できることがまず理解する必要があるなと思った。




#🔰Javaで学ぶオブジェクト指向プログラミングの基礎知識
###発表資料
https://www.slideshare.net/masuda220/java-objectoriented-programming-primer

###気付き
* 増田さんはプログラマとのこと。
* 基本プログラムで伝えることをモットーとしている。
* 発表の内容は「現場で役立つシステム設計の原則」のネタ元・背景として考えた内容とのこと。
* キーワードは「モジュール性」「シームレス性」
* モジュール性は型（値の種類）を重要視する事＝値オブジェクトが重要ということ？
* 型にこだわる事で変更容易性や再利用性は向上する。
* シームレス性は「分析〜モデリング〜設計〜プログラミング〜保守」の継ぎ目をなくす事
* 腹落ちして欲しい内容は２つ「型」「カプセル化」
* 型は”範囲”と”操作”を制限する。
* 「現場で役立つシステム設計の原則」の１章２章はカプセル化というワードを使わずにカプセル化を説明している
* 型×カプセル化＝クラス
* 設計力＝独自の型の発見と改良のスキル
* 独自の型は現実世界とプログラムの直接的な写像
    * 値オブジェクトは直接モデルングして、集約とかコンテキストはメンタルモデルの写像なのかな？

###発表後に質問した内容
範囲の制限と操作の制限以外に制限を行うべきものはないのでしょうか？（自分）
→基本的にはないです。（増田）

###感想
モデリングについて、難しく考えていたけど
あまり難しく考えなくても良いのかなと思った。
基本的に型を作って、改良していくことが重要

#【ランチセッション】JJUG初心者のためのJavaコミュニティのススメ

###気付き
*お弁当を食べながら聞いたので、メモ取れてないので写真を数点。。。。*
![IMG_8152.JPG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/538251/674ae2ea-d023-e037-5ccd-8951396cd353.jpeg)
![IMG_8155.JPG](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/538251/ad37e667-390f-462a-c5c6-9f1cd248ea64.jpeg)


#🔰開け！ドメイン駆動設計の扉
###発表資料
なし
**内容を見たい方は是非成瀬さんに講演依頼をしてみてください！**（なぜか宣伝w
<blockquote class="twitter-tweet"><a  href="https://twitter.com/nrslib/status/1198111940188356608"/></blockquote>

###気付き
* GMOインターネット社内で研修で利用している。
* ボトムアップと切り口を変えて、EricEvance本ちっくに解説する
* DDD原著を読むためには準備運動が必要。
* 仕様書がないと「仕様を探しにコードの森に旅に出る」しかない
* ソフトウェアの利用者とコードが地続きになること。
* DDD設計は最初期にコストを払って、変化に強くしようとすること。
* ドメインに含まれるものを決めることが重要
* ソフトウェアにとって役立つ知識を抽出化したモデル
    * トラックを例に「アクセルを踏む」「荷物を運ぶ」ドメインが物流システムなら「荷物を運ぶ」が重要、ゲームなら「アクセルを踏む」が重要
* ドメインモデルによるソースがドメインオブジェクト
* 「業務⇄ドメインモデル⇄ドメインオブジェクト」をイテレーティブに反復する。
* ドメインエキスパート≠ステークホルダー
* ドメインエキスパートと業務観点で同じ言葉で話しましょう＝ユビキタス言語
    * 業務上、普段からやっている・意識している事では？
* ドメインエキスパートの固有語を利用するわけではない。技術者と共通で話せる言語を構築する。
* Entity：同一性（ Identity）で識別できる。→IDで識別できる。
* リポジトリ：同一のインターフェースで実体はDIで別に作る。
* リファクタリングは勇気を持って行う。これを行わないと変更容易性は得られない。

###発表後に質問した内容
ドメイン駆動設計を行う事で業務のルールはコード化できると思いますが、
ルールには現れない業務の背景はどうすべきでしょう。（自分）
→そのような知識は資料に落とすべきで、ドメインモデルに吹き出しなどで表すのが良いでしょう。（成瀬）

###感想
業務とドメインモデルとドメインオブジェクトの関連性についてモヤモヤしていた部分明確になった。
大まかな部分の話がメインだったので、原著を読んで勉強したいと思った。




#🔰まだまだ間に合うJUnit(再)入門
###発表資料
https://speakerdeck.com/yusuke/jjug-ccc2019-fall

###気付き
* Inteli Jのコーディング早い！
* assertThat（ham crest）は５ではJunit利用できない？
* テストを先に書くメリットは実装の先入観がないため、ブラックボックスとして考えることができる。先に実装すると、テストケースが実装に引っ張られる。
* テストケースには日本語を記載したほうがよい。（ただし、開発メンバーが日本語ができることが前提）
* assertAllメソッド良いよ
* Getter／Setterメソッドやライブラリのテストを実施するのは辞めた方が良い。

###感想
テスト駆動開発のススメのように感じた。
IDEやJunitやCIが進化してきているからこそ、テストをモダンにすべきなのかな。
”ASTER”のカンファレンスなどでも情報収集しないと

#AngularとSpring Bootで作るSPA + RESTful Web Serviceアプリケーション - 開発ツールやプロジェクト構成も含めて45分で丸わかり -
###発表資料
https://www.slideshare.net/ssuser070fa9/angularspring-bootspa-restful-web-service

サンプルコードも落っこちていた
https://github.com/Masato1986/angular-spring-parent

###気付き
* AngularとSpring Bootの研修を提供しており、その宣伝として
* カサレアルの多田さん。pivotalに認定されているマイクロサービス研修講師
* SpringBootはPivotal社が中心に開発している。
* DisptatcherServletで全てのリクエストの振り分けを行う。
* セキュリティ対策もライブラリ（Spring Security）で提供してくれている。
* Spring側で「＠CrossOrigin」を使うと異なるホストでもリクエストできるようになる。


###感想
コーディング的な話が多く、あまり理解できなかった。。。。
（というか眠くなってしまう）
資料がアップされたらちゃんと見よう。
あとは、SpringとAngularは親和性がよく、Angular向けのライブラリもあるというのはためになった。


#JavaでTracing
###発表資料
*あとでハッシュタグ[#jjug_ccc]付けて発信してくれるらしい*

###気付き
* サービスメッシュの話
* Istioというツールでサービスメッシュを導入できる。
* Istioでサービス間認証もできる！すごい
* OpenTelemetryというツールで分散トレーシングができる
    * ２つのシステムを統合されてできているらしい。
* 特定のサービスや特定の条件で遅延が発生しているかが分散トレーシングを利用することでわかるようになるらしい・・・・
    * 本当に？
* 分散トレーシングの大きな概念は「Trace」と「Span」
* Uberが開発したイエーガー（Jaeger）とOpenTelemetryを組み合わせるパターンを説明していた。
* Javaでコンテナ化する際に、デプロイ時間が問題になる。それを解決するのが「Quarkus」。コンパイル時にJVMなどをバイナリ化してしまうらしい
* 全体の構成説明

###感想
分散トレーシングの概要も理解できなかった。。。
具体的にどのようなことができるのかから、勉強しないと。。。

#Swagger ではない OpenAPI Specification 3.0 による API サーバー開発
###発表資料
https://www.slideshare.net/techblogyahoo/swagger-openapi-specification-30-api

###気付き
*  Swaggerの進化形がOPEN API３.0
*  SwaggerとOpenAPIは元が同じ（全日本からノアが生まれた的な感じ）
*  OpenAPIの方が Swaggerよりも開発が活発
* 「Generation Gap パターン」というツールで生成したものはリポジトリ管理しないという考え方がある。


###感想
Swaggerがある程度わかっていないと理解するのが難しかった。
Udemyとかで講座ないかな。。。。


#総括
非常に参考になるカンファレンスが多かった。
ただ、自分の知識不足で腹落ちしきれていないもの多かったのは反省点。。。
もう少し、勉強した上で、資料を読み直してみたいと思いました。

@nisioka55さんが発表資料をまとめてくださっていたので、そのツイートを載せておきます。
この資料をまたゆっくり読んで、来年の春のJJUGに備えたいと思います。
<blockquote class="twitter-tweet"><a  href="https://twitter.com/nisioka55/status/1198282917392203776"/></blockquote>