發表文章

目前顯示的是 2015的文章

Serverless! 使用 AWS 開發 Slack Slash Commands

作者 時間
圖片
本文介紹如何使用 AWS Lambda & AWS API Gateway 搭建一個不需要伺服器的環境，提供 Slack Slash Commands 查詢豆瓣電影。
2016-01-24 Update：New – Slack Integration Blueprints for AWS Lambda
這篇文章使用到的技術：
Slack Slash CommandsAWS LambdaAWS API Gateway豆瓣電影 API 閱讀這篇文章需要具備什麼能力：
Node.js 的基本能力Amazon Web Services 的基本操作 接下來我會逐步講解這些東西：
Slack Slash Commands 的運作機制建立一個簡單的 AWS Lambda function建立一個簡單的 AWS API Gateway 執行 Lambda function使用 Lambda 呼叫豆瓣電影 API測試 AWS API Gateway將 API Gateway endpoint 加入至 Slack Slash Command Slack Slash Commands 的運作機制 當你在 Slack channel 輸入 /movie 權力的遊戲，Slack 會發出一個 content-type Header 設為 application/x-www-form-urlencoded 的 HTTP POST 請求，格式如下：
token=YOUR_SLASH_COMMAND_TOKEN team_id=YOUR_TEAM_ID team_domain=YOUR_TEAM_DOMAIN channel_id=YOUR_CHANNEL_ID channel_name=YOUR_CHANNEL_NAME user_id=YOUR_USER_ID user_name=YOUR_USER_NAME command=/movie text=權力的遊戲 response_url=YOUR_HOOK_URL 然後 Slack 需要收到的 JSON 回應格式如下（詳見 Attachments）：
{ "response_type": "in_channel", "attachments": [ { &q…
閱讀完整內容

解決 Universal 架構的 CSS Modules 問題

作者 時間
最近在使用 React 和 Redux 建構一個 Isomorphic JavaScript（Universal）應用。但是在實作 CSS Modules 的時候，會碰上兩個問題：Server-side 的 Node.js 無法 import *.css。如果改成使用 process.env.IS_BROWSER 來判斷只在 Client-dide import，那又會碰到 Server-side 與 Client-side render 出來的 DOM 結果不一致的問題。解決方式：安裝 css-modules-require-hook 這個套件：npm install css-modules-require-hook --save-dev修改 webpack config 的 css-loader 設定：// webpack.config.js { // ... module: { loaders: [{ test: /\.css$/, loader: 'style-loader!css-loader?modules&localIdentName=[name]__[local]___[hash:base64:5]!!postcss-loader' }] } // ... }在 Node.js 的 main file 加入 css-modules-require-hook：// server.js require('css-modules-require-hook')({ generateScopedName: '[name]__[local]___[hash:base64:5]' }); // ...注意 generateScopedName 的命名格式，必須與 css-loader 的 localIdentName 保持一致。
閱讀完整內容

如何在發布自己的 NPM package 之前打包檔案

作者 時間
圖片
最近 Bower 宣布停止維護，所以許多前端的 packages 都移到了 NPM 上，甚至連 Grunt 和 Gulp 這類 build tools 都有要被 NPM scripts 取代的趨勢。
這篇文章主要是紀錄怎麼在發布自己的 package 之前，打包好需要的檔案。
假設你會使用 Grunt 或 Gulp 將所有原始碼打包存成一支檔案，例如 dist/build.js，但是因為通常我們不會把 dist 這類輸出文件放進版本控制，所以要在每次發布新版本的時候動態打包。
方法是在 package.json 的 script 底下新增一個 prepublish 的腳本，然後把你的打包命令寫在這裡：
// package.json { "script": { "prepublish": "..." // grunt or gulp } } 接下來是透過 main 指定程式的進入位置，讓其他人在使用的時候可以正常的 require 或 import 你的 package。
預設的檔案通常是 index.js，這裡我們把它改成剛剛打包完成的 dist/buid.js：
// package.json { "main": "dist/build.js" } 最後也是最重要的部分，記得在專案根目錄新增一份 .npmignore 的空檔案，因為如果沒有它，NPM 在發布的時候會參考 .gitignore 的清單來決定哪些檔案不能被發布，而通常 dist 就會在這裡面，所以要將它從 .npmignore 裡面移除。
都準備完成之後就可以發布了，如果你還沒有 NPM 的帳號，可以註冊一個：
npm adduser 然後發布新版本：
npm publish 記得更新 package.json 的 version 才能發布 發布成功之後前往 http://npmjs.com/package/name 看結果：

完整專案可以參考我的 GitHub 參考文章Publishing npm packages
閱讀完整內容

Code Coverage with CircleCI + Codecov

作者 時間
圖片
Code Coverage with CircleCI + Codecov
最近的案子用到 Redux + React，因為它 Pure Function 的特性，所以 單元測試 很容易寫，順便也趁機會玩一下 程式碼覆蓋率（Code Coverage）。
單元測試 Unit Test 這裡就不講單元測試怎麼寫了，網路上有很多大神的好文可以爬，我是用 Mocha + Chai：
mocha 是 test framework，提供 describe、itchai 是 assertion library，提供 assert、should、expect 安裝 Gulp：
npm install --save-dev gulp gulp-mocha 安裝 Babel 讓程式支援 ES6 語法：
npm install --save-dev babel 加入 mocha 到 gulpfile.babel.js：
// gulpfile.babel.js import gulp from 'gulp'; import mocha from 'gulp-mocha'; gulp.task('mocha', () => { return gulp.src('test/**/*.js') .pipe(mocha()); }); 使用 npm test 取代 gulp mocha：
// package.json { "scripts": { "test": "gulp mocha" } } 這樣做的好處：
gulp 可不用 -g 全域安裝CI 會自動執行測試 程式碼覆蓋率 Code Coverage 有許多提供 code coverage review 的服務，例如：Code Climate、Codecov、Coveralls。這裡選擇 Codecov，因為它的 GitHub public repo 方案是免費的。


安裝 istanbul 產生 coverage report：
npm install --save-dev gulp-istanbul ispartaisparta 讓 istanbul 支援 ES6 加入 covera…
閱讀完整內容

GTD＆Creative Routines

作者 時間
圖片
這是一篇勉勵我自己如何實行 GTD & Creative Routines 的一套方法。
前言 不知道該做什麼什麼是 Creative Routines？人生終極目標GTD收集（Collect）處理（Process） 二分鐘法則四象限法則整理（Organize） 目標金字塔三隻青蛙理論執行（Do） 番茄工作法回顧（Plan） PDCA 循環願望清單結語
前言 你是否常常在夜晚帶着一絲傷感入睡呢？明明胸懷大志，卻總是因爲忙碌無爲而感到愧疚？時間總是在不知道該做什麼之中悄悄流失……
節錄自「我的时间管理与方法论」 不知道該做什麼 為了解決這類焦慮，我們需要有一套 GTD 方法，讓自己在正確的時間（Time），有正確的事（Things）可以去做（Done）。
什麼是 Creative Routines？ 「世界上最恐怖的事情就是－比你優秀的人，比你更加努力。」優秀的人之所以能夠創造出令人矚目的成就，是因爲他們在日常作息、工作和學習之中，養成了規律良好的習慣。
「優秀是一種習慣」 —— 亞里士多德 幸福並非取決於天性，我們的一言一行都是日積月累下，養成的習慣。如果說懶惰是一種習慣，那麼優秀也是一種習慣。

人生終極目標 我們每天生活所需要維繫的目標，不外乎五大主題：
健康事業社會責任情感愛好 若想長時間、規律地維持著良好的習慣，必須得有一個基準，用來判斷上述生活中會碰到的這些事情中，哪些對你而言才是最重要的、哪些才是你想做的、哪些是你該做的，而這個基準就是 GTD 的中心思想，也就是人生終極目標。比如：我的人生目標是對社會做出貢獻。那麼每當你完成一個經過篩選的目標時，也同時在實現人生的終極目標。
GTD 有了人生終極目標之後，接下來我們就可以開始探討如何實現 GTD（Getting Things Done）方法了。
GTD 的好處？
把複雜的事情簡單化把簡單的事情可操作化把可操作的事情度量化、數字化把可度量、可數字化的事情可考評化把可考評的事情流程化 節錄自「什麼是科學管理」——《命好不如習慣好》 GTD 的壞處？
會有人來留言對你說「你活得不累嗎？」 GTD 的核心流程，五大步驟：
收集（Collect）處理（Process）整理（Organize）執行（Do）回顧（Plan） 收集（Collect）
不要相信你的記憶能力，身為一個專業的程序猿，我們有義務清空自己的記憶體，讓…
閱讀完整內容

OpenCC 簡繁中文轉換 Alfred 2 workflow v1.0.0 released!

作者 時間
圖片
從以前就在找一個可以簡繁互換的 Alfred workflow，可惜一直沒找到滿意的，所以一直以來都是用 Yahoo 的輸入法來切換模式。結果前幾天突然看到 OpenCC 這個開源項目，而且還有 Python 的庫可以用！二話不說就自己來寫一個了，以下是節自我的 GitHub alfred-chinese-converter v1.0.0 的 README。
┈┈┈┈┈┈┈✄┈┈┈┈┈┈┈

Introduction 介紹 使用開源項目 OpenCC（開放中文轉換）開發的 Alfred 2 workflow，支持簡繁體中文的詞彙級別轉換、異體字轉換以及地區習慣用詞轉換（中國大陸、臺灣、香港）。

Features 特點 節選自 OpenCC 的部份特點：
嚴格區分「一簡對多繁」和「一簡對多異」。完全兼容異體字，可以實現動態替換。嚴格審校一簡對多繁詞條，原則爲「能分則不合」。支持中國大陸、臺灣、香港異體字和地區習慣用詞轉換，如「裏」「裡」、「鼠標」「滑鼠」。詞庫和函數庫完全分離，可以自由修改、導入、擴展。 Installation 安裝 Mac OS X 環境底下，使用 Homebrew 安裝 OpenCC 這套開放中文轉換庫：
$ brew install opencc Download 下載alfred-chinese-converter.alfredworkflow v1.0.0
Usage 用法 使用關鍵字 cc 輸入需要作簡繁轉換的詞句：



Alfred 會列出 7 項轉換結果：
簡體到繁體繁體到簡體簡體到臺灣正體臺灣正體到簡體簡體到香港繁體（香港小學學習字詞表標準）香港繁體（香港小學學習字詞表標準）到簡體簡體到繁體（臺灣正體標準）並轉換爲臺灣常用詞彙

選擇其中一筆結果，自動複製至剪貼簿：

閱讀完整內容

DevOps：持續整合＆持續交付（Docker、CircleCI、AWS）

作者 時間
圖片
這篇文章將一步一步介紹如何使用 Docker、GitHub Flow、CircleCI、AWS Elastic Beanstalk 與 Slack 來完成持續整合與持續交付的開發流程。
前言 什麼是持續整合＆持續交付？ 持續整合＆持續交付（Continuous Integration & Continous Delivery），簡稱 CI & CD，具體介紹可以參考「山姆鍋對持續整合、持續部署、持續交付的定義」這篇文章。
簡單來說就是盡量減少手動人力，將一些日常工作交給自動化工具。例如：環境建置、單元測試、日誌紀錄、產品部署。
我使用了哪些工具？Git - 版本管理GitHub - 程式碼託管、審查CircleCI - 自動化建置、測試、部署Docker - 可攜式、輕量級的執行環境AWS Elastic Beanstalk - 雲端平台Slack - 團隊溝通、日誌、通知 看完這篇你可以學到什麼？瞭解 GiHub 的工作流程（GitHub Flow），利用 Pull Request 以及分支來完成代碼審查（Code Review）與環境配置，例如：開發版（development）、測試版（testing/QA）、上線產品（staging/production）。使用 Docker，統一開發者、測試人員、以及產品的執行環境。使用 EB CLI 將應用程式部署到 AWS Elastic Beanstalk 平台上。使用 CircleCI 將以上工作全部自動化。偵測 GitHub 分支上的程式碼，若有更新則觸發：建置 Docker 環境、單元測試、然後自動部署新版本到 AWS EB。使用 Slack，讓團隊成員能夠即時接收 GitHub 與 CircleCI 每一項動作的通知。 內容大綱Node.js在本地端執行 Node.js在本地端測試 Node.jsGitHubCircleCI在 CircleCI 測試 Node.jsCode Review with GitHub FlowDocker在 Docker 執行 Node.js在 CircleCI 測試 DockerAWS Elastic Beanstalk在本地端部署 AWS在 CircleCI 部署 AWSSlack Node.js 安裝：
node: 0.10 這篇文章以 Node.js 的應用…
閱讀完整內容

這個網誌中的熱門文章

DevOps：持續整合＆持續交付（Docker、CircleCI、AWS）

作者 時間
圖片
這篇文章將一步一步介紹如何使用 Docker、GitHub Flow、CircleCI、AWS Elastic Beanstalk 與 Slack 來完成持續整合與持續交付的開發流程。
前言 什麼是持續整合＆持續交付？ 持續整合＆持續交付（Continuous Integration & Continous Delivery），簡稱 CI & CD，具體介紹可以參考「山姆鍋對持續整合、持續部署、持續交付的定義」這篇文章。
簡單來說就是盡量減少手動人力，將一些日常工作交給自動化工具。例如：環境建置、單元測試、日誌紀錄、產品部署。
我使用了哪些工具？Git - 版本管理GitHub - 程式碼託管、審查CircleCI - 自動化建置、測試、部署Docker - 可攜式、輕量級的執行環境AWS Elastic Beanstalk - 雲端平台Slack - 團隊溝通、日誌、通知 看完這篇你可以學到什麼？瞭解 GiHub 的工作流程（GitHub Flow），利用 Pull Request 以及分支來完成代碼審查（Code Review）與環境配置，例如：開發版（development）、測試版（testing/QA）、上線產品（staging/production）。使用 Docker，統一開發者、測試人員、以及產品的執行環境。使用 EB CLI 將應用程式部署到 AWS Elastic Beanstalk 平台上。使用 CircleCI 將以上工作全部自動化。偵測 GitHub 分支上的程式碼，若有更新則觸發：建置 Docker 環境、單元測試、然後自動部署新版本到 AWS EB。使用 Slack，讓團隊成員能夠即時接收 GitHub 與 CircleCI 每一項動作的通知。 內容大綱Node.js在本地端執行 Node.js在本地端測試 Node.jsGitHubCircleCI在 CircleCI 測試 Node.jsCode Review with GitHub FlowDocker在 Docker 執行 Node.js在 CircleCI 測試 DockerAWS Elastic Beanstalk在本地端部署 AWS在 CircleCI 部署 AWSSlack Node.js 安裝：
node: 0.10 這篇文章以 Node.js 的應用…
閱讀完整內容

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 …
閱讀完整內容

Factory pattern 工廠模式

作者 時間
距離上一篇 Strategy pattern 策略模式已經兩個多月了，一直拖到現在才生出這篇文章...orz。
其實這篇工廠模式應該要當作第一篇 Design pattern 的文章會比較好，因為這個模式很容易懂，但是工廠模式中又細分出一些其他類似的模式，例如抽象工廠模式，所以我把一些相關的資料都讀了一遍後，分三篇作介紹。
工廠模式最主要的精神就是將 new Class 這個動作另外封裝成一個 Factory Class，這個Factory Class 專門負責實體化這些類別。
特地這樣做有什麼好處呢?
舉個例子，假如我們現在有兩個繼承 Product 的類別，它們擁有共同的方法 Operation()，如下圖:

閱讀完整內容