如何寫出 User Story

什麼是 User Story?

User Story 是一段簡單的功能敘述，以 客戶或使用者的觀點 撰寫下有價值的功能(functionality/feature)。與其說它是規格文件(documentation)，不如說它代表(represent)客戶的一個需求而已，因為實做細節將延後至開發時才會確定。

幾個 User Stories 的範例如下：

• 使用者可以在網站上張貼履歷
• 使用者可以搜尋有哪些工作
• 公司可以張貼新工作
• 使用者可以限制誰可以看到他的履歷

Deferred 與 Promise 的差異

在談Promise 之前，我們先來了解一下 CommonJS.org

CommonJS.org

CommonJS 是一個致力於將 JavaScript 生態圈標準化的計畫，尤其是針對瀏覽器以外的應用環境，也因此第一個版本的名字叫做 ServerJS。
CommonJS 的終極目標是制定一個像 C++ 標準庫一樣的規範，也就是介面，使得基於 CommonJS API 的應用程序可以在不同的環境下運行，就像用 C++ 編寫的應用程序可以使用不同的編譯器和運行時函數庫一樣。為了保持中立，CommonJS 不參與函式庫的實作，而是交給像 Node.js 之類的項目來完成。

而不少開發者向 CommonJS 提出 Promise 的規範草案，但是一直未被列入正式規範，有著 Promises/A, B, KISS, C, D 等版本。其中以 Promises/A 的提案最為簡單，也最常被大家提及。

值得一提的是：Promise/B, D 的提案人是知名流程控管套件 Q.js 的作者 Kris Kowal

滿有趣的一點是：Node 團隊在前年左右放棄繼續遵守 CommonJS 的規範。Isaac 指出 "Ryan basically always gave zero fucks about CommonJS anyway" ，並轉述了 Ryan 的一句重話 : "Forget CommonJS. It's dead. We are server side JavaScript."
有興趣可以看看這個Github的討論串：https://github.com/joyent/node/issues/5132#issuecomment-15432598
( Issac 是 NPM 的作者， Ryan 是 Node 之父 )

你還在為了UI-binding使用肥肥的Angular嗎？試試這些前端函式庫吧！

從 jQuery 到 Angular

從最早的 jQuery 以後，各種前端framework百花齊放：Backbone, Knockout, Ember, Angular....
其中 Angular 狹著 Google 的大名，可以說是在前端世界中呼風喚雨，但是許多人使用Anugular一段時間以後才發現入門容易但是深入難，而且隨著專案的複雜性增加，也開始踩到了各種地雷。因此也有人用這張圖來揶揄模擬Angular的學習曲線：

UI only

許多人開始發現，很多狀態下他們幾乎只需要 Data-UI binding 的功能，React.js 這個 facebook 御用、注重高效render 的 Library 就開始受到廣大的目光關注... React不是個完整的framework，只是專注於View的Library，因此更輕量、也更能與其他framework整合、相容。React官網是這麼說的：

Just the UI
Lots of people use React as the V in MVC. Since React makes no assumptions about the rest of your technology stack, it's easy to try it out on a small feature in an existing project.

但是！

React 推薦使用 JSX 在程式碼中勾勒 template，這點我就真的不行了，覺得髒髒的。所以我實在無法接受 React。

但是幸好這是一個前端技術大爆炸的時代，我們還有很多選擇....

手機網頁必會技巧！HTML meta viewport 屬性

什麽是Viewport

手機瀏覽器是把頁面放在一個虛擬的「窗口」(viewport) 中，通常這個虛擬的「窗口」(viewport) 會比螢幕寬，這樣就不用把每個網頁擠到很小的窗口中（這樣會破壞沒有針對手機瀏覽器優化的網頁的布局），用戶可以通過平移和縮放來看網頁的不同部分。移動版的 Safari 瀏覽器最新引進了 viewport 這個 meta tag，讓網頁開發者來控制 viewport 的大小和縮放，其他手機瀏覽器也基本支持。舉例來說，一個常用於RWD優化過的頁面上，常會有這樣的程式碼：

<meta name=”viewport” content=”width=device-width, initial-scale=1, maximum-scale=1″>

Viewport的屬性

• width：控制 viewport 的大小，可以指定的一個值，例如600或者其他的值，如 device-width 為設備的寬度（單位為縮放為 100% 時的 CSS 的像素）。
• height：和 width 相對應，指定高度。
• initial-scale：初始縮放比例，也即是當頁面第一次 load 的時候縮放比例。
• maximum-scale：允許用戶縮放到的最大比例。
• minimum-scale：允許用戶縮放到的最小比例。
• user-scalable：用戶是否可以手動縮放

其中特別需要注意的是 width這個屬性，比較不容易搞懂。
舉例來說，當你的頁面沒有經過RWD優化，最適合的解析度是960px寬，因此有些使用者拿著螢幕800像素寬的手機時，會無法看到右方160px的區塊，必須進行橫移或縮放。
而你希望使用者無論拿著多大的手機，看到你的網頁時都能夠從左到右完整顯示的顯示網頁內容。於是你就需要設定width為960px，此時無論是480px, 640px, 800px 甚至是 1280px寬的手機，都會調整顯示比例至能完整顯示800px的寬度。
當然，手機的解析度是不可能變的，於是小手機上看到的內容就會比較模糊不清，畢竟他是試圖使用480px來顯示960px的內容。

Reference:

穆乙's Blog: http://www.cnblogs.com/pigtail/archive/2013/03/15/2961631.html

初探 Python Decorator

最近剛巧聽到朋友介紹 Python 的 Decorator。
一開始以為是指 design pattern，後來才發現原來是Pyhton特有的一種語法糖，其實有點合成函數的味道。

舉例來說，有一個取得商品價錢的函式：

def get_price(product_id):
    ...
    return price

但是為了慶祝聖誕節，有的商品打八折，有的商品則是大打五折
而該打幾折的程式是由另一個函式判斷:

def christmas_discount(func):
    discount = get_discount()
    def get_christmas_price(product_id):
        return func(product_id) * discount
    return get_christmas_price

這時我們可以用這兩個程式合成一個新的程式：

get_price(21) // ==> 200
get_price = christmas_discount(get_price)
get_price(21) // ==> '160'

但是我們可以用 decorator語法糖「掛上」合成的函式：

@christmas_discount
def get_price(product_id):
    ...
    return price

get_price(21) // ==> '160'

Functional Programming vs OOP:

在OOP中也有所謂的裝飾者模式，具體的講解可以參考 良葛格的文章
這裡就可以看出：原本許多在OOP需要特別實作的設計模式，在Python或JavaScript等函數式語言中都能夠很直觀、輕鬆的被實作出來。
常見的Factory模式也是一樣的道理，在JS中能夠被輕易的實作。

Git 小筆記

跟 git 太不熟了，在這邊堆放一些常用筆記

Branch:

git branch //看local branch(星號代表現在所在的branch)
git branch <bar> // 新增 "bar" branch
git branch -D <foo> // 刪除 "foo" branch

Checkout:

git checkout <bar> // 切換到 local 的 "bar" branch
git checkout -b <NewBranch> // 新創一個 branch 並同時 checkout 它

註：如需從origin拉下一個branch，需在本地創一個branch，checkout 後再拉 "origin/branchname"。eg. "git pull origin test"

回溯：

git log // 取得過往的commit，其中以 hex code 為 id
git checkout <hex code> // checkout 過往 commit
git show // 顯示當前所在
git checkout <branchname> // 回到 local 最新commit，eg. "git checkout master"

Tag:

git tag -l // 列出所有 tags
git tag -a <tag name> <hex code> // 針對某一 commit 打 tag
git push origin --tags // 上傳所有本機 tags 到 遠端

[SQL] Common Table Expression (CTE)

CTE 簡單來說就是依據一定的查詢條件建立一個暫時的 table ，以便重複性的 Subquery 查詢。

舉例來說，我需要從 pc, laptop, printer 三個 Table 取最貴的產品出來，想像的寫法可能是如此：

SELECT model FROM (
    SELECT * FROM pc
    UNION
    SELECT * FROM laptop
    UNION
    SELECT * FROM printer
)
WHERE price=(
    SELECT MAX(price) FROM (
        SELECT * FROM pc
        UNION
        SELECT * FROM laptop
        UNION
        SELECT * FROM printer
    )
)

我們會發現三個 table 的 UNION 被重複使用，非常麻煩。
這時我們可以將這三個 table 的 UNION 暫存成 CTE，藉由以下的方式。

WITH product AS (
    SELECT * FROM pc
    UNION
    SELECT * FROM laptop
    UNION
    SELECT * FROM printer
)

SELECT model FROM product
WHERE price=(
    SELECT MAX(price) FROM product
)

TADA~~~是不是簡單明瞭又方便勒？