JJUG ナイトセミナー 「Reactive Streams特集」に行ってきた #jjug
かなり前評判高かった感じだったんですが、割と早めに申し込んでいたので無事参加の運びとなりました。
本編
資料は以下です。ともに Reactive Streams の触りを掴む日本語の資料としては秀逸で、取っ掛かりとしてコストパフォーマンスが素晴らしく良いです。僕自身 Reactive Streams についてはなんとなくオレオレイメージでしか捉えてなくてきちんと深入りしたのは今回が初めてでしたが、お話もわかりやすかったのもあってこの2時間だけで理解がとても深まりました。*1
- 概念や定義、特徴や生まれてきた背景、想定されるユースケースなどがわかりやすくまとまっていて、Reactive Streams を俯瞰して輪郭を捉えるのに最適
- Reactive Streams と RxJava のコードを読んで、具体的にどんなものかがわかりやすい
@okapies さんと @grimrose さんのお二方の資料がとにかく素晴らしいので、僕がここでダラダラ書くよりもとにかく資料読んでくださいという感じ。
2015/6/26 追記
@okapies さんのブログでセッションの補遺が上がっており、そのエントリも大変参考になるのでリンクを追加しています。
感想
で、僕個人が感じた感想をつらつらと。眠いので雑に箇条書き。ツッコミあればお願いします。
- Reactive Streams に乗っかることで非同期処理やメッセージパッシングを効率よく簡単に書けるメリットは大きい
- インタフェースが決まっているのである程度決まった書き方があるのは乗っかればいいだけなので理解しやすい
- Reactive Streams で書かれたコードを実行する下回りのランタイム部分がよろしくやってくれて、今まですごく気を使ってたスレッドの待ち合わせとかスレッド間で共有する状態やデータなどをプログラマが気にしなくていいのは精神衛生上すごく楽だし、本来そこプログラマが気にしなきゃいけない本質ではないよね感
- Reactive Streams に則った実装のランタイム間でお互いに繋ぐことができて、かつお互いの世界の中で閉じてコードが書けるのは良い。自分が気にしなきゃいけないスコープが境界で閉じててかつ拡張には開いているというか、Open-Closed Principle っぽいなぁと思った
いい面もあれば、この辺どうなんだろう、という点もあって、
- テスト大変そう
- ストリームから最終的に結果を得るには、block して同期することになるんだろうけど、刻々と変わる状態を追いかけてテストしたいとかあった場合にすごく大変そう
- そもそも状態を気にするものじゃないのか？
- Reactive Streams ならでは設計のパターンやテストパターンみたいなものってあるのだろうか？
- 個々のシステム同士がReactive Streams の世界で小さいシステムやサービスに変化していった時に全体の整合性をどう担保するのか
- そのサービスを利用する側が最終的な結果整合性の段階を自ら定義しておき、その段階の中でどれを選ぶかは要件次第、みたいな感じだろうか？
- 楽になった分、ブラックボックスになる部分が増える？
- 今まで大変だった部分を Reactive Streams のランタイム側が受け持ってくれるから楽になるんだけど、その分実際の運用やチューニングを考えなきゃいけない状況を考えるとｳｯとなる
- 最終的にコード読んで解決できればいいだろうけど、今まで大変だった部分を頭が良い人達が解決してくれた部分を読むわけで、結構しんどそう
- @grimrose さん曰く、RxJava の Observable の中見ると相当泥臭くやってるらしく、勉強になるけど深淵だとも。
- 実行 Flow の最適化や結果のキャッシュをランタイム側がやってくれる余地があるかも、という話もあったので、それに期待？
- それとも分散並列処理が問題意識の根源なんだから、とにかく横に並べてスケールしる、そしたら性能上がるんだよみたいな話なのかしら
懇親会
懇親会でもお二方と直接お話させていただいて、大変勉强になりました。ありがとうございます。あと、@eiryu さんとか @tokuhirom さんとかともお話できたので懇親会すごく楽しかったです。
毎度のことながら運営の方々、お疲れ様でした。ありがとうございました。
*1:個人でおっかけてたら2時間でこの理解には絶対到達できてない
