老啄木鳥的窩

今天有人提到：「JSON 資料格式與語言無關」，這樣斷章取義真的會誤導部分不求甚解的人。應該完整的引用整句話上下文：「JSON 資料格式與語言無關，脫胎自JavaScript」，想像一下子女與父母的血緣關係，沒有人會說兩者就像路人一樣無關的。 我覺得維基百科上「JSON 資料格式與語言無關」這段文字的適當性其實有很大的商榷空間。 維基百科的內容不是真理，畢竟它的大部分內容是開放的。它的文案校對水平跟出版業比起來不是一個級別，網頁文字修改並不像印刷品需要逐本去貼貼紙，因此沒有一套嚴謹的出版SOP。 『只知學習，卻不去思考所學的道理，那還是等於一無所知；而單憑空想，卻不去實地學習，也是得不到正確的學問。』 嚴格地說，JSON 是 Javascript 的非函式物件拓墣型態，它在拓墣後必然失去生命力，因為無法存在非執行環境(網路)的邏輯資料(API語法)已經被移除。然而，該拓墣若回到原生執行環境則100%相容，因此JSON非常適合用於瀏覽器跨平台資料交換。 JSON是唯一一種程式語法的片段本身，既可當成網路資料傳輸文件，同時是不須經過修改即可直接被直譯的程式語言和網路資料交換標準。講白話就是，你可以把Javascript的特定程式碼(子集)直接傳給任何其他語言開發的系統，都能被接受，更不用說這語言子集已經是IT產業 EDI 標準。 任何程式語言都能透過對JSON文檔或字串的解析來轉換為語言自己的資料型別，但不能用JS語法來宣告定義資料型別和初始值。反觀Javascript可以一字不改的使用JSON來宣告定義。 請問有哪位程式人員會在JS寫：「var o = JSON.parse("[1,2,3]");」而不寫「var o = [1,2,3];」的？ 事實上，不管JSON的格式如何進化，都會先在Javascript的現行版本包含這些規格，因為這是規定(都說是子集了)，這是JSON的宿命，當初若沒有Javascript打下Ajax的一片天，JSON就沒有取代XML的優勢可言，未來不會有JSON跟JS有分道揚鑣的一天，因為唇亡則齒寒。 上面立論非常重要，也是我認為「JSON 資料格式與語言無關」這句話有誤導概念之嫌的原因。 維基百科是這樣寫 JSON 的： 「JSON（JavaScript Object Not

當 我們談到 delegate 和 lambda、Func、Action 這幾個字眼時，腦中觀念上總是有些模糊不清，就像是遠方有一片烏雲，雖然遙遠，卻擔心有一天會飄過來。我認為基本觀念很重要，像是delegate/Ｄelegate大小寫代表不同意思，全小寫的delegate是C#關鍵字，Delegate/MulticastDelegate是函式庫類別，Func和Action是BCL預先定義方法簽章的17組委派類型，這34組方法簽章都是泛型函式。另外，官方有些文件存在著一些描述上令人困惑的文字，甚至我聽到有「Func和Action就是繼承自Ｄelegate類別的衍生類別」的奇怪說法在流傳著，基於存在著這些奇點現象，若我們真的想要知道上述觀念是否正確時，最好的方法是直接看原始碼才能見分曉。 本文試著透過官方.NET基礎類別函式庫(BCL)的原始程式碼(Source Code)一窺堂奧，解釋編譯器怎麼編譯一個delegate語法或者怎麼實作，並提出個人見解以饗諸公。 探索System.Func、System.Action、System.Delegate原始碼 二話不說先給兩個官方Source Code網址： System.Func/System.Action： https://referencesource.microsoft.com/#mscorlib/system/action.cs  System.Delegate： https://referencesource.microsoft.com/#mscorlib/system/delegate.cs,0dd8585ba1833ad7 坦白說我看不到10秒就看出「 貓膩 」了， 本文寫下心得，也可以說是依據個人有限知識＋腦補的結果，但目的是期望能拋磚引玉，看到更多討論C#語法的觀念文，去幫助新手建立正確的程式根基。 先離題一下，談談這篇文章的濫觴， 隨著科技進步，現在的程式設計師跟以前寫程式的人的相比，有著很大的不同。 早期的程式設計師撰寫低階或中階語言，仰賴自身對計算機各種運算單元和IO知識，也要對資料結構的演算方法有足夠的學習，程式實體只有程式人員寫的語法和電腦機器碼兩種。 現代的程式設計師進行程式寫作是否能有高品質的程式碼產出，端依賴對該語言的關鍵字和類別

語言整合查詢 LINQ（Language Integrated Query） 世界最高的山叫聖母峰(珠穆朗瑪峰)，而讓主脈看起來偉大神聖的，就是環繞的支線山脈稜線風光，群山烘托出一幅一幅壯絕的美景。.NET的LINQ就像聖母峰主山脈一樣，匯集各項技術才完成整個技術的淬鍊，成就偉業。(此時腦中浮現美隊大喊：Avengers! assemble...) 就在Python、C++、C#、PHP以及Javascript這些語言都支援Lambda語法的當今，還不會寫Lambda的程式人員請考慮移民火星，因為地球越來越危險了。 然後我們不免好奇一件事，究竟Lambda( 發音 )的由來和原理是甚麼，我們只知道使用Lambda可以少寫很多代碼，它可以用來寫匿名函式給Delegate委派、寫Linq必用、能把函式當參數傳、可以inline寫一長串程式碼超爽der...等等神奇又便利的特性，生在現代的程式設計師是不是太幸福了呢? ...     但也許我們就像瞎子摸象故事中那些盲(忙)人一樣，天天盲(忙)著工作，成本和速度儼然主宰了一切，漸漸對技術駕馭無能為力，直到彼此都在用荒謬溝通。 網路上大多是介紹Lambda語法的文章，完整精闢的觀念文缺乏，發現越來越多彼此對Lambda有一些認知上的差距；隨著.NET 的版本不斷演進，C#這個語言已進入一個全新的里程碑，而時下最夯的程式技術詞彙：Lambda 則是引爆一切的原點，究竟Lambda成就了C#，還是LINQ成就了這一切，卻把光環都給了Lambda，就讓我試著來整理這些資料，幫大家系統性的做一個介紹。 從Lambda起源說起 Lambda原本是一套數學邏輯表達式 ： λ演算， 我們先來看維基上的介紹： 「λ演算（英語：lambda calculus，λ-calculus）是一套從數學邏輯中發展，以變數綁定和替換的規則，來研究 函式 如何抽象化定義、函式如何被應用以及 遞迴 的 形式系統 。它由數學家 阿隆佐·邱奇 在20世紀30年代首次發表。lambda演算作為一種廣泛用途的計算模型，可以清晰地定義什麼是一個可計算函式，而任何可計算函式都能以這種形式表達和求值，它能類比單一磁帶 圖靈機 的計算過程；儘管如此，lambda演算強調的是變換規則的運用，而非實現它們的具體機器。 「lamb

寫這篇是起因於在臉書討論C# DTO時我講了"建構賦值比物件初始化優先"這句話(其實我的意思是指先執行)，不明白的人請我解釋是甚麼意思，所以就完整交代一下個人設計DTO物件的心得。 當然，若設計其他非DTO物件會更複雜一些... DTO不宜設計成一個複雜的邏輯物件，一般來說我們設計DTO物件時主要是做關於[屬性]的驗證和存取層級的規格設定。 另外，屬性的驗證應止於型別與範圍的安全，所以我們用屬性的get和set方法就可以達到這個需求。 設計每個DTO首先都要面臨3個課題，如下： 1.參考型別的屬性建構時是否實例化。 2.屬性型別與範圍的安全驗證。 3.屬性值的存取保護。 DTO要做到上述課題的完美解答，設計者除了要對物件導向的精神有足夠的認知與內化，還需要正確掌握C#語言的執行方式。這裡提供兩個觀念和技巧﹔ 1.要清楚DTO實例化的過程(C#建構函式與初始化程式碼區塊{}的執行順序) 有幾個重點： 1.屬於參考型別的屬性(例如List<T>)若沒有先實例化就沒辦法使用其API。 2.物件初始化語法區塊中無法執行類似 "new myClass{ myList[0] = "my string", ...}" 這樣編譯器會報錯，因為參考型別的實例化必須等到物件本身完成實例化之後，所以物件初始化要賦值屬性時不能參考到其資料結構，就算程式碼已宣告其值都要等到初始化後才能使用。類似以下例子： 2.更進階的觀念：讓關鍵屬性私有化並限制只能於建構時期賦值 由於物件建構階段比物件初始化階段先完成，所以相同屬性若在建構賦值之後會又被初始化覆蓋。 為了保護建構值我們可以在屬性private set中設計驗證程式碼，然後在建構函式傳入值到setter時驗證後才設定其值。這樣建構函式本身簡潔乾淨，屬性值又不會被初始化覆蓋或後續從外部修改。類似以下例子： 寫在最後 也許目前為止看似一切都妥當，但若是遇到非DTO而是較複雜的物件設計，程式常常會由不同程式人員維護，可能會在程式某處重複設定屬性myList的值，而我們本意是只能在建構時以參數設定myList。 有沒有方法保護程式碼呢? 答案是肯定的。 作法是把負責建構關鍵組態的程式設計

最近公司內部新人多了，雖然我只是個小小技術經理，還是接下內部教育訓練的重責大任。分享一下要上的課程規劃，寫完發現新人真可憐，這通識課範圍有點廣啊，沒嚇跑上完之後應該會打通任督二脈。 ================================== Web Development Training Courses Agenda 網站應用程式開發人員進修教育訓練課程規劃大綱 @共規劃兩個階段的"通識課程"，各階段分不同目標實施如下： 第一階段內容難度:入門~進階 ->目標：重在確保人員技術基本水平 ->適合人員：新人~資深工程師 第二階段內容難度:進階~精通 ->目標：致力於培養高級人才 ->適合人員：資深進修 PS.若因專案需要針對某些技術作教育訓練則另外規劃之。 @課程內容準備和主持講師採領養方式，建議由內部資深人員認養 @課程大綱規劃如下： ****第一階段**** [Web後端開發技術講座(第一階段)] ================== <一、精通.NET MVC的本質與開發架構> 1.強化C#物件導向設計基礎觀念(C# OOP Basic Concept(封裝、繼承、多型)) 2.說明甚麼是.NET Framework的BCL和CLR? 甚麼叫擴充函式庫? 3.事件Event驅動和Delegate(委派)的最主要用途是甚麼? 4.詳解LinQ技術、Lambda語法及語法樹Expression Tree觀念 5.進階物件導向設計(深入探討IoC、DI、AOP) 6.MVC Design Pattern是甚麼? 你現在用的是哪一種設計模式? 甚麼是反模式? <二、MS SQL SERVER 2016資料庫設計基礎教學> 1.資料庫基礎知識及SSMS管理工具教學 2.介紹資料表設計階段的正規化的分析邏輯 3.DB效能調整及監控分析 [Web前端開發技術講座(第一階段)] ================== <一、如何精通WEB客戶端應用程式設計> 1.說明甚麼是網頁執行環境? 甚麼是瀏覽器相容性? 2.盤點及說明各種W3C標準(HTTP Portoccl、CSS、HTML5、RSS、SVG...)

精通.NET MVC的本質與開發架構 ·          1. 強化 C# 物件導向設計基礎觀念 (C# OOP Basic Concept( 封裝、繼承、多型 )) ·          2. 說明甚麼是 .NET Framework 的 BCL 和 CLR?  甚麼叫擴充函式庫 ? ·          3. 事件 Event 驅動和 Delegate( 委派 ) 的最主要用途是甚麼 ? ·          4. 詳解 LinQ 技術、 Lambda 語法及語法樹 Expression Tree 觀念 ·          5. 進階物件導向設計 ( 深入探討 IoC 、 DI 、 AOP) ·          6.MVC, Design Pattern 是甚麼 ?  你現在用的是哪一種設計模式 ?  甚麼是反模式 ? ·          7.Web API ·          8.Entity Framework 每堂課兩小時，以下為課程的備課資料： 1. 強化C#物件導向設計基礎觀念(C# OOP Basic Concept(封裝、繼承、多型)) I. 型別、變數和值 II. 封裝、 繼承 、 多型 III. C# 關鍵字 IV. 微軟官方教學文件： i. Microsoft C# 指南 https://docs.microsoft.com/zh-tw/dotnet/csharp/ ii. C# 語言參考： https://docs.microsoft.com/zh-tw/dotnet/csharp/language-reference/ 2. 說明甚麼是.NET Framework的BCL和CLR? 甚麼叫擴充函式庫? I. .NET Framework概觀 I. CLR執行環境 II. BCL是.NET Framework 基礎類別庫 III. 透過C#擴展方法使您可以向現有類型添加方法，而無需創建新的派生類型，重新編譯或以其他方式修改原始類型。 C#擴展方法是一種特殊的靜態方法，它被稱為擴展類型的實例方法。