try swift 2018 tokyo day 2 参加メモ

try swift 2018 tokyo 2日目の参加メモです。

Expression Problem を解決する

発表資料
niwatakoさんのまとめ

• MapViewのようなものを作るときUIViewのサブクラスを作って解決する
• UIViewだとMacOS, Webで使えない
• どうするか
• Expression Problem: 拡張性の問題
• 解決策
• enumで解決できないか？
• EnumKit
• こういうenumを定義

enum View {
  case button
  case textField
}

• renderメソッドを定義

extension View {
  func renderSomething() -> Something {
  }
}

• iOSだとUIViewで実装

extension View {
  func renderSomething() -> UIView {
  }
}

• Viewを追加したいときにどうするか
• ライブラリに追加するのはよくない
• non exhaustive　enumkit はどうか
• デフォルト実装が必要になりよくない
• protocolを検討してみる
• Selfに注目

protocol View {
  static func button() -> Self

• SelfがREALに置き換わる

extension REAL: View {
  static func button() -> REAL
}

• 新しいViewを追加するときはprotocolを追加

protocol WithMapView {
  static func map() -> Self
}

• もっと知りたい方は Final Tagress Style で検索すると関連した話題が見つかる
• もっと詳しく知りたい人向けに４つの資料を紹介（詳しくは発表資料で）

⚡️🎤 Swift もくもく会 in Barcelona

niwatakoさんのまとめ

• 開発者が一箇所に集まって共同作業する場を提供した

Swift によるアルゴリズムの可視化

niwatakoさんのまとめ

• Bezier曲線の話
• アルゴリズムについて理解する必要がある
• Playgroundを使ってSwiftで描いてみる
• ライブコーディング

Kitura で Codable ルーティング

niwatakoさんのまとめ

• JSONのエンコード、デコードについて
• jsでは簡単
• swiftは型安全に処理する必要がある
• Swift4からEncodable, Decodableが提供された
• Encodableに準拠するコードも大変
• Kitura: Build end-toend application in Swift
  • クライアント、サーバを同じ言語で書ける
  • Swiftはメモリのフットプリントが低くサーバサイドの実装に向いている
• Kituraとクライアントの実装について。JSONのEncode/Decodeを中心に

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

niwatakoさんのまとめ

• 超解像: 解像度の低い動画を高くする技術
• SEMethod
• Deep Learingを使ったテクニック
• 低解像度の画像をダウンロードし、クライアントサイドでSR On Core MR
• MLModelを学習して用意した
• Modelをアプリに取り込む。とても軽量
• OpenSourceで公開
  • https://github.com/DeNA/SRCNNKit

iOSでCharlesを導入する

niwatakoさんのまとめ

• プログラミングを学び始めた1985年ごろデバッグは難しかった
• AdobeでFlushの開発をしていた
• ネットワークを多く使う開発だった
• 問題が発生するとネットワークが問題なのかクライアントが問題なのか判断が難しかった
• iOSでCharlesを使うのは少しめんどくさい
  • wifiの設定を変更しなければいけない
• iOS用のCharlesを用意しようと思った
• CharlesはJavaで実装されていた。大変だった
• iPadでも動く
• iOSのCharlesにデータが残る
• デスクトップで確認することができる
• プロキシ設定不要
• コンピュータ不要
• wifi不要（mobile通信でもOK）
  • まだAppleレビュー中

拡張現実における体験設計

niwatakoさんのまとめ

• 現実の種類
  • VR
  • AR
  • Mixed R
  • 素晴らしいAR体験をするためにどうすればいいのか
• デザインプロセスの話
• 頭にあるアイデアは完璧に思えるので紙にかけ
• イテレーションのサイクルを短くする

Swift エンジニアのための Kotlin 入門

niwatakoさんのまとめ

⚡️🎤 Swift5のOwnershipに備える

niwatakoさんのまとめ

• メモリのパフォーマンスの高度な制御が可能になる
• sharedキーワードを使う
• コピー不可能な型の提案もされている
• 先発のRustでも学習コストが取り上げられている
• Rustは理解必須だが、Swiftはオプトイン機能

デジタル信号処理 in Swift

niwatakoさんのまとめ

• DSP
• 信号を操作するテクニック
• デジタル音声はフーリエ変換なしに考えられない
• フーリエ変換とは音を聞いたときの耳の反応
• AVFoundaionはかなり強力
• Swiftで見逃しがちの事に焦点を当てたい

内容が難しく理解できなかった。

15:25 - ⚡️🎤 Codableが導く型安全な世界

niwatakoさんのまとめ

• Codable: Support Encoding, Decoding
• Codableはjson以外にも使える
• protocolと組み合わせるとうまく使える
• userDefaults/keychainにも使える
• Dictionary, URLQueryのCordableを実装してみた

iOS / Swift における対話型インターフェースの作成

niwatakoさんのまとめ

• 対話型インターフェースの音声のインターフェースについて
• おじいちゃん、おばあちゃん。対話型インターフェースなら使える
• 魅力：面倒なことはソフトウェアが行ってくれてユーザの負担が少ない
• 音声認識を行う方法はいくつもある
  • iOS Speech Recognition API（Siri）
  • Amazon Lex
  • other...
• いずれも音声認識はサーバ側で行われ、結果がクライアントに戻ってくる
• iOS Speech Recognition APIの実装の紹介
• Amazon Lexの実装の紹介

UIImageView vs Metal

niwatakoさんのまとめ

• Metalを通してGPUレイアについて
• UIImageViewとMetalのグラフィックスレンダリングパフォーマンスの比較

画像表示とGPU

• 画像表示の基本的な処理の流れ
  • processor -> FrameBuffer -> screen
  • 60フレームならprocessorが1秒に60回書き込む
• processerは2種類
  • CPU：スポーツカーのイメージ。はやいが多くの人は乗せられない。
  • GPU：バスのイメージ。はやくないが多くの人を乗せられる。
• pixelの処理順番が変わってOK。画像処理はGPUに向いている

metalとopenGL

• yourapp -> metal -> GPU
• metalとopenGL
  • openGLはiOS以外の多くのプラットフォームで動く
  • metalはAppleのハードウェアに最適化されている

metalの実装

• metalを使うとコード量が多い
• Metalのwrapperクラスがあれば良いのでは
• MetalImageViewを作った

パフォーマンス比較

• TableViewに画像を表示するサンプル
• metalの方が早い
  • UIImageView: 0.4 0.6
  • metal: 0.02 0.05
• スクロールするとMetalが遅い
• 先程の計測だとGPUの処理が含まれていなかった
• 修正結果
  • UIImageView: 0.4 0.6
  • metal: 40 200
• UIImageViewは既に早い
• WWDC2017のPlatforms states of the unionでUIKitは既にmetalを使っていると発表されていた
• metalを使った自分の実装がなぜそんなの遅かったのか

実装の確認

• Instrumentsでtraceしてみた
• resize->renderingという処理
• この処理の間に時間がかかっていた
• GPUの処理完了をCPUで待っていた
• resize, renderingでCPU,GPU行き来していた
• resizeとrenderingを同じCommandBufferにまとめた
• 短縮できた
• texstureのキャッシュが必要
• GPUではどこでキャッシュするか気をつけなければいけない
• CPU側にキャッシュしてしまうと遅くなる

⚡️🎤 Swiftが動くDockerコンテナの各OSの性能比較

niwatakoさんのまとめ

• Ubuntu 14.x and 16.x
• Swiftのバージョンアップにより安定した環境を用意するのは難しい
• Dockerを使う
• vaporのDocker Imageを用意した
• Ubuntuバージョン間のパフォーマンス比較をしたが、差がほとんどなかった
• imageの容量の差 16.xのほうが小さかった

⚡️🎤 型とパフォーマンスで見るType-erasureの利点

niwatakoさんのまとめ
https://github.com/tarunon/try-erasure

• closuereを使用しないtype erasureの実装の紹介
• 各type erasureのパーフォマンスの比較
• 詳しくはgithubを見る

VisionとCoreGraphicsで顔をでかくする

niwatakoさんのまとめ

• 顔の領域を取得する方法を探した
• Visionでは顔の下半分しかとれない
• Visionの下半分の情報を反対側にも描くことでやってみた
• 点の操作にCoreGraphics
• うまくいった

開発者ツールと経験への時間投資

niwatakoさんのまとめ

いくつか例を見ていく

コンパイルに時間がかかる

フレームワークを分ける

• アーキテクチャが良くなる
• ビルドが早くなる

フレームワークを分けられない場合

• Code Injection
  • https://github.com/johnno1962/injectionforxcode
• playgrounds
  • https://github.com/krzysztofzablocki/Playgrounds

データに対する依存

• アーキテクチャを整備していれば解決できる
• アーキテクチャのレイア間でprotocolを使う
• fileアクセスもサーバリクエストも同じAPIで操作できるFilewatchersを使った
  • https://github.com/krzysztofzablocki/KZFileWatchers
• ファイルの変更が直ぐに反映される

手動データ入力（ログイン画面など）

• 開発時にいちいちデバイスに手入力するのは面倒
• 自動化すべき
• breakpointを設定して設定すると一番簡単
• 多くのステップが多い場合は向かない
• #if でデータを設定するようにする

問い合わせ対応

• ユーザが見た最後のViewModelをシリアライズ化して保存し、バグレポートに含める
• 単方向アーキテクチャを使うとログをすべて記録できて再現できるようになる
• 本当に素晴らしい

ボイラープレートコードを書くこと

• 毎回お決まりのコードを書く必要はない
• ライブラリを作った
  • https://github.com/krzysztofzablocki/Sourcery
• ライブラリが動くなくなったら削除し、コードを書く作業に戻すだけ。導入しやすい・
• テストのFakeオブジェクト作成にも使える

asset

• SwiftGenが使える
  • https://github.com/SwiftGen/SwiftGen