平屋慢生活

https://vocus.cc/article/67fa5aeffd89780001cc79ef

讓團隊知道為什麼要做，這件事比較少，常常 kickoff 與 refine 可能一起開，且比較偏向就是指派的感覺而不是協作，團隊就是先接下來再討論怎麼做，且通常專案專案之間沒甚麼空隙，通常是直接案直接壓進 Sprint 讓 RD 知道這功能和 KPI、用戶痛點的關聯，會提升投入感。 >> 反正都是說 用戶想要 沒惹 不太會跟工程師確認認知上的 未知程度 費工程度 複雜程度

OverloadConsole.WriteLine()String.Format() 或 $"{value}"HttpClient.GetAsync(...) 重載Overload 是讓「使用者思維」與「開發者實作」分離Overload 幫助 API 適應成長需求（可擴展性）用 Overload 做「語意導向」的 API 設計（Intent-Driven Design）取代複雜參數物件或旗標（Flag）用在「動作不變，情境變化」的功能設計Anti - 語意模糊Anti - 過度 overloadAnti - 行為不一致，產生不可預期狀態結語 對使用 API 的開發者來說。當他們呼叫一個方法時，心中想的只是「我要讓它運作」，卻不希望因為情境稍有不同，就被迫學習一整套全新的操作方式。這就是 Overload（方法重載） 存在的理由，它讓同一個「旋律」能被多種方式演奏，保持一致性，同時降低學習與使用的心智負擔 我們平常在寫 Console.WriteLine() 的時候，可以丟 string、int、bool、甚至物件，對吧？因為每種型別印出來的方式不一定一樣，比如物件就會呼叫 ToStr ...

在資訊的天空裡，每一次請求都是一隻信鴿。它揹著我們的訊息，穿過纜線與路由器，飛往未知的彼端。 但如果我們只急著把字條塞進它的翅膀，信鴿或許能起飛，卻未必能安全抵達。它需要一個完整的「航行指令」：要飛向哪裡、攜帶什麼、如何證明身份、以何種姿態展現誠意。 HttpRequestMessage 就是這份航行指令。它讓我們能在雲端的長風中，為信使裝備地圖、護照與行李，確保訊息能準確無誤地抵達遠方。 📨 HttpRequestMessageHttpRequestMessage 的存在就是為了讓 HTTP 請求能「物件化」並且「延後執行」，這是一種「Command Pattern」的應用：          組好請求指令 → 再交給執行者 HttpClient → 再送出 這樣做的好處是： 請求可以先組好但晚點再送 可以重複使用或修改 可以做攔截、紀錄、包裝（例如透過 DelegatingHandler） HttpRequestMessage 是一個「請求的包裹」，你可以把它裝滿所有你要送 ...

在古老的時代，國王要把詔令送往四方，往往需要派出一位信使。但這位信使總得記住每一段路線、每一條小徑，甚至還要自己翻譯當地的語言。每一次派遣，不僅耗費心力，也總有出錯的風險。 程式世界裡的我們，也常常面臨相同的窘境。每次要呼叫第三方 API，就得重複 HttpClient、手動處理序列化與反序列化，還要加上各種 Retry、Logging。久而久之，這些細節就像一張張散落的地圖，讓信使負擔沈重。 而 Refit 的出現，就像給我們一套「信使專屬的傳令書」。只要定義好任務（Interface），信使便能自動遵循指令，把訊息送達遠方，並且用我們熟悉的語言回報結果。從此，我們不必再煩惱翻譯、路線和格式的細節，只需專注於該傳遞的訊息本身。 他讓我們能夠以 Interface 來定義 怎麼串接第三方 API 。 所以我們不需要直接使用 HTTPClient，而是定義一個 Interface，Refit 會將 Interface 的方法包裝起來，處理 HTTP 請求並將 Response 數據序列化為 Interface 中指定的類型，還可以組上自製的 HttpMessageHandler 以及處理 ...

在浩瀚的網路之海，每一次 API 呼叫，就像派出一位無聲的信使。他背著我們的訊息，穿越纜線與雲層，去敲響遠方伺服器的大門。而我們該如何訓練這些信使？如何確保他們既不迷路，也不在途中耗盡力氣？這就是 HttpClientFactory 存在的理由。 📨 A. 方法內各自 CreateClient（匿名信使）每次出征時，我們都臨時徵召一位信使，並告訴他要去的目的地與身份證明。信使們雖然每次看似「新生」，但其實都共享一條秘密通道（Handler Pool），因此不會因為頻繁占用多個港口。但缺點是每次都要重複交代路線與口令，若忘了，就會讓信使迷途。 12345678910111213141516171819202122232425262728293031public void ConfigureServices(IServiceCollection services){ services.AddHttpClient(); services.AddRazorPages();}public class LineService : ILineService&# ...

在浩瀚的網路之海，每一次 API 呼叫，就像放出一位無聲的信使。他揹著我們的訊息，穿越纜線、翻越路由器，終於抵達遠方的伺服器。然而，這段旅程並非沒有代價。 當信使啟程時，作業系統會替他分配一個「臨時的港口」（ephemeral port），讓他能安全啟航。但若我們過於頻繁地呼喚、過於急切地派遣信使，這些港口就會一個接一個被佔滿。直到最後，新信使無處登船——這就是 Socket Exhaustion 的隱憂。 📨 TCP 4-tuple要出海，信使需要四件通關憑證： 假設我們今天上 Google 首頁，其實就是建立一條 TCP 連線，這條連線會用到這「四件東西」來唯一識別這條通道： 項目 說明 你的 IP（來源 IP） 例如：192.168.1.100 你的 Port（來源 Port） ⚠️ 是作業系統隨機分配的，例如 51234 伺服器的 IP（目的 IP） 例如：142.250.190.46 伺服器的 Port（目的 Port） ✅ 這通常是 80（HTTP）或 443（HTTPS） 這四個合起來叫做：TCP 4-tuple就像護照、簽證、船票與碼 ...

在這個時代，我們打下一行簡單的程式碼，資料便能穿越海底電纜、飛越路由器之間的節點，抵達遙遠的伺服器。這一切對我們來說只是「一次 API 呼叫」，卻在背後上演著一段浩瀚的旅程。 想像有一位無聲的信使，他從你的程式出發，手中捧著訊息，沿著電纜與協定鋪展的道路一路前行。途中他會經過城市的路由器、跨越國界的骨幹網路、穿梭雲端的防護牆，最終抵達遙遠的伺服器大門。完成使命後，他又沿著相同的路徑回返，把遠方的回應帶回到你眼前。 這位信使，就是 Socket。他是隱形的橋樑，是程式與世界的通道。在鍵盤與螢幕的另一端，他靜靜地，卻堅定地奔走於無形的網路之海。 📨 Socket 是什麼？Socket 可以理解為「程式」與「網路」之間的連接點（endpoint）。它讓你的程式能透過 IP 和 Port 與外界通訊，發送或接收資料。 舉例來說： 當你寫了一個 Web Server，你會讓它透過一個 Socket 在 80 port 上「監聽」(listen)。 瀏覽器想連到你的網站時，會建立一個 client socket，去「連線」你的 server socket。 而 Port 是區分 ...

StackExchange.Redis它是由 Stack Exchange 團隊（就是經營 Stack Overflow 的那群人）開發維護的所以這個套件名字就叫做 StackExchange.Redis。 🧠 本質上，它就像是你（.NET 程式）跟 Redis 這個外部系統中間的一個翻譯官，透過這個翻譯官，對 Redis 下指令、讀寫資料、訂閱事件、操作快取。 🔧 StackExchange.Redis 幫我們做了哪些事？ 建立連線（像 ConnectionMultiplexer.Connect(…)） 存資料（像 db.StringSet(“key”, “value”)） 取資料（像 db.StringGet(“key”)） 訂閱/發布消息（Pub/Sub） 效能最佳化（自動管理連線、批次處理、壓縮） ConnectionMultiplexerConnectionMultiplexer 是一個管理 Redis 連線的「總管」，幫你處理所有連線、發送指令、接收資料、訂閱事件等等。它會幫你： 建立一條或多條 TCP 連線到 Redis 伺服器 管理這些連 ...

鎖定一般的快取流程（單純快取） 步驟是這樣的： 先去 Redis 找資料 X，有的話直接回傳。 如果 Redis 沒有，就去主資料庫拿資料。 拿到後再放回 Redis。 回傳給使用者。 看起來很正常吧？但問題在於 「快取缺席」的那一瞬間。 問題場景 假設同一時間有 1000 個人同時來查詢資料 X。 如果資料庫只要 80ms 就能回傳，這 1000 個人雖然 Redis 沒資料，但資料庫還能勉強頂住（同時湧入 80 個請求，壓力還算可控）。 如果資料 X 需要計算 8 秒（8000ms），那麼在 Redis 還沒被「補上」之前，這 1000 個人都會同時衝進資料庫，結果資料庫要處理 8000 個請求 × 8 秒 = 64000 秒 CPU 時間。這時候你的資料庫直接爆炸，整個系統癱瘓。 這就是為什麼你約會的時候還要拿筆電救火的原因：表面上流程合理，但遇到高併發 + 重運算，會出現「快取雪崩」的災難。 進階的快取流程（加鎖） 改良的方法是「加鎖」，步驟是這樣： 先去 Redis 找資料 X，有的話直接回傳。 如果沒有，就先拿到「資料 X 的鎖」，確保只有我能進去查主資料庫。 ...