try! Swift 2018 レポート的な何か
あらすじ
年に一度、日本で開催される Swift 関係で唯一の国際カンファレンス：try! Swift Tokyo へ今年も行ってきました。1 日目と 2 日目はトーク、そして 3 日目は各種ワークショップやもくもく会など、盛りだくさんの内容で賑わう 3 日間でしたので、今回の参加で気になった内容をまとめようと思い、この記事を書くこととしました。最初は Qiita で書くかこちらで書くか迷いましたけど、みんな Qiita で書くと try! Swift 関連の記事で TL 荒らしになりそうな気がするのでこちらにしました（笑）。
1 日目
裏 Swift Tour
最初の発表。普段何気なく書いてるあのコードも、実は裏ではこんなことをやってるの！？みたいな解説もあって、とても興味深かったセッションでした。トリッキーな動きをするコードはあまり積極的に買うべきものではないですが、その動きを把握することはデバッグすることにおいてとても重要ですので、把握しておいて損はないです。ちなみに個人的に一番興味深かったのは、宣言が Stored Property のように見えても、didSet や willSet 入れただけで、実は裏では set と get を利用する Computed Property になります。Computed Property と Stored Property は、特にマルチアクセスがあるときの動作は結構違いますので気をつけましょう。
レスポンダチェーンを知ろう
※公開スライドなし
iOS の開発しかやってないとあまり意識したことがない Responder Chain ですが、チェーンをカスタマイズすることで途中で好きな処理を挿入できたりして、例えば Delegate を使ってた処理とかも、Responder Chain の途中で好きなオブジェクトを挿入してハンドリングしてもらうこともできるそうです。個人的にはまだあまりその旨味を実感できてませんが、これからはこれを意識して使い道を探してみようと思います。
関心の分離と単純化のためのSwiftコードの最適化
我々はソースコードを書くことよりも、倍以上の時間を費やしてソースコードを読んでます、そのためコードレビューなどではコードの読みやすさはとても重要です。そんな中、コードの中に「What」と「How」を分離することは、コードの読みやすさに大きく貢献しています。例えば UTF16 で文字数を数えるソースコードで、.utf16.count を使うわけですが、このコードだけでは .utf16.count を使っていることはわかっても、なぜ utf16.count を使っているのか、これはプログラム上ではどういう意味を持っているのかはわかりません。そのため、String を拡張して、var countUsingBackendPolicy: Int { return utf16.count } を定義することによって、「これはバックエンドのポリシーによる文字数の数え方だよ」ということが読み取れます。この発表はこのようなユースケースをたくさん紹介して、実務ではどのようにソースコードを改修してきたのかを説明したとても為になるセッションでしたので、スライドも定期的に読み直したいですね。
SwiftyPi
実はこのトークの時間、自分は前の前のセッションの Ask The Speaker のコーナーにいたのでその場で聞くことはできぜ、あとからスライドを眺めることしかできませんでしたが、内容自体はとても気になりました、なぜなら実は自分も去年ラズパイに Swift 入れようとして Ubuntu 入れるところまで行ったけどそれ以上の進捗がなく止まってました。このトークによりますと、どうやら現状 Swift 4.1 はまだ ARMv7 の対応がなく、使うときは Swift 3.1.1 を利用すべきらしいです。また、GPIO を操作するときは GPIO の番号を使う必要があって、それが物理の PIN 番号とは違うので要注意です（そして GPIO 番号はボード上ではバラバラに配置されています）。また、このトークでは Vapor も利用しており、クライアント側／サーバ側／組み込み側が全て Swift で作られているので、Swift 信者としてはとても気持ちいい構成になってますので時間あるときに是非とも深く研究してみたいと思います。
👾
去年からゲーム開発ネタをぶち込んでくる自称ゲーム開発者の iOS エンジニア兼 fastlane コントリビューターの giginet さんの発表です。去年はマリオを Apple Watch に移植したことを発表しましたが、今年はさらにエスカレートし、Xcode を「統合ゲーム開発環境」だと訴えました。まあ確かに Xcode だけで RPG のマップとか作れるけどさー。自分も前職がゲーム会社だったこともあって、リリースまでは持ち込めなかったものの、ゲーム開発用の SpriteKit や SceneKit は確かに色々触ったこともありましたので、3D は専門外ですが 2D なら確かに SpriteKit を使えば結構手軽にいろんなジャンルのゲームが作れます。そして SpriteKit は唯一 Apple Watch に対応しているゲームエンジンだということもアピールし、自作の RxSpriteKit の宣伝もしっかり入れました。凄まじいゲーム愛を伺えます。
AST メタプログラミング
なかなか高度の話題で、少なくとも自分としては今まで全く触ったことのない分野の話でした。構文解析された Abstract Syntanx Tree の中にさらに独自の処理を入れることによって、普通に自力でソースコード書くととてつもなく大変なものがテンプレートを使うのと同じ感覚ですぐ書けちゃうのがとても魅力的で、生産性が上がるだけでなく重複労働が省かれるためヒューマンエラーも減りそうな予感です。この発表では発表者の岸川さんが作った強力なアサートライブラリ SwiftPowerAssert を最後に紹介しましたが、真面目な話、自分が作ってる NotAutoLayout もメタ的な視点で見ると重複してるコードが沢山ありますので、是非とも導研究してみたい気分です。
2 日目
超解像 + CoreML + Swift を使ってアプリの画像データ転送量削減に挑戦する
通信、特に画像や映像が頻繁にサーバとやりとりするアプリでは、通信量の削減は常にホットな話題の一つです。削減法は沢山ありますが、例えば画像の場合、圧縮比の優れたフォーマットを利用する方法もありますが、もっと直接で乱暴な方法として画像の解像度を減らすというのもあります。しかし低解像度の画像をそのまま表示されると見栄えがさすがに悪いので、どうにかローカルで解像度を上げないといけません。そんなとき、我々アニオタならまっ最初に頭に浮かぶのは waifu2x ですが、それはアニメ画像用にチューニングされたものですので、直接漫画に適用すると、漫画のトーンが潰されたり、文字が滲んだりする問題があります。そのため、DeNA ではマンガボックスというサービスのために、ローカルで解像度を上げた画像を手軽に利用するための SRCNNKit を公開し、その解像度を上げるための独自の学習モデルを開発しました。さすが漫画データを用いた学習済みモデルだけあって、漫画トーンもとても綺麗に出てかなり良かった感じです。
Swift 5 の Ownership に備える
Swift 5 では新しい機能として「Ownership」が導入される予定だというのはもうニュースではありませんが、このトークは実際 Ownership 導入されたら今までのコードにどんな影響をもたらすのか、我々エンジニアにとってどんなメリット／デメリットがあるのかについて軽く紹介した内容です。Swift は値型である struct や enum を大幅にパワーアップし、今まで参照型である class にどうしても頼らなくてはいけない多くのものは、値型の struct や enum でも十分カバーできるようにし、暗黙な参照を減らすことでより安全なコーディングを可能にしました。しかしその反面、値型のデメリットであるコピーコストはどうしても避けては通れない道でした。今まででも Copy on Write という仕組みで、値型はコード上コピーされても、実際の動きは修正が入ってから初めてデータがコピーされることによってある程度のパフォーマンスの問題をカバーしてきましたが、それをより高度なチューニングを可能にしたのが Ownership です。moveonly struct による定義や shared 修飾子による引数宣言で、プログラムは今までと同じ安全性を保ちつつも、明示的に参照だけ渡すことを可能にしたことで不要なコピーコストをさらに減らすことが可能になります。またすでに Ownership を導入した Rust では学習コストが高く、Ownership を使いこなす必要がありますが、Swift では Ownership はあくまでチューニング用の機能であり、使わなくても今までと同じコードで開発可能だそうです。
Codableが導く型安全な世界
Xcode 9 がもたらす最も嬉しい機能の一つと言っても過言ではないであろう Codable ですが、多くの人はこれを JSON データとの相互変換にしか使っておらず、それが大変もったいないということを再確認させてくれるトークです。Codable は JSON だけでなく、ありとあらゆるデータのエンコード／デコードは理論上可能であり、その必要があれば自前の XxxEncoder と XxxDecoder さえ作れば 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 が聞きたい！」という声があったためここで発表する運びとなりました。
初めてのターミナルプログラム
当日は仕事の都合によりほとんどのトークが聞けず、なんとかギリギリ自分の発表順番が来る直前に会場にたどり着いたわけですが、そこで発表したのがこちらです。Swift はアップルが主導で開発している言語であり、また Swift を使った開発の多くは iOS 開発でしょう。しかし Swift はあくまで汎用プログラミング言語であり、iOS だけに使うのはもったいないです。せっかく我々は Mac を使って iOS 開発しているので、ついでに Swift で Mac のターミナルで使えるプログラムも開発してみようではないか、という思いで出した CfP でして、また発表自体ライブコーディングを交えつつ簡単なズンドコプログラムをその場で作りました。ターミナルプログラムの開発はとても手軽にできちゃいますので、ぜひともたくさん作ってみてほしいと思います。
まとめ
本記事が完成した時は既に try! Swift の開催から2週間も過ぎたのですが、今年も多くの収穫があり、特に Ask The Speaker コーナーは今年自分初めて利用し、そこでアップル社の中の人ともお話ができてとても嬉しかったです。限られたリソースの中、アップルとしても Swift をより汎用的なステージに送り出そうとしているようですので、Swift 大好きな筆者としてもぜひこれから iOS、ひいてはアップルのエコシステム以外での Swift の活躍をお祈りしたい気分です。
そうだ。浜松、行こう。
これは、今年行ってよかったところ Advent Calendar 2017 3 日目の記事です。
ものすごい遅くなって大変すみませんでした。冬コミの原稿の進捗がかなり思った以上にやばくて、Advent Calendar の執筆が遅れてしまうことになりました。そしてどうせならついでに宣伝します。冬コミ 1 日目、12 月 29 日に、東キ-11b にて、自作 iOS 用フレームワーク「NotAutoLayout」の解説本：「レイアウトを、もっと Swifty に」を出します。表紙入れて全 48 ページで、当日現金価格 1000 円です。また、昨年と同じく一部電子マネーによる支払いも受け付ける予定ですが、対応する電子マネー及び電子マネー用の価格はまた後日発表いたします。
それでは、本編に入ります。
なぜ、浜松へ？
筆者は大学時代は宇都宮で過ごしていました。そういった意味では浜松に対してはある意味ライバル視な気持ちがあります。餃子の街として。
ところが、今年に「ガヴリールドロップアウト」というアニメがありました。とても面白かった。そしてそのアニメの舞台となっているのが浜松でした。聖地巡礼大好きな筆者として行かねばと思いました。
準備
準備と言えるほどの準備なんてしませんでした。いつもなら行く前に一応最低限の下調べして、どのシーンにどこが映ったかとかを把握した上で行ってます。でも今回はあまり時間がなかったので、とりあえず公式聖地巡礼 HP にも載っている「舞天島」こと「弁天島」に行くことだけ決めました。そして運転するのが大好きな筆者として、せっかくだからタイムズレンタカーのマツダロードスターを借りることにしました。初めて乗りましたけど、ロードスターはいいぞ
マツダロードスター
別にステマやってるわけではありませんが、マツダロードスターは本当にいい車ですのでここで少し場所を借りて宣伝してみたいと思います。そして「マツダロードスター」って名前なんか長いのでここからは海外名の「MX-5」を使います
意外と知ってる人少ないようですが、MX-5 は実は全世界で一番売れている 2 シーター 2 ドアオープンカーです。MX-5 がこれだけ売れてる理由は実はとてもシンプルで、馬力こそそんなに高くないものの、非常に高い操作性を持ち備えながら誰でも純粋な運転の楽しさを気軽に感じられ、日常の中でちょっぴりな非日常をリーズナブルな金額で味わえられる車だからです。200 も行かない馬力しかないですが、たった 1 トン程度の重さに、完璧たる 50:50 の前後比重、そしてスポーツカーの王道である FR 駆動方式、ダントツな助手席に彼女を載せたい車 No.1 間違いなし（筆者調べ）です。（なお彼女(ry
そんな MX-5 ですが、MT 車もタイムズレンタカーで取り扱っており、興味ある方はぜひ一度借りてみてはいかがでしょうか？以上宣伝です。
弁天島
弁天島はガヴドロでは主にいわゆる「海回」の第 4 話で登場した舞台です。天使と悪魔たちの楽しい楽しい海でのお話です。混ざりたい。
浜松市
せっかくなので一応市内にも行って来ました。駅の観光案内所にもガヴドロの巡礼マップ配布してると聞いたので(ry
以上、短くて何も伝えなかったが浜松でした。今度チャンスあるときに是非ともまた行きたいです。夏に。できれば彼女と(ry
そして、新しいゲームを。
ブログ開設して早々、2 記事目でいきなり転職記事を書くのも、転職記事書くのにブログ開設した人除けば多分自分が最速なんじゃないですかね。
はい、今回は転職記事です。タイトルではわかりづらいですが。
ちなみにこの記事公開した時にはもうすでに現在いる会社の最終出社日が終わった頃になるはずですが、執筆している今現在は、TVアニメ「NEW GAME!!」最終回最速上映イベント終了直後です。
はい、色々と感無量です。とりあえずイベント直後は、両手が赤くなったくらい沢山拍手しました。キャストの方々が嗚咽しながら頑張って喋ってたの本当にこっちまで泣きそうでした。涙をこらえるの大変でした。
NEW GAME! について
現在の会社を詳しく説明する前に、まず NEW GAME! という作品について触れてみたいと思います。
ご存知の方も多いかと思いますが、最初は「今日も 1 日がんばるぞい！」という 1 コマでなぜか大ブレイクし、原作者の得能正太郎先生もこのブレイクに驚きを隠せなかった芳文社さんが出版した 4 コマほのぼの社畜漫画ですが、そのブレイクを皮切りに TV アニメ化をはじめ、ラジオやゲーム化などのメディア展開がされており、多くのファンの心を掴みました。
そんな素敵な作品に、筆者がゲーム化作品の NEW GAME! -THE CHALLENGE STAGE- にちょっとだけ参加できたのは、本当に今までで指 5 本入るくらい嬉しかったことです（小ネタ挟むとプログラマにとって指 5 本では 32 まで数えられるがここは普通に 5 を指します）。なぜかこの作品は、自分と重ねられてしまう部分が沢山あります。まず自分も大卒とは言え一応新卒で憧れのゲーム会社に入り、原作でリーク情報の回を読んだ時ちょうど会社も同じようなリーク事件が発生してしまい、そしてその直後に東京ゲーム展の話が出てきますが、アニメでこの回を放送した週は自分も青葉ちゃんたちと同じくビジネスデーの企業パスでゲームショウに行き、他にも色々業界ネタで胃が痛くなった挙句、まさかアニメ 2 期が終わる頃に、自分も会社から退職するとか、この 2 年近くを振り返ってみると本当に感慨深いです。
では、このゲームに自分はどういう風に参加したのかというと、まあクレジットはアシスタント P という肩書きで載せていただきましたが、やってたことは主に収録への立会いで「ここはこうして欲しい」とか「ここ誤字あったので後でスクリプト直そう」とかの仕事をします。アニメの 1 期をご覧になられた方でしたら青葉ちゃんの収録の立会いの回を思い出すかもしれませんが、まさにそんな感じです。もちろんそこには自分だけでなく、音監さん以外にも立会いの人が沢山います。ですので自分のやったことは他のスタッフの方々と比べると本当に「ちょっとだけ」です。他にも一応ゲームの制作定例会議には出席しておりましたがまあそんな大したことはしてません。なので本当にクレジットに乗せていただいてとても恐縮でした。それでも「移植」や「多言語展開」ではなく、「原作ゲーム」では初めて自分の名前がクレジットに載ったので、ものすごい嬉しかったです。そして私に「史君好きそうだから参加してみない？」と声をかけてくださった木村 P には本当にしきれないほど感謝しています。おかげさまで本当に入社して一番楽しかった 1 年ちょっとを過ごすことができました。
もちろん、アニメと一緒に成長してきた fourfolium の皆さんの輝かしい姿も、上から目線に見えるかもしれませんが見ててとても嬉しかったです。繰り返しになりますがそんな NEW GAME! の TV アニメ第 2 期と一緒に、八神さんと同じように私も会社から退職してしまうなんて、感慨深すぎてどんな言葉でも今の私の気持ちをうまく表すことができません。
現在の会社について
上記の紹介でもう気づいた方もいると思います（というより筆者を知ってるなら知ってるはずです）が、私が今いる会社は、STEINS;GATE とか、古い作品ですとメモリーズオフとかを作った MAGES. という会社です。ゲームのブランド名 5pb. Games. の方がもしかすると比較的に知名度高いかもしれません。いろんなご縁があって、まさか自分が憧れな会社で働くことができるなんて思ってもみなかったから本当に嬉しかったです。そして入社した後も、たくさんの先輩にご迷惑をかけながらもいろんなお世話になって、自分にとってかけがえのない4年間でした。
ところが気づいた方もいるかもしれませんが、筆者は iOS のネイティブ開発者です。なのになぜコンソールゲームの開発会社にいるかというと、これはまたねねっちと同じような「コネ入社」です。最初はメモリーズオフの iOS 版移植などを作った Mtrix という会社でバイトをしてましたが、ちょうど卒業する頃に色々と事情があってほぼ新卒で MAGES. に入社することになりました。しかも入社当時は筆者はプログラマではなく、iOS 移植のディレクターとして入社したのです。そもそも筆者はその時 iOS 開発経験なかったし、プログラミング経験と言っても中学校で BASIC をちょっとだけ独学したのと、大学で C 言語入門の授業を取ったのと、卒業研究でバリバリ CUDA やっただけです。なので最初は自分の仕事はただ単に「ここはこうして、あそこはああして」などの指示を実際の移植開発会社に伝え、そして出来上がったものを確認すると言った感じの仕事でした。
そして時は 2014 年 6 月に移り、この時に何があったかというと、アップルがその年の WWDC を開き、iOS や macOS 開発のための新しい言語 Swift を発表したのです。そしてちょうどこれと同じくらいのタイミングで、社内の方針転換により、移植プロジェクトを内制でやることになり、自分が iOS 開発者になったのです。
最初の頃は本当に大変でした。社内に他に iOS 開発者もいなかったので、話が聞ける先輩もいなければ、当時 Swift がまだ beta 版だったこともあって何かあったとしてもそれが Swift の問題なのか自分の問題なのかも神のみぞ知るでした。でも「まあとりあえず何か作ってみようよ」という非常に曖昧、言い換えれば自由なオーダーのおかげで、本当に色々と自由に研究することができました。昔の移植開発会社が作った iOS 移植作品のソースコード参照しながら Swift でそれを書き直してみたり、参考書を買ってきて何かしらのアクセサリーアプリを作ってみたり、話が聞ける先輩がいないことも言い換えればなんでも自己裁量でやってしまうことができました。自慢になってしまいますがその 2 年間は凄まじい成長ができた自負があります。iOS 開発の勉強会の常連にもなって、登壇して初心者たちにアドバイスすらできるくらいになったのです。
ですので、言い換えれば、今回転職することができたのも、本当に今まで自由にやらせてもらったおかげで圧倒的成長ができたから他ありません。なので今の会社にも当然とても感謝しております。
感謝といえば先ほど木村 P の話出てきましたが、他にも松原 P にもたくさんお世話になりました。私の「将来プロデューサーになりたい」の一言に、「このコンシューマ化企画もし通ったらとりあえずまずディレクターからやってみない？」と声をかけてくださったのが松原 P でした。残念ながら最終的にその企画自体がボツになってしまいましたが、やりたいことがあればなるべくそれを叶えようとしてくださるプロデューサーさんたちに本当に感謝極まりないです。
ちなみにちょっとずれた話になりますが、先ほどのクレジットの話にも出てきましたが、「移植」や「多言語展開」ならすでに何回か自分の名前をクレジットに載せたことがあります。「移植」は当然ディレクターの経験あったからですし、「多言語展開」は一部作品の中国語版や英語版の翻訳マネージメントも担当したことがあったからです。なので実は今の会社で iOS 開発以外にもいろんな仕事経験があります（一番レアでアレな経験は 1 回だけ音監も担当したことありますがそれはまた今度機会あれば話しましょう）。
ならばなぜ転職するのか
NEW GAME!! 最終回では、八神さんの退職理由は「海外に行ってもっとたくさん勉強したい」だということが明かされました。これは自分の転職理由の一つでもあります。確かに今まで好き勝手にやらせてもらった結果圧倒的成長ができたし、一人でなんでもこなしてきたから並みの iOS 開発者よりは圧倒的広い分野を経験してきたかもしれません。ですが今の環境ではとうとう天井が見えてきました。自分の成長できる限界が見えてきました。八神さんが今まで以上に成長するために海外行くことを選んだのと同じように、私も違う会社に転職して、もっと違ったたくさんの刺激を受けることを選びました。
ただ、転職理由はこれだけに尽きる、というのはあまりにも絵空事すぎです。残念ながら現実は NEW GAME! みたいに、職場に行ったら全員可愛い美少女なわけありませんし、人々が転職する理由も八神さんみたいに前向きな理由だけってわけでもありません。自分も同じく、もちろんさらなる成長をしたいというのも大きいですがそれだけではありません。もう一つ大きな理由があります。ズバリ給料です。
NEW GAME! をご覧の皆さんでしたら大体想像はつくかと思いますが、青葉ちゃんは新卒で給料が低くても実家通いのため家賃の負担がなく、比較的に楽な生活ができますが、すでに何年か経験がありながら部屋借りてるはじめさんはそううまくいかず、欲しいフィギュアを買うのにもたくさん躊躇って最後「仕事にも使うから」と自分に言い聞かせてようやく決意ができるのです。筆者も同じような感じです。ただ違うのは、自分の仕事はゲーム製作に直接な関係が薄く、あくまで iOS ネイティブ開発です。なので結局最終的に会社との需要と供給のミスマッチもあって、会社にとっても私が扱いづらく給料を上げにくいし、私にとっても給料が少ない上やりがいを感じにくいです。
そして転職に振り切った決定的な理由がもう一つあって、それは開発スタイルの違いです。
弊社はあくまでコンソールゲームの開発会社であり、SDK 非公開で、資料やノウハウは基本社内開発陣のみに共有されている非常にクローズドなコンソールゲーム開発と、SDK 公開の上毎年公式非公式たくさんのカンファレンスや勉強会があっちこっちに開かれ、資料やノウハウもネットでたくさん公開されておりとてもオープンなスマホアプリ開発とでは空気が全然違います。先ほど説明した通り私はそもそも iOS 開発者になった時他に話聞ける先輩がいなかったので、勉強会やネットの資料がとても手助けになりました。その代わり、知らずうちに社内の開発チームとはとても空気感の違う開発スタイルになってしまいました。そういった空気感の違いがだんだんストレスにもなり、それがきっかけで「むしろ転職すべきでは」と初めて転職すべき理由を考え始めました。
次の会社はどんな会社か
有休消化もありますので、ちょっと時間空いてしまいますが 11 月からゆめみという会社に正式入社することになります。主な仕事は受託開発の会社ですので、実は面接の時も人事の方に「自社サービスの会社に入りたいので正直に申し上げますと御社は第一志望ではありません」と馬鹿正直な告白をしたのですが、人事の方からの「でも逆に言うと弊社に来ると転職せずにいろんな業界の仕事が体験できるよ！」との言葉がとても刺さっており、それ以外にも勉強し放題などのユニークで面白そうな社内制度がある上、自分が言い出したたくさんのわがままな条件を全部受け入れてくれて一番最初に内定を出してくださいました。執筆時点ではまだ入社手続き等も終わっていないので具体的な感想はまだありませんが、とても面白そうな会社だと思いますし、レベルもとても高い会社（のはず）なのできっとここでならさらなる圧倒的成長ができると思います。そして、次のステージへ向けた、新しい社畜キャリアという名のゲームへの第一歩になることを祈ります。
これから就活／転活する人へ
SHIROBAKO を見てアニメ業界を志望しました、これが声優！を見て声優業界を志望しました、そして NEW GAME! を見てゲーム業界を志望しました、と言った方々がたくさんいると思います。そんな方々に一言だけアドバイスをするのでしたら、「この業界は、人々に夢を見せるのが仕事であり、自分が夢を見てはいけません」。もちろん、夢があるのはいいことですし、この言葉も別に何も「この業界では夢が叶いません」なんて意味ではなく、あくまで「毎日夢ばかり見てそれを行動に移さないというのはダメ」です。むしろ宮森さんや青葉ちゃんたちの輝かしい姿を見て、自分も同等以上の努力をせねばならないと考えなくてはいけません。なにせ、この業界は作品で描かれているように甘くありません。
そして、この業界を志望しなくても、一番憧れの職につきますように。
iOSDC Japan 2017 に参加してきました
ほらね、Wi-Fi のパスワードがね、iwillblog になってたら、書かなきゃダメじゃん？
というわけで、はてブデビューさせていただきました。Auto Layout 絶対殺すマンこと、星野恵瑠（ホシノエル）です。Twitter も Qiita もアカウントは lovee です。GitHub だけアカウントは el-hoshino です。
実はどこでブログ書くかかなり悩みました。何故ならば自分のブログ持っているんです。Crazism です。もう 2 年近く更新してないしそもそもほとんどの記事は中国語で書かれてるけど。だからこそね、今更そこに突然完全に違うジャンルの日本語の記事更新してもなんか微妙だよな。もう一度 WordPress 構築する気もぶっちゃけないし。
となるとじゃあやっぱ既存のブログサービスを使うことになるけど、まあこの界隈の人ってだいたいはてブか Medium のどっちかだよね。はてブの中の人たちには申し訳ないけど、正直 Medium の方がテーマが綺麗に見える。さすが海外サービスといったところだろうか。ぶっちゃけデザインセンスのいい日本生まれのサービス本当少ない。ほとんどない。○天市場とかまさにその代表格。デザインのセンスのかけらもない。でも逆に考えてみた。どうせ日本語ブログだから、まあ○天なんかと比べればはてブのテーマはだいぶセンスを感じる。じゃあはてブでいいや、と。
閑話休題、早速本題に入りましょう。iOSDC Japan 2017 に参加してきました。
発表してきました
Swift 4.0 対応しようとしたら大変な目に遭った話というタイトルの発表です。タイトルだけで見るとなんか Swift 4 の言語仕様とかの話に見えなくもないかもしれませんが、中身はただのエモい話です。そもそも当初 CfP 出した時もきちんと書いておきました。対応しようとしたらすんなりと終わっちゃったから色々と「余計」なものに手を突っ込んでしまった結果大変な目に遭ったというエモい話だと。6 つも CfP 出して、うち 4 つがかなり真面目な技術的な話で、残り 2 つは 1 つが 5 分の LT 枠のエモい話で、残りのもう 1 つがこれ、15 分枠のエモい話。だからぶっちゃけ「これだけは絶対当たるわけないだろｗ」と思ってました。そしたら一体どういう手違いか、この絶対当たるわけがないと思ったテーマが当たりました。
それでも、Track B という比較的に小さい部屋とはいえ、まさかの満員を超えて立ち見まで発生したことにはとても感謝しております。iOS 開発者はみんな優しい。この話に出てきた Pravda というフレームワークは公開するわけにはいかないのがとても辛いですが。
まあ、さすがにエモい話だけで終わってはあまりにもためにならなすぎるので、最後の最後にちょっとだけ「教訓」を入れました。少しでも役に立つことがあったら幸いでございます。
人の発表を聞きました
当然、これだけ大きなカンファレンスだから、ためになる発表はいくらでもあります。人の発表を聞いて、発表者とあとで親睦を深めるのもとても大事です。同時にやってる発表もありますので当然全部の発表を見るのは無理ですが、とりあえず自分が聞いた発表の中で印象に残った、勉強になった発表をピックアップしたいと思います。
節子、それViewControllerやない…、FatViewControllerや…。
前夜祭の発表です。発表者は言わずとしれる（？）我ら AKIBA.swift のマスコットキャラ、ダンボーこと田中賢治さんです。この発表では iOS 開発で陥りがちな罠である「Fat ViewController」問題を、「MVP（Model-View-Presenter）」アーキテクチャの導入で解決を図る手法を紹介しました。UIKit、引いては Cocoa はそもそもの設計上、ViewController と View が密結合になりがちなため、多くの人は一度はハマってしまったことがある罠なんじゃないかと思います。筆者自分は MVP は採用しておりませんが、ViewController の債務整理には一つのヒントになるんじゃないかと思うトークです。それにしても、一昔はダンボーといえばクリーンアーキテクチャだったが、最近はどうやら MVP 推しですね。
AutoLayout Algorithm
1 日目の Track A にて行われた発表です。発表者は「Auto Layout 作ったマン」こと、Abema TV の稲見泰宏さんです。自分は Auto Layout 絶対殺すマンですが、敵を殺すには敵を知る必要がありますので、大変興味深く聞かせていただきました。このトークでは、Auto Layout が実際に方程式を解く際に使われていると思われる Cassowary やシンプレックス法を解説し、そして Auto Layout が自らの可能性にかけた制限を解除した Cassowary という自作フレームワークを最後に紹介しました。もちろんほとんどの人はこれ聞いても「結局我々は雰囲気で Auto Layout してる」ことに変わりはないと思いますが、最低限のイメージを頭に入れておけば使う際には必ずいいことがあると思います。同じ AT 車を運転しても、AT 限しか乗れない人と MT も乗れる人とでは大きな差がある（筆者脳内談）のと同じです。ちなみに筆者の独断と偏見を言いますと、これだけ計算量が多い上不等式とプライオリティまで取り入れて、確かに可能性は無限に広がりそうですがその代価は人類には早すぎたのでやはり筆者はこれからも Auto Layout 絶対殺していきます。
具体例とクイズで学ぶ、Swift4種類のエラーの使い分け
1 日目 Track B にて行われた発表です。内容は簡単に言ってしまえば発表者が以前 Qiita で書いた記事をさらにより実践向きに解説したような発表です。Domain Error、Recoverable Error、Universal Error、そして Logic Failure、この 4 つのエラータイプですが、「どのようなカテゴリーなエラー」ではなく、「どのように処理させたいか」という発想の元で生まれました。最後のクイズはおそらくみんな納得いかない部分もあるかと思いますが、それこそ「俺はこういう風に処理したいからこのタイプのエラーだと思う！」でよろしいかと思います。重要なのは「これはこんなエラー」ではなく、「これはこういう風に処理したいエラー」だと認識することです。
Swiftで数学のススメ 〜 プログラミングと数学を同時に学べ
www.slideshare.net
1 日目の Track B にて行われた発表です。数学は別に得意でもなんでもないですが、発表者の数学への熱意は十二分伝わりましたし聞いててとても面白く感じます。ちなみに筆者の個人的に一番ツボにはまった発言は「√2 のように振る舞うなら、それが √2 だ！」という言葉です。確かに普通計算機のメモリは有限だから、無理数である √2 を直接表現するのは不可能ですが、逆に √2 の定義からして、自分と自分の積がが 2 になるのであれば、それは √2 とみなしてなんの問題もないのです。そんな表現を作ってしまえば良いんです。そしてアップルプラットフォーム開発以外の Swift の活躍の場として、数学の応用も確かに期待できそうに思います。それにしても、1 日目は数学関連のトークが多くあり、さらに英語に関するトークもあったので、開催会場である早稲田大学理工学部キャンパスという要素が相まって本当にまるで 1 日だけ大学生に戻ったような不思議な気分です。
クラス名に個人の名前を含めるとこうなる
1 日目の LT でエモい話です。が、とても面白かったです。何より Eltaso とか Usami とか嫁の名前駆動開発を実践しいつも変な名前の Framework を作ってしまう筆者にとってはとても他人事には聞こえなくて胃が痛いです。いつか Eltaso の Framework の不具合のせいで「Eltaso 問題」と dis られたりしないかとピクピクしてます。そしてそんなことを呟いたら「Danbo 問題起こそう」との優しい声をいただきました。起こしちゃいましょう。
触り心地の良いInteractive Transitionをマスターしよう
2 日目の Track A にて行われた発表です。Pairs というコミュ障でキモオタな筆者としてはおそらく一生使う勇気が湧かないアプリの中の人の発表ですが、気持ちよく動くアニメーションに対する執念はきちんと伝わりました。ちなみに発表者曰く日本発のアプリで気持ちよく動くアニメーションにこだわるアプリ見たことないとのことですが、違います。筆者はきちんと気持ちよく動くアニメーションにこだわっております。まあ筆者は日本人ではないですが。余談すると筆者は ServalCat という画像プレビュー用の Framework も制作しており、発表者がデモにしたアニメーションの動きとは共通する部分も多いです。ただまあ筆者の場合は TransitionDelegate を真面目にやる余裕が当時無かった（納期問題）ため簡単に View の追加のアニメーションだけで対応してましたが。というわけで今度時間あった時に ServalCat をきちんと Transition で対応させたい所存でございます。
AutoLayout と友達になる方法
2 日目の Track A にて行われた発表です。Auto Layout 絶対殺すマンとしては Auto Layout と友達になるつもりなんて端からないのですが、Twitter の反応からしてみるとやはりというか当然というか会場内でも Auto Layout ではまった人が非常に多かったのです。そんな人たちのためにはとても役にたつトークだったとは思います。実際それらのポイントは筆者でもはまったところですので、これから Auto Layout を触らなくてはならない人たちはこのトークを聞いて少なくとも大まかな Auto Layout（正確には Storyboard）の手順がわかったんじゃないかと思います。ちなみに発表者に一言言っておきたいのです：公式表記は AutoLayout ではなく、Auto Layout です。友達になるのでしたら名前を間違えないようにしましょう。
アイコンや画像の配置をCIで自動化する
2 日目の Track D にて行われた発表です。Sketch からのアイコン出力を CI で回せば自動的に iOS や Android のプロジェクトにプルリクを出し、開発者は後でレビューしてマージするだけで仕事が終わるのでヒューマンエラーを最小限に抑えたとても素晴らしいプロセスです。あとは次の会社は Sketch を導入していることを祈るだけです。
地方在住iOSエンジニアの生存戦略
2 日目の LT です。発表者の方は徳島在住で、東京に住んでる開発者たちと違って地方在住の場合はどれだけ不便があるかの話。しかしそんな不便さを全て踏み抜いてこそ一人前の開発者で、そんな気概もなければ地方にいても東京にいても結局何もダメ人間で終わるとのことです。というわけで東京在住の開発者たち、東京という便利すぎる地理条件に甘えすぎず、ちゃんと前向きな気持ちで今日も 1 日がんばるぞい。
人の発表を聞きたかった
同時に複数の発表があるってことは、当然全ての聞きたい発表が聞けるわけではありません。自分の発表とダブってしまったり、別の聞きたい発表とダブってしまったり、そんな様々な要因で気になってたけど結局聞きに行けなかった発表もピックアップしたいと思います。
インタラクティブ画面遷移の実践的解説
1 日目の Track A にて行われた発表です。画面遷移含む UI に関しては筆者はいつも非常に気をつける部分ですので、とても気になってはいたのですが、残念ながらエラーの話とダブってしまい聞けませんでした。
Building High Performance and Testable UI component
1 日目の Track A にて行われた発表です。こちらも同じく UI の話でしかもあの iOS 開発界隈で有名な岸川大先生の話なのでとても気になった発表だったのですが、結局 Track B にずっといたため聞けませんでした。
Xcode Source Editor Extensionの世界
1 日目の Track C にて行われた発表です。発表者は「ほぼ FiNC」「軍曹」で知られる takasek 先生です。Xcode にいろんな便利なプラグインをずっと作りたいと思っていたのでとても聞きたかったのですが、残念ながら自分の発表とダブってしまいまして大変辛かったです。ちなみにちょうど自分の発表の隣の部屋で行われて、そしてどうやら自分が声がちょっとデカかったためそちらの部屋の壁際の人に「うるさい」との苦情をいただきました。大変申し訳ないです。
Server Side Swift実用性評価 2017
2 日目の Track B にて行われた発表です。Swift 信者として、当然何でもかんでも Swift で書きたいですし、何よりサーバサイドができればフルスタックエンジニアになるワンチャンもあるので、前からずっと気になっていたのです。しかし残念ながら当日は Track D で iosdc.fm の公開収録も気になっていたためこちらを断念しました。
詳解Objective-C
2 日目の Track B にて行われた発表です。発表者はスター乞食こと bannzai さんです。今更 Obj-C なんて書きたくはないですが、何せ Obj-C 時代からゲームの移植に携わってきたしそれなりに Obj-C に対する思い入れがあります。というか正直好きか嫌いかと言われたら好きです。今更書きたくはないですが。しかし当日は残念ながら Track D での「iOS 11 Programming プレビュー」を見に行ったためこちらを聞きに行けませんでした。
Human Interface Guidelinesから滲み出る限界感を考える
2 日目の Track C にて行われた発表です。いつも率先して Human Interface Guideline を破っているのはまさにアップル自分自身ですが、まあとにかくタイトルでとても気になりました。残念ながら当日はアイコンを CI で回す話を聞きに行ったためこちらは聞けませんでしたが。
あとがき
iOSDC と関係ない話ですが、ここまで読んでいただいた読者の皆さん、特にリアルで筆者と会ったことのないみなさん、もしかして頭の中で「このブロガーなんか怖い」みたいな感情、抱いてないでしょうか。大丈夫です。筆者はとても人畜無害な人です。基本人前ではニコニコ笑顔です。文章書くときいつも格好つけてるだけです。
ちなみに来年の iOSDC では是非とももう、（Auto Layout）やめても、いいんだよ？というタイトルで発表したく存じます。30 分枠で CfP 出しますから、コアスタッフの皆さん、宜しく御願い致します。もちろんベストスピーカー賞も狙う予定です。
