其他

可理解的代碼非常重要，測試代碼也是如此。在我看來，優秀的測試代碼，必須做到一個重要的事情就是保持測試邏輯的清晰。一個完整的測試案例通常包括三個部分：1. SetUp2. Exercise3. Verifiy4. TearDown一 個測試案例如果能清晰的區分這三個部分，其實已經成功了一半。但是，如果僅僅只是做到這一步，離我們的“可理解的”測試代碼還有些距離。在我看來，要做到

 下載/Files/gpcuster/SmartContact.rar  Smart

最近Twitter開發了一款分布式即時統計系統Rainbird。用處Rainbird可以用於即時資料的統計：1 統計網站中每一個頁面，網域名稱的點擊次數2 內部系統的運行監控（統計被監控伺服器的運行狀態）3 記錄最大值和最小值效能要求作為大型網站的分布式應用，需要具備以下效能： 1 極高的寫入效能，可以達到100,000的WPS2 非常高的讀取效能，可以達到10,000s的RPS3 高度的可擴充性，包括讀取和儲存等等，能夠擴充到100+ TB的量級4

GTD，Getting Things Done的縮寫。來自於David Allen的一本暢銷書《Getting Things

自動化測試過程中，有一些基本的原則，就如同宣言(Manifesto)。由於大部分的原則在前面其實都提到的，因此，有的不做太多說明了。原則：Write the Tests First原則：Design for Testability原則：Use the Front Door First意思是說，從最外層暴露的publish方法開始測試。原則：Communicate Intent意思是說，測試案例要意圖明確，這樣才容易理解和維護。比如，命名時，使用Intent-Revealing

在這個激情四射的夏季，在這個充滿奇蹟的2008.讓咱們全中國人驕傲的奧運會正在北京舉行，在大家為中國加油，為奧運健兒加油的同時，部落格園正在為大家準備一個以程式設計來展現自己編程水平的模擬機器人足球比賽平台:)訂閱本系列文章 大家可以先看下面這個圖片 這個就是部落格園模擬足球比賽平台的啟動畫面。啟動這個平台以後，我們可以上傳2個由咱們自己編寫的足球隊伍，與該平台進行串連。

Hadoop的HDFS叢集非常容易出現機器與機器之間磁碟利用率不平衡的情況，比如叢集中添加新的資料節點。當HDFS出現不平衡狀況的時候，將引發很多問題，比如MR程式無法很好地利用本地計算的優勢，機器之間無法達到更好的網路頻寬使用率，機器磁碟無法利用等等。可見，保證HDFS中的資料平衡是非常重要的。在Hadoop中，包含一個Balancer程式，通過運行這個程式，可以使得HDFS叢集達到一個平衡的狀態，使用這個程式的命令如下：sh

需要調用svn去做一些操作時，有兩種方式：調用svn.exe命令列和調用svn api介面。我不太喜歡調用命令列的方式，是因為它需要依賴一個外部的exe程式，同時，為了得到命令執行結果，還需要去捕捉命令列的輸出控制台，然後去解析，使得不太可靠。因此，我選擇了調用svn介面的方式，因為我使用的是c#，有一個現成的第三方封裝的庫SharpSvn可以調用。SharpSvn首頁：http://sharpsvn.open.collab.net/使用起來很簡單，下面是一個例子：Code

Hadoop是使用Java語言開發的，但是有一些需求和操作並不適合使用java，所以就引入了本地庫（Native Libraries）的概念，通過本地庫，Hadoop可以更加高效地執行某一些操作。目前在Hadoop中，本地庫應用在檔案的壓縮上面：zlibgzip在使用這兩種壓縮方式的時候，Hadoop預設會從$HADOOP_HOME/lib/native/Linux-*目錄中載入本地庫。如果載入成功，輸出為：DEBUG util.NativeCodeLoader - Trying to

這本書找來很久了，一直沒讀。關於軟體測試的好書相當少，對於測試代碼的重構及模式的書就更加難得了。雖然我才讀了前幾章，給我的感受是，這本書確實講的很全面，並且給很多測試中的東西給出了專業的術語，相信當我讀完並吸收完這本書後，會有更多的體會和收穫。第一章是全書概述，直接跳到第二章開始我的筆記。Test Smell，測試的壞味道。和我們通常講的Code Smell是一樣的，不同的是Test Smell是從測試的角度來分析測試過程中的壞味道。測試的壞味道主要分為三類：code

之前調試一直在用print。。。很寒，其實在WingIDE中可以直接斷點調試GAE的，下面介紹兩種常用的方法：1. 在WingIDE中設定 dev_appserver.py為main debug file(右鍵 - Set As Main Debug File)，然後設定運行參數：appname

之前在測試Django應用時，使用了非常方便的django.test.TestCase。在測試Tornado時，我也封裝了一個TestCase類，提供和Django一樣便捷的測試方法。最終，測試案例的代碼將會是這樣：Code highlighting produced by Actipro CodeHighlighter

基本使用如下面這個shell指令碼：#Oracle的連接字串，其中包含了Oracle的地址，SID，和連接埠號碼CONNECTURL=jdbc:oracle:thin:@20.135.60.21:1521:DWRAC2#使用的使用者名稱ORACLENAME=kkaa#使用的密碼ORACLEPASSWORD=kkaa123#需要從Oracle中匯入的表名oralceTableName=tt#需要從Oracle中匯入的表中的欄位名columns=AREA_ID,TEAM_NAME#將Oracle中的

今天嘗試和比較了各種各樣的檔案搜尋替換工具，比如：Search And Replace, Actual Search & Replace, PowerGREP, AKS Text Replacer, TextCrawler, Quick Search and Replace, Multiple File Search and Replace 等等。我對工具的要求並不高，只要求支援：1. 支援正規的Regex2. 搜尋和替換時，有結果預覽3. 預覽結果支援代碼著色和高亮4.

文章目錄 不安全的方式安全的方式 無論是在Hadoop叢集中添加機器和刪除機器，都無需停機，整個服務不中斷。本次操作之前，Hadoop的叢集情況如下：HDFS的機器情況如下：MR的機器情況如下：添加機器在叢集的Master機器中，修改$HADOOP_HOME/conf/slaves檔案，在其中添加需要加入叢集的新機器（hp3）的主機名稱：hp3hp2dell1dell2dell3dell4然後在Master機器中執行如下命令：

文章目錄 自動化測試的目標 或許有人覺得單元測試可有可無，因為覺得需要付出太多的精力，而客戶並不需要它。這就涉及到投資報酬率的問題，其實所付出的用於測試的投資，往往會收穫到更多回報。它讓我們減少了Bug的數量，減少了調試代碼尋找Bug的時間。看，有效自動化測試投資下，測試和開發付出的努力的時間圖：

像我們用的cctray，可以設定.NET Remoting的方式添加一個主機，然後擷取伺服器編譯的結果並提供手工觸發編譯的功能。因為工作需要，我需要通過代碼查詢編譯伺服器當前的編譯狀況，擷取一些CCNET伺服器端的資訊。因此，我也通過.NET Remoting方式，輕鬆的取得了想要的一些資訊。首先，需要添加引用：ThoughtWorks.CruiseControl.Remote.dll，瞭解.NET Remoting的應該知道這個DLL定義的是遠程封送的對象介面。然後，調用也很簡單：Code

1、_stdcall是Pascal程式的預設調用方式，通常用於Win32 Api中，函數採用從右至左的壓棧方式，自己在退出時清空堆棧。VC將函數編譯後會在函數名前面加上底線首碼，在函數名後加上"@"和參數的位元組數。 int f(void *p) -->> _f@4(在外部組合語言裡可以用這個名字引用這個函數)2、C呼叫慣例（即用__cdecl關鍵字說明）（The C default calling

Regex 教程由於排版和篇幅關係，本文僅提供PDF版本：http://www.tracefact.net/document/Regular-Expression-Tutorial.pdf這裡列出本文的目錄：引言 什麼是Regex？ 準備工作 匹配單個字元匹配固定單個字元 匹配任意單個字元 匹配“”元字元 匹配字元組字元組的基本文法 在字元組中使用字元區間 反義字元組

這一章主要講自動化測試的原則。前面的章節介紹了很多測試的思想，而思想的東西難免有點虛，這一章就是告訴你，遇到了具體的什麼問題時，應該怎麼辦。作者諮詢了很多的開發人員和測試人員，同時也和Martin Fowler就自動化測試的一些原則問題進行了交流，有些是顯而易見的，有些又是讓人把握不定。因此，這章主要討論了以下幾個問題：Test First or Last? Tests or Examples? Test-by-Test or Test All-at-Once? Outside-In or