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

其他筆記: Swift開発者が知りたかったけど聞きにくい機械学習のすべて | try! Swift Tokyo 2017 #tryswiftconf Day1–1 — niwatakoのはてなブログ

在 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 on Android | try! Swift Tokyo 2017 #tryswiftconf Day1–2 — niwatakoのはてなブログ

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 數值的時候,都可以運用這個型態

相關筆記: SwiftのPointy Bits | try! Swift Tokyo 2017 #tryswiftconf Day1–3 — niwatakoのはてなブログ

3D Touch

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

幾乎都是 API 介紹。大概就是提到,3D Touch 可以用在 — App Shortcut — App Extension — Peek and Pop — Custom 3D Touch action — iOS 10 push notification

相關筆記: アプリを新次元に導く3D Touch | try! Swift Tokyo 2017 #tryswiftconf Day1–4 — niwatakoのはてなブログ

Pixcels 的創業經驗

Pixcels、プロセスと情熱 Rikke Møller Koblauch

大概講了 Pixcels 的創業經驗,從一開始沒什麼用戶,到逐漸成長。Rikke Møller Koblauch 認為

  1. 要解決問題,並且愛上要解決的問題
  2. 技術不是最困難的事情,最難的還是對人的理解
  3. 而在製作產品時,也要知道如何善用自己的人際網路。
  4. 離開自己的舒適圈

相關筆記: Pixcels、プロセスと情熱 | try! Swift Tokyo 2017 #tryswiftconf Day1–5 — niwatakoのはてなブログ

每天都會用到的 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,以及避免程式碼的混亂。

相關筆記: 毎日リアクティブ | try! Swift Tokyo 2017 #tryswiftconf Day1–6 — niwatakoのはてなブログ

Unsafe Swift 的安全性

Unsafe Swiftの安全性 Ray Fix

上午就有提到的 Unsafe Pointer。Unsafe Pointer 除了可以修改單一物件的屬性之外,還可以用來修改 Dictionary、Set 等 Collection 型別。

此外,如果某個型態需要 hash value,可以有更安全的實作方式。

更多說明會在接下來的一系列 Advanced Swift 3 教學影片中說明。

相關筆記: Unsafe Swiftの安全性 | try! Swift Tokyo 2017 #tryswiftconf Day1–7 — niwatakoのはてなブログ

Cookpad 怎麼做測試

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

作者是 Cookpad 的測試工程師,也是 appium 的 ruby 版本的維護者。在 Cookpad 主要做 uI 測試。

在測試之前,需要知道測試的目標。Cookpad 有兩個版本,日本版與世界版,日本版是 Cookpad 的主要用戶與收入來源,因此在這邊講的是如何測試日本版。

Cookpad 在日本已經推出五年,是個成熟的產品,因此最重視的是軟體的穩定程度,以及讓軟體維持很低的 crash rate。

大約兩週到一個月左右會推出一個新版本,每個版本大概變動五千到一萬行程式碼。在變動之前,都會先寫測試。

Cookpad 有兩種修改程式的動力,來自內部(公司策略與技術演進)與外部(用戶需求)

  • 來自外部的需求:先確認 UI 測試目前的 app 沒問題,然後進入開發,之後撰寫單元測試
  • 來自內部的需求:先撰寫程式碼,再撰寫單元測試,之後做 UI 測試

盡可能保持單元測試>整合測試>UI 自動化測試>手動測試的金字塔,如果反之,則會嚴重影響開發進度。Cookpad 在過去五年,就逐步調整成現在的金字塔,大幅降低開發時間。

單元測試不見得可以解決所有的問題,但是 UI 自動化測試又太花時間。

不要拿 UI 自動化測試做所有的邊界值檢查,這應該是單元測試要做的事情。UI 測試的速度沒辦法做所有程式邏輯的檢查。

相關筆記:クックパッドアプリのテストを味わう | try! Swift Tokyo 2017 #tryswiftconf Day1–8 — niwatakoのはてなブログ

如何分離資料層

データレイヤを分離する 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 物件之後處理。

好處:簡單,隱藏了實作細節,方便多人共同工作

壞處:需要額外翻譯,因此執行時需要額外的處理時間

相關筆記: データレイヤを分離する | try! Swift Tokyo 2017 #tryswiftconf Day1–9 — niwatakoのはてなブログ

如何寫出 Swift 風格的 UI code?

UIをSwiftyに書く Sommer Panage

薛丁格的狀態

在使用網路 API 抓資料的時候,基本上只有成功與失敗兩種狀態,既然如此,我們可以用 enum 來管理 API 的回傳結果,像是

enum {
case Success <T>
case Error <Swift.Error>
}

如此一來,就可以在撰寫連線的 code 的時候,使用 switch/case 處理連線結果。Result Kit GitHub — antitypical/Result: Swift type modelling the success/failure of arbitrary operations. 就可以解決這個問題。

寫一個小型的 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 一個預設的實作。

相關筆記: UIをSwiftyに書く | try! Swift Tokyo 2017 #tryswiftconf Day1–10 — niwatakoのはてなブログ

Show your support

Clapping shows how much you appreciated zonble’s story.