.NET Walker

我好幾年沒有用傳統的關聯式資料庫了。 老實說，傳統的關聯式資料庫，其實對於教育訓練和小型的專案來說，是一種負擔。 如果你想讓學員清楚的掌握一門技術，就好比說，對談機器人的開發吧，在整個教學的過程中，若是範例用到SQL或MySQL資料庫，無疑是一種節外生枝，把問題變得更複雜。因為，在對談機器人當中，儲存只是一種迫不得已的額外需求，是枝微末節，而非對談機器人技術的主體。 同樣的，如果你做一個小型專案或POC的話，『儲存』也往往不是重點，儲存只是『必要之惡』。其實，若是從這個角度廣義的來說，軟體開發的GUI、資料庫，都只是細節(枝微末節)，都應該要是可以隨時被抽換或取代的部分，而非系統核心。 一套軟體或解決方案的真正核心，是商業邏輯。它(商業邏輯)才是一個應用程式真正展現價值的部分。 我們把主題拉回來。所以，我最近這幾年在上課的時候，盡量不讓範例程式碼涉及資料庫存取，特別是關聯式資料庫的存取。因為這對讀者或學員來說，變成了另一種必須學習的負擔。 但說的容易，如果範例中有碰到需要儲存資料的時候該怎麼辦呢? 有沒有什麼最簡單的儲存機制可以在程式碼中替代傳統資料庫? 這也是我最近幾年寫範例的時候，常常碰到的問題。因此，我特別花了一段時間，找看看有沒有什麼好用的『類』資料庫儲存體? 最後，我選擇了 Airtable。 Airtable Airtable 是一個靈活的雲端資料庫產品，結合了資料庫的功能和電子表格(data grid)的簡易性。它允許用戶以視覺化的方式存儲、組織和協作各種資訊： 白話一點說，就是它可以很自由的在Web畫面上設計欄位和維護(輸入、編輯)資料。 對我來說，它還有另一個重點，就是它擁有非常簡單的REST API，透過呼叫API就可以直接來讀寫資料。 它的API在使用上很簡單，只需要在設計好資料表之後，透過 https://airtable.com/create/tokens 站台建立一個 PAT(Personal Access Token): 建立PAT的時候，可以選擇要針對所有資料表，還是特定資料表，要只給這個token 讀取(Read)權限，還是要寫入(Write)權限： 有了token之後，可以透過很標準的REST API呼叫，進行連線的建立與資料的寫入： string ID = "👉air_tabl

如果先不管自動化CD Pipeline，習慣使用Visual Studio的開發人員，若要對 Azure Web App 佈署網站，大概最喜歡採用的佈署方式，莫過於『發行設定檔』。這一招用很久了，直到最近你可能會發現，建立Azure Web App 的時候，會看到底下這樣的警告： 這也意味著，你無法下載發行設定檔了： 如此一來，Visual Studio 當然也無法佈署了! Azure 這個調整，當然是為了安全性提升。 使用基本驗證不安全嗎? 對，相對來說是的。 因為基本驗證只透過一組帳號密碼來做佈署，再加上發行設定檔還把這組帳密直接給放在裡面，誰拿到了這組帳密都能夠更新網站，沒有進一步的身分驗證，對一般個體戶小型專案的開發人員來說還行，但對企業來說顯然不是一個理想的選擇。 好吧，但這樣比較簡單啊。假設，你只是要快速的進行佈署，我們是否可以先把這個被 disabled 掉的功能暫時開啟呢? 可以的，在 Azure WebApp 的組態設定，將『基本驗證發佈認證』給開啟即可： 如此一來，發行設定檔又可以下載了(記得把網站 reload 一下)： 下載到發行設定檔之後，我們在Visual Studio當中可以透過底下這樣的方式佈署網站： 然後選擇剛才下載的發行設定檔即可。 這種佈署方式雖然方便，但就如同前面說過的，發佈的過程並沒有嚴謹的身分驗證，也不支援AAD帳號或是RBAC等權限配置。因此，短期暫時將傳統的基本驗證開啟，取得發行設定檔佈署即便可行，建議未來還是採用AAD(Entra ID)驗證是比較理想的做法：

先前我們 提到了 透過Semantic Kernel，可以讓AI/LLM在與用戶對談的過程中，自動在需要的時候去呼叫 PlugIn 物件的方法(Method)，特別的事情是，這個呼叫並非是我們寫程式去做的，而是 AI 自己做的，我們並沒有寫這部分程式碼的邏輯，我們寫的只是提示(prompt)而已。 那問題來了，如果不是我們寫程式去呼叫這個方法，而是AI自己去呼叫的，那假設，這個被呼叫的方法裡面發生了 Exception ，那會發生什麼事情!? 我們看底下這段程式碼: public class LeaveRequestPlugin { [KernelFunction] [Description("取得請假天數")] public int GetLeaveRecordAmount([Description("要查詢請假天數的員工名稱")] string employeeName) { isRock.LineBot.Bot bot = new LineBot.Bot(ChannelAccessToken); bot.PushMessage(AdminUserId, $"[action : 查詢 {employeeName} 假單]"); if (employeeName.ToLower() == "david") return 3; else if (employeeName.ToLower() == "mary") throw new System.ArgumentOutOfRangeException("無法取得假單資料"); else return 5; } (...略...) } 請注意上面這段查詢員工請假天數的程式碼，你會發現，我們刻意在程式碼裡面，加入了底下這段 code: (...略...) else if (employeeName.ToLower() == "mary") throw new System.Ar

身為 LAE(LINE API Expert) 與 LINE 的支持者，既然知道透過Semantic Kernel可以快速的開發對談機器人，那當然要嘗試用在 LINE Bot的開發上。 先前我們 介紹過 如何使用 Semantic Kernel 來開發一個支援記憶與對話前後文、可以用自然語言進行請假的對談機器人，但當時的架構是在 console 環境，負責記憶處理的 ChatHistory 是可以被長時間保存的實體物件，但換成了LINE Bot開發的WebAPI架構，一切就變的有所不同了。 首先，由於ChatHistory物件會隨著WebAPI行程消失而遺失，且我們的LINE Bot還得面對多個用戶，因此也無法簡單的用一個 ChatHistory 物件就保存所有用戶的對話紀錄。所以我們要做一些調整，為每一位用戶建立一個自己的ChatHistory物件。 因此，我們在 WebAPI 中撰寫了底下這樣的程式碼： static Dictionary<string, ChatHistory> ChatHistoryByUser = new Dictionary<string, ChatHistory>(); private ChatHistory getHistoryFromStaticRepo(string UserId) { if (ChatHistoryByUser.ContainsKey(UserId)) return ChatHistoryByUser[UserId]; else return new ChatHistory(); } private void saveHistory(string UserId, ChatHistory chatHistory) { if (ChatHistoryByUser.ContainsKey(UserId)) ChatHistoryByUser[UserId] = chatHistory; else ChatHistoryByUser.Add(UserId, chatHistory); } 這段程式碼以靜態方式儲存ChatHistory物件的Dictionary，搭配 getHistoryF

既然我們已經知道，可以透過 Semantic Kernel 輕易地建立聊天機器人/智能助理，我們之前(參考 這篇 )也看到了如何用自然語言驅動 AI ，來自動呼叫 IoT 控制開關燈類別中的方法，體驗過了它的威力，接著，我們就來實作一下，如何透過 Semantic Kernel 來建立一個可以透過自然語言請假的對談機器人。 我得說，我過去幾年做過無數次這個範例，試圖用自然語言以對談方式來完成請假。從最初LINE Bot 出現的時候，以手工苦刻的方式，來建立請假機器人，到使用 Azure AI 上的 Language Understanding 解決方案，讓機器人能夠『稍微』看懂用戶以自然語言的方式輸入的請假資訊，但整個過程從來沒有愉快過。 過去，電腦對自然語言的理解實在太差了，直到GPT的出現，直到有了LLM，一切才開始不同。現在，我們可以輕易地透過 Semantic Kernel 使用大語言模型，來建立一個類似底下這樣，表現非常好的自然語言請假系統： 你會發現，我們實作了一個可以幫助用戶請假的對談機器人。他會蒐集用戶的請假資訊，然後在資訊滿足之後，呼叫API來完成請假動作。 上面這段對談紀錄當中，黃色的部分就是AI自動進行的 Action，也就是具體的『請假』或是『查詢』動作，其他的則是自然語言的交談對話。 我們之前說過，透過 Semantic Kernel ，我們可以快速地完成上面這個功能的開發。為了完成這個需求，我們建立了底下這個 LeaveRequestPlugin 類別。這個類別裡面有三個方法，你可以從Description描述看到這些方法的功能(當然，範例裡面的Action暫且用示意的方式來呈現，不真的寫入資料庫)： // 請假功能 Plugin public class LeaveRequestPlugin { [KernelFunction] [Description("取得請假天數")] public int GetLeaveRecordAmount([Description("要查詢請假天數的員工名稱")] string employeeName) { //修改顯示顏色 Console.ForegroundColor = Con