其他

上周末，麥斯博在上海召開了亞太地區軟體研發團隊管理年會，我作為講師參與了架構分會場的演講。我的演講題目正是《對象設計的藝術》。“藝術”這個詞語有些大，有點玄，不過我確乎希望能將設計作為一種藝術，與工程結合，既注重實效，又能保證軟體的品質，代碼的優雅。在這次演講中，我希望能夠深層次地挖掘所謂設計的本質。這是我的有感而發。因為在設計領域中，前人已經為我們總結了太多的思想、原則與模式。這些內容汗牛充棟，很多程式員根本無法窮盡其內容。學得越多，感覺懂得越少。而如果就這樣無知下去，自然也不利於技能的提升。

下面是一個我們學習線程的一個小例子，大家看看。實現兩個線程，A為控制線程，B為背景工作執行緒，要求：1、從A中讀入一個整數；2、根據A中讀入的數字計算其階乘，同時將結果輸入到D盤根目錄下的1.txt檔案中。該結果需要重複寫入1000次，但當使用者輸入的整數發生改變時，中斷寫入，並計算新數位階乘，將結果追加到1.txt中；3、輸入0退出。程式如下：using System;using System.IO;using System.Threading;namespace ThreadTest{ //

本文是篇譯文（原文在devx），對於想初步瞭解webservice的朋友可能有些協助。Webservice 作為一項新的技術出現在我們面前，它的出世是用於解決在不同的平台下的應用的協同的。目前幾乎每家廠商都要去開發Webservice 應用，然而如果缺乏對Webservice更深的瞭解，不能很好的在設計階段處理好一些重要的問題，那麼最終完成的系統必然是效率低下，沒有可靠性的產品。  在設計Webservice 應用時，以下幾點務必要考慮到：l         管理好與外系統的協同關係l     

今天在部落格堂（不是部落格園哦！）看到mvm寫的一段代碼，可惜作者敝帚自珍，不肯公布原始碼。但作者好心，給了一個提示方法，叫我用reflector直接在Assembly裡面去看。真是不錯，讓我又多了一個好工具。用了一下reflector，還真是好使。註冊了部落格園，也該有點奉獻。可惜自己拿不出什麼好東東，只有拿別人的東西來撐門面了。這個軟體地址是http://www.aisto.com/roeder/dotnet/，有興趣的朋友可以看看。老實說用這個還不太熟，要是大家用了也可以交流交流啊。 

如果一家公司已經上市，那麼我們可以從其股價看出公司的前途。一般來說我們可以從其PE等指標太看。根據此，我打算簡單分析RIM。RIMM在Nasdaq上市，公司股票代號為RIMM。圖1反映了公司最近一年的股價。目前最新價位147.55元（2008-06-19的價格).                                                        

       TDD這個概念出現至少也有兩年多了, 在大家剛接觸它時候, 幾乎沒人不拍手鼓掌, 測試驅動的概念確實可以為我們帶來很多的好處. 泡泡在前不久寫了一篇很不錯的TDD的文章, 可是我還是忍不住在他的評論中說到這篇文章有點”老”. 確實,同樣的概念在書中, 在大家的口中已經被說爛了. 但是TDD真正給我們帶來什麼呢? 有多少人在用TDD呢? 為什麼這麼好的技術到了應用中就被人們”拋棄”了呢? (注: Design Pattern面世都十幾年了,

這幾日，在閱讀GoF之一的John Vlissides著作《設計模式思考》，在James O. Coplien為本書所撰寫的序中，摘引了Richard

協變和逆變，這兩個詞的翻譯實在很難表達出他們的真實含義。其實他們是繼承和多態的衍生物，而且在.Net 1.0 和2.0中都提供了某種程度的支援，只是在.Net 4.0中支援的更加完善了。 簡單說來，協變和逆變就是希望支援更多情況的隱式類型轉換,使得我們的編程更加方便，而通常來說只有具備繼承關係的兩個對象才可以發生隱式類型轉換，如Base b=new Derived(). 協變和逆變則使得更多的類型之間可以發生隱式類型轉換，如通過協變以下代碼可以正常工作：

金旭亮著作《.NET 4.0物件導向編程漫談》推薦序 .NET技術浩如煙海，沒有任何一本書可以窮盡它，因為作為一個主流開發平台，它涵蓋的內容實在太豐富了。然而，當我閱讀完金旭亮先生的這本著作（《基礎篇》+《應用篇》），我開始對我的論斷產生了懷疑。不錯，本書依舊沒有能夠窮盡.NET，然而它在技術廣度與深度的結合方面，或許稱得上是無與倫比的。可以說，.NET平台的各項重要技術，包括.NET

今天，我向那些參考本站Blackberry文章的朋友致歉，因為本部落格上一些文章可能存在錯誤，可能會導致大家的不便。在此對大家說聲對不起，同時我也很慚愧。因本人今天參考一些文章，才發現以前寫的或翻譯的文章不準確甚至是錯誤，我對此感到十分害怕，因為擔心對大家產生誤導。為什麼會出現這種錯呢？最大的原因是自己的知識太淺陋。很多文章都是前幾年寫的，但是在今天看來，好多地方都不準確。既然有錯誤，我就會改正，我會以我最大的努力盡善盡美。以後只要自己或大家發現錯誤，我會不停的更新他們。

最近公司要在.net平台下二次開發報表，我是新兵，任務是做前期準備，分析分析現在國內外好的報表軟體，比較優劣，提交報告。任務說起來簡單，不過就是上網查資料而已。看了幾天用友華表的資料，下載了試用版用了用。發現和Excel也沒有多大區別，華表組件/外掛程式對於我們二次開發協助也不大。雖然提供的ActiveX控制項省了不少事，可失敗的是華表對使用者自訂報表和資料庫的串連支援實在太差。上華表的論壇上看，似乎bug很多啊，真可以如雷的抱怨聲。華表技術服務人員真要是頭疼了。不過該表揚的是華表的售後服務（不

領域驅動設計的關注重心是領域，尤其在面對複雜的領域邏輯時，它總能夠協助我們很好地分析領域。領域驅動設計的基礎是領域建模。Eric認為需要和領域專家良好地合作，從交談中發現通用語言，找到領域的關鍵詞。領域建模是迭代的過程，根據逐漸深入的領域知識來精化模型。不過，領域驅動設計並不排斥其他的分析技術，例如分析模式，或者通過測試驅動開發來引導我們找到問題域的領域模型。領域建模並非領域驅動設計所專屬。在RUP中，領域建模就是一個非常重要的環節。它是一種用例驅動的開發方法，通過獲得的用例來協助分析和設計人員

在前不久發布的”質疑國內.Net社區”的隨筆中, 我個人算是對社區的力量抱怨了一把. 下面該有些實際行動來推動社區的發展, 其實在寫那篇隨筆的時候正在總結一些心得, 現在我把它發表出來供大家討論,也算是帶個好頭,希望能起到拋磚引玉的作用.    在閱讀此文之前推薦閱讀O/R Mapping 基本概念,在基本概念上達成共識.    Enterprise Persistence Design

首先聲明，我可不是要做什麼導師，這樣崇高的身份與我無緣。我害怕自己才疏學淺，而誤人子弟。導師是要李開複、唐駿之流才能做的。因為之前在一家公司和西南大學有一些業務來往，所以應邀到西南大學做過一次講座，並為軟體工程專業的學生開設了一學期《設計模式》課程，認識了一些熱情洋溢的未來程式員。如今，他們也踏上了工作崗位。於是，碰到了一些問題。承他們看得起，居然想到給我發郵件，讓我幫他解惑。回複了郵件後，發現這些問題也許對很多菜鳥而言，大約會是常見的困惑。站在一隻老鳥的角度來看，我的回答或許能夠在一定程度上解

關於代碼的重構，已經是老調常彈。自Martin Fowler《重構》一書橫空出世，到如今已有十年光景，對於重構，許多程式員已經耳熟能詳。然而，每當我們面對項目壓力時，常常會將重構置之腦後，拋到九霄雲外。理由足夠充分，言之鑿鑿：功能還未完成，何談重構？究其原因，是因為我們還未將重構當做習慣。即便現在的許多IDE已經支援自動完成常見的重構手法，我們仍然會忘記，仍然會忽略。只因重構不能直接產生價值，只因我們還沒有看清重構之美。

無論您通過什麼方式訪問本頁面，如果您打算在海南或海口購置房產，請耐心閱讀此文，對您置業會有協助。聲明：K.K不是中介由於工作在外地的原因，K.K很久都沒有好好逛海口了，今天出去走了走，發現海口變漂亮了。其實K.K並不是土生土長的海口人（haikouning)，而是在上大學以後舉家從海南西部的一個城市搬到海口的，所以對海口的感覺是既熟悉又陌生。是不是想說海南人都這樣的了，那內地來的怎麼辦？別擔心，現在很多內地的朋友到海南來居住和生活，所以這種隔閡，嚴重點說是排外的情況基本上已經沒有了（除非是到周邊

為了讓SOA的應用能夠更加的成熟，一些標準化組織(主要有W3C，OASIS)對Web Services的功能進行了擴充，為此制定了一系列的WS-*規範。通過這些規範，使得Web Services在實際應用中的能力得到了很大的增強，這些能力主要體現在對服務品質的保障上，例如安全，可靠性，事務等等。其中，WS-Addressing規範作為一個基礎，為其餘的規範提供了重要的支援功能，因此有必要在瞭解其他規範前，首先深入瞭解WS-Addressing規範。本文將從概念上介紹該規範，並希望通過WSE3.0

敏捷人士認為代碼是最好的文檔，蓋因只有代碼才能真實表達設計者與實現者的意圖。然而，一旦系統變得複雜，通過閱讀原始碼來理解系統就會變成一樁苦差事。系統千頭萬緒，直接閱讀原始碼，常常會陷入“只見樹木，不見森林”的困境。可以說，純粹理論描述的文檔太空，直接閱讀原始碼又太細，任選其一都不利於對系統的瞭解。若能為二者搭建一座橋樑，問題就迎刃而解了。真實的原始碼加上明白通暢的理論描述，或許可以稱得上是學習軟體技術的“終南捷徑”。 郝慶豐先生顯然體會到了這一點，他的大作《返璞歸真-UNIX技術內幕》節選了10

在接下去的幾篇文章中，我將對分布式應用中的一些問題做一些介紹，希望通過這些介紹能夠加深我們對分布式應用的瞭解，這些話題所討論的內容可以說很基礎，但是在進行分布式設計和開發中所必須深刻理解的。我們經常談到所謂的企業級應用，那麼什麼樣的程式才算是企業級的呢？ 使用資料庫，持久化技術，可以算是企業開發的一個明顯特徵，而需要用到分布式技術也可以算是企業級應用中的一個特徵。分布式？

萬般不情願，還是只有告別憊懶打起精神去面對新的一周。只有上班的人才珍惜周末的可貴，只有起早床的人才明白被剝奪睡懶覺的痛苦。從擁擠的公車下來，一進辦公室，開啟電腦看新聞。我是典型的姚明fans，看到火箭加時贏了雄鹿，姚明也表現不賴，只有一個字可以形容：爽！心情好了一點，可以開始工作了。這幾天分析報表弄得我頭都大了。寫軟體偏偏要寫這塊不熟悉的，也夠煩了，沒辦法，為了生活啊！開工吧！