.NET Walker

Overview 這個 Lab 介紹如何透過Command Line來免費發送的LINE Notify通知 Prerequisites 下載安裝 .net core sdk 3.1 以上版本 here 安裝 LINE CLI 工具1.0.19以上版本 here Steps 在command line輸入 dotnet --version，確定您的執行環境具備 .net core 3.x 以上版本 PS C:\ > dotnet --version 系統會出現類似底下畫面… PS C:\ > dotnet --version 5.0.202 2.接著執行底下指令， 安裝 LINE CLI 工具… PS C:\ > dotnet tool install --global line.cli 如果成功，系統會出現類似底下畫面… 工具 'line.cli' 已安裝。 申請 LINE Notify Token 前往 LINE Notify ，以個人帳號登入，至個人頁面的最下方『發行權杖』： 選擇訊息要發送到哪一個群組(亦可發送給自己一人)： 按下『發行』後，可取得類似底下的 Notify Token: 如果是發送給群組，記得將 LINE Notify帳號加入該群組中。 未來，只需要透過底下Command Line指令，即可免費發送LINE訊息給特定群組： PS C:\ > line notify -n [ NotifyToken ] -m 要發送的訊息 你會發現訊息就會出現在LINE通知中： CLI本質上也是透過 LINE官方的Rest API來完成的： POST /api/notify HTTP/1.1 Host: notify-api.line.me Authorization: Bearer ___Notify_token___ Content-Length: 135 Content-Type: multipart/form-data; boundary=----WebKitFormBoundary7MA4YWxkTrZu0gW ------WebKitFormBoundary7MA4YWxkTrZu0gW Content-D...

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，我覺得會是遺憾...

官方帳號(或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參數時被呼...

接續著 上一篇 介紹如何用 .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...

前面 提過，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撐腰，又有自然語言語意...

我在現場看到LINE日籍講師使用 VS Code作為主要的開發工具，還頗讓人驚豔的 緣起 前陣子，LINE推進了LIFF這個框架來到 v2的版本 ，v1到v2是一個很大的改變，一般來說，我們改變主版號(from 1 to 2)意味著新釋出的版本將跟前一版有著不相容性，也就是一個重大的breaking changes，也確實，v2版本增加了很多亮眼的新功能，像是QR Code掃描、外部瀏覽器支援…等。 還不只如此，LINE 11/11發布了一個我認為很重大的 消息 : Users can no longer add LIFF apps to Messaging API channels 看到這個消息的第一眼，我只有一堆問號…，WHY? 為何LIFF 2未來只能從LINE Login新增LIFF，為何將要取消過去LIFF綁在Bot(Messanging API)身上的方式??? 我相信不只我有這個疑惑，很多熟悉LIFF的開發人員也是。我心裡始終帶著這些問號，來參加了今年的LINE Developer Day，當然，我希望能找到答案。 LIFF的改變 在Day 2關於LIFF的場次中，講師不免俗地把LIFF的歷史交代了一下: 其實從v1到v2也不過就是一年的時間，但重點當然不是歷史啊，重點是改變。到底有那些改變呢? 那得看當前的LIFF有些什麼: 上面這三張看似平淡無奇的投影片，其實是接下來講者埋的梗，我得說，後面看到差異的時候，是頗讓人興奮的。上面第一張投影片的Easy Development是理所當然，LIFF可以透過純HTML方式開發，且運行上是無需伺服器端的，但我們也知道，當前的LIFF只能運行在LINE的WebView環境，即便是開發方式和一般的HTML頁面相同，你還是會碰到像是開發階段難以debug之類的困擾。 是的，v1的LIFF是很難偵錯的，因為你必須在手機環境上(LINE的內部WebView)才能執行。我忍不住直接破梗好了，講者在最後ending的時候，上面第一張slide變成了： with LIFF v2，你可以在手機的外部瀏覽器上運行，這也表示，你有機會可以在一般的瀏覽器上進行開發和除錯。對，你沒聽錯，過去非得在手機裡測試偵錯的時代即將過去了，當你用LIFF v2架構開發搭配SDK，基本上你的開發根本就像是一個純Web Application(只是這...

過去幾年，我身邊很多軟體開發人員，要嘛往大陸發展，要嘛待歐美棲身，但LINE選擇的路線，卻給了我一個不同的啟發… 今年 的LINE Developer Day依舊位於東京舉辦，不過較之過往，擴大為兩天的議程，在keynote當中，講者有提到今年改為兩天的原因。總的來說，過去想說的事情多，能用的時間少，所以今年改為兩天乃是天經地義、理所當然(但…費用不就增加了一倍? )。 話雖然這麼說，但我其實一直對LINE的工程師文化很好奇，一個保有傳統謹慎保守基因的日系公司，怎麼去塑造一個對開發人員如此友善的開放文化? 你如果到日本東京新宿LINE辦公室的開放空間，會看到底下這樣的場景： 充滿自在氛圍的空間裡，有著喝咖啡寫程式的Developer、有著接洽外來訪客的員工、甚至放空休息的夥伴…在同一個空間裡，自在且互不打擾的完成自己當下的任務。 這種自由開放的氛圍很像這兩天的大會，當你仔細觀看，不難發現 議程表 上的內容，絕大部分都是LINE員工們真實開發經驗的分享，其中少數才是LINE相關產品和服務的介紹，這跟過去我們看到由企業主辦的年度大拜拜聚會完全不同，更有點像是open source社群聚會的感覺。 透過 上百個議程 ，講者竭盡所能的，把自身的開發經驗，分享給與會的其他開發人員: 這些議程當中，大部分是LINE如何透過open source開發技術，實現自身所需的商務需求、以及自己在採用open source技術所碰到的挑戰與解決方案，那這些議程是怎麼決定的呢? 我問了來自台灣LINE團隊的講者，這些議程主題怎麼決定的? 台灣LINE團隊的講者跟我說，大部分都是由LINE員工投稿，獲選後由LINE贊助講者參加大會，一聽之下，發現身為LAE的我們，平白享有免費三天的東京飯店＋來回機票，看起來待遇似乎比LINE自己的員工還好呢～ 其中有個頗有趣的地方，由於LINE大量的使用了open source技術，對於過去很少接觸 OSS 的微軟 .net 開發人員來說，參加LINE的聚會會讓你突然恍如置身到另一個世界中的感覺，議程當中許多過去在 .net 世界中沒有的東西，霎那間頗有讓人目不暇給之感。 今年的場地改在台場日航飯店舉辦，這個地點是著名的觀光勝地，搭地鐵前往的路上，電車上路過的海景頗讓人心曠神怡。當天天氣很好，廣場上藍色的天空讓人一覽無遺。 到了夜晚，當地頗具盛名的購物中心和...