AuthorRef 這個想法有趣。不過大多數的 relation 都不是 aggregates ，這不是變成 8 成以上的 relation 都要多加一個 *Ref class 嗎?
我本身的話， Mac 三、四年就換一台，這時我也不會從 TimeMachine 回復，都是整個重裝，因為三年來累積的垃圾很可觀的。
手機我也是比照辦理，每次買新的都不 copy 資料的，真的重要的資料雲端早就該放一份的
inbox 是個技術力挑戰的產品, 80%的程式碼都是用 java 寫的. (web 用 gwt 轉, iOS 用 J2objc 轉)
這個產品結束也代表 google 完全放棄 gwt 和 j2objc 了
snake_case 是很美好的，但是我自個是不採用，我只用 camelCase。當然啦，這樣進資料庫後會變醜，但我比較希望:
Mobile Client/Web client -> REST JSON -> Model -> Database Table 這四個 layer 裡的欄位通通長的一樣，而不是在那轉來轉去的自找麻煩。
Android/Swift/Typescript/JSON/Kotlin 通通都是 CamelCase，除非你的 tool chain 裡有 ruby 或 python，不然建議不要浪費時間在這上面。
日期是指 literal 嗎？
不然 format 成什麼樣子有什麼差？不是都 prepare statement 代問號進去？
edit: 剛看完 mysql 那篇，best practice 是 uint。LOL，mysql 果然沒下限。
純 rest 要用名詞, 所以要改寫成 /user/{id}/approval。
要講究純 rest 到最後變得像是在考文法一樣, 咬文嚼字, 我個人是不太喜歡浪費時間在這種地方啦。
而且用 PATCH 就對了嗎？approve user 這個動作有可能改到三個 Table 以上，不一定是只改 user.approved 這個 boolean flag 而已啊。
我最後都是混用。只有簡單的 CRUD 才會用 REST，其他很難用 resource 表達的通通用動詞 + POST (就是 RPC)
不過 url 都會是小寫英文 和 - 就是了。然後就算是 RPC ， url 也會傾向用 /approve/user/{id} 而不是 /approveUser?id={id}
Java8 應該會是有史以來會被維護最久的版本吧，一堆人會卡在這。
ubuntu 18.04 本身就是裝 openjdk8 ，所以最少會被 canonical 維護五年