其他

我在閱讀Ken Schwaber所著的《Agile Project Management with Scrum》一書，就對ScrumMaster的其中一個職責抱有懷疑的態度。Scrum要求ScrumMaster保證開發人員在一個Sprint（衝刺）過程中，不受到其他無關人員尤其是上司們的幹擾。真的能做到這一點嗎？即使ScrumMaster通過有效地與Product Owner溝通，確定了Product Backlog；然後我們開啟了一個Sprint，並確認了Sprint

期限（Deadline）是軟體從業人員必須面臨的最大困難與挑戰，準確地說，它是所有程式員包括專案管理者的可怕夢魘。當堂吉珂德看到郊野之上的數十架風車，風車的翅翼如巨人的胳膊，正耀武揚威地奚落著這位中世紀後期沒落的騎士時，堂吉珂德如勇敢的鬥士一般，躍馬而上，用長槍狠狠地刺向風車，換來的卻是長槍折斷，人仰馬翻，最後大敗而歸。沒錯，期限之於程式員，正如風車之於堂吉珂德，確實是太強大以至於無法戰勝。那麼，我們真的要知其不可為而為之嗎？就像孟子老夫子說的那般，雖千萬人吾往矣！雖然充滿了風蕭蕭兮易水寒的悲壯

本系列的第 1 部分 介紹了有關架構設計師以及 SOA 架構的知識，分析了 SOA 架構師在設計 SOA 系統架構時有哪些應該特別注意的地方。本文將延續第一部分的內容，向您介紹了 SOA 為企業級架構設計帶來的影響，以及在構建基於 SOA 架構的企業系統時應該怎樣保證所構建的系統架構能夠滿足系統中不同的服務等級需求。1. SOA 為企業級架構設計帶來的影響1.1 SOA 的特點及其使用範圍SOA 既不是一種語言，也不是一種具體的技術，它是一種新的軟體系統架構模型。 SOA

企業的運行價值鏈分為三步：發現價值，生產價值，收穫價值。我認為，TDD的價值鏈也可以如此劃分。本文的目的，關鍵在與體現TDD的價值，並以一個實際的例子，力圖闡述TDD的重要性。最後，我認為，TDd內力精深，大約分為四種無上之力：1、 驅動力——驅動程式代碼編寫；2、 學習力——新兵訓練營之絕佳教材；3、 自信力與他信力——bug降到最低；4、 控制力——與重構緊密接合，牢牢控制開發過程；關鍵字：價值鏈、TDD、NUnit、重構、單例模式、原廠模式全文連結：《從企業的運行價值鏈說起——我眼中的測試

      <bindings>        <netTcpBinding>          <binding name="sharePortBinding" closeTimeout="00:02:00" receiveTimeout="00:05:00"            sendTimeout="00:02:00" maxBufferPoolSize="524288000" maxBufferSize="655360000"           

WCF Tips之三WCF支援對Stream對象的操作，尤其對於傳遞size過大的訊息而言，如要考慮傳遞訊息的效率，WCF推薦通過Stream進行操作。然而，WCF對於Stream操作規定了一些限制，在我們編寫相關程式時，需要特別注意：1、綁定的限制如果需要使用Stream操作，可以使用的綁定只能是BasicHttpBinding，NetTcpBinding以及NetNamedPipeBinding。此外，在使用Stream操作時，不能使用Reliable

原文名稱：Entity Framework 4.1: Optimistic Concurrency (6)原文地址：http://vincentlauzon.wordpress.com/2011/04/17/entity-framework-4-1-optimistic-concurrency-6/看到 Entity Framework 4.1 推薦英文教程，為了幫大家看起來方便一些，簡單翻譯一下。這是一個系列，共有 8 篇，這是第 8 篇。Entity Framework 4.1 之一 :

在InfoQ最近發表的一篇文章《實施TDD時的常見問題》中，Chad Meyers提出了關於TDD實施的問題，如下所示： 我該容忍多大限度的預先設計？你怎麼知道應該何時停止（也就是說，“當人們開始討論演算法，就是該測試的時機了”）？ 對於象“我心裡清楚我們需要這個”這類東西——我們該如何處理（例如，在控制台main()方法中加上一個try/catch{Console.WriteLine(ex);}？）

  初次使用Nunit進行單元測試 本樣本出自以下連結每個.NET 開發人員應該下載的十個必備工具http://www.vckbase.com/document/viewdoc/?id=1303#NUnit 關於TDD相關文章參照idior的以下連結http://www.cnblogs.com/idior/category/18786.html 關於NUnit的詳細使用方法參照以下連結http://www.cnblogs.com/confach/archive/2005/06/20/177817

WCF Tips之一集合元素類的定義如下：Code highlighting produced by Actipro CodeHighlighter (freeware)http://www.CodeHighlighter.com/-->    public enum FileType    {        TXT,DOC,HTML,OTHER    }    [DataContract]    public class Document    {        private string 

    最近因為系統的擴大,發現以前的軟體實在是越來越難維護,每次都要業務經理給我講清楚商務程序,我在給程式員講清楚相關的商務程序,然後才可以進行開發維護.以前的專案經理沒有留下任何文檔,都要我來理清業務,書寫文檔等事情.頭大之餘在網上看到了SOA,這裡談下自己對SOA的理解.   

中國有句老話－－無規矩不成方圓，所以，我們並不缺乏對規範的重視。我們認為有了周全的規範，就能保證產品的品質，獲得更高的生產效率。最近，我加入了一家培訓機構（本文涉及公司的內容並沒有通過公司，並且現在發展前景還是有些不清晰，所以不具名），公司為了提高長遠競爭力，大力推行正常化（估計總部公司有高層對CMM比較感興趣和瞭解，所以這套正常化還確實不簡單，非常的詳盡，也有一定的指導性），只不過這套規範讓我覺得離實際工作比較遠，並不能太多的改善我們的工作效率，也不會真正的保證工作品質。思考其原因，我覺得公司

我有這樣的一個經驗，當你拿著你的proposal去和你的客戶洽談，希望通過超強的技術拿下這個項目時，往往不能如你所願。誠然，當你炒出一大堆概念，例如物件導向設計、設計模式、AOP、敏捷或者SOA，客戶的談判代表往往會為你口若懸河的一番談吐而佩服得五體投地，甚至於暈暈乎乎，但客戶總能把握自己最後的底線，“咬定青山不鬆口”。終究說來，要去洽談項目，除了要看公司的實力、項目經驗以及業務人員的關係之外，客戶最關注的還是你的WBS和報價，以及項目或產品的交付時間。所以談方法，可以讓客戶佩服你，卻不能讓客戶

流程說明： 需求階段： 形成基本穩定的需求文檔後，測試介入需求評審，以便瞭解需求的相關內容以及測試工作的可行性分析（軟體可測試性）。專案經理制定專案計劃，測試部門測試 經理/測試團隊負責人制定測試計劃，項目組測試人員閱讀相關測試需求文檔，如果存在疑問或者發現需求缺陷及時與需求人員溝通，如果是需求缺陷，可以將相 關問題可以記錄到bug管理工具以便進行跟蹤。 設計階段：

   在敏捷開發過程中，我們還需要對系統架構進行設計嗎？事實上，Martin Fowler在《Is DesignDead?》一文中已經給出了答案，那就是我們同樣不能忽略對系統架構的設計。與計劃性的設計（PlannedDesign）不同，我們需要演化式的設計（EvolutionaryDesign）。在敏捷開發的生命週期中，我們通過每一次迭代來豐富與更新我們的設計方案，以使其最大限度地符合客戶對系統的需求。這裡所指的需求，包括功能性需求和非功能性需求。    在Agile

原帖：再問TDD：擴散角模型有關測試“後行”也可以接受的說法，說明了一個事實：即使是最中堅的測試粉絲，也經常需要修正自我。很多理論拋出來之後，在現實面前，都不斷的妥協。一些妥協到基本完善，一些妥協到基本完蛋。說實話，我表面上是一個保守派，其實骨子裡是個激進派。幾年前我的想法深度和廣度都不足，實際上也非常容易跟潮流；

Justin Smith在MSDN雜誌上發表了文章《使用 WCF 和 .NET Framework 3.5 進行 HTTP 編程》，暢談了WCF 3.5對於HTTP編程的改進。以下幾點值得關註：.NET Framework 3.5 中的 WCF 構建於 .NET Framework 3.0 的擴充點之上，從而為構建符合 Web 原則的服務提供一流的支援。它包含一個便於使用的 HTTP 編程模型、JavaScript Object Notation (JSON) 訊息傳遞功能，以及新的整合

做項目的時候，我們都有很好的計劃，也在不斷的強化風險承受力等等~~~ 但事實上，Devolpment完了，到了test和UAT的時候了，通常時間處於這個階段的時間都比計劃安排或者領導認為需要的時間要長的多。程式員一次又一次的收到bug report 和new changes。這裡面new changes

幾天前，InfoQ發表了文章《給敏捷團隊發獎金就像在刀尖上跳舞》，單從標題就可以看出其中的“驚心動魄”，顯然我們需要高超的技藝，以及皮粗肉糙的腳底，就像某些非洲土著那樣，方才能夠遊刃有餘地舞動在刀尖之上。確實如此，通過發獎金的形式來激勵團隊成員，本身就是一把雙刃劍，弄得不好，可能就會破壞團結，導致彼此之間的矛盾與衝突，這對於一個團隊而言是絕對致命的。然而，如果一個團隊缺乏合理的激勵方式，又無法調動成員的積極性。如何取捨，真是傷透腦筋。現在，讓我們思考一個情境。項目成功結束了，要獎勵整個團隊與團隊

《Windows Communication Foundation之旅》系列之四六、定義DataContract我在介紹如何定義一個ServiceContract時，舉了這樣的一個例子，代碼如下：[ServiceContract]public class BookTicket{ [OperationContract] public bool Check(Ticket ticket) {  bool flag;  //logic to check whether the ticket is