try! Swift Tokyoに参加してきました。

僕はしばらく大きなカンファレンスに出ていなかったのですが、アプリも作ってるし、Swiftのイベントがこの時期にあることを知って参加することにしました。

参加してざっくり感じたこと。

• 参加者は結構多い。
• 同時に複数の場所で講演をやることはないので、見たい講演は必ず見れる。
• 同時通訳の精度がすごい。
• 朝ごはんと昼ごはんが出るよ！
• 講演の大半が英語なので、ある程度英語ができるともっと楽しいと思う。（自分はできない）

こんな感じです。
他の言語のカンファレンスと比較して、参加料が高くしかも英語がメインな感じなので、ちょっと敷居は高いのですが、それだけの価値は十分にあると感じました。
特に同時通訳の精度が高く、専門用語も適切に翻訳できてて非常に聞きやすかったです。
…同時通訳レシーバーがあることを最初知らず、最初の2講演を詳しく理解できなかったのが悔やまれるところ。

以下、1日目のまとめ。

---

Swift開発者が知りたかったけど聞きにくい機械学習のすべて

• 機械学習とは、男の場合の平均値、女の場合の平均値、体重がこれぐらいの人の平均値、こういう職業の人の平均値…etc等、属性ごとに平均値を出すみたいなもの。
• 機械学習はUIデザインに似て、ちゃんんと動くか、それが正しいのか証明できないのが難しいところ。
• 機械学習は、TensorFlowのチュートリアルや、ドキュメント、本が揃っている
• python on the server, Swift in the hand

Swift on Android

• C言語はすべてのプラットフォームで動く。なのでC言語にしちゃえばよくない？
• Android NDK (native development kit)というAndroidをC言語で書くSDKがある。
  • AndroidはOSがなかなか統一されないので、Cの標準ライブラリも微妙に違っててやりづらい
  • Hell Problemだぜ！
• Blurrr SDKというのを作った
  • Macアプリとか、Windowsアプリとかも動くぜ!

SwiftのPointy Bits

• Swiftって安全な言語だよね。
• でも安全じゃなく書けるよ。
  • unsafePointerを使おう
• Unsafe Pointerは次の利点がある。
  • C言語のAPIが使える
  • 速度が速い
    • ただし安全性とのトレードオフはあるので注意。

アプリを新次元に導く3D Touch

• Appleは3Dタッチに5年もの開発を費やしたんだからみんな使おうよ！
• 3Dタッチを使う理由
  • ユーザーのショートカット
  • App Storeで3Dタッチ対応アプリのところに出せる
• 3Dタッチでできること
  • ホーム画面のクイックアクション
  • Peek & Pop – 事前にページを開く前にプレビューをする等によく使われている
  • Notification Content Extension
    • 通知画面にアクションを追加できる
• 3Dタッチは古い端末に対応していないので、長押しなどのアクションを代用して、同じ機能を古い端末で対応するようにしたほうが良い

Pixcels、プロセスと情熱

• 主に開発おモチベーションをどう保つかという話
• 講演者は去年あたりから、Blogを始めたり、様々なハッカソンに参加したりして精力的に活動してきたらしい
• （あまり興味がなかったのでちゃんと聞いてない…）

毎日リアクティブ

• シナリオ駆動にすることでステートを減らすというアプローチ
• Swiftでリアクティブをやる方法
  • RXSwift
  • ReactiveSwift
  • etc…
• 既存のどのような処理に適用していくか
  • MVVMモデル
  • async operation
• observerパターンに適用するのがよくある
• トレードオフ
  • デバッグがやりづらい
    • ログイベントを一連のストリームで発火させることでデバッグをやりやすくする
  • フランクにやりすぎるオーバーヘッドが大きくて死にやすい
  • 変更時の影響範囲のわかりにくさ
  • 多用するとカオスになりがち
• 大事なのは、必要な箇所だけを使うということ

Unsafe Swiftの安全性(LT)

• Unsafeで扱いたいことがある
  • C言語で書きたい
  • 速度をあげた
  • Lowレベルにアクセスしたい
• https://www.raywenderlich.comでUnsafe Swiftについて書いた
• ちゃんとした書き方をすれば、Unsafe Swiftでも安全性を担保することはできる、らしい…。

クックパッドアプリのテストを味わう

• UITestにフォーカスした話
• Cookpadアプリ
  • グローバルアプリと日本アプリの2つがある。統合はまだしていない
  • UIコンポーネントは複数大きく変えている
  • だいたい10万行ぐらいある
  • 以前は2週間、最近は1ヶ月毎にアップデートしている
• kano-model という品質モデルがある
  • Attractive – Must-be Qualityの２つのパラメータ
  • Diachronic Quality for mobile
• UITestのやり方
  • テストを書いてからリファクタリングをする
• UITestの実際
  • マニュアルテストは簡単に出来る、ユニットテストはめんどくさい
  • でも理想はその逆
  • Cookpadでは2015年〜2017年にかけてUITestを初めてCrash率を下げ続けた
• UITestの書き方
  • シナリオを書く
  • シナリオをRubyコードに変換
  • Appiumで実行
• Appium
  • XPATHはOSのフレームワークにかなり依存している
  • テストをUIレベルからメソッドレベルに移動することが大事
• image diffを見せるようにした。
• 数ヶ月前にSwiftを実装し始めた
  • テストがあるので安心してSwiftの実装出来る
• テストの自動化は、エンジニアのスキルとはまた違ったスキルセットが必要
• (質問)Appium使ったことあるけどめっちゃ時間かかるんだけどどうしてAppiumなのか？
  • システムアラートを制御することができる
  • 外部の環境をいじれるのでこれを選択している
  • コミット毎にテストを回しているわけではない
• (質問)時間がかかるboundaryのテストの代替テストはどういうものを考えたか
  • よくある文字入力などのバリデーションにかかわるテストは、UIテストではやらず、ユニットテストで担保する

データレイヤを分離する

• MVAモデル(Mininmum Viable Architecture)という考え方
  • 必要最小限のアーキテクチャー
• CoreDataやRealmObjectはスレッドを意識したりしないといけないけど、Viewレイヤーでそれを意識したくはない。
• DTOモデルに変換するというアプローチ
• Plain old swift Object(POSO)で書く
• CoreDataやRealmObjectからDTOモデルに変換する
• デメリット
  • 自分たちでモデルを管理しないといけない
  • 変換処理を書く必要がある
• (質問)DTOに変換するのはオーバーヘッドがあるわけだけど、その線引きをどうするか
  • チームの規模が大きかったら、全員が全員スレッドとかを考えなきゃいけないとめんどくさいので、そういう視点で線引をどうするか考える

UIをSwiftlyに書く

• Resultライブラリを使う
  • API読み込み時に、成功時のパターン、失敗時のパターン、失敗したけどデータを受信したパターン、通信は成功したけどデータが不正のパターン…等色々考えると大変
  • Resultライブラリを使って、成功/失敗に応じて処理を分ければ2つ考えるだけでよい
• AutoLayout
  • storyboard、xibではIDベースでコンポーネントが管理されている
  • プログラマティックにAutoLayoutを実現するのは大変
  • Autolayoutを書くとよくわからない
  • Cartograpyというライブラリを使う
    • Autolayoutをわかりやすいコードに書けるラッパーライブラリ
• ステート管理
  • APIはロード中/成功/失敗3つの主要なステートがある
  • コレをboolで扱う
    • このパターンはisError && isLoadingのステータスの場合がよくわからなくなる
  • enumとswitchステートメントで管理すれば良い
• コード共通化
  • ProtocolとProtocol extensionを利用する

SwiftのWeb APIとアプリをともに構築する

• API設計
  • Paginationの例
    • Get /posts?page=2
      • 各ページでのpostコンポーネントの担保
    • Get /posts?before=2
      • このようにすることで、ID 2のページの前のページの要求をすることができる
  • APIのバージョニング
    • /v1/posts
  • REST
  • APIの問題点
    • クライアントのアップデートが必要
      • Web Linking RFC5988を使うというアプローチ
      • SwiftではWebLinking.swiftというライブラリがある
      • application/hal+json, application/vnd.siren+jsonという方式で書くと、APIのアップデートに耐えうる実装にできる
      • さらにHypermedia APIを使うことで、ビジネスロジックをバックエンドに持ってくるができる
• APIを実装する上で使えるSwiftのウェブフレームワーク
  • 主にfrank, kitura, vaporの3つが有名
  • frankは軽量なフレームワーク
• テスト
  • linuxでXCTestを使える
• デプロイ
  • herokuが楽
  • IBMのブルーミックスというのもある
  • 他にもDockerを使ったり、もちろんマニュアルデプロイでも良い
• ロギング
  • paperteailを使ってプリントしたエラーを取得する等

楽しく便利なSwiftチャットボット

• 去年は色んなチャットボットサービスが出て来た
• まだまだ微妙な感じ
• LINEで言語学習ボットを作ってみた
• グーグル翻訳のAPIを使う
• ボット上で言語登録ができる
• Spaced Reptirionで言葉を覚えたか確認する
• ボットの作り方
  • 制限のあるインタラクション
    • テキストとかスタンプとか画像とか動画とか、全部に対応しようとしない
  • とにかくシンプルにする
  • 他のサービスのapiを活用する
  • 不必要にユーザーを長く拘束しないようにする
• (質問)VRにボットを拡張する可能性はあるのか
  • 今すぐではないが、VRが軌道に乗れば、確実にくると考えている

Realmを使ってコラボレーションアプリを作る

• コラボレーションアプリとは？
  • Google Docs/Slack/JIRA等の複数のユーザーが同時進行で作業をすることができるアプリ
• Realmとは？
  • 大事なのはDBマッパーではない
  • データーベースそのもの
  • schemalessではない
• Realmの利点
  • オブジェクト思考で書ける
  • クラスを実装するように書けるので、新しいことを覚えなくてよい
  • React NariveやXamarinにも対応しているので、クロスプラットフォーム
  • すべての環境で同じデータを使いまわせるので、バックアップがとれる
  • トランザクション管理をしているので、リアルタイムの共同編集ができる
  • サーバー、モバイルの両方でRealmを採用すれば、アプリからjsonを排除することが可能
• Realmの通知機能
  • プロパティの変更、オブジェクトの変更、コレクションの変更、ファイルの変更など、様々な変更に対して通知を行える
  • イベントハンドリング
• アクセス権の管理
  • Admin Realm, Management Realm, Permission Realmなどの特別なRealmを使えば、アクセス権の管理が可能
• (質問)RealmをPHPから操作する等、さらに多言語対応をしていく予定はあるか
  • 今のところPHPの予定はないが、いくつかの言語をサポートする予定はあり、そこになくてもGithubで要望を上げてくれれば検討する

独自のツールを構築する

• ネイティブアプリの問題点
  • ネイティブアプリのテストが長くなってしまう問題
  • ウェブアプリケーションも提供していたが、カスタムUIがたくさんあるとウェブ側の開発のスピードについていけない
• これらの問題は、コードの再利用が出来ていないことによるのではと考えた
• 独自コンポーネントのインフラの構築のアプローチ
  • jsonベースのコンポーネント
  • React in swift – Katana
  • React Native
• すべての実装を、Swiftにするか、Javascript(React Native)にするかすれば、コードが使いまわせるのでは。
  • Swift
    • メリット – 盛り上がっているし非常にエキサイティング
    • デメリット – コンパイルは遅い、独自実装が沢山必要
  • React Native
    • デメリット – 依存性が593もある、まだ若い、アップデートが早い
    • メリット – ただしAPI思考アプリと親和性が高い
• その他のReact Nativeのメリット
  • シンプルなレイアウトシステム
  • テスト界隈は進んでいる（javascriptなので）
  • コミュニティはオープン
• React Nativeでコンポーネント化することで、コードを再利用をはかった。
• (質問)複雑なコンポーネントをReact Nativeだけでできるのか
  • 今のところ自分達のアプリでは、問題になっていない

リアルタイム物体検出アプリでよりよいフィードバックを提供する（LT）

• Wantedlyで行っている名刺の検出の例
• 前提
  • カードの認識はできていて、位置が定まっているという前提
• 複数のオブジェクトがカメラに写っている時に、各フレーム間のオブジェクトラッキングが問題
  • オープンCVの標準のトラッキングを実装したけど、一部の端末で微妙だった
  • なので独自トラッキングメソッド実装した
• その他iOSアプリでは、CoreImageを使ったトラッキングがあるが、あくまで顔認識に特化したもの
  • サンプルコードをGithubにあげた

UXエンジニアという働き方

• エンジニアもUXを考える必要があるということ
• エンジニアにしかできない提案がある
• UXを良くするためにやっていること
  • リテラシーが高くなく、アプリに馴染みがないユーザーをターゲットにした場合
  • 実際にユーザーにプロトタイプをいじってもらって検証した
• デザイン思考の学習
  • デザイナーの思考法であり、これによりイノベーションを起こすような思考法
  • ユーザーへの共感がポイントらしい

---

以上、本日はこんな感じでした。

今日の講演の内容を振り返ると、全体的に

• Swiftの安全性について
• ネイティブアプリのテスト、特にUI Test

についての話が多かったように思います。
特にテストについては、質問でもそれに関連した質問が多かったですし、やはりどこもテストについては苦労しているんだな、と。

また、講演の内容によっては自分もやっているようなことについての話もあったので、これはもっとちゃんとブログを書いて情報発信をしたほうがみんな幸せになれるかもれしないな、と。
本ブログではアプリについてあまり書いてないですが、今後は積極的に書いていこうかと思います。

あ、あと夕方ぐらいにMacのバッテリーが持たなくて、最後はiPhoneで講演をメモっていました。
Macのバッテリーを長持ちさせるにはどうしたら良いんだろうか？

とにもかくにも、とても刺激的な一日でした。
明日もまたtry! Swiftに行ってきます！
ではまた明日。