Tutorial

前言 / Introduction 最近在註冊某個服務時，我的 email 地址竟然被別人註冊走，導致驗證信收不到。 但聯絡客服申訴又過於麻煩，搶回來的機會又很渺茫，與其這樣，不如自己建立一個「可以正常收信」的網域信箱。 於是我用 Cloudflare Email Routing 搭配現有的 Gmail／iOS Mail 完成這件事，以下是我實際操作的流程與心得。 Why using Cloudflare Email Routing 與其再去註冊一個新信箱，不如直接用自己的網域收信，再轉寄到現有的 Gmail 或 iOS Mail。 Cloudflare 的 Email Routing 是免費的、無需自架 Mail Server，也完全不會改變日常的收信方式。 How to Do It Add or Select Your Domain If your domain is already on Cloudflare, just open it. Otherwise, add a new one Enable Email Routing 進入後該網域，在左側的功能列表選「Email」→ 啟用 Email Routing。 Create a Custom Email Address Custom address: [email protected] Action: 選擇 “Send to email” Destination: 輸入你要接收的信箱（Gmail / iCloud / Outlook 都可以） Verify and Apply DNS Records ...

前言 / Introduction 隨著 Python 3.14 的正式發布，多線程開發的限制，也隨著下面的改動迎刃而解: Free-threaded mode (PEP 703), Isolated interpreters (PEP 684), And the new InterpreterPoolExecutor (PEP 734), Python can now run true parallel CPU-bound code directly — even within the same process. 下面將展示一些 Example Async I/O CPU-bound parallelism Multicore execution with interpreter pools 1. Classic Problem: Async + CPU Work 如果你遇到需要 You fetch data from multiple APIs (I/O-bound) Then process, analyze, or compress the data (CPU-bound) 在 Python 3.14 之前 ...

前言 / Introduction 在 Python 專案的開發過程，或多或少會碰到需要平行運行的時候，而大多的資料只說使用 asyncio 就可以加速，但實際上執行時，卻還是一樣的緩慢甚至更糟，那或許你也踩到了錯誤使用線程的坑。 在這篇文章，將討論下面幾點: Why I/O-bound and CPU-bound tasks behave differently The right way to use asyncio Why requests.get() blocks async functions- This sets the foundation for understanding Python 3.13 and 3.14 improvements later in the series. I/O-Bound vs CPU-Bound: The Real Difference 在討論 asyncio or threads 之前，我們需要先搞清楚甚麼樣的任務類型是你面對的 Type What slows it down? Best approach I/O-bound Waiting on network, files, DB, API asyncio, threads CPU-bound Calculations, parsing, encoding multiprocessing, free-threading If your app is fetching APIs, reading files, or handling sockets → it’s I/O-bound. If it’s crunching data or doing math → it’s CPU-bound. 本篇文章為了更清楚描述，接下來會專注在 I/O-bound 的討論。 ...

前言 / 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 When you’re working with Docker for development or deployment, environment variables are essential. But let’s be real — it’s easy to get confused. Does .env work for both build and run? Why doesn’t my variable show up in the container? Where should I put secrets? This post is a personal cheat sheet of the 4 main ways I manage env vars in Docker. Hopefully, it’ll help you too 🙌 ...