CodeTengu Weekly 碼天狗週刊

Hello World

如果命運的齒輪沒有出差錯，CodeTengu Weekly 都會在 UTC+8 時區的每個禮拜一 AM 10:00 出刊。每週會由三位 curator 負責當期的內容，每個 curator 有各自擅長的領域，如果你在這一期沒有看到感興趣的東西，可能下一期就有了。當然你也可以瀏覽一下前幾期的內容。

目前的 curator 陣容：

@vinta - I failed the Turing Test - 科幻迷，最近在玩 Detroit: Become Human
@saiday - Imnotyourson - 電量給我這種人用就是一種浪費
@tzangms - Oceanic / 人生海海 - 最近真的都在玩薩爾達
@fukuball - ImFukuball - 有新工作了，但歡迎直接挖角
@mingderwang - Ethereum enthusiast
@kako0507 - 熱愛嘗試新事物的前端工程師
@chiahsien - 》〉》我們要找 iOS 工程師《〈《
@uranusjr - Smaller Things - 聽說 Pinkoi 少了個棒球記者所以現在去應徵前端應該有機會！？Shadowverse: uranusjr
@kkdai - 態度萬歲 - Learning Deeply....
@yhsiang - AMIS / MAICOIN 徵才中，歡迎聯繫！
@johnlinvc - 挑戰自動化家中電器
@drumrick - 歡迎加入台灣 Kaggle 交流區
@wancw
@allanlei
@theJian

你也可以關注我們的 Facebook、Twitter、GitHub 或 Open Source 專案，有很多 weekly 看不到的內容。有任何建議也歡迎來 Gitter 聊聊。

彷彿致力於解決開發者之間的資訊不對稱

@vinta

Write code that's easy to delete, and easy to debug too.

Write code that is easy to delete, not easy to extend. 的最新續篇，同樣非常值得一讀。而且就像作者說的，programming is terrible。

Dimagi's Code Review Policies

在 code review 的時候應該明確地區分出 Merge blocker 和 I personally prefer A over B, but no strong opinion. 這兩種反饋。

在 code review 中發現的問題，如果是會顯著地影響程式碼品質、效能或是可讀性，那的確是需要被修正；但是如果 code review 到後來，雙方一來一往都只是在修改一些無關痛癢的小問題時，reviewer 應該問問自己是不是陷入完美主義的陷阱裡了。在大多數的情況下，其實完全可以先 merge 並部署上線，確認測試完畢之後，再請該作者另外開一個新的 pull request 進行那些優先權沒有那麼高（但是你實在看不順眼）的修改。畢竟曠日費時的 code review 對整個團隊的效率和士氣都不會有什麼正面幫助，尤其當你有同事處在不同的時區或是 remote 工作時。

不過我指的不是 coding style 這種層面的修改，不應該浪費寶貴的 code review 時間在那些程式就可以檢查出來的問題，編輯器 linter 或是 pre-commit-hooks 都是好東西，再不然在 CI 做 auto-format 也行。

其他 curator 也都分享過不少關於 Code Review 的文章，例如：

github.com

Why Scrum is the Wrong Way to Build Software

標題都說得這麼明白了，大家自己感受一下，有什麼想說的話不要憋在心裡。

medium.com

Specify arrayFilters for Array Update Operations in MongoDB

雖然之前一直在嫌棄 MongoDB，但是它的 aggregation 功能其實挺強大的（即便寫起來有點惱人）。除此之外，MongoDB 3.6 才引入的新特性 arrayFilters 也是把 MongoDB 對 array 的更新操作強化了不少，甚至還支援好幾層的 nested array。

mongodb.com

IPFS: The (Very Slow) Distributed Permanent Web

前陣子終於有機會玩了一下 IPFS (InterPlanetary File System)，也順手把使用方式和在過程中遇到的問題都記錄下來了，跟大家分享一下。不過說起來，這個技術在好幾年前就開始發展了，但是最近實際試用了一陣子發現還是非常不成熟啊，至少跟他們當初描繪的那個願景相比有很大一段距離。

vinta.ws

@saiday

How to shuffle songs?

「我覺得你們的隨機不隨機。」

這是 Spotify 在 2014 年對隨機播放的研究跟改進，並分享了他們實作方法。

實際上，簡單精美的 Fisher Yates shuffle 隨機演算法就做到了很好的隨機。所以是用戶、產品經理錯了嗎？這些不懂隨機性的人太愚蠢了，以為自己帶著一顆炸彈上飛機就會減小遇到恐怖份子炸飛機的機率。

執著於隨機這個詞的實作與用戶想要的東西是不同的，畢竟，誰想要一個真正隨機的播放列表呢？他們想要的是歌曲被打亂分配。他們想要用不同的順序來聽音樂。

iPod 推出的時候，也遇過這個問題，Steve Jobs 也表示他們改變了隨機算法，讓它不真正隨機，回應了大家的質疑 (And now for something completely random)。

如果你覺得用戶提出這樣的問題是他們不理解隨機，或許是你不懂胖虎。

spotify.com

Sealed classes opened my mind

Kotlin 的 sealed class 是一個很有趣的設計，完全可以把它當成 Enum，那 Kotlin 的 Enum 又是幹嘛的？這又是 Kotlin 務實的地方，為了跟 Java 的互操作性，Kotlin 的 Enum 可以被當成 Java 的 Enum 用。總之，把 sealed class 當成更強大的 Enum 就對了，他跟 Swift 的 Enum 基本上可以當成一樣的東西。

接受了這種 sealed class 導向的概念之後，可能會對你設計的產生化學反應，比方說將有 state 的物件都用 sealed class 來包裝狀態跟對應行為。

最近有感而發覺得 Swift 跟 Kotlin 有了強大的 Enum 就可以取代部分 Visitor Pattern 的使用機會。指的是在一個有限集合下根據特定類別做不同的事情的情況。

codeascraft.com

Making illegal states unrepresentable

Ole Begemann 在討論用 Swift 設計 API 時透過類型資訊包裝狀態，因為你希望其他人在用你的 API 的時候從 method name, input 跟 output 就可以知道這是什麼，要怎麼用，會回傳給你什麼。

Swift 的類型相較 Objective-C 更靈活也更易用，它可以怎樣幫助我們的 API 設計。

文章中舉了 NSURLSession 的 API 為例，他的 completion handler 會帶 (Data?, URLResponse?, Error?) 參數，沒有狀態的包裝。更甚至，在特定情況下你會同時得到 response 跟 error。這樣的 API 設計可以怎樣變得更好？

oleb.net

Lightweight Generics in Objective-C

Apple 在 WWDC 2015 為 Objective-C 引入了 Lightweight Generics，命名帶了 Lightweight 因為這不是一個語言層面的升級而是透過 LLVM 的支持。

這是同事在 Objective-C 的專案引入 Swift 的時候一起引入的，就是為了 Objective-C 跟 Swift 的互操作性。除此之外，使用 Lightweight Generics 也可以讓 Objective-C 代碼更具可讀性和 compiler 的檢查。

我一直到現在才知道這件事，真的是太遜了。

imnotyourson.com

@kkdai

你了解 SRE 跟 DevOps 的差別嗎? 來聽聽 Google SRE 與 Google DevOps 來討論彼此工作的差異吧

你了解 SRE 跟 DevOps 的差別嗎? 來聽聽 Google SRE 與 Google DevOps 來討論彼此工作的差異吧．

這一集的 GCP Podcast 實在太有趣了．而且相當實用．

DevOps 在這十年間被大家廣泛的討論．讓開發與維運工程師再也不是各自工作．而Google 在 2016 出版的書籍 "Site Reliability Engineering: How Google Runs Production Systems" 之後，全球掀起了 SRE 的熱潮．

但是 SRE 跟 DevOps 之間的差異到底是什麼呢? 這段採訪分別請來了 Google 的 SRE 與 DevOps （是的，不像其他公司 SRE 跟 DevOps 只會澤一存在，他們共存在 Google) 來討論他們的工作內容．並且分享他們主要工作價值．

這裡簡單分享一下擷取出來的主要工作價值，也就能了解 SRE 與 DevOps 的差異:

DevOps: 讓工程師在工作上能夠高興為最高宗旨．
SRE: 讓客戶在使用服務上能夠滿意為最高宗旨．

gcppodcast.com

sindresorhus/awesome: Curated list of awesome lists

最近的 GitHub Trend 前幾名幾乎都是 curated list (俗稱 awesome list)

話說.. 怎麼最近那麼多 awesome 出來?

github.com

An Analysis of vgo

Sam Boyer 身為另外一套「實驗性質的」套件管理程式 dep 主要開發者之一，對於 Russ Cox 提出的 vgo 一直提出令人深思的意見。

本篇文章（導論）將提出 MVS(minimal version selection) 可能有一些場景不適用。並且提出一個結合 gps (dep 使用的演算法）修改而成的方向。

一連有六篇文章，令人期待。

sdboyer.io

Google 開源了 user-kernel sandbox: gVisor 讓你更安全地跑你的 Container

Kubernetes Google Podcast: gVisor, with Nicolas Lacasse and Yoshi Tamura.

Google 在 Kubecon 前開源了 user-space kernel "gVisor" ，主要就是要解決 docker container 下太多的 system kernel call 造成 host 相當程度的危險．於是 Google 做了 gVisor 一個基於 OS 上面的 sandbox 並且全部使用 golang 實作了 2000+ 個 system call (全部 3000+ )．

這篇訪談也討論到，建議以下的人都可以使用:

對於目前自己 Container app 不確定會不會影響到 host 安全
想要將自己 App 從 VM 搬離，但是又怕直接到 container 影響系統安全
想要研究 Kernel code 但是又不想要 K Linux source code XD

很推薦大家聽聽..

kubernetespodcast.com

Uber's Data Platform with Zhenxiao Luo

Uber 來介紹他們的資料處理平臺．主要是要處理大量的 Nested Structure 方面的資料．

我們都以為 Uber 資料應該都是 Geolocation 的資料， Uber 除了自己的服務外．也將服務提供給其他公司與產品 (Uber Eats ... ) 再這樣運用下，除了一般的地圖資料下，還會加上一些額外的 Nested Structure 資料．

此外在此篇採訪中有提到一個很酷的服務 Presto ，一個可以透過 SQL 的方式來查詢 SQL (MySQL, PostgresSQL) 與 NoSQL (Hive, Hadoop, Cassandra ..) 甚至可以透過 join 的指令來合併查詢跨資料庫層級 (ex: MySQL 與 Hive) 的資料．感覺相當好用．

也有提到一個有趣的東西 Apache Parquet 一個基於 HDFS 之上的資料格式．可以很轉換成 ProtoBuf 或是其他資料格式化文字．

蠻值得一聽的．

softwareengineeringdaily.com