為了能讓 Weekly Review 系列的寫作盡可能持續——不要像以前的我，幾乎兩三下就半途而廢——我一邊寫也一邊在持續調整寫作的模式，也就是下文說的「畫框」。而畫自然是指文字本身。
在〈Hexo 部落格心得：一週年總結與持續寫作策略〉中，我提到了「發文的頻率與長度」這個萬年苦惱，並提出「短文發在臉書」這個暫時解決方案。
這方案確實讓我寫作的頻率明顯提高，今年 7、8 月之間，臉書發了 8 篇短文，且其中的幾篇（比如這篇），我自己也非常喜歡。
但它同時也有一個明顯的「副作用」——強化了我對臉書的關注與依賴，這是我不想要的部分。
所以，一段時間後，我不禁再次思考：要怎麼做才能在「保持」提升發文頻率的同時，又不那麼依賴臉書？
Weekly Review 系列就是我思考後的答案，而它也帶來了一些意料之外的正向效果，比如接下來要講的。
替代方案——Ruff：Python 開發：Ruff Linter、Formatter 介紹 + 設定教學
Python linter、formatter 整合 VS Code 的文章，已經寫過好幾篇，但還是不厭其煩地繼續寫，原因很簡單——它們實在太基本也太重要，卻往往未受到足夠的重視。
永遠不要小看這些排版上的細節對程式寫作習慣的影響。
如同我在〈Python isort 擴充套件介紹與簡易設定教學〉文末所言：
對於重視程式寫作規範，意在貫徹 Clean Code 精神的開發者而言，它不是一種選擇，而是一種必然。
以及〈VS Code 設定 Python Linter、Formatter 教學〉中說的：
Linter 和 formatter 雖然無法保證你寫出 Clean Code，但至少能協助你盡可能符合 PEP 8 風格，並省下處理排版細節上的心力，讓你更專注在程式的核心部分。
儘管「善用 linter、formatter」和「寫出 Clean Code」之間，還相隔著不知多少努力與反省，但後者必定是建立在前者之上——我對此深信不疑。
所以我不曾去質疑這些工具的必要性，因為它們就像陽光、空氣、水一般，不可或缺，只要我還寫程式的一天，就只會立足於它們之上。
廢話不多說，我們進入正題。
2024/01/30：修訂部分內容並新增「目標讀者」一節。
在〈Notion + VS Code：我的 Markdown 寫作工作流〉一文中，介紹過 Notion 的文字編輯器、鍵盤快捷鍵，以及它對 Markdown 文本格式的高度支援。
事實上，如果你已使用 Notion 一段時間，應該就不會以它自帶的「簡易編輯器」作為筆記排版的主要手段——因為和直接使用 Markdown 符號或鍵盤快捷鍵相比，編輯器顯然沒那麼方便、好用。
不得不承認，從接觸 Notion 開始，我對編輯方式的偏好，也從以前 Evernote 時期的「編輯器導向」，慢慢轉變成了現在的「Markdown 符號 + 快捷鍵導向」。
可以說，現代筆記軟體，幾乎都「更希望」你透過快捷鍵來操作。因此，我們能看到：附帶的編輯器不是愈做愈陽春，就是在預設上，乾脆隱藏起來。
本文主要面向 Notion 或 Markdown 的初學者，介紹我在操作 Notion 時，最常使用的 Markdown 元素（加上一點 Notion 特有元素），與「快速建立」這些元素的方式。
有時用 Markdown 符號，有時則用 Notion 快捷鍵，偶爾需要透過 Notion 指令。端視哪一種方式讓我感覺更加流暢、自然。
這些內容，雖然是基本中的基本，但在我看來，只要熟悉並善用它們，你就已經學完 Notion 的一半了——另一半是簡單用好 Notion 的資料庫。
相關文章：Notion 資料庫「反複雜」使用指南
今年 8 月下旬開始使用 Logseq，一開始的動機，就只是為了背單字，且看中了它的快閃卡片（flash card）功能。
結果 3 個月過去，筆記軟體是用順手了，但學英文、背單字的事，已完全拋諸腦後。
這星期重新思考了這個議題，試著找出發展不如預期的主要原因。經過一番歸納，發現 3 個主要問題，在此寫下來，作為方向調整的參考。
系列的第一篇，我花費了非常大的篇幅論證：為何不建議以「All-in-One」方式來使用 Notion——因為成本太過高昂，且很可能難以持續。
本文將沿著這個核心思路，繼續展開，進一步介紹：無論是以何種方式使用 Notion，你都很可能踏入的兩個「陷阱」，與我的對策。
替代方案——Ruff：Python 開發：Ruff Linter、Formatter 介紹 + 設定教學
最近發現，VS Code Python 擴充套件附帶的 isort 功能失效了！打開settings.json查看相關設定：
1 | "python.sortImports.args": [ |
VS Code 會提示這樣的訊息：
This setting will be removed soon. Use
isort.argsinstead.
果然該來的還是要來，在〈試用從 Python extension 拆分的 Black、isort 套件〉中提過，微軟一直在積極拆分 Python 擴充套件功能，試圖為其「減肥」與解耦。
而 linter 和 formatter 正是拆分的一大重心所在，前者目前已有 Pylint 和 Flake8，後者則有 Black，都是微軟官方出品。（yapf 表示：因為我來自 Google 就差別待遇？）
再參考 iThome 這篇〈VS Code Python擴充套件現在會預設安裝匯入項目排序擴充套件isort〉，顯然 VS Code 官方認為，isort 的正式獨立時機已到。