最近遇到兩個專案的 bugs

都是用 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 雜感

最近在公司開始用 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 曖昧未明的苦衷),卻能含括概念的譯詞。

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

國考圖書資訊管理類科,到現在還在考 MARC 幾段在幹什麼

實在很令人傻眼。

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

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

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

正確設定 Android Emulator 的硬體加速

之前寫過〈開啟 Android Emulator 的 GPU 硬體加速〉,但是偶爾還是會聽到社群朋友在抱怨 Android 本家提供的模擬器很慢,而去用其他一些第三方提供的加速模擬器,覺得很奇怪。

我對 Android 模擬器「夠快」的標準是,非高度要求「即時反應」(如遊戲、影音)、「一般」的 app 能夠跑得順,就算夠快了,而我自己設定正確的本家模擬器,是合格的。

Android 本家模擬器的硬體加速手段,其實可粗分成兩種:

  1. 使用 Intel x86 Atom System Image,那麼就可善用 CPU 的 虛擬化技術(如 Intel 的 VT)和 KVM 來使用電腦上的同質性硬體 (x86 <-> x86),大幅減少指令轉譯的成本,達成效能最佳化。
  2. 使用 Host GPU (即電腦上的顯示晶片)來加速圖形繪製,這個手法即使是使用非 Intel x86 Atom System Image 亦能受益。

所以,滿足手段 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)有正常啟動,本來就能正常運用。兩者搭配起來,不誇張,就像用實機一樣。但是我也實話實說,這些要安裝的軟體套件、要設定的東西頗多、頗雜,免不了小小折騰一下。

在 Cron 裡跑 (RVM) Ruby scripts

罕用,結果就是每次用每次忘…。

  1. 如果執行檔放在 system-wide 定義的 PATH 以外(= Cron 執行時使用的身分),就要指定絕對路徑,像是透過 RVM 安裝的 Ruby,或是在 crontab 裡載明 PATH。
  2. 如果使用 RVM 則要在 crontab 裡載明 RVM 專用的 GEM_PATH,否則就會爆 LoadError。
  3. 用 sh -c ‘target_cmds’還不夠,最好是用 sh -l -c ‘target_cmds’ 更不容易出包。

買了一把 WiNTEK ACK-230

DSC_1285

之前買了 Apple Wireless Keyboard,無奈還是不太習慣它的手感。這次換了新工作,主要的作業環境在 Mac OS X 上,我原先還是從善如流地使用 Apple Wireless Keyboard,但是幾天下來發現被「卡」到嚴重影響工作效率,心想不快點解決這問題不行。

對於這隻工作用的鍵盤,我列了幾個條件:

  1. 手感要好
  2. 不能太吵

針對條件 1,其實我可以把家裡的 Acer 6511 帶上來用,但是它的聲響還是可能影響其他人。

DSC_1287

至於市面上的黑軸鍵盤,高「貴」品牌的我買不下手,平價的 DK1087 缺貨,於是我再搜尋了「平價 好打 鍵盤」而找到 WiNTEK ACK-230。

簡單扼要的感想:

用過 Acer 6511 後,WiNTEK ACK-230 手感相比也只是落在 75~80 分而已,有點軟,但是也好過 Apple Wireless Keyboard。

不過後者真的比較安靜,在辦公室裡盡情 coding 也不怕引來側目,所以 ACK-230 還是買對了。

回家,在蘭陽觀光夜市吃晚餐

回來的路上,為了處理悠遊卡鎖卡問題,跑了一趟國光客運在宜蘭轉運站的櫃台。就順路(?)去蘭陽觀光夜市吃晚餐。一直覺得這個夜市的地點處在一個很尷尬的位置,交通動線很難讓搭乘客運的乘客經過,但是又位在居住人口較稠密的這一側,不過在地人又有多少是外食族呢?外食族當中又有誰會「吃巧而不求吃飽」的以小吃當正餐呢?

所以幾個月前跟國中好友來時,攤位還算多,此次來卻發現幾乎收了大半,冷冷清清,又門可羅雀,看了心裡實在覺得有點難過。

若要跟附近的東門夜市比較,這裡停車相對方便、有洗手間、非露天不怕雨淋,其實優點很多。

當下就想起了「あまちゃん」劇中主角回到災後的故鄉,心想是不是可以做點什麼。

吃了一碗很好吃的蚵仔麵線,再點一份蔥餅,填了一點肚子後,有點悵然地離開這裡,繼續歸途。

RTL-SDR 軟體無線電 (Software-defined radio)

偶然得知 Realtek RTL2832U 這顆 DVB-T 訊號處理晶片,搭配適當的 tuner 晶片,可以拿來做軟體無線電,也就是所謂的 RTL-SDR。看了別人寫的〈2013-09-17 廉價的Realtek RTL2832U軟體無線電〉就忍不住也去 eBay 買了一組 RTL2832U+R820T 的產品。

沒想到從香港賣家(我猜實際所在地是深圳…)發貨後到我手上,竟耗了兩個月又一週,中間我還在 eBay 提出申訴而獲得退費,實在烏龍。在收到貨後緊急聯絡賣家,補匯款給他們。真的不知道在今日,平郵過個黑水溝還會耗這麼久,好像回到了古早古早的時代。

IMG_20140501_194151

一開始我使用 RTL-SDR 附的命令列介面工具 rtl_fm 來接收訊號,實在是…不太好用,所以又去找 GUI 工具來用。

SDR# 在我的 Arch Linux 上,需安裝 PulseAudio 才能正常使用,功能也不錯,偏偏使用 Linux 的各位應該都知道,PulseAudio 製造的麻煩比解決的問題多,所以我只好再物色其他的選擇。

於是我又找了 Gqrx 來用。其實更早之前我是想先試 Gqrx 的,只是看到需要安裝的相依元件那麼多,就心生抗拒、退避三舍。後來實際動手才知道,其實沒有現成 Arch 套件、得要我手動安裝的,只有 gnuradio-osmosdr,而事實上這已經有熱心人包好的 AUR。所以在我稍微兜個小圈子,把 Gqrx (特別指定禁用 PulseAudio)編譯出來後,就有一個不錯的 GUI 可用了。

天線還是收訊的最重要因素,隨附的小天線大概只能收幾個訊號還算強的 FM 廣播。用自製的四菱形天線,則可順利收到更多電台,還很勉強地聽到一個一般民眾對話的頻道。

接收設備的參數設定則是其次,要把硬體自動增益 Hardware AGC 打開,還有依訊號品質情況設定 Filter 的寬窄幅度。

接下來我想去借或買一根木瓜天線來試試看,能否聽到更多頻道,還有收氣象圖傳真。

Ruby & Arch Linux Taiwan 陶瓷吸水杯墊設計稿釋出

Ruby & Arch Linux Taiwan 陶瓷吸水杯墊

會知道有這種陶瓷加值產品,是因為看到漫畫家漢揚貼的訊息,查了一下,並不貴。訂製後收到成品,發現印刷品質很好,業者交貨速度也很快,還可以推廣在地陶瓷,所以就接連製作了兩批 Ruby & Arch Linux Taiwan 的。Ruby 的都拿來送給社群朋友,包括在這次 RubyConf Taiwan 2014 親手送給 Matz さん。Arch Linux Taiwan 的則先採小量團購方式給社群朋友各自認購。

陶瓷吸水杯墊原稿採用 InkScape 設計,輸出為 SVG & JPEG,在此釋出,供大家自由使用。

為避免廣告嫌疑,在此恕不貼出我接洽的廠商聯絡方式,敬請見諒。