Hello World
CodeTengu Weekly 碼天狗週刊
CodeTengu Weekly 會在 GMT+8 時區的每個禮拜一 AM 10:00 出刊，每期會由三位不同的 curator 負責當期的內容，每個 curator 有各自擅長的領域，如果你在這一期沒有看到自已感興趣的東西，可能下一期就會有了。你也可以瀏覽一下前幾期的內容。
目前的 curator 陣容：
- @vinta - I failed the Turing Test - 科幻迷，最近在讀 The Player of Games
- @saiday - Imnotyourson - 希望在離開台北之前可以見證到捷運禁止飲食廢止
- @tzangms - Oceanic / 人生海海 - 衝動型購物
- @fukuball - ImFukuball - 婚後生活
- @mingderwang - Ethereum enthusiast
- @kako0507 - 熱愛嘗試新事物的前端工程師
- @chiahsien - 新年新專案，好刺激啊！
- @hiroshiyui - 沒有人是一座孤島
- @uranusjr - Smaller Things - 不愛談技術的技術人，最近對做菜很有興趣
- @kkdai - 態度萬歲 - 喜歡 Golang 的略懂工程師，最近在學機器學習 (疑?)
- @yhsiang
你也可以關注我們的 Facebook、Twitter、GitHub 或微博，有很多 Weekly 看不到的內容。有任何建議或疑問也可以來 Gitter 聊聊，歡迎亂入。
致力於解決開發者之間的資訊不對稱
@vinta
Parallel tasks in Python: concurrent.futures
在 Python 中如果想要平行或並發地執行許多任務，常常會用 multiprocessing 或 multiprocessing.dummy（其實就是 threading）。不過如果你的任務是所謂的 Embarrassingly Parallel，就是指每個任務之間不需要相互溝通或依賴，其實有更簡單的方式：concurrent.futures。
寫起來跟一般同步的寫法幾乎一樣，一個 for loop 打完收工，清爽。
延伸閱讀：
Inside Cloud Spanner and the CAP Theorem
上禮拜最值得一提的消息無疑是 Google 發表了 GCP 的新服務 Cloud Spanner。幾乎就是一個理想的資料庫該有的樣子啊，global distributed (not pure) relational database，支援 ACID transaction、SQL: 2011 和他媽的 horizontal scaling，看完都要尿褲子了。
Eric Brewer（就是提出 CAP 定理的人）在這篇文章提到，Spanner 嚴格來說是 CP 啦，而不是 @googlecloud 推文宣稱的 CAP，畢竟只要是分散式系統，network partition 是無可避免的。只是 Google 透過他們的技術和資本實力能夠把 A 拉高到你幾乎可以假設他們的服務不會出事（或者說是還沒等到 Google 的服務掛掉，你的服務先掛掉的機率還比較高）。
不過 Cloud Spanner 其實是跑在 Google 自家的 private global network（Eric Brewer 說這是最關鍵的一點），而不是我們這些平民平常在用的 public Internet；在 white paper 裡面還提到 Google 透過在各個 datacenter 裝備 GPS 和原子鐘實現了一套 TrueTime API，解決了分散式的 MVCC 機制在全球範圍內的不同機器之間的 timestamp 誤差。是說軟體開發搞到最後，拼的反而是硬體了啊。
延伸閱讀：
- Spanner, TrueTime & The CAP Theorem
- Cloud Spanner - Schema and Data Model
- TiDB - 中國的團隊根據 Spanner 論文開發出來的 NewSQL，相容 MySQL protocol
（這一期難得有兩個 curator 都寫了同樣的主題啊）
Building Recommendation Engines
之前趁春節假期的時候讀完了這本專門講推薦系統的書，從古典的 Collaborative Filtering、Content-based 到利用機器學習方法的 Model-based，提到了不少搭建推薦系統常用的機器學習和自然語言處理的「套路」，也分別示範了如何使用 Spark、Mahout 和 Neo4j 來實作推薦系統。雖然每個部份並沒有太深入，但是勝在給出了一個整體的、概觀的學習路徑，適合入門。
而且不知道為什麼，竟然還有附一系列的教學影片，影片內容就是書的精華版。何必呢。
不過專門講推薦系統的書也真的是不多，之前也讀了老牌的 Collective Intelligence in Action 和项亮（他的英文名字是叫 Vector 嗎？）的「推荐系统实践」，前者有點過時而且不太實用，後者很扎實但是就相對難啃，所以最先讀完的反而是這本書。
About debugging: 8 things I wish I knew earlier in my career
作者總結出來的 debug 應該有的「心法」，尤其是第二點。
其實只要不是那種 typo 等級的錯誤，你每解完一個 error / bug / issue，你其實就是學到一項新的知識，當然這個新知識可大可小。我自己的習慣是只要解決掉一個我之前沒遇過的問題或任務，就會開一篇 Evernote 的筆記記錄下來，不只是對以後的查詢、溫故知新很有幫助，長久累積下來，也是挺有成就感的，像我目前就囤了快 1800 篇的筆記。大家有空可以試試。
不過這個其實就是所謂的 TIL (Today I Learned) 的概念啦。
Growing Your Tech Stack: When to Say No
如果你也讀了前陣子那篇引起無數人共鳴的文章 Hype Driven Development，多半也會發現有些工程師就是ㄏㄧㄠˊ咖稱，你不讓他們三不五時玩一下新玩意兒他們是坐不住的，所以下一步要考慮的問題就會是：該如何評估要不要採用某項技術？
有個簡單的方式就是根據引入的新技術對產品可能造成的風險來判斷，例如從最輕微的開發工具的改善、中等程度的部署流程的變動到最重大的改用新的程式語言或採用新的資料庫。雖然這篇文章是把改用新的程式語言列為 moderate risk 啦，但是考慮到團隊成員對新語言的掌握程度和能不能即時從人力市場中找到足夠多而且足夠好的人來接手開發等等的因素，更重要的是導入新的程式語言通常也意味著新的工具鏈與整個生態系，所以怎麼看都不會只是 moderate 吶。
@kkdai
Golang Taipei Gathering #21: Go 1.8 release party 投影片與影片
這個月的 Golang 社群聚會號稱聚集了台北，台中與高雄的夥伴們一起歡慶 Golang 1.8 正式發行． 雖然當台北時間舉辦 Release Party 的時候還沒有正式發行（後來在半夜就出了正式版，可見專案管理能力萬歲)
這次主要請到 Umbo CV 的 David 跟 Kent 來講 Go 1.8 的一些新功能，內容包括新的語法，工具，甚至有提到 plugin 或者是 dynamic loading 的部分．
歡迎大家一起來看看．
Grumpy: Go running Python!
Google open source 為了解決很多 legacy 的 python code ，開發了一個工具可以讓你將 Python 轉換成 Go ，或是在 Python 裡面跑 Go 的套件．
一些重點整理:
Grumpy (脾氣暴躁 XD) 把 令人討厭的 GIL (Global interpreter lock) 拿掉了．換成 Go 的 GC 來管理．可以讓跑 python 的時候 multiple thread 更快． Grumpy 也不是第一個把 GIL 拿掉的 Python runtime, IronPython / Jython 都這樣幹過
目前 Grumpy 支援度不夠，所以大家使用前看一下 issue list (光是 import "/", "." 就有些問題 refer issue 11)
Grumpy 不知道 CPython 的部分，所以 numPy 跟 opencv 都不能用． (其實還不少不能用的，畢竟還 alpha)
也是可以跑 Interactive shell "make run" 就可以了...
目前僅支援 Python 2.7 (畢竟還有四年可以活 XD)
最後，為了呼應拿掉 GIL ， Russ Cox 也發了篇十年前的 C 語言文章．來解釋 lock 有多痛苦 XDDD
想清楚了解 Python GIL 是什麼，可以看看這篇 slide
uber/cherami-server: Distributed, scalable, durable, and highly available message queue system.
Uber 將他們的 Task Queue - Cherami 開源． 原本 Uber 是使用 Celery (Python) 作為他們的 task queue ． 由於業務的增加，對於 HA 的需求增加，於是用 #Golang 重寫成過，
並且與 Uber 許多好用的套件 TChannel (管 RPC) 與 RingPop (負責 Health Checking 與 Membership ) 結合在一起．
成為一個具有 Distributed, scalable, durable, 跟 highly available 的 task/message queue 系統
說明的部落格在這裡
[ATC: Podcast] 專訪 Swift 與 LLVM 的創造者，剛離開 Apple 到 Tesla 的 Chris Lattner
最近剛離開 Apple 到 Tesla 的 Chris Lattner 接受 ATP (ACCIDENTAL TECH PODCAST) 的邀請來談談 LLVM 跟其他相關科技． 記錄一下一些重點摘錄:
- 關於職涯轉換:
- 當然有談一下關於 Apple 跟 Tesla 在職業生涯上面的轉換． 對於 Chris Lattner 從工程師到管理階層的轉換，他自嘲不是一個所謂的 People person 但是他喜歡這方面的轉換．
- 有討論到 Apple 對於 Objective C 想要改善的想法，一直到了 ARC 甚至談到了 Swift 誕生的起因．
- 關於 Swift 的開源 (Open Source):
- Lattner 提到原本在他心中就覺得會發生，但是礙於公司政策無法來運作．
- 其實從一開始的 Commit 到相關工具的開發，都有顯示出來 Lattner 是從 Open Source 的角色來思考．
- 但是 Swift 2 Open Source 後， 公司無法規劃到說會得到那麼多的回饋．
從 HN 找到一些，關於 Chris Lattner 的八卦:
- 他一直都是一個實務派的人，所以小木屋與木工也都自己做． 照片在此:
備註一下: Chris Lattner 是 LLVM 跟 Swift 的發明者跟主要維護人．
參考:
- Swift creator Chris Lattner talks developer tools and career after recent jump from Apple to Tesla
- HN: Interview with Chris Lattner [audio] (atp.fm)
Google Cloud Platform Blog: Introducing Cloud Spanner: a global database service for mission-critical applications
Google 改變世界的幾篇論文中 (MapReduce, BigTable, Chuppy, Borg, Spanner) ，總算又有一個從論文變成商品了．參考: 五大神論文
當然宣傳內容很讓人驚訝，CAP Theorem 可以完全 (強) 滿足嗎? 可以看看這篇文章
當然我們都知道 CAP 無法都完全支持，大部分會選擇某些比較弱，當另外兩項選擇強支持的時候．
"Spanner does not actually beat CAP theorem. It chooses C over A when P happens. But the infra team in google manages it so well so they could still deliver high Availability to most users."
但是，當然這麼好的神器便宜嗎？
"開一台 0.9 usd/hour，儲存和傳輸另外算錢" refer kaif
難道 Spanner 論文出來後沒有人試著把 Spanner 做出嗎?
當然有！就是之前很紅的小強資料庫 CockroachDB，所以他們當然趁著風頭繼續推廣他們的 Open Source 小強資料庫
最後，別忘記 CockroachDB 使用 Golang 寫的!! 歡迎加入 Golang.tw 社群
@yhsiang
A deep dive into children in React
詳細地介紹 React children，還有 React 內建的 Children helper 函式。 沒有用過 React children 的話建議可以看一下這篇，善用 React children 對於 component 組合會很有幫助。
UI component explorers — your new favorite tool
告訴你為什麼應該要用 UI Component explorer，主要以 Meteor 的 Chromatic 為介紹，最後也有帶出其他幾個知名的工具，像是 Storybook、Devcards。
如果你們前端團隊還沒導入類似的工具，建議趕快導入。對於前端開發協作有很大的幫助。
RethinkDB versus PostgreSQL: my personal experience
作者介紹他從 RethinkDB 轉移到 PostgreSQL 的心路歷程。
使用 RethinkDB 相當長一段時間，即使中間有碰到許多問題，還是相信 RethinkDB 最終會解決這些問題。直到 RethinkDB 的公司喊停為止，加上客戶要求產品中不能有 AGPL 相關授權的東西。此時，才重新思考用何種技術取代 RethinkDB。
最後選中了 PostgresSQL，因為有比較自由的授權，而且擁有 LISTEN / NOTIFY，比較符合他原來的使用方式。比較了轉移前後的速度，CPU 使用量，還因此省下每月約 $800 的費用。
WebPack is not the only way
webpack 出現以後，改變了前端開發的生態。過去要靠 make、grunt、gulp 或者自行寫 shell script 解決，都因 webpack 出現而改變。當然因為 webpack 還是有許多被人詬病的地方，例如文件寫得不是很好。而 webpack 出現的時候，babel 也還沒出現而且 ES2015 還沒被廣泛地使用。後來也出現許多類似的工具，像 JSPM，Rollup 但始終不像 webpack 這樣能解決 html、css 甚至圖片的打包問題。
Fusebox 除了強調他快速以外，透過 plugin 也能夠打包 html 跟 css。雖然 webpack 前陣子終於釋出第 2 版，但看來 fusebox 來勢洶洶。希望能繼續良性競爭，造福廣大的前端開發工作者！
An Update on ES6 Modules in Node.js
雖然 node 上面已經實現了不少 ES2015 的語法，但是 module system 卻遲遲不見蹤影，因為 node 當初採用的是 CommonJS 跟 ES2015 的 module system 有很大的不一樣。
像 node 裡面是當執行到該行 code 的時候才同步地載入，而 ES2015 採取異步的策略。當然他們也正在嘗試解決這個問題，像是採用新的副檔案名 mjs，別名為 Michael Jackson Script ，透過這個副檔名，該檔案可以被認為是 ES6 module 而原本的 js 就採用 CommonJS 的系統。
工作機會
Python Web Backend Developers at StreetVoice
開發與維護 StreetVoice 旗下相關網站，開發流程包含 Code Review、CI 與自動化部署，團隊內有專職的 DevOps 和前端工程師。主要技術棧：Python、Django、MySQL (MariaDB Galera Cluster)、Redis、Elasticsearch、Ansible 和 AWS。
意者歡迎來信：tzangms@streetvoice.com。
This RSS feed is published on http://weekly.codetengu.com/. You can also subscribe via email.