Craftsman-Spirit #9
Welcome to this week’s edition of Craftsman-Spirit, where I share smart ideas for your relentless pursuit of excellence.
edited by @brownylin with 💖 at 2017-11-19
What I’m reading —
tags: #Observability
, #Monitoring
這個推文串還蠻值得 highlight 一下的,@peterbourgon 闡述他對於幾種達成 Observability 手段 (Metrics
, Logging
and Tracing
) 的看法,我深感認同。
系統絕大部份的問題可以透過良好的 metrics instrumentation 來提早發現,如同好的 error handling 一樣,在設計的時候就要把一些 預期/可能 發生的錯誤都透過 metrics 發送出來。
而 logging 通常是在問題發現後用來釐清狀況時使用。換句話說,如果你是透過 logging 在發現問題的話,那代表你的 metrics 做的不夠好,這時候應該回頭補強 metrics。
至於 tracing 我覺得是當模組彼此間的溝通複雜度到達一定程度時才需要引入的手段,有時候單一模組的 metrics 發生異常並不一定代表應該發出 alert (複雜系統中,單一功能往往涉及多個模組的協作)。
這時候,tracing 可以幫助我們視覺化整個流程的時序關係,讓我們可以更快速去定位出問題的環節,而不是自己在腦中把這些 metrics 串成一個故事。
所以,加強系統的可見性 (Observability),依序加強系統的 metrics 和 logging,行有餘力再加上 tracing。
tags: #Observability
, #Instrumentation
![](https://camo.githubusercontent.com/af83c3359c10bcd99eb9f086a7c2563604db9685aa26c6501247b397c22ed7cf/68747470733a2f2f7062732e7477696d672e636f6d2f6d656469612f444c554a51356357344138336a66762e6a7067)
- Monitoring the work is more important than the resources
- Metrics are aggregations of events, and they can be awesome too
- Focus on the most valuable, cheapest, easiest stuff
這篇剛好作為上一篇的補充,要有好的 observability 必然要在系統中添加許多 instrumentation 邏輯。那麼,我們應該監測哪些東西呢?這篇文章裡面有不少寶貴的經驗。
tags: #Design
, #Architect
Coupling measures the spread of a change across elements. Cohesion measures the cost of a change within an element. An element is cohesive to the degree that the entire element changes when the system needs to change.
An element can lack cohesion either by being too large or too small. An element that is too small, solving only part of a problem, will have to be coupled to elements solving the other parts of the problem. Changing the solution will require changing all the elements. An element that solves several problems will only be partly changed. This is riskier and more expensive than changing a whole element because first you need to figure out what part of the element should be changed and then you need to prove that the unchanged part of the element is truly unchanged. Cohesive elements, replaced in total, don't incur these costs
cohesion 原來可以這樣理解啊,一直都覺得這個概念很難描述,原來就是 對 changes 的一種 transaction 啊
One of the things about design that makes it such a joy is that it requires balance. If elements are too large, each change will be more expensive than it needs to be. If elements are too small, changes will ripple across elements
This suggests that the most care should be spent on reducing coupling. This is a bit puzzling as my practice is generally to make more smaller pieces. Perhaps I'm just confident of my ability reduce coupling
不過 cohesion 這種東西真的是人生難題,也是設計之美。可以這樣理解,低耦合其實是系統持續往高內聚演進的一個必要手段。
在需求不斷變動的外在環境下,低耦合的特性可以讓系統內的各個元件獨立的改變以適應新的需求,進而更加確立自己的職責達到高內聚的特性。
tags: #Go
, #Bufio
最近在處理 Go exec 執行 ffmpeg 的 log parsing 剛好有用到 bufio.Scanner
,使用內建的 ScanLines
split func 並沒辦法抓到 fps 和 bitrate 那行不斷 update 的 log,原因是因為這行 log 並沒有用 newline 分行。
之後索性就自己弄了一個客製化的 split func,直接回傳整個也不用 split 了 XDD,目前看起來堪用,然後如果早點看到這篇文章就好惹,哭哭。
The valuable resources —
把自己的東西放在 valuable resources 好像有點無恥,不過本週實在沒有什麼梗只好拿自己的東西來墊檔一下。
工作上有需要作一個 module 利用 ffmpeg 作一些串流 fanout 的任務,因為這個服務要跟我們既有的 infrastructure 整合在一起,所以用 Go exec 在外面包一層會是比較有彈性的方式。
然後又希望這個 Go module 可以接收 ffmpeg 的 output log 作一些 error handling 所以就有了上面這個 gist 囉,有需要的人可以參考看看 XD。
The quotes I’m pondering —
📌 It's not "hard" skills vs "soft" skills - its "technical" vs "professional" skills
OH: It's not "hard" skills vs "soft" skills - its "technical" vs "professional" skills.
— Russell Keith-Magee (@freakboy3742) 2017年9月11日
📌 You are entitled to your own opinion, but you are not entitled to your own facts
“You are entitled to your own opinion, but you are not entitled to your own facts.”
— Daniel Patrick Moynihan
— Shane Parrish (@farnamstreet) 2017年11月11日
📌 We don’t see things as they are, we see them as we are
"We don’t see things as they are, we see them as we are."
Anais Nin#qotd
— Markus Eisele (@myfear) 2017年11月10日
The jokes entertain me —
🤣 AI degradation
When you’re fundraising, it’s AI
When you’re hiring, it’s ML
When you’re implementing, it’s linear regression
When you’re debugging, it’s printf()
— Baron Schwartz (@xaprb) 2017年11月15日
🤣 Move fast and break things (if you can fix after)
Pro-tip to developers: only “Move fast and break things” if you’re confident you can fix things after you’ve broken them ...
— Duncan Doyle (@DuncanDoyle) 2017年11月12日
That’s all!
I’ll see you next week, Browny