iOSアプリ開発のためのFunctional Architecture情報共有会のまとめ

2020/10/25にiOSアプリ開発のためのFunctional Architecture情報共有会を開催しました!その発表のまとめを書いておきます。見直すのにだいぶ時間がかかりました。

情報共有会について

そもそもFunctional Architectureとは?

Functional Architectureとは何かみたいなものを一応解説しておくと、その答えはどこにもありません。しかし発端としては@inamiy(稲見さん)の『 SwiftUI時代の Functional iOS Architecture』という発表により紹介された各種フレームワークや、関数型プログラミングの考えを取り入れたiOSアプリ開発についての情報を共有するという会です。

各種フレームワークは下記の通りです。

  • The Composable Architecture(以下TCA)
  • bow-arch
  • Hervest

ちなみにiOS以外でも参考になればかまいませんし、自分で考えたオリジナルでもかまいません。

そういうのもあって、TCAのKotlin版であるKotlin Composable Architectureでもかまいませんし、Redux-like architecturesであるReSwiftでもいいわけです。Redux-likeなフレームワークでも良い理由としてはReducerが純粋関数を目指そうとするという点があれば、それは関数型プログラミングの考えを取りいれているというコンセンサスがあるためですね。つまり意図的にかなり間口を広げちゃってるという感じです。

だいたい下記の要件に当てはまる関数型の特性を活かしていればFunctional Architectureと言えそうです

  • 純粋関数を扱うことに焦点を当てている
  • 副作用を扱うことを区別している
  • 関数合成を利用した宣言型な処理スタイルを利用している

なぜこういうことをやってく必要があるかというと、部品を組み合わせられるように作ることで再利用しやすくテストコードを組み立てやすくしていて、さらにコードが何を実行してくれるか想像しやすくもしているっつうわけです。

勉強会ではなく情報共有会とは?

勉強会という名前にしないのは従来のオフラインでの勉強会スタイルから考えを変えたいためです。例えばよくあるオフラインでの勉強会スタイルというのはどこかのオフィスで企業が主催して発表者、そして、その発表を聴く人たちいるというスタイルです。目的はリクルーティングだったりするんでしょう。他にはコミュニティを作りたいみたいなのも従来のタイプだと思います。そういう勉強会は人が多く集まったほうがいいんだと思います。ただ自分がなぜそういう場所で発表するかというと情報交換をしたいんですよね。自分は発表して一方的に話して終わるということを目的としてなかったことに気がついたんです。もちろん、一方的に話して終わりのタイプでもしょうがないこともありますけども。

さらにiOSアプリ開発というジャンルはもうめちゃくちゃ広くなってる。普通にデザインの話から機械学習の話、さらに電話の話までいくらでも話題はあるんですよね。だから会ごとにある程度テーマを絞ったほうが話す方も前提知識を説明しなくて済むし、聴く方もそれを求めると思っています。

オンラインの勉強会というのはありがたいことに参加が簡単なんですけど、参加が簡単がゆえに従来のオフラインの勉強会の感じそのままでやってしまうと本当に聞く方は気軽にいっぱい集まってしまう。その体験って話す方としたら情報交換を目的としている何かとは別の感じになると思うんです。全然知らん人がオンラインでたくさんいるというのが緊張するし。本来情報交換したいんであって緊張なんてしたくないわけですよね。

前置きが長くなりましたが、そういう理由があって情報共有会という名前にしました。今書いてみてわかりましたが情報交換会が意味的には正しい。そういうのをやりたかったというのがモチベーションです。そして基本は参加者全員発表スタイルです。でもどうしても発表することはないけど、次回は参加したいからどういう雰囲気なのか見たい人もいると思うのでTwitter実況枠を用意しました。

結果的に今回は自分入れて4人が発表でTwitter実況枠が0人でした。もともと発表枠は5人の枠だったので自分が二人分発表するという形にしてたので、人数が足りないから困るということはないです。なのでこういう会を開催したい人はどんどんやってほしいとも思っています。

利用したシステム

Zoomのウェビナー

Zoomのウェビナーでやってみたのですが知見は下記2つです。

  • 設定している時間を過ぎても何も起きず、切断されるわけじゃなかった
    • ウェビナーは時間を終了時間も設定するのでその時間を過ぎたらどうなるのかと思ってた
  • 全員発表ならウェビナーにする必要がそもそもない
    • ウェビナー参加者を発表者に選んでいく機能を使っていったのでウェビナーの必要性皆無です

全員発表だとウェビナーの意味がないということがわかったというのが収穫なわけです。やらないとわからないからやってみたという感じです。ウェビナーは本当にセミナーなどで参加者同士が交流する必要がない場合に使われるユースケース何だと思います。今回はやりませんでしたが、参加者を事前登録制にできたりするので、そういう用途に向いてるんでしょうね。私は他にもRxSwift研究読本の読書会なんかをやってるのでそういうのにはZoomウェビナーは向いてると思います。

発表前に『質疑応答をリアルタイムにやるか、あとでまとめてやるか』を確認

まず、ROXX社さんの開発ブログの記事『Vue3 について語る会をした』にて、質疑応答をリアルタイムにやって盛り上がったとか書いてありまして

当日は自分が中心で話していたんですが、質問や疑問は随時受け付けていたので発表というよりは、ディスカッションに近い形で実施できたことが大きかったです。

このスタイルは オンラインの勉強会の短所を補ってる 気がします。というのもオンラインで何の反応もなく一人で喋ってるようになってしまうのはやってみると不安になるわけですよ。ちゃんと接続できてないんじゃないかとか、もしくは内容が伝わってないんじゃないかと思ってしまう。ちなみにオンラインカンファレンスの事前収録では自分でも一人で喋るのでやってることはだいたい同じなんですがその不安はないんです。つまり、人がリアルタイムで聞いてるという前提があるのに反応がわからない状態だと不安になるわけで、そのために質疑応答をリアルタイムにやっていくというのは良い方法なんでしょうね。

ただ、リアルタイムな質疑応答にも短所があって

  • リアルタイム質疑応答だと発表者がやりづらいかもしれない
  • 発表のタイムキーピングが難しい(質問がながければ終わりまで伸びる)

そのために「発表はリアルタイム質疑応答でやるかどうか」っていうのを発表者に確認するというのをやってみました。これは4人中3人はリアルタイムでやったと思います。慣れてくると発表者がアンケートを最中にとるのはいいかもしれませんね。「Redux使ったことある人Zoomの挙手で反応してください」とか。

さらに発表のタイムキーピングが難しいのはバッファを組み込むしかないです。例えば10分の枠+質問5分枠は15分枠として用意するとかです。今回はやりませんでしたが、残り5分ですとアナウンスを促すこともいいでしょうね。そういうこと考えるとちょっと夜やるのは自分の場合は余裕がなくて、土日の昼から夕方にかけてやるのがいいかなと思います。終わったら暇つぶしにサウナでも行くかというくらいの余裕でやるのが良いでしょう。

発表まとめ

当日の発表についてまとめます。見直してたらだいぶ時間かかりました。

SWORD ART COMBINE - アリシゼーション -

TCAがReducderのテストコードを書くためにcombine-schedulersというライブラリを使うんですが、それの解説です。

combine-shcedulerをより理解するため、まずCombineにあるスケジューラの概念を説明し、さらにRxSwiftの仮想時間という概念と比較するっていうね、そういう周りくどいことをやってみるのが前半でした。

後半はその内部実装について、Combineのスケジューラのそもそもの動作からの説明をしてみるという内容になっています。Combineのスケジューラはその動作自体はRxとだいたい一緒なんですが、protocolがありカスタマイズできるようになっています。OSSとしてカスタマイズを公開しているcombine-schedulerもすごいし、OpenCombineもすごい。

参加者の感想として「とんでもなくどでかいSAOのネタバレな気がする...」ということだったんで、SAO未読の方は読まないのがいいと思います。スライドの最初の方は耳と目を塞いでと書いてますからねちゃんと。

redacted を TCA でスマートに扱う

『redacted を TCA でスマートに扱う』@kalupas0930さん

TCAでプレースホルダー表示のため、それ用のStoreを渡すという記事 The Point of Redacted SwiftUIの日本語解説。

これは会の開催2日くらい前にpointfreeで公開されてすぐの記事の解説でめちゃくちゃありがたい。

まずは素のSwiftUI(Vanila SwiftUI)+ViewModelを使った際の課題点を説明し、
その解決案としてTCAではカラの配列やフラグを保持するStateや何もしないActionを持つStoreを渡す方法という解説です。さらにこの利点としてアクションが何もしないので、SwiftUIの色が固定されたdisabledを利用しなくてもいい長所もあるとのことです。

感想としては、TCA利用者はこの方法独自で思い付かないかもしれないレベルですね。TCA利用者はStoreは本番利用の他にテストStoreを作ったりそれをpreview用にしたりすることはあるんですが、それ用のStoreを使ってローディング中を表現するというのは、わかってみれば直感的な方法です。

また、自分でこの方法思いついてもTCAを正しく使えてるか分からないので、こういう直感的なやり方があるというのを知るのは公式ならではかもしれません。しかも、この最新の話は他の参加者も私も、英語記事だからあとで読もうと思ってたんでめちゃくちゃ助かりました。

ReSwift

『今更学ぶReSwift』@cor0suke_kさん

ReSwiftというReduxの影響を受けたフレームワークのおさらい発表。

そもそもReduxは関数型の影響を強く受けているのでFunctional Architectureの仲間と言っても良いでしょう。特にReduxのReducerについてはActionを入力することでイミュータブルなStateを返すタイプの関数ですからね。

そして、発表にあるReSwiftのReducerは、副作用が分離されていてmiddlewareとして利用することになっているという話でした(なのでTCAのReducerが副作用をEffectとして登録しておいて戻り値として購読させるスタイルとは違いがあることがわかりますね)。

他の参加者もReSwiftをあんまり知らなかったという感想もあったのもちょうど良かったです。

pointfree Vol.1 - Vol.3

『Recap Pointfree Vol. 1~3』 @freddiさん

pointfreeのVol.1から3までの解説です。

これTCAのベースになる考えでもあるのですが、基礎ではあるが初歩ではないので結構難しい話なんですよね。

内容として、Vol.1は演算処理を合成すると宣言的に処理をかけて良いという話で、これがこの先続くpointfreeの最も根源のことなので、このVol.1を見てないと次のVol.2も理解するのは難しい。のでここはじっくり理解が必要ですね。

Vol.2は関数の中の副作用を制御する話で、これ最初見ても何のことかわかりづらいんですが、副作用のための手続き自体は関数内で行い、副作用実行自体は関数の呼び出し側で実行ができるのでそれを積み重ねれば制御できるわけです(本文中では副作用のprintする文字列を関数内で用意し、print自体は外でやっている)。このVol.2はTCAの副作用実行とそのまま結びつく考えでしょう。ReSwiftでは副作用をmidddlewareとして切り出してReducerと直接関係がないようにしていましたが、その短所としては副作用とアクションがTCAよりは離れてしまうことでしょう。TCAはReducer内でアクションによってどの副作用が実行されるかを決めることができ、さらにCombineを使っていることで即時に実行は終了する違いが明確になるわけです。

メインになる処理と副作用を合わせて返す、という内容はTCAのReducerになってる訳ですね。TCAのReducerではアクションによってStateを書き換えるというメインの処理の後に、Publisherに準拠したEffect型を呼び出してそれをReducerの戻り値とする訳です。これによってReSwiftでは副作用を分離していて関連が分からなかったのが、TCAではアクションに対し、メイン処理のState変更と副作用がセットにできるという利点が出てくるという訳です。

Vol.3はViewのスタイリングについての記述を、宣言的にしていくという内容。このVol.3が発表された時期は2018年なのでSwiftUIがなかった時代に、UIKitでどのように宣言的にViewのスタイル反映をするかという進歩的な内容だったんだと思います。

他の参加者もこのVol.1から3という初期の話は見てなかったのでかなり興味深かったという感想でした。これpointfreeの初期の話は結構難しいので根気がいるんですよね。これが前の発表のVol.117までくると「redacted を TCA でスマートに扱う」のような話になって応用する話になっていくわけです。

その他感想

参加者の感想はだいたい次のような感じでした。

  • ReSwift話とか各々別々の知見ががあってよかった
  • 表面的な話に終始してなくてよかった
  • テーマが濃くてよかった
  • トラブルもなくてよかった

発表者全員が、「自分の発表が場違いな気がする」と思ってしまったのが印象的でしたが、結果的に全ての話は何かしら関数型のテーマで繋がっているわけで、何かしら話が補完しあえるというのがテーマを絞って面白いところです。

次回に向けて

反省点というかもっとうまくやれる点として、会の開始と終了のメリハリがあるやり方を模索したいと思ってます。やっぱり始まりの緊張感をわくわく感に変換したい。そして会の終了時にはシュッとした終わりのタイミングがほしいわけです。サウナ入る前の体をキレイにするときのわくわく感、そしてサウナを出るときの熱波による今すぐ出たい感じと言えば伝わるでしょう。そういうメリハリが大事です。

次回開催は11/22 14:00からを予定しています。

https://connpass.com/event/194239/

私はTCAでKeyPath MemberLookupがどのように使われていて、他のFunctional Architectureと差別化できているかというテーマで話そうと思ってます。

もし情報共有してみたいことがあれば気軽に参加をお願いします。

コメントを残す

CAPTCHA