標題: 「軟體工程師你真的工作的很開心嗎??」 類別: others 連結: https://stackoverflow.blog/2022/03/17/new-data-what-makes-developers-happy-at-work/

疫情這兩年影響全球，其中對於勞動力來說更有甚巨的變化，而科技業更是其中的佼佼者，是所有行業中離職率最高的行業。 2021 的離職率相對於 2020 來說提升了 4.5%。

StackOverflow 基於想要理解科技領域的這個趨勢及原因，所以發起了一個調查想研究工程師工作是否開心，並且將 基於 350 位來自全球開發者的回應統整為報告於三月份釋出。

結果來看

1. 70.3% 的工程師覺得工作開心
2. 14.4% 表示不開心
3. 15.3% 沒感覺

以最令人感到開心的地區排名來看，前五名分別為

1. 西班牙 (90%)
2. 印度 (79%)
3. 德國 (70%)
4. 美國 (69%)
5. 英國 (68%)

那到底哪些因素會影響開心與否？ 報告中列舉了相關的指標 前五個最令人感到開心的因素有

1. 薪資(60%感到開心)
2. work-life 平衡
3. 工作彈性
4. 是否有足夠生產力
5. 職涯發展機會

而令人感到不開心的五個最重要指標其實就是上述指標的反轉，依序為

1. 工作覺得毫無效率與生產力
2. 工作生活不平衡
3. 沒有職涯發展與機會
4. 薪水太低
5. 工作無彈性

調查的全部指標除了上述五個之外還有

1. 工作是否能夠帶來影響力
2. 是否能夠獨力解決問題
3. 有一個瞭解我工作的主管 ... 等

其實面試找工作也就是針對這些條件進行排序，與其跟風看大家去什麼公司就想去什麼公司，不如好好跟自己對話，瞭解自己對於工作的目的以及追求是什麼，才有辦法找到一個自己喜歡且舒適的工作環境

標題: 「如何於 Docker 環境中運行 rootless 模式」 類別: container 連結: https://thenewstack.io/how-to-run-docker-in-rootless-mode/

雖然可以使用非 root 的方式去安裝 Docker 服務，但是 Docker 本身服務中還有其他各種元件需要透過 root 身份去運行，譬如 dockerd, containerd, runc 等元件， 而本篇文章則是探討要如何以真正 rootless 的方式來運行一個 docker container 。

使用 rootless container 有一些要注意的事情，譬如 port number 沒有辦法使用 1024 以下，所以如果你的服務有需要被外界存取時要使用大於 1024 的 port number。 此外 AppArmor, host network mode 這些都不支援，因此使用上會有一些情境要注意。

安裝其實滿簡單的， Docker 官網有提供 rootless 的安裝檔案，安裝後需要針對一個使用者 ID 進行處理，這個處理主要是因為要將 container 內的 root 使用者給轉換到系統上的非 root 使用者，所以才會有相關的 userID 要設定。 當然如果真的要完全追求 rootless 的容器解決方案可以考慮使用 Podman 來使用，其本身的設定就是針對 rootless 去開發的，使用上會相對於 docker 來說更為簡單。

標題: 「一個用來管理 Kubernetes 開源工具的開源工具」 類別: tools 連結: https://github.com/alexellis/arkade

作者因應過去於 Kubernetes 的教學與開源過程中，必須要一直不停地去安裝各式各樣必備的工具而感到厭煩，譬如每次都要安裝 kubectl, kind, kubectx 等各種常見工具 而每個工具又會有不同的版本，每次都要專寫相關的安裝流程都很麻煩，因此作者萌生出開發一個能夠安裝這些工具的開源工具, arakde.

該工具用起來非常簡單，同時也支援不同版本的工具，除了基本 CLI 工具外也支援 Helm App 的安裝，我個人認為光工具本身就非常好用了，譬如可以透過該指令輕鬆的安裝不同版本的下列工具

1. dive
2. helm
3. gh
4. jq
5. k3d
6. kind
7. kubectl
8. k9s
9. kail
10. opa
11. terraform ...

如果你常常需要撰寫文件去分享安裝各種文件的需求，也許可以考慮使用看看此工具來簡化流程

標題: 「為什麼 3A 大作的遊戲室都不愛喜歡使用 STL」 類別: usecase 連結: https://mobile.twitter.com/m_ninepoints/status/1497768472184430600

熟悉 C++ 語言的讀者必定聽過 STL，而本篇推特系列文則是用來解釋為什麼 3A 大作的遊戲室都不愛使用 STL，這邊節錄一些概念與想法

1. STL 的實作通常會因為不同平台與編譯器而會有不同變化，但是對於遊戲業者來說很多時候會希望能夠針對所有平台能夠有一個統一一致的實作
2. 跨平台的統一實作對於開發者來說可以帶來很多好處，譬如除錯可以更有效率，不需要針對每個平台獨立研究問題
3. STL 由於不同平台的實作方式都不同，所以發生問題或是要客製化都會變得稍嫌麻煩，變成還要根據平台去研究與處理，整體來說就是煩
4. 某些情況下 STL 的實作是犧牲效能來完成的，但是效能反而是業者所需要的

覺得本篇推文非常有興趣，對這系列有興趣的可以看看大家的討論

標題: 「Terraform 生態下的五個相關輔助工具」 類別: terraform 連結: https://betterprogramming.pub/5-essential-terraform-tools-to-use-everyday-e910a96e70d9https://medium.com/geekculture/my-jq-cheatsheet-34054df5b650

隨者 IaC 的概念落地開花，愈來愈多團隊嘗試使用 Terraform 來管理各式各樣的 infrastructure，作者本篇文章分享五個自己每天使用的 Terraform 輔佐工具，分別是

1. TFSwitch
2. TFLint
3. Terraform-docs
4. Checkov
5. Infracost

TFSwitch: 如果環境中目前因為歷史因素沒有辦法統一轉移到相同版本的 Terraform 使得你必須要用不同版本的 Terraform 來處理不同的專案的話，可以透過 TFSwitch 來幫助你快速地切換版本

TFLint: 就如同大部分的 Lint 工具一樣， TFLint 針對 Terraform 的工具，特別是跟特定 CloudProvider 整時候會有更多的錯誤偵錯，將該工具整合到 CI/CD pipeline 中更可以幫助團隊避免合併一個有問題的 Terraform code.

Terraform-docs: 這是一套能夠將你的 Terraform module 直接產生對應 Markdown 格式文件的工具，如果本身有撰寫 Terraform Module 的團隊都可以使用這工具試試看，看看產生的文件是否可以滿足基本需求

Checkov: 這是一套支援 Terraform 的靜態程式碼掃描工具，可以用來檢查是否有可能的安全性漏洞與不良好的設定，目前預設大概有 750+ 以上的預設規則，

Infracost: 這工具會的目的就如同專案名稱一樣，根據創造的雲端資源幫你估計這些資源的實際花費，對於要控管成本的團隊來說，可以提供一個粗略的金額概念，畢竟如網路流量等相關付費還是要實際上線才知道，但是可以快速地針對不同的 infra 直接列出大概的金額差異，搭配得宜對於整體工作流程還是有幫助的。

標題: 「Facebook 內的文化特別之處」 類別: usecase 連結: https://chinese.catchen.me/2022/02/unique-engineering-culture-of-facebook.html

作者作為一個 Meta 工作七年的員工，分享了一些認為 Facebook 頗有特色的文化，這些特色文化並沒有辦法直接斷言是好是壞，一切都是看用什麼角度去看待。

工程師對產品結果負責

年度績效評估時要如何去評估一個工程師的績效一直都是個不簡單的問題，作者提到對於 Meta 內部的高級工程師(不確定正確級別代號是什麼)來說，其績效並不是單單的只去看技術用的好不好，程式寫的好不好 更多的反而是這個產品是否有真正的商業成長結果。

作者認為這種鼓勵從下而上解決問題的思路能夠讓產品的發展更佳有效率與有意義，舉例來說 假如今天工程師的績效是完全基於技術方面的呈現，而專案負責人(PM)的績效可能是該專案對於使用者的黏著度，兩者績效不一致的情況下很容易發展出不同的開發與演進策略 工程師為了達到自己的績效其發展的路線就不一定可以為產品帶來更好的使用者黏著度，反之亦然，為產品帶來更好使用者黏著度的改善並不一定可以讓工程師看到很好的表現績效。

但是一旦當工程師與 PM 的目標一致，整體的合作就會更加融洽也目標，這也是為什麼 Meta 的工程師非常了解自己產品的指標跟數據，還會花時間去分析產品數據與使用者分析報告，透過自己的理解來思考到底要怎麼去改善產品的方向，而不是完全等待 PM 發號司令。

基礎架構被視為一個產品販售

Meta 內部的基礎架構某程度也被視為是一個產品，公司內的其他工程團隊則是該產品的潛在用戶，所以開發該產品的團隊本身也要努力的去推銷這個產品，去說服為什麼要使用這個架構，使用這個架構能夠帶來什麼樣的好處。 作者以早期的 Reat, React Native 為範例，早期該產品於公司內推廣也是四處碰壁，並非外部所想像的一推廣就廣受歡迎與嘗試。

由於基礎架構被視作是產品，所以如果其「商業」表現不如預期的話，該專案也是會被砍掉的，這類型的模式搭配上述的概念其實非常有趣

所有的專案都想要長期存活都必須要證明其有價值，就算是內部架構也要證明其對內部其他工程團隊有價值 這種方式也降低了「只專注技術而不考慮使用者需求的」的開發方式，這讓我想到大家最愛講的「Service Mesh」.... 帶來什麼效應不確定，但是很潮就是享用...，

標題: 「Package Maintainers 應該要具備的資安概念」 類別: other 連結: https://sethmlarson.dev/blog/security-for-package-maintainers

本篇文章的作者是 python3 urllib3 套件的主要維護者，由於近年來軟體供應鏈的資安議題逐漸受到重視，特別是這些已經被廣泛使用的套件，一套受到入侵與修改，其影響危害程度難以想像 作者撰寫本篇文章分享自己的想法希望能夠讓所有套件維護者有一些基本的資安觀念，同時也讓所有使用 OSS 的使用者一起學習

捐贈給開源貢獻者

作者提到本文提到的所有資安意識都需要花時間精力去實作與維護，如果你的組織使用了大量的開源專案但是本身在意資安卻又不想要花時間研究資安，那就花點小錢捐贈給這些開源貢獻者，讓這些貢獻者有更多的動力去幫你維護這些套件。 如果該開源專案對於你公司來說有非常舉足輕重的角色，那甚至可以考慮雇用一兩個該專案的主要維護者讓他們定期分配時間來維護，對公司來說只是花一些小錢但是卻能夠有更有信心的使用這些開源專案，以免哪天這些專案一炸整個公司產品全炸

文章主要分成兩大類，分別是

1. 如何保護好你的個人帳戶
2. 如何保護好你的套件倉庫

Securing Your Accounts

對於一個套件維護者來說，你的個人帳號由於有超級大的權力，所以該帳號的資安管理必須是最高層級的注意，一但這個帳號被攻破，攻擊者就可以很輕鬆的去發布新版本，加入惡意程式碼等各種行徑，而通常使用者如果本身使用時沒有很好的限制版本，譬如採用大於1.1.0 這種比較寬鬆的用法就會不自覺升級而使用到危險版本 作者強調就算你本身不是套件維護者，這些帳戶保護方式對你來說也是非常實用的，良好的資安保護永遠不吃虧

接下來作者列出幾個大項，分別是

1. Email Securiy Is Your Top Priority Email 地址很重要，很多情況下這些地址都會是重設密碼的一個途徑，所以妥善保存 Email 地址是非常重要的，所以作者推薦使用那些大公司服務如 Gmail 與 Outlook。 如果你真的想要使用私人域名作為你的聯絡信箱，你就要保證你不會有忘記付費的那天，不會剛好有人買走你的域名然後順利的取走你的 Email 地址。

2. 2FA 2FA 要求提供一個除了密碼以外的認證方式，常見的有手機或是一些硬體裝置，使用妥當的話基本上攻擊者很難登入你的帳號。 作者認為所有跟程式碼有關的帳號密碼最終都需要有一個不使用 SMS(簡訊) 的 2FA 機制保護，譬如 NPM 最近才宣布其 Top 500 的套件管理都需要強迫使用 2FA，作者希望 Python 有天也可以跟上這種趨勢。

3. Password Managers

4. Hardware Keys

5. Why Not SMS 2FA

6. Where Do I Put My Recovery Codes

7. What to do if your account is compromised?

上述範例我就不列出來了，每個項目都沒有很長，非常推薦大家閱讀，甚至可以讓團隊的所有工程師都有這些基本概念

標題: 「如何判別到底要不要使用 Service Mesh」 類別: Network 連結: https://medium.com/google-cloud/when-not-to-use-service-mesh-1a44abdeea31

本篇文章是一個經驗探討文，想要探討近年來非常熱門的網路網格(Service Mesh) 到底導入時要怎麼抉擇與判斷。 Service Mesh 如果用得正確與適當，能夠為團隊帶來很多優勢，可以讓團隊更專注於軟體的服務上，讓 Service Mesh 幫忙提供各種方便的功能。 但是如果使用錯誤則可能只會造成整體架構更加複雜，同時也沒有解決什麼真的重點問題，一切只是疊床架屋的空殼而已。

1. 採用 Service Mesh 要儘早 作者認為到底要不要導入 Service Mesh 是一個專案初期就要決定的事情，即使 Istio 網站有特別教學如何將專案從 non-MTLS 給轉移到基於 Istio MTLS 的過程 但是作者說真的跑過這些流程就知道絕對不是官網寫的三言兩語這麼簡單，有太多額外的事情要考慮，譬如上層安裝的服務，網路分層設計等，這些會因為有沒有 Service Mesh 而有不同的決定

2. 不要當 Yes Man 作者體驗過最多的案例就是每個團隊看到下列問題都是不停的說 YES，然後最後就直接無腦導入 Service Mesh

3. 我們需不需要強化資安

4. 使用 mTLS 能不能強化資安

5. mTLS 是不是很難管理

6. Service Mesh 是不是可以讓 mTLS 便於管理

連續四個 YES 下來就直接無懸念的導入 Service Mesh，殊不知

因此作者接下來就列出幾個要導入 Service Mesh 前需要仔細思考過的問題

1. 是否有計畫於當下或是未來使用到 Serivce Mesh 的所有功能 Service Mesh 的功能除了 mTLS 外還有各式各樣跟流量有關的管理，譬如 A/B Testing, 金絲雀部署等。 透過 Service Mesh 能夠讓應用程式不需要實作這些功能而依然可以享有這些功能的好處。 所以作者認為團隊中的所有人都要仔細的注意，到底你們即將採用的 Service Mesh 有哪些功能可以用，這樣可以避免應用程式重複開發相同功能。 作者也提到不需要第一天就決定好要採用什麼功能，但是至少要仔細理解自己採用的解決方案到底有什麼功能，然後未來改善架構的時候可以即時的想起來這功能有提供

2. 團隊中是否有人對於 Service Mesh 有足夠的理論或是實戰理解？ 作者看到的非常多團隊很多人根本不理解 Kubernetes 以及 Service Mesh 但是就想要導入 Service Mesh。 由於對 Service Mesh 完全不理解，連其實作的概念都不同，所以當問題發生的時候就什麼都不能做，因為根本不懂也不知道該從何下手 請花時間學習與理解你要使用的專案，以確保你有足夠的背景知識去使用與除錯

除了問題之外，作者也認為要導入 Service Mesh 到生產環境並不是單純的建構一個 Hello World 這麼簡單，還有很多事情要考慮，譬如

1. 自動化
2. 監控與追蹤
3. 除錯與已難雜症排除

整篇文章非常的棒，有興趣的可以詳細閱讀

標題: 「透過 Helm 與 Terraform 來自動 Re-new Cloudflare origin CA」 類別: usecase 連結: https://awstip.com/auto-renew-cloudflare-origin-ca-with-terraform-and-helm-d28be3f5d8fa?source=linkShare-91a396987951-1645539866&gi=a18b2bbd9604

本篇文章是過工具介紹文，探討如何基於 Helm 與 Terraform 這兩個不同層級的工具來處理 Cloudflare 的憑證。

Why Cloudflare

根據 W3Techs 的調查顯示， 81.2% 的網站都使用 Cloudflare 來提升讀取速度或安全防護。 透過 CDN 的概念與機制，網站可以讓全球使用者有更快的讀取速度，此外也愈來愈多的網站會透過 Cloudflare 來處理如機器人, DDOS 之類的流量攻擊，畢竟要自己架設網站處理這些攻擊非常困難 因此讓 Cloudflare 這類型的網站來幫忙過濾與處理能夠讓團隊更專注於本身的業務開發與維運

Kubernetes

想要在 Kubernetes 內妥善管理所有使用的憑證其實也是一個麻煩事情，除了要能夠設置正確來創立憑證外，能夠於到期前自動 re-new 也是一個不可或區的功能。 Kubernetes 內跟憑證有關的最知名專案我想就是 Cert-Manager，而 Cloudflare 也基於此專案撰寫了相關的 Kubernetes Controller，如 Origin CA 等 因此本文使用的功能與示範都會基於 cert-manager 與 Cloudflare 的架構。

目的

本文的目的是希望能夠將過往手動的繁瑣步驟給自動化，讓 Kubernetes 可以獲得 Cloudflare 提供的好處，如憑證與相關域名等。 內文是基於 Terraform 作為出發點，然後透過 Kubernetes Provider 的方式來與之互動，一步一步的安裝各種資源最後成功於叢集內獲得相關域名的 SSL 憑證以及其他資源

標題: 「20年工程師生涯教會我的 20 件事情」 類別: others 連結: https://www.simplethread.com/20-things-ive-learned-in-my-20-years-as-a-software-engineer/

本篇文章是作者談談自己工程生涯近 20 年的經驗，聊聊 20 個作者覺得很值得跟大家分享的一些想法與經驗。 開頭作者就說，所有的建議與經驗分享最重要的就是脈絡，沒有了脈絡所有的建議可能都沒有任何用處，甚至可能會對你有害 所以作者先表明自己的一些經驗，包含

1. 前半職業生涯作為一個小型公司與新創的軟體工程師。
2. 顧問人生同時加入規模非常大的公司
3. 創立 Simple Thread 這間公司從兩人團隊一路成長至今

這邊節錄幾個經驗，整體來說我認為全部都滿不錯的，都推薦當作心法去看待，甚至也可以作為一些討論的主題。

1. I still don’t know very much: 不知道你有沒有很常聽到別人說「你怎麼會不知道 BGP 怎麼運作？」「你怎麼沒有聽過 RUST ?」，軟體世界的有趣點不論你怎麼學習，每天都有會展新的技術被發展出來 你於你專精的領域努力了十年，對於其他人的領域你會發現還是有很大一片空白需要學習。 所以請認知這一點，軟體世界龐大本來就很容易有不知道的事情，然後保持謙虛的去面對這一切，不要用一種別人都是白癡的態度來質疑別人

2. The best software engineers think like designers 最好的軟體工程師其思路不單純只是滿足功能，而是如同一個設計師一樣，會去思考設計的這個軟體各種使用，包含外部 API的設計，使用者介面，甚至要去考慮 使用者會怎麼使用，使用者為什麼會想要用等，將使用需求放到開發的第一順位才能夠打造一款真的是很適合使用者使用的軟體。

3. Look for technological sharks 那些發展許久至今仍活躍的技術能夠於現在這個迭代快速的世代存活下來必定有其價值與原因，如果今天想要替換掉這些技術一定要有很好的理由與評估，不要單純冒然基於 新技術好像比較好就去替換。這些舊有的技術與工具也許用起來沒有現在這麼潮，但是其穩定性與良好的表現絕對能夠讓你晚上好好睡覺

4. Every system eventually sucks, get over it 軟體開發中沒有一個正確的架構，所有的人無時無刻都在處理相關的技術債，所有開發的介面過一段時間都會因為情境不同而需要改動與重寫，你撰寫的測試永遠都不足夠。 但是這些概念並不能當作一個不往前邁進的理由，相反的就是因為知道沒有一個完美的架構，所以才要更有系統地去持續精進整個架構，永遠都有值得改善與變好的地方 透過不停的循環這個開發流程才能夠讓整個軟體愈來愈好。

文章中還有其他 16 個非常實用的建議，非常推薦大家閱讀閱讀