Posted on
by

最近已經不太貢獻時間到 Debian 計畫中，雖然日常工作、辦事還是全部使用 Debian GNU/Linux。做的比較多的大概是幫忙踩地雷，跟偶爾回報一些自己常用軟體的小問題。

相較於商業軟體軟體，在自由軟體或開放原碼社群，最棒的使用經驗就是如果你碰到了甚麼問題，而且你描述得當的話，通常有機會得到開發者的注意與修正。但是你得「描述正確」。作為一個嘴砲開發者，我不甚喜歡收到毫無意義的回饋，過度熱情的回報人往往造成小開發團隊的極大困擾，數量跟質量往往成反比，而低質量的大量回報只會降低團隊士氣跟產能。如果可以的話，我希望可以收到許多高質量的回饋，也期許自己盡力這麼作。

這裡不談基本的回報問題的方式，你若用 Debian 請參考 How to report a bug in Debian using reportbug 或 reportbug-ng，使用 Ubuntu 請參考 ReportingBugs。你若是新手，在你回報問題之前應該先讀 Simon Tatham 的如何有效地報告錯誤。這篇文章提供了一些基本的原則，你若碰到軟體使用的問題，應該試著按照文中的原則跟軟體開發者對話，可以避免殺死太多開發者的腦細胞，也可以幫你快點解決問題。

在先進的軟體中，不少已經內建 Crash reporter，像是 Gnome 的 Bug Buddy、Mozilla 的 Breakpad、Ubuntu 的 Apport 等等，這些工具會在你的軟體當掉時，自動收集一些系統資訊與程式狀態，並回報、收集到中央系統。這些資訊可以協助開發者收集一些技術性的資料，比「我的程式當掉了」這種回報更容易辨別錯誤所在。不過這些資訊只能提供一般性技術資料，並不方便作為直接除錯使用，大約可以利用於統計、分析軟體穩定性等加強軟體品質的用途。

若你恰巧不幸是軟體工程師，你可以試著利用 gdb 等試著收集更多資訊，甚至先進行初步的偵錯。但是我知道要求一般人重新編譯軟體加上除錯資訊等，再開啟暗黑 gdb 視窗下指令除錯，實在會嚇跑一些曾經習慣在其他平台只用 IDE 開發軟體的朋友。事實上，在 Debian 中還是有些工具可以讓你快速的進行軟體除錯，而且也有比較友善的工具可用。

你若要除錯，第一部大概是取得除錯資訊，預設的 Debian 套件是不含除錯資訊 (Debug symbols) 的，因為大部分的使用者不需要這些特別佔用空間的檔案。許多資深的 Debian Developer, 都會分別在包裝的套件時加上 Debug package，於是你可以在不重新編譯軟體的狀況下拿到同版的除錯訊息。 這些除錯套件的命名原則都是以 dbg 為結尾，例如以 Lifera 為例，你可以安裝 liferea-dbg。

另外你也需要原本的程式碼，這點可以直接利用  apt-get source 指令取得，例如以下指令，系統會自動抓回你目前安裝版本的原始檔，並自動解開。
apt-get source liferea

而除錯時，你需要一個除錯工具，上述提到了 gdb 這個工具，對一些朋友說，熟悉指令的學習門檻似乎有點高，不過你若熟練 gdb 的使用技巧，可以直接利用其強大的 sciprt 功能進行許多自動化的測試或對程式直接插入命令。有機會還是應該學習一下。圖性化的使用介面亦有相當多選擇，像是 ddd 或是 KDbg 等。這裡推薦一下 Gnome 中新的工具 nemiver，若你曾經用過其他除錯工具，大概看到 nemiver 的介面就知道該何使用。它基本上就是原始碼閱讀工具加上 Call Stack, Variables, Breakpoints, Registers, Memory 等觀看與編輯工具，圖形介面非常簡單直覺。

這裡以 liferea 為例子，若你想對其除錯，可用以下指令，使 nemiver 載入 lifera 擺在 /usr/lib/debug 的除錯資訊。nemiver 會詢問你原始檔位置，你可以將其指到剛剛利用 apt-get 下載的原始碼目錄，這樣便可以一邊除錯一邊閱讀其程式碼或設定除錯點 (Break points)

LD_LIBRARY_PATH=/usr/lib/debug nemiver liferea

畫面會像是

nemiver

快快樂樂來抓蟲吧。

Posted on
by

先前裝了 HelloTxt 的 Ubiquity Script 來用，以便於可以在 Firefox 中直接用 Ubiquity 介面來更新自己的狀態到多個微網誌。不過 Hellotxt 的 script 是針對早期 Ubiquity 版本所撰寫，因此在 0.5 版釋出後，原 Script 不相容於新 Parser 2 API，因此幾個月前就無法使用了，官方也一直未修正。於是自立自強的依照 Parser 2 API Conversion Tutorial 修正一版，可於此網址安裝或下載 patch。

自己已經用了 Ubiquity 一陣子，目前使用經驗良好，值得推薦給你使用。但網路上介紹已相當多，除了 Mr6 的「開啟比 Google寬一千倍的路」目光短視的膚淺廢話不要浪費時間之外，其他的使用面介紹都可參考。這裡就不多費唇舌，你想了解基本的使用方法可以參考 Ubiquity 0.1 實際操作過程的精彩影片示範一文。

若可聽讀英文或日文，可讀 mitcho 在 Tokyo 2.0 的精彩演講 Ubiquity: Command the Web with Language 言葉で操作するWeb (簡報)，mitcho (Michael  Yoshitaka  Erlewine) 現在是 MIT Department of Linguistics 博士生，之前在 Mozilla Lab 擔任研究員開發 Ubiquity。

Ubiquity 的指令與功能極多，逐一介紹極耗時，請安裝後利用 list ubiquity commands 指令取得各項功能說明。

自從新版的 Ubiquity 的 Mozilla Web Search Commands 整合了 Firefox 的 Open Search 功能後，我就可以直接用 search 指令查詢自建的 Open Search Plugins。過去雖然依照自己的需求建立了十幾個不同的 open search plugin 來找不同的郵遞論壇、BTS、搜尋引擎、拍賣等，但是用滑鼠切換搜尋引擎絲毫沒有可用性可言。

新版的 Ubiquity 可讓你利用鍵盤快速搜尋所選文字，而且常用的指令會排序再前頭，也可以直接選擇文字後透過滑鼠右鍵執行該指令。因此除了內建的 IMDB, Wikipedia 外，我自己最常用得就是 amazon, aNobii, FindBook, 博客來、臺北市立圖書館館藏間互查書籍，一邊在 aNobii 規劃書單，一方面在不同的地方查詢藏書。

過去查詢一本書，你得「複製」、「開啟新頁」、「連上特定網站」、「貼上」、「搜尋」等幾個步驟，現在一樣是選取可以直接用右鍵選擇該服務，或者叫出 Ubiquity 的搜尋介面鍵入該服務名稱即可，也避免在複製貼上間還得找網頁的輸入欄位。剪貼行為總是很快讓我進入昏睡狀態。

另外一個值得提的指令是 Marcello Herreshoff 的 create search command，之前建立自己的 Open Search plugins 程序其實有點複雜，即便利用 Ready2Search 或 Search Plugins Generator 等工具也需要一些步驟。這個指令只要選定一個搜尋欄位，鍵入 create search command 名稱 就會自動產生一組 Ubiquity 專用指令，一行程式都不需要寫！非常好用。另外你也可以利用 create bookmarklet command 把你常用的 bookmarklet 轉成 Ubiquity 指令。

即便我自己最常使用的還是搜尋引擎等指令，但是我相當看好 Ubiquity 的未來發展。不少人認為 Ubiquity 僅多提供 Web 的 CLI 的介面，也有些人質疑指令列根本就是走退路，未能體會 Ubiquity 的多國自然語言介面設計理念。

事實上，對電腦下命令不難，難的是背指令後依照指定語法下命令。

CLI 介面最令人畏懼的是得背下指令名稱，還得依據其指定之語法給予參數。而多國自然語言介面的設計用意就是，讓使用者盡量用熟悉的口語方式給予指令，不讓使用者強記。替代日漸繁雜的選單與功能列，取而代之是選取文字後使用「search this with Findbook」、「到 Findbook 查這個」的這種指令方法。

在新版 Ubiquity 的 Parser 2 中，Ubiquity 帶入了 semantic roles 的指令設計，搭配先前設計的名詞詞性 (Nountypes)，可以更精確的分析使用者欲執行的指令。再研究過眾多語言的文法架構後，在語意分析器設計上也可有彈性的適應於不同語系，現在你可以依照自己的語言特性設定 Branching、斷詞等方式，讓分析器再判斷完介係詞、分隔字後正確判斷文句意義。因此未來除了現有的英文語系之外，你也可以使用中文來下達指令，再接下來的計畫中，也會納入 Command chaining，於是或許接下來你就可以直接對電腦說「到 Findbook 查這個並寄給 Rex」這種語法。

不少人拿 Ubiquity 跟一般桌面的 Launcher applications 作比較，像是 MacOS 上的 Quicksilver 介面，或 Linux 上的 Gnome-Do 等。但是桌面系統的特性畢竟跟網頁略有不同，許多桌面工具並非文字導向，應用上並沒有像網頁間互相傳輸字串那樣自然。

我最期待的幻想其實是希望這套系統可以置入行動裝置，並結合語音辨識功能。雖說現在許多智慧型手機已內建語音辨識，但常常都還只是啟動電腦或直接撥打電話這樣程度的應用，軟體若可以知道自己接受哪些參數，或許就可以利用觸控螢幕輸入欲傳送之「物件」(object) 並用語音給予指令了。這樣的應用相對只需要聽懂指令，可以避免以語音給予「物件」數值時容易聽錯的缺點。

Posted on
by

最近，追蹤了一些在 HTML5 draft 上的新規格，試著想跟上一些更動，一方面嘗試新 API 的用法。基於 HTML5 的強大功能，未來只用 HTML 與 Java Script 便可以實做出許多的網頁版本的應用軟體，在行動裝置如 iPhone, Palm webOS 上已經有許多軟體或小遊戲之實做。其中一項感興趣的功能是離線 Web Apps 的應用。這篇文章稍微紀錄一下相關的規格。

若想進一步瞭解 HTML5，可參考 Google 的 Brad Neuberg 的演講 Introduction to HTML 5 或 Ian Hickson 的 HTML 5: Features you want desperately but still can’t use 的展示。Ian Hickson 是 Web Applications 1.0/HTML 5 specification, CSS 2.1 的規格作者之一，也是 Acid2, Acid3 的維護者。

Offline resources

離線網頁的第一個問題，是必須使頁面中所使用的各項網頁、圖片先行快取於系統中。欲達到此目的，規格中定義了一個 manifest 宣告機制，你必須在此檔案中宣告所有欲快取之檔案列表。規格中亦定義了一組 Application Cache API，使你知悉目前快取狀態。

Offline resources 功能已經包含於Gecko 1.9.1/Firefox 3.5 中。

Online and offline events

若要作離線程式，第一個要判斷的可能還是網路連線狀態，雖說有時會是電腦依然接在網路上，但是卻連不上網路的狀態，但是若系統可以自行告知目前連線狀態，就可以省下不停確認連線狀態的白工。在 Debian GNU/Linux 上，若使用 NetworkManager，瀏覽器如 Iceweasel 會自動依照網路狀態切換狀態。

關於連線狀態之規格定義在 Browser state API 中，在 Firefox 3 中已可取得連線狀態改變的通知。

Client-side Storage

關於儲存離線使用的客戶端資料，在不同的瀏覽器中有不同的作法。像是早期 Firefox 2 (與 IE8) 的 globalStorage、Microsoft’s userData、Flash storage、Google Gears 的 Database API 等等。原則上有兩種形式，一是 key-value 為主，另一種則是 SQL 語法導向，在 HTML 5  中有兩份規格，可以用來儲存離線使用的客戶端資料，一為 Web Storage、另一則為 Web Database。

Web Storage 即為 key/value 形式的 API，在 Firefox 3.5 後已可使用相容於規格的 DOM Storage API. 而 Web Database 則提供給開發者利用 SQL (SQLite) 的語法直接管理資料庫，但除了特別需要搜尋功能外，我其實頗懷疑還有多少人願意用 JS 寫 SQL 語法。目前尚未見到 Firefox 實做 Web Database API，類似的 API 是 mozilla.org/storage/service，此 API 只能提供給 Firefox Extension 使用，尚無法直接應用於網頁中，網頁中必須透過 XPConnect 與取得權限才能使用。實際的作法可以參考 Klaus Förster 的 Offline SQLiteSVG database applications with Firefox 一文。

Other APIs

雖說目前已有較新的瀏覽器開始逐步支援 HTML 5 規格，但是基於跨平台的考量，目前最方便的 API Framework 應該暫時還是 Google Gears。這麼說得主要原因是因為其支援眾多平台，Firefox 1.5 之後、Safari 或者 IE6 以上皆可支援，甚至也支援一些 Windows Mobile 5 或 Android 平台，自然 Google 自己的 Chrome 瀏覽器也是內建支援的。跨平台支援，大約是網頁開發者最想避免的痛苦之一吧，在 HTML 5 普及前，若你願意使用 Database API 的 SQL 語法，Google Gears 可以減輕一些痛苦。另外 Google Gears 比 HTML 5 還好一點的特色是，Database API 讓開發者直接作全文搜尋，此乃利用 SQLite 的 fts2 模組。

或者，也可以利用一些 Java Script Library 來避開平台問題，讓 Library 自己選擇適當的儲存機制，像是早期的 Dojo Offline Toolkit、PersistJS，或者我自己比較偏好使用的 jquery-jstore。

新版的 Google Gears 0.5.21 (Released May 29, 2009)，還支援 Blob 與 Canvas。Blob 可以讓你在瀏覽器中存取一些二進位的檔案。Canvas 最大的用處大概是拿來縮圖，並另存檔案吧。0.5.21 中也增強了 Desktop API，Desktop API 除了最強大的製作捷徑 (createShortcut) 功能外，也新增了猜(圖片)檔案格式的 extractMetaData，跟可以處理檔案拖拉進瀏覽器處理的 getDragData。

目前的狀況，若想直接使用 Google Gears 同步網站資料，依然需要自己花費一些精力配合自己的伺服端 API 整合設計。一個需要考量的技術瓶頸是得避免同步抓取時，使網頁下載、解讀速度變慢，影響使用者的使用經驗。雖然這個問題可利用 WorkerPool 進行背景下載 (見 Google Gears 架構之  Background Sync)，但依然必須攥構一快取與同步機制。

我更感興趣的是 Vladimir Vukićević 所提出的看法，他提議或許可用 CouchDB 來處理資料儲存的問題。而 Atul Varma 發表了他的新嘗試 BrowserCouch，用 Java Script 重作 CouchDB 的 API，目的是若上線狀態，可將資料存進「雲端」，而離線則可用本地快取。這種作法相當接近我期待中的系統架構。

Posted on
by

最近為了在網頁中使用一個 C Library，從頭寫了一個 PHP PECL Extension。期間自然做了一些調查與研究，在此寫下供其他朋友作為參考。

首先應瞭解開發 PECL 時，一些必要得知識，像是基本的 Zend SAPI、每個模組的生命週期、記憶體管理、ZVAL 參數的取得等等。關於這方面的知識，除了已經相對太舊的Zend API – Hacking the Core of PHP 外，Sara Golemon 算是著述的較多的開發者，他甚至出了一本書叫做《Extending and Embedding PHP》，去年在 ZendCon 2008 也談過一次 PHP Extension Writing。

不過要完成一個 PECL Extension，大約不需要讀完一本書，Sara Golemon 在 2005 年時亦在 Zend Developer Zone 發表幾篇詳盡的技術文章，說明了最重要的幾個重點，讀過跟著做一次，大約就可以熟悉一些基本的技巧。我並沒有發現 Zend SAPI 的詳細文件，因此必須再翻翻 /usr/include/php5/Zend 下的 header files，看看其他 core extensions 的程式碼，大概就可以掌握完成一個 Extension 的知識。

Sara Golemon 的幾篇經典文章是

英文若嚥不下，或可參考 Huang Shiqiang 的簡體中文翻譯。Huang Shiqiang 尚做了一個以 C 為基礎的 PHP Framekwork – Kiss (計畫網頁)，頗有趣。以效能為出發點的 framework 或 template engine 還有 Blitz 等。

讀過文章，瞭解基本的概念之後，就可以開始動手寫程式。首先，你得有開發環境，包含編譯檔案、目錄結構、文件與封裝機制等。你自然可以動手複製一份別人的來改，或者你可以依照 PHP Manual 中的說明利用 ext_skel 來產出一個空白的專案。我自己是利用功能相較完整一點的 CodeGen_PECL。利用 Pear 裝好後，就可以利用 pecl-gen 生出一份空白的專案。

PHP Extension 預設利用 phpize 來自動生成 autotools scripts，對開發者來講，若要新增編譯參數或增加原始檔案，只需要增修 config.m4 中的內容即可，不用管整套的 autotools scripts，算是相當方便。config.m4 是用 m4 這個 macro processor 來處理，語法這裡就略過不提了，編譯文件應相當好找。

撰寫一個 Extenstion 的知識大概是這樣。補充說明，上述文件沒有提到的 PHP5 中的 Reflection API，你可以為每個函式加上 arginfo，可以方便一些工具自動取出這些 API 來用，作法請參考 Christian Weiske 的 Hacking PHP5。

另外一個值得一提的是做 Unit Testing 的方法，養成寫 test case 是維持軟體品質的好習慣。你若用了 phpize，系統應會自動生成 run-tests.php 等自動測試工具，你可以依照其設計寫一些自動測試的案例，每次編譯後可 make test 做自動測試，確保運作正常。在 IBM developerWorks 上有一篇淺析 PHP 官方自動化測試方法，值得一讀。

最後補充一點，這次我寫的延伸函式庫乃是 C 語言，若欲整合物件導向的  C++ 函式庫，可參考 Wrapping C++ Classes in a PHP Extension 一文。

Posted on
by

此文承接前文「A5 筆記活頁紙之執念」，分享一些使用 A5 活頁紙上的經驗。

前兩週路過了誠品信義店，無意中看到今年的手帳日誌展，誠品今年進口了不少日系的手帳精品，甚至連「1101ほぼ日手帳」都替人進口，在在誘惑我的小朋友離家出走阿，真要命。

日誌展中比較感興趣的有好幾本，以下稍微提一下自己感興趣的幾個產品。

Quo Vadis 日誌展其中一品項是 Quo Vadis (英文網頁) 的 Habana 系列。據說 Quo Vadis 從 1952 年開始首創一週兩面的排版，有別於當初一日一頁的排版樣式，雖說現在許多工商日誌都發行一週兩面格式了，不過 Quo Vadis 在品質上還是相當傑出。Habana 是空白日誌，並非工商日誌。除了有非常類似 Moleskine 的束帶與小紙袋設計，比較傑出的是用了法國 Clairefontaine 集團出品且通過森林驗證認可計畫 (PEFC) 的 Elemental chlorine-free 之無酸紙，相較於未脫酸的酸性紙，除了環保一點，尚不容易變色容易保存，除此之外最讓我動心的莫過於 Habana 的仿皮硬封面，質感佳外，又適合當墊板。另外，根據 Jaymi Elford 的使用經驗，他提到與 Moleskine 比起來，Habana 相較之下更容易攤開使用，不需要特別撐開也不會跑頁，相當值得參考。
Quo Vadis 中文介紹

另外一個比較感興趣的是 Ciak 的 Agende e Organizers，特色是封面皮革 (仿皮?) 好看，還特別做了缺口，讓束帶可以固定。可惜的是，這種封面由於硬度與彈性太強，缺點是無法自然攤平，妨礙了書寫的便利性。 :-/

我對於觸感接近真皮的封面絲毫沒有抵擋能力。大概是因為國中時期，熱愛打棒球，常常週末打球後，拿著綿羊油鬆開棒球手套的束線，伴著牛皮的氣味，小心的清潔心愛的手套。於是，現在聞到牛皮的氣味，總會想起那陣熱衷的時候。也因此逛到 Raymay Fujii 的產品時，讓我愛不釋手阿！先前就很喜歡 Raymay 的 Davinci 系列，這個系列的封面都是成牛皮再經過特別處理，觸感極佳，價格也絲毫不在我的預算之內！一直很擔心自己會失心瘋真的買一本回家，所幸誠品只有 System Binder & Diary 系列，沒有進口我需要的 zeit Vektor 系列，其中 Binder Standard type 與 Report Pad Clip Type 都有 A5 與 20 孔版本，就是我期待的樣子，不過每本都值兩張小朋友多，真是無法下手。

特別提醒一下，由於用筆習慣的不同，除非該廠商有推薦用筆，否則你最好還是試用過再買較好，因為筆觸的效果完全跟紙質有直接關係。此外，即便是商譽極好的外國文具商，很有可能在進口時為了不同的市場調性更改製作材料或等級。這點也要特別注意，不好盡信國外的評比。

討論完昂貴的舶來品，再回來看看日常使用的紙張吧。就像我之前說過，一個順手的活頁紙其實是很難找到，網路上像是愛麗絲、Ting Yang、masaru 等人也跟我有一樣的困擾，總是尋尋覓覓找一個最合適的替換內頁。

以下將會列出幾份我買過的活頁紙，並留下一些針對這些活頁紙品質的看法。事實上，這些是我在同一個月內搜刮了幾間台師大一帶的文具連鎖店，未來若用光了現在的內頁，且又發現了新的活頁紙品牌，也將會更新在此文中。

原則上，我評估的幾個重點是

  • 價格 (平均每張成本，儘量列出定價與特價之平均單張價格，特價以該文具店銷售價格為準)。
  • 紙質。類型與磅數，因為缺乏專業知識與器材，只能列出包裝上寫明之材質。
  • 排版。紙張大小、條列間隔、行數、邊緣裁切、活頁孔裁切方式、印刷圖樣。

下述的評比有一些個人主觀偏好，例如我偏好橫線印刷、乾淨的印刷圖樣、良好裁剪、小間隔、行數多、格線印刷精美、無卡通圖案圖樣、右上提供日期空格、第七八活頁孔做特殊放大處理，以方便使用原子夾。這些在你參考此文時應該要先知道，不要被我的主觀看法影響才是。

Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

Posted on
by

這兩日試玩幾個 clutter 為基礎的軟體，像是 mutter 與 Gnome Shell 時，發現在我的 X200 上畫面的反應極慢，根本爆慢到了不堪用的地步。翻查了一陣子之後，知道大約是 Intel 顯示卡驅動程式 (GM45) 中的 sync-to-vblank 問題。

根據 Emmanuele Bassi 的說法，若安裝了新版的 Intel driver，必須開啟 KMS (kernel mode setting) 後，驅動程式才會有正確的 sync-to-vblank 行為。

這個問題大約從 Clutter 0.2 之後就開始了，影響到所有的 Clutter 為基礎的軟體，像是 Gnome 的接龍遊戲 (/usr/games/sol-clutter) 等等，若啟動接龍遊戲後畫面速度極慢，大約就是這個問題造成的。

正確的解決方法是啟用 KMS (作法: Debian, Ubuntu)。

若暫時不想啟用 KMS，你可以在環境參數中設定CLUTTER_VBLANK=none，如

# echo "CLUTTER_VBLANK=none" >> /etc/environment

然後重新啟動 X 即可。