標題: 「多年工作經驗總是搞砸電話面試， why ?」 類別: 其他 連結: https://kevin.burke.dev/kevin/phone-screens-broken/

本篇是一個面試經驗探討文，作者闡述自己雖然已經有十年多的工作經驗，但是部分面試工作上還是沒有很辦法的去展現自己的能力 特別是那些用電話面試的經驗，而此文就是關於電話面試的小小抱怨文

滿多的電話面試都會搭配 Coderpad 這個網站來要求面試者線上進行程式撰寫，而該網站就要求你使用線上編輯器並且將所有的程式碼都統一到一個檔案中 ，同時也不一定有辦法去撰寫相關的測試規則，這對於作者來說非常不喜歡。 作者平常習慣開啟多個視窗進行開發，一邊撰寫程式一邊透過測試來驗證當前撰寫的程式是否往正確的方向前進，同時也花費大量時間去調整自己喜歡的工具來輔助所有 程式碼的撰寫。而上述所有習慣都沒有辦法於 Coderpad 的單一編輯器上去完成。 此外面試過程中還會被問各種問題，譬如為什麼這個變數這樣命名，為什麼blablabla... 對於作者來說，有些概念要到快完成時才會最佳化，就很明顯不符合電話面試這種要一次完美的特色。

最後作者也分享了一下關於電話面試的問題想法，相較於問一些實際上工作根本用不到的演算法問題，不如問一些更貼切真正工作會用到的經驗與概念，譬如

1. 給面試者看一段 opensource 專案產生的 stack trace, 問問面試者能不能從這個 trace 看得出來大概可能是什麼問題
2. 如果你開啟一個 database transaction 過久，有可能會發生什麼問題?
3. 寫檔案到硬碟如果每次都只有寫一個 byte, 這可能會帶什麼樣的壞處?
4. 給定一個函數，請面試者描述會如何針對這個函式去寫測試案例

這讓我想到多年前也有接過電話面試直接問我 Linux 用幾個bit實作權限，但是面試官本身也非這個專頁，是哪個權限也沒辦法回答，也不能給清楚的 context，就如同教科書一樣一個問題一個答案，沒辦法針對面試者的疑問去解惑...

連結: https://medium.com/.../dating-application-system-design... 本篇是一個系統設計文，探討設計一個如 Tinder 的應用程式該如何去思考整體架構

Tinder 這種交友應用程式有幾個特點

1. 透過 FB 走 OAuth 登入
2. 左滑右滑
3. 配對機制
4. 聊天對話
5. 通知功能 其中 (3) 這個特色是說當使用者開啟 app 之後系統要根據一系列的條件們去推薦可能的對象，條件包含很多
6. 從 FB 中抓到的個人資料，喜好等
7. 地理位置，通常這類型的交友軟體都可以設定希望對象與自己的距離，譬如 10km 內， 50 km 內。 同時這類型的交友軟體支援多語言，支援多語言基本上就是意味多地區，簡單的說法可以說支援全世界不同地區的使用者共同使用， 因此基於效能考量上，通常不會使用單獨使用一個地區的伺服器來提供全球的服務，取而代之的則劃分地區讓每個地方都有一個稍微近的伺服器可以使用。 所以整體架構上還需要考量這類型的分散式架構設計，特別是有一些交友軟體還支援切換地點的功能，使用者可以切換到不同地區去匹配 不同地區的使用者，這意味該使用者的資料也會需要同步到不同地區的伺服器之間，因此資料部分也需要特別注意處理。 接下來就是當使用者希望配對範圍 100km 的使用者，該功能到底該如何實作，要如何將實體的地理位置劃分出來並且有辦法根據該敘述， 100km 內的使用者進行配對。 文章內有針對這部分進行詳細解釋，如何拆分不同的小區塊然後如何後續處理，有興趣的可以參閱全文

疫情肆虐下的 2021 年即將結束，按照慣例來個年度回顧紀錄。 這一整年完全遠端工作，算是人生經驗中非常不同的一年，台灣副業今年的發展也稍微多一點，不過整體演講數量就有明顯下降

2021 回顧

• 粉絲頁 - 矽谷牛的耕田筆記發文: 199 篇，發文數量比預估(183)篇還要多，整體來說學到很多東西不過也花了很多時間在閱讀與分享。
• Ithome 鐵人賽發文: 30 篇，這次的主題圍繞於 Rancher & GitOps 的介紹，最後也很榮幸的獲得了佳作。
• 演講紀錄: 3 篇。整年度的演講數量下降，跨時區的限制實在不方便每次半夜四點起來參與台灣社群，比較特別是的參與 HiEXPERT 2021 DevOps 領航者論壇 的討論分享。
• 部落格原創文章: 6 篇，想寫的很多，時間不夠多...
• 線上課程: 2 門課程，今年本來想要把 Networking 系列一口氣弄完的，沒有預期的順利，時間忙碌。
  • 線上課程包的線上演講: 2 次，這是個一整年的計畫，每個月給課程內的學生有一次分享，還有十次才結束。
• 書籍出版: 1 本，人生第一本實體書籍，因應鐵人賽的結果很順利的就體驗了出書的過程。
• 運動回歸: 因應疫情荒廢一年多的運動習慣直到有兩劑疫苗後才重新復活，直至年底整個運動表現有整體回溫，不過年底膝蓋有點小傷所以又要好好休養一下
  • 硬舉: 210 kg
  • 臥推: 125 kg
  • 深蹲: 170 kg
  • 肩推: 75 kg
• 新技能學習: 今年開始認真學習並且繼續鑽研的技術是舉重，先從抓舉開始練習並且養成瑜伽的習慣來加強活動度與柔軟度
• 企業教育訓練: 1 次，年尾很驚訝的收到一個企業教育訓練的機會，看看有沒有機會讓這個也變成常態服務
• 長時間出遊: 3 次，下半年去了芝加哥, Reno 以及西雅圖度假放鬆，體驗不同生活。

2022 展望

• 保持運動習慣，想把體重給降回到 7 字頭了
• 書籍，課程: 量力而為
• 原創文章: 花更多時間到這一塊
• 粉絲頁: 繼續多閱讀多分享，藉由閱讀逼迫自己學習一些平常碰不到的東西
• 生活順遂: 工作之餘還是要定期放鬆旅遊

連結: https://docs.microsoft.com/.../archit.../patterns/ambassador

微軟文件中的系列好文，探討雲端方面的各種設計模式，而本篇探討的是 Ambassador 模式 想法:

1. 想要提供更多進階的網路功能到應用程式上，譬如 TLS、circuit、breaking、routing 或 metering。
2. 應用程式不太方便修改來符合上述功能。
3. 部署一個跟原應用程式相鄰的應用程式來處理這些網路功能。 應用程式過於古老，團隊沒有辦法進行深度修改或是團隊中的應用程式使用過多的語言與框架完成，很難簡易的將這些功能給導入到既有的應用程式中 這時候部署一個全新的應用程式就可以再不修改既有應用程式的前提下來提供這些進階的網路功能。 這個模式普遍被稱為 ambassador 模式，而本篇文章就是針對該模式進行一個科普概念。 文章最後還要探討使用這種模式的一些注意事項，譬如網路的延遲會因為多一個應用程式而提升，所以使用上也要評估看看是否合適。 也有簡單的列出什麼情況適合使用 ambassador 什麼情況不適合。

連結: https://pythonspeed.com/articles/stop-using-python-3.6/

本部落格是一個基於 Python & Container 的系列介紹文，而本篇文章是其中一篇探討容器化 Python 要注意的事項。 標題非常簡單：「是時候停止使用 python 3.6了」 Python 3.6 的 EOL 時間就剛好是 2021/12，這也意味到 2022 年後 python 3.6 就不再享受官方的任何維護與更新。 文章中提到建議趕快升級，同時也要注意不要每次都拖到最後一刻才升級相關軟體，應該要把升級軟體的流程給整合到日常流程中，定期掃描定期更新， 否則只會不停的被不同版本的 EOL 追趕而已。

連結: https://coolshell.cn/articles/21672.html 本篇文章是作者工作 20 年來的經驗分享文，內容非常好，提出了很多不同的觀點，由於是篇中文文章，所以就不幫忙節錄重點，直接列 文章中的十一個原則標題。 每個原則都非常精彩，文章底下的討論也滿有趣的。 原则一：关注于真正的收益而不是技术本身 原则二：以应用服务和 API 为视角，而不是以资源和技术为视角 原则三：选择最主流和成熟的技术 原则四：完备性会比性能更重要 原则五：制定并遵循服从标准、规范和最佳实践 原则六：重视架构扩展性和可运维性 原则七：对控制逻辑进行全面收口 原则八：不要迁就老旧系统的技术债务 原则九：不要依赖自己的经验，要依赖于数据和学习 原则十：千万要小心 X – Y 问题，要追问原始需求 原则十一：激进胜于保守，创新与实用并不冲突

連結: https://emmer.dev/blog/docker-shell-vs.-exec-form/

Docker 基本介紹文，不知道常寫 Dockerfile 的讀者能不能分清楚 Dockerfile 內 Shell 與 Exec 兩種格式的差異 RUN, CMD, ENTRYPOINT 等指令都同時支援這兩種格式 Shell 格式就是 RUN command arg1 arg2 arg3 這種直接描述的格式，而 Exec 則是用 [] 包起來，每個參數單獨敘述，譬如 RUN ["command", "arg1", "arg2", "arg3"] 等。 本篇文章推薦 RUN 指令採取 Shell 格式而 CMD/ENTRYPOINT 都應該採用 EXEC 格式。 如果自己不清楚差異以及沒有想法為什麼平常自己這麽寫的話可以參考全文

連結: https://linuxconfig.org/how-to-propagate-a-signal-to-child-processes-from-a-bash-script

基本 Bash 介紹文，探討 trap 的用法，如何於不同的情況下正確攔截 SIGNAL，同時如果 script 中運行的程式有無背景執行 會有什麼差異，推薦給對 Bash 不熟的讀者閱讀重新複習

連結: https://matduggan.com/mistakes/

本文是作者踩過的各種 Infrastructure 雷，希望讀者能夠避免這些雷。

總共有幾大類，分別

1. Don't migrate an application from the datacenter to the cloud
2. Don't write your own secrets system
3. Don't run your own Kubernetes cluster
4. Don't Design for Multiple Cloud Providers
5. Don't let alerts grow unbounded
6. Don't write internal cli tools in python

其中第六點簡短扼要，大概就是「沒有人知道如何正確地去安裝與打包你的 python apps, 你真的要寫一個內部的 python 工具就給我讓他完全跨平台不然就給我改用 go/rust, 不要浪費生命去思考到底該如何安裝那些東西」

這讓我想到你的 Python 跟我的 Python 每次都不一樣，有已經不支援的 python 2.x, 還有各種可能會互相衝突的 python 3.x....

ref: https://jpetazzo.github.io/2021/11/30/docker-build-container-images-antipatterns/

本篇文章分享的是建置 Container 中的 Anti-Patterns，不講哪些好反而探討哪些不好。

文內列舉了不同的主題，包含

1. Big images
   • All-in-one mega images
   • Data sets
2. Small images
3. Rebuilding common bases
4. Building from the root of a giant monorepo
5. Not using BuildKit
6. Requiring rebuilds for every single change
7. Using custom scripts instead of existing tools
8. Forcing things to run in containers
9. Using overly complex tools
10. Conflicting names for scripts and images

以下針對內文幾個部分摘錄一下為什麼作者認為是個不好的模式

Small Images

Image 小本身不是什麼問題，但是有時候過度追求容量會使得一些常用有幫助的工具沒有辦法於容器內執行，這可能會導致未來要除錯時要花費更多的時間去處理，可能要研究如何重新安裝該工具等。

作者有強調這個議題是非常看環境與需求的，有些情況可能團隊根本不需要進入到容器內去執行 shell 來處理，有些可能會需要到容器內執行 ps, netstat, ss 等指令來觀察不同狀態。 作者推薦可以使用 gcr.io/distroless/static-debian11 這個 image 做為基礎然後將其之間的 busybox 給複製環境中，至少確保有基本工具可以使用

Not using BuildKit

BuildKit 是 docker build 的新版建置方式，相對於舊版方式來說 Buildkit 提供了更多功能，譬如平行建置，跨平台建置甚至效能上也會比過往的更好。 為了讓舊有使用者可以無痛轉移，所以 BuildKit 完全相容既有的 Dockerfile 的語法，所以切換方面是完全無腦的。 目前新版的 Docker Desktop 基本上已經預設採用 BuildKit 來進行建置，不過某些系統譬如 Linux 的環境下，還是需要透過設定環境變數來啟用這個功能，譬如 DOCKER_BUILDKIT=1 docker build . 等方式來建置。

此外透過 BuildKit 建置的產生結果跟過往不同，所以只要看建置結果的輸出就可以判別自己是否使用 BuildKit。

剩下的8個項目就留給有興趣的讀者自行閱讀