作者: Hui-Hong YOU

報到的時候由於不諳動線規劃，所以跟報到櫃台人員發生一點誤會，主要責任還是在我，是我修養不到家。雖然後來跟對方道歉了，但是在這裡還是想要再次跟當事人表示歉意。

JavaScript 老爸的演講很精彩，回顧與展望了 JS 的發展，只是我印象最深刻的還是 asm.js 的威力展示。（爆）

接下來雖然我選擇聽蔡學鏞的場次，起初是基於追星的心態，畢竟受他超高水準的譯作獲益不少，且很少人的譯者序可以寫到比作者序還引人入勝的。但是真正聽過他講其個人獨創的 3D 架構方法，就有種「聽過這場就值得這報名費了」的滿足感，這是真正知道如何治學的人，將其心得化為有系統的知識，再用易懂的敘述講給別人知曉。我只能說：「佩服！」

再來我原本打算要聽拓元的場次，卻臨時改變心意去聽獎金獵人如何逃離 Drupal 的泥淖。很可惜沒聽到他們如何處理原有資料庫，畢竟這才是重點。

下午第一場聽 KKTIX 的場次，重點就是他們並不是完全拋掉 Ruby on Rails，事實上還持續跟上最新版本。務實地將 Go 與 Rails 各自用在其擅場。

唐鳳的演說很鼓舞人心，其實這陣子我的情緒很低落，聽過唐鳳的演說，以及接下來 Art Pai 的場次後，有平復一些。

Mozilla 的場次很有意思，一般做手機的多螢幕是使用多個 user agent 或直接 mirroring，但是在 Firefox OS 上他們做的是單一 user agent 在不同螢幕顯示不同內容。

最後一場我聽 Paul Li 的場次講 frontend 的 BDD，講者真是太有趣了，滿滿的笑點讓我從頭忍笑到尾，但是演說的內容其實是很紮實的前端測試技術，聽完真的獲益良多。

繼續昨天的研究…。

• Developing Custom Language Plugins for IntelliJ IDEA – IntelliJ IDEA – Confluence
• Xtext – Language Development Made Easy!

初步看來就是要在平台內實作「近乎整個編譯器」。之前我知道 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] 這本電子書，並對照幾個編輯器專案，去驗證書中所說的開發概念與方法：

• Lime Text Editor
• Iota
• Rim

（我挑這幾個「使用比較現代的系統程式語言 (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 機制下傻傻為人作嫁？

這樣兼顧原創內容來源、推廣通路、讀者服務的想法，可行性有多高？