.NET Walker

昨天，在 .net conf 2021，明明講的主題是框架設計的延續 - 套件設計，但其中六七個demo當中，大家看起來最有反應和效果的反而是底下這個語音轉文字的CLI Demo。 影片: 這是一個透過CLI呼叫的語音辨識的服務，挺有趣吧，我只是把它變成command line tools, 也就是CLI工具，這個demo只是一個我想做的語音助理的一半，後半段沒demo出來的是一個語音助理的雛型，也就是透過語言來控制電腦。(還需要整合LUIS以及掛上特定 intent 的 actions) 若想要用語音來控制電腦，第一步當然是辨識語音，你可能沒想到過，現在即便 command line, console app也可以辨識語音(Speech to Text)。 拜 azure cognitive 所賜，如今這已經是簡單到不行的技術。主要的程式碼只有底下這幾行: async static Task FromMic(SpeechConfig speechConfig) { using var audioConfig = AudioConfig.FromDefaultMicrophoneInput(); using var recognizer = new SpeechRecognizer(speechConfig, "zh-tw", audioConfig); Console.WriteLine("嗨~ 請透過語音下達指令..."); var result = await recognizer.RecognizeOnceAsync(); Console.WriteLine($"語音命令 = '{result.Text}' "); } 我把整套 CLI tools的source code放 github上了: https://github.com/isdaviddong/demo-listenup-VoiceCommand 當然你得自己換掉 Namespace 與 Azure Cognitive Services 的key。 如果要申請 Azure Cognitive Services 的 語音轉文字服務，可以參考: https://portal.azure.com

在預設的 Azure DevOps Pipeline範本當中，針對 .net core的專案，你可以透過 dotnet task來運行單元測試，使用的指令是 dotnet test。底下是Yaml code, 這是一個很標準的做法： steps: - task: DotNetCoreCLI@2 displayName: Test inputs: command: test projects: '$(Parameters.TestProjects)' arguments: '--configuration $(BuildConfiguration)' 但使用預設的dotnet rest，並不會產生code coverage報表，雖然我們並沒有想追求很高的unit test code coverage，但出一下報表對我們來說還是很具有參考價值的。 如果你也想要檢視code coverage報表，可以做底下調整。 step 1: 修改 dotnet test task steps: - task: DotNetCoreCLI@2 displayName: Test inputs: command: test projects: '$(Parameters.TestProjects)' arguments: '--configuration $(BuildConfiguration) --collect:"XPlat Code Coverage" -- DataCollectionRunSettings.DataCollectors.DataCollector.Configuration.Format=cobertura' 你會發現在參數的地方，我們加上了 --collect 等敍述，主要是告知 dotnet task運行test的時候，要蒐集相關資訊。 step 2: 增加Publish code coverage results task steps: - task: PublishCodeCoverageResults@1 displayName: 'Publish code coverage

DevOpsDays 2021的會場，有個活動叫專家面對面好像(具體叫啥我忘了)，主要是讓與會者能夠和現場講師有更多互動。當天分享結束後，主辦單位請我去那坐一下(我當然也從善如流的照做了)，正當我回答完幾位學員的問題，準備離開的時候，有一位年紀比我稍長的先生坐了下來，有條不紊的介紹完自己的團隊與專案後，開口問了幾個問題。 其中，有一個很關鍵，大概是這樣的內容：『如果團隊手上非常多插單的情況，導致每個迭代都無法正常進行，這樣適合 run scrum嗎?』根據多年的經驗，這個問題肯定只是表象，背後一定有著其他沒說出來的狀況。 我想了想，反問他：『你們的迭代設定多長?』 『一周或兩周，每個團隊有點不同』他回答。 我疑惑的問：『所以用戶的需求等不及一周的時間? 非得立刻插單不可?』『因為都是一些非常嚴重bug，不立刻處理不行』他說 『那你們真正該面對的不是插單的問題，而是整個專案已經快失控了，這樣等於每天都在救火啊?』我看著他。 他有點不好意思的說：『的確是這樣的。』 『那我的建議會是…』我認真的回答他道：『你們應該停止任何新功能的開發，先把所有的bugs解決，然後找出系統架構上或開發上的核心問題，到底~是什麼原因導致系統bugs層出不窮? 先著手解決它，別讓團隊陷在持續救火的處境裡…』 如果團隊每天都必須救火，那不管你 run 什麼方法都是對專案沒有幫助的，敏捷或scrum的導入不會立刻改變團隊的體質，如果大家的習慣不改變，團隊面對的困境還是會持續僵在那裏。 『但是，如果不開發新功能，這樣專案就不會有進度了啊?』他似乎有些擔憂這個。 如果你不停止開發新功能，去面對團隊本該處理的核心問題，這樣你看到新功能的進度，也只是個假象，終有一天，層出不窮的bugs會在專案的後期吃掉你所有的進展，最終，你會無法交出任何一個功能給客戶。 『恩，我知道』他面有難色地回答。說完謝謝之後，就皺著眉頭離開了。 我知道他心裡的考量和難處。 回到根本，敏捷其實很簡單–就是務實的面對問題，努力交付出用戶真正可以用的軟體。但，在這世上，總是有很多事情，特別是技術面以外的事情，並非那麼的務實。有時候我們的思慮，可能還包含了人情、績效、政治…等等各種其他方面的考量。這時候，問題就被我們搞複雜了。 就如同我在DevOpsDays中說的，敏捷一直都很簡單，但讓一切複雜的，是人。如果

在上Azure DevOps課程的時候，學員問了一個很好的問題。 如果我們採用 Feature Branch，那你會走一個底下這樣的團隊合作流程： 上圖中有一個很重要的部分是，在PR之後所觸發的自動化佈署。 也就是，在feature branch分支被commit/push準備合併到主線前，我們會透過PR進行code review和discussion，過程中當然應該要先針對分支進行build才對呀。如果 build fail 了，那或許根本沒啥好討論了，整個PR直接給個comment然後reject掉就得了。 所以，分支(特別是feature branch)在走PR合併回主線前，針對分支的auto build非常重要，但，這要如何實現? 在Azure DevOps中，是透過 branch policy來實現的: 你只需要設定特定分支(例如master)的branch policy，把開關打開，設定任何從只分支建立出的分支(像是feature branch)，PR後都會觸發個定的build pipeline就行了。 如此一來，圖中PR就會自動觸發該分支的build，這樣，我們的repo owner或是reviewer就可以在code review之前，看看build是否成功: 當然，在build pipeline中，我們也可以先做像是 SonarCloud / Checkmarx 之類的程式碼掃描，如此一來，整個團隊的開發協同運作流程，就更加迷人了。 相關課程： 敏捷開發專案管理與Azure DevOps實戰 https://www.studyhost.tw/NewCourses/ALM

#一起看廣告 昨天晚上，做了個夢。 我夢到在駕駛座上睡著了，然後被後座的其他乘客叫醒，乘客急急忙忙地跟我說：『ㄟㄟ，David，你睡著了啦!! 車還在開耶…』 我回答：『對耶，啊…有自動駕駛啦…』 然後我就繼續睡了… 早上起床突然想到，跟老婆說。 她說：『好啦，收到，我知道你有多想買自動駕駛的車了…』 古人說：『日有所思，夜有所夢。』可能真的是因為，這陣子看了好多汽車廣告。 最近看到 Ford 的廣告拍得很好，分別是林依晨的 New Focus (很值得看) 還有先前張鈞甯的 KUGA: (超好看) 後來又補一個: 上面這兩個廣告我都超推，不看你會後悔。但某天，我看著看著，卻讓我回憶起十多年前的這一支廣告。總覺得 Ford 的車怎麼樣我不知道(沒開過)，但廣告總是拍得很有意境： +壓力-身段×堅強÷任性 換算之後，你是否還記得真實的自己? 當初看上面這則廣告時，自己還是個帶著無限衝勁，剛站穩在職場上的少年。 但，這十幾年(也才十幾年)，很多事情都改變了。環境變了，世界也變了。傲氣收斂成淡淡的執著，衝動則被多慮的思緒給撫平了。 年輕人總是想『做自己』(相信我，這並非時下青年的特色，每一個世代都是)。但，到了最近這個年紀，才發現，原來做自己之前，還得先找到自己。很顯然的，年輕時不顧後果地去凸顯自己的任性，並不是做自己。 當你找到並認識自己是誰，明白自己的能力和限制，還能無畏著外界的眼光，放下纏累自己的包袱，不跟他人比較、不被世俗的成功定義，還有勇氣和餘力踏上自己想走的路。持續走下去…這樣，才是做自己。 『做自己』要的不單單只是一股衝勁，而是認真的認識並面對自己的個性和缺點、堅持著持續超越和挑戰自己的毅力。

如何在瀏覽器中執行 Windows? 要談這件事情前，我們得說說為何會有這個需要? 雖然對我而言，這個需求是顯而易見的。 虛擬桌面的美好想像 過去在企業環境中，使用vmware或hyper-v搭建一整套給用戶的虛擬工作環境，或是採用RDP以multi-session的形式提供用戶透過遠端連入的工作環境，都是企業內很常見的使用方式。 這樣做帶來幾個好處: 用戶端的實體設備等級不用太高，因為大量工作實際上都運行在遠端機房。 安全性容易控制，因為實際運行的程式大多也都在機房。 MIS/IT人員不再需要為每一台用戶端設備傷腦筋。用戶端隨便用任何一台設備，登入遠端虛擬桌面後，都可以立即讓同仁開始工作。 同仁即便在遠端(家裡、網咖)、拿自己的ＮＢ也可以隨時連入工作（WFH居家辦公一次搞定) … 隨手都能舉出好幾個理由，讓大部分MIT/IT人員對於遠端虛擬桌面有許多美好想像(包含我在內)。 自從有了Azure雲端之後，事實上我的桌機或NB的硬體更新頻率越來越低，因為大部分我工作都直接透過RDP用雲端上的VM來進行。這樣有許多好處。包含，有需要時隨手可以把VM升級成16或32G的記憶體，硬碟空間更是要多大有多大，只要網路速度可以，在遠端VM上工作比local實體機效率來的高上不少，算是一個頗奢侈豪華的享受。 對我個人來說，這樣做也有另一個好處，方便我把工作和個人電腦分開，工作我一律用雲端VM，個人NB則大多做些教育訓練或私人的事情，工作時只需要從NB連上雲端VM即可，環境乾淨不容易混亂或衝突。 需要克服的缺點 然而，使用RDP從NB連上雲端windows 10的VM，對很多人來說已經很美好，但我覺得還是有些缺點。當我想要大範圍的導入時，會碰到一些障礙： RDP採用3389 port，常常在企業內有被擋掉的可能。 RDP在MAC環境可以用，但在android和iOS上還是有不少限制。在Windows環境上用戶也需要一點基本概念，才能夠使用。 用戶端的RDP上會保留有連線位置等資訊，在網咖或是外部環境使用相對風險比較高。 Azure WVD解決方案 因此，當我聽到Azure上的WVD解決方案時，實在非常心動。比起單純的RDP和雲端VM(或是地端的hyper-v, vmware)，它有底下好處： 用戶端只需要有瀏覽器(Chrome/Edg

我正在讀一本奇書，裡面有個觀念頗有意思。但在分享之前，我先問你一個問題… 你覺得…過去一年，哪一段時間你的生產力最高? 那段時間會不會正好是你最忙的時候? 其實並不一定，對不對? 也就是說，你可能很忙，但完全沒產出甚麼有價值的成果(俗話說是「瞎忙」)，也可能實際工時很少，但成果豐碩(特別是創作者)。 書中有一個章節告訴我們，如果想提高生產力，你必須減少工作時數(注意，不是增加)。作者覺得，傳統的時間管理很有問題，因為工作時數不等於生產力。這部分你可能跟我一樣，我始終覺得，企業用工時來計算薪資(或是專案成本)是件很奇怪的事情。老闆想要(買)的到底是"成果"? 還是想要 “看到我在辦公室出現”? 這是大家都知道的道理，但如今這個持續了那麼久，讓我們覺得不可思議的薪資和成本設計，是過去一百年來延續出的結果(這邊我要提到另一本過去介紹過的書『組織再進化』，有空可以自己去看看)。你知道，過去(工業革命時代)，“時間就是金錢”，那時候生產線林立，勞工的上班時間就100%等於產出時間，下了班離開了工廠、沒了生產設備就什麼事都不能做(也就是沒有產出)。 因此，在那個時代，工時=薪資(或成本)是很有道理的。但，這已經是將近一百年前的事情了，想想好玩，如今我們的勞基法的基本精神卻還是基於那個年代? 而今天，對我們(特別是開發、創作人員來說)，工時跟生產力之間根本沒有必然的關係。你一定有這種經驗，有時候你靈思泉湧、創作如同神來之筆，半小時內可以完成平時三四倍的工作量。而另一些時間，你可能沒睡飽或因為私事思緒混亂，這時就算在辦公室待上一整天也做不完任何一件事情。 所以這本書的作者認為，“時間” 根本並不重要，專注力與精力才是重點。(好啦，他其實沒這麼說，他覺得時間也很重要，但不是唯一重要) 同時，他還做了一個有趣的實驗，實驗結果顯示，當工時加倍，其實最終的有效工作產出只比工時減半時增加了 “一點點”。但有趣的部份是，當事人總會 “以為” 自己的產出很高(因為感覺自己很忙)，但統計之後則是發現 “根本沒有”。 我覺得這也解釋了，為何辦公室中許多主管很喜歡一直開會，因為開會會讓自己主觀上覺得一直很忙、一直有產出，但其實…你知道的，根本沒有。 所以，總的來說。 工時越長，並不代表工作成果(或產出)會越好 傳統時間管理很有問題，因為重要的(你想要的

前面 說過，最近因為WFH的關係，協助了一些公司將許多地端的OA相關應用移動到像是Microsoft 365、teams、與Azure等雲端環境上，以確保萬一封城或是台灣大規模分區停電下，企業主要服務依舊可以透過雲端來存取和運行。也因為如此，上次和大家分享了 如何在家裡透過VPN連上Azure ，以安全的方式來存取雲端資源。 但除了讓用戶走VPN去存取雲端資源，以避免讓雲端上的資料或服務公開在網際網路上(讓駭客當箭靶)，另外一個非常基本卻重要的機制，是使用M365/Teams/Azure等雲端服務的企業不該忽略的，也就是2FA(Two-Factor Authentication)。 很多企業用戶可能根本不知道，瀏覽器上常見的登入行為，本身就有機會造成資安疑慮的最大風險，只要用戶在不熟悉的電腦上登入(例如網咖、公用電腦、別人的筆電…)或是用了不熟悉的網路(像是車站、咖啡廳、或是網路上隨意搜尋到的免費WIFI分享網路)，都很可能在無意之間讓你的帳密外洩。 由於Azure和Microsoft 365(包含MS Teams)都是攤在網際網路上的服務，倘若用戶一不小心帳密外洩，那造成的風險恐怕也是不低的。 如何讓帳密更安全嚴謹的使用呢? 答案就是2FA(Two-Factor Authentication)，關於2FA的細節你很容易在網路上找到，這邊就不多提了，總之微軟除了讓用戶以帳密登入以外，還提供你多重的身分驗證機制，例如手機簡訊就是其中之一。 簡單的說，你可以將M365或是Azure帳密設定為 – 在陌生的電腦上登入時，即便正確輸入帳密，還得再透過手機簡訊進行2次驗證(也可以用App進行驗證)。如此一來，可以大幅增加駭客的攻擊難度，避免你在密碼不小心外洩(或被猜對)時，遭受到駭客的入侵。 讓admin開放此功能 設定的方式很簡單，首先，你必須讓M365(Teams)管理員幫你從後台開起這個功能，它位於M365的admin center–>設定–>組織設定–>多重要素驗證： admin可以透過底下UI找到要開啟此功能的用戶，並且點選『啟用』即可： 你會看到底下畫面： 用戶設定2FA驗證(以手機簡訊為例) 啟用之後，下次該用戶成功登入後，就會發信自己被引導到底下畫面： 進入下一步之後，系統會讓你選擇第二重驗證方式： 你可

在一般的承平時期，企業內部網路要連接到位於雲端的服務，可能會採用 site to site VPN的形式，也就是把企業內網與Azure雲端的虛擬網路透過VPN互聯，達到安全連線的效果： 需求 但最近這幾周，很多企業開始居家上班(WFH)，導致用戶需要從家裡存取雲端上的服務，不管是伺服器、網站、資料庫、或是檔案系統…這時候，該怎麼辦呢? 你可能會說，這很容易啊，位於azure上公有雲的服務，都有對外(對internet)的IP，只要開放讓同仁從家裡連線不就得了? 當然不行，因為如此一來，等於把企業的應用攤在網際網路上讓駭客當箭靶練習入侵，因此，我們還是必須走一個安全的方式才行。 做法有兩種，一個是在企業的防火牆上，開放用戶透過VPN從家裡連線的管道，讓用戶先從家裡連到公司，再從公司透過VPN存取雲端的服務。但這樣等於是透過企業機房作為橋接，大部分公司我猜也是這麼做，但有個小缺點，如果台灣斷電(別跟我說不可能)，那所有的服務就只能停擺了，即便根本沒受影響的雲端服務也是。 因此，另一種作法呢，則是直接讓用戶從家裡以VPN連線到 Azure 雲端服務，直接存取企業在Azure雲端上的資源，如果你根本把整個企業機房(或上面的主要服務)都移上雲端上(做異地備援或主要服務)，更適合這麼作： 這篇文章要介紹的，就是上面這個模式。 如何讓員工，直接透過VPN，從家裡(其實從公司也行)透過網際網路安全的連線到企業位於公有雲上的資源。 環境說明 好，為了說明這個情境，我們建立了一個簡單的模擬。請再仔細看一下上面這張圖，其中有幾個需要注意的部分: 假設企業在雲端有兩台VM(提供了企業的主要應用，先別管是DB還是AP是WEB…反正就是個情境)，IP位置分別是10.0.0.4, 10.0.0.5，這兩台VM使用同一個虛擬網路，其子網路是10.0.0.0/24，這個虛擬網路就是待會我們要讓員工從家裡連上的虛擬網路。 為了讓員工從家裡安全的連上虛擬網路，我們有設置了一個Virtual Network Gateway，員工要從家裡連上虛擬網路，必須通過這個Virtual Network Gateway。 從家裡連上Virtual Network Gateway的工具，是Azure VPN Client，而我們用的驗證方式，是採用Azure AD 驗證，這意味著你必須要有

『如何在CI/CD Pipeline中發送LINE通知訊息?』有次，Azure DevOps上課時學員問了這個問題。 我聽到之後忍不住說：『這位同學你問得太好了!!!』 耐不住心中竊喜，繼續說道：『本人剛好有 30秒可達成的全球最佳 解決方案。😁』 要知道，關於LINE和Azure DevOps這兩個主題，分開來討論時我也向來是不落人後的，現在這兩個主題合在一起，那我當然就更不客氣了。 開啟Pipeline，我說『請看，第一個步驟，在pipeline中，加入『Use .net core』task： 接著，第二步，上 LINE Notify官網 ，建立一個發訊息給你自己(或群組)的LINE Notify Token： 你會取得一個長得像底下這樣的token: 3QrpcH5XauJVoFCoSxbuWJH747TkC7yW5aXfsDk7RsM 然後，第三步驟，在Pipeline中，加入一個PowerShell Task，在inline script中填入底下指令： dotnet tool install --global line.cli line notify -n 3QrpcH5XauJVoFCoSxbuWJH747TxC7yW5aXfsDk7RsM -m "$(Build.BuildNumber) is done. 狀態: $(Agent.JobStatus)" 然後? 然後就完成了。 現在，你可以自由的在上面這段script中發送訊息給自己(或自己的群組)，當然還可以帶入環境變數$(…)。如此一來，每當CI build完成之後，不管成功或失敗，你都可以即時地取得通知，例如： 這一招，我們採用的是跨平台的 .net core，因此，不管你的build agent是MAC、Linux、還是Windows通通都支援啦😎。 相關課程： 敏捷開發專案管理與Azure DevOps實戰 https://www.studyhost.tw/NewCourses/ALM LINE Bot與人工智慧實戰 https://www.studyhost.tw/NewCourses/LineBot