當一名程序員實作了一個 daemon 時，他將會面臨一個關於系統啟動流程的問題。他要如何安排啟動流程，才能正常地啟動他的 daemon？ 要放在 init.d 嗎？還是放在 rc.local？再者，每種 Linux 或 BSD 系統的啟動流程都有差異，更是為這項工作增加不少負擔。而 D-Bus service 的運作模式基本上也是一個 daemon ，所以當程序員實作了一個 D-Bus service 後，按理也是要為安排啟動流程煩惱。
所幸 D-Bus 有一個 dbus daemon launch helper 的功能，可以免除程序員安排 D-Bus service 啟動程序的困惱。只要按照 D-Bus 規格上說明的方式，寫好 .service 文件，dbus daemon lauhcn helper 就會在使用者呼叫指定 D-Bus service 時，自動啟動該 D-Bus service 程序。程序員不必煩惱 D-Bus service 程序的啟動問題。
Ubuntu 10.04 採用 Plymouth 取代 xsplash ，所以 Ubuntu 9.10 及以前版本的啟動畫面修改方式全都不適用。但是 Plymouth 提供了更簡單的修改方式。
Ubuntu 10.04 的 Plymouth 設定文件都放置在 /lib/plymouth 目錄內。與主題樣式有關的設定文件放置於 /lib/plymouth/themes ，預設主題樣式文件為 default.plymouth。其內容大致如下:
[Plymouth Theme] Name=Ubuntu Logo Description=A theme that features a blank background with a logo. ModuleName=script [script] ImageDir=/lib/plymouth/themes/ubuntu-logo ScriptFile=/lib/plymouth/themes/ubuntu-logo/ubuntu-logo.script
觀其內容，稍有經驗的使用者應該很快就能理解該如何下手修改了。
Ubuntu 10.04 採用 Grub2 作為啟動管理程式，同時也大幅改寫了設定文件的內容。這讓使用者更容易改變 Grub 的主題樣式(背景圖案與文字顏色)。
Ubuntu 10.04 的 Grub2 主題設置文件是 /etc/grub.d/05_debian_theme。Ubuntu 10.04 大幅改寫了 05_debian_theme 的內容。預設情形，它會去尋找 /usr/share/images/desktop-base/moreblue-orbit-grub.png 作為 Grub 的背景圖案。一般使用者只要將背景圖檔複製為 /usr/share/images/desktop-base/moreblue-orbit-grub.png ，再執行 sudo update-grub2 即可。
我曾耳聞將來只有 JDK7 而不會有 Java7 的傳言(No more Java 7)。雖然結局尚未到來，但看 Java technology, IBM style: A new era in Java technology 中的用字遣詞，傳言似乎真有那麼點可信度了。
雖然 Oracle 收購 Sun 之後，附帶取得 Java 內容的控制權，但 IBM 顯然決意擴大它對 Java 內容的影響力。在 Java technology, IBM style: A new era in Java technology 中，IBM 提出了不少項目。觀其態勢，既便 Oracle 最後不將這些內容納入 Oracle Java 7 specification，IBM SDK for Java v7 也會支援。在 JCP 的成員中，IBM 不是唯一有這打算的。 Apache 基金會也有自己的一套想法。
今天聯合報從 Telegraph 取材了一篇高盛弊案的重要關係人物 Fabrice Tourre 的報導。該篇報導摘錄了 Fabrice 與朋友間的一封郵件內容。我覺得這篇郵件的內容， Fabrice 說出了難得的實話，故一併搜尋到原文內容，摘錄於此。引為己誡。
E4X 全名為 ECMAScript for XML ，是 ECMA-357 Standard 的規範項目。它屬於 ECMAScript 的選用性能力，所以 ECMAScript 實作品不一定會實作的。目前看來，最積極支援 E4X 的就是 Mozilla 。它旗下兩種 ECMAScript 引擎 (SpiderMonkey, Rhino) 都支援 E4X。另外， Adobe 的 ActionScript 也支援 E4X ，只是用法略有不同。
E4X 最主要的能力，就是將 XML 文件直接視為 ECMAScript 中的原生型態 (primitive type)。一份 XML 資料在 E4X 眼中，其地位等同於 1,2,3, "hello" 這些原生型態的資料。E4X 基本上將 XML 資料視為容器，因此提供許多與 Array 相同的方法。這意味著你可以像是在面對 Array 般地操作 XML 資料。
前兩天，我在觀看 PHP Manual 中新增的 Gearman 和 mqseries 兩個擴充元件的內容。我一邊想著 PHP 連 IBM WebSphere MQ Series 這種 Message bus 都支援了，真是不錯；另一邊又想起好一陣子沒留意 PHP 的 D-Bus 相關消息了。於是搜尋了一下，這次找到了兩個 php-dbus 擴充元件，版本都還在 0.1.x ，文件也非常匱乏。不過我還是看了它們的源碼文件，安裝並撰寫一些 D-Bus 應用。就結果而言，現在已經可以使用 PHP 撰寫基本的 D-Bus 客戶端應用工具了。
目前有兩套 php-dbus 擴充元件:
這兩套我都測試過了，以 Derick's php-dbus 完成度較高。儘管 Derick's php-dbus 目前版本 (ver 0.1.0) 在撰寫 D-Bus 服務與客戶端程式時，仍然要避開某些情況才不會觸發記憶體錯誤。但它功能齊全，假以時日，等它修正錯誤後，相信它就會是 PHP 官方的 php-dbus 擴充元件。
我的電腦上，內接兩台光碟機，偶爾還會接上外部光碟機。有時，則是把光碟片的內容複製到SD記憶卡，插在記憶卡讀卡機內。也就是說，我有多個可抽換式儲存設備。而在採用 udev 管理設備的 Linux 桌面環境中，每當我們把儲存媒介(CD, SD card)放入可抽換式儲存設備後，系統都會在 /meida 配賦一個掛載點。只是掛載點的名稱，預設使用設備的 UUID ，例如 /media/1234abcd 。對人而言，實在不是容易記憶的名稱。當電腦上有多個抽換式儲存設備時，就會帶來一些小小的麻煩。
例如我放入一片 Ubuntu 的安裝光碟片，有時我就會搞不清楚這片光碟片的內容掛載在哪個點下。所以，我就寫了一個 shell script ，到 /media 目錄下幫我找出來。
使用 json.dumps() 將個體轉換成 JSON 文件時，Python json 模組可以自行處理絕大部份的 Python 內建型別資料，列表請見 Performs the following translations in decoding by default.。但是當轉換的個體為自定型別，或者是容器中包含自定型別資料時，你就必須指定 default 或 cls 鍵值參數，指示 json.dumps() 如何轉換那些自定型別資料。
我在 Ajax and Blocking IO - To Resolve Polling Anti-pattern 中闡述了 Ajax 設計時，如何運用 Blocking IO 模型解決輪詢反模式(polling anti-pattern)；這整個模型，又稱之為「需求把持模型(Request handle model)」。結語時，我提到我們在實際應用中，需要在伺服端規劃另一種行程間通訊機制(IPC)。這就衍生了一個問題，即伺服端的需求把持模型與效能問題。
為了搭配我的小黑(X200s)筆電，前幾天去挑了一組耳擴與耳機。由於我已經有一組桌上系統，又是要搭配筆電，故只挑隨身耳擴與耳道式耳機。耳機的預算是 2000元以下。
出發前，先用自己的桌上系統聽過一遍，讓耳朵熟悉一下。桌上系統配置為:
筆電部份， Grado SR60 直接接上 X200s 的耳機輸出孔。當天是帶著筆電與 SR60 到店家處試聽。
我把 NuForce Icon Mobile 買回家後，曾接上我的桌機做為 USB 音效裝置 (C-Media USB Headphone Set)。一開始試著當前級，直入綜擴。但是輸出似乎不夠， NuForce Icon Mobile 的音量轉到最大了，喇叭才發出勉強可聽的音量。接著採類比輸出(line out)接上綜擴，音量足夠了。但解析力聽來比電光石火 Spitfire 差了些。
NuForce Icon Mobile 在我的 XP/Foobar2000 環境下，輸出設備不能用 KS 輸出。但幸好搭配 ASIO4ALL driver 後可以用 ASIO 輸出，效果明顯比 DirectSound 輸出好。
Icon Mobile 搭配 ASIO4ALL driver 時，有些設定的注意事項。
最後一點，NuForce Icon Mobile 使用 Foobar2000/ASIO 輸出時，最好是專心聆聽音樂。如果開啟其他程式，例如瀏覽器看網頁，都有可能影嚮音樂播放，甚至爆音。這似乎是 USB 音效裝置的通病。我的 TerraTec Xfire 1723 配合 ASIO 輸出時，就不會被其他動作影響。
在 Web 應用上，當瀏覽器向伺服端索取資料，而資料尚未存在或尚未被輸入時，我們通常令伺服端回傳代表目前無資料的訊息，並告知使用者稍候再讀取。當 JavaScript 被帶入 Web 應用程式開發領域後，我們在客戶端設計上，便運用 JavaScript 在間隔一段時間後，主動地向伺服端查詢是否有資料可以讀取。由於這個動作是放在一個無窮迴圈中，令它反覆地向伺服端執行查詢動作，故而我們將之稱為「輪詢」(polling)。
然而這種普遍地解法，實際上是一種反模式(Anti-pattern)，也就是把反面的例子當成正確的做法(當我正在思考該如何表達這種普遍地錯誤形式時，我剛好瞄到桌上的《Java AntiPattern》， Anti-pattern 正是貼切描述這種情形的詞語)。在早期，瀏覽器的功能還很單純時，我們沒有別的選擇，只能使用這種輪詢式的解法。但隨著瀏覽器的功能強化與 Ajax 技術的普及，繼續使用輪詢式解法，就是反模式。正確地做法是，我們要在 Ajax 這種非同步設計模式中，導入同步 I/O 行為。在本文中，將說明如何運用 Blocking IO 解決 Ajax 設計中的輪詢反模式。
IBM 宣佈將把軟體開發與測試服務延伸到雲之彼端。快速導讀請看《A quick look at the IBM Smart Business Development and Test on the IBM Cloud》。
軟體開發的雲端服務，並非教我們如何設計與開發雲端服務項目。而是在雲之彼端為開發者提供軟體開發過程中所需的資源。軟體開發最基本的資源，是源碼的儲放與版本控制，還有規格文件的管理(wiki)，這兩項就是源碼代管服務。例如 SourceForge, Google Code, GitHub 皆屬此類。 IBM 的軟體開發與測試的雲端服務內容，除了最基本的源碼代管服務，其最大的優點，在於為開發者提供解決 軟體開發之建置風險 的資源。
在會場，我聽到許多廠商掛在嘴上說「現在都做數位訊源播放器了，誰還要做CD-Player？」。講白一點，就是說現在都直接用個人電腦、iPod 播音樂了。新推出的播放器上，USB 端子已經成為標準配置，加上 iPod 插座更是主流趨勢。
上個月，我在抱怨內政部自然人憑證系統僅支援IE瀏覽器時，主張要透過政治手段解決這個問題。三月初，歐盟和 Google 就先後以政治手段「解決」了 IE6。
當我們逐漸把觀看網頁的瀏覽器最低版本提高時，我們並不是在要求設計者與使用者使用那些瀏覽器的獨特功能。相反地，我們希望讓設計者與使用者享受到標準化的好處。因為愈是新版本的瀏覽器，它們對網頁標準規範的支援度就愈完善。儘管那些網頁標準規範已經發佈5年到10年之久了，例如 HTML4.1, XHTML, CSS 1 ~ 3, DOM level 1 ~ 3 ，但瀏覽器的實現腳步則是近一、兩年才逐漸趕上規範內容。造成瀏覽器實現進度落後的罪魁禍首，正是 IE6。現在的趨勢對使用者與設計者而言都是好事。設計者可以用一致地表達方式設計網頁，而使用者可以看到一致地呈現內容。
但是我國從政府機到學術圈，大多數人都未注意到這些問題。因此我國以政治手段解決 IE6 的時候，看來還遙遙無期。
Cron 是 Unix 平台上的工作排程服務，它有一套特定的時間記述方式，俗稱 crontab (See crontab(5))。例如 * 30 5,12,17 * * * 表示每逢 5點30分、12點30分與17點30分時，執行工作。CronLine 則是使用 Ruby 所實作的一個用於解析 crontab 的類別。它的源碼來自於 Rufus::Scheduler 。
日前有一位同事要離職，而他負責的案子指派給我接手維護。他負責的那件案子，我之前完全沒有接觸。原本以為專案交接會是一項很麻煩的事，但整個過程出乎意料地簡單，大概只花了不到30分鐘就交接完畢了。為什麼我們那麼快就能交接呢？原因就在於每日建置系統。
去年底完成一件大案子後，我們公司就指示我建立一套每日建置機制 (軟體開發之建置風險的故事 )。在每日建置系統上，只安裝了編譯、建置與安裝的最基本環境，其他 library 一律不裝。並要求所有專案都要實作一套可以在命令列下完成 init, build, package, install, test 動作的建置程序。視專案內容，這套建置程序可能是一份 build.xml(ant), 也可能是一份 Makefile ，或是更基礎的 shell script。重點是，這套建置程序要能交由建置系統自動執行並完成上述所有動作，整個過程不可以有人工輸入的部份。此外，我們定期會還原系統內容，以確保一個乾淨的建置環境。
專案交接時，最常碰到的情形就是接手者無法複製出原負責人的開發環境，以致於專案連建置執行都做不到，也甭提修改維護了。但是每日建置系統讓這個問題消失了。這項專案的交接工作，很幸運地在每日建置系統建立後才發生，因此大幅地減少交接工作的內容。當一個專案的內容，可以在每日建置系統上自動建置時，同時意味著別人也可以在簽出該專案的內容後，直接在命令列下建立起專案的開發環境。即使什麼文件都沒有，也可以接續專案的維護工作。至少，我可以用文字編輯器 (gedit, notepad) 開始修改程式。至少，我還有命令列可以跑 ant, make 。剩下的程式架構說明，都已經按照 Javadoc 形式寫著程式碼。剩下的問題，就是接手人員的功力高低了。
This tool which written by Ruby language publish file to Trac wiki page. It will read the file content then publish to Trac wiki.
Many people use Trac to trace the software projects. When project execution, we will renew the project's wiki page frequently. However, many contents often are written in other documents. For example the API specification, Java will write by the Javadoc form in the .java source code, Ruby has RDoc, PHP has PHPDoc. The update log will write in the Subversion commit message. “The source code is the document”, these methods are quite universal. Because the document content had already existed, we most effective processing mode is with publish tool to read the file and to publish to the wiki page. Remembers, Copy and Paste is not the job which a professional programmer should do.