忍者工坊
0%

發表於 更新於 分類於

Header

其實本來也沒打算在我的部落格發這種 mur mur 文，但總覺得在前往更高層級時總是需要思考一下自己在做的事情是不是對的，接下來就在描述一下好了 😆

Body

就在今天跟著大家一起看GitHub 全球最大軟體工程師交友平台的排名網站(可惜我貢獻還不夠多沒排進去 😭)
https://commits.top/taiwan.html

看著各位為大神的排行榜中點來點去就碰巧點到了這篇文章
https://jaceju.net/be-a-senior-engineer/

而最近也是一直在想這問題

「如何才有資格稱為資深工程師」

以前總想著只要工作一陣子之後我就可以號稱我是 senior
但工作後又跑社群發現認識的一個比一個還強都覺得離他們好遠啊 👀

但看完這篇之後也很慶幸自己身邊有那麼多貴人在幫助我往資深工程師的方向在走
但不管職稱是什麼我認為「自我反省」是一件很重要的事
小到文件錯字、大到系統 runtime 爆炸 🐛
都得從中去找到錯誤去找出讓自己成長的契機

這是最近做了一個類似 AWS IoT Job 的 mur mur 🤣
讓自己成為更好的軟體工程師～

發表於 更新於 分類於

前言

最近在實作需要處理字串並且把它改成真實的判斷式，找 google 的過程中找到了一篇解答，當中剛好看到 Operator 這個套件，以下就用一些範例來示範～

實作

處理的範例: 1=1AND2<5OR8>9

可以使用re把字串處理成陣列

1
2
re.split("AND|OR", payload)
# -> [1=1, 2<5, 8>9]

接著再使用迴圈+同樣的方法去處理掉=、>、<

在處理完之後就可以找到所有的 key 以及 value 的陣列

接著就是要把 AND、OR 找出來存下來，這邊我會會使用split('AND', 1)只切第一個找到的AND字串，因為像是 SQL Where 子句的功能要一個一個處理才行，否則最後判斷會出問題。

1
2
3
4
5
while re.search('(AND)|(OR)', payload) is not None:
    result = payload.split('AND', 1)
    if result[0] and ... # 判斷 AND 字串
    result = payload.split('OR', 1)
    if result[0] and ... # 判斷 OR 字串

接著再切完之後會拿到operator_list知道裡面有哪些運算子的陣列，以原本的資料來說可以用迴圈去處理，這邊我就用簡單的範例來表示operator可以處理的東西。

像是operator除了可以判斷純數字以及純字串以外，也可判斷英文+數字的組合。

1
2
3
4
5
6
7
operator_list = ['>', '<', '=']
if operator_list[0] == '>':
    result = operator.gt(2, 0)
if operator_list[1] == '<':
    result = operator.lt('z01', 'z99')
if operator_list[2] == '=':
    result = operator.eq('A', 'A')

使用以上方法可以比對運算子，而使用以下方法則可以比對AND以及OR

1
2
3
4
5
ex = ['AND', 'OR']
if ex[0] == 'AND':
    result = operator.and_(1, 1)
if ex[1] == 'OR':
    result = operator.or_(1, 0)

結論

透過 operator 這個函示庫讓我處理運算子們可以少很多事，藉此紀錄一下工作上使遇到的一些方法以及問題，最驚訝的就是可以比對英文+中文的判斷式，以一些韌體的本版資訊來說他們會擁有這樣的組合，在上傳之後要比對時用這樣的方法就很方便，若有什麼問題歡迎留言給我 😊

參考

發表於 更新於 分類於

前言

為什麼會想玩這個呢，因為之前串了一隻介接 Twitch API 的聊天機器人，不過最近因為 API 似乎已經翻新了，所以那隻機器人暫時死亡了 😆，但是聊天機器人不限定只有在 facebook、LINE 通訊軟體上，因此就寫了這篇文章來紀錄一下使用過程。

文件 & 申請密鑰

Twitch Chatbot IRC 官方文件

要使用的朋友在 google 時可能會找到另一套，不過他也說請大家來用 tmi.js 了ＸＤ

首先要先申請一個 OAUTH 的密鑰，網址在這邊

套件安裝

透過npm安裝tmi.js

1
npm i tmi.js

IRC 通訊

接著需要寫一個腳本透過IRC的方法來與 Twitch 的聊天室連結：

IRC（Internet Relay Chat）是一個位於應用層的協定。其主要用於群體聊天，但同樣也可以用於個人對個人的聊天。

新增 bot.js

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
const tmi = require('tmi.js');
const client = new tmi.Client({
  options: { debug: true },
  connection: {
    reconnect: true,
    secure: true,
  },
  identity: {
    username: 'YOUR_NAME',
    password: 'oauth:YOUR_KEY',
  },
  channels: ['yuniko0720'], // 想加入的聊天室
});
client.connect();
client.on('message', (channel, tags, message, self) => {
  if (self) return;
  if (message.toLowerCase() === '87') {
    client.say(channel, `@${tags.username}, 你是第 N 個說 87!`);
  }
});

設定檔

  • username: 設定你的使用者名稱
  • password: 申請的 oauth 放在這邊，格式皆是oauth:XXXXX
  • channels: 一般會進入自己的頻道，當然也可以去其他頻道
1
2
3
4
5
identity: {
    username: 'YOUR_NAME',
    password: 'oauth:YOUR_KEY',
  },
  channels: ['yuniko0720'],

連結聊天室

這部分則是開始監聽聊天室的內容，所有的範例連結皆在此。

1
2
3
4
5
6
client.on('message', (channel, tags, message, self) => {
  if (self) return;
  if (message.toLowerCase() === '87') {
    client.say(channel, `@${tags.username}, 你是第 N 個說 87!`);
  }
});

成果

執行node bot.js會看到以下的畫面

其實這樣監聽看起來真的是讓我這個宅心噴發 🚀🚀，可以透過IRC收到聊天室訊息後看後續要怎麼處理，像有些實況主與觀眾的互動可能是輸入+1這樣的文字來獲得獎賞(抑或是互罵 🤣)，在很多情境下這樣用會讓觀眾除了跟實況主互動以外還有個對象能玩 👾。

結論

而在這樣監聽下若人數很高之後其實可以收集到更多的資訊去做利用，也許想是開啟訂閱者模式後讓訂閱者輸入特定文字後將資訊傳入Google sheet之類的資料表，在做抽獎等活動性質的內容，對整個遊戲實況內容行銷都會是滿好與觀眾互動的方式～

大概就玩到這邊了，下次想到什麼應用再來說 😆

發表於 更新於 分類於

前言

大家好，我是 NiJia

下半年度辛苦來參加小聚的各位了，最後一季場地一直變更，因為每次小聚都有熱情的夥伴提供場地給小聚，也一起尋找最適合各位的一個場地，若造成困擾小弟深感抱歉 <(_ _)>

2019 年度活動資訊請參考 ➡️Chatbot Taiwan GitHub

小聚活動 & 簡報連結

meetups 14

Topic Speaker Link
What’s new in LIFF v2 and TECHPULSE 2019 preview Evan Lin link
Bottender 一路走來 林承澤(C.T Lin) link
如何使用 kamigo 快速開發 LINE bot 林家煜(NiJia Lin) link

心得

當時 LIFF v1 只能透過 Deep link 的方式讓很多需要 Web view 的動線設計上增加了許多困擾，而在 v2 上線後改善了這方面的問題，且也對外公布支援 Query string 讓開發者可以帶參數進去(雖然之前就已經在偷用了 😆)，雖然很不幸的因為 iOS 的政策問題導致 Scan QR code 的功能在接下來的版本硬生生被拔除，但整體下來其實 LIFF v2 對於在 LINE 上開發功能的朋友可以更有彈性的去應用了。

iOS 政策問題參考

Bottender 是在某次小聚聊到時才知道原來有這麼酷的開源專案，我覺得最特別的除了可以支援多平台之外，就是 console 模式了，像我最近做的 ABL 台灣隊賽程機器人就只使用到純文字的功能，在console模式下很快速的就把功能弄好，部署時只要把相關 Key 放進去功能就完成了，這部分是真的很驚艷 😆
上週去參加 GDG Hackthon 時介紹給其他寫前端的朋友使用，從來沒寫過後端的他們也覺得使用上真的很快就上手，所以有寫Javascript的朋友不妨參考試試囉！

當初因為訓練時沒有一個可以幫我儲存記錄的地方，因此想到想做 LINE bot 來解決我的問題，但同時我又不喜歡處理一大堆 JSON 的問題，因此選用 Kamigo 作為我開發 bot 的框架，除了框架幫忙轉打請求轉到對應的controller讓我不用寫一堆if else以外，最好用的功能就是 Kamiflex 了，當我們在 Flex Message Simulator 弄了一堆 JSON 出來時，同時我們需要從資料庫拉資料出來組裝產生大量的 JSON，在組裝時程式碼會很髒亂，所以使用 Kamiflex 來幫忙轉譯讓我在寫 Flex message 時可以更像在寫 Ruby code，讓整個 JSON 可能幾千行瞬間被濃縮成 100 行時這段 Flex message 在維護時也能更好的維護。

Kamigo 流程

Topic Speaker Link
LINE Push / Message 開發經驗談 Caesar Chi
邊緣人救星！用 Laravel 打造私人定製的聊天機器人 李小胖 link
Chatbot builder Penny Sun link

心得

我平時就有在看一些社群行銷朋友分享他們是如何對行為下標籤tag以及發放對應內容給使用者進而提升購買力，在 Caesar 大大的快速了解到這些商業行為背後的開發經驗為何，從設計到大量推送所需注意的問題以及服務器之間的溝通問題…在這次的議程中讓我學到很多付費內容才會聽到的題材，讓我對於 Push message 這件事情的做法與思路又重新被教育了一次 😆

這次要請到一個月有一半時間都在參加小聚的小聚王小胖來為各位分享如何用Laravel做一隻專為自己客製化的機器人，雖然 Live demo 過程中了魔咒，好險後來也解決的一些 live demo 才會遇到的問題 🤣，總之若有使用 php 的朋友歡迎參考簡報哦～

最後由 LINE 的資料工程師-Penny 為我們帶來在 LINE techpulse 上的議程，從介紹中 NLU 部分看起來功能會像是 Dialogflow 一樣，而在其他的部分則是提供一個介面讓使用者可以更快速的在網頁上設定自己想要的機器人樣式，只是目前功能只提供給合作的商家，期待未來 release 時的效益 🚀

官方帳號已經有套用囉！想收到啲一手資訊或是想玩玩的朋友可以掃描加入 👾

所有小聚資訊接收藏在 -> Chatbot Taiwan GitHub 上哦！

閃電秀

14

Speaker Topic Link
陳佳新 LINE Beacon，數位導覽的小幫手！
Eric Flex box, 一起收集分享 Flex message link
徐郁涵 食農飽可夢
郭佳甯 午餐隊長 link

15

Speaker Topic Link
Calvin LINE Beacon，數位導覽的小幫手！ link
JT ChatOps & Rasa link
NiJia ABL 台灣隊查詢機器人 link
郭佳甯 Bottender & Kamigo 介紹 link1、link2

短評

除了內容豐富的主議程外，閃電秀就是在每個社群最特別的部分了，從每次的閃電秀中都讓我對於 side project 的想法又重新被定義了一番，常常會看到很多不同的應用情境以及特殊的用法，歡迎大家踴躍報名閃電秀來互相交流，多方交流或許有機會蹦出不一樣的想法並讓機器人的其他用途 😁

結論

在舉辦每次的小聚活動都希望可以給每個來的朋友最豐富的內容，以及提供 Lighting talk 的舞台讓有作品的朋友可以上來分享，而最近有與其他社群的朋友聊到，發現似乎把議程塞太緊，導致影響到會眾與講者交流以及回家休息的時間，所以之後的小聚改善這個狀況並調整時間，再麻煩大家多支持 Chatbot Taiwan🚀🚀🚀

發表於 更新於 分類於

大家好，我是 Chatbot Taiwan 的 NiJia，最近我們 Github 開張囉，想找之前演講的紀錄都會在此哦！

前言

事情是這樣的，本週末 12/13-12/15 我要去 GDG Taichung Hackthon Party 上當導師，礙於我實在想不出有個題目可以分享給其他同好，碰巧之前跟過 Wolke 大大的 Dialogflow + LINE bot 工作坊，憶起當時的明媚風景，接著前陣子寫鐵人賽也有跟到 C.T Lin 大大寫的使用 Modern Web 技術來打造 Chat App，如此一來我就乾脆把這兩個東西合在一起弄個東西！

又這麼剛好的我最近瘋狂看 ABL 球賽(支持本土球隊！)，剛好週末也沒事，就順手把它做出來啦~有在看球賽的朋友別錯過這隻機器人囉！他可以告訴你下一場比賽是哪時候～

以下記錄著我踩雷的過程 🤣，詳細 bottender 使用手冊還是參考 -> 使用 Modern Web 技術來打造 Chat App

本篇文章的程式碼已經開源囉 Taiwan-ABL-Games

建立專案

1
npx create-bottender-app taiwan-abl-games

接著會看到以下的畫面，bottender 很貼心的列出一些大家平常比較會使用的平台，這邊我們先選擇 LINE，後續會再告訴大家如何增加其他平台選項。

Dialogflow 注意事項與串接

這邊一定是要參考主要開發者所寫的文章啊 -> Day25
大致上創建服務的過程差不多，這個部分就簡單帶過比較重要的部分。

在處理意圖部分有個小撇步，若鼠標從左邊到右邊，到第二個時會把第一個意圖覆蓋掉，這邊我都是從右邊到左邊一個一個選，才不會遇到覆蓋的問題。

接下來再處理 Dialogflow API 的問題，Day 25 文章中所提到的地方 Google UI 似乎有換位置，我找到的位置在此 -> URL

從頁面的藍色按鈕(建立服務金鑰)後會遇到下圖畫面，第一個紅色框框需要注意是不是剛剛建立的 Dialogflow 的 agent。
而第二個下拉式選單選擇 Dialogflow Integrations，下面則選擇 JSON 格式。

在一開始建立完之後若是要回來管理的話，直接到 GCP 的主控台左側的API & Services的Cedemtials來管理金鑰。

把下載的檔案放在主目錄下，接著要在.env下新增以下兩個 key，GOOGLE_APPLICATION_CREDENTIALS則需要打上絕對路徑，後面再部署會再解釋這段。

1
2
GOOGLE_APPLICATION_CREDENTIALS=/Users/.../taiwan-abl-games/YOUR_KEY.json
GOOGLE_APPLICATION_PROJECT_ID=taiwan-abl-games-mpmomf

PROJECT_ID要去 GCP 主控台查詢。

實作

這邊就先複製原作者的 code 並稍做修改至 /src/index.js：

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
26
27
28
29
30
31
32
33
34
35
36
37
const dialogflow = require('dialogflow'); // 記得安裝
const { format } = require('date-fns'); // 記得安裝

const PROJECT_ID = process.env.GOOGLE_APPLICATION_PROJECT_ID;
const sessionClient = new dialogflow.SessionsClient();

module.exports = async function App(context) {
  if (context.event.isText) {
    const sessionPath = sessionClient.sessionPath(
      PROJECT_ID,
      context.session.id
    );

    const request = {
      session: sessionPath,
      queryInput: {
        text: {
          text: context.event.text,
          languageCode: 'zh-tw',
        },
      },
      queryParams: {
        timeZone: 'Asia/Taipei',
      },
    };

    // 透過 dialogflow 偵測意圖
    const responses = await sessionClient.detectIntent(request);
    const { intent, parameters } = responses[0].queryResult;

    if (intent.displayName === 'dreamer-next-game') {
      //...YOUR CONTEXT
    } else {
      await context.sendText('您輸入的內容我不懂哦~🏀');
    }
  }
};

藉由上述程式碼會發現藉由 Dialogflow 判斷出來的 intent 到底是要填入什麼？intent 顯示的字串就如下圖所示，我們在 Dialogflow 裡建立的 Intent 的名字就是最後 API 會回傳給我們的判斷字串，這邊就正規化一下自己所要提供的意圖吧！

bottender.config.js

最後這邊提一下如何設定給多平台使用，一開始藉由npx create-bottender-app xxx幫我們建立 app 時這個檔案就會自動生成，bottender 很好心的把所有明台所會用到的 key 全部都會放在這裡面。

以我為例我就有使用到 Messager 來試玩，這邊就需要把enabled啟動(false -> true)，實際建立粉絲頁相關可以參考

題外話: 最後再使用npx bottender messenger webhook set就會幫我們把 localhost 串接到 Message 上，實在是太讚了！！！

部署注意事項

我是使用 Heroku 當作我部署的環境，請服用這篇Heroku 部署

在本地端測試時會用到很多的環境變數，而 Dialogflow API json 的路徑我是透過環境變數去取得，在 Heroku 上會把專案的內容放在/app底下(不管你專案叫什麼名字)，因此環境變數GOOGLE_APPLICATION_CREDENTIALS需要輸入/app/xx-ooo.json這樣就會取到當前目錄下的檔案囉！

結論

經由這次試玩這個 project 讓我覺得 bottender 這個 chatbot 框架整合真的是厲害，幫開發者處理掉很多跨平台上的問題，我認為最酷的就是 console mode，在測試程式邏輯上可以不用每次都一直用手機開 LINE 或是 FB 來測試機器人狀態，而是在終端機就解決這件事，這是我開發機器人到目前為止覺得最酷的模式 👍！

而在這個專案上我使用到 Dialogflow，除了參考的原文畫面 (GCP 頁面) 已有些許更動外，其實介接的速度是非常快的，此外我很認同原文作者的觀點，把 Dialogflow 接在程式後面才去處理這件事會增加很多彈性，畢竟當一個回應來的時候可能會想做其他不同的應用，此時若是模型就在前面先把訊息回覆掉，會增加很多開發上的問題(當然若簡單的功能單人沒問題 🤣)。

總而言之～誠心推薦大家去玩玩 bottender，也許你會跟我一樣發現了新大陸 😎。

參考

Dialogflow
GCP
Bottneder 建立專案
Heroku 部署

發表於 更新於 分類於

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，實在是有夠方便又快速(還是免費的)。不過有個問題是當程式沒在運行時他會睡覺，身為一個免費仔做的小專案這樣是夠的，做為一個貪心的免費仔怎能容許睡覺睡這麼久 🤤！但若是照著我上篇分享的文章做，佈署程式沒問題，但就開發機器人我都要佈署才能測試，這未免也太不人性了 😒。

閱讀全文 »