修好了 fcitx-chewing

每次輸入法壞掉,我在電腦前、網路上就近乎啞了一樣。上次修好 ibus-chewing 前,我用行列輸入法一個字一個字慢慢拆,還是不若使用注音輸入法流暢,現在臨時要我用行列,我除了基本十訣還有些模糊的印象,也早就忘光光了。

這次因為 libchewing 0.4.0 改了幾處,fcitx-chewing 果然如我預料的也壞了,我又用輕鬆輸入法搭配拼音輸入法一個字一個字慢慢拆、慢慢拼。輕鬆輸入法真的好學不易忘,我覺得最大的缺點就是它用了四排鍵來定位字根,造成選字麻煩。而這個問題我想在觸碰面板裝置上反而不是問題,如果我更進一步能在 Android 上實作一個可自動選字詞的輕鬆輸入法,我爹以及千千萬萬個不習慣注音符號、漢文素養卻不差的長輩,用起來應該會很高興。

對於不是很慣 C 的我來說,要修好輸入法不像慣 C 的夶們那麼簡單,但是秉持著「自己的輸入法自己修」精神,我還是硬著頭皮、用我程度相當彆腳的 C 與 GDB 知識去修。

上次修 ibus-chewing 時,非常幸運地用 GDB 加上人腦 debugger,在主程式一開始沒幾行就抓出型別錯誤問題,順利把 bug 解掉,後來從 iBus 跳到 Fcitx 輸入法框架,則一直開開心心地在之上使用新酷音、Anthy 分別處理中、日文輸入,沒遇過什麼問題。

而此次 fcitx-chewing 我依照編譯時的錯誤訊息,分別停用 chewing_Init(), chewing_Terminate() 以及把 chewing_zuin_String() 改用 chewing_bopomofo_String_static() 後,還是無法使用新酷音。

在這中間我翻了 libchewing 本身的文件、測試案例,不得不說 libchewing 到後來漸次補上的這些測試案例寫得很棒,是很好的新酷音實作參考範例;還翻了 fcitx/developer-handbookfcitx/fcitx-templates,幾乎把整個 fcitx-chewing 逐行審核過,收穫之一就是大概瞭解了在 Fcitx 之下如何實作一個輸入法。

我發現程式在 chewing_new() 這邊就已經未正常產生一份 context,遑論後續的操作。交叉測試之下,才發現是 userpath(使用者詞庫目錄)參數在我電腦上出了詭異的問題。libchewing 0.4.0 新增使用 SQLite 資料庫來維護使用者詞庫,而我的 userpath ($HOME/.chewing/) 底下原本該有一份 chewing.sqlite3 資料庫檔案,卻被生成為一個目錄,導致 chewing_new() -> chewing_new2() 根本無從處理,只好傳回 NULL。於是我手動移除 $HOME/.chewing/ 讓 libchewing 重建,終於讓 fcitx-chewing 可以正常運作。

我後來又翻了 libchewing 想要重現這個問題,卻怎麼也找不出問題所在,無論是 GetDefaultUserPhrasePath() 還是 InitUserphrase() 看起來都很正常,只好先擱置了。

幾個 MySQL 跳 PostgreSQL 的心得

我的 DBA 程度很遜(好吧,因為我樣樣都沾一點醬油,所以樣樣都很遜),這篇請不要期望有太多有營養的東西。

真正開始轉用 PostgreSQL 是因為它的 ltree 實在太好用,由於我的工作緣故需要能高效處理一個巨大階層樹結構(也就是物種名錄)的機制,而 MySQL 的解決方案我都覺得太迂迴、太阿雜,所以在我看到 ltree 之後,我就改投 PostgreSQL 麾下了。

我對各個 taxon 名稱予以 MD5 編碼後,再將階層存成 lable path,並建好索引。這樣處理一份有數十萬筆 taxa 的資料集,要找出任一 taxon 之下的全部子 taxon,在 PostgreSQL server 經過適當參數設定調校的環境下(見後述),瞬間就可得出結果。我當然是非常滿意。

之後我又用了 JSON 資料類型存一些 hash, array 的資料,發現我幾乎可以將 PostgreSQL 當作 MongoDB 的同質替代品來用,且沒有 32-bit 的最大容量限制,在我這裡迫於各種(我不知道的)因素未能安裝 x86-64 Linux 的伺服器,也能受惠於 JSON 式資料表述法的便利性。

一開始我用 MySQL 的觀念來用 PostgreSQL 當然是常常碰壁,譬如認證、權限系統的差異,譬如資料庫到資料表間還有層 schema。但是透過 pgAdmin 的輔助(如同 phpMyAdmin 在 MySQL 上的管理工具一哥/一姐地位),還有 PostgresSQL 明確的錯誤訊息以及詳盡的文件,適應也只是幾天內就搞定的小問題。

比較難的反而是當初要跨過自己設下的、懷疑是否真有必要「重複學習另一套資料庫軟體」的心理門檻。

至於效能,把 shared_buffers, temp_buffers, effective_cache_size 這三個預設值實在太過保守的參數調高,立即就拉上來了。這還是我在 ASUS EeeBox B202 開發機上 (Intel Atom N270, 2GB RAM) 跑出來的表現,拿到 production 的伺服器上跑就更猛了。

剝奪

睡前才在 Twitter 上感嘆最近職場上的際遇、頹廢的自己對脫離困境的裹足不前,就做了惡夢。

夢到自己太過散漫,背包在少人搭乘的公車上離身亂放,被扒手扒了。營生的家當、工具被洗劫一空。原本為了打算去報名進修課程而辦的信用卡,也連帶遭殃。悲從中來,痛哭失聲。背景音樂竟還很清晰地配上王靖雯的「棋子」。

家母與街坊阿姨笑我哭得太誇張,彷彿在暗喻說,沒了電腦我就什麼都不是,你看長輩們過去做什麼事情,只要不違背天理、違背法律,都是撐起一家的技能。事實上的我會的東西其實很多,不單是電腦(或者說,不單是受人輕蔑、勞動成果看量不看質的碼農),何苦這樣哀傷?

臺灣寓言:蘋果與拼果(四)

老闆:都已經快到發表會了,你到底還要搞多久,你看隔壁老王多勤快,隨時都有工程樣品可以讓我知道有什麼東西做出來了。

宏:可是工程樣品到實際產品還有很多地方要調整,像這個用飛線改的線路,到時磁檢一定不會過的,而且我不可能要使用者去用這個這麼奇怪的接頭…

老闆:喂!

宏:啊?

老闆:媽哩個連夢露咧,要你做事你意見一直這麼多,卻沒看到你做什麼東西出來。這樣品在我看來已經可以上市了啦!

宏:等一下,老闆,這個還不行。

老闆:不行?我偏偏要行。這家公司多你一個人根本沒差啊,東西也沒有做得比較快,我到底找你來幹嘛的?

宏:(回到辦公桌,望著自己做出來的、省力但牢固的接頭樣品乾笑)

臺灣寓言:蘋果與拼果(三)

亞太區研發處處長:我聽說你們正在開發一台新款電腦,生產線好像跟我們研發處開發的「呷熊霸」都是同一套系統,這樣你們要不要用看看「呷熊霸」?

宏:這個…我們的…

亞太區研發處處長:你看,底層系統都一樣,用起來一定沒問題啦!

老闆:對啊對啊,這個系統都是一樣的,喂,你去用看看!

宏:可是我們的材料比較特殊,生產線就算要用一樣的系統,到時也要大改…

老闆:啊反正就可以用嘛!你現在是在這邊浪費我時間喔我多請一個工程師來做事要多一個人的錢你知道嗎?

亞太區研發處處長:對啊,而且這套生產線還有那麼多現成的擴充模組可以用,這樣我們搞不好還可以拿去北美區、南歐區用喔!

(一個月後)

老闆:啊那個「呷熊霸」到底可不可以用啊我們要做的這款電腦到底要做多久?

宏:我覺得還是很多地方沒辦法通用,所以最後還是拿比較原始的系統來做。

老闆:你這樣我怎麼跟處長交代?你這樣我怎麼跟處長交代?

宏:………(現在是把電腦做出來重要,還是花時間去改一個生產線系統來削足適履重要?)

臺灣寓言:蘋果與拼果(二)

老闆:工具、材料都在這裡,沒有多的了,你趕快幫我做出一台像那個什麼蘋果的電腦出來,不要花那麼多時間去研究那些有的沒的,做就是了。

宏:呃,為什麼這隻明明是扳手,這裡卻叫它起子?這個工具是要怎麼用啊?沒有說明書嗎?

老闆:沒有!你工程師耶不會自己用看看喔你現在是在這邊浪費我時間喔我多請一個工程師來做事要多一個人的錢你知道嗎?

宏:………

宏:好~~~的,我用看看。這裡的毛邊沒修好,會刮傷人,我修整一下好了。

老闆:你現在是在這邊浪費我時間喔我多請一個工程師來做事要多一個人的錢你知道嗎?

宏:這個按鈕應該是自爆裝置、那個按鈕應該是叫外賣的,我都貼上標籤,不然以後按錯把公司炸掉怎麼辦?

老闆:你現在是在這邊浪費我時間喔我多請一個工程師來做事要多一個人的錢你知道嗎?起子拿來啦!

宏:起子。

老闆:我咧幹~~~什麼啊,我說的起子是在說那隻扳手啦!你來公司多久了還搞不清楚狀況啊?

臺灣寓言:蘋果與拼果(一)

老闆:昨天我看到一台那個什麼蘋果最近出的 PowerMac,真不錯,我想我們也可以來做一台那樣的電腦來賣。

宏:好啊,我先研究一下他們是怎麼做這台電腦的。喔喔喔,拆開側版不用螺絲起子、內部的走線好俐落,這設計真…

老闆:喂!

宏:啊?

老闆:我叫你去做一台這樣的電腦,你浪費時間看那些東西幹嘛?

宏:可是我要知道他們是怎麼做的…

老闆:哇靠!就抄嘛!外觀像、可以開機可以動、我對董事會可以交差說我們做了一個像那個蘋果的電腦出來,就好了啊,你現在是在這邊浪費我時間喔我多請一個工程師來做事要多一個人的錢你知道嗎?

宏:可是我就算要抄也得知道他們是怎麼做的…

老闆:我咧幹~~~什麼東西啊?材料去光華商場找一找回來組一組就有了,滿街都是會組電腦的阿宅,怎麼我偏偏請到你這個毛病特別多的?

宏:可是這樣做出來的東西,就只是一台普通的組裝電腦啊。

老闆:是!我就是要組裝電腦!到時候找個機殼廠幫我仿一個類似那個什麼蘋果的外殼,像就好了啊!喂!你到底是在龜毛什麼?

關於 “Open” 這件事

昨天在 MozTW Lab 臺北場採訪 MozTW 社群聯繫人 Irvin,席間可能是因為我們談到 Mozilla FoundationMozilla Corporation (MoCo) 的差異,以及我名片上印著「開放標準推動者」,引來了另一位 MoCo Taiwan 朋友以及 littlebtc 加入討論「關於大家各自認知的『開放』是怎麼一回事」。

因為我當場忘了基本禮數,請教這位長輩尊姓大名,所以在此容我以「MoCoTW 君」稱之,並請注意在此這只是代稱該位長輩,請不要誤會我上綱到 MoCo Taiwan。

我的立場是,基於我的 Library & Information Studies/Science 的專業,其實我近年來漸漸由高中開始信仰的 Free Software(自由軟體)往 Document Freedom(自由文件)「雙修」。我意識到如果光打著 Open Source 名號、沾 Open 的名聲,卻做一些封閉介面的產品,把使用者生產的各種數位資訊鎖著,表面上你用得開開心心,實際上你卻是個奴隸,且是個自我感覺良好的奴隸,那並不符合我對資訊自由、平權的正義觀。

MoCoTW 君在最後問我說:「假設某廠商做一套不管是開源還是私有軟體,但是他們皆有公開這軟體產出的檔案格式,不過卻經常、頻繁地改動,這樣的『開放』是我可以接受的嗎?」我基於一個 Librarian(再重申一次,我不喜歡「圖書館員」這個因襲下來的譯詞,而比較愛用符合其本質定義的「資訊看守」之類稱呼)的專業,表示當然可以接受,因為如果該廠商確實以明文且有效的授權條款,開放這個檔案格式,那麼我在任一處資訊機構(包括狹義的「圖書館」)只要用到這個檔案格式,我都可以安心使用。我不用擔心這個廠商哪天倒了,或是後續服務愛理不理,影響我機構內使用這個檔案格式儲存的資訊的存取,我可以保證只要我遵循這個檔案格式定義去寫「解碼程式」,我都可以完完整整、毫無漏失地把檔案讀出來,再做後續處理、利用,且這樣的解碼行為,不會無端惹訟。

這樣的數位典藏,我以為才算是真數位典藏。

而 MoCoTW 君會這樣問我,可能是因為我與 Irvin 在談論 Mozilla Foundation 與 MoCo 的差異時,言談之間讓他認為我們帶著反商情結去看 MoCo 在做的事情,接著帶到 Linus 對 Linux 的 GPL 版本選用、Google 對 AOSP 的「開放」方式等例子,想要表達「現實是這些在授權方式上、手腕上、作法上的妥協,才使 Open Source 的商業化有活力,極端如 FSF 者光靠推『理念』並不能當飯吃」 。廠商如果遵循遊戲規則(授權條款)做事,可能依授權條款沒有義務一定要 Open Source,而就算照規則得 Open Source,也沒有義務要維護「Open Source 出來的那(個、些)版本」,在商言商,如果廠商確實照規則來做事,就不應該再受到道德上的批判。

關於這點,從近期 Mozilla Firefox 在討論 new tab directory tiles 要放網站廣告的爭議例子,可以看到說,如果「投放網站廣告」要追蹤績效,就可能勢必要「追蹤使用者行為」,站在 MoCo 必須營利來經營下去的立場,以及 Mozilla Foundation 堅持捍衛隱私權理念的立場,就會有所衝突。同樣的,MoCo Taiwan 推出的 Firefox 臺灣版事件也有類似的爭議。

那麼,Mozilla Foundation 這邊的 Mozillians 所批判的,是 MoCo 這邊對理念的妥協、棄守,而不是針對追求營利這件事。如果 Mozilla Foundation 必須藉著 MoCo 把理念打折來維持,那麼 Mozilla Foundation 就只是為了存在而存在,而不是為了其堅守的理念而存在。其他公司可以把 Do No Evil 之類的口號可能只用來妝點形象,而 Mozilla Corporation 的成立初衷讓它沒有任何餘地可以賴皮,至少必須面對 Mozilla Foundation 的檢視。

進一步推回前幾段的「照規則來 Open Source,就不該再受到道德上的批判」這點,如果今天 Firefox 有個功能是會侵害隱私權的,那麼就算開發者將該功能的 source code 完完整整、毫無保留地照授權條款 open 出來,這只能滿足「你確實照規則來做事」這點,但是並不表示「你這個功能是符合 Mozilla 信念的」。

(以上是我個人的想法記錄整理,不代表 MozTW)

買了 Apple Wireless Keyboard 2011 日本 JIS 版暨第一次送 Linux kernel patch 就失手

DSC_1155

因為在辦公室使用的 Ducky 1087 機械式鍵盤,聲響屢屢受到同事側目(特別在我碼得特別來勁、或遇到解不掉的 bug 時),所以決定忍痛賣掉,這裡說的忍痛不只是心痛,還有左臂長期以來的疼痛。無論如何,我還是需要一個方便工作、好打(或至少不難打)的新鍵盤。

然後我調查了一下,扣掉會吵到、嚇到人的機械式鍵盤,符合「方便工作」、「好打」條件,再加上「不要 100% 大小」、「我負擔得起」的款式,其實沒多少可選,於是我就買了 Apple Wireless Keyboard(2011年版)。

照片上有兩「片」鍵盤,沒錯。家裡的 Mac mini 搭配的 Apple Pro Keyboard 在經年累月的耗損之下,也愈來愈會卡鍵、愈來愈難打了,所以一不做、二不休,一次買兩片,宜蘭、臺北兩處用。因為網拍上有很便宜的日本 JIS 式排列版鍵盤,而我本身對日文打字還是有一定程度的需求,所以 JIS 式排列版鍵盤對我來說算是實用。

Mac mini 搭配 Mac OS X 用 Apple Wireless Keyboard 當然是沒有問題的;但是我平日使用的主力 ThinkPad X230i / Arch Linux / KDE 則不免需要折騰一下。

雖然它看似可以被 Linux 正常驅動,但是很奇怪的就是 ‘fn’ 鍵沒有作用,這代表我無法使用 fn 鍵搭配四方向鍵操作 Home, End, Page Up, Page Down。

我追蹤了一下問題成因,利用 bluetoothctl 掃描硬體資訊,發現 hid-apple 模組並未納入 Apple Wireless Keyboard 2011 的 JIS 版,也就是廠商代號 (vendor ID) 0x05ac (Apple)、產品代號 (product ID) 0×0257 不在其中,所以針對 fn 鍵的程式碼未能正確套用在這款鍵盤,這款鍵盤被 Linux 當成了一般的藍牙鍵盤來驅動。

於是我把缺少的幾行程式補上去、證實可以正常使用 fn 鍵之後,開始了我跌跌撞撞的送 patch 歷程。

一開始我跑到 Linux kernel 的 Bugzilla 系統去回報,卻沒有看清楚這是給 mainline 使用的,在上面回報 3.12.9 的問題,一開始就錯了,而我沒有確實讀過 Documentation/SubmittingPatches 文件,沒有照正確的格式、方法,只是憑著「我找到解法了」的小屁孩樣的熱血、如無頭蒼蠅般亂竄,還被 Alan Cox 大神回以簡短一行提示,實在是很慚愧。

接著我改往 linux-input mailing list 上面送 patch,無奈可能還是因為不得要領,過年這幾天還是見不到我的 patch 被維護者 review 的跡象。

於是我跌跌撞撞地反覆修正我的 patch,最後才發現使用 git format-patch 搭配 git send-email 是最簡單省事的。畢竟 Git 原本就是為了維護 Linux kernel 而生的。

用 Git 從 The Linux Kernel Archives 抓回 mainline (此時是 3.14-rc1)的 source code 後,先 git checkout -b apple-hid 用一個新的分支來修問題。

把問題修好後,commit 異動,此時編輯 commit message 請記得遵循規定格式。第一行會被當成 commit 的標題,請照類似這樣的格式寫:

HID: Add Apple wireless keyboard 2011 JIS model support.

開頭要標明這份 patch 是屬於哪個子系統 (subsystem),譬如我這次送的問題是屬於 HID (Human Interface Device) 子系統,就要確實標明。

跨一行後,敘述此 commit 的主要目的、功用等說明。這會被當成 commit 的內文

Commit 完成後,就可以使用 git format-patch –stdout –signoff master 先以螢幕輸出檢查這份 patch 信件(是的,git format-patch 此指令會輸出一份標準的 Unix mail 格式文件)是否確實遵循規範,如果有錯誤,則可使用 git commit –amend 回去修改 commit message。

確認無誤後,則使用 git format-patch –signoff master 正式輸出 patch 檔,檔案會以「流水號-標題.patch」的格式命名。

接著請先跑過 scripts/checkpatch.pl 檢查剛剛產生的 patch 檔還有沒有嚴重的格式問題,再跑 scripts/get_maintainer.pl 找出此次回報 patch 時,應該送給哪個 maintainer、送到哪個 mailing list。接著可以去 subscribe 該 mailing list 取得發文的權限。

然後就可以用 git send-email –to <mailing-list-email-address> –cc “maintainer-email-address” –smtp-server <smtp-server> –smtp-user <smtp-user> –smtp-pass <smtp-pass> –smtp-encryption <smtp-encryption> <patch-filename> 把 patch 送到 mailing list 並寄送副本給剛剛從 get_maintainer.pl 得知的 maintainer。

我今晚照這個流程跑,maintainer Jiri Kosina 在幾分鐘內就回覆我格式還有點小問題、需要再改,而我修正之後重發,接著剛剛就被接納了。往後,這款鍵盤在 Linux 上就可以爽爽用了,而我也因此機緣學會了送 Linux kernel patch 的方法,非常高興。

WhosCall 退費事件

一開始聽到這個消息,我很惱怒。

然後讓我想起了,約一年前看過的公視除夕賀歲大戲「穿越 101」(於 YouTube 收看)。片中陳漢典飾演的主角子超,窮途潦倒到不得不偷便當止飢,卻被之前因為相信神諭而積極幫助過的資源回收婆婆(周遊飾)撞見,教誨「人付出就要有收穫」

一個五百元的軟體,幫我擋掉了也許是惱人的推銷、也許是會損失五千、五萬、五十萬甚至更高額的詐騙,我覺得非常值得、簡直是超值,並且他們 (GOGOLOOK) 做的很好,WhosCall 無論在功能、效能、UI/UX 都是我用過臺灣產的、最好的 Android 工具軟體。

最後我能做的,就是給他們留個訊息,加油打氣,並且講明了,我可不會去申請什麼退費。因為我覺得,五百元支持一間認真做出好產品的公司,還嫌太少了。

如果付出沒有相對應的合理收穫,誰還要努力做事情?