Mee's Notes

node.js 的 ServerResponse 回應 binary data 的問題

2012-02-10T15:54:00.000+08:00

這兩天在測試時一直被一個問題困擾, 我是用 node.js 寫一個簡單的 HTTP Server 接收 GET request, 這個 server 會把傳入的 GET 參數 (都是表示整數的字串) 轉成整數後加總傳回, 一開始都用文字的方式傳回, 測試也都正常, 可是因為我的 client 要處理字串有點麻煩, 所以當我嘗試把加總值改成用 binary data 傳回一個 16 位元的整數值時, client 這邊一直收不到答案, 經過一番測試, 發現 node.js 這邊會把 HTTP respnse header 與 binary data 分開成兩次傳回, client 這邊沒有考慮到這個問, 於是就收不到答案了。

後來直接看了一下 node.js 裡頭 http.js 原始碼, 發現果然如果使用 ServerResponse.end() 或是 ServerResponse.Write() 送出回應時, 如果 header 尚未送出, 而要回應的資料是字串的話, 就會直接將 header 與回應內容串在一起後送出, 但若是回應的是 binary data, 就會將 header 與 binary data 分開送, 事實上, 只要傳送的資料的編碼不同, 就會分開傳送。

如果您也使用 node.js 的話, 希望這個經驗能夠避免一些問題。

命令提示字元 (DOS Prompt) 下的小技巧

2012-02-10T15:42:00.001+08:00

天啊, 我居然今天才發現, 原來在 DOS prompt 下, 可以使用 tab 鍵直接幫你輸入檔案名稱或是目錄名稱, 這在輸入指令或是參數時超好用, 尤其時檔案名稱若是包含有空白字元、或是檔名有夠長的時候, 簡直就是救星！

舉例來說, 如果我在某個資料夾下有兩個檔案, 分別是 test.js 與 testone.js, 當我在 DOS Prompt 下按 tab 鍵, 就會出現 test.js, 再按一次則會出現 testong.js, 如此輪流。如果你先鍵入 t, 再按 tab 鍵, 那麼就會出現以 t 開頭的第一個檔案名稱, 更棒的是, 如果檔案名稱包含有空白字元, 也會幫你加上 "" 括起來, 省去自己鍵入檔名的麻煩。

Android Screen Cast 軟體--可將 Android 裝置畫面顯示在 PC 桌面上的軟體

2012-02-08T10:39:00.001+08:00

最近因為同事有需求要再簡報時直接在 PC 上秀出 Android 手機的畫面, 因此找了一下, 試過之後以 Android Screen Cast 表現最佳, 其他試過的軟體雖然也都可以運作, 但因為 fps 太低, 所以 PC 上看到的畫面都是斷斷續續的, 不像是連續操作的動作。這類軟體運最方式大都類似, 具有以下特點：

都需要事先裝好 Android SDK (當然, 一定得先裝好 JDK)
都需要使用 ADB, 所以也要事先裝好所使用手機的 ADB driver
都是使用 Java 撰寫, 所以只要 Android SDK 可用的平台, 也都可以使用
手機要設定『設定/應用程式/開發/USB除錯』

如果執行後出現以下錯誤訊息：

點選『詳細』鈕後, 若錯誤原因是『Timeout getting device list』：

請直接使用 SDK 中的 ADB 工具程式執行 "adb devices" 指令連接你的 Android 裝置：

應該就可以執行了, 像是以下這個畫面就可以看到 Android 的照相畫面：

目前這個軟體的 fps 大約可到每秒 5 張畫面, 因此在 PC 上看起來雖然還是有些頓, 但已經比我試過的其他軟體每秒才 1 張畫面好多了。

Appcelerator Titanium 的 Java 設定

2012-01-31T12:05:00.001+08:00

Appcelerator Titanium 是個很吸引人的開發工具, 不過在試驗的過程中, 每當要建置專案時, 總是說需要 JDK 1.6 版, 可是我明明安裝的就是 1.6.20, 試過設定 JAVA_HOME 環境變數還是有問題, 最後看了這個討論串「ERROR] Error locating JDK: set $JAVA_HOME or put javac and jarsigner on your $PATH」後, 改為將 JDK 的 Bin 資料夾設定到 PATH 環境變數中, 果然就搞定了, 特別記下來, 免得以後在別的機器上要測試時又遇到！

免費的 JavaScript 檔案存放空間：Free Javascript Hosting

2011-11-30T00:24:00.000+08:00

因為想把 JavaScript library 放在網路上, 以便能在 blogger 的網誌上使用, 順手找了一下, 果然有免費的 JavaScript 檔案存放空間, 而且上載程序超簡單, 只要填入 email 就可以上載, 之後就可以在任一網頁中引用了, 真不賴！

Free Javascript Hosting

修改 .NET 程式的版本

2011-11-24T19:22:00.001+08:00

由於工作的關係, 常會用 C# 寫點小工具給同事使用, 修改多次後, 版本就亂了, 同事也很難分辨手上的程式到底是哪一個版本？還好, 在 application version (major and minor) c# winform 這一個問答中找到, 原來只要開啟專案中 Properties 下的 AssemblyInfo.cs 檔案, 即可修改版本編號了, 真是學藝不精。

補充：感謝網友提醒, 其實應該是在「專案/屬性/應用程式/組件資訊」這裡改會更方便才對！

檢查物件是否具有指定的屬性：JavaScript 的 in 運算子

2011-09-25T12:18:00.001+08:00

記憶中好像沒有好好認真學過 JavaScript, 多半是隨著應用就邊用邊學, 所以常常在遇到問題時才去查, 前幾天就遇到想要確認某一物件是否具有指定的屬性, 才發現不知道該怎麼做？直覺想到的是用 for in 列舉所有的屬性之後再一一檢查, 但總是覺得不可能只有這麼笨的方法, 一查才知道原來 in 並不是指能與 for 配合使用, 而是可以單獨運作, 它的作用就是檢查左邊運算元是否為右邊運算元的屬性。例如如果有一個這樣的物件：

var obj = {1:"one","two":"two"};

那麼就可以利用 in 運算子檢查是否具有某屬性。以下就以 node.js 為例, 示範 in 運算子的用法：

console.log(1 in obj);
console.log(2 in obj);
console.log("1" in obj);
console.log("two" in obj);

這一段程式的輸出結果如下：

D:\TEMP>node test.js
true
false
true
true

由於 1 是 obj 的屬性, 所以第一個輸出是 true, 而 2 並不是 obj 的屬性, 所以第二個輸出就是 false。要特別留意的是第三個輸出結果為 true, 這是因為在 JavaScript 中, 物件的屬性一定是字串, 如果你指定的屬性名稱是數值, 也會先被轉為字串, 因此, 雖然我們在建立物件時用了 1 當作屬性名稱, 實際上屬性的名稱為 "1", 所以第三個輸出也是 true。

Node.js 學習資源記錄

2011-09-09T10:27:00.001+08:00

由於最近對於 node.js (官網說正式名稱為 Node, 但大家也稱它為 Node.js) 很有興趣, 所以花了一點時間學習, 不過因ˋ為我自己的工作平台都是 Windows, 因此在使用 node.js 時常遇到一些完全以 Linux 說明, 沒提到 Windows 下怎麼辦的狀況, 經過網路爬文後獲得解決,所以趕緊把這些資源記錄下來：

怎麼安裝 Node？

Node.exe

Windows 平台沒有 NPM, 怎麼安裝 Node 的模組？

Node.js on Windows: Who Needs NPM?

有 Node 下現成的 Web Framework 可以用嗎？

express

Getting Started with NodeJS on Windows

Node 初學入門教材？

The Node Beginner Book

Tera Term Portable 版本

2011-09-05T22:24:00.000+08:00

Tera Term 雖然沒有正式的可攜版, 不過它的開發中版本是以可攜的方式公開, 所以如果不顧慮是開發中版本的話, 就可以當成可攜版使用, 也是不賴喔！

Tera Term 開發中版本:

'via Blog this'

EmEditor 使用的 TeraTerm Macro 語法檔

2011-09-04T12:04:00.001+08:00

如果你使用 EmEditor 撰寫 TeraTerm 巨集, 那麼可以使用以下這個語法檔為巨集加上語法標示, 不過這個檔的內容沒有包含像是 waitregex 等較新版本 TeraTerm 才有的指令, 必須自己視需要加上。

TeraTermマクロのEmEditor構文ファイルを公開:

'via Blog this'

Tera Term Macro 的一個小陷阱

2011-09-04T12:00:00.001+08:00

Tera Term 的 Macro 實在很好用, 不過我在使用時遇到了一個小陷阱, 如果你啟用了 local echo (不論是透過 Terminal Setup 或是 setecho=1 指令), 都會讓 local echo 的內容變成 waitln 等等待指令收到的第一行資料, 如果想等待的字串剛好與 local echo 回來的內容相仿, 就可能會發生錯誤。以底下這個範例來說：

setecho 1
timeout= 10

sendln 'CONNECT'
waitln 'HELLO''CONNECT'

if result = 1 then
	messagebox '收到 Hello' 'Info'
elseif result = 2 then
	messagebox '收到 connect' 'Info'
endif

end

原本預期能夠區分收到的字串是 'HELLO' 還是 'CONNECT', 但實際執行時會因為 local echo 回來 'CONNECT' 的關係, if 判斷永遠都是收到 'CONNECT', 即便遠端真的有回應 'HELLO' 也沒有用。如果一定需要 local echo, 那麼可以先執行 recvln 指令略過 local echo 回來的資料避免這個問題。

Firefox 中觀看 Windows Media File 的方法

2011-05-07T02:27:00.000+08:00

之前找到相關的資料後, 雖然 PO 在 Facebook 上, 不過 Facebook 我實在不知道該怎麼找資料, 還是再 PO 一次在部落格上比較妥當, 基本上就是依據以下這篇文章下載三個 DLL 複製到 Firefox 的 Plugins 資料夾下：

Manually Installing Windows Media Player Plugin for Firefox in Windows Vista

希望文章中 DLL 的下載連結不會失效！

WMZ檔轉EPS檔的方法

2010-12-08T19:52:00.000+08:00

我的工作常會需要從WORD檔轉換為純文字檔整理之後，以特定的格式轉交給美編使用InDesign排版，這樣的程序會有許多麻煩事情，比方說常見的WORD中的方程式，轉到純文字就什麼都沒了。以前我大部分都會使用WORD先轉成PDF檔之後，再從PDF檔抓取方程式當圖檔給美編處理，這樣子雖然可行，不過一來程序有點複雜，而且也要看轉出來的PDF檔內容是否可用，比方說有時候根號竟然變成一條粗線配一條細線，這時PDF在怎麼抓也沒用。

為了解決這樣的困擾，所以我嘗試把WORD檔轉成HTML檔，WORD在這個程序會把文件中所有的點陣圖與向量圖單獨存檔，放在與檔名同名，但加上「.files」結尾的資料夾中，其中方程式物件會被存成WMZ檔，這個WMZ檔根據WIKIPEDIA的說明，就是壓縮的WMF檔，而WMF檔則是Windows Meta File，簡單的說，就是Windows下的向量圖檔。既然是向量圖檔，那如果可以轉成EPS檔，就方便多了！

好在，根據這一篇文章，Windows和ZIP壓縮格式是一家親的，所以只要將WMZ檔的副檔名改成ZIP，就可以用ZIP解壓縮工具取出WMF檔。不過要注意的是，取出的檔案是沒有副檔名的，所以要自己加上.WMF的副檔名。得到WMF檔之後，如果你有Illustrator，應該就可以直接開啟WMF檔。如果沒有WMF檔，也可以使用這個WMF2EPS轉檔工具，將WMF檔轉成EPS，接著就無所阻礙了。

解說數學極限觀念的精彩範例

2010-10-05T13:10:00.002+08:00

前一陣子在翻閱《世にも美味しい数学》（美味的數學）這本書時，看到了一個對於數學中極限觀念的精彩範例，題目是這樣的：如果要切蛋糕給三個人吃，怎樣切才能讓三個人吃到相等份量的蛋糕呢？如果是要切出四等分、八等分，一般人都可勝任，但是三等分要怎麼切呢？

只要套用極限的觀念，就可以找到「理論」上的切法了。先將蛋糕切成四等分，每人分1/4，再將剩下的1/4切成四等分，每人拿一份，也就是原本蛋糕的1/16，再將剩下的一份切成四等分，如此循環，也就是每個人實際上拿到整個蛋糕的1/4 + (1/4)^2 + (1/4)^3 + ...... + （1/4)^x，當 x 趨近無限大時，每個人所分到的就是趨近 1/3，不過這當然是「理論」上的切法啦，x = 4以上時，大概就很難再切下去了吧？除非原本就是個超級大蛋糕！

題外話，針對這個問題，如果你有 iPhone 的話，有現成的 app CakeCutter 讓你打開相機對著蛋糕，就會自動出現任意等分的分割線，只要照著分割現切蛋糕就好了，哈哈！

[更新]Bloglines Toolkit 1.8

2010-07-04T12:10:00.000+08:00

更新：目前已經有1.8了，Firefox 3.6可用！

如果你跟我一樣是使用Bloglines當成RSS閱讀器，那麼大概也都會用過Bloglines Toolkit這個Add-on，不過原作者的部落格好像停止更新了，最後一篇文章是2008/09/29，而上面找到的最新版本1.7.0與Firefox 3.5並不相容，今天用Google隨便找，竟然發現一個1.7.1的版本，作者是同一人，安裝後可正常使用，趕快記下來，如果您也有需要，趕快去下載安裝吧！

Excel VBA中Sort物件的SortMethod屬性值xlPinYin與xlStroke意義顛倒了？

2010-06-07T14:10:00.000+08:00

今天在校對一本書時，發現Excel VBA中Sort物件的SortMethod屬性值xlPinYin與xlStroke意義似乎顛倒了？請看下圖，先以xlStroke為SortMethod屬性的值排序，結果筆畫多的「台北」排在「台中」之前：

再來以xlPinYin為屬性值排序，結果「台中（ㄓ）」排在「台北（ㄅ）」之前：

如果此時點選「資料」頁次的「排序」，在「排序」交談窗按下「選項」，會看到是「依筆畫排序」，而實際上排序結果的確是依據筆畫順序：

若回頭去看之前用xlStroke為屬性值排序的結果，顯然是依據注音符號排序，所以似乎這兩個常數在VBA中弄反了。

再進一步印證，如果用錄製巨集的方式，採用注音方式排序，錄製下來的巨集如下圖：

可以看到實際採用的是xlStroke常數，這樣看來，我的猜測應該是正確的。

PS：這目前在2007與2010中都測試過，都是同樣的結果。在網路上搜尋的結果，似乎在Office XP中的Excel 2002就會出現錄製結果常數值相反的問題，不過已經在Office SP3修正了。不曉得現在這個問題以後是否會修正？

守護白海豚，全民認股行動

2010-05-30T02:49:00.001+08:00

這是一份簡單的守護白海豚，全民認股行動的投影片，希望能讓您在最短的時間內瞭解現在的危機，也邀請您一起加入！

更多資訊可上網站查詢：
http://et.e-info.org.tw/node/119

一直到六月底，我們全家都會在週六日到西門町紅樓前的創意市集擺攤當義工，盡力解說『守護白海豚，全民認股行動』，也歡迎大家一起來幫忙！

守護白海豚，全民認股行動

View more presentations from meebox.

依照日期排列WORD追蹤修訂資訊

2010-04-13T11:52:00.000+08:00

我的工作常常需要用到WORD的追蹤修訂功能，追蹤修訂功能雖然可以標示出修改日期與時間，但是卻沒有依照日期排列追蹤修訂資訊的功能，上網找了半天，似乎也沒有適當的解法，不過找到了一個可以擷取追蹤修訂資訊，整理在一份新的WORD文件上的VBA程式。它會建立一份新文件，並且以表格的方式擷取出增刪的修訂資訊，這樣一來，我就可以貼到EXCEL上，依據日期欄位排序，得到我需要的資料了。

[英文]does what it says on the tin

2010-03-21T12:56:00.001+08:00

今天讀 The Rough Guide to Men's Health 一書簡介時，讀到了這一段：

The fifth section, Reference,pretty much does what it says on the tin.

其中 "does what it says on the tin" 大概可以猜出意思，但很好奇這句話是怎麼來的？後來在Wiki上看到，原來這句話是源自於英國某個產品的電視廣告，強調其產品內容、時效完全就如同其錫罐上的文案，童叟無欺，演變到後來，即便這家公司的產品不一定採用錫罐為容器，也都一樣在廣告上套用這句話，而因為這個廣告太出名了，甚至變成了一般人的常用句，表示真實內容就如同文字一樣，沒有用文字誇大不實之處。

[英文]ride off into the sunset

2010-03-21T12:41:00.002+08:00

在閱讀 Building iPhone Apps with HTML, CSS, and JavaScript 這本書的前言時，作者提到他看到 App Store 時，想到他之前已經寫了一堆 iPhone 上的 web 應用，所以認為：

Some of my web apps were already somewhat popular, and I figured I’d just rewrite them as native apps, put them in the App Store, and ride off into the sunset on a big, galloping pile of money.

這裡頭的 "ride off into the sunset" 本來一直搞不懂文意，後來看了《CNN新聞關鍵用語：英語詞彙語用策略實例》一書〈典故〉篇，原來這句話是從西部電影來的，西部電影通常結尾都是主角騎著馬在落日餘暉下遠去，所以 "ride off into the sunset" 就演變成形容退場、結束的意思了，因此之前提到的那一整段就是說：

我寫的web應用中有些已經很紅了，所以我發現只要重新寫成原生應用，上架到 App Store，就可以海賺一票離開了！

看來，英文還是得加強啊！

快速取巧的Firefox附加元件升級法

2010-02-03T10:38:00.000+08:00

每次升級Firefox後，最討厭的就是遇到附加元件（Add-ons）與新版Firefox不相容的狀況，這一篇有個投機取巧修改附加元件最高相容版本資訊的方法，可以騙Firefox，有空來試試！

A Quick-And-Dirty Way To Update Your Firefox Extensions

CISCO提供的網路設備圖示

2009-11-25T18:19:00.000+08:00

如果你需要繪製網路拓檏圖，那麼CISCO所提供的這一組網路圖示會非常好用，有PPT格式、VISIO格式等，任君採用，網址在這裡：

http://www.cisco.com/web/about/ac50/ac47/2.html

如果網址有變，應該用CISCO ICON POWERPOINT為關鍵字就可以找到。

資料夾名稱含"["與"]"會導致Excel無法存新檔

2009-11-24T12:24:00.000+08:00

因為工作的關係，常常會在資料夾上用 [XXX] 的方式標註該資料夾的資訊，之前常常遇到用Excel建立新的工作簿後，要存檔時不論怎麼取檔名都無法存檔，後來試驗之後才發現，原來是資料夾名稱中的[]作怪，不過有趣的是，如果把現有的檔案移到名稱中含有[]的資料夾中，開檔後存檔都不會有問題，特別記錄下來，如果你也遇到類似的問題，希望能幫上忙！

PS：經驗中，若是開新Excel檔要存檔，取檔名時含有[]也會有類似的症狀，但一樣若是現有的檔案則不會有問題。

Facebook是業務人員的好工具！

2009-09-19T00:06:00.000+08:00

最近因為Facebook火紅，有些朋友常會問Facebook到底有甚麼好玩？或者是Facebook到底是甚麼？不管官方或是所謂嚴謹的定義，我自己倒是發現了Facebook一個很有意思的用途----讓職務上必須與有點熟又不是太熟的人聯絡的人，能夠有機會瞭解這些不太熟卻又必須聯絡的人的嗜好或是近況。

一般來說，如果只是因為職務上剛認識的朋友，通常你不大可能知道他們的喜好，而如果又必須與他們保持聯繫，往往會有不知道要談些甚麼的窘狀。但是如果能夠把他們加入成Facebook的朋友，你就可以透過觀看他們的近況，而有機會更認識他們一些，甚至先在Facebook裡互動一下，實際談話時不但可以有話題，也比較不會太突兀，好像在刺探別人隱私一樣。

即使朋友們完全不PO任何的狀態更新，而只是玩遊戲，你也可能從中看出朋友喜愛的遊戲類型。如果朋友們很勤快的更新近況，那更是可能看到朋友們喜歡那個樂團、從事甚麼運動、參加了甚麼表演、或是小孩上小學了等等，這些都可以成為未來的話題，甚至可以幫助你挑選未來要送給客戶的禮物，一舉數得呢！

所以，如果你還以為Facebook是年輕人的玩意兒、或是太浪費時間，你可能得重新考慮一下，多投資一點時間在上面，效果可能出乎你的意料之外哩。

網頁設計實戰課程：不注重網頁相容性就是會有這樣的後果！

2009-09-16T18:52:00.001+08:00

之前編輯了一些CSS的書，這種書有個特色，就是一定會大談網頁相容性的問題，不過其中很少點出不注重網頁相容性的嚴重性，前幾天剛好在不來恩的噗文上看到以Pizza關鍵字查詢時，因為必勝客的網站只能讓IE看，所以必勝客雖然佔到了第一位，但卻出現這樣的畫面：

除非看網址，否則大概不會發現那是必勝客，這其實是網頁設計者貼心但卻粗心的結果所造成的，原本網頁設計者想的是對於Windows的Firefox使用者，可以建議他們安裝IE Tab這個外掛，就可以切到IE引擎瀏覽內容，但是沒想到這樣一來，因為搜尋引擎的機器人也被視為非IE瀏覽器，所以看到的搜尋結果就是一堆和必勝客無關的文字。如果你進到必勝客，就可以知道原來他是這樣的：

我其實建議就算沒有功夫或預算改成可以讓不同瀏覽器看到相同的畫面，至少也用一些文字訊息宣傳一下特惠活動之類，並且要注意讓網頁的標題（也就是顯示在瀏覽器標題列的文字）一定要出現公司名稱等關鍵字，而網頁中則在特惠或是公司行銷訊息之後才出現貼心的IE Tab外掛安裝建議，這樣搜尋到網站時瀏覽者才能辨識網站名稱，同時連過去之後也不會完全放棄就跳離！

用Yahoo Pipes實作可直接查詢Amazon日本站書籍細節資料的服務

2009-09-06T01:05:00.000+08:00

Amazon網站的書籍搜尋雖然很好用，可是我常會要進一步知道每本書的頁數、銷售排名等等只有點進單書詳細頁面才能看到的資訊，因此今天用Yahoo Pipes處理從Amazon E-Commerce Service傳回的搜尋資料，做了一個可以查詢細節資料的服務。如果您也有這種需求，可以試試我所製作的服務，網址如下：

amazon.co.jp book search 1-100

只要輸入關鍵字，就會取得依據Amazon Sales Rank排序的前100筆資料。

要特別說明的是，由於Amazon ECS每次查詢只能傳回10筆資料，而Yahoo Pipes目前並沒有一般程式語言那樣的迴圈，所以我只好先坐了一個會傳回100筆資料的服務，以我自己的工作需求來說，以銷售排行順序前100名應該也就夠了，超過此範圍的書通常我也不會去注意了。

如果在使用上有任何問題，歡迎您將意見回饋給我。

延伸閱讀：

Amazon E-Commerce Service
目前使用Amazon E-Commerce Service除了需要註冊帳戶外，還得使用數位簽章您可以參考API Signing Service的說明，或者直接使用他們所提供的免費服務幫您處理。

全民公敵真的來台灣了，Google台北街景啟用！

2009-08-18T13:31:00.001+08:00

能窺看別人家是一回事，能在Google地圖上看到自己家裡可是有點毛毛的啊！

我的防毒軟體到底是關閉還是開啟？

2009-08-18T10:21:00.001+08:00

不曉得是不是因為電腦太慢，防毒軟體和安全中心溝通不良，我的電腦常常會看這樣的畫面，安全中心說防毒軟體回報已經關閉，但是工作列上的防毒軟體看起來卻正常執行：

日文中H18.2.1原來是指平成18年2月1日

2009-07-24T12:01:00.004+08:00

跟譯者討論日文書內容時，遇到一個和日期有關的「H18.2.1」，討論了半天猜不出來，還是請出Google大神來，輸入「H18.2.1」，只跑出一條檢索結果：

照著連過去後，咦，怎麼找不到「H18.2.1」？

這一頁剛好也只有一篇文章，看到日期欄2006/2/1，就想會不會原來H18.2.1就是2006/1/1？再請出Google大神，找一下日本年號，果然，平成是從1989年開始的，若H18是指平成18年的話，那換算過來就是2006年了。

還好是網路世界，不然這難題要去哪裡問啊！

看來電子書閱讀器有譜了

2009-07-23T15:25:00.003+08:00

在Stuff網站上看到這個：

整個看起來好像很符合我對於用電子書閱讀器看漫畫的需求哩，希望價錢不會很貴，拿來看PDF電子書也很不賴啊。

日本手機漫畫成為新商機

2009-02-23T14:12:00.002+08:00

之前我自己曾經想過「電子書閱讀機的殺手級內容--漫畫書？」，今天剛好看到台灣出版資訊網上一篇新聞「日本手機漫畫成為新商機」，果然大家有志一同，都找到這個有賺頭的領域去。

如果對照1109期商業週刊中訪問尖端發行人黃鎮隆的「印書像印鈔票的秘密--尖端執行長二十年的釣魚經營學」一文中格林文化發行人郝廣才所言「以前一本漫畫發行幾十萬本，是常有的事，現在，漫畫就像書一樣，能賣超過一萬本，就算是暢銷，」，至少對於漫畫，紙本的地位已經越來越不保了。

但話說回來，用手機看漫畫，我想螢幕還是算小了點，雖然已經比看小說好太多，但若是用電子書閱讀機，顯然舒適多了！

取出WORD文件中所有文字框的文字

2009-02-19T11:39:00.006+08:00

我的工作因為要整理作者提供的稿件，因此一直有個需求就是把WORD文件中所有文字框（有加上文字的快取圖形、水平或是垂直的文字框）中的文字取出來，這樣我就不需要一個一個文字框作Copy貼的動作，今天剛好找到了一個合用的範例如下：

Dim sh As Shape
Dim txt As String
For Each sh In ActiveDocument.Shapes
   If sh.TextFrame.HasText Then
   txt = sh.TextFrame.TextRange.Text
   MsgBox (txt)
   End If
Next sh

只要把MsgBox那行換成你需要的動作，就可以將取出的文字再利用了，我自己是把所有文字匯集到一個跟WORD文件同名，但加上 "_shape" 字尾的文字檔：

Sub 匯出文字框的文字()
'
fname = ActiveDocument.FullName 'Word檔名
txtFname = Left(fname, Len(fname) - 4) & _
    "_shapes.txt" 'txt檔名
Set fs = CreateObject("Scripting.FileSystemObject")
Set txtfile = fs.CreateTextFile(txtFname, True) '建立文字檔

Dim sh As Shape
Dim txt As String

For Each sh In ActiveDocument.Shapes
   If sh.TextFrame.HasText Then
   txt = sh.TextFrame.TextRange.Text
   txtfile.writeline txt
End If
Next sh
txtfile.Close
End Sub

Silverlight 2 = Java Applet in .NET World

2008-09-05T11:18:00.002+08:00

對於資訊技術的發展，我總覺得很有意思，許多過去被提出但似乎失敗的想法總是會透過不同的方式捲土重來，比方說過去總被認為執行速度太慢、不夠嚴謹的scripting語言，居然就因為早期寫CGI的Perl、瀏覽器都支援的JavaScript、廣為流行的PHP、甚至最近的Rails中的Ruby而佔有一席之地，只要是網頁開發，到處都是scripting語言。

而十年前Java初登場時最紅的Java Applet，似乎越來越黯淡，不過就在我最近瞭解Silverlight 2時，卻有一種莫名其妙的熟悉感，這不就是.Net下的Java Applet嗎？只是當然Silverlight進化些，有現成的動畫與影音機制，但骨子裡不就是Java Applet嗎？

怪事第二件：Google Chrome跑了就出錯！[賽門鐵克SEP軟體相衝]

2008-09-04T10:53:00.005+08:00

這兩天大熱門就是Google Chrome，想當然要試用一下，沒想到在我主要的工作機上，就是無法正常運作，一跑就會出現以下的畫面：

這是甚麼狀況啊？厲害的是果然如同Google說的，每個Tab都是不同的Process，按下「確定」後，Chrome並不會結束，還是繼續運作，但是在網址列不管輸入甚麼，按下「Enter」後，一樣出現這個錯誤，屢試不爽。另外一台機器上則沒有問題，可以正常執行，天啊，Google大神，救救我吧！

[更新]根據找到的 Problems installing Google Chrome when Symantec Endpoint Protection
is installed. 這一串討論顯示，賽門鐵克的SEP軟體可能就是原因，而賽門鐵克官方的論壇上也有一篇提到暫時的解法，不過我還不確定這種解法會對SEP有甚麼影響，畢竟這是防毒軟體啊！

今日怪事：Microsoft Office Word、Excel 及 PowerPoint 2007 檔案格式相容性套件罷工

2008-09-04T10:32:00.005+08:00

〈Microsoft Office Word、Excel 及 PowerPoint 2007 檔案格式相容性套件〉一直是我很倚賴的工具，因為許多作者都更新到Office 2007版，但我的電腦只配有Office XP，這幾個月靠著微軟提供的這套工具，讓我除了轉檔過程比較耗時外，還是可以正常工作。可是就在昨天開始，不曉得是甚麼狀況，用這套工具開啟Word 2007的檔案時，就會出現以下這個交談窗：

顯示「本軟體為預先發行版本的相容性套件，僅可用來開啟預先發行的Office 2007檔案。您要檢查是否有更新版本的相容性套件嗎？」如果按「取消」，當然就真的取消了，不會找新軟體，也不會開啟檔案；但就算按下「確定」，雖然會帶到下載頁面，但也是2007/11/19發行的版本，而且Word一樣不會開啟檔案。即使試過重新安裝相容性套件，問題一樣會產生，天啊，請問這要怎麼辦啊？

[更新]雖然透過朋友商請微軟支援工程師處理，還使用遠端連線進來操作，不過經過一個多小時的努力，還是沒有進展。今天跟MIS研究，利用Office修復功能之後，反而出現新問題，現在不論是開哪一個Office軟體，都會看到這樣的交談窗：

按下「確定」後就關閉軟體，變成甚麼檔案都開不了了。好再經過Google之後，找到了這一篇〈執行 Office 2003 顯示「目前的使用者尚未安裝 Program_name…」〉，依據該文最後的解法，終於可以正常開啟Office了！接下來還得試試Office 2007相容性套件。

GMail與CSS

2008-06-27T10:17:00.003+08:00

如果您需要發送電子報，而且設計電子報時會使用CSS，那麼您得注意一下，GMail在顯示HTML郵件時，會將<style>元素所指定的CSS內容剔除掉。所以若是您的電子報內容會依靠CSS定位與展現特效，那麼GMail用戶收到時，可能就會看到錯亂的郵件內容。即便是郵件中以夾檔方式寄送的HTML檔案，如果以GMail提供的檢視功能，一樣會剔除掉<style>元素，在瀏覽器檢視原始碼就可以明確的看到這樣的結果。

面對這個問題，我個人僅有兩項建議，一是電子報內容一定要在醒目的位置留有連結，可以讓收件人點選後連到發報人的網站觀看正確格式的內容，這樣不論收件人閱讀郵件的環境發生任何狀況，收件人都有最終的機會可以閱讀電子報。另外，這也是迫使內容設計者遵循XHTML良好文件結構的契機，目前大多數人仍然只是將CSS視為輔助外觀設計的技術，HTML的內容中仍然會混雜一些與版面配置及外觀顯示的設定，使得在CSS失效時，HTML內容無法以良好的文件結構展示，甚至因為不同瀏覽器處理某些影響外觀的HTML標籤或屬性的差異，導致無法閱讀的窘境。

有關各Web-Based郵件服務對於CSS處理的差異，可以參考CSS support in HTML emails of Hotmail, Yahoo! Mail and Gmail。

電子書閱讀機的殺手級內容--漫畫書？

2008-06-09T16:28:00.005+08:00

電子書閱讀機出現在市場上已經不知道多少年了，不過一直以來似乎都沒有造成太大的迴響，雖然這中間對於紙本書與電子書的戰爭也引發了許多人的猜想與推論，但我總覺得要能夠讓電子書閱讀機突破現況，總得有個殺手級內容（Killer content），讓你真的會很想隨時隨地閱讀、卻又不用帶上一大堆的書。

可想而知，這個殺手級內容決不是一般電子書閱讀機附贈的哪種甚麼經典文學、四書五經，一方面普羅大眾絕沒這麼認真，而且就算要認真起來，讀這些書時恐怕都會很想寫寫心得、記記筆記之類了，用電子書閱讀器不但無法提供前述功能，也缺少了紙張所擁有的fu啊。

直到最近一來開始嘗試用電腦看漫畫，一方面看到了這麼一篇新聞〈Computex 2008：Netronix 的 300 美元電子書閱讀器〉，其中的這一張展示畫面（圖片引用自癮科技網站）：

我想，應該就是它了，電子書閱讀器的殺手級內容--漫畫！漫畫應該是唯一一種大家會想隨時閱讀、但是冊數又很多，閱讀時也不大會作甚麼筆記的書種。如果能有一部輕巧價廉的漫畫書閱讀器，再跟漫畫出版公司推出月租型服務（當然，你也可以靠其他方法取得漫畫，是吧？），那不就是絕配？或者十大漫畫書坊之類的也有漫畫下載服務，這樣一來，在通勤時間看完一部《20世紀少年》，豈不是太方便了。等等，別看得太高興，坐過頭啊！

呵呵，朋友，你說這樣子配好不好？

翻譯名詞：render

2008-04-26T00:41:00.002+08:00

render這個名詞在程式設計的原文書中很常出現，本來我一直想這個詞要怎麼譯才會達意，剛好譯者劉祖亮先生在翻譯《Essential WPF》一書時提供了一個好的譯法：演算上色（我不確定是否有其他地方已經這樣翻譯），覺得非常恰當，因為render通常只的並非一般的上色，而是要先經過依據特定的規則運算，來決定某一個位置的顏色，然後在將該顏色繪製到該位置上，譯為「演算上色」既簡單又明白。

編輯不可不知：「校對」源考

2008-01-28T23:45:00.000+08:00

今天翻看《書的迷戀》一書，在p65頁提到「古人治學，首重校讎。」甚麼是「校讎」呢？就是校對的工作啦，也稱為「讎校」，「讎」也通「仇」，唐李善《文選‧魏都賦注》中說：「讎校，一人讀書，校其上下，得謬誤為校；一人持本，一人讀書，若怨家相對，故曰讎也。」就是指讎校時需要兩個人，一個人拿個書唸，一個人對照著看正確與否，這兩個人相對，好似仇人一般，所以稱為「讎校」。

其後根據何焯《義門讀書記》說：「一人刊誤為校，二人對校為讎，後人嫌讎字，易其名為校對，對即讎也。」也就是說，後來的人覺得「讎」字不雅，才改稱為「校對」。

原來如此，編輯當不可不知！不過突然想到，現今還能落實二人對校的，恐怕已經不多了。

書賣幾本才算好？

2008-01-10T18:48:00.000+08:00

很多作者或是編輯都會思考這個問題，希望能夠評斷自己寫的書或是編的書到底賣的好不好？剛好同事給了我一個參考的依據，根據行政院主計處《九十二年電腦應用概況調查統計結果分析摘要》的資料顯示，民國92年時台灣資訊就業人口中，程式設計人員大概有21,646人，系統管理人員大概有20,824，如果我樂觀的假設其中有1/10的人會買我編輯的書（賣過東西的人應該不會認為目標族群的1/10是過低的期望吧？），那也就表示像是ASP.NET AJAX或是Winodws Server 2008這樣題目的書，如果能賣到差不多2000本，應該就算是不錯了。

這下子問題就來了，如果2000本就算是不錯的話，對於許多每頁單價低的書來說，可能都是賠錢貨哩？如果再把這幾年來技術人員西進大陸的趨勢算進來，會不會其實2000本都還是樂觀的期望？果真如此，也許我得好好規劃未來了，呼！

延伸閱讀

同一年行政院主計處自己公布的報告中，都沒有人數統計的資料，頗為奇怪？
93年的調查報告，一樣沒有依職務別的人數統計資料，但有退職、新進人員比率之類的數據，也許可用來推算。
94年的調查報告。
95年的調查報告。

書介--閩南方言與古漢語同源詞典

2007-11-08T12:08:00.000+08:00

我自己對於閩南語的書寫非常有興趣，基本來說，閩南語不過就是中文的一套讀音，所以理論上閩南語應該是可以用中文寫出來的。基於這樣的理由，我個人極不贊同以羅馬拼音為優先，書寫閩南語，而是應該先找出來我們所講的音究竟是中文中的哪一個字，實在真的找不到字，才尋求其他的方法，而不是一開始就捨棄中文字，採用音標的作法。

由這樣的起點出發，我在網路上找了許多的資料，不過大抵上都較零散，直到有天從圖書館借來了《詞典的兩個世界》一書，其中楊照先生介紹了一本《閩南方言與古漢語同源詞典》，趕緊買來一看，如獲至寶，正是我所企望對於閩南語書寫即有幫助的一部詞典。

這是由廈門大學的學者林寶卿經過多年研究、考據所編著而成，除了讓讀者可以知道平常所講的詞彙，譬如說「虬（讀qiu）毛」（捲毛的意思）、「中晝（讀dao）」（中午）、「下晡（讀boa）」（下午）等倒底怎麼寫以外，更透過古代典籍，找出古時候這些字就是這樣用，而不只是作者隨便找個閩南語讀起來相近的字來搪塞而已。透過這些考據，同時也可以發現閩南語保存了許多古漢語的用字與詞彙，這也是這本詞典的名稱源由。

要提醒的是，這是一本簡體書，不過在詞典中會列出繁體寫法。另外就是這本詞典的檢索方式，是依據福建省所提出的羅馬拼音法，查閱時可能要先習慣一下。不過我自己是把翻閱這本書當成趣味，隨性所致瀏覽，總是會驚呼「原來是這個字！」。

Photoshop問答：筆刷的opacity（不透明）與flow（流量）的差別？

2007-10-18T00:19:00.000+08:00

我並不是Photoshop的使用者，不過因為剛好同仁有發生這樣的疑問，所以就想找找看有沒有答案。如果您在Photoshop中單獨設定筆刷的opacity（不透明）與flow（流量），也就是譬如說保持不透明為100%，變動流量的值；或是保持流量為100%，然後變動不透明的值，就會發現好像兩者的效果是一樣的，那麼為什麼要有不透明與流量兩種值呢？

為了解答這個問題，所以我查閱了相關的說明，終於瞭解了這兩個值的差別。這兩個值其實是以不透明為主，設定的是筆刷繪製結果的不透明度。不透明值越小，筆刷繪製的結果就越透明。那麼流量是甚麼意思呢？根據Adobe官方網站上Photoshop CS3的說明文件，流量的意義如下：

流量
設定您在某個區域上移動指標時套用顏色的速率。當您在某個區域上繪畫時，如果按住滑鼠按鍵不放，色彩量就會依據流量速率而逐漸增加，直到達到不透明設定為止。例如，假設您將不透明度設定為 33%，流量也設定為 33%，那麼您每移到某個區域上一次，上面的顏色就會以 33% 的比例趨近於筆刷顏色。除非您放開滑鼠並且再次在該區域上運用筆觸，否則總和將不會超過 33% 不透明度。

講明白一點，就是在不放開滑鼠按鈕的前提下，筆刷每次經過同一區域時，該區域往不透明值前進的速度，而這個速度是以剩餘距離的百分比來表示。也就是每多經過同一區域一次，就會以該區域目前的不透明度與不透明值的差距，乘上流量所設定的比例增加不透明度重新繪製（注意，是重新繪製，也就是當成該區域之前沒有用筆刷繪製過，然後以筆刷顏色套用計算出來的不透明度繪製）。所以如果按住滑鼠來回移動筆刷，重複經過的區域就會越來越接近不透明值而顯得越來不透明，最終趨近於不透明值。

舉個例子來說，如果不透明設定為50%，流量設定為20%，那麼不放開滑鼠按鈕用筆刷經過某一個區域第一次時，該區域的不透明度（一開始就是0%）距離50%為50%，所以不透明度會增加50%*20%，也就是10%。如果再經過一次，因為現在不透明度是10%，所以距離50%為40%，所以不透明度就會再增加40%*20%，也就是8%，變成以18%的不透明度重新繪製該區域。依此類推，如果再經過一次，目前的不透明度18%與50%的差距為32%，所以不透明度就會再增加32%*20%，也就是6.4%，變成24.4%。依據這樣的推演，每次經過同一區域，不透明度就會距離50%越來越近，最終趨近於50%。也正因為流量所描述的是接近不透明值的增量，所以稱為流量。示意圖如下：

以下的圖就示範了上述的過程（請觀察多個圓交疊的部分）：

多次的變化圖如下，你可以看到不透明度逐漸增加，最終趨近50%的效果：

要注意的是，滑鼠按住不放來回經過同一個區域，和在原地點點按滑鼠的效果是不同的。以下的圖仍然以不透明度50%，流量20%為例。若是在原地點按滑鼠，第一次點按時不透明度一樣為差距50%*20%，就是10%繪製。但第二次點按時，仍然是以10%的不透明度繪製，但是因為該區域的顏色已經因為上一次點按用筆刷繪製了10%不透明度的顏色，所以已經比尚未繪製前更接近筆刷的顏色，第二次繪製後，就會又更接近筆刷的顏色。依此類推，如果多次點按，最終就會趨近筆刷的顏色：

以下是多次點按的變化，你可以看到大概5次點按後就是50%的不透明度，一直點按下去，就會變成筆刷的顏色：

所以如果只是繪製一次，就完全看不出來不透明與流量的意義，甚至因為互換兩個設定值的結果看起來都一樣，使得許多人以為不透明與流量的作用相同了。

延伸閱讀：

Photoshop Brush Tutorial: Brush Tool Options：這篇文章對於opacity與flow的說明其實並不完全正確，不過卻可以引導思考出其中的意義。
Photoshop CS3 Help繁體中文版：工程界說的好，要解決問題，最簡單的方法就是RTFM（Read The F*cking Manual）。

GET、POST與cache的關係

2007-10-03T11:10:00.000+08:00

在大部分的AJAX書籍裡頭，只要解說到XMLHttpRequest的open方法時，一定都會提到GET與POST的差異，不過大抵上講的都是GET會把參數直接加在URL上，使得一方面會在瀏覽器的網址列上洩漏傳遞的資料，另一方面則是會受限於URL長度的限制，而無法傳遞較大量的資料。但是GET與POST還有一個很關鍵的差異，在大部分的書上都沒有提到，就是GET的response會被cache下來，但是POST不會。

由於cache的基準是以URL為對象，如果傳遞的參數不同時，很難發現cache的存在。但如果URL相同時，就可能造成程式出現靈異現象。舉例來說，我的同事剛好在撰寫一個AJAX版本的聊天室範例，由於純屬示範性質，所以採取很簡單的作法（事實上有許多上線運作的聊天室也用同樣的方法），將參與聊天的發言不斷增補到一個文字檔尾端，而用戶端就透過AJAX機制，定時向伺服端取回儲存發言的文字檔，顯示在瀏覽器上的聊天區域。

假設這個文字檔就叫做chat.txt，你可以想像會發生甚麼事。由於我的同事使用GET方式叫用XMLHttpRequest的open方法，並且URL參數都指定為"chat.txt"，所以每次取回的都是cache中的chat.txt，造成不論如何發言，瀏覽器上顯示的結果都沒有變化，好像剛剛的發言石沈大海一樣。

有些人為了解決這個問題，採用了一些小伎倆，例如將URL參數改為傳入"chat.txt?"再加上日期時間，強迫URL每次都不一樣，而使得瀏覽器不會傳回cache中的檔案。這樣的作法固然有效，不過最簡單的方法，就是將GET改成POST，就一切正常了。

GET與POST的這點差異，主要是因為GET原始設計的語意，就是單純的查詢，只要是相同的查詢條件（傳遞的參數內容），不論查詢幾次都應該傳回相同的結果。由於這樣的原因，瀏覽器端的實作就會把GET的response給cache下來。反觀POST，原本的語意就是將資料遞送回伺服端處理，所以瀏覽器就不應該自作聰明，不將資料傳回給伺服端而逕行取用cache。

GET與POST的這點差異雖然很不容易發現，但在除錯環境困難的AJAX程式開發中，卻很可能讓程式員耗費時間精力，找不出問題在哪裡。

延伸閱讀

W3C中有關GET與cache的關係說明。
W3C中各種HTTP method的解說。

日文翻譯的陷阱

2007-08-16T12:25:00.001+08:00

日文因為使用了大量的漢字，所以對於我們來說，有了幾分的親切感。不過也正因為如此，埋藏了許多陷阱，有時候不知道對應的適當中文詞彙時，很可能就會直接用日文漢字草率了事，但實際上中文讀者看到了這個由漢字組成的詞彙時，卻無法從漢字聯想到真正的意思。我自己不懂日文，以下斗膽舉例，如有謬誤，還請指導。

有些詞彙雖然和中文不同，但還可以猜出意思的，例如「16進制」，中文通常說「16進位」。但有些詞彙單看日文，就比較難猜出意思。比方說，在CSS的書籍中，會出現「段組レイアウト」。「レイアウト」是外來語layout的日語拼音，在CSS中自然指的是版面設計，那麼「段組」是什麼呢？「段」是colunm的意思，「組」就是排版，整個「段組レイアウト」指的就是多欄版面設計。如果直接用日語譯為「段組版面」，大概就很難讀懂意思了。

當然，有些詞彙因為崇日風尚，大家習以為常，也就懂意思了。像是濫用程度最高的「達人」、「殘念」、「萌」等等，雖然如此，使用上我認為還是有斟酌之處，因為許多詞彙我們未必真的理解日文精確的含意，比方說「達人」和「玄人」是有差異的，如果人人皆稱「達人」，可就怪了，哪有那麼多「達人」？

最可怕的是那些讀起來好像完全正確，但其實意思錯誤的日文漢字，譬如說日文中橫的稱為「行」、直的稱為「列」，與中文的直行橫列相反，如果翻譯時不細心，直接照用，那就麻煩了。這特別是在資料庫或是Excel等大量出現表格的文章時最為嚴重。

你可以說我古板、或者民族情結作祟，我很不喜歡中日文夾雜，用在書名一兩個字勉強也就罷了，如果內文行文之間，充斥日文詞彙，我總是覺得渾身不舒服，讀起來腦筋不斷打結。當然，我不排除也許有些詞彙日文其實是真正保留了中國古文，而我們現代的用法才是瞎搞，這就很難說了。

BrowserCam：多平台多瀏覽器網頁測試服務

2007-08-04T17:06:00.000+08:00

我的工作裡有些時候必須處理翻譯書的螢幕抓圖，尤其是一些跟網頁設計有關的書籍，常常會提到同樣的網頁在某一種平台上的某一種瀏覽器上會有什麼樣的問題，然後就秀出一張執行畫面。不過你知道事實上多數人都不可能有那麼多種機器在手邊，也不大可能還安裝有古時候的瀏覽器，所以一旦需要抓取這些圖的時候，如果只是Windows＋Linux也還好，但若是需要Mac，我就沒轍了。還好，最近剛好看到BrowserCam網路服務，可以針對指定的URL抓取在多種作業系統下不同瀏覽器的多種版本的畫面。

以下就是這個網站在幾種作業系統下的瀏覽畫面：

要提醒您的是，BrowserCam是付費的網路服務，原本的用途是讓網頁開發人員測試自己所設計的網頁，以便確認不同平台上的使用者都可以看到正確的畫面。不過如果您只是需要抓幾個圖的話，可以申請24小時200張圖限制的試用帳號，利用一天的時間把所需要的畫面抓好。另外，付費使用者最大的好處就是可以透過VNC實際登入到提供服務的機器上，進行像是拉下網頁上的選單之類必要的操作後再抓圖，更是方便許多。

延伸閱讀：

如果需要在自己的機器上實驗不同版本Internet Explorer的畫面，可以利用善心人士準備好的Internet Explorer獨立運作（Standalone）版，在本機上同時執行多個版本的IE。
如果需要在自己的機器上實驗不同版本的Firefox的畫面，則可以利用原本為了行動碟設計的Firefox可攜（Portable）版。

SQL Server仍舊維持霸主地位

2007-08-03T11:29:00.000+08:00

從SD Times的報導看到，依據BZ Research在2007年6月針對軟體開發經理人員進行的2007 Database and Data Access, Integration and Reporting Study調查顯示，微軟的SQL Server仍然是資料庫市場的霸主，如果單純以是否使用某種資料庫產品來回答，佔比如下圖：

你可以看到SQL Server遙遙領先，不過這裡的數字包含了過往的舊系統。如果以最近完成的專案所使用的資料庫系統來統計，就如下圖所示：

上圖中一樣把包含舊系統的數字列出來，以方便比較。你可以看到SQL Server仍然是大幅領先，而Access則明顯得落後Oracle了（我知道，拿Oracle和Access相比有點怪），MySQL就偏低了。

根據報導中所說，SQL Server勝出的原因其實大家應該都猜得到，就是簡單易用，而且和開發工具有高度的整合。因此，除非認定Oracle才是企業級資料庫業界標準的受訪者以外，大多會選用SQL Server。另外，有些受訪者認為中小型企業普遍裝置有SQL Server，而大型企業則會有Oracle，因此開發專案時就會遷就企業現有的資料庫系統。值得一提的是，部份受訪者也表示考慮用MySQL替換掉Oracle。

有趣的是當問到選取特定資料庫系統的考量因素時，熟悉度、信賴度、開發成本低、佈署成本低等自然不在話下，但是傳統觀念中的「記憶體耗用程度低」反而只有3.1%的人關注，而「容不容易得標」也只有1.9%的人會考量，可見得大多數的軟體人員最重視的還是專案能不能儘速完成哩。

書介：版面設計概念學習東西軍

2007-08-03T10:23:00.000+08:00

如果您對於版面設計有興趣，或者是和我一樣工作上需要與美術人員溝通，想要自修一點版面設計的概念，那麼來自日本的《設計的文法──忍不住想動手的平面設計書》與來自美國的《寫給大家的平面設計書》這兩本寫給非設計科班出身的讀者看的書應該就非常適合。

這兩本書相同的地方在於把平面設計本身無關設計天份而能規則化的部份，透過簡單扼要的歸納說明與實際的範例展示，讓讀者能夠確實的體會。而事實上，兩本書在這個部份所提出來的設計規則也極為相近，這當然不是什麼奇怪的事，因為談的是通則，而不是個別設計師的獨門創意，如果差異很大，自然無法成為大家可以依循的常規了。

雖然談的主題相近，不過兩本書還是有些不同之處。首先，《設計的文法──忍不住想動手的平面設計書》一書的範例比較貼近實際成品，而《寫給大家的平面設計書》中的範例則比較像是單純為了說明而設計；另外，前者也包含了比較多長篇文章排版的概念，而後者焦點著重在單頁文件的設計，所以如果您有製作書籍的需求，那麼我就會比較推薦前一本書，但如果只是設計一些宣傳單、小海報，那麼後一本書就很足夠。

另外還有一點很重要的是，由於文字天生的差異，日文與中文的相似性使得第一本書對於文字處理的相關主題能讓讀者有比較直覺的理解，因此閱讀上與實際應用上會比較直接。當然，如果你預算允許，我還蠻建議兩本書都買來翻一翻，畢竟同樣的事情，未必只聽一位老師就能懂，同時接受東西方精華也不錯啊！

延伸閱讀：

《設計的文法──忍不住想動手的平面設計書》原書為《デザイン・ルールズ》，作者為伊達千代與内藤タカヒコ。
《寫給大家的平面設計書》原文書為Non-Designer's Design Book, The, 2nd Edition，作者為Robin Williams，她同時還著作有一系列給非設計科班出身的人閱讀的相關書籍。

編輯不願面對的真相：拖稿原因揭密

2007-07-19T10:50:00.000+08:00

從事編輯一段時間後，一定會遇到的就是拖稿，你一定很想知道為甚麼，而你的主管更是需要你給的理由，於是你就會從譯者或是作者口中聽到一些說法：

「快要寫完了，晚上就會寄給你。」
意思就是你下班後我可能就會寄給你，但明天上班時答案才會揭曉。
「已經寄出去了，你沒收到嗎？」
別先懷疑作譯者，很可能他用的附件檔案格式被你的MIS英勇的擋掉了。
「你給我的FTP不知道為甚麼連不上去？」
先自己連連看吧，況且作譯者未必熟悉FTP。
「我已經燒成光碟到郵局寄出去了！」
你只好等個三天再說囉，或是急的話自己請快遞去拿，別郵寄。
「我硬碟掛點了，得等我修好重灌！」
「我中毒了，開不了機！」
以上兩種，除了相信，你不大能做些什麼，或者你去幫他重建系統？
「我要出差，下週回來才能寫稿。」
「我家人生病，要去照顧他。」
以上兩種，只能相信，硬要去查證是沒有必要且魯莽的行為。
「嘟..........」、「您撥的電話未開機」、「將為您轉接語音信箱」、「您撥的電話號碼是空號，請查明後再撥」
這一種就表示你已經達到編輯的最高境界，把人給蒸發掉了，因為聯絡不上，你永遠不知道發生了什麼事，甚至想把每一份報紙的社會新聞都詳細看過，確認沒有任何意外。

對了，經過上述各種狀況拿到了珍貴的稿件時，可能還有難關等你突破：

壓縮檔打不開？
壓縮檔打開裡頭空空如也？
壓縮檔打開裡頭好豐富，但都不是你要的稿件？
果然是稿件，咦，沒寫完？
收到一張空片？
收到一張DVD電影？
收到一張無法讀取的光碟片？
收到沒有夾檔的mail？

相信我，以上這些我全部都遇過，不過我相信這都是意外，我也當過SOHO、也當過員工，將心比心。

加油啊，稿件尚未完成，大家仍需努力！

Firefox使用者超越IE指日可待？

2007-07-17T16:14:00.000+08:00

根據O'Reilly Radar上的Update: Firefox vs. IE in O'Reilly Network Logs一文指出，依據O'Reilly Media這個網域的log檔資料分析，造訪該集團網站的使用者中，使用Firefox的人數已經以一個百分比之差超過IE的45%了，這是從前年的19%對75%到去年的35%對54%一路攀升到今年的結果。

當然，造訪O'Reilly網站的族群多半是技術背景顯然有絕對的影響，不過Tim O'Reilly在該文後續的回應中也指出，O'Reilly一向都是先驅，過去出版過的許多書籍也都是引領潮流，因此這項分析結果具有很重要的指標。雖然Firefox是我非常喜愛的瀏覽器，不過我個人認為，只要大多數的一般使用者在使用時會遇到狀況，例如MSN Messenger中的連結還是會開啟IE，這就會成為障礙，使得Firefox很難跨到一般使用者的領域。

在該篇文章的後續報導Opera and Safari in O'Reilly Network Logs一文中，也分享了其他品牌的瀏覽器佔比，其中較特別的是Opera 9推出後反而下降，同時期Safari則是往上攀升，成為第三品牌。有網友回應表示，Opera 9剛好遇到了IE7，而既然Opera 9的一些功能IE7都有，所以可能有些Opera的使用者反而回籠到IE的懷抱，才會導致這樣的結果。

無獨有偶，在Tim O'Reilly的文章之後沒有幾天，法國的XiTiMonitor發表了Firefox narrowly misses 28% use in Europe,Internet Explorer under 70%調查報告，其中Firefox在2007年七月第一周在歐洲的市佔率已經從去年同期的21.1%節節上升到27.8%（IE則是從73.3%下降至66.5%）。特別的是，在少數國家Firefox有高達45%以上得佔有率，像是斯洛法尼亞為47.9%，芬蘭則為45.4%，而根據CNET的（Firefox歐洲佔有率提高蠶食微軟 IE）報導中指出，Mozilla Europe總裁Tristan Nitot認為這些佔有率超高的國家主要是因為有良好的社群支援，這也指出了Firefox推展主要的障礙。

在這一篇文章最後也提到了全世界的Firefox佔有率狀況，都反應了Firefox上升的趨勢，其中大洋洲的佔有率28.9%最高，而亞洲14.3%最低。

同一時間兩篇文章，一篇代表了極富希望的前景，一篇代表了樂觀的現況，無論怎麼看，似乎Firefox都有極可期待的未來，也許這中間的關鍵就在於Firfox的親和力吧，我想。

延伸閱讀：

XiTiMonitor對於Firefox 2與IE7在各自陣營佔有率的報導：Browser War: FF2 pulls ahead of IE7 in Europe

越來越多開發者開發的軟體不是在Windows上跑？

2007-07-17T15:35:00.000+08:00

根據Evans Data Corporation的North American Development Survey指出，已經有連續兩年受訪的開發人員在回答所開發軟體的目標作業系統時，Winodws平台的佔比有明顯的下滑。以下是根據該報導提供的數據所繪製的treemap：

你可以看到整個Windows平台完全不意外地佔了超大一塊，而Linux比去年底的調查提昇了2%，我比較好奇的是Others到底包含了哪些作業系統？

延伸閱讀：

相關報導：Evans Data: Developers Trending Away From Windows

崔健海洋音樂祭壓軸演出

2007-07-09T02:32:00.000+08:00

一直到凌晨回到家，都還覺得像是做夢，等待了這許多年，終於在現場聽到、看到老崔。以下影片品質不佳（手機拍攝），但純粹表達心中對於一位搖滾漢子的崇敬，華文世界搖滾第一人--崔健。

結尾曲（一無所有）的結尾部份及安可曲（解決）開頭

安可曲也是整個session及海洋音樂祭最終曲（花房姑娘）

記憶所及，昨天的演唱曲目如下：

飛了
新長征路上的搖滾
寬容
混子
像一把刀子
一塊紅布
滾動的蛋
飛越那一天
一無所有

安可曲：

解決
花房姑娘

晚間10:35登場，足足唱滿約一個半小時，7/9 0:00結束。

編輯作品：Ruby on Rails 專業網站案例實作

2007-06-09T00:52:00.000+08:00

會簽下這本翻譯書，最早的想法其實是很簡單的，隨著Rails的熱潮不減，市面上一定會有一堆入門書。但是根據我自己的經驗，看完入門書之後還是寫不出程式的大有人在，這時若是能夠有好的臨摹對象，就能發揮很大的幫助。這本書就是以從無到有開發出一個網路書店為主軸，一步步帶領讀者完成。主要的特色如下：

徹頭徹尾強調Test-Driven Developement（TDD）：即便你對於Rails沒有太大的興趣，也可以藉由本書了解TDD的概念與作法，更遑論TDD本來就是Rails框架不可或缺的要素。
善用pluggin組合應用程式：Rails本就強調能不自己寫的code就不要自己來（Don't Do it Yourself，DDY），而本書在為網路書店增添像是標籤等功能時，就本著這樣的理念，直接採用現成的pluggin，搭配Rails神奇的ORM魔法，就把新功能兜起來了。
實務的主題：為了讓網路書店邁向國際，這本書中有單獨的章節討論應用程式的localization，可能受到中國這個巨大新興經濟體的影響吧，書中的舉例正巧就是中文化，更值得台灣讀者一讀。

雖然據我的觀察，台灣書市似乎並沒有像是美國市場那樣發生Rails的熱潮，但就網頁開發這部份，open source和.NET等商業平台可說是勢均力敵，而且Rails大有吸取PHP人口之勢，未來應該還是頗有希望。

延伸閱讀：

本書原文本為Beginning Ruby on Rails E-Commerce: From Novice to Professional
Thegiive對本書中譯本的評論。

如果您想出書？

2007-06-09T00:19:00.000+08:00

因為工作的關係，我收到過許多投稿的信件，這些信件多半都很簡潔，大概就是：

您好

我是XXX，我想寫一本XXX的書，不曉得貴社有沒有興趣出版？

說實話，收到這樣的信件，我是無從判斷我們公司會不會有興趣的，原因很簡單，資訊實在太少了。如果您也想投稿的話，我建議您準備好幾項資料（格式不拘）：

清楚描述對象：是寫給初學者看的？業界人士看的？學校上課用的？哪個科系的學生適合？千萬不要告訴我「就是寫給想看這個主題的人看的」。如果能夠進一步說明這樣的人為甚麼需要看這本書，那就更棒了。
具體說明差異：出版商畢竟就是「商人」，因此在競品環伺的情況下，你的這本書和別人的書有什麼不同就很重要了。除了嶄新主題可能沒有競品外，最好能夠具體講出來你這本書的特點，但是記得，要「具體」！如果你認為你的書是最容易看懂的書，就要讓出版商知道為甚麼？也許是因為你是採用圖解的方式，每一頁至少有一張示意圖；又或者你說你的書是範例最多，那就算給出版商看你的範例的確比別的書多；也可能你說你的書是市面上最完整，那就把你的書有而別人的書沒有的題材列出來。總之，就是要「具體」。
二到三章樣章：光靠以上的資料，出版商也許可以認同這是不錯的企劃，但是卻無從判斷你是否真的寫的出來，所以最好可以準備好樣章，這遠比你將多采多姿的傲人學經歷搬出來要有效的多。

最後，你可能有個疑問，給了這麼多的資料，會不會被出版商給抄去，賠了夫人又折兵呢？我的看法很簡單，如果你的書這麼容易就被抄去，我想出版商出版的興趣大概也不會太大，懂嗎？

編輯作品：SQL語法範例辭典

2007-05-24T12:19:00.000+08:00

每一個開發人員最需要的就是一本好查閱、看得懂的參考手冊，尤其是像是SQL這種每個人都以為自己學過，卻常常遇到問題的語言更是如此。我一直覺得要找好的工具書，日文書絕對是首選，不論是各種繁雜的索引，高閱讀性的版面設計，日本人在這方面都是首屈一指。這本書就是譯自日文，雖然是2003年的書，但對於版本變動沒有那麼迅速的資料庫伺服器來說，我覺得仍然是夠用的。

本書包含了MS Sql Server、Oracle、MySql、MS Access、PostgreSQL、DB2在內，而且內文中均有明顯標示特定功能適用的資料庫系統。除了基本的SQL語法以外，本書還包含像是T-SQL、PL/SQL等程式設計的語法參考，另外，對於應用程式的開發者來說，本書也包含有程式設計介面（API）的詳細資訊。更棒的是，在這本書的最後，包含有一個SQL常見問題的解答，將較常遇見的SQL問題列出來，並提供解決方案與解說，非常實用。

如果你曾經看過體積厚重、文字密密麻麻不知如何閱讀的SQL in a Nutshell，一定會被這本小巧精緻的參考手冊（全書含索引600頁）所吸引，即便是放入包包也不佔空間，而且幾乎每一頁都有範例，完全不必擔心只能靠文字意會有看沒有懂得窘境，如果你是DBA、應用程式開發人員或是MIS，都應該買一本保心安啊！

延伸閱讀：

本書原文本為《改訂新版 SQLポケットリファレンス (単行本)》
另外一本可能沒有太大幫助的口袋書： SQL Pocket Guide , Second Edition

我的nokia 6288手機使用經驗談

2007-04-19T14:36:00.000+08:00

MySQL市佔率大有斬獲？

2007-03-27T17:35:00.000+08:00

在SD Times上面看到，根據Evans Data Corporation的調查報告指出（新聞稿在此），過去兩年內開發人員使用資料庫的比例從32%提升到40%，其中MySQL所佔的比例增加了25%，值得注意的是調查顯示2006年秋季在北美有65%的開發人員採用開放原始碼的工具，因此在新聞稿中推斷MySQL將會持續攀升。

其實這樣的結果並不令人意外，光是PHP的高市佔率，就可以幫MySQL卡下不小的位子，加上這給年來多種XAMP（我指的是XP/Linux+Apache+MySQL+PHP）的簡易伺服器軟體包風行，許多人不知不覺就用了MySQL，高市佔率是很正常的結果，但我比較思考的問題是，這樣的市佔率似乎沒有在書籍的銷售上反應出來？以中文書來看，脫離PHP而專門講述MySQL的書多半沒有好的銷售成績。

我心目中有個答案是許多不小心使用了MySQL的人，只希望MySQL可以做出正確的結果就好，至於MySQL的進一步探究，也許並不那麼重要？

編輯作品：網頁程式駭客攻防實戰--以PHP為例

2007-03-23T22:55:00.000+08:00

近一兩年來，網頁開發無疑是技術書籍領域中獨占鰲頭的主題，不過有個有趣的現象，就是大部分的書籍都只是教導如何開發網頁程式，但是卻很少著墨在如何開發高安全性的網頁程式。本書就是針對這一點，以實際的程式碼來展示各種可能的漏洞與防禦對策。

本書一開始概略介紹網頁安全的觀念之後，便本著「不了解駭客就不可能防駭」的精神，以一個尋常的留言版程式，透過實際的攻擊，示範大家隨手都可能寫出來的程式裡，淺藏著多少的漏洞，凸顯網頁程式與一般應用程式在面對安全性時本質上的劇烈差異。

接著，作者彙整了14種駭客的攻擊手法一一詳解，並提出可能的對策。更重要的是，作者還舉出許多活生生的例子，都是在開發人員以為已經徹底封鎖駭客的攻擊之後，仍然存在的許多漏洞，更有許多知名軟體曾經範過的疏忽，再次提醒讀者仔細檢查程式的重要性。

經過上述的震撼教育後，作者再透過telnet直接連上HTTP伺服器直接溝通的方式，赤裸裸展示了前述各式攻擊手法運作的實況，同時也讓讀者瞭解到瀏覽器並不能限制駭客的攻擊方式，只要透過telnet連線，駭客更能夠以各種令人驚嘆的手法進行攻擊，切勿以為瀏覽器的限制可以成為一道值得信賴的防線。

全書到了這裡，算是已經完全體會到了駭客的無孔不入。因此，本書接著提供了多種檢查漏洞的方法，讓讀者可以針對自己所開發的程式，滴水不漏找出所有可能存在的漏洞。除此之外，作者也提供了兩個防駭工具，可以透過程式自動找出漏洞，不但可以提昇效率，也可避免人為的疏忽。

本書雖然是以PHP為主要討論的對象，不過書中所討論的主題，大體上也都適用於ASP、ASP.NET、JSP等這類伺服端的開發技術。對於網頁開發者來說，本書應該是迄今為止對於網頁程式安全性主題探討的最全面的中文書，頗值得一讀。

延伸閱讀：

本書日文原著《PHP サイバーテロの技法　攻撃と防御の実際》
本書日文原著作者支援網頁。

書介：Ajax Patterns and Best Practices

2007-03-18T00:13:00.001+08:00

由於AJAX的日漸火紅，越來越多的網頁開發人員都在嘗試套用這項技術的最佳方法。但除非您使用的是以伺服器端為主的應用程式框架（framework），否則就得自行透過JavaScript負責與伺服端暗通資料，並且操控瀏覽器端的資料與外觀。因此，JavaScript漸漸從用戶端的輔助角色，躍升成為整個網頁應用程式的主要核心。

如果發揮到極致時，整個網頁應用程式在用戶端就只剩下一個空的HTML網頁，加上建構網頁內容並擔負程式邏輯的JavaScript，以及伺服器端負責擷取資料與傳送資料的簡單程式。正由於如此，整體程式架構的好壞，就不只是會不會使用XmlHttpRequest物件的問題而已，Ajax Patterns and Best Practices這本書就是希望能夠幫助大家解決這個問題。

本書透過作者所彙整的9種pattern，提出建議的解決方案，所使用的工具在用戶端就是以JavaScript為主軸，而伺服端則以C#所撰寫的ASP.NET 2.0網頁或者是Java Servlet為例，主要的內容如下：

第1章是簡單介紹AJAX的淵源與要素，並且比較相關技術，如果您並不是AJAX新手，大可跳過這一章。
第2章主要是作為後續各章的基石，透過factory pattern建立了一個產生XmlHttpRequest物件的跨平台機制。在後面的章節中，凡是需要與伺服端溝通的部份，都是透過這一章的機制來完成，不需處理XmlHttpRequest物件的細節，而將焦點集中在每一章所要解決的問題上。
第3章處理的是content chunking pattern，簡單的來說，就是將網頁區分為單獨的個別區塊，並透過AJAX技術載入個別區塊需要展示的內容。
第4章提出的是cache controller pattern，主要解決的是如何為AJAX建立快取機制，使得AJAX的運作更有效率。
第5章的permnutations pattern讓您可以建立一個資源封裝的機制，使得網頁應用程式可以依據用戶端的特性，以最適切的資料格式傳回同一份資料，確保用戶端可以為使用者展示正確的結果。舉例來說，如果用戶端使用的是WAP瀏覽器，那麼如果可以傳回特製的格式，就會比傳回一般的HTML格式要好，也能保證用戶端能夠閱讀結果。
第6章可以視為是第3章的變化，談的是如何讓網頁中不同的區塊產生互動的機制，也就是當某個區塊因為使用者的操作或是其他原因造成狀態的變化時，讓相關聯的其他區塊也能夠產生對應的改變，這樣的問題稱為decoupled navigation pattern。
第7章的presentation morphing pattern則是針對同樣的一份資料，讓它能夠在網頁上依據不同的目的或是功用，以不同的面貌同時呈現，並且可以在資料有所變動時，同時更新個別面貌的展現結果。舉例來說，當你透過表單來讓使用者輸入資料時，如果能夠同時以預覽的方式展示目前輸入的資料未來展示的樣子，就能讓使用者更確信輸入資料的正確性與適當性，而不需要等到資料輸入完畢送到伺服端後才發現錯誤而重新修改。
第8章要解決的是與伺服端保持連線傳輸資料的問題，稱為persistent communication pattern，股票行情顯示的網頁就是最典型的範例。
第9章的state navigation pattern則是對於如何為AJAX取得的內容建立瀏覽紀錄提出可能的解法，而不會在使用者按下熟悉的『上一頁』按鈕時，產生出乎意料的結果。
第10章透過infinite data pattern處理伺服端會送來大量資料的狀況，建立分段接收與展示結果的機制，像是搜尋網頁就是大家耳熟能詳的例子。
第11章提出了REST-based Model View Controller pattern，其實就是建立marshup的機制，讓網頁可以彙整外部來源的資料，重組後展示在網頁上，就像這些資料是從單一伺服器傳回的一樣。

整體而言，本書所提出的問題與解法頗具參考價值，不過作者本身的解說能力我個人覺得有頗大的進步空間，同時所下載的原始碼也很散亂，許多與書中的內容不符合。雖然如此，我還是很建議想要將AJAX列為網頁應用程式開發主要工具的程式員都可以讀讀這本書，未必要採用作者提出的程式碼，但參考一下其中的想法，應該也會有很大的幫助。

延伸閱讀：

本書作者的blog：BlogJacks
本書中文版已經出版。

恭賀新禧！

2007-02-17T13:24:00.000+08:00

新年到，派我兩個女兒跟大家拜年！

延伸閱讀：

我的家庭網站

Eclipse攻陷Java開發社群？

2007-02-03T13:35:00.000+08:00

根據SD Times在Two-Thirds of Developers Now Use Eclipse一文中所披露，由BZ Research所進行的Eclipse Adoption Study調查中顯示，Eclipse的採用率年年升高，從2004年九月的53.9%躍升到2005年十一月的62.5%，2006十一月又小幅提升到66.3，往後加上Borland的JBuilder轉向Eclipse平台，後勢絕對看漲。

根據報告中顯示，受訪者中超過六成是因為成本低廉、開放源始碼、或者是外掛繁多而採用Eclipse，所以我推測如果要花錢去購買同樣建構在Eclipse上的JBuilder，除非加上了什麼殺手級外掛或是整合功能，不然開發人員應該也很難說服老闆撥下預算買一個大家都不需要花錢的開發環境吧？

這份報告美中不足的一點是受訪者是以SD Times的訂戶為對象，並使用email方式調查，所以對於有效問卷的受訪者背景沒有明確的說明，這是比較可惜的地方。

延伸閱讀：

從《The State Of Web Development 2006/2007》看網頁開發概況

詞辨：type selector與class selector

2007-02-02T23:47:00.000+08:00

type selector與class selector也是很容易因為翻譯之後而弄混的兩個詞，有些人不知不覺中就把這兩個詞都翻譯為「類別選擇器」，使得文章讀來意思完全混淆。

若是依照這兩個詞的原意，type selector是依據HTML標籤（tag）種類來選擇要套用樣式的元素、而class selector是依據class屬性值來選擇要套用樣式的元素，其中HTML標籤可以當程式元素的資料型別（type），因此我個人建議type selector可以譯為「型別選擇器」，而class selector就譯為「類別選擇器」。

當然，您可能會覺得型別和類別不是也容易混淆？但首先，使用兩個不同的詞彙，至少在同一篇文章中可以明確表示這是兩個不同的東西。其次，如果以人來比例，你可以用膚色來分類，也可以依據個性來分類，因此「型別」就可比擬為「膚色」，而「類別」則可比擬為「個性」。所以每一個人只會屬於某一種膚色，但卻可以歸屬於多種個性，就如同頁面上的某個元素只會屬於某一種標籤型別，但卻可能歸屬於多種類別一樣。

合約到期的注意事項

2007-02-02T13:20:00.000+08:00

在之前的文章（圖解最後一刷後半版稅計算法）中曾經提到合約到期時的議定處理方式對於作者或是譯者的版稅收入有影響，一般的作法會在合約到期前另外簽訂一份終止合約書，載明合約到期時各項處理事務。今天朋友在整理文件的時候，剛好看到某出版商一份大約七年前的終止合約書，上面有一條條文很有意思，特列列出來給大家參考：

...
三、滯銷書之販售：乙方（指作者）同意甲方（指出版商）得繼續販售本著作物至完全售完為止；惟該剩餘未販售之滯銷書版稅歸甲方所有。
...

簡單的來說，意思就是合約到期後，剩下來所有的書都可以繼續賣，而且不用給作者版稅。這個條款有幾個問題：

此份合約並未載明剩餘書的數量。
通常這種不付版稅的銷售應該是折價出售的商品，求的只是回本，但此份合約也沒有對於售價有任何限定。
如果以小人之心度君子之腹，若是這本書是長銷書，那麼合約到期前再多印一些，甚至到期後還偷印，又不用給版稅，豈不是太棒了？

詞辨：child selector / descendant selector

2007-01-31T19:32:00.000+08:00

在CSS中，child selector與descendant selector在翻譯的時候很容易弄混，許多人會把descendant selector翻譯為「子」選擇器，這就和child selector混在一起了。如果從原意來看，child是選擇指定元素的直接子元素，而descendant selector則是包含了指定元素的子元素、子元素的子元素、....，比如說：

div > p {...}

就是child selector，會將後面的CSS樣式套用在直接包含在div內的p元素上，div與p之間不能夾有其他層的元素。也就是說，只會套用在像是<div><p>...</p></div>這樣的p上。但如果寫成這樣：

div p {...}

就變成是descendant selector，會將後面的CSS樣式套用在所有包含在div內的p元素上，不論p元素與div之間有沒有夾著其他層的元素。也就是說，即便是<div><span><p>...</p></span></div>這樣中間夾了一層span，樣式也會套用到最裡頭的P上。

因此，在翻譯時我比較建議要將這中間的差別區分出來，最簡單的方法就是將child selector翻譯為「子代元素選擇器」，而將descendant selector翻譯為「後代元素選擇器」。

讀書筆記：邏輯思考的技術

2007-01-24T23:02:00.000+08:00

書未讀完，前四章筆記以圖解方式紀錄，如果您有這本書，希望這張圖也對您有用處：

延伸閱讀：

邏輯思考的技術

推：IBM提供Many Eyes資料視覺化服務

2007-01-24T12:28:00.000+08:00

如果您像我一樣對於資料的視覺化有高度的興趣，那麼IBM推出的Many Eyes服務絕對是最大的福音。只要註冊IBM網站帳號，就可以使用這個網站的服務。您可以上載資料，然後選擇想要呈現的視覺化方式，套句Steve Job的口頭禪，Boom，漂亮的視覺化圖形就秀出來了。更棒的是，同樣的資料可以任意選擇多種方式呈現，而且因為是使用Java Applet，所以還可以對視覺化的結果操作（例如加總等等）。

舉例來說，以下就是以之前的文章提到的《政府機構軟體開發環境問卷調查》中整合開發環境問題問卷結果做出的Treemap：

相同的一份資料，可以用另外一種方式呈現氣泡圖：

對於每一個視覺化的呈現，都提供有Blog this按鈕，會幫您產生可以放在您文章的HTML碼，方便您刊登在自己的網站上。另外，網站也提供回應的功能，可以讓網友針對每一個視覺化圖形的意義進行交流（這也表示您所發佈的每一個視覺化圖形都是公開的）。

延伸閱讀：

書介：HTML Dog: The Best-Practice Guide to XHTML and CSS

2007-01-22T19:23:00.000+08:00

如果您已經在使用HTML/CSS設計網頁，但想回頭好好學學HTML或是CSS，卻被市面上許多大堆頭的書所嚇到，那麼就該買下這本書，我保證你絕對不會後悔。

本書和市面上大部分HTML＋CSS的書不同，以採用Web Standard為出發點，所以不會浪費時間和篇幅教你一大堆HTML標籤，然後回過頭來告訴你這個標籤最好不要用、那個標籤不應該用。而是從頭開始就只教你能夠表現文件結構的標籤（其實也就是XHTML），所有以外觀為目的的標籤一律不會出現，也因為如此，所以一開始就是使用CSS調整外觀，照著這本書的路走，要不符合標準也難。

簡單的來說，這本輕薄短小（如果扣除附錄，只有205頁，而且排得很寬鬆）的書非常適合好像已經學過HTML/CSS，但卻又覺得不是學得很踏實的網頁設計人員，只要利用很短的時間，就可以從這本書上補足所有你可能欠缺的根基，絕對划算。

延伸閱讀：

本書作者的網站
相關書籍《跨平台網頁設計--使用Web標準技術》

專職翻譯活的好嗎？

2007-01-21T23:49:00.000+08:00

有朋友問我如果想專職翻譯，到底收入好不好？如果你看過圖解翻譯稿酬一文，那我們就來作個簡單的計算。首先，我個人認為以資訊技術翻譯書來說，要遇到暢銷書本來就不容易，本本都要暢銷更是難，所以我們先把版稅的方式排除掉，專門看稿費的作法。

拿稿費其實就很像是去工地搬磚塊，賺多少就看你能搬多少。假設你一天可以翻譯5頁，每頁稿費200元，一個月粗略估算是20個工作天，那麼整個月理論上的收入就是5X200X20=20,000元。所以如果你可以增加產量，每天翻10頁，就會變成40,000元；如果更厲害些，每天翻15頁（相信我，如果你真的要好好的翻，一天15頁大概是個瓶頸），就會變成60,000元。

聽起來似乎不錯，不過您得注意以下幾件事：

你得自行負擔所有的業務成本，電費、保險、網路、參考書籍等等。
和工地搬磚塊不一樣的是，你不會每個月結算翻譯稿費，得視各家出版社而定，也許全部譯完後、也許多少份量結算一次。
和工地搬磚塊一樣的是，你不一定總是有書可以翻譯。
最重要的是，不會每一本書都是你很感興趣的主題，也不會每本書都寫的好。

當然啦，最後我還是要說，如果你可以樂在其中，這樣的收入其實還不算差，有興趣嗎？趕快來！

延伸閱讀：

[我的神經病.之五]倦勤者言──論不可拿翻譯當正職的 N 個理由

圖解最後一刷後半版稅計算法

2007-01-21T23:25:00.002+08:00

許多朋友看過上次的圖解翻譯稿酬之後，可能都有一個疑問，就是不就永遠都有最後一刷的後一半數量沒有付版稅嗎？為了解釋這一點，我特別又畫了一張圖解末刷後半版稅支付流程，說明大概的方式：

所以你可以發現，合約上對於到期時所議定的處理方式，會影響末刷後半的版稅支付，我看過最扯的合約是連有效期限都沒有約定的，真的！

從《The State Of Web Development 2006/2007》看網頁開發概況

2007-01-17T13:05:00.000+08:00

Sitepoint發表了一份 The State Of Web Development 2006/2007 的調查報告，在這份2006年6/15~7/15的期間針對5,000位網頁開發人員的問卷結果中，可以看到網頁開發技術平台的現況大概是這樣（這份報告要價不斐，我當然沒有財力購買，以下的Treemap圖都是從這份報告的Preview版本中推演而來，圖中區塊大小與顏色都代表佔比，越亮綠佔比越大、越紅佔比越小，越接近白色越接近中間值）：

你可以看到PHP獨占鰲頭，比整個MS（微軟）平台的技術加總還高。
最近火紅的Rails雖然只佔了一小塊，但卻接近ColdFusion。我推估到了現在，過了半年後，Rails的版圖應該大有斬獲。
如果單看微軟平台，會發現ASP與兩個版本的ASP.NET大概各分1/3，但從顏色上可以看出來ASP（白色）略高於.NET（淡粉紅色），顯然升級到.NET平台的行銷工作微軟還有一段路要走。
JSP只與ASP.NET的單一版本佔比相近，得加油了。
Opensources（JSP沒算在內）佔住了半邊天，還有明日之星蓄勢待發，前景可期。

如果問到接下來的12月內可能會考慮採用哪一種技術，那麼佔比的Treemap如下（這裡區塊大小代表佔比，顏色則是把這個問題的數據當成未來實際的市場狀況時，與上一張圖同一技術佔比的差距，越亮綠表示成長、越紅表示衰退、白色持平）：

這裡可以看到，Rails最受青睞，這和這半年來看到或聽到的狀況相符。
可能是Rails帶起的效應，Python也獲得不少注目。
微軟平台則是ASP.NET 2.0最受到用戶的期待，準備採用。
PHP反而有流失的現象，其餘技術則大多持平。

報告上也提到了在考量新技術時，大致上可看出的板塊移動如下圖所示：

很明顯可以看出來，Opensource與MS各自為政，互不侵犯，兩方的開發人員不會轉換陣地，但在各自的版圖中，則有相當的變動。如果從另一個問題的調查結果來看，更可以看出未來可能的趨勢，以下是針對希望哪些技術有更多的資源得到的佔比分配（區塊大小與顏色的意義同第一張圖）：

AJAX是大熱門，不過調查的時間是去年六月，現在AJAX的資源應該已經算是氾濫了。由AJAX效應帶起的就是JavaScript和JavaScript Library的需求，目前看來JavaScript Library書很缺，應該是可開發的方向。
值得注意的是XHTML/CSS，同一份調查中發現有25%的開發者會堅守HTML檔必須驗證通過，而有近60%的開發者會驗證自己的HTML檔，但不一定會修正錯誤，另外有近70%的開發者主要採用CSS做版面配置，因此對於XHTML/CSS的需求自然是趨勢。如果將美國的情況視為台灣的前哨站，那麼台灣今年應該會展現一波需求才是。
PHP雖然已經有許多豐富的資源，但這裡的需求仍然很高，很可惜沒有進一步調查，不然我挺好奇大家的需求是什麼？
你也可以看到Opensource總和的需求極高，一方面反應前面看到Opensource佔市場一半的局面，另一方面可能也展現了Opensource的技術文件量的問題。
另外可以發現到Flash的需求也不小，尤其Flex聲勢不小，其實還蠻值得開發人員去瞧瞧，而不只是把Flash當成網路動畫的技術。

後記：我手上總共有兩個版本的Preview報告，一份有全部15個問題的結果，一份只有其中幾個問題，但加上了專家評論的內容，後來再嘗試去下載都只有後面這一份了。

延伸閱讀：

每季一次的 State of the Computer Book Market, Q4 06, Part 1, Overall Market Trend 來了，可以和這份報告交互比較。
之前寫的從《政府機構軟體開發環境問卷調查》看程式語言與整合開發環境市場佔比

稿費、辦稅收入怎麼報稅？

2007-01-16T14:39:00.000+08:00

許多作譯者都有這樣的疑問，稿費或是版稅怎麼報才省錢？另外，許多作譯者也對於給付稿費或版稅時被預扣所得稅耿耿於懷，好像少領了錢。事實上，根據各類扣繳所得標準的規定：

給付稿費、版稅、樂譜、作曲、編劇、漫畫、講演的鐘點費等執行業務報酬，所得人如果是境內居住的個人，按給付額扣繳10%，但是如果每次應扣繳稅額不超過新台幣（以下同）2,000元的話，可以免予扣繳。

所以預扣是守法的，不預扣的你得注意這家公司，並且留意扣繳憑單上的所得分類是否為稿費、版稅、鐘點費這一類，否則會影響你報稅。

至於稿費、版稅的報稅，大部分作譯者都知道有18萬的免稅額，不過根據所得稅法規定，扣除18萬之後的所得，還可以扣除30%作為成本：

個人取得稿費、版稅、樂譜、作曲、編劇、漫畫、講演的鐘點費等類的收入，每人每年合計不超過18萬元時，可以全數免稅，超過18萬元的話，如果是屬於自行出版的部分，可以就超過部分檢附成本和費用的憑證核實減除或直接減除75%的成本費用，以餘額申報執行業務所得。其他不是自行出版的部分，可以減除30% 的成本費用以後，用剩下的金額申報執行業務所得。

也就是說，如果稿費版稅收入全部30萬元的話，可以先扣除18萬元免稅額，剩下的12萬可再扣除30%，也就是3.6萬元為成本，所以實際上要計入所得的部份就是8.4萬元，這可能就可以讓您少跳一級稅率哩！

延伸閱讀：

圖解翻譯稿酬

2007-01-15T23:45:00.004+08:00

常常有人問，翻譯的收入如何？我特別製作了一張稿酬東西軍圖表，讓大家可以自己算一算翻譯這一行到底划不划算？

延伸閱讀：

老貓學出版網站的（歡迎討論：適當的譯稿費用計算法）

Here Comes iPhone, Cool.

2007-01-11T13:52:00.000+08:00

透過線上觀看Steve Jobs簡報已經是我近年來的大樂趣，昨天看的iPhone秀更是讓我悸動不已，我記得上一次讓我有這種感覺的產品是Google的GMail。整個秀（雖然該說是簡報，但實在像是一場秀）高潮不斷，讓我讚嘆的有以下這些：

iPod部份

手指捲動清單的方式，這的確很類似我們用手指指著一串資料閱讀的手法。
翻弄唱片封套找唱片，相當符合一般人找CD的習慣，我想到的是現在的電子書閱讀器不知道能不能用這樣的方式作翻頁的效果，會更像是在翻書。

Phone部份

加入類似GMail Conversation的SMS（簡訊）處理方式，的確很適合現在大量用簡訊的手機用戶，這項功能也是我個人覺得GMail最值得稱道的地方。
直接讀取特定的留言，不知道這是否需要系統商支援？如果並不需要，而只是現今的手機都沒做到，那真是奇怪了。

Photo Album部份

用多觸點的觸控螢幕控制圖形縮放，真有一套，我想這應該會有更多用途，雖然目前只看到這個用法。

Internet Navigator

有Safari Browser真好，最棒的是先以縮圖方式顯示完整的網頁，可自由選取區域放大閱讀點擊，而不會因為畫面實體的大小破壞網頁的外觀（像是瀏覽器中有虛擬桌面）。另外，透過Web Page Thumbnail選取頁面也可以解決tab太多無法分辨個別頁面的困境。我一直都希望可以有一個PDA大小的PC，只要能跑Firefox，加上Google的各式服務就是一個超讚的PDA，還不需要同步來同步去的哩。

隨便先記下這些，2008年亞洲才上市，好樣的，真會做生意！

對了，改天應該來談談Steve Jobs的簡報術。

延伸閱讀：

The iPhone As An eBook Reader

Treemap製作簡易教學二部曲：使用Treemap軟體

2007-01-06T22:45:00.000+08:00

要製作Treemap，除了使用上次介紹過的Microsoft Treemapper with Excel Add-In以外，還可以使用Treemap原創人Ben Shneiderman所領導以Java開發的跨平台軟體Treemap，目前的版本是4.1.1，需要Java 1.4的環境才能執行。只要下載回來，解開壓縮檔，執行其中的run.bat即可（這是指Windows平台，其他平台請自行閱讀readme.txt）。

不過再真正顯示treemap之前，必須先準備好原始的資料，Treemap軟體可以接受以tab分隔欄位的文字資料，您可以使用Excel製作原始資料，再另存成文字檔，例如底下就是和（Treemap 簡易教學示範）這一篇的範例同樣的資料，但依循Treemap軟體要求的格式：

要注意的有以下幾點：

量化的資料欄位要擺在最前面，並且與後面描述階層結構的欄位之間空一欄。
量化的資料可以必須標示資料的型別，可用的型別共有FLOAT、INTEGER、DATE、STRING四種，而且必須以大寫字母標示。

準備好這份資料後，就可以開啟Treemap軟體，選擇『File/Open...』開啟資料檔案，就會看到對應的treemap：

咦，奇怪，不但每個區塊看起來都一樣大，而且也沒有顏色標示？這是因為我們還沒有告訴Treemap軟體要以那一欄量化資料代表區塊大小語言色，您可以在操作畫面右邊選取Legend頁籤：

分別在Size以及Color欄位選擇量化資料的欄位即可，結果如下圖：

這樣就顯示了我們所需要的Treemap（此圖中是以業績維區塊大小、業績成長率維顏色，越紅表示成長率越低、越亮的綠色表示成長率越高，黑色則是持平）。Treemap軟體可設定的選項繁多，此篇僅是簡單的入門，提供給大家參考。

延伸閱讀

詞辨：element、tag

2007-01-06T22:09:00.000+08:00

如果查閱W3C對於XML檔案結構的說明，會清楚看到XML文件是由多個element所組成，而每一個element可以是以下兩種形式：

empty-element-tag：也就是像是<img src="http://www.w3c.org/head.hpg" />這種沒有content的element。
start-tag content end-tag：也就是以一對起始標籤/結束標籤所界定範圍所組成，像是<a href="http://www.w3c.org/">W3C</a>這樣。

因此，element與tag並不相同，不過綜觀市面上的一些書籍，有些已經把element與tag混為一談，譬如當我讀到Professional ASP.NET 2.0的第13章時，就看到以下這段話：

The third line, , is the root element or document entity of the XML document. An XML
document can have only one root element. The last line in the document is the matching end element
.

很顯然的，依據W3C的說法，這一段話裡頭的"root element"應該改成"start tag of root element"；而"end element"應該改成"end tag"才是正確。不過這本書這樣寫是情有可原的，因為如果回頭查閱微軟.NET的說明文件，會看到XmlReader對於整個XML結構樹的每一個節點，有以下的種類（原文件請看這裡）：

Element：項目。 XML 範例：
EndElement：結尾項目標記。XML 範例：

可見微軟的文件中就是把tag當成是element，因此許多書也這樣寫就再自然不過了。

翻譯名詞：attribute、property

2007-01-03T00:01:00.000+08:00

在大多數的書或是文章中，對於attribute與property兩個詞一律都翻譯為「屬性」，雖然在語意清楚的情況下，自然可以分辨，但還是常常會容易混淆。如果要分辨清楚，就得回頭看看物件導向的起源--ADT（Abstract Data Type）。

ADT是由表示資料的data與行為能力的operation所組成，落實在程式語言的層面，當我們用class來描繪一個ADT時，就將代表資料的data稱為attribute、而operation稱為method。在某些程式語言中（如C++），就將attribute稱為member variable、而method稱為member function。不過在其他種類的程式語言（像是C#）中，也把attribute稱為field。實際上，在許多書中，可能也都沒這麼考究，幾個詞彙可能交替互用，而沒有細分。

那麼property呢？我認為這個詞彙的流通，主要是component-based的程式語言或是整合開發環境（如VB、Delphi）興起之後才逐漸被使用，主要是指以一對分別用來儲存（setter）以及擷取（getter）的方法（method）所封裝的資料，由於是以方法來封裝，因此就可以在設定或是讀取資料的同時進行必要的運作，像是驗證新設定的值是否合理、或是因應新的值自動更改其他屬性的值等等。隨著property的流行，許多程式語言（像是C#、Ruby）本身就直接提供property的語法，Java則是要求程式員必須依循一定的命名規範，讓一對方法在整合開發環境中使用起來像是其他程式語言中的property。

在.NET中，事情又被複雜化了，因為.NET使用attribute這個詞彙來表示物件在進行某種行為時的特性，比如說透過Serializable這個attribute，可以指定類別中哪些field在serialize時要儲存起來。這裡的attribute就跟前面所提到對應到ADT中data的attribute不同了。如果您查閱微軟的文件，會發現有些地方微軟把attribute翻譯為「自訂屬性」，雖然已經和「屬性」有所區別，但還是容易讓人誤會「自訂屬性」是「屬性」的一種，我個人比較建議將.NET中的attribute譯為「特性」，會比較達意。

了解了這一點之後，就可以知道在HTML/XML中attribute的意義了，依循的還是ADT中data的意思，所以譯為「屬性」並沒有太大的問題。

延伸閱讀：

Treemap 簡易教學示範

2006-12-30T23:21:00.000+08:00

Treemap簡單的來說，就是以二維平面的方式展示包含階層結構（hierarchical）形式的統計資訊，主要的特徵如下：

透過層層包圍的區塊表現階層的關係
以區塊的大小表現各階層元素的一組量化資訊
以區塊呈現的顏色層次表現各階層元素的另一組量化資訊

這樣講也許很抽象，我們以實際的圖例來說明，最簡單的例子就是銷售業績的比較：

從這個圖中你就可以看出來幾件事：

業務部門的階層結構為：

北區

黃一峰
張大大
張小小

中區

劉三

南區

鄭中
周海闊

如果區塊面積代表業績，鄭中就是第一名。
如果越接近紅色表示與去年相比衰退越多、越接近綠色成長越多、白色為持平的話，無疑的鄭中成長第一名，劉三吊車尾，而黃一峰維持一樣的業績。

是不是就一目了然了呢？以下我們就用這個範例來說明如何製作Treemap，為了符合大部分使用者的環境，這裡我以Microsoft Treemapper with Excel Add-In為例，採用這套軟體的原因如下：

Windows平台的使用者多半都安裝有Excel軟體
Treemapper Add-In（增益集）可免費下載
直接在Excel環境下即可操作

首先請下載Treemapper Add-In，安裝完畢後請開啟Excel，點選『工具/增益集』，勾選Treemappe：

按下確定鈕後，就會出現Treemapper工具列，上面只有一個Treemapper按鈕，就是用來產生Treemap。

安裝好軟體後，接著就是準備資料，底下就是產生剛剛所看到Treemap圖例的原始資料：

這份資料應該不需要解釋，一看就懂，接著只要按下Treemapper工具列上的Treemapper按鈕，就會看到如下的交談窗：

Box sizes are in 指的就是要表示區塊大小的量化資訊，這裡選的就是業績欄
Box colors are in 指的就是用來表現區塊顏色層次的量化資訊，這裡選的就是成長欄
Box name components are in 指的就是區塊的名稱，每一橫列表示一個區塊，並且以並排的儲存格表示階層結構中一層層的區塊名稱。
如果第一橫列是表頭文字，就勾選 First row contains headers that should be ignored

其餘的選項就先略過，畢竟這是篇「簡易」示範教學。按下OK鈕後，就會產生之前看過的Treemap了。您也可以調整區塊的顏色、區塊中文字的字體與大小、區塊間邊框以及補白（padding）的寬度等等，操作都很直覺，應該難不倒各位，簡單示範，就此打住囉。

延伸閱讀：

如果您對於產生Tremap的演算法有興趣，可以看看Ordered and Quantum Treemaps: Making Effective Use of 2D Space to Display Hierarchies
如果是非Windows平台，可以試試由Ben Shneiderman以Java實作，跨平台的Treemap軟體。

編輯作品：PHP Smarty 樣版引擎 -- 解決版面‧程式碼糾纏不清的困境

2006-12-30T10:16:00.000+08:00

凡是從事網頁程式開發者，最終都會遇到與版面設計人員之間的紛爭，不論是設計人員誤改了程式員完美邏輯的程式、抑或是程式員粗心的弄亂了設計人員精心配置的精美頁面，總是都想怪對方，又都怪不得對方的尷尬窘境。為了解決這個問題，綜觀各方意見，MVC似乎是個一致的答案。所以ASP.NET搬出了Code behind；JSP雖然沒強制，但骨子裡發想的就是MVC架構；近來竄起的RoR則更進一步，只有MVC，否則寫不出程式。那麼網頁開發一方之霸的PHP呢？Smarty就是一種可能性。

Smarty雖然也走MVC的路，但是以最寬鬆的方式，只把V（iew）抽離出來，M（odel）與C（ontroller）程式員可以自我發揮。我自己的觀察，PHP開發人員中服膺資訊理論者說實話比例並不很高，也正是這樣的特性，和PHP的簡易入門與高度彈性相匹配，因而造就了PHP歷久不衰的盛世。如果從這個角度看，Smarty也許是最適合PHP程式員進入MVC的方式，先把最惱人不得不解決的設計人員共事問題解決掉，剩下的就可由程式員自由發揮，想完全MVC也好、MC共體也好，都行，程式員自己寫的開心就好。

企劃這本書是個嘗試的開端，過往書市中PHP的書籍大致上分成三類：

PHP+MySQL入門學習
PHP+Dreamweaver快速開發
PHP範例集

主要都是集中在入門學習與快速開發上，鮮少對於程式開發本身的技術或是方法論的進階書籍，所以希望能以這本書作為試金石，試探PHP族群在這類書籍的接受度，希望能夠有好的結果。

延伸閱讀：

此書作者的blog

從《政府機構軟體開發環境問卷調查》看程式語言與整合開發環境市場佔比

2006-12-28T18:13:00.000+08:00

在iThome上看到，依據行政院主計處電子處理資料中心於2006年10月公佈的調查，以最近一年內「政府機構軟體開發環境」為題問卷，採可複選的方式，我將調查出來的結果轉換成為Treemap的形式，以便看出各方角頭所站的區塊大小。要說明的是，原始調查資料僅有單獨品項的統計，我依據自己的推估，加上了平台以及軟體廠商的分類，如有謬誤，請不吝指正。

底下是程式語言的部份：

如果以單一程式語言來看，Java無疑是最大，但如果把VB.NET+C#+ASP.NET視為一體（.NET平台），就和Java旗鼓相當了（以實際數據看.NET略高1%）。
單以.NET來看，VB.NET遠遠高於C#。
值得注意的是，VB仍然佔據一大塊，這個族群是否會在短時間內移轉到.NET，值得關切。
在網頁程式部份，Open Source陣營的PHP獨大，ASP還有一片小天地，但ASP.NET就佔比很低。
其他語言（C++、Delphi、C、PowerBuilder、COBOL）也都還有一席之地（C++的部份我暫時歸在C++ Builder），只是都不大就是了。

以下這張圖則是針對整合開發環境（IDE）的調查：

你可以看到，用文字編輯器的佔了一半，我推斷這主要是PHP的開發人員，以及許多Java與ASP的開發人員，蠻好奇的就是這些開發人員使用了哪幾種編輯器。
整合環境部份，Visual Studio雖然獨大，但因為統計資料沒有區分版本，所以等於是把上一張圖中 .NET+ASP+VB 併起來（實際上不是總和，因為上一張圖中統計的數量可視為專案數，單一機關可能用了VB和ASP開發多個專案，就會為VB與ASP各自貢獻 1，但在這張圖中卻只會為VS貢獻 1），因而遠遠超過Java平台。
Eclipse和JBuilder的佔比相當，看來替許多軟體開發公司省下了不少軟體費用。由於最近JBuilder改版宣稱根基於Eclipse上，不知道此舉會吸引Eclipse族群往JBuilder遷移、還是直接讓Eclipse擴大領土，畢竟JBuilder不算便宜啊。

對了，如果您想製作類似的Treemap，我所知道的兩種免費方案如下：

使用微軟提供的Microsoft Treemapper with Excel Add-In，就可以直接在Excel裡產生Treemap，並且可以匯出成圖檔，本文圖檔即由此軟體產生。
使用Treemap創始人Ben Shneiderman的Treemap軟體（使用Java 1.4）。

另外，如果您曾經閱讀過O'Reilly創辦人Tim O'Reilly所撰寫的State of the Computer Book Market, Part 1等一系列文章，一定會知道我只是東施效顰，套用他的模式與工具看統計數字，當然功力相差甚遠，在此向Tim O'Reilly先生致敬，也為O'Reilly這間獨具特色的出版商有這樣優秀的領導人感到欽羨。

延伸閱讀：

政府機構軟體開發環境問卷調查報告

Web2.0 = BBS

2006-12-19T23:12:00.000+08:00

自從Web2.0這個觀念被提出來之後，不僅關於Web2.0是什麼的爭論不休，連帶喚起另一波的網路造夢潮，可是如果以目前比較公認的一些Web2.0的特點來看，我個人很大膽的認為，Web2.0=BBS，因為：

網友貢獻內容 = BBS貼文/圖
社交網路 = BBS討論串
標籤（Tag）= 虛擬討論版

如果再把時間往前推移，上一波的Blog熱潮只要將Blog抽象化之後，一樣會發現Blog=BBS（只是能夠發起貼文的僅線站主或少數共同作者）：

Blog發表文章 = BBS貼文
Blog評論（＋Trackback）＝ BBS討論串（我不確定是否有BBS系統實作過類似Trackback功能）
Blog文章分類 = 討論版

事實上，再把時間推移到Blog之前，你仍然可以發現，Web Site=BBS，舉橫跨網路熱潮的Amazon書店來說：

商品上架 = BBS貼文
商品評論 = BBS討論串
商品分類 = 討論版

如果拿任何一家商業公司的網站：

新聞發佈 = BBS貼文
客戶服務 = BBS討論串
不同區塊（新聞區、商品區、客戶服務區、...、）= 討論版

或是看看拍賣網站，不也是BBS？Flickr不也是BBS？Digg、GMail（我甚至認為GMail是因為其模擬了BBS的概念而成功，大容量只是成就這個概念的必要條件）、Del.icio.us、Wiki、...都可以抽象化後得到BBS的骨架，唯一的差別只是貼文的使用者權限設計不同，以及貼文的內容種類不同，還有整體網站的外觀（Presentation）不同而已。

所以在經歷了一波波高潮迭起的網路演進之後，其實我們只是回到BBS，但差別是幾乎所有的人都玩的不亦樂乎了。

URI、URN、以及URL？

2006-12-13T07:50:00.000+08:00

在大部分的書上，可能會出現URI與URL，而且在許多地方已經把URI與URL視為等價的兩個詞彙，不過如果追本溯源，就會發現這兩個名詞涵義並不相同。

根據Wikipedia，簡單的來說，URI（Universal Resource Identifier）是泛指任何可以識別出某項資源（某個東西、某個人、某個....）的項目，這又可區分為兩種，一是大家較不常用的URN（Universal Resource Name），是指能夠識別出某項資源的名稱，比如說「Wikipedia」就是URN；另一種URI就是最常用的URL（Universal Resource Locator），除了能識別出某項資源外，還能指出資源所在的位置，比如說 http://www.wikipedia.com/ 就是URL。

因此，嚴格來說，URL是URI，但URI並不一定就是URL，這是在使用詞彙時必須注意的事情，否則對於某些讀者就可能會造成誤會。

書介：翻譯研究、翻譯新究

2006-12-06T23:27:00.000+08:00

我有一個夢想，希望每一個來找我的譯者都好好的讀過思果先生的《翻譯研究》。

我相信這的確是每個編輯的夢想，否則就不需要花那麼多時間看稿，而是應該享受在閱讀的樂趣中。

這本書的焦點放在翻譯的結果究竟像不像中文？中國人讀了之後對於文句所要表達的意思會不會有直覺？以英文中常見的"one or more...."這樣的句子為例，大多數人會依據英文很直覺地翻譯成「一或多個....」，但中國人其實很少這樣說，閱讀起來一定覺得很拗口。道地中文的講法應該翻為「至少一個....」，才會像是中文，否則雖然意思也許讀者看得懂，但骨子裡卻不是中文。

但可別以為就這麼簡單，作者還期望譯者要能在翻譯結果中展現與原文一樣的語氣，比方說 "Well,I'll be there."，直譯就是「好，我會在那裡。」但一般人不會這樣說，大概會說「好，到時我在那裡等你。」或是「好，到時候見。」但如果說話的是文謅謅的老教授，也許就該翻成「好，到時我在那裡恭候。」。另外，同樣的事情發生在不同人身上，英文可能是一樣的，但中文卻不同，像是一般人與妻子離婚，換成了皇帝，就是「廢后」。

如果您看過其他討論翻譯的書籍，很容易就可以發現本書最大的特點，就是「實務中的理論」。書中所談到的內容或是實例，都是作者自己多年蒐集以及苦思、實作的心得，舉例來說，英文中常見的 "one of the best XXX" 這樣的句子就很困擾我，不花腦筋的譯法就是「XXX中最好的其中之一」，意思雖然能懂，但畢竟不像是中文，但看到書中的建議，恍然大悟，這就譯成「了不起的XXX」不就得了。

如果您有志從事翻譯，那麼我真誠的認為好好把這本書徹底研讀幾遍，一定會讓你的翻譯功力大有斬獲，但唯一的缺點是，鑑別力也會大幅增長，即便想要降低標準多騙點錢大概都沒法對自己放水。最後要提的一點是，本書雖然主要針對英文翻譯，但對於其他語言的翻譯，也會有很大的啟發，建議都不妨一讀，絕不會浪費時間。

後記：本書舊版本的編排比較適合閱讀，新版在版面上加上了一些托福應試類型書籍中會出現的圖樣，不但不利閱讀，也讓這本書的質感頓時跌落千丈，真不知出版商是怎麼想的。另外，作者還有一本《翻譯新究》，亦值得一讀。

取得Excel工作表的名稱

2006-12-05T10:21:00.000+08:00

我自己拿Excel做很多跟試算表沒關係的事情，因此常常會遇到一些奇怪的需求。日前我就碰到需要取得工作表名稱的狀況，靠著Google，找到了答案，只要以下這行就可以了：

=MID(CELL("filename",A1),FIND("]",CELL("filename",A1))+1,256)

其中的奧秘就是這樣：

CELL("filename",A1)

會傳回A1指定的儲存格所在工作表的完整路徑，像是這樣：

D:\temp\[test.xls]Sheet1

其中 "test.xls" 是檔名，"Sheet1" 是工作表名稱，所以利用FIND()找出"]" 在完整檔名的位置，也就是：

FIND("]",CELL("filename",A1))

再利用MID()從這個位置的下個位置開始，取出到字串尾端的所有字元，就是工作表的名稱了。

書介：咬文嚼字話翻譯

2006-12-05T07:55:00.000+08:00

這本薄薄的小書關注的焦點在於用詞的正確，細讀此書，總是會不斷的發現「原來是這樣！」「啊，我都用錯了！」。舉例來說，「杯葛」一詞在現今的新聞中看得多了，但多數的人並不知道這個詞是外來語譯音而來。更重要的是，「杯葛」是指以不到場的方式讓特定活動無法辦成，或是至少失去重大意義，比方說過去蘇聯杯葛洛杉磯奧運，根本不參加，就使得美國即使得到最多金牌數，也無法登上世界第一。但現在許多媒體濫用，連有到現場但干擾活動進行都稱為「杯葛」。

再舉個例子，「聽眾」是我們常使用的詞彙，這個詞也是從audience翻譯而來，但既然是聽「眾」，就是複數，所以「一個聽眾」這樣的說法是不成立的，但這卻是一般人經常脫口而出的講法。

您可能會說，反正大家看到、聽到都知道意思，約定成俗了嘛！或者是說，語言難道不能創新嗎？不過作者提出一個最簡單的檢驗方法，就是將譯文翻譯回原文時是否會讓外國人誤會意思，如果會，就必須斟酌中文詞彙。以前面提到的「杯葛」為例，翻譯為英文必然是 "boycott"，而外國人一看便認為是沒有到場了，因此，用或不用「杯葛」就值得商榷了。

翻譯名詞：strong type language

2006-11-30T00:25:00.000+08:00

strong type是很討厭的詞，屬於英文中簡單幾個字卻表示複雜意思的詞彙。一般我所看過的譯法大抵上就是「強型別」、「強力型別」等等，這樣的譯法有個很大的問題，就是如果不知道原文，很難猜測出來這個詞代表的意義（「強」是指整個型別系統很強？抑或是某種資料型別很強？顯然都不是），而對等的詞難道是「無力型別」或「軟弱型別」？

我自己對於這個詞，最建議的譯法就是「嚴格型別」，望文生義，代表的意義就是這種程式語言在資料型別的要求上很嚴格。如此的翻法，在處理相對的weak type時，就可以翻譯為「寬鬆型別」，也能夠表示真正的意義，提供給大家參考。

翻譯名詞：object, instance

2006-11-30T00:12:00.000+08:00

object與instance可能是困擾程式設計類書籍譯者最多的名詞，在大部分的文章中，一旦翻譯成中文之後，即使將object或是instance都譯為「物件」，在語意上多半不會造成困擾（我自己也常這樣做），但如果細究起來，我認為其實object與instance是有所不同的。

object應該是泛指某一物件；而instance通常是特別指某一類的其中之一個。也就是說，出現instance的場合多半都會指明所屬的類別，比方說"a instance of Car class"；而出現object的場合，多半不會特別指明其所屬類別，或者無法指明所屬類別，比方說"delete all objects in the collection"。

好，如果是這樣，那麼object與instance究竟應該如何翻譯呢？我個人的建議是object就簡單翻譯為「物件」，這也和一般稱「物件導向程式設計」相符；而instance如果審視上下文，有必要區別出來時，就翻譯為「某某類的（一個）實體」，否則可以一樣翻譯為「物件」即可。

編輯作品：AJAX 網頁程式設計--Google成功背後的技術

2006-11-11T18:12:00.000+08:00

AJAX無疑是從去年（2005）延續至今最熱門的話題，伴隨著Web2.0的話題引爆，大多數人都將AJAX與Web2.0劃上等號，也使得AJAX這項技術更加令人關注。如果您是想要找一本書可以快速瀏覽，對於AJAX有一個全面的概念，這本台灣第一本出版的AJAX技術書絕對是首選！

本書僅以很簡短的介紹開場，便立即進入實作的階段。在示範了基本的AJAX實作手法之後，特別將焦點放在JavaScript的程式設計上，詳細介紹Prototype函式庫，並進一步介紹幾個與伺服端技術結合的程式框架（Framework），讓本來已經熟悉個別伺服端技術的讀者可以有方便的選擇。

接著，本書就以實際範例為主，示範AJAX的實務應用方式，包含了會員申請帳號即時檢核與住址郵遞區號即時查詢、線上英文字典、拖放式購物車、簡易版 WIKI 系統等等在內，都是一般網頁程式員可能會需要實作的系統，最適合想從實務面著手的人。

編輯這本書是相當興奮的事情，因為相信一項技術必定會竄紅，而有機會出版第一本書介紹給大家，光是想著就熱血沸騰了起來。

延伸閱讀：

此書作者的blog

編輯作品：The Wargame --駭客訓練基地

2006-11-11T18:05:00.000+08:00

每個人心中都有想當駭客的慾望，時時都在想像自己駭入別人的電腦，發現了天大的秘密，或是進入銀行的電腦，彈指間讓自己變成百萬富翁。這些迷人的夢想聽起來都挺不賴的，但你可知道，駭客可不是天生下來就是駭客，想要成為駭客，得學習一堆技術，然後找地方練習，嗯，最困難的就是這一點：『找地方練習！』

如果你是練習空手道，可以到道館找對手練習對打，但對駭客來說，除了四處尋覓侵入的對象外，別無他法！但到處找練習駭技的對象是一件很危險的事，在道行尚淺的時候，失敗的代價極高，因為你極可能觸犯法律，身現囹圄。Wargame的誕生就是為了這個目的，提供一個練習的場所，讓你在安全的環境下鍛鍊駭技。

簡單的來說，Wargame就是一個線上遊戲網站，你必須運用所有的知識與技術，包括程式設計、編碼、網路技術、電腦常識等等，找到通往下一關的密碼，一路過關斬將，到最後登上破關名人榜。透過這樣的過程，就可以練習所有的駭技，最重要的是，不用擔心觸犯法律。

在這本書中，就由台灣知名的駭客團體CHROOT.ORG帶領我們一路闖越國內外知名的4個Wargame網站，經過這樣的鍛鍊，一定可以讓你駭技突飛猛進，當然，另外一種可能是挫折連連，粉碎當個駭客的美夢。

編輯這本書相當有趣，我自己玩得非常愉快，有一種玩Game破台的虛榮，呵呵！

翻譯名詞：Regular Expression

2006-11-10T10:20:00.000+08:00

Regular Expression是我認為每一個使用電腦處理文字的工作者都應該要學會的一門技術，不論是各種程式語言、文字編輯器、甚至於幫助您批次修改檔名的小工具，大部分都已經加上了Regular Expression的功能。但是這門技術的名稱到底中文應該如何翻譯呢？

如果查閱目前市面上的電腦類書籍，會發現有多種翻譯結果，像是正規表示式、正則表示式等等，我個人認為都極不妥，原因很簡單，就是無法看出到底是什麼意思。比如說正規表示式一詞，姑且不論其意思正確與否，光就「正規」來看，那何謂「不正規」的表示式呢？

以我個人的淺見，應該就意義上來著手，翻譯為「規則表達式」，因為Regular Expression本來就是用來描述一個字串樣式（Pattern）的構成規則，譯為「規則表達式」很明白，就是用來表達規則的式子，豈不是又「信」又「達」呢？

延伸閱讀

微軟譯成規則運算式 (Regular Expression)。

書介：Minimal Perl

2006-11-07T23:48:00.000+08:00

如果您曾經想要學習Perl，但卻被Perl的繁複所遏阻，那麼本書可能很適合您。作者Tim Maher之所以撰寫這本書，就是因為覺得大部分的Perl書都寫得太多了，Perl強調「做一件事有N種方法」，導致大多數的Perl書籍都竭盡所能的想把N種方法全部教給讀者，因而讓讀者迷失在各種奇奇怪怪的語法迷宮中。本書作者認為，學Perl只要學需要用到的即可，重要的是能夠用Perl解決問題，他把這樣的概念就稱為Minimal Perl。

秉持上述的原則，本書分為兩個部分，第一個部分以一章Perl簡介入門開始，隨後便示範給讀者看Unix-like作業系統上常用的工具，像是grep、find、awk、sed等等，如何使用Perl取代，並且做得更好。第二個部分則是告訴您如何使用Perl完整的程式語言特性取代shell程式設計的各項元素，而且運作的更有效率。

本書最特別的地方就在於目標讀者是Unix-like的作業系統使用者，因此書中的範例都以實務取向，不會讓讀者有「如果學Perl只是用來寫這種無聊的程式，那我幹嘛學Perl」的誤解，如果您想學Perl，又是在Unix或是Linux平台的話，從這本書開始應該會是個不錯的起點！

我最中意的紙本行事曆

2006-10-20T23:16:00.000+08:00

您可能和我一樣，一直都在找尋最好用的紙本行事曆，我心目中最理想的行事曆就是如下的方式（注意：市面上販售的行事曆在右頁是沒有中線的，以下圖案取自哈伯實業）：

這種格式的用法是這樣的：

先把右頁對折，自己加上一條中線。
一開始先在右頁的右半邊，從下往上依序新增待辦事項。
每天一早，就從待辦事項以及預定的約會規劃當天的行程。
如果有會議要開，可以在右頁的左半邊由上往下做會議記錄。
每週一由前一週尚未完成的待辦事項移到該週的待辦事項。

這樣一來，是不是就很好用呢？