平屋慢生活

Redis單執行緒會不會撐不住高併發與其他服務相比🍂 併發問題與 Optimistic lock🍂 樂觀鎖🍂 我真的需要 WATCH + MULTI 嗎🍂 多條件一致性🍂 庫存到底該放 Redis 還是 SQL想像一條高速公路，如果有太多交流道、紅綠燈、車子搶道，雖然看起來能同時容納很多車，但實際上常常塞爆，而 Redis 的設計是，入口很多 + 收費站只有一個，但每台車過站只要 0.001 秒，除非突然來了一台「超寬超慢的車」，這麼設計是因為，Redis 幾乎只做單純的操作，例如 : 從記憶體拿資料、在記憶體改資料，並且結構非常單純（key → value），他不需要管 join、constraint、transaction 等複雜邏輯，所以它可以保證「每個操作都很短、可預期」 Redis 把所有資料放在記憶體裡，所以車子（請求）一旦進來，就能以極快的速度通過。這種設計讓 Redis 在需要低延遲的場景裡，成為最可靠的快取層。它不追求資料永遠存在（Persistence），而是保證當下的快與穩真正會壓垮 Redis 的不是請求數，而是「單一請求做太多事」，Redis 怕的不 ...

https://ithelp.ithome.com.tw/m/questions/10211504 物件導向設計 (OOD) 通常是比結構化設計 (SD) 更好的選擇。物件導向設計是一種軟體設計方法，它強調將系統分解為可重用的、相互協作的物件。這使得軟體更易於理解、擴展和維護。 現在RD的分工都很細，在開發或維護大型系統(或應用程式)的過程中，每個人可能只負責一個小部分功能，而且需求經常會因應市場環境(或老闆的喜好)不斷的變更(甚至變更到發布的前一天晚上還在變更)，如果沒有用物件導向的方式來組織各個模組，那在工作的協同上勢必會遇到一大堆bug。 抽象化的過程是讓程式碼更貼近人的思維，並不會讓程式碼變複雜，反而是變得更容易理解且更好維護才是，如果你的物件導向會讓你的程式碼變複雜，那應該好好思考一下你寫的code真的是物件導向嗎？ 物件導向的設計還會使效能下降 為甚麼這樣說 封裝與間接層 (Indirection) 在物件導向裡，資料和行為綁在一起，所以往往需要多一層方法呼叫。 例如： order.Total = order.CalculateTotal(); 在結構化設計可能 ...

https://medium.com/%E9%96%92%E8%AB%87%E8%BB%9F%E9%AB%94%E6%9E%B6%E6%A7%8B/%E9%96%92%E8%AB%87%E8%BB%9F%E9%AB%94%E6%9E%B6%E6%A7%8B-plug-in-ed2cbce7464a https://code-maze.com/csharp-plugin-architecture-pattern/ plugin1 1plugin1 2

paymentPlugin Pattern（外掛模式）卡帶實作Factory Method Pattern（卡帶管理員模式）Reflection 遊戲機的讀卡頭執行遊戲flowsumary在開發金流或第三方整合系統時，一定會預期到金流是無止盡在擴充的，今天要支援 LinePay，下個月要加上 ApplePay，後天客戶希望有 GooglePay、PayPal 如果每增加一種支付方式都要打開主程式去修改，就好比一台遊戲機的遊戲被寫死在機器裡，每次想玩新遊戲，就得整個流程要再改一次，想想就覺得很可怕 好的設計主軸是 遊戲機本身保持穩定，玩家只要插上不同的卡帶，就能享受不同的遊戲 必須要接受支付方式一定會一直增加，LinePay、ApplePay、GooglePay 不會是最後一個，只會是個開始，因此把「會變的部分」獨立出來，不同支付流程、API、驗簽方式，我們把它全部抽成「外掛模組（Plugin）」，而主程式只負責呼叫介面，它不關心甚麼 Pay，只知道「你是一個 Payment Plugin」，並且透過工廠（Factory）拿對卡帶，根據設定或參數，決定要載入哪一個 Plugin 實作， ...

那天早上，廣播突然響起 ——「各位家長請注意！吉伊寶寶順利考取除草證照 5 級！」不到三秒，家長們已經刷了滿滿的貼圖，含淚喝采 這則喜訊，像是一場同步播放的快閃演出，正在教室自習的悄悄看了手機，忍不住笑到被同桌戳了一下；咖啡廳裡打工的，拉花時多畫了一片草葉致敬；剛進辦公室的設計師，立刻在筆記本上畫了「五級除草王」的手繪海報；外送路上的長，順路把好消息送到各個巷口；還有剛下班的夜班便利商店店員，抱著零食袋邊走邊笑說：「值得熬夜等這條消息！」 如果你覺得這畫面很熟悉，那是因為它就像程式世界中的「觀察者模式（Observer Pattern）」—— 一個事件發生，所有「訂閱」它的人會同時收到通知，不用一個個去問。       同一個消息，在不同的心裡綻放成各自的顏色。 如果你覺得這畫面很熟悉，那是因為就是程式世界中的 觀察者模式（Observer Pattern） —— 當一個事件發生，所有訂閱它的人會同時收到通知，不用一個個去問。 🪵 廣播器情境想像有一台「家長廣播器」，只要一播送，所有家長都會同時聽到並作出反應 ...

Serialization&Deserialization從記憶體城堡到數位信件狀態的保存與重生一一對應的映射關係兩大 JSON 操作流派Newtonsoft.Json 的古典魔法：JObject 與 JArraySystem.Text.Json 的現代魔法：JsonObject 與 JsonArrayNewtonsoft.Json：經典範例Test.JsonNewtonSoft vs Text.Json空 list 序列化後還是 []Refit 的 api_response 無法 deserialze 原因探討summary在數位世界中，序列化（Serialization） 和 反序列化（Deserialization） 就像是一對魔法師，負責在不同的資料形式之間進行轉換。想像一下，您有一個複雜的 C# 物件，裡面包含各種屬性、巢狀結構，甚至是陣列——這些資料存在於程式的記憶體中，就像是一座精美的城堡，但這座城堡只有您的程式看得懂 當您需要將這些資料傳送給其他系統，或是儲存到檔案中時，就需要將它們「打包」成一種通用的格式。這就是序列化的魔法： 1234567891011// 原始的 ...

在數位世界的浩瀚星海中，有一種神秘的語言穿梭於不同的系統之間，它就是 JSON。今天，讓我們踏上一場探索編碼奧秘的旅程，揭開 Unicode 轉義背後的故事。 先前提到的加密通信中，人類會有 發公鑰 或 交換公鑰 的行為，但實務上，除非這個人走到你旁邊，手寫這一段公鑰交給你，否則你無法確信這一段到手的公鑰訊息被動過甚麼手腳 所以人類又想到了，我們引入 “第三方公證人”吧 (考駕照也是要到駕訓班認證過，上交幾隻雞腿，然後才能拿到駕照上路吧) 當有一個傢伙他想要發布公鑰時，他就要走進這個公正的機關 (CA Certificate Authority)，在這個世界做資料驗證與證書頒發 於是就有了 “證書”(Certificate) 的概念 Certificate證書包含:1.持有人姓名2.發證機關3.證書效期4.證書持有人公鑰5.其他訊息6.Signature… 以最生活化的例子果然還是 “HTTPS” 了吧，平時瀏覽網站時總會看到一個鎖在瀏覽器上，表示 “該網站是經由公正CA認證過的” 比如 今天 yolin.io 向 CA 機構申請一張證書: 1.填上 ...

在瀏覽器輸入網址時，是否有注意過上面的編碼跟想像的不太一樣呢? 舉個例子: 有一個電商網站，允許用戶搜索商品，並對搜索結果進行分頁和排序 原始提交的搜尋:https://www.example.com/search?q=電視機&brand=大同&price=1000-2000&page=1&sort=price_desc 編碼後:https://www.example.com/search?q=%E9%9B%BB%E8%A6%96%E6%A9%9F&brand=%E5%B0%8F%E7%B1%B3&price=1000-2000&page=1&sort=price_desc 那如果直接把尚未編碼的 URL 在瀏覽器直接發 Request 會怎麼樣? 其實有一個很簡單的測試方法，直接在 Google 中文搜尋後，上面的瀏覽器 URL Bar 就會顯示: https://www.google.com/search?q=火車快飛&sca_esv=88708a24d6188b8d&sca_upv=1&rl ...

不知道大家有沒有使用過 Bouncy Castle，我自己是在串接金流時誤打誤撞碰到，想當年(也才半年…)對 C# 加密、證書、簽章…都還沒甚麼概念的情況下，在網路上找到這個 Package，But…看名字還不太敢用，畢竟NuGet Gallery的 Candidate 多如腿毛 (這就是所謂的第一印象嗎?)，猶豫許久，後來發現公司專案也經有人引入並且使用過後，才鬆了一口氣… 加解密、簽章、證書等等處理，Bouncy Castle 像瑞士刀一樣，引用 Utilities，抽一把武器來用解決你的需求，且後來發現，原來他是一個跨語言的套件(想想好像也合理)，直接 Google 搜可能還會看到一堆 Java 的 Sample Demo現在有點難自己寫出來，所以先拿別人的Code來練習 取自 : https://blog.darkthread.net/blog/bouncy-castle/https://gist.github.com/therightstuff/aa65356e95f8d0aae888e9f61aa29414https://en.wikipedia.org/wiki/RS ...

🌊 DbContext 是什麼？ — 它就是你的「臨時記事本」 在 Entity Framework Core（EF Core）裡，DbContext 是一個很關鍵的角色，背後有兩個重要概念： 它是工作單位（Unit of Work） 它自帶一級快取（First-Level Cache） 當你在一個業務流程裡使用 DbContext 時，它幫你做三件事： ✅ 變更追蹤（Change Tracking） 追蹤每個被載入的 Entity 誰改了什麼，幫你記錄要更新的欄位。 ✅ 一級快取（First-Level Cache） 相同主鍵的資料，只要查過一次就放在 DbContext 的快取中，後續查詢就直接從快取拿，不會再打資料庫。 ✅ 單一交易（Single Transaction） 呼叫 SaveChanges() 時，會把所有變更一次送到資料庫並用同一個交易包起來，確保一致性。換句話說，DbContext 就像一個臨時記事本（背包 🧳），把這段流程需要用到的資料和變更都記錄起來，最後一次打包送到資料庫。 🌊 EF Core 的一級快取是什麼？所謂「快取」，指的是 ...