.NET Walker

今天上課的時候，跟學員介紹Azure Web App，它是我最喜歡(應該也是使用最多的)Azure PaaS服務。原來，還有很多人不知道，Azure Web App很久以前就可以 No Code 的加上身分驗證與授權的功能。 對，不用寫任何一行程式碼，作法很簡單，只需要30秒設定即可: YT Video: 可能更多人不知道，若要登出，只需要 redirect 到網址: http://domain/.auth/logout 若要登入，則只需要 redirect 到網址: http://domain/.auth/login/aad(或facebook...etc.) 即可，非常簡單。 這個機制等同於是幫你內建寫好了一組身分驗證的程式碼，你完全不用在C# code當中做任何事情。當然，若你想要，也可以透過程式碼抓取到用戶的登入身分是誰，例如： Request.Headers["X-MS-CLIENT-PRINCIPAL-NAME"]; 這個功能內建支援 google, Facebook, MS, Twitter, Apple ID…etc. 應有盡有(除了LINE Login😭) 其實，如果沒空，你真的不一定需要學太多身分驗證的相關技術啦，把網站佈署上Azure Web App，啥事都輕鬆搞定。 相關資源: User identities in AuthN/AuthZ - Azure App Service | Microsoft Learn

今年參加 Agile tour taipei 2022 除了當任講者，當然也趁機聆聽了許多場不同講師的分享，覺得收穫頗豐。 其中一場George(詹喬智)分享的『從調適性領導看敏捷的推動』，相當引起我的注意。George分享時，談到了 Succeeding with Agile 一書作者Mike Cohn強調的 ADAPT model，讓我這個參與多次敏捷導入的人特別有感。 書中提到敏捷導入的幾個關鍵步驟，分別是 A wareness, D esire, A bility, P romote and T ransfer，而這幾個字的字首，就組成了ADAPT這個字。 在一個對 敏捷/Scrum 完全陌生的環境中，怎麼讓同仁從 意識到(Awareness) 團隊/企業有改變(導入某種技術或方法)的需要，進而引發同仁對導入的渴望(Desire)，然後培養同仁所需的能力(Ability)，接著才進行推廣(Promote)，最後透過持續的典範轉移(Transfer)將導入面擴大(Scale, 規模化)，這個系統化的做法，大致描述了推動者該有的步驟與順序。 擔任敏捷/Scrum和DevOps導入的顧問服務多年，我對這個程序特別有感。我常常看到很多 Scrum Master，在企業中陣亡的原因，剛剛好就是因為沒有遵循這個系統化的作法。 一拿到老闆發下的令牌，就好像握有尚方寶劍般的開始強推敏捷轉型，誤以為同仁都和自己一樣，對敏捷充滿了渴望，殊不知，往往只有自己一個人在自嗨而已… 在同仁沒有意識到(Awareness) 自己(與自己所屬的團隊)有轉型的需要前，是不會有任何動力去培養轉型所需的能力(Ability)的(因為大家都很忙)。這時，任何強加上去的教育訓練或協助，都會像是投入池塘的小石子，即便泛起漣漪也難成大浪。 反倒是，同仁若對轉型有足夠的了解後，自己開始有了對轉型的渴望(Desire)，這時，培養同仁的能力所舉辦的任何教育訓練或是其他活動，都會相對容易獲得支持和歡迎，且會被視為是一種對同仁的友善協助而非干擾。 ADAPT，是一個非常好的提醒，對於在企業中想導入敏捷和DevOps等數位化轉型的推動者，都是一個很值得參考的模型。 覺得在你的企業內很難推動 敏捷/DevOps/單元測試(Unit Test)/OOO/XXX/… ? 想要讓同仁進行Pair Pr...

當你在Azure服務裡面，看到 “Managed” 這個字眼，大多被翻譯成『受控XX』，例如我們現在要介紹的這個『受控憑證』。這是一個可以讓你的網站免費享有SSL憑證服務的好東西。 這年頭 網站已經不能沒有SSL 應該是眾所周知的觀念，過去，我的非商用網站大多使用 ZeroSSL 或 Let’s Encrypt 這種免費的憑證，但用起來頗為麻煩，有要額外申請，有的管理手續繁瑣。 最近我開始試用Azure Web App的『受控憑證』，發現我沒有再使用其他憑證的理由了。因為… 免費 可和Web App站台一起管理 建立操作非常容易 使用的方法很簡單，首先，確定你的網站有B1以上的level： 接著，請自行建立你需要的domain(如果你以前用過SSL，應當知道該怎麼做)，然後在Azure Web App的管理後臺點選到『TLS/SSL 設定』的畫面，選擇 『私密金鑰憑證 (.pfx) --> 建立 App Service 受控憑證』： 接著，選擇你設定好的domain，並且建立該憑證: 建立完受控憑證之後，再到繫結畫面進行設定即可： 這樣就搞定。 免費，簡單，好用。👍

沒想到這題會變成有網友敲碗要求解答的問題? 我在TW MVC的 .net conf mini 研討會中，大致描述了在 DevOps 採行高強度的持續交付時，團隊應該要做單元測試(unit test, UT)的原因。 議程後，有學員提問：『老師建議要做unit test，但同仁的程式碼大多是CRUD，似乎沒什麼測試好寫的? 這樣要如何提高測試程式碼覆蓋率?』 當時我的答案是：『如果真沒什麼東西好測的，那就別寫了，不需要為提高覆蓋率來硬寫測試程式。』這個答案乍聽之下可能讓人疑惑，特別是那種對於工程技巧實踐極端渴望，到近乎有些強迫症的工程師。 然而，現場學員這個問題的背後，真正的核心問題應該是，為何你寫的程式碼都沒啥東西可測的? 要探索這個問題，得先回到單元測試的本質。我們之所以要寫單元測試，大約有底下幾個原因： 減少人工手動測試，建立自動化回歸測試。 or 將測試案例(test case)自動化。 確認重要的核心邏輯程式碼不會出問題(確認你的程式碼堅固且可被驗證) 提高可維護性的確據(確保不會改了這邊，壞了那邊) 便於類別開發(例如開發API、或商業邏輯類別函式庫) … 差不多上面這些，是我聽到大多數人想做單元測試的原因。 但問題來了，我在養成班或是許多剛進入開發領域的工程師身上，大多碰到一個問題。就是…他手上寫的程式碼幾乎都是很基本的資料庫CRUD，再不然就是畫面UI的處理，就還真沒什麼複雜的邏輯，程式碼主要的工作差不多都是 ==> 取得畫面上用戶輸入的欄位，然後呼叫EF(entity framework)做資料庫的寫入，或是反過來，從資料庫把資料讀出來，然後呈現在畫面上。 『這樣的程式碼，要怎麼寫單元測試?』學員問。 的確，這樣的程式碼，確實沒什麼重要的單元測試好寫。因為，你既不需要去測試EF(entity framework, ORM)，也不應該去測試UI是否正確的把你需要的畫面呈現出來，因為這都是框架本身已經做好的事情，若你的程式碼中沒有什麼運算邏輯，卻花大把時間去寫測試，似乎有點划不來。你真正要測試的對象，應該是你自己撰寫的『邏輯』。 一般我在上課的時候，大多用撰寫BMI計算、或是轉換匯率的類別來當作Unit Test範例，是因為它們都有明確的處理邏輯，如果程式碼大多只是為了做輸出輸入，撰寫單元測試的意義就不大。 ...

這張圖片很有意思。 我有些朋友很有勇氣，會在每年年底的時候，在FB列出自己今年度成就了哪些事情，例如 : 寫了幾篇部落格、錄了幾支影片、出了幾本書、完成什麼專案…等等等。 可能是因為，不管是MVP、LAE或是其他的Award，大概都需要這些具體的數字，才有獲選的機會。因此有許多人，平時都習慣整理和累積這些KPI。 我們在指導養成班轉職的學員寫履歷表的時候，也常常建議同學，你已經畢業一段時間了，履歷上不能只寫學經歷，要盡可能寫出你過去曾經"成就過(完成過)" 哪些事情。 具體的數字和成果，才是大部分企業想看到的內容。 但許多學員可能從來沒做過軟體專案，因此養成班才會規劃大量的實作，累積專案經驗。因為真正的實力，永遠都是從戰場上操練出來的。 前幾天在一個研討會現場，有位講師鼓勵聽眾，如果有機會，嘗試把你自己寫的程式真的放到市場上銷售(這年頭確實有很多管道)。當我們這麼做，會學習(突然間領悟)到很多事情，你可能會發現，要讓用戶心甘情願的持續掏錢，不一定如同想像般的容易，不管你程式碼寫的有多快、自覺技術能力有多強、架構設計的多美… 在面對真實市場時，所有人都必須低頭謙卑 。 之前FB有位朋友回覆，提到了 “從真實世界中得到的反饋，才會有助於提升品質”，我想，應該也是一樣的意思。 在工程的領域，一切都是很務實的。 履歷上只寫著自己有經驗、會做事、有熱誠這些口號般的內容，不如具體寫出自己曾經成就了什麼專案，為過去服務的企業帶來什麼價值與成果。 在職場上，沒有誰一定有責任要搶救誰;也沒有規定一定要給什麼人一個機會。能給未來自己機會的，永遠是過去的自己。吃飽飯，休息一下，再繼續努力，未來的我，還等著現在的我去搶救呢~ 2022/11/23

在TW MVC舉辦的 .net conf mini中，現場學員問了一個問題: 『如何讓老闆重視軟體品質，而非只是想趕時程快速上線?』 這個問題，有些時候，換了不同的身分，你可能會有不同的答案。 在職涯中前十幾年我身為工程師，我很能理解工程師常常被時程追著跑的壓迫感，常常會覺得客戶(或老闆)要系統在很短的期限內上線，迫使我們沒有時間做好該做的事情。😣 『該做的事』有很多種不同的類型，從系統或架構設計、到單元測試、添加log或telemetry、甚至只是要多一點時間重構或調整程式碼改善品質(以後的可維護性)…族繁不及備載。 這些當然都是對的，也都是該做的，但常常 在deadline面前，這些都顯得奢侈 。看著自己的軟體作品被迫於期限而逐漸成為疊床架屋的怪獸，心裡確實很難過。 但，在老闆心裡可不是這麼想的。 老闆想的是，我答應客戶X月X日要能使用，我需要在記者發布會之前，讓XX功能出現，這個deadline都是訂好的，而且還需要留一點buffer，然而到今天，我甚麼都沒看到。工程師說已經完成了80%，什麼底層架構元件都做好了，最後只要把這些組在一起就可以給客戶用了，但…每次就是那該死的10%花了最久的時間(然後delay)，結果因為各種我聽不懂的意外(程式碼合併衝突? 套件衝突?OO框架有個XX的坑? 程式碼都是對的，我們這邊都可以用，但客戶環境有問題，找不到原因…這什麼鬼?)，導致無法準時交付。 過去有這麼多奇怪的延遲的經驗，而現在我(老闆、客戶)什麼都看不到，感到非常沒安全感。 我不知道這個是不是換了位置就換了腦袋? 但開始身兼專案資方身分幾年後，我對這件事情確實有了不同的感受。 老闆在意的常常是 time to market， 有時候，如果不能在某一個時間點推出產品，前面所有的努力(投資)基本上都是一場空。特別是這個競爭激烈且變動的時代，市場瞬息萬變，這幾年我們經歷過疫情，大家也開始能夠體會，許多時候，時間(或機會)是不等人的。 這讓過去瀑布式的軟體開發，顯得更力有未逮。 當天，我在會場對大家的回答是 : 這個問題本質上其實是一個『溝通問題』。 因為，雖然時程和deadline看起來是不可變動的，但老闆要的其實是敏捷度，是面對市場的機動性(彈性、選擇性)。而工程團隊要的呢? 是足夠的時間嗎? 如果有更多的時間，就一定能夠提升品質嗎? ...

在TW MVC舉辦的 .net conf mini中，現場學員問了一個問題: 『如何讓老闆重視軟體品質，而非只是想趕時程快速上線?』 這個問題，有些時候，換了不同的身分，你可能會有不同的答案。 在職涯中前十幾年我身為工程師，我很能理解工程師常常被時程追著跑的壓迫感，常常會覺得客戶(或老闆)要系統在很短的期限內上線，迫使我們沒有時間做好該做的事情。😣 『該做的事』有很多種不同的類型，從系統或架構設計、到單元測試、添加log或telemetry、甚至只是要多一點時間重構或調整程式碼改善品質(以後的可維護性)…族繁不及備載。 這些當然都是對的，也都是該做的，但常常 在deadline面前，這些都顯得奢侈 。看著自己的軟體作品被迫於期限而逐漸成為疊床架屋的怪獸，心裡確實很難過。 但，在老闆心裡可不是這麼想的。 老闆想的是，我答應客戶X月X日要能使用，我需要在記者發布會之前，讓XX功能出現，這個deadline都是訂好的，而且還需要留一點buffer，然而到今天，我甚麼都沒看到。工程師說已經完成了80%，什麼底層架構元件都做好了，最後只要把這些組在一起就可以給客戶用了，但…每次就是那該死的10%花了最久的時間(然後delay)，結果因為各種我聽不懂的意外(程式碼合併衝突? 套件衝突?OO框架有個XX的坑? 程式碼都是對的，我們這邊都可以用，但客戶環境有問題，找不到原因…這什麼鬼?)，導致無法準時交付。 過去有這麼多奇怪的延遲的經驗，而現在我(老闆、客戶)什麼都看不到，感到非常沒安全感。 我不知道這個是不是換了位置就換了腦袋? 但開始身兼專案資方身分幾年後，我對這件事情確實有了不同的感受。 老闆在意的常常是 time to market， 有時候，如果不能在某一個時間點推出產品，前面所有的努力(投資)基本上都是一場空。特別是這個競爭激烈且變動的時代，市場瞬息萬變，這幾年我們經歷過疫情，大家也開始能夠體會，許多時候，時間(或機會)是不等人的。 這讓過去瀑布式的軟體開發，顯得更力有未逮。 當天，我在會場對大家的回答是 : 這個問題本質上其實是一個『溝通問題』。 因為，雖然時程和deadline看起來是不可變動的，但老闆要的其實是敏捷度，是面對市場的機動性(彈性、選擇性)。而工程團隊要的呢? 是足夠的時間嗎? 如果有更多的時間，就一定能夠提升品質嗎? ...

#多工問題怎麼解 #老闆不願加人手怎麼辦 看到網路上有人詢問到 “部門人力不夠，老闆不願意加人，導致同仁水深火熱” 的問題。感覺提問者問的聲淚俱下，但其實這問題並非特例，幾乎每家公司都有這個狀況。 我們在企業導入敏捷時，常碰有團隊面臨多工(一人接多個專案)，或是人力不足的問題。 同仁提出後，問我，敏捷(或Scrum)專案該怎麼面對這個問題? 我其實很想跟同仁說 : 這問題跟敏捷一點關係都沒有。敏捷也不是設計來解決這些問題的。 然而確實，當你採用敏捷或Scrum，這些原本被公司 “掩蓋的很好” 的人力(人事)問題，就會被你凸顯出來。(這也是一種透明度的展現?) 有人覺得，那為何以前在瀑布開發的時候，人員可以參與多個專案，可以多工，看起來沒什麼問題，但為何現在敏捷就不行??? 再強調一次，不是敏捷不行，也不是瀑布式開發可以，而是瀑布式開發把透明度降低了，讓問題被掩蓋(隱藏)了起來，直到驗收結案時(前)一次償還這個被掩蓋問題所要付的代價(專案延遲、品質降低、團隊士氣低落…etc.)。而這時你根本分不出問題的 root cause 是什麼，是人力不足、是太多技術債、是專業能力不足、是插單…? 其實是專案中這些所有的問題所帶來的後果，一次一起呈現在你面前。 而敏捷則會在專案一開始，就讓你知道，當你把人同時投入多個專案多工時，會付出什麼代價? 但，這個問題該如何解決? 你得換位思考，把自己當老闆的角色，去思考這個問題。 你可能會發現，人夠不夠最終往往不是工程需求或計算工時的問題(所以任憑你做出再怎麼精緻的人力使用率報表，上面充斥著紅色的加班時數，也不見得有用)。而是資源(錢)怎麼分配，和資源(現金)夠不夠的問題。 也就是說，我們去證明人力不足，是工程思維；但設法證明，在我的部門若有更多的人，將會為公司帶來更多的價值(錢)，或是人太少會讓公司虧很多錢，這是商業價值。 而主管大多在意 商業價值 > 工程需求。 "老闆好像總覺得我們部門有能力空間去支援OOO" <=== 這往往凸顯出的是，老闆覺得這個部門再多花點錢請人"不划算"，暫時用加班可以解決問題就好。 當然同時也意味著，老闆可能還看不到這個部門人力使用的透明度，你確實應該使用一些工具(像是看板、CFD、燃盡圖)把工時的透明度呈現出來。但最終老...

前陣子，一群朋友吃飯，在座一位友人問到，大家假日都在幹嘛? 我說: 『在寫 Code 啊。』 她不解:『什麼意思? 你都一直在加班寫程式?』 我說: 『不是，是我自己的 side project，就是興趣啦。』 對方有點不可思議地看著我：『你平常上班沒寫夠? 假日還寫興趣的?』 我說：『這不同，平常寫程式是工作，而假日寫 side project 是舒壓。』 他不信。 我說，真的，我最近在寫一個可以自動產生網頁報表的程式，這樣我就可以自動把學員的成績單，輸出成 HackMD 的網頁格式，不賣錢的，純粹就是喜好而已。而且為了寫這個功能，我還順手幫 HackMD 寫了套C# SDK，然後又寫了單元測試… 一票人愈聽愈目瞪口呆… 哈哈哈哈，你們真的不懂工程師的世界。真的啦，不蓋你們，HackMD.API C# SDK nuget package 套件開源專案網址如下: https://github.com/isdaviddong/HackMD.API 真的，不唬爛。

這張圖是一個老梗了。 記得前陣子跟幾個朋友聊天，席間，一夥人為了一個話題爭論不休。小時候，我的管理學老師曾說，有兩類議題，你不用試圖跟朋友討論清楚，因為不管怎麼說，都說不清的。一個是宗教，一個是政治。 年輕時覺得真理愈辯愈明，後來才知道，其實沒這回事。我們所相信的，其實都會左右我們觀察事情的角度，而看事情的角度不同，看到的真相就會不同。 網路時代，社群媒體更強化了同溫層的力道(對這原理有興趣的人可以看Netflix有一部影片Social Dilemma)。 試圖跟不同看法的人溝通，你會很訝異的發現，你怎麼可能會這樣想? 如果你常覺得，TMD的這麼簡單的道理為什麼總有人想不通? 那你更該看看這影片。 柯維在『第三選擇』中說：「溝通中的傾聽是你讓對方充分表達並且了解對方的感受，到足以為對方辯護的程度…」 身為工程師，我很喜歡明辨是非對錯，但總要提醒自己，身為負責溝通的顧問或教育訓練的引導者，我得嘗試設身處地，從不同的角度來重新觀察我已經相信的事實，或許，會有其他的收穫也說不定。

啥是Replace tokens? 為何要在Pipeline中使用Replace tokens? Replace tokens是一個DevOps的Pipeline設計中，我相當常被問到的需求。客戶常常會問我：『 如何在Pipeline中，把檔案(程式碼)裡面的某些字換掉。 』 我第一次被這樣問的時候，覺得有點怪，客戶為何要這樣做? 後來發現，原來是因為，同仁把敏感的資料(例如帳號密碼、token、連線字串…etc.)寫在設定檔(其實也不好)或程式碼(萬萬不可)裏面，然後就這樣commit到repo中。 全世界都嘛知道，不應該在repo中存放正式機的連線字串帳密或正式token，所以一般來說，開發人員commit的程式碼中，是不會放正式帳密的。然而，我們的Pipeline採全自動化佈署，需要一口氣自動建置、佈署到正式機，那能不能在Pipeline中，安全地把這些位於程式碼或設定檔中的機密資料換掉，換成正式機的帳密呢? 當然可以。 使用的就是Replace tokens。 舉例來說，底下這個設定檔內容，原本JSON裡面放的是帳號密碼，或是token之類的機密資訊，你可以把它改成這樣： 以 #{…}# 框起來，裡面放 變數 的名稱。把這樣的設定檔commit/push到正式repo的主要分支。 接著，在Pipeline的build之前，使用Replace tokens這個task: 它可以將特定檔案中，具有#{…}# 框起來的文字，都換成Pipeline中的環境變數。 所以，別忘了你還要設定相對應名稱的環境變數，例如，我們為Pipeline設定底下這樣的變數： 如此一來，上面程式碼中的 #{token}# 就會被換掉： { "token": "#{token}#", //會被換掉 "tempNote": "#{tempNote}#" //會被換掉 } 在build之前，它就會被換成Pipeline中Variables中的值，然後才進行build的動作。 如此一來，就可以在設計Pipeline的時候，把正式機的帳密等機密資料，塞入build好的artifact中，填入正式環境之中。 這樣可以達到開發人員無需經手正式環境帳密的效果。 總的來說，R...

10/24 Line Messaging API有了一個更新: https://developers.line.biz/en/news/2022/?month=10&day=24&article=validate-message-objects-api 主要內容是，提供了一組新的endpoint，來驗證你想發送的訊息，看看你組出的JSON訊息格式是否正確。 其實這對使用我們的 LineBotSDK的開發人員來說，不算是常會用到的功能，因為如果你用我們的 LineBotSDK，大可透過 message object 來建立要發送的訊息物件，不需要自己組JSON。 但，萬一你有自己組JSON的需求，或是需要透過 PushMessageWithJSON 或 ReplyMessageWithJSON 這類 method來送出自己組出的訊息，那這個功能就非常好用。你先呼叫它，將可以避免讓你送出格式錯誤的訊息，畢竟，LINE Bot的 Message JSON格式愈來愈複雜了。 這組API，我們依舊是搶先實作在我們的LineBotSDK套件上了。 使用的方式很簡單，在更新SDK時，我寫了底下的單元測試程式碼，就權充是使用範例給大家參考:

每次忙到天昏地暗時都想起這個故事 一位投資銀行家在墨西哥某海灣度假，看見一個年輕的漁夫在碼頭釣魚，手到擒來，不到半刻鐘便釣了十多條肥大的活魚，塞滿整個水桶。 漁夫收桿離開，投資銀行家語帶不解問道：「為什麼不多呆一會兒，可以釣更多的魚？」漁夫回答：『賣掉這些魚已經夠換來好幾天的家用，等需要時再釣吧。』 投資銀行家好奇，問漁夫除了釣魚，是怎麼過日子。 漁夫答道：「我釣魚的時間不多，沒錢用時才到碼頭或出海捕魚。白天我和我的孩子們玩、睡午覺，下午和太太漫步、溫馨溫馨，晚上和朋友們喝酒吃飯、唱歌跳舞玩吉他，一直到深夜。我們平時睡覺很晚的。」 投資銀行家於是教訓他：「你太不思進取了。你應該花多點時間去釣魚，多釣多賣多賺，然後買一隻大漁船，釣更多的魚。」 漁夫不明所以：「之後呢？」 投資銀行家續道：「之後賺了錢便換更大、更多的船，把船租出去，再把你村內的漁民組織起來，變成為你賺錢的船隊。到那個時候，你就不需要自己出海，你可以自己開一個魚食加工廠，做自己牌子的魚肉罐頭，自己生產、推銷。」 漁夫更加不解瞪大雙眼問：「那我豈不是很忙碌？我豈不是沒有時間陪伴家人，不能常常和朋友吃喝玩樂？」 投資銀行家安慰他：「我是投資銀行家，我可以幫你，把這個業務做大做強，然後安排公司在紐約交易所上市，到時你便是千萬富翁了。」 漁夫聽罷有點興奮：「這要用多長時間？」 投資銀行家回應：「沒意外的話，只需要10到20年時間。」 漁夫心裏冷了半截，續問：「公司上市後又如何？」 今次是投資銀行家有點興奮了，他回道：「公司上市後你可以退休，搬到一個美麗的小漁村去生活，白天和你的孩子們玩，中午睡個午覺，下午和你的太太一起溫馨溫馨，晚上你的朋友們喝酒唱歌跳舞玩吉他，一直玩到深夜！逍遙快活，多麼寫意。」 漁夫淡然回應：「哦，我現在不就是這樣生活嗎？我為什麼要等10到20年呢？」

上課的時候，中午休息回來，看到大家精神狀況不是很好，我就講了一個最近在書上看到的故事… 話說 有一個古代的王　就當作是法老好了 養了非常多做工的奴隸　來為法老工作蓋金字塔 然後其中　有個奴隸想要叛變　但卻被法老王知道了 法老打算殺了他 後來仔細一想 殺了一個 後面還有千千萬萬個 殺不完呀 得想一個一勞永逸的辦法 於是就跟所有的奴隸說 你們　從今天開始　全部自由了 不用再為我蓋金字塔了 你們現在隨時可以走 但 留下來的人　我每天給你一個金幣 你可以用金幣來買吃的　喝的　醫療　住更好的房子 結果　所有的奴隸都留了下來 甚至比以前更賣力工作了 因為奴隸們想從法老王那賺取更多的金幣 從此　法老王安枕無憂 繼續有人幫他蓋金字塔　大家也心甘情願 不會想要叛變 甚至　有些奴隸還時常擔心 萬一哪天法老不雇用自己了　沒有金字塔可以蓋　沒有磚可以搬 不知道該怎麼辦? 所以很珍惜這份工作　雖然天天抱怨法老虐待殘酷又沒人性 但心裡還是會擔心自己沒有機會可以繼續當奴隸 同時 為了成為稱職且Qualify的奴隸 開始進修 讓自己在市場上更有競爭力 以便從法老那賺取更多更多的金幣 冀望著或許有朝一日 可以擺脫法老的控制 得到自由 故事講完了，同學也差不多醒了。 課後，有位同學問：『老師，奴隸們不是早就自由了嗎? 為何還是天天抱怨卻不直接離開法老的掌握呢?』 『恩…這…也難說。人生嘛…本來就是一種選擇，也許奴隸覺得，離開了，也只不過是換另一個地方繼續當奴隸而已。又或者，其實奴隸實際上過得比法老王還快樂也說不定呀 😁，誰知道呢?』我笑著回答。

過去這幾年，很榮幸有機會常常能跟企業分享敏捷觀念，甚至參與某些企業的敏捷導入。以前，一有機會主導，我立刻如火如荼，對組織進行一連串的推動。最近這一兩年，反倒開始會先觀察一下，針對企業內的同仁，做些正式或非正式的調查或訪問，然後再選擇比較適合該企業的導入策略。 因為幾年下來，我發現，所謂的數位轉型，大多都有底下四個階段，分別是『知識、信仰、習慣、文化』。 組織規模不很大的公司，在進行所謂的數位轉型，往往沒有很複雜，不管是bottom up(由下而上)，或是top down(由上而下)，總能說轉就轉。若來個強勢一點的老闆，一聲令下，立刻水到渠成。如果是自由一點的新創公司，若能碰到有概念的同仁，從組織底層開始推廣，也常常一帆風順。幾年下來立竿見影，轉型成功，成效卓著。 但是，在規模比較大、或是年資比較老的公司，就沒那麼幸運了。你會發現，航空母艦的轉向常常需要不少時間，不同的階段還得有不同的節奏。你很容易看到，大企業老闆的一聲令下，但員工上有政策、下有對策，開始跟老闆比氣長，看誰撐得久。反正公司夠大，一時半刻也還死不掉，老闆從市場上感受到的轉型迫切度，在員工眼裡看起來很不明顯。反過來也是，感覺敏銳的一線同仁，嗅到市場的趨勢，開始想做些改善，從底層開始推動，但企業的中階或高層主管，卻還沉浸在看似漂亮的業務數字中，絲毫無法察覺風浪已經近在眼前。 這導致這些年數位轉型談的公司多、做的也不少，但能有具體成效的企業卻寥寥無幾。 針對大型的組織，數位轉型有四個重要的階段，就是前面提到的『知識、信仰、習慣、文化』。 首先，必須讓企業同仁對於『改變』有一致的認識，這是『知識的建構』，也是對焦。讓同仁知道為何要改? 該如何調整? 是轉型的第一步。讓高階主管看到風浪、嗅到趨勢、針對轉型改革的必要有足夠的認知和心理準備。讓同仁們明白為何需要改變? 變革將會帶來哪些好處與價值? 如此才能夠從觀念與心態上建構轉型所需的動力。 從知識的建構到『相信』，往往會是第一個門檻。很多企業，就算有了轉型所需的知識，卻無法相信，如果不相信，怎麼從日常工作開始做起? 敏捷轉型是很好的例子，許多企業看過成功案例、也上過教育訓練，知道背後的原理和價值觀，甚至還考過認證、知道敏捷框架和作法。然而一旦開始實施，碰到跟現行制度或過去的作法稍有衝突的地方，同仁立刻自動回到過去的樣子，這樣如何轉型? 敏捷歡迎需...

近代軟體開發，不管是使用哪一種語言，幾乎都一定會使用到套件(Package)，套件的使用都有著非常重大的意義。套件不只是讓開發變的更方便，套件的版本管理，能夠讓專案之間的相依性被有效管控，避免dependency hell的發生。 所以各大開發語言，不管是node.js、python、Java…都有自己的套件庫，微軟的.net當然也是，nuget就是.net開發人員的標準套件庫。如今，使用套件庫上的組件來開發企業內的專案，已經是理所當然的習慣了。 套件庫的使用風險 然而，使用套件並非100%毫無風險，由於開源軟體的觀念盛行，這個時代任何人都可以將自己開發的套件貢獻上nuget讓大家使用，雖然開發社群與nuget站台會針對有潛在或惡意風險的套件提出警訊，但由於這些資訊並非即時提供，且有可能因為開發人員的疏忽而沒有被發現，導致你的專案使用到有品質不佳，或是有安全疑慮的套件。 除此之外，套件還有許可授權的問題，並非每一個套件使用上都是毫無代價的，雖然nuget會要求套件開發人員具體標明套件的使用授權許可，但倘若開發人員不察，使用到一些並非可以免費使用的套件，或是使用到了標註為GPL的套件，那你依賴該套件開發的專案，也會被要求開源，這對於公司來說，可能會造成一場災難… 在CI Pipeline中掃描套件 因此，為了避免軟體開發人員一時疏忽，CI Pipeline有必要針對軟體套件的使用作一些掃描和檢查。而WhiteSourceBolt就是這樣的一套免費工具。 你可以在Azure DevOps Pipeline中，加入WhiteSourceBolt這個task，就可以輕易的掃描整個專案中使用的套件： 呈現出的報表如下： 你會發現，報表中清楚的告訴我們，哪些套件是高風險的，並且原因為何(上圖A)。如果你的專案有紅色高風險套件，強烈建議你要立即著手處裡(升級版本或尋找替代套件)。 要在Azure DevOps中啟用WhiteSourceBolt非常簡單，只需要為你的組織安裝Azure DevOps Marketplace中的外掛： 下載位置位於： https://marketplace.visualstudio.com/items?itemName=whitesource.ws-bolt 安裝好之後，你重新進入Azure DevOps，可以看到在...

當網路上出現一則訊息，誰有權力判斷這則訊息的真假? 1.政府 2.平台業者 3.KOL(Key Opinion Leader, 意見領袖) 4.我自己 上面這個問題，不知道你的答案會選擇甚麼? 這兩天沸沸揚揚的中介法，造成了很多網路上的輿論。主因是平台業者被要求有責任管理(刪除或標註)不實言論，否則要罰款。 但這中間出現了兩個問題 1. 誰決定不實? 2. 如何做到有效即時的內容管理? 身為技術人員，我想從技術的角度談這件事情。首先，有沒有可能即時發現用戶將有問題的內容張貼到網站上? 技術上確實有可能。 現在微軟Azure, AWS, Google都有許多雲端AI服務，可以辨識圖片、影音、文字，近乎即時的判斷內容是否涉及情色、猥褻、或是具有冒犯意味甚至鼓吹自裁。這服務微軟叫做 Azure Content Moderator，內容仲裁 。總的來說，在當今的AI技術上，我們早就可以針對圖片、影像、或文字進行客觀的內容判斷，這些技術已經逐漸成熟，經驗上準確度大約八九成沒問題。 所以各大網站(像是FB)可能早已把這些技術用在內容分析上了(如果你的網站也需要，但不知道該怎麼做，可以與我聯繫)。但問題是，這些AI服務，可以判斷內容，無法知道對錯。 因為內容的正確與否，涉及價值觀的判斷。 在這個世界上，並不是所有事情都是非黑即白，一翻兩瞪眼的不是對就是錯，更何況，真假對錯很可能因為時間而有所改變。一開始你可能以為是對的(內容為真)，但經過時間，很可能發現是錯的(內容為假)，反之亦然。舉個更簡單的例子，不同世代對於同一件事情的看法，也往往南轅北轍。 如果第一時間不分青紅皂白的，就直接屏蔽刪除或標註某種論點，很可能事情將永遠沒有水落石出的一天。當然，如果你不在意真相(只在意管理)，也就無所謂。 所以，從技術的角度來說，現在的科技就算不用靠誰立法、無須哪個單位協助，單單使用AI技術，就足以判斷內容是否違背善良風俗，這個也早就在做了。然而問題是，會不會我覺得的裸露、是你覺得的藝術呢? 這條界線該如何決定? 誰決定? 因為一旦涉及主觀價值判斷，所有的一切就變的不再簡單。 因此，AI就算能幫你辨識內容，卻無法幫你判斷真偽。 是非、對錯、真假，都很難由誰單方面說了算。 因此，我們再看一次這個問題。 當網路上出現一則訊息，誰有權力和責任判斷這則訊息的真假? 1...

每當寫程式或文稿累了的時候，我會到河堤騎車。 最近這幾年，台北鄰靠基隆河的兩岸，都有了挺不錯的自行車道，幾乎沒甚麼難騎的上下坡，很適合以悠哉閒逛的心情慢慢騎吹吹風… 一天，忙了一整個下午，趁夜幕微微垂下，趕在日落前，我租了YoiuBike在河堤邊緩緩騎乘。岸邊隨風飄來青草的香味，讓人很是愉快。 正當我覺得身心放鬆，通體舒暢。卻不知耳邊何時傳來了一陣犀利(你要說淒厲也行)的對談聲，有點像是你去傳統菜市場會聽到的那種婆婆媽媽在攤販前理直氣壯的討價還價聲，聲音從遠而近，由小而大，漸漸飄了過來。 仔細一聽，位於六點鐘方位，後方。 一群騎著貌似淑女自行車的大媽，集團似的緩緩逼近。 我側眼一瞥，數了一數，五位。喔不，是六位，其中一位有些落單，奮力的在後面追趕。 前面五位大媽，領頭的三人，並排而行，佔據了來往雙線車道，伴隨著中氣十足的對談，讓人不注意到她們都很難。雖然距離有些遠，但言談中我依稀聽到關於某位大媽的兒子的太太的最近一些態度問題…呃…不關我事，非禮勿聽，我騎我的車。 加速前進。 可能是我租賃的YouBike齒輪比不佳，也可能是每天騎車的大媽中氣十足，我雖然加速超前了一定的距離，但每當我放鬆開始欣賞河邊的景色和迎風吹來的芬芳草香，一不注意，這群大媽集團立刻從後方逼近。一連數次，我在聽到了大媽們對談的特殊嗓音時，才意識到我快要被集團軍輾斃，只能瞬間加速遠離…但沒多久，我優閒的騎車氛圍就又會被身後堅持出現的音量所打破。 大媽們像是擁有裝上了勁量永備電池一樣的持久續航力，以堅毅且穩定(甚至我覺得似乎有愈來愈快)的速度屢屢逼近。 每當大媽集團軍從後方接近，我airpods裡的音樂聲量，總是不爭氣的敗陣下來… 當這條沿岸車道已經騎了約莫三分之二時…我，終於做出了決定。 在車道轉角處的某一個空曠處，我停了下來。站穩步伐，拍拍身上的風沙灰塵，好整以暇的，帶著敬佩與釋放的心情，目送大媽集團軍隊從我眼前騎過去… 喝了口從家中帶出來的水壺裡的氣泡水，整理了一下裝束，跨上自行車，我開始緩緩而行。 我何苦讓自己被身後追趕的雜音持續干擾著呢? 人生旅程上總是會碰到不同的人群，路程上人來人往、來來去去，我又不是要和誰比賽，幹嘛跟自己過不去，身後的雜音，不如就讓它從眼前過去。 等雜音遠離，我戴上耳機，依舊開始自在的騎自己的路，欣賞屬於自己的風景，以我自己習慣的速度，...

使用Azure DevOps Services，部署到雲端相對容易，部署到地端環境，得考慮的事情就多了。主要的原因是，Azure DevOps Services在雲端，無法(也不應該)直接跳過防火牆存取地端環境上的伺服器。 另外，如果不管是雲端或地端伺服器，若是HA(高可用性)架構，做了負載平衡(Load Balance)或是Failover，部署站台時，需要把同樣的artfact一次部署到多台伺服器，在pipeline的設計上也有一定的難度。 上面提到的這些事情，解決方案就是『Deployment Group』。 功能說明 Deployment Group可以讓你把特定artifact一次部署到多台伺服器，同時，也可以突破防火牆的限制，從雲端部署到地端。其中的關鍵就在於，你必須在伺服器端安裝一個代理程式。 我們來看一下底下這個準備好的情境，我們準備了兩台Windows Server 2019 VM，名稱分別是testdpvm1與testdpvm2。並且，在這兩台伺服器上開啟了IIS，也運行了基本的網頁如下: 同時，我們也建立了一個Azure DevOps Team Project，其中的repo很簡單，只有一個html檔案： 並且，我們為這個repo的部署建立了一個CI Pipeline: 這個CI Pipeline的功能也超單純，只是打包這個 .html頁面成為 .zip檔案，然後放入(publish)到drop資料夾，準備給CD Pipeline使用。 建立Deployment Group 接著重點來了，我們待會要將drop資料夾中的artifact透過CD Pipeline如同『穿越防火牆』一般地『同時』發佈到那兩台剛才建好的VM上，為此，我們來建立Deployment Group。請在Pipeline功能中，找到Deployment Group，並且建立新的Deployment Group： 接著，為Deployment Group命名，一般採用的是你的環境名稱，例如Dev、QA、Production…等。 然後，請複製出現的PowerShell Script (別忘了要勾選Use a personal access token in the script for authentication)： 運行代理程式 接著...

昨天，幫客戶介紹 .net core 的單元測試(Unit Test)開發。 其實，單元測試(Unit Test)是個非常簡單的概念，近代開發工具本身也都進化的超級方便，輕輕鬆鬆的就可以建立出單元測試專案的架構。 單元測試(Unit Test)看起來一點都不難。 這話只對了一半，單元測試難的地方並非撰寫單元測試程式碼本身(甚至，單元測試程式碼本來就應該盡可能的簡單，簡單到不該出現邏輯)，難的地方是為了實施單元測試前的程式碼重構(如何增加程式碼的可測試性)，以及如何在企業內真的推廣和實作。(因為上至主管下至開發人員，總有成千上百個看來非常合理的理由，解釋為何自己現階段無法導入單元測試) 不過，這些困難的問題，我們留到 課程 裡面再討論。 我們今天先來看一個簡單的，如何在 .net core 產生測試程式碼覆蓋率的報表。 其實，只有三個動作，第一個，請安裝 .net tool: dotnet tool install -g dotnet-reportgenerator-globaltool 然後 透過 dotnet CLI 跑一次單元測試進行資料蒐集，記得請在 .sln 或 .csproj 所在的目錄下執行: #收集資訊 dotnet test --collect:"XPlat Code Coverage" 請注意上面的 --collect:“XPlat Code Coverage” 參數，是為了蒐集單元測試涵蓋率資訊，執行完畢之後，會出現底下畫面，請特別注意XML檔案所在位置: 因為我們下一個指令需要該位置資訊。 最後，請執行: reportgenerator -reports:"路徑\coverage.cobertura.xml" -targetdir:"report" -reporttypes:Html 嘩啦，單元測試涵蓋率報表出來了(位於report資料夾中，還是HTML格式的)，就這樣: 簡單吧~

今天上課的時候，跟同學聊到，最近很流行的一個詞彙 『滾動式修正』(或 滾動式調整)。 不知道你自己對這個詞的定義是什麼? 所謂的『滾動式調整』是不是走一步算一步? 是不是朝令夕改的美化版? 是不是先做再說，後面再看著辦? 儘管很多人不明所以，但『滾動式調整』這個詞彙這幾年仍被許多團隊理所當然地使用著。為何過去從沒聽過，這幾年卻如此盛行? 我自己覺得，和敏捷(Agile)似乎脫不了關係。 敏捷(Agile)存在的意義，是因為我們認知到並承認， 現今外在環境的變化實在太快了 ，快到我們再也沒法像過去一下，先妥善地做完計畫，然後再動手實行。如果堅持如此，將會錯失先機。 此外，更重要的是，倘若沒有先著手實施，試著得到外界真實的反饋，只在辦公室裡籌算，即便覺得計畫得再周密，一但拿到真實世界裡，很可能就會立刻破功。 這兩者都是同樣的前提 --> 這個世界變化得愈來愈快。 這也是敏捷之所以日趨主流的原因。 而敏捷的被認可，或多或少讓『滾動式修正』變得理所當然。然而，真的每一個組織，每一個單位，每一個計劃，都適合滾動式修正嗎? 今天上課談的是DevOps。 我問學員：『如今需求變化快速已不可避免。假設，持續交付 (所謂的持續交付，一般是指一天數次這樣的頻繁上版，最少也是一周數次，不會更低)是必須的，那什麼是持續交付的基礎?』『一家公司、一個團隊，一個專案，能夠毫無準備的就實施頻繁交付(CD-Continuous Delivery)嗎?』 答案是 : 『不能』。 因為， 沒有良好準備的頻繁交付，將會帶來災難 。 頻繁交付的前題是持續整合(CI-Continuous Integration)，持續(密集)到什麼程度? 最好應該是一天數次，至少是一周數次，將程式碼頻繁的簽入並且合併至主線(main)。同時在合併前進行程式碼品質掃描、安全性掃描、單元測試。如果這些都沒做到，那請容我這麼說，目前這個團隊(專案)恐怕還不到可以實施頻繁交付(CD-Continuous Delivery)的程度。 所以，持續交付(或謂 頻繁交付，不過這兩者其實有些許不同)的前提，是良好的基礎建設(這邊指的基礎建設是指 CI - Continuous Integration)。 同樣的，若企業想要執行『滾動式修正』，你的團隊和行政體系必須要有足夠良好的體質，這體質指的是 : 快速...