LINE Developer Day 2019 現場筆記 (三) – LINE Bot 與 DevOps

作者： -

前面提過，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撐腰，又有自然語言語意分析加持，其前景很讓人看好。

開發Chat Bot的DevOps自動化

另一個與微軟有關的場次是由Kenichiro Nakamura介紹的How to optimize bot development lifecycle with DevOps，講者是MS的開發人員，同時也是LAE：

主題的內容是開發Bot時的DevOps。

開發Chat Bot也需要DevOps? 當然，在這個時代不管開發麼甚麼，都需要DevOps，Chat Bot當然也是。講者談到了Chat Bot的開發其實更需要DevOps，特別是我們常常有正式、測試環境、為了讓LINE Bot的開發與測試更順暢，一般來說，我們在開發一個LINE Bot時，會特別建立2-3個LINE Bot Account，分別將其設定成Dev/UAT/Production環境。

而Azure WebApp的好處就在這邊體現了，我們可以透過WebApp的Slot機制來做不同的環境佈署。當我們建立了WebApp後，對該WebApp分別建立額外的Dev or UAT Slot，然後針對不同的Slot配置環境參數：

其實這個做法，基本我們在Azure Web App上幾乎是天天上演，算的上是開發Chat Bot的best practice了。然後，再搭配Azure DevOps，來實現自動化CI/CD:

只要在MS的世界中談到DevOps，那毫無懸念的就是採用Azure DevOps，然後LINE Bot的開發可以採用WebApp(不管是Linux based或是Windows based)，以Slot切分出Dev/UAT/Production環境，搭配Azure DevOps的Release Management自動化佈署與簽核功能，在開發人員有任何修改後，自動上版到Dev/UAT環境，待UAT環境的測試人員確認無誤後，可以在portal上按下Approve鈕(上圖右)，就繼續自動上版到Production環境。

這個在MS世界中幾乎算是理所當然、生來就有的流程，在Open Source世界多少還是需要一些環境上的配置，但Azure雲端服務搭配Azure DevOps，基本可以近乎自動的實現上面所有的流程。

有趣的Bot

對我來說，前面介紹的那些不算是特別新鮮的內容，但這位講者一上場，立即就吸引了我的目光…原因是，他帶來了一隻非常有意思的Bot。

開場的第一張投影片，他先請大家掃QR Code加一隻LINE Bot為好友，這隻Bot可以幹嘛呢? 它可以索取當前的投影片：

這是一隻有著Rich Menu的LINE Bot，按下該LINE Bot的Rich Menu，就可以下載講者當前螢幕上撥放的投影片!!!

這有意思，這樣大家就不用拍照了啊~

這對講師超級有用的!

為甚麼呢? 每次我在上課，總是會看到許多學員在底下拍照，可能是覺得某一張投影片相當精彩，所以想要拍照存證留念，但我自己也會坐在底下當學員，這樣拍照出來的品質我清楚的很，有時候實在慘不忍睹。

而且，不是每一個講者都會在會後立即釋出投影片，特別是我，我上課的投影片常常是幾百張裡面的幾十張。因為我會把同樣的主題放在一個.pptx檔案裡面，然後看不同的課程就挑其中一小段來講。因此，我不是很方便把整份投影片都給學員。

但學員常常需要做筆記或是從投影片上摘錄重要的資訊啊，怎麼辦呢? 這就是你常常看到學員在底下拍照的原因了。

現在有了這支Bot超讚的啊。

你只要在台下打開手機，眼睛盯著台上的螢幕，喜歡哪一張投影片，就立即在手機上按一下，那一張投影片就會自動下載到你的手機裡，超完美的啊。我看到這支Bot之後立刻被吸引，第一時間就給他安裝了起來，不過…

開場前10分鐘還可以用…後來似乎就…掛了。

發生了什麼事情嗎? 當下我不知道，但不管如何，這個Bot太讓人驚艷了，我立刻下定決心，我回台北之後要自己做一個出來玩。

發生了什麼?

後來，我跟講者聯繫上，請教了他是怎麼實現這個Bot的。他告訴我，基本上是採用了MS Office的VSTO開發技術，透過設計一個外掛(Add-Ins)，在PowerPoint的 “下一頁” Event上，做一些動作，把當前的投影片位置提供給Bot的WebAPI(底下是講者blog上的介紹):

而到底當下究竟發生了什麼? 導致現場Bot有問題的呢? 這個故事你可以看底下講者的Blog，有現場報導般的說明:

在LINE Developer Day 2019通過LINE bot分發PowerPoint幻燈片的故事

你會發現，這個故事的主角不僅僅是這支Bot，還包含了講者開發這支Bot的過程，以及他如何使用Azure DevOps做開發的版控與rollback，是個非常精彩的故事。

這整個故事讓這場研討會變的很有意思，講者用自身的LINE Bot開發DevOps經驗，來講在開發LINE Bot時候DevOps扮演了如何重要的角色。不只是過程吸引人，產出的Bot也非常吸引人…

後記

從看到那隻Bot的那一天開始，一直到我回台灣，我始終對那隻LINE Bot念念不忘。終於，我找了一個周末的下午，在自己的環境重新開發了一隻類似的Bot，我改變了做法，在PowerPoint的VSTO當中，Hook 投影片播放的下一頁事件，在該事件發生時，再抓取當前的投影片，然後以非同步的方式上傳到Imgur圖床，並且把該位置丟給LINE Bot的WebAPI。

此時，只要有任何用戶按下Rich Menu上抓取當前投影片的按鈕，LINE Bot就會將該圖片下載到用戶手機上，完成當前投影片下載的任務…

哈，非常完美，下一次，換我帶給學員surprise～

LINE Developer Day 2019 現場筆記 (一) - 看見LINE、開發者、未來
LINE Developer Day 2019 現場筆記 (二) - 關於LIFF的改變與未來

留言

Eng Soon Cheah寫道…
在Microsoft Ignite 就有 BotFramework-Composer(Preview) Release Workshop 了。
2019年12月3日 下午5:09
Unknown寫道…
Cool 最後的Bot有創意，果然科技始終來自需求~
2019年12月3日 晚上11:00
張貼留言

這個網誌中的熱門文章

在POC或迷你專案中使用 LiteDB

作者： -
圖片
3/24，我發了篇FB 貼文 ，提到我很久沒有在撰寫範例的時候使用關聯式資料庫了。這不是因為關聯式資料庫不好，而是使用場景和情境的問題。 大部分的教學文章或範例，為求讓主題專注不要失焦，我會讓範例盡可能地簡單。例如，用Console App 取代 Web 架構，用file取代DB。這樣學員的進入障礙會再降低一點，畢竟，我們不能假設每一位學員都對MVC框架或是資料庫存取的ORM有認識。 那篇貼文得到不少迴響，其中有位讀者建議，也可以考慮用 LiteDB ，我當時回覆說我會找個時間來試試看。既然說了出口，肯定是必須要測試一下的。 LiteDB 技術上來說，LiteDB 是一個嵌入式的 NoSQL 資料庫，特別是針對 .NET 開發者設計。其本質上是一個檔案，但它提供了類似於傳統關聯式資料庫管理系統的功能，包括存儲、檢索、更新和刪除資料操作。LiteDB 以單一檔案的形式儲存在專案資料夾中，這使得它非常適合於輕量級應用。不管是desktop app、mobile app或任何需要資料庫但又不希望安裝重量級資料庫伺服器的情境，都很適合。 你只需要針對專案安裝 NuGet 套件就可以使用： dotnet add package LiteDB 不需要伺服器、不用管帳號密碼、可以跨平台，所有的資料都存儲在單一檔案，便於管理和分發、佈署。簡單的說，當我寫好範例，在裡面放一些資料，丟上GitHub，你不管在哪一個平台(Windows, Linux)，Clone下來之後，無須任何配置、設定，就可使用，資料也不會消失，無須重建。 確實，這對做範例非常方便。 你可以看看我在GitHub上的這個範例： git clone https://github.com/isdaviddong/TestLiteDB.git 下載下來之後，無須任何設定，直接 dotnet run 就可以執行： 專案中，包含了一個MyData.db檔案，就是資料庫實際儲存的位置： 你可以透過底下這樣的程式碼，即可使用： var db = new LiteDatabase ( "MyData.db" ) var col = db . GetCollection < Person > ( "persons" ) ; 其
Read more »

使用Qdrant向量資料庫實作語意相似度比對

作者： -
圖片
什麼是向量資料庫? 在許多的AI實作當中，都有向量資料庫的使用需求。例如RAG(檢索增強生成)、或是資料的相關性比對、相似性搜尋…等，這些應用情境中，我們都會用到向量資料庫。 向量資料庫主要的任務，當然就是存儲和查詢向量數據。被儲存的向量數據通常是高維度的資料，以陣列(集合)的形式呈現。 例如，OpenAI就有提供一組Embedding API，讓我們可以把文字給向量化。你可以透過該 API，把一句話(一段文字)轉換成向量數據，類似底下這樣： OpenAI 的這組 Embedding API，在預設狀況下，會把資料轉成 1536 維度的向量數據，其背後的行為是把文字送給一個訓練好的模型，透過該模型跑出這組向量數據，再回傳給用戶。 然而，把一段文字給向量化的目的是什麼呢? 當我們把文字做了這種轉換後，在 1536 維度的座標空間(向量數據)中，愈相似的文字，透過Embedding API會得到距離愈接近的座標點，藉此，我們得以迅速的判斷兩段文字在語意上的相似性。 而向量資料庫中所謂的查詢功能，主要就是向量的檢索，像是『近鄰搜索（Nearest Neighbor Search）』，當用戶或應用程式提交一個向量查詢時，向量資料庫會幫我們找出資料庫中，與之最相似(接近)的向量座標點。 因此，開發人員只需要透過 Embedding API，把文字轉成向量，再把轉換好的向量座標值，儲存到向量資料庫之中，未來就可以透過向量資料庫來查詢相似(接近)的文字。 關於這個部分，如果讀者有興趣，前陣子有段網路上的影片把多維度向量資料庫的概念介紹的蠻清楚的: https://www.youtube.com/watch?v=W_ZUUDJsUtA https://www.youtube.com/watch?v=ct20Kv8yn0U 為何需要? 向量資料庫最實務上的應用，就是找到類似的特徵值。 例如，當我們把人臉的特徵值以向量資料的形式儲存到向量資料庫中之後，我們就可以透過資料庫本身提供的搜尋功能，快速地尋找出相似的人臉，這也是許多AI應用實現的基礎。 我們底下的程式碼範例，則是找出最接近的問題。(呃…什麼意思?🤔 請往下繼續看) 我們在建立對談機器人時候，常常需要讓機器人回答用戶的問題。這時，我們會讓用戶輸入問句，然後透過 Embedding API
Read more »

專業的價值...

作者： -
圖片
每次，我去修車的時候... 師傅說：先生你這車開那麼久了，這樣壞很正常拉，你要不要換台新的? 你不知道零件會老化嗎??? 我：是是是...那，這零件換掉要多少錢??? 師傅：喔...便宜啦，大概就XX萬就可以了... 每次，我去客戶那邊... 我說：大哥，這軟體我們用那麼多年了，總是會需要調整維護一下的... 客戶：是你們一開始沒有設計好吧? 我說：不是啦，技術總是會更新的，而且現在有一些新的需求...恩，大概，就收你XX萬就好了... 客戶：什麼? 你們當初沒設計好的東西，還想要加收錢??? -------------------------------------------------------------------------   我相信上面這樣的情況你一定和我一樣常碰到，我不知道有多少次，被修車廠唬的一愣一愣的，但我總是心甘情願地掏錢出來(好吧，我有點心不甘情不願，但我沒得選擇)。   有一次，我的動力方向盤打起來卡卡的，好像快不能正常轉向了，所以我立刻把車開到保養廠，師傅熱情的出來迎接我，問我車哪裡有問題，我描述狀況，接著師傅就把車開走了。剛好這時候我接到一通電話，我在講電話的同時，師傅把車弄好了(不到五分鐘)，跟我說，這個動力方向盤的油沒了，要補充，打折後收我一千多塊，我趕緊謝謝他。   離廠前，師傅把剩下的動力方向盤油給我(很有良心)，說：這是剩下的。我還沒反應過來，他就說：老闆，慢走，開車小心，注意安全。(好貼心的師傅)   我看了一下，那罐動力方向盤油只加了1/5，剩下4/5我要怎麼辦?放後車廂? 等他漏了再加? 我不知道!!! 他為何不乾脆 免費 幫我加一下呢? 像這樣類似的例子我碰過非常非常多(因為我的車老了，很多問題)   也有很多次，我明顯發現修車廠的人在唬爛我，但我換過很多家、原廠、副廠、出去玩的時候在風景區的修車廠(這更狠，擺明了就是要坑你，他清楚知道只會跟你做一次生意)，幾乎都一樣，我常常有被唬弄的感覺。我想要跟著車看他怎麼修，修車廠的師傅總是說：『老闆，您可以到休息室等一下，不會那麼快喔!!!』   對照先前我在軟體社群看到有位朋友寫的一篇 文章 ，提到了軟體工程師的無奈和心酸，我其實很想說，軟體工程師大部分真的都太古意了!!!!   從商人的角度來看，每一次免費的服務，其
Read more »

使用 Airtable 在小型需求上取代傳統資料庫

作者： -
圖片
我好幾年沒有用傳統的關聯式資料庫了。 老實說，傳統的關聯式資料庫，其實對於教育訓練和小型的專案來說，是一種負擔。 如果你想讓學員清楚的掌握一門技術，就好比說，對談機器人的開發吧，在整個教學的過程中，若是範例用到SQL或MySQL資料庫，無疑是一種節外生枝，把問題變得更複雜。因為，在對談機器人當中，儲存只是一種迫不得已的額外需求，是枝微末節，而非對談機器人技術的主體。 同樣的，如果你做一個小型專案或POC的話，『儲存』也往往不是重點，儲存只是『必要之惡』。其實，若是從這個角度廣義的來說，軟體開發的GUI、資料庫，都只是細節(枝微末節)，都應該要是可以隨時被抽換或取代的部分，而非系統核心。 一套軟體或解決方案的真正核心，是商業邏輯。它(商業邏輯)才是一個應用程式真正展現價值的部分。 我們把主題拉回來。所以，我最近這幾年在上課的時候，盡量不讓範例程式碼涉及資料庫存取，特別是關聯式資料庫的存取。因為這對讀者或學員來說，變成了另一種必須學習的負擔。 但說的容易，如果範例中有碰到需要儲存資料的時候該怎麼辦呢? 有沒有什麼最簡單的儲存機制可以在程式碼中替代傳統資料庫? 這也是我最近幾年寫範例的時候，常常碰到的問題。因此，我特別花了一段時間，找看看有沒有什麼好用的『類』資料庫儲存體? 最後，我選擇了 Airtable。 Airtable Airtable 是一個靈活的雲端資料庫產品，結合了資料庫的功能和電子表格(data grid)的簡易性。它允許用戶以視覺化的方式存儲、組織和協作各種資訊： 白話一點說，就是它可以很自由的在Web畫面上設計欄位和維護(輸入、編輯)資料。 對我來說，它還有另一個重點，就是它擁有非常簡單的REST API，透過呼叫API就可以直接來讀寫資料。 它的API在使用上很簡單，只需要在設計好資料表之後，透過 https://airtable.com/create/tokens 站台建立一個 PAT(Personal Access Token): 建立PAT的時候，可以選擇要針對所有資料表，還是特定資料表，要只給這個token 讀取(Read)權限，還是要寫入(Write)權限： 有了token之後，可以透過很標準的REST API呼叫，進行連線的建立與資料的寫入： string ID = "👉air_tabl
Read more »

周末讀書會 - 一如既往

作者： -
圖片
一般來說，我都是看完整本書之後，才會決定要不要推薦，能讓我還沒看完就忍不住推薦的書極少。 但『一如既往』，就是這極少中的之一。 這本書的主題很難界定，你既可以說它是在談投資、也可以說他在談經營或企管、有些內容說的是競爭、但有時候你會覺得他講的是人生。 然而重點在於，這本書寫得非常好看。 我超愛的科幻小說家倪匡，曾說過：『好看的小說非常簡單，必定要有豐富的情節、鮮活的人物，小說寫得不好看，裏面有再多的學問、道理、藝術價值，都沒有用。』 一如既往，這本書的作者厲害之處，就是他能夠把每一篇都寫得環環相扣、異常好看，然而即便我知道每篇文章的pattern，想要模仿也是很難(這是個苦功來著)。 基本上那個pattern就是…以引人入勝的故事開頭，使用對照法讓故事撐托出主題，以極具說服力的文字或數據讓主題凸顯出價值，讓讀者有所收穫，最後在最短的文字內把一篇文章總結，然後預告下一篇作者想要接著談論什麼。 就這樣，你會一篇接著一篇，不由自主的閱讀下去，每一篇，你都會有一些驚訝、會有一些省思、接著會有一些take a way。 整本書，看似信手拈來、行雲流水，一氣呵成。但我知道，這是精心設計與編排後的結果。 一本書，最要緊是好看。 好看，讓人讀得下去，裡面豐富的內容才對身為讀者的你有意義。 『一如既往』這本書做到了，而且做得很徹底。 我快看完了，看完之後，如果有時間，我還想針對裡面某幾篇特別分享，如果你等不及，不妨先找來看看。
Read more »