星期四, 11月 08, 2007

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


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

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

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

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

星期四, 10月 18, 2007

Photoshop問答:筆刷的opacity(不透明)與flow(流量)的差別?

我並不是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%的不透明度,一直點按下去,就會變成筆刷的顏色:


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

延伸閱讀:

星期三, 10月 03, 2007

GET、POST與cache的關係

在大部分的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程式開發中,卻很可能讓程式員耗費時間精力,找不出問題在哪裡。

延伸閱讀

星期四, 8月 16, 2007

日文翻譯的陷阱

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

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

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

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

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

星期六, 8月 04, 2007

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

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

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


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

延伸閱讀:

星期五, 8月 03, 2007

SQL Server仍舊維持霸主地位

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%的人會考量,可見得大多數的軟體人員最重視的還是專案能不能儘速完成哩。

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


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

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

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

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

延伸閱讀:

星期四, 7月 19, 2007

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

從事編輯一段時間後,一定會遇到的就是拖稿,你一定很想知道為甚麼,而你的主管更是需要你給的理由,於是你就會從譯者或是作者口中聽到一些說法:
  1. 「快要寫完了,晚上就會寄給你。」
    意思就是你下班後我可能就會寄給你,但明天上班時答案才會揭曉。
  2. 「已經寄出去了,你沒收到嗎?」
    別先懷疑作譯者,很可能他用的附件檔案格式被你的MIS英勇的擋掉了。
  3. 「你給我的FTP不知道為甚麼連不上去?」
    先自己連連看吧,況且作譯者未必熟悉FTP。
  4. 「我已經燒成光碟到郵局寄出去了!」
    你只好等個三天再說囉,或是急的話自己請快遞去拿,別郵寄。
  5. 「我硬碟掛點了,得等我修好重灌!」
  6. 「我中毒了,開不了機!」
    以上兩種,除了相信,你不大能做些什麼,或者你去幫他重建系統?
  7. 「我要出差,下週回來才能寫稿。」
  8. 「我家人生病,要去照顧他。」
    以上兩種,只能相信,硬要去查證是沒有必要且魯莽的行為。
  9. 「嘟..........」、「您撥的電話未開機」、「將為您轉接語音信箱」、「您撥的電話號碼是空號,請查明後再撥」
    這一種就表示你已經達到編輯的最高境界,把人給蒸發掉了,因為聯絡不上,你永遠不知道發生了什麼事,甚至想把每一份報紙的社會新聞都詳細看過,確認沒有任何意外。
對了,經過上述各種狀況拿到了珍貴的稿件時,可能還有難關等你突破:
  1. 壓縮檔打不開?
  2. 壓縮檔打開裡頭空空如也?
  3. 壓縮檔打開裡頭好豐富,但都不是你要的稿件?
  4. 果然是稿件,咦,沒寫完?
  5. 收到一張空片?
  6. 收到一張DVD電影?
  7. 收到一張無法讀取的光碟片?
  8. 收到沒有夾檔的mail?
相信我,以上這些我全部都遇過,不過我相信這都是意外,我也當過SOHO、也當過員工,將心比心。

加油啊,稿件尚未完成,大家仍需努力!

星期二, 7月 17, 2007

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

根據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的親和力吧,我想。

延伸閱讀:

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

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


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

延伸閱讀:

星期一, 7月 09, 2007

崔健海洋音樂祭壓軸演出

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

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


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


記憶所及,昨天的演唱曲目如下:
  1. 飛了
  2. 新長征路上的搖滾
  3. 寬容
  4. 混子
  5. 像一把刀子
  6. 一塊紅布
  7. 滾動的蛋
  8. 飛越那一天
  9. 一無所有
安可曲:
  1. 解決
  2. 花房姑娘
晚間10:35登場,足足唱滿約一個半小時,7/9 0:00結束。

星期六, 6月 09, 2007

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


會簽下這本翻譯書,最早的想法其實是很簡單的,隨著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人口之勢,未來應該還是頗有希望。

延伸閱讀:

如果您想出書?

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

我是XXX,我想寫一本XXX的書,不曉得貴社有沒有興趣出版?
說實話,收到這樣的信件,我是無從判斷我們公司會不會有興趣的,原因很簡單,資訊實在太少了。如果您也想投稿的話,我建議您準備好幾項資料(格式不拘):
  • 清楚描述對象:是寫給初學者看的?業界人士看的?學校上課用的?哪個科系的學生適合?千萬不要告訴我「就是寫給想看這個主題的人看的」。如果能夠進一步說明這樣的人為甚麼需要看這本書,那就更棒了。
  • 具體說明差異:出版商畢竟就是「商人」,因此在競品環伺的情況下,你的這本書和別人的書有什麼不同就很重要了。除了嶄新主題可能沒有競品外,最好能夠具體講出來你這本書的特點,但是記得,要「具體」!如果你認為你的書是最容易看懂的書,就要讓出版商知道為甚麼?也許是因為你是採用圖解的方式,每一頁至少有一張示意圖;又或者你說你的書是範例最多,那就算給出版商看你的範例的確比別的書多;也可能你說你的書是市面上最完整,那就把你的書有而別人的書沒有的題材列出來。總之,就是要「具體」。
  • 二到三章樣章:光靠以上的資料,出版商也許可以認同這是不錯的企劃,但是卻無從判斷你是否真的寫的出來,所以最好可以準備好樣章,這遠比你將多采多姿的傲人學經歷搬出來要有效的多。
最後,你可能有個疑問,給了這麼多的資料,會不會被出版商給抄去,賠了夫人又折兵呢?我的看法很簡單,如果你的書這麼容易就被抄去,我想出版商出版的興趣大概也不會太大,懂嗎?

星期四, 5月 24, 2007

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

每一個開發人員最需要的就是一本好查閱、看得懂的參考手冊,尤其是像是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,都應該買一本保心安啊!

延伸閱讀:

星期二, 3月 27, 2007

MySQL市佔率大有斬獲?

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的進一步探究,也許並不那麼重要?

星期五, 3月 23, 2007

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


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

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

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

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

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

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

延伸閱讀:

星期日, 3月 18, 2007

書介:Ajax Patterns and Best Practices

由於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列為網頁應用程式開發主要工具的程式員都可以讀讀這本書,未必要採用作者提出的程式碼,但參考一下其中的想法,應該也會有很大的幫助。

延伸閱讀:

星期六, 2月 17, 2007

恭賀新禧!

新年到,派我兩個女兒跟大家拜年!

延伸閱讀:

星期六, 2月 03, 2007

Eclipse攻陷Java開發社群?

根據SD TimesTwo-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方式調查,所以對於有效問卷的受訪者背景沒有明確的說明,這是比較可惜的地方。

延伸閱讀:

星期五, 2月 02, 2007

詞辨:type selector與class selector

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

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

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

合約到期的注意事項

在之前的文章(圖解最後一刷後半版稅計算法)中曾經提到合約到期時的議定處理方式對於作者或是譯者的版稅收入有影響,一般的作法會在合約到期前另外簽訂一份終止合約書,載明合約到期時各項處理事務。今天朋友在整理文件的時候,剛好看到某出版商一份大約七年前的終止合約書,上面有一條條文很有意思,特列列出來給大家參考:
...
三、滯銷書之販售:乙方(指作者)同意甲方(指出版商)得繼續販售本著作物至完全售完為止;惟該剩餘未販售之滯銷書版稅歸甲方所有。
...
簡單的來說,意思就是合約到期後,剩下來所有的書都可以繼續賣,而且不用給作者版稅。這個條款有幾個問題:
  • 此份合約並未載明剩餘書的數量。
  • 通常這種不付版稅的銷售應該是折價出售的商品,求的只是回本,但此份合約也沒有對於售價有任何限定。
  • 如果以小人之心度君子之腹,若是這本書是長銷書,那麼合約到期前再多印一些,甚至到期後還偷印,又不用給版稅,豈不是太棒了?

星期三, 1月 31, 2007

詞辨:child selector / descendant selector

在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翻譯為「後代元素選擇器」。

星期三, 1月 24, 2007

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

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



延伸閱讀:

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

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

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



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



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

延伸閱讀:

星期一, 1月 22, 2007

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

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

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

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

延伸閱讀:

星期日, 1月 21, 2007

專職翻譯活的好嗎?

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

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

聽起來似乎不錯,不過您得注意以下幾件事:
  • 你得自行負擔所有的業務成本,電費、保險、網路、參考書籍等等。
  • 和工地搬磚塊不一樣的是,你不會每個月結算翻譯稿費,得視各家出版社而定,也許全部譯完後、也許多少份量結算一次。
  • 和工地搬磚塊一樣的是,你不一定總是有書可以翻譯。
  • 最重要的是,不會每一本書都是你很感興趣的主題,也不會每本書都寫的好。
當然啦,最後我還是要說,如果你可以樂在其中,這樣的收入其實還不算差,有興趣嗎?趕快來!

延伸閱讀:

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

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


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

星期三, 1月 17, 2007

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

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個問題的結果,一份只有其中幾個問題,但加上了專家評論的內容,後來再嘗試去下載都只有後面這一份了。

延伸閱讀:

星期二, 1月 16, 2007

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

許多作譯者都有這樣的疑問,稿費或是版稅怎麼報才省錢?另外,許多作譯者也對於給付稿費或版稅時被預扣所得稅耿耿於懷,好像少領了錢。事實上,根據各類扣繳所得標準的規定:
給付稿費、版稅、樂譜、作曲、編劇、漫畫、講演的鐘點費等執行業務報酬,所得人如果是境內居住的個人,按給付額扣繳10%,但是如果每次應扣繳稅額不超過新台幣(以下同)2,000元的話,可以免予扣繳。
所以預扣是守法的,不預扣的你得注意這家公司,並且留意扣繳憑單上的所得分類是否為稿費、版稅、鐘點費這一類,否則會影響你報稅。

至於稿費、版稅的報稅,大部分作譯者都知道有18萬的免稅額,不過根據所得稅法規定,扣除18萬之後的所得,還可以扣除30%作為成本:
個人取得稿費、版稅、樂譜、作曲、編劇、漫畫、講演的鐘點費等類的收入,每人每年合計不超過18萬元時,可以全數免稅,超過18萬元的話,如果是屬於自行 出版的部分,可以就超過部分檢附成本和費用的憑證核實減除或直接減除75%的成本費用,以餘額申報執行業務所得。其他不是自行出版的部分,可以減除30% 的成本費用以後,用剩下的金額申報執行業務所得。
也就是說,如果稿費版稅收入全部30萬元的話,可以先扣除18萬元免稅額,剩下的12萬可再扣除30%,也就是3.6萬元為成本,所以實際上要計入所得的部份就是8.4萬元,這可能就可以讓您少跳一級稅率哩!

延伸閱讀:

星期一, 1月 15, 2007

圖解翻譯稿酬

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



延伸閱讀:

星期四, 1月 11, 2007

Here Comes iPhone, Cool.

透過線上觀看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的簡報術。

延伸閱讀:

星期六, 1月 06, 2007

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

要製作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

如果查閱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,因此許多書也這樣寫就再自然不過了。

星期三, 1月 03, 2007

翻譯名詞:attribute、property

在大多數的書或是文章中,對於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的意思,所以譯為「屬性」並沒有太大的問題。

延伸閱讀: