上個月中，我在寫部落格時，突然發現圖片上傳失敗，無論怎麼嘗試都無法成功。
我的寫作流程是用 VS Code 的 Markdown Image 外掛，透過鍵盤快捷鍵，直接把圖片傳到 Imgur 上，這個流程已經持續了好幾年，非常方便、順手。
但這次踢到鐵板了。
認真查了一下，才發現原來是 Imgur 大概從 5 月 16 日開始，無預警地封鎖了來自台灣的 IP，不再允許台灣使用者上傳圖片。（所幸已上傳的圖片還是可以看）
PTT 上也有討論。
可以想見，這是多麼大的衝擊！
官方既然沒有給出任何理由，這個舉動（封鎖 IP）又顯然是蓄意的，那我們可以合理推測——短期內恐怕不會恢復正常了。
但我的部落格還是要繼續寫啊！只能乖乖尋找替代方案。
如〈Python 套件管理器 uv 介紹——與 Poetry 比較〉一文中所述，最近我開始了一個新的 side project。
我打算好好利用這個專案，練習並實踐那些，在工作中無法盡情揮灑，或想學習但是還用不到的新技術。包括後端、AI、DevOps。
為了嘗試不同的開發體驗，從框架到工具都有所更新：
而型別檢查器——本文的主角，則從 Mypy 改為 Pyright。
這不是一時興起的炫技選擇，而是一連串有意識的技術決策：選擇那些效能更好、體驗更佳，並且有長期潛力的替代方案。
Pyright，就是其中之一。
如果你對 Python 的「型別檢查」議題還不熟，歡迎參考我之前寫的「Mypy 三部曲」，其中對 Python type hints 與型別靜態分析工具做了深入說明。
Type hints 歷經多代 Python 發展至今，已趨於成熟。但它在實際專案中的流行程度，恐怕還不算高。
甚至直白地說，對部分 Python 開發者而言，可能：
這正是本文要努力的目標——讓更多人加入撰寫 Python type hints 的行列🔥😎
幾天前，我收到了一封來自 Pocket 的電子郵件，開頭是：
感謝您的閱讀：Pocket 向您道別
我們有一些重要訊息要和您分享：幾經思考之後，我們做出了一個艱難的決定，我們的先存再看和內容探索應用程式 Pocket 即將結束服務。
如你所知，知名的「稍後閱讀」服務 Pocket 已經被 Mozilla 正式宣布將於 2025 年 7 月 8 日停止服務。
對許多知識工作者來說，這是個令人感慨的時刻，Pocket 的結束讓我們再度體認到：我們存下來的東西真的大多都沒有看。
不過，資訊囤積還是要繼續😎，所以本文會介紹兩個，我覺得還不錯的替代品，並說明我的選擇與理由。
「Read It Later」（稍後閱讀）是一種資訊整理的方式，也是一種使用習慣。
它允許你在沒心情或沒時間的情況下，把重要但無法即時處理的內容先存起來，日後再回來閱讀。
對知識工作者或資訊成癮者來說，這類服務是不可或缺的夥伴。
從食譜、文章到影片，這些被儲存下來的內容，構成了每個人專屬的知識倉庫。
2025/06/04: 更新「1000 次請求的最佳場景」落段。並感謝〈愛好 AI Engineer 電子報 🚀 模型上下文協定 MCP 應用開發 #27〉的推薦，本期的含金量極高，除了 MCP 最新進展，還討論 AI 應用開發的一些「哲學」（ex：框架是必要的嗎？）議題。推薦必讀！
在這個 AI 應用百花齊放的時代，我們可以透過各種方式來接觸 AI。
可以使用線上服務——比如 ChatGPT，也可以直接使用 LLM API 來更加客製化自己的需求。
最近我開始使用 OpenRouter 這個平台上的 API 服務，對於 AI 開發人員或 LLM 重度用戶，想必不陌生。
本文介紹 OpenRouter 上的 5 個免費模型，幫助你快速上手並選擇合適的模型。
OpenRouter 是一個語言模型的 API 聚合平台服務，讓使用者可以透過單一介面，就能夠付費存取多家公司的大語言模型，包括 OpenAI、Anthropic、Google 等大公司的 LLM API 產品。
而且像 LLaMa、DeepSeek 這類開源模型，你想要使用的話，除了在本地跑之外，也可以透過 OpenRouter 提供的 API 來使用。
好處就是你不用擁有機器、顯卡，就能體驗這些開源模型的能力，而且價格相對於閉源模型，通常有一定的競爭力。
總之，OpenRouter 不僅為開發者提供了統一的介面，更讓非技術出身的用戶也能輕鬆使用 AI。
最近都在為〈Python 套件管理器——Poetry 完全入門指南〉一文進行「減肥」，讓它更容易閱讀、回顧。
除此之外，是時候為「Python Poetry」這個系列畫下句點了——而本文就是最後一塊拼圖！
我曾在前文中提到，為什麼不在 Docker 容器中使用 Poetry。主要原因是：
啟動容器後需要先安裝 Poetry 到全域，或打包一個帶有 Poetry 的 image，兩者都會增加新的耦合與依賴，需要更細緻的管理。
但這樣的限制，其實可以透過 Docker 的 multi-stage build 解決。
本文將從實務角度出發，介紹如何使用 multi-stage build，在 Docker 中整合 Poetry。
讓你既能享有 Poetry 的套件管理優勢，又不會對部署流程增加額外負擔。
- Python 套件管理器——Poetry 完全入門指南
- Poetry + pyenv 教學：常用指令與注意事項
- Docker 教學：用 Multi-stage build 建立 Poetry 虛擬環境
我們開始吧！
3 年前，我寫了這篇〈Python 套件管理器——Poetry 完全入門指南〉，它成為了本站最受歡迎的文章之一。
隨著 Python 開發生態的發展，新的工具不斷湧現，你可能已經聽過，我們今天要介紹的主角——Astral 的 uv。
之前有讀者希望我介紹 uv，但因為沒有急迫需求，所以一直拖到最近才開始嘗試。
這幾天，我終於在 side project 中開始使用它，因此有了初步的心得。
這篇文章將先介紹 uv 的背景、特點，以及和 Poetry 的比較（這是我最在乎的，也是所有習慣 Poetry 的讀者可能感興趣的），幫助你評估是否要轉向這個新工具。
至於教學，我會在下一篇文章中分享 uv 的實際使用方式，包括安裝、專案初始化、依賴管理等操作，協助你快速上手。
在〈Docstring 的重要性——《Python 功力提升的樂趣》〉一文中，我提到了：
Docstring 也不是有寫就行，還需要從「讀者（也就是你的同事）」的角度去思考與表達。不然看起來會很像開發者的自言自語——沒人看得懂。
在工作上使用 Python 多年，即便是經驗豐富的 Python 工程師，很多人也未必養成了撰寫 Docstring 的習慣。
畢竟在日常趕專案的場景下，一段程式碼能否 work，往往比「好讀、好理解」更重要——至少更急迫。
然而，當專案逐漸擴大、團隊成員增加時，沒有良好的 Docstring，協作上的痛苦就會慢慢浮現。
Docstring 不是單純寫給自己的備忘，而是寫給「下一個會看這份程式的人」。
當你開始用這個角度思考，你會發現，寫好 Docstring 並不是加分項，而是基本功。
那要怎樣才能寫好 Python Docstring 呢？
作為 Docstring 信奉者，本文將分享我在過去工作經驗中所累積的 Python Docstring 寫作心得，並整理成教學指南。