Clojure 取代 if 的技巧 (3) --- Atom validator

;; Using :validator to replace the `if`
(def a 
  (atom 3 :validator pos?))

(swap! a dec)

;; Without using `:validator`, we need to put a `if`
(def b
  (atom 3))

(swap! b (fn [n]
           (if (pos? (dec n))
             (dec n)
             (throw (ex-info "content must be positive"
                             {:a 1})))))

*out* 被 captured 時的變通之道

在 Clojure , *out* 是 System/out 這個變數被 java.io.OutputStreamWriter 的物件。

有的時候，有一些 codebase ，*out* 會被 captured ，這種時候，無論怎麼 print ，都無法 print 成功。這種時候，簡單的變通之道是：

(add-tap (fn [o] (.println System/out o)))
(tap> DATA)

Clojure 取代 if 的技巧 (2) --- cond->

問題：

有時候，我們會想要表達一種語意 (semantic)

if (c) {
  hm[x] = y
}

這種語意在 Clojure 會略顯得冗長

(if c
    (assoc hm :x y)
    hm)

但是，其實可以這樣子表達

(cond-> hm
   c (assoc :x y))

Clojure 取代 if 的技巧 (1) --- fnil

問題：
我們需要對一個 Clojure HashMap hm 裡的某個 path 做操作，插入 val 值。需要滿足的條件為：

• 如果該 path 為空，就插入空的 vector，並且在該 vector 裡插入 val 
• 如果該 path 已經有一個 vector  ，就把 val 插入 vector 的尾端

直覺的寫法可能是：

(if (nil? (get-in hm path)
    (assoc-in hm path [val])
    (update-in hm path conj val))

但是，這又略顯得重複、冗長

解法：

• (update hm path (fnil conj []) val)
• (update-in hm path (fnil conj []) val)

Clojure 的 tree 表示法

我本來是比較喜歡 (2) ，多想了一陣子之後，又覺得 (1) 似乎更好一些些。

使用 (1) 的表示法還有一個理由： 假設，你現在是要從一堆已經 serialized data 裡，一個又一個的 item 去讀取，最後會建出這顆樹。很有可能，你會想寫 recursive function 。

而在 Clojure 裡，想到 recursive function ，要想到兩種改善效能的方式：
(1) recur
(2) lazy-seq

其中，lazy-seq 的話，需要跟 cons 一起搭配使用，所以 (1) 的表示法相對有彈性。

malleable design

malleable design 又可以稱之為 evolvable design 。舉例子來說明的話：

• Lisp Macro: 提供你一個 compiler plugin
• Postgres UDF (user defined function) / Object system / foreign data interface
• Protocol, atom semantic in Clojure

上述這些可以延展系統的接口設計，都可以讓後人巧妙地去增加原本的抽象層的廣度與深度。如果善用這些接口的話，日後使用系統的人，可以充分地享受 conceptual integrity 的好處，而不是得到一個層層疊床架屋才勉強構築出來的系統。

雖然我寫 Clojure 也好一陣子了，對於『延展 Clojure』的技巧，一直沒有充分地掌握。仔細想想的話，這個才是 Clojure 最 powerful 的技巧之一，真的要講的話，像大名鼎鼎的 Reagent 就是用這種技巧做出的 library 。使用 reagent 的感覺非常奇妙：一方面，你知道你在寫的東西，它的底層是 React 。另一方面，你又可以使用 Clojure 的高階 semantic ，直接用 @ operator 來取得 reagent 內部的資料。 

background job queue library of Clojure

先談簡易的結論：
1. 想搭配 Postgres 使用 => 用 Proletarian
2. 想搭配 Redis 使用 => 用 Jesque 
3. 都不滿意的話，就再去 Java 的 ecosystem 找，總會找到勉強可以接受的 library 來用。

其實這個問題也滿多人討論的：
比方說，這一篇：有人在 ClojureVerse 詢問，在 Clojure 世界裡，相當於 Ruby 的 sidekiq 是什麼？

＜ 技術決策的理論 >

如果是我來思考這個議題的話，兩個重點：

1. Deployment 是否省事？
2. Library 提供給我的 interface 是否好用？直覺？不會太多儀式性的 code 要寫

DevOps 要省事的話，常常會不想用 Redis 。可以參考這一篇。

由於使用 Redis 做為 durable storage 的 library 疑似發展比較久、也比較成熟，有可能反而是 Redis 組別的 Library interface 比較好用。類似的觀點來自這邊。

< 技術決策的實務 >

Proletarian 與 Jesque 我都用過，library 給的感覺嘛，好像也沒有差很多。大概還是優先選 Proletarian ，畢竟我本人很怕 Deploy 那一段的 complexity。

Postgres 的一些好用的功能：Auth, jsonb, validation on json, ltree, Expression based index

1. Postgres 可以利用 pg_crypto 這個 extension ，快速地做出 Authentication。參考這篇。

2. Postgres 的 jsonb column ，這可以用來快速地搬移 Firestore  到 Postgres 。參考這篇。

3. Postgres 可以對 json column 加上 schema validation。參考這篇。

4. Postgres 可以利用 ltree 這個 extension 來記錄 tree 類型的資料結構。參考這篇。

5. Postgres 也支援 expression based unique index 。參考這篇。

第五項多加一些說明：

在 Clojure 的世界，我想找一個簡單易用的 worker queue ，但是又懶得架 Redis，所以 Proletarian 是選項之一。（Proletarian 是一個輕薄的 job queue library on top of Postgres）

然而，使用 Proletarian 也是有一些缺點：

- 比方說，job 的 payload 會被 Proletarian library 先做成 Transit ，再轉換成 text 來儲存。這時，如果你要放進 worker queue 裡的 job ，你想要對其施加一些 unique constriaint 時，該怎麼做呢？

之前我想不出做法，因為整個 payload 都被先打包成一包做成 text ，總覺得 unique constraint 加不上去。無奈之下，只好在 application layer 去實作這個 unique constraint 的檢查，實在有夠難寫。

最近研究 Postgres 才發現，有一個很犯規的東西叫做 expression based UNIQUE INDEX。用了這個的話，就可以輕易地對 text 或是 json 之類的資料的部分集合，加上 unique constraint了。 

Web application 生成的報表速度太慢

 最近在 Gaiwan 公司遇到客戶委任我們做一些效能改進：

1. 客戶把 code 的 link 給我之後，他們留下的訊息是說，覺得有沒有可能，把一些 code 改成用 Transducer 來改寫，效能就會好了。
2. 我第一時間就覺得，八成不是這個問題。一般來講，web application 這種東西，會慢，十之八九都是資料庫的查詢在慢，更何況，客戶用的資料庫還是 Datomic 。
3. 但是，光是有直覺沒有用，還是要設法証明。我很久沒有做 profiling 了，上次做疑似是十年前，總之，基本的概念還有，技術完全沒有。花了一些時間研究工具之後，發現有兩個程式很有用。
   (3.a) jcmd => 這個可以快速找到 java program 對應的啟動 argument 與 pid
   (3.b) VisualVM => 我是用 statistical mode 去量測。它可以幫你一層又一層地向下展開，看到 x function calls y function ，且 x function 的 total time, CPU time, self time 。我用了這個之後，層層展開函數呼叫後，果然，定位出來，最耗時的地方是資料庫查詢 (Database Query)
4. 該怎麼改進呢？ 一旦找到關鍵點了，要改就有很多可能性。在眾多的改法之中，我個人覺得工程略為耗大，但是一勞永逸的改法，是把資料 sync 到資料倉儲 (Data warehouse) 裡，把本來很慢的資料庫查詢都送到資料倉儲去。由於資料倉儲在 schema 、index 上都有許多神奇的最佳化，效能的大躍進滿可以期待的。
   
5. 然而，這件事的結尾並不是使用資料倉儲。
   我老闆一眨眼就找出效能低落的關鍵點：N+1 problem 。速度很慢的那一段程式碼，它在迴圈裡做 Query 。如果 Query 是那種極度單純的，完全不需要 scan 資料庫的，老實說還好，畢竟 Datomic 在 peer 端做了大量的 cache ，並不會有很大的 I/O 開銷。 而我遇到的這個案例，迴圈裡的 Query 是有做一些些 unification 的。所以解決之道，是要改變程式碼的寫法，把 Query 移到迴圈外。 修改完之後，就快了 20 倍。
   
   

Clojure syntax error 解決方案

使用 Clojure CLI 來做為啟動程式的話，由於 Clojure CLI 會生成 .cpcache 檔，啟動速度會比較快一點。然而，有的時候，.cpcache 可能有一些 cache 造成程式的載入順序錯誤，就會造成 syntax error 

如果遇到明明沒有寫錯 syntax ，卻一直得到 syntax error 的話，可以考慮將 .cpcache 刪除，就可以解決了。