標題: 「Kubernetes 紀錄片 」 類別: others 連結: https://thenewstack.io/a-kubernetes-documentary-shares-googles-open-source-story/
來自歐洲的 Honeypot.io 與 RedHat, Google 以及 CNCF 合作完成一個長達一小時的 Kubernetes 紀錄片，該紀錄片分成上下兩集，探討 Kubernetes 的發展及過程 被戲稱就像是給開發人員的 Netflix 影片 如果英聽還行的話，非常推薦當個小品影片去聽聽看 Kubernetes 的今生前後
標題: 「Golang 原始碼的的版本控制歷史」 類別: others 連結: https://research.swtch.com/govcs
本篇文章是 rsc 來仔細介紹 golang 的發展歷史，主要是針對整個開發過程的版本控制轉移以及一些有趣的 Commmit 舉例來說，如果你去看 golang 的 commit 會發現第一筆 commit 是 1972 年的內容，並且該 commit 增加了一個 src/pkg/debug/macho/testdata/hello.b 的檔案
而以實際狀況來說，前面四筆都是假的 commit，第五筆 commit 才是 golang 開發的第一筆 commit，這之間的緣由牽扯到版本控制的轉變。 以 Golang 來說，其經歷了四次轉變化，從最初的 Subversion 到 Perforce 到 Mercurial 到 Gerrit
其中 golang 正式對外公開是發生於 Mercurial 的過程中，而這些假的 commit 也是這個時間點由 rsc 自己產生的，當作一個復活節彩蛋的概念 有興趣的可以閱讀全文
標題: 「大家總是喜歡誇大自己的工作時數」 類別: other 連結: https://drmaciver.substack.com/p/people-dont-work-as-much-as-you-think
本篇是一個心態探討文，作者探討了到底一天的有效工作時間有多少，並且認為人們宣稱的工作時間通常都不准，很多時候只是一種想要讓人看到自己工作很久的心態而已。 從作者的經驗來說，作者認為軟體開發，作家，顧問等行業都會有這類型的特性，一個有效率的工作者其實根本不可能一整天連續工作八小時。 一開始作者先列舉自己一天可以達到的事情有哪些(可達到不代表全部都會做)
總體來說，作者一天認真工作的時間大概就是四小時左右，當然有需求時當然可以提升整體的工作量，不過作者認為這會影響身心健康，所以不是很喜歡。作者也認為「愈需要創作的工作其實真正工作的時間愈少」 很多工程師看起來工時很長其實有時候上班也都在滑 Twitter, Reddit 等各種網站，真正的工作時長其實都不如自己宣稱的。因為每個人的精力有限，不可能長時間執行高度專心的工作，很多時候花一堆時間去拼工作量結果得到的是每件事情都辦不好， 與其如此不如找到一個適合自己的工作方式，讓自己能夠有效率地去做好每件事情。
這邊要特別注意的是
如果今天有人要丟工作給你，請友善禮貌地回答「我很願意幫忙你，不過我目前手頭上正在忙 XYZ，你想要做的事情優先度有比較高嗎？」
最後作者針對工程師列出一個不同類型工作的適合工作時數
標題: 「ClickHouse 與 Elasticsearch 的比較」 類別: other 連結: https://developer.aliyun.com/article/783804
這篇文章內容非常精彩，從不同層面去探討 Elasticsearch 與 ClickHouse 這兩套解決方案的差異，探討了包含
文章很長且滿多技術坑，適合對於 Elasticsearch 有維運與管理有經驗的使用者
標題: 「Paypal 如何調整 Kubernetes 讓其規模達到四千節點，20萬個 Pod」 類別: usecase 連結: https://medium.com/paypal-tech/scaling-kubernetes-to-over-4k-nodes-and-200k-pods-29988fad6ed
摘要: Paypal 過去一直都使用 Apache Mesos 來運行其大部分的服務，而其最近正在針對 Kubernetes 進行一個評估與測試，想瞭解如果需要轉移到 Kubernetes 會有哪些問題需要挑戰與克服。 本篇文章著重的是效能問題，原先的 Apache Mesos 可以同時支持一萬個節點，因此 Kubernetes 是否可以拿到相同的效能 而本文節錄的就是擴充 Kubernetes 節點中遇到的各種問題以及 Paypal 是如何修正與調整讓 Kubernetes 可能容納盡可能更多的節點。
效能測試方面是基於 k-bench 去開發的測試工具，基於平行與依序等不同方式來創建 Pod/Deployment 兩種資源。
文章接下來開始針對 API Server, Controller Manager, Scheduler, ETCD 元件遇到的問題並且如何解決，中間提到了不少參數，這部分應該是大部分使用者都比較不會去研究與使用的參數 因此我認為本篇文章非常值得閱讀。 ETCD 的部分遇到很嚴重的效能問題，作者團隊觀察到大量的 Raft 溝通失敗個訊息，觀測到跟硬碟寫入速度有關，然而 GCP 沒有辦法單純增加效能，必須要同時提升硬碟空間，所以使用上彈性不變。 不過就算採用 1TB 的 PD-SSD ，當 4 千個節點同時加入到 Kubernetes 時依然會遇到效能上的問題，團隊最後決定使用本地端的 SSD 來想辦法改善寫入速度，結果又遇到 ext4 的一些設定 過程很多問題也很多解決方式。
結論來說: k8s 複雜
標題: 「macOS 的 fsync 實作其實跟大家想像的完全不同 」 類別: others 連結: https://mobile.twitter.com/marcan42/status/1494213855387734019?t=TyXUEg-2LcbNiKkv0JVOsg&s=09
以下節錄自該留言串 「As it turns out, macOS cheats. On Linux, fsync() will both flush writes to the drive, and ask it to flush its write cache to stable storage.
But on macOS, fsync() only flushes writes to the drive. Instead, they provide an F_FULLSYNC operation to do what fsync() does on Linux.」
簡單來說就是 Linux 的 fsync 會執行兩次動作，最終讓當次修改給寫回到底層儲存設備，而 macOS 的版本卻不會真的確認寫回硬碟，所以這個導致很多仰賴 fsync 的應用程式就會有一些不預期的行為，這也是為什麼首篇發文的內容 「Well, this is unfortunate. It turns out Apple's custom NVMe drives are amazingly fast - if you don't care about data integrity.
If you do, they drop down to HDD performance. Thread.」
標題: 「 取代 Docker Desktop 的高效率開發環境」 類別: Container 連結: https://medium.com/partoo/replacing-docker-desktop-with-a-more-efficient-development-environment-582c61c50984
作者認為 Docker Desktop 是一個非常好的開發環境工具，能夠簡化很多設定讓開發者更容易的開發應用程式，但是對於 Windows/Mac 的使用者來說 Docekr Desktop 實際上也是先運行一個基於 Linux 的 VM 並且於其中運行 Docker Container。這種架構實際上帶來了一些使用上的缺陷，包含
作者的公司 Partoo 採取了 VM + Vagrant + Ansible 的方式來創建開發者環境，讓每個加入團隊的開發者都可以輕鬆簡單的建設期開發環境 並且文章中也探討如何於本地端使用 Vistual Studio Code, PyCharm 來編輯 VM 的檔案並且順利的進行應用程式開發。
從效率來看，相對於直接使用 Dodcker Desktop 來看，作者團隊的測試程式基於自己的 VM 提升了將近 30% 的效能，主要的問題就是儲存系統與 Docker Container 之間的掛載關係差異。
標題: 「 Kubernetes 四種不同開發環境的比較」 類別: Kubernetes 連結: https://loft-sh.medium.com/kubernetes-development-environments-a-comparison-f4fa0b3d3d8b
根據 VMware 2020 的一個研究報告指出，如何存取 Kubernetes 叢集是影響開發者生產效率的最大要素，所以本篇文章就是就會針對如何去評估與挑選一個適合開發者的 Kubernetes 叢集與存取方式。
作者將 Kubernetes 叢集分成四大類，分別是
為了比較這四種不同的叢集，作者定義了幾個不同的面向，針對這幾個面向來評比，分別是
文章一開始就有列出一個結論表，對於這個議題有興趣的歡迎閱讀
標題: 「 談談遷移應用程式到 Kubernetes 內的失敗經驗談」 類別: Kubernetes 連結: https://medium.com/@marcong_54227/unsuccessful-experience-of-migrating-applications-to-kubernetes-a896823d9b95
作者團隊於 2019 年要開發一個全新的 API 應用程式，當時部門的 IT 團隊計畫要將既有的 VM-Based 應用程式給轉換到 Container-Based，最後團隊使用了 RedHat 的系統，並且使用 OpenShift 做為容器管理平台。
從結果來看，該專案從 2020/05 一路到 2021/05 花了整整一年也沒有順利的將應用程式轉移到 OpenShift 中，其中的一些重點有
最後團隊內又針對不同團隊給予不同的想法
譬如 Application Team 的開發人員都只滿足自身的技能，而且拒絕學習新技能，誇張的是一年過後團隊內的人也沒有辦法撰寫 dockerfile 或是使用 docker build.
後續還有一些針對不同團隊的想法與總體建議，整體來說非常真實，一個血淋淋的轉換案例。
標題: 「GitHub 上常常看到的奇妙 commit 到底是什麼？」 類別: others 連結: https://people.kernel.org/monsieuricon/cross-fork-object-sharing-in-git-is-not-a-bug
每過一段時間都可以於 GitHub 上面看到一些看起來很嚇人的 Commit，最經典莫過於 Linux Kernel 中的各種內容，譬如檔案被砍光，README 加入一些驚嚇言論 不知道情的使用者可能會想說這個內容是真正的 Github Repo 上的東西，鐵定是真正被認可而合併進去的，所以相信不疑。 殊不知這一切其實都只是 Git 的底層設計使得一些有心人可以打造出一些以假亂真的內容，文章中就有列出兩個關於 Linux Kernel 的有趣 Commit.
文章內詳細的去解釋整個來龍去賣以及底層 Git 的設計，包含 blob, tree, commit 之間的關係，並且說明為什麼有心人可以輕鬆的產生這些以假亂真的 Commit。 舉個範例來說，Linux Kernel 的整個 Git 專案大概有 3GB 的大小，然後被 Fork 的次數高達 40000 次，請問從實作方面來考量，你會希望
如果是選項(1)的話，那這樣至少要準備 120TB 的資料，從儲存方面來說完全不是一個可接受的實作方式，因此自然而然的都會是基於(2)的方式去實作 因此該 Linux Kernel 的 Git 專案實際上裡面記錄了所有的 Fork 資料，而每個人針對自己的 Fork 去進行更新等行為也都會記錄到 Linux Kernel 本身的專案上。 換句話說， 那 40000 個 Fork 出來的專案實際上還是共用同一份 Git 專案，因此每個人的 Commit 都只要該 Hash 被知道，其他人都有機會去檢視與瀏覽。
而 GitHub 的 UI 又允許使用者以 Commit Hash 的方式去瀏覽每一個 Commit 的內容，因此就可以跑到主要專案去輸入自己 Fork 產生的 Commit 來產生以假亂真的 Commit 內容。
對於整體有興趣的可以觀看全文