以下是我自己的心得：（圖片版權都屬原作者，這些書也跟我一點關係都沒有）

首先我認為一定要看看的是這本Code Complete。雖然外觀看起來很厚，這本書的內容是由許許多多的經驗、統計等等的短篇文章所組成的，並不需要什麼專業知識就能看懂。由於是短篇性質，翻閱起來相當的輕鬆，許多內容也很簡單明瞭，翻過之後對於軟體的品質應該會有很直接的理解。另外還有幾本類似的書，像是編程創藝。

接下來就是第一個技能的分歧點了（？），在看這些書之前，還是建議先了解一點基礎的物件導向會比較好

Refactoring與Head First OOAD這兩本書，我認為是分別從不一樣的角度去教你「怎麼寫出好程式。」Refactoring是從一般常見的問題（bad smell）開始，告訴你為什麼那些情況是個問題，要如何去修改。Head First OOAD則是從規劃開始，告訴你怎樣規劃出一個好的架構，印象中也有稍微提到一些Design Pattern。

兩本都看完後，實戰上應該會有一些新的體會。接下來可以把Design Pattern當做廁所書翻翻，也就是沒事蹲廁所的時候翻他幾頁就好了。這本書不需要一口氣看完，所以可以慢慢當閒書看就好，有看有加分。

最後，你可以看看Refactoring to Pattern，讓你知道怎麼把重構與Design Pattern這兩個從不同方向的作法結合起來。

當然，我看過的書並不是很多，如果你有其他喜歡的書，也許可以讓這棵技能樹長得更豐富。

最早的時候，這東西的queue是用beanstalkd做的（我還寫了篇Beanstalkd的介紹。）剛開始一切都很順利，速度相當快。一直到production負載越來越高，beanstalkd開始不斷的吃光CPU。在始終找不到解決辦法的情況下把整個系統用Amazon SQS重寫

Amazon SQS算是相當的簡單易用，但是提供的功能也相當少，沒有retry，沒有delayed，只有一個很難用的visibility設定。SQS也替我們稱了相當久的時間，不過最後還是因為一些因素讓我開始考慮其他的解決辦法了：

1. 速度不快：將job push進queue的latency就從10ms ~ 500ms不等，在一個只有50ms左右的API request中實在顯得太慢了。而且不只是push進去慢，worker pull job的速度也不高。

2. 費用高：當job的量越來越大的時候，worker數量也越來越多。SQS的worker是採用不停去poll SQS的方式來取得job的。可是SQS每一個request都是要錢的！每次小小的費用累積起來也是相當的可觀

3. 難以管理：在使用的過程中，不管是要監控queue的job count，檢查worker status等等都非常的困難。在實務上常常會產生許多的麻煩。雖然在我寫文章的這時，看到amazon終於提供了基本的管理介面…

綜合以上理由，最後我還是決定把整個job queue搬到Resque上。Resque速度非常快，管理介面也相當好用，本身對job queue與worker的操作能力就不錯，加上各式各樣的plugin（目前用了resque-retry, resque-scheduler, resque-status），目前而言還算是相當滿意

許多大量使用Internal DSL的程式都會有一個特點，看起來非常像在寫configuration，程式碼中幾乎沒有邏輯運算的存在，只有許多的設定，像是最近手上的某個code：

  track :watch, :as => "impressions"
  track :click, :as => "clicks"

而整個軟體開發中，最常面對config的人是誰？是System Admin。

也自然這些用Ruby以及大量Internal DSL的管理套件會受System Admin歡迎了。

之前寫過這篇對Redis的心得

今天看到antirez寫的這篇 How to take advantage of Redis just add it to your stack。

我只是想說，看吧，人家引人入門的說法跟我一樣 XDD

Redis在最近當紅的NoSQL database中算是一個異類（事實上，許多人根本不把它當作一個database來看待），資料完全存在記憶體中，沒有auto sharding，沒有relation，甚至連處理persistent的機制都相當單純。缺少這麼多東西，Redis吸引人的到底是什麼？

1. 超高的效能：100000 sets/second，80000 gets/second(source)。就算在我的爛macbook上也是輕鬆做到每秒數萬次寫入。
2. 各式資料結構：任何有基礎程式設計能力的人，都知道選擇一個適合的資料結構的重要性。Redis給你現成的List, Set, Hash, SortedSet…等等，讓Redis用起來就像你的程式中的一個簡單的物件一樣。Ruby裡面你有現成的hash, array, set可以用，Redis用起來也差不多。這些資料結構要如何互相支援，對程式設計師來說也是早就有著相當的理解。因此你不需要另外學一套處理資料的思考模式，只要你有基本的資料結構知識，使用Redis應該是幾乎沒有門檻可言。網路上有相當多利用Redis這些資料結構的例子，我就不多提了。
3. Atomic Operation：Redis提供了豐富的操作指令，從基本的incr到複雜的ZREVRANGEBYINDEX都有，而且這些操作都是Atomic Operation。由於實際上你常常會把Redis當做是shared memory來使用，atomic就成為了相當重要的特性。
4. 簡單：compile redis甚至不需要configure，光這點就讓我眼睛亮了一下 XD。make下去你就有redis-server的執行檔可用了，沒有複雜的系統配置。

最近的心得是，Redis帶著強烈的Law of the Instrument（如果你手上有著搥子，在你眼中什麼都看起來像釘子。）在寫Web的東西的時候，常常會需要存一些資料，像是log，即時的數據，Preference…等等。這些資料沒有複雜到需要分析一下ER model，存到MySQL裡面也有點麻煩。Redis在這種時候就非常的好用。也很適合拿來搭建各種系統，像是Resque。

實際使用時，Redis就像是你在一堆process與server實體機器之間有一塊shared memory。不僅高效能、也有實用的資料結構。有許多人寫下了實戰的心得：Rubygems.org，Plurk等等。

總之，目前我並不認為Redis是可以完全取代Database用途的東西。但是Redis絕對是一個相當實用的東西，切中了原本Web development缺少的一塊。Redis本身也還有許多有趣的發展，像是最令人期待的Redis Cluster。作者做的許多嘗試也相當有趣，Redis有個branch甚至提供了lua scripting！想知道Redis背後的精神的話，可以看看這篇Redis Manifesto。

所有程式唯一不變的原則就是不停改變。

你有兩種方法可以面對改變：逃避、或是習慣它。

Facebook選擇了後者，每天都在Push新code

什麼東西能幫助你免除每次上production那戰戰兢兢的惡夢？文化

Facebook擴展的速度跟網站的規模應該是世上數一數二快的，一般小型網站處理Deployment的問題就常常讓人頭痛了，看他們怎麼解決這問題便是相當有趣。也許你會期待Facebook是不是又開發了什麼獨門技術解決這個難題。很可惜的是，影片一開始就告訴你，能解決這問題的是開發者的文化，而不是工具。

什麼樣的文化？貫穿影片的核心主軸就是

你為你的code負責，沒有別人會幫你

Facebook本身用了大量的工具來幫忙檢查程式碼品質：

1. IRC Bots：在你的code上production之前，你必須要先告訴IRC Bots你正在待命，否則你的code會被略過
2. 大量測試、自動測試：Unit Test, Selenium, Watir…大家都很熟，就不細講了
3. 分隔環境：除了基本的latest, sandbox…等等，Facebook有著GateKeeper的機制，可以直接控制要讓員工、特定地區、特定來源、特定比例的使用者看到特定的改變，從小修改到新功能都可以這樣設定
4. Push Karma：追蹤所有人搞砸的記錄
5. PerfLab：非常有趣的系統，記錄Production與Trunk的各種Metric，可以從圖表中輕易比較Trunk跟Production的差異，是否該Push了？Trunk是不是有問題？兩邊效能是否一致？都可以輕易目測
6. BT：用BT來同步Hiphop編譯出來的binary

從上面的列表可以看到，這些工具並不是非常的具有革命性。那Facebook跟一般人的差別在哪裡？答案是環境，與直達開發者的責任。

影片中提到，Facebook真正管理所有Deployment的團隊其實只有幾個人，他們怎麼管理數百人的開發者團隊？

一是前面提到的工具，讓他們能很快抓出問題的來源。

二是整個環境的責任制度，各團隊有專人on-call，出問題就是找他，他再找出製造這問題的人，便可很快處理問題。

開發者就是程式的主宰

#!/bin/bash
function f() {
  sleep "$1"
  echo "$1"
}
while [ -n "$1" ]
  do
    f "$1" &
    shift
  done
wait

example usage:
./sleepsort.bash 5 3 6 3 6 3 1 4 7

簡單的說，替每個input的數字建立一個thread，thread中就sleep該數字的秒數後，印出該數字。這真的太天才了 XDD

出處：http://dis.4chan.org/read/prog/1295544154

原討論串也是充滿各式各樣笑點，強烈推薦閱讀

忙碌中看到這個讓我笑到翻掉阿 XDD

為事物命名這件事，背後的意義通常有兩種

1. 你對這件事物有足夠的了解，因此可以替它取一個適當的名字
2. 你對這件事物有所期許，因此取了一個代表你的期許的名字

編程不就是如此嗎？若是程式架構中的一個物件、一個函式你可以輕易的取個正確的名字，通常代表著你對這個命名對象在架構中的定位有著足夠的了解。通常也代表你的設計正確且清楚。若是你沒辦法替這個東西想個名字，很可能你的程式架構出現了問題。（當然，也有可能只是單字量不夠。）

命名不只是給自己看的。取名的同時，也將你對這個東西的期許傳承給了下一個閱讀這段程式碼的人。你將一個東西叫做Adapter，下一個看到的人就會期待它是個按照Adapter pattern做出來的東西，或是單純的轉接了什麼protocol。

如同在為你的孩子取名一樣，一個名字決定了他將來的外號，可能決定了他交到什麼樣的朋友，甚至影響了他的自尊心。替變數命名也許不用這麼謹慎，但也不是可以輕忽的一件事。

首先，根據Richardson Maturity Model，在完全的REST之前可以分成四種程度：

1. The swamp of POX：單純的把HTTP當成RPC來用，沒有Resource的概念。譬如你要訂閱一份報紙，就會變成
   POST /subscribe_news?id=1234?type=free 之類的東西。

   此時每一個HTTP request都是單獨的action。

2. Resource：顧名思義，API的設計開始以Resource為中心。同樣的訂閱報紙會變成：
   POST /news 先取得報紙列表，然後
   POST /subscription 建立「subscription」的resource

   此時，每個HTTP request都是針對某個Resource在操作，而不是一個複雜的動作

3. HTTP verb：此時，你開始善用HTTP提供的get/post/put/delete，讓同樣的URL結合不同的HTTP verb來完成不同的動作。就如同舊文中Rails內建的resource一樣，不重複解釋。
4. Hypermedia Control： 或是你可以叫做HATEOAS ( Hypertext As The Engine Of Application State )。
   還記得REST的全文：Representational State Transfer嗎？HATEOAS講的就是「Transfer」

   大多數的RESTful API，每個request都是對某種Resource獨立的操作。你要怎麼知道取得news id之後要建立 subscription來訂閱新聞？大多數的情況是：看文件。

   而Hypermedia Control的重點就是：你回傳的Resource中，必須要包含接下來可以做的事情的資訊。
   當你回傳一個news resource的時候，你還要附上訂閱該news所要使用的URL，顯示該news內容所需要的URL…等等。例如回傳的news可能會變成：
   

   { :title => "World War III!", :date => "2011/12/25", :subscribe => "/subscription", :show => "/news/123" }
   

   
   好處是什麼？好處是client只要取得news resource之後，就能清楚知道下一步所要用到的resource是什麼，而且這個「下一步」是可以隨著Server API變動而跟著改的，因此Client不需要寫死下一步的HTTP request該發什麼。也就是所謂的「Discoverability of Actions on a Resource」

至於為什麼很少人做到第四階段的REST？有人認為因為目前的工具並沒有方便的支援Hypermedia Control。或著也可以說，大多數人連POST跟GET都分不清楚了，搞的懂REST的也沒幾個，還有很長一段路要走呢…

以前是用apns for Rails，不過這東西已經不支援Rails 3了
（再度證明，這種應該以library方式存在的東西沒事搞成plugin根本是自找麻煩）

搜尋了一下找到apns4r，不過裡面的code有點亂，也會撞到Ruby 1.9沒有把’.'放進load path的問題。

稍微修了一些Syntax Error（…）跟改用require_relative之後看起來是能用了，
暫時先丟在https://github.com/poga/Apns4r