<?xml version="1.0" encoding="UTF-8" ?>
<rss version="2.0">
    <channel>
      <title>Terry Yao&#039;s Blog</title>
      <link>https://terryyaowork.cc</link>
      <description>最近的 10 條筆記 on Terry Yao&#039;s Blog</description>
      <generator>Quartz -- quartz.jzhao.xyz</generator>
      <item>
    <title>微服務之旅：從「該不該拆」到「每一層該怎麼選」</title>
    <link>https://terryyaowork.cc/backend/micro-service/</link>
    <guid>https://terryyaowork.cc/backend/micro-service/</guid>
    <description><![CDATA[ 微服務之旅 這個系列不是規劃出來的，是走出來的。 起點很單純——我們的單體電商（FastAPI）在 UV 10 就報錯，想搞清楚「到底能撐多少人」。於是蓋了一個壓測平台，拿 9 個後端框架在相同條件下比較。 結果越測越多。後端測完想知道前端差多少，前端測完想知道 DB 怎麼選，DB 選完想知道要不要加 Redis，加了 Redis 想知道架構怎麼配。一個「簡單的壓測」變成了涵蓋前端、後端、資料庫、儲存、架構五層的完整技術選型。 最後回到起點的問題：到底該不該拆微服務？答案是「遲早要拆，但不要急」。大部分效能問題不是框架不好，而是配置沒做對——Redis cache + nginx keepal... ]]></description>
    <pubDate>Sun, 16 Aug 2026 00:56:38 GMT</pubDate>
  </item><item>
    <title>[algorithms] Treap 與 Splay Tree：不靠嚴格規則的平衡樹</title>
    <link>https://terryyaowork.cc/common/foundations/algorithms/59-treap-splay</link>
    <guid>https://terryyaowork.cc/common/foundations/algorithms/59-treap-splay</guid>
    <description><![CDATA[ AVL 和紅黑樹靠嚴格旋轉規則保證平衡，但手寫刪除的 case 分析能寫到懷疑人生。Treap 把平衡交給隨機、Splay Tree 乾脆不維護平衡改成自我調整——兩條「不硬幹」的路，換來更好寫的程式碼與競程最愛的區間操作。 ]]></description>
    <pubDate>Tue, 11 Aug 2026 00:00:00 GMT</pubDate>
  </item><item>
    <title>[algorithms] Sparse Table：靜態區間查詢的 O(1) 特快車</title>
    <link>https://terryyaowork.cc/common/foundations/algorithms/60-sparse-table</link>
    <guid>https://terryyaowork.cc/common/foundations/algorithms/60-sparse-table</guid>
    <description><![CDATA[ 線段樹能 O(log n) 查區間最小值，但要建樹、要維護，還得吞下那個 log。當資料建好就不再改，Sparse Table 靠倍增預處理把每次查詢壓到 O(1)——代價只有一個：不准改值。這是靜態 RMQ 場景最俐落的一招。 ]]></description>
    <pubDate>Tue, 11 Aug 2026 00:00:00 GMT</pubDate>
  </item><item>
    <title>[algorithms] 單調佇列：為什麼滑動視窗最大值天生要用它</title>
    <link>https://terryyaowork.cc/common/foundations/algorithms/61-monotone-queue</link>
    <guid>https://terryyaowork.cc/common/foundations/algorithms/61-monotone-queue</guid>
    <description><![CDATA[ 暴力掃每個視窗的最大值是 O(nk)，視窗一大就爆。單調佇列讓每個元素只進出各一次做到 O(n)，關鍵是一個反直覺的動作——新人進來時，把尾端所有又矮又比它早走的舊候選人直接請走。這篇聚焦單調佇列這個結構本身，以及它為什麼是佇列而不是棧。 ]]></description>
    <pubDate>Tue, 11 Aug 2026 00:00:00 GMT</pubDate>
  </item><item>
    <title>[algorithms] 持久化線段樹：舊版本不用整棵複製，只複製一條路徑</title>
    <link>https://terryyaowork.cc/common/foundations/algorithms/62-persistent-segment-tree</link>
    <guid>https://terryyaowork.cc/common/foundations/algorithms/62-persistent-segment-tree</guid>
    <description><![CDATA[ 一般線段樹改一次值，舊版本就永遠消失了。但很多題目要查「歷史某個版本長怎樣」或「區間第 k 小」——你需要保留每一版。整棵複製是 O(n) 空間爆炸；持久化用路徑複製只複製被改到的那條 log n 路徑，其餘節點跟舊版共享，每次改動只多 O(log n) 空間。 ]]></description>
    <pubDate>Tue, 11 Aug 2026 00:00:00 GMT</pubDate>
  </item><item>
    <title>[algorithms] Fibonacci Heap 與 Link-Cut Tree：把攤還成本壓到極致的兩把武器</title>
    <link>https://terryyaowork.cc/common/foundations/algorithms/63-fibonacci-heap-lct</link>
    <guid>https://terryyaowork.cc/common/foundations/algorithms/63-fibonacci-heap-lct</guid>
    <description><![CDATA[ 二元堆的 decrease-key 是 O(log n)，在稠密圖上跑 Dijkstra 那些 log n 累積起來很痛——Fibonacci Heap 用懶惰整理把它攤還到 O(1)。靜態樹的路徑查詢碰到「邊會加會刪」就整套失效——Link-Cut Tree 拿 Splay Tree 當零件在動態森林上撐住 O(log n)。兩個都是攤還分析玩到極致的產物。 ]]></description>
    <pubDate>Tue, 11 Aug 2026 00:00:00 GMT</pubDate>
  </item><item>
    <title>關於</title>
    <link>https://terryyaowork.cc/about</link>
    <guid>https://terryyaowork.cc/about</guid>
    <description><![CDATA[ 這裡是什麼 這是我寫給自己的跨領域筆記本，公開放著。 技術、心理學、紫微、職涯、養貓——我把每個認真碰過的主題，寫到「能教別人」為止。對我，這是第二大腦：學到的東西有地方接住。對你，希望是一個新手也能上手的入口——難的東西，我盡量講到你聽得懂為止。 寫得雜是故意的。雜的地方，才是這個站跟別的技術部落格不一樣的地方。 我是誰 Terry Yao，12 年全端工程師、跨產業技術管理。日常在做的事，是把 AI 從「聽起來很厲害」變成「真的能用、還能維護」——Agent 架構、多模型串接、自動化工作流，導進實際的產品跟開發流程裡。 技術之外，我也寫紫微斗數、心理學、職涯這些。它們同樣需要「把複雜的東西... ]]></description>
    <pubDate>Sun, 09 Aug 2026 13:29:14 GMT</pubDate>
  </item><item>
    <title>許願池</title>
    <link>https://terryyaowork.cc/wishlist</link>
    <guid>https://terryyaowork.cc/wishlist</guid>
    <description><![CDATA[ 想看我寫什麼？ 這個站大部分是我自己想搞懂才寫的。但如果你有想學、卡住、想看我怎麼拆的主題——技術、AI、SEO、職涯、甚至紫微——在下面留一句。 我不保證每個都寫，但你說了，我就知道有人在等，那通常會被我排到前面。新手的問題我特別歡迎：你覺得「這太基礎、不好意思問」的，往往就是我最該寫清楚的。 留言不用註冊 GitHub，一般帳號（Google／訪客）就能留。丟一句，剩下的交給我。. ]]></description>
    <pubDate>Sun, 09 Aug 2026 13:29:14 GMT</pubDate>
  </item><item>
    <title>AI 天天在用、題庫幾乎不考的那些演算法</title>
    <link>https://terryyaowork.cc/common/foundations/algorithms/58-ai-era-algorithms</link>
    <guid>https://terryyaowork.cc/common/foundations/algorithms/58-ai-era-algorithms</guid>
    <description><![CDATA[ 「有沒有 AI 很看重、但演算法題庫很少出現的演算法？」有，而且是一整族。題庫集中在精確、離散、單機、最壞情況這一邊，AI 生產系統靠的是機率、近似、串流、相似度那一邊——這篇解釋落差怎麼來的，並列出完整清單和它們跟經典演算法的血緣。 ]]></description>
    <pubDate>Sat, 08 Aug 2026 00:00:00 GMT</pubDate>
  </item><item>
    <title>我自己寫的教材，我自己讀不下去</title>
    <link>https://terryyaowork.cc/thoughts/example-relatability</link>
    <guid>https://terryyaowork.cc/thoughts/example-relatability</guid>
    <description><![CDATA[ 我做了一套 Redis 學習 repo，範例技術上全對、每支都能跑，然後我在自己寫的第 17、19、25 支範例前面反覆卡住。卡住的根因不是機制難，是我給的資料沒有名字——這篇講「範例接近性」，以及我怎麼把 34 支範例全部改寫成同一間電商的故事。 ]]></description>
    <pubDate>Tue, 04 Aug 2026 00:00:00 GMT</pubDate>
  </item>
    </channel>
  </rss>