軟體主廚的程式料理廚房

先前有寫過一篇文章 - 將 ASP.NET MVC 的 View 依使用者角色來拆分可以減少邏輯分支，在留言中 demo 哥有提到用 Display Mode 也可以漂亮地解決，於是我就試著把這樣的需求用 Display Mode 來實作，實作之後我必須說，程式碼真的可以少寫一些。

隨著業務的增長，應用程式要處理的需求愈來愈多，也愈來愈細，需求間的依賴關係也會變得複雜，當使用者也隨之增加的時候，應用程式也需要進行拆分及擴展，因此我們需要一種設計方法，來引導我們針對高併發、分布式、需求多又細又複雜的應用程式來進行設計。

Topshelf 這個套件在網路上隨便搜尋，不管國內外都有很多文章在介紹它，我是直到最近才開始跟它有更親密的接觸，利用它我們可以很容易地將 Console 程式 Host 成 Windows 服務，變成 Windows 服務之後我們的應用程式就擁有了透明且可控的生命周期。

我們對於 Message Queue 的既定印象就是先進先出，先發送的訊息就先傳遞出去，這兩天收到一個需求是希望通知能夠在指定的時間傳遞出去，以往這類型的需求我們會跳過 Message Queue，改用定期去看資料庫或是某個資料夾，如果有資料或檔案內容的指定時間符合當下的時間，我們就發送通知，但我現在想讓 Message Queue 處理延後傳遞的訊息。

不知道曾幾何時，我慣用的 DNS 伺服器變成中華電信 hntp1.hinet.net，其 IP 位址變成 2001:b000:168::1？

這個對於一般的使用者而言，其實沒有任何影響，但是對於我而言，我的使用環境有自建的 DNS 伺服器，以及自己架設的一些開發機器，這些主要都還是運作在 IPv4 上，由於 IPv6 的 DNS 優先於 IPv4，我自建的 DNS 伺服器就被排在後面，然後我就找不到自己架設的機器了。

微軟官方部落格在去年發佈了一篇 System.IO.Pipelines: High performance IO in .NET，這個東西高不高效我是比較不出來，但是它著實解決了以往在接收 NetworkStream 時算位置的困擾，用它寫出來的程式碼簡潔清晰許多。

ROW_NUMBER() 是在 2008 的時候出現的，自從它出現之後，我做分頁查詢就都是用它來做，從 SQL Server 2012 開始出現了 OFFSET / FETCH，它類似於 C# 中的 Skip() / Take() 這種跳過幾筆取幾筆的方式，知道之後就都改用 OFFSET / FETCH 來做分頁查詢。

之前的報表，老闆覺得還不夠，他還想再看到一些數據，於是就開需求了「Johnny 啊，我想再看到每個分店每月銷售額跟他們最好及最差的那一個月相比，看看差了多少百分比。」，當然沒問題，付錢就行。

上一篇文章提到依日期彙總結果，這時候老闆又開需求了「Johnny 啊，能不能幫我多加一個欄位，讓我看到每個分店當月銷售額與上個月銷售額相比的成長百分比？」，這個需求也很常出現在我的程式設計生涯當中，我們來看看在 SQL Server 中怎麼來實現。

假定老闆提了一個需求，他想要看每個分店每天的銷售額，如果當天沒有銷售額的分店則銷售額顯示為 0，這個需求我們從訂單資料庫裡面彙總出來就可以呈現了，但是它有一個點在於萬一某個分店在某天沒有訂單，那麼該分店在訂單資料庫是沒有資料的，則該分店的該天銷售額必須標為 0，類似這樣的需求經常在我的程式設計生涯中出現。