之前的＜C# 筆記：重訪委派－－從 C# 1.0 到 2.0 到 3.0＞已經交代過 lambda expressions 的語法及其來龍去脈，這篇筆記會先複習一下 lambda 表示式，然後進入 LINQ...

摘要：本文將簡單介紹 C# 3.0 的新語法：擴充方法（extension methods...

這篇文章主要是複習一下 C# 委派（delegate）的基本觀念，同時也示範從 C# 1.0、2.0、到 3.0 的委派寫法。 我們會看到更直覺的建立委派物件的語法、匿名方法、以及 Lambda 表示式...

C# 3.0 增加了自動實作屬性（auto-implementation property）與物件初始器（object initializer）的語法。這兩種語法都提供了某種程度的方便性，Scott Guthrie 很早就寫了一篇文章介紹它們，這裡就不寫太多重複的東西了。貼個簡單的範例上來：...

有時候，例如在某個函式裡面，我們會臨時需要一個簡單的類別來儲存一些簡單資料，但又不想為了這個簡單的需求另外定義一個類別，此時便可使用 C# 的匿名型別（anonymous type）。...

C# 3.0 增加了 var 關鍵字，你可以用它來宣告隱含型別，例如： int i = 10; var j = 10;...

這個問題不太好找，值得記錄一下。 問題描述 在 ASP.NET 2.0 網站中呼叫另一個網站的 Web service 時，「有些」用戶端瀏覽器會出現以下錯誤： 連線嘗試失敗，因為連線對象有一段時間並未正確回應，或是連線建立失敗，因為連線的主機無法回應。 111.xxx.xxx.xxx:80 [SocketException (0x274c): 連線嘗試失敗，因為連線對象有一段時間並未正確回應，或是連線建立失敗，因為連線的主機無法回應。 111.xxx.xxx.xxx:80] 問題難解的原因有兩個。首先，是這個問題只有在少數用戶端環境才會發生，開發團隊不易模擬出問題環境。其次，整個網站的運作架構有點複雜（load-balance、proxy、switch、firewall...blah...

2009-02-24 更新：書籍已出版，詳情請看《物件導向分析設計與應用 第三版》書籍相關資訊《Object-Oriented Analysis and Design with Applications 3rd edition》是由物件導向三巨頭之一的 Grady Booch 以及其他作者所共同撰寫。中文版書名目前暫定為：《物件導向分析設計與應用 第三版》這本書將近 700 頁，雖然附錄和參考文獻就占了 139 頁，但是對我來說還是屬於重量級的挑戰（對讀者來說恐怕也是吧）。目前的翻譯進度：第 12 章 > 附錄 > 索引 > 校稿 > 等出版2009/1/16 更新:今天（2009/1/16）的版本應該是最後的修訂了，最後一次校稿結果是由出版社的編輯做最終修訂，我自己也沒有看到最後的排版結果。不過，碁峰出版社的編輯...

對於複雜的資料查詢，我們是該用手工打造的 SQL 指令呢，還是該寫程式碼來處理？在甚麼情況下該選擇甚麼方法呢？我的看法是應該盡量以撰寫程式的方式來處理。在解釋原因之前，要先聲明一件事：我不是 SQL 高手，所以在一開始打算寫這篇文章時，我就在想我的結論可能過於偏頗。不過，若能拋磚引玉，得到其他前輩、高手的意見，因而修正自己的想法，倒也是好事一樁。其實在多年以前，我便覺得撰寫 SQL 對我來說是一件「寫時容易讀時難」的工作。我不是說兩三兩個資料表 join 這類簡單的 SQL 查詢，我說的是包含七八層、甚至更多層子查詢的 SQL。因此在我自己寫的程式裡面，我都盡量不寫太複雜的 SQL，而我的 SQL 功力自然也就一直停留在小學生的階段（好吧，也許是幼稚園階段）。兩種解法會想把這個議題寫下來，其中一個原因是不久前又碰到了複雜...

延續上一篇，這裡寫一點第 2 章＜流程改善，沒有魔法＞的筆記。精實（Lean）製程定義了七種會破壞客戶價值流的浪費：過度生產（overproduction）：開發太多不重要、甚至無用的功能。傳遞成本（transportation）：專案建置（build）、版本分支（branch）、和團隊成員之間透過 e-mail 溝通等傳遞成本。多餘動作（motion）：花在找資料、找解法、搞清楚要做甚麼等動作的時間太多。等待時間（waiting）：系統功能的優先順序沒訂好、開發流程不當、品質不良等因素，導致各開發小組之間彼此等待。過度處理（overprocessing）：把軟體功能設計得太複雜、對已經跑夠快的程式不斷做效能最佳化的調整、增加不必要的擴充等等。庫存過剩（inventory）：矇著頭開發了一堆功能，後來發現有很多都白做了，在系統上線前就被拿掉，所以客戶也看不到這些功能－－未實現的價值是種浪費。產品瑕疵（defects）：太多...

本文原刊載於 .NET Magazine 中文版 2005 年 12 月號，現在將此舊文重發，只是為了方便參考。摘要在撰寫多執行緒的 Windows 表單應用程式時，有一項必須特別注意的規則，就是不可以在工作執行緒（worker thread）當中修改表單或控制項的屬性與方法。本文說明這項規則的由來，以及違反此規則將造成的後果，同時示範錯誤的以及正確的程式撰寫方式。在撰寫多執行緒的 Windows 表單應用程式時，有一項必須特別注意的規則：只有在建立該表單（或控制項）的執行緒中，才能存取、修改表單（或控制項）的內容。如果讀者到MSDN Library查看Control.BeginInvoke方法的說明，也可以得到類似的訊息（雖然不是很明顯），其中有一段備註是這麼說的：「在任何執行緒裡面可以安全呼叫的函式只有四個：Invoke、BeginInvoke、EndInvoke、和...