プロポーザルは次の5つです
- <30分> リアクティブプログラミングのパラダイムをおさらいし、iOS 13以降のCombine.frameworkに備える
- <30分> 自作して理解するリアクティブプログラミングフレームワーク
- <60分> 自作して理解するリアクティブプログラミングフレームワーク
- <LT5分> HUNTER×HUNTERに学ぶRxSwiftのViewModel設計パターン
- <LT5分> Violet Evergardenに学ぶリモートワーク文字コミュニケーション
WWDC19でAppleが新しいリアクティブプログラミングフレームワークCombineを発表してから、世の中のリアクティブプログラミングフレームワークに対する関心というものがさらに高まったのではないかと思います。
Apple自身はこのCombineをリアクティブプログラミングという用語で説明しているのではなく、時間の経過という概念を用いて値を処理する宣言型のSwift APIだという説明を行っています。そしてそのインタフェースは、ユーザイベントやネットワーク、スケジュールされたイベントなどの非同期処理によるデータを表現するとのことです。
もはやそれをリアクティブプログラミングと呼ばない理由がすでに謎。なのですが、まあリアクティブプログラミングという言葉を避けたい気持ちはわかります。その定義に沿っているかどうかということに対してAppleは興味がないか、縛られたくないために避けたのではないでしょうか。例えばFRP（ファンクショナルリアクティブプログラミング）という言葉をよく目にすると思いますが、厳密にはRxSwiftなどのRxは真のFRPと認めないという主張があります。これはRx公式の意見でもあり、RxのTwitterアカウントでもそれを明確にしています。
… although Rx* is not FRP
we prefer to say inspired by FRP, but no, not a subset
で、その中でじゃあFRPってなんなのよという質問に対して、Rx公式のTwitterアカウントは次のように答えています
as opposed to FP, FRP is quite well defined by @ conal, see here:
つまり、stackoverflowで正確な定義があるよってなことですね。
まあこのRxのように、ファンクショナルでリアクティブなプログラミングがFRPではないことが大抵の人にはほぼどうでも良いことではあるんですが、同じようにCombineがRPなのかFRPなのかということもほぼどうでも良いです（しかし実際はdenotativeであるというFRPの表示的意味論に沿っているのかどうかは突き詰めていくと実際は重要ことではあるんですがそれはまた今度）。
ということで、Combineを始めていく際に、リアクティブプログラミングについて振り返ってみようというのが１つ目のトークです。
<30分> リアクティブプログラミングのパラダイムをおさらいし、iOS 13以降のCombine.frameworkに備える
CombineはSwiftUIのためだけのバインディングフレームワークではありません。ですが、おそらく、SwiftUIを成立させるためにはリアクティブプログラミングが重要で、それを外部のRxSwiftやReactiveSwiftなどでまかなうのではなく、自前で作ろうということになった、というのが発端なのではないでしょうか。
このトークでは、Rxを始めとするリアクティブプログラミングフレームワークが、なぜこれほど重要で普及したのかということを紐解くため、歴史から振り返ってみようという内容です。
もともとca_swift第8回目で呼ばれて25分くらいで発表した内容に近いもので、今回はその内容をブラッシュアップしたらもっと良くなるのでは、という感じです。
プログラミングでもスポーツでもなんでも初期に雰囲気でやっていくのは良いのですが、実際に突き詰めていくとなるとそれでは壁にぶち当たることが多いはずで、そのときに歴史や背景を振り返っていくということはごく自然な発想でしょう。
せっかくカンファレンスということであれば、そのようなトークがあっても良いはずというのがこのプロポーザルを出すきっかけとなりました。
Rxなどで採用される関数型プログラミングのアイデアやオブザーバパターン/イテレータパターンとは何か、などの話もしながら、現在公開されている範囲でのCombineの特徴であるバックプレッシャー、Cold/Hotに分かれていない件なども話せればと思います。
<30分/60分> 自作して理解するリアクティブプログラミングフレームワーク
リアクティブプログラミングフレームワークという車輪を再発明していく過程をお見せながら、リアクティブプログラミングフレームワークにおけるルールが実は単純な実装上の制約であるということを示せれば、
より理解が深まるのではないかというのがこのトークです。
30分版
60分版
フレームワークを理解する際に一番手っ取り早いのはソースコードを読んでいくことですが、昨今のリアクティブプログラミングフレームワークというのは当然複雑になっているわけです。
それはなぜかというと、スレッドセーフ、メモリ管理、スケジューラの概念が複雑に入り組んでいるからですね。そのような概念と実装はとりあえず気にせずにコードを書いていけば、一通り動くものができるので、学ぶことを目的としていればそれで十分なはずです。
トークの時間が30分になるのか60分になるのかはどちらでもいいです。
むしろ2,3時間話せるようなテーマなので、30分か60分か決まってからそれに合わせて内容を調整することになります。
具体的には次のようなコードから始めたいと思います。
このようなコードから、次第にオペレータを増やし、ObserverやSubjectを作り、そしてCold/Hot変換をします。
60分あれば偽Combineを作ってもいいかもしれません。
このCombineはimport Combineをしていません。
つまりこれは脳内CombineでありAppleのNDAに触れないのでは？という感じになります。
CombineはHot/Coldの区別がないため、単純なJustですらHotにしていく必要があるため、作る工程は単純ではありませんよね。このことはつまり、Rxなどのようにプラットフォームにまたがったフレームワークにおいて、
Coldがあるというのはフレームワーク実装者にとって開発のステップをシンプルにしてくれる作用もあったと私は感じます。逆に言うと、クローズドなCombineにはColdな性質のストリームはそもそも提供する必要がないと判断できるのではないでしょうか。
リアクティブプログラミングというのは難しいのですが、それを作る過程を見せることでそれが簡単に見えるはずです。そしてその奥深さがわかりやすく伝わるのではないかと思います。
<LT5分> HUNTER×HUNTERに学ぶRxSwiftのViewModel設計パターン
LT5分のほうではさらに実用的なトークを考えました。前述の30分のトークでリアクティブプログラミングとはなにか、ということがなんとなく分かった気になったところでじゃあ実際仕事に活かすにはどうすればいいいのか、というのがこのトークです。
このトークは、私の書いた「RxSwift研究読本3 ViewModel設計パターン入門」を基にして、ハンターハンターの制約と誓約の考えが、リアクティブプログラミングのViewModelを設計する上で重要だという切り口で展開していく予定です。
RxSwift研究読本3 ViewModel設計パターン入門
何かの参考に、この本の評判をランダムに選んだものを乗せておきます
ハンターハンターを読んでいると「制約」を条件、「誓約」をペナルティと解釈した私の考えが正しいかはさらに分からなくなってしまうのですが、このトークでは同作の「制約と誓約」の名場面を振り返りながらViewModel設計に例えて話そうと思います。
<LT5分> Violet Evergardenに学ぶリモートワーク文字コミュニケーション
パソコンに向かってプログラミングさえすればいい、
我々の仕事はそんなふうに思わることが多いのですが実際は対面/リモートの打ち合わせや、文字コミュニケーションによる連絡が問題解決になることが多くの時間を占めています。
ヴァイオレット・エヴァーガーデンという物語は、少女兵として戦うことしか知らず、人の心が理解できない主人公ヴァイオレットが戦争終結後に手紙の代筆屋として言葉を仲介する仕事を通じて人と触れ合いながら成長していくストーリーです。
我々の仕事におけるコミュニケーションでも、このヴァイオレットと同じように少女兵的なスタイルをとってしまっていないでしょうか？というのがこのトークで話したい部分です。
プロポーザルの紹介は以上です。
プロポーザルが選ばれるか選ばれないか、ということも重要ですが、
会場で会った際には上記の内容で会話できれば楽しそうですね。
最後に、プロポーザルのリンクは次のとおりです
<30分> リアクティブプログラミングのパラダイムをおさらいし、iOS 13以降のCombine.frameworkに備える
<30分> 自作して理解するリアクティブプログラミングフレームワーク
<60分> 自作して理解するリアクティブプログラミングフレームワーク
<LT5分> HUNTER×HUNTERに学ぶRxSwiftのViewModel設計パターン
<LT5分> Violet Evergardenに学ぶリモートワーク文字コミュニケーション
iOSDC 2018では次のようなプロポーザルを出していてasync/awaitの話が採択されていました。
