軟體主廚的程式料理廚房

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() 方法不是只能修剪空白字元而已。

由於 CPU 時脈的發展受限，因此 CPU 的發展不再往更高時脈前進，而是往更多核心數前進，隨之而來的，便是軟體設計師需要調整軟體的設計，讓原本的演算法能夠分散執行，充分地利用多核心的資源，使程式執行起來更有效率，而在開發分散式運算應用程式時，我個人是認為應該加入不可變性（Immutability）的設計，來強調其分散式運算的意圖。

有一些網頁的內容是有時效性的，甚至有一些操作是不可逆的，但是瀏覽器的歷程記錄（History）卻會逆轉這些特性，在使用者按下「上一頁」的那一刻，不該出現的卻出現了、不該消失的卻消失了，怎麼會這樣？

觀察到使用者不時地被一個小問題給困擾著，在表單中編輯一些資訊後，突然岔去做其他事情，回來之後覺得剛剛的表單應該已經處理完了，就把網頁給關掉了，殊不知他剛剛編輯的資訊並沒有儲存，往往發現時，是已經被客訴了，要解決這個問題有很多面向的方式，系統這邊能幫的其中一種方法就是提醒使用者資料沒有儲存。