技術領域有很多讓人深感困惑的地方，不管是架構師、設計師還是程序員，在完成任務之余，偶爾都有自責的地方：程序員在使用新技術完成任務的時候，有時會覺得自己舊技術都沒有完全掌握，使用新技術有些好高騖遠；設計師對于架構師所采用的新技術和程序員的學習成本表示擔憂；架構師覺得自己可能沒有完全了解技術細節，關心了客戶，卻忽略了程序員的感受。

      Mono 2.0 是一個里程碑版本，為Linux下.Net程序開發創造了基本框架。不考慮穩定性和可靠性，從功能上考慮，Mono 2.0的Microsoft 兼容的API有了大幅的改進，ADO.NET、ASP.NET 和 Windows.Forms 三大應用API，使得為Linux平臺遷移大量的網站、客戶端程序和數據庫應用程序成為可能。

　　單元測試是最早階段的軟件測試，面對的目標最小，可以綜合使用黑盒測試方法和白盒測試方法，按理說，單元測試用例的設計應該是最簡單的，但實際上，單元測試用例的設計常讓人感覺無從下手，這是什么原因？是代碼真的不具有“可測性”嗎？還是測試思路和方法不對？正確的測試思路和方法是什么？單元測試工具應該具備什么樣的功能，才能支持快速地構建測試用例？

　　英文原文：Avoiding common HTML5 mistakes

　　英文原文：Reverse Ajax, Part 2: WebSockets

 前言：

    園子里有很多關于去除Html標簽的文章。一個常用的經驗是使用 Regex.Replace 方法利用正則去替換。這里有一篇使用該方法的文章 C#中如何去除HTML標記 。下面我貼出該方法的代碼,見代碼清單1-1

　　作為WCF中一個核心概念，終結點在不同的語境中實際上指代不同的對象。站在服務描述的角度，我們所說的終結點實際上是指ServiceEndpoint對象。如果站在WCF服務端運行時框架來說，終結點實際上指代的是終結點分發器（EndpointDispatcher）。而ServiceEndpoint與EndpointDispatcher是一一匹配的，并且前者是創建后者的基礎。而終結點分發器具有自己的運行，即分發運行時（DispatchRuntime）。

有一段時間，正則表達式學習很火熱很潮流，當時在CSDN一天就能看到好幾個正則表達式的帖子，那段時間借助論壇以及Wrox Press出版的《C#字符串和正則表達式參考手冊》學習了一些基礎的知識，同時也為我在CSDN大概賺了1000分，今天想起來，去找《C#字符串和正則表達式參考手冊》時，已經不知所蹤了。現在用到正則的時候也比較少，把以前的筆記等整理一下，以志不忘。

　　隨著 .NET 平臺上，LINQ、ORM 框架、Dynamic Data、... 各種數據訪問技術不斷推陳出新，程序員也一直追著新技術跑，但對底層和代碼細節卻越來越難以掌控。當項目性能需要調優時，通常也只能對數據庫加入更多索引，而多數人已難以對數據訪問的代碼優化，且手寫 SQL 語句的功力似乎也持續退化中。

　　終結點分發器在自己的運行時中對請求消息的處理最終肯定體現在相應操作的執行。如果從服務描述的角度來看，操作是一個OperationDescription對象。而服務端分發運行時中的操作則代表的是一個DispatchOperation對象。作為服務描述的一部分，服務所有終結點的所有操作描述（OperationDescription）在ServiceHost創建過程中被創建。而當ServiceHost被正常開始時，這些操作描述最終轉換成分發操作（DispatchOperation）。而DispatchRuntime的Operations屬性代表了對應終結點的所有分發操作。

系列文章導航：

WCF從理論到實踐(1)：揭開神秘面紗