Prism for Firefox 3 beta 5 url link opening issue

今天將自用的電腦換成還在 beta 中的 Firefox 3，順手就裝了可以「將網頁變成桌面程式」的擴充套件 Prism。它的功能一如產品網頁描述，可以在桌面產生一個 URL 連結，也可以顯示 tray icon。

我首先轉換的應用網站便是 Gmail，轉換成完後，點選桌面 Gmail 捷徑，帶出一個沒有任何修飾 (不會讓你分心) 的 Gmail 應用程式視窗。怪的是，在我的環境 Windows XP + 這樣的組合下，在 Prism 的 Gmail 網頁中開啟 URL 連結時，它開啟的外部瀏覽器竟是 IE，而不是我所期望的 Firefox。在 Firefox 「工具/選項/進階」中將 firefox 設定成系統預設瀏覽器也沒有用。

本想試試 Linky 這個專門用來改進連結開啟方式的擴充套件，但在 Prism 中卻無法安裝。我沒去細究那是 Prism 本身，還是 Linky 或 Firefox bata 3 的版本關係，總之就是不能用。

查了一下 firefox command line arguments, 看到了 -setDefaultBrowser 這個選項，可以將 firefox 設定成系統預設瀏覽器。於是我試著在 DOS 指令視窗中輸入以下指令：

C:\>cd "\Program Files\Mozilla Firefox 3 Beta 5"
C:\Program Files\Mozilla Firefox 3 Beta 5>firefox -setDefaultBrowser

沒想到這麼一來，當我再次於 Prism 的 Gmail 網頁中開啟連結時，竟然就能將連結開啟於 Firefox 中了。

相關連結：

• Prism: 將網頁變成桌面程式
• Gmail: Google 所推出的 webmail 服務
• firefox command line arguments: 說明 firefox 啟動參數
• Linky: firefox 延伸套件

Technorati : bug fix, firefox, firefox 3, prism, tweak

Miro 1.2.* 無法啟動的 Bug 及 Quick Dirty Fix

Miro 這套以 XUL Runtime 為基礎的網路影片撥放軟體，有著優良的使用介面及易用豐富的影片搜尋功能，在網路上已經有不少 blogger 介紹過，我就不再贅言。

如果你也是 Miro 的愛好者，或是看過介紹後躍躍欲試，卻同我一樣遭遇以下畫面：

除了程式視窗外框、骨架外，所有內容都沒有顯示出來。那麼底下提供一個 quick dirty fix，或許可以解你想看影片的燃眉之急。

首先，找到 C:\Program Files\Participatory Culture Foundation\Miro\components\pybridge.py 這個檔案。找到其中一段程式碼：

   keyElement.setAttribute('keytext', _('Spacebar'))

由於這行程式中的 _(Spacebar) 在執行期會運算成 "空白鍵" 這個中文字串，進一步造成 UnicodeDecodeError: 'ascii' codec can't decode byte 0xe7 in position 0: ordinal not in range(128) 的錯誤。因為並未深入了解 Miro 完整的 localization 架構，這是一個目前看來我無法完整解決的問題。因此我採用一個 quick dirty fix，將上面那行改成如下：

   keyElement.setAttribute('keytext', 'Spacebar')

注意，由於程式是 python 語言，因此請不要改變以上程式碼的縮排。儲存檔案，重新開啟 Miro，那麼你應該可以重新找尋、欣賞喜好的影片了。

Note: 本方法僅在 Window Miro 1.2, 1.2.2 版上試驗過。

Technorati : bug, bug fix, miro, video, web

該學那些程式語言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 講解的「設計塔圖」。謝謝!!