Hello World
CodeTengu Weekly 碼天狗週刊
如果命運的齒輪沒有出差錯，CodeTengu Weekly 都會在 UTC+8 時區的每個禮拜一 AM 10:00 出刊。每週會由三位 curator 負責當期的內容，每個 curator 有各自擅長的領域，如果你在這一期沒有看到感興趣的東西，可能下一期就有了。當然你也可以瀏覽一下前幾期的內容。
目前的 curator 陣容：
- @vinta - I failed the Turing Test - 科幻迷，最近在讀 Dirk Gently 系列
- @saiday - Imnotyourson - 電量給我這種人用就是一種浪費
- @tzangms - Oceanic / 人生海海 - 最近真的都在玩薩爾達
- @fukuball - ImFukuball - 有新工作了，但歡迎直接挖角
- @mingderwang - Ethereum enthusiast
- @kako0507 - 熱愛嘗試新事物的前端工程師
- @chiahsien - 我們又要找 iOS 工程師啦！
- @uranusjr - Smaller Things - 我要成為錯字王
- @kkdai - 態度萬歲 - Learning Deeply....
- @yhsiang
- @johnlinvc - 挑戰自動化家中電器
- @drumrick - 歡迎加入台灣 Kaggle 交流區
- @wancw
- @allanlei
你也可以關注我們的 Facebook、Twitter、GitHub 或 Open Source 專案，有很多 weekly 看不到的內容。有任何建議也歡迎來 Gitter 聊聊。
偶爾致力於解決開發者之間的資訊不對稱
@saiday
APIs as infrastructure: future-proofing Stripe with versioning
Stripe 分享設計 REST API 版本的經驗跟方法。
其中最有趣的部分是 Stripe 不再主要地採用 URL 夾帶 API 版本 (v1/endpoint) 而是採用日期 (2018-04-01) 的 API 版本化方式。其原因是大版本 API 升級是痛苦的，對 API developer 跟 client developer 來說都是。
他們透過一套自己的 DSL 來描述每一個 endpoint、撰寫 version change (包含與上一版的相容轉換方法)、紀錄 version changes list。
當一個舊版的 API request 進來會從最新版的實作開始，透過 version changes list 一步一步退版本直到符合這個 request 的 API 版本。
這樣的方法就像是 DB 的 migration，只是他是倒過來的、針對的是你的 API endpoint。
有兩個很明顯的好處，不用管舊版的實作可以快速滾動升級，跟做完之後就有免費的 changelog。
Who will steal Android from Google?
Steve Yegge 換工作了，對前公司正常能量釋放中。開頭就來了這句：
Android’s dev stack is the world’s biggest poo sandwich.
當然，他在 Google 並不是開發 Android 的，但他對 Android 生態的觀察還是滿犀利的。特別是 Flutter 的部分：
“Oh yeah? Well you can’t compete with us, because we’re going to compete with us!” and they launched Flutter, which is a 100% serious Android development stack that competes with native Android.
結論是想要在他的新公司嘗試用 Reactive Native，畢竟這種大公司大 app 總是為了 build time 所苦。然後他也鼓勵有後端經驗的開發者學習 mobile 開發，因為現在這種全端人才實在太少了，奇貨可居。
Steve Yegge 的文筆還是那麼流暢，如果懷念他的憤怒可以看這篇的上一篇 Why I left Google to join Grab。
Nullability annotations 之亂！
最近用 Kotlin 調用 Android SDK，明明看到它的 .java 有 @Nullable 的標註，但 Kotlin 的類型推導卻給了我 Platform Type，檢查發現在 bytecode @Nullable 就被抽掉了。原因是 Android SDK 用的是 android.annotation.Nullable，這個 annotation 並不是公開的 API (AOSP Nullable)
那問題就來了，如果我要重新做人在 Java code 裡標註 nullability，我應該用哪套 package 的 @Nullable？JetBrains 的 org.jetbrains.annotations.Nullable 、 JDK 的 javax.annotation.Nullable 還是 Android 的 android.support.annotation.Nullable？
先講結論，寫 Android 用 android.support.annotation.Nullable 因為 Android Studio 的 Lint 只認這個。不是寫 Android 的話就看你的 nullness analysis 工具用哪一套。
Kotlin 開發過程也苦惱過同樣的問題，Kotlin 的 null-safety types 跟對 Java 的兼容性就是魚與熊掌。務實如 Kotlin 這個語言嘗試了很多做法，最後妥協在什麼 package 的 nullness annotation 都參考，如果沒有標註，就 infer Platform Type 給你，你自己管吧。 (More Null-safety for Java 是他們不斷嘗試解決的過程)
是說，為什麼會有這麼多套的 nullness annotations？
啊，沒有錯啦，因為大家都不相容嘛哈哈哈哈
Python，你到底是在__底線__什麼啦！
Python 在變數上有許多 underscore (_) 的語法跟命名習慣，這篇解釋了這四種形式：
foo__foo__foo____foo
對我這個剛學習的人有很大幫助。
@chiahsien
Technical Note TN2387: In-App Purchase Best Practices
接下來有段時間可以重新整理某專案裡頭的 IAP 相關程式碼與流程，所以找了不少參考資料，最權威的當然就是蘋果自家的文件囉。除了這個之外，底下這些也很適合參考：
- Technical Note TN2413: In-App Purchase FAQ
- Optimizing In-App Purchases - WWDC 2014 - Videos - Apple Developer
- Preventing Unauthorized Purchases with Receipts - WWDC 2014 - Videos - Apple Developer
- Advanced StoreKit - WWDC 2017 - Videos - Apple Developer
- What's New in StoreKit - WWDC 2017 - Videos - Apple Developer
我也打算把 StoreKit 包起來，讓其他地方的程式碼可以更優雅地使用它，所以也參考了其他 library 的做法，看起來這幾個算是做得滿漂亮的。
- InAppPurchase: A Simple and Lightweight framework for In App Purchase
- CargoBay: The Essential StoreKit Companion
- IAPManager: Ultralight StoreKit - iOS macOS
Release 1.0.0.alpha.1 - First fastlane.ci alpha
之前曾經提過的 fastlane.ci 已經按照進度推出 1.0.0 alpha 了，它跟 fastlane 完美的整合，打從一開始就是為了 iOS/Android 開發流程打造，並且 100% 採用 MIT 授權開放原始碼，你可以自架伺服器來運行它。雖然只是 alpha 版，但已經算是堪用了，有興趣的可以玩玩看。
iOS Developers Ship 29% Fewer Apps In 2017, The First Ever Decline – And More Trends To Watch
除了標題講的那樣之外，這篇文章也提供了一些其他數據，例如使用 non-native 開發的比重有多少，以及最多人選擇的 non-native 開發方式等等。蠻有趣的一篇觀察，有些數據或許可以做為你下一個 app 開發方向的參考依據。
GitHub - shuaiwang007/RAC: RAC 的常用用法，提高开发效率
在我們公司的專案裡頭，ReactiveObjC 佔了蠻重要的一個角色，所以熟悉 RAC 的各種用法是很重要的（當然不會 RAC 也沒關係啦，我們會教你！）。前幾天在亂逛網路時，發現了這個 repo，裡頭把最常用的 RAC 功能都詳細解說了一遍，不管是當作速查表或是當作新手上工補充教材，都非常合適啊！
順便追加一個速查表，裡頭包含了 ReactiveObjC / ReactiveSwift / RxSwift。
Tips to become a better Swift (iOS) Developer
很多人推崇 Swift 的一個理由是它比較簡單，但我一直認為這是一個假象。我覺得 Swift 好上手，但它易學難精，一個不小心就會寫出不優雅或是效能不夠好的程式碼。這篇文章裡頭透過大量的程式碼片段說明如何成為更好的 Swift 工程師，值得初學者參考。
SwiftTips: A collection of Swift tips & tricks that I've shared on Twitter
看完之後或許你會懷疑這真的是你平常在寫的 Swift 嗎？恩..... 真的是易學難精 Orz
@allanlei
Mastering Chaos
Josh Evans (of Netflix at the time) gave a great talk of Netflix's road to where they are now. He talks through problems they've experienced creating large distributed systems, what microservices are and are not, and how embracing chaos can affect design decisions.
Storing Redis values with msgpack
It's like JSON. but fast and small.
When there is a need to store data structures in Redis, the go to way is to serialize in JSON. For those cases, why not use msgpack?
- Serialized size is smaller with msgpack and smaller means memory savings
- Able to serialize custom types via Ext
- Redis lua supports it out of the box
Critics of msgpack, including the author themself, says it is still not as good as JSON+Compression, but for the use case of redis, there wouldn't (normally) be compression.
Seems like a straight-forward method to save on resource with limited drawbacks.
ZStandard for better Compression of REST APIs
A lossless compression algorithm by Yann Collet at Facebook (also the worked on lz4) that aims to offer faster compressions and at higher ratio compared to current libraries like zlib.
The special feature in ZStandard I think will be very beneficial is the use of a pre-train dictionary aimed for the use of small payloads where the data is normally too small to generate any valuable compression context. JSON payloads from REST APIs fit this use case pretty well having many small payloads <100KB.
Having run a very simple test against our own APIs, I was looking at 20% better compression compared to gzip using a pre-train dictionary. Don't take my word for it, try it out for yourself!
工作機會
Senior Frontend Developer at Swag
薪資範圍：年薪新台幣 100 萬元以上。
能力需求：
- 精通 JavaScript、CSS 與 HTML
- 相容主流瀏覽器的前端整合開發經驗
- 前端 framework / library 的使用經驗
- 熟悉 React
- 模組化開發經驗
This RSS feed is published on https://weekly.codetengu.com/. You can also subscribe via email.