CodeTengu Weekly 會在 GMT+8 時區的每個禮拜一早上 10:00 出刊,每一期會從目前的 curator 名單中選出三位來負責當期的內容,每一位 curator 各自負責不同的領域,如果你在這一期沒有看到自已感興趣的東西,說不定下一期就會有了。
你也可以瀏覽一下前幾期的內容,有價值的東西是不會過時的。
以下是目前的 curator 陣容:
大家也可以 follow 一下 CodeTengu 的Facebook 和Twitter,有很多 Weekly 看不到的內容。有任何建議或疑問也可以來Gitter 聊一聊,歡迎亂入 :japanese_goblin:
為了服務廣大的喜愛動漫的臭宅們,從本期開始,我們會不定期地推出 Otaku is the New Sexy 專欄,以三場晚餐約會和跟她去一次動物園作為交換,我們非常榮幸邀請到在東立出版社工作的職業腐女@autisticcat 小姐來跟大家分享。
所謂的 Magic Methods 就是指 Python 的那些 __xxx__
的特殊 methods,例如最常見的 __init__
、 __call__
、 __str__
或是寫 context manager 一定會用到的 __enter__
和 __exit__
。雖然有很多的 magic methods 平常不見得用得到,但是你至少應該看一下最後的那個 How to Call Magic Methods 表格,這樣你就知道那些你在別人的程式碼裡看到的魔術一般的用法是怎麼做到的了。
這篇文章匯整了各方大神給 Golang 初學者的建議,但是主要講的都不是技術上的細節,而是觀念和心態上的 best practices。
雖然常常聽到有人說每個程式語言都大同小異,只要精通一個,就能夠一法通萬法通,但是老實說我覺得這種說法根本就是放屁啊。如果只是學學基礎的語法,寫幾個屁程式,很多語言當然都很簡單。但是不同的語言其實都有各自的設計哲學、風格和慣例,要能夠寫出「道地的」程式碼,終究還是少不了長時間而且大量的實踐。所以「學習新的程式語言」這件事的潛在成本其實很高,換句話說,「如何決定要學什麼」也是一種很重要的技能啊。
medium.com
從資料庫中隨機取出幾筆記錄是個很常見的需求,但是我們都知道 ORDER BY RAND()
很慢,就算你以為你 LIMIT 1
了。這篇文章就列舉了其他幾個能夠達到同樣結果但是效率更好的方案。
延伸閱讀:
imysql.com
這是由The New Stack 出版的一系列的 Docker 特刊,這一本是第一集。雖然我偶爾會取笑 The New Stack 就是技術文章界的內容農場,但是這本製作精美的小冊子倒是挺全面的,連最近的熱詞 Unikernel 都提到了。雖然有些章節的廢話很多,但是其中提到的某些數據蠻有趣的,例如對 Docker / Container 這項新技術的採用程度,大公司反而比一般的 startup 更高,但是想了一下也是有道理。
題外話,我當初知道這個網站其實是因為awesome-python,那時候建立這個 repo 才沒幾天,就收到 The New Stack 的人寄來的信,說想針對這個主題寫一篇文章(雖然其實我後來沒回覆他),從那個時候開始我才發現國外的技術寫手的生態原來這麼蓬勃,而且他們不像Inside 這樣的網路媒體,老是寫一些不入流或是錯誤百出的文章,國外的這些技術寫手對技術趨勢是有敏銳度的,而且他們是真的知道 Kubernetes 和 Mesos 是在做什麼的啊。
thenewstack.ioHow do you answer questions like "Why did you choose X over Y" where X and Y are two competing technologies and you simply prefer X to Y?
我對於這種怎麼決定要用什麼技術(或是該怎麼點自己的技能樹)的主題一直都很感興趣。
這是一個在devmag.io 上討論,其中有一個人的回答可能挺有道理的:對於那些 "serious" 或是有急迫性的專案(簡單說就是你們公司的主力產品,做得好不好會左右公司存亡),最好還是用你或整個團隊都很熟悉的技術,即使那是個已經不新潮了的技術。
但是我們也不要騙自己了,軟體工程師就是一群喜新厭舊的人啊,一聽到可以在專案裡用那個很潮的新玩意時,大家都超興奮的啊。所以嘛,才說每個人其實都應該要有自己的 side project,因為 side project 就是讓你嘗試新技術的地方啊。走得再前面一點,甚至每間公司、每個團隊也都應該要有 side project,畢竟現在優秀的軟體工程師可是很難找的啊,除了薪水、年終之外,彈性上下班(甚至是在家工作)、可以玩新技術也是很重要的福利啊,希望各企業的雇主們好好檢討一下。
devmag.io
Android 上最知名的 REST client - Retrofit 在近期華麗地推出了 Retrofit 2 ,有哪些不一樣呢?終於可以在取得 deserialized object 的同時查找 header 或 URL、request 可以被真正的取消、一律採用 OkHttp 為 Retrofit 的 client。
Retrofit 2 發佈時的影片, 投影片
如果你對 Retrofit 有興趣,但還在觀望,建議你可以看這篇教學 Consuming APIs with Retrofit
inthecheesefactory.com
這個 IntelliJ / Android Studio 的 plugin 實在是太令人振奮了!透過 Wifi 網路就可以 build 到實機上 debug 了。
github.com
在開發 iOS 的時候一定會經常性使用 lldb console 或是 Xcode 6 之後的 Debug View Hierarchy。而 chisel 是一個 lldb 的插件,有一堆常用跟不常用的命令集合,可以加速以上的過程或做到一些原本需要 rebuild 才能調試的部分,省下大量的時間,理論上大家就可以因此更早下班了。
大家的好朋友 objc.io 有一期 lldb 的主題 Dancing in the Debugger — A Waltz with LLDB ,在介紹實作的部分有大量提到 chisel。
如果想要先感受一下,可以看 Chisel-LLDB 命令插件,让调试更 Easy 及 教你使用 FaceBook 的 chisel 来提高调试效率
github.com
app 不只有一個進入點已經是越來越常見的事情,可以是在 web 上透過Universal Link,較傳統的 custom URL schemes 或甚至是在 spotlight 搜尋進入 app 的特定頁面。
這篇文章是Buttons 內部對 Deep Links 的 best practice,比較有趣的部分是關於 Deep Links 的 error handling 以及開始為你的 Linkable page 做 testing。
usebutton.com雖然 Apple 的開發者網站一直做得很爛,但是透過這個新的搜尋功能來找 WWDC 的影片真的是蠻棒的。WWDC sessions 就是 iOS 開發者的寶庫,現在可以精確地跳到你搜尋關鍵字所在的秒數,以後要是有什麼 iOS API 用得沒什麼信心,倒是可以先來這邊搜一下,再去 stackoverflow 或 GitHub 了。
apple.com
應該沒人真正統計過誰是最多人用的 APIs framework, 那是 Swagger 在官網宣稱的, 但值得我推薦。
通常開發專案, 我們都會先開發 app, 再開 APIs, 最後才提供 APIs 文件。但有了 Swagger, 我反而喜歡請 PM 用swagger editor 編輯器吧 APIs 開好, 再給程式設計師開發, 最後再統一給 front-end 或 mobile app 工程師同時來調用。
由 swagger editor 編好的 YAML 或 JSON 檔, 除了可以直接放在 swagger UI 網路上開放, 如petstore demo, 更可以直接拿swagger generator 來產生 client 端範例程式, 其中包括 iOS, Android, JavaScript, Java, Scala, Ruby, Python, Clojure 等。太好用了。下次有新專案, 讓我們用 swagger 定義 APIs 開始做起。
swagger.io
一直想介紹 go generate, 但很難找到好且易懂的介紹文章。這個msgp 其實是一個 go generate 的工具, 自己也是它產生出來的碼自己叫用的副程式庫。(沒想到可以這樣用)
每當你想用 go generate, 第一步你需要寫一個工具 (例如 msgp, 它可以用任何語言寫, 只要能被執行到), 第二步寫一個你想產出程式的部分程式碼 (這裡 main.go 爲例), 裡面加上下面這一行
//go:generate msgp
當你執行 go generate 後, main.go 會產生 main_gen.go 和 main_gen_test.go 這兩個程式就馬上可以執行, 範例還包含了測試和 benchmark 的程式碼。(很神奇吧!)
github.com
當你寫 Go 時, 會慢慢開始用到 goroutines 來加速你的程式。但一平行化下去, 處理同一區資料時, 執行先後次序不同, 問題就來了。
這篇文章介紹如何使用 Go 語言的 sync.Mutex 來寫 lock 跟 unlock, 還有如何寫才不會造成 deadlock。這是一般工程師常用的方法, 但未必是 Go 的 style, Go 更希望大家用channels 來解決這類的問題。
但到底用 sync 還是用 channel 比較好?這裡有簡單的答案: 一開始, 你可以先用熟悉的 lock, 當你 lock 越做越複雜時, 可慮看看用 channel 會不會比較簡單。
medium.com