Notion 這款強大的筆記軟體服務，從 2018 年開始打響名號，短短數年之間，已然襲捲全球，即使在台灣也收獲了不少使用人口——包括我。

回首 10 年前的筆記霸主，無疑是當時剛成為獨角獸（估值達 10 億美元），鋒頭正健的 Evernote。那時如果你跟別人說你有在用 Evernote，而對方也知道那是什麼，則對方很可能會對你肅然起敬，表示佩服。

畢竟在 2012 年，有使用筆記軟體的人，相對小眾。

10 年後的今天，資訊爆炸，我們所處的世界也已和過去大不相同，堪稱是筆記軟體的「戰國時代」。選項上五花八門，讓人眼花撩亂，對許多人而言，筆記軟體更是工作與生活中，不可或缺的一部分。而昔日的王者 Evernote，如今已垂垂老矣，不值一提。

2020 年我曾在 Medium 上寫過這篇〈心得 |《曼無止盡》第40期：Evernote 的重生之路〉，祈禱著 Evernote 不要倒閉。因為當時，它仍然算是我的筆記主力（雖然已到了強弩之末）。

沒多久，我就正式棄用 Evernote。此後，我的筆記便改以 Notion 為核心展開。

經過 3 年多的相處，與最近兩年的大量使用及嘗試，總算讓我對 Notion 有了一個比較完整的看法與感受。如標題所言，我並不推薦用 Notion 來管理你的「整個」人生，或試圖將它打造成一個可以管理「一切」的主控台——儘管這聽起來確實很吸引人。

至於「為什麼不？」，則是這整個系列文章所要探討的。

在〈Ubuntu 安裝使用 zsh + 輕量級套件管理器 zinit〉一文中講述了如何在 Ubuntu 安裝 zsh 以及套件管理器 zinit，但省略了「佈景主題」的相關說明。

這次適逢拿到全新的工作機——M2 Macbook Air，我不得不重新建立 macOS 上的 zsh 與 zinit 開發環境。

通常遇到這樣「重新設定」的情境，我真的就是回頭看自己寫的文章，一步一步照著操作，可惜上述文章卻沒有關於 Powerlevel10k 的安裝部分，也對我自己造成了不便。

鑑於 Powerlevel10k 已成為我使用 zsh 時，必搭的佈景主題。所以，僅僅設定好 zinit 並不足夠，我還須補上 Powerlevel10k 這塊拼圖才行，於是有了本文的誕生。

2018 年 2 月，我開始在 Medium 平台上寫作，並持續了好幾年。直到去年 6 月，我終於下定決心，雖不完全脫離 Medium，但改用 Hexo 靜態框架、GitHub Pages、獨立網域「kyomind.tw」，建立自己的 blog 來進行文字創作。

其中的原因與方案選擇過程，以及如何透過 Notion、VS Code 實踐 Markdown 寫作，我已透過下列三篇文章，詳加表述。

就以本文，為整個系列劃上階段性句點。

系列：Medium 到 Hexo——我的 Markdown 靜態部落格寫作四部曲

1. 不離開 Medium，我自架 blog 的理由與選擇（上）：理由篇
2. 不離開 Medium，我自架 blog 的理由與選擇（下）：選擇篇
3. Notion + VS Code：我的 Markdown 寫作工作流
4. Hexo 部落格寫作一週年：完整心得與總結 + 如何持續寫作 Part 2

前言：獨立一週年

本站第一篇文章是去年 6 月 24 日發表，也就是上述的「理由篇」，最近剛滿一年了，是時候該來好好整理一下，這一年之間，有關部落格寫作的心得與總結。

這篇剛好是全站第 40 篇文章，可謂別具意義。

有別於常見的個人年度回顧與展望，既然是部落格的週年紀念文章，闡述重心自然會落在「寫作」這個主題上。其中也包括最重要的——寫作對我的影響。

在〈再見了 pip！最佳 Python 套件管理器——Poetry 完全入門指南〉中，我提到了自己選擇 Poetry 而非 Pipenv 的兩大理由之一，是因為 Poetry 採用了pyproject.toml作為它的工具設定檔。

本文則直接以 pyproject.toml 為主角，用一半以上的篇幅對其做進一步介紹。

第二部分則大概講解一下：在 VS Code 中如何透過pyproject.toml，作為 Black、yapf、isort 這幾個常用的 Python 開發工具的共同設定檔，而非使用 VS Code 自身的settings.json來儲存設定。並提醒一些使用上的細節。

我們知道，Django 提供了專屬的 HttpRequest 類別，把從前端（主要為瀏覽器）傳過來的 HTTP 請求重新封裝成 OOP 物件，方便我們在 view 中操作、使用。

而這個HttpRequest物件，也就是開發時，前端傳給 view 函式的第一位置參數——request。

我們經常使用request，在 view 函式（或類別）內部獲得本次 HTTP 請求的相關資訊，比如所使用的 HTTP 方法，或下面提到的 header 相關資訊等等。

1
2
3
4

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

2022/06/22：GitHub Copilot 要開始收費啦！比我想像的來得更早。價格是每月 10 美元或每年 100 美元，對學生與開源專案維護者免費。詳情請見官方這篇〈GitHub Copilot is generally available to all developers〉介紹。既然確定要收費了，自然也不必再申請，隨時可以安裝試用。

由微軟推出，鼎鼎大名的 GitHub Copilot，相信大家都已經有所耳聞，或者正在使用。

目前這個產品還處於「Technical Preview」階段，想要親自體驗嘗鮮，需要另外提出申請。剛推出時好像是秒申請秒過，但我在上個月初提出申請，月底才收到核可通知。

本來也想寫一篇關於 GitHub Copilot 如何輔助我寫程式的使用心得，可惜我用了一個多星期，並沒感受到太多驚豔。

在看了這篇〈能節省四成開發時間的工具？ GitHub Copilot 的介紹與心得分享〉後，覺得自己可能也無法寫得更詳盡，索性就簡單聊聊。

專案開發難免要使用到 NoSQL，其中最具代表性也最常用的，無疑就是儲存資料結構和 JSON 十分貼近的 MongoDB。

目前工作專案中，存在著需要大量儲存 IoT gateway config 設定的需求，這些 config 記載著所有連接 gateway 的 sensor 設定狀態，是典型的多層結構，且不同 sensor 的 config，其層級、數量並不完全一致，而不同 gateway 之間的差異更大。

本來使用 MySQL 儲存，table 間的關係十分凌亂且複雜，ERD 都畫得很辛苦。

而這種資料特性，正是 MongoDB 擅長的舞台。