第 131 期 - 五月來了,今年夏天到底要不要出去玩?

本週專欄

跟著高手的腳步「軟體工程師的修煉與成長」學習筆記

本篇文章是閱讀 vgod 撰寫的「軟體工程師的修煉與成長」系列文的心得筆記。
這一系列文章真的相當地精采,從來沒有人這麼有系統地分享矽谷頂級公司各職等需要具備的能力與心路歷程。

前端開發

The Array Methods Coming to JavaScript in 2022

在 JavaScript 裡,大部分的 array methods 都可以從原本的 array 再複製一個新的 array 出來,像是 map 或 filter 等等,這些操作都不會影響到原本的 array,不過還是有些像是 sort 或 reverse 等執行都還是會改變原有 array,為了改變這個狀況有些提案這麼誕生,且進入提案的第三階段了!

18 GitHub Repositories to Become a CSS Master 🎨🧙‍♂️

這篇文章對於想學習 CSS 的人來說真的是大秘寶,裡面提到的 repo 都用自己的方式在講解關於 CSS 的知識、概念或技巧,那如果一個 repo 不夠看怎麼辦?文章裡可是列出了 18 個!

大菠萝?Pinia已经来了,再不学你就out了

Pinia 是在 Vue 框架內,除了 Vuex 外的另一個 state 管理工具,在 Pinia 的 README.md 中,也直接說明了 Pinia 就是 Vuex 的後繼者,那它在使用上和 Vuex 有什麼不同呢?一起看看文章中的用法介紹和下方的留言討論吧!

Book 好書推薦

97 Things Every Programmer Should Know

這週要來跟大家推薦我覺得幾本很不錯的書,首先是 O’Reilly Media 出版的「程式設計人應該知道的 97 件事」,這本書一開始也是同事推薦我的,讀了之後覺得真的很不錯,裡面會講到「你應該用什麼心態來做 Refactor」、「如何選擇工具」等等很重要的問題。雖然 97 件事聽起來很多,但每件事情平均大概就兩三頁,所以有時候搭個公車捷運就可以看完一件事了,比起滑手機讀書應該有意義多了對吧~

《A Philosophy of Software Design》心得 I — 寫出複雜度低的軟體

這本 “A Philosophy of Software Design” 感覺也是很好看的書,但我還沒時間去看他,所以先看看別人的讀書筆記XD。一般來說當一個專案隨著時間的推移,程式碼變得越來越多時,當中也業務邏輯也會逐漸變得複雜,累積久了之後甚至會到難以修改的程度。既然如此,那要怎麼在一開始設計時就避免這種情況呢?看完這兩篇心得有興趣的話再去網路上找來看吧~

[The Effective Engineer 翻譯筆記] Introduction

這本 “The Effective Engineer” 也是網路上可以找到的,他主要是在講說你要怎麼成為一個高效率的工程師(就跟書名一樣XD),像是我非常認同的一點就是「你必須不斷改善、並且熟悉你的工具」,因為你的終端機、編輯器、Git 等等都是你每天會不斷使用的工具,所以記得要把它調整到最適合你的狀態,譬如說常用的快捷鍵、設定 Alias 等等,雖然省下來的都是小小的時間,但累積起來也是非常驚人。除了個人之外,也要成為可以增進團隊效率的工程師,譬如說把一些東西寫成腳本、把新人該知道的東西寫成文件,否則每次有新進員工都要到處問半天,無形中也增加了非常多的時間成本。

後端開發

SQuriL: Generate and Store Your GraphQL Schemas

GraphQL 是讓 API 對既有資料實現強大搜尋功能的語言與 Runtime,他提供了一個相對於 RESTful 的替代方案,讓開發者可以使用單一個請求來對多個資料來源獲取資料;雖然 GraphQL 的優勢顯而易見,但有許多的公司尚未將查詢語言整合到既有的技術棧當中,對於這類公司來說要採用 GraphQL 的門檻相對地高,SQuriL 就是為了解決類似問題而生的解決方案,他是一個開源的 GraphQL Schema 生成和儲存工具,可以從 PostgreSQL URI 來產生客製化且具備可以 Production 環境使用的 GraphQL Schema 給 Node.js 和 TypeScript 相容環境使用,有興趣的人可以參考這篇文章看看如何使用它

Improving Query Performance by 10000x

當你嘗試從系統中獲得更多資訊時,你的應用程式是不是也變得更慢了?你並不孤獨,雖然有人說過不要過早去優化系統,但在某些時候,你還是必須要花點時間去研究看看如何提高系統效能,作者所在的 Sky Ledge 最近遇到類似的問題…一個簡單的 Query 本來預期在 1 秒內就要跑完,但在 Staging 環境花了將近 30 秒才取得回應,作者後來花了兩個多小時將問題解決掉!文中巨細彌遺地慢慢解釋他怎麼用科學方式去分析找到問題的過程還滿值得參考一下的

System Design — Design a Monitoring System

如何設計一個監控系統?這個問題應該滿常會在面試中被提問到,首先必須考量的點在於如何收集 Metric,是要用 Pull 或是 Push 模式,假如使用 Pull 模式的話要怎麼去設計 Exporter;而一個監控系統應該要具備擴展性,那麼要如何達成?儲存資料的 DB 要怎麼設計…等,這一連串的問題,作者用一篇文章來含括與回答,讓大家可以更清楚的理解監控系統的設計

DevOps

New Relic Report Shows Lots of Java Apps Running in Containers

2022 年 New Relic 報告指出許多組織 Java 服務逐漸轉換成 container,而且每個服務有變微服務的趨勢。整體而言,Java 11 佔將近 48%,然而 Java 8 依舊佔了 46%。另外 Java Development Kit(JDK)也有增加的趨勢,在 AWS 上跑的 Java 服務 JDK 佔了 22% 而 Oracle 佔了 35%,與 2020 年相比,Oracle 曾經有 75% 的佔比。除了 Java 程式本身,也討論了大型企業雖然很慢但還是有在做變化甚至從地端轉化到雲上,幸好許多 Cloud Native 工具像是 OpenTelemetry 可以幫助組織監控服務的狀態,讓企業轉化可以更順利,並且以後 Open Source 跟商用軟體混用會更盛行。

Kubernetes volume backup for disaster recovery

作者解釋 Kubernetes 災難復原雖然已經有 Velero 備份 volume,但是 Velero 每次都是完整的備份,當資料越來越多時恐會影響到復圓所需的時間(RTO)。作者幫大家複習 PV、PVC、StorageClass 以及比較新的 VolumeSnapshotContent、VolumeSnapshot 和 VolumeSnapshotClass 技術概念,之後 demo 如何在兩個不同 region 的 Cluster 之間靠 snapshot 複製 volume。

Dockershim not needed: Docker Desktop with Kubernetes 1.24+

自從 Kubernetes 宣布棄用 Docker 後震驚業界,社群開始考慮其他替代方案,但其實 Docker 還是有推出新的 cri-dockerd 版本,也就是使用標準的 CRI 所做的 interface,這樣 Docker 跑起來跟其他替代方案無異了,以前的流程是:

kubelet -> cri-dockerd -> dockershim -> docker

新的版本則是可以不用 dockershim 了:

kubelet -> cri-dockerd -> docker

StarBugs Weekly

StarBugs Weekly 由一群不寫文章就會想要亂花錢,但是又沒有那麼多錢,只好繼續寫文章的開發者所創立。
內容包含 Web 前端、中端、後端、DevOps、產品開發、精實創業,一切跟產品有關的知識,都是我們的守備範圍!

Writers:

  • @HannahLin - 從台灣到矽谷,熱愛前端的工程師女孩。
  • @KyleMo - 雜食性軟體工程師,喜歡的技術我都想學。
  • @Airwaves - Hi~我是 Airwaves,熱愛研究如何造輪子的前端工程師。
  • @Jenny - 我不寫 CSS。
  • @Andy - 目標成為用嘴巴工作的工程師,專長為網頁開發以及 K8s。

Maintainers:

  • @GQSM - Hi!我是神 Q 超人,一個先衝再說的男人。
  • @LarryLu - 我是 Larry,傳說中的 0.1 倍工程師!
  • @LukaJoJo - 一名全身都是死角的工程師。
  • @smalltown - 熱愛鑽研各種可以提升雲端服務品質及增進團隊開發效率的開源技術。
  • @RicoChen - 熱愛許多技術且努力看透技術的本質,如果有什麼好玩的技術,還請各位歡迎直接找我聊聊。

Feedback

本週呈現主題方式做了一些改變,希望讓讀者能夠更快速精準的找到自己要的資訊。也加入社群活動這個區塊,每週更新社群活動的資訊。如果有任何建議,歡迎私訊 星巴哥技術週刊 FB 粉絲專頁 與我們聯繫。