對於這種我以為會 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 時就做掉。

習得教訓：「本機上明明就可以，為什麼搬到部署環境上就不行了？」就是推託、就是偷懶。

最近在公司開始用 Docker。之前請過 Carl Su 來講 Docker 簡介，但是實際採用還是最近這幾天的事。

實際去用才會知道 Docker 箇中奧妙，不然看再多文章、再多書、聽再多夶演講，都還是會墜入五里霧中摸不著頭緒，也很容易因為用慣了典型的虛擬機，使得觀念轉不過來。

對於用過 FreeBSD 的人來說其實很好懂，因為很像當中的 jail。如果沒有用過，則我想到最簡單的譬喻，應該就是去唱卡啦OK吧：

你以為全世界都可以聽到你唱歌（你以為自己在一個完整的系統下執行），

實際上只有包廂內的朋友聽到你唱歌（但其實你是被一個 Docker 容器給隔離），

另一個房間裡的別人也聽不到你，他唱分手快樂、你唱愛我別走，兩個人不會打起來（除非經過特別設定，否則一個個容器各自獨立），

你以為你有自己專屬的全套視聽設備，但是點歌系統其實是卡啦OK業者建設的，讓你們連線共用（Host OS 資源透過 Docker Engine 調度給容器共用）。

如果這個譬喻很爛，請再隨意吐嘈我沒關係。反正最近我的自尊心與羞恥心已經低落到比馬里亞納海溝還低了。

實作時拿了 Fluentd 來打包，這一點就讓之前的我，以及諸多還不理解 Docker 的人覺得奇怪，如果照官方提供的安裝方法，其實沒有必要這樣「折騰」。何況在之前我已經用 OpsWorks (+ Chef) 寫過自動安裝的 cookbook recipe，照理講直接裝到機器上應該很快很方便，為什麼還要這樣重新發明輪子？

原因就在於 Docker 換來極大的彈性：

• 我依舊可以搭配 OpsWorks 用，事實上我為了要在 OpsWorks 上的 Ubuntu 14.04 AMI 上用，還特別寫了一則 recipe 去新增 Docker 官方的 repository 來安裝新版。
• 如果哪天我不想用 OpsWorks 了，我還是可以帶著我的 Dockerfiles, Docker images 直接叛逃、無痛轉移。
• 不同專案會有不同的 Fluentd 設定，甚至同一個 layer 底下不同的 instances 都可能會有不同的設定，在 OpsWorks 上做起來實在很阿雜，但是配合 Docker 之後，只要管好「不同的地方，載入不同的 Dockerfile，在已有的 Fluentd base image 上再用 ADD 把專屬的設定疊上去，做出一個特用 image 就好」。
• Docker 測起來很快，實務上跨 Mac (Boot2Docker) 與 Linux 開發也不覺得阿雜。用簡單一個字表達的話就是「爽」。

先到這邊，之後想到再寫…。

敲邊鼓的某位仁兄認為，過去根本沒人在意 package 這個譯詞問題，言下之意，是我小題大作。

不過我確實覺得這是個問題。不管這對你而言，是個大問題、小問題，或根本不是問題，對我來說，因為我跟對方同樣在意「翻譯」這件事，所以至少我覺得，這是個問題。

回顧辯論過程中，我用錯方法，一直用舉反例的方式想要闡述「某某東西不是『軟體』」而將自己逼入死胡同。

是的，我再說一次，我學藝不精，誤解「軟體」的定義，這點被屢屢打臉，我服輸。

正確的思路應該是要問：

1. 如果有個 ‘package’ 單字放在 package management 的 context 裡，而不是 ‘software package’，面對這個 context，你在當下，只看到 literal 的資訊，是否能斬釘截鐵地確信 ‘package’ == ‘software package’  而堅信選用「軟體包」的譯詞是適當的？
2. 你會不會犯了過度推論的邏輯問題？
3. 前人如果考慮到 context 可能有的曖昧、模糊，用「套件」這個較為中性、泛指的譯詞，來試圖含括 package 的「概念」，是否就真如你認為的那般不合理？

辯論過程中，使得我動了火氣的地方是：

1. 對方一開始不論青紅皂白，直覺認為我只是「不習慣」。
2. 對方以自己的一套理論，認為「套件」這個詞不能與「包裹」的意義互通，而質疑始終堅持「套件」譯詞妥當的我有問題，認為如果我在日常生活中也把一箱箱、一包包的東西叫「套件」，那他沒話講。

即使我們在所謂「日常生活」中，也常遇到同一個名詞，有不同意義：

1. 平面設計、印刷的「出血」；醫院急診室的「出血」
2. 新聞台的「採訪」；圖書館辦公室的「採訪」
3. 雜誌社的「標題」；圖書館辦公室的「標題」
4. 使用軟體時的「物件」；買賣不動產的「物件」
5. 小市民說的「機構」；做電腦、手機硬體設計的「機構」

今天對方可能是將「套件」解讀為「放在包裝裡的整套物品」，所以推及「包裝不等於內容物」，是把「套件」想成 kit, set 之類的。

但是就我，以及我揣測的前人所下的這個「套件」譯詞，是 ‘packed ware’ 的概念。意即我前面所述，當我不能確信 ‘package’ == ‘software package’ 時，我寧願下一個或許沒那麼直觀（因為有 context 曖昧未明的苦衷），卻能含括概念的譯詞。

兩方想法全然不一樣，所以吵起來真的不意外。

實在很令人傻眼。

我翻一下「103 年公務人員初等考試試題」圖書資訊管理〈中文圖書分類編目大意〉，一股怒氣就從腳底衝到腦門。

MARC 是給程式設計用的，是給機器讀的，所以才叫做機讀格式。你拿來考考生，還是考幾乎不可能碰到系統開發工作的初考考生，是有什麼鑑別度？是要鑑別誰比較會背《中國機讀編目格式》嗎？還是要真正選才？

就算在編目的實務工作中，你也不會直接操作 MARC 資料，我再說一遍，MARC 是給程式設計用的，是給機器讀的，所以才叫做機讀格式。那每年一直考一直考一直考這些 MARC 的細節，到底有什麼意義？出題老師你真的有在做編目工作嗎？如果你真的在技術服務工作中每天每天都直接操作 MARC 資料，意即寫程式去算幾位元的欄長、資料長、去把資料抓出來，那我佩服你，我跪著把你鞋子舔乾淨跟你賠罪都沒問題；倘若不是，拜託，出一些有鑑別度的題目好不好？選一些真心有志於圖書館工作的人進公家單位好不好？救救我們的圖書館事業好不好？