Programming, Life
最近常常被問到要如何提高自己的程式品質… 除了大量的經驗之外，正確的閱讀順序我想也是很重要的
以下是我自己的心得：（圖片版權都屬原作者，這些書也跟我一點關係都沒有）
首先我認為一定要看看的是這本Code Complete。雖然外觀看起來很厚，這本書的內容是由許許多多的經驗、統計等等的短篇文章所組成的，並不需要什麼專業知識就能看懂。由於是短篇性質，翻閱起來相當的輕鬆，許多內容也很簡單明瞭，翻過之後對於軟體的品質應該會有很直接的理解。另外還有幾本類似的書，像是編程創藝。
接下來就是第一個技能的分歧點了（？），在看這些書之前，還是建議先了解一點基礎的物件導向會比較好
Refactoring與Head First OOAD這兩本書，我認為是分別從不一樣的角度去教你「怎麼寫出好程式。」Refactoring是從一般常見的問題（bad smell）開始，告訴你為什麼那些情況是個問題，要如何去修改。Head First OOAD則是從規劃開始，告訴你怎樣規劃出一個好的架構，印象中也有稍微提到一些Design Pattern。
兩本都看完後，實戰上應該會有一些新的體會。接下來可以把Design Pattern當做廁所書翻翻，也就是沒事蹲廁所的時候翻他幾頁就好了。這本書不需要一口氣看完，所以可以慢慢當閒書看就好，有看有加分。
最後，你可以看看Refactoring to Pattern，讓你知道怎麼把重構與Design Pattern這兩個從不同方向的作法結合起來。
當然，我看過的書並不是很多，如果你有其他喜歡的書，也許可以讓這棵技能樹長得更豐富。
今天準備要把手上的東西從Amazon SQS完全的換到Resque了
最早的時候，這東西的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的感想
Redis在最近當紅的NoSQL database中算是一個異類（事實上，許多人根本不把它當作一個database來看待），資料完全存在記憶體中，沒有auto sharding，沒有relation，甚至連處理persistent的機制都相當單純。缺少這麼多東西，Redis吸引人的到底是什麼？
最近的心得是，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。
