flutter 也可以做 android app 啊，所以到某個程度時就會衝到。
例如 Google Map team 要做 Android 的 Map sdk，但也要做 flutter Map 的 sdk，資源分配就出問題了
google 自己生了個 flutter 跟自己的 andorid team 對幹, 實乃天下奇聞...
這也反應 google 本質上是多頭馬車, 所以有很多專案活不了多久.
多頭馬車是個壞事? 可是 google 卻是世上數一數二賺錢的公司.
state machine 只是個 pattern，實作方式有很多種。像這篇文章寫的方式 (純 OOP) 會很難 trace 嗎？
kaif 的按鈕用的是 event-based 的 state machine，這是特化過的，專門用在即時 event 的服務 (遊戲 or 聊天室)。而 event based 的架構本身就不好 trace，跟 state machine 其實沒什麼關係。
kaif 按鈕其實用不到 event-based 的設計的，只是我寫慣了才直接用。
spring 其實也有出 state machine1 ，可以看看他們的設計
會用 state machine 解問題的人真的很少，大概只有遊戲圈的人才會用。而且需要一段時間練習。
一個簡單的判斷法，如果你的 class 出現了三個以上的 boolean flag，然後有一些會衝突相依，那麼差不多可以試試用 state machine 來 refactor 了。
題外話，你知道 kaif web 的 up vote/down vote1 的三角型按鈕是用 state machine 做的嗎？
一對小小的三角型包含了六種 state :
- WaitVoterState
- WaitSignUpState
- EmptyVoteState
- UpVotedState
- DownVotedState
- VotingState
為什麼只是個 up/down vote 要搞到 state machine？沒辦法，一開始也沒用 state machine 解的，不過後來跑出來三、四個 boolean flag 後我就寫到抓狂了，一氣之下就 refactor 成這樣了
這一篇還幫大家復習了 compiler/interpreter ，不錯讀。
Dart/Flutter 會變成 AOT 一部份的原因是 iOS 造成的，因為 iOS 不能跑 js 以外的 JIT 語言。(最早的 Flutter 只有 interpreter)
創業跟轉行到底能不能類比？
會出來創業的人大部份都會有 不想按步就班 的想法吧，無論背後的原因是什麼。這種特質和 磨好幾年後再跳出來 根本是相斥的。
所以創業的人跌個頭破血流是個常態，而且無法改變。
很少人直接寫 servlet 吧？ 大部份上面都會掛一層 (Jersey/spring...etc)
那麼 servlet 這個 abstraction 就變成累贅了，去掉後少一層自然變得比較輕，也不需要部署肥肥的 servlet container 了。
(不過 benchmark 的結果都是純 servlet 變態的快… 神奇)
時代已經在前進，除了 servlet 技術外還有別的選擇，像是 spring web flux
web flux 因為沒有依賴 servlet 所以只能和 Freemarker/Thymeleaf 整合。所以跳過 jsp/jsf ，改用這兩個以後切換時會比較有利吧。
是說純 server page 也越來越不重要就是
在台北怎麼享受同樣的經驗？
- 搬到合適位置租房子
現在台北沒人買房子吧？沒吧？真的有人買嗎？
- 上班路徑規畫經過河濱
台北市河濱一整圈 60km，外國人來都羨慕的要死，哪有什麼城市一整圈都有河還有專門的單車道？
- 台北工作地點沖澡很難
到健身房付月費洗澡，或是
到附近朋友家洗或合租一小間來換衣洗澡
- 早上彈性工時就靠運氣了，沒辦法就只好早起，夏天沒問題，冬天大概就掛了
作者可以做到 篩選 這件事，是因為 Spring 有幾項優點
API 成熟穩定。即使現在已經 spring 4/5 了，還是可以用 2.x 版的方法去改寫，2.x 版到 5.0 中間隔了十年啊！
可以漸進式的移植。原本 servlet 的寫法，改成 spring controller 的皮後，大部份的舊程式還能動，你不用一次全部改完，可以分好幾個批次做。
spring 是個高度模組化的 framework，你可以只用他的 mvc 就好了，其他都可以放著先不管。也因為如此，你才有機會 篩選，只導入一部份你想要的功能
不是什麼 framework 都能這樣玩，例如 Angular 就沒有上述的任何優點。想導入嗎？那就全部重寫吧