前言

大家好，我是 LINE Taiwan Developer Relations 團隊的 NiJia Lin。很開心在這裡跟各位分享 2021 年的首場開發者小聚，本場次是我加入以來第一次在台北舉辦的線下活動(過往都是會眾身份)，除了有美味餐點以外，現場也能感受到滿滿的開發者們對於技術熱情(同仁們一直包圍詢問)，以下就由我帶大家體驗一下現場的熱情吧！

KKTIX 活動網頁: 活動網址

TL;DR

Heroku Postgresql 引入時預設 DATABASE_URL 的開頭是 postgres，因 Python ORM - SQLAlchemy 有先天限制問題，需另起一個環境變數並改成 postgresql 才不會遇到：

1

sqlalchemy.exc.NoSuchModuleError: Can't load plugin: sqlalchemy.dialects:postgres

前言

在 Vue 3 出來之後我有嘗試了一下新的功能，結合 LIFF 做了一個 side project - Announcer-Vue，當然也有寫了一篇相關使用的文章 在 Vue3 中引入 LIFF 的 ShareTargetPicker 分享 FlexMessage 訊息給 LINE 好友，那既然會用了，當然也要來了解一下一些 Composition API 的介紹，那以下就是我去參加 Kuro 的簽書會所聽到的內容。

翻譯來自泰國的 Jirawatee 的文章

在過去的一年中，Rich Menu 上的文章非常受歡迎，它的優點是在用戶聊天頁面上顯示重要的**選單(Menu)**並可以選擇各種操作，降低用戶使用官方帳號的門檻。而對於擁有 LINE 正式帳戶或 LINE Chatbot 的用戶而言，加上創建步驟是相當簡單的，可以透過 Official Account 後台或是讓具有程式能力的朋友透過呼叫 API 的方式建立 Rich Menu，若能這麼容易就建立 Rich Menu，那麼成為每個帳戶必須具備的基本功能也就不足為奇了。

本文中我將邀請所有人開發一個 Rich Menu，以便能夠顯示出來每個用戶在手機上使用的語系。首先必須知道的是 “該用戶使用哪種語言？”，我們可以透過哪種方式獲取用戶手機上的語系，早期我們只能取得 userId、displayName、pictureUrl和statusMessage，而現今 LINE 已在用戶的個人資料訊息中添加了一個 language 參數以供使用。

到目前為止，我們已經準備好了想法。因此，讓我們看一下開發它的步驟：

1. 準備使用 Cloud Functions for Firebase 開發的 LINE Chatbot
2. 準備泰語和英語的 Rich Menu
3. 建立條件以獲取 Follow 類型 Webhook 的事件
4. 從用戶個人資料中取得 “language” 參數
5. 讓用戶匹配對應語系的 Rich Menu

前言

大家好，我是 LINE Taiwan 的 Tech Evangelist - NiJia Lin。這次很開心受到 chatbot 社群的邀請，參加了 “Chatbot meetup 聊天機器人小小聚 28 @ Onramp Studio“ 的聚會活動，過了一個農曆年，相信很多人也很期待三月 LINE Platform API 的新功能，藉由在社群上與大家分享 LINE API 更新與個人開發的心得，也希望透過社群分享的力量能夠讓聊天機器人的開發動能更加的盛大。

• 社群 Chatbots Meetup： https://www.facebook.com/groups/chatbot.tw
• 本次活動網頁: 活動網址

由於 Chatbot Meetup 本身屬於社群自主性的活動，裡面也有許多社群朋友所贊助的閃電秀。裡面的所有內容也是相當的難得與有趣。也希望能夠透過本篇文章讓大家稍微了解 Chatbot Meetup 社群閃電秀的魅力。

這次就由我用文章帶大家了解一下近期有什麼有趣的更新內容吧！

翻譯來自泰國的 Tan 的文章

大家好，我希望 2021 年對每個人來說都是美好的一年 😃，本次會分享一篇對於有在開發 LINE Chatbot 朋友相關的有趣文章。

12 月時，LINE 更新了 Messaging API 的新功能(新聞連結)，方法是當用戶將貼圖發送給 Chatbot 時，將會從 Webhook 的 keywords 中找到貼圖的關鍵字訊息。

前言

Kubernetes 幫忙處理掉許多以前很繁雜的問題(Auto-Scaling、容器管理..)，讓開發者只要手持 Container 與大量 yaml 檔即可將工具部署上去(前提是容器要正常工作)，但作為僅有一台筆電的開發者(我)想試玩總不能直接至雲端開叢集(金幣攻擊)，因此找到了一個解決方案，使用 k3d 來幫助我們建立 Kubernetes 試玩，以下就一步步帶大家從容器建立到將服務部署於叢集上。

範例專案：louis70109/kubernetes-line-echo-bot

前言

以前不管在單元/整合測試、部署或是一些週期性的工作，有點經驗的工程師通常會很習慣寫個 Script 去跑相關指令集。而隨著寫的服務越來越多，許多部分也微服務化後，同一個指令集可能會服務到對象也越來越多，因此就開始有了像是 Jenkins、Drone、Travis 以及本篇會介紹 GitHub Actions 這類的 CI 工具，但既然是工程師當然要把指令集內的耦合性盡可能的降到最低，因此就有像是 GitHub Marketplace 的套件市集，讓大家可以在上面選擇不同功能的工具套入於自己的 CI 中，接下來就讓我帶你來了解一下平時會遇到什麼問題，以及如何建立與使用 LINE Notify 於 GitHub Actions 上吧！

以前如何知道結果？

• 寫 Script 並用 Linux 的排程(Crontab)在固定時間跑測試案例、爬資料、部署…等狀態
• CI/CD 過了之後自己上網站看 log (沒通知)
• 即便寫通知程式在 Script 裡，未來的可用性極低(不好管控金鑰、換程式語言…)

Why GitHub Actions?

• GitHub 自家出的 CI 工具
• 專案大多放在 GitHub 上的情況
  • 可達到資源 Single Source of Truth
• 市集(Marketplace)已經有許多工具可以合併使用
  • 之前的文章中使用過 Python 自動打包與自動測試的工具

Why LINE Notify?

前言

過年前收到了預購的 Vue.js 3 書，除了支持以外也希望透過紀錄把看過的東西在寫下來加深印象，以下就分享一些我看的過程中覺得有學習到的部分。