componentClassName is null in the component 

在開發系統時，如果測試情境的輸出會有許多資料類別並且要驗證很多欄位時，會利用 object graph 比對整個結果是否和預期一致。

現在我的專案裡有個 CustomerRootData 類別，裡頭屬性為十幾個不同型別的子集合，每個類別都有 UpdateTime、UpdateUser 這兩個欄位，但這兩個欄位是在程式執行當下才寫進去的，不屬於測試驗證的重點，在寫測試的時候常常陷入重複設定的地獄。

於是在 AwesomeAssertions / AwesomeAssertions Object Graphs 的架構下，想辦法在做比對時去做到比較方便省事的設定方法，讓我輕鬆地去排除指定的欄位。

在找尋資料、解決方法的同時，也讓我得知不一樣的處理方式，將這些處理方式用文章記錄下來，也提供給大家做個參考。

其實這也不是新聞了，早在今年 1/15 時大家就已經知道並且被商業授權的費用給嚇了一大跳（每個人 $129.95 USD）。

現在特地寫一篇是因為上週因為 AutoMapper 將要變成商業化授權而寫了兩篇文章介紹替代套件，就想到好像並沒有對於 Fluent Assertions 轉變為商業授權去寫一篇文章與替代方案，於是就以 Fluent Assertions 從 v8.0.0 起轉為商業授權，簡單寫了這篇去說明授權限制、專案應對策略，以及替代的 Assertion Library，提供給大家做個參考。

調整設定搭配命令列模式 , 快速進行 SQL Server 安裝

寫個存取DB小功能

Drill Down，常被翻譯或解讀為深層探究、向下鑽取、深入探索、向下切入、…這描述與形容我都覺得很傳神，也很有意境。在層層疊疊嵌套式結構化資料的架構中，由廣入深的探究底層的資料與有用的訊息，正是資料分析與探勘的必要手段。(系列文章實作練習下載)

Mapperly 在以前找尋替代 AutoMapper 的時候就有看過，但當時著重在與 AutoMapper 設定與操作習慣相近的替代套件，所以對於 Mapperly 就沒有太多的關注。

直到寫了「替換映射工具 - 使用 Mapster」這篇文章後才稍微去看看 Mapperly，發現到它和 AutoMapper, Mapster 雖然都是屬於 Mapping 工具，都是做物件對映轉換的處理，但設定與使用上就有蠻大的差別，所以寫篇文章做個簡單的紀錄。

整合 GitHub Action 在 Self Host Runner - 不分平台篇

整合 GitHub Action 在 Self Host Runner - Android 篇

整合 GitHub Action 在 Self Host Runner - iOS 篇

建立 GitHub Action Self Host Runner 

其實四年前就已經將手邊專案由原本所使用的 AutoMapper 以 Mapster 取代了。

起初的原因是效能考量，因為 AutoMapper 的效能一直被人詬病，但也因為 AutoMapper 的優點在於功能豐富、配置設定靈活，能夠處理複雜的 Mapping 需求，以致於我在帶新人的時候還是以 AutoMapper 為主，但是前些日子得知 AutoMapper 在之後也將走上商業化（跟 Fluent Assertions 一樣），所以就藉此來寫篇文章簡單介紹 Mapster。

Javascript多執行緒+非同步應用動態載入大量元素到Dom

加一個簡單api

Get Files from Directory

Must have pro license to use this module.

在 python 利用 FastAPI 建立 API 非常的簡單，同樣的，要測試它也非常地容易，這裡我會使用一個簡單的例子，演練 pytest 測試 API (FastAPI)

今天 (2025-04-06) 早上在 Facebook -  台灣 .NET  技術愛好找論壇裡看到 Will 保哥轉貼了一則 X 貼文，
要檢查一個集合物件是否有元素在內，會使用哪一種語法來檢查 … 

在 C# 開發中，經常需要判斷一個集合是否有包含任何元素。雖然這是一個簡單的判斷，但其實背後有不少值得探討的細節。就來瞭解這四種常見的做法，並分析它們的優缺點與適合的使用情境。

對於階層式的資料，除了利用紀錄父階層的 Id 之外，SQL Server 可以使用其特別專屬的 hierarchyid 來做處理 

pytest 是一個功能強大且靈活的 Python 測試框架，身為一個開發者學好怎麼寫測試是基本的必要條件，以下是我對 pytest 的使用心得。

CoPilot 與 Google Gemini哪一個比較「人性化」？

之前有介紹過 TestContainers 在 .NET 的使用方式 傳送們，同樣的 Python 也可以使用它，就不再贅述太多；我將使用 WSL + Python 環境搭建起開發環境。

Table容器是Power Query中處理結構化數據的核心工具，也就是我們俗稱的資料表(Data Table)。透過行、列方式儲存資料，可以執行篩選、合併、轉置等多樣操作，滿足數據清理與轉換的需求。Table容器在資料整合中更扮演重要角色，可以整合多個來源數據，也是進行複雜分析的基礎，能與Excel及Power BI無縫對接，支援樞紐分析、動態報表等。熟練掌握Table容器不僅能提升工作效率，還有助於應對多樣化的數據分析需求，是瞭解與學習Power Query的關鍵一步。

經過這一輪的List(清單)實作，相信您對清單的結構、語法與特性，有些基本認識了吧！接著，我們就來看看另一個Power Query容器：Record(記錄)的特性。

除了使用［向下切入］或點開超連結的操作來執行擷取List元素之內容的查詢步驟外，也可以透過程式碼的編輯來達到相同的目的。這時候就一定要懂得List索引值的概念了。