dev, production 都可用
怕的話就 local 玩一玩就好，算是最簡單的方式建立一個 k8s 環境，然後資源用的很少。
去裝 minikube 或是 Docker Desktop 內建的 k8s 就知道，裡面什麼都沒裝就吃掉 30% CPU usage，這真的抓狂
kaif 哪天我也會轉到 k3s 吧… 有空的話 XD
基本上新設計的 date API 多半都有 Java8 time API 的影子 -- 分為機器產生的絕對時間和人使用的曆法時間
Absolute -- Java 8 Instant
DateTime -- Java 8 LocalDateTime
不過沒看到相對應的 ZonedDateTime 或是 OffsetDateTime，只有轉 string 時才會出現。
這個嘛... 我猜未來 proposal 會加上去吧，而且 Absolute 這個字大概會被改掉，因為明明文件裡就一直出現 instant 這個字。
所以要寫 test
如果比較好測，那通常是比較好的設計。你通常也只會重構到測試不會太難寫這樣，不會太過頭。(class 太多就測試更多，想到這你就會懶得抽這麼多層了)
測試可以引導設計，再加上一些經驗的累積大概不會錯太多。
當然如果寫的是 library ，會放出來給別人用，那又是另一種規則。
這篇又浮上來了
method 加上參數，裡面多寫個 if 進行擴充 -- 這大概工程師每天都在做
所以我覺得這類型的還好，它要累積到一個程度之後，才要重構，看是要回到重覆或是抽得更多層。
出現問題的大部份都是太多參數，就是作者說的，抽象化錯了方向。另一種錯誤是太早將單純的 if 抽成更複雜的 class/interface，也不能說一定錯，但新需求多半不可預知，所以八成都是抽錯方向，不如不抽。
然後更難得問題是，這些修改不一定是同一個人做的…
每次只要有機會用到 micronaut, 就有一種清爽的感覺
小, 簡單, 又快. 然後還大部份和 spring 很像
如果 spring 沒有包伏然後重開機的話, 大概就是 micronaut. 而不是現在的 spring boot.
但是你就是知道它不會變 spring 成為主流, 所以只能在小專案玩玩而已...
4k 用 2x scale，然後又配 27" 字就會太大了。
如果要用 2x scale 又要 4k，就是選 24" ，字才會剛好，但真的有人這樣選嗎？
27" 要上 2x 就是要用 2560*2 這種 5k 的解析度，這也是為什麼 Apple iMac 27" 是 5k。
我自己就不是用整數倍率了，不論在 Mac 或 Linux，不細看的話看不出差別，不像這作者這麼精。
這對 server-side 的開發者也很傷，本來 build docker image 已經是跑在 VM 裡了，現在 VM 變成要用 Arm emulate x86。