Monthly Archives: November 2014

最近遇到兩個專案的 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 曖昧未明的苦衷),卻能含括概念的譯詞。

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