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 傳輸效率更高，更能壓縮資料，實現高效率。
蠻多 coding 語言在一般情況下是使用
32 bits的空間來儲存整數的，例如 Java 的 int，範圍是-2147483648 ~ 2147483647，大約正負21億。但是現實世界中，較小的數字往往比較常出現，大約幾十到幾十萬是最多最常出現的，如果只是要儲存或傳輸這樣的一個小數字，卻每次都需要用到 32 bits 的空間，其實有點浪費，這是有機會優化的 !Varint 和 Zigzag 演算法就是要處理這種問題，讓值小的數字，可以用較少的 byte 數量表示，而達到資料壓縮目的，著名的資料傳輸格式 Protobuf 也是通過 Varint 和 Zigzag ，來大幅減少了資料佔用的空間。
Protobuf 全稱 Protocol Buffers ，是一種輕量級的資料交換格式，最初是由 Google 開發的「可擴展的序列化資料結構」，現已成為一個開源項目，其語⾔中⽴且平台無關，適合高性能且對響應速度有高要求的資料傳輸場景；也因為有資料壓縮的能力，故也可用於資料儲存。Protobuf 的核心思想是先定義好 data schema ，然後可根據所需的語言生成對應的 code base，方便使用者操作 :「序列化寫入、反序列化讀取」。
Profobuf 需要注意的缺點是為二進制格式，故編碼之後不具有可讀性，需要反序列化後才能看得懂資料內容 ; 雖然是個好東西，但並非是個用來完全取代 JSON 的解決方案，JSON 仍有其可讀性高、易操作及通用性高等優點，在多數 API 設計的場景之下，JSON 仍然是最好的選擇。
OpenTelemetry ，也稱為 OTel，是 Cloud Native Computing Foundation(CNCF) 下的一個開源專案，為一供應商中立(vendor-neutral)的可觀測性框架，目的是提供一個標準化Observability 的 pluggable 框架，解決 telemetry data 的模型定義、檢測、採集、處理、輸出等一致性問題。
借助 OpenTelemetry ，可以從各種來源收集 telemetry data ，但對於資料的存儲和可視化是留給其他工具的，本身並不提供儲存，只能將其發送到其他的服務來存儲，如 Prometheus、或其他雲端廠商服務。
