該學那些程式語言2008版

這主題向來是討論區上常被提出的問題，一言以蔽之，選擇最好的或最受歡迎的…

選擇最受歡迎的，站在你自己的角度來看，它可以提高你在市場上的身價，讓你找的到工作，可以填飽肚子。而站在別人的角度來講，你開發出來的系統容易讓別人接手，開發系統時可用的支援較多，市場的接受度較高，不用重新教育使用者。

選 擇最好的，一方面是可以接觸新思維，提供不同的視野。另一方面，則是期望有一天，最好的可以變成最受歡迎的。而早期投入者，多少可以收到 "傳教士" 般的尊崇待遇。還記得以前 XML 剛出來時，大力推廣 XML 的勞虎，在網路上廣泛傳送其免費電子書《無廢話 XML》，而今多少學習 XML 的網民，還是感念其恩德啊!

那麼，以下便是我的選擇。我會說明其主要應用，及個人對它的觀感。

最受歡迎：

C/C ++：這應該是正統資訊工程科系都必修的語言吧，它的應用不但能讓你直指核心(C)，也能讓你站在物件的具像高度(C++)，思考系統的構成。像是系統程 式、原生應用程式、軔體、Driver 等，皆是 C/C++ 應用所及之處。尤其台灣電子產業相對發達，在各種掌上型、智慧型裝置不斷推陳出新的今天，對C/C++的人力資源有高度需求。不過這個語言(尤其 C++)因為承載太多歷史包袱，各種實作變體太大，開發時常需用很多 tricks，在應用時需要付出較多心力，在程式語言本身及各種環境歧異的細節上!

Java：如果你唸資工 系，但學校 C/C++ 課程非必修，那麼至少 Java 是必修課程吧! Java 除了較少用在系統程式外，其他領域幾乎都占有一席之地。由於 Java 具有良好的物件導向基礎，當代許多企業應用皆採 Java Solution，尤其是在 SOA/ESB/EAI 等領域。採用 Java Solution 的好處是自由度高，但缺點就是很多事情沒有標準作法，或支援標準作法的解決方案太多，往往要花費不少時間在選擇如何架構系統上。

C# & VB.NET：這能讓你賺錢! 可以讓你快速的寫出漂漂亮亮的應用程式! 能讓你與微軟的企業系統做 完美的結合。像是 BI(OLAP、Reporting、Data Mining)那一塊，是 Java 在應用上比較需要費心的。而 .NET 相對於 Java 較緊緻的技術堆疊，能讓開發者較專注於應用程式的開發上。缺點是，離開了微軟平台的世界，就幾無用武之地。

PHP/Ruby：如果你想 run 自己的 business，或想建立一個像黑米、放P、挖女孩那樣的網站，相信我，這是一個很好的選擇。不過由於目前這兩個語言主要用途只在 Web 開發上，因此特別要注意典範的轉移，或是其原來專精的部分不再具有優勢。

就典範轉移：我的意思是，PHP/Ruby 除了在 Web 開發上已有成功的 killer apps 之外，其實它們能做的事，其他語言或平台也都能做，除非它們能在別的應用領域一樣成功，否則對其未來發展仍是一項危機。而就 "其原來專精的部分不再具有優勢"，這並非不可能發生，請見以下的 ECMAScript 說明。但好消息是，至少在 2007 年，這兩個語言的排名在 TIOBE 上的排名都是往上升的。

最好的：

Python： 真正的跨平台，除了跨 Windows, Linux 這類原生作業平台外，它也有 Java 及 .NET 虛擬機器的移植版本。在 Java 與 .NET 競相誇炫平台能力之際，Python 仍能堅守語言本身的原味之美，是令人讚賞的。也因如此，Python 的應用領域眾多，從 Web、文字及檔案處理、科學到研究等，幾乎無所不包。事實上，很多研究平台內定的 scripting language 就是 python，像是用於統計的 SPSS、用於資料探勘的 Clementine 等。

D：被視為是 "C++ done right!" 的一個程式語言，支援了許多 C++/Java/C# 共有的特徵(OOP)，但卻也有些特徵是其他語言所欠缺(或尚在研議中)像 Out function parameters,Nested functions,Function literals,Closures,Resizeable arrays...。在現今 VM 當道的年代，D 仍編譯為 native executable，可見其定位，是比較接近 C/C++ 的。也就是適合拿來撰寫系統程式、原生應用程式、伺服器程式，以及網路應用程式等。不過，對於 D 被廣泛接受仍有重大疑慮，因直至目前為止還不知有任何較大型的專案採用 D 語言開發。相較於 Ruby 也沒有像 RoR 那樣的殺手級應用出現。

最受歡迎+最好的：

ECMAScript/JavaScript/ActionScript：JavaScript 與 ActionScript 都朝 ECMAScript 標準靠攏。本來 JavaScript 是被某些人唾棄的一無是處，以為它只會在瀏覽器上作作表面功夫的語言，但一朝 Ajax 的應用得到普遍的喜愛，JavaScript 的行情也就跟著水漲船高。但如果只是這樣，對於 ECMAScipt 最新標準的推廣倒不見得有多大助益。特別是後來 ActionScript 也遵循 ECMAScript 標準，而且號稱 ActionScript 3.0 是非常遵循，這就好玩了。因為 ActionScript 是應用在 Flex/Flash player 中，而瀏覽器中主要執行的指令語言是 JavaScript， 而這兩者都是當代 Thin Client/RIA 的主流，因此我們可以說 ECMAScript Family 幾乎已成為 Universal Client Lauguage。

再者，認為 JavaScript 只會在瀏覽器上作作表面功夫其實並非事實。早期 Netscape Enterprise Server 及 BroadVision One-to-One Server，在 JSP 尚未出現前，伺服器上執行的指令語言就是 JavaScript。而前文提到現在是 VM 當道的年代，現在 ActionScript 的 engine 也已成為一個 VM，叫 AVM，且已貢獻給 Mozilla，成立 Tamarin 專案，將來若用於 Firefox 中，網頁內的 JavaScript 跑起來說不定會跟飛的一樣。

若是真有人拿 AVM 來寫伺服器，說不定會光復 JavaScript 在 Server 端的失土哦 (好吧! 天方夜譚)! 說真的，AVM Server 版若成(例如成為 Apache 的一個 module)，要威脅 Java 或 .NET 既有地位是比較困難，因為這兩個平台既有應用多、進化動力也強；但對其他 Server 端的 Scripting Language 絕對是個威脅。想想看，若你能在 Server 端及 Client 端同時使用 ECMAScript，那使用 Ruby 或 PHP 的誘因是否會漸漸變弱呢！而 Ruby 會紅，並不是語言本身之美所致，而是出了一個 Ruby on Rails Framework，而 framework 裡面的 concepts 是很容易 porting 到別的語言或平台中的。

其他：

看了以上個人挑選出來的清單，看啊看的，現在還是程序導向和物件導向語言的天下。難道沒有其他不一樣思考面向的東西嗎? 有的，而且我們也還滿常用，像是 SQL，或是各式 Markup Language 了(雖然不是程式語言)。還有那些用在工程、模擬、統計分析、人工智慧上的，你沒有那個環境或從事相關職業，是幾乎無從著手的語言，而這些當然就不算在推薦之內。

結語：

一項語言要被廣為接受，在過去，我一直以為大廠的支援是個必要因素，但 PHP(XOOPs, Nuke...) 及 Ruby(RoR) 這種透過 Community 及 Killer Application 來帶動風潮的成功案例，似乎也印證了 "世界是平的" 的論點，在這個網路世代，不只大企業，小企業及個人一樣有機會。Killer Apps 與 Success Stories，可能比大廠背書更有價值。

而對於你的選擇，我想，如果要做個尋常的程式開發人員，我會建議你 ECMAScript Family 一定要學，那 Java 或 .NET 再選一種。若你是個不尋常 (開發特殊應用的軟體) 的程式設計師，通常也就沒什麼好選了，因為應用的型式就決定了我們的選擇。

想起一段令人感傷的住事

記得在國小一年級時，班上有個年約 16 歲的同學。這麼大的年紀才唸小學，在以前經濟尚不發達的年代並不算特別。然而，他倒不是因經濟問題才延遲就學，而是因為學習上的理解力不佳。他可能可以勉強知道 1 + 1 = 2，但問他 3 + 4 等於多少，就已經超越他的能力了。事實上，他已唸了好幾次小學一年級了。

由於年紀的及學習能力的因素，他常成為學校同學的笑柄。年代久遠，我已不記得我是要別的同學別取笑他，還是跟著別的同學一起欺負他。這樣從開學後一直過了一兩個月，突然有一個星期一他沒到學校。我想起，上個星期六放學時我似乎是跟他一起走路回家的，有一種不好的念頭出現在我的腦子中。

放學後，我到了那個我之前常去的小公園，我知道他家就在附近。我想問問他家人他去哪裡了，怎麼沒上學。還沒到他家，卻看到，他已經掛在相思樹上，上吊死了…

我有另一個同學，他的哥哥因為高燒而智力受損，也就是一般認定的白痴。那種言語不清，看起來髒髒的，好像一段日子沒洗澡的樣子，大家都認得出來這樣的人。從他智力受損後，別人當然也會取笑他，大人小孩都欺負他，但他似乎不能區別那是不是欺負，他一直過得很快樂，真的是笑罵由人，從小到現在，快 40 歲了!

這段年代久遠的記憶，多年來不曾在出現在我的腦海中。我甚至可能是選擇去故意遺忘它--我沒再去過那個鄉下的小公園。在那之後，的成長過程中，我也的確一直沒想起這事。讓我想起這事的原因，可能是因為某些情境觸發了我。我偶爾會聽到有人在教育小朋友時，說出：「你怎麼可以笨成這樣… 你為什麼不去死一死好了…」。

這段回憶提醒我，惡語傷人六月寒。即使是身邊的家人、朋友，也可能因一句不小心的剌激而走上絕路。而萬一傷人的話語成真，背負著的，可是一輩子的歉咎與不捨。

iGoogle 與 Google Reader 裡的 RSS 訂閱

之前看到有人在「訐譙(ㄐ｜ㄝˊ ㄑ｜ㄠˊ)」Google 把預設的 RSS 訂閱導到 iGoogle 去，有人說是版本有差，有人說是已改了回來。我的 firefox 則是到現在還是這個樣：只會導到 iGoogle 去。

雖然我也是 iGoogle 的愛用者，但是想放到 Google Reader 裡去細細品嚐的資訊，真的跟想放在 iGoogle 上的資訊不太一樣。強迫用戶只能接受 Google 的指定，未必合理。不過若是做個瀨尿牛丸，真正的把 iGoogle 跟 Google Reader 訂閱做進一步整合，也是可能的解法。

我的想法是，既然放在 iGoogle 上的 google bookmark 會在 google bookmark manager 內被自動置入 homepage folder，那何不如法泡製，將加入 iGoogle 個人化首頁的 feed，也自動放在 Google Reader 內的 homepage folder 中。如果用戶已在 iGoogle 內加入分頁標籤，那更可用頁籤名稱作為 Google Reader 內的 folder 名稱。

另外，在 iGoogle 內閱讀 RSS 文章時，如果也可以選擇將文章開啟在 Google Reader 中，那種感覺也是挺不賴的!

「留著」哲學

以前對於留在身邊的東西，總有一種去蕪存菁的怪癖。 我不喜歡沒有用的東西，我不喜歡用不到的東西。 凡是東西用不到了，總是想要將它移除，丟掉。 留著沒有用的東西，就是浪費空間。 而這年頭，會跟我們有所牽扯的東西，卻又不可勝數。 在網路上寫日誌、評論，會留下你在各地的思想點滴。 換了一家公司上班，就多了至少一份經歷，也至少多了一個銀行戶頭。 有些東西做了之後是無法拭去的，像是學歷，工作。 有些東西卻是可以加以刪除，像是那些因為換了工作後，久久未曾再動用的戶頭。 前一陣子心血來潮，想要將那些久未動用的戶頭清一清。 但其實對一個上班族而言，這麼簡單的動作卻未必容易。 大抵上，銀行會跟你說：抱歉哦！要到原開戶行才可以結清。 你還記得開戶行在哪嗎？ 就算記得，你確定結清所得的款項會大於花了時間跟金錢跑到那兒的代價嗎？ 更重要的是，說不定下次因為某些因素，可能還要重新啟用那銀行的戶頭呢！ 所以我想：留著吧，也許以後會用得著。 當下，我只要先把那些零頭，轉到別的戶頭去就行了。 等到有一天我退休了，在畢業之前那段美麗的、短暫的、悠閒的時光中， 再來結清吧。

奇妙有趣的設計塔圖

「設計塔圖」是一種神奇的「創造性思考技法」，依照「設計塔圖」思考技巧所建構出來的思想產物，將同時具有連續性與關連性。如果將任一處的連接線切斷的話，那麼整個系統就將遭到破壞。「設計塔圖」對於聯想力及系統化思考，極為有益。

我們以「何謂備忘錄」這個主題，來說明「設計塔圖」的應用方式。

備忘錄具有聯想、資訊、留言三種功能，因此就把這些功能當成三角形的頂點記下，到此已完成基本骨架。

然而，為了使備忘錄促進聯想，就必須把所想到的事項立刻記下來。也就是說，書寫工具必須和備忘用紙同時攜帶在身上。於是在「聯想」之下，就立刻出現「攜帶」這個字眼。

其次，必須要能妥善的「保存」備忘錄，才能使它的「資訊」架值得以彰顯，但若要使資訊更有價值，更有助於聯想，就得好好「整理」備忘內容。

就另一項功能「留言」而言，它與其他兩項功能最大的差異在，它必須不斷的意識到「他人」的存在。這不是為自己而作的備忘錄，而是為他人而做的。在備忘錄的內容被接收之後，這份備忘錄也就可以「消滅」了。

而就交付者的立場來說，要儘量網羅5W2H的內容。如此一來，就算備忘錄離開自己的手上，內容也不會遭到誤解。

另一方面，就接收留言者的立場來說，也可妥善應用備忘錄，將其內容「內在化」，加以了解及吸收，以提昇自己的構想。

與備忘錄有關的「設計塔圖」完成了。普通的發想法通常只是針對特定的主題作各種聯想，因此常呈片段而零亂的狀況。 而「設計塔圖」，卻能將這些零亂的聯想系統化。

有了這一張圖，不但可顯示要點，亦能將之擴大成文章，一魚多吃。但在過程中，卻好像只是進行了一場排列關鍵字的遊戲而已。

※ 給採用 RSS 閱讀軟體的讀者：有些 RSS 閱讀軟體並不能正常顯示內嵌物件，請移駕本文原始網頁，才能看到 slide show 講解的「設計塔圖」。謝謝!!

管理寓言：男人愛當顧問

在彭懷真所著的《時間好經營》中，讀到這樣一個管理寓言：

甲君養了隻愛叫春的公貓，每晚嚎叫吵得鄰人無法入睡。在群情激憤下，甲君不得已將公貓送去獸醫處使其不能貓道。幾天過後鄰人仍見那公貓夜夜外出 “辦事”。鄰人不解而問之，甲君便說：牠現在到處去給別人當顧問。

自從聽到這個比喻之後，我就對顧問這個身份感到過敏 (偏偏我的 title 便是顧問)。從上面的故事來看，似乎在諷刺顧問是只剩一張嘴，不能幹正事的人。不過，我在大陸的網站上看到另一個版本，而有不同的解釋：

社區裏，有只公貓，花心，夜夜出去，找母貓鬼混。 後招各家公貓投訴，女主人一狠心，把這只花心貓喀嚓了。 花心貓被喀嚓了後，仍然夜夜出去，回來後竟然更得意。女主人大奇。 花心貓得意地說：“您把我喀嚓之後，我是不行啦，那些公貓也安靜了幾天，不過他們現在都高價請我去做consultant。”

該站作者解說如下：

• 各家公貓投訴，說明這只貓很有魅力和能力。暗喻在公司裏面能力非常強的sales，但是這個sales很自狂，未處理好同事之間的利益關係，遭同事到老闆那裏投訴。
• 女主人把這只貓喀嚓了。暗喻老闆是昏君，賢能招妒無善終。
• 公貓後來被大家聘consultant.暗喻公貓的實戰能力還是大家公認的，做consultant是無奈之舉。

不過我覺得這樣的解釋也有些牽強。有實力的人，何以只能無奈的做consultant。真正有實力的話，不但能在旁指導，甚且可以自己入場打場好球。有道是心寬天地寬，何必自嘲受昏君閹割啊！

台北市圖書館的貼心服務

大家都知道圖書館可以借書，但若談到預約借書的功能，可能就比較少人知道或使用了。而把預約借書功能發揮到極致的，我想台北市立圖書館算是其中的佼佼者。 預約書籍很簡單，首先，你要辦妥借書證。然後登入台北市立圖書館網站 (密 碼預設是你的生日)，搜尋感興趣的書籍。找到書籍後，便可按下畫面上的預約連結進行預約。也許有些書籍只在其他館藏中才找的到，沒關係，台北市圖書館讓你 可以跨館預借，並讓你自由指定所要取書的分館。大概一段時間後 (約一個禮拜)，圖書館會幫你把書備妥，送到指定的分館，並發出 email 跟電話通知你在三天內取書--完全不收分文。email 格式長相像下面這樣：

MR. XXX 臺端所預約之以下圖書已到館,請至圖書館辦理借閱, 收到本館通知逾3日未取則（送回原典藏館）上架供其他讀者 閱, 謝謝 ! 請注意︰此郵件是系統自動傳送，請勿直接回覆此郵件，若 需要請直接與(取書館)聯絡。 1 XXXXX/ AAAA ; BBB, CCC譯 AAAA call number:000.0 0000 copy:1 2 YYYY: YYYYYYY/ DDDD. EEEEE著 ; FFF譯 DDDD call number:111.1 1111 copy:1

如果你想，甚至可以要求圖書館將書透過貨運送到你家，而你只要出資支付貨運費即可。 Anyway，這是一項相當體貼便民的服務。不過我也擔心，若是使用這服務的人多了起來，是不是會造成圖書館的作業成本太高…考慮到這點，還是把借回來的書努力的 K 完再說吧。 ※ 2007/9/1 另一點通知：台北市圖書館用悠遊卡也可以借書了喔! 詳情見此。

雜牌軍現象與石油提鍊作用

問題很簡單，就是團隊裡面誰會出線，支援前線作戰！而其後果又會對組織造成何種影響？

站在支援部門這邊的觀點，若是支援前線這檔子事對於本身無利可圖，那麼她所派出的傭兵將可能是團隊內貢獻能力最少的成員。每個被要求支援的部門都把 "功能較弱" 的成員交給外部專案經理，最後，整個專案團隊的組成就成了雜牌軍。此謂雜牌軍現象！

與此極端相反的狀況稱為石油提鍊作用：支援外部專案的人員必須經過外部公司的專案經理審核，審核不過者只能留在組織內進行內部專案… 這個程序，有如石油提煉的過程：

– 天然煤氣分餾溫度在20°C以下
– 汽油分餾溫度在20~150°C
– 輕油分餾溫度在120~220°C
– 柴油分餾溫度在200~360°C
– 重油分餾溫度高於360°C
– 最後的殘餘物—瀝青

不同外部專案的經理把最好的人才，次好的人才，再次好的人才一層層的過濾出去，最後留在組織內的就只剩瀝青了。這對公司內部專案的進行，甚至是公司的核心進化產生莫大的阻礙。

不管是雜牌軍現象還是石油提鍊作用，都在彰顯一個準則：組織要能建全運作，必需能留住優秀人力。

人力的組成決定打法，更決定勝負。

這就像玩牌一樣，手中握有的牌，永遠會主宰你發牌的順序。若是手中僅有幾張王牌時更要小心，太早發了，後面就後繼無力，遭人宰制。晚點發，就可能永遠也發不出去。最好是想辦法換牌，調整手中部位。我相信，有些組成是不用下場玩，就知道勝負如何了。

如何成為令人倚重的程式設計師之另類思考

昨晚與好久不見的朋友餐敘，提及當年某公司有一個 "優秀" 的 RD 部門主管及另一個 "重要" 的程式設計師。那位 "優秀" 的 RD 部門主管總會用正規的方式設計，有良好的軟體架構，並且開發過程中及完成後，都會提供其設計文件、使用手冊或範例程式。
另外有一個公司所 "倚重" 的程式設計師--並不是說他不優秀，只是他對公司的重要性，大於他的優秀性。
公司裡面複雜的系統，只有他能維護。而前人所留下的程式，並沒有相關的文件說明該系統的整體架構設計跟思維。
這就產生了一個有趣的現象：對於一個程式設計師而言，把事情做到最好 (除了寫程式外，還寫了讓人看得懂的文件等等)，對他本身而言並不一定是好事。當別人越了解你的系統，你的可替代性就越高，那麼你的價值不就越低？
反之，若有人能寫出他自己才看得懂的程式碼，就算上級要求寫文件，也是寫一些高深莫測、形而上學的東西(諸如，用90%的篇幅介紹物件導向的基本觀念，然後說明只要了解物件導向或設計模式的觀念，再自行 trace 程式，就能理解系統運作)。
這樣一來，後人無法維護該套系統，完全是後人資質不佳或能力不足。這樣，他就成為令人倚重的程式設計師了。
以上所言，並不代表本人立場!
PS: 即使是某公司那一位令人倚重的程式設計師，也沒有達成我上述的要求，因為他沒有寫出需要睿智才看得懂的文件。何況，那些不可維護的程式碼，他也曾經力圖改良，想讓人看懂過！

我的一點 Thunderbird 使用訣竅

自從進入目前公司後，我便一直以 Thunderbird 作為我的 email client，算算時間也三年半以上。這一路走來，我發展了許多 Tunderbird 的應用密技，我想有許多可能是別人沒想過要這樣用的，特別發表出來，與各位分享。

(一) 利用 Message Filter, 將所有不在 Personal Address Book 中的來信，全部移到 Junk 信件夾

因為垃圾信實在太多，只好使出這招釜底抽薪的方式。如果是業務、專案上的初次來信，通常事先會透過電話連絡。此時只要手動自 Junk 中移回 Inbox，再將寄件人加入 Address Book，下次即不會再跑到 Junk box 中。

(二) 快速安裝 extension 的方式

在 https://addons.mozilla.org/thunderbird/ 裡面找到所要安裝的 extensions 後, 在網頁的 Install Now 按鈕上選右鍵，選 "複製連結網址"。然後打開 Thunderbird  的 Add-ons 管理員，按 Install，在 Select an extension to install 檔案對話窗中，在檔名文字欄位按 Ctrl+V 貼上 extension URL，再按下開啟，就會進行安裝程序。

(三) 用 7-zip 來修改 extension 的安裝資訊

如果你也是嚐鮮一族，已在使用 Thunderbird 2.0，那麼你將遭遇最大的問題極可能是 extension 版本的不支援。如果你願意碰碰運氣，可採用下面這種作法：

1. 以 7-zip 開啟 extension 的 xpi 或 jar 檔案
2. 在壓縮檔案的 install.rdf 按右鍵選編輯
3. 7-zip 會以你設定的編輯器開啟 install.rdf，找到類似以下這一段，將其中的 em:maxVersion 元素值調整到你的 Thunderbird 版本以上，例如 2.*，然後存檔，關閉編輯器

       
           
                {ec8030f7-c20a-464f-9b0e-13a3a9e97384}
                1.0
                1.5.*
           
       

4. 7-zip 將提示你檔案已被修改過，是否要更新壓縮檔之訊息，請選擇確定，然後重新安裝 extension 即可。

(四) 用 Plaxo 同步通訊錄

不曉得你有沒有因為重灌電腦而遺失通訊錄的經驗呢？重灌電腦時，我通常會記得備份信件，但是聯絡人卻老是因忘了備份通訊錄而流失。

Plaxo 是一個線上服務，提供通訊錄、行程、作業及記事管理等諸多功能。對於 Thunderbird 而言，最實用的地方在於它提供通訊錄同步的 extension。我把 Plaxo 當成是我的通訊錄管理員，因為它支援了匯整、備份、同步聯絡人的功能：

• 匯整：我把 MSN、Yahoo!、GMail 上所有的連絡人全數匯入 Plaxo 中
• 備份：經上述匯整後，Plaxo 成為我唯一一個需要維護通訊錄的地方。因為在資料存在 Server 上，只在 Plaxo 還在，我永遠不怕通訊錄再次流失
• 同步：因為使用多台電腦，而且我在不同的地方都裝有 Thunderbird，我可以透過 Plaxo 同步不同機器上的連絡人

在 Thunderbird 2.0 上安裝 Plaxo，由於 Plaxo Thunderbird Extension 目前只支援到 Thunderbird 1.5，所以請用前述的方法以 7-zip 來修改 extension 的安裝資訊。另外，個人覺得 Plaxo Toolbar 的設計極醜。若要隱藏 Plaxo Toolbar，可在選單列上選擇 PlaxoPreferences，將 Plaxo Preferences 對話窗中的 Show Toolbar check box 取消即可。

(五) 使用 Duplicate Contacts Manager 移除重複連絡人

當我使用 Plaxo 合併 MSN、Yahoo!、GMail 上的連絡人時，常會造成連絡人重複。透過 Duplicate Contacts Manager 這個 extension，可以快速找出重複聯絡人，並選擇保留與移除的項目。在移除重複連絡人後，從選單列執行 PlaxoSync，你會發現 Plaxo 通訊錄裡面重複的連絡人也被移除了。

(六) 將寄件備份與收件資料夾合併

我將寄件備份放在 Sent 信件夾中，Inbox 用來保留最新的信件。每隔一段時間，我會將 Inbox 裡的信件移到 Sent 信件夾。如此，在 Sent 資料夾中採用 Thread 模式檢視時，我獲得一個類似 GMail 的 Message Thread 介面，可以很方便的看到發信與回信的脈胳。

(七) 將老舊的信件移存到不同的信件夾中

將較老舊的信件，以年為單位封存到不同的信件夾之中，可以避免掉 Thunderbird 同一信件夾不得大於 4G 的限制。

(八) 使用 Remove Duplicate Messages 移除重複信件

有時在不同的信件夾間複製或移動信件後，會造成同一資料夾內信件重複的狀況。使用 Remove Duplicate Messages 這個 extension，可以快速的刪除重複的信件。在信件刪除完畢後，別忘了在該資料夾上執行 Compact，如此才能真正的減少信件檔案的儲存空間。

(九) 善用 To(收件人) 或 Subject 信件表頭欄位分類信件
我知道 Thunderbird 2.0 已正式加入對 Tag 的支援。但是我所採用的方式，不但適用於 Thunderbird 1.x，而且比之 Tag 的操作更為簡易。作法很簡單：在編輯新信時，我會把 To 欄位拿來輸入分類關鍵字，我稱為 To tags。例如，這篇 blog 就是在 Thunderbird 中編寫的。我將此信件的 To 欄位分別加上 blog, note, thunderbird 三行。如果是內收信件，就需要 TB Header Tools Extension 這樣的 extension 才能更改信件表頭。對於內收信件，我通常會透過修改 Subject 的方式，來分類信件，如 [Project:Company].... 這樣的格式。

(十) 善用 Search  Folder  建立分類檢視

Draft 信件夾原本放置外寄信件的草稿，在我為信件加上 To tags 後，它變成個人記事資料夾。我進一步為 Draft 信件夾建立各種查詢條件的 Search  Folder 來設定分類檢視。例如我有個 Search  Folder 名為 "部落記事"，其查詢條件為 "to Contains blog"；另有個 "生活記事" 則對應為 "to Contains diary"。當然，透過 Search Folder 可建立更複雜的查詢條件。

同樣的，專案的分類檢視也可透過建立 Search Folder 為之，只是查詢條件會變成 "subject Contains Project:Company" 這樣的型式。

(11) 拿 Drafts 信件夾當記事薄

之所以拿 Drafts 信件夾當記事薄，而非別的信件夾的原因是：預設 Thunderbird 所有新信存檔時都會存放在 Drafts 信件夾中。你可以在 Drafts 信件夾重複編輯信件，而不用擔心它會跑到別處。要 Tag 分類的功能，可用上述的 To tags；要樹狀分類的功能，則可用 Subfolder 結合 Search Folder。

當初會想用 Thunderbird 來做記事管理，另一個原因是它的 Rich Editor 功能實在做的太好。而信件又可夾帶附檔，加入圖片。再說，除非你只用 Web Mail，否則電腦裡極可能需要一套 email client，既是如此，那何不就把它的應用效益最大化，這樣又少了需要另外安裝記事軟體的需求。