.NET Walker

每個月 10元美金，折合台幣 $315 左右，到底能帶給開發人員什麼? 據麥肯錫說：『使用微軟 GitHub Copilot 的軟體開發人員完成任務的速度比不使用該工具的人快 56%。』這個數字真的可信? 而 GitHub 與 Wakefield Research 合作，今年針對 500 位在千名以上員工企業的開發人員進行調查，蒐集到的回饋則是： 你如果問我，真的覺得有這麼高的果效嗎? 我是覺得，這個問題要由開發者自己親身體驗後，由你自己來回答。 我最近接到非常多客戶詢問 Github Copilot 的教育訓練，team member 問我，Github Copilot 不就是申請好安裝起來就用嗎? 還需要上課嗎? 其實，網路上的資源那麼多，哪一門資訊技術真的非得上課才能學會呢? 絕大部分的課程也只是縮短你自己摸索花費的時間而已。 為了準備課程，我錄製了不少的影片，底下這兩個是這系列影片的開頭兩隻，或許對於還在對 Github Copilot 猶疑的朋友會有些幫助。第一個影片是 Github Copilot 的安裝與基礎使用介紹，第二個影片則是展示了如何使用 Github Copilot 很快的建立出一個前端 UI。 觀看第二支影片時，請特別注意 Github Copilot Chat 的部分，在影片中我們展示了怎麼透過 Github Copilot Chat 讓Github Copilot 幫我們把網頁改成支援 bootstrap 以及把表格轉換成中文，在這個過程中，你應該會自己體察到， Github Copilot 在你的工作場域中，到底能不能幫你節省時間。 GitHub Copilot - 01 基本程式碼生成 與 QA GitHub Copilot - 02 前端頁面html與bootstrap 不管是對於新人或開發老手來說，這兩個影片，應該都能有效的帶您進入 AI 協同開發的領域，希望對大家有所幫助。 後記: 上課時，和學員談到這個問題。 有學員問道：『依照上面這樣的展示，老師您會不會覺得，若開發人員將來廣泛的使用 AI ，那以後都只負責看程式碼都不用花腦袋寫 Code 了，那是否會讓開發人員的技術能力降低呢? 』 我還來不及回答，另一位學員開口說了：『這看人吧，搞不好有些人反而會因為能夠看到不同的程式碼寫法，讓...

前幾天上課的時候，發現原本可以順暢使用的 LINE Bot WebHook Template (自動建立LINE Bot WebHook API專案的範本)突然間不能用了，學員哀號，身為現場指導老師，我當然跑不掉。 走向前往學員的電腦上一看，發現整個操作動作並無不妥： dotnet new webapi dotnet add package linebotsdk dotnet new install isRock.Template.LineWebHook dotnet new linewebhook 但依照過去的做法，使用瀏覽器讀取 http://localhost :???/api/LineBotChatGPTWebHook 結果出現 不對，照說透過我們 template 建立出來的 WebAPI ，其程式碼的內容應該是： namespace isRock.Template { public class LineBotChatGPTWebHookController : isRock.LineBot.LineWebHookControllerBase { [Route("api/LineBotChatGPTWebHook")] [HttpPost] public IActionResult POST() { (...略...) 這段 code 所產生的 WebAPI 就算不能使用瀏覽器以 http get 方式讀取，也應該是得到 http 405 method not allowed 而非 404 啊，這怎麼回事呢? 估計應該是 Route 沒抓到，查看 Program.cs ，Routing 的設定怎麼變成底下這個樣子了? pp.MapGet("/weatherforecast", () => { var forecast = Enumerable.Range(1, 5).Select(index => new WeatherForecast ( DateOnly.FromDateTime(DateTime.Now.AddDays(index)),...

前幾天介紹過如何透過 LINE Messaging API 來串接 OpenAI API，實現具有GPT能力的LIEN Bot。但如果你的 ChatBot 不想只支援 LINE 怎麼辦呢? Microsoft Bot Framework 是另一個不錯的選擇。 Microsoft Bot Framework 提供了一個健全的平台，讓開發者可以建立、測試、和部署具有高度互動性的聊天機器人，除了可以直接串接 LINE Bot， 還支援 Teams、Telegram、FB、Skype、Alexa、Web UI、甚至 email 和 SMS…等不同的Channel。 當它與 OpenAI 的 API 結合時，不僅可以快速的建立出對談機器人應用 ，更能確保了機器人可以在多種平台上運行，包括網頁、社交媒體平台和行動應用，使其更具可訪問性和便利性。 底下這個在MS Bot模擬器中的截圖，就是我們在上課的時讓學員做出的成果，你會看到透過 Bot Framework 設計的對談機器人，具備理解前後文與對談記憶，由於ChatGPT的加持，可以輕易的理解用戶的對談訊息，從而輕鬆地蒐集用戶的購票資訊，協助用戶進行購票。 這個範例的最後，產生了一個可以傳遞給 購票系統的 JSON 內容，只需要再加上呼叫 購票系統的API，就可以在對談中自動完成協助用戶購票的動作了。 讓 OpenAI API 產出 JSON 是為了方便開發人員後續可以直接呼叫 售票系統的 API 來完成真正的購票行為，如此一來可以更方便的做系統間的整合。 而採用 MS Bot Framework 開發的好處在於，可以輕易地透過 Azure Bot 的維護後台，以設定的方式，就可以讓串接好 ChatGPT 的 Bot 與各種不同的頻道進行整合: 這樣我們只需要撰寫一次，就可以直接支援各種不同的操作介面或App。 基本款的 MS Bot Framework + ChatGPT 範例，可以參考筆者的 Github repo: https://github.com/isdaviddong/DemoChatGPTwithMSBotFramework.git 相關課程: https://www.studyhost.tw/NewCourses/LineBot

OpenAI 的 Completions API 雖然已經是屬於legacy的API，但其實一直以來它都是一個挺方便的文字生成工具。 這個 API 提供了對 GPT-3 和最新的 GPT-4 模型的存取，允許用戶輕鬆創建自然語言應用。無論是文章 自動生成 、 語言翻譯 還是 情緒分析 ，Completions API 都是相當便捷好用的API。 要使用 OpenAI Completions API，開發人員可透過 POST 方法與 API 互動。在 Request 的 Header 中，應包含 Authorization 字段，其值為 Bearer [你的API金鑰] ，以認證API的使用者身份。 ( 金鑰申請方式 ) Request 的 Body 則需包含數個參數，主要是 model （指定使用的 GPT 模型）， prompt （輸入給模型的提示文本），以及 max_tokens （指定生成文本的最大長度）等。透過指定這些參數，開發者可精確控制生成出的文字，例如： 你會發現，當使用 OpenAI Completions API 的 POST 請求時，Body 部分的撰寫相當重要。這部分的內容指導了 AI 模型如何回應需求。其中， prompt 屬性是控制AI Model生成文字的起點，而 max_tokens 則指定生成內容的最大長度。其他可用的參數包括 temperature （控制回應的創造性）， top_p （影響回應的多樣性），以及 frequency_penalty 和 presence_penalty （用於調節特定詞語的重複出現）。合理的設定這些細節，能夠讓開發者有效地定制模型的回應，以符合其特定應用場景的需求。 我們再透過一個例子來看 Completions API的另一種用法。假設我們想要生成一段關於人工智能未來趨勢的文字，我們的 POST 請求的 JSON Body 可以如下: { "model" : "gpt-3.5-turbo-instruct" , "prompt" : "描述未來五年內人工智能的發展趨勢" , "max_tokens" : 1450 , "temperatu...

OpenAI 在 ChatGPT 紅了之後，開始逐步把背後的 LLM(大型語言模型) 開放給開發人員使用(當然是收錢的)，LLM 作為對談機器人實際的運算主體，它隱藏在雲端的某一個角落悄悄的運行著，而外部的 UI 則是透過 API 來存取這個大型語言模型(LLM)： ChatGPT 採用 Web 的方式實作此操作界面，背後也是透過 OpenAI 的 API 來叫用LLM。而當開發人員有了API可以呼叫LLM之後，我們(企業內的開發人員)，也可以建立自己的界面，或在自己開發的應用程式中直接來使用AI，不管是 App、Web 或是ChatBot (像是 LINE Bot)，都可以透過串接 OpenAI 的 API ，來叫用 LLM 實現各種 AI 加值功能。 其中， OpenAI 釋出的 Chat Completion API 就是作為對談機器人應用的主要API 。它讓開發人員可以直接叫用最新的 GPT 模型(GPT-3 or GPT-4)，生成流暢、(與提示)關聯性高、且自然的回應對話。 在接下來的介紹當中，我們將深入檢視該功能的REST API 呼叫方式，並通過實際例子來展示其用法。 功能概述 從功能面來說，Chat Completion API 能夠理解用戶傳來的訊息(提示)，並且以智能助理的角色來回應，由於LLM具有基礎知識，其回應範圍從日常對話到專業的主題，都可以很好的進行問題解答、情緒分析、故事講述等多種任務，甚至可以生成 JSON(這對於開發人員相當重要)。 要使用 Chat Completion API，開發人員可以通過 HTTP Request與之互動。該API標準的HTTP請求包括以下幾個部分： Endpoint : API 的 URL 端點，就Chat Completion API 來說，目前是 https://api.openai.com/v1/chat/completions。 Headers : 包括用於認證的 Authorization 欄位，其值應為 Bearer [您的API金鑰] 。 Body : 包含請求參數，如 model （指定 GPT 模型）， messages （包含一系列對話歷史和當前用戶消息的陣列），例如： { "model" : "gpt-3.5-tu...

我依稀還記得AI的上一波潮流，大概是在2016年前後，各種基於類神經網路模型的應用開始市場化。但當時，還沒有到現在這種遍地開花的程度。 自從去年2023年11月，ChatGPT出現之後，坊間對生成式AI的 各種想像 開始變成了 各種應用 ，圖像生成當然也是其中之一。 如今，透過雲端的API，使用程式碼來動態產生圖片，已經是人人都能夠做的事情。OpenAI除了提供文字的生成，也提供了圖像的生成，採用的是DALL-E技術，最新的更新是DALL-E3，加入了類似於 ChatGPT 的 AI 聊天機器人技術來幫助完善圖像生成的提示，也因為這樣，你只需要透過自然語言，以形容的方式，甚至只需要打個關鍵字，就可以讓AI輕易的為你繪製出想要的圖片，支援不同的大小( 1024x1024 , 1792x1024 , or 1024x1792 )與風格。​ 熟悉REST API使用的開發人員，可以輕易地透過底下這樣的方式，來呼叫API，產生所需的圖片(底下是透過postman工具呼叫API的擷圖)： 如同上面API呼叫中的提示，我們要生成 “ 麥當勞美味的漢堡 ” ，出現的圖片如下: 完整的HTTP/1.1 呼叫為： POST /v1/images/generations Host: api.openai.com Authorization: Bearer ______API_KEY______________ { "model": "dall-e-3", "prompt": "麥當勞美味的漢堡" , "n": 1, "size": "1792x1024" } 你會發現，其實呼叫方式相當簡單，endpoint 是 https://api.openai.com/v1/images/generations ，只需要在http Header中提供 API Key 即可呼叫，API Key的建立方式在 這裡 。不過當然，好的服務是要付費的，OpenAI 關於DALL-E的費用在 這裡 。 使用C#呼叫API的程式碼如下: using System; using System.Net.Http; using Syste...

先前曾經提過，My GPT的Action功能，讓我們可以在自行設計的客製化GPT當中，呼叫外部API，這將使我們能夠輕易地透過 ChatGPT 強大的自然語言對話能力，讓用戶透過語音或文字就可以操作企業內的資訊系統。 未來，在企業內想要用語音或文字Chat Bot 來控制電腦請假、簽核、自動填寫各種表單，甚至操控企業的資訊系統，都將不是難事了。(我自己覺得，這對幾十年來，紅了好一陣子的UI/UX 會是一個很大的影響，但我由衷期待一個可以透過語音控制資訊系統的時代來臨) 底下這個MY GPT的Demo，展示出的就是這樣的效果： 具體設計 action 的方式如下： 不過這些在企業內的API，大多都是必須要透過API KEY進行驗證與授權後才能呼叫的。因此，這一篇我們就來看，需要KEY的API，要如何在MyGPT的Action中被呼叫。 首先，底下是一個需要KEY才能呼叫的API，如果我們把 header 中的 API Key 移除，你會發現呼叫時就會出現 401 Access Denied錯誤： 因此，當我們在 MyGPT中使用這組API，當然也會出錯： 這時，你可以在 MyGPT 下方的 Action 處，設定Authentication，並且填入該API所需要的 http header key 和 value： 例如，上圖中的 Ocp-Apim-Subscription-Key Header，就是APIM中很常見用來保護API的訂閱金鑰，前面提過的API，當有金鑰驗證之後，就可以呼叫了： 也因此，當我們對 MyGPT做了同樣的驗證金鑰配置之後，MyGPT也可以順利呼叫受金鑰保護的API了： 或許，要不了多久時間，我們就可以在螢幕前用語音跟電腦說：『幫我訂一張從南港到左營的高鐵票，要找靠窗的座位，8點左右出發，最好是能夠直達的班次…』 然後，我們的訂票GPT，就能夠自動呼叫高鐵班次查詢與購票API，幫我們持續搜尋最適合的班次與座位，最後完成訂票。 靠一張嘴完成所有事情的時代，終於將要出現。 相關課程: https://www.studyhost.tw/NewCourses/LineBot

OpenAI DevDay 最驚豔的展示之一，就是現在人人都可以設計自己的GPT了。 (成果展示影片請參考底下) 不用寫程式，只需要跟ChatGPT以對談的方式，ChatGPT就可以自動幫你做出客製化的GPT，給你的公司、客戶、甚至上架給所有人使用。 只要你有ChatGPT帳號，即可開始建立： ChatGPT會問你想建立什麼功能的GPT，用對談的方式，一步一步引導你做出自己客製化版本的GPT，還可以即時預覽: 你可以用對談的方式(當然也可以上傳文件)，讓ChatGPT知道請假規則： 對談之中，不知不覺的，你的客製化GPT已經完成，你可以選擇公開給全世界所有人，或是只給自己的好友或企業使用： 可預見的未來，將能更進一步的，串接企業系統的API，與自己企業內的ERP、CRM、HR系統整合。 半年前，我在一次受訪中曾說，ChatGPT的出現，將會改寫資訊系統的UI發展方向，如同電影Star Trek中，以自然語言語音控制電腦實現你想要完成的任何功能，現在已經近在眼前。 做完之後，用戶就可以透過客製化GPT以自然語言的對話方式請假了： 改變真的很大，未來將會發生什麼變化，就留給大家自己想像了… 相關課程: https://www.studyhost.tw/NewCourses/LineBot

有在使用 ChatGPT(OpenAI API)開發的Developers 一定知道，對於開發人員來說，使用OpenAI API有一個重要的技巧，就是要求 API 回傳JSON格式的物件。 這樣的 Prompt 非常好用，因為 ChatGPT 最強的功能可能不是回答正確的答案，但對於理解用戶說的自然語言，絕對可以說是所向披靡、無人能及。 如果在程式碼中，能夠要求OpenAI API固定的回傳JSON格式，這樣我們就可以輕鬆的Parsing回傳結果。然而，過去的OpenAI API，就算你的 Prompt 寫的再好，在幾十次的呼叫當中，總是會有一兩次回傳給你的不是精準的JSON格式，而是帶有描述性的字串，這可能會讓接收的程式立刻崩潰，除非你在程式碼中額外做一些判斷，然後重新呼叫API，retry到接收到正確的JSON格式為止。但顯然，這樣的結構設計會讓程式顯得有點傻。 如果OpenAI API能乖乖的回傳 JSON 不就好了嗎? 恩~ 恩~ OpenAI DevDay 之後，這件事情實現了。 現在你可以在呼叫 Chat API 的時候，加上底下的參數: "response_format" : {"type": "json_object" } 這會讓回傳的結果一律變成 JSON 形式。 這指令必須搭配新的 Model 👉gpt-4-1106-preview 或 gpt-3.5-turbo-1106 JSON Mode可以確保你拿到的一定是一個可以解析(Parsing)的 JSON 字串，這使得你 parsing JSON 的時候，不會得到 null，開發人員終於可以不再碰到因為 ChatGPT 的回傳不確定性，所可能帶來的程式崩潰問題。 我自己覺得，OpenAI DevDay中新推出的JSON Mode這個小功能反而是對開發人員最大的幫助。

現在的應用程式登入，特別是 Microsoft, Google, Facebook等大廠的網站SSO登入，常常設計有二階段驗證(2FA)，而其中手機App二階段驗證是最常用的模式。主要是因為簡單、迅速、免費，對於用戶、開發人員、網站本身，都是一個很好的選擇。 這種透過手機App實現的二階段驗證，採用的常是一種稱為TOTP(Time-based One Time Password)的技術。簡單的說就是，用戶以先以正確的帳號密碼登入之後，必要時(或每次)再跳出一個驗證視窗，讓用戶輸入另一組隨機產生的N位數密碼，而該密碼會自動出現在你的手機(APP)上，且只能使用一次並有時間限制。 如此一來，即便用戶的帳號密碼不慎外洩，駭客也必須要有用戶的手機，才能登入或執行進階的功能。當然，如果每次都要這樣驗證，用戶肯定會覺得麻煩，所以這類的驗證，往往不會在每次登入時都進行，而是在底下幾種情境下被觸發： 用戶在不尋常的情境下(地區、IP、時間)登入 用戶要進行進階的行為(例如變更密碼) 觸發的時機或演算法因系統特性不同而異，但2FA做法的原理則大致相同，這一篇，我們就來看如何實現2FA。 概念 上圖是 Twilio 網站的 TOTP示意圖，現在有很多業者提供 Authenticator App來實現這個功能，我自己喜歡 Twilio 的 Authy Authenticator, 你可以從底下位置下載： https://authy.com/download/ 使用 Authenticator App 實現2FA 的典型流程如下: 網站針對已登入的用戶產生一個唯一的key值，並以這個Key值產生URL，進而生成QR Code 讓用戶以任何一款Authenticator App掃描該 QR Code，即可在該App上登記註冊。 掃描好QR Code完成註冊後，一般會先做一次六位數密碼驗證，以便於確認用戶有正確完成掃描註冊。 未來，任何需要二階段驗證的時機，網站後台都可以呼叫API產生六位數密碼，並讓用戶在手機上檢視由App產生的六位數密碼，若兩者相同，即可確認用戶身分正確無誤。 實作 程式碼其實一點都不難，而且有現成的NuGet套件可以使用，我整理好的 source code 這邊: https://github.com/isdaviddong/...

Azure API Management ( APIM ) 是 Microsoft Azure 服務的一部分，主要功能在協助組織建立、發佈、維護、監控和保護 API。 其主要功能包含： API Gateway 限流和配額 分析和監控 保護 API 現有服務的代理和包裝 … 使用 Azure APIM 可以幫助組織提供統一的 API Gateway、提升 API 管理與發佈、更確保 API 的安全和可靠性。因此，在最近幾年許多企業開始想走微服務或是API first的架構下，常常做為API的對外閘道。 這樣做有一個好處，拿保護API做為例子，透過APIM，你只需要透過設定，就可以讓Gateway 後面的所有API都支援 JWT token驗證，你就無需在每隻API的程式碼裡面，去做token驗證的動作。 這一篇，我們就來實踐這個例子。 使用 Policy 我們做好了一組測試API，呼叫的網址是 https://testapim20231030.azure-api.net/conference/speakers ，這是APIM的雲端位置，它保護了我們原始的API Endpoint，這也是閘道器基本的功能和行為。 你會發現，預設狀況下我們透過postman在呼叫這組API的時候，是無需驗證帳號密碼的： 假設，我們希望讓 APIs 都受到JWT token驗證的保護，那只需要在 InBound Policy 這邊做設定： 加入底下這條 policy: <validate-jwt header-name="Authorization" failed-validation-httpcode="401" failed-validation-error-message="Unauthorized"> <issuer-signing-keys> <key>123456781234567812345678</key> </issuer-signing-keys> <required-claims> <claim name="admin...

ChatGPT 也紅了好一陣子，大部分開發人員應該也知道，如果要把ChatGPT的能力整合到自己的專案當中，可以透過 Open AI 所提供的API(或是微軟提供的Azure OpenAI API)。 我們開發LINE Bot也是，想做一個具有ChatGPT能力的LINE Bot非常簡單。如果你是C#開發人員，甚至可以直接用套件和範本來完成。 你可以先用 .net 6 以上的環境建立 WebAPI專案： md testgptbot cd testgptbot dotnet new webapi 完成後，請一併執行 LineBotSDK和LineWebHook範本的安裝： dotnet add package linebotsdk dotnet new install isRock.Template.LineWebHook dotnet new linewebhook 執行後你會看到底下畫面： 這時開啟專案，會看到這些範本內容，主要是LineBotChatGPTWebHookController 這隻： 這隻是寫好的 LINE Bot 範本，同時支援 OpenAI API 和 微軟的Azure OpenAI API。如果您熟悉LINE Bot的開發，只需要把25行的Channel Access Token換掉，順便把 20 行的 Admin User ID換掉(這是處理發生例外的訊息用的)，這樣主程式就完成了。Channel Access Token和Admin User ID這些資訊你可以從LINE Developers Console( https://developers.line.biz/console )找到： 為了讓這個 LINE Bot 可以支援 OpenAI API，我們把需要一個 OpenAI的API Key，這個Key可以從OpenAI的開發人員後台( API keys - OpenAI API )看到： 有了這些資訊之後，只需要把剛才LineBotChatGPTWebHookController 這隻程式碼中的 117 行調整成 return ChatGPT.CallOpenAIChatAPI(…)，並填入剛才取得的key: 將其運行起來之後，你就可以跟這隻 LINE Bot互動了： 你會發現，有了 Ch...

在Web應用程式開發的過程中，我們常常會聽到所謂的 Claim-Based Authentication或Authorization之類似的用詞，中文常直白的翻成『基於聲明的驗證或授權』。 翻譯沒錯，但『基於聲明的…』中的這個『聲明(Claim)』，有點不好理解。 簡單的說，你可以暫時先把所謂的『聲明(Claim)』理解成一張駕駛執照(或身分證)，由監理單位(或戶政單位)發出，發出Claim的單位我們叫 Issuer。 在傳統的 asp.net core web應用程式當中，身分驗證與授權(authentication and authorization)，預設常常都是走 Claim-Based 來實踐的。其實應該說，當我們進入了WEB 2.0時代之後，網站開始需要與用戶端互動，伺服器端需要識別用戶是誰，並針對不同的用戶給予不同的權限，這時，基於聲明的Claim-Based Identity就逐漸成為主流。 在解釋之前，先簡單提一下驗證(authentication)和授權(authorization)，一般來說，『驗證』是確定你是誰(who)，而『授權』則是確定你能做(或能看、能存取)什麼(What)。 為了實現這件事情，一般的網站在開發時，大致會這麼做： 用戶在使用某個網站時，會先透過瀏覽器以匿名方式進到一個登入頁面。進入該頁面後，會先以帳號密碼(或是其他機制、例如email、SMS)進行登入(Login)工作，這就是驗證。通過驗證之後，網頁系統一般會建立一個由伺服器端發出的Claim，這個Claim就像我們剛才說的駕駛執照一樣，可能描述(聲明)著用戶的個人資訊，以及該用戶可以駕駛的車種(也就是權限之類的訊息)。為了確保安全，一般來說，Claim常會被編碼或加密，然後包裹成為一個Token，甚至加入一些檢核機制，以便於能夠確保該Claim(Token)的合法性(例如足以識別該Token是由誰Issue的)。接著，應用程式就可以拿著這個Token(或實作成cookie)，作為憑證來存取特定的資源。 以上這樣的機制，就是Claim-Based Identity。 你可能會覺得疑惑，那我們在開發 asp.net core 網站的時候，有這麼複雜嗎? 感覺好像沒有做那麼多步驟啊!? 其實有，只是 .net 框架主動為你做了大半，所以開發人員常常不知...