寫 C# 久了之後，會發現效能改善不一定都要做到很複雜
很多時候不是要換架構，也不是一定要上什麼很進階的技巧， 反而只是一些平常寫 Code 時的小習慣
例如少查一次 Dictionary、少產生一個 String、少配置一個 Array，單看一次幾乎沒有差
但如果這段程式每天跑幾十萬、幾百萬次，這些小地方累積起來其實就有差了..
前一篇測試了 Scriban，主要目的就是希望在 .NET 10 裡面
可以讓前端頁面在執行期直接修改，不用每次都重新 Build、Publish、Deploy..
前一篇測試了 RazorEngineCore，主要目的就是希望在 .NET 10 裡面
可以做到像以前 ASPX 一樣，前端頁面可以直接修改，不用每次都重新 Build、Publish、Deploy..
最近在測試 .NET 10 製作網站時，遇到一個很現實的問題
以前使用 ASP.NET Web Forms，只要建立一個 product.aspx?id=1， 我就可以去更改 .aspx 裡面的內容或是樣式
設計師修改版面時，只要替換 .aspx，完全不用重新編譯整個網站
但是到了 ASP.NET Core Razor Pages，.cshtml 預設會在發布時編譯進 DLL
最近一直在測試各種可以產生圖片與影片的 AI API
前一篇測試了 Agnes AI 的圖片生成， 既然圖片可以直接用 API 產生，當然就會想看看影片是不是也可以
結果 Agnes AI 也有提供 agnes-video-v2.0 影片生成模型，而且可以直接透過 API 呼叫
Agnes AI 官方目前也將圖片與影片模型列為可透過 API 使用的多模態功能
最近都一直在測試有沒有可以產生圖片的 AI，看到 Agnes AI 有提供圖片生成 API，目前 agnes-image-2.1-flash 產生圖片的價格是 $0 / 張。
這時候我就感興趣了，可以有不用錢又可以透過程式產生圖片的機會，當然要用一波，畢竟現在 token 都好貴 :'(
最近我遇到一個 GitHub 圖片載入的問題
我習慣把 Blog 使用的一些圖片放在 GitHub Repository，網站直接使用 GitHub Raw URL 顯示圖片
原本一直都正常，但最近在單一 Client 一次讀取比較多圖片時，突然開始出現下面的錯誤
429: Too Many Requests For more on scraping GitHub and how it may affect your rights, please review our Terms of Service
(https://docs.github.com/en/site-policy/github-terms/github-terms-of-service).
最近小米推出了 Mimo2.5 Pro，各家 Token 成本也越來越高。小米官方也推出了百萬億創造者激勵計畫
身為米粉當然一定要申請一波，申請網址：https://100t.xiaomimimo.com/
像 OpenClaw 這種東西我其實是會怕的，因為它太強了
越強的 Agent，代表它可以碰的地方越多，能做的事情也越多
可是回到我自己的使用場景，其實很單純，我大部分時間只是想拿來 寫 code、改 code、看 code，沒有真的想把整台機器都交給 Agent
所以後來我就想，那乾脆不要一開始就追求一隻超大超猛的怪獸，先自己開發一隻比較順手、比較可控、比較像工程師日常會真的用的小東西。
也就是這隻 "小蝦"：CopilotClawD
最近朋友問我可不可以不透過 Visual Studio or Visual Code 呼叫 Github Copilot
感覺起來他就是要幹大事，其實問一下 AI 就知道可以不過我還是測試一下
畢竟可以讓程式自己寫程式，一直都是工程師的浪漫?
很多人一開始看 async/await，都會先把它當成語法糖。
我自己一開始也是這樣想
就覺得不就是把同步改成 await，讓 thread 不要卡住，看起來也比較現代一點，而且你現在用 copilot 應該也是 tab tab 就出來了
但真的在 API、網站服務，或是有點流量的系統裡用久之後，才會慢慢發現
async 不是只有能不能跑而已，它其實還會影響 效能、記憶體使用量，還有整體穩定度
有些 async code 表面上完全沒問題
但如果剛好寫在系統很常被呼叫的地方，它就可能一直默默建立 Task
平常流量小的時候不太有感，等到 request 一多，GC 開始變忙，延遲就會慢慢浮出來
一開始看到 record，其實完全抓不到重點
看起來跟 class 很像，而 class 又早就被拿來跟 struct 比過無數次
現在再多一個 record，第一反應只覺得，是不是又一個學了也不一定會用到的語法糖..
最近在整理一段舊系統的商業邏輯時，發現錯誤處理幾乎清一色都是 try/catch + throw
現在其實已經是 21 世紀了，很多時候有更好的方法可以處理 try catch 跟以前學習的方式有點不同
這篇單純記錄我實際套用 Result Pattern 後的想法與最小可行寫法筆記一下..
聊一下關於好用的 LINQ 很多時候我們從資料庫撈出資料來，並且透過 API 往外吐，這是後我們都會把肥大的資料
拿掉一些或是組合一些欄位，之後再往外面吐，當然這沒什麼問題但...
最近遇到一個老專案，他之前設計都讓客戶自由輸入生日，不過幸好 placeholder 提示
至少他的客戶是乖乖輸入 國曆xx年xx月xx日，或是農曆xx年xx月xx日，但是他現在跟我說要算
天干地支跟五行...WT...
最近都再釐清一些觀念跟償還技術債，其實只要常常遇到程式要大量改寫成非同步化常常對專案都是
毀滅性的更改，也就是大量翻修，這裡面有一個很常被忽略的東西，處理的好才能夠把非同步化達到最大價值
很多人聽過 MessagePack，但真正用在 Web API 上的機會其實不多，尤其是完整從 Client 到 Server 都走 binary 傳輸的情境
這篇文章用 .NET 10 示範一個最小可行的案例，實作一個只接受 MessagePack 的 Web API，並搭配一個 Client 呼叫範例
讓整個傳輸流程從頭到尾都清楚可以快速複製貼上了解
MessagePack 其實一直都聽到這名詞，但是因為在這 JSON 當到的現在比較少處理這東西，所導致我聽到很久了
但是也沒有實際去測試他，最近測試一下似乎蠻好用的
