.NET Walker

很多人一開始使用Azure DevOps的時候不知道，其實Azure DevOps有內建的Git Repos，也就是說，你根本無需自行建立Git版控環境或伺服器，就可以享有相關的功能。不僅如此，使用Azure DevOps內建的Git Repos還有諸多的好處，像是可以在前面介紹過的Backlogs/Tasks上，直接建立/關聯到版控的Branch(分支)，連帶著讓PR(Pull Reuqest)串起整個開發流程。 千萬別小看這件事。這件事是提升你的程式碼品質和控管的一大關鍵，如果沒有使用這個功能是很可惜的。 [1] 我們來看，當你在Azure DevOps中建立好一個新的專案之後，可以點選Repos中的Files： 一個新的專案會內建一個空的Git Repos(上圖1)，但其實你還可以為專案建立多個Repos(這個以後有機會我們再談)。剛建立好的Repos會如上圖。 你可以很簡單的匯入某一個既有的Repo (例如從GitHub或其他Git Repos)到當前這個Repo中(上圖C)。如果你的用戶端已經有既有的專案(且在用戶端也已經透過git init建立好用戶端版控環境)，那你可以透過很簡單的幾個指令，就把用戶端的程式碼推上Azure DevOps雲端中的repos(上圖B)，你也可以用各種開發工具以HTTPS或SSH的方式連結到這個Repos(上圖A)： 大概主流的開發工具Azure DevOps都支援了。 不管是你要把開發端既有的程式碼推上去、或是Clone(Import)其他Repos、還是直接連上空的Repos…其實都很簡單。 關於Azure DevOps Repos的使用，我自己喜歡的流程是這樣： 1. 先建立好一個Azure DevOps專案 2. 透過上面(上上圖中D所示)的『Initialize with a README or gitignore』功能，先為預設的Repo建立好初始環境 3. 以用戶端的開發工具連上這個Repo，把該Repo clone下來 4. 如此一來就可以在筆電上進行開發了 我們來看一下怎麼做，首先，我們先進行(上圖D的)初始化： 如果你是.net開發人員，你可以在初始化時，選擇Visual Studio(上圖1)的gitignore範本(這會幫助你排除一些不需要簽入上去的檔案，例如.dll)。至於README檔案我是會勾的...

敏捷的概念讓我們拋開了以前複雜的規格書、以及用Word、Excel（我甚至還有看過用Power Point的），來蒐集和撰寫需求的作法。 而是把初期訪談的需求先寫成很簡單的Backlogs(可能就只有幾行文字描述的User Story)，然後就先放著，和用戶一起排好優先順序(這比較重要)，等到差不多準備開發（也就是快要將Backlog移入Approved這個Column變成SBI）的那一刻前，才跟用戶確認具體的需求內容與規格細節。 搭配Azure DevOps的看板，可以一目了然的看到當前的工作項與開發狀況： 這一篇我們來看在Azure DevOps的環境中，如何建立Backlogs來記錄需求。 在系統中，我推薦兩個地方來建立Backlogs。 第一個是底下這個畫面，他適合一次輸入大量Backlogs。我自己會讓PO，在專案啟動時，一開始跟用戶談需求的時候，用Azure DevOps底下的這個介面： 這是主選單中Boards分類裡面的『Backlogs』功能， 第一次 點選時，點選後會出現上面這個畫面，然後你可以選擇『+New Work Item』來建立新的工作項目，由於我們正在跟用戶蒐集新的需求，所以我們選擇『Product Backlog item』即可(上圖1)。 然後把用戶想要的功能(Wish)，填入到畫面中的文字方塊(上圖2，我知道，只有一行…而不是一大塊區塊)，然後按下『Add to Top』按鈕(上圖3)。 That’s it. 用戶可能會告訴你他需要很多功能，你就一筆一筆敲到畫面上，不需要逐筆討論細節，就先輸入進去，我們只是框一個範圍。你如果真的操作，會發現這個畫面有個好處，你直接在下圖的欄位中，輸入完用戶提的需求，直接按下Enter，又可以輸入下一筆： 不久之後，你大概可以蒐集到上百個項目(item)，或許每一個項目的顆粒度大小並不一致，先別擔心，我們後面還有時間可以整理。如此這般，我們先把每一個需求列進來即可。 如果某一個需求你真的有必要記錄一些細節，你還是可以Double-Click它，將backlog item開啟進行編輯： 在Description這個欄位(上圖1)中，你可以輸入跟這個需求有關的一些說明，可以輸入文字、貼上圖片、或是超連結…。我們後面會在更仔細地談談Backlogs的輸入，先知道這些已經足夠。 現在，我們去談需求時，只管需要...

沒想到，隨手寫著寫著，居然整理起來已經這麼多篇了? 真不知道是累積了多少時間之後的結果。 但就如同我常說的，我從沒想過要立定什麼太遠大的目標，就是這樣寫著寫著，看起來也應該夠出本書了(但大概不會有人買)，改天，我再來整個整理一下… 敏捷思維、敏捷人生 你準備往哪裡走…? Improvise 產品的價值 你只要堅持一天就好… Reactive 就說了，敏捷不要推動! 神聖不可侵犯的規格書 談需求，不要談功能 保持模糊的共識? 真正的需求訪談，是談價值、而非只談功能。 MVP(最小可行性產品)的重點不是雛形、不是迭代、不是探索需求、而是實現價值!!! 這些問題都不在Scrum 飛機上的27A - 談敏捷開發的成案問題 團隊開發 軟體開發的改變、困境、與挑戰 讓團隊溝通? 比你想像的容易… 重要的事情先做 如何培養你的『溝通力』 再談薛西弗斯的石頭 PM，你必須真的在乎團隊才行 偏執狂系列 If somethings difficult or painful, do it more often. 唯有偏執狂得以倖存 專業主義的秘密 - 練習 preparation is the key... 誰管你準備好了沒? 別再只問我要答案，這次沒有! 提升你在企業內的價值 什麼是專業? 命苦是自找的... 如果，不愛了呢? 假日撰寫吾code，不亦說乎 ; 寫code不問時程，不亦樂乎 ; code而不求天下知, 不亦君子乎~ 把程式寫好容易，把程式寫到能賣出去，很難… [周末留點時間給自己]起初的心情... 特權 天下本無事 如果人人都能寫程式??? 你為了什麼寫Code呢??? 專案中一個幾乎遙不可及的夢 - 專人專用 其實你才是台灣之光... 台灣的軟體人才在哪裡? 在努力背後... 技術並非唯一的解決方案 2011 出發吧... 走進廚房，才知道食材的好壞... 持續地改變是必然的趨勢... 白日夢系列 我的咖啡館 我的咖啡館 之 精緻輕食套餐

你一定看過底下這張圖，對吧。我得先說，這可能不是一篇政治正確的文章... 但我還是歡迎大家補充自己的看法... 有次上課時，有位擔任主管的學員在課程休息時間問我：『到底DevOps能對公司帶來什麼價值?(翻成白話就是…它真的有用嗎?)』這問題看起來不難回答，我腦袋裡立刻蹦出一堆答案，但…我要如何在30秒到1分鐘的時間內，讓學員有個本質上的概念呢? 前陣子我一直在思考這個問題，剛好這時候，我在FB上看到朋友貼來的一張圖，我猜你肯定也看過。 後來這張圖還出現了好幾個版本，基本上目的都一樣，就是揶揄客戶的不講理。也的確，這世界上沒有白吃的午餐，軟體開發和商業設計很像，同時要快、要好、又要便宜，天底下哪有這種好事? 正當我也想轉貼出去的時候，突然轉念一想，難道真的沒有可能讓成品的交付 又快、又好、又便宜 ? 如果有呢? 那實現出這個成果的企業，豈不是能夠領先其他競爭者一大截? 而且，如果這件事那麼不合理，為何幾乎每一個客戶都這麼要求呢? 甚至包含我自己。 前陣子我在印製一批教材的時候，我對印刷廠的要求似乎也是這麼的『不合理』，我希望它印製成本要低、品質當然不能拙劣、關鍵在於速度，由於訓練課程即將開始，我希望三天內可以完成…，回頭一想，我自己不就是那個傳說中的奧客嗎? 結果呢? 結果印刷廠還真的完成了(使命必達!)。不是應該不存在嗎? 為何印刷廠實現了這件事呢? 我不知道他們怎麼做到的，但我回想最近這十年印製教材的經驗，我發現，比起十年前，現在確實是又快、又便宜、品質也好上了一大截。是怎麼回事? 如何讓理當『不存在』的事情發生的? 這部份就不難理解了，我想是因為『產業升級』。最近這十年客製化小量印刷的技術不斷更迭(當然也是拜IT技術所賜)，許多只有一兩個員工的小印製店，靠著電腦和幾台印刷設備，就可以印製出媲美印刷大廠的成品品質，印製時間和成本還來的更低。 產業升級 ，讓過去被視為 不存在 的交集點發生了。 而DevOps根本就是軟體開發領域在最近十年中最大的『產業升級』。在DevOps中我們強調頻繁交付(速度要快)、我們強調程式碼自動測試、在CI/CD Pipeline中的系統安全弱點掃描(品質要好)、我們強調減少浪費、讓開發成本有機會可以降低(要便宜)，我們不正就是在實現過去認為不可能的事情嗎? 面對全球化的競爭，許多廠商正在改變，改變的不只是觀念思維，也包含開發方法、技術...

自從開始用VS Code之後，過去在Visual Studio上的一些行為，也逐漸希望在VS Code當中一樣可以實現，最主要的當然是為了實踐跨平台，讓非windows用戶，也可以順暢的使用並參考我們所撰寫的文件和教學素材。 最近在寫 .net core Web範例，所以當然需要把寫好的.net code網站範例透過VS Ｃode發佈到Azure WebApp上，CI環境用慣了，正當準備從Client端的VS Code發佈時，突然一愣，ㄟ…用VS Code怎麼發佈啊。 VS Code沒有像是Visual Studio那樣的發佈選單啊…找了一下，發現需要安裝Azure App Services擴充套件： 安裝後，你可以在command line透過 dotnet build; dotnet publish指令，把.net core應用建置封裝: 然後你可以在輸出資料夾中，看到publish目錄，你在該目錄上按下滑鼠右鍵，就會發現Deploy to Web App功能出現了： 後面就容易了，點選後會出現Sign in Azure引導你登入Azure： 登入成功後可以選擇你的訂閱帳戶： 再來可以選擇該訂閱帳戶下的WebApp(或新增)： 後面就自動幫你發佈上去囉： 哈，其實還蠻簡單的嘛… ----------- 線上課程： https://www.udemy.com/line-bot/ 最新實體課程： http://www.studyhost.tw/NewCourses/LineBot 電子書： http://studyhost.blogspot.tw/2017/12/line-bot.html 實體書： https://www.tenlong.com.tw/products/9789865022662?list_name=srh LineBotSDK： https://www.nuget.org/packages/LineBotSDK 如果需要即時取得更多相關訊息，可按 這裡 加入FB專頁。若這篇文章對您有所幫助，請幫我們分享出去，謝謝您的支持。

If somethings difficult or painful, do it more often. 這句話似乎有點黑色幽默。你知道我在哪邊看到它的嗎? 是Azure DevOps的教材中。不可思議吧，剛看到的那刻我一頭霧水，它是怎麼會這麼不搭的出現在教材裡? 然後，我努力地搜尋，發現第一次出現這句話相關的內容，是在Martin Fowler的blog: https://martinfowler.com/bliki/FrequencyReducesDifficulty.html 它讓我想起以前在某本書上讀到的一段話，『 如果你想成功，就拼命去做自己明知該做但卻不想面對的那些事情。 』理由很簡單，因為我們始終得去面對我們該面對的事情…早晚而已。 為何要 盡早且頻繁 的去做那些我們不想做的事情呢，Martin Fowler給了三個看法。分別是 Smaller chunks、Feedback、Practice。 越討厭的事情就要越早做，免得積壓起來變成一大塊，那時候你就更不想做了。而且，一小塊一小塊的去進行，比起特別空出一段時間一次做完，其實來的輕省的多。Martin Fowler提到Database migrations就是這樣，我覺得其實不只，根本重構也是。 (平常有掃地，過年的大掃除就可以輕鬆一點；每天做一點功課，就不用期末前拼命趕報告K書的概念…) 而一小塊一小塊地進行，更容易讓我們 即時取得反饋 (不管是來自外在 環境 的、或是來自 客戶 的)，這樣可以讓我們經常持續性的檢視自己的方向是否正確，如果把討厭的事情堆積起來，等到非做不可的那一天才做，那些會造成你卡關的問題常常來的讓你措手不及。 (平時不運動，等到發現自己身體有問題才開始運動，你的體能和身體狀況往往已經吃不消了的概念) 最後一件事情，就是『練習』。 確實，很多事情看起來很難(不然我們也不會想要逃避它)，但當我們去面對它，常常練習之後，它會開始變得容易，如此反覆進行之後，本來看起來很困難的事情，慢慢的你會越來越熟悉和上手，這時候原本的難度會開始漸漸消失，困難的事情也就變得不再那麼困難了。 藉由反覆練習，你會熟悉踩過的坑和需要注意的事項，久而久之將變成習慣，在外界的人眼中，你似乎是天生好手，但你知道，其實也不過是因為你常常練習罷了。 很有趣吧。 If somethings difficult...

在command lin(命令列)e發送LINE Notify的免費推播訊息，我想實現這個功能很久了，因為身為系統管理與開發人員，在許多系統管理與維運場合我都會用到。 先來看看執行結果，你可以在命令列中執行底下指令，它會讓你免費發送一則 LINE Notify 訊息給你指定的(訂閱你的通知)的用戶(或群組)： C:\> line notify -n C02hfClbZuqo9cKQk4uckWQdGLYJBgHNKpldgL1ialx -m "test" {"status":200,"message":"ok"} 上面這段命令中，-n後面的參數是LINE Notify Token，代表某個訂閱者(或群組)，而 -m 後面的參數則是你要發送的訊息。 上面指令的執行結果如下： 要怎麼實現呢? 其實很容易。不管是MAC或是PC/Linux環境，你只需要先安裝好 dotnet core 3.1 SDK , 然後執行底下指令： C:\> dotnet tool install --global line.cli 這會在你的環境上安裝好 LINE CLI，你會看到類似底下的訊息: 您可以使用下列命令來叫用工具: line 已成功安裝工具 'line.cli' ('1.0.15' 版)。 接著，就可以透過底下這樣的指令免費發送訊息給特定用戶了。 C:\> line notify -n C02hfClbZuqo9cKQk4uckWQdGLYJBgHNKpldgL1ialx -m "test" 除了可以發送文字訊息，當然也可以發送貼圖，類似底下這樣: C:\> line notify -n C02hfClbZuqo9cKQk4uckWQdGLYJBgHNKpldgL1ialx -s 1,2 也可以發送特定圖片: C:\> line notify -n C02hfClbZuqo9cKQk4uckWQdGLYJBgHNKpldgL1ialx -i [https://圖片url] 請留意上面 -n 後面的參數是 LINE Notify token，這是訂閱你的LINE Notify通知的用戶。是的，本質上它是透過LINE N...

接續著 上一篇 介紹如何用 .net core的WebAPI來建立 LINE Bot WebHook，這一篇我們介紹如何使用 .net core的 razor page web app來建立發送(push)訊息的LINE Bot。 請先確定你使用的是.net core 3.0以上(建議3.1)的版本： 接著透過『dotnet new webapp -n test01』指令，來建立一個新的WebApp： 建立完成之後，別忘了先透過CD test01指令切到專案所在的資料夾，然後我們用底下指令，來安裝幾個套件： dotnet add package isrock.web.core.razor 執行結果如下: 接著是重要的步驟，請利用底下指令，安裝我們在nuget上的linebot範本: dotnet new --install isRock.Template.LineBotPush 成功執行之後，請繼續執行底下指令: dotnet new LineBotPush 你會看到該範本的程式碼已經加入我們專案中了，接著，我們用 『code .  』指令來開啟vs code： 你會看到專案中已經有我們寫好的範例程式碼。現在已經可以執行了。 請在VS Code的終端機中，用dotnet run執行這個WebApp: 開始運行之後，你就可以在瀏覽器中，以 https://localhost:5001/__samplelinebot 網址來執行該頁面: 您可以在上面這個頁面中，輸入channel access token, user id…等資訊，當然還有要傳送的訊息，按下Push即可發送訊息。 程式碼相當簡單： 詳細的操作影片可以參考底下: ----------- 線上課程： https://www.udemy.com/line-bot/ 最新實體課程： http://www.studyhost.tw/NewCourses/LineBot 電子書： http://studyhost.blogspot.tw/2017/12/line-bot.html   實體書： https://www.tenlong.com.tw/products/9789865022662?list_name=srh LineBotSDK： https://www.nuget.org/pa...

習慣使用.net framework的開發人員可能會覺得，用.net core開發LINE Bot比起傳統的.net要難上一些，甚至覺得沒有Visual Studio好像總是不很方便。倘若告訴你，其實使用 .net core開發LINE Bot要比傳統 .net 快得多，信不信? 底下就挑戰一下如何在安裝好 .net core 3.1的環境中30秒內建立一個 LINE Bot WebHook囉。 首先, 在命令列使用底下這行指令可以幫你建立一個空的WebAPI專案: dotnet new webapi -n test01 然後切換到 test01 這個資料夾中。 cd test01 接著執行: dotnet add package LineBotSDK 上面這行指令會幫你剛才建立好的WebAPI專案添加最新版的LineBotSDK套件。 接著，請執行底下這行: dotnet new --install isRock.Template.LineWebHook 上面這行指令如果成功執行，系統會從網路上下載一個範本套件，安裝到你的開發環境上，上面這行指令只需要執行一次，除非套件有更新，否則以後就毋須重複執行。 正確的執行完畢之後，接著你就可以執行底下這行指令： dotnet new linewebhook 上面這行指令會為你的WebAPI專案，添加一個LineWebHook範本程式碼，完成後顯示如下： 這時候，你可以在命令列下 code . 以visual studio code開啟剛才建立好的專案: 開啟Visual Studio Code後，你會發現剛建立好的WebAPI專案中，已經包含一個預先寫好的LineWebHookController.cs，這是透過前面 dotnet new linewebhook 這行指令產生的: 接著，您只需要將程式碼中第21行的ChannelAccessToken換成你LINE Bot的ChannelAccessToken，將16行的AdminUserID換成你的Admin User ID就完成囉。 哇啦，你的.net core 3.1版LINE WebHook寫完了。碼表停止。 要不要挑戰看看？你能不能在30秒內完成？嚴格說起來，指令只有底下幾行: dotnet new webapi –n [專案名稱] cd [專案名稱] dotn...

前面 提過，LINE是一家非常熱愛Open Source的公司，諸多的solutions中，十有八九是藉由純Open Source技術來實現的，你很少很少很少看到其他軟體大廠的服務在LINE出現。也因此，當我在議程表當中，看到有Microsoft相關的場次時，不由得眼睛一亮，身為MVP，說什麼我也得前往瞧瞧… 議程表當中，共有兩個與Azure有關的場次，一場是由Kenichiro Nakamura分享的How to optimize bot development lifecycle with DevOps(這場非常有意思，我待會說)，另一場則是Ayako Omori的Developing chatbot with Cloud 101 for LINE account auto-reply，兩場都是純日文演說，我也都硬著頭皮參加了。 Bot Framework Ayako Omoris那一場是少數沒有英文即時翻譯的日文演說，導致我基本上是完全聽不懂講者在說什麼，不過，我卻大致可以掌握整場的內容。很矛盾? 一點也不。 因為內容是我非常熟悉的Azure Cognitive Services與Bot Framework，我發現技術語言是跨國籍的，我雖然完全聽不懂講者的日文，但只看Demo和操作，基本能夠掌握八成左右(所以如果讀者想去國外工作，大可不用過度擔心語文的問題)，講者除了大致完整的介紹了MS Bot Framework與LINE Bot如何整合，還有如何使用LUIS和QnA Maker服務，這些過去我在 書籍 和 線上課程 中大致也都有介紹，講者能在幾十分鐘的時間內把這些內容都塞進去，也算是不容易了。 除此之外，她也提到了MS最近釋出的 BotFramework-Composer (這就是個新玩意了)： Bot Framework Composer是一套 open source 的Chat Bot設計工具，可以讓你用視覺化的方式來建立Chat Bot。除了支援上圖這樣的所視及所得對談設計界面，也支援LUIS和QnA Maker，讓設計人員可以自由的使用這些雲端服務並整合在Bot當中，雖然目前還只是預覽版本，但未來頗值得期待。我知道台灣坊間也不乏這樣的工具，但掛著微軟的招牌，加上又是open source，背後有MS Bot Framework撐腰，又有自然語言語意...