愛德華日誌 - developing

PMOG 簡易練功外掛

noreply@blogspirit.com (Edward HSIEH) — Thu, 08 May 2008 00:03:50 +0800

前一陣子收到了 PMOG 的啟用信，便依照「電腦玩物」的說明，趁著工作空檔試玩了一下。突然想到，在一般的 game 系統，都有一些超級玩家或高手，懂得利用外掛程式來練功，那這個 client 端基於 Firefox 的遊戲平台，要寫一個練功的外掛應該也不是難事吧!

PMOG 平台裡面，透過 Datapoint 來代表玩家的經驗值。增加 Datapoint 最簡單的方式，就是瀏覽不同網域的網頁。如果我們要透過這樣的規則來練功，代表我們每天要想辦法去到不同的網域。而哪來那麼多不同的網域呢來瀏覽呢？

透過 Google 查詢，我找到一個 "Random Link" 連結，每當你瀏覽這個連結時，它會將你導到不同的網址。因此，你可以把這個連結放到 Firefox 的書籤工具列，每次按一下，就會連到不同的網頁。

接下來，就是想辦法讓上面的程序自動化。有時間、有時間精神的高手可以寫個 Firefox Extension。比較偷懶一點，就可以透過 Greasemonkey script 來達到這個功能。以下是我所使用的 user script：

// ==UserScript==// @name           automatic random link// @namespace      http://isong.blogspot.com/// @description    visit random web pages automatically// @include        *// ==/UserScript==setTimeout(function() {  location.href = "http://random.yahoo.com/bin/ryl";}, 5000);

只要在 Greasemonkey 中增加此用戶腳本，然後在想練功時啟用此腳本，就可以看到你的 Datapoint 值不斷增加囉!

相關連結：

PMOG: Passively Multiplayer Online Game 官方首頁
電腦玩物: 現實網路尋寶冒險，Firefox上的被動式多人線上遊戲：PMOG -- 完善的 PMOG 遊戲說明
Greasemonkey: 可自訂你的網頁瀏覽體驗
Greasemonkey Firefox 附加元件
Userscripts.org: 可在這裡找到許多給 Greasemonkey 使用的用戶腳本
Random Link: Yahoo! 所提供的隨機網頁連結

Technorati : firefox, funny, game, greasemonkey, pmog

用 JavaScript 來修飾你的超連結

noreply@blogspirit.com (Edward HSIEH) — Tue, 22 Apr 2008 20:17:08 +0800

網頁之間的互相引用、評論，是當代網誌的形式之一，而造就的結果就是正文之中充斥著超連結。

這樣的書寫風格本身並沒有所謂的好或不好。在我的日誌中，也存在不少此類用法。問題是，如果同一篇日誌中，重複提及一個特定的網頁，而該網頁又值得透過超連結參引，那麼重複編製超連結的動作，也會令人覺得繁瑣。

為此，我想到設定一種 "形式"，再加上 JavaScript，來為正文中的特定字眼加上連結。

構想是，在每篇網誌的最後，加上一段 "相關連結" 或 "參考資料"，段落名稱是什麼不重要，重點是：

將連結以無序清單的形式標明，每一清單項目以連結開頭
以冒號+空白 (": ") 來區分連結及解說文字，例如：
- 愛頌過生活: 就是過日子，人生不需太多大道理!
- DOM: Document Object Model (DOM); W3C 的官方說明

上例中的 "愛頌過生活" 及 "DOM" 字串，會被當作匹配條件，在正文的段落 (<p>...</p> 包起來的部分) 中，比對相符的字眼。若出現相符的字串，將被 JavaScript 套上超連結。

用來轉換文字成超連結的 JavaScript 程式碼如下：

<script type="text/javascript">var init = {  cmds: [],  run: function(){    for(i = 0; i < this.cmds.length; i++)      this.cmds[i]();  }}function getText(anchor){   return anchor.text ? anchor.text : anchor.innerText;}function fixPostElements(){   var uls = document.getElementsByTagName("ul");   for(var i = 0; i < uls.length; i++)      insertResourceLink(uls[i].parentNode)}function insertResourceLink(element) {  var links= {};  var lis = element.getElementsByTagName("li");  for (var i = 0; i < lis.length; i++){    if(lis[i].innerHTML.indexOf(": ") != 0){      as = lis[i].getElementsByTagName("a");      for(j = 0; j < as.length; j++)        links[getText(as[j])] = as[j].href;    }  }  var ps = element.getElementsByTagName("p");  for(key in links) {    var regKey = new RegExp(key, "g");    for(var i = 0; i < ps.length; i++) {      ps[i].innerHTML = ps[i].innerHTML.replace(regKey,         "<a href="+ links[key] +">" + key +"</a>");    }  }}init.cmds.push(fixPostElements);</script>

將上面的程式碼置於 HTML 的 head 區塊，在 body tag 中加上 onload="init.run()"，於撰寫網誌時採用本文規範的形式，即可達所述的效果。

一篇符合本文形式規範的網誌文章，可參考 "PRISM for Firefox 3 beta 5 url link opening issue"。事實上，筆者正是在撰寫該文時，因對重複的超連結編製深感不耐，才產生此構想的。

附帶一提，如果讀者採用 Google Reader 或其他 RSS 閱讀軟體，那麼你將無法看到此 JavaScript 的效果，因為 RSS feed 中並不含 JavaScript 轉譯碼… 這樣的設計，或許可以解釋為：「為親自造訪本站的讀者，所提供的一點加值服務 ^__^」。

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

noreply@blogspirit.com (Edward HSIEH) — Sat, 12 Apr 2008 17:28:41 +0800

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

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

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

首先，找到 C:Program FilesParticipatory Culture FoundationMirocomponentspybridge.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

Java: 淺談 OSGi 標準

noreply@blogspirit.com (Edward HSIEH) — Thu, 03 Apr 2008 20:31:31 +0800

OSGi 起源於1999 年三月，是由一些家用閘道器相關產業廠商所組合而成的組織，目前約有八十餘家廠商加入。包括了 IBM、Sun、BMW、Motorola、Nortel、Nokia、 Philips、Panasonic、Sony、Toshiba、Echelon 等。目前最新的標準是OSGi Specification 3.0。

當初制定OSGi 標準的最主要的目的，是要為遠端的服務提供者 (Service Provider) 與本地端的設備 (Device) 之間提供完整的點對點服務傳送解決方案。因此，OSGi 定義了一個開放性的平台，使得遠端軟體服務供應商所提供的應用程式及加值服務，能視使用者需求，隨時下載至靠近用戶的閘道器 (Gateway) 上，並且自動安裝執行，而這裡所指的閘道器通常是連接家庭網路(Home Network)、辦公室網路 (Office Network) 與廣域網路間的一個裝置，如機上盒 (Set-top Box;STB)、ADSL數據機、纜線數據機 (Cable Modem)、住宅區閘道器 (Residential Gateway)等。透過這個開放性的平台，不同廠商所開發出的服務軟體及設備都能互相溝通及搭配使用。

在 OSGi 網站上的 FAQ 中，指出 OSGi 應用方向包括：

Services in the Home:
- Communication
- Information/entertainment
- Safety and security monitoring
- Energy management and metering
- Appliance diagnostics and servicing
- Telemedicine and healthcare monitoring
Services in the Car:
- Navigation
- Emergency assistance
- Mobile commerce
- Information/entertainment
- Vehicle diagnostics
- Location-based services

Again, we see java succeeded in J2ME. We can see many big-name companies in the OSGi member name list which include many companies come from many industries.

最近 OSGi 在軟體業最為人雀躍的發展，莫過於 Eclpise Java IDE 支援 OSGi 標準。這是一個有趣的現象，本來是設計給其他產業的運用，卻在軟體業也有不凡的表現。這也讓我想起 Java 的發展歷史，本來也是為了 embedded 系統而設計，卻意外的在 internet 竄起的年代獲得各方的矚目，更在 enterprise application 中立於不敗之地...

JMX 與 OSGi 在功能上的許多重疊之處，在國外已經有人討論過 (例如 Eclipse Embeds OSGi Based MicroKernel 及 JMX vs. OSGi - The New Flavor of the Eclipse Runtime)。不過我認為重點是：

JMX 本來設計的用途就只為了管理，我們不該把他拿來 (over use) 作為開發應用程式的元件 (那是 EJB 或 JavaBeans 該做的事)。但 OSGi 卻可以!
JMX 多數用於 server 系統中，而 OSGi 卻不限於所開發的應用程式。你可以用它開發 embedded 系統、desktop 程式，甚至是 server 程式。

OSGi 不但提供了與 JMX 相似的容器管理能力，甚至它本身就是一套精密的 Framework。OSGi 採用Micro-Kernel 的架構，可以提供無限延伸的功能。OSGi 的 Bundles 線上更新功能、以及應用程式之微量記憶體執行能力，都是開發應用程式的利基。

OSGi 與 J2EE 在設計上，我覺得完全是兩種思維模式：J2EE 的思維是 build on large scale，OSGi 的思維是 build on dynamic scale。OSGi 以小搏大...

OSGi Resources:

註:

目前我看到與 OSGi 有關的 JSR 為：

JSR 8: Open Services Gateway Specification (OSGi)
JSR 232: Mobile Operational Management

該學那些程式語言2008版

noreply@blogspirit.com (Edward HSIEH) — Wed, 19 Dec 2007 05:45:00 +0800

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

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

選擇最好的，一方面是可以接觸新思維，提供不同的視野。另一方面，則是期望有一天，最好的可以變成最受歡迎的。而早期投入者，多少可以收到 "傳教士" 般的尊崇待遇。還記得以前 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 再選一種。若你是個不尋常 (開發特殊應用的軟體) 的程式設計師，通常也就沒什麼好選了，因為應用的型式就決定了我們的選擇。

Google Trends 網路開發應用趨勢分析

noreply@blogspirit.com (Edward HSIEH) — Thu, 26 Jul 2007 17:32:00 +0800

Google Trends 向來是我愛用的簡易趨勢分析工具之一。它的輸出趨勢圖形分成上下兩個區塊：上方區塊線條代表相對上的查詢量，也就是關鍵詞在某一段時間內，相對於所有查詢所占的比率，我將它引申為「一個議題被網路大眾所關心的程度」；而下方區塊線條表示關鍵詞在 Google 新聞裡被提到的次數，我將它引申為「一個議題被幕後黑手炒作的程度」。其細節資訊在 "About Google Trends" 裡面解釋的很清楚。

本想透過 Google Trends 查詢當前各程式語言的熱門度，幾翻探索之後，看到一些有趣的現象。雖然這樣的探索談不上精確與科學--若要強調這點，可能還要參考各種 Page Rank、網站流量、新聞群組討論數。這裡著重的是分析的樂趣，適可作為一點茶餘飯後的話題，當成餘興節目欣賞。

分析：各語言的熱度消長

java c# c++ python ruby

這裡可以看到，整體上來講，所有程式語言在網民心中受到的關注，都呈現消退的現象。有人說 C# 或 .NET 過去一年以來市占率有所增加，但實際上卻可能是導因於 Java 自己本身的衰退。C++ 逐漸衰退；Ruby 有超越 Python 往上爬的趨勢，而事實上實力仍在伯仲之間。

那麼問題來了，為何程式語言整體上的熱度下降了呢？從 Search Volume 的定義來看，有可能是上網人口結構的改變 (非程式設計背景的人口增加了)。或是新的網路題材迸現，程式設計師心有旁鶩。或是典範轉移，語言層級的題材已漸式微。

分析：Dynamic Language 有熱起來嗎？

python php perl ruby javascript

從 News Reference 的顯示，PHP 及 Ruby 均有一群推手熱情提倡。但從 Search valumn 來看，網民的反應或關注並沒有明確的成長。而明顯逐漸被冷落的，包括 Perl、PHP 及 Javascript。喔！在 Ajax 當道的今日，Javascript 的熱度消退了？是因為大家覺得 Javascript 太基本了嗎？還是直接交給某些 Framework 處理掉就得了呢？

分析：Web (2.0) 的技術支撐

ria ajax css javascript rails

剛說到 Javascript 熱度消退，可能是因為大家對它越來越熟悉了。而其他相關的 Web 技術，由上圖可看出：CSS 逐漸受到一群人的重視--Web 2.0 的時代，大家越來越重視外表嗎？光只靠外表，就快比上能幹活的 Javascript 了。

Ajax 的推手極盡倡導之能，社群的反應不錯。RIA 也有許多人提，可是反應就比 Ajax 差了些--是因為 Ajax 聽起來像帥哥的名字，而 RIA 聽起是一種醫療技術的原因嗎？Rails 呢？嗯~ 有反應。

分析：各種訊息交換的社群型式

blog wiki forum bbs irc

接著來看看各種訊息交換的社群型式，這裡我試了 blog, wiki, forum, bbs 及 irc。由這裡可看到，blog 這一兩年來的熱度一直在穩定中求發展，而 wiki 則從 2006 年起有突然增溫的現象。另外從 web 1.0 時代就存在的討論群 forum，我想由於它也符合某些 web 2.0 的精神，其熱度並不曾稍減。至於鎖定特定族群的 bbs 與 irc，在 bbs 這邊可能是因為有太多的可取代性，而呈現下滑。而 irc 可能因為其專業性與即時性，熱度並未明顯衰退，難能可貴。

分析：大哥所推出的特殊應用

gmail flickr youtube facebook wikipedia

這裡把 Flickr 跟 Youtube 放在同一張圖表上，很明顯看出，同樣是占頻寬占硬碟的事業，Youtube 顯然受到比較多關愛的眼神。當然我們不能以此驟下斷言說買下這兩家公司的那兩家大哥大所做的決定是否聰明…

這裡我把 GMail、Wekipedia 及 Youtube 擺在一起，我想找出一種可能 (當然除了應用的本身是否容易吸引人之外)，是否真能透過「網路服務與使用者」及「使用者間」的連結關係 (1 對 1、1 對多、多對多)，印證出該服務在成長上的數學關係 (常數、乘數、指數)。不過，大家看看圖，了解我的意思就好，太嚴肅的分析已超越本文的範圍。

延伸閱讀：

Technorati : Google Trends, analysis, programming, trends, web 2.0

小試 GWT

noreply@blogspirit.com (Edward HSIEH) — Wed, 28 Feb 2007 22:45:00 +0800

早上為了試了一下 GWT，找到了一個在 Eclipse 上開發 GWT 的 plugin -- googlipse。googlipse 的安裝與使用可參考其 Docs 說明，它的確可以簡化專案的建立以及開發 remote services 之類的工作。要注意的是，以 googlipse 開發 GWT 專案時，不論是專案名稱專案所在路徑，都要避免有空白字元，否則以 host mode 執行時會有異常。另外，如果在 GWT 的 UI class 檔直接輸入中文字串，執行時會變成亂碼。得要用它提供的、正式的 I18N 支援，才能避免這種狀況。

另一個問題是，我發現使用 tabpanel 時，GWT 預設的 style 並不會把 tab 的形狀畫來。查看了一下文件，得知它採用正常 css stylesheet，而且 stylesheet 檔案，必須在 ProjectName.gwt.xml 設定檔裡面指定才行。我發現 UI 用 Java coding，而 style 卻用 css，在使用上，需要有一點磨練，才能適應其間的心智轉換。

整個測試後，感覺是開發上並不困難，但是可用的元件卻不多, 像我最想用的 splitpane 就找不到。當然也就別提有類似 treetable, richeditor 這類比較進階的元件。另外，雖然 GWT 網站上已經有一些文件描述 GWT 的用法，但整體上來講它的文件並不算豐富。很多設定或用法，還是需要詳讀內附的幾個範例程式，並自行測試才能解決。

至於 GWT 是不是已經 production ready 了呢？可以說要寫出 rss reader, bookmark manager 這類應用是沒問題的。對我而言，若要能發揮 GWT 的開發效能，應該要一個禮拜的磨合期吧--若我真有機會使用 GWT 開發系統的話!

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

noreply@blogspirit.com (Edward HSIEH) — Thu, 25 Jan 2007 11:25:00 +0800

昨晚與好久不見的朋友餐敘，提及當年某公司有一個 "優秀" 的 RD 部門主管及另一個 "重要" 的程式設計師。那位 "優秀" 的 RD 部門主管總會用正規的方式設計，有良好的軟體架構，並且開發過程中及完成後，都會提供其設計文件、使用手冊或範例程式。

另外有一個公司所 "倚重" 的程式設計師--並不是說他不優秀，只是他對公司的重要性，大於他的優秀性。

公司裡面複雜的系統，只有他能維護。而前人所留下的程式，並沒有相關的文件說明該系統的整體架構設計跟思維。

這就產生了一個有趣的現象：對於一個程式設計師而言，把事情做到最好 (除了寫程式外，還寫了讓人看得懂的文件等等)，對他本身而言並不一定是好事。當別人越了解你的系統，你的可替代性就越高，那麼你的價值不就越低？

反之，若有人能寫出他自己才看得懂的程式碼，就算上級要求寫文件，也是寫一些高深莫測、形而上學的東西(諸如，用90%的篇幅介紹物件導向的基本觀念，然後說明只要了解物件導向或設計模式的觀念，再自行 trace 程式，就能理解系統運作)。

這樣一來，後人無法維護該套系統，完全是後人資質不佳或能力不足。這樣，他就成為令人倚重的程式設計師了。

以上所言，並不代表本人立場!

PS: 即使是某公司那一位令人倚重的程式設計師，也沒有達成我上述的要求，因為他沒有寫出需要睿智才看得懂的文件。何況，那些不可維護的程式碼，他也曾經力圖改良，想讓人看懂過！

軟體開發進行式

noreply@blogspirit.com (Edward HSIEH) — Tue, 03 Oct 2006 10:20:50 +0800

三到五月間陸續寫的一點小記事。當初原本的標題是「軟體開發未來進行式」，到現在，有些已成為事實，所以就把標題改了。

各種應用軟體，會更傾向於以 widgets、plugins或 extensions 的方式，整合於功一較大的應用環境之中 --> 在大多時候，你不再需要開發出像 MS Office 這樣 stand-alone 的大程式
Client 端的應用程式容器：Firefox, Eclipse, NetBeans, 以及依附於作業系統 desktop 各種 widget containers 如 Yahoo, Google desktop.
往後 Clinet 端應用程式，既使不見得與 Web 的應用有絕對關係，但仍會採用與 Web 相關的技術開發，如 Javascript, XUL, Java WebStarts, Flex(2) 等
Server 端的應用程式，會採用可擴充與整合的模組式設計 --> 這裡的整合，是指像 drupal 這樣應用層級的整合，而不只是像過去的 Application Server，只是把不同功能的應用，deploy 到同一台伺服器上而已
Server 端系統基礎架構
- Database, Application Cluster, Web Tier, HTML/Ajax/SVG Thin Client
- Grid Enviroment, Web Tier, HTML/Ajax/SVG Thin Client
分散共有的未來式架構
- SOA + Web Tier (Mash-up), HTML/Ajax/SVG Thin Client
- 大融合：SOA Web Grid
Application Builder 與 Production Enviroment 的整合更良好。採用線上即時組裝與試行的方式來開發系統，針對需求直接測試解決方案。在大部分情況下，(採用UML)從頭進行系統分析與設計的開發方式，將不再需要。

Doing Ajax the SCA Way

noreply@blogspirit.com (Edward HSIEH) — Wed, 23 Aug 2006 14:30:00 +0800

興趣盎然的閱讀著 tempo 所作的投影片「AJAX 的 client/server 溝通機制探究」，裡面提到了「如果你流落荒島, 但是只能帶一個 AJAX Framework, 建議你帶 DWR」。這句話引起我對 DWR 極大的興趣。

其實我們公司內部已經採用 Echo2 開發產品 (而且用的很高興)。Echo2 最大的優點是可讓我們完全擺脫 HTML、Javascript 編輯時擾人的細節，完完全全以乾淨的 Java 程式碼開發出極為動態的 Ajax 應用程式，但相對的它的缺點是會耗費大量的 Session 資源。因此如果想要開發 Community Style 的網站時，就不適合採用 Echo2 了。所以一直以來，我對較為傾向於 stateless, 單純 RPC 導向的 ajax framework 還是保持一定的注意。

看著 DWR 的範例程式碼，讓我有種似曾相識的感覺。我突然回想起，先前在 JavaTwo 中我所介紹的 Tuscany SCA 也有提供 Ajax Remoting 的功能。再回頭去翻翻 Tuscany SCA 所提供的 ajax client 端範例程式碼，嗯！它的風格一樣也是簡潔明瞭。

以 Tuscany 設計 Ajax 的 Server 端服務

直接以 Tuscany 的範例做說明，假設我們在 Server 端有個類別如下：

public interface HelloWorldService {
    public String getGreetings(String name);
}

@Service(HelloWorldService.class)
public class HelloWorldServiceComponentImpl implements HelloWorldService {
    public String getGreetings(String name) {
        return "jsonrpcHello " + name;
    }
}

為了要讓這個類別變成 Client 端 JSON-RPC 可以呼叫的服務，我們在 sca.module 中定義其 entryPoint 及 component wire：

<module ... name="sampleHelloworldJSONRPC">

    <entryPoint name="HelloWorldService">
        <interface.java interface="...HelloWorldService"/>
        <jsonrpc:binding.jsonrpc/>
        <reference>HelloWorldServiceComponent/HelloWorldService</reference>
    </entryPoint>

    <component name="HelloWorldServiceComponent">
        <implementation.java class="....HelloWorldServiceComponentImpl"/>
    </component>

</module>

在 Client 端使用 Ajax 服務

最後，我們在 client 端就可以使用 Tuscany 所提供的 "SCA 物件"，簡單的使用 server 上的服務操作：

:
<script type="text/javascript" xsrc="SCA/scripts/sca.js" mce_src="SCA/scripts/sca.js"></script>
:
<script language="JavaScript">
   function getGreeting() {
    var name = document.getElementById("name").value;
    var result = SCA.HelloWorldService.getGreetings(name);
    document.getElementById('greeting').innerHTML=result;
   }
</script>
:
<div id='greeting'></div>
:

嗯嗯... 這裡似乎隱約就可嗅到 SCA 所強調的 unified programming model。即使使用 javascript 來呼叫 service，它的用法幾乎與標準的 Java client 沒有多大差異。

在 Ajax client 呼叫 Web Services

另外，SCA 還有一項特長，就是可以「把別人家的 Web Services 包裝起來變成自家的元件」。這在 Ajax 手法下特別有用，因為受限於 security issues，Ajax 無法由 client 端向不同的網站發出 ajax request。透過 SCA「把別人家的 Web Services 包裝起來變成自家的元件」的特長，我們可以在 sca.module 中集成不同網站的 web services，然後用 entryPoint 匯出成可在 client 端以 JSON-RPC 呼叫的服務。有興趣的朋友，可以參考 Tuscany 所附的 scahelloworldjsclient 範例。

一點提醒

到這裡，有朋友心動，想用 SCA 來寫 Ajax 了嗎？哎~~ 還是提醒心動的朋友，出了事情要想辦法自己解決，因為網路上很少人談到這樣的作法。而且肯定的，至少在目前為止，在網頁元素的 binding 上，SCA 所提供的支援應該較為單調。至少我還不知道，是否有內建的 function call，只要一個指令，就可以把 service 傳回 string array binding 到 html 的 select 元素上。當然自己寫也不會太難就是了！

一個問題

最後，有一個問題我納悶很久了，很想問問 tempo：既然流落荒島，那為什麼還要帶一本 Ajax 的書呢？那時候我可能會帶「與食人族共舞」或「24 小時學會獨木舟造船術」。嗯…「螃蟹的 24 種吃法」也不錯，如果有的話。