建立這個 blog 後不知多久，我在網站選單新增了「熱門文章排名」頁面。你目前看到的是新版。
收錄「一段時間內」瀏覽量排名前 10 名的文章，供讀者參考。順便增加全站頁面的總觸及率。
畢竟作為一個 blogger，誰不希望讀者在我們的 blog 看完一篇又一篇呢？
如何讓讀者願意「多看」，無疑是重要議題。
大部分部落格的大部分文章，都是靠特定 SEO 關鍵字，吸引到新讀者的第一次瀏覽。
在讀者還不認識你之前，眼下的這篇文章，就是他 / 她決定是否再瞧瞧其它文章的主要依據。
如果內容寫的有趣、論述風格對了胃口、相關的議題剛好是讀者現在關心的，就有機會獲得第二篇、第三篇瀏覽——這是作者們所期待的。
不過這些都是讀者的主觀因素！除了文章內容外，我們幾乎無法控制。
那我們可以做什麼？
這是 Django Tutorial 的第 6 篇、DRF 系列的第 2 篇。
範例程式碼可參考我的 GitHub 專案。
本文相關的程式碼改動，都集中在這個 PR。
上一篇我們介紹了 Django 和 Django REST framework（以下簡稱 DRF）之間的區別，與它們各司其職的角色定位。
兩者相輔相成，讓 Django 在這個「前後端分離」的時代，還能佔有一席之地。
接下來，我們要開始動手實作 API。
本文的目標：建立一個 Django API，並確保它正常運行。
為了達到這個目標，我們需要完成以下三件事：
settings.py，並加入 Django REST framework 相關內容。就這麼簡單，讓我們直接開始吧！
你寫作嗎？
我一直覺得，持續寫作真的很不容易！
所以我們需要一些方法或看法，來增加持續的可能性、降低其中的門檻。
在過去的文章中，我曾兩次討論「持續寫作」這個議題。本文將整理從上一次到現在，我的 3 個新想法。
前兩次討論，其實都只是某篇文章的一個段落，分別是：
它們代表了我不同時期的看法，不過都是一脈相承的，後者往往是對前者的追加、補充或是具體化。
本文也是如此，我會提出新想法，也會對過去的看法提出更加具體的建議。
純個人見解！但保證都是我的肺腑之言。讓我們開始。
上個月，我將工作上幾個專案的 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。
在〈使用 Black 格式化程式碼——《Python 功力提升的樂趣》〉中，我們提到了「data」這個不佳的變數名稱。
以及應該要用什麼樣的名稱取代它，與例外可以使用 data 的情況。
看過那段後，你可以發現，data 雖爛，但還是偶有派上用場的時候。雖然絕大部分的情況，我依舊會避免使用。
然而有一個變數名稱，我絕對不會用。
當我遵守了好習慣，盡可能避免在程式碼中使用 data 命名後，本以為能從此過上幸福快樂的生活，但我錯了！
因為沒多久後我就發現，還有一個比 data 更駭人聽聞的變數名稱——result。
和 data 相比，其糟糕的程度，簡直有過之而無不及。畢竟萬事萬物都有「result」，因果循環、生生不息，而且這個命名更加抽象，令人不禁想問：
到底是什麼結果？
result 命名的濫用，在「儲存呼叫函式的結果」時最為常見，難怪到處都是 result。