今年(2018 年)は主に、環境がかわり、忙しみや iOS 以外の内容などをメインにやっていることもあり(というかもともと自分は iOS 専門の人間ではないのでした) CfP を出しませんでした。
なにやら 2018 年も大盛況のようで、500 以上の CfP が出たそうな。応募締め切りも終わり、採択されたセッションも決まったようなので、去年自分が CfP を出すときやスライドや口頭発表の内容を組み立てるときに考えたことを昨年度の知見のひとつとしてメモ書きしておきます。
これからスライドや発表内容を練られる方の反面教師もしくはご参考になれば幸いです。
去年出した CfP
いまや多くの Swift アプリケーションに採用されている RxSwift。
本セッションでは RxSwift を構成する主要素である Observable, オペレータ, スケジューラのうち、Observable にスポットライトをあて、その実装を俯瞰していきます。
実装を知ることは、RxSwift をはじめとした Rx 系ライブラリを活用する手助けになるだけでなく、ソフトウェアを設計する上でのひとつの大きな指針を手にいれることにも繋がるでしょう。
テーマ選びの理由
政治的理由と実用性です。
iOS 開発において、わりと早い時期(2015 年 6 月ごろ)より RxSwift を利用していましたが、黎明期は日本人のユーザーがほとんど見当たらず私が調べた限り、大きな日本の企業で使っていたのはフェンリルさんくらい(たしかフェンリルさんにいらっしゃったエンジニアの方のスライドを見つけた記憶がかすかにある... 違ったらすいません)という状況でした。
ライブラリを自分自身の手でメンテナンスできればきっとそれは一番理想ではあるのですが、私は雇われの身で、ミッションはユーザーによりよいアプリケーション体験を提供することです。
ライブラリの利用者が増えれば増えるほど、バグにヒットする方の数が増え、バグの洗い出しは早くなり、おそらく興味を持った人のなかにはコミットする方も現れるのではないかと思いました。また単純に利用者の多いライブラリは継続的にメンテナンスされる可能性が高いとも考えました。
したがって、一時期 RxSwift に関する発表を積極的に行なっていました。
iOSDC Japan を発表する場として選んだ理由
幸い RxSwift を使う前にソースコードを斜め読みしていて、ライブラリ自体はこのまま行けば多くの人に使われるであろうという確信がありましたし、実際そのとおりになっていきました。
が、 Rx を使ったプログラミングは結構むずかしいみたいな言及や Observable は hogehoge とか fugafuga という例え話が増えてきて、誤解を産みそうだなぁという視点で見ていました。
難しいと感じた人はおそらく、そんなにコード書いてうごかしたりしてないのでは...と思いつつ、じゃあどう説明するかと考えたとき、例えずにコード読んだらよいのではと思い、再びソースコード読んで Observable に関する必要なエッセンスだけ抜き出したら 200 行にも満たない形でライブラリが実装できたので、このソースコードを中心に発表内容を組み立てました。
その内容は 2016 年 4 月にあった RxSwift 勉強会 #1にて 15 minutes recipe of RxSwift というタイトルで発表を行いました。ただ 15 分枠なので、時間が足りなすぎて多分めちゃめちゃスライドすっ飛ばしても 20 分くらいかけて発表した記憶があります。Sansan さん、その節はすみません。
きちんと省略せずにエッセンスをお伝えしたいなと思いつつ、勉強会のセッティングとかだるいなーと思っていたので、iOSDC Japan 2017 のセッションに 30 分枠があるのを見つけて応募しました。でも 30 分でも足りなかった。時間足りないので自己紹介とか 2 秒で終わらせた(自分の発表だいたいこうなる...)。
あとはたくさんの人がいらっしゃるようなので、Observable に関してのコードレベルでの説明をして、難しくないことをわかってもらうにはいい場所ではないかなと思いました(少なくとも Observable を理解するとっかかりを多くの人に直接ご説明できるかと...)
実用性の観点からいくと、やっぱり非同期処理を扱ううえで、Swift 3, Swift 4 までの段階ですと Observable が非常に扱いやすく、個人的にはベストな選択だから多くの人に、難しそうという気持ちを持たずチャレンジして欲しいという思いがありました。
まあでも Swift 5 で async/await が入るというような話があるので、入ったあとでいえば MVVM で View のレイヤのアーキテクチャを構成したいとかいう場合をのぞいて必要性がだいぶ薄れる気もしますが(async/await のほうが個人的には好きではあります)。
スライドを作るときに考えたこと
スライドはこちらです。
あたりまえのことをやっただけですが以下のような感じです。
- フォントファミリー、サイズ、カラーのポリシーを統一する
- 余白を統一する
- ソースコードは座席後方から見てもスッとあたまに入ってくるように必要な部分だけをクローズアップして掲載する
細かいレイアウトを指示したかったので Illustrator で組んでますが結構大変だったので、やっぱり PowerPoint が一番かと...
発表内容を組み立てるときに考えたこと
聞き手を置いてけぼりにしないように心がけました。
もともと自分自身は iOS のエンジニアでもないですし、情報工学の出でもないので、技術的に特に秀でた部分もなく、平凡な人間です。
カンファレンスのセッションは多くの人が参加しますが、おそらく聞き手の方の大半は様々な会社で iOS に携わる仕事をしていたり、個人でアプリを開発している人ではないかなと思います。
そういった方を想定して、できるだけ多くの人に実戦で役に立ち、技術的前提がなくても聞いて理解できるセッションを作るように心がけました。技術的に高度だったりニッチな内容はむしろそういったテーマで少人数で勉強会やったほうが効率よさそうですし、そういう内容組みこもうか迷ったけど最終的には捨てました。たぶん自分の発表は個人的にはジェネラルな内容に寄ったのではないかなと思います。
ソースコード解説中心で、正直途中で目を話すとそれ以降全くついてけなくなる内容だったので、普通のプログラマであればだいたい知っているであろう、あるいは簡単な解説をすれば理解できる Observer パターンを、現実世界での例を交えて丁寧に説明し、その中にもバリエーションとして pull, push 型の Observer パターンがあるよという解説ののち、そこからの発展で、特徴としてこれとこれを追加したのが ReactiveExtensions の Observable だよというストーリーを明確に打ち出し、実装コードがあたまに入ってくるようにかなり気を払いました。
幸い何名かにセッションの感想を聞いた感じ、理解できたという声をかけていただけたのでよかったです。とはいえ、200 行のソースコードでも、口頭で発表するには 30 分では足りないですね。60 分くらいあれば、自己紹介 30 秒くらいできたかも(紹介する自己はとくにないんですが...)。
さいごに
ことしは忙しみなどあり、参加できないけれど来年なにかしら面白いネタを持っていきたい or ネットワークのお勉強してネットワークのスタッフとかやってみたいな(見習いとして)と思っている。参加されるみなさんはぜひエンジョイしてください。
無限ビールはいい文化。
Pinned Articles
About
ウェブ界隈でエンジニアとして労働活動に励んでいる @gomi_ningen 個人のブログです
Tags
JavaScript
PowerShell
kibana
elasticsearch
fluentd
nginx
イベント
五十嵐裕美
村川梨衣
logrotate
IoT
Scala
Java
C言語
iputils
ICMP
WUG
mastodon
Swift
AWS
Clock
Windows
アーキテクチャ
PoEAA
iOS
DeviceFarm
プログラミング言語
OS
StepFunctions
Lambda
Serverless
terraform
ポエム
RHEL
ネットワーク
GraphQL
CloudWatch
Linux
Coreutils
network
nc
telnet
LinuxKernel
fpinscala
ELB
IAM
AppSync
EFS
Gradle
english