繼續昨天的研究…。
初步看來就是要在平台內實作「近乎整個編譯器」。之前我知道 Eclipse 推的 Xtend 語言，（另）一個號稱「更好的 Java」，是從 Xtext 衍生出來的計畫，但也只是沾沾醬油，未嘗細究 Xtext 是什麼樣的東西。
雖然我是個非 CS 本科的外行人，但是我對 compiler, assembler 如何產出小時候在 hex editor 與 disassembler 看到的那些機器碼，一直很感興趣，卻始終因為個人的怠惰，也缺乏強烈的動機，沒有認真下去研究。也許這次是個好機會。
我最近已經有點受不了這樣的狀況：
當我在 Vim 底下，打開 NERDTree 的時候，由於游標還在 NERDTree 的 window 內，所以只要我操作 :edit 或 :bnext, :bprev 指令時，檔案就會被 Vim 在 NERDTree 的 window 內打開它所屬的 buffer，而非我預期的「編輯區」window 裡。
於是我必須把 NERDTree 的 window 關掉，而且得用 :q 指令，因為在當下這 window 的 buffer 已非 NERDTree，所以熱鍵對應的 :NERDTreeToggle 指令只會再分割出一個新的 window 來叫出 NERDTree。
成也 Vim 的彈性，敗也 Vim 的彈性，Vim 沒有「側欄」、「編輯區」的概念，而我想要的只是一個單純的檔案管理員而已。
轉頭望去，用 Sublime Text 的快樂同事們沒這個困擾，遑論 App 組的同事用全功能的 IDE (XCode, Eclipse) 搞定「真正基於專案 context 的 auto-complete」與「即時檢查程式問題」。
而我還堪自誇的也只剩下「就算 SSH 到遠端也能看似輕鬆寫意」、「看起來好像很 geek 的虛榮」。
但是，遠端作業通常也只是維護機器設定檔當中關鍵的寥寥幾行，Vim 熟手宣稱的高生產力在這裡佔不了多少優勢。符合「一般需求」的 Pico, Nano, Joe 等「簡易型」編輯器就夠用了。
前幾天試用了 Visual Studio Code 與 Atom，以及再讀一次王垠的〈怎样尊重一个程序员〉，更讓我覺得，我長期這樣折騰自己究竟是為什麼？而且我還是一個使用傳統上下左右鍵，根本沒習慣 hjkl 過的 Vim 使用者，日常工作用的那幾個按鍵也沒發揮過人的高效率。
簡單說，就是裝逼而已，根本就是個空心大老倌。
我還深深反省了，之前某新進同事問我們 Rails 開發是用什麼 IDE，我為此輕蔑不屑地想：「科科，又是一個沒 IDE 就不會做事的」。但是若仔細想想，如果我們的 Rails 開發，可以用個幫我們提供「真正基於專案 context 的 auto-complete」與「即時檢查程式問題」的 IDE，那之前有多少低級錯誤，其實是可以避免的？
於是，除了尋覓一個更適合我的編輯器或 IDE，我開始翻起 [The Craft of Text Editing] 這本電子書，並對照幾個編輯器專案，去驗證書中所說的開發概念與方法：
（我挑這幾個「使用比較現代的系統程式語言 (Go, Rust)」實作的編輯器，是想要摸蜆仔兼洗褲、看看別人是怎樣運用這些新語言的。）
一開始讀到這本書的 1.1 User Categories 時，介紹 Neophyte 型使用者那段，就讓我深切反省，自己在做產品時，對 UX/UI 的投入還是遠遠不夠的，甚至悖離了「應該是你要去適應與滿足用戶，而不是挑用戶」的原則與初心。
以往我會覺得這東西很重要，只是因為不是我所擅長，所以並沒有這麼關注。但是由於工作上長期下來一些事情的積累，造就我心境上的轉變，認為這東西跟我過去碰的「硬派」技術同樣重要。
好的 UX/UI 絕不僅是擦脂抹粉，套個版型。倘若金玉其外、敗絮其內，還是白搭。
好的 UX/UI 至少要做焦點團體研究。
好的 UX/UI 要符合基本的排版原則，顧及 Accessibility，符合 Human Interface Guidelines & Design Principles。
下次當你我用到一個「直覺、好用、近乎無腦」的 UI 時，也許可以想想，設計者花了多少心思與成本，來 make you happy？反之，那些強調功能多強大、架構多優異，用起來卻讓你我覺得「這尛？」的產品，到底哪裡做錯了？
對於這種我以為會 It Just Works 卻並非如此的事情，就會覺得很煩躁。
直覺上，我會以為只要掛上 ENI 就該直接能動，卻發現這網卡有掛就跟沒掛一樣，原因是 routing table 打架，適用於 eth0 的規則先套用，自然 eth1 就不理不理，如果手動置頂讓 eth1 規則排在前面，就反過來變成 eth1 能動，eth0 不理不理。
解法就是要用多個 routing table。參考這篇文章的方法，為 eth0, eth1 分別設定：
ip route add 192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.61.20 table 20 ip route add default via 192.168.1.1 dev eth0 table 20 ip rule add from 192.168.1.20 lookup 20
ip route add 192.168.1.0/24 dev eth1 proto kernel scope link src 192.168.61.21 table 30 ip route add default via 192.168.1.1 dev eth1 table 30 ip rule add from 192.168.1.21 lookup 30
什麼場合會需要這樣搞？AWS 的粉絲與專家會跟你說沒有必要這樣折騰，一個 ENI 就可以綁多個 IP add. 了，然而如果你需要架設某種就是要綁「網路介面」而不是綁「IP Address」的服務時，你就是需要這樣折騰。
事實上在 Linux 處理 IP 選徑的時候，預設行為就是這樣，所以 EC2 & ENI 也沒多做事，就只是蕭規曹隨。
當然 AWS 粉絲與專家也很有可能會跟你說：「你可以跟 AWS 官方提議，改成不需要這樣折騰。」現在我每次聽到這種話就會心火熊熊燃燒，尤其是在需求有期限、AWS 卻不見得會搭理你的現實下。
為什麼我們會對某些產品感到貼心、好用？就是因為「它雞婆地多做了一點事」。
北市圖現在有智慧館（無人服務圖書館）以及 FastBook 自動借書站。我剛剛聯想到，如果在公車站、火車站、捷運站以 Kiosk 型態，推送形同有「無限複本」的電子書，會不會有搞頭？
現在的智慧型手機、平板電腦很普及，且不論螢幕大小、顯示品質不一的枝微末節，單以「提供大眾交通工具旅客一份『文庫本』概念的閱讀材料」為宗旨，推廣一次車程就可以讀完至少一半的精選內容，這樣對推廣閱讀有沒有幫助？
對圖書館而言，讓圖書館員來經營內容農場，是否自詡「資訊守門人」的圖書館員能做得比現在這些內容農場業者與小編更好？錯誤內容更少（特別是健康醫療類內容）？
對創作者而言，圖書館舉辦講座、工作坊，教他們使用相關工具產出 EPUB 開放格式的電子書、並鼓勵使用 CC, FDL 等開放授權條款釋出，這樣圖書館是否能夠回到本質初衷、而不是在電子書商的 DRM 機制下傻傻為人作嫁？
這樣兼顧原創內容來源、推廣通路、讀者服務的想法，可行性有多高？
都是用 Rails 開發的，記錄起來。
其一，除非還沒有 release 給他人（包括分工合作的同事與客戶），否則請不要改動已經寫好的 DB migration(s)，不然就會有 time paradox 式的荒謬劇上演。
習得教訓：只看 db/schema.rb 是不準的，請跑 rake db:version 才知道當前運作的專案的 migration 是到哪個版次。
其二，在 Doorkeeper 裡、牽涉到 doorkeeper_for 處理的 controller(s) 當中、所有的 Devise seesion 操作，如果是從非 localhost 來的 requests，一概無效。（←好拗口）
如果想要「在認證完 OAuth 拿到 doorkeeper_token 後立即幹掉 Devise session，以免多開一道門就多增加一個安全風險」，得在 Doorkeeper::AuthorizationsController 處理 new 時就做掉。
習得教訓：「本機上明明就可以，為什麼搬到部署環境上就不行了？」就是推託、就是偷懶。