其他

Cuise提供了一些Restful Url，方便使用者來使用Cruise。目前這些Restful Url覆蓋三個方面（一）關於Artifacts的操作　　例如查看某個job有哪些Artifacts，以及通過API下載這些Artifacts，向某個已完成的Job上傳某些檔案。（二）關於Properties的操作　　例如查看某個job有哪些屬性，它們的值是什麼，以及為某個job增加一個屬性，做為一個Comment等。（三）關於組態管理的操作　　目前，Cruise可以通過Restful

同一個Feature的代碼要放在一起(IDE裡單獨的一個工程, 或者工程裡單獨的一個檔案夾), 這些代碼要麼全有要麼全無的, 它們合作完成一個Feature, 如果使用者不再需要這個Feature了, 可以把它們整個的痛快的刪掉, 不會留下誰也用不到的代碼成為系統的垃圾. 如果想看一個Feature是如何?的, 那所有相關代碼都在一起, 不需要在龐大的程式碼程式庫中跳來跳去.那麼理想的情況就是: 你看看原始碼樹裡所有工程檔案的名字, 或者檔案夾的名字, 就知道系統提供了哪些功能,

概念篇已經介紹了Cruise中出現的新名詞，今天就說一說Cruise的配置問題。由於Cruise幾乎提供了所有平台的安裝包，所以只要您瞭解各平台上安裝軟體的方法，您就可以輕而易舉地完成Cruise的安裝。現在，Cruise1.0的配置秉承開源項目CruiseControl的單一設定檔風格，但比CruiseControl要簡單的多。而且在Cruise1.0中提供了簡單的WEB介面編輯功能，儘管看上去非常簡陋，但總比沒有介面要方便一些的。（相信下一個版本在這方面會有較大的提高。）今天將Cruise的

文章目錄 誰來做Validation何時做Validation如何表達錯誤如何傳遞錯誤如何關聯錯誤到發生錯誤的對象圖, 尤其是對象圖中非Root對象一個額外的話題 誰來做Validation何時做Validation如何表達錯誤如何傳遞錯誤如何關聯錯誤到發生錯誤的對象,

文章目錄 Ubuntu (Debian):Mac OS:

CruiseControl傾向於通過源碼變化來自動觸發構建，但仍提供了幾種方式來定時觸發構建，以達到nightly building的效果。在開始配置之前，先說明一下config.xml檔案中Project元素的相關屬性。Project 元素對應你的一個需要構建的項目。其中：name為其指定名稱。buildafterfailed

自動化測試是持續整合的前提毋庸置疑，自動化測試是持續整合的前提。如果您的項目還沒有單元測試或功能測試代碼，那麼持續整合的意義就不那麼重要了。只有隨著項目的進行，不斷增多的自動化測試，才能突顯持續整合的重大意義。持續整合是代碼健康情況的指標或風向標。通過持續整合，可以儘早發現問題，提醒團隊成員儘早修複問題，得到更健康的代碼。持續整合有很多實踐，通過實際項目的經曆，總結三個基本實踐：一、儘早開始持續整合應該在項目初始階段就給予考慮，並在搭建開發環境的同時建立持續整合環境。而且，你最先check-in

 拿到一份對應屆畢業生的面試題：2． 問題：a)        請描述數組(array)和鏈表(link list)的相同點和不同點？答案：都是線性有序結構，數組是一塊連續的記憶體區，可以通過index直接存取，訪問速度較快，但是插入刪除要移動其他單元。增加長度時可能需要重新分配記憶體。佔用記憶體較少。鏈表每個儲存單元有指標指到下一個單元，佔用記憶體較多，插入刪除方便快速，只需要重設指標，增加長度無需重新分配記憶體。 b)        哪一個佔用記憶體少，哪一個插入刪除比較快。為什嗎？答案:

文章目錄 如何不帶來額外的效率損失如何在程式運行出錯時記錄儘可能多的資訊如何方便尋找特定條件的錯誤如何橫切的添加通用資訊  如何不帶來額外的效率損失如何在程式運行出錯時記錄儘可能多的資訊如何方便尋找特定條件的錯誤如何橫切的添加通用資訊 如何不帶來額外的效率損失在之前接觸的一個大型產品中見過散布著如下代碼:if (Log.Level > DEBUG) {    logger.write(some_method_to_build_the_

 原則一、首先要行動起來 改進多是些平常沒有做過的事情，不要在做之前就羅列出各種各樣做不到的理由。先試試，有不對的地方，馬上修正就好。 原則二、工作內容的可視化 要將工作的流程和進度，隨時都能被看得見。要將工作中的異常現象凸顯出來，並馬上採取措施。 原則三、生產效率的可視化 改進的好了還是壞了，不能搞不清楚。專註於能夠提高生產效率的改進。 原則四、現場和實物 不要紙上談兵，不去看現場，單憑想象依照過去的經驗就做出判斷。管理者要依據現場和實物來進行判斷。 一個組織在嘗試新的事物時，所遇到的障礙往往

文章目錄 1, 部署時如何方便的支援產品環境和測試環境, 即在不同環境下提供同一介面的不同實現2, 如何簡化配置, 使得架構能夠自動識別依賴3, 運行時如何動態切換同一個類型的不同實現, 比如使用者選擇了唯讀模式, 那麼所有的Save操作都應被忽略不做任何事, 可以通過提供Save操作的Dummy版本來實現4, 多使用者環境下, 如何保證每個使用者都有自己的對象組合而不互相干擾5, 對象的生命週期如何管理

原文：http://www.infoq.com/cn/articles/SOA-Agile-Friends-Or-Foes這是一篇關於SOA與Agile的討論，文章總結了當前使用這兩種技術的觀點。雖然沒有結論，卻也值得思考。其實，無論是敵？是友？都有共同的目標，那就是用技術為企業提供更大的價值。想一想，任何一種技術的產生都是同樣的理由。下面是該文的部分引用：敏捷與ＳＯＡ是朋友 

軟體從需求到發布是一個漫長的過程。而持續整合關注於軟體開發，即開發人員的每次代碼提交都會由持續整合工具進行構建。但到這個構建版本後，到將其真正部署上線還要走多遠呢？從持續整合那裡拿到好的Build以後，作為測試人員，部署到探索性測試（Exploratory

 問題: 如何減少跟某個客戶瞭解和確認並實現了的需求卻被他的同事推翻需重新設計和實現 具體的原因有很多，其中一點是一開始沒找對人.  一個項目，客戶那邊的stakeholder通常不止一個人，這些人有自己負責的領域. 他們也通常是某一領域的專家. 這裡專家的意見要參考，但要找負責的人確認. 所以首要的就是識別誰負責啥. 以CWP項目為例, 初始客戶那邊有4個人. 他們輪流到現場和Team Dev一起工作. 隨著客戶的輪換, 經常出現需求反覆的情況. 一段時間之後, 項目組瞭解了他們各自的職責. 

又是好一陣子沒有寫blog了，時間太少啦，也沒做回顧和反思。要不是朋友給我出了一個題兒，還真不一定什麼時候再寫呢。“如何才能把CruiseControl的結果反映到熔岩燈上面？”這個問題以前沒有想過，今天被朋友問到了，就查了一下資料，總結一下：1、使用真正的熔岩燈    需要準備：4-Piece Firecracker Automation System（ Cost: $39.99）2 lamps, preferably the kind that boil red and green

Cruise提供將任何HTML檔案作為一個子表單顯示到Web頁面上．我們每次在Build結束後就將EMMA的report放回到Cruise

今天在infoQ上看到一段視頻，一個敏捷專案經理分享了她的一次“客戶體驗”，並給出了一些建議。現將部分內容摘錄其中，詳細內容參見如下連結：Leading From A Position Of No Power: A Customer’s Perspective of an Agile Team。　清晰定義並維護好“客戶”這一角色，例如，向團隊傳遞項目願景，以及為什麼有這樣的願景；不要害怕衝突，要有建設性地利用衝突；客戶即使不能親力親為，也

在敏捷實踐中，“測試”毫無疑問地是一個經常談論的話題。然而，它也是經常被過分談論的術語，所以，當我們想討論“測試的種類”時，應該先瞭解一些細節。

網上已經有很多詳細解釋效能測試, 容量測試, 負載測試, 壓力測試各自的概念, 之間的聯絡以及區別, 還有騾子背東西等生動的例子...這裡按自己的理解re-statement一下其實所有的一切都只是幾個因素的相互作用, 互為函數: 並發量/資料量機器配置單個請求處理速度穩定已耗用時間A: 給定並發量/資料量，機器配置， 和必須的穩定已耗用時間，求單個請求處理速度（Example：所有請求都能在2秒內完成）B:

精益（Lean）從泰勒的”科學管理理論“，其思想源於消除浪費敏捷（Agile）的初衷是應對變化有觀點說：”敏捷是軟體行業中的精益“，但二者還是有一些區別的。精益可以說是一種比較完善的管理思想或理論，而敏捷可以說是一種做事原則或方法。精益是否發揮了作用，可以用實實在在的金融指標來衡量。而使用敏捷的效果還不能用金融指標來一概而論。敏捷如何發展呢？走向精益嗎？還是......？讓我們拭目以待吧。