不過根據 LiveScience 的文章1，應該完全不要裝這些通知外掛才對。 :p
原本離線使用 Gmail 的時候無法上傳附件1，但最近加上了這項支援。
所以要寄檔案時不必先注意自己是不是處於連線狀態了。
還沒有開啟離線功能的人，可以從這裡開啟。
消息來源：Official Gmail Blog: Send attachments while offline
一圖勝千文：
消息來源：Let your subscriptions' personality come through
剛剛在 JavaScript的中介編程與反射能力示範 讀到兩個 metaprogramming 的範例。
我覺得其中 foreach() 的例子怪怪的。
先來看看維基百科上對 metaprogramming 的定義：
Metaprogramming is the writing of computer programs that write or manipulate other programs (or themselves) as their data, ......
回過頭來看該篇文章所實作的 foreach()：
它接受並調用一個函數（f）以及存取一個物件（this.props），但是並未產生或是修改到任何「程式」。
我不懂作者怎麼會拿它當作 metaprogramming 的例子。
不過文章中另外一個例子——accessor()——就是個很典型的 metaprogramming 範例。
最近買了新手機，第一件事情就是找好玩的遊戲趁手的工作事項管理軟體，若是針對 GTD 設計的更好。
以下是我這兩天的試用心得：
Astrid Task/Todo List - 單純的工作清單（task），可以設定 priority 與 tag。
Shuffle - 典型的 GTD 工具，有 inbox、project、context 三種主要檢視模式。
最後是 Shuffle 以使用流暢性取勝！
另外還有兩套我沒有花很多時間試的：
.png)
.png)
.png)
.png)
.png)
我以為 "template method" 改用組合就是 "strategy" 了 :p由於 Plurk 會限制字數，不太適合發表長篇大論。所以我打算透過這系列文章把想說的東西表達清楚一點，並且討論一下這兩個 pattern。
不過我想會分成兩種 pattern ㄧ部分也是因為靜態語言的特性使然吧
程式碼太長的後果是沒人知道這一大段東西到底在幹嘛，因而不敢（或不願意）去修正它。要怎麼判斷一個函式是否太長了呢？有個我很喜歡的簡單準則，大家可以參考一下：
一個函式的長度不應該超過螢幕能顯示的範圍。
變數或是函式的名稱應該要清楚地說出變數與函式的用途。現在的編輯器都支援名稱提示與自動完成的功能。不要為了想少打幾個字，而取那種過了一個星期之後連你自己都不知道是什麼意思的式名稱。
註解裡面只要指出程式碼裡面沒有的東西（參數格式、呼叫此函式前應該被滿足的條件等...）就好了。最好可以搭配一些文件產生工具（如 javadoc）自動地產生說明文件。
不要用一些奇技淫巧來賣弄你的程度，因為日後可能連你自己都看不懂你在寫什麼。遵守 "KISS" (Keep It Simple and Stupid) 與 "DRY" (Don't Repeat Yourself) 這兩個原則，自然就可以寫出易讀好懂的程式碼。
cd /path/to/project git symbolic-ref HEAD refs/heads/new-branch-name rm .git/index git clean -fdx # create some files git add . git commit這樣會建立一個沒有 parent 的新 branch.
