Amo Wu's Blog

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...

如果你是使用 Angular、React 或是 Vue 來開發 SPA（單頁面應用），並且放在 Amazon S3 Static Website Hosting 上的話，那麼你會碰到 URL routing 的問題。 一般 react-router 或 vue-router 都預設使用 hash 的方式來處理 SPA 的路由： http://domain.com/#!/paths 如果你不喜歡 #!/ 的顯示方式，可以使用 HTML5 的 History API ，這樣就能像一般網站那樣顯示 URL： http://domain.com/paths 但是使用 HTML5 History API 時，通常必須搭配 server 端正確的 路由配置 才能防止出現 404 Not Found 的情形。 遺憾的是，在 Amazon S3 Static Website Hosting 上，你無法更動 Apache 或 Nginx 的配置，所以需要靠其它方式來解決問題。 使用 S3 的 Redirection Rules 使用 CloudFront 的 Custom Error Response 使用 S3 的 Redirection Rules Amazon S3 Static Website Hosting 提供了 Edit Redirection Rules 的選項，我們可以輕鬆使用這段程式碼將所有 domain.com/#!/paths 所產生的 404，全部重新導向至根路徑： <RoutingRules> <RoutingRule> <Condition> <HttpErrorCodeReturnedEquals>404</HttpErrorCodeReturnedEquals> </Condition> <Redirect> <HostName>你的網域（例：domain.com）</HostName> <ReplaceKeyPrefixWith>#!/</ReplaceKeyPrefixWith> </Redirec...