在擔任技術顧問時最常遇到兩件事，一件是系統架構調整，另一件則是最大化產品價值，前者是用來維護、奠定日後的發展，後者則是在面對競爭者。一般來說，多數的產品在開發初期就會有假想敵，如果你遇到的是沒有假想敵的產品，那麼恭喜你，你拿到了商業模式中最有利的籌碼，就是稀缺性，但不幸的是，這樣的機率很低，在這個年代，多數的商業模式都已經被找出來，差別在於執行細節及價值的定義。本篇文章以 Dapper 做為假想敵，將追趕它的最有價值部分做一個紀錄，結果其實不是那麼重要，過程才是有趣的部分。
前陣子看到許多朋友轉載這篇關於如何使用C# 快速建立物件實體的文章
.NET Core 從2016 年發展至今四年了，前陣子的.NET Core 3.0補上了Windows Forms、WPF桌面應用程式支援，讓其應用範圍擴及桌面應用程式，接著的preview 6 則帶來了ReadyToRun的部署模式，這是一個類似.NET Framework NGEN的技術，用來加快.NET Core應用程式的啟動效能，結合preview 5的單一執行檔模式，可以編譯出單一執行檔，又有更好啟動速度的.NET Core 3.0 程式。
每隔一段時間，偶而就會聽到一些靜態函式的都市傳說，比較誇張點的是非靜態函式(也就是類別成員函式)，會依據物件而複製，所以占用記憶體較多。較為貼近合理情況的是靜態函式的執行速度優於非靜態函式，如果你相信我的話，以下就是答案。
.NET Core 第一次 (2016/6) 出現，到第一版的 RC 1(2016/9)，至今已過了兩年，正式版本號也推進到了 2.2，前兩個主要版本開發標的均聚焦於跨平台與 Server-Side(ASP.NET)的支援，隨著基礎建設 (BCL)的日趨完善，.NET Core 3.0 開始轉移開發焦點至 Desktop部分，納入了 WPF、WinForm、UWP，還有 Entity Framework 6。也就是說未來的 .NET Core 3.0可以取代 NET Framework來進行 Windows GUI的開發，以目前披露的訊息及實作來看，GUI 的部分依舊是維持在 Windows平台上，不具備跨平台的能力。
多數的O/R Mapping Framework都有個共同的行為模式，在刪除資料或是修改資料前，必須隱式的下達一個Query，由資料庫取得即將要更新的資料列，然後轉成物件後再更新。 這個行為模式，多半也會成為設計師考慮是否使用O/R Mapping Framework的考量之一，因為多一個Query，就代表著效能會因此降低，雖然對於O/R Mapping Framework而言，這是一個必要的行為模式，因為它們得考量到當物件有著關聯時的情況。但對於實際的專案來說，跳過這個Query來更新資料，卻也是必然會出現的情況，既然是必然會出現的情況，多數的O/R Mapping Framework也只好為此做出讓步，提供可跳過Query來更新資料的機制，Entity Framework自然也擁有這個機制。
當一個地雷踩第二次的時候，就是以文字記錄下來的時候。
LINQ 的設計初衷就是放在程式設計師日常都會用到的功能上，藉此節省程式碼的量，身為C# 工程師，我們在解搜尋、排序、過濾這些問題時，應該時時刻刻都要想到如果運用LINQ，是否會有更好的解法，
本系列文便是一個紀錄，我沒有定任何的週期發布時間，純屬遇到後，就記錄下來，也不代表是最好的解法，你知道，這世界上只有當下最佳解，如果你有更好的解法，歡迎分享 ^_^ ，若對這系列有興趣，可以追蹤本粉絲頁。
C# 並不是唯一一個提供語法糖的程式語言，但卻是少數敢持續在新版本中加進數量堪稱大量語法糖的語言，單以語法糖這點來說，C# 算是發揮得相當極致。
最近的Windows 10 Fall Creators Update更新中，提供了一樣以往被視為是難以取得的的資訊，那就是GPU的使用率及記憶體用量，這以往都要靠特定的工具才能查看，例如GPU-Z或是Riva Tuner，如果是NVIDIA那就還好，NVIDIA會在資源監視器中添加幾個計數器，所以取得其實不困難，但如果是ATI/AMD甚至是Intel HD，沒有特定的通道與知識是很難達到取得這些資訊的，尤其是記憶體(Video Memory)用量，在這次的更新後，這一切都變得非常簡單了。
SIMD是Single Instruction Multiple Data的縮寫，通常中文翻譯為單指令多數據流，用較白話的說法是，同時對多個數據執行同一條CPU指令，達到平行運算的目的。
這是2011年 談C# 編譯器編譯前的程式碼擴展行為 的續篇，當年該文章由C# 1.0討論到4.0，中間也過了好多年，今年終於興起來寫個續篇了，如果你沒看過前篇，建議看這篇前先瀏覽一下，該文中提及的東西至今仍然未過時，語言的東西不比特定技術，很少會發生Breaking Changes或是整個Feature移除，頂多只是改善。
軟體需求總是不停地在改變，有些時候需求帶著UI，有些時候需求則可以排除UI，端看使用者的角色而定。會有這篇文章的原因是最近收到了一個很特別的需求，這個需求的受眾，也就是使用者其實是公司內部的PM、工程師，所以UI不一定需要很複雜，甚至不太需要UI，因為牽扯到實際商業行為，以下我便用類似的假想型需求來呈現。
保護與破解就像是矛與盾，本文著重與討論程式碼保護技術，也就是如何保護你的程式碼不被竊取及竄改
憑藉著Node.JS豐富的資源，傳統Desktop Application能做的事，Electron幾乎都做得到，前提是你能找到適用的套件，但總有些時候，能找到的套件雖然能達到你要的目的，但卻附帶一些不想要的後果，例如複雜的使用架構，或是效能不符需求，相依性過大等等，這時Electron Edge這類可以橋接.NET Library的機制就很有用。
年前，一次全面性的SQL Injection攻擊，導致數千個網站受害，霎時間，讓所有人領教到看似方便的網路世界，也有其陰暗的一面。SQL Injection是一種著床於程式設計師的慣性及惰性上的害蟲，只要有程式設計師持續提供其養份
隨著Microsoft擁抱開源的口號，.NET Framework也正式登上了其他平台，其中包含了Linux與OSX，與以往的3rd Party Mono不同，新的.NET Core具備官方的支援及完整的Roadmap。
為了登上其他舞台，.NET Core可以說從根源開始重新打造，在早期版本中Linux、OSX上仍是使用Mono Runtime，隨著時間的推移，現在的1.1 RTM中Mono的身影已經完全消失了，取而代之的是Native Platform Runtime，這代表著.NET平台新時代的來臨，也意味著Microsoft正走在一個Java曾走過的道路，Cross Platform、Write once，Run Anywhere。
前篇文章提及，VSTS其實可以自動透過Nuget Restore來取得專案所使用的套件，這樣不僅可以避免直接在專案中硬性加入參考，也可以解決套件散亂難以管理的問題，當然，專案中許多套件是屬於自行研發，也不打算放上Public Nuget Server給外部人使用的，這時候就需要自行架構Nuget Server。
版本控制系統(Version Control)是近代軟體工程必要的一部份，只要是專注於軟體開發的公司或是部門，都必定擁有這一環， 當建置好版本控制系統後，接著要思考的是下一步，通常這指的就是建置系統(Build System)，也稱為自動建置系統(Build Automation System)
一般來說，Windows Store Application對於Windows 8來說，是一個特別的應用程式，他執行在特殊的Container(容器)中，雖然有著與舊有執行檔相同的附檔名(.exe)，但事實上
Windows Program Loader是無法直接載入執行的，必須先建立容器，然後要求該容器來執行。