軟體主廚的程式料理廚房

有一天客戶的 IT 人員從資料庫中發現，某些資料欄位被塞入不尋常的資料。

看到這些資料的當下，我第一個念頭是「會不會某支程式有 Bug 導致整批資料被更新了？」，在排除這個原因之後，調查方向轉往「可能被駭客入侵了？」的狀況前進。

小時候換新電腦都會感到興奮，覺得又有新玩具可以玩了，除了感受新硬體設備帶來的速度快感之外，還能體驗新作業系統帶來的新鮮感，有了一定的年紀之後，電腦變成工作用的工具，就只有希望它好好的不要出事，而且對於換新電腦也沒有什麼動力，因為習慣的軟體及配置，就要重新安裝跟設定，這幾天在替新電腦設定工作環境的時候，遇到了這個錯誤：

這個錯誤是在測試遠端桌面連線的時候跳出來的，在幾年前曾經遇過，當時解決之後想說應該不會再碰到了，沒想到又遇上了，寫一篇文章記錄一下。

有一些專案它的生命週期不長，像是商業活動專案，活動過了，專案也就跟著結束，如果使用者不多，而且使用者大都集中在某個時段才會操作系統，那 Azure Functions 是挺合適的解決方案；又或者，我們有一些排程工作，執行的間隔時間很長，可能一天才一次，用 Azure Functions 也很適合。

最常見的依賴注入（Dependency Injection）方式，就是從建構式上面，將依賴的服務一一注入，但是實務上多多少少會有一部分的 Instances，在服務被釋放之前都沒有被用到，雖然一般來說，產生 Instance 的成本不大，不過我還是想試一下，能不能將依賴注入這件事移到執行的目標方法裡面，在方法裡面有用到的服務才注入，所以就有了「延遲依賴注入（Lazy Dependency Injection）」這個題目。

在 .NET Framework 中，無論是 App.Config 或 Web.Config，均有保留 <configSections> 讓我們可以自訂設定區塊（ConfigurationSection），由於曾經看過有一些 Library 把設定值放在節點之中，像這樣：

等到要自己弄的時候才發現，似乎沒有那麼簡單，網路上搜尋到的有關於自訂 ConfigurationSection 的文章，大都沒有提到這一塊。

看到 Bill 叔在 twMVC#39 講的 Compile-time weaving 的 AOP 框架 - PostSharp，勾起了我的 AOP 魂，隨手 Google 了一下，讓我找到了一個 Open Source 的框架 - AspectInjector（看名字我還以為是某個 Dependency Injection 的套件），看它在 GitHub 的介紹裡面下了 postsharp 的標籤，似乎有向 PostSharp 看齊的目標。

Nginx 預設每個 Worker Process 的最大連線數是 1024，這個對我們網站是不夠用的，那不夠用就會收到 socket() failed (24: Too many open files) 的錯誤訊息，於是就動手調整 Nginx 的參數，就在調整其中一個參數 worker_rlimit_nofile 的過程中，出現了下面的錯誤訊息：

setrlimit(RLIMIT_NOFILE, 65535) failed (1: Operation not permitted)

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

在 twMVC#34 聽到一位朋友說他遇到 ASP.NET SignalR 有連線數 11 的限制，由於這位朋友沒有現身，不知道更詳細的情況，我就我之前遇到的情況跟各位朋友分享，ASP.NET SignalR 是會有連線數限制的情形，但這不是 ASP.NET SignalR 的問題。

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