軟體主廚的程式料理廚房

gRPC 服務預設會使用 HTTPS，不過這個只有針對 localhost 這個網域名稱，這天我想要將自己的區域網路 IP 指定為 gRPC 服務的端點，好做一些驗證跟測試，於是我就動手修改了 Kestrel 監聽的 IP，使用的是 HTTP 協定，然後就在客戶端收到了這個錯誤訊息。

IOException: The response ended prematurely.

自從更新了 Windows 10 1903 之後，事件檢視器就經常爆出 ESENT 事件識別碼 455 的錯誤，是不影響平常的操作，但是這個錯誤實在太多了，多到整個事件檢視器有三分之二的空間都是這個錯誤，影響到查找其他錯誤的效率。

gRPC 服務底層使用 Protocol Buffers 做為序列化的格式，與我們經常使用的 JSON 格式相比之下，其大小已經小非常多了，如果我們還覺得不夠，想要再更進一步地減少傳輸量，可以啟用 gRPC 服務的壓縮（Compression）機制，讓傳輸的資料量再更少一些。

SQL Server 的資料型別中有一個 float，這個 float 在 C# 對應的應該是 double，而 C# 的 float 對應的 SQL Server 資料型別應該是 real，那如果將 real 對應成 C# 的 double 會發生什麼事？　答案是小數點的精準度會跑掉。

Azure App Service 中有一個 WebJob 功能，它可以讓我們上傳執行檔或指令碼，然後利用 App Service 的資源來長時間或排程執行，不需要另外開一台 VM，我們原本就已經有開發好的應用程式，改都不用改，直接打包成 zip 檔上傳就能執行，相當方便，但是我們要怎麼傳遞參數給我們在 WebJob 的應用程式？

Google Search Console 從 2019/09/13 開始就報了一個 「id」欄位未填（Missing field “id”）的錯誤，影響網站的頁面有三萬多頁，這不得了。

仔細查看發現是麵包屑出了問題，麵包屑是 SEO 的重點之一，它出了問題是會影響網站的搜尋排名。

這天在追查為何 A 客戶的訂單會出貨到 B 客戶哪裡去？　於是我看到了下面這段程式碼：

在 Login 的 Action 上面被加了 OutputCacheAttribute，Duration 屬性被設成 3，其中還用到了 VaryByParam 屬性，我猜寫這段 Code 的工程師應該是想要為每個登入的帳號做 OutputCache，這樣設定沒有問題，問題出在 HTTP Request 的發送內容。

gRPC 全名叫 gRPC Remote Procedure Calls，是一個由 Google 開發的 RPC 框架，基於 HTTP/2 協定及 Protocol Buffers 序列化協定設計而成的，主打著高性能、跨平台、跨語言（這一點頗吸引我），我們可以將 gRPC Host 在 ASP.NET Core 上做為一個服務發佈出去。

C# 從 7.0 開始加入了模式比對（Pattern Matching），最大的改變是將 switch 從常數比對中解放，讓 switch 可以比對運算式，到了 C# 8.0 更猛了，微軟弄了一個遞迴模式比對（Recursive Pattern Matching），大括號 "{}" 及小括號 "()" 寫到你不要不要的，但是模式比對裡面藏了一個 var 的陷阱，我就踩中了。

我們平常在做字串修剪的時候，一定會常用到 Trim() 方法，我們通常拿它來修剪一串字串的前後空白字元，相同的家族成員還有 TrimStart() 及 TrimEnd()，如果我們還想修剪掉其他字元，我們可以使用 Trim(Char[]) 這個多載方法，但是 Trim() 方法不是只能修剪空白字元而已。