軟體主廚的程式料理廚房

之前有介紹過 SSL 憑證只要放在 Load Balancing 就可以了，不必在每台 Load Balancing 後面的機器都去放置 SSL 憑證，假設我們原有 http://xxx.yyy.com 的網址，在我們打通了 https 之後想要將 http 都強制重新導向到 https，很直覺地我們想到的解決方案就是檢查打進來的 Request URL 如果是 http:// 開頭的就回應重新導向到 https:// 開頭的就行了，但死亡導向之門也就此被打開了。

對於 Web Site 的橫向擴展，有時候我們既定的印象就是多開機器，如果原本的機器就夠 Powerful，而採用的 Load Balancing 又可以對應到後端多個 Port 的話，我們其實可以選擇再新增一個相同服務但不同 Port 的站台。

HTTPS 協定已普及化了，甚至我們的網站如果沒有支援 HTTPS 的話，在搜尋引擎的排名還可能會被調降，本篇文章就在 IIS 8.5 躲藏在 GCP Load Balancing 背後的環境下，一步步去打通 HTTPS。

有這個議題是既有系統的 Cache 邏輯在 Cache 沒有命中的時候，會啟動 lock 機制，然後去執行一個由呼叫端傳進來的 delegate function 去後端資料庫重新取得資料，可是我們都知道每家公司多多少少都有遺留一些「初學者程式碼」，這些初學者程式碼不一定是初學者寫的，但它有時候執行的效能並不是很好，在這種情況再搭配 lock 機制之下，後面進來的 Request 就塞住了，進而影響客戶端的響應速度。

我利用 Opserver 透過 WMI 監控幾台 Windows 伺服器，途中遭遇到兩個錯誤訊息 The RPC server is unavailable. (Exception from HRESULT: 0x800706BA) 及 Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED))，還好這兩個錯誤訊息不難解。

有一些專案的建置作業中，某些步驟是需要對 Git Repository 做操作的，比如說在一切測試都通過之後，發行一個可執行的版本並 commit，然後 push 到待上線的 Git Repository，這時候賦予給 CI 的 Git 帳號就至少要有 Write 的權限，並且執行需要授權的操作時，自動帶上認證。

當我們的 Git Repository 只有一包的時候，而我們又想要讓 Jenkins 只 Pull 某個資料夾底下的檔案時，Sparse Checkout paths 這個 Git Plugin 的附加行為可以幫我們辦到這件事。

有時候我們不需要每次 commit 都執行 CI 的建置作業，例如：更換網站的 Logo、更新靜態頁面的 Wording，這次要介紹兩種方式，都是可以用來指定在特定條件之下才 trigger 建置作業的方式，一種是根據特定的 committed message，另一種是根據特定的 changed path。

爬了幾篇網路上的文章，實在是有看沒有懂，所以往下去追 log4net 的原始碼，再試著寫程式去實驗才明白這兩者之間的差異，顧名思義 LogicalThreadContext 與 ThreadContext 在選擇使用上跟 Thread 息息相關。

在這個時代身為一個碼農，有個幾處碼田是挺正常的，我本身有兩個 GitHub 帳號，一個是公司用的，一個自己私人用的，而 Git Client 是用 TortoiseGit，不同的遠端儲存庫使用不同帳號去認證，而當我們選擇使用 SSH 針對不同帳號，產生不同金鑰去存取遠端儲存庫的時候，就會看到這樣子的訊息。