Hello World
CodeTengu Weekly 碼天狗週刊
CodeTengu Weekly 會在 GMT+8 時區的每個禮拜一 AM 10:00 出刊，每期會由三位不同的 curator 負責當期的內容，每個 curator 有各自擅長的領域，如果你在這一期沒有看到自已感興趣的東西，可能下一期就有了。你也可以瀏覽一下前幾期的內容。
目前的 curator 陣容：
- @vinta - I failed the Turing Test - 科幻迷，最近在讀 Ready Player One
- @saiday - Imnotyourson - 徵 Android Developer！救我！
- @tzangms - Oceanic / 人生海海 - 衝動型購物
- @fukuball - ImFukuball - 有新工作了，但歡迎直接挖角
- @mingderwang - Ethereum enthusiast
- @kako0507 - 熱愛嘗試新事物的前端工程師
- @chiahsien - 徵有經驗的 Objective-C 工程師，快來 Twitter 私訊我
- @hiroshiyui - 歧路亡羊與中年危機的典範
- @uranusjr - Smaller Things - 我要成為錯字王
- @kkdai - 態度萬歲 - 公司誠徵前端，有想做 5G 與 AI 相關方面的前端歡迎聯絡我
- @yhsiang
- @johnlinvc - 挑戰自動化家中電器
- @drumrick - 歡迎加入台灣 Kaggle 交流區
- @wancw - 請推薦工作機會
你也可以關注我們的 Facebook、Twitter、GitHub 或 Open Source 專案，有很多 weekly 看不到的內容。有任何建議也歡迎來 Gitter 聊聊。
@chiahsien
Why many developers still prefer Objective-C to Swift
如今 Swift 版本已經演進到 4 了，但還是有不少工程師鍾情於 Objective-C，這是為什麼呢？本文作者採訪了多位工程師，詢問他們許多問題，諸如「為何還死守著 Objective-C、看到研討會上都是 Swift 的主題會不會感到不舒服、在社交平台上會不會羞於承認自己還在用 Objective-C」等等，滿有趣的一篇採訪。
當然，作者接下來又寫了一篇 Why many developers prefer Swift to Objective-C。
A Case For Using Storyboards on iOS
我只有在寫自己的 side project 或 prototype 時，才會用 Storyboard 去設計介面，工作的專案裡頭還是完全用程式碼寫出介面。
我其實有跟一些同事聊過這個話題，Storyboard 並非一無是處，只是我覺得很多人沒有正確地使用它。剛好最近看到這篇文章，作者對 Storyboard 的想法與使用方式跟我不謀而合：
- 一個 Storyboard 裡頭只有一個 UIViewController
- Storyboard 用來設定 constraints，其他畫面的設定都寫在程式碼裡面
- 不要用 Xib 設計 UIViewController
作者也提供了一個把 UIViewController 跟對應的 Storyboard 設為同名的小技巧，可以讓開發變得更方便。
Closures: Swifty closures for UIKit and Foundation
這個東西把大部分的 UIKit 跟 Foundation 元件都加上 Closure 語法，讓開發者寫起來更加方便一點。這讓我想到在 Objective-C 時代很流行的 BlocksKit。
iOS Device ID 的前世今生
IMEI、UUID、UDID.... 有沒有被這些名詞搞混過？有沒有想過該如何唯一識別使用者的裝置？從以前到現在出現又消失過多少種方法？這一篇文章應該可以解答你的困惑。
同場加映：
- iOS 11: The DeviceCheck API: It’s an Apple approved, and guaranteed way, to identify your app as running on a valid Apple device while maintaining absolute user privacy.
inessential: On Fixing that NSNull Crasher in Overcast
Overcast 是我很愛用的一款 podcast app，它的開發者 Marco Arment 最近在 Twitter 上邀請別人幫他想想該怎麼解決一個存在已久的 crash。本文作者剛好看到了這則求救，並提供了一個可能的解法，而且還真的解決了問題。無論是問題還是解法都很有趣，值得一看！
同場加映：
PSPDFKit 的開發者 Peter Steinberger 最近也在 Twitter 上詢問一個 UIToolbar 在 iOS 11 產生的 bug，最後的解法也是很奇葩。
@drumrick
遲來的 Google Teachable Machine 簡介
雖然 Teachable Machine 發布已經兩週了，但是一直還沒去瞭解，藉著颱風天稍微看了一下相關資料，撰文簡單介紹一下，到底需要怎樣的技術支援，才能讓 Teachable Machine 這樣的應用誕生？
Kaggle 教學網誌：語意分析 in R
文中使用 Tidytex 套件，分析 1989 到 2017 年間，美國的國情咨文內容。程式碼完整，簡單的視覺化呈現結果，文末附上幾個簡單的練習，最後並條列了幾個 Kaggle 上的語料庫，以及其他可供使用字典。
如果轉換到 Python 的部分，現在多數人使用的應該是 textblob，這個套件結合了 NLTK 以及 Google Cloud NLP 的 API，在此之上做了一層的封裝，很容易使用。
這些都是英文的部分，中文的話 Google Cloud NLP API 是有提供中文語意的判斷，但應該是要按次數比例收費的。公開的模型通常是以簡體中文為訓練資料，而且幾乎都是使用爬蟲爬某些網站的評分內容，例如電影評論網站、或是購物網站，導致並不是很適合普通情況的使用。
量子位
這是一個微信公眾號的名字，專門報導與 AI 相關的新聞。因為我習慣看文章追源頭，最近看到這邊出來幾篇不錯的文，但是沒有微信無法追蹤，令我相當苦惱，只好迂迴一下，看看量子位的文章會被轉發到哪些地方，總共找到兩個替代方案。
優點
- 文章齊全數量多
- 有點擊數量顯示，可以自行挑選熱門文章
缺點
- 版面比較雜，有廣告
優點
- 有讚數，可以自行挑選熱門文章
- 有標籤分類，可以選擇有興趣的標籤內容
- 有評論區可以討論
- 排版比較舒適，沒有廣告
缺點
- 文章數比較少不齊全
在 Medium 上找到有興趣的人來追蹤
我自己剛開始用 Medium 的時候，也感覺不知道要追蹤誰。最近也有幾位朋友剛開始用 Medium 有這樣的問題。所以看到這篇感覺挺有趣的，可以用類似方法不同定義去找到自己可能有興趣的使用者。
作者自己寫 Python 抓 Medium 上面的資訊，尋找自己可能感興趣的使用者來追蹤。程式碼很簡短，有在 Github 上面，一開始作者本來要用 Medium 自己的 API，不過因為功能有限，所以後來還是用爬蟲的方式來做。
我自己是感覺 Medium 官方比較是用內容為主的推薦方式在推薦文章，所以用作者這種 CF 方式來找相同興趣的使用者，也是一種相輔相成的做法。不過我感覺台灣用戶留言的比例還是比較低的，可能要退一步改成：追蹤我的使用者還追蹤了哪些使用者？或者是：對我的文章鼓掌的使用者還對哪些文章鼓掌？可能會有比較多的結果。
Google 及 Uber 內部，深度學習的最佳實踐 (in production)
Google 以及 Uber 都有在這方面發表論文，本文簡略地從幾個角度去看 Google 以及 Uber 流程的設計，到底解決了哪些問題。在這邊我簡單的筆記，但是內容滿好的，建議閱讀原文，有能力的話閱讀論文。
Uber
- 專案名稱：米開朗基羅
- 數據平台，加上機器學習功能
- 有一個叫做 Feature Store 的東西，各個團隊把自己要用的 feature 都加到 裡面，這樣團隊之間可以共享、重複使用各個 feature，而 feature 是每天自動計算並更新的。
- 內部的 DSL 做 feature engineering
- TFX 論文，內有影片。
- 自動對每個資料集做 data analysis
- feature engineering 雖然沒提到名稱，但應該就是用 dataprep
- 有一個資料檢查的機制，可以提早偵測到資料錯誤的情況，而暫停之後的動作。
- 剩下的基本就是 TensorFlow Serving。
@wancw
(Git) Rerere Your Boat...
前兩天在推特上看到一篇 每個開發者都該知道的 Git 基礎指令 。果然很基礎，連 diff 跟 rebase 都沒提到。
（題外話，各位覺得教入門者 reset 跟 rebase 哪個危險呢？ :p）
不過倒是讓我想起了一個我從沒用過的 Git 指令：rerere，不知道各位讀者有沒有人用過這個指令？歡迎到碼天狗的 [Gitter 聊天室] 分享一下經驗，也歡迎各位來交流一下少見但是好用的 Git 指令。 :D
P.S. 懶得看英文的話，Ruby China 上也有一篇分享： 你可能不知道的 git rerere。
说说 Code Review
自己绕过一个坑不难，难的是看到别人那么走，远远地你就能告诉他/她那里有个坑
Code Review 的文章不少，這篇也歸納了幾個面向：排版、可讀性、極端情況、錯誤處理、測試、架構。但我覺得文章裡提到的心態更重要：
代码审核是工作，不要抱有情绪化
在不违背公司 style guideline 的情况下，没必要一定让对方和你有一样的习惯。
相互 review 的过程中还能从彼此那里学到很多编程的小技巧和好习惯
Code Review 是互相學習，不是找碴、挑毛病。
IOCCC vs Clean Code
這篇舊文沒什麼新技術。只是作者嘗試整理一份 IOCCC (The International Obfuscated C Code Contest) 上的程式碼，讓它更可讀、好懂的過程。包括：調整排版、提取函式、取有意義的名稱、……，可以在 GitHub 上找到完整過程。
算是個很有趣的實驗過程，可以從簡單的例子中學習如何整理出好讀的程式碼（clean code）。學新技術學到頭昏演化的話，可以來看一下轉換心情。 XD
工作機會
EscapeX 強力徵求 Java 後端 / iOS / App QA 工程師
EscapeX 和超過 70 位全球頂尖的好萊塢、寶萊塢藝人合作（拉丁歌王馬克安東尼、復仇者聯盟「鷹眼」傑瑞米瑞納等），建立專屬藝人與粉絲間的私密互動俱樂部，目前在世界各地有八個辦公室。我們正在積極擴充團隊，尋找對 Java 後端 / iOS / App QA 充滿熱情的夥伴，快把履歷寄到這裏吧！