Posts

前言 / Introduction 為什麼需要 Docker Cache Mount？ 在 Docker 開發過程中，你是否遇到過這些困擾？ 重複下載依賴：每次 build 都要重新安裝相同的套件 漫長的等待時間：大型專案的 build 時間動輒 10-20 分鐘 網路資源浪費：重複下載相同的檔案 開發效率低下：頻繁的 build 測試嚴重影響開發節奏 Docker BuildKit Cache Mount 就是解決這些問題的終極方案！ 什麼是 Docker Cache Mount？ 核心概念 Cache Mount 是 Docker BuildKit 提供的高級功能，它允許你： 緩存依賴目錄：將套件、編譯結果等暫存起來 跨 Build 重用：下次 build 時直接使用緩存 大幅提升速度：減少重複下載和編譯時間 節省網路資源：避免重複傳輸相同檔案 工作原理 第一次 Build → 下載依賴 → 安裝套件 → 緩存到指定目錄 ↓ 第二次 Build → 檢查緩存 → 直接使用 → 跳過下載步驟 ↓ 結果：Build 時間從 15 分鐘縮短到 2 分鐘！ 基本語法與用法 語法格式 RUN --mount=type=cache,target=<緩存路徑> \ <你的安裝命令> 參數說明 參數 說明 範例 type=cache 指定緩存類型 --mount=type=cache target 緩存目標路徑 target=/root/.cache/pip id 緩存標識符 id=my-cache sharing 共享策略 sharing=locked 實戰範例：常見使用場景 1. Python pip 緩存 # 基本用法 RUN --mount=type=cache,target=/root/.cache/pip \ pip install -r requirements.txt # 進階用法：指定緩存 ID RUN --mount=type=cache,target=/root/.cache/pip,id=pip-cache \ pip install -r requirements.txt 效果：第二次 build 時，pip 會直接使用緩存的套件，跳過下載步驟。 ...

前言 / Introduction 在使用 uv container 開發 Python 專案時，可以透過一些技巧優化 build 時間與最終 image 的大小。 本篇將介紹三種常用方式：Intermediate Layers、Non-editable Installs、臨時使用 uv。 1. 利用 Intermediate Layers 提升 Build 速度 專案本身會頻繁變動，但依賴通常較穩定，可以將依賴安裝分離成獨立 Docker layer： FROM python:3.12-slim COPY --from=ghcr.io/astral-sh/uv:latest /uv /uvx /bin/ WORKDIR /app RUN --mount=type=cache,target=/root/.cache/uv \ --mount=type=bind,source=uv.lock,target=uv.lock \ --mount=type=bind,source=pyproject.toml,target=pyproject.toml \ uv sync --locked --no-install-project ADD . /app RUN --mount=type=cache,target=/root/.cache/uv \ uv sync --locked Note: --no-install-workspace：排除 workspace 成員 --no-install-package <name>：排除特定套件 pyproject.toml 必須複製進 image，以識別專案根目錄和名稱 2. 非編輯模式安裝（Non-editable Installs） 使用 –no-editable 可以只安裝虛擬環境，減少最終 image 大小： ...

前言 / Introduction 如果你也像我一樣，平時喜歡建構 Docker 的 container 並使用 uv 進行 Python 專案開發，那你一定不能錯過 uv 的官方 Image。 這篇文章將帶你了解如何快速上手，並示範一些實用的應用方式。 官方 Docker Image 官方提供了 uv 的 container 版本，你可以直接使用官方 Image 來快速建立開發環境： docker pull ghcr.io/astral-sh/uv:0.8.13 你也可以在 Dockerfile 中直接使用： FROM ghcr.io/astral-sh/uv:0.8.13 WORKDIR /app COPY . /app # 安裝依賴 RUN uv install # 啟動專案 CMD ["uv", "run"] 在 Container 中使用 uv 的好處 環境一致性：無論是在開發、測試還是生產環境，都可以保證專案運行一致。 快速部署：只需要拉取官方 Image，就可以立即開始開發，省去環境配置時間。 便於 CI/CD：在 CI/CD 流程中使用 uv container，可以統一 build、test、deploy 流程。 易於擴展：可以在 Docker Compose 中搭配其他服務，例如 PostgreSQL、Redis 等，輕鬆組建完整開發環境。 避免採坑：官方 container 已經幫你處理了 uv 的環境變數和依賴設定。 範例：快速啟動 Python 專案 建立專案資料夾並進入： mkdir my-uv-project cd my-uv-project 啟動 uv container： docker run -it --rm -v $(pwd):/app -w /app ghcr.io/astral-sh/uv:0.8.13 uv init 建立虛擬環境並安裝依賴： docker run -it --rm -v $(pwd):/app -w /app ghcr.io/astral-sh/uv:0.8.13 uv install 運行專案： docker run -it --rm -v $(pwd):/app -w /app ghcr.io/astral-sh/uv:0.8.13 uv run 這樣就可以在完全隔離的 container 環境中開發和測試你的 Python 專案。 ...

前言 / Introduction 為什麼需要 git worktree？ 在現代軟體開發中，我們經常面臨這樣的困境： 多個功能同時開發：主線功能、實驗性功能、緊急修復 AI 輔助開發：AI 生成的程式碼需要測試，但不想污染主分支 分支切換困擾：頻繁的 git checkout 容易忘記當前狀態 Stash 堆積：臨時程式碼越來越多，難以管理 Git Worktree 就是為了解決這些問題而生。它允許你在同一個 repository 中創建多個工作目錄，每個目錄對應不同的分支，讓你可以同時進行多個開發任務。 git worktree 核心概念 什麼是 Worktree？ git worktree 是 Git 2.5+ 引入的功能，它允許你： 在同一個 repository 中創建多個工作目錄 每個工作目錄可以切換到不同的分支 所有工作目錄共享同一個 .git 目錄 可以同時編輯、測試、提交不同分支的程式碼 與其他 Git 功能的比較 功能 用途 優點 缺點 Commit 永久記錄程式碼 版本追蹤完整 不適合半成品 Stash 臨時暫存變更 快速切換分支 容易堆積、遺忘 Branch 功能分支開發 版本控制完整 需要頻繁切換 Worktree 平行工作目錄 同時開發多分支 需要更多磁碟空間 實戰教學：從零開始使用 Worktree 1. 基本操作 創建新的 Worktree # 基本語法 git worktree add <path> <branch-name> # 實際範例：創建一個新的 Worktree 來開發 AI 功能 git worktree add ../myapp-ai-feature ai-feature # 如果分支不存在，使用 -b 參數創建 git worktree add -b experimental-feature ../myapp-experimental experimental-feature 查看所有 Worktree # 列出所有 Worktree git worktree list # 輸出範例： # /home/user/myapp main [main] # /home/user/myapp-ai-feature ai-feature [ai-feature] # /home/user/myapp-experimental experimental-feature [experimental-feature] 刪除 Worktree # 刪除 Worktree（會同時刪除對應的分支） git worktree remove ../myapp-ai-feature # 強制刪除（即使有未提交的變更） git worktree remove --force ../myapp-ai-feature # 只刪除 Worktree，保留分支 git worktree remove --keep-branch ../myapp-ai-feature 2. 進階用法 創建臨時 Worktree # 創建臨時 Worktree，用完自動清理 git worktree add --detach ../temp-Worktree HEAD # 或者指定特定 commit git worktree add --detach ../temp-Worktree abc1234 移動 Worktree # 移動 Worktree 到新位置 git worktree move ../myapp-ai-feature /new/path/ai-feature # 移動後記得更新 IDE 的專案路徑 AI 開發場景的最佳實踐 場景一：AI 程式碼實驗 當 AI 生成多個解決方案時，使用 Worktree 可以同時測試： ...

前言 / Introduction 工作上經常會寫一些自動化小工具，去解決日常的問題，開發過程不免俗與其他同事的專案有重疊的功能，因此會互相 Code Review，但此時常會覺得羞於見人，既沒有 Diagram 描述架構，文件描述又異常地空乏，總覺得少了點甚麼。 一開始我會覺得：「反正只是個小工具嘛」，但當聽到大神們聊起「模組設計 OOP」、「可維護性」、「容錯設計」等架構問題時，才意識到，我寫的不是工具，是妥協出來的程式碼。 初期的盲點：解決問題 ≠ 解決得好 對我來說，小工具只要「能跑」、「能交差」，就算完成。但這樣的 mindset 讓我忽略了幾件事： 沒人看得懂的 code，會變成團隊的負債 架構思慮不周，容易留下技術債 擴充性很低，重構等於打掉重練 沒有良好的錯誤處理、資源釋放、IO timeout 大神們思考的是「系統的運作」，而不是「功能的存在」 有一次 Code Review，學長只用兩句話，就打醒我： Function 過度耦合，缺乏可維護性和可擴展性 架設方式過於複雜，沒考慮使用者的背景 這時我才發現，System Design 不是只有在面試時才會遇到的 buzzword，它是真正在工作中，讓專案變得可靠、可維護的核心能力。 我為什麼決定開始學習 System Design 技術長大了，但腦袋沒長大：寫得出複雜的程式碼，但無法抽象出整體結構 專案開始有接觸多人合作：你不能只靠自己看懂，還要讓別人接得下去 我想寫出讓人放心的程式，而不是「現在能跑，之後爆炸的程式」 學習路線 我規劃一個 System Design Study Plan，希望能夠利用空閒的時間去補齊這些知識。 週次 主題 核心關鍵詞 重點問題 Week 1 Scalability & Load Balancer Vertical / Horizontal Scaling, Auto Scaling, Round Robin, IP Hash 如何應對高併發？如何分散負載？ Week 2 Cache 設計與策略 Read-Through, Write-Through, TTL, LRU, Redis 如何用 Cache 提高效能又保持一致性？ Week 3 Database 選型與 Sharding SQL vs NoSQL, Sharding, Replication, CAP 什麼情況選 MySQL？什麼情況拆 DB？ Week 4 Data Consistency & Message Queue Eventual Consistency, Kafka, RabbitMQ, Idempotency Key 系統怎麼確保資料一致？怎麼防重複？ Week 5 Rate Limiting & Circuit Breaker Token Bucket, Leaky Bucket, Retry, Backoff, Hystrix 如何保護系統不被濫用或雪崩？ Week 6 CDN & Global System Design Cloudflare, Geo DNS, Edge Cache 如何設計給全球用戶？如何用 CDN 加速？ Week 7 Monitoring & Reliability SLA, SLO, SLI, Prometheus, Grafana, Healthcheck 如何設計一個穩定且可觀察的系統？ Week 8 Design Real Systems & Interview Case Design YouTube, Messenger, TinyURL, LLM Infra 如何答出一個完整的系統設計題？ 結語 System Design 不只是為了寫出能跑的系統，而是為了寫出能活得久的系統。 ...