2024/04/26：重新潤飾全文，調整部分字句。

在〈使用 Notion 滿 3 年，為何我仍「不推薦」用它來管理你的人生？〉一文與其所屬的「Simple Notion 系列」中，我已用不少幅篇，明確表達我對這類「大而全」生產力系統的隱憂與質疑。

在其它文章中，也有過類似討論：

• 《人生 4 千個禮拜》筆記（一）病態的生產力
• 11，我絕不當資訊的聚合者

本文將進行一次「總結式」的整理，重新闡述不用這類系統的三大理由。並提出我認為相對可行的替代方案：局部實現。

本文目錄

1. 本文主旨與目標讀者
2. 所謂的「人生管理系統」
3. 大系統的兩個特徵
4. 為什麼不要這麼用
5. 3 個「不」的理由
6. 一、成本過高：神兵利器的代價
7. 二、適得其反：做了更多瑣事
8. 三、系統會觸發你「追求完整」的本能
9. 完整的悖論
10. 舉例：Notion 閱讀管理
11. 不必要的欄位
12. 再論生產力達人
13. 更適合一般人的做法：局部實現
14. 用「局部實現」取代人生管理系統
15. 結語：接受殘缺與遺憾

---

本文主旨與目標讀者

本文想表達一個核心看法：

打造大而全的「人生管理系統」，期望它全面提升你的生產力，可能不是一個好主意。

我知道，在這個資訊爆炸、快速變遷的時代，追求生產力幾乎可說是一種「顯學」。

這類系統也許為「少部分人」帶來了可觀的成就、自我掌控感，甚至是安全感。

因此他們能夠信誓旦旦地告訴你：「相信我！這是一個超棒的方法，而且你也能夠！」

老實說，連我自己都很難完全抗拒「高效、生產力」這類的主題，我想這是所有懷抱著自我期許之人的本能吧！

所以我並不打算阻止你去追求、建立屬於自己的生產力方法論。本文想要提醒的是——這些方法最好不要是「大而全」的那種，而是要能夠做到「取捨」。

不過，人生之難，就難在取捨。

前陣子，我得知了「Not By AI」這個徽章的存在。

它提倡為你的創作（以下都指文章）加上這個標籤，聲明是由人類所寫。

我們先看一下這個徽章的創立使命（中文為 Google 翻譯）：

使命
「Not By AI」徽章的創建是為了鼓勵更多的人製作原創內容並幫助用戶識別人類生成的內容。最終目標是確保人類繼續進步。
　
專家估計，到 2025 年，90% 的線上內容將由人工智慧產生。隨著人工智慧產生內容的激增，值得注意的是人工智慧是根據人類生成的內容進行訓練的。如果人類僅僅依靠人工智慧來產生前進的內容，那麼人工智慧產生的任何新內容都可能只是過去的內容的回收。這可能對人類進步構成重大障礙。只有限制對人工智慧的依賴並繼續創造原創內容才能推動我們作為一個物種向前發展。

我乍一看覺得有點心動，而且作為一個長期創作的部落格作者，像「Not By AI」這種「自我主張型」的標籤，僅是在本能情感上，就有股莫名的吸引力。

但同時又覺得，好像哪裡怪怪的。

2024/04/18：重新編輯全文，提高可讀性。

這是 Django Tutorial 系列連載的第 2 篇。

搭配學習的範例程式碼，可參考 GitHub 專案：Django-Tutorial。更多 Django 教學，請見「Django 文章總覽」。

系列：Django ORM 外鍵教學

1. Django ORM：一對一、一對多外鍵教學（上）前言與關聯設定
2. Django ORM：一對一、一對多外鍵教學（中）反向關聯

---

前言

上一篇我們介紹完 Django ORM 的關聯設定，接下來本應該要進入查詢部分。不過，由於「反向關聯」在 ORM 查詢中扮演著十分重要的角色。

所以我決定專門寫這個（中）篇，好好介紹 Django ORM 中的「反向關聯」。

這是《人生 4 千個禮拜》筆記的第 1 篇，你可以把它當作是一則重點整理，加上大量我個人的經驗與想法。

我認為，如果你不是書中描寫的這類人——在某些方面、某種程度上對追求生產力有過一定追求的人。那看本書很可能只覺得它像是一連串的高級雞湯文。

比如「接受人生有限」這樣的話，你可能早就聽過無數次，甚至已經麻木了。

然而，作者在書中把這類人在「生產力追求路上」所伴隨的種種「荒謬」與「弔詭」之處，精準地勾勒出來，令人拍案叫絕。

或許你不是這樣的人，沒關係，因為我（某種程度）是。

所以我會試著把這樣的努力與隨之而來的困境，盡可能展現出來，好比是種自嘲。就像〈使用 Notion 滿 3 年，為何我仍「不推薦」用它來管理你的人生？〉中的我。

2024/05/10：重新編輯全文，新增、刪除部分內容，補充更多設定實例。調整大量段落表述方式，提升文章流暢度。可視為 v1.5 版。

Ruff 從去年（2022）6 月正式開源起算，已過去一年半，知道此工具的開發者也愈來愈多。雖然在去年就聽過它，但我卻一直沒有任何行動。

隨著前陣子 v0.1.0 的發布（先別覺得這版本號怎麼乍看像早期測試版本🤣，前一版可是 v0.0.292），我感覺時機已到，所以進行了一番研究、嘗試，並寫下了本文。

本文目錄

1. 緣起
2. 本文主旨與目標讀者
3. Why Ruff？
4. 本文範例程式碼
5. Ruff 介紹篇
6. Linter 部分：取代 Flake8 與 isort 等等
7. Formatter 部分：取代 Black
8. 單、雙引號議題
9. Ruff 設定篇
10. pyproject.toml 設定
11. Ruff VS Code 套件設定
12. pre-commit 設定
13. Ruff 設定篇小結
14. 工作上我還未採用 Ruff 的理由
15. 結語：Time to Ruff

你現在看網站的選單，已經沒有「發文計畫」了。

至於那是什麼，可以參考上一期〈23，Blog 新增「發文計畫」與我的思路〉。

這篇就來解釋，為什麼它失敗了，與我的一點想法。

2024/05/05：重新編輯全文並刪除部分內容，使文章更緊湊。

這是《Python 功力提升的樂趣：寫出乾淨程式碼的最佳實務》閱讀筆記的第 3 篇，你可以把它當作是一則重點整理，加上我個人的開發經驗與心得。

本文整理書中的第 10、11 章，且篇幅幾乎集中在前者。無論什麼語言，「寫好函式」這件事總是如此重要，Python 自然也不例外。

系列：Python 功力提升的樂趣

1. 《Python 功力提升的樂趣》筆記（一）Black、命名、壞味道
2. 《Python 功力提升的樂趣》筆記（二）Pythonic、行話、陷阱
3. 《Python 功力提升的樂趣》筆記（三）函式、註解、docstring

---

第 10 章：寫出有效率的函式

有效率的函式（或說「好的」函式）需要你在「命名、規模大小（行數）、參數數量和複雜性」之間，做出許多決定和取捨。

本章探討的正是這些取捨之間的利弊得失，以及編寫函式的重要原則。

不用說，這是關鍵的一章。