在 Docker Compose file 3 下限制 CPU 與 Memory 這幾天某個 job 在進行最終階段測試時發現用到的某個 container 會出現 cpu high 的現象，而且狀況嚴重到會讓 docker process cpu 衝到 400% 以上，接著 docker service 掛了 XD

Test 中驗證 Object 是否相同的方法 最近花了不少時間在重構先前專案中的 Unit Test 與 Integration Test，其中對於 reference type 的物件比對有幾種不同的寫法 當然我個人大多配合團隊規範

從 Mac 移除 .NET Core Runtime 與 SDK 可以不時更新 .NET Core SDK 是幸福，也是痛苦; 幸福的是可以使用新的語言特性或是新功能，而痛苦的是不僅又有新的 feature 要學習適應還要想辦法移

在 Docker for Mac 上啟用 Kubernetes 現在工作的部暑都是透過 Kubernetes 來執行，不過我還是常常會卡東卡西，又不能老是使用團隊環境來練習，加上工作內部的資料也無法部署至自己建

使用 Homebrew 安裝 Docker 現在工作上都是使用 mac，但為了保留可以比較 macOS 與 Windows 在部份行為上的差異，自己的家用電腦一直都是 macbook pro 使用 bootcamp 開機直接進入 Windows 10，最近因

在 Kubernetes 上使用 Helm 安裝 Istio 其實對於 Istio 到底解決了什麼問題，我沒有把握可以講得很清楚，就我粗淺地理解是為了更有效地簡化 Pod 間的溝通與管理，但好壞都要等實際

透過 Kubespray 在 Kubernetes 上安裝 Helm 經過一段時間的發展 Kubernetes 目前是 container 調度工具中最受重視的，不過 Kubernetes 只是用來管理 container 的調度，該如何決定調度的計劃以及內容就成了新課題，而

透過 Kubespray 來架設 Kubernetes 最近剛好有機會可以參與專案的部署作業，雖然過去也持續進行過不同方式的 CI/CD，但真正部署至 Kubernetes 上則是全新的體驗，為了降低扯團隊

gRPC stream 如何傳送單一大物件 之前筆記 C# 搭配 gRPC 中使用 stream RPC 提到為了對於較大資料量以及即時性資料內容，可以透過 gRPC 的 stream RPC 來處理，不過官方範例是用在傳送 repeated 內

C# 中使用 Protocol Buffers 協定來序列化與反序列化物件 專案上剛好需要將 object 進行序列化，過去常用的方式都是序列為 json，後來同事覺得既然都使用 protobuf 了，為什麼不直

ASP.NET Core WebAPI 回應 406 Not Acceptable 照著之前筆記 從 Empty 建立 ASP.NET Core Web API 從空專案開始建立 ASP.NET Core WebAPI ，過程中一切順利直到開始加入商業邏輯時卻出現意料外的錯誤，雖然事後覺得我應

從 Empty 建立 ASP.NET Core Web API 之前曾經在筆記 建立ASP.NET Web API 專案的幾種方式- Yowko’s Notes 提到專案的起源分為兩派： 使用 Empty 專案範本再手動安裝需要的 framework 直接使用需要

gRPC 出現 8 RESOURCE_EXHAUSTED 錯誤 隨著系統一步步成形，資料量也愈來愈大，在原本只是先求功能正常而未進行資料分頁的功能逐漸露出原型，今天就來筆記 gRPC 在傳送龐大資料可

在 ASP.NET Core 中將 log 寫至 GCP 的 Stackdriver 之前剛好有個功能在內部環境運作時都一直出現錯誤，經過一輪測試後決定將功能搬至 GCP 的 GKE 上執行來確認問題是不是內部環境設定所

嘗試為gRPC 中的 stream RPC 加上 Unit Test 之前筆記 C# 搭配 gRPC 中使用 stream RPC 紀錄到在 gRPC 中使用 stream RPC 的操作語法，但實際應用在專案上時卻卡關，主因是單元測試出現錯誤，