Compute Engine 是託管在 Google 雲端上基礎架構即服務 (IaaS) 產品，其他的稱呼還有 compute engine instance 、 virtual machine instance 、 VM instance。 對應其他的雲端服務是 :
- Amazon Web Services (AWS) : EC2
- Microsoft Azure : Virtual Machine
啟動前可以訂製自己需要的 Machine Type ，例如 CPU、memory、disk 等等；再來 Boot disk OS 也可自行選擇 Linux 、 Windows 等等操作系統；針對容器虛擬化，可能使用專門優化來運行容器的 Container-Optimized OS (COS) image 在虛擬機上啟動容器服務。最後關於備份資料，GCP 也有提供相應的服務來面對災難發生時的處理。
曾經在使用 gcloud CLI 時，有遇到自己錯誤理解的部分，是關於 gcloud 管理的兩組 credentials :
gcloud auth application-default login: 是用於應用程式的 credential ，此 command 會管理 GCP Client Libraries 等套件會用到的 credential 稱為 Application Default Credentials (簡稱ADC)gcloud auth login: 此 command 只會授權 gcloud CLI 工具權限，讓它可以使用 user credential 訪問 GCP 雲端資源，同時把當前的 account activate除了以上講解，這兩個還有什麼不同呢 ? 接下來再多做一些探討。
gcloud CLI 全稱是 Google Cloud Command Line Interface ，是創建和管理 GCP 雲端資源的「命令行」 工具，還捆綁了專用的子工具例如 BigQuery(bq CLI)、 Kubernetes 集群(kubectl CLI) 可配合使用，是隸屬在 Cloud SDK 內的。對應其他的雲端服務是 :
- Amazon Web Services (AWS) : AWS CLI
- Microsoft Azure : Azure CLI
雖然可以使用 gcloud 來撰寫 script 自動化執行許多常見的任務，但實務上更多是會用例如 Terraform 等 IaC 工具來部屬和管理雲端資源， gcloud 現在基本上用最多是在初始化帳戶如 :管理身份驗證(manage authentication)，或是自定義本地配置(customize local configuration)，這些如權限管理、Project 設定、Billing 有關的功能會是 gcloud CLI 主要使用的地方。
Language Server Protocol 簡稱 LSP ，是微軟於 2016 製定的 Protocol 協定，專門用來輔助 Visual Studio Code 開發用的，目標是讓 Code-Editor 能便利地支援更多的程式語言。設計理念是把語言撰寫領域模型如：自動補全、引用定義、類型檢查器等等，這些提供輔助功能的部分拆出去用「公定的介面」來做溝通，給各自領域的人開發。
LSP 專門用於描述 Code-Editor 中，用戶行爲與響應之間通訊方式和傳輸資料結構，像是 VSCode 的 IntelliSense 提供的 auto-completion 就可以基於這個協定支援更多不同的 coding language。 現在支援 LSP 的 Code-Editor 也不少，除了 VSCode 還有 Eclipse 、 Vim 、 NeoVim 都已經支援了，可以在 langserver.org 可以看到各個 client 的支援狀況。
「 整合式開發環境 Integrated Development Environment 簡稱為 IDE 」 ，是一種程式開發軟體，通常只針對特定語言，且有應用程式生命週期管理（Application lifecycle management）簡稱 ALM 的功能 ; 另一方面「 文字編輯器 Text Editor 」通常只提供如複製、剪下、貼上、搜尋、取代等文字操作功能，但現在兩者已經沒有區分的這麼明顯了，原因就是 VSCode 的出現很大了融合了兩者。 VSCode 其定位採用核心是 <Text Editor + code understanding + debug>，並以檔案夾作為專案管理，保持輕量與高性能，但還是提供強大的支援語法。
與許多程式編輯器一樣，VSCode 也採用通用 layout，設計理念是希望可以提供簡單直覺的排版，讓使用者可以直觀的選取檔案並閱覽、編輯檔案，本文章首先討論 Workbench 的定義和介紹 vscode layout 的各個名稱。
Visual Studio Code 簡稱 VSCode ，是微軟 2015 年開源的輕量化 code editor ，基於 Electron 並用自家雲端的編輯器 Monaco Editor 作為其底層開發，支援多語言及平台且使用 TypeScript 來進行編寫，也提供了強大的外掛程式拓展機制給人加強功能。VSCode 的開發是由 Eclipse 之父 Erich Gamma 領導（ Erich 也是《設計模式》作者之一），在 2019 年的 Stack Overflow 開發者研究中，其獲選最受歡迎的 code editor 有
50.7%的使用率，且還在持續增加當中。
當要建立新專案時，都會需要決定一些關於基礎的架構或開發規劃的事項例如 :
- 設計 folder structure
- 打包編譯工具的選擇
- IDE 預設環境配置；IDE plugin 或 extension 的安裝
- CI/CD、IaC 設定或工具選擇
每次建立專案時都會參考之前的架構規劃，然後手動複製架構雛形，重新設定參數，其實不太方便… 這時就可以引入 Scaffold 這樣的模坂概念，來直接生成專案的骨架。本質用意是把那些重複地創建專案基礎結構、專案規格流程取代掉，實現 DRY (Don’t Repeat Yourself) 原則。而 Yeoman 就是一個著名 scaffolding generator tool，微軟官方維護 Visual Studio Code extensions，就是裡面非常著名的例子。
Homebrew 是一個廣泛使用在 MAC 上的套件管理工具，可以安裝一些 Mac App Store 上沒有的軟體，其操作十分方便，可以簡化軟體安裝的過程，是個很有名的非官方工具，由 Max Howell 以 Git 和 Ruby 為基底寫成，並通過 GitHub 維護，為 2012 年 GitHub 上擁有最多新貢獻者的專案。對於其作者也有個有趣的軼事：Max Howell 曾應聘過 Google 的職位，面試失敗之後在 Twitter 上發文章 :
- Google: 90% of our engineers use the software you wrote (Homebrew), but you can’t invert a binary tree on a whiteboard so f*** off.
因此在網上引發了面試白板題的討論。
現在越來越多的服務應用使用 Protobuf 來作為資料交換的格式，它被廣泛應用於 RPC 調用和資料存儲。 Protobuf 語言中立、平臺中立，只要定義好一份 .proto 檔案，就可以生成不同的程式語言來處理資料的序列化或反序列化。要了解 Protobuf 序列化/反序列化，首先需要了解一些知識點 :
- Varint Encoding
- Zigzag Encoding
- Wire Type 類型
- T-L-V 儲存方式
熟悉這些可以更加理解 protobuf，也能避免錯誤使用，以及更好的優化性能。本章節會實際把前面學到的知識點一次用上，用實際案例來了解 Protobuf - Serialization。
隨者網路傳輸、頻寬與硬體的設備的改善和增強，能傳遞資料量也越來越大、越來越複雜，這時我們也不再只是追求能夠將資料傳遞完成，而是更加要求短時內傳遞大量的資料，故勢必會需要強化序列化和壓縮的技術。這篇會介紹 Protobuf 編碼後的 byte array 結構，以及會這樣設計的思路，當有了基本的認識後，就會明白 Protobuf 為何它可以比 JSON、XML 傳輸效率更高，更能壓縮資料，實現高效率。
