平屋慢生活

🍔 從 foreach 官方文件開始想要使用 foreach 的集合需要實作 System.Collections.IEnumerable or System.Collections.Generic.IEnumerable interface foreach 的真正實現，是一個迴圈控制結構，必須知道： 怎麼取得下一筆資料 (MoveNext) 怎麼拿到目前這筆資料 (Current) 怎麼從頭開始 (GetEnumerator) 這一切都來自於 Iterator 模式，也就是 .NET 中 IEnumerable / IEnumerator 的設計核心。 🍔 有一天我在摩斯排隊點餐，但前面點餐的大叔點有點久，於是我開始發白日夢…一位客人 1234567public class FatLaw{ public int Number {get;set;} public string [] Menu {get;set;}} 排隊點餐的一群客人 123456789101112131415161718192021 ...

雞巴人NOT INNOT EXISTSLEFTJOIN... IS NULLEXCEPT測試方法你曾經鼓起勇氣，傳訊息給喜歡的人，卻始終只收到那令人心碎的「已讀不回」？你也曾在朋友聚會中，主動張羅大小事，結果現場只來了一半，還都最後才現身？ 你就是個魯蛇 這背後有「資料科學」的真相，就是所謂的隱藏多數       全部的人 - 出現的人 = 雞巴人 今天，我不想再假裝一切都沒發生。我要來製作一張黑名單，把這些嘴上說愛你、行動卻放你鴿子的人，通通揪出來！ 手上有兩份資料： Friends（朋友名單）：那些理論上應該會出現的傢伙 Attendance（實際到場名單）：那些真的有出現、值得你好好珍惜的朋友 接下來，我們要開始用幾個方法，來抓出那些含糊不清的嘴砲王 「拿一個主表的鍵，去跟一張子查詢產生的名單比對，只留下『不在名單裡』的那些資料」 123SELECT FriendID, FriendNameFROM FriendsWHERE FriendID NOT IN (SELECT FriendID FR ...

關於曉關於資料庫tempTable 拆查詢summary曉組織從不會跑去逐村、逐個忍者詢問「你是不是叛忍」，那樣太慢 他們先整理來自各村的大量任務紀錄，任務失敗率、行蹤中斷、查克拉特徵異常、忍術使用頻率…把整個忍界的龐大資料先「彙整」出一小群行為模式明顯脫離正常範圍的忍者。 等到名單縮小之後，曉組織才拿這份「疑似叛忍清單」去比對外部情報：黑市名冊、走私紀錄、賞金通緝、各村密報……這就像 JOIN 小表。 先把大集合縮到只剩「關鍵群體」，外部情報才能精準派上用場；不然會浪費巨大成本也找不到目標 不好的處理方式假如有以下資料 表格 筆數 說明 a 1,300,000 筆 主資料表，存放每筆紀錄（包含 name、bid、cid、did、count、position） b 5 筆 小表，包含欄位 col1 c 5 筆 小表，包含欄位 col2 d 5 筆 小表，包含欄位 col3 需求是針對每一組 (a.name, a.bid, a.cid, a.did)，計算 SUM(count) 與 AVG(position)，並且 JOIN b、c、d 取出對應的欄位 col ...

一生中有三大難題🧪 實戰💩🐛 結語☘️ 人的一生中有三大難題： 中午吃什麼? 明天要不要請假？ 怎麼把一堆資料拼成一句話？ 前兩個我還在想，第三個已經找到解答了—— STRING_AGG 他常用來作為文字串接的聚合函數，官方定義是這樣子的 :用於把 “指定的欄位” 串成一個 “以指定分隔符分隔的字符串”，不用寫一堆複雜的迴圈或自製拼接邏輯 123456STRING_AGG ( expression, separator ) [ <order_clause> ]<order_clause> ::= WITHIN GROUP ( ORDER BY <order_by_expression_list> [ ASC | DESC ] ) 每天上班打開公司群組，就像打開一個沒人整理過的資料表，一堆廢話、貼圖、+1、讚、下午茶，語焉不詳的訊息而零散像剛剛爆炸過。有時真的很想把他們 STRING_AGG 起來丟到任何看不見的地方「那個誰，幫我把這個資料表裡的這些串在一起」光頭手上揮舞著資料像在招魂一樣，語音剛落 123 ...

當我們在 C# 中使用 LINQ 查詢語法（Query Syntax）時，這種查詢語法看起來簡潔且易於理解，但實際上，.NET 的 Common Language Runtime（CLR）並不直接支援這種語法。CLR 主要還是處理方法呼叫 (method calls) 和其他基本的程式碼結構。 簡單的例子 12345678910111213int[] numbers = [ 5, 10, 8, 3, 6, 12 ];//Query syntax:（查詢語法）IEnumerable<int> numQuery1 = from num in numbers where num % 2 == 0 orderby num select num;//Method syntax:（方法語法）IEnumerable<int> numQuery2 = numbers.Where(num => num % 2 == 0).OrderBy(n => n); 看起來是兩種完全不同的寫法，但 本質上查詢語法只是語法糖 (syntactic suga ...

上班, 免不了要處理一些維運和監控的工作(請假)。然而,有時會遇到自己無法理解,也不知從何下手解決的異常情況,例如記憶體不足 (Out of Memory, OOM)。為了更好地應對這類問題,嘗試探索一下記憶體管理的相關知識,看看能夠理解到什麼程度 Managed Heap為了做到記憶體管理，在 .NET 中 當我們建立一個物件時，不是直接從 OS 的記憶體中分配，而是會從 .NET Runtime 已經預先分配的 Managed Heap 中分配記憶體。舉凡一般的 Reference Type 操作以及資料庫連線，都在這個範圍內Managed Heap 本質上是一長條的記憶體空間。.NET 會維護一個指向 Managed Heap 中下一個可用地址的指標。當 .NET 被要求創建一個新物件時，它會在這個地址分配所需的空間給這個物件，並將指標向前移動，以指向下一個可用地址。 Address Size Type0x00ad21e0 16 System.Int32[]0x00ad21f0 20 System.String0x00ad2204 32 MyClass0 ...

我們人生中最尷尬的某些時刻，不是沉默，而是訊息傳錯像是你在聊天室打了一句「我覺得主管頭好禿」，下一秒才發現你傳的是公司群組聊天室。你懊悔、你重開手機假裝這一切會 Reset、數秒鐘後你開始思考辭職信該不該寫得文藝一點。 又或者你做為一個老師，把生活中的小抱怨傳到學生群組中 來自 Thread 一篇貼文的情境支援 這種「錯頻溝通」其實不只在人生會發生，連程式也會。我們寫程式時，也會很天真地以為，訊息只會送到我們想送的人那裡。但如果發送 Request 時，將秘密資訊設定在 HttpClient.DefaultRequestHeaders 上，相當於把「寫給 A 的情書，貼在公共佈告欄」。 📲 為什麼會這樣？HttpClient 是一個設計上建議共用的元件，也就是說，我們應該用一個 HttpClient instance 去處理多個 request，以節省資源、避免連線耗盡（像是 socket exhausted）。 但問題也就來了：既然大家都用同一支手機在傳訊息，那麼貼在手機上的「身份識別貼紙」（也就是 DefaultRequestHeaders 裡的 token）是不是有可能搞混？ ...

這是一隻蛇蛇。突發奇想想用 / 畫出來當開場，欸還真不錯，看著看著竟有點可愛（？） 🐍 寄錯的明信片有時候，一行程式碼，就像一張寄出的明信片。 你滿懷誠意地寫下問候、地址、郵遞區號，甚至還貼上特別版的郵票，只為讓那封來自心底的訊息，抵達你想念的那個人手上。 但你忘了一件事──地址格式要「符合規格」。 就像 HttpClient 看著那個不完整的 BaseAddress，露出一種：「呃，好啦我自己猜看看好了」的尷尬表情。於是它猜錯了，訊息雖然出發了，但永遠沒有人收到。 🐍 建立實驗讓我們來實驗一下 BaseAddress 設定錯誤會發生甚麼事吧! 1.Autofac 註冊HttpClient12345678910111213141516171819public class ServiceModule : Module{ protected override void Load(Autofac.ContainerBuilder builder) { builder.RegisterType<BoredHttpClient>() .As& ...

煩惱DateTime.Now and DateTime.UtcNowDateTime.Kind時區轉換日期轉字串字串轉 DateTimeDateTimeOffset會議邀約實作練習工作上時不時就會碰到時間的處理 DB 該存甚麼時間? 部署到不同環境會不會有時區問題? 收發推播會不會因為時間處理不周導致收發有問題?首先我們先簡單確認一下這兩者在我們台灣的本機執行會印出什麼時間: 1234DateTime.Now.Dump(); //// 5/12/2024 9:16:01 PMDateTime.UtcNow.Dump(); //// 5/12/2024 1:16:01 PM DateTime.Now 給的是那台機器的 Local Time，所以我在我的本機執行，抬頭看看時鐘，嗯嗯一模一樣 (我曾經有在 Code 裡面看到 DateTime.Now.ToLocalTime() 的寫法..) DateTime.UtcNow 給的是目前的世界標準時間，而台灣、香港都比標準時間所在的位置快了 8 個小時，所以會得到比時鐘少 8 小時的結果承襲上一段，雖然好像理所當然，但假如這個時間在程式 ...

呼叫器🎵 章節一：傳訊以後的沉默 —— S3 上傳的非同步陷阱明確等待，確保任務完成先執行、後等待，彈性處理任務進度非同步方法其實長這樣你說等等，那我就等等洗內褲的故事...用 Throughput 的眼光看非同步 —— 效率不是來自加速，而是來自不浪費非同步的最佳戰場：I/O Bound vs CPU Bound那杯咖啡，終究會響起提示音 我拿著號碼呼叫器，坐在靠窗的位置。 咖啡廳裡播放著熟悉的爵士樂，氣味是熱牛奶與咖啡豆交融後的溫暖。呼叫器還沒響，但我確定店員剛剛有聽見我點了那杯熟成黑咖啡。 我不確定她現在是不是正在打奶泡，或是還在處理上一張訂單；我也不確定我該不該起身確認一下。但最終我選擇坐著，等她做好準備、等震動響起，等那杯「尚未完成的事」，被端到我手中。 這是一段將資料上傳到 S3 的程式碼 12345678910111213private async Task UpdateS3DataAsync(string s3RecordData, string s3Path){ using var stream = new MemoryStream(Encodin ...