今年も会社のお金で、大阪から行ってまいりました。
今年は、会場内の通路移動が一方通行になっていて、とても快適に移動することができました！
２回目の参加ですが、ブラッシュアップされていってるんだなぁというのを感じることができました。
では、私が参加したセッションの簡単な紹介と、所感を書いていきたいと思います。
JavaでWebサービスを作り続けるための戦略と戦術
内容
2009年からJavaを中心として稼働しているビズリーチのシステム、運用していくなかで得られた知見を広くふんだんにお話いただき・・・たかったのですが、内容が充実しすぎて全６章のうち２章だけで40分（45分中）を消費されて、あとは超超駆け足でした。
所感
内容もプレゼンテーションも素晴らしくて、私自身残り時間をまったく意識せず引き込まれていました。
特に実践的に役に立ったのは、開発者の環境構築のお話でした。
工場出荷状態から開発できる状態にするための手順はすべてsetup.shに集約されていて、開発環境構築手順書なる大量のドキュメントは持っていないというお話でした。
必要なソフトのインストール、ローカルにDB構築するDocker構成、DBへのデータ投入まで、すべてshell実行で準備するというのは、なるほどぜひ試してみたいと思いました。
私自身が現在参画しているプロジェクトでも、お客さんに収めるシステムなので開発環境構築手順書を準備していますが、この手順書のメンテナンスというのがなかなか後追いになってしまいます。開発が中盤に差し掛かると暗黙的に慣習化した手順が乗っていなかったり、適当な表現で再現性がなかったりと大変です。
システムのプログラム自体をコードで納品するのですから、開発環境構築の手順をコードで納品することは、十分説得可能かと思います。コードに概要的な設計書があるように、開発環境構築コードに概要的な設計書さえあれば十分です。
その他駆け足だったトピックも、ぜひ後から資料を読んでキャッチアップしていきたいと思います。
Kotlin + Spring Bootでサーバー開発
内容
個人でKotlin+SpringBootでサイトを開発する中での、やってみての印象や好きなポイントをお話いただきました。
何か特定のフィーチャーに特化したものではなく純粋にユーザとしての印象のお話で、内容がよく響いてきました。
所感
最近はJavaとTypescriptである程度verboseに見えるコードを書いていますが、Kotlin自体のシンプルさと、SpringBootのアノテーションを活用した意味付け的なコードをあわせると、ほんとうにコードベースが小さいままやりたいことができて、個人や小規模・少ない時間でクリティカルなアプリケーションを構築するのに便利そうだと感じました。
サーバをKotlinとSpringBoot、Typescript側のAPIはSwagger・DtoをKotlinからJavascript生成（Typescript生成できたら尚良いんだけどどうなんだろ）すると、ステキそう。
ざっくりわかった気になるモダンGC入門
内容
最近のシステム環境の変化によって、新しいガベージコレクションが生まれてきているという話。 コンパクトに、必要なキーワードがまとまっていて、私のように後から調べてやっとわかる、というようなスタイルでも安心の内容です。
所感
正直にいうと、いままでガベージコレクションのこと、全然考えてませんでした。
すみません。SELinuxもdisabledにしてた人間です。石川さんごめんなさい。
実際に話を聞いてみると、ガベージコレクションは「難しい」「複雑」というよりは「堅実」「ですよね（これもういらないよね？とか）に則ったもので、思ってたよりも素直に聞くことができました。
おそらく必須文脈であるCompactionとかそのあたりを、気が向いたらちょっと勉強しておきたいと思います。
やっぱり「Linuxのしくみ」読まなきゃいけないよなぁ。買うか。
書いました。いま。
普通の人のためのJavaコミュニティイベントのススメ
内容
www.slideshare.net
JJUG、ないしはコミュニティイベントの初心者向けのお話でした。
Virtual JUGって、きになる。観てみようかと思います。
所感
人によって気になるポイントは違うと思うので、社内でフィードバックする際にも漏らさずこういう話も展開したいと思います。
うちの会社は外の勉強会に行くような人がほとんどいないので、少しずつでも啓蒙活動していきたいですね。
Pivotal認定講師が解説！ReactiveだけじゃないSpring 5 & Spring Boot 2新機能解説
内容
www.slideshare.net
毎度おなじみ多田さん。今回はSpring5とBoot2のお話でした。
CoreなどそれぞれのSpringファミリーごとに、キーワード・トピックベースでお話されていて、これも後から追いかけるのにとても助かる資料です。
所感
「使い方なんてマニュアル読めばええやん」という意見もあるかもしれませんが、SpringFrameworkって、結構そうはいかないかなと思っています。
まず、フレームワークで一番大事なのは「記述方法」ではなく、「なぜこの記述になっているか」「こういう時に使って欲しい」「こういう使い方はしないで欲しい」という考え方が一番大事だと思うからです。
フレームワークへの想いはこちら。
また、それらフレームワークの中でも、特にSpringBootは
というような考え方だと思っています。なので、アノテーションの意図・用途を正しく理解することが、大事。「アノテーションの名前長いよ！」と思うのは英文脈的なアノテーション名になるからで、そのアノテーションの意図の理解はマニュアルだけだと理解が難しいです。マニュアルには「こう使え」、としか書いてませんからね。
このスライドは、おそらくこれからも度々参照することになるでしょう・・・関連機能に近づくたびに・・・お世話になります🙇🏻♂️
如何に “データが壊れない” 管理画面を作るか - 管理画面開発の裏側
内容
www.slideshare.net
管理画面のインタフェースに行き着くまでの内部のアプリケーション・プログラムのアーキテクチャのお話でした。依存関係とか安全性とか、結構抽象的な内容だったので、茶の間の反応は「だよねー」って部分と「ほぅ・・・？」という部分で構成されているような感じでいた。
所感
アプリケーションコンポーネント間の結合で「一部に汚れ仕事を任せることで、全体としての安定性、機動性が保たれる」という話は、個人的に一番「だよねー」と感じた部分です。
全体的に「お互いのことを意識しつつ慎重な構成になる」よりは、ほとんどのコンポーネントが「このコンポーネントとしての美」によってアーキテクチャとしてわかりやすくなり、「汚れ仕事」＝「何でも屋」をある程度コンパクトにまとめるというような。
なんとなくですが、 「Spring Bootのアノテーション」 と業務判定やDTO変換など 「意味を持つ主となるビジネスロジック」 の関係に似てる気がしなくもないかな〜と個人的には思います。
気にせずこのコンポーネントとしての美を保ったものを、フレームワークとして提供するのがSpringBootというか。
うーん。
俺はSpringになれない。
Spring Cloud, Docker & Kubernetes - Lessons Learned in the context of an OSS Project
内容
コンテンツとしては、ActivitiというOSSプロダクトをクラウドネィティブ構成で稼働させるための変更や検討のお話・・・だったように思います。
全編ほぼ英語で、しかもスピード早く、しかも遅れて立ち見になりメモできず、しかも体調悪くなって途中退出して・・・全く頭に残っていません。。。
見ていた感じ、CNCFが提供しているTrailMapに則ったような感じではなかったですね。模索と検討のお話でした。
5/29追記 資料公開いただきました！ありがとうございます！
お待たせしました。 #jjug_ccc #ccc_i5 の資料は、こちらです。 @saikou9901 @suke_masahttps://t.co/vmSuZG6BaHhttps://t.co/FBnLZTKkKC
— Daisuke Yoshimoto (@daisuke_yoshimo) 2018年5月29日
所感
（資料が出てきたら、読んで何か書きます・・・）
5/29追記
スライド中にもありますが、Journeyの果てが「？」というのが、なんともわかりみがある気がします・・・Cloud Nativeの条件は、今ままでに構築してきたアプリケーションとは大きく異なります。アプリケーションの分割単位、API毎の規模、アクティビティの複雑さなど。ある程度の機能を持った大きなOSSだと、再配布可能性や、利便性などのために工夫をしているはずなの、輪をかけて難しいと思います。
システム、アプリケーションに大切なことは「ソリューション」です。時代に合わせた「ソリューション」を常に考えていく体力が大切だと感じました。
Logicadの秒間16万リクエストをさばく広告入札システムにおける、gRPCの活用事例
内容
www.slideshare.net
広告配信サービスLogicad（ロジカド）の広告データAP、入札AP間をgRPCで構成したらうまいこといけてそう！というお話。
主題として「レイテンシ」「スループット」に的を絞ってお話いただいたので、かなり理解できました。
所感
会場では結構な人数が既知だったgRPCですが、私は名前くらいしかきいたことがなかったので、説明してもらってとてもありがたかったです。
うちでやってる仕事も、いまのところはデータセンター内で完結するようなものなので、レスポンスが要求されるような場合の事例として知ることができ、実用的な意味ですごくありがたい情報でした。
ちなみにセッション後の懇親会でちょっと質問しました。
Q: gRPCの利用時にTLSナシで平文で通信してるということだが、それに加えて広告配信サーバもスケールアウトすると、平文通信がまずいネットワークを利用するようになることはないか？
A: 広告配信含め、すべて１データセンター内で実現している。もともと物理距離を縮めるために１データセンターでやっていて、そこで今の規模はいけてる。
Q: 実際に構築しているのはウルシステムではなくソネットメディアネットワークスだが、テクニカルスキルはどうやって確保している？
A: ソネットメディアネットワークスさんもともとテクニカルスキルすげぇので・・・
すげぇらしい・・・🤔🤔🤔
DDDとクリーンアーキテクチャでサーバーアプリケーションを作っている話
内容
www.slideshare.net
ジャストシステムの、まだ公開できないプロダクトでDDDとクリーンアーキテクチャを使っている最中、という話。
しっかりとDDDやアーキテクチャの文脈、知識を集め、要点を押さえて忠実に実施している、というような印象でした。
しかもそれで「ひでぇ！」みたいなことにはなってなさそうな印象。
所感
DDDやクリーンないしはオニオンアーキテクチャでも、正直私の近くだと「気に入らない」「こうは言うけど、理想ばっかり実際無理だよね〜」「そもそも思想とかどうでもいい」というような、諦め口調の方がよく聞きます（もちろん、新規構築できるか、作り変えるパワーがあるか、といった物理的な制約はありますが）。しかし、そうではなく「理解しようとする」姿勢があるように見えるのが、本当に良いと思います。
アーキテクチャ、各レイヤー・コンポーネントのあるべき姿を定義するにあたってDTOなどの変換が増えてくることについても、私個人としては「やるべきことでしょ」と感じますが、人によっては「面倒だし、このレイヤーとこのレイヤーは”大体”一緒だから、これは使いまわそう」ということにもなったりします。そういった目先の手間によって「哲学」としての設計がおろそかになっていくことは、「適宜」というよりは「手前味噌」なんじゃないかと思います。
また、ユビキタス言語やプログラムのパッケージなど、ネーミングへのこだわりも、私も似たようなところがあるので「自分の考えも間違ってはなかったんだなぁ」と安心した部分もありました。その意味で、このスライドでの試みは、私の好きなやり方に則っているなぁと感じました。今後このプロダクトについて何か情報があれば、それは私自身のブラッシュアップにもなると思います。そんな事例に出会えたことは、今回イベントに参加してよかったことですね。
・・・
エンジニア募集してる・・・んですよね・・・
いや、深い意味はないですよ・・・
まとめ
今回はセッション全体が広いJavaの活用事例というような印象で、イベントの規模で見ても、改めて 「3 Billion Devices」 の説得力を感じさせられるイベントでした。
おわりに
どのイベントに行っても、セッション選びは、結構直感で選んでいます。
前回参加したのは2017年の春でした。
この時は個人的な興味もあってマイクロサービス、Springを中心としていろいろまわっていました。
今回はそれが落ち着いてきて、幅広く「Javaのしくみ」「Javaの活用」という感じの 純粋なJava に少しずつ関心がよってきているように見えます。それに加えて、広告配信サービスのレスポンスなど要件をベースにした実現方式についての興味もあることが伺えます。
まとめると、私はおそらく 「ビジネスのソリューションとして、Javaを適切に活用したい」 というのが一番の興味になっています。 Javaといっても、言語というよりはプラットフォームとしての捉え方です。ということは JVMと言い換えられるかも しれません。
最近はJavaのプロサポートのごたごたなど、Javaついていって大丈夫かな？という不安がありましたが、ランチセッションの内容や参加者の雰囲気などを見ていると、Javaも近年のフロントエンドと同じように「みんなで作り上げていくもの」になってきていること実感することができました。
私はITやプログラムは好きですが、あくまで「ツールとしての好き」なんだ、という今更ながらの自分の性格が少しずつ見えてきました。今後のキャリアの中でJava（ひいてはJVM）と、握手してやっていきたいですね。
