.NET Walker

官方帳號(或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

當許多用戶開始使用 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參數時被呼

前面提過，當我們有一個新的功能(或是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 D

人有見識、就不輕易發怒．寬恕人的過失、便是自己的榮耀( 箴言 19:11 ) 周末，去參加中學的同學會，結束之後大夥兒散場，因為老同學住在家裡附近，理所當然的搭他的順風車回去。就在準備上交流道的路口，後方一台B開頭的名車或許不耐等候，開始閃燈喇叭齊鳴。 我看到老同學瞥了後照鏡一眼，手反打入了低速檔，我立即把剛才忘了繫的安全帶扣好，心想接下來可要精彩了。要知道當年這位同學，可是率領我們一票人夜騎九拐十八彎的領頭狼，後來買了幾台名車之後，國道競速也時有所聞，即便人到中年，估計也是寶刀未老吧。 正當我身心狀態都預備好了，卻見老同學方向盤一個拐彎，把路讓給了後方的來車，只見後方BMW引擎喇叭輪胎聲大作，從我們車旁呼嘯而過。我心想，老同學這是身經百戰之姿啊，顯然是要讓對方輸得心服口服，所以打算從後方追趕是吧? 停了兩三秒…咦? 沒有。 偷瞄了老同學一眼? 嗯? 沒有反應。 『沒準備教訓對方一下嗎? 這不像你啊~』我忍不住開口揶揄一番。 『我現在開車可是心如止水，不動如山。』他笑著回答道。 『怎麼說? 是受了甚麼教訓嗎?』我一幅幸災樂禍樣。 結婚前，我女友常跟我說:『開車時幹麼跟其他車子比快比狠，除了逞一時情緒，還有什麼意義?』我當然聽在耳裡，沒放在心裡。 後來，有一年夏天，颱風剛過，路上很多被風吹倒的樹枝，當天急著要到公司，路還不很好走，開著開著，後面一台車也像是剛才那樣又是喇叭又是閃燈，我看了當然火大，立馬緊急煞車，停下來準備跟對方理論。 下車才走沒幾步，後方駕駛還沒來得及反應，我就發現他猛按喇叭的原因了… 原來我後保險桿勾到了一大串將近半個車身長的樹枝，顯然是被颱風吹斷的，似乎被我車子拖著跑了好一陣子。我一看當下沒了情緒，先把樹枝給拉開，然後跟對方駕駛打了個道謝的手勢。(原來後面的駕駛還是一位老太太) 回到車上，我一邊開車一邊思考，我想到的不是誤會了對方覺得不好意思(當然也有)，而是，我發現原來人的情緒可以變化的那麼快，前一秒鐘我還想下車理論個輸贏，但下一秒後我立刻沒了情緒，為何會有這差別? 我意識到，其實是我對事情的『認知』造成的。 我沒看到部分的事實(樹枝纏在保險桿上)，但卻看到了對方駕駛按喇叭和閃燈(這也是事實)，我自己把這行為 解釋成對方很不禮貌 ，就是要跟我輸贏。因為我這樣理解這件事，所以導致自己心情不好，衝動到下車打算講個道理，甚至