直接違反機器人三定律第一條。

之前比較 v1 和 v4 時就覺得 v4 有重複的機會，硬體 ID + timestamp 保證 unique 不是更好嗎？

最後大家還是要時序的 UUID...

他的第三點，special case 不好，然後他就直接 refactor 成重覆的兩個 function。

不過遇到這個問題，我還是會先套用 WET 再說 -- 也就是等到出現第二種 special case 時，再來重新思考怎麼 refactoring。

“The difference between xhyve and hyperkit” by Charley Chen https://medium.com/@hintcnuie/the-difference-between-xhyve-and-hyperkit-67a9f378ab97

https 看來是太難了 XD

人也會判斷不出來

用電腦的好處是 假設我有 ABCD四張不同時間拍攝的 可能A時間點還看不出來 但是 BCD 之後出現腫瘤 我可以把A也標示成有腫瘤去訓練

問題在於 AI 如果沒診斷出腫瘤怎麼辦？

希望這次AI熱潮會跟以前不一樣xd

遠景比較霧的部份也沒有被銳利化，神

對 AI 工程師有更多的了解，寫得不錯

我好興奮，我好興奮啊 ! (tm)

是啊，沒有問題

你現在postgres時間用 timestamp with tz?

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 果然沒下限。

hm 看到他寫 ISO-8601，但最近習慣存進去就直接 utc timestamp int。

剛剛 qrtt1 提醒了我還有這篇 Facebook 在 MySQL 裡存時間的型態1

這樣母湯喔… 變快或變慢的原因都要去了解

如果DBA不給力還是要有個保險可以刷卡callout percona阿xd 目前是都還沒用到就是了。

之前大部分問題是加ram讓資料進記憶體就會乖乖了，最近碰到加記憶體還是慢的，升版mysql速度居然快好幾倍，不知道是原來太爛還是oracle黑科技太威

資料庫會出什麼事？出事不是都自己搞砸嗎？

我用mysql主要還是出事找的到人support, 加上oracle下放很多黑科技

8.0 不是有支援json了?

nosql 用慣了, 回去用 rdbms 就是開 materialized view. mysql 當然是沒有.

json, recursive ... blah blah 什麼都沒有

用了 MySQL 一陣子好懷念 PostgreSQL 的 JSON 功能... PostgreSQL 可以直接對 JSON 欄位做 index，MySQL 要用 virtual column 來處理才行...

MySQL 有地方不符需求？