neil 主要就四種常用的用法：
其中，第一與第二種用法算是最常用的，因為 Clojure 的開發過程之中，就是會不停地尋找、新增 library 。而第三種用法裡，常用的有三種形式：
compojure 在決定接下來要使用哪一個 route 是單純地一個一個逐步比對，這個單純的作法多數時候沒有問題，但是一旦當某個 route 的 middleware 會有副作用的時候，這個作法就會出問題。
所幸，compojure 後來提供了一個 wrap-route 恰好可以處理這種情況。
HoneySQL format 的 default 輸出是給 JDBC 處理的，所以當想讓它輸出給 SQL CLI 時，就要使用參數。
有兩個很常見的 Exception handling 不良風格
1. 濫用 :pre 和 :post 來做檢查，而不是使用 spec 或 malli
2. catch Throwable
```
(try
(assert false)
(catch Throwable e
"Barfoo"))
```
理由是類似的：
(1) Error => 程式有 bug ，設計時不考慮 catch 它。這種可以用 assert 。
(2) Exception => 程式沒有 bug 但是執行的時候遇到異常，設計時可以考慮 catch 它。
註：
(a) 用 : pre 和 : post 的話，會丟出 Error ，但是一般的格式錯誤是 Exception
(b) catch Throwable 的話，會 catch 到 Error ，但是我們只應該 catch Exception ，不應該 catch Error 。
最近才搞懂的東西：「在什麼樣的 context 之下，應該考慮使用 Protocol ？」
為什麼在用了 Clojure 這麼多年之後才搞懂，應該是因為我過去寫程式的時間裡，幾乎沒有在寫 Java 。
我在 Clojure 官方論壇找到了答案
答案是：Protocol 最適合用於做為 SPI (service provider interface)
protocol functions are better as SPI to hook in implementations than in API as functions consumers call directly. It is often helpful to wrap protocol methods with a normal function that can supply additional logic if needed around the call into the protocol.
與 SQL 相比，Datomic 這方面的工具比較少。並沒有像 dbdiagram 這種工具。
不過，有一個算是簡單好用的 workaround 方法：
1. 將 schema 搭配 chatGPT prompt
> 將以下文本的 Datomic schema 的簡易表示法，轉換成 mermaid 的 ER diagram 表示法
2. 轉換完成之後，貼到 Mermaid Live Editor 來繪圖。
3. 做微調，因為有時候會判斷錯。