我寫「AI 對話筆記」的方法與思考

by Sam Chivers

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

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

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

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

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

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

Django REST framework 教學(一)前言篇

Let's Django!

這是 Django Tutorial 的第 4 篇。

範例程式碼可參考我的 GitHub 專案,更多教學請見「Django 文章總覽」。


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

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

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

本文主旨

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

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

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

系列:Django REST framework 教學

我絕不用 result 作為變數名稱

by Sam Chivers

在〈《Python 功力提升的樂趣》筆記(一)Black、命名、壞味道〉中,我們提到了「data」這個不佳的變數名稱。

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

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

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

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

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

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

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

到底是什麼結果?

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

29,我編輯舊文的三個理由

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

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

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

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

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

Django HttpRequest 常用屬性介紹

Let's Django!

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

範例程式碼可參考我的 GitHub 專案,更多教學請見「Django 文章總覽」。


如〈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 的路上更加踏實

28,去了 2 個月圖書館之後

今年 2 月下旬,我決定晚上(下班後)去圖書館讀書!

原因很簡單,我在家不好讀書,主要有兩點:

  1. 如你所知,房間誘惑較多。不過這點其實還好,畢竟我工作、學習都是在家,所以不是主因。
  2. 這才是主因,因為目前升降桌的燈光、螢幕都是為了「使用電腦」而設計,並不適合用來讀書。

以前我有兩張桌子,直接切換,一張專門用來讀書,那樣比較合乎實際。但換了升降桌後,小小的租屋空間就不夠了,不得不把「書桌」丟棄。

一直都有勉強試著讀書,但效果真的好差!

因為過程很麻煩,要先移開鍵盤,如果滑鼠沒放好,螢幕不時會被喚醒。檯燈我用的是 BenQ 的 ScreenBar,看螢幕很棒,但讀書的話,光源距離桌面又有點太遠了!而且角度也需要再調整。

讀個書猶如愚公移山,最後,我決定放棄苦苦掙扎,乖乖去圖書館!

Python API 開發:善用 Enum 的三大關鍵特性

from Pixabay

想必你知道 Python 中有一個內建的特殊類別叫 Enum(來自 enum 模組),專門用來處理「列舉」態型的資料集合。

如同 collection 模組中的各種容器(比如:dequeCounter),Enum 已經定義好很多「內建特性(屬性、方法、行為)」供你使用。這些特性會讓你在處理特定情境時非常順手。

但是,這些特性也使得 Enum 類別與一般類別有著很大的差異,增加了學習門檻

如你所見,Enum 的特性頗多,這讓人在學習、使用之前,難免有點望之卻步——至少我是這樣!

本文主旨與架構

本文分享我最近才開始把 Enum 應用在 API 開發中的經驗——從它的三大特性入手,並輔以一個實際問題情境。

Enum 的特性不少,但只要知曉這三件事,就可以在遇到「列舉」欄位時,善用 Enum 來提升開發效率,同時增進程式碼的簡潔與穩健。

不過話說回來,即使不是開發 API,也不影響你對本文的理解。只是我的經驗是從後端開發而來。

本文架構

為了讓你感受 Enum 的強大與美妙,本文的架構經過精心設計。共分為三個部分

  1. 問題情境:我會先提出一個問題情境,突顯舊方法的不足。
  2. 然後再介紹 Enum 的三大特性,帶你進入 Enum 的世界。
  3. 最後看 Enum 特性在問題情境中如何有效發揮,讓程式碼變得更加優雅——也就是它解決的痛點

藉由這個流程,相信你對 Enum 會有更進一步的理解。