转载

CodeTengu Weekly 碼天狗週刊 - Issue 41 一邊喊著找不到人才，一邊要求租稅優惠，聽到調高基本工...

Hello World

CodeTengu Weekly 碼天狗週刊

CodeTengu Weekly 會在 GMT+8 時區的每個禮拜一早上 10:00 出刊，每一期會從目前的 curator 名單中選出三位來負責當期的內容，每一位 curator 各自負責不同的領域，如果你在這一期沒有看到自已感興趣的東西，說不定下一期就會有了。

你也可以瀏覽一下前幾期的內容，有價值的東西是不會過時的。

以下是目前的 curator 陣容：

@vinta - I failed the Turing Test - 喜歡科幻小說，最近在讀「平面國」
@saiday -Imnotyourson - 捷運飲食推廣委員會
@tzangms -Oceanic / 人生海海 - 衝動型購物
@fukuball -ImFukuball - 徵 Android 工程師，意者內洽
@wancw - 繼續寫 LeetCode 可能會生出一套 Unit Test 框架
@adamp33 -看棒球才是正職，副業是前端工程師
@mingderwang
@kako0507 - 熱愛嘗試新事物的前端工程師
@chiahsien -Nelson
@hiroshiyui - 非典型司書
@uranusjr -Smaller Things - 聽說這是技術週刊，可是我不愛談技術怎麼辦
@kkdai -態度萬歲 - 喜歡 Golang 的略懂工程師

大家也可以 follow 一下 CodeTengu 的Facebook、Twitter 或GitHub，有很多 Weekly 看不到的內容。有任何建議或疑問也可以來Gitter 聊一聊，歡迎亂入 :japanese_goblin:

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

@vinta

SQL Exercises

"Real World" 的 SQL 練習題，前陣子在複習 SQL 的時候有拿來練練手，是個不錯的教材，推薦給同樣被 ORM 慣壞的你（誒，這句話好像前幾期就說過了？）。

P.S. 雖然跟主題無關，但是忍不住跟大家分享一下，我這禮拜都在玩BioShock Infinite，幹你娘真的超好玩，大家有空可以感受感受，這才叫做數位藝術吶。

wikibooks.org

Best practices working with Django models in Python

這篇文章列出了 25 個 Django Model 和 ModelForm 的 best practices，雖然多到有點瑣碎，但是每一項確實都是值得遵循的做法。

React 最佳实践 —— 那些 React 没告诉你但很重要的事

這篇文章（和延伸閱讀裡的第一篇）特別提到了「在 React 裡怎麼處理跟後端要資料」這件事的幾個做法。

Help!ful Things YOU Can Do for New Developers

因為公司前陣子來了幾位新同事，有 PMs 也有 developers，為了讓新人能夠更快上手、讓彼此的合作更加順暢，似乎也是需要一點小技巧的啊。正好就看到這篇文章，作者列出了一份「你可以為 junior 工程師做的事」的清單，以她當初還是新手時所受到的幫助為例，真的都是很務實的建議啊，例如：

Explain jargon that new developers might not know or understand.
Walk new engineers through the code base.
Give them read access to your database in a way that they know what data is available to them.
Let new engineers watch you debug, and explain what you’re doing.
Don’t give them lines to copy/paste into the code.
Explain your expectations and time estimations for projects clearly.

eventbrite.com

Being A Developer After 40

作者是一個 42 歲的軟體工程師，以一個見證了無數技術的更迭與炒作的過來人身份，給了很多中肯的建議。這篇文章寫得真的好。

freecodecamp.com

@saiday

JonSnow: Google Play review watcher, delivering to your slack channel

在 iOS 社群裡有一個LaunchKit 的 Review Monitor 服務，精美而且免費，我用它將 App Store 上的新評論都接到公司的 slack channel 裡面。

Android 社群中是有一些類似的服務沒錯，但是全部都要收費，而且功能還沒有很齊全，所以後來也就沒有使用了。

上禮拜我們公司上線了新版的 Android app (StreetVoice)，我覺得大家一定會稱讚我們，急著想要把 Google Play 上的評論接進 Slack 裡面，而既然市面上沒有好的 review monitor 的選擇，就只好自己做一個。

功能很簡單，就是爬一下 Google Play 的 reviews，而我將這個工具做了Heroku button 的整合 (@tzangms 介紹的！)，只要按一個按鈕，填入要 monitor 的 app_id 跟 slack channel incoming hook，你就自己 host 這個服務了，完全不需要寫 code。使用的方式都在 Heroku 免費的條件內，所以也不需要付費。

PS. CodeTengu 一直都有幫大家推廣 Open Source Project 的計畫，但是好像太少提而沒什麼人知道，如果你有自己的 Open Source Project 想要透過 CodeTengu 做推廣，你可以透過各種管道 (gitter,GitHub ..) 讓我們知道。

github.com

The Trouble with Manager Objects

你的 codebase 裡面有充斥著大量 Manager 或是 Utils 物件嗎？

Single responsibility principle (A class should have only one reason to change) 是一個很玄的東西，聽起來像廢話但是大家總是做不好。

遵照 SRP 的理念，我們可以問自己這些 Manager 、 Utils 的責任到底是什麼，它負責了超過一件事情嗎？它可以拆得更精確嗎？

作者有提到一點我很同意，在 OO 的概念裡面，應該是對該 model object 做操作，而不是把被操作的物件跟動作都丟給所謂的 Manager 來處理，畢竟這樣的話，你很可能把你的 model 弱化成 entity 了。

另外， Manager 這個詞代表什麼都可能做，其實也就是光從名字上是很難理解它到底在做什麼的，在這裡推薦大家這個經典的 stackoverflow 問題 Naming Classes - How to avoid calling everything a “<WhatEver>Manager”? ，裡面有很多名詞可以挑選，雖然說有些真的是太偏門了。

sandofsky.com

Automatic memory leak detection on iOS

Facebook 針對 iOS 的 memory leaks 開源了三個項目 FBRetainCycleDetector 、 FBAllocationTracker 、 FBMemoryProfiler 。

前兩個是這套工具的基石，透過 objC 強大的 runtime framework，不斷的在記憶體中檢查 retain cycles。

Facebook 說他們利用這兩個項目建造了一個自動化檢測 memory leaks 並發修復通知給引入 retain cycle 的工程師的系統。

而 FBMemoryProfiler 也是利用前兩個項目做到了基本上可以取代 Xcode 提供的 Instrument allocation 的工具，裝在你的 debug build 上，可以隨時做快速地檢測。

其實偶爾會聽到人家說，現在記憶體都那麼大，不用怕啦。我覺得不是這樣子的，memory leaks 除了字面上的該釋放而未釋放之外，他還會有一些可怕的 side effects 呀，比方說透過 Notification、KVO 或 FRP tools 引入的 observer 它 leak 了，那它還是有可能會被觸發一直做事情，就可能會有可怕的事情發生。

facebook.com

Avoiding cold starts on Android

code start: 你的 app 不在記憶體裡的啟動，是花最多時間的啟動情況。

作者再一次宣稱 Android app 不應該在 code start 的時候使用像 iOS 一樣的 splash screens，因為這樣做會拖慢開啟的時間、增加 app 的大小。

我們可以透過 android:windowBackground 跟 <layer-list> 搭配的技巧合理地在我們的 app 載入到記憶體的這段期間做點事情，在 Material design guides 提到的兩種啟動畫面: placeholder、 branded 都可以透過這個技巧來實作。

github.io

Meaningful Motion with Shared Element Transition and Circular Reveal Animation

Material Design 真的是很不錯，其中的 circular reveal animation 不只看起來舒服，而且對使用者的認知體驗也是加分的。

這是一個關於 circular reveal animation 的教學，而關於 transitions 你也可以輔助官方的教程使用。

thedroidsonroids.com

@hiroshiyui

What's coming in Elixir 1.3

這篇介紹了 Elixir 1.3 的新特性，其中很多語法上的更動讓 Elixir 程式得以撰寫的更精鍊易讀，有些輔助工具的更動則讓程式碼測試、建置變得更方便，我個人讀來是非常喜孜孜，期待 1.3 版正式釋出。

文章作者 Daniel Perez 另外做了一份簡報版發表在tokyo.ex 聚會上，再追了一下才知道日本有beam-lang.tokyo 這樣一個社群，頭一次看到對基於 BEAM VM 的程式語言統稱為 beam-lang，我這個愛用文字哏的人覺得還蠻有意思的。

tuvistavie.com

Comparing Elixir and Erlang variables

在 Erlang 裡，變數只能被賦值一次，是不可變的 (immutable)。但是在 Elixir 裡，我們卻 彷彿可以 像是用 C, Ruby 之類的語言，對變數「重新賦值」，而這也是從 Erlang 跳過來 Elixir 的人最可能會覺得離經叛道、一時無法接受的地方。事實上，Elixir 是對變數「重新綁定」(rebinding) 而非「重新賦值」，變數先前被賦予的資料仍舊存在記憶體的某個位置，重新綁定後的變數只是指向了另一份不同位置的新資料。

這篇文章，是 Elixir 之父 José Valim 談論 Elixir 與 Erlang 對變數處理設計的相異點。我推薦搭配 Immutability in Elixir - Self Recursion 這篇，以及 Elixir RAM and the Template of Doom 這篇一起看。

plataformatec.com.br

Unicode and Elixir

早期因為讀了蔡學鏞的文章開始接觸 Erlang 時，看到「而且 Erlang 居然還不支援 Unicode，這是個相當大的缺點」這句，心就涼了半截。以我主修的圖書資訊學來說，拿程式來處理文字資料，是最基本的功夫，這當中對於 character Set, character encoding 的處理自然是不可免的，尤其在臺灣這個至今還會遇到活化石Big5 的地方，程式語言的內建機制若沒有現成的字元編碼處理能力，用起來就會顯得綁手綁腳，自然會影響使用意願。

事實上，Erlang 對 Unicode 與 UTF-* 的支援，隨著歷次更版漸漸在改進，所以情況已經與早先大不同了。回頭看 Elixir，可能是因為後起之秀的關係，對 Unicode 與 UTF-8 的支援已經很完善，官網對此也有專門的一份文件 Binaries, strings and char lists 說明。那麼，Elixir 針對 Unicode 支援的內部實作又是如何呢？標題這系列文有不錯的探討，截自本期出刊，已經寫到第三篇：

Unicode and Elixir, part 1: Introduction
Unicode and Elixir part 2: Where Elixir defines and uses Unicode
Unicode and Elixir part 3: Elixir's Unicode source

github.io

Erlang 程式開發原則：該錯的放它錯

從講求防禦式程式設計的 paradigm 轉來學習 Erlang 與 Elixir 時，相信很多人，包括我在內，一開始也不習慣「放乎去」這樣的思維。但是就因為函數式語言追求函式求值結果的單純，所以對於 business logic 上的可能複數狀況，則應該反思在函數規劃上是否還不夠「純粹」，至於各種外部因素的錯誤，則應交給 supervisor, BEAM 與 OS 去處理，函數就只應負責如實求值就好。

在 Stack Overflow 上頭這則 Non-defensive programming in Erlang 問答，講得很清楚，也值得大家一讀。

wordpress.com