最近、個人的にSpring Bootが気に入って、Springの技術動向を追うようになりました。
仕事も暇だし、ちょうどいいタイミングでSpring Oneの報告会があったので行ってきました。
以下、サイト公式サイト
JSUG勉強会〜Spring One 報告会！
六本木 is リア充エリア
六本木ヒルズが会場だったんですけど、やっぱり六本木はダメですね。。。
なんか雰囲気が！
イルミネーションがいっぱいあり、綺麗は綺麗なんですけど、どうもそわそわする。
卑屈な人間が行くところではありません。
できればもう行きたくない。
入り口が不明だ！
到着してからが、結構キツかった。
会場の入り口がさっぱりわからなかった。。。
森ビルは、前にGREEで行われたJava One報告会できたことあるから余裕だろ？って思ったけど、そうでもなかった。
声をかけたくないインフォメーションセンターの受付の人(女性)と話すはめになるとは思わなかった。
受付で対応してくれた方、どうもすいません。挙動不審で。
こころよりお詫び申し上げます。
会場は森ビルではなくてアカデミーホールらしく、行っても受付けとか無くて困った。。。
なんとかエレベーター見つけて、49Fまで上がって会場には付けた。
会場到着！
前置き長くなりました。
話は聞いてきましたが、全部は覚えてないです。。。
興味があった内容だけ紹介していきます。
Reactive Programming
Spring OneのReactive Programmingに関してのまとめでした。
なんとなく理解はしているのですが、バズワード*1の域をでないです。
Spring Oneの各セッションも同様な感じだったようです。
報告内容では、コンビニに例えて説明していました。
各役割は以下の通りです。
- コンビニ = サーバー
- 客 = リクエスト
- レジ = スレッド
- 店員 = 処理
リクエストをレジで待ち、リクエストがきたら店員が対応する。
リクエストが増えてきたらレジを増やして対応し、それでも対応できなくなったらコンビニを増やすといった内容でした。
コンビニやレジを増やすのには資源(資金)の限界があるので、効率よく店員が処理する必要があり、
店員がレジの温めとかの作業中(他サーバーの処理待ち)とかに作業出来るようにするのが、Reactive Programmingであると行った内容。
最初、「コンビニに例えると・・・」ってくらいから怪しい感じがしましたが、なんとなく意味は伝わりました。
ノンブロッキングをどう対応するかが、Reactive Programmingの本質なのかなぁ～と思います。
自分が受けてきた説明で一番分かりやすかったのは、Excel関数もしくはソースで例えた表現ですかね。
粒度が細かい方がしっくり来た感じがします。
エンジニアだからかもですが、ソースに近い方が共感を得られる気がしました。
どちらかと言うと、一般人向けの説明ではありましたが、見方が少し広がった気がします。
自分の中でのReactive Programmingは、マイクロサービスで処理を小さく作ってシームレスに繋ぎ、処理が止まらないように実装することだと今までの説明を聞いて考えました。
次期Springでは、Reactiveのプロジェクトが統合されるそうです。
現在はSpring Reactiveで実験中だそうです。
どうでもいいですけど、Reactiveと聞くとリアクティブアーマーを思い出します。
日本語だと「爆裂反応装甲」ですね！
リアクティブアーマーに紐付けてReactive Programmingを考えると、即時性の処理だってことが覚えやすかった。
遊戯王の「炸裂装甲(リアクティブアーマー)」から興味をもっていろいろ調べたんですけどね！
また、つまらぬことを書いてしまった。。。
Spring REST Docs
こいつが一番面白かった！
何かって言うと、Springによるドキュメント生成FWです。
今のドキュメントは色んな問題を抱えている。見難いし、嘘があるし、メンテコストが高いし、実装との差がひどい。
それらの問題に立ち向かうためのFWだそうです。
いま参画しているプロジェクトがもろにそんな感じで、共感をしました。
で、実際どうするかと言うと、テストコード⇒ドキュメントで生成するそうです。
なぜテストコードから生成するかと言うと、仕様と実装の差をなくすためです。
テストコードでテストOKだった＝実装と仕様が合致している＝ドキュメント化しても問題ない・嘘がないになるため、テストコードから生成する。
非常に筋の通った意見です。テストコードは仕様を確認するためのものでなくてはなりません。着眼点として非常に面白いと思いました。
それに、未だにExcelで仕様書書くのは無理があると思います。
設計書=仕様であるならば、仕様は常に進化します。(エンハンス対応とかで。)
つまり設計書は常に進化・変化するものであり、変更に強くなくてはいけません。
それがExcelだと、中身を開くまで対応したか分からない、差分が人間に分かりづらい、フローが描けないなど、仕様書を書くには向いてません。
本来はもっと別な用途であると思います。
それを解決するためのSpring REST Docsです。
実際のドキュメント生成にはAsciiDocterというものを使い、随時生成していくそうな
以下、作成までのイメージ
テストが通ったものだけドキュメントが作られるので、誤記が少なく、動くことが書かれる。
テストコードの何をリソースとして出力するか？という問題はあるが、即時に動くものだけドキュメントが作れる恩恵はデカイ。
アジャイル的な開発にも向いているし、Reactive開発といった視点から見てもありだと思う。
話しを聞いて、大変興味をもった。
まだ、日本語のドキュメントは少ないそうな。。。
これを機に英語覚えて早く使いたい！
感想
JJUG CCC2015 Fall でもそうだったが、JavaEEと比べるとSpringが魅力的に見える。
JavaEEも標準化はいいのだが、もうちょい早く対応サイクル回して欲しいとは思う。
調査ができていないので、これから気になったものについてきちんと理解をしておきたい！
*1:具体的な定義がないキーワード
