.NET Walker

時代在改變著。認證考試也是。 微軟推出全新的 Microsoft Applied Skills 系列的認證，現在主打免費、隨時隨地都可以考，而且是仿造真實世界的案例實作，也就是說，這是上機考試唷。 通過了，你會得到一個類似底下這樣的證書，證明你在特定領域具有實作能力： 考試時間共兩小時，算是充裕，前提是如果你對於考試的主題真的有足夠認識的話。 你一定以為，線上考試，那不就是可以open book? 應該很容易通過吧，並不一定。 考試是採用網頁進行，網頁中會出現一台可以遠端操作的虛擬機(類似WVD)，考生可以在網頁上透過實作，完成所有題目。 如同微軟一般的認證考試，作答完成送出之後，你會立刻看到結果： 如果你沒通過，會收到底下這樣的訊息： 可以重考嗎？ 可以，但要冷靜一下，７２小時之後才能繼續。 若是考過了，則會出現美麗的綠色畫面： 其實，我還蠻喜歡這個考試的。 首先，它免費。相較於其他認證考試，它不用錢也可以考，沒通過頂多等個72小時，用功一點很容易可以考到過為止。 比起是非、選擇這種考試，Applied Skills 是真的要操作的，這對於真正有在應用的技術人員而言，其實是比較有利的，有時候根本不用特別準備，就可以去考，考了就過。說實在的，就算你原本不會某個領域，能憑真本事通過，大概本來不會的實作完之後也搞清楚了。基本上這個考試的目的就是要你真的搞懂某個技術實作，因此，這考試算是很務實的。 隨時隨地都可以考。傳統認證需要報名、排隊、跑去考試中心、待在小房間裡面幾小時，還不能上廁所😆。但這個考試，你隨時，隨地，想到就考，像我大半夜睡不著，手邊沒劇可以看，索性考個認證，也算是挺有成就感的。 總的來說，這個認證考試挺好玩的。 硬底子的技術夥伴們，不妨無聊的時候考個兩張來玩玩。 瀏覽認證: https://learn.microsoft.com/zh-tw/credentials/browse/?credential_types=applied skills 常見問題: https://learn.microsoft.com/zh-tw/credentials/support/applied-skills-faq#applied-skills----------------

昨天去參加G社群舉辦的活動，想說來認識一下Gemini。 來到了據說是全台灣最高的活動舉辦場合，也具體實作了一下 Gemini API 的使用。 聆聽分享的過程當中，台上講者問大家說：『現在已經有使用 OpenAI API 的舉手? 』(恩…很多)。 又問：『現在已經在使用 Gemini 的呢?』(哇…也不少)。 再問：『那使用 Azure OpenAI 的呢?』 我正想舉手，往四周一看，哇靠，怎麼一個人都沒有! 真的假的? 原來來到不同的陣營，民調數據會差這麼多? 🤔 接著台上講者繼續問大家，用什麼語言寫AI程式，看來 Python 還是大宗，我本來想喊 C# 的，但看看周遭氛圍，我決定暫時先觀望一下。 然後講者開啟自己的 github repo，點選一個 badge ，把 github 的source code 帶到 colab 中，順口又問了一句：『應該大家都用過 colab 吧?』 (我本來又想喊…“沒有”) 沒想到講師立即說：『恩…很好，顯然大家都有用過…』😮😮😮 我偷偷看了一下隔壁的朋友，耶欸，大家好像還真的都挺熟悉colab的呢。哇，果然隔『營』如隔山。 接著我看講者嘩啦嘩啦地在colab中運行每一個程式碼片段，行雲流水，很是順暢。也難怪，大家喜歡用 python，雖然從我的角度來看，一直覺得它其實跟 Visual Basic 有點像。 不過做Labs的過程中，我確實也開始覺得，有寫好的互動式腳本，上課時還是頗方便，大家只需要點個按鈕 clone 過去，然後程式碼都寫好了，只要改改參數，就可以一段一段運行了，難怪大家覺得 OpenAI API 和 Gemini API 用起來很簡單。 但其實，Azure OpenAI 也不難啦~ 做完 Gemini Lab 後，我索幸順手也寫了一個 python 的 notebook ，用 python 來呼叫 Azure OpenAI ，我把它放在 github 上了。又效法講者的作法，為它做了一個 badge ，讓用戶可以從 github repo 直接連到 colab。操作動作如下： 然後我們就可以在 colab 中，透過互動式的方式，一段一段把程式運行完，體驗一下 Azure OpenAI API的呼叫。你看到上面的影片，就是整個操作過程。 由於notebook程...

某天，朋友向我詢問一個問題 ：『Git 版控到底有沒有正確的用法?』 因為團隊成員要求走自己習慣的 Git 協作流程，溝通無效，team member堅持 : 『像是 Git 這樣的工具，使用時沒有絕對的對錯，不是國外的大神說的就是對的，也沒有觀念是否正確的問題…』。 『很有魄力耶』我說。 『但這樣我很困擾啊』朋友無奈地問:『Member這樣講是對的嗎?』 我回答道： 『你可以說對，也可以說不對。 所有東西都是工具，甚至，廣義來說整個軟體開發技術也都是工具， 常常需要因時因地制宜，因此… 對錯是相對的沒錯，但是到底 相對於什麼呢? 得看目的 。』 Git的使用，一般來說，有爭議或選擇的是兩個部分，Repo 大小的分割(專案顆粒度)，以及 git working flow… 拿 git working flow來說，如果是早年的 Git 使用者，多半選擇 git flow，那是有當年時空背景因素的。Git 發展初期，需求是開源專案，開發人員可能並不在同一個辦公室協作，常有跨國合作的需求，當時網路狀況也不像現在品質那麼好，那時分支的建立就相當多且頻繁。 再加上 Git 切分分支的成本極低，到後期，甚至有很多團隊用分支來做為暫時性的程式碼存放或測試，這本身不是問題。但這些分支，終有一天需要合併，每次合併，都帶來不少的痛苦。過去沒有頻繁交付的需求，一兩個月合併一次花花時間，日子也就這麼過了，但如今，不同了。 最近幾年，我們是不建議切出具有 長生命週期 且 數量多 的分支的，因為分支本身就是一種 程式碼隱藏 ，Continuous Delivery 的作者 Dave Farley 就說過， 從 頻繁交付 的角度來看，具有長生命週期且多分支的 git flow 是個不好的選擇: https://www.youtube.com/watch?v=_w6TwnLCFwA 所以，如果要實踐敏捷的頻繁交付(一周數次，一天數次)那我會建議 git 分支數量愈少愈好，分支生命周期愈短愈好，以便能有利於持續整合，實現頻繁交付： 但這是有前提的。 前提是 : 『團隊有良好的自動化CI流程，包含程式碼的靜態掃描、套件安全性掃描、自動化測試…都 必須 在Pipeline中出現。』 如果你想實踐真正的持續整合(CI)，就要盡可能地減少不力於頻繁整合的程式碼隱藏，...

每個月 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 了，那是否會讓開發人員的技術能力降低呢? 』 我還來不及回答，另一位學員開口說了：『這看人吧，搞不好有些人反而會因為能夠看到不同的程式碼寫法，讓...

最近好巧，很多朋友詢問我，DevOps導入前後，該如何評估成效? 或是，企業可以從哪些角度來看自身的 DevOps 現況? 找到可以改善的空間和指標? 或許是因為最近 DORA(DevOps Research and Assessment) 蠻紅的，所以大家開始想了解如何評估 DevOps吧? 其實很久以前 Azure DevOps 的網站中就有這個服務，你可以在底下網址找到 : https://devopsassessment.net/ 進入之後，點選『開始評量』就可以了： 接著，可以在出現的領域中，選擇你關心的部分： 接著會出現一堆類似考試或問卷的題目，請認真乖乖作答，完成之後，你就會看到評估的結果，與改善的建議: 從上表中，可以清楚知道企業目前 DevOps 的成熟度，還有可以進行哪些改善項目，雖然這些項目看起來像是老生常談，但其實是歷久彌新，在公司導入 DevOps 的前後，不妨來這個網站評估看看，相信對選擇改善標的會有很大的幫助。 相關課程： 敏捷開發與Azure DevOps實戰 https://www.studyhost.tw/NewCourses/ALM

上課時，學員發現教室的電腦中安裝了奇怪的 VS Code，它是綠色的 Logo，連忙問我教室是不是被駭客入侵了!? 如同你知道的，VS Code 的 Logo 一直以來都是藍色的，怎麼會突然之間變成綠色呢? 有綠色 Logo 的VS Code 嗎? 不要懷疑，其實還真的是有，當然，也跟政治無關，綠色的 VS Code 長這樣： 它是所謂的 Insider 版本。 微軟很多產品都有所謂的 Insider 版，Visual Studio Code Insiders是VS Code的測試版。它包含了最新的功能和錯誤修復，但是這些新功能可能存在著些許的不穩定性。 Insiders版本 每天 都會更新，包含最新的bug fix和new feature，讓使用者可以嘗試新功能。與普通版本的VS Code相比，普通版本較為穩定，通常也不包含尚未完全測試的新功能。 使用者可以同時安裝和打開這兩個版本 ，並且可以使用特定的擴展來同步兩者之間的設置。因此，Insiders版本更適合那些希望體驗最新功能並願意承擔潛在不穩定風險的使用者。 底下這段影片展示了如何下載與安裝，並且把它和藍色的 VS Code 同時開啟： 如果你是喜歡冒險犯難的勇者，綠色的 VS Code，或許更適合你。

又到了一年一度的尾牙節期。 朋友公司每年參與舉辦很多尾牙活動，身為主辦單位，活動的紀錄當然是重點之一，記錄不是問題，請了一大票工讀生，拍照攝影帶回了大把的素材，等到要整理的時候，才是惡夢的開始。 連續看他唸了好幾年，雖然不關我的事，但我還是很好奇他到底怎麼做影片的整理和歸類的? 『就一段一段看啊?』他說。 『什麼?』我疑惑的問：『 那不是要花很多時間?』 『當然啊，不然怎麼辦?』他問。 怎麼辦，現在 AI 時代耶，當然是用 AI 處理啊。 我跟他介紹 Video Indexer ( https://www.videoindexer.ai/ )，他驚為天人： 這網站可以把上傳的影片逐格(frame)分析，不僅能夠自動為影片自動加上字幕(當然，支援中文)，還自動幫你找到出現在影片裡面的每一個人物： 這個功能非常關鍵，它可以輕鬆地幫我們找到某人出現在影片中的每一個片段，以便於來做剪輯與後製。 以前，活動結束之後，要剪出特定人物的精華集，常常得先看完一整部片子，找出該人所有出現的段落。現在人人都有手機攝影，一場活動下來隨便也拍了十幾二十小時的影片，影片常常還來自不同的拍攝者，事情相當棘手。 如今，透過AI工具，可以直接幫你把某人出現在影片的哪裡，都標註的清清楚楚，使用Web界面點選人頭，就可以跳到該片段出現的位置，非常好用： 不僅如此，AI工具還幫你標出影片中各種場景的tag，highlight各種出現的物件： 甚至還能判斷影片中每個段落的情緒： 有這個工具，你可以輕鬆地找到每一個你想要的精華，即便沒有看完所有的影片與段落，都不會錯過任何細節。 很讚吧! 不用謝，今年辦完活動之後，不要再熬夜剪片，好好睡個覺吧。

最近 AI 很紅，連帶著 Azure AI 詢問度也很高。最近很多企業客戶紛紛參與Azure的 AI 教育訓練。這個訓練課程中， Computer Vision 也是重點之一。 其實 Azure 上的 Computer Vision 功能很強，模型也都封裝好放上雲端，可以透過REST API的方式進行呼叫，從2016年起，我們就在 Blog 上多次介紹過這個 API，相關文章可以參考 這裡 。 但這一陣子頻繁的帶著學員操作，看到學員在使用postman呼叫API時，常發生許多有趣的bug，整理一下，和大家一起分享。 要使用Computer Vision，你只需要申請好一組 endpoint，並且取得 key 即可，這很簡單： 從 文件 上可以看到，使用此API，可以辨識人臉、取得圖片說明、判斷成人圖片，因此你使用了底下這樣的呼叫，可是卻硬生生地得到 HTTP 400 的錯誤： 如果你對 Azure AI 熟悉的話不妨挑戰一下，先停在這邊，看看上面這個呼叫指令可能有什麼錯? 從訊息看起來是 NotSupportedVisualFeature 但你放大觀察 VisualFeature 的部分，看起來也沒啥問題: 哪怎麼回事? 結果發現，網址列多一個空白： 這樣也不行? 對，這樣也不行。 另外學員常常也碰到的錯誤像是收到 404，但 endpoint 明明正確： 結果是，http method用錯： 從Get改為POST問題就解決了。 至於什麼把本來該放在 Header 的 key 錯放到 parameter 結果收到 401 的錯誤，也是見怪不怪了： 這些都很簡單，但是稍微注意一下，會減少你走冤枉路的時間。畢竟，平常工作已經很累了，把時間花在這種 debug 事情上，有些冤枉了。 我們在透過程式碼呼叫雲端的API前，我都建議同仁先用 postman 測試一下，如果測不過，就先別急著寫程式了，先搞定API，測通了再寫code，往往事半功倍，否則如果從程式碼開始卡關，你會debug的更辛苦。😆

前幾天上課的時候，發現原本可以順暢使用的 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)),...