你寫作嗎？

我一直覺得，持續寫作真的很不容易！

所以我們需要一些方法或看法，來增加持續的可能性、降低其中的門檻。

如何持續寫作

在過去的文章中，我曾兩次討論「持續寫作」這個議題。本文將整理從上一次到現在，我的 3 個新想法。

回顧 Part 1、Part 2

前兩次討論，其實都只是某篇文章的一個段落，分別是：

1. 小結：如何盡可能持續寫？（2021 年）
2. 如何持續寫作 Part 2（2022 年）

它們代表了我不同時期的看法，不過都是一脈相承的，後者往往是對前者的追加、補充或是具體化。

本文也是如此，我會提出新想法，也會對過去的看法提出更加具體的建議。

純個人見解！但保證都是我的肺腑之言。讓我們開始。

上個月，我將工作上幾個專案的 Python linter、formatter，從原本的 Flake8、isort、Black Formatter 遷移至 Ruff。

本來以為很簡單，應該半小時就可以搞定。不料細節比想像中的多，前前後後還是花了近 2 小時。

可能我比較龜毛吧！

正因耗費的時間有點多，所以寫下這篇懶人包教學，作為讀者遷移時的參考。

本文主旨與目標讀者

這篇文章是寫給，目前正使用上述 Flake8、isort、Black Formatter 作為格式化工具，並打算遷移至 Ruff 的 Python 開發者。

受眾就是〈VS Code 設定 Python Linter、Formatter 教學〉中描述的那樣。在專案中使用上述工具，也安裝了相關的 VS Code 套件，設定好 pre-commit hook，以及使用 pyproject.toml 作為這些工具的設定檔。

而本文的目標，就是讓專案的 linter、formatter，最終都統一使用 Ruff。

相關文章：AI 讓寫作變輕鬆了？我可不這麼認為

你會把「和 ChatGPT 的對話、問答」寫成筆記嗎？顯然我會，而且很大量！

其中有 8 成以上都是程式相關，來自每天和 ChatGPT 的日常開發問答。

應該說，與 ChatGPT 對話早已成為我工作、學習的重要環節。在〈別依賴「試誤法」寫程式〉中我也強調過，像 ChatGPT 這樣的工具，如果僅僅用來「獲得答案」，未免也太可惜。

因此，我幾乎每天都會有新的「AI 對話筆記」。

話說回來，把 AI 的回答寫成筆記，並作為主要的知識來源，這是一個好的實踐嗎？

本文無法回答這個問題XD，但我可以分享一下，做了一年 AI 對話筆記後，我的看法與注意事項。

這是 Django Tutorial 的第 5 篇。

範例程式碼可參考我的 GitHub 專案。

終於要進入 Django API 的世界了！

不過，在開始 DRF 教學之前，我要先介紹 Django、DRF 兩者間的關係。

為什麼 Django 不乾脆自己實作 API 功能就好？而是把這個任務交給第三方套件，比如本文的 Django REST framework。

本文主旨

因此，本文的主要目標是：為讀者建立一個「high level」的世界觀。讓你了解為何在 Django 之外，我們還需要 Django REST framework。

了解兩者的關係，更能體會它們所扮演的不同角色。

簡言之，這一篇還沒有要開始寫 API。

系列：Django REST framework 教學

• 系列文章清單（連載中）

在〈使用 Black 格式化程式碼——《Python 功力提升的樂趣》〉中，我們提到了「data」這個不佳的變數名稱。

以及應該要用什麼樣的名稱取代它，與例外可以使用 data 的情況。

看過那段後，你可以發現，data 雖爛，但還是偶有派上用場的時候。雖然絕大部分的情況，我依舊會避免使用。

然而有一個變數名稱，我絕對不會用。

比 data 更糟的變數名稱——result

當我遵守了好習慣，盡可能避免在程式碼中使用 data 命名後，本以為能從此過上幸福快樂的生活，但我錯了！

因為沒多久後我就發現，還有一個比 data 更駭人聽聞的變數名稱——result。

和 data 相比，其糟糕的程度，簡直有過之而無不及。畢竟萬事萬物都有「result」，因果循環、生生不息，而且這個命名更加抽象，令人不禁想問：

到底是什麼結果？

result 命名的濫用，在「儲存呼叫函式的結果」時最為常見，難怪到處都是 result。

作為一個 blog 創作者，我算是比較常編輯、翻修舊文的人。

編輯舊文往往需要花費不少時間，而且讀者也未必看得出有哪裡不同——所以我一定會在文章開頭備註、提醒☺️

部分文章，編輯過不止一次，比如〈Python 套件管理器——Poetry 完全入門指南〉，我將它視為代表作之一，編輯的次數應該是全站之最。

這樣的行為，雖然源於對文字與表達的追求，但其中也有實際的理由。

這篇來就分享一下，我考慮編輯舊文的三個實際理由。

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

範例程式碼可參考我的 GitHub 專案。

如〈Django Tutorial：系列介紹與導讀〉所言，這個系列主要是圍繞著「Django API」教學展開的。

但無論是用 Django 建立全端網站，還是開發 API，Django 的 HttpRequest——也就是我們熟悉的request參數——都是必不可少的元素。

HttpRequest封裝了來自前端的 HTTP 請求，而 Django 會將HttpRequest物件自動帶入 view 函式的第一位置參數（通常就叫request），讓我們可以直接使用。

為何需要了解 HttpRequest 物件

在我剛開始寫 Django 的時候，根本不太清楚HttpRequest具體有哪些屬性。

通常是看教學或為了實作某個功能而 Google 的時候，看到範例程式碼使用某個屬性，然後才知道這個屬性的存在。比如：

1
2
3
4

if request.method == "GET":
    do_something()
elif request.method == "POST":
    do_something_else()

看到這段，才知道request有一個method屬性。

這樣學當然可以，但如果一開始就對常用的HttpRequest屬性有基本了解，會讓你在學習 Django 的路上更加踏實。