try! Swift 2018 レポート的な何か

あらすじ

年に一度、日本で開催される Swift 関係で唯一の国際カンファレンス:try! Swift Tokyo へ今年も行ってきました。1 日目と 2 日目はトーク、そして 3 日目は各種ワークショップやもくもく会など、盛りだくさんの内容で賑わう 3 日間でしたので、今回の参加で気になった内容をまとめようと思い、この記事を書くこととしました。最初は Qiita で書くかこちらで書くか迷いましたけど、みんな Qiita で書くと try! Swift 関連の記事で TL 荒らしになりそうな気がするのでこちらにしました(笑)。

1 日目

裏 Swift Tour

speakerdeck.com

最初の発表。普段何気なく書いてるあのコードも、実は裏ではこんなことをやってるの!?みたいな解説もあって、とても興味深かったセッションでした。トリッキーな動きをするコードはあまり積極的に買うべきものではないですが、その動きを把握することはデバッグすることにおいてとても重要ですので、把握しておいて損はないです。ちなみに個人的に一番興味深かったのは、宣言が Stored Property のように見えても、didSetwillSet 入れただけで、実は裏では setget を利用する Computed Property になります。Computed Property と Stored Property は、特にマルチアクセスがあるときの動作は結構違いますので気をつけましょう。

レスポンダチェーンを知ろう

※公開スライドなし

iOS の開発しかやってないとあまり意識したことがない Responder Chain ですが、チェーンをカスタマイズすることで途中で好きな処理を挿入できたりして、例えば Delegate を使ってた処理とかも、Responder Chain の途中で好きなオブジェクトを挿入してハンドリングしてもらうこともできるそうです。個人的にはまだあまりその旨味を実感できてませんが、これからはこれを意識して使い道を探してみようと思います。

関心の分離と単純化のためのSwiftコードの最適化

speakerdeck.com

我々はソースコードを書くことよりも、倍以上の時間を費やしてソースコードを読んでます、そのためコードレビューなどではコードの読みやすさはとても重要です。そんな中、コードの中に「What」と「How」を分離することは、コードの読みやすさに大きく貢献しています。例えば UTF16 で文字数を数えるソースコードで、.utf16.count を使うわけですが、このコードだけでは .utf16.count を使っていることはわかっても、なぜ utf16.count を使っているのか、これはプログラム上ではどういう意味を持っているのかはわかりません。そのため、String を拡張して、var countUsingBackendPolicy: Int { return utf16.count } を定義することによって、「これはバックエンドのポリシーによる文字数の数え方だよ」ということが読み取れます。この発表はこのようなユースケースをたくさん紹介して、実務ではどのようにソースコードを改修してきたのかを説明したとても為になるセッションでしたので、スライドも定期的に読み直したいですね。

SwiftyPi

speakerdeck.com

実はこのトークの時間、自分は前の前のセッションの Ask The Speaker のコーナーにいたのでその場で聞くことはできぜ、あとからスライドを眺めることしかできませんでしたが、内容自体はとても気になりました、なぜなら実は自分も去年ラズパイに Swift 入れようとして Ubuntu 入れるところまで行ったけどそれ以上の進捗がなく止まってました。このトークによりますと、どうやら現状 Swift 4.1 はまだ ARMv7 の対応がなく、使うときは Swift 3.1.1 を利用すべきらしいです。また、GPIO を操作するときは GPIO の番号を使う必要があって、それが物理の PIN 番号とは違うので要注意です(そして GPIO 番号はボード上ではバラバラに配置されています)。また、このトークでは Vapor も利用しており、クライアント側/サーバ側/組み込み側が全て Swift で作られているので、Swift 信者としてはとても気持ちいい構成になってますので時間あるときに是非とも深く研究してみたいと思います。

👾

speakerdeck.com

去年からゲーム開発ネタをぶち込んでくる自称ゲーム開発者の iOS エンジニア兼 fastlane コントリビューターの giginet さんの発表です。去年はマリオを Apple Watch に移植したことを発表しましたが、今年はさらにエスカレートし、Xcode を「統合ゲーム開発環境」だと訴えました。まあ確かに Xcode だけで RPG のマップとか作れるけどさー。自分も前職がゲーム会社だったこともあって、リリースまでは持ち込めなかったものの、ゲーム開発用の SpriteKit や SceneKit は確かに色々触ったこともありましたので、3D は専門外ですが 2D なら確かに SpriteKit を使えば結構手軽にいろんなジャンルのゲームが作れます。そして SpriteKit は唯一 Apple Watch に対応しているゲームエンジンだということもアピールし、自作の RxSpriteKit の宣伝もしっかり入れました。凄まじいゲーム愛を伺えます。

AST メタプログラミング

speakerdeck.com

なかなか高度の話題で、少なくとも自分としては今まで全く触ったことのない分野の話でした。構文解析された Abstract Syntanx Tree の中にさらに独自の処理を入れることによって、普通に自力でソースコード書くととてつもなく大変なものがテンプレートを使うのと同じ感覚ですぐ書けちゃうのがとても魅力的で、生産性が上がるだけでなく重複労働が省かれるためヒューマンエラーも減りそうな予感です。この発表では発表者の岸川さんが作った強力なアサートライブラリ SwiftPowerAssert を最後に紹介しましたが、真面目な話、自分が作ってる NotAutoLayout もメタ的な視点で見ると重複してるコードが沢山ありますので、是非とも導研究してみたい気分です。

2 日目

超解像 + CoreML + Swift を使ってアプリの画像データ転送量削減に挑戦する

speakerdeck.com

通信、特に画像や映像が頻繁にサーバとやりとりするアプリでは、通信量の削減は常にホットな話題の一つです。削減法は沢山ありますが、例えば画像の場合、圧縮比の優れたフォーマットを利用する方法もありますが、もっと直接で乱暴な方法として画像の解像度を減らすというのもあります。しかし低解像度の画像をそのまま表示されると見栄えがさすがに悪いので、どうにかローカルで解像度を上げないといけません。そんなとき、我々アニオタならまっ最初に頭に浮かぶのは waifu2x ですが、それはアニメ画像用にチューニングされたものですので、直接漫画に適用すると、漫画のトーンが潰されたり、文字が滲んだりする問題があります。そのため、DeNA ではマンガボックスというサービスのために、ローカルで解像度を上げた画像を手軽に利用するための SRCNNKit を公開し、その解像度を上げるための独自の学習モデルを開発しました。さすが漫画データを用いた学習済みモデルだけあって、漫画トーンもとても綺麗に出てかなり良かった感じです。

Swift 5 の Ownership に備える

speakerdeck.com

Swift 5 では新しい機能として「Ownership」が導入される予定だというのはもうニュースではありませんが、このトークは実際 Ownership 導入されたら今までのコードにどんな影響をもたらすのか、我々エンジニアにとってどんなメリット/デメリットがあるのかについて軽く紹介した内容です。Swift は値型である structenum を大幅にパワーアップし、今まで参照型である class にどうしても頼らなくてはいけない多くのものは、値型の structenum でも十分カバーできるようにし、暗黙な参照を減らすことでより安全なコーディングを可能にしました。しかしその反面、値型のデメリットであるコピーコストはどうしても避けては通れない道でした。今まででも Copy on Write という仕組みで、値型はコード上コピーされても、実際の動きは修正が入ってから初めてデータがコピーされることによってある程度のパフォーマンスの問題をカバーしてきましたが、それをより高度なチューニングを可能にしたのが Ownership です。moveonly struct による定義や shared 修飾子による引数宣言で、プログラムは今までと同じ安全性を保ちつつも、明示的に参照だけ渡すことを可能にしたことで不要なコピーコストをさらに減らすことが可能になります。またすでに Ownership を導入した Rust では学習コストが高く、Ownership を使いこなす必要がありますが、Swift では Ownership はあくまでチューニング用の機能であり、使わなくても今までと同じコードで開発可能だそうです。

Codableが導く型安全な世界

speakerdeck.com

Xcode 9 がもたらす最も嬉しい機能の一つと言っても過言ではないであろう Codable ですが、多くの人はこれを JSON データとの相互変換にしか使っておらず、それが大変もったいないということを再確認させてくれるトークです。CodableJSON だけでなく、ありとあらゆるデータのエンコード/デコードは理論上可能であり、その必要があれば自前の XxxEncoderXxxDecoder さえ作れば OK です。そして、発表者は実際にそういったエンコーダ/デコーダを作った MoreCodable ライブラリーも公開し、JSON 以外でもより手軽に Codable が使えるようになりますので、ぜひ試してほしいライブラリーの一つです。

3 日目

今年の try! Swift Tokyo は 3 日目にハッカソンがなく、代わりに様々なワークショップがあります。そんな中で自分が参加したのはこちらです↓

Swift の値型を極める powered by SWIFT QUEST

参加した、というのは間違いないですが、さらに正確にいうとアシスタントとして参加し、ステップバイステップに手を動かしたわけではなく、むしろ参加者が手を動かすのを手伝う立場でした。

前述 2 日目の Ownership の話にもあった通り、Swift の値型はとても強力で、このワークショップはその値型の振る舞いをマスターするためのものです。そのために使ったのは主催者が作った SWIFT QUEST という誰もが知っている(であろう)あの RPG をモチーフにしたゲームです。このワークショップを通じて、如何に値型の struct だけで、安全なプログラムを構築しながらも手軽なデータ修正を行うという、Mutable Class と Immutable Class 両方のいいとこ取りをするのか体験できます。

After talks 2 日目

公式のプログラムが終わった後には、さらに非公式な関連イベントがいくつか開催されており、この After talks もそのうちの一つです。また、とても光栄なことに、自分も当時 try! Swift に出した CfP が落ちたものの、「この CfP が聞きたい!」という声があったためここで発表する運びとなりました。

初めてのターミナルプログラム

speakerdeck.com

当日は仕事の都合によりほとんどのトークが聞けず、なんとかギリギリ自分の発表順番が来る直前に会場にたどり着いたわけですが、そこで発表したのがこちらです。Swift はアップルが主導で開発している言語であり、また Swift を使った開発の多くは iOS 開発でしょう。しかし Swift はあくまで汎用プログラミング言語であり、iOS だけに使うのはもったいないです。せっかく我々は Mac を使って iOS 開発しているので、ついでに Swift で Mac のターミナルで使えるプログラムも開発してみようではないか、という思いで出した CfP でして、また発表自体ライブコーディングを交えつつ簡単なズンドコプログラムをその場で作りました。ターミナルプログラムの開発はとても手軽にできちゃいますので、ぜひともたくさん作ってみてほしいと思います。

まとめ

本記事が完成した時は既に try! Swift の開催から2週間も過ぎたのですが、今年も多くの収穫があり、特に Ask The Speaker コーナーは今年自分初めて利用し、そこでアップル社の中の人ともお話ができてとても嬉しかったです。限られたリソースの中、アップルとしても Swift をより汎用的なステージに送り出そうとしているようですので、Swift 大好きな筆者としてもぜひこれから iOS、ひいてはアップルのエコシステム以外での Swift の活躍をお祈りしたい気分です。