略過導航

提昇軟體品質的閱讀順序

最近常常被問到要如何提高自己的程式品質… 除了大量的經驗之外，正確的閱讀順序我想也是很重要的

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

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

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

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

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

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

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

Background Worker: Beanstalkd, Amazon SQS, Resque

今天準備要把手上的東西從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 and System Administration

很久以前就想寫這段文字了，剛好最近看到這篇，就順便寫一下吧。

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

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

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

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

直接把Redis加入你的stack中吧，你不需要取代什麼東西

忙的要死所以沒辦法寫啥長文…

之前寫過這篇對Redis的心得

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

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

 

 

Redis: Your utility belt, just like batman!

標題代表著最近幾次玩弄Redis的感想

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。

Follow

Get every new post delivered to your Inbox.