highlight.js

星期六, 12月 30, 2006

Treemap 簡易教學示範

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)的寬度等等,操作都很直覺,應該難不倒各位,簡單示範,就此打住囉。

延伸閱讀:

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

凡是從事網頁程式開發者,最終都會遇到與版面設計人員之間的紛爭,不論是設計人員誤改了程式員完美邏輯的程式、抑或是程式員粗心的弄亂了設計人員精心配置的精美頁面,總是都想怪對方,又都怪不得對方的尷尬窘境。為了解決這個問題,綜觀各方意見,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族群在這類書籍的接受度,希望能夠有好的結果。

延伸閱讀:

星期四, 12月 28, 2006

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

在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這間獨具特色的出版商有這樣優秀的領導人感到欽羨。

延伸閱讀:

星期二, 12月 19, 2006

Web2.0 = BBS

自從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,但差別是幾乎所有的人都玩的不亦樂乎了。

星期三, 12月 13, 2006

URI、URN、以及URL?

在大部分的書上,可能會出現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,這是在使用詞彙時必須注意的事情,否則對於某些讀者就可能會造成誤會。

星期三, 12月 06, 2006

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

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

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

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

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

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

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

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

星期二, 12月 05, 2006

取得Excel工作表的名稱

我自己拿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()從這個位置的下個位置開始,取出到字串尾端的所有字元,就是工作表的名稱了。

書介:咬文嚼字話翻譯

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

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

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