[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

...繼續閱讀 »

[C#][LINQ]樂透頭獎、雙贏彩及安慰獎的寫生

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

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

[SonarQube]Scanners(MSBuild)執行掃描時出現記憶體不足SonarQube java.lang.OutOfMemoryError: GC overhead limit exceeded

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

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

...繼續閱讀 »

[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]Realtime評分(預測)

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

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

...繼續閱讀 »

[Fortify]Critical: Insecure Transport: Database解決(啟用SQL加密連線)

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

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

 

...繼續閱讀 »

[SQL Server]暫存資料表(#TABLE)引發的重新編譯(資料源統計值更新)

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

...繼續閱讀 »

[SQL Server]暫存資料表(#TABLE)引發的重新編譯Re-Compilations(Ad hoc)

我們有時在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,要找一個設定方便,資訊又完整的就令人傷腦筋。

 

...繼續閱讀 »