CodeTengu Weekly 碼天狗週刊

Hello World

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

目前的 curator 陣容：

@vinta - I failed the Turing Test - 科幻迷，最近在讀 Dirk Gently's Holistic Detective Agency，電視劇也拍得超屌！拜託看！
@saiday - Imnotyourson - 電量給我這種人用就是一種浪費
@tzangms - Oceanic / 人生海海 - 我最近居然開始在挖礦跟研究區塊鏈了呢
@fukuball - ImFukuball - 有新工作了，但歡迎直接挖角
@mingderwang - Ethereum enthusiast
@kako0507 - 熱愛嘗試新事物的前端工程師
@chiahsien - 徵有經驗的 iOS 工程師，快來 Twitter 私訊我
@uranusjr - Smaller Things - 我要成為錯字王
@kkdai - 態度萬歲 - Learning Deeply....
@yhsiang
@johnlinvc - 挑戰自動化家中電器
@drumrick - 歡迎加入台灣 Kaggle 交流區
@wancw

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

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

@vinta

Timezone in Python: Offset-naive and Offset-aware datetimes

關於 datetime 和 timezone 的處理可能是每個軟體工程師遲早都會遭遇的難題之一，以前一直沒有搞得很清楚，前陣子總算有時間稍微整理了一下 timezone 在 Python 裡需要注意的地方。跟大家分享一下。

之前幾期的 issues 裡，其他 curator 也都不約而同分享過 Falsehoods Programmers Believe About XXX，其中就有幾個主題是「時間」，有興趣的人可以翻一下。

MongoDB Query Performance over Ranges & Indexes that Help

上禮拜換了新工作，負責解的第一個 issue 就是改善某個複雜的 MongoDB aggregation 的效能。雖然對 MongoDB 還不是很熟（只有在第一份工作用過一陣子，而且後來就改用 PostgreSQL 了），不過遇到 slow query 問題的起手式基本上都是先 explain 一下，從 queryPlanner 和 executionStats 欄位可以知道哪個 stage 的哪個 query 用了哪個 index、掃描了多少數據和回傳了多少數據。最後透過修改了 query 的寫法並且加了一個「欄位順序正確」的 compound index，總算成功地把執行時間從 1.x 秒降到 0.01x 秒。

這篇文章講的就是「欄位順序」對 MongoDB 的 compound index 的影響。作者還給出了一個簡單的判斷方式：

The order of fields in an index should be:

First, fields on which you will query for exact values.

Second, fields on which you will sort.

Finally, fields on which you will query for a range of values.

Spark 2.x Troubleshooting Guide

這份簡報和延伸閱讀的那篇文章列出了許多 Apache Spark 在使用上常見的問題和解法，這陣子在用 Spark 做推薦系統的時候，幾乎把這些地雷都踩過了，如果可以早一點讀過這些資料就好啦。

題外話，如果你也是用 Google Cloud Dataproc 跑 Spark cluster 的話，千萬記得可以用 Preemptible VMs，能夠省下不少費用。不要像我一樣白白被多收了好幾百塊美金，心寒啊。

Learning at work

這篇文章是 Stripe 的工程師分享的「如何在工作中學習」的文章。不過重點其實不是如何學習，而是「在工作中」學習。

畢竟要求每個工程師都應該在下班之後還要花很多時間學新技術、開發 side project 或是貢獻 open source 專案其實是不太現實的嘛。而且一天工作 8 小時，但是可以真的進入 mindflow 專心寫程式的時間可能連 4 小時都不到（我承認我超少）。有時候可能是狀態不對或是你就是欠缺完成任務所需要的知識，這時候與其硬幹、用 workaround 或是產出一些自己都不明所以只是剛好能動的程式碼，那還不如好好地利用上班時間，仔細鑽研一下你要解決的問題、搞懂那些你之前沒搞清楚的東西。再不然也可以重新審視一遍那個你剛剛解決的 bug 的 root cause，因為每個 bug 其實都是一個學習的契機啊。

就像陈皓說的「多些时间能少写些代码」，共勉之。

jvns.ca

@kkdai

[好文介紹] Scaling Kubernetes to 2,500 Nodes

最近比較忙碌，都只能夜深人靜才能好好的來閱讀一些文章來充實自己．(公司牛人多到像牧場，只好不斷努力 lol)

OpenAI 最近有一篇技術文章，相當的值得一讀．就是他們分享他們如何管理超過 2500 個節點．當然我們都知道，

Kubernetes 自從 1.6 之後就號稱可以乘載 5000 個節點以上，但是從數十台到 2500 台的路上，難道不會遇到一些問題嗎? 這篇文章分享了，他們遇到的問題，試著要解決與懷疑的地方，最後找到真正的問題．這篇文章適合所有 DevOp 好好的熟讀．

(公司目前在找 FE/BE Engineer, Data scientist 有興趣的可以來聯絡我喔

evanlin.com

The State of Go 1.10

Francesc Campoy 在 FOSDEM 上面講解 Go 1.10 上面修改的部分與未來方向..

對了 FOSDEM 2018 有很多好的講題

speakerdeck.com

[論文導讀] The Case for Learned Index Structures

剛好最近有幾次機會可以去工研院開會的路上，在高鐵的路途上可以好好的來欣賞這篇文章．這篇文章是由 Google Brain 的大神 Jeff Dean 連署的論文之一．講的是透過 NN 的方式來讓大家熟知的 B-Tree, Hashing table 甚至是 Bloom Filter 更有效率...

2018 年第一篇好好閱讀的論文，當然要獻給有深度而且相當有趣的這篇文章．The Case for Learned Index Structures ．主要的原因有以下:

這篇是講解一個新的機器學習的新領域（至少是相當有趣的觀點）
雖然有些限制跟品質的降低，但是讓我們對於 AI/Deep Learning 有了一個新領域的想法...
這篇是被稱為世界上最聰明的人 Google Brain 的主持人 - Jeff Dean 的論文 (編按: 這篇 Quora 有許多關於 Jeff Dean 的敘述文，相當的有趣 XD)

Jeff Dean 是誰? 快來看他的 Quorahttps://www.quora.com/What-are-all-the-Jeff-Dean-facts

他看得懂, 也寫 Binary code
他的 PIN code 是 Pi 末四碼

這系列導讀，我寫了上下集．下集在這裡．

evanlin.com

@johnlinvc

Stimulus Framework

百家爭鳴的 FE 界又多了一個名門之後。Ruby on Rails 的開發者 DHH 最近推出了新的 JavaScript framework, Stimulus.

設計的核心概念相當有趣，相較於 React.js (不含 redux) 專注在 MVC 中的 View ，Stimulus 專注在 MVC 中的 Controller 部分，把 Model 的 data 和 View 都交還給 HTML 本身。延伸了之前的 turbolinks 的概念，和伺服器的溝通不是透過 JSON, 而是直接回傳 HTML。裡面也可以看到很多 DHH 的 Rails 哲學，慣例大於設定，讓常做的事變得簡單。

有興趣的人可以照教學裝來玩玩看，不過官方推薦使用的線上編輯器 glitch 真的有 glitch，沒辦法跑 Stimulus 用到的 babel-plugin-transform-class-properties。要玩的人還是在自己的電腦上裝吧。

github.com

軟體複雜度正在殺死我們

身為程式設計師，最重要的工作是什麼呢？寫出好 Code？

作者認為程式設計師最重要的工作就是產生(商業)價值。做購物網站最重要的就是能購物，而不是與 babel 和 npm 對戰。和沒有銀彈提到的一樣，很多時候開發軟體的附屬複雜性還是太高，讓我們花了很多不必要的時間。最近 IFTTT 等低程式碼平台的流行，讓我們軟體工程師必須要反思：我們有把時間花在最重要的事情上嗎？還是都拿來做一些附屬性的工作 (修 dependency 等等)？畢竟很多的工作用 IFTTT 瞬間就搞定了，自己來做卻連 npm install 都還沒跑完。

好的程式應該要像 Larry Wall 說的一樣

Easy things should be easy, and hard things should be possible.

simplethread.com

Chaos Engineering

在這個 micro service 與 distributed system 當道的世代，容錯變的越來越重要。 Netflix 之前推出的 Chaos Monkey 帶來了一個嶄新的概念。如果我自己在系統裡隨機產生各個問題，不就能知道系統夠不夠穩定嗎？Chaos Monkey 如其名，會隨機在雲端服務上關掉 VM 或 Container，強迫系統在設計時就考慮到最糟的情況。

Chaos Engineering 延伸了這個想法。先定義一個可測量的穩定狀態，再列出可能會有的各種錯誤。在實驗組中手動產生各種錯誤，再和對照組比較，就能找出系統中的各個脆弱的部分。

PS. Do not try this at home (production)

PS2. 雖然真正穩固的系統都在 production 上做測試，包含 Netflix & Uber

principlesofchaos.org