Amo Wu's Blog

如何自動化 GitHub Releases 流程 2017 年初的時候，曾經寫了《 如何自動化 release 的流程？ 》這篇文章，介紹了如何利用 semantic-release 和 TravisCI 自動化 GitHub Releases 和 NPM publish 這件事。這次要介紹的是如何直接透過 Probot 機器人做到 GitHub Releases。 大綱 什麼是 GitHub Releases？ GitHub Releases 有什麼問題？ 什麼是 Conventional Commits？ 什麼是 Conventional Release Bot？ 為什麼要用 Conventional Release Bot？ 什麼是 GitHub Releases？ GitHub Releases 是 GitHub 提供給每個專案在釋出（Release）新版軟體時，用來紀錄更新內容（Change Log）的頁面。 GitHub Releases 通過 GitHub Releases，你可以為每次的 release 加入說明，描述該 release 進行了哪些更改。 GitHub Releases 的基礎是建立在 Git tags 之上。Tags 代表了你的專案在某個特定時間點下的里程碑，所以它會是一個很好的 release 表達方式。 更多有關於 Git tags 的資訊可以參考 GitHub 的《 Working With Tags 》。 GitHub Releases 有什麼問題？ 我們團隊在執行 release 的過程中碰到過不少問題，總結如下： 無法回憶起曾經「新增了哪些功能」或「修復了哪些問題」，就像突然有人問「你記得上禮拜二中午吃什麼嗎？」的感覺，每次負責 release 的人都要口頭一個一個問其他工程師，最後崩潰躲在角落獨自一個人慢慢爬 commit log⋯⋯😢 Push 或 merged master 的當下就應該馬上 release Git tag，但是常常會忘記做這件事，導致之後想起來還要回去找 commit SHA 才能補上 tag 不是所有人都知道 SemVer 的版本號更新規則 Git tag 下在錯誤的 branch：因為有些 rep

這篇文章會以 node-github 的 getCommits API 為例，介紹如何使用 RxJS 取得所有分頁的 commits 結果。 前言 以往在處理分頁的 API，通常都會使用遞回運算，這會讓程式碼的可讀性不佳。有鑒於最近 RxJS 正夯，想說來試著寫寫看，於是就有了這篇分享文章。 需求 首先，因為 node-github 的 getCommits API 回傳的是一個 Promise 物件，所以需要先使用 RxJS 的 fromPromise 將它轉成 Observable： Rx.Observable .fromPromise(getCommits(...)) 接下來，利用 node-github 提供的 hasNextPage 和 getNextPage ，搭配 RxJS 的 expand 來處理分頁的遞回運算： Rx.Observable ... .expand( (response) => hasNextPage(response) ? Rx.Observable.fromPromise(getNextPage(response)) : Rx.Observable.empty() ); 上述邏輯大概是這樣： 如果 getCommits 回傳的結果還有下一頁，就繼續 call getNextPage API 如果已經沒有下一頁，則回傳 Observable.empty() 結束 expand 運算 最後，透過 reduce 將所有分頁回傳的結果 concat 成一個 Array： Rx.Observable ... ... .reduce( (acc, curr) => acc.concat(curr.data) , []); 整體程式碼大致如下： Rx.Observable .fromPromise(getCommits(...)) .expand( (response) => hasNextPage(response) ? Rx.Observable.fromPromis

AWS Serverless RESTful APIs 近幾年在雲架構上討論熱度較高的 2 大主題分別是 容器化 （Containerize）與 無伺服器 （Serverless）架構。本篇文章會帶你瞭解什麼是 AWS 無伺服器架構，以及如何使用 Serverless Framework 這個框架，快速開發 RESTful APIs。 大綱 什麼是 XaaS？ AWS 無伺服器架構 Serverless Framework CRUDable Service 基礎設施即程式碼 什麼是 XaaS？ 馬雲說過一句話：「過去的一百年，我們把人變成了機器，未來的一百年，我們將會把機器變成人。」 人算不如天算，天算就是雲計算。 如果要用一句話來定義 XaaS（X as a Service）的話，那就是「 萬物皆服務 」。 舉凡 IaaS（基礎設施及服務）、PaaS（平台即服務）或 SaaS（軟體即服務）等⋯⋯，用一張圖來概括各個 XaaS 的關係： 坐在服務窗口後面的人最後都會變成 API。（via @legendtang ） — ruanyf (@ruanyf) 2016年8月26日 身為程式設計師，我們就是那個負責寫服務來取代人類的存在 。 所以能夠以最快速度開發出可驗證的服務原型，就成了開發者彼此之間的競爭條件之一，也是本篇文章的目的。 AWS 無伺服器架構 AWS 是目前雲技術的領頭羊，如果想要用 AWS 來開發 Serverless 的 RESTful APIs，主要會由 3 個核心服務所構成： AWS Lambda（Functions as a Service） Amazon API Gateway（REST API Endpoint as a Service） Amazon DynamoDB（NoSQL DB as a Service） 利用 3 個 XaaS 組成一個 BaaS（後端即服務） 這裡不會贅述如何操作這些 AWS 服務，如果你已經熟悉這些服務，可以直接前往下一章的 Serverless Framework；如果還不知道它們是怎麼運作的，強烈建議先跑過一遍官方的幾篇教學與實作，理解這 3 個傢伙為什麼這麼酷，也才能理解為什麼接下

Mock Server＆契約測試 這篇文章會介紹如何運用 Mock Server 和 Integration Contract Test（契約測試）解決一些在前後端分離的開發環境底下會碰到的問題。 大綱如下： 什麼是 Mock Server？ 為什麼需要 Mock Server？ 如何使用 Mock Server？ 什麼是契約測試？ 為什麼需要契約測試？ 什麼是 Mock Server？ 下圖是傳統的前後端分離架構： 當後端 API 還沒開發完成的時候，前端會需要一個可以暫時回應假資料（mock data）的 mock server，如下圖： 等到後端的 API 開發完成之後，前端只需要將 API endpoint 從 mock server 切回 remote server 就可以使用真實資料，如下圖： 為什麼需要 Mock Server？ 一句話，因為有了 Mock Server 之後，前後端就能夠並行開發。 如何使用 Mock Server？ 這裡會介紹兩種方法： Postman Mock Service Puer Mock Server Postman Mock Service Postman 是前後端在開發上很常用到的一款 HTTP Client 應用程式，主要是拿來測試 API，除了有好用的 Collection Test Runner 之外（詳見《 基於 Postman 的 API 自動化測試 》），其實 Postman 還有提供 Mock Service 的功能，大致流程如下： 送出一個 request（R1） 儲存 R1 至 Collection（C1） 編輯 R1 的 response，儲存成為一個 example（P1） 建立一個 C1 的 Mock Server（M1） 再次向 M1 送出 R1，即會收到格式為 P1 的 response 詳細操作方法請見官方教學文章《 Mocking with examples 》。 但是使用 Postman Mock Service 會碰到一個問題，雖然 Postman 可以同時 mock 多筆 API，但是一個頁面可能會同時存在「需要 mock 的 API」和「後端已經寫好

在開發前端的時候，常常會碰到想要回到 migration 之前的 MongoDB 資料結構來除錯，如果只使用本地安裝的 MongoDB，操作上會很麻煩，所以這篇文章會說明如何在本機不安裝 MongoDB 的環境下，使用 Docker 準備多份 MongoDB 資料庫。 請確認電腦有安裝 Docker，先準備好要使用的 MongoDB 資料庫備份檔案，大概會是長這樣： 存放的路徑這裡暫定為 ~/Downloads/20170622/foo/... 。 打開 Terminal，下載 MongoDB（這裡以 2.6 版作為示範）的 Docker image： $ docker pull mongo:2.6 然後開啟一個新的 MongoDB Docker container，container 名字可以透過 --name 自訂： $ docker run --detach --name mongo_foo_20170622 --publish 27017:27017 mongo:2.6 使用 docker inspect 取得 container 的 IP，後面會用到： $ docker inspect mongo_foo_20170622 | grep IPAddress 前往剛才存放備份資料庫的位置： $ cd ~/Downloads 開啟並進入一個暫時性質的 Docker container，用途為 restore 資料庫到 mongo_foo_20170622 的 container： $ docker run --interactive --tty --rm --volume $PWD:/tmp mongo:2.6 bash 因為 ~/Downloads 被 volume 在 /tmp 底下，所以可以根據對應的路徑前往該資料庫存放的資料夾位置： $ cd /tmp 使用 mongorestore 恢復備份資料庫到 mongo_foo_20170622 ，IP 記得使用上面 docker inspect 查到的 IP： $ mongorestore --host 172.17.0.2 --db foo 20170622/foo 如果順利 restore 完成之後，就可以離開，它會自動刪除這個一次性的 conta

像我這種日文不好、需要靠翻譯工具作參考的人，有時候想翻譯雜誌這種長文會很麻煩。 以前會找一些網路上的 OCR 工具，最近才發現原來 Google Docs 就提供這樣的功能！而且還很強大！ヽ(●´∀`●)ﾉ 以下圖為例，假如我想要翻譯底下那塊專欄的話： 黃色框框處為打算翻譯的文章 先將文字區塊裁剪成一張圖檔： 裁切出只想翻譯的部分 上傳圖片到 Google 雲端硬碟 點選右鍵 > 選擇開啟工具 > Google 文件 使用 Google Docs 開啟圖片 等待它轉換完成之後，就會產生一份帶有文字檔案的 Google 文件： Google Docs 自動幫你將圖片上的內容轉成可以編輯的文字 完成！Google Docs 提供的圖片轉文字功能有以下特色： 語言自動判斷，日文也沒問題 (*´艸`*) 橫書＆直書自動判斷，這個有點厲害 🌚 相較於其它的 OCR 服務，Google Docs 在內容上的判斷準確率很高！ 從此翻譯雜誌的效率大幅提升 ｡:.ﾟヽ(*´∀`)ﾉﾟ.:｡

我們團隊目前使用 Sentry 這個服務作 error tracking，JavaScript 或 React 的基本安裝方法在 官方文件 都可以找到，這裡就不贅述。 同時我們也有在使用 redux-observable 這個 RxJS middleware 來處理帶有副作用的 Redux action。 根據 redux-observable 這篇 Error Handling 文件的介紹，一般處理 async 錯誤的寫法大概會是： import { createAction } from 'redux-actions'; import { Observable } from 'rxjs/Observable'; const fetchUserEpic = action$ => action$.ofType(FETCH_USER) .mergeMap(action => Observable.fromPromise(fetch(`/api/users/${action.payload}`)) .map(response => createAction('FETCH_USER_FULFILLED')(response)) .catch(error => Observable.of(createAction('FETCH_USER_REJECTED')(error.message))) ); 但是因為這裡並非正規的錯誤拋出方式，導致 Sentry 無法攔截到。 所以根據 Sentry 的這篇 Rich Error Reports with Redux Middleware 文件介紹，我們需要另外為它寫一個 Redux middleware 來處理。 策略是利用 redux-actions 的 Flux Standard Action 特性，將錯誤用 JavaScript 的 Error object 封裝至 action payload： ... .catch(error => Observable.of(createAction('FETCH_USER_RE

我是用 cider 在管理自己的 dotfiles，然後前陣子因為 gnupg 的 formula 剛好一起被更新，導致我的 GPG signature verification 無法順利運作。 解決方式： $ brew unlink gnupg && brew link gnupg 如果有跳出某些 conflicting error 的話，可以照著提示解決，例如： Linking /usr/local/Cellar/gnupg/2.1.21... Error: Could not symlink bin/gpg-agent Target /usr/local/bin/gpg-agent is a symlink belonging to gpg-agent. You can unlink it: brew unlink gpg-agent To force the link and overwrite all conflicting files: brew link --overwrite gnupg To list all files that would be deleted: brew link --overwrite --dry-run gnupg 然後再重新 link gnupg 一次： $ brew unlink gnupg && brew link gnupg 最後檢查 Git 能不能順利 commit 和 push，然後確認 GitHub 的 commits 有出現 verified signature 的話，表示順利修復成功。

這篇文章會介紹如何使用 semantic-release 這個工具，自動化 Node.js (or JavaScript) 專案的版本號，以及 changelog 的 release 流程。 什麼是 semantic-release？ 為什麼要用 semantic-release？ 如何使用 semantic-release？ 什麼是 semantic-release？ semantic-release 可以自動完成下列這些事： 當 code 被 push 或 merge PR 回 production branch (ex: master) 的時候 CI build 被觸發， semantic-release 會收集此次更新的所有 commit messages（需遵循 AngularJS Git Commit Message Conventions 的格式） 自動根據 semver 的規則來更新 package.json 的 version，並建立 Git tag 自動 publish 新版本的 package 到 npm registry （非必要） 自動在 GitHub releases 的頁面上，產生相對應的 changelog 所以簡單來講， semantic-release 指的就是遵循 semver 的 release 流程。 semver 的介紹和好處可以在網路上找到很多文章，這裡就不贅述了，它的概念主要就是將版本號分成： Major . Minor . Patch 例如 React 的 0.11.2、Vue.js 的 2.0.10 等，這三個數字各自代表： Major 當你的 API 不兼容前一版本時（又稱 Breaking Change），major + 1，例如：1.x.x -> 2.0.0。 Minor 當你增加新 feature 的時候，並且不影響前一版本的 API，minor + 1，例如：x.6.x -> x.7.0。 Patch 當你修復 bug 的時候，並且不影響前一版本的 API，patch + 1，例如：x.x.9 -> x.x.10。 如果專案有在執行 git-flow 的話，minor 配合的就是 feature 的 re