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

延伸閱讀：

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

編輯作品：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族群在這類書籍的接受度，希望能夠有好的結果。

延伸閱讀：

• 此書作者的blog
  

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

在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

自從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？

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

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

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

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

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

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

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

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

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

取得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"，而外國人一看便認為是沒有到場了，因此，用或不用「杯葛」就值得商榷了。