第 15 期 - 值得紀念的時刻，全台最大的口罩駭客松，Respect!
本週專欄
Kubernetes 教學 (一) 概念與架構 - 為什麼該學 K8S ？Pod？Node？搞的我好亂呀
為什麼該用 Kubernetes? 使用 K8S 的概念可以有哪些好處？真的值得我們一用嘛？好，我們知道為什麼要用了，那接下來，開從哪裡開始，我們從 K8S 的架構開始認識，了解一些重要名詞，開始我們的 K8S 之旅。
神 Q 超人
Improve Your Algorithms with this Simple Equation
這篇是關於如何改進演算法的文章，一開始看作者的解說可能會不知道他在講什麼，但是看完第一則回覆的內容後，整個人突然恍然大悟 XD，在重看一次以後覺得相當精彩！推薦各位可以看看文章裡作者如何思考問題：）
How to get your first job as a self-taught developer
文章中有給出幾個自學程式的夥伴該如何找到第一份工作？其中比較深刻的是第三點提到的「Start interviewing as soon as possible」，有許多剛開始學習程式的工程師，會對自己感到沒有方向以及徬徨，不曉得到底要到什麼時候才夠格開始投履歷面試，但其實如果你從未投出履歷，並且開始第一次面試，這個問題才會永遠得不到答案。
How does your code sound?
姑且不論 Coding 時的狀態如何，但你曾經想過自己創造的 Code 有什麼樣的聲音嗎？雖然文章中沒有太仔細描述這個 Side Project 是如何產生的（文中有附 GitHub），但是我第一眼就覺得太有趣，直接迷上！大家快一起去看你們的 Code 聽起來是快樂還悲傷！
Larry Lu
語音通訊軟體 Discord 開發語言以 Rust 代替 Go
最近很熱門的語音通訊軟體 Discord 把內部的一些服務從 Go 換到 Rust，原因是 Go 的垃圾收集器會造成一些延遲，而 Rust 用所有權的方式來管理記憶體所以沒有這個問題
身為這兩個語言的愛好者，我覺得 Discord 這麼做並不代表 Rust 比 Go 更好，Rust 在記憶體管理方面確實略勝一籌，但 Rust 也因此變得難學，間接導致了生態系不如 Go 豐富。所以真要說的話每個語言都有他的優缺點，不需要去戰語言，找到最適合自己的那個就可以了
發佈 npm 套件 - 從手動到自動 系列
這一系列文章目前已經寫到第四篇，他從頭教你怎麼發佈 npm package，並 且一步一步把很多事情都自動化掉。內容包括 rollupjs、自動化測試、Travis CI 等等，如果你對於 CI 有興趣的話我覺得這一系列很不錯
Performance Best Practices: Query Patterns and Profiling
近年來使用 mongoDB 的專案越來越多，但很多人可能不知道怎麼用好他，這邊分享一篇官方發佈的 best practice，如果你也有在用 mongoDB 的話一定要讀一讀
LukaTW
100 days practicing TDD
用一百天的時間來練習 TTD。出於尊敬 TDD 的三個法則之下，這裡是我的幾個建議 1. 你不需要測試任何的東西 2. 你可以寫多個測試錯誤的案例 3. 你不需要在你看不見錯誤的狀況下練習 TDD。還有更多內容是想要寫出好的程式碼的你會想要看的。
Learn Kubernetes, Part I, Basics, Deployment and Minikube
這是一個 K8S 教學的系列文，從基礎開始，逐一介紹各種概念與實作演練。
電影欣賞《OAuth 2.0 and OpenID Connect (in plain English)》
Oauth 大家很常用，但是真的懂了嘛，今天 qrtt1 帶來一段非常好的 Oauth 解說影片，並且將影片內容摘要成一篇文章。推！
smalltown
被 RedHat 收購後神隱多時的 CoreOS 的第一個消息是…
正式宣佈 CoreOS 要 EOL 了XD 時間點會是在 2020/05/26，所以有用的人可以準備改成使用 Fedora CoreOS 了！自從被收購之後 CoreOS 跟以前在社群的活躍程度差好多喔，感覺有點可惜…
Packer 支援 HCL 了！
這次 Packer 1.5 真的是大改版，主要的兩個大更新如下：
總算支援 HCL: 此格式一開始主要是 Terraform 在使用的，Packer 這邊一直是使用 JSON 格式，現在總算也可以用 HCL 來撰寫了，這樣寫起來順手很多，不知道之後所有的 HashiCorp 工具是不是都會往這個方向發展；不過這算是大改，所以官方希望大家先當成 Beta Feature 就好，因為 Packer 目前總共支援 33 builders, 21 provisioners, 和 20 post-processors 所以不可能一次到位，應該需要一點時間讓社群反應與發酵
變數的傳遞方式：變數可以在 Builder 和 Provisioner 間共享了，目前支援的變數有: ID, Host, Port, User, Password, ConnType, PackerRunUUID, SSHPublicKey, 和 SSHPrivateKey，假如還是不夠用的話，可以到官方的 GitHub 開個 Feature Request
Microservices 的缺點是什麼?!
近年來有很多的部落格文章，白皮書，投影片，傳教士都在宣揚微服務有多好，用了之後就會有多麼的敏捷，服務多容易擴展，只要一把架構轉換成微服務，就會有工程師來敲門說要應徵工作XD 在某些情況下，它的確有其優點，特別是在大型組織而且團隊數目眾多時，然而微服務並不是萬靈丹，它也有一些嚴重的缺點…
分散式系統其實不容易…
- Consensus: 所有分散式系統研究都嘗試在解決共識性的問題，例如: Paxos, Raft, Vector Clocks, ACID, Eventual Consistency, Map Reduce, Spark, Spanner…等，而所有解決方案都嘗試在共識性與效能間作取捨
- Partial Failure: 在單體式服務的架構下，假如今天一個 HTTP 請求失敗了，要嘛是這個服務有 Bug 或是 硬體壞掉之類的，導致這個服務有問題；不過假如當 HTTP 請求的背後是一個微服務架構，此請求將會在多個服務間傳遞，那假如在中間某個服務失敗了，那要怎麼辦？
更多有的沒的要注意…
- Development: 單體是服務可以很簡單的在本地端運行起來，不過假如是微服務的話，就要使用一堆工具來跑一堆東西才可以開始開發，例如 docker-compose 跟 minikube
- Debugging: 對於微服務來說，一個小小的請求也可能會牽涉到很多不同的服務，要除錯的時候就會很麻煩，雖然可以使用類似 Jaeger 的工具來幫忙，不過還是很煩XD
- Logging: 一定要有 ELK 或是 Splunk 這種 Log Management 系統，不然根本沒有戲唱
- Monitoring: 一堆東西要監控，上一個世代的監控工具，例如: Nagios 已經不敷使用，所以要改採用新一代的監控工具，例如：Prometheus, Datadog, Sysdig… 等
- Deployment: Chef 跟 Puppet 對於單體式架構來說還滿好用的，不過以微服務來說，可能就要使用 Kubernetes 來管理會比較明智一些
- Networking: 微服務有一大堆的 Endpiont，每一個都需要 Load Balancing, Service Discovery, Consistent Security Policy…等，光想到頭是不是就很大了XD 目前的趨勢是使用 Service Mesh 來解決類似的問題，不過好像還有一段路要走
所以從某些技術觀點來說，微服務比單體式服務來得難解決，不過從人類的觀點來看，微服務可以增進大型組織的效率，允許大公司的不同團隊可以獨立部署各自的服務；不過就像所有在資訊工程領域的事物都會有 tradeoffs 一樣，有時候你必須在組織效率和技術挑戰之間做選擇，而且最好很清楚，當你想要組織具有效率時，所面臨的技術挑戰是值得的
StarBugs Weekly
StarBugs Weekly 由一群不寫文章就會想要亂花錢，但是又沒有那麼多錢，只好繼續寫文章的開發者所創立。
內容包含 Web 前端、中端、後端、DevOps、產品開發、精實創業，一切跟產品有關的知識，都是我們的守備範圍！
Curators:
- @GQSM - Hi！我是神 Q 超人，一個先衝再說的男人。
- @Larry850806 - 我是 Larry，傳說中的 0.1 倍工程師！
- @LukaTW - 一名全身都是死角的工程師。
- @smalltown - 熱愛鑽研各種可以提升雲端服務品質及增進團隊開發效率的開源技術
Feedback
想看什麼內容，告訴我們！ 點我回饋意見