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敏捷開發與專案管理實戰

2020年3月2日 星期一

Reactive


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

熱門文章