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，而是指 Servlet API，掛一層 Jersey/Spring，還是看到不少人搞不出 HttpSession、ServletContext 等的一些對應功能，然後縮回去直接搞 HttpSession、ServletContext … 基本上 Jersey/Spring 這類抽象層都想或有對應的方案，不過有時麻煩，有時藏在某些地方找不到，有時是心智模型還是掛在 Servlet Container，經驗上難以脫離（新生代若完全沒有或不用接觸 Servlet 容器，大概會比較沒這困擾） …
很少人直接寫 servlet 吧？ 大部份上面都會掛一層 (Jersey/spring...etc)
那麼 servlet 這個 abstraction 就變成累贅了，去掉後少一層自然變得比較輕，也不需要部署肥肥的 servlet container 了。
(不過 benchmark 的結果都是純 servlet 變態的快… 神奇)
若可以屏壁 Java EE，就算只是 Servlet API，基本上有很多人會很開心（也許他們並不清楚為什麼開心），雖然 Web Flux 目的並不在為了取代 Servlet（這野心也太小）。
或許多數人也舉不出 JSP/JSF 的問題在哪，大概只是純 Server Page 越來越不重要的投射居多。
時代已經在前進，除了 servlet 技術外還有別的選擇，像是 spring web flux
web flux 因為沒有依賴 servlet 所以只能和 Freemarker/Thymeleaf 整合。所以跳過 jsp/jsf ，改用這兩個以後切換時會比較有利吧。
是說純 server page 也越來越不重要就是
即使事隔多年還是會遇到中文亂碼的問題 ...
其實主要還是 http header content-type 中的 charset 要設正確，client 端與 server 端統一都用 UTF-8 的話就不會有亂碼問題 ...