發表文章

Mock Server&契約測試

圖片
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 ServicePuer Mock ServerPostman Mock ServicePostman 是前後端在開發上很常用到的一款 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」和「後端已經寫好的 API」。Puer Mock Server為了解決上面碰到的問題,找到了這個 open-source 的 mock server:puer-mock。它可以將沒有 mock 的 API …

如何使用 Docker 切換不同的 MongoDB

圖片
在開發前端的時候,常常會碰到想要回到 migration 之前的 MongoDB 資料結構來除錯,如果只使用本地安裝的 MongoDB,操作上會很麻煩,所以這篇文章會說明如何在本機不安裝 MongoDB 的環境下,使用 Docker 準備多份 MongoDB 資料庫。
請確認電腦有安裝 Docker,先準備好要使用的 MongoDB 資料庫備份檔案,大概會是長這樣:


存放的路徑這裡暫定為 ~/Downloads/20170622/hahow/...。
打開 Terminal,下載 MongoDB(這裡以 2.6 版作為示範)的 Docker image:
$ docker pull mongo:2.6 然後開啟一個新的 MongoDB Docker container,container 名字可以透過 --name 自訂:
$ docker run --detach --name mongo_hahow_20170622 --publish 27017:27017 mongo:2.6 使用 docker inspect 取得 container 的 IP,後面會用到:
$ docker inspect mongo_hahow_20170622 | grep IPAddress 前往剛才存放備份資料庫的位置:
$ cd ~/Downloads 開啟並進入一個暫時性質的 Docker container,用途為 restore 資料庫到 mongo_hahow_20170622 的 container:
$ docker run --interactive --tty --rm --volume $PWD:/tmp mongo:2.6 bash 因為 ~/Downloads 被 volume 在 /tmp 底下,所以可以根據對應的路徑前往該資料庫存放的資料夾位置:
$ cd /tmp 使用 mongorestore 恢復備份資料庫到 mongo_hahow_20170622,IP 記得使用上面 docker inspect 查到的 IP:
$ mongorestore --host 172.17.0.2 --db hahow 20170622/hahow 如果順利 restore 完成之後,就可以離開,它會自動刪除這個一次性的 container:
$ exit 之後…

使用 Google Docs 將圖片轉成文字

圖片
像我這種日文不好、需要靠翻譯工具作參考的人,有時候想翻譯雜誌這種長文會很麻煩。

以前會找一些網路上的 OCR 工具,最近才發現原來 Google Docs 就提供這樣的功能!而且還很強大!ヽ(●´∀`●)ノ

以下圖為例,假如我想要翻譯底下那塊專欄的話:

先將文字區塊裁剪成一張圖檔:
上傳圖片到 Google 雲端硬碟點選右鍵 > 選擇開啟工具 > Google 文件
等待它轉換完成之後,就會產生一份帶有文字檔案的 Google 文件:
完成!Google Docs 提供的圖片轉文字功能有以下特色: 語言自動判斷,日文也沒問題 (*´艸`*)橫書&直書自動判斷,這個有點厲害 🌚相較於其它的 OCR 服務,Google Docs 在內容上的判斷準確率很高!
從此翻譯雜誌的效率大幅提升 。:.゚ヽ(*´∀`)ノ゚.:。

如何發送 redux-observable 的 catch error 至 Sentry

我們團隊目前使用 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-actionsFlux Standard Action 特性,將錯誤用 JavaScript 的 Error object 封裝至 action payload:... .catch(error => Observable.of(createAction('FETCH_USER_REJECTED')(new Er…

如何解決 GPG 失效的問題?

我是用 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 的話,表示順利修復成功。

如何自動化 release 的流程?

圖片
這篇文章會介紹如何使用 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 的 release flow,patch 則是 hotfix 的 release flow。
為什麼要用 semantic-releas…

Amazon S3 正確處理 HTML5 History 路由問題

圖片
如果你是使用 Angular、React 或是 Vue 來開發 SPA(單頁面應用),並且放在 Amazon S3 Static Website Hosting 上的話,那麼你會碰到 URL routing 的問題。一般 react-routervue-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 RulesAmazon 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> </Redirect> </RoutingRule> <…

這個網誌中的熱門文章

DevOps:持續整合&持續交付(Docker、CircleCI、AWS)

Mock Server&契約測試

Factory pattern 工廠模式