Try! Swift Tokyo 2017 第一天筆記 Part 1
Try! Swift Tokyo 2017 第一天筆記 Part 1
Swift 工程師所該知道的機器學習
Swift開発者が知りたかったけど聞きにくい機械學習のすべて Alexis Gallagher
什麼是機器學習（Machine Learning）？
- 一般程式需要由工程師撰寫所需要執行的函式（function），機器學習就是讓機器自己從資料當中，探勘出應該執行怎樣的函式
為什麼最近人們開始熱衷於機器學習？
- 機器學習基本上可以追溯到類神經網路，類神經網路從 1958 年起就開始發展了
- 在智慧型手機流行之後，網路上的資料量大增，因此擴充套件了機器學習可以發展的領域
- 目前類神經網路往往被稱為深度學習（Deep Learning）
在 WWDC 2016 中，就有與 iOS 上進行機器學習相關的 talk 以及 sample code
機器學習對於 Swift 開發者有什麼影響？
- 機器學習對目前的一切領域都有影響，Swift 工程師自然也在其中
- 如果不懂相關數學，也可以透過 Google 的 Tensor Flow Library 建立機器學習的 Model
可以用 Swift 做深度學習相關開發嗎？
- 某方面來說可以
- 像是在 server side 使用 Python/Tensor Flow 建立好資料，在 client 端使用 Swift 呼叫
- 在 App 端也可以想辦法嵌入 Tensor Flow Library
- 移植成 Acceleratie 的程式
- 移植成 MetalPerformanceShader 的程式
- 在使用 AVFoundation/Core Image 做即時機器學習分析的時候，需要注意這些 Framework 會有延遲執行的狀況
做機器學習與設計 UI 很像
- 在開始進行之前，無法評估最終會有怎樣的結果
- 在開始的時候，只能以直覺進行
- 需要一邊實驗、一邊調整
- 如果能夠達到 98% 準確，就是了不起的成就了
可以從哪裡開始著手？
- Google 的 Tensor Flow 介紹
- 史丹福等學校的機器學習教學
- Youtube 上的許多教學影片
結論
- ML 是真的有用，而不是誇大的神話
- 接下來很快就會有更多以 Swift 為基礎的工具
- 現在可以在 server 上用 Python，在 App 端用 Swift
在 Android 上使用 Swift
Swift on Android Eric Wing
作者自我介紹：曾經參與過 SDL、CMake 等專案，做過讓 Cocoa Framework 銜接 Lua 語言的 CocoaLua，也寫過 iOS 遊戲開發的書。
Android 上可以用 NDK 橋接 C/C++，於是也可以讓 Android 用 NDK 呼叫 Swift，而 Swift 語言本身也是用 C++ 寫成的。
理論上，只要把 UIKit、CoreAudio、libDispatch、Fondation，換成其他函式庫，就可以做到跨平臺開發。
但如果要讓 Android 透過 NDK 呼叫 Swift，就可以發現，NDK 本身就有很大的問題
- NDK 呼叫的不是標準的 C/C++ 函式庫，而是 Google 自己的閹割版本的 C/C++ 函式庫，當中連 fopen、fread 等 function 都沒有
- NDK 缺乏與 IDE 的整合，而且很多東西都壞掉沒人修
- NDK 可以呼叫太多種 C/C++ 函式庫（glib、std…），缺乏統一
- NDK 一樣會有 DLL Hell 的問題
Eric Wing 使用 CMake 解決了編譯系統的問題
GUI 方面，目前已經可以成功接上
BlurrSDK http://blurrrsdk.com/ 是一套以 SDL 為基礎的遊戲引擎，透過 BlurrSDK，現在已經可以使用 Swift 語言進行 2D 遊戲開發，在 SteamOS/Linux, OS X, Windows, iOS, Android, Raspberry Pi 2 上執行。
Swift 的 UnsafePointer 型態
SwiftのPointy Bits Nate Cook
Swift 是一個安全的語言
- Swift 的安全來自於沒有什麼位定義的行為（Undefined Behaviors），但如果遇到隨意對可能是 nil 的物件做 force unwrap，還是一樣會 crash
Swift 在處理指標的時候，會使用自己的一套比較安全的型別系統包裝指標
Swift 中有以下幾種指標型態
- UnsafePointer
- UnsafeMutablePointer
- UnsafeRawPointer
- UnsafeMutableRawPointer
- 這幾種型態是根據是否可修改，以及是否有特定型態區分
在混用 Swift/C 的時候，可以在呼叫 withUnsafePointer(to:pointer) 之後，透過 UnsafePointer 物件的 pointed 屬性，修改指標所指向的值
像是在撰寫排序演演算法/swap 數值的時候，都可以運用這個型態
3D Touch
アプリを新次元に導く3D Touch Meghan Kane
幾乎都是 API 介紹。大概就是提到，3D Touch 可以用在 — App Shortcut — App Extension — Peek and Pop — Custom 3D Touch action — iOS 10 push notification
Pixcels 的創業經驗
Pixcels、プロセスと情熱 Rikke Møller Koblauch
大概講了 Pixcels 的創業經驗，從一開始沒什麼使用者，到逐漸成長。Rikke Møller Koblauch 認為
- 要解決問題，並且愛上要解決的問題
- 技術不是最困難的事情，最難的還是對人的理解
- 而在製作產品時，也要知道如何善用自己的人際網路。
- 離開自己的舒適圈
每天都會用到的 Reactive 技巧
毎日リアクティブ Agnes Vasarhelyi
Reactive Programming 所要處理的問題是：如何在多個不同的資料來源進行非同步操作時，管理好程式的狀態，所以會：
- 減少狀態
- 行數較少，但是簡潔的程式碼
- 容易閱讀
目前有 ReactiveKit、ReactiveCocoa、ReactiveSwift、PromiseKit、Vince RP、Interstellar 等 Reactive Framework 可以選擇
- 在程式變得複雜的時候，就可以考慮使用 Reactive Programming
- 像是 MVVM 架構、有多個 async 操作的狀況…
Reactive Programming 基本上就是一種 Observer Pattern 的實作，可以減少狀態，處理資料的轉換與合併（transform and combine），同時簡化、統一各種 async 操作
- 但是代價是，在 debug 的時候，看到的不是傳統的 callstack，可能會增加 debug 的難度。
- 不要只把 Reactive Programming 當做比較 Fancy 的 KVO 來用，還是要注意要把抽象層抽離出來。才能有效避免 side effect，以及避免程式碼的混亂。
Unsafe Swift 的安全性
Unsafe Swiftの安全性 Ray Fix
上午就有提到的 Unsafe Pointer。Unsafe Pointer 除了可以修改單一物件的屬性之外，還可以用來修改 Dictionary、Set 等 Collection 型別。
此外，如果某個型態需要 hash value，可以有更安全的實作方式。
更多說明會在接下來的一系列 Advanced Swift 3 教學影片中說明。
Cookpad 怎麼做測試
クックパッドアプリのテストを味わう Kazuaki Matsuo
作者是 Cookpad 的測試工程師，也是 appium 的 ruby 版本的維護者。在 Cookpad 主要做 uI 測試。
在測試之前，需要知道測試的目標。Cookpad 有兩個版本，日本版與世界版，日本版是 Cookpad 的主要使用者與收入來源，因此在這邊講的是如何測試日本版。
Cookpad 在日本已經推出五年，是個成熟的產品，因此最重視的是軟體的穩定程度，以及讓軟體維持很低的 crash rate。
大約兩週到一個月左右會推出一個新版本，每個版本大概變動五千到一萬行程式碼。在變動之前，都會先寫測試。
Cookpad 有兩種修改程式的動力，來自內部（公司策略與技術演進）與外部（使用者需求）
- 來自外部的需求：先確認 UI 測試目前的 app 沒問題，然後進入開發，之後撰寫單元測試
- 來自內部的需求：先撰寫程式碼，再撰寫單元測試，之後做 UI 測試
盡可能保持單元測試>整合測試>UI 自動化測試>手動測試的金字塔，如果反之，則會嚴重影響開發進度。Cookpad 在過去五年，就逐步調整成現在的金字塔，大幅降低開發時間。
單元測試不見得可以解決所有的問題，但是 UI 自動化測試又太花時間。
不要拿 UI 自動化測試做所有的邊界值檢查，這應該是單元測試要做的事情。UI 測試的速度沒辦法做所有程式邏輯的檢查。
如何分離資料層
データレイヤを分離する Jon Bott
最近很多人在講 MVC 以外的程式架構，如 MVVM、VIPER，但是他追求的是 MVA — 最小可行架構（Most Viable Archtecture）
基本上就是把資料層從程式中抽離出來，把各種資料，變成獨立的物件
以前這種物件叫做 DTO（Data Transfer Objects），現在他覺得可以叫做 POSOS（Plain Old Swift Objects）。基本上就是隻有 property，沒有 method 的物件。
程式不應該直接操作 CoreData、Realm、JSON…而是先將各種資料轉換成這種 DTO/POSOS 物件之後處理。
好處：簡單，隱藏了實作細節，方便多人共同工作
壞處：需要額外翻譯，因此執行時需要額外的處理時間
如何寫出 Swift 風格的 UI code？
UIをSwiftyに書く Sommer Panage
薛丁格的狀態
在使用網路 API 抓資料的時候，基本上只有成功與失敗兩種狀態，既然如此，我們可以用 enum 來管理 API 的回傳結果，像是
enum { case Success <T> case Error <Swift.Error>}寫一個小型的 Layout 引擎
傳統透過 override layout subview 難以管理，而使用 Storyboard/XIB，則有：XML 難以 diff、git merge 會爛掉、而且把型態字串化等缺點，因此，不如使用一個小型而且簡單的 Layout 引擎，用 code 撰寫 auto layout 的配置。Cartography 就是個很好的選擇 GitHub — robb/Cartography: A declarative Auto Layout DSL for Swift
View 有多種狀態
一個畫面可能會有載入中/載入成功/載入失敗三種狀態，很多人都用兩個 flag（isLoading、isError）管理這種狀況，但是這個時候應該寫成 enum，像是
enum State { case Loading case Loaded case Error}然後在 property 中，就可以用 switch/case 管理這些狀態對應的 UI code
var state: State { didSet { switch(self.state) { case .Loaing:… case .Loaded:… case .Error:…. } }}如何避免重複的程式碼？
很多 View Controller 都會呼叫 API，而且都有載入中/載入成功/失敗的狀態，因此可能最後出現大量重複的程式碼。我們可以把這些行為設計成 protocol，然後寫一個 extension，給這個 protocol 一個預設的實作。