Software Cinema

lazybuntu [1] 是國內著名 bbs/web browser 軟體 PCMan 的作者(也叫 PCMan :p)發起的計畫, 就如同其他 lazyxxx 計畫一樣, 是希望透過把常用的, 好用的 softwares 綑綁在一起(software bundle), 並設定好在特定 platform 上的安裝設定以及 package deployment, 使得在該 platform 上的使用者可以快速地安裝好必要的 softwares. 當然會這樣作的原因也包含了在原來的 distributions 中並未能夠考慮特定區域的使用習慣來決定內建的 packages 支援, 或是因為 packages 太多反而讓一般使用者不知道怎樣選取.

相似的東西, 最近國內比較 hot 的應該是 lazyeeepc [2] 吧, 而我之前為了求方便分別在 Linux 以及 Windows 上也使用過的 XAMPP [3] 也算是類似的東西. 但是我認為從 information & knowledge engineering 的角度來看, 這些 software bundles 之間還是有所不同.

如果只是從 把常用受歡迎的 softwares 一起包裝起來 的角度來看 software bundle, 那麼 software bundle 其實可以被看為是一個 packaged information aggregation. 在此 aggregation 內, softwares 是以特定的關係被 connect 在一起, 但是這樣的關係只會是 在同樣 platform 上的關係, 或是跟某個 programming language 相關等等的關係, 並沒有包含這些 information 怎樣以有方向性的關係作連結的資訊.

以 XAMPP 的例子來說, 有意識地選用了特定的 software 組合, 意味著完成 XAMPP 的 developer 認為這樣的組合在他的使用經驗中具有某種優勢, 這樣的組合是對於他來說是有意義的. 而有意義意味著對於 Information 的認知能夠提供他使用上的某種經驗, 於是 Information with Meaning 就變成了 Knowledge.

更甚而可以形成某種解決問題的 pattern, 擁有合適的 context description, 以及使用此 software bundle 時需要考慮的 forces, 使用後的 consequences 等等, 這就已經不再只是 information aggregation 的 level, 而是把 software bundle 作為一種 knowledge sharing 的手段了.

以 lazybuntu 來說, 其實蠻有淺力往這邊走的, Ubuntu 的使用者多, 在 Ubuntu 上的 applications 也多是兩個主要的原因. 但是要以怎樣的 format 讓 contributers 可以在 lazybuntu 上分享自己的 "knowledge" 倒是一個難題. 特別是所謂的 knowledge 是可以包含各種使用方式的, 像是 Apache 雖然是 web server, 但是我也曾經把他跟 Trac 綁在一起用, 原因只是為了利用 Apache 的密碼加密模組.

當我們可以把 software bundle 完完全全視為一個被 share 的 knowledge 時, 或許到時看到的就不再是 software 的 composition (或說是 component composition), 而是現在正開始熱的 service-orientation 的角度了. 到時我們看的不是一個一個的 softwares, 而是看到 softwares 經過適當的組合, 經過使用的測試, 匯集使用的經驗, 所提供出的 services.


References

[1] lazybuntu, URL : http://lazybuntu.openfoundry.org/
[2] lazyeeepc, URL : http://yurinfore.blogspot.com/2007/10/lazyeeepc-001.html
[3] XAMPP, URL : http://www.apachefriends.org/zh_tw/xampp.html
[4] Michael Negnevitsky, Artificial Intelligence : A Guide to Intelligent Systems, Addison-Wesley, 2001

最近EeePC 的在台灣上市導致了蠻有趣的現象, 雖然 ASUS 宣傳是以給年長者跟小孩為主, 但是台灣購買的顧客群卻以年輕人及上班族居多, 這是在看完了整個 Mobile01 [3] 相關討論, 以及 Ptt, 其他討論網站後得到的結論. 然而這只是一個現象, 究竟 ASUS 對於 EeePC 的定位是怎樣看待, 這只是一個過度期的產品, 或是未來幾年 ASUS 會持續支援推廣的產品呢 ? 特別是, 從我們作 software 的眼光來看, EeePC 又是怎樣的東西 ?

1. Hardware Perspective

下表是 ASUS 公開的 Eee PC specification, 分為四種, 但是差別只在硬碟容量跟 Webcam.

另外在 CPU 的 frequency 上, 為了 battery 使用時間可以延長, 以及機體散熱考量, ASUS 在機器出廠前把 frequency 限制在 630 Mhz (70 倍頻), 而且目前的 BIOS 版本無法調整回 900 Mhz (100 倍頻). 以 hardware 的角度來說, 我認為是 downgrade PC.



2.User Interface Perspective

從 software user interface 的角度來說, 我倒認為是 upgrade mobile device.(以下圖片取自 ASUS EeePC 官方網站說明)

EeePC 的 software user interface 設計跟既有的 hand-held PC 以及 mobile device 比較接近, 是以 Task-Orientation 以及 Workspace 的概念去設計. 其目的就在於讓使用者以較為直覺的方式直接使用 software 的 service 完成 task. 而 EeePC 本身的 hardware 條件使得同樣的設計在 usability 上會更好.

然而以最近的新聞表示 ASUS 也將與 Microsoft 合作提供搭配Microsoft Windows 的 EeePC 版本, 這就應該只是單純的商業運作考量. 但換個角度來說, 也顯示出 EeePC 與 UMPC, OLPC [4][5] 之間在 flexibility 之間的差異. 然而, 無論如何這些東西都還稱不上是創造了一個新的 usage paradigm [6] 就是了.


3.Utilization Perspective

ASUS 自身對於 EeePC 的宣傳標語是, Easy to Learn (易學)、Easy to Play (易玩)、Easy to Work (易攜帶), 換句話說他們希望 Customer 看到這些標語時, 是去跟手上已經有的 Desktop PC 或是 Notebook 作比較, 而 Customer 手上的這些 PCs 則是 Hard to Learn、Hard to Play、Hard to Work. 從這個角度來說, 是以 Customer 的 Utilization 作為根據推出產品.

而再以 User Interface Design 來說, EeePC 雖然採用 Debian 系列的 Linux (嚴格來說是 Xandros Linux), 但是並非直接採用 Desktop Linux 版本, 而是刻意作了不少修改, 使得在 User Interface 呈現上是以 Task-Orientation 的方式, 切割成為數個 Workspace, 明確地讓使用者意識到隨著使用的目的而切換 Workspace.顯然有別於 Desktop Linux 或是 Microsoft Windows Desktop 版本的做法. 從這個角度看也是著眼大部分 EeePC 的目標 Customer, 其所會利用 EeePC 所進行的工作, 並不需要 Desktop 環境才能進行, 透過規劃好的 Workspace, 反而更能有效率. (不過看起很多人拿到 EeePC 的第一件事就是把他灌回 Windows XP, 究竟是真的 ASUS 原先設計的 interface 不好使用, 或是中 Windows 毒太深, 或是害怕接受新事物呢 ? )


4. Software Perspective

接續上面的說法, 我認為 EeePC 是在 補上失落的環節 , 在 Desktop PC 獲得巨大成功, 並且快速朝著更高效能的道路上發展時, Palm Pilot 的成功帶起了 hand-held PC 的相關開發, 乃至於後來的 PDA, Smart Phone, 近期的 iPhone 等等, 在 Desktop PC 到這些 Mobile Device 之間, 我們經歷了極為快速的一次跳躍. 而這兩邊卻又朝著各自的方向在發展.

當許多檢討的聲音出現, 討論這些 mobile device 的能力限制, 以及 desktop PC 的 power 缺乏有效的利用之同時, UMPC 以及 OLPC 嘗試回頭去補這兩者之間的落差. UMPC 在我看來是以強化 hand-held PC 的方式去補, 而 OLPC 則是以限定應用領域 (Education) 的方式去補. 而 ASUS 的 EeePC, 則是選擇了以弱化 Desktop PC 以及 Notebook 的方式去補. 這三者會有不同的考量以及限制.

如下圖所示, 拜 Web Application 風潮所致, 許多傳統上需要在 Desktop PC 上執行的 softwares [1][2], 例如 Office Suite, GIS software, Multimedia/Image/Graphic Processing software 等等, 都開始可以以較少的運算能力需求或是資源需求來滿足, 只要能夠有 Web browser, 或是能夠裝上 client 端軟體就行. 然而這些軟體還是有其他需要被滿足的需求, 例如 Office Suite 還是需要 keyboard 才方便作輸入 (手寫的便利性以及速度還不算成熟), 而 GIS 在過小的螢幕上使用及觀看也極為不便. 而因應這樣的需求, Notebook 固然可以滿足, 但是 Notebook 仍然是太過於 powerful 了, 同時在體積跟重量上也比較不便. 而 EeePC 從 software 觀點來看, 卻正好補足了這一塊.

EeePC 的選擇使得她有機會針對不同的使用者族群, 利用不同的 software combination 去滿足, 我想這可能是 UMPC 以及 OLPC 所作不到的.

References

[1] Stan Schroeder, "Big WebOS roundup - 10 online operating systems reviewed," Dec. 2006, URL : http://franticindustries.com/2006/12/21/big-webos-roundup-10-online-operating-systems-reviewed/
[2] 異塵行者, "覽器萬能，應用程式在線服務（Web Application）的年度彙整," Feb. 2007, URL : http://playpcesor.blogspot.com/2007/02/web-application.html
[3] Mobile01, URL : http://www.mobile01.com/
[4] One Laptop Per Children (OLPC), URL : http://laptop.org/
[5] Telka S. Perry, "The Laptop Crusade,"IEEE Spectrum, vol44, no.4, pp.28-33, April 2007
[6] T. Selker, "New Paradigms for Using Computers," Communications of the ACM, vol.39, no.8, pp.60-69, August 1996

我大約在一年前第一次到 Ohloh.net 一逛, 那時整個網站公開還不久, 大約幾個月而已. 一切都還很陽春, 只有大約 3000 多個 projects (其中有些是空號, 因為我那時閒閒沒事寫個 crawler 把人家資料整個抓下來分析 XD), 其中有很多還是空號. 那時的 project assessment 頁面長的像這樣 (幸好有舊資料留著), 以下是舊畫面歐 :


而資料方面只有針對 project 的 contributors 以及 code base 作分析. code base 只有 language 比例分析, license 分析, 以及 code base 大小增長曲線分析. 其中比較有趣的是右方的 project cost estimation, 用來推測此 OSS project 在業界的 cost 會是多少. 當初已經有 community 功能, 但是參與的人還很少. 現在已不可同日而語了, 除了 project 本身的 statistics 統計有更好的分類以及更詳細的內容, 結合 project 相關 news 也使得我們一次可以接收到該 project 進行的最重要發展訊息, 以及 community 內的相關 comments.

一樣是 MediaWiki, 現在比較漂亮, 資訊也比較多了.



當初會找到 Ohlon.net 的原因之一是因為, 當時我正在參與實驗室的一個 OSS software measurement 相關計畫, 也作了一個簡單的 tool 分析 SourceForge.net 上的 OSS software 其 source code 相關資訊, 包含 programming language 組成, package 組成, quality evaluation 等等. 當時就想到, 雖然 software measurement 的 tools 已經有很多, 但是似乎沒有看到過有作成網站提供服務給 software project 的. 加上當時已經是 open source portal 龍頭的 S.F.net 也沒有類似的功能 ( 直到現在 S.F.net 還是只有基本的 project statistics 統計功能 ), 就想說把做好的 tool 延伸作成 web application, 然後作成一個提供此種服務的網站應該會是很有趣的事情, 比起 OpenFoundry 要學 S.F.net 又學的不好來的有市場機會多了.

沒想到 domain analysis 作著作著就發現 Ohloh.net 早已經開始作一樣的事情了.

Ohloh.net 創始者只有兩個人, Jason Allen 以及 Scott Collison, 有趣的是兩個人都是從 Microsfot 出身的. 在離開 Microsoft 之後, 有感於當時的 Open Source community 缺少統一的 software evaluation 服務, 無法讓其他開發者或是使用者對於有興趣的 OSS project 在 management 以及 quality 上有更深入的了解, 因此創立了 Ohloh.net, 希望不只幫助有興趣的人了解, 也讓 OSS project manager 可以從 engineering 觀點提升自己的 project efficiency 以及 product quality.

一年來 Ohloh.net 穩健地成長, 不僅網站提供的 evaluation angles 越來越多, community 也有逐漸茁壯的感覺. 但我覺得在 Ohloh.net 提供的 services 到 project manager 如何利用這些 services 以改善 projects 還有一些 gap 存在. 或許 Ohloh.net 應該針對他們的服務是否有達到預期的效果作 validity 檢測, 或是以問卷詢問 services 使用者的 satisfaction, 作為未來要增加的新服務之基礎.

Anyway, 這是一個值得時常造訪, 長期觀察的網站 :)

今天才看到 OxygenOffice Professional 這套 OpenOffice.org 的加強版軟體, 真是後知後覺. 雖然中文網頁有討論的不多, 但是好像早在去年 10 月左右, OpenOffice 補給站就有人發出訊息討論過了.

OxygenOffice Professional 說穿了是加強 OpenOffice.org 在編輯上的便利性, 嘗試藉由更容易管理與引用圖片等資源, 加入類 VBA 的 support, 以及提供更多分類後的 templates 來達成 (好像還有額外的 Fonts ?).

在 SourceForge.net 上的 statistics (~2007/10) 倒是有點奇怪, 雖然在 2007-04 後大幅增加了網頁流量, 但是 downloads 數次卻逐漸低迷, 顯示並未造成使用的大流行, 只有一開始固定的用戶有持續更新, 新用戶可能極少. 或許跟宣傳有關 ? (以下圖片擷取自 SourceForge.net )


我也抓下來試用了一下. 可以看到在編輯 odt 文件時, 能夠把圖片引用選擇開啟在工具列, 然後直接用拖曳的方式拉進去. 不過我覺得圖片選擇工具組能夠開在左右比較好, 因為現在有寬螢幕 LCD 卻沒有長螢幕 LCD (除非把寬螢幕旋轉過來, 但是並非每台 LCD 都可以), 放在左右比較不佔文件編輯空間.


另外開啟檔案時有許多種類的 templates 可以選.


隨便選了一個 maintenance report 相關的 template.

試用歸試用, 我真正覺得有趣的地方在於 OxygenOffice Professional 是否能夠成功, 以及他的成功帶來的意涵.

長久以來 Windows 的使用者習慣於 Microsoft Office 類型的編輯軟體, 即便是後來在 Linux 上的 AbiWord, KOffice, StarOffice 等等其實都是一樣, 此類編輯軟體的 power 掌握在開發團隊手上, 即便有些採用較為開放的 license, 但是缺乏良好的 design 以及 interface, 有心者一樣很難加入開發.

而隨著時間推進, OpenOffice.org 出現了, 仍舊, 跟過去一樣, 是 power 掌握在開發團隊手上的編輯軟體. 但這次有點不同. 不同之處在於同時期出現了一個極為成功 (可能是有史最成功的) 的開發軟體 : Eclipse.

熟悉 Eclipse, 而且使用過如早期 Visual Studio, IBM Builder 系列等等有的沒的 IDEs 的使用者, 應該都能一下子指出 Eclipse 跟這些 IDEs 的最大不同處. 這樣的不同處建立在良好規劃的 software architecture, interface, 以及 open source community 的逐漸壯大上 (當然, 還有 Java 的熱潮).

OxygenOffice Professional 給我的感覺就像在 OpenOffice.org 上加了許多 plug-ins, 看那引用圖片管理的工具組, 不覺得跟許多 Eclipse plug-ins 的出現方式很像嗎 ?

或許 OpenOffice.org 想持續壯大, 搶奪 Microsoft Office 的市佔率, 應該考慮以 Eclipse 為學習對象, 變成一個文書編輯軟體的 framework/platform. OOo 本身有絕佳的條件變成文書編輯領域的 Eclipse, 唯一的問題在於目前的 architecture 以及 interface 是否設計的夠好, 如果需要修正, 要花多少 efforts ?

我期望著有一天我會像在 Eclipse 上嘗試各種 plug-ins 的 combination 以提升我的 development performance 般, 在 OpenOffice.org 上嘗試數不完的 plug-ins :)

不知道為什麼, 關於 UPnP 比較有內容的文章好少, 而且可能因為剛寫完 Jini 的 review, 加上 UPnP 比較沒有我的愛 :p , 所以不知不覺變成用跟 Jini 比較的角度來寫了.

因為我打算一直累積這份 review, 因此 references 會連續, 部分 references 請參考 Jini 那篇.

What is UPnP

UPnP 由 Microsoft 所主要領導的 Universal Plug and Play Forum [11] 進行開發.

UPnP 本身其實是由許多 protocols 所組成, 意圖讓這些 protocols 成為溝通標準 (standard). 採用 UPnP 的 devices 等同於是同意使用一組標準的protocols 進行溝通. 從此點馬上可以看出 Jini 跟 UPnP 在標準化 (standardization)上的差異. Jini 試圖讓 Services 之間溝通的行為標準化, 也就是需要標準的 interface, 但是 data 格式是自由的. 而 UPnP 則是建立在近乎標準的許多 protocols 之上, 在 Services (或該說是 devices) 之間讓 data (或說是 message) 的格式標準化 (IP, DCP, UDP, HTTP, HTML, XML), 因此 Services 溝通時, 需要假設對方知道溝通用的 protocol. 也因此 UPnP 需要採用 XML 作為 service description (SOAP) 以及 service control (Device Control Protocols) 的主要工具, 因為他不像 Jini 具有 mobile code 的能力.


Comparing the Success of Jini and UPnP

就 Jini 與 UPnP 的市場比較來說, 我認為其實很難看出來勝敗. 雖然說現在到處可以看到支援 UPnP 的 devices, 但是 Jim Waldo 說的也是有道理 [7], 他認為 Jini 事實上在業界有許多十分成功的應用, 只是基於商業考量, 這些成功的公司不會把此點曝露出來, 避免對手也採用同樣的技術. 因此雖然說有文章對於 Jini 與 UPnP 在各項具備的能力上作直接的比較 [12], 但是我認為其實這樣比較的意義性不大. 因為兩者所瞄準的是不一樣的目標. 然而如果都放置到 Service-Oriented Computing 的 context 下作比較, 我認為 Jini 要比 UPnP 來的有優勢, 給予 programmer 的 flexibility 較大, 且就所處的 layer 以及彼此的著眼點來看, Jini 是可以把 UPnP 合併進來的 (除去 License 的問題, Sun 可用 Java 來 implement UPnP [13] ), 相對來說 UPnP 就很難反過來把 Jini 合併, 即便是 [4] 的 inter-operation 做法也等同於是把 UPnP 變成 Jini 的底層 Service 溝通的支援方式之一而已.

References

[11] Universal Plug and Play Forum, URL : http://www.upnp.org/
[12] Jini and Universal Plug and Play (UPnP) Notes, URL : http://www.psinaptic.com/link_files/jini_and_plugandplay.pdf
[13] Larry Press, "The Post-PC Era," Communications of the ACM, vol.42, no.10, pp.21-24, October 1999

我對於 Jini 的 capabilities 以及 architecture 之認識主要依靠閱讀 Jini Architecture Specification [1] 以及Jim Waldo (Sun 資深工程師, Jini 的主要發明者之一) 在 1999 年發表於 Communications of the ACM 上的一篇文章 [2].

The Goal of Jini

引用 Jim Waldo 在 [2] 文章一開始的一段話 :

The Jini™ architecture exemplifies a new approach to computing systems—making the network the central connecting tissue. By replacing the notion of peripherals and applications with that of network-available services and clients that use those services, the Jini system breaks down the conventional view of what a computer is, while including new classes of devices in a unified architecture.

可以看出Jini 的理想是跳脫目前的電腦架構, 而在目前的基礎之上, 建構一個以 Service 為單位, 基於 Network, 只存在 Services 與 Clients (Users) 的世界.

The Reality of Jini

然而 Jini 以開放的 Specification 來看並未真正完全具備實現理想世界的完整能力. Jini 的主要能力仍是以 Service Lookup 為主, 也提供 Service Registration 以及 Leasing 的特性. 其中 Leasing 機制可以視為一種極為簡單的 Service Negotiation. 另外一個令 Jini 與目前既有的 Service Middleware 極為不同的特點是, Jini 有 Mobile Code (Code Mobility) 的概念. 此概念為跳脫傳統在 Service 與 Client 是只有單純的 Data 傳送的方式, 而把 Code 也視為 Data 進行傳送. 這樣一來 Services 之間的 coupling 將更低, 同時更能更應付一個快速變化的網路環境 (Changing Network). 此特殊的能力事實上是建構在 Java 本身統一利用 JVM 執行程式, 以及 Java 的 Security 特性上. Jini 的真正意函在於 Jini Specification, 而利用 Java 作為實現只是一種選擇, 然而其他語言是否能夠實現 Jini Specification 就不一定了.

在所查到的相關資料中, 大多將 Jini 的 limitations 歸因於下列幾點

1. Network-Centric [3]
1. need a central server [3][5]
2. TCP/IP based [5]
2. Architecture Base
1. based on conventional distributed system [3]
3. Java-based [4]
1. JVM limitation [3][5]
2. Java RMI limitation [3][5]
   

如果單以 Jini architecture specification 的角度來討論, 唯一可能留下的應該只有 need a central server 以及 based on conventional distributed system 兩點. 其中需要 central server 此點會使得 Jini 在某些環境下比較難以實現, 例如 pure Ad Hoc 環境, 或是缺乏 central server 的 P2P 環境. 而 based on conventional distributed system 這點在 [3] 中則是認為會導致 Jini 需要 statically configured infrastructure 來完成 service discovery, 這跟 need a central server 是一樣的意思, 另外就是 Jini 將會需要一個足夠穩定的網路環境 (well-behaved computing environment) 以便進行 RMI 的運作, 滿足 transparency 以及 synchronization 的需求.

而餘下的 limitations 我認為其實跟 implementation 的選擇相關比較大. 比如說 TCP/IP 的依賴性問題, 在 Jini 原先的 implementation 中僅支援 TCP/IP, 但是根據 specification 可以進行適當的擴充, 以支援其他不同的 protocols, 在 [5] 有參與討論者說明自身的相關計畫經驗. 同樣的, 與 Java 相關的 limitations 可以藉由選擇不同的語言實現 Jini architecture specification 解決.

再者, 如果回到 Jini 原先的理想下, 那麼其實 Jini 還有著更多的 limitation, 包含在目前 service oriented 環境中要求的各種 service management 能力, 諸如 service broking, service negotiation, service mediation, service billing, service composition, service security... [6] 等等, Jini 都有許多尚未能滿足的部分.

The Rise and Fall of Jini

下圖說明了我認為 Jini 的 rise and fall. 但因為其中的許多部份沒有查到確切的年份資料, 因此我僅是簡單地照我的猜測及推想擺放相關方塊的位置.


首先是 Jini 的開始開發以及第一個版本的 release. 根據相關的文章可以看出 Jini 在當時引發的熱潮. 而這時有個意外的插曲, Sun 的 marketing 把 Jini 說小了, 沒有完整地呈現出 Jini 的理想, 或許這是為了單純的 marketing 考量, 此點在後來採訪 Jim Waldo 的文章中也有提及[7]. 我認為這點在某個程度上使得 Service-Oriented Computing 沒有更早獲得重視與劇烈發展.

而在 Jini 於市場上取得短暫的成功後, 怎樣維持接續的發展以及強化 Jini 的能力是最重要的事, 單純只有 service lookup 顯然是不夠的. 在這裡我想同時受到幾項因素影響 Jini 的發展. 首先是同一時間 Java 本身也在 J2SE 以及 J2EE 領域取得巨大的成功, 相關的應用及計畫大幅展開, 此段時間內想必 Sun 本身也是忙的不可開交. 對照同時間的 J2ME 發展, 幾乎呈現停擺狀態. 另外如上述說的 Service-Oriented Computing 的想法還不成熟, 許多 Jini 可以沿深加強的方向都還沒有較為成功的研究成果出現. 另外有一個我認為很重要的因素, 在於 Sun 在 Jini 最初 release 不久後開始緊縮 license, 以 Sun Community Source License (SCSL) 授權, 直到 2005 年才開始分別釋放部分程式碼改為 Open Technology License 以及 Apache License [9]. 我認為這無形中對於 Jini 在 Open Source Community 以及 Commercial Company 的發展進行了侷限, 許多基於 Jini 的可能性無從發展 [8], 進而影響後續對於 Jini 是否能夠制定一個 standard 以及 Jini 應用的 promotion.

而對於 Sun 以及Jini 來說, 最大的玩笑或許是 Web Services 的崛起. Web Services 使用 XML-based Remote Procedure Call (XML-based RPC), 相對於 Jini 的理想來說其實有點開倒車.然而在之後的兩年之間, Web Services 的熱潮完全掩蓋了 Jini 的光芒. [10] 的作者認為原因可能是 Web Service 相對的 simplicity. 我覺得應該反過來說, 是 Jini 還沒有達到應該有的 simplicity.

縱使如此, 不管怎麼說, Web Service 的熱潮也逐漸退了, 取而代之 Service-Oriented Computing以及 Middleware-based Software Engineering 看起來正要開始快速發展, 因此我想我同意 Jim Waldo 說的, 許多真正有用而強大的概念是需要時間成熟及驗證 [7], 過早斷定 Jini 已經不行了是不必要的, Jini 仍有大好的機會捲土重來.

References
[1] Jini Architecture Specification, URL : http://www.jini.org/wiki/Jini_Architecture_Specification
[2] Jim Waldo, “The Jini Architecture for Network-Centric Computing,” Communications of the ACM, vol.42, no.7, pp.76-82, July 1999
[3] Robert Grimm, Janet Davis, Eric Lemar, Adam Macbeth, Steven Swanson, Thomas,erson, Brian Bershad, Gaetano Borriello, Steven Gribble, and David Wetherall, "System Support for Pervasive Applications," ACM Transactions on Computer Systems, vol.22, no.4, pp.421-486, November 2004
[4] J. Allard, V. Chinta, S. Gundala, and G. G. Richard III, "Jini Meets UPnP: An Architecture for Jini/UPnP Interoperability," Proceedings of Symposium on Applications and the Internet, pp.268–275, 2003
[5] Limitations of Jini Technology, discussion thread at Jini mailing list, URL : http://osdir.com/ml/java.sun.jini/2004-10/msg00199.html
[6] Dan Jong Kim, Manish Agrawal, Bharat Jayaraman, and H. Raghav Rao, "A Comparison of B2B E-Service Solutions," Communications of the ACM, vol.46, no.12, pp.317-324, December 2003
[7] Janice J. Heiss, "Jini Network Technology Fulfilling its Promise: A Conversation with Jim Waldo," March 2004, URL : http://java.sun.com/developer/technicalArticles/Interviews/waldo_qa.html
[8] Eric S. Raymond, "Open letter to Sun: Let Java Go," 2004, URL : http://www.catb.org/~esr/writings/let-java-go.html
[9] Licensing of Sun's Jini Technology, at Sun official website, URL : http://www.sun.com/software/jini/licensing/
[10] Berco Beute, "Universal Plug 'n Play: Jini's ex-rival back from the dead?" 2004, URL : http://www.artima.com/weblogs/viewpost.jsp?thread=48801

Embedded System

在過去對於 embedded system 的認定或是說明 (在此我避免用 定義, definition 這 個辭, 因為嚴格來說我認為沒有被 well-accept 的定義), 大多是利用一些特徵來描述 embedded system, 例如功能專一性 (not general purpose), 資源有限 (limited resource), 可用記憶體有限 (memory constraints) 等等各種 hardware constraints, 另外就是具有 hardware / software co-design 的特徵(不過這屬於逐漸被拋棄的一個領域), 可以進行操作的介面通常都很小等等. 總之就是把 embedded system 跟許多 hand-held device 或是家電 IA 畫上等號. 最常見的就市直接跟桌上型 PC 作比較, 像是 PC 這種運算快, 記憶體多, 體積大, 多功能用途的電腦系統就不是 embedded system, 反之大概就是. 這種概述大概是過去十幾年來對於 embedded system 的共通印象. 而對於資訊相關的學生來說, 因為講到 embedded system 開發好像就是一定要在一塊裸板上燒 ROM, 或是利用封裝好的小型主機, 外接螢幕什麼的, 好像不是這樣開發的就跟 embedded system 無關似的. 而所謂的 embedded application 當然就是在這樣的環境下可以執行的 applications 摟.

但我並不認為時至今日, 對於 embedded system 的認知應該維持過去的想法. 重點在於 embedded 這個字. 引用 webster's dictionary, rosetta edition 對於 embedded 這字的說明為 :

1. Enclosed firmly in a surrounding mass

2. Inserted as an integral part of a surrounding whole

embedded system 也只是一種 computer system, 而因為他所具有的特徵使得我們特意冠上 embedded 這個字. 但是如果是因為各種 hardware constraints 而冠上 embedded, 對照 embedded 這字本身的意思, 不是很怪嗎 ? 因此我認為, 對於 embedded system, 應該從別的角度來詮釋.

既然我們說 computer system 的目的, 其實終究還是希望可以幫助人類的生活過的更好更輕鬆, 是整體社會文明的一種進步. 因此在此我把上述對於 embedded 釋意文字中的 surrounding mass 以及 surrounding whole 對比到 human life. 換句話說, 所謂 embedded system 事實上是指能夠 embed 到 human life 的 computer system.

在此認知下, 一般熟悉的 PC 自然就不被涵括在裡面. 的確, PC 在很多人的生活中都會出現, 很多人每天也一定會使用到 PC, 但是 PC 有很顯然地融入一般人的生活中嗎 ? 恐怕是沒有吧, 大多數常接觸的人要不就是 PC Gamer, 否則還是以工作接觸居多, 這種情況就變成是刻意去接觸利用, 而不是嵌入或是融入我 們的生活之中. 當然, 我必須承認, 這樣的認知與區隔並不是很嚴謹, 或許仔細想還是可以找到介於是與不是之間的例子. 比如說手機就是一個. 對於現代人來說, 手機或是其他通訊設備幾乎就是融入生活的一部分, 然而當我們說到多功能的智慧型手機, 或是所謂的 Smart Phone, UMPC 等等, 其所提供的服務, 似乎又不是那麼地融入我們的生活了. 這種情況我就認為他既是也不是摟, 換句話說就要看你所持的觀點而定.

我的認知可以下面的概念圖表示. 圖中的 application software 以及 embedded application software 指的僅是 software 部分, 而整體的運作還需要加上更底層的 hardware. embedded application software 在添加 hardware 部分後構成一個 embedded system. 而此 embedded system 所達成的服務應用則是 embedded application. 兩者的差異即在於 Unawareness of Users 的考量範圍. 在 embedded application 的情況中, 需要設法達成讓 users 感覺不到 embedded application software 的存在.


而我上述的認知跟過去對於 embedded system 的認知之間的關係如何呢 ? 我認為過去從 hardware constraints 的角度去區別 embedded system 與否其實也沒有錯, 因為要符合上述我的說法, 將會使得 embedded system 所處的環境面對較多的限制, 例如機體大小等等, 自然而然就會形成各種 hardware constraints. 但是這點在硬體開發技術以及製程逐漸進步, CPU 處理速度越來越快, 同體積的記憶體效能 (Performance) 越來越好的情況下, 過去與桌上型 PC 相比的 hardware constraints 只會隨著時間逐漸的消失, 因此再也不適合用來區別 embedded system 與否.

最後一點, 則是關於上文中不斷提到的 融入 . 這也是之所以沒辦法有嚴謹定義的原因. 所謂融入跟人本身, 以及人所處的環境 (context) 會有關係. 人本身包含了生活習慣, 而環境則包含了文化 (culture) 因素. 這些都是會逐漸演進的 (evolve). 換句話說, 對於 embedded system 與否的認定, 會隨著整個社會環境的逐漸電子化而有所改變. 而如果對於 pervasive computing 或是 ubiquitous computing 略為知曉的人, 可能又會覺得好像沒什麼不同. 這樣說吧, 我認為 embedded system 就是 pervasive computing 或說 ubiquitous computing 的基礎構件之一, 而後兩者所描繪的是 global vision.

Embedded Middleware

而在 embedded middleware applications 的部分呢, 我認為 embedded middleware 跟一般的 middleware 不同處在於 middleware 所要代替 applications 面對的對象, 擴展到了使用者. 已下面的概念圖表示我的想法.

在我的想法中, embedded middleware 除了與一般的 middleware 一樣會需要替 embedded application software 處理面對不同的 operating systems, network, 以及 resource management 等相關問題之外, 還存在於 user 與 embedded application software 之間, 而所負擔的責任即在於降低 developer 設計與實現 embedded application software 時, 需要考量到不同的 users 在不同 context 下的使用問題. 因而有別於一般的 middleware software, user interface (UI) 在 embedded middleware 領域中佔有較重要的份量及地位.

這個想法是從 Code Snippet 來的, Code Snippet 簡單來說就是一個片段的可重複利用 (re-use) 程式碼, 通常會是利用 copy-n-paste, 加上適度修改的方式利用. ( 在這裡我刻意用可重複利用: re-use 而非可重用: reuse , 因為這兩者有本質上的差異, Code Snippet 應該算前者而非後者 )

Paper 開始寫多了, 被老師改的次數或是送外國人改的次數多了, 就會感覺被改過的句子其實是自己本來想寫出來的感覺, 但是限於腦子裡的英文程度, 總是沒辦法較為準確有效率的自己的意思, 總是只能用比較簡單的辭彙跟片語堆積出好幾句, 還沒有別人用一句說的清楚. 這種情況對於撰寫 Introduction, Related Work, 以及說明清楚自己要解決的問題時非常不利.

之前在 ptt 看到 CCY 學長說他會把看到的 paper 內寫的好的句子 copy 留下來, 之後有需要就可以套用, 再稍作修改. 其實這就跟以前背英文句子或句型一樣, 只是那要用人腦去記憶, 沒有背到很熟不容易使用...就算背很熟可能也反而會妨礙使用.

現在覺得自己好像也有必要這樣做了, 姑且把這種剪下來的 Sentences 叫做 Sentence Snippets 吧, 畢竟他也不算是大家或專家公認的佳句, 只是同領域的 papers 裡看到覺得寫的不錯, 可能以後會派上用場的句子.

雖 然不知道 CCY 學長如何管理他的 Setence Snippets, 但是直接 copy 下來保存一定不會是個有效率的使用方法, 適當的分類管理方法還是必要的. 可能用 faceted classification 或是 tag system 去作分類還可以吧, 只是要花點人工就是了, 同時使用的 tag 可能需要是中英文並用的, 比較能配合寫 paper 時的思考模式, 然後直接用 blog 紀錄, 應該也會蠻方便的. 恩...再想想好了.

That's what I think about Wii Fit : A Possibly Successful Application of Wearable Devices.

Wearable devices, 或是更廣義的說, wearable computers, 的概念已經存在很久, 不過對這種起源的歷史討論我向來沒什興趣, 參考 Wikipedia [1] 就罷.

Anyway, wearable devices 過去在學界, 主要是分散在 pervasive/ubiquitous computing, smart home, medical devices, military 等應用中, 事實上也取得了相當的進展. 因為我的 thesis 跟 context-awareness 以及 smart home 有關, 當時(一年多以前)也 survey 了很多發表的成果, 在各種可以對人們作 profiling 的 devices 上其實都已經可以有 product 出來. 但是實際市場上就是沒有大公司率先推出. 那時我就在猜原因, 想來想去除了市場推廣因素也想不出其他的原因來.

沒想到在 "正當" 的用途之外, wearable devices 居然在 game 領域可望率先取得成功了 :p

當然我說的成功指的是能夠在市場快速地達成一定的佔有率, 而非只是能夠開發出產品而已. 在 Wii Fit 準備推出後, 這樣看來其實就很清楚了, Wii 其實只是探路的棋子, 任天堂 (Nintendo) 可能打算藉由 game 領域為出發點, 快速擴大市場佔有率, 然後由 game 反攻上述各種應用, 包含 smart home, medical 領域. 像是 Wii Fit 廣告中已經有的各種應用軟體, 事實上就是觀照你身體健康的目的. 當然目前許多批評者認為, 實際運動效果其實不大, 但承認吧, 多少該有的效果還是有的. 況且 Wii Fit 也沒叫你一整天玩他就好, 出外運動跟玩 Wii Fit 並非互斥的選項. (以下影片引用自 YouTube)




等 Wii Fit 的其他配件再推出來, 例如感應手腳動作, 甚至頭部動作的配件, 看起來就更像早期研究者對於 wearable devices 的想像了.

這樣一來, 嘿嘿, 其實空間更大的是 software. 基於 Wii Fit 可以蒐集的資訊, 建構於 Wii 平台上的 software 可能發生的應用太多了. 希望任天堂公司別像 Apple 一樣, 把 Wii 平台開放出來吧, 這對於 Wii 的未來以及市場銷售絕對是有利的阿. 但在這之前, security 的問題絕對是十分十分地重要.

相對於任天堂的策略, Sony 跟 Microsoft 就採相反的做法, 他們都太執著於那台主機本身, 希望 customer 先坐著接受主機, 再來接受延伸的應用. 如果 wearable devices 的市場就此開發出來, 人們的電腦使用習慣因而改變, 任天堂應該會在歷史上再添榮光 :)

不過, 就像我標題寫的, 這只是可能而已, 變因太多了 :p

References
[1] Wearable Computers at Wikipedia, http://en.wikipedia.org/wiki/Wearable_computer

最近我有一個關於 code commenting 的想法, 正交由學弟妹進行計畫以及撰寫 paper 中, 剛好找別的資料時又看到一篇有趣的文章 : Ryan Campbell 早在 2005 年寫的 Successful Strategies for Code Commenting [1]. 文章中列舉了數種 code commenting 的樣式, 探討了 comment readability 甚至 comment reusability, 嘗試從各個面向, 探討一個好的 code comment 應該要有的長相. 文章內的其他連結也都很值得一讀.

然而, 我們真的需要這些 successful strategies 嗎 ? 或是更準確地說, 我們需要為自己或是 project 找一套 successful strategies 嗎 ? 誰又能負責對於是否 successful 作 evaluation ?

Software engineering 的書裡常說, software 的存在是為了讓人們可以更加專注在於他們應該思考的事情, 而不需要去在意可以透過 software 解決的事情. 而選擇或是擬定 comment strategy, 真的是 programmer 在撰寫 comment 時, 應該要花時間去思考的事情嗎 ?

Referfences
[1] R. Campbell, "Successful Strategies for Code Commenting," August 2005,URL : http://particletree.com/features/successful-strategies-for-commenting-code/

About a month ago, I found that several refactoring patterns are expressed with thumbnails [1]. The following figure is Evolving to the Strategy Pattern thumbnail, expressed by several refactoring thumbnails, referred from [1].


And yesterday, when I was checking the differences between JUnit 3.x and JUnit 4.x, I found it again in the document of JUnit 4.x [2] release. The following figure is referred from JUnit 4.x document.


This figure contains rich information, and clearly shows the global picture of how and the order design patterns were composed in the design of JUnit 4.x, without revealing the details.

I myself usually do the similar thing when sketching the initial design idea, however there is no patterns or fixed forms of my sketch. The lack of regulation in the sketches makes the design granularity and leveling hard to control.

It would be wonderful if there exists a design tool that can hold the design granularity and leveling control for me...maybe by the design thumbnailing support ?

References
[1] Refactoring Thumbnails, URL : http://refactoring.be/thumbnails.html
[2] JUnit, URL : http://www.junit.org/

雖然主要編輯軟體改成 OpenOffice.org 有一段時間了, 不過遇到某些狀況還是跟 OOo 白痴沒兩樣, 就跟以前使用 Word 一樣.

雖然說身為唸 software engineering 的人, 覺得責任也不全在我身上, 編輯軟體的 user interface design 應該是很典型的, 遵守 "讓使用者專心在他該花心思的事" 去設計, 而不是當使用者想要什麼效果時, 還需要抱著一兩本厚厚的書在翻找, 或是找有深厚使用經驗的 "高手" 求救 (通常這情形發生的越多, 表示這 software 的 user interface 設計越有改進的空間). 過去 Word / Office 每次出新版, 市面上的相關書籍就琳琅滿目, 該說 M$ 跟這些書的作者也算是某種共犯結構嗎 ?

回到 OOo 的自訂頁碼起始值好了, 如何插入頁碼在 OOo 的基本操作手冊文件裡已經有說明, 但是當我要自訂文件的頁碼起始值, 也就是希望頁碼不見得要從 1 開始, 可以從 15, 43, 或是任何數字開始呢 ?

(以下方法適用於 OOo 2.1, 也就是我現在使用的版本.)

有兩個方法, 第一個是在頁碼上按滑鼠右鍵進入欄位設定,

在欄位設定的格式選項下方, 有一個叫做修改的可修改欄位. 但問題是, "修改" 是什麼意思 ? 要修改什麼 ?

實際試了之後才會發現, 這裡的修改意思是對於目前頁碼的修改, 而且是加減的修改, 而不是直接替換掉原本的頁碼. 舉例來說, 如果把這裡填 10,

確定之後就可以看到原本頁碼是 32, 變成了 42, 同時上下相連的頁面, 其頁碼也會跟著改變. 換句話說, 原本的 32 + 修改的 10 = 最後的 42.

第二種方法就更神奇了, 你必須要把游標移到要改頁碼的該頁, 比如說剛剛的 page 32, 頁面內容的第一段上, 然後右鍵進入段落設定中. 請注意要是第一段, 否則改變的頁碼會從下一頁開始產生影響.

進入段落設定中, 在中間的位置有換行與分頁的設定, 需要把插入以及使用頁面樣式都勾選, 然後才能對右邊的頁碼進行調整, 一樣把他改到 42.

按下確定之後, 一樣可以看到 page 32 變成了 page 42. 但是請注意, 這種方法所造成的頁碼改變, 僅限於 page 32 及其以下的頁面, 換句話說 page 33 會變成 page 42, 但是 page 31 仍舊只會是 page 31, 跟第一種方法的影響不同.

Well, 回過頭來說 user interface design, 像是這種 design, 一來在使用者想要某項功能時, 很難以選擇施行(因為根本不知道可以這樣改阿), 二來對於究竟會造成什麼效果 (post-conditions), 也難以掌握. 今天只是改個頁碼就可能出現兩種不同的結果, 要是改其他的東西, 使用者如何放心文件的其他不相關部分不會被偷偷的進行什麼變動 ? 如果每次作設定的改變都需要使用者重新檢查文件一次, 這未免太累人了 :(

從這個 case 其實可以深入探討三個議題,

1. use case consistency : 如果上述兩個方法其實是同一個 use case, 或是相似的 use cases, 那麼他們的 post-conditions 是否應該保持一致 ?

2. use case understandability : 如何讓使用者事先意識到在他所使用的 use cases 中, 最終會對文件帶來什麼改變, 而不是等到 use cases 執行完了, 才讓使用者去找尋造成了什麼改變. 畢竟 use case 在 forward engineering 中本來就是給 customer 看的東西, 沒道理在真正使用 software 時反而不能從 use case 裡得到應該知道的訊息.

3. document-preserving activity : 這是從 refactoring 的 behavior-preserving 借用過來的, 以編輯軟體來說, 是否部分 activity 應該可以視為對 document 作了 refactoring, 同時這些 activity 也必須具備某種 document-preserving 的特性. 舉例來說, 上述的兩種頁碼變更方式, 第一種會維持頁碼的連續性, 第二種則是會打斷頁碼的連續性, 這可能是兩種不同的編輯功能, 但是顯然地他們造成的效果是不一樣的, 換句話說這兩個 activity 對於 document 的改變事實上就是具有不同的特性.

阿...越扯越遠了, 就此打住, 有機會再深入討論這些想法吧 :)