變天了！
value type 改名 InlineType , InlineType 不能 null，要多一層 IndirectType才行 (後面加個 ?)
IndirectType 白話講就是 Boxed Type 吧
primitive 和 boxed type:
int -> Integer
到了 inline 和 indirect 就會寫成這樣
inline class Foo
Foo -> Foo?
所以 inline type 可直接當 primitive 來看，像這種寫法 List<Foo> 是不行的，你得用 indirect type (即Boxed)，也就是 List<Foo?>。
私以為這個設計高竿，只用一個 symbo ? 直接解決原本 value type 模菱兩可的表示 (看不出到底有沒有 boxing)，而這個 ? 可以為了之後的 nullable type 舖路
Boring Tech 的特徵:
- 有 LTS 版本，時間長達三年以上
- 即使沒有明確的 LTS，舊版本也繼續維護到天荒地老
資訊新人都以為學最新最潮的技術是最棒的投資，卻不知道 Boring Tech 學完一用就是十年...
舉例問一個寫 nodejs 的，給他選 SQL 和 GraphQL，他會選哪個？
從 ec2 instance 搬到 k8s 之後發現，現在 cluster 一死掉，就是全部服務一起死。不像以前 ec2 個個虛擬主機是獨立的，隨便掛一個都沒差
k8s 適合跑的應用都是 stateless，更廣泛一點說，就是 cloud native app。因為這樣，所以Pod、Job…等等元件要 scale 和重啟都好輕鬆啊！但其實有另一大塊是 stateful app 很難搞定，許多人乾脆 stateful 的通通不放 k8s 裡了。然後更妙的是 k8s cluster 本身就是個 stateful app，而且不符合 cloud native 的定義。這算是呼應第一點，當 cluster 壞掉時，你沒辦法很容易啟動新的 cluster 原地復活。
k8s 太複雜了，而且未來只會更複雜，因為目前不斷有新的標準產生。依照過去十幾年的經驗，過度複雜的系統最後會被簡化過的新架構取代，感覺 k8s 也是個過渡性產品。
與 k8s 成對的是 microservice，甚至有人還說: 如果沒要要用 microservice，何必用 k8s ? 問題是 microservice 這種分散式泡沫一定很快就會消失，因為前例太多了，像是 EJB、WebService、SOA... 等等
k8s 現在有很多小廠商提供產品和服務，大廠則是不斷推出相關的新產品，然後又有証照可考，未來很多企業都會導入的。從這角度來看似乎很正面，但這個超級像過去的 J2EE，有標準、有証照、有一堆免費和商用 container 可選 (以前 J2EE server 也叫 container，這不是巧合)。你看看 J2EE 現在還剩什麼廠商吧…
當然啦，技術本來就會隨時代迭代，這個十年可能就是 k8s 稱霸，而十年也夠久了，投身這門技術可以讓自己有競爭力，企業也會因為標準化，尋求人材時會簡單許多。要說短期內會出現的缺失，就是因為 k8s 變成顯學、標準化，造成大家不適用 k8s 的系統也會硬套，然後又難學難管理，白白增加成本。
通常 second level cache 可做的事都會在更前面擋掉 (例如網頁的 cache) 所以 2nd cache 沒事不用去碰，用比較宏觀的角度去最佳化比較好
security best practice, No.1:
Always blocks pastebin in production, here are steps to configure security group via aws cli...