Code Monkey home page Code Monkey logo

craftsman-spirit-letter's Introduction

craftsman-spirit-letter's People

Contributors

browny avatar ikala-browny avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar

craftsman-spirit-letter's Issues

Craftsman-Spirit weekly #1

Craftsman-Spirit #1

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-09-25

What I’m reading —

🔖 Isaac Asimov: How to Never Run Out of Ideas Again

艾西莫夫是一位超級多產的科幻作家,其一生創作產量假設以每兩週就能完成一本小說的速度來計算,要連續 25 年都維持這樣的速度才有可能達到 😱。是什麼秘訣讓艾西莫夫如此多產呢?作者從他的自傳當中找到了一些線索。

總結:多領域的涉獵和閱讀,不要被一時的靈感空乏所阻礙,隨時保持多線的產出,不要一次就追求完美到位,然後不斷的努力產出。希望這個週報也能秉持著這樣的原則前進 🤘

🔖 25 Ways to Demonstrate Technical Leadership

Senior 之所以為 Senoir 我覺得除了技術和經驗外,最重要的就是 leadership 惹。但是 leadership 這個概念 hen 抽象的。之前有篇中譯文相當的火: [翻譯]領導專案走向成功的資深工程師之路。而這篇 Linkedin 更是洋洋灑灑列出了 25 點,真希望我早點知道這些,也許就已經當上 CTO 了呢 😅

🔖 Write the Docs

最近專案步調比較沒這麼緊湊,想說來幫之前的 project 補上文件。過程中,忽然一股巨大的疑惑浮上心頭:到底要寫出一份好的 technical document 需要具備哪些條件,有哪些 practices 可以參考?

於是決定來好好 survey 研究一下,在軟體設計領域:需求文件、業務文件、模組文件、開發者文件等等⋯一大堆的文件,到底該怎麼寫比較好,有沒有一些準則可以遵循。於是乎找到上面這個蠻有意思的網站,原來這個世界上是有一群很在意文件的人而且還組成了一個社團甚至還有 conference,真是太有意思啦。等我把這個主題好好研究完再來發布一篇 blog,敬請期待 ~

🔖 我是如何學習區塊鏈的

最近對 digital currency 有點興趣,這篇文章不僅整理了一些相關的學習資源,還分享了作者自己的一套學習方法框架:目標導向,結構化知識的產出,和我最近看完的一本書躍遷當中提到的還挺像的。

🔖 拋開命令驅動,採用事件驅動方式構建服務

Event driven design 其實就是在模組溝通層面的依賴反轉,在 microservies 的架構趨勢下,模組間的溝通成了複雜度的主要來源,事件驅動就成了配方良藥。Command 和 Event 其實不太陌生,不過文中還提及了 Query 的概念 (重要的是,查詢操作沒有副作用,它們不會改變系統的狀態),其實就是所謂的 CQRS 架構模式,講解的相當清晰好懂。

The valuable resources —

🔦 [movie]《還有機會說再見》Before I Fall 2017 (無雷)

整體來說屬於心靈雞湯類型的片,要你好好把握每一天。所以對於劇中的邏輯要求可能標準不要太高,不然會很容易出戲 (我就有好幾次黑人問號的 moment)。10 分來說給 6 分。

🔦 [tool] rg3.github.io/youtube-dl/

youtube-dl 顧名思義可以把 youtube 上面的影片抓下了,除此之外針對 live 還有一些蠻有趣的指令:

// 列出某個直播的串流資訊,會輸出各解析度的 format id
youtube-dl --list-formats <youtube_url>

// 透過 format id 可以取得該 live 的 m3u8 檔案 (ex: format id = 95)
youtube-dl -f 95 -g <youtube_url>

// 就可以用 vlc 或 ffplay 直接看 youtube live
ffplay $(youtube-dl -f 95 -g <youtube_url>)

The quotes I’m pondering —

📌 最近開始接觸 Ruby on Rails 很有感 😅

Why do #golang developers prefer libraries over frameworks? Because they prefer composition over inheritance.

— Cap'n Dave (@davecheney) 2017年9月19日

📌 其實很多概念都是人類自己定義出來的,譬如時間,愛因斯坦之所以那麼偉大就在於他能夠跳脫出這個邊界

我們發明了邊界,最後發現自己被困其中

— brownylin (@brownylin) 2017年9月15日

The jokes entertain me —

🤣 最近 hen 夯的 IT

It works on my computer (color version)https://t.co/HNWgawAEpf#ITMovie #softwaredevelopment #sysadmin pic.twitter.com/SM1KtrmKvl

— turnoff.us (@turnoff_us) 2017年9月20日

🤣 下面的推文超好笑 der。♫ 想回到過去 ~ 試著讓故事繼續 ~ ♫

git bisect but for figuring out where you went wrong in life

— angus✨ (@angustweets) 2017年9月21日

If only I had taken the time to write meaningful commit messages

— Rob Colburn (@robcolburn) 2017年9月22日

Probably at `git init`.

— aido (@aidenbenton) 2017年9月22日

Craftsman-Spirit weekly #13

Craftsman-Spirit #13

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-12-17

What I’m reading —

🔖 Architecture As Journey

tags: #SoftwareArchitecture #Metaphor

A good architecture comes from understanding it more as a journey than a destination, more an ongoing process of enquiry than a frozen artefact

「架構」一詞在軟體開發中的本質到底是什麼,顯然他是從其他領域借來的詞。字面上理解起來像是「結構化」。但是在實際的軟體開發過程,他的意涵遠遠超過了這個範疇。

本文有許多有意思的引言:從其他領域切入,用隱喻的方式來理解架構在軟體開發中的各種面向,讓人更具象的理解「架構」的本質。

This is the monstrosity in love, lady, that the will is infinite, and the execution confined; that the desire is boundless, and the act a slave to limit.

— William Shakespeare

瞧瞧,莎士比亞也跟架構有關係的 ~

🔖 I have people skills

tags: #Career #Communication #SoftSkills

Here's a list of required skills mentioned in a random software engineer job posting ...

Note how specific they are about the engineering skills. On the other hand 「strong communication skills」 is… all the same. Which is rather ridiculous ...

What are those 「communication skills」 we want? I decided to take 5 minutes and try to list as many as I can :)

好工程師不僅硬實力要堅強,軟實力在現今高度協作的社會也不可或缺。但是,幾乎所有軟體工程師的職缺描述當中,對於軟實力這塊,經常就只有單薄的幾句描述:

The candidate is expected to have strong communication and interpersonal skills, high motivation, ability to learn quickly, and must be a self-starter.

這種像是公民與道德考題的描述,大多數人都會覺得自己符合要求吧...。作者認為看待軟實力應如同我們鉅細靡遺的看待技術需求一樣,將軟實力所應該包括的技能給一一條列出來。

做為檢視自己軟實力的部分,相當具有參考價值。對於招募端來說,也可作為具體考察的準則。

The valuable resources —

🔦 5 Ways To Enhance kubectl UX

gcloudkubectl cli tool 是小弟每天吃飯的傢伙,但是總是有更有效率使用他們的方式。參考一下這幾個工具吧。

🔦 [Mac] jigish/slate: 可高度客製化的視窗管理工具

之前一直是使用 Spectacle 這套,今天發現 slate 的功能更加強大且可程式化 (可以透過自訂組態檔 .slate 達成高度客製化的視窗管理行為),而且也是免費的,立馬就轉換過去了,推薦給大家。

The quotes I’m pondering —

📌 Design depends largely on constraints — Charles Eames

That’s all!

I’ll see you next week, Browny

Craftsman-Spirit weekly #15

Craftsman-Spirit #15

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-12-31

這是今年最後一刊啦,在這邊預祝各位 2018 新年快樂。Craftsman-Sprint 在 2018 也有個小小心願,就是不中斷發刊直到 2019 啦,希望大家都收穫滿滿 ~

What I’m reading —

🔖 Introduction to modern network load balancing and proxying

tags: #Infrastructure #LoadBalancing

這真的是我讀過對於 Load Balancing 主題講述的最詳盡最全面也最跟的上時代 (廢話,才剛發布不久...) 的一篇文章啦!

作者是 Envoy 的主要 contributor Matt Klein,是 service mesh 架構領域蠻著名的人物。本文從基礎概念開始,推展到 L4 / L7 LB 的優缺點比較,並且列舉了一些常見的 LB topologies,最後引入的 sidecar proxy 的概念,並指出其將是未來設計的趨勢。

🔖 Naval Ravikant on Reading, Happiness, Systems for Decision Making, Habits, Honesty and More

tags: #Podcast #Wisdom

因為下面這則推文所以我就聽了這個 podcast,是一個一對一的深度訪談,訪談對象是 Naval,一查之後發現是一個相當有來頭的人 (AngelList 的 CEO)。

I can't say how much I enjoyed @farnamstreet's podcast discussion w/ @naval. Don't miss it. Deep stuff. https://t.co/3Xv0HqLTNf

— Jonas Bonér (@jboner) 2017年12月27日

訪談涉及面向極廣,談閱讀、決策、習慣養成、人生觀、幸福觀等等...,我覺得相當適合在年底的時候,了解一下這些奇葩的人是怎麼看待這個世界、看待這個人生的。另外也發現 Farnam Street 是一個很優質的 blog 呢!

🔖 Bitcoin, Ethereum, Blockchain, Tokens, ICOs: Why should anyone care?

tags: #DigitalCurrency #Bitcoin

上週跟大家分享了一篇從 Bitcoin 了解金錢的運作方式一文。今天這篇則是在技術面上帶大家了解 Bitcoin, Ethereum, Blockchain, Tokens, ICOs 這些當紅的名詞背後的意涵 (透過什麼方式解決了什麼問題)。

除了技術面的介紹相當淺顯易懂之外,作者從市場面的角度剖析區塊鏈/數位貨幣:這些技術解決了什麼問題、仍然存在什麼樣的挑戰、可能有怎麼樣的應用、要如何普及和擴散

在一個比較高的層次上了解區塊鏈/數位貨幣帶來的改變,我覺得對於感興趣的開發者或是投資者都相當有幫助。

The quotes I’m pondering —

📌 Culture is shaped by what you reward as much as what you hire for

It is great to see this recognized but, as of ~2 years ago this attitude was not prevalent in promo committees. Culture is shaped by what you reward as much as what you hire for.

— Joe Beda (@jbeda) 2017年12月26日

That’s all!

I’ll see you next year, Browny

Craftsman-Spirit weekly #9

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 —

🔖 Observability: Metrics -> Logging -> Tracing (in that order)

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。

🔖 Instrumenting systems for arbitrary observability

tags: #Observability, #Instrumentation

  • 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 邏輯。那麼,我們應該監測哪些東西呢?這篇文章裡面有不少寶貴的經驗。

🔖 Coupling and Cohesion

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 這種東西真的是人生難題,也是設計之美。可以這樣理解,低耦合其實是系統持續往高內聚演進的一個必要手段。

在需求不斷變動的外在環境下,低耦合的特性可以讓系統內的各個元件獨立的改變以適應新的需求,進而更加確立自己的職責達到高內聚的特性。

🔖 In-depth introduction to bufio.Scanner in Golang

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 —

🔦 Capture ffmpeg output when executed by Go os/exec pkg

把自己的東西放在 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

Craftsman-Spirit weekly #3

Craftsman-Spirit #3

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-10-08

What I’m reading —

📹 Ways To Do Things - Peter Bourgon

tags: #Go, #Orchestration

利用 channel 讓 goroutines 彼此協作是 Go 語言處理 concurrency 的優美設計。講者從一些常見的 goroutines 協作模式切入,探討了這些模式的缺點,根據自己的經驗提出幾個改善的方式。除了具體的模式實現細節之外,講者怎麼看待不同模式帶來的優缺點我覺得也很值得學習。

🔖 Monitoring in the time of Cloud Native

tags: #Monitoring, #Observability

「監控」實在是 Microservices 架構下一個非常重要的課題 (我甚至覺得是最重要的課題)。隨著系統成長,模組之間的溝通越來越複雜,傳統的 Monitoring (監控) 思維已經不敷使用,而有必要引入新的思維 Observability (可見性)。

Monitoring 讓我們對預期發生的錯誤做出實際的警示,但當系統複雜到一定程度,我們面對的大部分問題是:我們不知道我們不知道什麼 (Unknown unknowns)

這類問題發生的時候,僅靠傳統的 Monitoring 方法,很難快速找到問題的癥結點。所以,好的 Observability 成為 Microservices 不斷往前的一項必備條件。

文中分析了 loggingmetricstracing 三種達到 Observability 的手段:logging 紀錄事實,metrics 探測模組隨著時間的變化,tracing 則告訴我們 business logic 在各模組間的流動。他們解決了什麼問題、實際應用時會遇到的難點,等等...文中都有相當深入的探討。

檢視自己目前所屬團隊中,logging / metrics / tracing 其實都有用上。只是 tracing 的部分算是自己土砲的:各 module 遵循自訂的 trace protocol 然後以類似打 metrics 的方式實現。我想等之後 service mesh 漸漸成熟後再來引入更全面的 tracing 應該會容易許多。

🔖 In Six Seconds, Giphy Could Make Billions

tags: #Gif, #Idea

最近越來越常看到 twitter 上充滿搭配 gif 的推文,配合好的話真的 hen 傳神。我就在想這些人去哪找到這些這麼搭的 gif。

後來發現,twitter 本身的發文就有 gif 選項可以選,嘗試了一下搜尋功能,輸入一些比較語意的 term 沒想到找出來的 gif 都還蠻搭配的,實在是相當厲害,不知道這方面是怎麼標記的。

也剛好看到 GIPHY 這個 gif 分享和收集的網站,短影片看來已經成為數位廣告的兵家必爭之地,這種佔據語意渠道的模式是不是可以轉為廣告獲利呢,我是覺得機會還蠻大的!

The valuable resources —

📹 四分衛 - 十月病

入秋了,點播一首小奎哥推薦的十月病 ~

沒有輪廓 失去重量的每一天
侷限在框框之中
像條乾掉的河流
遼闊的十月
荒涼的十月

The quotes I’m pondering —

📌 Design until you feel you understand the problem. Write code until you realize you don't.

Channeling some beautiful honesty here by @jessitron at #GOTOcph pic.twitter.com/DUv7pw4S2d

— Russ Miles (@russmiles) 2017年10月2日

The jokes entertain me —

😆 「請問對方辯友,世界上有沒有絕對的事物?」「沒有」「絕對沒有嗎?」

“请问对方辩友,世界上有没有绝对的事物?”“没有”“绝对没有吗?”

— 学术状态帝 (@xueshudi) 2017年10月3日

😆 Software is never finished

Software is never finished 😉 by @Dilbert_Daily #DevOps #developers #software #agile #comics pic.twitter.com/A8OuNlPMBl

— Sara Chaoui (@schaouii) 2017年10月3日

Craftsman-Spirit weekly #14

Craftsman-Spirit #14

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-12-24

What I’m reading —

🔖 What Bitcoin Shows Us About How Money Works

tags: #DigitalCurrency #Bitcoin

  • Bitcoin could one day supplant ordinary currency
  • The decentralized / algorithmic nature of Bitcoin makes it safer than 「normal」 currency
  • Bitcoin is like gold, and gold is good for counting wealth, therefore Bitcoin is good for counting wealth.

For Bitcoin, the problem is similarly that the number of bitcoins is fixed, and not connected to the total utility of all the goods and services that need to be counted.

So here lies the fundamental difference between the dollar and Bitcoin: The supply of bitcoin is fixed, but the demand is beholden to uncontrollable market forces and speculator whims. That means that unlike the dollar, the value of BTC can never be stable, because there is no means regulate the supply to keep the value consistent from moment to moment.

伴隨著比特幣最近雲霄飛車般的上上下下,周遭越來越多朋友開始關注數位貨幣。剛接觸數位貨幣的朋友經常內心會有一些疑惑:比特幣到底是什麼他跟法定貨幣有什麼差別如果比特幣真的像說的那麼好,未來會不會取代貨幣? 甚至,到底比特幣是不是好的投資標的

那麼,我推薦大家讀一下這篇深入淺出的文章。本文先帶大家了解了什麼是貨幣、貨幣的價值從合而來、貨幣的價值如何反應市場供需,接著才帶出比特幣,一一檢視其特性,並和貨幣作比較。很適合給想要入門投資比特幣的朋友作為背景知識。

🔖 給新手的以太坊介紹

tags: #DigitalCurrency #Ethereum

到目前為止,大多數人都認為以太坊是第二大有價值的加密貨幣,目前價值超過600億美元。然而,以太坊實際上並不是一個加密貨幣 - 它是一個讓程式設計師在區塊鏈技術之上建構應用程式的軟體平台。在以太坊平台中,是一種被稱為 ether 的加密貨幣,用於為以太坊區塊鏈上的應用程式提供動力。

以太幣的功能比數位貨幣更像數位商品。就像你需要汽油來加油,你需要比太幣在Ethereum區塊鏈上運行應用程式。適用於石油和天然氣等商品的供應/需求經濟學也適用於以太幣。石油是有價值的,因為它為我們在日常生活中使用的許多東西提供動力。依靠以太坊應用的人和企業越多,對以太幣的需求就越高,從而增加其價值

不要把以太坊以太幣搞混囉 ~

🔖 12 Signs You’re Working in a Feature Factory

tags: #ProductManagement #SoftwareDevelopment

你覺得每天的工作就是不斷的 deliver features 嗎?你任職的公司是用 feature 產出來衡量績效嗎?

feature 產出數量的確和付出的勞力和心力成正比,但是未必會和公司/個人的成功成正比,所以如果單看 feature 來衡量公司成長 就如同 用程式碼行數來衡量一個工程師的貢獻一樣。

這十二個徵兆,很多都有蠻強的既視感,需要時時刻刻提醒自己。不論從管理或是開發的角度來看、公司或個人的發展來看,都是很有參考意義的指標。

The valuable resources —

🔦 [Mac] Coin Tick - Menu Bar Crypto

The quotes I’m pondering —

📌 Exploiting Unrecognized Simplicity

Most geniuses - especially those who lead others - prosper not by deconstructing intricate complexities but by exploiting unrecognized simplicities.

  • Andy Benoit

The jokes entertain me —

🤣 Guide to job postings

Your definitive guide to job postings. In my experience, this is still pretty accurate. pic.twitter.com/kgIf3R44EE

— Cory LaNou (@corylanou) 2017年12月19日

That’s all!

I’ll see you next week, Browny

Craftsman-Spirit weekly #10

Craftsman-Spirit #10

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-26

What I’m reading —

🔖 Cohesion - understanding by the word's etymology

tags: #Design #Architect

寫扣的人對 coupling 應該都不陌生,硬凹也說的上幾句,但是對 cohesion 就不一樣惹,總有一種似懂非懂的朦朧美感,說不上來。

作者推論這是由於這個字的字義比較隱晦一些,大家比較難用日常生活常見的概念來理解。所以本文透過探尋 cohesion 這個字的來源帶領讀者領略其意涵。讀完之後,真的覺得這個名字很傳神啊 ~

The valuable resources —

🔦 BurntSushi/ripgrep: 超級快的 grep

一直以來都使用 The Silver Searcher (ag) 作為全域搜尋的工具。今天介紹這款 ripgrep (rg) 跟 ag 一樣好用,而且更快!

實際使用後真的快的驚人,立馬換上,人生又省下了不少時間。

🎶 陳奕迅 - Baby Song

我為我將對你撒的謊先跟你道歉
當你發現黑白不是那麼的分明
世界不是那麼的公平
別太失望
我講的是個夢想

不用太聽我們的話
不要讓任何人告訴你
你該怎樣對待世界
或它該怎對你
要跟現在一樣隨心

最近多了一個 father 的身分,朋友會問當了爸有什麼感想。老實說,沒有什麼太特別的,但我想到了 peter principle 的一句話:「In a hierarchy every employee tends to rise to his level of incompetence」。我隱約感覺,孩子的出現正引領著我去認識更深層的自己。

凝視著他,彷彿搭著時光機回到過去看著小時候的自己,如果可以,我會給那時的自己怎樣的忠告。謹慎謹慎,每個人都是這個世界上獨一無二的個體,我想告訴並教導你的,就是傾聽你的心,忠於自己。謝謝奎哥,分享這首歌給我 ~

The quotes I’m pondering —

📌 We can be truly successful only at things we are willing to fail at

We can be truly successful only at things we are willing to fail at.
https://t.co/IPXKr0uQsV

— Carmen H. Andoh (@carmatrocity) 2017年11月21日

The jokes entertain me —

🤣 Machine Learning

Machine Learning: pic.twitter.com/3mPZWQhUAn

— Shawn Wildermuth (@shawnwildermuth) 2017年11月20日

🤣 程序員 = 理論和實戰的結合 = 藝術

"Theory is when you know something, but it doesn’t work. Practice is when something works, but you don’t know why. Programmers combine theory and practice: Nothing works and they don’t know why." - Unknown

— Programming Wisdom (@codewisdom) 2017年11月24日

That’s all!

I’ll see you next week, Browny

Craftsman-Spirit weekly #2

Craftsman-Spirit

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-10-01

What I’m reading —

🔖 AI is the new electricity

tags: #MachineLearning, #AI

監督學習、遷移學習、非監督學習、強化學習這四類算法所創造的經濟效益是遞減的。除了遊戲和機器人領域之外,要把強化學習應用到商業和實踐中還有很長的路要走。

以後聽到那些未來 AI 世界的想像可能要先打個折扣了,目前大多數創造效益的 AI,仍舊需要很多工人的輔助。

機器學習依靠結構化數據,比非結構化數據創造了更多的經濟效益。公司的壁壘不再是算法,而是數據。

傳統科技公司 + 機器學習/神經網絡 ≠ AI公司。我認為,AI公司傾向於策略性地獲取數據

數據才是決勝的關鍵而非算法,文中提到一個蠻有意思的觀點。

講者提出會為公司建構一個循環 (Data -> Product -> User -> Data):收集數據然後推出產品,產品有了 user 以後又會產生更多的數據用來更好的優化產品,進而吸引更多的 user。

能夠找到滿足這樣正向數據積累迴圈的項目,就是好的 AI 公司。

🔖 How to be interesting

tags: #Marketing, #Creativity

這篇的標題下的實在有點大,其實內容講述的是研究者想要探究那些在 Youtube 上面爆紅而被瘋傳的影片、那些被認為很有趣的影片,背後到底隱藏了什麼秘密,有沒有什麼特定的 pattern。答案是有的:

interesting' not because it tells them some truth they thought they already knew, but instead because it tells them some truth they thought they already knew was wrong

有趣的事情經常是那些推翻我們視為理所當然的論述,也就是一種反差,一種 surprise 的 feeling。也許這樣的技巧未來也可以融入週報的寫作或是上台的演講。

不過,這篇文章提出的觀點其實並沒有推翻我原本認為理所當然的事情啊,所以他也不能算是有趣的吧 😅

🔖 Golang在Kubernetes語境下的編程範式 (投影片)

tags: #Kubernetes, #Golang

這篇蠻有料的分享,一開始從 k8s 為什麼選擇 Golang 切入,接著簡單、直白、好懂地介紹了一遍 k8s 的一些主要抽象概念 (像是: Pod, Service, Ingress, Deployment, 等等...)。最有趣的是,文中剖析了一些 k8s 的編程範式,對於理解 k8s 內部如何運作相當有幫助。

🔖 Burn Rate 101 for Startups: A 15-Min Introduction

tags: #Startup, #Entrepreneurship

自己目前也算是在 startup 的世界努力著,雖然職稱是 Engineer 但是了解一些基本的 business concepts 還是有幫助的。「有人用的技術才是好技術,能為團隊、公司帶來成長的投資才是好投資」,所以一些基本衡量 startup 是否成功的指標,我們還是有需要來給他認識一下。

BurnRate (燒錢的速度) 和 Runway (錢花光的那天) 算是最基本的兩個衡量指標;如同軟體開發中的 HumanMonth 和 Deadline。為什麼估時會這麼的困難,其中一根本原因在於我們只能基於目前的狀況對未來做出預測,而這個目前狀況通常是會改變的。文中提到 SaaS 型態的產品,初期通常 burn rate 會較高,基於會計原則,收入會分攤在客戶簽約的期間,但是支出卻是認列在交付的當月。

Software-as-a-Service (SaaS) companies face the unique challenge of having to spend large amounts (perhaps all of their) money on acquiring customers before they can re-claim that cost in the form of revenues and thereby generate profits

Many of these up-front expenses don’t get recognized over time in the income statement and therein lies the rub: The timing of revenue and expenses is misaligned

這又讓我聯想到軟體開發中的重構,初期投入的成本要隨著時間其價值才會陸續顯現。其實道理是相同的,都是 trade off,既要保守的評估自己的 burn rate 可以支撐多久,又要積極的去思考怎麼要投入能夠產生更長遠而能夠累積堆疊的效益。

「長期戰略需穩健,短期戰術需敏捷」,我想在軟體開發也一樣適用吧。

The valuable resources —

🔦 [mac] BitBar - Put anything in your Mac OS X menu bar

可以在 Mac 的 menu bar 放進任何東西 (只要你會寫 shell script)。也有一些別人寫好的 plugins 可以用。目前我有在用的是:pomodoro(番茄鐘)、nowplaying(可以顯示 spotify 正在聽得曲目)。

The quotes I’m pondering —

📌 Everything is nothing, nothing is everything

這句話看似是個 infinite loop,但是人生何嘗不就是如此。其實道理很簡單,就是 everything is everthing 這樣多對多的博奕取捨。我們要走過多少道路,要多麼認識自己才能跳脫如此人生的歧義。

"everything is nothing, nothing is everything" - via https://youtu.be/crt-tc9rScM

📌 只有笨到以為自己可以改變世界的人,才能真正改變世界

我以前很喜歡一句話,還把他放在部落格副標題:
只有笨到以為自己可以改變世界的人,才能真正改變世界

— Pellaeon Lin (@Ellaeon) 2017年9月26日

📌 階段是心境,放下是心情

credit to a good friend JD

The jokes entertain me —

🤣 如何讓你的文案看起來有深度?

這實在太好笑了 ~ 好像也適用在簡報領域 XDD

我們要瞭解為什麼我們寫的是淺案,而不是他們心中的深案?
其實原因很簡單,因為他們看得懂。

Craftsman-Spirit weekly #7

Craftsman-Spirit #7

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-05

What I’m reading —

🔖 WTF is The Blockchain?

tags: #Blockchain, #Bitcoin

相當淺顯易懂的一篇科普文,要是有人問你 什麼是比特幣什麼是區塊鏈,可以用這篇文章的思路跟他解釋解釋,讓他好好感受一下。(ETH 怎麼不趕快起飛呢 XDD...)

🔖 The Web began dying in 2014, here's how

tags: #Web, #Internet

從這篇文章中驚人的發現,原來當今世上幾乎七成的網路流量集中在 Google 和 Facebook 兩家公司手上。網路三巨頭 GOOG, FB, AMZN 正在慢慢擴大特定領域的壟斷,過去 Web 多樣、開放、中立的特性已不復存在。

人工智慧、社交、電商都朝著直接跳過 Web 的方式在堆砌各自的競爭壁壘。人因有選擇而自由,但 Web 正在漸漸凋零,我們正在拱手讓出手上的自由?

🔖 Understanding kubernetes networking: Pods

tags: #Kubernetes, #Networking

清楚解釋了 k8s 在 Pods 抽象層的 networking 實作,推薦這種 scope 清晰又見樹見林的好文。

🔖 Queueing Theory

tags: #Optimization, #Performance

Really great slide deck. Anyone running production servers should be familiar with the basics here. https://t.co/wIP13hK4eI

— Russ Cox (@_rsc) 2017年11月2日

來自 Russ Cox 大大的推薦,最近剛好在弄 stress testing 的 tasks,獲益良多。如何有效率的去理解甚至進而優化系統的效能,靠的不是亂槍打鳥的 loading test,而是對系統的理解進行建模然後驗證,如此迭代下去找出正確的模型

The valuable resources —

🔦 Go design patterns - Curated list of Go design patterns, recipes and idioms

老實說自接觸 Go 和實際寫了兩三年的經驗來看,好像沒有印象有用過什麼 design patterns ... XD

The jokes entertain me —

🤣 What's the difference between AI and ML?

"What's the difference between AI and ML?"

"It's AI when you're raising money, it's ML when you're trying to hire people."

— Will Wilson (@WAWilsonIV) 2017年11月1日

🤣 RAM

1969:
-what're you doing with that 2KB of RAM?
-sending people to the moon

2017:
-what're you doing with that 1.5GB of RAM?
-running Slack

— I Am Devloper (@iamdevloper) 2017年11月3日

🤣 雙 11 最該打折的是什麼?

pic.twitter.com/zcnFY5Qh3S

— 萌萌宝儿(*≧ω≦) (@amberqaq) 2017年11月3日

That’s all!

I’ll see you next week,
Browny

Craftsman-Spirit weekly #11

Craftsman-Spirit #11

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-12-03

What I’m reading —

🔖 Running in Circles - Why Agile Isn't Working and What We Do Differently

tags: #Agile #ProductManagement

People in our industry think they stopped doing waterfall and switched to agile. In reality they just switched to high-frequency waterfall.

敏捷開發透過不斷的迭代,小步快跑的精神,成為近年新創團隊的主流協作模式。本文指出,迭代快速並不代表 shipping 快速。如果你發現跑了 sprints 後但是 shipping 的速度並沒有改善,那可能掉入 high-frequency waterfall 的陷阱中。

除了快速迭代,作者列出三點需要注意:

  1. Deliberate resource allocation (深思熟慮的資源配置)
  2. Mutable requirements (彈性的需求)
  3. Uphill strategies (爬坡策略的估時方法)

其中第三點的形容我覺得相當貼切,時程掌控一直是很難拿捏的一環,作者以爬坡取代直線來比喻時程估算,分為上坡 (Discovery) 和下坡 (Delivery)。

前半段主要是釐清所有 uncertainties,這段過程本來就是不確定的,所以就需要搭配 1., 2. 來保持彈性;而能夠比較準確估時的是下坡的部分。

我想這對 PM 和 RD 兩端都有所啟發。PM 排定時程要考慮上坡段的不確定性,結合組織目標和項目優先序做出彈性的時程規劃;RD 在具體投入實作之前,應先以較高的視野檢視需求所涉及的各個元件和可能遭遇的問題。

🔖 We are All Product Owners! An Impact Guide for Engineers

tags: #ProductManagement #Impact

經常聽到的一種抱怨就是付出和回報不成比例,覺得自己做的 features 很多、解的 bugs 很多,但升遷和加薪還是讓你不滿意?

這篇文章舉了兩類公司為例 「ship company」和「impact company」,ship company 是以你產出了什麼做為績效指標,而 impact company 則是用你帶來了什麼影響做為績效指標。ship company 曾經是 500 大企業之一,如今已經不復存在;而這間 impact company 叫做 Facebook。

在技術上追求卓越自然是工程師的根本,但如果你在一家公司工作並且希望公司成功,那麼除了技術卓越以外,應該時時檢視自己所做的事情是否為公司帶來正面的影響力。這篇文章提供的具體的指導原則。

🔖 SVE: Distributed video processing at Facebook scale

tags: #VideoProcessing #Scalability

The central idea in SVE is to process video data in a streaming fashion (strictly, mini-batches), in parallel, as videos move through the pipeline

了解一下 facebook 怎麼平行處理大量的 videos 來應付每日數以億計的流量。

The valuable resources —

🔦 caskroom/homebrew-cask

原來 brew 也可以安裝 GUI macOS applications 啊 ~

The quotes I’m pondering —

📌 Understanding the tradeoffs and being able to explain them

Good engineering is less about finding the "perfect" solution and more about understanding the tradeoffs and being able to explain them.

— JBD (@rakyll) 2017年12月1日

📌 Simple is not easy. Simple looks easy

Good engineering is about taking complexity and making it simple. Simple is not easy. Simple looks easy.

— JBD (@rakyll) 2016年9月20日

That’s all!

I’ll see you next week, Browny

Craftsman-Spirit weekly #12

Craftsman-Spirit #12

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-12-10

What I’m reading —

🔖 Technical Decision Making

tags: #SoftwareDevelopment #EngineeringManagement

技術決策很難,好的技術決策,更難。本文 review 了技術決策常遇到的誤區,不可不慎。

  1. Solve the wrong problems (技術決策先決條件是去發現真正待解的問題)

    Technical decision making isn't so much about which tool to pick than what problem to solve

  2. Prioritization of tip of the iceberg problems (有時候問題藏在 Unknown unknowns,不要因為釘子看起來很好釘就拿鐵鎚先敲他)

    The easy thing to do is solve the most 「visible」 problem, when the real problem is lurking beneath the surface. I call this the 「tip of the iceberg」 approach

  3. Pattern Matching (注意 context,同樣的問題在不同公司/團隊有不同的解法考量)

    Oftentimes the easy thing to do is convincing oneself that a solution that worked for another organization facing similar problems is the best solution for the problem at hand

  4. The Swiss-Army-Knife Conundrum (做一件事,並且把他做好)

    Good solutions, for the most part, are optimized for solving only just the problem that really needs solving

  5. Collateral increase in overall complexity (解法所附帶增加的整體系統複雜度需要取捨)

    While solving problems, one of the most difficult challenge lies in choosing solutions that reduce the overall complexity. This becomes even more difficult with the normalization of 「big-company complexity」 that's underway currently, at least in the infrastructure space

  6. Passion projects (用 impact 去衡量每個決策)

    in order to justify a new project, the engineer proposing the project is required to furnish enough evidence about how the project will be impactful

  7. Not failing fast enough or failing well (不要把雞蛋放在同一個籃子裡)

    Or in other words, to plan projects in such a way that no subproblem can become the single point of failure

🔖 How Slack hooks users through artificial urgency

tags: #Slack #Productivity

What lures people to Slack in the first place is its ability to manufacture an artificial sense of urgency. There's no option to send a message on Slack in such a way that says 『no need to stop what you're doing, but could you please deal with this at some point?』

每天都在用 slack,原來他是生產力殺手!而且還會讓你產生很有生產力的幻覺...太恐怖啦,決定定時 check slack 就好 ಠಠ

🔖 Error handling in Upspin

tags: #Golang #ErrorHandling

初接觸 golfing 的時候,你也許會覺得他的 error handling 有一點囉唆,有一點弱。但若理解到 Errors are values,就可以透過編程來客製化以符合自己的錯誤處理需求。

Rob Pike 將自己在開發 Upspin 的錯誤處理經驗分享出來,透過這篇,更能夠了解到 error 設計之簡。error 並不是什麼特別的型別,他就是個簡單的 interface,他和程式當中的其他 primitives 一樣,可以結構化、可以抽象化,讓 error handling 按照你所需要的那樣去行為。

🔖 How we are solving the biggest issue of conversational assistants: Data

tags: #AI #Chatbot

這是一篇介紹語音智能助理的文章,簡單地鋪陳解釋其背後所涉及的技術。並斷言,未來會有越來越多垂直領域的語音智能整合進各式各樣的裝置。

數據智能驅動的產品會遭遇最困難的挑戰就是「雞生蛋、蛋生雞」的問題:沒有足夠的訓練資料就沒有好的智能表現、沒有好的智能表現就沒人要使用,也就收集不到更多數據。所以 snips.ai 提供了「Data Generation as a Service」的服務:利用少量資料,就可以幫你合成出用於 training model 所需要的大量變異資料 (太神奇啦)。

「描述你想要完成什麼,而不是你如何達成他」,在程式語言中不是什麼 new idea。但是要具體落實到生活周遭的裝置,也許就差這最後一哩路了。老實說,我也很不想再看產品說明書了 (最近看很多 baby 用品的說明書感到悲催)

The valuable resources —

🔦 Typora — a minimal markdown editor, markdown reader

最近從 MacDown 換到 Typora 這套 markdown editor,質感倍增,整個寫作的心情都來惹 (但寫作的時間好像越來越少惹)

That’s all!

I’ll see you next week, Browny

Craftsman-Spirit weekly #6

Craftsman-Spirit #6

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-10-29

This week’s outputs -

✍️ Testing with Concurrency in Go

tags: #Go, #Testing, #Concurrency

10/24 在 GTG#28 分享了一個主題 **「Testing with Concurrency in Go」**的 lightnig talk (video)。

探討在測試 concurrent code 時面臨的兩個挑戰: 1. Finishement uncerntainty (不可預測的結束時刻) 2. Real time dependent (對於真實時間的依賴),以及其相應的解決方法。

What I’m reading —

🔖 Scaling your API with rate limiters

tags: #API, #Reliability

Rate limiting is one of the most powerful ways to prepare your API for scale. The different rate limiting strategies described in this post are not all necessary on day one, you can gradually introduce them once you realize the need for rate limiting.

Rate limiting 是維持系統可用性穩定性的一個常用技巧,但是要用什麼樣的 metrics 來設定 threshold 則是個經驗活兒。本文深入淺出整理了幾種在 production 環境中可以循序使用的 rate limiting 技巧,值得參考收藏。

🔖 站立會議經驗亂亂彈

tags: #Agile, #Meeting

開站立會議時, 需要回答三個問題: 我昨天做了什麼, 我今天打算做什麼, 我遇到什麼問題. 前兩者比較算是流水帳的問題. 通常, 與會者會覺得站立會議無聊, 最主要是參加的人都是提供流水帳, 那當然無聊. 你要回答的是跟別人有關的資訊. 像是我昨天做了什麼, 是跟其他人有關的. 或這是我天打算做什麼, 是跟其他人有關的.

敝司 RD 團隊也跑 daily standup meeting,團隊在每一次的 sprint retrospect 也都會探討如何讓 team member 彼此的協作間更加有效率。我覺得本文是每一個參與 daily standup meeting 的人都可以遵循和時時反省檢視的一個指標。

🔖 The Behavior Of Channels

tags: #Go, #Channel

I learned over time that it's best to forget about how channels are structured and focus on how they behave. So now when it comes to channels, I think about one thing: signaling. A channel allows one goroutine to signal another goroutine about a particular event. Signaling is at the core of everything you should be doing with channels. Thinking of channels as a signaling mechanism will allow you to write better code with well defined and more precise behavior.

So now when it comes to channels, I think about one thing: signaling (用 signaling 去思考 channel)這篇是我看過對於 channel 最漂亮的講解了。幾種使用情境和其語意,作者都做了非常詳盡的講解。讀完這篇更加了解 channel 設計的抽象語意,對於日後使用 channel 可謂助益良多。

🔖 Matt Klein at Scale: 「Stay on your monolith!」

tags: #Microservices, #Envoy

A big part of Envoy is that we wanted to abstract a lot of these networking concepts away from the application. These are things like advanced load balancing service discovery, rate limiting, buffering, stats, logging, tracing. The idea behind Envoy 2 is that because it's an outer process proxy, it's not a library written for a particular language. We don't have to re implement everything in five different languages, in PHP and Go and Python and Node. (We also have Node services at Lyft.) The idea behind this outer crossed proxy is to make it so that we can implement these things in one place.

Microservices 架構帶來最大的挑戰就是 service 彼此之間的溝通。在分散式系統 Monitoring and Observability 是極為重要的,service 彼此的 technology stack 不同,溝通的網路又錯綜複雜,為此帶來很大的挑戰。

因此有了 Service Mesh 的概念出現,其透過 Sidecar pattern 的方式,在溝通層級作一個 monolithic 的抽象層 (有限制的自由才是好的自由 XD),來統一這些 networking 相關的議題,使其與業務邏輯解耦。

The valuable resources —

🔦 Instant Terminal Sharing - terminal sharing based on tmux

用來做 live coding 和 pair programming 看起來挺不錯的。如果有安全性考量,可以自幾架一個內部的 tmate server。

The quotes I’m pondering —

📌 在互聯網上得到正確答案的最佳方法不是去提問,而是去貼一個錯誤答案

#今日金句 互联网上,得到正确答案的最佳方法,不是提问,而是贴出一个错误的答案。 pic.twitter.com/v2wJGFnOAx

— ruanyf (@ruanyf) 2017年10月26日

因為貼出一個錯誤的答案至少表達了部分你對於問題的 understanding context,可以讓回答者更清楚你的立場。或者,會惹惱一些看不下去的專家 XDD。

📌 Latency Numbers Every Programmer Should Know

"Latency Numbers Every Programmer Should Know"

It is hard for humans to get the picture until you translate it to "human numbers": pic.twitter.com/ZeBMlgQOYq

— Srigi (@srigi) 2017年10月11日

面對一個不熟悉的度量單位,感受差異居然如此巨大 ...

The jokes entertain me —

🤣 Making Progress

Making Progress https://t.co/IqWhkkCxOa pic.twitter.com/xpqOrLrpa8

— About Programming (@abt_programming) 2017年10月23日

每每到了星期一,就相當有感受啊啊啊...

Craftsman-Spirit weekly #5

Craftsman-Spirit #5

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-10-22

What I’m reading —

🔖 RICE: Simple prioritization for product managers

tags: #Productivity, #Management

RICE is an acronym for the four factors we use to evaluate each project idea: reach, impact, confidence, and effort.

每件事都重要就是沒有一件重要,做對的事遠比用對的方法做事來的有用。本文提出 RICE 框架 (Reach, Impact, Confidence and Effort) 來決定事情的優先序,我覺得蠻值得記下來在排 priority 的時候拿出來檢視一下。

🔖 The QA mindset: designing for reliability

tags: #QA, #Reliability

Each of these pillars — correctness, error resilience, performance, and robustness — requires careful and thorough investigation on an ongoing, and ideally automated, basis. I apply this methodology when facing any new project. If I've effectively tested in each area of focus I can be confident that the project is ready for release and will behave reliably.

本文雖然是從 QA 視角出發,探討 Reliability 的四個支柱:Correctness, Error Resilience, Performance and Robustness 在測試環節中要利用什麼技巧去確保其品質。但其實對於產品初期的架構設計也相當具有參考價值。RD 若能在設計之初就帶入 QA mindset 應該能大幅度減少之後修修改改的狀況。

📹 Testing Techniques

tags: #Go, #Testing

因為下週要去 Gopher Taipei 分享一個關於 testing 的 talk,所以找資料的時候剛好看到這個 video。影片中針對一些大家覺得比較難測試的 case 來 demon 教學。我覺得尤其有用的是其中講 testing with concurrency 的部分,下週的 sharing 可以從這邊偷一些來分享了 XDD。

The quotes I’m pondering —

📌 A good API is not just easy to use but also hard to misuse

A good API is not just easy to use but also hard to misuse.

— JBD (@rakyll) 2017年10月16日

Craftsman-Spirit weekly #4

Craftsman-Spirit #4

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-10-15

What I’m reading —

🔖 The Difference Between Open-Minded and Closed-Minded People

tags: #Psychology, #Wisdom

closed-minded people would never consider that they could actually be closed-minded

closed-minded 的人幾乎從來不認為自己是 closed-minded 的 (詳見下方 joke 😆)。學習著當一個 open-minded 的人並不是自以為很 open 就可以的,而是要時時刻刻提醒自己面對困難和挑戰的態度,抵抗安於舒適圈的演化本性。

🔖 Software Is About Storytelling

tags: #SoftwareEngineering, #Empathy

Software engineering is more a practice in archeology than it is in building.
As an industry, we undervalue storytelling and focus too much on artifacts and tools and deliverables

軟體工程比起建築學其實更像考古學,代碼寫出來不難,難的是後續的維護和演進。大多數代碼的註解或文件多著重在 How & What 很少會記錄下 Why,作者認為 Why 才是真正需要流傳下去的資產,根據商業領域和市場考量產出的技術決策才是真正有價值的東西

軟體架構文件化是我蠻感興趣的議題,但這篇文章提到了一個我未曾思考過的點:面對業務需求,我們會在白板上討論各種實現可能及其優缺點,最終選擇一個我們認為當下最適合的,但這個過程很少被記錄下來,被記錄下來的僅僅是那個最終的結果。想像今天有一個新人要接手維護這個功能,那麼當時的討論恰恰才是能讓他最快進入狀況也最能學到東西的一個重要環節。

"我們擅長抽象化但卻經常忽視了把故事說好的重要性": Software Is About Storytelling - https://t.co/9hD5DYIZoW

— brownylin (@brownylin) October 10, 2017

🔖 The Ultimate Guide for Becoming an Idea Machine

tags: #Idea, #Wisdom

Every situation you are in, you will have a ton of ideas. Any question you are asked, you will know the response. Every meeting you are at, you will take the meeting so far out of the box you'll be on another planet, if you are stuck on a desert highway – you will figure the way out, if you need to make money you'll come up with 50 ideas to make money, and so on.

如何成為點子機器 (無論在何時何地遇到何事,都能想到一打解決方案,這不是神是啥 orz),我承認我是被標題騙進去了,因為發週報的確需要很多 ideas 😆。文中用 idea muscle 來比喻這個大腦產生點子的機制,也就是說我們得經常鍛鍊這個肌肉才不會使他退化。

所以作者提出了**「每天 10 個點子」**的鍛鍊,當你絞盡腦汁想不出來的時候,才是 idea muscle 被活化的開始。另外,此法在多不在精,不要覺得 idea 很爛很鳥,而是盡量想出 10 個,那麼每半年來就累積了 1800 個 ideas,裡面一定有一些不錯的,挑出來開始做些什麼。

📹 Analyzing production using Flamegraphs - Prashant Varanasi

tags: #Go, #Profiling

講者詳細的演示了 pprof 這個強大的 profiling tool,除了 profiling 之外其實透過 pprof 也可以找出 memory leaks, deaklocks, groutine spikes 等等疑難雜症。

也介紹了 go-torch 這套火焰圖工具,讓我們可以更快定位出發生問題的地方。補足 pprof 的不足。有這麼強大的 tool-chain,gopher 們要好好善用才行。

The valuable resources —

🔦 sharkdp/fd - A simple, fast and user-friendly alternative to find

一個用 Rust 寫的取代 linux find 指令的工具。指令相對比較 user-friendly,速度挺快的,輸出也很體面,可以拿來取代 find

🔦 《微服務:從設計到部署》中文版

本書為 Chris Richardson 和 Floyd Smith 聯合編寫的微服務電子書 Designing and Deploying Microservices 中文版,其從不同角度全面介紹了微服務:微服務的優點與缺點、API 網關、進程間通信(IPC)、服務發現、事件驅動數據管理、微服務部署策略、重構單體。

🔦 How to write your own git commands

要寫一個客製化的 git command 其實蠻簡單的,創建一個 git-<your_command_name> 的 shell script,然後把該檔案的路徑放到環境變量 PATH 當中就搞定啦 ~

🔦 HD wallpapers for mobile and desktop screens

偶爾換換桌布轉換一下心情也是不錯的。

The jokes entertain me —

😆 When people say they are open-minded ...

Nice try people! https://t.co/Ix7j7tJcLc pic.twitter.com/LFyBn1zw1y

— 9GAG (@9gag) 2017年10月10日

Craftsman-Spirit weekly #8

Craftsman-Spirit #8

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-12

What I’m reading —

🔖 我的架構感悟:從美國憲法學習架構設計原則

tags: #Architecture, #Constitution

從一個架構師的角度來看:合眾國憲法作為美國這個國家的基礎架構,從發佈到現在200多年,美國也從13個州發展成50個州,人口從380萬增長到3.2億,時代早已發生劇變,但是美國政治的核心架構基本未變,這個系統的運行狀況堪稱良好。當年那群「架構師」,實在是了不起。(雖然他們當年的底氣相當不足,華盛頓認為,這部憲法能維持20年就不錯了)

如果,我們想要設計出這樣的一個架構,能夠長期適應需求與環境變化,能夠歷久彌新並始終穩定可靠,那麼瞭解一下美國憲法的制定過程,其實是一件非常有價值的事情。

從美國憲法的制定到推行反思大型軟體架構的方方面面,相當有趣的切入視角,順便了解一下美國憲法的歷史。

🔖 Simulating a Real-World System in Go

tags: #Go, #Performance

以實現一個 coffee shop 為例,展示不同的 concurrency 實作對系統效能 (throughput 和 latency) 的影響。mutex lock, unbuffered channel, buffered channel 三種方式皆有探討,透過圖表能夠很清楚的感受到其中的 trade offs,是我們在做系統最佳化的時候可以參考借鏡的。

🔖 Video: How Events Are Reshaping Moden Systems (slide)

tags: #Architecture, #Events

When you start modeling events, it forces you to think about the behavior of the system, as opposed to thinking about structure inside the system.

Modeling events forces you to have a temporal focus on what's going on in the system. Time becomes a crucial factor of the system. - Greg Young

Event driven design 不是什麼新觀念了,在 microservices 架構趨勢下,events 的使用基本上就跟喝水一樣自然。

整個 talk 很完整的勾勒出當前 events 在系統架構中所扮演的角色以及一些常用的 patterns。不過最令我眼睛為之一亮的就是上面那段引言,還得花時間沈澱一下 ~

🔖 Technical Debt is a Good Thing

tags: #Product, #TechDebt

有技術債其實並不一定是一件壞事 (代表你還有能力還債),做產品本來就是時間和品質之間的 trade off。

只是什麼時候該接受,什麼時候又該堅決反對技術債,心中還是需要一把尺的。

  1. 是否為產品核心
  2. 對未來開發的影響
  3. 還債的代價
  4. 對客戶造成的影響

The valuable resources —

🔦 easymotion/vim-easymotion: Vim motions on speed!

一個加速鼠標移動的 vim 套件,類似 chrome 套件 cVimF 鍵,利用字元匹配快速將鼠標移到目的地。

The quotes I’m pondering —

📌 Every man dies. Not every man really lives - William Wallace

Every man dies. Not every man really lives - William Wallace #quote

— brownylin (@brownylin) 2017年11月12日

📌 If you ever have to ssh into a machine, your monitoring has failed

If you ever have to ssh into a machine, your monitoring has failed.#reversim #fasterisbetter @randyshoup @reversim pic.twitter.com/5ec5gH8A5v

— Yonatan Bitton (@bityob) 2017年10月16日

The jokes entertain me —

🤣 Call it "Manager"

Naming things is not so hard: If it’s unclear what your class does or will do in the future, you call it „Manager“. Just like in real life.

— Reiner Pittinger (@rpitting) 2017年11月6日

🤣 神...豬隊友

太太:「你自己說,你覺得你是神隊友還是豬隊友?」
我:「我是神...豬隊友......」

— 是擅長 workaround 的朋友呢! (@honglong0420) 2017年11月8日

That’s all!

I’ll see you next week, Browny

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.