軟體主廚的程式料理廚房

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

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

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

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

前些日子開了一台新的 SQL Server，最近從監控當中發現凌晨 02:10 ~ 02:30 之間 CPU 被拉高，日復一日都是相同的時間點。

看起來吃了不少 CPU 資源，由於這段時間嚴格來講並不算是服務的離峰時間，還是希望將珍貴的 CPU 資源留給服務，所以必須查出來到底是誰吃掉了 CPU 的資源？

我個人認為 SQL Server 預設拿主鍵（Primary Key）來當叢集索引（Clustered Index）欄位這件事情，應該要被重新考慮，以目的來講，主鍵與叢集索引的關係其實並不大，主鍵的目的是確保資料是唯一且正確的，而叢集索引的目的是提升查詢效率，所以在這點上，我覺得在資料表一個開始設計的時候，預設是分開考量的會比較恰當。

用過 Dapper 的朋友應該對它是愛不釋手，最近在一個對效能敏感的系統上 tune SQL 查詢語句時，發現到 SQL 參數型別的不同及使不使用 SQL 參數，對執行計劃的選擇影響甚大，相同的查詢條件及結果，只因改了參數的型別，執行計劃就跟著改變，查詢成本也跟著拉高。

在 SQL Server 可商用的版本中，Express 及 Web 版本是唯二沒有完整 Replication 的版本，但是一個免費、一個便宜，對於老闆來講這是一個可以節省成本的點，如果真的有 Replication 的需求，除了升級之外，我們還可以寫點程式自己土砲。

公司內的一個系統的開發風格轉變，Data Model 必須設計成 Immutable（不可變）的類別，其中一部分會被用在泛型上，由於 Immutable 類別是不能有無參數建構式的，所以被用在泛型的時候，它就不能用 where 進行 new() 的條件約束，沒辦法做 new() 的條件約束，就無法呼叫泛型類別的建構式來產生 Instance，著實困擾。

手上或所處的資訊環境如果有一些舊硬碟，在還堪用的情況之下，應該會希望能持續發揮它的價值直到它生命的最終點，微軟從 Windows 7、Windows Server 2012 R2 開始就內建軟體式的 RAID 功能，有 JBOD、RAID-0、RAID-1、RAID-5 可以選擇使用，已經能滿足大部分的需求了。