前言: 各位好， 我是 LINE Taiwan 資深開發技術推廣工程師 – Evan Lin。 今天這篇文章為各位詳細解釋 「 LINE Bot 開發指南」這一份投影片文件。這一份文件是來自於 Development guidelines 的投影片，考量到在台灣還沒有正式的公布與中文化。這一次跟總部共同合作準備中文版本之外，並且特定用這一系列文章加以解釋，希望可以讓更多開發者有更多的了解。 Development guidelines 文件內容很多，本份投影片也將以五篇文章的篇幅來加以解釋。本篇文章為第二篇文章，主要講解的會是關於設定 LINE Bot Webhook 相關注意事項。 文章索引: 完整投影片鏈結： https://speakerdeck.com/line_developers_tw2/line-bot-developer-guideline-chinese 希望各位可以持續關注： 關於LINE Bot 使用Webhook URL接收請求時的注意事項(本篇文章) 發送 API 請求時的注意事項 LINE Login LINE Login (補充） 其他相關功能 本篇文章將專注在第一個段落，也就是 Page 3 ~ Page 8 的部分。 Webhook URL 接受請求時的注意事項 本篇注意事項中，其實在「開發LINE聊天機器人不可不知的十件事」。有許多著墨，這裡稍微帶到與解釋。以下個別根據不同頁面來解釋。 A 考量安全性的通訊環境 B 接受到請求的時候，回覆狀態代碼 200 C 防止來自於 LINE 以外未經授權的請求 D 對於大規模訊息處理的考量 A 考量安全性的通訊環境 這部分提醒大家需要提升 Webhook 伺服器的安全環境，這邊也提醒大家根據 2021/01 的新聞 ([Updated] TLS 1.0 and TLS 1.1 support by the webhook notification source will be discontinued at the end of January 2021)，如果要能正常地接受到 LINE 平台的 Webhook 必須要讓伺服器支援到 TLS 1.3 。 平台開始支援 TLS 1.3 LINE’s APIs now support TLS 1.3 將不在支援 TLS 1.0 與 1.1(參考 Updated: TLS 1.0 and TLS 1.1 support by the webhook notification source will be discontinued at the end of January 2021 ) 第一件事：正確設定HTTPS from 在 「開發LINE聊天機器人不可不知的十件事」 也有提到相關的支援，請開發者們務必要注意。 在設定HTTPS伺服器時，有下列幾點必須注意的事項： HTTPS伺服器所使用的根憑證（Root CA）必須是在LINE平台的白名單列表中，否則LINE平台會拒絕傳送訊息。在白名單列表中大多數的憑證都需要付費申請，但是LINE平台也支援常用的免費憑證，例如Let’s Encrypt。 請勿使用已知具有安全性漏洞的協定（例如SSL v2或SSL v3）或Cipher Suite（例如SWEET32或CVE-2016-2183）。 請務必正確設定中繼憑證（Intermediate certificate），以避免無法對應到根憑證而發生錯誤。這是最常見的問題通報狀況，請在設定HTTPS伺服器時多加留意。 更多訊息歡迎參考以下文章：...

前言: 在二月份文章有提到 使用 GoReleaser 打包你用 Golang 寫的 CLI (Command Line Tool)，並且搭配 Github Actions 準備 Changelogs ，透過 GoReleaser 可以跟 Github Action 整合之外，還可以幫你撰寫 Changelogs 讓版本管控上變得更加的簡單與方便。 但是隨著服務與產品的應用變廣，會有更多的客製化需求發生。那麼該如何讓你的 Github Action 能夠有更多樣的自訂設定呢？ 基本需求： GoReleaser with Github Action 大家可以參考前一篇文章，也可以快速學習本篇。 把這個建立成檔案在 .github/workflows/release_build.yml 就可以了。 這個其實比較適合 main.go 直接放在 github repo 下的，可以參考 https://github.com/kkdai/go-cli-template 的專案形式。 main.go 在子目錄 (sub-folder) Main program in sub-folder 通常在開發一些套件的時候，有時候我們主要 Repository 會是相關的開發套件 (Package) 而會將 CLI 的部分放在 cmd/xxx_cli 的資料夾中。需要安裝的時候再跑 go install xxx.com/xxx/uuu/cmd/xxx_cli 來安裝。 如果這時候你的 main.go 並不在 repo 的主目錄下，而是在 cmd/test_cli 的目錄下。 這個時候你就會發生錯誤。 goreleaser error: dones not contain a main function 這時候要如何修改呢? 依照上面顯示，主要修改部分就在於 workdir: ./cmd/test_cli 放在 Steps Run GoReleaser 裡面的 with:。 這樣就可以正常的編譯出執行檔案，並且更新 changelogs 。 多個相關的執行檔案需要編譯 / 客製化編譯選項 因為原先在 .github/workflows資料夾中，有相關的指令限制，參考 github action Workflow syntax。 如果有想要更多客製化編譯選項如下： 多個資料夾在 /cmd/ 底下。 讓 GoReleaser 的編譯選項多一些，預設會全部 Compile 。可以挑選只要 Mac + UNIX ，或是加上 x64 選項。 加上一些 enviironment variable (e.g. CGO_ENABLED=0) 打 LDFLAGS 給 go build (e.g. -s -w -X main.build=) 透過 hooks 來跑某一個 compile shell script (e.g. post: ./script.sh ) 如果有以上相關的客製化選項，可能就需要將 GoReleaser config 獨立出來成一個檔案，相關做法如下： 主要修改就是透過 args: release -f...

前言: 各位好， 我是 LINE Taiwan 資深開發技術推廣工程師 – Evan Lin。 今天這篇文章為各位詳細解釋 「 LINE Bot 開發指南」這一份投影片文件。這一份文件是來自於 Development guidelines 的投影片，考量到在台灣還沒有正式的公布與中文化。這一次跟總部共同合作準備中文版本之外，並且特定用這一系列文章加以解釋，希望可以讓更多開發者有更多的了解。 Development guidelines 文件內容很多，本篇文章也將以五篇文章的篇幅來加以解釋。 文章索引: 完整投影片鏈結： https://speakerdeck.com/line_developers_tw2/line-bot-developer-guideline-chinese 希望各位可以持續關注： 關於LINE Bot (本篇文章) 使用Webhook URL接收請求時的注意事項 發送 API 請求時的注意事項 LINE Login LINE Login (補充） 其他相關功能 本篇文章將專注在第一個段落，也就是 Page 3 ~ Page 8 的部分。 LINE Developers 相關資源 這邊主要提到兩個網站，分別是： LINE Developer Doc: 負責存放所有的相關產品說明文件， API 詳細說明。 LINE Developer Console: 這就是開發者稱為的控制台部分，跟官方帳號 (Official Account) 的後台不同，這邊主要是負責設定相關的開發資源。 不論是建立新的 Channel 或是新增，修改 LIFF App 都可以利用控制來完成。 LINE Bot 的機制 這一張投影片解釋了一個使用者傳訊息給一個官方帳號後，訊息會如何透貴 LINE 的平台傳遞到開發者的（也就是圖上的客戶端）的 Bot 伺服器。 這邊表達了幾件事情： 所有訊息都會透過 LINE 平台的 Talk 伺服器與 Channel Gateway 伺服器處理後傳給 「 Bot 伺服器」。訊息都是透過 Webhook 的方式傳遞，開發者只要依照官方文件開發好像關的 「Bot 伺服器」並且在登入好 webhook 的位置。就可以正確地收到訊息。 開發者處理完訊息後，可以透過 API 的方式發送給 LINE Channel Gateway 。 會在依照相關的訊息發送人透過 Talk 伺服器來發送訊息。 相關的開發者文件可以參考： Receiving messages (webhooks) Sending messages 關於 LINE Bot 與 Channel 之間的相關性 這張投影片解釋了官方帳號與 Channel 之間的相關性，接下來將為讀者詳細解釋: 首先使用者對於官方帳號（LINE Bot) 所做的所有動作，都有相關的訊息透過 Webhook 來傳給開發者的 LINE Bot 。 LINE Bot 收到訊息後，可以透過取得的 Access Token 來通過伺服器認證來發送訊息給使用者。 透過 LINE Login 的認證部分也可以將使用者鏈結到相關 LINEE Bot 帳號。（ e.g. 透過網路商城的第三方登入 LINE Login ，可以讓使用者登入網路商城後，也直接加入 LINE Bot ）。 相關部分可以參考文章： 如何透過...

前言: 前幾天的文章中 [Jekyll] 移除 Disqu 替換到 utteranc 來使用 github issue 作為文章評論 ，我有提到我將本來部落格中的 Disqus 評論有搬到 https://utteranc.es/ 的過程，但是在 Disqus 裡面還有接近兩百個留言 (共有 189 個留言，分別在 55 篇文章內) 怎麼辦？ 秉持著自己打造自己用的小工具原則（ –關在家裡太無聊– ），就寫出了這個小工具來使用，希望能幫助到一些人。 也希望有更多的人一起加入開發相關功能。 TL;DR 本篇文將要介紹以下一些的部分，除了介紹如何使用外。人和 如何導出 Disqus Comment 套件: Disqus to github issue Go  包括哪些功能 Disqus XML Format 解析 Github issue created in Go 結論 成果 參考文章 如何導出 Disqus Comment 到 Utteranc 到 Disqus 管理介面，去導出： http://disqus.com/admin/discussions/export/ 。 大概需要過一兩天才會收到導出的檔案（不定時）。 到 Utteranc 設定導入 修改 Github Page 設定。 可以參考文章 [Jekyll] 移除 Disqu 替換到 utteranc 來使用 github issue 作為文章評論 套件: Disqus to github issues Go https://github.com/kkdai/disqus-to-github-issues-go 安裝套件方式：``go get github.com/kkdai/disqus-to-github-issues-go` 並且提供一個 CLI 給大家先用，大家可以安裝 go install github.com/kkdai/disqus-to-github-issues-go/cmd/import_disqus_cli 相關指令： -f: Import disqus exported xml file. (get from http://disqus.com/admin/discussions/export/) -u: github user name, you want to use for post github issue. -r: github repo name, you want to use for post github issue. -t: github token, you can request your from https://github.com/settings/tokens. 使用指令範例： ./import_disqus_cli -f="EXPORTED_XML_FILE" -r="BLOG_REPO" -u="GITHUB_USER" -t="YOUR_TOKEN" 包括哪些功能 讀取從 disqus export 的...

什麼時候是好時候：掌握完美時機的科學祕密 When: The Scientific Secrets of Perfect Timing 作者： 丹尼爾・品克 出版社：大塊文化 出版日期：2018/05/29 買書推薦網址： 電子書: Readmoo 博客來: 購買網址 前言: 這一本是今年所讀完的第六本書。你知道透過大數據統計的狀況下，大部分的人什麼時候喝咖啡最好？ 什麼時候做文件處理的事項最好？ 什麼時候是最容易發生轉職跟轉換工作的季節？ 這本書分享了許多統計上的相關數據，讓你了解時間所帶來的秘密，並且也根據每個人工作上的習慣，來建議什麼時候做回覆電子郵件的事情最好，什麼時候建議拿來開會與發想事情？ 這本書作者之前看過他的書： 動機、單純的力量(DRIVE: The Surprising Truth About What Motivates Us) ，所以對於他這一本書相當的期待。 內容簡介與心得: 我們無時無刻都面臨一連串永無止盡、與「時機」相關的決定。什麼時候換工作，什麼時候安排課程，什麼時候步入穩定關係或全心投入專案。然而，我們卻隨意做出這些決定——基於直覺、預感及猜測。在本書中，丹尼爾．品克認為這是完全錯誤的方法。 根據品克的話，我們都知道時機就是一切，但我們對時間本身卻了解不多，以為時機是種藝術。他在書中表明，時機其實是一門科學，於是寫出這本談論「什麼時候做什麼事」、有關「時機」的書，為我們揭開時機的科學祕密： •早上何時喝咖啡最好？——不是起床後立刻喝，最好的時間點是在起床後1～1.5小時喝。 •工作多久應該休息一下最有效？——每工作52分鐘，休息17分鐘。 •包含新年元旦，一年當中你有幾天可以重新開始？——86天。 •怎樣利用一天中隱藏的模式來建立理想的工作時間表？ •為什麼有些特定類型的休息，會顯著提高學生的考試成績？ •什麼時候是辭職、轉職、或結婚甚至離婚的理想時間？ 品克借鑑心理學、生物學、神經科學和經濟學等豐富的研究成果，提煉精華，彙整成引人入勝、深具說服力的文章，字裡行間充滿魅力無窮的故事，以及實用的要點——集結在每一章的「時間駭客指南」中。本書富含宏大觀念與深遠寓意，將改變你對自己過去、現在及未來的想法，同時助你掌握人生各階段面臨時機抉擇的最佳決策。 章節條列 第1部　一天 首先透過心理學與生物學的角度來分析，上班族一天的情緒波動。會發現中午吃飯是一個很大的分界點。許多的人專注度在上午最高，但是中午吃完飯回來辦公室後，就開始逐漸下降到下班才會回覆。 還有快樂的心情也是如此，透過這些方式來提供給讀者們知道，該如何尋找人開會，該如何將工作事項做有效的排列與準備。 接下來透過慕尼黑時間型態問卷 (https://www.danpink.com/MCTQ/) 來判別每一位讀者屬於哪一種的人，那麼這樣來說他一天得時間會如何安排。 雲雀 第三種鳥 貓頭鷹 其中雲雀是指的是早起的人們，而貓頭鷹完全相反的是晚起的人們，最後一種就是介於其中的人（大部分也是第三種）。 接下來探討的中午休息（午睡）帶來的工作相關影響，這部分蠻有趣的，其中午休可以帶來下午的充沛活力也是不能不注重的。其中建議的就是小睡 10 ~ 20 分鐘是最建議的休息長度。 下午之後，也建議有所謂的「微休息」，讓專注度可以快速地透過休息後來回復。 第2部　開始、結尾與中場 開始： 將時間從一天放長一點，放到整個職涯，整個人生或是幾年來說。什麼時候會是最被重視的時間？ 就是一個新的專案的啟動，一個學習開始，甚至是一個新的工作的開始。 本書作者相當建議讀者要做「事前的驗屍」，也就是在一開始先訂定專案的成功，失敗的可能性，先預想各種可能發生的大型危機。 中場： 人們總是習慣在一開始的時候戰戰兢競，但是過了一半之後就出現了所謂的「中間點危機」（放大到人生，叫作中年危機）。 本書也分享了哪一些時間容易發生轉職的危機，中間點容易發生疲倦與厭煩感是既定的事實，該如何調適也是一門大學問，作者有其他建議方法： 設定暫時性目標： 將中間幾個點設定成小目標，全力衝刺。 公開宣示暫時目標: 告訴其他人你將要完成事項，讓大家一起來給你壓力，讓你能夠做完它。（這也是我最常使用的方式，笑！） 話說到一半就停：這邊說得是，你不要把中間事情做到一個段落，而是每一件事情都做到一半，才會讓你有繼續的動力。 不要讓鏈子斷掉： 回頭看看你過往的努力，會讓你更有信心跟毅力能夠往後。 想像這麼做可以幫助其他人： 往往許多事情是不是只有你自己，很多時候你的工作會帶給其他人很深遠的影響。 結尾： 人們對於中年後的朋友開始去蕪存菁，也會慢慢對於自己想要深交的人開始篩選，這些都是結尾容易發生的事情。 甚至也分享了許多人在工作的最後幾天也往往最讓人印象深刻，甚至是人生的末期也讓人印象深刻。 所以結尾的力量其實相當的重要且深遠。 其中有句話我印象很深刻： 皮克斯每一部的電影主角都有一個想要達成的目標，但是他會明白這個目標其實不是自己需要的東西。而這個目標往往會讓他放棄他需要的事情：朋友，家人。最終主角都會放棄原來的目標，真正的追求他們原本就擁有的東西。 結果層次最高的情就是在這些背後的心理轉折。核心在於這種錯中複雜的情感。 第3部　同步與思考 接下來探討的是群體的時間點，同步與思考的部分。 要如何在整個團體能夠同步到一個最佳的狀況呢？ 比如說合唱團要如何抓準時間表演？ 龍舟隊伍要如何才能同步大家划船的力量往前衝刺？ 擴大到整個組織要如何抓到好的時間點。讓整個團隊能夠在合諧的狀態？ 首先作者介紹了一個印度的奇特行業： 幫人送新鮮的午餐便當到手上的工作，在印度首都有許多的人，到每一個人家中收取剛剛包好的便當，送到工作人員的手中。這些人代表的中午吃飯的重要，也代表著一份情感的傳遞。 他們分工也很精密，收送的人，跟發放的人如何有默契的交接，讓便當可以快速的到人的手上，不會冷掉。 這些和諧的團體會有一種同步的機制與節奏，就是「同步者的快感」。 團隊中協調技巧： 快速回覆電子信件 分享彼此的奮鬥故事 培養自律的團隊儀式 由每個人都提供一點點的拼圖方式 最後作者也分享一些名言： 以前我相信，時機就是一切。現在我相信，任何事情都有其時機 心得: 「什麼是好時機？」，我們常常在問自己這個問題。 這本書讀到一半的時候，會以為很像是心理學或是生物學的建議書籍。但是隨著書本內容的案例分享與許多有效與睿智的「時間駭客」精髓，作者除了分享時機的重要性之外，更分享了如何在每個時間中，讓事情的效果發揮到最大。 這一本書有實際的建議，也有相當程度的整理與統計，讓你可以更有效地接受相關的概念，相當建議可以看看。 參考文章 讀書心得-動機、單純的力量(DRIVE: The Surprising Truth About What Motivates Us)

前言： 疫情升溫打斷本來出遊計劃，還好女兒很乖在玩。 那我就來弄弄 Jekyll 的評論搬遷，結果發現最近有個好用系統 utteranc.es 可以讓你直接使用 github issue 來作為文章評論。 來看看吧。 本篇文章將告訴你如何移出，並且使用 Github Comment 作為文章評論用，現在也有個開源好用的工具。 https://utteranc.es/ 什麼是 Disqus 一直以來本站是透過 Jekyll 來架設的，之前本來有使用 Disqus 作為文章評論系統，雖然很多人說廣告太多，太慢。只是覺得還好，可能沒仔細看。 最近覺得 disqus 的廣告越來越嚴重，影響整個效能。決定拿掉了。 有需要參考的可以看一下這個 commit 主要就是先註解掉相關的設定。 然後發送 git push 即可。 移除 diqus 大家可以參考這個 commit. https://github.com/kkdai/kkdai.github.io/commit/3dfba4885874cb1cb0c06a09fd2f4fffd892623a 主要就是把 disqus 的設定拔掉。 highlighter: rouge markdown: kramdown #disqus: evanlin1007 #comments : # provider : disqus # disqus : # short_name : evanlin1007 加入 utteranc utteranc 是一個完全 Open Source 並且使用 github comment 。並且提供一些設定，還有外觀的 theme 可以設定。感覺相當好用，社定上也很簡單： Install for your github app Put code in your Jekyll Done ! (搭啦) 參考 https://github.com/kkdai/kkdai.github.io/commit/b9606abd93c08bf131efa4db78c8762e8a26f1da 可以修改 _layouts/post.html 如下： <script src="https://utteranc.es/client.js" repo="kkdai/blog" issue-term="pathname" theme="github-light" crossorigin="anonymous" async> </script> 完成品： 這樣是不是很快速（五分鐘就好了） 代辦事項： 接下來就要把 disqus 的評論搬到 github comment， 這邊可以先 export 出來後，寫個 Golang 來 import 。找到了在這裡： http://disqus.com/admin/discussions/export/ 接下來就是把文章評論搬過去。 參考文章： Removing Disqus and adding GitHub Issue Comments Enabling Jekyll Blog Comments with Utterances 我的相關 commit: 拔掉 Disqus https://github.com/kkdai/kkdai.github.io/commit/3dfba4885874cb1cb0c06a09fd2f4fffd892623a 增加 utteranc https://github.com/kkdai/kkdai.github.io/commit/b9606abd93c08bf131efa4db78c8762e8a26f1da