北市圖現在有智慧館（無人服務圖書館）以及 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 換來極大的彈性：
先到這邊，之後想到再寫…。
敲邊鼓的某位仁兄認為，過去根本沒人在意 package 這個譯詞問題，言下之意，是我小題大作。
不過我確實覺得這是個問題。不管這對你而言，是個大問題、小問題，或根本不是問題，對我來說，因為我跟對方同樣在意「翻譯」這件事，所以至少我覺得，這是個問題。
回顧辯論過程中，我用錯方法，一直用舉反例的方式想要闡述「某某東西不是『軟體』」而將自己逼入死胡同。
是的，我再說一次，我學藝不精，誤解「軟體」的定義，這點被屢屢打臉，我服輸。
正確的思路應該是要問：
辯論過程中，使得我動了火氣的地方是：
即使我們在所謂「日常生活」中，也常遇到同一個名詞，有不同意義：
今天對方可能是將「套件」解讀為「放在包裝裡的整套物品」，所以推及「包裝不等於內容物」，是把「套件」想成 kit, set 之類的。
但是就我，以及我揣測的前人所下的這個「套件」譯詞，是 ‘packed ware’ 的概念。意即我前面所述，當我不能確信 ‘package’ == ‘software package’ 時，我寧願下一個或許沒那麼直觀（因為有 context 曖昧未明的苦衷），卻能含括概念的譯詞。
兩方想法全然不一樣，所以吵起來真的不意外。
實在很令人傻眼。
我翻一下「103 年公務人員初等考試試題」圖書資訊管理〈中文圖書分類編目大意〉，一股怒氣就從腳底衝到腦門。
MARC 是給程式設計用的，是給機器讀的，所以才叫做機讀格式。你拿來考考生，還是考幾乎不可能碰到系統開發工作的初考考生，是有什麼鑑別度？是要鑑別誰比較會背《中國機讀編目格式》嗎？還是要真正選才？
就算在編目的實務工作中，你也不會直接操作 MARC 資料，我再說一遍，MARC 是給程式設計用的，是給機器讀的，所以才叫做機讀格式。那每年一直考一直考一直考這些 MARC 的細節，到底有什麼意義？出題老師你真的有在做編目工作嗎？如果你真的在技術服務工作中每天每天都直接操作 MARC 資料，意即寫程式去算幾位元的欄長、資料長、去把資料抓出來，那我佩服你，我跪著把你鞋子舔乾淨跟你賠罪都沒問題；倘若不是，拜託，出一些有鑑別度的題目好不好？選一些真心有志於圖書館工作的人進公家單位好不好？救救我們的圖書館事業好不好？
之前寫過〈開啟 Android Emulator 的 GPU 硬體加速〉，但是偶爾還是會聽到社群朋友在抱怨 Android 本家提供的模擬器很慢，而去用其他一些第三方提供的加速模擬器，覺得很奇怪。
我對 Android 模擬器「夠快」的標準是，非高度要求「即時反應」（如遊戲、影音）、「一般」的 app 能夠跑得順，就算夠快了，而我自己設定正確的本家模擬器，是合格的。
Android 本家模擬器的硬體加速手段，其實可粗分成兩種：
所以，滿足手段 1 與 2 者能得到最好的效果；如果手段 1 很不幸地受限無法運作，至少手段 2 可以讓視覺感受上不會太過「卡頓」。
而今天我再度碰到同樣龜速的問題，發現 emulator 輸出錯誤訊息如下：
emulator: ERROR: Could not load OpenGLES emulation library: lib64OpenglRender.so: cannot open shared object file: No such file or directory
emulator: WARNING: Could not initialize OpenglES emulation, using software renderer.
原來是我將 Android SDK 的路徑改了，卻忘了更新 /etc/ld.so.conf.d/ 底下的設定檔，將 $SDK_PATH/tools/lib/ 改正後，就能回復使用手段 2。至於手段 1 如果硬體有支援、核心模組（如我使用的 kvm-intel）有正常啟動，本來就能正常運用。兩者搭配起來，不誇張，就像用實機一樣。但是我也實話實說，這些要安裝的軟體套件、要設定的東西頗多、頗雜，免不了小小折騰一下。