軟體主廚的程式料理廚房

前幾天處理了一個檔案沒更新的問題，請看下圖：

這是一個 UNC 路徑，可以看到它路徑中間有兩個 \，然後它就爆了。

會造成這樣的原因是因為在原始程式碼中，在兜路徑的時候沒有處理尾綴的 \ 的數量，而使得尾綴的 \ 多了或少了，路徑就失效了。

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

這個雷我踩了不下三次，寫下來記錄一下，C# 程式要取得當前目錄的方法我們下關鍵字搜尋可以搜出一堆解決方案，沒意外的話第一個搜尋結果通常是 Directory.GetCurrentDirectory 方法(System.IO) - MSDN - Microsoft，但是這個方法在程式是由 Windows 工作排程器（Task Scheduler）啟動的狀況下就不 Work 了。

如果我們認真要用 ASP.NET MVC 做一個對外服務的網站，直接赤裸裸地爆黃白畫面在使用者面前，實在不是那麼優雅，如果從 Web.config 著手要自訂錯誤畫面的話，那麼 Google 到的答案大致就兩個方向：<system.web>/<customErrors> 及 <system.webServer>/<httpErrors>。

Html.Action、Html.RenderAction、Html.Partial、Html.RenderPartial 這四種方法都可以協助我們在 View 裡面渲染部分 HTML 內容，網路上針對這四種方式的差異說明大都著重在使用方式，但這次我們往下挖，看看這四種方式做了些什麼事？

上一篇文章提到依賴，依賴也無所不在，而 DIP 要我們將依賴做「反轉」，是要反轉什麼？反過來依賴嗎？　當然不是，而是解除直接依賴的關係轉而去依賴於抽象介面，使得位於較低層次的類別依賴關係的方向反了過來，大致上看起來就會像這樣。

DIP - Dependency Inversion Principle（依賴反轉原則）說：

1. 高層次的模組不應該依賴於低層次的模組，兩者都應該依賴於抽象介面。
2. 抽象介面不應該依賴於具體實現。而具體實現則應該依賴於抽象介面。

如果是初次接觸到這段說明的朋友可能會有一個感覺，就是裡面每個字都看得懂，但是它在講什麼？要了解 DIP 要先清楚它這邊提到的依賴是什麼？我就以我個人的理解來分享我的心得。

Isolate Scope 使用在重用的組件是非常適合的，如果只是單純地想在 Directive 中避免直接操作 Controller 範圍的屬性或方法，希望定義一些別名在 HTML Element 中與 Controller 的屬性或方法織在一起，應該避免使用 Isolate Scope。

用 AngularJS 開發程式很少不用額外撰寫 Directive，如果我們在 Directive 裡面使用 Isolate Scope 並且從 Controller 指定了一個 function 為觸發函式（&），好死不死這個 function 是需要丟參數給它的，按照一般正常的丟法是不會 work 的，想要丟參數給觸發函式需要一點迂迴的做法。

憶起第一次執行自己寫的程式的感動，到現在都還記得，當時用的語言是 VB，在 IDE 上開了一個 Form 拉了一個 Button，按下去之後跳出 MsgBox 顯示 "Hello World"，內心不斷地給自己鼓掌「哇！我也會寫程式了。」，至今有沒有曾經後悔過走這條路已經忘記了，但是程式設計「賜我吃、賜我穿、賜我借錢可以還。」是個事實，講這些跟這篇文章的主題有什麼關係？