忍者工坊
0%

發表於 更新於 分類於

Armeria: A Microservice Framework Well-suited Everywhere

前言

大家好我是 Chatbot Developer Taiwan - NiJia，很開心這次能夠以 LINE API Expert 的身份被邀請來參加 LINE Developer Day 2019。

本次議程是由韓國的 open source manager - trustin 為我們帶來議程。

而在今年參加八月舉辦的 COSCUP，並且在第一天的 after party 參加 LINE BoF 上就已經看到 LINE 開發的 Open Source - Armeria，它是基於 Java 所撰寫的一個非同步的專案，支援 Java8, Netty, HTTP/2, Thrift 以及 gRPC，當時聽團隊簡單介紹就覺得這個專案一定是個很不得的專案，只不過當時因為他們快速介紹兒少聽了很多細節，這次就把我聽到的細節告訴各位吧！

據之前的議程的以及講者的分享說這個服務已經被應用於很多 LINE 服務裡頭，因為覺得好用才推出來🤣

如何讓開發者快速使用 Armeria

接下來就用 Java code 來簡單火力展示如何用一個串聯式寫法把服務互叫起來，不管是要用什麼服務只要用串接的方式加入即可，像是 gRPC、Thrift、annotation…等等如下面幾張圖所示。

這邊看到可以這麼簡單就把一個服務叫起來，然後要讓他開發者可以很輕易地理解並上手，LINE 團隊的開發文化真的是令人佩服…

為什麼要做成 async 以及 reactive

首先就先提到若 Queue 裡頭的東西若是都 sync 的話會有什麼問題，這邊就以一個 Call API 常遇到的問題 - Timeout，在大量的 Queue 在排隊時，以 sync 的方式存在時光遇到 Timeout 就會有服務器爆炸的問題，因為彼此不能影響彼此，且這件事會發生在真實世界的每個地方。

這邊講者提出的解決方案為：

  • 增加執行緒的標記(#)並且減少呼叫堆疊(stack)
  • 預準備 Tread pools 讓大家互相共享
  • 少調用 points
  • 使用非同步的好處就是能夠平行呼叫+較少的執行緒

現在他們能用非同步的方式解決系統被鎖住的問題，但今天若遇到一個很肥～的 payload 呢？以範例來說若一個用戶送他 10 MB 的大小，一次送給 100K 個用戶就相當於 1 TB 大小的流量。

這邊使用的方法是用不同的頻寬 & 處理能力，並且只需要足夠的 buffer 來排除 Out of Memory 的錯誤。

聽到這邊看起來是使用相關的工具來讓整個串接服務可以更有效的 Debug，最後透過 Kibana 來讓訊息可視化，讓 Debug 可以更加快速。

若對相關 Debug 工具可以參考我之前寫的 Sentry 文章

Kibana 可參考： 安裝 ElasticSearch + Kibana 實現中文全文搜尋與數據分析

結論

經過了講者一連串的火力展示後感受到 LINE 對於 open source 有多麽的重視，連 Slack 也都愛上 Armeria 這套 Java 函式庫，用於他們的軟體中並公開推薦，讓像我這種喜歡做 open source 的工程師可以燃起新希望繼續為開源做努力。

其實還有很多技術細節的部分在簡報裡，這邊我就不再多家贅述，大家可以參考 GitHub，裡面有更加詳細的用法提供給大家。

這次來 LINE Developer Day 讓我感受到不同於其他大公司的文化，除了精彩的議程外也招待我們這群 LINE API Expert 前來共襄盛舉，若你也想成為 LINE API Expert，不妨拿著你的貢獻來申請看看連結，或許明年我們就能一起去啦！

或是你想面對面直接問問看，也可以來 Chatbot Taiwan 參加我們一個月一次的社群聚會喔！我們時常會邀請 LINE 的資深技術傳教士 - Evan 來為各位帶來第一手 LINE 的資訊，也許可以跟他詢問看看，或許會有意外的收穫喔！

發表於 更新於 分類於

How we continuously delivery LINE TODAY App with high agility and high quality

簡報連結: URL

前言

大家好我是 Chatbot Developer Taiwan - NiJia，很開心這次能夠以 LINE API Expert 的身份被邀請來參加 LINE Developer Day 2019。

這個議程是難得出現的台灣人，一開始只是想說聽看看 LINE TODAY 是如何透過維持高度敏捷以及保持高品質，其實也就是瞎子摸象，結果聽到自我介紹後發現是台灣人來講，感覺就是在異地聽到一個台灣味的口音覺得很親切🤣

接下來就看一下我聽完這場的心得吧!

負責專案

  • LINE
  • LINE TODAY
  • LINE SDK
  • LINE MUSIC(Taiwan)

    最近常常出現在左上角的那個 LINE MUSIC

流程

從 Pull Request - Code review - Build pipeline - unit test - UI test - deploy

當中提到兩個主要部分：

  • Unit test: 覆蓋率最好要多少？
  • UI test: 自動化測試的可信度？


且在測試當中會有一種測試叫做 flaky test，有時候測試有過、有時候有沒過，完全讓人摸不著頭緒的測試，這會傷害到軟體品質以及覆蓋率，因此若這種狀況出現時趕快號招團隊的人來討論這個狀態是否處理。

flaky test

UI 自動化測試

在這部分提到說 UI test code 好寫但是難去維護，主要在於 UI 的東西可能會因為裝置、作業系統…等等的問題去影響到，且會很容易出現 flaky test，這邊我詢問講者得到的答案是測試只要確認在當前 UI 上最重要的元件若有出來的話這部分的測試就給過，若太精細的測試時常會影響到整體的開發敏捷度與流暢度。

想想也是有道理，平常聽到人家說測試測試的，只是當今天測試時的究竟是要到多詳細還是要取決於團隊的決定。

這段講者有提到要注意 UI Automation test 是 Smoke test，因此要注意維護成本以及flaky test的問題！

驗收標準 - Acceptance Criteria

接著就提到團隊需要準備各種情境所需要的東西：

  • 不一樣的測試資料來讓產品有彈性且是可信賴
  • 若有針對類似 Database 這類的測試團隊則更需要去注意測試細節避免導致特異情況
    總之就是 Product Owner(PO) 是需要訂定團隊規則並讓大家去遵守，確保品質！


這裡有提到他們經由上述制定好的驗收標準之後，隨著 Release 版本之後的手動測試比率逐漸減少，到後來都是偏向自動化測試去處理，且是有團隊可信度。

Code Coverage

這邊以 iOS 開發為例，首先就是 MVC 框架上所遇到的問題，官網都是以 MVC 下去做範例，但實際上開發起來則是還得以 MVVM 的框架去執行在測試的部分才不會採太多不必要的坑。

接下來提到的部分我覺得是這個議程最重要的一部分，就是如何去取捨覆蓋範圍，像是上圖顯示，可能會有一些 Callback 或是其他的是不可預期的範圍，團隊需要將這些問題一一列出來討論，並且去制定一個最低標準以及 Must have 的標準，促使團隊可以更有規則的去進行開發，如下圖所示。

結論

其實一家公司很願意花成本去讓開發者可以去寫各種測試確認服務品質，若是以普遍環境來說這真的是很難人可貴的地方，此外從中也了解到一個好的流程應該是如何，從談需求到開發中間所要經歷過多少事才能讓一個服務起來，測試這部分真的是很大的一門學問，千萬別寫一堆測試但這個測試只是自己測開心的，而是要讓測試的內容可以讓團隊很放心的將 code 交給測試去驗證，達到這樣子目的的程式我相信在市場上一定是很能接受考驗的！

發表於 更新於 分類於

Seamless device migration using LINE secure backup

簡報連結: LINE Dev Day 2019

前言

大家好我是 Chatbot Developer Taiwan - NiJia，這次被 LINE 邀請來參加 LINE Developer Day 2019。
經由 每位負責人的 Keynote 開場完後就是會眾們開始聽議程的時候了，我選擇跟資安相關的主題來開始我今日的第一場議程，想想在接觸資安時還是大學時期呢(遠望)。

心得

開場不免俗的一定是要自我介紹並說主要大綱，講者本身為一個駭客並是 Side-Channel Marvels 成員之一，在 GitHub 上坐了一個逆向工程的工具 - QBDI。而作為一個 Hacker 破壞當然對他們來說是相對簡單，但換個方向來看，就是透過滲透測試來建立更完整的服務內容，的確在真實世界上要摧毀一個服務是相對容易的！

但講者是在 LINE 這種規模較大的公司裡做滲透測試，在滲透後做完測試報告時需要顧慮到其他開發團隊的工作時程問題，也許這個漏洞在實際服務運轉上的容錯率是相對高的話，就可以讓開發團隊安排時程去修補漏洞而避免延遲產品上線時間。

這邊主要提到一些 加密協定原則 以及傳統訊息傳送都是怎麼做。

接著說到帳號轉移裝置時的問題，今天要從舊的裝置備份到新裝置時，若透過 Server 的話他只有加密過後的資料，如此一來根本無法備份過去，而 end-to-end 的備份的話會遇到以下問題：

  • 會受到各種通訊協定的問題(wifi, Bluetooth, NFC…)
  • ios - andriod 不同裝置相容性問題
  • 需要重新建構訊息模型
  • 要怎麼處理來自 parameter 的攻擊
    • Hacker 透過中間人攻擊
    • 會透過各種狀態來找尋漏洞 (BGP, DNS, Certificate PKI…)

UX x Security

前面簡單介紹一些備份上的問題以裝置間的問題，接下來就進入如何在最好的使用者體驗上並擁有資訊安全：

若要最好的使用者體驗 - Best UX

流程

  • ✅不需要在意裝置間的問題
  • ❌會被駭客透過中間人攻擊去塞有問題的資料
  • ❌安全層級等於零

這樣公司就不用運作啦 (笑)

最安全的等級但最差的 UX

Best security

  • ✅Private key 加密過並且擁有最難破解的密碼
  • ❌使用者根本記不得這密碼
  • ❌密碼過於複雜

這邊講者有補充若是只有六位數的密碼他大概有 一百萬 種可能性，可以透過暴力破解的方式就解決，且有大約 10% 的密碼是重覆性很高的，因此還是建議擁有大小寫以及特殊符號是相對好！

每天都會有弱密碼出現於生活中

  • combination padlock
    • 硬體設備都用很弱的加密協定
  • Banking card PIN
    • 很容易出現像是 生日 這類的密碼
  • smart phone lock screen
    • 使用者求快
    • ARM trustZone / apple secure

Server Side 相關相關加密元件

HSM in backups

接著就介紹是如何透過 HSM 的硬體元件來處理備份資料資安的問題

透過硬體(HSM)來幫忙加密確保每一段上傳下載都是安全且可加解密，使用者在這過程中也不需要輸入一大串的密碼就只顧及資訊安全而放棄 UX，而在 HSM 當中會將私鑰安全的存下來，不用擔心會有被攔取之類的問題。

由於 HSM 經過雙重加密認證達到資訊安全且是安全的儲存下來，因此不會因為被抓到之後就馬上被解開，確保整個資料傳遞上的安全性。


上圖則為 HSM 簽證公鑰的註冊流程，經由一連串的加密把它存成二進制 source code，且裝置還是能使用 public key 來解開這個二進制檔案，如此一來在備份到新裝置上就不用擔心整包資料的安全性了！

結論

我們在實作的網站在沒什麼流量時都不太需要注意資安相關，但當系統請求越來越大或是有金流時在每段的加解密終究都相對重要很多，且在建立 UX 以及 Security 之間要如何平衡也是個重要的議題，如同講者說的，在做這些技術的同時且站在巨人的肩膀上(LINE)對於白帽駭客的成就感是源源不絕的，能夠透過滲透來讓我們每天在用的東西更加完整也是很棒的一個作法😊。

而過往在聽駭客朋友們在聊都是在講 WAF 較多是在講 Web application 相關的，這次聽到的 HSM 功能看起來雖然很相似，但看來是叫專注在資料的加解密當中，或許當中應該還有更深入的功能還未提到，透過這個議程認識到新的東西也是一大收穫😁。

發表於 更新於 分類於

前言

大家好，我是 Chatbot TW 的 NiJia

當產品開發完上線後難免會遇到可能是邏輯上的 Bug、例外錯誤或是想記錄使用上的錯誤，當沒有工具時都只能等錯誤出來時乖乖的去翻 Log 找問題，對於每次出錯要 Debug 的我就覺得很困擾 😭。

公司強者寫 APP 的同事他們都很開心的在使用 Crashlytics 幫他們將 APP 出問題時將錯誤訊息丟上去，看了實在時羨慕，但那們寫 Web 的朋友要怎麼辦！

最近就發現了Sentry這個玩意兒(應該是有段時間的產品了)，支援了幾乎支持現在市場上主流的各種框架以及語言，且串接上也都很簡單就能實現，文件也都清楚解釋每個 API 的功能如何使用，以下就來介紹如何使用它吧 😎

這邊顯示較常用的語言，還有支援很多其他種類的框架及語言

說明

如何使用

首先先到 https://sentry.io/welcome/ Get start

這邊可以整合了GitHub或者Azure DevOps兩種 OAuth 的登入方式

接著就照著步驟來囉！

選擇自己所使用的語言，這邊我使用 Flask(python) 框架來實作

接著官方會有個簡單的文件告訴你要如何實作這塊，這邊就先使用pip在本地安裝套件

1
pip install --upgrade "sentry-sdk[flask]==0.13.2"

若是使用雲端服務的話需要將sentry-sdk[flask]==0.13.2放入 requirements.txt 中

將以下 init code 放入 api.py 裡，在 app = Flask(__name__) 之前

這邊我將 Sentry 的 DSN 放入 .env 裡，若有參考這部分的朋友需要注意環境變數的地方喔！

1
2
3
4
5
6
7
import sentry_sdk
from sentry_sdk.integrations.flask import FlaskIntegration

sentry_sdk.init(
    dsn=os.environ.get('SENTRY_DSN'),
    integrations=[FlaskIntegration()]
)

接著就開始丟錯誤上去看看狀態，我的專案上是串著 LINE Bot，功能只是當個應聲蟲，在這情況下只需要丟個貼圖給它就會出錯。

當錯誤丟出來之後原本監聽的紅色燈號就會打勾囉 ✅

Sentry 預設都會寄信通知，所以若有錯誤記得看信箱哦！

點進去後就可以很清楚的看到程式是錯在第幾行，寫到這有種莫名的感動，平常都是在 LOG 海裡找看看到底報錯在哪邊，終於有個地方能幫我接下來了 🎉

到這邊基本串接已經完成了，但身為免費導向的工程師怎麼能讓 5000/月 限制我！接下來就要去過濾一下來的錯誤內容，若不是系統造成的錯誤就不上傳。

我選擇判斷 Log 達到Waring或是Internal就回報，並照著官方的指示新增以下內容:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
import sentry_sdk
from sentry_sdk.integrations.flask import FlaskIntegration
+ import logging
+ from http.client import HTTPException
+ from sentry_sdk.integrations.logging import LoggingIntegration


+ def strip_sensitive_data(event, hint):
+     if "exc_info" in hint:
+         instance = hint['exc_info'][1]
+         if isinstance(instance, HTTPException) and instance.code < 500:
+             return None
+     return event


+ sentry_logging = LoggingIntegration(
+     level=logging.INFO,
+     event_level=logging.WARNING
+ )

sentry_sdk.init(
    dsn=os.environ.get('SENTRY_DSN'),
+    before_send=strip_sensitive_data,
+    integrations=[FlaskIntegration(), sentry_logging]
)
  • strip_sensitive_data: 過濾來自 Http 的 Exception 錯誤碼是否大於500，否則不回傳。
  • sentry_logging: 使用 SDK 的 LoggingIntegration 來定義 log 回傳事件時的層級到哪層才上傳錯誤訊息，這邊我設定Waring等級，並加入到 init 的 integrations 裡。

此時不管你打上都會將訊息送上 Sentry：

1
2
logging.waring("i am waring")
logging.error("i am error")

或者是

1
raise InternalServerError("Hi Error")

或者！！自己手殘讓程式崩潰也會送通知

到這基本上已經完成串接完成並能過濾錯誤訊息，接下來則為將服務串至 Slack 上。

Slack bot 串接

首先來到Settings按下Integrations會看到以下畫面，並安裝一下Slack

接著就要跟 Slack 連動囉

連動完成後再按下configure來設定以下內容

到了Alerts頁面後就開始設定以下內容囉，這部分參考官方文件

可以指定透過哪個group去傳送至哪個tag，我就直接送到預設的#general

測試就直接送出貼圖來讓 bot 報錯，結果就收到key的錯誤啦～

結論

最後就能透過sls deploy將專案部署到 AWS 上，透過這次的紀錄對 Sentry SDK 運作在框架上的問題更加了解，同時也找到了一個不僅可以紀錄錯誤還能通知我錯誤訊息的地方，可以在第一時間直接進去分析 log，若完成了可以直接在 slack 上按Reslove來完成這個 issue。

本來有在考慮要串接LINE Notify，不過看著 Sentry 對 Slack 的整合比較好，也就放棄了這個念頭了 🤣，但串接哪個平台其實就看公司的需求，Sentry 一樣可以透過 webhook 將錯誤訊息傳至 Server。

此外它一樣可以整合Github、GitLab、Azure DevOps…等等，若錯誤處理好的話可以讓 Sentry 幫你送 Issue 上去，不僅整個超炫砲 😎，若是 open source 的專案也可以大家一起去修這個問題，真的是一舉兩得啊！！！

發表於 更新於 分類於

前言

如果還不知道 Serverless (以下簡稱 sls )的朋友可以先看我上篇文章，裡頭有介紹 Python 以及 Ruby 的範例。
還沒接觸 Serverless 之前，當開發完一包程式時就將它部署至 Heroku，實在是有夠方便又快速(還是免費的)。不過有個問題是當程式沒在運行時他會睡覺，身為一個免費仔做的小專案這樣是夠的，做為一個貪心的免費仔怎能容許睡覺睡這麼久 🤤！但若是照著我上篇分享的文章做，佈署程式沒問題，但就開發機器人我都要佈署才能測試，這未免也太不人性了 😒。

閱讀全文 »

發表於 更新於 分類於

前言

Serverless 架構是一個基於 FaaS(Function as a Service) 實作的一個服務，讓開發者可以更專注在開發功能，將 yml 檔設定好其餘維運的問題都交給 AWS、Google、Azure 這些服務商去處理，只要把信用卡準備好就好(?)，讓開發者在寫完程式之後不用煩惱部署得問題，減少的不少的麻煩事。
那因為現任公司的服務都是基於 AWS，如此這般我就接觸到 Serverless(以下簡稱 sls) 這個框架啦 (想更深入了解 FaaS 架構可以參考 AWS)
[2019/07/04 更新]
若已經暸解的朋友可以參考我的 python 版本:
louis70109/aws-line-echo-bot
Ruby 的範例版本:
louis70109/aws-ruby-line-echo-bot

為什麼要 Serverless

[2019/06/29 更新]
以用一個 Ruby on Rails 寫的機器人為例，在寫完個 webhook function 後，設定路由然後部署，一般主機或是虛擬機就很麻煩，要安裝佈署環境以及一安裝堆相關套件，完了之後設定 Domain 什麼的有夠花時間。但若是使用 heroku 部署就很方便，Login — Create-Deploy 馬上就結束，機器人馬上就上線了，實在是俗又大碗呀～
但我覺得像是 LINE Message 這種 stateless 的服務，且只要一個 function + route 就能實作的程式最適合 Serverless 了，讓專案可以簡潔有力，只要寫一個 function+yml 設定並打個指令就部署了，而且 domain 還附贈 SSL，將服務交給 AWS 也不需要擔心，整個就是超級方便啊！
Cold start time 問題，依照我目前使用的結果下來，在 heroku 以及 AWS Lambda 同時睡著的情況下，AWS 起床的回應速度大概 1 秒左右，而 heroku 則大概落在 10~15 秒(參考)。如下圖所示的免費方案，基本上開發階段應該是不至於到 100 萬/月 個請求吧 😆，所以這部分就別擔新大力地給他用下去～ (感謝 petertc 幫忙找這方面的問題 💪)

AWS Lambda 免費方案
接下來就讓我介紹如何使用 sls + LINE Message API 建立一個 Echo bot 吧！

環境

npm 6.9.0
python 3.7.3
serverless 1.45.1

建立 AWS 存取金鑰

首先要先有個 AWS 帳號(廢話) ，如果沒有綁定信用卡記得去綁定才能繼續，接下來就可以去就可以去建立鑰匙囉！

如上圖，按下紅色框框的部分，接著按箭頭指的按鈕，就會建立一個我們要的金鑰囉！
AWS secret & ID key

如上圖所示，可以下載 key，AWS 不會幫忙保存 Secret key，若這視窗關掉的話 key 就不見了，所以使用者可以自行下載檔案保存，以免哪天要部署的時候找不到 key。
接著就將這兩個參數加入環境變數中：

1
2
export AWS_ACCESS_KEY_ID=<your-key-here>
export AWS_SECRET_ACCESS_KEY=<your-secret-key-here>

Serverless 建立與部署

首先先透過以下指令讓 npm 幫忙安裝 sls 的指令。

1
npm install serverless -g

安裝完之後就透過 sls 指令來建立專案嚕！

1
serverless create — template aws-python — path aws-line-echo-bot

severless 指令可以縮寫成 sls
template = 想用什麼平台以及語言就在此模板了 (參考)
path = 檔案名稱


透過 severless 建立專案指令
依照不同的 template 可能會建立 N 個檔案，但主要還是以下三個檔案

1
2
3
.gitignore
handler.py = 主程式的地方
serverless.yml = 所有設定都在這裡，funtion 參數會對應到指定的路由

在部署前須至 serverless.yml 裡，把 runtime 的 python2.7 改至 3.7，否則會因版本問題導致錯誤。

1
serverless deploy # sls deploy

Serverless 部署畫面

接著到 AWS Lambda 以及 S3 就可以看到第一次部署完的程式以及檔案囉！

加入 LINE Message API

既然是寫 python，那一定是要用 line-python-sdk
照著官方用法應該是要執行以下指令安裝套件

1
pip install line-bot-sdk

不過我們是要部署到 AWS 的 Lambda 上，且因為他是無伺服器運算的服務，所以他沒辦法跑 pip 去幫我安裝套件。
此時就要出動 requirements.txt 來管理相依套件 ，但只有加入它 sls 根本不認識，因此我們需要安裝 pulgin 來讓 sls 認得(requirements.txt)。

1
sls plugin install -n serverless-python-requirements

安裝指令 & package.json
如圖，安裝過程中會自動建立 package.json，且會幫忙在 serverless.yml 裡面加入 pulgin，這樣 sls 在部署時就認得 requirements.txt 囉！
接著將 LINE SDK 加入 requirements.txt， AWS 就會幫忙安裝套件了。

1
echo "line-bot-sdk==1.12.1" > requirements.txt

然後新增一個 setup.cfg 並加入以下內容：

1
2
[install]
prefix=

由於 AWS Lambda 上都會將套件安裝在本地端(Lambda 上)，因此在執行 pip install -t . -r requirements.txt 時會需要 setup.cfg。
至於詳細原因嘛～還有請各位大大幫小弟解答 🙏
最後就處理 handler.py 以及 serverless.yml 囉！
將上述兩個 gist 分別貼到自己的 handler.py & serverless.yml，在 hanlder.py 裡的 CHANNEL KEY & TOKEN 記得換成自己的機器人 👾 哦！
佈屬完狀態
接著在執行一次 sls deploy，將程式部署上去，如上圖所示，在 endpoints 那行會有一個網址，將那網址放到 LINE Webhook URL 上並 Verify 看看有沒有成功，如下圖所示。

最後對著自己的機器人發個話，看他有沒有回應你一模一樣的文字，若成功了就能往下一步應用層繼續開發囉！若失敗了就要檢查一下是不是有哪個步驟做錯了～

結論

因為公司的緣故讓我能夠接觸到這神奇的 Serverless，經過這次的分享加深我對於 FaaS 的架構更加了熟悉，由於我也是初碰，我認為使用上可以把它當作是一個 Docker 的容器或許概念上會比較好理解，後續還有很多的設定檔都還沒詳細研究，最近讓我先研究研究一下再上來分享。

文章中有任何勘誤歡迎指正

如果覺得這篇文章有幫助的話請給我個掌聲鼓勵我一下 👋
下列是我的這次實作的專案，如果有幫助也來顆星星吧！
louis70109/aws-line-echo-bot

參考

發表於 更新於 分類於

前言

大家好，我是 NiJia，很榮幸被邀…是本來就負責 Chatbot meetup 的 Co-organizer，連續兩天參加了 meetup 真的是揮灑自己熱情兩邊跑(好 High)，希望藉由社群的分享讓大家可以吸收到不同的新知！

這次活動場地感謝 溫明輝 教授幫 chatbot 借了台北商業大學的場地，而台北商業大學最近有跟 LINE PROTOSTAR 聯合舉辦了 ”LINE Chatbot 對話機器人設計大賽”，覺得自己的機器人不錯嘛？歡迎大家踴躍報名參賽哦！

北部小聚 in 台北商業大學

LINE Platform Update 201910 - Evan Lin

長期支持 Chatbot 社群的 Evan 大大為大家帶來陣子 LINE 的更新內容，像我這種開發者最期待的就是 LIFF v2 終於上線了 🎉，當中增加了很多種應用讓嗷嗷待哺的工程師們終於可以生出更多種不一樣的應用啦，

  • 外部瀏覽器上使用 LIFF 🎉
  • 兼容 Login v2.1，取得使用者基本資訊
  • 可掃描 QR code
  • 在 LIFF 的 webview 下可獲取使用者的 OS/Language/AccessToken 等等的內容

詳細參考: https://engineering.linecorp.com/ja/blog/liff-v2/

試玩新功能：

LINE Bot 上的表單驗證、搜尋以及分頁 - 郭佳甯

簡報連結

身為卡米粉的我終於再度聽到卡米哥的議程啦，這次介紹的是從 COSCUP 之後一直更新的 kamigo，並完全使用這個套件做的寵物協尋機器人，此議程就已這隻機器人為主體介紹。

在實作網頁的過程中最長需要弄的東西不外乎就是表單驗證、搜尋以及分頁，因為 kamigo 是讓使用者經由 LIFF 幫忙將表單回傳成一份 JSON 至使用者的的對話欄上，
再轉介給 controller 去解析並儲存進資料庫，但若使用者在操作的過程中少輸入會不會一樣送出？
此時 kamigo 透過 rails 原生既有的 validates 來驗證表單欄位內容，並藉由 Turbolinks ajax + js.erb 讓表單在送出時先透過 ajax 打到後端驗證，若驗證失敗後則回傳告知 LIFF 哪個欄位有問題，這個方法也讓我使用到這個套件的肌肉仔可以透過 rails 的鬼神方法幫我驗證表單，如此一來在表單的確認上就沒問題啦！🎉

順手捐星星，救救卡米狗: https://github.com/etrex/kamigo

不懂開發也能建立屬於自己的 Chatbot - 白凱仁

接著由 Cloud Native Taiwan User Group Co-organizer - Kyle Bai 為大家帶來講題，藉由故事的敘述讓大家知道他是為甚麼啟動這個 idea 出來，並靈活運用圖片演示對話流程(筆記)，並因為打遊戲的困擾決定做一個機器人來解決朋友問題，運用 container 的技術來封裝 chatbot App，再用 k8s 透過 N 台機器來管理 container 讓它獲得不死之握能力，確保服務的可用性與延展性。

最後再透過 live demo 的方式讓會眾們一飽眼福，若是對於 Cloud Native 相關技術有興趣的朋友別忘了加入社群，或是你已經有相關主題遲遲沒地方講？趕快搭上線讓你有舞台可以發揮 😎

閃電秀

這部分就參考 Evan 大大的文章

  • Afore: 如何用 Chatbot 說 921 故事
  • 謝化挺: 921 Chatbot 開發心得
  • C.T Lin: 介紹即將發佈的 Bottender v1
  • kevin: 宣傳 DevFest 活動
  • Demo: FunWater - It’s time to rethink about the “single-use plastic” product.

中部小聚 in 夢森林

LINE Pay 串接全紀錄 - KoKo

身為通勤學的作者也是自由工作者的 KoKo 每次都熱情參加 Chatbot 的活動 👏，本次邀請來帶大家認識 LINE Pay，透過詳細的介紹 LINE Pay 帶著大家一步一步做並提醒大家當中需要注意的部分，有部分的會眾是金融相關背景也特地來了解 LINE Pay 的各種機制，透過 KoKo 解釋後讓會眾更清楚裡頭眉眉角角，此時真的是感受到滿滿的熱情，講者跟會眾踴躍的討論也讓整個活動更活絡，想了解更多議題的歡迎來許願或是來當講者體驗一下中部人真正的活力啊！

serveo 讓你用 Docker 開發 chatbot 也能過的去 - Jimmy

COSCUP 就來擔任 Chatbot Taiwan 講者的 Jimmy，本次來分享他包起來的 servo 的容器服務，主要原因是因為在開發機器人時大家都習慣用 ngrok，只是每次都要重新執行重新貼到 LINE Bot 或 LIFF 上，如此繁雜的步驟現在只要透過 container 以及自定義的 DNS 每次只要 docker 啟動後 Domain 啟動後即可開始寫機器人，根本不需要再進後台重新填寫，只能說工程師沒有極限啊！

透過 Jimmy 將 serveo 打包的 container 就不會有連線不穩定的問題(我有經歷過 🤣)，這邊需要注意的問題 serveo 有 ssh 連線數的問題，但一般來說在開發人數不會太多，這樣理論上已經很夠用了～

若對這服務有興趣的話：https://github.com/taichunmin/docker-serveo

閃電秀

感謝 Flex Simulator 拯救了我 - 陳佳新

身為中部負責人的佳新，介紹 LINE 的工具 - Flex Message Simulator，因為應用大量的 flex message 在自家產品「彰化旅行+」上，透過 LINE 的工具讓我們使用 flex message 上能夠叫得心應手。

ChatBot 製造 ChatBot - EJ Lin

近期加入 chatbot 志工的 EJ 製作了一個可以透過 chatbot 管理 chatbot 的服務，將使用者所註冊機器人的 secret 以及 token 放入後，就能訂閱 ptt 特定作者的文章，當作者只要發文就會透過 push message 通知訂閱的人，若這邊 500 則免費訊息用完的話就建議使用者在開新的 🤣

肌肉仔更新啦 - NiJia Lin

最後則是我前一陣子分享過的健身記錄機器人-肌肉仔，引入了最新更新的 flex message 站牌樣板，讓健身者在訓練的每筆紀錄變得更漂亮，讓健身者可以像是公車一樣一步一步的往下一站走！

肌肉仔還是會持續更新，有興趣的朋友別忘了幫小弟按個星星 ⭐️ 鼓勵我繼續前進 😃

結論

臺北臺中連著兩天舉辦真的是很累，但是看到大家踴躍的互動讓我覺得不虛此行，接下來還需要大家的熱情支持，讓我們繼續辦下去 🚀

Chatbot Taiwan 在台北、台中皆有一個月一次的定期聚會，致力於提供並討論聊天機器人的相關應用，每回小聚將安排講者主題分享、新知討論，環繞 Chatbot 與 AI，及大家共同關心的話題。歡迎大家踴躍分享、自由與會眾交流，同時也期望大家可以在分享中得到收獲。

歡迎各位報名、推薦講者以及閃電秀，介紹自己開發的 chatbot 並分享 chatbot 相關的議題，若有相關需要合作歡迎與我聯繫 https://m.me/linnijia。

發表於 更新於 分類於

詳細文件參考

docker 抓 mysql 最新的版本

1
docker pull mysql:tag

若只是要建立普通容器用以下指令:

1
docker run -d -p 3306:3306 -e MYSQL_USER="myname" -e MYSQL_PASSWORD="mypasswd" -e MYSQL_ROOT_PASSWORD="root_pwd" --name mysqltest1 mysql:5.7 --character-set-server=utf8 --collation-server=utf8_general_ci

由於會有備份的問題，所以要先建立資料夾們

1
2
3
4
mkdir ~/docker
mkdir ~/docker/mysql
mkdir ~/docker/mysql/conf
mkdir ~/docker/mysql/data

新增 my.cnf 配置文件

vim ~/docker/mysql/conf/my.cnf

my.cnf 加入如下内容：

1
2
3
4
5
6
7
8
[mysqld]
  user=mysql
  character-set-server=utf8
  default_authentication_plugin=mysql_native_password
[client]
  default-character-set=utf8
[mysql]
  default-character-set=utf8

將 /docker 這個資料夾映射到容器內的 /etcmysql/my.cnf

1
docker run -d -p 3306:3306 --privileged=true -v ~/docker/mysql/conf/my.cnf:/etc/mysql/my.cnf -v ~/docker/mysql/data:/var/lib/mysql -e MYSQL_ROOT_PASSWORD=123456 --name mysqltest2 mysql:5.7
  • –privileged=true：容器内的 root 永有真正 root 权限，否則容器内 root 只是外部普通用戶權限
  • -v ~/docker/mysql/conf/my.cnf:/etc/my.cnf：映射 config 資料夾
  • -v ~/docker/mysql/data:/var/lib/mysql：映射 data 資料夾 (table 都在這)

如此一來就可以儲存 /docker 這個資料夾達到備份的功能

PHPMyadmin

將 myadmin 連接 mysql 的容器指令:

1
docker run --name myadmin -d --link mysql_db_server:db -p 9100:80 phpmyadmin/phpmyadmin

mysql_db_server = mysql container id

在瀏覽器上輸入 localhost:9100 就可以看到 phpmyadmin 囉！

Docker 查詢容器 IP

1
docker inspect -f '{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' container_name_or_id

發表於 更新於 分類於

Cold start

其實個家園端平台多少都會有這問題，畢竟大家都是靠流量賺錢，自然會需要個方法限制使用者，不然免費爽爽用他們也不是做慈善的 🤣，像我最常用的 Heroku，只要 30 分鐘沒有使用他就會進入睡眠時間(參考)，叫醒的時間需要 10~15 秒，不過對於我這個免費宅來說測試夠用了 🤣

AWS以我實際測試起來大概 2 秒左右，回應時間看起來不會太差，其實第一天就有提到這部分，需要的話可以參考。

若是需要它隨時都在都活著的話就要搭配 warm-up，抑或是搭配 crontab 去設定特定時間執行 warm-up。

Function as a Service

在快速成長的前、中期是很適合這個服務的， 畢竟開發者只要將 serverless.yml 基本設定完之後就可以先好好開發，等到中期之後把設定檔稍微整理一下又是一尾活龍了，且平台大多都擁有 auto-scaling 的功能，在服務快扛不住流量的時候只要錢拿出來平台就幫你解決。

只是說當流量越來越大之後相對錢也會越付越多，或許當流量 > 10K 之後代表你的服務應該也有不少人使用了，自己架主機應該不會是什麼難事(?)

幫忙推廣一下 Backend 大大的 高流量心得雜談

在 FaaS 架構下其實很適合 Chatbot 的服務，以概念來說實作時只需要一個路由**(Function)**即個完成，不需要額外太多的資源去處理 web server 的問題，像是這個系列的只要透過 serverless + WSGI 就可以馬上就可以進行本地測試，部署只要下 sls deploy，實在是超級快又輕鬆，不用像以前一樣還要去處理 Nginx 等等相關的問題 😁。

且 AWS、Google 在使用 python 跟 nodejs 上支援度很高，也不用怕找不到資源使用。

使用 Node JS 的朋友可以參考 C.T Lin 大大的文章，他們家的 bottender 超猛的！

Log

在 Log 這部分我覺得 AWS 有點不太好的地方就是他們的 Cloud Watch 應該是獨立服務，當我的 Lambda 輸出紀錄時大概要過 10 秒才會印出來，不像以前自己架主機時只要進 server 就可以馬上切到目錄看紀錄抓蟲，在使用這雲端服務可能在抓蟲有一半的時間都在等 log 出來，有時候急的時候還真的會被氣死 😭。

SNS

像是我前一陣子發的一篇文章，SNS 被觸發事件之後回來的東西是舊的，那時候看到錯誤訊息真的是心很涼，就得用一個 Lambda 排程一直去抓 DB 的 updated_at 欄位有沒有變更時間而去更新狀態，這樣情況就會多浪費一個 Function 去處理這樣的事件，不得不說專門來支援 AWS 服務的 boto3 套件(python)在某些時候做的事不是那麼完善，得使用旁門做到的方法去完成這件事，讓整個開發體驗不是那麼好，若他們可以把一些 error handle 弄更好那就完美了。

結論

其實還有好多服務沒有玩到

但其實使用 AWS 來實作 Serverless 的服務也是這一陣子加入新公司所學到的新技能，過程中總是會用舊的開發思維去想，但常常都因為這樣落坑 😓，但也因此讓我更了解像 AWS 這類的雲服務他們是如何開發每個服務並如何串接，同時也研究了 Serverless 相關的 plugins，看他們是如何支援雲平台讓開發者在開發時可以更像平常時在開發 web，也因為這樣我去貢獻了 example 到了 Serverless 的範例專案上面(參考)，慶祝完成人生第一場鐵三十，跟自己的競賽也告一段落，發現趕著寫文章品質真的會差很多，看來是時候該整理一下，謝謝您的收看 <(_ _)>