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 - 最近好窮，有案子可以接嗎？
- @wancw - 為了工作開始看韓劇
- @mingderwang - Ethereum enthusiast
- @kako0507 - 熱愛嘗試新事物的前端工程師
- @chiahsien - Nelson
- @hiroshiyui - 非典型司書
- @uranusjr - Smaller Things - 不愛談技術的技術人，最近對做菜很有興趣
- @kkdai - 態度萬歲 - 喜歡 Golang 的略懂工程師
- @yhsiang
大家也可以關注我們的 Facebook、Twitter、GitHub 或微博，有很多 Weekly 看不到的內容。有任何建議或疑問也可以來 Gitter 聊聊，歡迎亂入 👺
致力於解決開發者之間的資訊不對稱
@kako0507
JavaScript variables lifecycle: why let is not hoisted
Hoisting 是 JavaScript 容易被混淆的一個機制，就像字面上的意思，是將 Declarations 提升到 Scope 的頂端，如果對這個機制不熟悉，就很可能寫出錯誤的邏輯，文內會探討 var 與 function 宣告時的 lifecycle ，分成以下三個階段：
- Declaration phase：在此 scope register 一個新的變數。
- Initialization phase：配置記憶體空間並且初始化變數值為 undefined。
- Assignment phase：賦予變數新的值。
在 var 的 lifecycle，Declaration phase 與 Initialization phase 會合併在 scope 最頂端執行，而 function 則是三個 phase 同時執行， ES6 的 let 可以將 Declaration phase 與 Initialization phase 這兩個步驟 decouple ，從而打破 Hoisting 的機制。
Create Apps with No Configuration
@Dan Abramov 提出一套無須任何設定，幾道簡單指令即可開始練習撰寫 React 專案，想開始入門的朋友可以試著玩玩看。
React.js in Patterns
這個 repo 介紹許多使用 React 時的 Patterns 以及 Anti-Patterns ， 能幫助使用更好的方式開發 React 專案，會以以下幾個觀點切入：
- Communication
- Composition
- High-order Component
- Event Handlers
- Dependency injection
- Data Flow
@uranusjr
Don’t add your 2 cents
當你沒什麼有用的意見時，閉嘴。說起來簡單，但卻是極度容易犯的錯誤。尤其當位置越爬越高，有時候總是會覺得好像沒有意見，好像就暴露出自己其實也不太懂；隨口講幾個無關痛癢的屁點，展示出自己其實也是略懂，才不會丟臉啊。
但這樣其實對大家都不好 —— 無謂的批評傷了創造者，而真正懂的人一聽就知道這毫無營養，對講話人的評價也相應下降。被滿足的只有自尊，以及早該遠離的同樣草包同伴。世界上要學的事情太多了，每個人都會有不懂的事情；只有看透這件事情，才不會落入這個陷阱。
HyperTerm — JS/HTML/CSS Terminal
HyperTerm 是個基於 Electron 的 terminal，目標是為三大平台提供美觀且可擴充的 command line 介面。我從用 Mac 起就一直使用內建 Terminal，確實沒有很好用，一直也有人叫我跳槽其他工具（例如 iTerm2），可是我就一直覺得介面哪裡怪怪的，不太好看，一直不想換。
但這個好像不錯啊，有點願意換了！現在功能還有點差，也不支援中文輸入法，所以用了一天之後送了幾個 bug reports 就先放旁邊，不過開發團隊還滿 responsive 的，也有不少 contributors，過一陣子會再看看。還有就是最近也有用 Windows，不論 Command Prompt 或 Powershell 都很難用，希望它也可以解決這個需求。
大家也幫忙試用一下，回報點東西啊！
Can't code, won't code - cracking the secret of gender imbalance in STEM
性別平權近年在很多領域都有大進展，除了一個例外：科技界。這篇文章描述了非男性在科技業界持續遭受，且幾乎沒有改善的受歧視處境，從高等教育領域人數、招募刻板印象、玻璃天花板、一直到 Apple 最近推出的 HealthKit 包山包海，就是沒有考慮月經、更年期、以及懷孕。
講這種話題在台灣一向都很引戰。中文界對女性的歧視表現不太一樣，所以常聽到國情不同，我們沒這麼做，所以不是歧視。也有很多人看到女性工程師因為較低標準被錄取，而認為女性根本比較吃香，男工程師才是受壓迫。「國立私立不如兩粒」。
是啦台灣的男工程師確實被壓迫得很慘，但這不代表其他人就比你好啊。壓迫你的是資方，別搞錯敵人了。我知道很多人不會認同，在這裡寫一小段也說服不了人。但我還是想把這篇放上來，希望有人願意讀。
9 Non-Threatening Leadership Strategies for Women
有女上司的人，大概很多都會抱怨上司太強勢吧。女人實在是很麻煩，尤其是老女人。或者你就是那個女上司？這篇文章提出了九個領導技巧，讓女性主管更得人心，不會太具攻擊性。多學著點！
身為女生能力太強就是錯了，沒什麼好說。就算你很厲害，也記得不要讓別人知道啊。
How Not to Offend Men’s Delicate Feelings When Talking About Being Harassed: A 5-Step Programme
反過來，如果在職場受到騷擾，要怎麼處理，才不會傷到男人們的自尊呢？
- 千萬要安靜。不要讓你的受害者角色太明顯。
- 隱藏你能得到的任何好處。
- 避免表達你的感受。你能有什麼感受，大家已經幫你決定好了。
- 語氣很重要。最好聽起來不太確定，不然會被誤解成你自以為。
- 記得強調你只針對那一個人。這是個案。
乖喔，男生就是調皮，偶爾犯點錯無傷大雅。原諒人家，不要那麼情緒化，不要無理取鬧，好嗎？
@yhsiang
Structuring CSS in large projects
CSS 很好寫，但是通常也很難維護。前端領域中，已經有許多人提出各種方式，企圖要解決 CSS 可維護性的問題。像是 OOCSS、SMACSS、BEM。此篇作者根據在 peergrade.io 的經驗提出三個簡單的原則。
- class 命名需要有前綴 (prefix)
- 不要使用巢狀選擇器
- 採用 BEM 命名規則
這邊比較特別的是採用 BEM 命名規則後，可允許 1 層的巢狀選擇器。這樣可以避免重複指定區塊裡面的修改器。
Coding mobile-first emails
如何寫出能適應各種 email client 的模板，一直以來都是設計師或前端工程師的挑戰。本篇作者一步一步教你如何設計出，適合手機上的 email 樣式。
先從手機上的畫面開始設計，簡單的 div 和 css，確保每個 email client 都有支援。而 Margin，注意是大寫的 M，即使是舊版本的 Outlook 也支援這個寫法。
接著使用 media query 製作桌面版本的樣式，這邊用到了 display: table 能讓我們製作出多個 column 的效果。但是這邊有幾個 client 不支援，像是 outlook 和 gmail。
但是對於新的 outlook.com 可以使用 [owa] 的 attribute selector，來讓樣式成功套用在 outlook.com 上。
配合 IE 常使用的 conditional comments 和 table element，遇到 outlook 的時候，就可以 fallback 到 html 的 table 樣式。
最後透過 calc、max-width、min-width 讓 gmail 相關的 client 也可以完美的呈現之前的設計。
width: calc((Desktop Width - Mobile Width) * 100% - (Desktop Width - Mobile Width) * Breakpoint - Desktop Width); 作者提供了一些公式告訴你 layout 或 column 該怎麼計算。使得這個方式能夠修正 gmail 上面的顯示。
用以上的方式，就可以製作出適用各種 client 的 email 樣式，工作上有在製作電子報的朋友，務必花點時間閱讀！
What ORMs have taught me: just learn SQL
ORM 提供了我們一個方便的介面，而不需要學會 SQL，即可從資料庫中取得需要的資料。實際上你還是需要學會 SQL，若是 Object 有許多 attribute，ORM 的遍歷 attribute 就會帶來效能問題。除非你的 data model 簡單到不需要 join，不然 ORM 會讓你花更多時間在理解其產生的 SQL 語法。
ORM 也會造成兩份 schema 維護的問題，作者建議還是放在 DB，然後讀到 Application 裡來用會比較好。針對 identity 和 transaction 作者也有提出見解。最後作者說使用 stored procedures 不見得是壞事，但如果你在使用 RDBMS，最好還是學會 SQL 比較好。
Let’s build a Productivity Timer App with Elm
作者因為接觸了蕃茄時間工作法，以及 Elm。決定要使用 Elm 來開發一套有關計時器的生產力工具。
一開始作者先畫了草稿，並且擬定簡單的 Data model 跟 App message。藉由這樣的 planning，作者感受到了和 OOP programming 不一樣的方式。接著作者介紹他使用的環境跟如何開始一個簡單的專案。
透過 update 函式的撰寫，並一一完成需要用到的函式。確保了 message 跟 model 的功能後。最後再將 view 的部分勾勒出來。就這樣作者很順利地完成了 Elm App 的開發。
有興趣的人可以閱讀一下作者的原始碼，感受一下 Elm 是不是真的很容易閱讀呢？
How to correctly use context.Context in Go 1.7
本篇在教你如何使用 Go 1.7 的新套件 Context。建議先讀完官方介紹和文件。
目前有兩種方式整合進你的 API：
- 當做函數的第一個參數
- request 結構下可選擇的 config
幾種情況正好適合使用 Context
- 不想將東西存進 struct
- 長時間的阻塞操作
有些東西不適合放進 Context.Value (request-scoped values)
- database connection
- logger
文章的後半部都在講解如何正確使用 Context.Value，有興趣的朋友可以仔細閱讀。
This RSS feed is published on http://weekly.codetengu.com/. You can also subscribe via email.