主打 AI 輔助寫程式的編輯器——Cursor，這陣子非常火紅。

剛好我在上星期經朋友推薦，認真試用了一下，還接了 OpenAI GPT-4o mini API 作為編輯器的 AI 助手。

本文會分享我試用 Cursor 的心得，以及我仍不打算從 VS Code 遷移至 Cursor 的三個理由。

雖然是從個人角度出發，但我會考慮不同狀況、不同需求的讀者，給出不同的建議。

---

Cursor Editor 簡介

Cursor 是一款主打 AI 輔助寫程式的新型態 IDE，它並非單純在既有編輯器加上外掛，而是將 AI 深度整合進編輯器中。

它直接使用了 VS Code 的開源程式碼來建構。

這意味著，Cursor 在介面與操作邏輯上都與 VS Code 極為相似，對於那些想要從 VS Code 遷移過來的使用者來說，幾乎不需要花費額外的時間適應，就能快速上手。

它的最大亮點，是內建了強大的 AI 功能（名為：Copilot++），可以根據你的指令，自動生成程式碼、提供程式碼建議，甚至幫你 debug。

不過這些其實 GitHub Copilot 也能做到。所以，我認為，真正讓 Cursor 脫穎而出的，是以下三點。

相關文章：

• 2024 iThome 鐵人賽參賽思路：主題選擇、命名與標題策略
• iThome 鐵人賽寫作攻略——新手必看指南

轉眼間就八月了！我的天，時間過得真快。

渡過了相對低迷的七月，這個月我要好好備戰鐵人賽——不然也沒有時間了XD

本期講一下我對於鐵人賽的看法、準備（雖然才剛開始），與個人期待。

---

iThome 鐵人賽

2024 iThome 鐵人賽的官方頁面已經上線，報名時間從八月到九月中。

今年新增了 Python 組和 JavaScript 組，這是個好消息，作為一個 Python 開發者，能在 Python 組參賽是最好。

尤其這是我第一次參加 iThome 鐵人賽，別具意義。

早在〈32，下半年寫作目標〉中，我就宣布要參加鐵人賽，結果一個月過去，現在才開始動工😂

那時收到了一位，我覺得很厲害的開發者的來信，表示對鐵人賽如果有什麼疑問，可以協助，我當下真的是又驚又喜！

不過隨著七月一整個月的低迷（包括前半月的生病），這份驚喜逐漸轉變為一種淡淡的罪惡感：「可惡，我怎麼還沒開始！這樣豈不是浪費了別人的好意？」

七月上旬不慎感冒，不知為何，這回特別嚴重。足足過了近兩星期，才逐漸恢復正常。

而且，整個七月至今，狀態都不太好。不僅是身體，心情也低落，有一種找不到出口的感覺。

這樣的心情間接影響了我的寫作士氣，讓我感到心有餘而力不足。

這星期四、五，和女友去了宜蘭，雖然是一次的短暫旅行，但至少能夠打破既有的生活節奏，讓自己放鬆一下。

宜蘭我還算熟悉，畢竟曾在宜蘭工作了 5 年多，想起這段過往，覺得人生真的有很多變化。

本期結合旅記和近況回顧，篇幅會比以往略長。

這是《Python 工匠｜案例、技巧與開發實戰》筆記的第 3 篇，你可以把它當作是一則重點整理，加上我個人的開發經驗與心得。

如第一篇所言，這是一本關於「Clean Code in Python」的書。

上一篇我整理書中了第 13 章「有關單元測試的建議」的內容（以及我的看法）。這次我們要再回到一開始，繼續學習如何寫好程式碼。

本文整理自書中的第 1 章第 3 節，為了不過度重複書中內容，下筆點到為止，並加上我自己的理解。

系列：Python 工匠

1. 如何寫好 Python 註解——《Python 工匠》
2. 為什麼你應該寫單元測試——《Python 工匠》
3. 精通「變數」的宣告與使用——《Python 工匠》

這是「Python 入門三部曲」的最後一篇！歷時 2 年，終於要為這個系列劃下句點。

在此之前，我已寫下 3 篇關於《Python 功力提升的樂趣》的筆記與心得。本文建立在它們之上，但會從更高的俯視角度來介紹與推薦這本書。

從全書的輪廓與定位切入，讓初學者更容易掌握觀念，不至於迷失在細節中。對於已有經驗的 Python 開發者，則可以藉由一篇篇的筆記，直接找到自己感興趣的章節。

所以，本文不會在內容上重複前文，或在細節上多加著墨，而是更多的回顧與比較。

這是為什麼我要先寫筆記，最後再完成這篇閱讀心得的原因。

當然，不是每一本書都值得你如此對待。畢竟其中要投入時間精力甚多，這是我第一次——可能也是最後一次，這麼詳細地介紹一本書。

但這本書，我認為值得。

系列：Python 入門三部曲

1. 《精通 Python 第二版》心得：給入門者的 Python 學習藍圖
2. 最佳 Python 入門書——《Python 技術者們 - 練功！》心得與導讀
3. 《Python 功力提升的樂趣》心得總結：掌握 Clean Code 基本功

系列：Python 功力提升的樂趣

1. 使用 Black 格式化程式碼——《Python 功力提升的樂趣》
2. 如何寫出 Pythonic 程式碼——《Python 功力提升的樂趣》
3. Docstring 的重要性——《Python 功力提升的樂趣》
4. 《Python 功力提升的樂趣》心得總結：掌握 Clean Code 基本功

你聽過 Tony Huang 嗎？

20 年前他就已經開始寫登山健行 blog，最近 5 年改為拍攝 YouTube 影片，成為旅遊 YouTuber。

他的作品特色是，在旅行中融入人文、歷史、文學等元素，讓觀眾不只是看風景，更能了解台灣這塊土地的過去。

我無須介紹太多，而是要聊聊，最近看了許多他的影片的一些感想。

這是 Django Tutorial 的第 9 篇、DRF 系列的第 3 篇。

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

本文相關的程式碼改動，都集中在這個 PR。

---

Views 是 Django 中處理 HTTP 請求的核心邏輯。它的作用是接收請求、處理請求，最後返回 response：

A view function, or view for short, is a Python function that takes a web request and returns a web response.

在 Django 中，我們可以使用兩種方式來撰寫 views：

1. Function-Based Views（FBV），其實就是一個 Python 函式，也是 Django 預設的 view 寫法，所以又稱 view 函式。
2. Class-Based Views（CBV）。CBV 是 Django 1.3 版本引入的，它是基於類別的 view 寫法。

CBV 與 FBV

「CBV vs. FBV」是初學 Django 一個常見的議題。如系列的第一篇所言：

CBV 有著重用程式碼優勢，適合大型專案。而 FBV 則以簡單、直接為賣點，方便快速開發中小型專案。

究竟要選哪個，取決於個人喜好與專案需求。

Django REST framework（以下簡稱 DRF）同時支援這兩種 views。

事實上，DRF 顯然更加鼓勵使用 CBV，不僅提供了許多現成的 generic views，它的很多元件也是基於 CBV 設計的。

不過，本文只打算介紹 DRF 中的 FBV，並實作一個 DRF view function。