.NET Walker

Line在去年以OAuth規格推出了Line Login機制，試圖與各家大廠一起角逐身分驗證與單一登入SSO(Single-Sign-On)的一席之地，相關的概念與使用方式我們在06年底曾經 介紹過 。 而關於SSO與OAuth相關的技術與概念，我們也曾經在 這邊 有過分享。 今年(2017)底，Line又更新了Line Login相關的API，來到了 v2 以及 v2.1 ，在這一版更新當中，Line Login可以跟Line bot做 連結 和整合，以便於讓你得知用戶更多的訊息並與用戶互動。除了功能比較多之外，還有一個你不得不升級的原因，因為舊版v1的API，依照公告，將於2018年三月底停用： https://developers.line.me/en/news/2017/12/05/ 因此我們的LineBotSDK也更著做了升級，我們後續將分幾篇貼文來介紹新版的Line Login API，這篇我們先來看基本SSO的部分，首先，由於申請畫面跟舊版有些許不同，我們也一併整理一下。 申請新版Line Login服務時，請先從 https://developers.line.me/en/ 的官方管理站台登入，登入後請點選主畫面的『Start Using Line Login』： 接著出現底下畫面，請依序輸入相關資料，其實本質上跟 我們介紹v1時 候的做法差不多，由於我們待會要做的是Web Site的SSO，下圖畫面請務必勾選Use Web： 輸入完成後按下 Confirm，最後會出現底下畫面，基本上一個服務就建立完成了。但相關資訊我們還要接著輸入，因此，待會請點選底下畫面中我們新建立好的這個Line Login服務圖示 ： 進入後你會看到底下畫面： 其中大部分的資訊都是我們剛才自己輸入的，少部分是系統產生的，其中就包含了上圖畫面中標示A、B的部分，如果你熟悉OAuth flow就應該不陌生，上圖中的ID與secret就是我們要做SSO時的client_id與client_secret，不過新版Line Login底下多了一個Bot linked…的部分(標示C)我們後面再來談。 請留意畫面左上方有一個App Settings： 點選後會出現底下畫面： 我們待會按下上圖右方的筆，來修改這個callback URL。在此之前，我們當然得先產生出一個Callback ...

前幾天聊到價值(Value)，給我點時間，讓我細說從頭。 這幾年做案子下來，發現大多數的SA/PM/PO在需求訪談時跟客戶談功能很在行，談價值卻很吃力。你可能覺得疑惑，需求訪談不就是談需求嗎? 為何會扯到價值? 回答這問題前，先幫我想想，一個軟體的需求是為了什麼? 沒錯，需求是為了實現價值，功能則是需求的具體表現。 舉例來說，一個電子商務網站可以有各式各樣的功能，但核心價值要嘛是銷售、要嘛是服務，OK，這個你一定懂。 但大多數的SA或技術人員，受過了多年的技術訓練，談功能很拿手，各種工具、圖表、道具順手捻來毫不手軟，客戶看的眼花撩亂但也很開心，因為看到這麼多功能(工項)被列出來，腦袋裡自然而然幻想著，當這些功能實現，需求『自然』就滿足了，而需求被滿足，價值『自然』就實現了。 但真的是這樣嗎? 做那麼多年的軟體之後，你肯定知道，不是的。擁有一堆功能跟這個 軟體/網站 能不能滿足客戶需求乃至於實現某種價值，根本可以是兩回事。 然而很多客戶(和廠商)死不信邪，以為價值沒實現是因為功能不夠多(天殺的!!!這是我碰過最可怕的思維...) 然後試圖用無止盡的增加功能來滿足可能根本不存在的想像出的需求，然後在心裡期望價值能發生。(天佑PM/天佑SA/天佑客戶...) 每當我們要求跟客戶談需求時，試圖把焦點拉回價值(而不是一直停留在談功能上)，一開始客戶都很不習慣，因為這仿佛很抽象，廠商自己也擔心，因為哪有一個網站可以保證上線後就財源滾滾而來? 就好比你賣一個ERP軟體要保障客戶使用後利潤增加一成，這...似乎有點難? 對，但就是因為這很難，所以久而久之，我們把價值放一邊，銷售時就拼命暗示客戶你有某種需求等著被滿足，而要滿足這些需求，則要做出這些功能，只要你買了這些功能，一切就搞定了。 然後，最初期待實現的價值呢? 恩...沒實現嗎? 不要緊，下一套軟體我們再來談... ------------------ 相關課程： http://www.studyhost.tw/NewCourses/ALM 電子書： http://studyhost.blogspot.tw/2014/10/blog-post_1.html 如果需要即時取得更多相關訊息，可按 這裡 加入FB專頁。若這篇文章對您有所幫助，請幫我們分享出去，謝謝您的支持。

最近網路上有幾篇文章， 這篇 文章中談到的MVP(最小可行性產品)那個圖，我在上課時也常用，也常被問到一樣的問題，而我的回答也總是很簡單... 在下圖中第一和第二個路線的例子裡，我們從來都不是說要做『一台汽車(太具體了)』，而是說要做一個運輸或交通工具(相對抽象)，因為一開始你根本不會知道具體需求是甚麼，下圖中的『汽車』只是運輸器具的一種呈現方式，但根本不是一開始的目標... (如果你做過產品，就會知道，開始時需求根本不可能是具體的，更不用說有什麼『清楚的規格』這種事情了，再清楚的規格，其實都是你自己的想像，只要碰到市場都會幻滅) (講到這裡你應該知道我認為下圖是對是錯了，但重點在於，這些根本不是重點!!!) 這幾篇文章討論到最小可行性產品這個議題時，都少了一個我們做軟體專案時非常重要的概念，就是:『MVP的每個迭代(或交付)都必須要對用戶產生出價值(Value)』。 因此我在談MVP時的重點，從來都不是雛形(prototype)、也不是邊做邊改去符合(或探索)用戶需求，甚至不是其實我認為也很重要的快速反饋，而是『時刻產生價值』。 沒有帶來價值的產出，不管是滑板、腳踏車還是機車、汽車，對我(客戶)來說，都叫做『浪費』。 當客戶的預算有限、需求常常變、一切彷彿都捉摸不定時，你很有可能永遠都不知道客戶(或市場)到底最終要的是戰車還是超跑，但，不管你產出的是什麼，只要能在當下立即為客戶帶來『價值』，那就是好東西，否則不管你做出什麼曠世巨作或太空梭，只要沒能帶給客戶價值，我們都稱之為『浪費』。 敏捷專案管理中所追求的，是每一個迭代、每一次交付都要能為客戶帶來『價值(Value)』。這很不容易，但這才是我在乎的重點... 後記：關於價值，為何我們那麼看重? 後續我又做了一些補充，請參考 這裡 。 ------------------ 相關課程： http://www.studyhost.tw/NewCourses/ALM 電子書： http://studyhost.blogspot.tw/2014/10/blog-post_1.html 如果需要即時取得更多相關訊息，可按 這裡 加入FB專頁。若這篇文章對您有所幫助，請幫我們分享出去，謝謝您的支持。

我猜，這應該是第一本跟Line bot (Line Messanging API)開發有關的電子書了吧。 [ 購買位置 ] >>>>>>>電子書特色 1.全彩 2.具有超連結(在章節、圖片、引用網址) 3.圖片可放大檢視 4.方便檢索、方便筆記或塗鴉、不傷本體 5.購買後終身免費持續更新 >>>>>>>序言 2017 年，今年一整年可以說是開發人員的AI元年，從2016開始，各種人工智能、bot的開發工具與套件紛紛出籠，各大廠商像是深怕自己被人遺忘一般，把手上各種放在實驗室中已久的人工智慧服務、套件、APIs端上檯面。 而IM則趁勢搭上這股風潮，台灣常用的Line、FaceBook Messanger、中國大陸的WeChat、標榜著自由開放的Telegram…都紛紛推出bot開發工具與框架，讓這個市場突然之間熱鬧了起來。 早在2013年初，在坊間這些AI工具和服務尚未出現之前，筆者就有幸因為專案的關係，接觸到了自然語言對談機制與bot開發相關領域，也因此，對最近這一陣子市場上出現的各種服務與應用相對熟悉、同時也非常感興趣。 身為微軟MVP，剛好也比較有機會接觸到早期釋出的一些資源，例如Cognitive Services，其中包含了人臉辨識、語意分析、圖像辨識、語音辨識…等多項功能。 因為工作上的需要，綜合這些技術，搭配上台灣相當普及的Line通訊軟體，2017年我們建構出了許多Linebot相關應用。同時間也應邀舉辦了多次的教育訓練課程，介紹如何開發Linebot對談機器人，並且與企業各種應用整合在一起。 許多應用本身就非常有趣，用戶的反饋也讓我們感到相當興奮。而這些第一手經驗，我們希望能盡快的整理出來，更多的分享給對這個領域有興趣的技術人員。 因此，你看到了這本電子書。 我們期望，透過這小小的經驗分享，讓對於自然語言對談實作與應用有興趣的朋友，可以快速的入門上手，並且用最短的時間作出一隻可以分享給你的親朋好友的Linebot，不只是為了趕上時代的潮流，也是滿足了身為開發人員從小對智能助理的期待與幻想。 >>>>>>> 本書相關議題: Line bot 文字、貼圖、圖片、Template Message…等訊息發送與回覆 Li...

從我們釋出第一版的 LineBotSDK 開始，套件的建立最主要的精神就只有一個，讓我們家的.NET開發人員，能夠用更簡單、輕鬆、便利的方式來開發Linebot。 在這個最主要的目標之下，我們再盡可能地兼顧開發自由度、以及開發的架構、可維護性、與持續更新和相容性…等議題。 也因此，在最近撰寫了數不清的line bot和蒐集了一些用戶實際的反饋之外，我覺得可以將整個LineBot WebHook的開發繼續簡化，讓有興趣進入這個領域的初階開發人員，能夠更輕鬆沒有負擔的踏入開發。 因此，我們從0.6.4-beta1這個版本開始，加入了LineWebHookControllerBase這個類別，讓開發人員可以在幾行的程式碼內完成一個Line bot WebHook的設計。 像是底下這樣： 你會發現，我們把原本的APIController換成了LineWebHookControllerBase(第10行)，這會讓開發人員可以少寫很多程式碼，例如抓取http post data後Parins並轉換JSON成strong type物件的工作(白話：取得用戶傳給Line bot的message)，就由我們的LineWebHookControllerBase這個類別代勞了，你只需要透過20行的this.ReceivedMessage即可抓取到需要的物件。 同樣的，如果要push或reply，也可以透過像是this.PushMessage或this.ReplyMessage這樣的Method來完成(像是第22行)。 你大概也已經發現，ChannelAccessToken的部分我們可以在第18行透過this.ChannelAccessToken這個屬性設定一次即可。甚至你所幸乾脆不撰寫在程式碼裡面也行，LineWebHookControllerBase會自動抓取Web.COnfig / AppSettings 中 ChannelAccessToken這個Key的Value(如果有的話)，如此一來，開發人員就更無須特別撰寫相關的code了。 整體來說，應該降低了不少開發難度。 如果你從來沒有寫過任何Line Bot WebHook，可以從底下介紹開始。 首先，請先開啟VS2017/2015，接著建立一個空的aps.net web專案： .net版本建議 4.5.2以上，底下畫面記得務必選擇...

2017年下旬，Line更新了相關的API，終於讓Linebot可以抓取到群組中的用戶的資訊，這一點看似不起眼，但其實沒有這個功能的話，相當程度的限制了Linebot在群組中的可能性。 也因此，隨著Line開發相關API，我們的 LineBotSDK 當然也跟著支援了，請將專案中的LineBotSDK更新到 v0.6.1-beta 即可享有此功能： 更新後你會發現有幾個跟群組聊天有關係的API，分別是 LeaveRoom LeaveGroup GetRoomMemberProfile GetGroupMemberProfile … 在開始之前，你需要知道一些基本概念: Line裡面的群組聊天有兩種，分別是room與group 你隨意地邀請幾個人加入聊天，那一種叫做room 你透過選單所建立的群組，叫做group 一個群組裡面只能加入一隻bot 你的bot無法知道是誰把自己加進來的 但你的bot可以知道群組中當前說話的人是誰(意味著，可以取得他的個人資料，包含頭像、顯示名稱…等)，即便你的bot沒有跟發話者成為好友。 你的bot只能被某人加入群組，無法主動加入群組，但可以主動離開群組。 好了，有了這些基本概念之後，我們可以開始來玩玩看，請先大致瀏覽一下底下這段code，這是WebHook的片段程式碼(完整程式碼位於github https://github.com/isdaviddong/LinebotInTheGroup )  : 接著我們看運行的結果，當我們在兩人對話的狀況下，可以透過邀請好友的方式，把一隻bot加入對談： 注意上面testlinebot2018這支bot，請觀察他回復的訊息，你會發現，他是知道自己是被加入room還是group中的(這資訊很重要，可以透過source.type取得)。 同時，當你對照上面的code也可以知道，當bot被加入群組(room/group)時，WebHook會收到一個join的event(位於第12行)。 接著，你可以試試看在群組中說話: 你會發現，當bot收到你的訊息時，WebHook會收到一個message event(第18行)，其中可以取得說話者的userId(36行)，透過UserId你可以取得該人的個人資訊(35行, GetRoomMemberProfile)，最後回應給群組中所有人(一樣透過Re...

如果你開始使用MS Teams，Incoming WebHook是個不用可惜的簡單機制。 需求是這樣，我們常常在工作上想要在某些事件發生時(例如失火，系統崩潰、訂單爆量…)發生的時候，可以透過手機推播訊息的方式告知大家，而MS Teams中的Channel，本身就有手機App可以接收推送訊息，如果企業有使用免費的MS Teams(只要你有Ｏffice 365)，那沒什麼道理不安裝這個App（因為平時跟同事的溝通、群組討論…都在用才對）… 因此，當事件發生時，把訊息送到Channel中是再合理不過的了。 怎麼實現呢？簡單到不行，首先，請先建立一個連接器(看你要在哪一個channel收到通知，就在哪一個channel裡面建)： 在出現的連接器清單中，找到『Incoming WebHook(傳入WebHook，嘖嘖…翻譯的真好)』： 點選設定後，在接下來出現的畫面中，逐一填入: 最後按下建立，完成後會出現底下這一組URL: 請務必複製該URL，未來你只需要對該URL送出Post訊息，即可把訊息發到該channel，有訂閱該channel的用戶，自然可以在手機App上收到該通知。 例如，當你對WebHook URL送出底下訊息: 用戶會收到: 手機上也會收到通知: 很簡單吧… :)

MS最近推Teams推得很兇，但不知道有多少台灣企業開始使用MS Teams? 如果你也開始用，應該會知道裡面有一個T-Bot，也就是MS teams的bot，它可以擔任一些基礎的引導工作，但也僅此而已。不過，類似Slack一樣，你可以自己開發一個chat bot，掛在MS Teams裡面，做一些日常的查詢功能，例如查詢分機、檢索資料位置、一般員工 Q & A、教育訓練索引、或是更進一步的與ERP整合，來查詢訂單、庫存…等。 而且開發方式極其簡單，只需要透過MS bot framework就可以了，也就是說，IT人員可以透過bot framework，幾乎不用寫什麼code就完成一個可以運行在MS Teams裡面的T-Bot。 你可以先從透過azure建立一個bot開始: 在azure站台中，你可以透過搜尋 bot service找到(上圖)，點選後，請選下圖中的建立: 接著填妥底下的資料，最後按下建立: 完成後，portal會自動跳到底下這樣的設定畫面，請依照您的需要選擇，如果您熟悉C#，您可以不勾選任何項目，以預設的值進行配置: 選擇Next之後，會出現底下畫面： 由於bot framework會需要您建立一個Microsoft App，因此azure portal會透過上圖的畫面引導你建立一個App，最終我們需要得到App Name, AppID與Password這三組資訊，請點選上圖中的Create…，接著，會自動跳出底下這樣的畫面： 系統已經自動為您產生同樣名稱的App，以及所需要的App ID，你只需點選上圖中的藍色按鈕『Generate…』，在接下來出現的畫面中，牢記你的Password(因為只會出現一次)： 記好password之後，按下『Finish…』鈕回到原本的畫面，這時，你要填入剛才記得的密碼即可： 所有的設定完成之後，就會看到底下這個畫面，這表示你的bot已經被自動建立完成，到目前為止我們還沒寫任何一行程式碼： 當你點選上圖物中的這個『→test』鈕，azure portal會出現一個web的測試UI，讓你可以直接跟chat bot對話，當然，目前這個chat bot只會echo，但已經很不錯了。 如果你希望調整chat bot的功能，讓它多做一些事情，你可以點選上圖中的Download zip file下載source code，...