去翻一下自己的 blog，最早是 PostgreSQL Lob筆記1 這篇。2007 年那時我就把單位的 Oracle 給換成 Postgres 啦。
那時最好笑的是別人問我我用什麼 DB，我回 Postgres，然後那人說沒聽過...
設計師投入前端的不二法門
在前端職涯中，我常遇到許多視覺科系背景的設計師來詢問投入前端領域的可能性，我可以打包票和你說是百分之兩百適合，但礙於許多人會對所謂的「前端工程師」、「前端設計師」、「網頁設計師」的工作內容感到黑人問號，因為有些設計師本身也會一些網頁排版，那麼到底要具備哪些能力，才可以稱得上自己有投入到「前端」呢？
設計師 --> 通常邏輯不夠強
工程師 --> 通常沒有美感
兩者兼具 --> 貴貴的人材
但我認為 Kotlin 缺少類似 swift 的 guard 機制，如果對於多個 nullable 物件，要確認他們均不為 null 再做某件事，程式難免會寫出許多 if null check，會讓 code 繁瑣，詳情可以參考此討論 Kotlin null check for multiple nullable vars。
這點我也不同意，swift 的 guard 實在是有點煩，跟 Java CheckedException 一樣繁鎖，寫起來很囉嗦。
問題是出在有一堆 nullable 的 type 才會有 multiple guard 這種需求，在 Swift 因為常常和 objective c 和 UIKit 對接，所以會有一堆 nullable type ，這是技術債，很難避免。
Kotlin 這裡，我沒有很多需要 multi guard 的地方，印象中最多兩個吧？因為習慣上我會偏好很早之前就把 argument 轉成 nonnull type (比方說從 restful API 過來，通常會有一堆 null，在這一層就通通擋掉了 (reject/validate/convert/default value)，能進入 service 層的 nullable 並不多。
或者比方說，你有一個 boolean flag， var enable:Boolean? 。你的需求除了直覺的 enabled/disabled 兩種狀態外，還有另外一個 未設定 的狀態。然後大多數的人取捷徑就直接讓 flag 變 nullable Boolean? 達到三元狀態的需求。
我個人偏好就直接改 enum 了，省得一堆 nullable type。Kotlin 很多定義都是 one liner ，就儘量用吧
最後，如果一個物件上有一堆 nullable type field，這是一種 design smell，臭臭的，應該拆開重構才是 (Database 的 table 有一堆欄位是 null 也代表正規化做的不好)
關於 pair/triple... 我覺得 triple 已經很夠了啊？
而且如果寫到 triple 以上我就會開始看要怎麼改了，另外 Triple 我也不會 return 出去給別人用，都是中間產物而已。有三個欄位要送出去我就會換 data class ，比較好懂。
guava 那邊1 有一些討論為什麼連 Pair 都不好
其實這是為了催毀廣告公司而來的，不止是擋廣告而已
每個廣告都點，所有的廣告系統都會崩潰 (基本上就是把你加入黑名單)，Google 就這樣把這個 extension 給 ban 了
有關 var ，的確 rust 的做法比較好。不過 kotlin 寫到後來就是 val 和 lateinit var 兩種而已。
Java10 要加入 var ，這點另人傷心，現在的規格是:
var str1 = "foo"
final String str2 = "bar"
final 的版本反而很長。應該是倒過來比較理想:
val str1 = "foo"
String str2 = "bar"
也就是鼓勵大家偏 final 的設計