晚期繫結是一種程式語言與作業系統的手法，用意在於避免因為編譯時期的型別檢查機制，導致程式員在編寫程式時，需要處理過多的型別資訊 (Type Information)，晚期繫結可以有效的處理在平台之間型別資訊的隔離，讓編譯出來的程式可以在特定的平台之間執行，而不需要被型別資訊綁住，不過也不能過度濫用，除非原生平台就是要用晚期繫結 (例如 JavaScript)。
Connect() 研討會在昨晚於 Channel 9 線上開幕，發表了數個 .NET 的未來走向，以及新工具的發表，其中最令人期待的當然就是 Visual Studio 2015，這個代號 VS 14 的新版開發工具，它除了持續性的功能演化外，另一個我們一直在關注的新平台：ASP.NET vNext，正式定名為 ASP.NET 5，這可不是 MVC 5，而是整個平台的版本，而 .NET Framework 本身也分為兩支，一支是原本的 .NET Framework，持續演化並維持與舊版本的相容性，版本號碼為 4.6；另一支則是全新的 .NET Framework，稱為 .NET "Core"，這個版本是輕量化的 .NET Framework，所有組件都重新設計，擺脫與 .NET Framework 大多數核心組件的相依性，以作為 Cloud 平台的核心執行引擎，同時它也搭配了 .NET Native 等新一代的執行環境一起釋出，它也是首個正式進軍 Linux 與 Mac 的官方 .NET 平台。
.NET Framework 才剛宣佈 4.5.2 沒多久，隨即在 TechEd 2014 North America 上宣布 .NET Framework 的 vNext 版本，它也是 ASP.NET vNext 的核心，這次的 .NET vNext 倒不會看到在 BCL (Base Class Library) 上有多少改變，倒是為了配合微軟的新策略，大量引進 Open Source 的概念，將原本專屬於微軟的相關技術都開放，並且針對 Device 和 Cloud 的應用情境做專屬的最佳化，讓 .NET 在 Device 和 Cloud 都能獲得最佳表現，同時也讓 .NET 可以跨出 Windows 平台 (之前只有 Mono，微軟希望有更多的平台加入...
LINQ 語法中有兩個很令人玩味的方法，一個是 Any()，另一個則是 Count()，Any() 的功能是判斷集合中是否有物件，Count() 則是用來計算集合中的物件數量，功能其實很像，以一般的使用習慣來說，我們多半會使用 Count() 來判斷集合中是否有物件，而且在大多數的情況下是沒問題的。
在 .NET 平台寫程式寫久了，一定會覺得程式中的資料一定得物件化，而且要有明確的成員來規範，沒錯，這是我們告訴大家寫程式的基本要求，能做強型別的就一定要做強型別，不然光是轉型 (type casting) 這件事就能搞死一堆人了...
NuGet 真的是所有寫元件的程式設計師應該要好好玩一下的東西，不僅僅是它方便開發人員引用你辛苦開發出來的元件，它也隱藏了一些讓元件開發者能即時修改專案內的資訊，例如組態檔 (configuration file)。
自從 NuGet 2.0 讓加入元件到 Visual Studio 專案變得超級簡單之後，很多來自微軟和第三方廠商的免費套件也都大量使用 NuGet 來作為 SDK 或可程式的元件的集中地，NuGet 也有提供 Server 版本讓企業內的開發團隊也能建置 NuGet 類型的服務，加速開發人員在整合參考元件的處理速度。
要不是今天工作的地方沒有網路給虛擬機器用，大概也不會看到這個問題...
有很多技術，如果不從頭講的話，很多人會不知道當初為什麼要這麼做，而且這麼做的好處又是什麼，它能解決哪些問題。委派和 Lambda 的關係就是一個極好的例子。
例外處理 (Exception Handling) 是每個寫程式的人都會遇到的問題，其實處理例外就像呼吸那麼自然，而例外處理的工作不外乎...
ORM 原理前面8集中己經講述了基本的ORM核心內的運作方式，大多數的ORM其實都是這麼做，當然還會做一些更進一步的最佳化工作，例如產生SQL的方式等。不過既然都是寫程式的，當然會希望這些對應欄位的設定工作可以完全的程式化 (Coded Map)，而不用再假手那麼多的設定檔。
SignalR 是一個使用上並不困難的 Framework，而在 Visual Studio 上使用更容易，透過 NuGet 的功能，我們可以很容易的整合 SignalR 到專案內，只要在 Package Manager Console 中使用一個指令就能自動安裝與整合 SignalR 與相依的組件到專案內。
單一簽入 (Single Sign On) 一直是驗證存取權機制的最終境界，整合單一簽入的技術在市場上早已炒到不能再炒了，而且也有相當多的單一簽入解決方案，其中包含 OAuth 1.0/2.0，Open ID，Active Directory，LDAP 等等協定和服務，而在社群網路流行後，幾個重要的大型帳戶儲存庫像 Facebook, Google, Yahoo, Twitter, Plurk, Linked In 等廠商也相繼的開發了認證的 API 群，以支援來自不同設備或用戶端的驗證需求，而在台灣最新的個人資料保護法正式施行前，外部的單一簽入已經成為應用程式認證機制的首選，尤其是小型網站或新進市場的應用程式，透過大廠來處理驗證，使用者不但不用記太多的帳戶密碼，也容易吸引使用者登錄資料...
Session State 和雲端應用程式狀態管理一向是設計 Cloud 應用程式的重要考量因素之一，因為雲端應用是分散在不同的虛擬機器內執行的，VM 間可應用的大概只有像資料庫或 storage 這種集中式資料來源，而且雲端應用的儲存也都是分散式的，若是有一個地方能快取這些資訊，那麼就能降低分散環境的 I/O 負擔，應用程式的回應速度也會比較快，所以才會有 Windows Azure Caching Services (原稱 AppFabric Caching Services) 的出現，只是有個問題，就是它有點貴：128MB 的快取要 $45 美元月費，而中大型應用程式的快取通常需求又很高，同時 Caching Services 也是分散式的環境，所以還是有 I/O 的問題。
今年會有不少重量級的產品發表 (SQL Server 2012, System Center 2012, Windows 8, Visual Studio 11, Windows Server 8, Tango, ...) 和上市，看來今年應該很熱鬧了~
延遲執行 (Deferred Execution) 是 LINQ 的重點技術之一，對於像是會存取資料庫的 Framework 或指令，如果在指令下的當下就執行的話，有可能會在下個指令存取之前就跑了，這樣可能會有時間差，或是下一個指令無法反應到結果上的問題...
這個需求真的是老需求了，只有使用者端有 Office，就難免會有這種需求，像是在 server 上產生 Word, Excel 或是將表格轉換成 Word/Excel 格式下載的，而這次碰到的需求是要將 Word 轉換成 PDF，只是目前市場上可用的免費工具如 itextsharp, pdfFactory 這種，都不能支援由 server 轉換文件為 PDF，而一些可轉換的元件要錢而且很貴 ($599 鎂以上，可轉散布的更貴)，在一個預算有限的專案上，僅能使用最原始的方式來實作這個功能，畢竟 $399 還是比 $599 便宜多了...
有用過 jQuery 的人應該會對它的方法鏈 (method chain) 印象深刻吧，一條龍的方法呼叫可以簡化很多程式碼量，雖然看起來有點不容易維護，但就不需要特別設定的程式撰寫上，它還是一個很方便的 pattern。
到原理 (8) 為止，我們已經完成了資料的查詢工作，但資料庫應用程式不是只有查資料而已，對資料的新增，修改和刪除 (C/R/U/D) 也要實作，才算是具有完整的資料存取能力，所以我們也必須要做到 C/U/D 才行，對程式來說，C/U/D 比 R 要簡單，但還是會有一些需要考量的地方，首先，在一堆資料的集合物件中，大部份的情況下不是每一筆都需要做 C/U/D，怎麼判斷每一個物件的狀態，以及在處理物件時何時更改狀態，就是一個重要的課題了，再者，如何產生資料庫需要的 INSERT/UPDATE 和 DELETE 指令，也是我們需要關心的。
在原理 (7) 中，我們完成了關聯的基本處理，只是我們做到的是一對一的關聯，如果今天要的是一對多的關聯時，我們就需要處理到集合物件，集合物件不像單一物件那麼簡單，尤其是集合物件的元素又和其他物件有關聯時，載入的方式就會決定程式的速度，以我們到目前為止的例子，Customers, Orders 和 Employees 三個表格，Customers 會和 Orders 有一對多的關係，而 Orders 和 Customers 與 Employees 有一對一的關係，我們在原理 (7) 中實作的是 Order 類別，所以是一對一，但如果我們要實作 Customers 和 Orders 之間的關係，會變成一對多，也就是我們要處理 Customer 類別內的 OrderCollection 集合物件...
我們在原理 (1) 時，看到了看似很完美的屬性與欄位對應，因為屬性和欄位名稱一致，在處理起來算是很容易，但現實的情況是，屬性名稱未必會和欄位名稱一樣，這時我們就需要一套方法來處理欄位與屬性的對應。
我想大家或多或少都聽過 Entity Framework 或是 NHibernate Framework 這種大型應用程式開發的 Framework 吧，它們都是做 ORM (Object Relational Mapping) 技術的資料存取函式庫，只是很多人都只看它有什麼功能，卻沒有多少人對它內部感興趣－為什麼它們可以精確的對應 SQL 的欄位和物件屬性呢？我試著以一系列的文章來介紹 ORM 到底做了什麼事。
繼今年四月份的 EasyOAuth Framework 1.0 上架到 Codeplex.com 後，除了再檢視程式本身以外，還吸取一些來自社群的意見 (雖然不多...)，以及配合 Windows Live ID 支援 OAuth 2.0 規格的發表，EasyOAuth Framework 也順勢改版到 2.0，同樣支援 Desktop Edition 與 Web Edition，可供桌面應用程式與 Web 應用程式的 OAuth 認證機制開發功能。
本回的 bug 逃走中，發生在 Windows Azure Platform 的 Service Management API 上。
要是寫程式，一定多多少少會需要讀寫資料，畢竟 Program = Data Structure + Algorithm，只是大多數的情況下，資料的讀寫多半是對資料庫，而資料庫內的檔案實際讀寫由 DBMS 自己控制，開發人員基本上是碰不到的，但是資料不是只會存在資料庫內，像是檔案系統 (File System)，網路資料或是其他可能的資料儲存地，而像這些不同的資料保存，都需要由開發人員自己處理 I/O 的工作...
Web Service，這個從 2001 年開始被微軟炒起來的分散式元件概念，隨著 Visual Studio 2002 (.NET Framework 1.0) 的推出得到了軟體龍頭微軟的背書，一個原本要從 SOAP 和 XML 開始打造的可重覆使用 (reusable) 式軟體元件就在 .NET Framework (System.Web.Services 命名空間) 的精美包裝下，讓開發人員只需要使用 [WebMethod] 就能夠寫出自己的 Web Service 元件...
最近這一個月事情還真不少，不斷的在嘴砲和務實的角色之間切換，也寫了不少的程式碼，而且為了因應今年 9/13-15 的微軟大拜拜 (Tech.days) 的課程，我還特別寫了支範例程式準備要在課堂上 demo 用，這支範例程式是 Windows Azure Platform 上的服務管理應用程式，核心均來自 Service Management APIs，很快的，就在 Tech.days 2011 Taiwan 研討會中將正式釋出...
我們在階段 1 中已經完成了最基本的 DACL 資料結構，能針對簡單的 CRUD 權限做控制，但一般來說權限設定沒那麼簡單 (尤其是複雜度高又講求安全的系統)，很多程式或系統有時無法只單純用 CRUD 就可以解決...
前面兩篇文章已經大略說明了 DACL 的概念，而在本文中，我們來實際建構一個 DACL ...
判別式存取控制表 Discretionary Access Control List (DACL)，這個自由度頗高的存取控制方法，在 Windows 以及其他作業系統中已行之有年，它最大的特色就是使用者和群組可以擁有自己的存取控制設定，而系統物件也可以擁有自己的存取控制項目，也就是說系統物件不會只有 CRUD 四種權限，還可以因為物件的特性而定義額外的權限，例如存取詮釋資料 (metadata), 列印 (printing) 或是下載檔案 (download) 等權限，discretionary 這個字有 "任意的"，"無條件的" 的意思，而 DACL 也是讓消費者和生產者可以擁有自己的權限設定，只需要在存取時進行檢查即可。
