其他

1. 用記事本編寫如下代碼.assembly HelloWorld{}.assembly extern mscorlib{}.class HelloWorld extends [mscorlib]System.Object{ .method public static void HelloWorld() { .maxstack 1 ldstr "Hello World" call void

看了什麼是真正的目的一文，有類似的一些感受，說說自己的想法。敏捷思想就是那四條敏捷宣言和十二條基本原則，很抽象也很乏味。就好像那個著名的“見山還是山，見水還是水”

update:有道有兩道題，這裡特指第一道題，因為我沒仔細看第二題。 這幾天有道的兩個題目成了討論的焦點，大家貢獻了一些解法，貼出了自己的代碼，還引出了演算法重不重要、要不要OO一下的討論。在我看來，這幾天的討論是有問題的。首先，演算法有沒有意義，重不重要？ 可以肯定的是，演算法是重要的。他是電腦科學的重要組成部分，廣義的說任何程式邏輯都是演算法，程式＝資料結構＋演算法

需求：    客戶需要網站支援多種外觀, 包括顏色, 圖片以及某些頁面的結構和功能. 網站的大部分內容布局和功能是一樣的,但是某些頁面(首頁,masterpage)的布局和功能內容每個外觀都不一樣（光看首頁的話可能會當成不同的網站，或許要的就是這種效果 ：p)。 當使用者訪問網站時根據不同的網域名稱顯示不同的外觀。思路:    使用asp.net theme進行css的選擇實現不同的主題。 使用url rewriting重定位某些頁面達到不同外觀有不同布局功能的目的。

好的名字總是能為代碼的可讀性做出重大貢獻，而這種貢獻是通過對事物進行抽象實現的。想想一下我們平常說話時所用的語言，比如說“我家的狗跑的很快”，“家”、“狗”和“跑”都是抽象，它們分別代表了不同的含義，如果不適用這幾個抽象的詞彙，而是直接說它後面所代表的含義，恐怕幾十句話都說不完。不信的話，你可以試試定義一下什麼是狗，什麼是跑，保證不是那麼容易的事。抽象可以說是軟體設計和開發中的核心概念，對變數、方法、類、介面、包等元素的命名，都包含了抽象過程。例如方法，方法的名字應等價於方法內部所有代碼的功能，

最近在做一個支援多種外觀的網站，主要使用不同的CSS定義改變外觀。由於現在可以換膚的網站並不稀奇，而且ASP.NET 2.0也內建了對主題的支援，因此從技術上實現並不困難。然而在實際項目進行中，出現了不少前台UI的問題。這個項目是一個改造項目，對已有的網站添加功能，並修改UI樣式。新的樣式由其他的公司設計，我們拿到PSD圖後由UI工程師轉換成HTML+CSS表示，然後編程人員將HTML,CSS倒入到項目中，添加代碼。問題1：項目開始不久，我們就發現很多設計出來的HTML,CSS並不好用。

是的，你沒有聽錯，我說的確實是“慢”，但如果敏捷關注的是慢，我為什麼還要用敏捷呢？ 

原文地址：http://blog.briandicroce.com/2008/03/14/three-index-cards-to-easily-remember-the-essence-of-test-driven-development/當我瀏覽ObjectMentor的部落格的時候，其中一篇Tim Ottinger的“TDD on Three Index Cards”引起了我的注意。他回憶了他是如何在不到15分鐘的時間裡，用三張索引卡來教授什麼是TDD基本原則的過程。我看了以後想：“恩..

   如果一個對象擁有非託管資源，則應該實現IDisposable介面，這樣調用方可以在使用之後及時釋放資源。   有很多關於.Net的書籍和文章都描述了如何?IDisposable介面，但是幾乎每一篇實現的都不完全一樣，這裡將幾個主要的實現進行合并，試圖找出能夠適應絕大多數條件的實現方法。      實現代碼    1namespace Disposable 2{ 3    public class ResourceBase:IDisposable 4    { 5        privat

今天看了一下Cucumber和Cuke4Nuke。前者是ruby社區流行的BDD架構，它使用一種叫做Gherkin的語言來描述story和scenario，然後使用ruby來實現這些scenario。而Cuke4Nuke則可以讓你用.NET上的語言（比如C#）來編寫scenario的實現部分。相比於在IronRuby下直接跑cucumber，你可以用熟悉的語言（C#）來寫測試，也省去了在IronRuby中調用C#代碼引入的額外複雜性。拋開BDD的本來意圖，這樣將scenario實現為自動化測試的

TDD已經發展多年，然而卻仍未能普遍成為日常開發的實踐之一，很多人在嘗試使用TDD時遭遇了困難，並對TDD心存疑惑。我並非TDD方面的權威或專家，但希望能將我的經驗和感想記錄下來，希望能對某些仍對TDD有所困惑的人有所協助，同時也希望能夠聽到不同的聲音，共同交流與討論。  本教程不是工具的使用教程，也不是TDD入門知識普及教程，因此這裡不會告訴你TDD是什麼，TDD的工具如何使用。關於TDD的基本概念和工具的使用，已經有很多文檔可以參考，請自行學習。 測試驅動開發之可執行檔文檔

前幾天看到一個關于敏捷的比喻，覺得很好。如果你喜歡登山露營的話，應該知道每次出去都要帶很多東西，比如帳篷、睡袋、手電、水、事物、指南針等等，通常都會裝滿滿的一大包。這些東西通常都會用到，特別是在碰到一些意料不到的情況時，可以說萬全的準備是非常必要的。但是這些東西同時也會帶來負擔，你帶的東西越多，你的負重就越大，體力消耗會很大，走路也會慢下來。對於有經驗的人，他會根據經驗從包裡拿出一些東西，減輕包的重量，從而加快行進的步伐，節省更多的體力。但是拿出的這些東西絕對不是隨意的，在水源豐富的地區可能不需

最近在看Refactor your wetware這本書，裡面提到一種收集靈感的方法：每天早上醒來，第一件事就是拿起筆，在紙上寫字，腦袋裡面出什麼就寫什麼，不要刻意的去思考，就是把腦中浮現的東西寫出來，滿滿寫上10頁，並且一定要堅持。據說由於大腦還處在不太清醒的狀態，可以抑制經常使用的左腦，從而更多的傾聽右腦的聲音。 這個方法看起來真的很stupid，但是TDD看起來也很stupid，Pair

TDD已經被證實為一項可以提高軟體品質的基本實踐，然而對於很多程式員來說，在抱著嘗試一下的想法實踐的時候，卻困難重重。這裡面有多方面的因素，比如環境，比如編程習慣，比如不會寫測試案例等等。TDD是一項實踐性很強的事，就像OO一樣需要大量的實踐來獲得經驗，因此如果能在平時養成寫測試的習慣，從簡單到複雜一點一點進行練習，就能慢慢的掌握TDD了。這裡建議初學的人可以考慮先寫代碼後寫測試，等到測試寫的很熟練了再轉到先寫測試後寫代碼的階段。先說說如何先寫代碼再寫測試：

本篇基本上是我這幾天參與的討論的一個總結，首頁問題似乎也討論過很多次了，本次討論又從經濟學的觀點出發，令人耳目一新，同時也學到了不少知識。我無法從經濟學方面給出任何的東西，因此我試圖從另一個方面提出一個方案。在我看來，首頁問題牽扯到幾類人發貼的菜鳥發帖的老鳥看貼的菜鳥看貼的老鳥審核人員（決定是否將文章從首頁撤下）這裡的菜鳥與老鳥指文章水平的高低，沒有具體的標準和分界線，大家可以根據我的描述大致對號入座。同時任何一個人可能在某一方面是菜鳥，而在另一方面是老鳥，因此有些人可能會在不同時間扮演不同的角

最近又在首頁看到幾篇設計模式相關的學習隨筆。回想起來，這幾年在園子裡發布的有關設計模式的隨筆都有一個共同的特點。那就是Factory和Singleton居多，如果是系列的，也往往是從這兩個模式開始的。由於能夠堅持把《設計模式》中所有模式都寫完的非常少，所以基本上也很少見到有關其它模式的隨筆。 這種情況也很好理解，因為《設計模式》這本書就是按照這個順序來的。最先講述的就是Abstract Factory模式，於是它排第一也無可厚非；排第二的Builder基本不太容易見到；第三的Factory

文章目錄 1.1 依賴關係1.2 面向介面編程2.2 IoC容器依賴  目錄 1. IoC使用簡介與原理  1.1 依賴關係  1.2 面向介面編程  1.3 IoC使用與實現原理 2. 模式與經驗  2.1 code configuration vs. xml configuration  2.2 IoC容器依賴 1. IoC使用簡介與原理 1.1

我在作url rewriting時， 發現頁面的圖片路徑會出現問題。例如：    在/application/folder/default.aspx中放置一個圖片控制項 ~/images/img.jpg,  我在AuthorizeRequest事件中將url /application/default.aspx 重寫為 /application/folder/default.aspx, 圖片無法顯示.   

前言在園子裡看到很多關於TDD、Mock、IoC的文，但是很少有將之組合到一起成為完整的例子的。在這一系列的文章中，我會將TDD、Refactor、Mock、IoC放到一個程式中，一步一步的開發，形成一個完整的樣本。我假設你已經對TDD、Refactor、Mock和IoC有一些的認識，因此並不會解釋這些概念，也不會包含如何使用這些技術的基本內容。本篇是系列的開篇，主要介紹一下此系列的內容和要解決的問題。

最近設計模式的文章又多了起來，戲說之風也漸漸顯現，當然這也不是第一次有某項技術被戲說，或者被放到了故事之中，甚至還有一本專門戲說設計模式的書出版。然而設計模式真的可以被戲說嗎？首先來探索一下為什麼會有戲說這種方式。設計模式剛出來的時候，被無數大牛所吹捧，凡是玩OO的一定要學，於是一時間設計模式風靡大江南北，凡是跟設計模式沾邊的書一律大賣。甭管是懂不懂OO的，有經驗沒經驗的，真會的假會的，張口閉口設計模式。如果你沒法隨口說出幾個模式、沒法隨手畫個UML還真不好意思和別人打招呼。然而四人幫的原版《設