軟體主廚的程式料理廚房

無論我們是要引用網站的資源，還是做重新導向，除非是外部的資源，不然使用相對路徑絕對是優選，在 ASP.NET 的世界裡面我們用來表達根目錄有人會用 /（Slash），有人會用 ~/（Tilde Slash），但它們兩個的差別在哪？

XPath 發佈已經快 20 年了，在 Lambda 運算式 出世之前想要選取 XML 節點，XPath 的語法是一定要去了解的，至今仍然還是有可能會遇到無法使用 Lambda 運算式的情況，例如：.NET Framework 2.0 的專案，底下列幾個我常遇到的需求範例。

程式的生命週期往往比我們想像中的長，通常年紀愈大的程式包袱愈重，後面接手的人肩負的壓力也愈重，如果我們知道有一個字串叫 http://www.xxx.com ，現在因為政策的關係必須改成 https://www.xxx.com ，偏偏 http://www.xxx.com 被到處寫死在資料庫及程式原始碼裡面，除了把寫死的那些找出來改之外，我們還可以怎麼做？

天有不測風雲，人有旦夕禍福；服務在走，HA 要有，先前有介紹過使用 Redis-Sentinel 打造 Redis 的 HA，當時只完成了伺服器端的設定，這次要介紹如何在應用程式這一端也完成自動 failover，以維持服務的 HA。

為了讓搜尋引擎多認識我們的網站、提昇搜尋結果的排名，大都會做 SEO（Search Engine Optimization），其中有一條規則是要讓網址保持一致性，避免相同的網頁內容使用不同的網址，導致網頁的瀏覽量被分散，因而讓搜尋引擎認為我們的網頁內容沒什麼人要瀏覽，使得該網頁的權重下降而影響排名，如果是全新的網站，我們大可配合 SEO 來調整設計，可是如果是已經被蹂躪過的已存在網站，又剛好是 Host 在 IIS 上，該怎麼辦？

實行敏捷開發的團隊大部分都會用 User Story 來梳理使用者的需求，依照團隊的情況，每個團隊實行的方式也不盡相同，看起來差不多，可是細節卻有差。

User Story 看似簡單，操作起來卻有很多地方需要注意，一不小心很容易成為災難一場，不僅徒勞無功，又累死三軍，下面記錄我最近一次使用 User Story 的經驗，過程多少有一些操作得不是很好的地方，把它寫下來後，希望可以做為我未來調整及修正的方向。

Redis 到目前為止都還是以單執行緒的方式在執行，要多個 Redis 就要多設定幾個 instance，這樣如果 Redis crash 了怎麼辦？預設我們可以從 master 的設定檔去設定 slave 是誰，但是 slave 預設是 read-only，而且當 master crash 的時候，不手動做 master、slave 的身份互換，slave 是無法接手 master 的工作，這時候我們可以利用 Redis 內建的 Redis-Sentinel 的工具來解決 failover 的問題。

Windows 7 下用 VirtualBox 5.0.10 r104061 版本安裝 Windows Server 2012 R2 的 VM 時發生 Error In supR3HardNtChildWaitFor 錯誤訊息。