2020年5月1日 星期五

關於AMA(Ask Me Anything)

https://ithelp.ithome.com.tw/upload/images/20200430/20126141tmKgD8beFm.jpg

5/5(週二) 中午 12 點到 1 點,有一個很特別的活動,名稱是AMA(Ask Me Anything)。在這個場合中,我為大家招集了我的幾位好友,你可以在這一段時間內,盡情的留言發問。

雖然此次的主題是與口罩查詢等疫情應用App相關(沒錯,我上面的這幾位好友,都是開發人員,各自也都開發了相當受歡迎的口罩查詢應用App),但如果您有其他相關問題,我相信這些大師們也都非常樂於回答。

在談AMA(Ask Me Anything)之前,我想先介紹我的朋友們…

我的朋友們

我認識忠成(Jeffray Huang)的時間已經不可考了,他最讓我覺得神奇的是,不管哪一個領域的開發技術,只要他有興趣的話,總是能像生來就有天分般的,輕易地專研出他人難以望其項背的成果。

在台灣說多不多,說少卻也不少的開發人員當中,唯一能讓我自嘆弗如、直接放棄比拚的,也就只有Jeffray一人。他總是像是個身懷絕技的獨行俠客,興致一來,時不時地略施身手仗義助人。他拯救我的那段故事,就寫在這一篇blog中…

第一次認識佳新,就是和他一起出國玩(別誤會,同行還有許多男人。呃…怎麼好像有點越描越黑的感覺,那我還是別提我們去新宿的那晚…)。回台之後,才知道佳新可是譯作等身、獲獎無數的新創企業負責人,近年來在LINE Bot的應用開發上更是成果非凡,有鑑於此,我覺得AMA我必須找他來共襄盛舉。

Ian位於國境之南,雖然我們都是微軟MVP,但因為距離,見面的次數應該是手指數的出來,平常也只能在研討會上才有互動。但此次COVID-19疫情爆發,Ian卻讓我驚呆了,他開發的那隻LINE Bot,甫上架即秒殺其他應用,而今的好友數量更是超越台北市政府官方LINE Bot(破百萬啦),直接輾壓所有我們這些玩了LINE Bot好幾年的開發者們。不僅如此,我知道他的應用中還加上了MS的AI服務(像是LUIS),因此口罩開發AMA我怎能放過他?

James不僅和我一起協助過Build School作為講師和助教,也在.net相關社群中時常見面,而他也是台灣少見的Xamarin 跨平台開發 App開發專家。在這次疫情爆發時,他採用Xamarin同時開發出iOS和Android的口罩查詢應用,不管是品質和速度,都是一時之選,我自己不常開發手機App,但AMA如果只有LINE Bot沒有App,我覺得會是遺憾,因此我強烈的拜託他務必抽空參加…

關於AMA(Ask Me Anything)

在上面這群人中(我差點忘了算自己),有至少三位以上的書籍作(譯)者、超過四位以上的MVP(Microsoft Most Valuable Professional)、更不用說LAE(LINE API Expert)了,開發領域橫跨App/Web/Mobile/LINE/Cloud/AI/front-end/back-end…我相信不管你想問什麼問題,在這邊都能夠找到你需要的答案。

更不用說,上面有好幾位還是現職的教育訓練講師和顧問,即便你的問題超脫技術、進入生涯規劃、職場、甚至人生或其他形而上的領域,這幾位專家依舊是提供你最佳解答的不二人選。

感謝IT Home的Tina妹妹安排了這次線上活動,我只負責找人,和提供這個千載難逢的機會給大家,如果5/5(二)中午有空 12:00-13:00,帶著你的問題上線, 這個組合只有這一次,請千萬別錯過了。

活動詳情: https://ithelp.ithome.com.tw/articles/10231167

週二 5/5 中午 12 點到 1 點,只要在下方留言板用文字留言,就會有人跳出來解答疑惑唷!機會難得,請預留時間!

2020年3月26日 星期四

用C#開發LINE Bot(37) - 可變換官方帳號頭像暱稱的 Icon Switch機制

官方帳號(或LINE Bot)大多是代表著某一個機構團體或公司,官方帳號後面可能會有很多的操作人員,這些操作人員可能是不同的身分,但都使用官方帳號這個唯一的管道作為出口與加入此官方帳號為好友的用戶互動。

不過,這些都是該官方帳號在還沒有串接後端的WebHook之前。

一旦官方帳後透過後端的WebHook作為訊息回應的方式,那真正回應訊息的當然就是後端的程式碼了。

但你會不會覺得,官方帳號每次都是同一個頭像或暱稱,來對用戶回應,似乎有點枯燥乏味? 有沒有可能動態的切換官方帳號(LINE Bot)的頭像與暱稱呢? 可以的,LINE在本月開放了這個新的機制,可以讓您透過API來實現本功能:

上圖中其實是同一個官方帳號,但當用戶與之對話時,該官方帳號可以依照需要的情境,自動切換成不同的頭像與顯示暱稱。

怎麼實現的?

透過C#程式碼超級簡單,你只需要在發訊息的時候,額外設定sender.name與sender.iconUrl這兩個屬性即可:

透過上面這樣的指令,原本的程式碼幾乎完全不需要修改(只需要額外加入上面兩行指令),就可以在推送這則訊息的時候,改變官方帳號(LINE Bot)的頭像與暱稱。

請注意,這個頭像與暱稱是跟著訊息的,也就是說,如果你下一則訊息,沒有加上這兩行指令,則推送出的該訊息,就會顯示預設的頭像。

就這樣,是不是讓你的LINE Bot生動很多?
(btw, 請升級到最新版LineBotSdk(2.0.12+)才有支援)

這功能幹啥用?

如果你做的是一般機關行號型的LINE Bot,可能不容易想像這個功能的用途,但如果你做的是遊戲類的LINE Bot、或是你在LINE Bot中想要做些行銷活動,這個功能就非常好用。

例如,你可以在遊戲或行銷活動與用戶對談的過程中,把LINE Bot的頭像換成卡通人物,但當用戶離開遊戲或行銷折扣活動,變成詢問問題時,你可以再把頭像切換成客服人員,這樣即便只用一個官方帳號,用戶也可以更清楚的知道目前正在對談的情境和事件是什麼。

又或者,企業在舉行端午節的特惠活動時,你可以在發送訊息時,把頭像切換成屈原(或粽子)…這樣頗為生動的小動作,會讓你的LINE Bot生動不少。

相關的程式碼可以參考我放在 Github上的範例:

https://github.com/isdaviddong/Example-LineIconSwitch

enjoy it.

-----------

最新實體課程:http://www.studyhost.tw/NewCourses/LineBot
線上課程:https://www.udemy.com/line-bot/
電子書:https://www.pubu.com.tw/ebook/103305
實體書:https://www.tenlong.com.tw/products/9789865022662
LineBotSDK:https://www.nuget.org/packages/LineBotSDK
如果需要即時取得更多相關訊息,可按這裡加入FB專頁。若這篇文章對您有所幫助,請幫我們分享出去,謝謝您的支持。

2020年3月10日 星期二

用C#開發LINE Bot(36) - 關於LINE Notify的發送限制

當許多用戶開始使用LINE Notify之後,就會發現它真是一個方便好用的機制。

他的推播速度不亞於使用Messaging API的Push Command,甚至我覺得在群發上有更高的彈性與控制自由度。我們只需要得到用戶的Token,就可以輕易的透過HTTP POST發訊息給用戶,這使我不僅可以透過程式碼操作,也可以在command line或搭配script 工具操作,使用起來非常方便。

但是,總不可能是無止盡的發送吧,這個機制怎麼計算發送量與限制的呢?

目前看到LINE官方文件上的說明是…

There is a limit to the number of times an API can be called on each service.

The default number is set to 1000.

The limit is per access token.

The API Rate Limit status, can be checked on the response header of the API.

其實有點抽象,讓人有些分不清楚。

不過我們從上面說明也可以知道,呼叫API的次數限制是1000次,而且是Per Token的。也就是說,限制不在服務本身,而是在被呼叫的Token。看起來限制是針對我們取得的用戶Token,而非針對我們(開發人員)所申請的某一個LINE Notify Service。

另外,文件也讓我們知道,相關的資訊可以透過response header取得,針對Header的回覆訊息意義,文件上有說明如下:

我們可以嘗試對某一個token送出訊息,並觀察它的response header:

你會發現,當某個token被呼叫(上例是傳送訊息)時,response的header會透過X-RateLimit-Remaining回傳剩餘的可呼叫次數(上圖A)。不管是發送訊息,還是取得狀態(get status api),只要拿某一個token當做參數,該數字就會遞減。也就是你能針對這個token呼叫api的次數就會減少。

所以我們可以得到一個初步的結論,LINE Notify的限制,不是針對某一個服務、而是針對你取得的用戶Token。也不是針對該Token被發送訊息的量,而是該Token被作為Bearer token參數時被呼叫的API次數。

所以不管是針對該Token(用戶)發送訊息(send notify)或是取得狀態(get status)都算一次。但由於基本量有1000,且定時會reset,所以其實這個數量是遠遠的超過一般的需求的。

開發人員無須擔心LINE官方帳號若作為訊息推播時成本提高的問題,適當的使用LINE Notify不僅會讓你的推播更加輕送,也能夠大幅降低成本唷。

-----------

最新實體課程:http://www.studyhost.tw/NewCourses/LineBot
線上課程:https://www.udemy.com/line-bot/
電子書:https://www.pubu.com.tw/ebook/103305
實體書:https://www.tenlong.com.tw/products/9789865022662
LineBotSDK:https://www.nuget.org/packages/LineBotSDK
如果需要即時取得更多相關訊息,可按這裡加入FB專頁。若這篇文章對您有所幫助,請幫我們分享出去,謝謝您的支持。

2020年3月5日 星期四

Azure DevOps in Action - 從需求建立分支的開發流程

前面提過,當我們有一個新的功能(或是bug)需要開發時,可以從tasks上建立branch,這個模式是走feature branch的開發流程[1]。一般來說,我們可以在Azure DevOps的Boards或是Sprints來建立:

其實我自己比較喜歡在Azure DevOps的Sprint畫面中來建立:

原因很簡單,因為開立tasks與branch的這項工作,幾乎都是在Scrum的Planning Meeting Part 2中進行,Planning Meeting Part 2,是團隊在討論某一個backlogs該『如何做?』的會議。這個會議進行時,肯定已經進入迭代(Scrum的迭代稱為Sprints),且已經決定好哪些backlogs要放入此迭代進行開發。所以,上面這個Azure DevOps中Sprints的畫面,團隊討論時一邊開起來看最適合不過了。

至於在哪一個tasks身上開Branch? 完全無所謂。因為最後相關的tasks都應該一併納入。

例如,上圖中,團隊準備開發『計算BMI』這個backlog,在planning meeting時,為該backlog建立了三個tasks,分別是編號942, 944, 945。不管你在哪一個task身上開branch,都會出現底下這樣的畫面:

請在(上圖A)的地方,輸入branch名稱,然後把所有相關聯的tasks都加進來(上圖B),直到三個與此branch都相關tasks都被納入。[2] 完成後,按下『Create Branch』鈕建立即可。

接著系統會自動帶你到底下畫面:

你會發現,該branch已經建立好了(上圖A)。這時候,你可以透過你的開發工具,把程式碼sync/pull到你開發端的電腦上,然後你會發現,在開發端的電腦上,已經可以看到該branch:

你可以透過Visual Studio的branch管理工具(上圖A),點選『管理分支』,然後就可以在出現的遠端分支中,找到剛才建立的分支(上圖B)。開發人員即可切換到此分支,開始撰寫程式碼。

建立PR(Pull request)

一但程式碼撰寫完成,開發人員可以透過同步(sync)的方式,把Committed在開發端的程式碼,同步到伺服器端。

一但程式碼完成同步,你會發現當你開啟Azure DevOps伺服器端的檔案檢視畫面時:

Azure DevOps會提醒你,你剛才更新了程式碼,並建議你開立一個PR單。

你可以點選(上圖A)的按鈕,開立一個PR單,點選後會出現底下畫面:

你會發現在這個畫面中,系統告訴你這張PR單準備要處理從『feature-計算BMI』分支合併到主線(master),你可以輸入一些描述或補充說明(上圖B),然後選擇程式碼code review的reviewer[3]

在(上圖D)的部分會自動帶入先前與此Branch相關聯的work items(還記得嗎?先前我們選了一些tasks),即便你先前漏掉了,在這個步驟依舊可以加添,這些被選定的tasks,在完成code review並merge之後,其狀態都會被自動設定為done。

確認輸入的資料無誤之後,您可以按下『Create』。

進行Code Review與Merge

接著reviewer會收到通知,點選通知後會被帶到PR的reviewer畫面:

Reviewer可以在這個畫面中檢視程式碼差異比較(上圖C),並且撰寫評論(上圖A),你也會看到頁面上有帶出相關聯的工作項(上圖B),在完成code reviewer之後,可以按下(上圖D)的Approve(當然有必要你也可以不approve,改選Reject。

確認無誤後,最後可以按下右上角的『Complete』鈕,它會將這段變更merge回到目標分支。

如此就完成了整個開發流程。

Branch與PR帶來的價值

透過上面這個流程,開發人員能夠更嚴謹的管理程式碼變更,同時團隊所修改的程式碼,會跟需求(或bugs)關聯在一起,讓整體的透明度有很大的提升,我們可以輕鬆地知道,某個需求改動了哪些程式碼? 反過來,我們也可以知道某一行檔案、某一行程式碼之所以變更,是因為哪一個需求。

不僅如此,我們也可以有效的保護master(主線,或其他目標分支)的穩定性與正確性,不會因為開發人員隨意修改主線,導致改壞了原本可以正常執行的系統。

這還只是版控而已,後面我們會從這個基礎點開始,接著加上CI與相關的自動化掃描,以及CD和相關的程式碼檢測。這對於軟體品質的改善將會有顯著的提升。

而PR過程中的code review,也是一個很重要的步驟,由於這個流程會誘導團隊自然而然地進行code review,那怕只是先從合併前的review開始,讓code review的習慣在團隊中慢慢萌芽。久而久之,對於團隊開發品質,與開發人員的功力成長[4],都有很大的幫助。


[1] 再強調一次,走哪一種開發流程,會依照團隊的特性、技能、習慣、甚至喜好而有所不同,並非放諸四海皆準。但要把握的原則是,我們之所以不直接改master主線,是因為要維持一個可以隨時建置佈署的穩定分支。

[2] 其實,如果你有兩個backlogs,底下的tasks也都與此branch有關,你可以把相關的tasks都納入,不一定要by每一個backlog都各自開一個branch。因為branch太多也不見得是好事。不過這部分請依照團隊習慣做選擇。整個團隊必須有一致性。

[3] Reviewer的對象並沒有一定要是團隊中的誰,一般來說,我們可能會選擇自己以外的一兩位資深開發人員、或是團隊中的leader來擔任reviewer。

[4] 學習程式碼最好的方式其實不是看書,是觀摩其他人寫的code。不管其他人寫的code比自己好或比自己糟,都會是一個很有效的學習。

---------------------------
相關課程:http://www.studyhost.tw/NewCourses/ALM
節錄自『Azure DevOps in Action』

2020年3月2日 星期一

Reactive


人有見識、就不輕易發怒.寬恕人的過失、便是自己的榮耀(箴言 19:11)

周末,去參加中學的同學會,結束之後大夥兒散場,因為老同學住在家裡附近,理所當然的搭他的順風車回去。就在準備上交流道的路口,後方一台B開頭的名車或許不耐等候,開始閃燈喇叭齊鳴。

我看到老同學瞥了後照鏡一眼,手反打入了低速檔,我立即把剛才忘了繫的安全帶扣好,心想接下來可要精彩了。要知道當年這位同學,可是率領我們一票人夜騎九拐十八彎的領頭狼,後來買了幾台名車之後,國道競速也時有所聞,即便人到中年,估計也是寶刀未老吧。

正當我身心狀態都預備好了,卻見老同學方向盤一個拐彎,把路讓給了後方的來車,只見後方BMW引擎喇叭輪胎聲大作,從我們車旁呼嘯而過。我心想,老同學這是身經百戰之姿啊,顯然是要讓對方輸得心服口服,所以打算從後方追趕是吧?

停了兩三秒…咦? 沒有。
偷瞄了老同學一眼? 嗯? 沒有反應。

『沒準備教訓對方一下嗎? 這不像你啊~』我忍不住開口揶揄一番。
『我現在開車可是心如止水,不動如山。』他笑著回答道。
『怎麼說? 是受了甚麼教訓嗎?』我一幅幸災樂禍樣。

結婚前,我女友常跟我說:『開車時幹麼跟其他車子比快比狠,除了逞一時情緒,還有什麼意義?』我當然聽在耳裡,沒放在心裡。

後來,有一年夏天,颱風剛過,路上很多被風吹倒的樹枝,當天急著要到公司,路還不很好走,開著開著,後面一台車也像是剛才那樣又是喇叭又是閃燈,我看了當然火大,立馬緊急煞車,停下來準備跟對方理論。

下車才走沒幾步,後方駕駛還沒來得及反應,我就發現他猛按喇叭的原因了…

原來我後保險桿勾到了一大串將近半個車身長的樹枝,顯然是被颱風吹斷的,似乎被我車子拖著跑了好一陣子。我一看當下沒了情緒,先把樹枝給拉開,然後跟對方駕駛打了個道謝的手勢。(原來後面的駕駛還是一位老太太)

回到車上,我一邊開車一邊思考,我想到的不是誤會了對方覺得不好意思(當然也有),而是,我發現原來人的情緒可以變化的那麼快,前一秒鐘我還想下車理論個輸贏,但下一秒後我立刻沒了情緒,為何會有這差別? 我意識到,其實是我對事情的『認知』造成的。

我沒看到部分的事實(樹枝纏在保險桿上),但卻看到了對方駕駛按喇叭和閃燈(這也是事實),我自己把這行為解釋成對方很不禮貌,就是要跟我輸贏。因為我這樣理解這件事,所以導致自己心情不好,衝動到下車打算講個道理,甚至想動手出氣。

但原來對方可能是好意,而我不知道。然而重點是,其實不管對方是惡意或好意,我發現其實影響我心情的,是我怎麼看待這件事情,也就是我對自己遭遇到的事情的認知是什麼。

『心如止水?』我突然補了一句。

他接著說:『從那一天開始,每當有人在後面按喇叭和閃燈,我就會想起這件事情。我會先下意識的檢查一下是不是自己的車子怎麼了,會不會對方其實是想提醒我。一想到這邊,我就沒了情緒。』

『但我覺得路上的惡人還是比好人要多的多,是吧?』我問。
『沒錯!』他回答。

確實開車時大多數人其實都是沒耐心沒禮貌才閃燈按喇叭,但有了前面的那次經驗,以及後來刻意的練習之後,我發現自己逐漸可以『假裝』對方是為我好,想提醒我什麼,才瘋狂的按喇叭。久而久之,我幾乎可以不對路上車子的無理而動氣。

有一天我意識到,我居然可以這麼輕鬆地控制自己的情緒? 且這種控制不是忍住壓抑,而是有能力決定,當面對別人的無理時,自己要採用哪一種態度來回應

接著我發現,這能力在工作上非常重要。讓我可以平和理性的面對客戶或同事的無理、或不友善的態度。因為我知道我有能力,也可以,選擇自己回應的方式

由於不在盛怒下衝動的做決定,久而久之,我發現自己可以不被情緒控制,決策更加的正確,大多數同事也慢慢覺得我是個理性好相處的人。

『我想,現在根本沒人會相信,當年我是吆喝一群人夜騎飆車的衝動少年了吧。況且,就像我太太說的…』他緩緩地道:『在路上跟其他車子比快比狠,除了一時情緒,其實根本沒意義。』

『現在我都在這裡玩車』他拿出一張會員卡給我看,說道:『這邊拚輸贏還可以開香檳,拿名次,練技巧…比起在路上沒法控制自己情緒的亂衝耍狠,要有趣的多了。』

我知道他其實是有在玩車的,還花了不少錢在上面。只是沒想到他在路上竟然可以這樣控制自己的脾氣。這到底是不是他在事業上小有成就的原因呢? 我不知道,但他說的那句話『我知道我有能力,也可以,選擇自己回應的方式。』讓我印象深刻。

我打算把這句話記起來,下一次有人從後面無理地按喇叭的時候,我不想輸給老同學,也不想讓自己沒有不生氣的自由。

2020年2月29日 星期六

Azure DevOps in Action - 專案的相依性管理與套件的使用


近代軟體開發大多以套件或框架為基礎,不管你採用哪一個語言。最近這五年,我們在專案的相依性管理上已經有了很大的成熟度和改變。如果你回憶十幾年前的軟體開發,可能常常看到專案中有底下這樣充滿相依性的設計:

說明一下,在上圖中,WebBMI.sln內共有三個專案,HealthMgr(上圖A)它是一個類別庫(Class Library),而HealthMrgTests是該類別庫的UnitTest,WebBMI則是Web UI的主程式(上圖B)。

由於主程式中使用到了HealthMgr,因此它是相依於HealthMgr的,也就是說,主程式在建置時,必須要參考到HealthMgr內的一些類別與方法。

如果你開啟Visual Studio來看會更清楚:

Visual Studio 2019本身有著很好的相依性檢視工具,你可以看到主程式WebBMI相依於同一個.sln中的HealthMgr,而且是以專案形式相依,這點是我們不喜歡的。

目前,WebBMI以『加入參考』的方式:

把同一個.sln中的HealthMgr給加入到WebBMI當中:

這雖然讓WebBMI可以輕鬆的使用到撰寫於HealthMgr內的類別和方法,但這是很古典的作法,不能說不好(如果把HealthMgr內的類別直接全寫在WebBMI主程式中可能更不好),但最近幾年我們已經不再鼓勵開發人員這樣作了。

最主要的原因有幾點:

第一, 這使得WebBMI這個Project在Build的時候,非得跟HealthMrg專案綁在一起,兩者無法分割,形成高相依性。兩三個專案你看起來還好,但我就看過.sln的solutions中有近百個專案的。

第二, 如果HealthMrg專案又被另一個B專案所參考使用,未來很可能造成潛在的版本衝突。例如,當WebBMI專案因為某些理由,必須修改HealthMrg專案中某個類別的運算邏輯,但因為除了WebBMI專案之外,B專案同時也在使用HealthMrg中同一個類別,導致若修改了HealthMrg就會與B專案不相容,不改又不符合WebBMI新的需求,進入兩難的狀況。

砍斷針對專案的相依

因為前述的原因,近代在我們作軟體開發時,幾乎都已經不會再如同過去這樣,直接對某一個專案作參考(reference),造成專案之間的潛在相依性衝突,而是改為針對套件(Package)的相依。

砍斷對專案的相依,改成對套件相依有許多好處,我們可以把前面講到的HealthMrg專案,建立成一個副檔名為HealthMrg.nupkg這樣的套件,然後把主程式(WebBMI.csproj)對HealthMgr專案的參考,改為對HealthMrg.nupkg套件的參考。

由於HealthMrg.nupkg套件本身可以有多重的版本機制(例如HealthMrg.1.0.1.nupkg , HealthMrg.1.0.2.nupkg這樣),每一次當套件需要修改,我們只需要增加版號即可。

如此一來,就算同時有多個專案參考到同一個套件,因為套件有版本可以區分差異,所以無須擔心A, B兩個專案同時參考了HealthMrg這個套件後,HealthMrg需要更新時該怎麼辦的問題。

也因此,近代軟體設計中,只要可能被其他專案參考使用的類別,我們幾乎都會設計成套件的形式,這也讓套件庫這樣的機制開始盛行,Node.js開發有NPM、python有pip、.net開發則是Nuget。

為了確保使用到套件的應用程式可以正確執行,所有的套件都必須維持恆定性,也就是套件一但上架後是不能修改、不能刪除(只能下架隱藏)的,如果有修改,就必須對套件作版號上的增添。這也是你會看到套件都有這樣的版號的原因:

HealthMrg.1.0.1.nupkg

HealthMrg.1.0.2.nupkg

HealthMrg.2.1.1.nupkg

HealthMrg.2.2.1.nupkg

一般來說,版號會遵循著業界的規則。

例如,HealthMrg.3.2.5.nupkg這個套件其中的3是Major, 2是Minor, 5是Patch:

舉凡Major版號有所變更,例如從2升到3,大多表示新版(3.x.x)將與舊版(2.x.x)有相當大(大到不相容)的改變。因此,當我們看到自己專案中所採用到的套件升級了Major版號的時候,一般也意味著必須留意升級後相容性的議題。

而Minor版號的變更,則大多是在維持相容性的前提下,所作的套件功能擴充或修改。而Patch則多是bug fix,或是某些與新功能無關的套件修正或調整。

這個版號是業界對於套件建立與開發的習慣,遵循這樣的版號機制,可以讓套件的開發者與使用者在同一個基礎上順暢的合作。

在.net core專案中建立nuget套件

對於套件有一定的認識之後,我們就實際來建立一個套件。打開Visual Studio 2019建立一個.net core的類別庫:

或乾脆使用我在Azure DevOps上公開的Repo,其Clone位置如下:

https://mytestaz400@dev.azure.com/mytestaz400/SampleCode/_git/dotNetCoreBMISample

你可以直接建立一個Azure DevOps專案,然後在repo中Clone上面這個現有的Project。

開啟後,你會發現,其中有一個HealthMrg專案:

這個類別有一個Calculate方法(上圖A)我們會在WebBMI的主程式中使用到:

參考上圖A,你會看到這是以.net core的razor page所撰寫的主程式,其中呼叫到了HealthMgr類別中的Calculate方法,用來計算BMI。這是因為在這個主專案中我們透過『加入參考』的方式,參考了同一個.sln方案中的HealthMgr專案,之前說過,這是傳統的作法,而現在我們要改成以Nuget Package的方式參考。

我們來到了HealthMgr專案的屬性視窗:

你會發現,在.net core/.net standard的類別庫(Class Library)專案上,想要讓某一個類別庫專案建置為nuget套件非常、非常容易,只需要在上圖的畫面中打一個勾即可。

當專案勾選了『建置Nuget套件』後,在Build這個類別庫時,就會自動建置出該組件(.dll)的nuget套件。

若你開啟產生出的nuget套件,可以看到:

包含該.dll的nuget套件就這樣被自動的建立出來了。

將套件上傳到Nuget.Org

建立好Nuget套件之後,我們得讓原本主程式WebBMI改為對套件參考,而非對專案參考。因此,我們必須先把建置好的套件發佈到套件庫裡面。

套件內的程式碼常常會被視為企業資產的一部分,所以一般來說,企業應該要針對自己開發的套件作為一個Private的套件庫,而非上傳到開放存取的Nuget.Org[1],以避免全世界都來共享你的開發成果。

要建立一個Private Nuget也不是太難,但更方便的是Azure DevOps裡面已經具有內建的套件庫,位於Artifacts:

不過,我們後面再來談這個部分。我們先來看,如果要把套件上傳到Public的Nuget.org該如何作?

開發人員只需要具有Microsoft Account,就可以透過Single Sign On的方式,登入Nuget.org(人人可開發套件的概念):

登入後,最簡單的方式,是透過Upload Package選單來上傳你開發好的套件:

在右上角登入的個人選單底下,選取Upload Package(上圖A),就可以進入上傳畫面,然後選取你要上傳的組件直接Upload即可。

不過要請留意,你的套件ID不能跟其他人的相同,且每一個套件的同一個版本,也只能上傳一次,否則就會出現底下的錯誤訊息(下圖A):

所以,如果你是Clone本文中前面提到的專案,你必須修改套件名稱和版號,才能夠上傳的上去nuget。由於我是HealthMgr這個套件的作者,因此我可以上傳id為HealthMgr的套件,只需要修改版號即可:

在上圖中我們把版號改成1.1.10,Visual Studio會自動建置出名稱為『HealthMgr.1.1.10.nupkg』的套件。

取得套件後我們將其上傳:

上傳後你會看到該套件會先被自動檢查,並且nuget會為其建置索引,一段時間後(大概十幾分鐘到一小時),該套件的狀態(Status)就會變成Listed,這意味著剛才我們上傳的套件已經上架,這時候你在開發工具中,就能夠使用該套件了。

改為針對套件的相依

在套件上架後,我們可以透過Visual Studio的方案總管,先移除WebBMI主專案原本對HealthMrg專案的相依。

您可以在專案名稱上按下滑鼠右鍵,選擇加入參考,就會出現底下畫面。然後直接把原本打勾的HealthMgr勾選取消:

移除後,你會發現,方案總管中相依性的部分也看不到『專案』了。

接著,我們再對主專案加入Nuget套件:

我們可以透過專案的『管理nuget套件』選單,開啟Nuget套件管理員,接著選擇『瀏覽』頁標籤,透過關鍵字搜尋套件名稱。

你會發現我們剛才上傳的套件果然有列在清單中,點選該套件選擇『安裝』即可:

成功安裝後,你可以建置(Build)主專案,你會發現主專案由於使用了這個套件,既便沒有直接對HealthMrg專案的相依,依舊是可以建置與執行的:

就是這樣,我們將主專案中針對Project的相依,改成針對Package的相依,過程並非相當困難,但對於系統相依性的管理則大大的提升了便利性。


[1] 當然,如果企業覺得該套件沒有敏感性,也沒有商業考量,想要上傳到nuget.org和全世界一起分享也並無不可。

---------------------------
相關課程:http://www.studyhost.tw/NewCourses/ALM
節錄自『Azure DevOps敏捷開發與專案管理實戰

2020年2月28日 星期五

凡事都可行,但不都有益處…

凡事都可行,但不都有益處:凡事都可行,但不都造就人。(林前 10:23)

前陣子有位好友特別到我辦公室,跟我討論他最近想要做的某個軟體產品。他知道我過去這幾年有非常多產品開發(我想估計是失敗的)經驗,所以他說想跟我請益一番。

一如既往,只要人到了我辦公室,我肯定熱情接待、滔滔不絕、知無不言。談過了他的想法與企圖,也給了一些建議,茶過三巡,我也就不客氣地分享了我最近想做的另一個資訊服務,話還沒講完,他拍案大讚,說到:『David你這個案子會成,要不要做? 我有興趣。』

他的熱情讓我愣了一下,我有點猶豫地說,我還在思考一些問題,像是…為什麼我目前沒看到市場上有類似的服務? 台灣那家知名的網路商城P公司,該是最有資格做這個案子的,不管是倉儲、物流、和我這個案子最關鍵的庫存品,都一應俱全,我不太懂他們為什麼不做?

朋友說了一句話:『P公司太大了,他們什麼都能做。什麼都能做,就代表什麼都做不了。』

他話才說完,我就明白了。
(有時候跟頻道接近的朋友聊天就是有意思,話不用講太多,彼此一點就懂。)

我明白了朋友說的意思,但也看到了我自己的限制。

這一直以來是我的問題,我意識到這個問題,但卻始終沒有去面對。

前陣子流行『斜槓青年』,你可以在網路上找到這個字的意思。但我慢慢發現自己實在斜槓太多的領域了(而且也不是青年了)。過去這幾年,我寫書(手上正在寫一本),做企業顧問(目前一家進行中,一家洽談中),同時也帶人做軟體專案(目前三個案子進行中,好在差不多都是結案階段了),我也喜歡上課(下個月開始預計有兩個排定的課程),另外每周我給自己的目標是產出三到五篇的貼文、blog文章和數個教學影片檔,為了提供給線上課程和電子書…

然後,我還一直很想做產品。

雖然盡全力把每一個手上的任務做好,但很明顯的,我發現瓶頸在哪裡了。的確,瓶頸就在自己身上。

問題來了,我要割捨掉哪一塊? 我太明白多工與多重目標所帶來的陷阱和限制。回頭翻自己的貼文,還有底下這兩張照片呢:

但怎麼當要去面對這些問題的時候,自己也變得難以割捨了?

管理方法的道理和邏輯永遠是那麼鮮明,但執行的困難卻往往不是不懂這些,而是在情感上的拉扯和限制。

剛開始工作的第一年我就發現,除非自己選擇放下,否則手上的工作永遠不會有作完的那一天的。而當人(企業)能做的事情看似愈來愈多,就愈是得克制每一件事情(每一個目標)都想去做的衝動。

我記得從某本談管理的書上看到這麼一段話:『這世界上根本沒有時間管理這回事,你要管理的不是時間,而是你自己。』

我喝了口手上的咖啡,抬頭跟朋友說:『這個案子我真的很有興趣,但我得再放一陣子。對我來說,現在不是最好的時機。』

這世上有許多很有趣的事情等著我們去做,不過,我們始終得把優先序排好才行,畢竟,管理好自己,是成就所有事情的第一步。

自由不只是去做所有自己想做的,更是有能力放下自己不該做的。工作是這樣、專案是這樣、其實生活也是。

Related Posts Plugin for WordPress, Blogger...

熱門文章