史丹利好熱

把CI/CD 訊息通知也丟到指定的Teams頻道上。

想讓資訊聊天機器人有溫度，有個重要的關鍵就是聽懂使用者問題(Language Understanding)，如果自己寫資訊問答機器人的程式，我們可能要寫很多關鍵字的解析才能判斷好客戶的意圖，經過持續的回饋及除錯，最後才能聰明的回答出設計好的答案。微軟Azure上有一個認知服務(Cognitive Service)可以讓這件事變得簡單，服務的名稱是QnA Maker，今年5月已經是GA(General availability)版本了，介紹的網頁上說，只要數分鐘就能從FAQ到BOT，要串接既有系統的網頁或是加入即時通訊合作軟體也很方便，來試試From FAQ to Bot in minutes。

這星期收到許多勸敗Microsoft Teams的分享訊息，Teams也是一種辦公室即時通訊合作軟體，不過以前Teams得要有Office 365才能用，現在有免費的方案了。除了團隊溝通、檔案共用和視訊通話等功能，我們先從應用程式的Log拋到Teams 頻道開始，來串一下NLog To Teams Channel。

明明同事用了using來確保區塊結束時會呼叫Dispose()作到自動釋放資源，但還是被源碼檢測工具fortify舉報。呼~~來解題。

這週Review年輕同事的程式，程式中需要將兩組序列作比對來決定輸入資料的去向，意外發現了同事使用LINQ All及Any判斷式不小心留下的小bug，簡單作樂透案例給同事看:

• 判斷序列的"任何項目"是否"都"符合(頭獎)
• 判斷序列的"任何項目"是否都不符合(雙贏彩)
• 判斷序列的任一項目是否符合(安慰獎)

同事最近想在新版本的SQL Server追蹤異常的SQL登入(SQL Login Fail)，不過同事在舊版本SQL Server都用SQL Trace，來推薦同事改用擴充事件(Extended Event)追蹤登入失敗的錯誤碼18456。

同事的專案因為時間長，累積超過上千個Jira issues，每到了專案會議前要整理issues狀態作統計，就會收到客戶對於下載上限1,000筆限制的抱怨，來幫DevOps Team解題。

最近在新的專案CI流程內開始加入聲納(SonarQube)來進行程式碼分析，希望能獲得海面下更多有關程式碼品質度量的指標。從Jenkins以Command Line執行大型程式庫掃描時，卻出現了記憶體不足的異常，不過小型程式庫則可以正常完成掃描。

進入疑難排解階段，我們先確認伺服器記憶體是充足無虞的，不過觀察掃描程式在大型程式庫執行時，只吃到1G多一點就出現記憶體不足的異常。筆記解題方法。

最近參與了同事專案的討論，在專案文件庫中，發現年輕同事曾遇到MSTest整合進CI Server的問題，CI Server加裝的MSTest Plugin以Command Line(CLI)跑測試時，出現了"沒有要執行的測試"(No tests to execute.)訊息，先前自己也遇到，來筆記這個問題。

.NET專案完成建置、掃描及測試等等等的持續整合程序後，下一步就到了過版到QA環境的佈署階段了，要佈署到IIS的Web專案可以靠Web Deploy單鍵佈署建立的發行組態與Jenkins直接整合，透過web deploy(8172)直接佈署到WEB Server的IIS。但遇到Windows Service或是其他執行檔專案時，就稍微麻煩一點。這次我們在Jenkins Master作建置並且產生發行成品，但佈署時，直接從測試機連回Jenkins Master取得封裝成品來作版本更新。

上一篇先筆記Realtime的評分預存程序sp_rxPredict給同事看，這篇來筆記SQL 2017推出的原生(Native)述詞- PREDICT，更直覺簡單的寫法。

測試環境訓練好模型，正式上場預測前，我們會需要再建立一段R的評分程式碼，並且以字串的方式包在外部預存程序介面內(sp_execute_external_script)，透過讀取序列化後的模型在R的環境執行預測。

但這樣的方式還是多了點麻煩，第一個是程式的可讀性，第二個則是正式環境的資料庫必需依賴R的環境作運算，要解決這個問題，也許可以試試看SQL2016就推出的Realtime評分(sp_rxPredict)或是SQL 2017推出的原生(Native)評分方式，更即時更原生的方式執行。

在.NET程式透過WebRequest來建立HTTPS或FTPS連線時，有時攻城獅可能因為無法確認憑證有效性，寫了不理會憑證是否有效的程式碼來讓程式正常運作，上線前，送到源碼檢測健康檢查時，就會被列出來*標示Critical的風險，來還技術債吧。

為了避免SQL Server與AP伺服器傳輸時的內容被攔截竊取後容易解析，我們可以採用加密的傳輸通道，一來可以增加傳輸封包安全性，二來也避免源碼檢測工具打小報告。

以前都是在DB Server手動裝憑證，然後DB匯出，AP伺服器匯入再設定連線字串啟用加密，才能啟用加密連線(大誤)。最近和同事討論，意外發現，即使沒有額外處理憑證，單只要AP連線字串加上TrustServerCertificate=true;Encrypt=true，實際連線時，SQL會自動產生憑證，重要的TDS封包就被加密了，而且專案中的組態檔還可以通過源碼檢測的盤查。

由於工作的關係，時常需要和源碼檢測工具神鬼交鋒一下，持續整合之路上也有源碼檢測的探險，累積幾家客戶的要求，半數是以Fortify SCA(Source Code Analyzer)作為檢測工具，也寫筆記留給同事及以後的自己參考。

經過前面的2篇實驗，實驗出Ad hoc使用到臨時資料表(#TABLE)每次都會重新編譯，至於預存程序(SP)使用臨時資料表則要視情況而定。上一篇還有一個延伸問題，既然預存程序使用臨時資料表(#TABLE)不一定會觸發重新編譯而更新臨時資料表統計值，如果產生臨時資料表的資料源在第一次編譯之後，資料量變動很大，而臨時資料表要和其他資料表Join，是否會導致SQL Query Optimizer應該正確選擇合併或雜湊連結(Merge/Hash Join)卻選擇巢狀迴圈(Nested Loop)而導致效能問題?

上一篇筆記了Ad hoc使用暫存資料表(#Table)引發的重新編譯(Recompilations)，過量的重新編譯會增加CPU的負擔，換個方式執行SQL，如果預存程序(Stored Procedure)中使用暫存資料表(#TABLE)會不會造成每次執行就重新編譯?

我們有時在SQL Server監控CPU的效能時，會額外多觀察每秒陳述式重新編譯次數(SQL Re-Compilations/sec)的效能計數，透過收集的資訊及後續的調校來降低生產環境出現大量的重新編譯。

最近專案裡，奉旨把SQL程式也加入持續整合(CI)的測試項目內，在掃描SQL程式時發現幾位成員在頻繁的線上交易語法中，使用了少許的暫存資料表(#TABLE)，解釋給同事聽，順便筆記可能引發的大量持續不斷的重新編譯。

上一篇，我們用cloc.exe 自動計算程式碼行數作為程式碼開發進度的概觀，但如果想調查專案中的程式有沒有波動拳的情形(很深的巢狀邏輯)，觀察程式碼複雜度、可維護性指數都是找出快打旋風Ryu與Ken的方法。

在時間還是充裕的時候，也許我們人工Review時可以用上Visual Studio擴充套件的CodeMaid或是Visual Studio 內建的程式碼度量(Code Metrics)功能來識別出潛在的技術債，不過，在自動化持續整合階段，如果沒用SonarQube，要找一個設定方便，資訊又完整的就令人傷腦筋。

繼續往持續整合之路前進，有時老闆會想知道最基本的程式碼度量，究竟專案中使用了幾種程式語言，多少支程式碼，多少行程式碼(LOC:Line Of Code)?如果專案程式碼沒送SonarQube掃，還有哪些方式能持續自動的紀錄?