如果我們明確地知道我們的服務尖峰及離峰時間，那麼我們可以在離峰時間關閉一些機器來節省一點成本，GCE 沒有提供排程開關機的設定，所以我們只好自己寫，Google APIs 的文件告訴我們可以選擇純 HTTP 方式，或是使用 Google APIs Client Library 來控制 VM 的開關機，底下我就用 Google APIs Client Library for .NET 來撰寫控制 VM 開關機的程式。
在狀態表達的設計手法中，有一種是以 2 的 n 次方來設計，例如：Status1 = 1、Status2 = 2、Status3 = 4、...依此類推，當我們得知某物件的 Status = 5，我們就知道它包含了 Status1 以及 Status3（因為 5 = 1 + 4），.NET Framework 中有一個列舉型別 System.Reflection.BindingFlags 就是這樣設計的，那重點來了，我們要怎麼知道任意一個正整數可以由哪些 2 的次方加總結果呢？
[料理佳餚] C# 實作二階段提交（Two-phase Commit），即使 SQL Server 沒有啟用 MSDTC 也能做分散式交易。
無論是業務需求或是 IT 需求的關係，依據不同需要將資料庫分放在不同伺服器的情形很多見，要進行跨資料庫伺服器交易我們可以啟用 MSDTC 服務來達成，我就在想能不能不去動伺服器的設定，在應用程式端來實現分散式交易？
分散鎖定的使用場景通常是我們希望某個資源，同一個時間存取它的程序不要超過一個，在同一個應用程式中我們有 lock 陳述式、Monitor.Enter、Monitor.TryEnter 可以用來做鎖定，當有一個以上的應用程式，甚至是跨不同機器的應用程式要做鎖定，這個會需要用到額外的資源，我們儘量利用我們手邊有的資源來做這件事。
[小菜一碟] 檔案目前位置取得方法的不同，而不是不同的檔案目前位置取得方法。
在這篇文章中網友的留言吸引了我的注意，.NET Framework 提供了至少三種取得檔案目前位置的方法：
我還真不知道它們具體上的差異，趁這個機會做了一下實驗順便記錄下來，也提供給各位朋友參考。
Base64 各位朋友應該都有聽過，也使用過，但是 Base32 或許就比較少了，而且 .NET Framework 也沒有內建 Base32 的 API，會碰到 Base32 是因為有一個需要編碼結果全小寫的需求，顯然 Base64 並不適合，.NET Framework 又沒有 Base32 可以用，那就只好自己來寫一個了。
多型在像是 C#、爪哇（用中文應該就不會被告了）這種強型別的物件導向程式語言，要將一個抽象類別的實例存到關聯式資料庫或是做序列化／反序列化，都需要另外處理，關於多型跟關聯式資料庫的對應方法我已經寫在這篇文章裡面，這篇要來寫寫多型如何做 JSON 的序列化／反序列化。
我們呼叫一個函式原則上以回傳一個結果為優，偶爾像 int.TryParse 使用 out 修飾詞，或是使用 Tuple 類別 來多吐一些結果，不過這些都不如將多個結果封裝成一個類別還來的合適，但是如果私有函式有回傳多個結果的需求，為此定義一個類別就顯得有些雞肋，除了要取一個適當的名字之外，還要定義它的存取限制，把它弄成 public 也不是，弄成 private 放在當前類別裡面又覺得「嘖...」。
[食譜好菜] 檔案及資料夾的路徑不用自己兜，讓 System.IO.Path 靜態類別來做會方便許多。
前幾天處理了一個檔案沒更新的問題，請看下圖：
這是一個 UNC 路徑，可以看到它路徑中間有兩個 \，然後它就爆了。
會造成這樣的原因是因為在原始程式碼中，在兜路徑的時候沒有處理尾綴的 \ 的數量，而使得尾綴的 \ 多了或少了，路徑就失效了。
這個雷我踩了不下三次，寫下來記錄一下，C# 程式要取得當前目錄的方法我們下關鍵字搜尋可以搜出一堆解決方案，沒意外的話第一個搜尋結果通常是 Directory.GetCurrentDirectory 方法(System.IO) - MSDN - Microsoft，但是這個方法在程式是由 Windows 工作排程器（Task Scheduler）啟動的狀況下就不 Work 了。