把CI/CD 訊息通知也丟到指定的Teams頻道上。
[Azure]QnA Maker and Bot Service對話機器人加到網頁或是Microsoft Teams
想讓資訊聊天機器人有溫度,有個重要的關鍵就是聽懂使用者問題(Language Understanding),如果自己寫資訊問答機器人的程式,我們可能要寫很多關鍵字的解析才能判斷好客戶的意圖,經過持續的回饋及除錯,最後才能聰明的回答出設計好的答案。微軟Azure上有一個認知服務(Cognitive Service)可以讓這件事變得簡單,服務的名稱是QnA Maker,今年5月已經是GA(General availability)版本了,介紹的網頁上說,只要數分鐘就能從FAQ到BOT,要串接既有系統的網頁或是加入即時通訊合作軟體也很方便,來試試From FAQ to Bot in minutes。
[Teams][.NET]NLOG的訊息拋到Microsoft Teams
這星期收到許多勸敗Microsoft Teams的分享訊息,Teams也是一種辦公室即時通訊合作軟體,不過以前Teams得要有Office 365才能用,現在有免費的方案了。除了團隊溝通、檔案共用和視訊通話等功能,我們先從應用程式的Log拋到Teams 頻道開始,來串一下NLog To Teams Channel。
[Fortify][.NET]Unreleased Resource: Streams 排除
明明同事用了using來確保區塊結束時會呼叫Dispose()作到自動釋放資源,但還是被源碼檢測工具fortify舉報。呼~~來解題。
[C#][LINQ]樂透頭獎、雙贏彩及安慰獎的寫生
這週Review年輕同事的程式,程式中需要將兩組序列作比對來決定輸入資料的去向,意外發現了同事使用LINQ All及Any判斷式不小心留下的小bug,簡單作樂透案例給同事看:
- 判斷序列的"任何項目"是否"都"符合(頭獎)
- 判斷序列的"任何項目"是否都不符合(雙贏彩)
- 判斷序列的任一項目是否符合(安慰獎)
[SQL Server][擴充事件]稽核SQL Server Login Fail
- 1424
- 0
- SQLExtendedEvent
同事最近想在新版本的SQL Server追蹤異常的SQL登入(SQL Login Fail),不過同事在舊版本SQL Server都用SQL Trace,來推薦同事改用擴充事件(Extended Event)追蹤登入失敗的錯誤碼18456。
[Jira]下載超過1,000筆以上的issues(JIRA Cloud)
同事的專案因為時間長,累積超過上千個Jira issues,每到了專案會議前要整理issues狀態作統計,就會收到客戶對於下載上限1,000筆限制的抱怨,來幫DevOps Team解題。
[SonarQube]Scanners(MSBuild)執行掃描時出現記憶體不足SonarQube java.lang.OutOfMemoryError: GC overhead limit exceeded
最近在新的專案CI流程內開始加入聲納(SonarQube)來進行程式碼分析,希望能獲得海面下更多有關程式碼品質度量的指標。從Jenkins以Command Line執行大型程式庫掃描時,卻出現了記憶體不足的異常,不過小型程式庫則可以正常完成掃描。
進入疑難排解階段,我們先確認伺服器記憶體是充足無虞的,不過觀察掃描程式在大型程式庫執行時,只吃到1G多一點就出現記憶體不足的異常。筆記解題方法。
[MSTest][CLI]沒有要執行的測試
- 1199
- 0
- Visual Studio
最近參與了同事專案的討論,在專案文件庫中,發現年輕同事曾遇到MSTest整合進CI Server的問題,CI Server加裝的MSTest Plugin以Command Line(CLI)跑測試時,出現了"沒有要執行的測試"(No tests to execute.)訊息,先前自己也遇到,來筆記這個問題。
[Jenkins]持續整合之路(十一)Jenkins加入Slave作自動佈署(Copy Artifact plugin)
.NET專案完成建置、掃描及測試等等等的持續整合程序後,下一步就到了過版到QA環境的佈署階段了,要佈署到IIS的Web專案可以靠Web Deploy單鍵佈署建立的發行組態與Jenkins直接整合,透過web deploy(8172)直接佈署到WEB Server的IIS。但遇到Windows Service或是其他執行檔專案時,就稍微麻煩一點。這次我們在Jenkins Master作建置並且產生發行成品,但佈署時,直接從測試機連回Jenkins Master取得封裝成品來作版本更新。
[SQL Server][Machine Learning]新功能-PREDICT述詞(原生評分)
- 4512
- 0
- R Language
上一篇先筆記Realtime的評分預存程序sp_rxPredict給同事看,這篇來筆記SQL 2017推出的原生(Native)述詞- PREDICT,更直覺簡單的寫法。
[SQL Server][Machine Learning]Realtime評分(預測)
- 4549
- 0
- R Language
測試環境訓練好模型,正式上場預測前,我們會需要再建立一段R的評分程式碼,並且以字串的方式包在外部預存程序介面內(sp_execute_external_script),透過讀取序列化後的模型在R的環境執行預測。
但這樣的方式還是多了點麻煩,第一個是程式的可讀性,第二個則是正式環境的資料庫必需依賴R的環境作運算,要解決這個問題,也許可以試試看SQL2016就推出的Realtime評分(sp_rxPredict)或是SQL 2017推出的原生(Native)評分方式,更即時更原生的方式執行。
[Fortify]Critical: Insecure SSL: Server Identity Verification Disabled(驗證憑證)
在.NET程式透過WebRequest來建立HTTPS或FTPS連線時,有時攻城獅可能因為無法確認憑證有效性,寫了不理會憑證是否有效的程式碼來讓程式正常運作,上線前,送到源碼檢測健康檢查時,就會被列出來*標示Critical的風險,來還技術債吧。
[Fortify]Critical: Insecure Transport: Database解決(啟用SQL加密連線)
為了避免SQL Server與AP伺服器傳輸時的內容被攔截竊取後容易解析,我們可以採用加密的傳輸通道,一來可以增加傳輸封包安全性,二來也避免源碼檢測工具打小報告。
以前都是在DB Server手動裝憑證,然後DB匯出,AP伺服器匯入再設定連線字串啟用加密,才能啟用加密連線(大誤)。最近和同事討論,意外發現,即使沒有額外處理憑證,單只要AP連線字串加上TrustServerCertificate=true;Encrypt=true,實際連線時,SQL會自動產生憑證,重要的TDS封包就被加密了,而且專案中的組態檔還可以通過源碼檢測的盤查。
[Jenkins]持續整合之路(十)程式碼安全檢測(執行Fortify SCA源碼檢測)
由於工作的關係,時常需要和源碼檢測工具神鬼交鋒一下,持續整合之路上也有源碼檢測的探險,累積幾家客戶的要求,半數是以Fortify SCA(Source Code Analyzer)作為檢測工具,也寫筆記留給同事及以後的自己參考。
[SQL Server]暫存資料表(#TABLE)引發的重新編譯(資料源統計值更新)
- 2374
- 0
- SQLStatistics
- 2018-06-14
經過前面的2篇實驗,實驗出Ad hoc使用到臨時資料表(#TABLE)每次都會重新編譯,至於預存程序(SP)使用臨時資料表則要視情況而定。上一篇還有一個延伸問題,既然預存程序使用臨時資料表(#TABLE)不一定會觸發重新編譯而更新臨時資料表統計值,如果產生臨時資料表的資料源在第一次編譯之後,資料量變動很大,而臨時資料表要和其他資料表Join,是否會導致SQL Query Optimizer應該正確選擇合併或雜湊連結(Merge/Hash Join)卻選擇巢狀迴圈(Nested Loop)而導致效能問題?
[SQL Server]暫存資料表(#TABLE)引發的重新編譯Re-Compilations(SP)
- 1945
- 0
- SQLPerformance
- 2018-06-18
上一篇筆記了Ad hoc使用暫存資料表(#Table)引發的重新編譯(Recompilations),過量的重新編譯會增加CPU的負擔,換個方式執行SQL,如果預存程序(Stored Procedure)中使用暫存資料表(#TABLE)會不會造成每次執行就重新編譯?
[SQL Server]暫存資料表(#TABLE)引發的重新編譯Re-Compilations(Ad hoc)
- 2062
- 0
- SQLPerformance
- 2018-06-10
我們有時在SQL Server監控CPU的效能時,會額外多觀察每秒陳述式重新編譯次數(SQL Re-Compilations/sec)的效能計數,透過收集的資訊及後續的調校來降低生產環境出現大量的重新編譯。
最近專案裡,奉旨把SQL程式也加入持續整合(CI)的測試項目內,在掃描SQL程式時發現幾位成員在頻繁的線上交易語法中,使用了少許的暫存資料表(#TABLE),解釋給同事聽,順便筆記可能引發的大量持續不斷的重新編譯。
[Jenkins]持續整合之路(九)程式碼度量(SourceMonitor)
上一篇,我們用cloc.exe 自動計算程式碼行數作為程式碼開發進度的概觀,但如果想調查專案中的程式有沒有波動拳的情形(很深的巢狀邏輯),觀察程式碼複雜度、可維護性指數都是找出快打旋風Ryu與Ken的方法。
在時間還是充裕的時候,也許我們人工Review時可以用上Visual Studio擴充套件的CodeMaid或是Visual Studio 內建的程式碼度量(Code Metrics)功能來識別出潛在的技術債,不過,在自動化持續整合階段,如果沒用SonarQube,要找一個設定方便,資訊又完整的就令人傷腦筋。
[Jenkins]持續整合之路(八)程式碼度量初階(SLOCCount Plugin)
繼續往持續整合之路前進,有時老闆會想知道最基本的程式碼度量,究竟專案中使用了幾種程式語言,多少支程式碼,多少行程式碼(LOC:Line Of Code)?如果專案程式碼沒送SonarQube掃,還有哪些方式能持續自動的紀錄?