〈再見了 pip！最佳 Python 套件管理器——Poetry 完全入門指南〉發表至今，已過了 1 年多，這意味我也用了一年多的 Poetry。
感覺如何？——我覺得還不錯！可見不是三分鐘熱度而已。
對現在的我而言，Poetry 已成為專案開發不可或缺的元素。它不僅提供了更加便捷的專案套件管理和版本控制，同時，Poetry 支援 pyproject.toml 作為設定檔的特性，也使得我更容易使用其他也採用 pyproject.toml 的工具。
- 再見了 pip！最佳 Python 套件管理器——Poetry 完全入門指南
- Poetry + pyenv 實戰心得：常用指令與注意事項
- 終結 requirements.txt：Dockerfile 多階段建構 Poetry 虛擬環境（待發表）
我常常覺得，軟體工程師可能是最能體現「當你手裡只有鎚子，看什麼都會像釘子」的一群人😂
我們在工作中，有時會陷入一種被稱為「路徑依賴」的困境。本文將探討「路徑依賴」在軟體工程師的工作與職涯發展中，所造成的各種影響和受困者會有的具體表現。
或許會讓你感到有點熟悉。
「路徑依賴」是個社會科學的概念，用來描述一種現象，即一旦人們在某一方面選擇了特定的路徑或方式，他們就可能變得過度依賴這條路徑，並且可能難以改變。
這種依賴性可能源於各種因素，包括習慣、成本、學習曲線等，並可能在多個層面上產生影響，包括個人的行為、團隊的運作，甚至是整個社會的結構和制度。
在這裡，我們將專注於討論「軟體工程師常見的路徑依賴」。以下的內容主要是基於我個人在工作上的觀察，可能會帶有一點偏見，但絕大部分都是基於事實。
isort 是一個 Python 套件兼命令列工具，可以幫開發者自動排序 Python imports，以符合 PEP 8 規範。這種排序也可以讓程式碼更加易讀且易於維護。
之前已有數篇文章介紹過，可參考本站的「isort 標籤頁」。
isort 會自動將 import 分為「Python 標準函式庫」、「第三方套件」、「本地模組」等三大區塊，並依字母順序排列，同時為你在三個區塊之間空一行。
isort 有一個 bug（我也不確定是不是 bug），就是對於本地模組的「排序判斷」，有可能發生錯誤。
這會造成什麼結果？通常的影響是，本來應該排在第三區塊的 import，排到第二區塊去了。總之就是 import 放錯了區塊。
這樣除了不符合 PEP 8 規範，更重要的是，它還可能對開發者造成「誤導」。而且會使用 isort 的人，往往就是在乎 import 排序的人，當然不能接受這樣的錯誤。
相信大家在 2023 的上半年都被 AI 相關資訊狂轟濫炸到有點厭世了。
從去年 11 月底 ChatGPT 發布以來，我們都知道，這個世界發生了天翻地覆的改變。
有人因此賺到快錢，有人想法得到了實現，而更多人如你我，則是在這波浪潮的後方，苦苦追趕，擔心跟不上時代，或失去了自身價值。
藉著大眾對於 AI 資訊的焦慮與渴求，線上知識平台紛紛推出了相關課程。有些你我從未聽聞的人，也說要開課教你學 AI。甚至連 3C 產品評測網站、信用卡優惠資訊部落格等等，也開始發表 AI 工具介紹文章。
此時此刻，AI 就是風口，就是流量密碼。
「資訊焦慮」一詞並非 ChatGPT 時代所獨有，早在此前就已存在。但隨著 GPT 時代的到來，焦慮感無疑加劇了，因為我們面對的資訊量比以往更加龐大、更加複雜。
太辛苦了。
這篇應該算是 Python Linter、Formatter 系列（嚴格來說並沒有這個系列，它們只是彼此相關）的最後一篇，有關「Code Formatting」這一主題的文章，之前已經寫了不少，依時間順序如下：
仔細一看，其實不就是 Flake8、yapf、isort、Black Formatter 這 4 項工具的排列組合而已嗎XD。
是的！我自己整理到都覺得有點不好意思了🫣。
但是，為什麼要寫這麼多？還是那句老話：「我認為這些工具的重要性，再怎麼強調也不為過——更別說它們常常被低估了。」
我曾在上述文章中的開頭或結尾處，不厭其煩地表達自己對它們的重視，這裡就不再贅述，直接進入重點。
在這篇文章中，我們將講述如何使用 pre-commit 設定 Git Hooks，並以 Flake8、isort、yapf 為例來進行演示，同時提醒一些注意事項。
如同 Poetry，pre-commit 也是我在工作上，強烈希望導入的工具——畢竟它可以有效降低我 code review 時血壓升高的次數☺️
〈14，小米 13 的兩大關鍵亮點，與那些「價值觀層級」的器物們〉點出了所謂「價值觀層級」的「器物」，這期就來補完這個部分。
當然，無論是定義還是清單都是非常個人化的產物，僅供參考。
我們或許可以把喜愛或討厭特定人事物的程度，大致區分為「偏好」與「價值觀」。
兩者在好惡上，肯定具有「量」的差異，但顯然不止如此而己。
如果要再加上一個根本的區別，那或許是「難以忍受」——那些你難以忍受它不存在、存在的人事物，可能就稱得上價值觀層級的事物。而其餘的，就只能說是偏好。
比如，我就完全不能忍受，命令列（CLI，Command-Line Interface）的背景是白色的！淺色的可以，但白色就不行。
或更常見的「香菜之爭」，要說它對部分人而言，屬於價值觀層級的事物，或許也不為過。
本文主要寫給軟體工程師，尤其是後端。
不過，這並不是一篇 yadm 操作教學，而是我在選擇 dotfiles 同步方案時，所做的功課與思路整理，其中的考量大概有下：
如〈Linux 開發環境設定：zsh、zinit、pyenv、poetry、docker〉所言，因為新 VM 的建立，我又得重設一次開發環境，而重設開發環境往往是一個耗時且繁瑣的過程。
在這個過程中，需要重新建立一些設定檔，例如.bashrc、.zshrc。這些設定檔通常包含了工具設定、命令別名、環境變數等大量內容，因此特別惱人。
此外，即使不是重建環境，平時要在不同 VM 包括本機電腦間「手動同步」這些檔案，也是一件讓人很想逃避的事。
以.zshrc為例，如果它很少變動，那可能還好。但很不幸的，我又是一個很愛為命令列工具建立 alias（別名）的人，光憑這點，就使我不時會修改.zshrc。