Software Cinema

Restaurant versus Application, Service, and Cloud

2010-11-16T15:13:00.021+08:00

An interesting metaphor comes up in my mind during today's Lab. group meeting...

(* All pictures bellow are retrieved from Google Image. Please let me know if there is any legal right violated.)

"Dine in" versus Conventional Application Software

"Drive-Thru" versus Service-based Software

"Call & Meal Delivery" versus Cloud-based Software

There are advantages and disadvantages in each way. Different issues must be considered from the customer's viewpoint, such as the control of restaurant selection, food quality and security, information privacy ...

I don't know if this is a good metaphor, but I think it shows some aspects of the differences among conventional software applications, service-based software, and cloud-based software.

BTW, I actually don't like McDonald's, but their pictures are most easily to be found on Google Image, so...

Recovering A Missing Simple Configuration File

2010-11-07T00:26:00.016+08:00

山不轉路轉, 嘿.

今天花了許多時間在挖某個 Jave-based Tool 的使用方式. 就不說是哪個 Tool 了, 也不打緊.

該 Tool 雖然有把 Source 公開 ( in Limited, Private License ), 但是幾乎沒有註解, 也沒有使用方式. 雖然包成了 Jar, 裡面也有 Applet GUI, 但是並沒有讓你直接使用的意思. Manifest.mf 裡面甚麼有意義的東西也沒寫, 也沒有內嵌 Applet 的 .html 檔案在. 換句話說, 該 Tool 作者使用包 Library 的方式在包一個事實上是 HTML Applet 的工具.

更麻煩的是, 某個必要的 Configuration File 並沒有附在裡面. 沒有該 File, 就算摸清程式運作邏輯, 也不可能讓工具動起來.

但是由於該工具可用的話將省下我一個禮拜以上的時間, 加上該工具的程式碼實在寫的太好了, 不使用跟探討看看可能是我的損失. 必須得想辦法回復此 Configuration File. ( 寫信跟作者要? 拜託... 這哪是可能的選項... 這樣不就讓作者得逞了嗎... )

在仔細去看 Loading Configuration 部分的程式碼之後, 發現了令人高興的事情: 該 Configuration File 的結構看起來十分簡單. 先看看他的 Config Loading 設計大概是這樣表示.

然後呢, 細節看看讀取跟處理的程式碼, 首先是如何取得單一設定值的要求.

接著看該工具怎樣處理 Configuration File 的 Parsing. ( 另外這裡只用 One-Pass 的方法, 讓程式更容易寫也值得筆記, 有時候不是非得要求 Two-Pass 來滿足任性的使用者 )

如此一來就可以得到結論, 該工具的 Configuration File 大概是長這樣.

attr1:value1
attr2:value2,value3,value4
attr3:value5, value6

問題是, 該填寫哪些 Attributes 呢 ?

這時候注意到取得單一設定值的要求都是透過同一個 Method Call Interface 處理的.

Config.get("snippet_dir")
Config.get("score_dir")
Config.get("benchmarkdir")
Config.get("classifier")

因此只要寫個簡單的 Python Script 去掃所有的程式碼, 看看出現同樣 String Pattern "Config.get" 的是哪些部分, 然後把所有的 Attributes 值重建就好了.

當然, 這流程只對結構簡單的設定檔案會有用, 略為複雜的就不太可能成功, 或是需要更複雜的演算法幫助, 例如 Apache httpd.conf 那種 = =

不過這個經驗倒是讓我想到一個問題. 假使不考慮這件事情的複雜度跟需要花費的時間, 是否只要有 Program Logic (Source Code), 就一定可以反推出任何該 Program Logic 所會取用的 External File / Data Source 的最基本 Structure ? ( 最基本 = 使該 Program Logic 可以運作 )

這問題是否等同於, 只要我們確定兩個 Components 之間能夠進行溝通, 且必會進行持續溝通, 我們就一定能夠破解溝通的內容 ?

Graph Cut Image Segmentation with A Center ( Star Shape Prior )

2010-10-30T21:10:00.024+08:00

在找某種 Tool 的過程中發現這個有趣的工具: Segmentation Graph Cut

它事實上是這篇 Paper 內容的實作:

Olga Veksler, "Star Shape Prior for Graph-Cut Image Segmentation," European Conference on Computer Vision, pp.454-467, 2008

雖然 Google Code 頁面上沒有明寫, 不過猜 Project Owner 就是作者本人. 因為 Tool 裡面包含的 Samples 跟 Paper 內容的範例圖都一樣, 同時如果你從 SVN 上 Check-out, 而不是只抓 Binary 的話, 會發現 Repository 裡面還有兩篇相關的 Paper PDF, 如果不是自己有版權, 應該不至於敢直接放到 Repository 裡面吧.

Anyway, 這篇 Paper 跟這個 Tool 的重點很單純, 就是要把所謂的 Star Shape 加到利用 Graph Cut 作 Image Segmentation 的方法中. 至於所謂的 Star Shape, 採用 Paper 中的定義:

A star shape is defined with respect to a center point c. An object has a star shape if for any point p inside the object, all points on the straight line between the center c and p also lie inside the object.

如果用圖來舉例解釋的話, 大概是像下面的 (a) 不管怎樣裡面的任一點都可以做為 Center C, (b) 只有部分的點可以做為 Center C, 因為有些點無法讓 P 的條件符合, (c) 不管哪裡都不存在 Center C 可以讓 P 的條件符合.

其中 (a) (b) 的情況都符合 Star Shape 的定義.

工具的 Binary Release 本身需要 Visual Studio 2008 的一些 Libraries, 我在 Windows 7 沒法安裝, 直接從 SVN 抓下來 SRC, 裡面有 C++ Code ( 尚不清楚實際用途 ) 跟作為 GUI 的 Python Code. 直接利用 GUI.py 執行極可.

請注意會需要 wxPython 跟 Psyco, 沒有的話會要安裝才能繼續執行.

工具目的單純所以容易操作. 載入圖片後利用滑鼠在圖片上指定 C 跟 P. 左鍵 Click 兩下會出現藍色點是 C, 一下的話會出現黃色點是 P.

我本來以為會以 P 作為切割邊線的決定條件的, 但看來不是這樣, 像上圖那樣標記, 最後還是會抓到整朵花 (右下的紅框是結果, 是我額外貼上去的, 工具本身是會呼叫你的看圖程式去開結果圖). 但是如果舉個極端一點的例子, 像是這樣:

基本上還是會割到 Boundary 為止, 我猜跟裡面用到的 Graph Cut 演算法有關. 不過我的 Image Processing 只有到基本的傅立葉程度 = = , 這個就沒法猜了.

當然 Title 寫 With A Center 是有理由的...

在一般的情況下, 只要標記上 C, 不用 P 也是可以抓到, 像是這樣:

而且運算時間算是蠻快的, 扣掉開啟看圖程式的時間, 可以直接把結果接到工具畫面輸出的話, 應該是幾乎到無感的程度吧.

很有趣, 改天有空再來從 Python GUI 研究看看是不是可以直接使用裡面的 Kernel Function, 接到別的程式上.

That's Not What I Sent

2010-10-28T16:28:00.030+08:00

其實這是上週的事情了, 只是很忙沒空寫下來.

上週在忙的事情, 其中一件是要開始電機系網站, 教授資料部分的 Data Migration. 因為目前的網站在教師資料部分, 超過 90% 的資料比例是用 HTML 網頁方式保存的, 不是用 Database 保存資料. 加上新網站是計算機中心統一跟外面的公司購買, 資料庫系統跟格式都大不相同, 對方也沒有 Migration 的服務 ( 就算有計中應該也不會想付這錢 ), 變成要人工去做. 不過這不是重點啦~

因為資料量太多了, 而且每個教授的資料維護本來就不是我們負責的工作, 所以就乾脆提前開放教師帳號, 給每個教師的工讀學生去處理 Data Migration.

開放帳號, 當然就是要寄出帳號跟密碼啦~ 這時候就發生了此篇的重點事件, 有位同學 ( 幫某教授更新資料的, 簡單說就是新網頁系統的一般使用者之一 ) 打了分機電話過來詢問:信件裡面的密碼有一部分變成笑臉男了, 怎麼辦 ?

沒有啦, 怎麼可能真的變成笑臉男, 這樣就變成 Security 的問題了. 其實只是變成一個驚訝臉的表情符號 ( 找不到完全一樣的, 用類似的替代 ).

沒記錯的話, 該同學用的 Mail Client 是 Outlook 的樣子. 然後他不知道原來 8o 會變成表情符號, 所以也無法自行 Decode 回去 ( 其實我也不知道 @@ ), 原本的密碼應該是 8#fdt8o

這問題有趣在於,

1. 這不是因為 Security Leak 產生的問題
2. Software 沒有錯, 也提供了調整或關閉的方法
3. 收信者不知道其實他有能力讓 Software 呈現正確的訊息
4. 收信者無法自行在腦中作 Decoding
5. 寄信者在收信者沒有 Feedback 前, 完全不會知道這問題的發生. 當然, 也無法預知會有這個問題.

不知道如果從 Sender 端跟 Receiver 端分別考量這個問題, 是不是可以解決. 這樣的問題應該不只存在於 Mail System 中. 更加極端地說, 這是系統中不同 Components 之間的 Trustworthiness 問題. (下圖大小很難調, 不管了, 請將就)

在 Receiver 端要提供更加 User Friendly 的 Active Configuration Notification, 而不是倚賴 Receiver 的使用能力. 而在 Sender 端則是提供 Active Warning 的服務, 類似 Automatic Spelling Check. 不過要做到這些, 其實有許多附加的問題要解決, 不知道是否有更簡單的解決方法呢 ?

Know both Design Abstraction and Implementation Detail ever Resourceful

2010-10-15T10:53:00.020+08:00

為了取這個標題, 還特地去查某句成語的英文一般都怎麼說 XD

昨天在處理實驗室 MoinMoin Wiki 出現的一個奇怪的問題. 某個特定頁面只要進行瀏覽, 就會導致 MoinMoin 整個 Crash, 一點 Process 也不留. 自然, 直覺就是該頁面內容有什麼奇怪的東西, 或是內容在磁碟上有毀損, 導致 MoinMoin 讀到該頁面內容就會出現 Exception 而掛掉.

但是在想要近一步去檢視該頁內容是, 猛然發現, 其實我不知道 MoinMoin 是怎樣處理 Page Data 的. 我既不知道 Page Data I/O 的部份在哪, 也不知道 Page Data 平常是保存在哪.

本來, 閉著眼睛也可以大概畫出一般 Wiki System 的 Architectural Design Abstraction, 主要的 Components 有哪些, 各自的責任也清楚. 但是單知道這些對我現在要解決問題幫助卻不是很大.

作為一個在唸 Ph.D. Program 的 Programmer, 這樣的事情真的是很不應該的, 但是還是發生了, 因此特別寫下這個標題--雖然別人看來可以摸不著頭緒--來警惕一下自己.

幸好簡單查一下 MoinMoin 的資料, 馬上就看到 MoinMoin 在 Data 的保存上十分簡單, 直接利用現成的 File System 作儲存而已. 這樣一來馬上補足了在 Data Repository 部份的一些細節, 也就一下子找到 Page Data.

MoinMoin 的 Page Data 存放在 /data/pages/ 中 ( 實驗室的資料比較敏感, 以下用電機系網路服務使用手冊 Wiki 作例子 ),

每個頁面直接用 Relative Page Path 作為 Directory Name, 其中 "/" 以及 "-" 之類的就用特殊符號取代, 像是 (2f) 跟 (2d).

在每個頁面的 Directory 之下, 有幾個主要的檔案跟資料夾, 名稱一看就很清楚, 不一一加註, 只舉頁面內容來說, current 檔案紀錄目前的版本, 而 revisions 資料夾裡面存有所有的歷史頁面資料. 因此實際的頁面資料是存在 revisions 資料夾裡的, 把每個頁面 cat 出來就很清楚了.

從這點也可以看出來, 其實大量頻繁的網頁修改, 在 MoinMoin 系統中是很吃硬碟資源的.

知道 MoinMoin 資料存放的細節後就更有趣了.

目前手上有些給實驗室用的小東西, 過去不是很清楚要怎樣把其輸出直接送到實驗室的 MoinMoin Wiki, 這樣一來其實可以直接在 File System Level 作手腳. 繞過 MoinMoin 本身, 直接輸出到 Data Repository 中, 只要內容格式符合 MoinMoin 語法, 跟 Revision History 等 Meta-data 有正確的填寫, 就能夠被 MoinMoin 讀取, 出現在 Wiki 頁面系統上了.

Know both Design Abstraction and Implementation Detail ever Resourceful.

我要把這句印出來貼在座位旁 :p

Play Sound using Virtual MIDI Piano Keyboard

2010-10-09T23:40:00.017+08:00

其實主要步驟只要照著 Compdigitec Labs 的這篇 Virtual MIDI Keyboard In Ubuntu 作即可.

不過實際上在我的系統上有些微的不同. 因為對整個 Sound System 不熟悉, 沒有辦法理解是怎麼回事, 姑且記下來當作 "這樣設定也可以" 看吧.

先記一下安裝的部份, 共需要 ( Package Name 以 Mandriva 2010.1 上的為準 ) :

1. qjackctl ( JACK Audio Connection Kit )
2. zynaddsubfx ( ZynAddSubFx )
3. vmpk ( Virtual MIDI Piano Keyboard )

其中 vmpk 是要作為虛擬 MIDI 鍵盤的主介面. 雖然後來發現 ZynAddSubFx 也有虛擬鍵盤介面, 但是變更 Keyboard Map 設定跟其他各種設定上, 感覺 vmpk 比 ZynAddSubFx 來的方便.

而 qjackctl 是 Connection 控制器, 負責把 vmpk 作為前端介面, 輸出的 MIDI 資料導引到 ZynAddSubFx, 再到實體的音效硬體/音效卡作播出. 因為 vmpk 本身其實就是單純的虛擬鍵盤子系統, 因此到實際播出前需要 Synthesizer 幫忙處理合成. ZynAddSubFx 在這裡就當作 Synthesizer 使用.

接著作 limits.conf 設定,

sudo su -c 'echo @audio - rtprio 99 >> /etc/security/limits.conf'
sudo su -c 'echo @audio - memlock 250000 >> /etc/security/limits.conf'
sudo su -c 'echo @audio - nice -10 >> /etc/security/limits.conf'

把系統 reboot 後重新開啟 qjackctl, 並利用 "Start" 按鈕開啟 JACK server ( jackd ). 這時候如果遇到開啟失敗的訊息, 請利用 Messages 按鈕看錯誤訊息. 如果是 server 啟動失敗, 請把 ALSA 重新啟動試試看. ( alsa command 的位置可能根據系統有所不同 )

sudo su -c '/etc/init.d/alsa force-reload'

啟動沒問題的話, 開啟 ZynaddSubFx 以及 vmpk, 然後利用 Connect 按鈕設定上面說的, 從 vmpk 到 ZynaddSubFx 再到音效裝置的 Connections.

照 Compdigitec Labs 的文章中之示範, 音效卡代號應該會出現在 ALSA 分頁中, 但是我的沒有 ^^b, 所以先只有把 vmpk 的 Output 接到 ZynaddSubFx. 接上的方法很簡單, 用滑鼠把 vmpk Output 拉到 ZynaddSubFx 上放開即可.

而 ZynaddSubFx 到音效裝置間的連結, 則是改在 Audio 頁面中搞定. 其中 playback 1 是左聲道, playback2 是右聲道, 其他的在我系統中無作用.

這樣設定完就 OK 了~, 把視窗 Focus 移到 vmpk 上面, 對應的鍵盤按下去就可以看到琴鍵變化, 以及發出 MIDI 音效. 在 ZynaddSubFx 視窗中也會有對應的變化.

其實當焦點移到 ZynaddSubFx 上也是可以有同樣的反應. 不過如上所述 vmpk 較占優勢的理由, 本篇還是以 vmpk 作為 Front-End 為主.

最初學 Programming 時的作業樂趣

2010-10-06T23:52:00.015+08:00

正在看一篇跟 Code Readability 相關的 Paper, 不知怎忽然想起大一剛進成大電機時, 學 Programming 的作業...

當然, 當時我學 Programming 與其說是上計概課學的, 不如說是自己學 + 認識的資工學長作榜樣居多, 但是書本上的練習跟上課的練習還是有差, 特別是你不想端出去的作業比別人差, 而且我們的計概課也不是一般呼嚨用的計概課.

我印象深刻的是一個 Hanoi Tower 的作業. 說到 Hanoi Tower, 其實我國中的時候就用數學的角度解過這個問題了, 但是寫程式是另外一回事. 稍微熟悉的人應該都知道, Hanoi Tower 是練習 Recursion 的基本入門題之一. 但是該作業有趣的是, 附帶了一個額外的加分題: 請用 Non-Recursive 的方式寫出解 Hanoi Tower 的程式 (當然, 要 step-by-step 輸出).

* 其實這題目有些書在 Recursive 章節後面也會加. 只是小大一是不會主動去看後面的練習作業題的 XD

那時候其實還不太會用 Search Engine, 而且 Google 在台灣也還沒有知名度, 很"傻"地就一頭鑽下去想解法, 以及怎樣寫成 Program, 還附帶要寫成 Document.

最後當然是有寫出來 ( 還上台介紹 = = 我大學生涯中第一次上台 ), 利用某些規律可以知道在三個 Towers 處在特定的 State 時, 就應該怎樣做 Transition 來到達下一個 State, 並且達到 Optimization. 也當然啦, 當時小大一是不會知道其實我在畫 State Transition Diagram 的 XD

其實在寫成 Program 以前, 我在找規律以及推導的過程, 本身就是 Programming 最重要的邏輯觀念之一. 可以在憑空找以及運算這些邏輯之中得到樂趣, 是後來可以成為一個積極的 Programmer 最重要的條件之一.

後來的作業印象中就比較偏向 Application 導向, 例如寫簡單的火車訂票系統之類的. 雖然其中也有很重要且複雜的 Scheduling 問題存在, 但是因為整個系統要考慮的 Functions 變多, 反而重要的 Scheduling 問題對於當時只是程式初學者的人來說, 變得不是那麼重要與有趣.

直到現在, 可能因為我們 Lab. 的大家習慣以系統角度通盤思考事情, 因此也反映到出給學生的作業上. 現在的作業寫滿整整兩頁 A4 的說明是基本 ( 一次作業一題而已歐 ), 前兩年甚至出現了高達六頁的說明 ( 印象中, 一樣是一次作業而已 ). 而看這作業說明的學生, 大多只是剛上大學, 剛要開始認真接觸 Programming 而已...

我們不禁應該思考, 這樣的作業美其名可以讓學生提早從整個系統角度思考 Programming, 可以更加貼近真實生活中的應用系統, 但是效果真的有比當初的 Hanoi Tower 好嗎 ? 如果我們並不期許計概課裡的所有學生最後都是一個好的 Software Engineer, 或是都要走 Pure CS 路線, 或許多些 Hanoi Tower 的題目能更引起學生自發的思考, 也更加容易傳遞 Programming 課程每次的教學重點.

Proceedings Review of the 5th International Conference on Software Engineering Advances (ICSEA 2010)

2010-09-27T10:27:00.051+08:00

今年雖然有投上 ICSEA 2010, 但是受限於早先已經申請了到 SEKE 2010 的補助了, 不太方便再跟國科會申請, 只好放棄 Nice 之行, 委託也有投上的另位實驗室同仁代為進行 Presentation.

不過帶回來的 Proceedings 還是應該掃過一次. 雖然 ICSEA 不算是頂好的 SE Conference, 但是我還蠻喜歡逛這種 Proceedings, 有時候會發現一些不成熟但是有趣, 具啟發性的想法 :)

1. A. Martin, R. Mazalu, and A. Cechich, ''Supporting an Aspect-Oriented Approach for Web Accessibility Design,'' pp.20-25

Software GUI Design 事實上從 70 年代以來就沒有公認的 Process. 雖然期間曾經有一段時間出現了各種 Methodology, 也有類似於 OO 分析的方法出現, 但是始終對於應該在何時開始考量 GUI, 中間的 A/D/P Process 與 Application 本身的 A/D/P Process 關係, 以及後續的 Maintenance 議題, 沒有一個串起來的發展系統. 而 Web GUI Design 近年來的思考似乎也漸漸向 Conventional Applications 靠齊... 除了看起來 Style 不太一樣, 其實操作模式都跟 Conventional Applications 很類似. 如果我們把 Browser 換成一般的 Client-side Interface, 似乎就也沒什麼兩樣. 我倒是很期待看到 Web GUI Design, 或是討論 Accessibility 議題是, 如果針對 "User 使用同樣的 Client-side Interface (Browser) 來看所有的 Web Applications'' 這點作討論的話, 會出現什麼樣的 Papers.

2. H. P. Breivold, D. Sundmark, P. Wallin, and S. Larsson, ''What Does Research Say About Agile and Architecture ?'' pp.32-37

我對於這篇的 Summary 不太意外, 因為整篇直接嘗試把 Agile 對於 Architecture 的影響在不限定 Context 的情況下去評估, 本身很可能得不到任何有意義的結論. 對我來說 Agile 其實是不適合直接跟其他的 Paradigms 去比的. 更進一步來說, 大部分的 Paradigms 都有它最適合的使用情境, 硬是要拉在一起比意義不大. 比較重要的是, Managers / Developers 是否可以在適當地時候得到該使用哪種 Paradigms 最有利的建議. 以這篇來說, 如果可以鎖定目前最常使用 Agile Paradigm 的開發情境, 再歸類此情境下最常被採用的 Architecture Design 類型, 再來作討論會比較有意義.

3. M. Basdavanos and A. Chatzigeorgiou, ''Placement of Entities in Object-Oriented Systems by Means of Single-Objective Genetic Algorithm,'' pp.70-75

這篇讓我想到五年前在實驗室的一個沒有完成的計畫. 該計畫的其中一個觀念就是把 Use Cases 當作 Capabilities 的集合來分析, 所有的 Objects 事實上是 Capabilities 的 Distribution. 這樣做的目的很抱歉無法在這裡說明...畢竟這是個不知道什麼時候會活起來的計畫. 不過可以理解在這篇裡面嘗試把所有的東西都打散, 不要依照直覺與經驗式的去找出 Objects 的想法. 但是在此之前的前端分析方法 Papers 中沒有明說...我覺得這對這篇 Paper 的 Justification 還挺重要的. 另外值得注意的是 Second Author 是 Alexander Chatzigeorgiou, 他跟 Nikolaos Tsantalis 的幾個 Works 真是令人印象深刻, 也讓我對這篇的下一步充滿期待阿...

4. M. Gebhart, M. Baumgartner, and S. Abeck, ''Supporting Service Design Decisions,'' pp.76-81

這篇左看右看總覺得, 跟 OO 的某部份分析方法好像阿(笑), 只不過一些關鍵字, 像是 Class, Coupling, Metrics, 沒有被拿出來, 也沒有被 Formalize 就是了. 我想, Service-Oriented Computing 跟 Functional Paradigm 以及 OO Paradigm 之間的關係, 應該在未來的兩年內就會很明朗了, IEEE TSE 上已經開始有 Paper 表明立場了...

5. H. Kaindl, J. Falb, S. Melbinger, and T. Bruckmayer, "An Approach to Method-Tool Coupling for Software Development," pp.101-106

因為這個方向, 實驗室也有一個延續性的計畫方向在做, 不便評論太多, 但是這個題目很實用也很有趣. 簡單來說, 現在的 Software Process/Paradigms 越來越多, 裡面要做的事情越來越細也越明確, 但是又不是每個細項都要在每一次的 SDLC 中被作到. 另一方面, 不管是 Commercial 或 FLOSS 的"工具"也越來越多, 同時各項工具目的用途有重疊也有相異, 有些共享標準有些沒有. 好的工具很重要, 如何知道根據工作選與使用好的工具更加重要... 大概就是這樣的問題.

6. M. Y. Santos and R. J. Machado, "On the Derivation of Class Diagrams from Use Cases and Logical Software Architectures,,," pp.107-113

從 Use Case Diagram 到 Class Diagram 的自動生成也是一個老問題了, 近幾年來幾乎沒有什麼新的東西出現, 主要還是這技術本身有 Accuracy, Reliability 的問題在, 連帶影響 Efficiency & Effectiveness... 太小的系統用處不大, 太大的系統又沒人敢/有必要用. 不過這篇 Paper 倒是提供了另外一個角度的思考: 如果在 Transformation 過程中, 加入了 Domain-Specific 的 Constraints 進去, 是否會讓這個技術有 "轉換" 之外的價值產生 ?

7. K. Popovic, Z. Hocenski, and G. Martinovic, "Do the Software Architects get the Need Support for the Job They Perform ? pp.123-128

這篇我只對最後一個整理出的 "What Architects Do and What They Need" 表格有興趣. 要我自己整理可能都要花個幾天想想.

8. S. Gunther, M. Haupt, and M. Splieth, "Agile Engineering for Internal Domain-Specific Languages with Dynamic Programming Languages," pp.162-168

我覺得這篇還不錯, 從務實的的角度把 "大家其實都是這樣作 DSL 的", 以及 "這樣作 DSL 比較會有人用" 給整理出來. 其實 Domain-Specific Language 可以說無時無刻都存在, 只是透過 Formalization / Standardization, 以 Language 的角度作整理, 才能有效地利用/重利用. 而建立於既有的 Programming Languages 之上, 可以省去建立 Compiler 的麻煩, 同時如果跟自家產品用同一種 PL 就有更多 Traceability Management 上的好處. 不過現有的 Dynamic Programming Languages 在被利用來建立 DSL 的侷限性, 例如適用的 Domains 等等, 似乎還是一個未知的問題 ?

9. S. C. de B. Sampaio, E. A. Barros, G. S. de A. Junior, M. Jose, C. e Silva, and S. R. de L. Meira, "A Review of Productivity Factors and Strategies on Software Development," pp.196-204

就只是關於 Productivity Factors 以及 Productivity Improvement Strategies 的整理. 可參考用.

10. M. Breu, R. Breu, and S. Low, "Living on the MoVE: Towards an Architecture for a Living Models Infrastructure," pp.290-295

我只能說, 有夢最美阿... 基本上有統一的 MetaModel. 以及不斷被建立的 Adapters 當然是很理想. 問題是一個不需要時常被更新的 MetaModel, 勢必造成不同 Models 之間的實質差異性會很大, 這樣的話能夠透過 Adapter 去解析與管理不同 Models 的能力就變低. 退一步來說, 在 Programming Languages 的轉換問題上, 也曾經造成一陣子的風潮, 但是現在幾乎沒有看到人在談了, 取而代之的是從根本建立一個共通的中介碼, 然後不同的 Programming Languages 則是根據用途變成不同 "Interfaces" 的感覺. 但是連在 Programming Languages 階段的改變, 實質效益跟使用度/接受度都還沒有明顯的功效之前, 我覺得一下子拉到 System Modeling 的層級還太早.

11. N. M. Carod and A. Cechich, "Cognitive Profiles in Understanding and Prioritizing Requirements: A Case Study," pp.341-346

雖然我認為如 Paper 內所提到, 此篇的 Study 結果也很難被用來佐證在其他 Context 下, 此方法的有效性, 但是 "感覺應該會有效" 卻是很直覺. 要想看到比較大規模的 Case Studies 也許還要等好一陣子, 畢竟這個想法的相關工具跟實驗應用的商業公司數量感覺都還不算多. 同時如何建立 Cognitive Profiles 在不同的應用情境下似乎又是一個不同的問題. 或許把此想法跟 Visual Software Requirements 結合會有意外的發展...

12. G. Grambow and R. Oberhauser, "Towards Automated Context-Aware Software Quality Management," pp.347-352

這篇 Paper 在 Abstract 以及 Solution Approach 一開始所描述的其實是一個 Too Good to Be True 的理想, 貌似我在碩一快結束時提的碩士論文題目也是類似的想法, 而且還包含更多 SDLC 的東西在 Context-Aware 的概念下, 所以我完全可以理解這篇作者的 "偉大願景" :p 很遺憾理想跟事實總是有相當落差... 從 GQM 出發我不認為是個好選擇, 因為 GQM 相當倚賴經驗法則去建立 Model, 要想全自動化需要先建立相當程度的假定 (Assumptions), 而這又會讓 GQM 變得不好用. 從這篇所引用的 Agent-based GQM Papers 全都是出自不太有名的會議論文也可略窺一二.

13. C. L. Reis and J. M. Pacheco, "Minimizing CO2 Emissions in a Computing World," pp.395-399

跟內文無關, 只因為最後一頁的那張圖 (話說, 內文也沒直接引用到這張圖阿... = =). 這圖很有意思, 最近有個題目的關係, 正在重新思考 Distributed Computing, Grid Computing, 到 Cloud Computing 之間的關係, 跟演進的理由. 這張圖在某個角度上還蠻符合我目前的想法. 這三個名詞都是指不一樣的東西, 雖然核心技術會感覺很像, 但是本來 CS 很多技術都是舊的, 只是當 User & Context 改變了, 想要達到的 Perception 也改變了, 導致最終提供的 Services 也改變了, 此時 Challenges 也不一樣了. 當然, 達到的效果也完全不同.

覺得比較有意思的, 扣掉自家實驗室的, 大概是這些篇, 因為按照順序看下來, 基本上頁數也是照順序. 在 page 399 之後的覺得有些跟 SE 關係其實較遠了, 有些非常技術性, 就是穩定地建立一個演算法來加強或解決某個具體的問題之類的, 可衍生的想法較少, 就都不記了.

"Implicit" Software Engineering Journals

2010-09-25T23:22:00.007+08:00

因為一些投稿的問題, 最近這週花時間把成大電通所的期刊點數清單掃過一次, 除卻清單本身錯誤百出之外, 倒是發現一些看起來不是直接跟 Software Engineering 相關, 但是其 Aim & Scope 有提到 Software Engineering 研究其實也可以投稿的期刊.

一般 Software Engineering 領域比較常見相關的 IEEE TSE, ACM TOSEM, SIGSOFT Soft. Eng. Notes, IEEE Softw., Comm. of ACM, ASE, JSS, IST, SP&E, Journal of Softw. Maintenance and Evolution, Software Quality Journal, Empirical Software Engineering 之外, 間接相關的也有 IEEE ToSC, IEEE TKDE 等等.

然後再扣除一些需要付費的 Journals (每頁付費或是 Free-of-Charge 的頁數過少), 例如 IJSEKE 以及 Intl. Journal of Computer Applications in Technology 之類的, 目前找到的還有以下幾個:

1. Journal of Information Technology (JIT)

因為此期刊我在成大無法取得所有全文瀏覽, 就 Sample Articles 來看, 此期刊偏向 Management 議題(特別是對於人的), 對於一般 Software Engineering Group 來說, 可能適合的主題包含: (1) Software, Middleware, Framework, Software Visualization Designed for Management (2) The Management of Customers, Stakeholders or Development Groups (3) Social Network Analysis in Software Domain

2. International Journal of Computer Applications in Technology (IJCAT)

就 Sample Articles 來看, IJCAT 在 Software Engineering 領域似乎沒有特別的偏好. 包含 Software Process, Design Models, Architecture Design, AOP 等等主題都有. 但是比較特別的是, 在內容上比較沒有看到 Tool Screenshot 形式的實物說明圖. 都是以示意圖, 範例圖或是架構圖居多. 另外也較少看到冗長的數據及驗證分析.

3. The Computer Journal

此期刊收納的 Computer-related 主題相當廣. 在 Software Engineering 領域的文章在 2001~2007 年不多, 但是 2007 年以後變多, 跟 Software Engineering 相關的文章數量占了 2001 ~ 2010 July 的近 80% 的量. 其中類別如上所述, 較少看見 Empirical Study, Quality Evaluation, Stakeholder Management, Requirement Analysis 等等的主題. 但是也或許是因為目前此期刊在 Software Engineering 領域收納的文章還不夠多所致...

4. Advanced in Engineering Software

此期刊著重在工程領域的軟體創新, 但是也有些許論文屬於上述的類別, 講述 OO 在協助解決特定領域的軟體開發問題. 通常 Paper 內會含有重要的分析設計等等... 實驗室若有在對外合作的計畫中, 例如醫療, 智慧家庭或其他具有工程特性的領域, 有利用 OO 進行開發, 可以考慮投稿到此

5. Journal of Research and Practice in Information Technology (formerly Australian Computer Journal)

雖然說在 Aim and Scope 裡也明列了 Software Engineering, 但是事實上自 2005 年之後, 嚴格來說只有 4 篇跟 SE 有直接相關, 且分散在不同的主題. 好消息是對於 SE 的主題沒有偏好, 壞消息是 SE 的直接相關論文實在太少, 況且是在澳洲有自己的 SE Conference 情況之下...

雖然這些 Journals 在一般 Softwar Engineering Community 裡不太會被人提起, 但是從這些期刊原本關注的範圍來看他們各自對 Software Engineering Papers 的偏好以及投稿狀況, 也別有意思. 以上僅限於成大電通所列出點數之部份, 不包含其他學校可能額外列入之 Journals.

To Have More "Replaceable" Distro. is Good

2010-09-21T17:31:00.015+08:00

剛剛才看到 Mageia 的消息, 忽然驚覺自己的想法也有些轉變.

在幾年以前, 雖然覺得難度很高, 但是基本上我算是 "統一 Linux 版本" 的隱性支持者. 姑且不論要用什麼方式統一, 例如有單一組織發行標準版, 或是針對 Distro. 架構訂出標準等等. 希望就此解決使用者會感覺混亂, 沒有單一品牌, 不易推廣等等問題.

但是上個月初, 因為一些誤會, 導致剛安裝好的 Mandriva 2010.1 RC 被我砍掉重裝了. 因為還有工作要完成, 沒有辦法等我慢慢釐清問題, 很不安地先備份資料後選擇重裝 Mandriva 2010.1 Stable. 因為我以前使用的習慣不是很好, 導致每次更新或重新安裝新版本, 在回復過去的工作環境上都需要六個小時或以上的時間.

但是這次因為距離上次更換為 Mandriva 2010.1 RC 的時間尚短 (不到幾個月), 大部分資料都只存在 /home 裡面, 額外的 Library 也幾乎都是用 Package Manager 安裝的. 因此在重新安裝之後, 再次透過 Package Manager 勾選所有我需要的 Package, 安裝後會動取用 /home 裡面的 Configurations & Profiles, 在一個小時內我就完成了整個安裝 + 幾乎整個環境回復.

這次的經驗是很好的, 因為我花了很少的時間得到了更新而穩定的系統, 同時我的資料以及各種 Configurations & Profiles 都沒有失去.

這個完全從使用者角度來看的經驗, 或許反映出是否有統一的版本或架構其實並非重點...

生物多樣性 -- 版本多樣性很重要, 但是對於使用者來說, 前提是不會因為版本多樣性而造成額外的負擔, 即便是版本多樣性可以帶來任何 Distro. Makers 所宣稱的好處.

所以什麼 "Domain-Specific", "More Stable", "The Plan of Company"... 一堆理由或許都敵不過 "Replaceable" 的重要性.

滿足 "Replaceable" 使用者就可以自由地轉換 Distro., 哪怕你的團隊就只發行一個版本的 Distro. , 只要他對於轉換提供某種程度以上的保證, 使用者就可以放心的使用, 不用挑什麼 "穩定長久地發展" 等等...

人都是不可靠的, Distro. 發展團隊也是. Mageia 也不能保證 Mandriva 的使用者改用他們的 Distro. 就不會在兩三年後被迫改回用 Mandriva 或是其他的 Distro. 以得到比較新版的整合. 相對來說, 如果 Mageia 可以跟我保證, 在某個時間點, 我可以知道轉移其他 Distro. 的 "Replaceability" 有多少, 會是更有意義的保證.

神速的 Justin.tv 守門員

2010-08-24T13:25:00.003+08:00

剛剛在看 Justin.tv 某台播電影, 邊看邊在找電影資訊, 因為 up 主沒放, 然後聊天室也沒人知道. 不過我認得男主角, 很顯然男主角是年輕時的 Tim Robbins, 而且就拍攝手法跟造型來推測, 應該是 The Shawshank Redemption 之前的作品. 這樣一推測其實就很好找了, 沒點幾下就找到是 Jacob's Ladder

正想把訊息貼到聊天室的時候, BAN !!

該頻道被 Justin.tv 管理員 ban 掉了...理由應該是因為一分鐘前出現了很短的女性露點畫面 (男主角老婆). Justin.tv 對色情管制還蠻嚴格的.

不過如此神速, 加上該頻道當時人不多, 而且畫面是電影中的合理出現, 讓我不禁懷疑是因為有人檢舉嗎 ? 還是 Justin.tv 本身會對頻道內容有自動檢測的背景程式在運作 ?

就我所知的確 Justin.tv 有監測員以及回報的管道, 但是如此多的頻道, 又只是一閃而過的畫面, 在考量由人管理時, 需要聯繫上管理員以及作 double check 的時間, 怎樣也不可能在一分鐘左右就決定 ban 掉頻道, 效率未免太好...

合理的懷疑是 Justin.tv 有整合截圖跟分析色情畫面的演算法, 作即時的監測. 如果是這樣的話還蠻厲害的...

真是夠了...

2010-08-24T12:04:00.008+08:00

已經不是第一次了... 今天又作了一個很類似的夢

什麼時候主管層級會意識到 Process 的重要性, 以及他們的位子在 Process 之中的重要性呢 ? 一個新聘人員的網頁資料新增工作, 照 Process 走是最有效率, 避免出錯, 而且該知道此事件的人都會知道的作法

可是偏偏就可以被搞成這樣

其中主管 T 是主導 K 聘任案的幕後推手之一, 但是卻只是草率地轉信丟出去給別人處理. 主管 B 的助理 J 是新找的, 有這麼信任 J 的處理不會丟了自己的顏面 ? 然後主管 D 默默地什麼都還不知道中...

這就是圖方便責任往外推的做事文化...

btw, 好像翻個身後還夢到上面六個人裡面有兩個是 IEEE Fellow ...

Picasa 3 Web Connection Failed (Login Failed) on Linux

2010-08-14T03:25:00.007+08:00

因為重新安裝了新版的 Mandriva, 自然 Picasa 也要重裝 ... 時間過得很快, 沒想到已經有 Picasa 3 beta 了, 鑑於個人對於 Picasa 2 for Linux 的諸多不滿, 自然想試試看 Picasa 3 ...

結果還是一樣, 到底為什麼 Picasa 要設計成一啟動就不受控制地 Scan 我的所有大大小小資料夾呢 ? 而且介面對於 zh-TW 的支援還是很有問題阿...

正向上傳去澎湖的一些照片的時候, 又遇到 Web Connection Failed 的問題, 訊息大致是像這樣:

Login failed
HttpOpenRequest failed (12157) -
https://www.google.com/accounts/ClientAuth [13]
.........

找了一下 Google, 補上 openssl-devel 的安裝即可解決. 在 Mandriva 2010.1 下的話, 相對就是 libopenssl-devel package

不過感到奇怪的是, 因為原本 openssl 已經有安裝了, 為什麼 Picasa 還是需要 devel package 呢 ? 如果只是需要 libssl.so 的話, 在 openssl/libopenssl package 裡面應該就已經有了.

難不成在進行 Web Connection 時, Picasa 會作某些 Compilation 動作 ?

不過如果仔細去看 /home/user/.google/picasa/3.0/ , 會發現有以下的錯誤訊息:

fixme:wininet:InternetSetOptionW Option INTERNET_OPTION_CONNECT_TIMEOUT (10000): STUB
fixme:wininet:InternetSetOptionW INTERNET_OPTION_SEND/RECEIVE_TIMEOUT 10000
fixme:wininet:InternetSetOptionW INTERNET_OPTION_SEND/RECEIVE_TIMEOUT 10000
err:wininet:NETCON_init trying to use a SSL connection, but couldn't load libssl.so. Expect trouble.

從最後一個訊息看起來是因為找不到 libssl.so , 因此再回頭去看 Mandriva 2010.1 在 libopenssl 以及 libopenssl-devel 裡面的檔案安裝配置, 會發現 :

libopenssl 安裝完只有 /usr/lib/libssl.so.1.0.0

而 libopenssl-devel 安裝完會建立 /usr/lib/libssl.so -> /usr/lib/libssl.so.1.0.0 ( Konsole 配色 XD )

這樣 Picasa 才能夠找到 /usr/lib/libssl.so 而成功進行 Web Connection.

所以... 應該是可以不用安裝 openssl-devel package, 只要自己在 /usr/lib 裡面建立 softlink 到正確的 libssl.so 檔案位置就好... 不過這只是個人猜測, 懶得移除再嘗試一次了 :p

Boot and No Screens Found [Solved ... ?]

2010-08-01T13:59:00.025+08:00

Unfortunately... after a weekend power blackout, my Philips 200WB monitor could not display anymore in X system.

The booting message on the monitor displays fine, it just got into "SLEEP" mode when the X starts to running, and nothing shows up thereafter.

Changed the runlevel to 3, and logined in command line to check the log, the kdm.log only says: No Screens Found.

The log message may be correct, but it seems odd to me since I could see all the booting messages before the X starts to run...

If you google the message "No Screens Found" plus the keywords linux, mandriva, startx, or whatever, you might found many speculations and possible solutions, such as the corrupted xorg.conf, inconsistent package upgrading, driver problems...

I had no idea what's going on, but I did make some X system upgrades before the blackout, so I guessed maybe one of the speculations is my problem. Therefore I tried these solutions as people suggested on the web:

1. depmod -a & startx to see if it works

2. XFdrake --experts to re-configure the xorg.conf ( actually this works the same as drakconf on Display configuration )

3. Remove the original xorg.conf, use xorgconfig to generate new xorg.conf

4. Set the device and the monitor to generic options

5. Re-install the X system

6. Re-install the Mandriva ... ( Yes I did that !!! Fortunately I made the system and data partitions a clear cut, so the re-installation is quite easy )

And all of these solutions did not work, my monitor still SLEEPED ZZZzzzzzzz after the X starts to run.

Somehow I started to think : Will it be the problem of the monitor itself ?

So I changed the monitor with another Mozo LCD with D-Sub connection. Hell, my desktop is back ~!!

After a cross check, I finally figured out that the problem is on the DVI+ connection of my original Philips monitor. The connection is a DVI-D single link. The end of the link in the monitor side is not locked, and being a little loose.

I check some DVI information on the web, but I really can not figure out how it works and how this would happen. I guess there might be two causes: (1) because of the loose link, the video adapter can not acquire the correct monitor EDID, or (2) because of the loose link, some video signal (TMDS) can not transmit correctly.

Anyway, after I re-connected the DVI-D link and locked it well, the monitor functions correctly as usual :)

So, if anybody has the same problem as me, maybe you can consider check the DVI link before try any complicated solution :p

Supporting SQL in DBMS

2010-07-26T15:41:00.003+08:00

最近因為研究上的需要, 回頭在翻一些基礎的 Database, 猛然發現很多重要的觀念, 當初唸書時都理所當然地輕帶過去, 沒有去深入思考其在軟體設計上的意義.

例如昨天忽然就想到 SQL 在不同 DBMS 上的問題. 當然我知道 SQL/ANSI-SQL 已經算是 RDBMS 領域的標準語言, 但是, 是否各家 RDBMS 需要自己實做對於 SQL 的所有支援, 或是有某幾種 SQL 處理引擎或元件是可以直接被不同的 RDBMS 採用的 ?

修過 Database 基礎課程以及 Database Tuning 課程, 卻沒有想過這個問題...

回頭翻了手上的 Database System Concept 帆船本第四版, 在介紹 SQL 時完全是以使用以及對比前一章的 Data Definition Language 角度來寫, 自然沒有提到 Database Architecture 的事情. 其他地方我也沒翻到, 直到最後面的 Case Studies 在 SQL Server 的部份才略為說到一點 Query Processing 的東西. D. Shasha et al. 的 Database Tuning 則是在第四章一開始, 以及第五章一開始有提到, 特別是 ODBC 的部份, 不過顯然我當初這地方是很直覺地帶過去了 = =

對照網路上找得到的 SQL Server Architecture 參考圖 ( from http://sqlbaba.wordpress.com/ )

再來個 MySQL 5.5 的架構圖

答案我想應該就跟很符合邏輯的猜測一樣, 在效能調校及商業機密考量下, 主要的 Vendors 應該都還是自行實做 SQL 處理的部份.

SE 的研究工作是你想的這樣嗎 ?

2010-07-23T15:40:00.007+08:00

今天在意外之中看到了 Mr. Jamie 的這篇創業不是你想的那樣. 話說我有好一陣子沒有在 follow 這些創投相關的 Blogs 了...

Anyway, 撇開創業一事不論, 從 SE 研究的角度看他列出的這幾點中, 倒是有幾點相當有感觸.

最重要的是堅持, 由很多很多小事情組成, 從最簡單的產品開始, 根本不用去想競爭對手

幾個月前老師找我去談, 直說了我還欠我的學位最後一項東西, 那就是堅持. 對於自己手上工作直到最後有價值產出的堅持. 我們永遠可以有很多的 Ideas, 但是拿幫你拿下學位的是對於其中一兩個 Ideas 所付出的堅持.

從 SEKE 2010 回來之後, 也不斷地在思考 VESTA 為什麼推出去評價兩極, 只得到 Short Paper 的結果, 怎樣的包裝才是對的 ? 最終我得到的答案卻是啟發自一個四年前曾經被 Reject 的 Paper. 如果當初有持續把該 Paper 修改完成, 或許我會早一年發現到正確推出 VESTA 的方式.

眼頭的這個暑假, 是明年初能否有好結果的關鍵期, 不過自七月中回 Lab. 後, 故態復萌地對幾個手上撰寫中的 Journal Papers 三心兩意. 雖然老師早就告誡過我, 先從付出最少 Effort 就可以簡單完成的開始, 似乎我總是沒放在心中...

四年了快邁入第五年 (加上 Master 就不只啦), 回頭看看, SE 的研究工作真的跟我剛進 Lab. 時想像得不一樣, Funny & Creativity 只是研究工作中的一部分罷了...

Notes on SEKE 2010 (二)

2010-07-15T06:03:00.000+08:00

Sessions

我三天來其實聽了不少 Sessions, 三天總計參加了 14 個 Sessions, 不過有深刻印象的 Presentations 不多, 或許是因為 SE + KE 其實範圍很大, 但是 Conference 的題目大部分都是比較小而明確的, 除非對兩個領域中的所有主題都很熟, 否則有的很難快速理解, 加以並非每個講者的 Presentation 技巧都很好... 另外 SEKE 的 Presenter 缺席狀況比我預計的要嚴重一些, 也許是因為簽證問題, 幾乎我去聽的每個 Session 都至少有一位 Presenter 缺席.

不過有少數的 Presentation 還是可以學到不少東西. 例如第一天的 Software Engineering with Computational Intelligence and Machine Learning Session 中, Prof. Taghi Khoshgoftaar 的 Presentation 就很精彩. 雖然因為內容牽涉到我不懂的背景知識, 在短時間內很難判斷論文內容貢獻度, 但是 Prof. Taghi Khoshgoftaar 的演講風格極具 "攻擊性", 對於自己的論文內容以及貢獻有極強的自信, 甚至直說整個會議只有他 Group 的 Papers 是真正結合 SE & KE 在做研究的. 是國內會議以及學者演講少見的報告風格. 之前就聽我的指導教授說過, 好的 Conference 中會出現很多 Presentation 是講者跟聽眾之間的 "戰爭", 這算是第一次見識到了 :p , 有機會遇到應該要去聽聽.

我自己第二天是在 Software Maintenance and Evolution Session 進行 Presentation, 內容算是很順利, 在 Session 結束後 Session Chair Dr. Ned Chapin 也給我一些 Presentation 上的建議. 網路上找得到 Dr. Ned Chapin 個人資料不多, 也沒有比較明顯的照片, 本來以為 Dr. Ned Chapin 會是有點頑固的老學究, 但是卻是出乎意料地親切的一位老先生. 我發現 Dr. Ned Chapin 對於像我這種學生進行 Presentation 都會在私下給予建議, 另外他在講者要開始說之前會作簡要介紹, 提醒大家 Paper 在 Proceeding 中的頁面, 最後的提問往往也很切中要處, 是我在這次 SEKE 中遇到主持最好的 Session Chair. 因為 Dr. Ned Chapin 也算是 Software Maintenance 領域 Conference 的常客, 作這方面的國內學者應該有相當機會遇到他.

Dressing

在服裝上, 我發現 SEKE 會議大多數參與者其實沒有傾向穿著整齊的西裝或女性套裝, 就我看到有穿整套西裝/套裝或是類西裝的學者人數大約不到 30% 吧. 許多人都只是穿了襯衫, 也不一定有打領帶. 因此若前往參加而不便攜帶西裝或套裝者, 準備整齊適合辦公場所的服飾應該就可以. 我自己是三天都穿了整齊的西裝啦, 不過也沒有遭受什麼異樣的眼光 XD

第一天的晚宴跟第二天的渡輪晚餐在穿著上大家也是都跟白天差不多, 所以基本上就是放輕鬆穿就好~

Hotel Sofitel and Around

Sofitel 的一般房間價位加上稅是每夜 200 美元出頭, 不過因為他們給 SEKE 的優惠, 所以我大概每夜花了 3000 NTD 左右, 差不多跟台灣同等級的旅館價位相仿. 不過我在台灣也極少住這種價位的 ( 窮學生 = = ).

房間我覺得算是很大, 寢具都很軟且舒服, 住起來相當舒適.

Sofitel 所在的位置比我想的還要偏僻一些, 位在一些軟體公司的附近 (像是 EA, Oracle, Sony Ericsson 等等 ), 可以事先準備 Google Map 列印紙本, 或是跟櫃台要簡易地圖. 基本上我出去玩幾乎都會跟旅館要看看地圖, 有時候旅館自家畫的地圖會很有趣.

Sofitel 有提供地圖, 但不是複雜街道圖, 因為附近道路其實也很單純. 出了旅館, 除非有開車, 否則步行的話主要只有兩個方向可去.

第一個是出旅館後往左邊沿著路一直走, 這時候右手邊是 EA, 沿著路走大約 12 ~ 13 分鐘, 會遇到一個較大的十字路口, 直走過去會遇見一個小的 Market 區域, 有超市跟一些賣吃的, 墨西哥捲, Pizza, Starbucks, 中式餐館, 漢堡潛艇堡店等等.

檢視較大的地圖

最裡面的 Amici's Pizza 店我覺得很好吃, 墨西哥捲那家的 Fish Burrito 也好吃, 中式餐館聽說附近蠻有名的, 不過我沒去嘗試 :p , 價錢都還好, 看你吃什麼, 含軟性飲料大約都在 7 ~ 20 美元一餐. 下面是 Fish Burrito, Pizza 還在等北大的王立杰寄給我, 當時去吃時相機沒電了 :p

第二個方向是出旅館後往右走, 直走到底會遇到 T 字型路口, 過了馬路馬上會看到 Oracle Campus, 相當地漂亮. 之後往左邊走, 有高架橋道路可以遇過 Free Way, 之後再直走會遇到一些吃的店家以及 Cleaners, 包含溫蒂漢堡.

檢視較大的地圖

在溫蒂漢堡路口往右前方看就是 CalTrain 的 Belton Station. 這條路大約 30 ~ 40 分鐘. 另外一個走法是出旅館後直走再右轉, 也是會接到高架道路, 大約可以少走 5 分鐘左右.

Sofitel 鄰近 Redwood Shores Lagoon, 因此早上傍晚都可以直接從旅館吧台附近的玻璃門出去到 Lagoon 走走. 推薦早上六點多帶著熱咖啡穿禦寒衣物沿著 Lagoon 走一小段再走回來, 雖然有點冷但是十分舒服.

CalTrain 系統往北可以接上舊金山 BART 到舊金山市區, 往南可以到 Palo Alto / Stanford, San Antonio, San Jose ...等等, 採用分區計價, 月台上有自動售票機, 上車後才會有列車人員檢查車票, 感覺人力相當精簡. 會議期間利用 CalTrain 到了 RedWood City, San Carlos, Palo Alto / Standford, 以及接上 BART 到 Berkley 逛了逛, 雖然車票比起台灣不算便宜, 但是還蠻方便的. 其他部份屬於旅遊參觀性質, Google 上應該可以找到相當多資料, 就不寫了~

Notes on SEKE 2010 (一)

2010-07-14T05:20:00.015+08:00

六月底到 San Francisco 參加 SEKE 2010, 在各方面都學到不少 :)

今年在 Redwood City, San Francisco Bay 的 Hotel Sofitel 舉行, 2006 年後 SEKE 都是在 Boston 跟 Hotel Sofitel 輪流舉辦, 不過下一屆 SEKE 2011 據說會在 Miami Beach 舉辦, 因此 2012 是否會再回 Hotel Sofitel 就不知道了.

把一些會議的東西雜記下來, 順便當作申請國科會補助的報告, 也許往後台灣跟我一樣首次參加的同學們也用得著.

關於會議內容或 Keynote 等等或有疏漏, 如果同樣今年有參加的朋友歡迎協助更正或補齊.

在 Keynote 的部份, 前兩天參加的人數都還算挺多的, 應該都在 60 人以上, 第三天稍微掉了, 但應該還是有 40 人左右. 在三個 Keynote 的內容部份, 其實我覺得並沒有聽到太多新的觀念或思考, 但是有機會看看一些重要人物的風采, 以及底下的教授們怎樣針對內容提問也是有趣.

Keynote I

日的 Keynote I 邀請到 Google 的副總裁 (Vice President of Research and Special Initiatives ) Alfred Spector 進行演講, 講題為 Prodigious Data, Logic, Processing, and Usage.

Alfred Spector 副總裁首先由會議主旨的 Software Engineering & Knowledge Engineering 兩個領域的結合切入到 E-Science 這個主題, 而其所指稱的主要是針對極大量資料的處理, 以及從中獲得知識的科學問題, 特別是在社會現象研究的領域. 過去在科學領域缺乏適當的工具及平台來即時獲得足夠大量的資料進行此類的科學活動. 然而 Google 以高市占率的搜尋引擎, 結合使用者與網路, 並在系統後端保存此龐大的社會資料, 使得此方向的研究充滿可能性. Alfred Spector 副總裁並提到, 如果我們能夠得到真正足夠大量的資料, 我們將有可能直接就資料來解釋某些現象發生的原因, 進而即時做出決策判斷. 人們將可以從系統 (搜尋引擎或是 E-Science 系統) 得到知識, 而得到的知識促使人們產生更多的資料給系統, 系統藉此推論出更多的知識 ( People learn from the System, and the System learns from the Data. )

在這樣的願景下, 其實還有諸多難題需要直接結合 Software Engineering & Knowledge Engineering 兩個領域進行研究. 例如最受關心的隱私權問題 ( Privacy Issue ), 目前尚缺乏真正具影響力的研究成果. 另外極大的系統規模必然會使得一些關於規模的議題更加重要, 例如目前 iPhone 上有超過 22000 項應用軟體可以選擇, 其中最少也會有一項軟體在實際運作時, 產生對於資料的安全性問題. 而在系統內, 透過各種方法所搜集的大量資料, 又要如何被重新用來預測可行的決策, 回答各種可能的問題等等, 都有待進一步的研究.

Keynote II

次日的 keynote Speech 由 IBM 聖荷西 Almaden 研究中心的副總裁 Josephine Cheng 針對建立更聰明的世界 ( Smarter World ) 與各大學的合作為主體作演講. Josephine Cheng 副總裁主要透過 IBM 目前在世界各地所進行的各種計畫以及其成效為主題, 以計畫帶動演講內容. 比較令人訝異的是, IBM 的各項計畫並非以電腦系統為主體, 而是以各種社會面向為出發, 從 Socio-Technical System 的角度在經營計畫, 並從中找出可以利用電腦系統來輔助計畫進行的方式. 因此從 Josephine Cheng 副總裁的介紹之中, 其實內容涵蓋了許多看似跟電腦系統無關, 或是跟綠能環境無關的計畫主題. 但若深入細想, 會發現 IBM 在此議題上的主張其實並不是一味地要求節省能源, 而是在進行各項先端的未來研究, 或是大型社會計畫的過程中, 儘量做到節省能源.

在 Josephine Cheng 副總裁的演講中列舉了以下幾項計畫:

IBM 正與許多國家的政府合作, 在推動以 RFID 系統標記農產品, 藉此掌控所有農產品從生產後到運輸及倉儲系統, 直到銷售為止的過程. IBM 的願景是希望透過這樣的系統可以減少運輸及倉儲階層的剝削, 同時讓農產品的生產過程更加透明化.

在認知科學運算 ( Cognitive Computing ) 以及腦神經模擬科學的部分. IBM 目前已經在簡單動物的腦模擬上取得相當成果. 問題是當這樣的醫療計畫需要進展到更複雜的動物腦模擬時, 需要極大量的電腦主機以及 CPU 同時進行模擬, 此時會形成相當巨大的腦模擬系統. 這樣的系統在耗能上對於研究人員以及社會資源會是相當大的負擔. 因此在持續此研究的方向同時, 必須要兼顧到怎樣可以製作較為節省能源, 同時又適用於腦模擬科學的 CPU 以及系統, 就是一個重要的問題. 同樣的問題也會發生在未來可能的資料中心 ( Data Center ) 或是雲端系統 ( Cloud System ).

在水資源的利用方面, IBM 也意識到許多產業事實上在產品製作過程中消耗大量的水資源. 因此 IBM 也在協助建立更加節省水資源的製作系統, 以及強化在製作過程中的水資源重用 ( Reuse )

另外 IBM 也與 Stanford University 合作, 在塑膠保特瓶的回收流程上進行改進. 基本精神是: 改變遊戲規則. 換句話說, 他們所研發的新流程跳脫往常的回收及集體重製思考模式, 而是嘗試把瓶子分解為可直接重新組裝的基本元件, 進而加速重製流程, 降低過程中的化學流程使用, 降低水使用量以及污染量, 同時也可以降低成本.

Keynote III

第三日的 Keynote Speech 由 Texas Tech University 的 Daniel E. Cook 教授針對多處理器 ( Multi-Core ) 時代, 以及隨之而來的平行運算環境, 以軟體開發者 ( Programmer ) 所面臨的程式設計 ( Programming) 挑戰, 以程式語言 (Programming Languages ) 的角度進行探討. 在 keynote Speech 中, Daniel E. Cook 教授首先簡要說明了研究者以及軟體開發者所會面對的程式語言之挑戰, 接著主要的內容為介紹其領導之研究團隊所開發之 SequenceL 語言. 據 Daniel E. Cook 教授的說法, SequenceL 並非最近幾年才發展的語言, 而是起於二十年前, 從平行運算研究時代一路發展過來的成果.

Daniel E. Cook 教授在演講中主要整理出三個主要的挑戰點:

The challenges and difficulties in finding emergent behaviors and potential faults in parallel computing hardware, such as race condition. 程式語言及編寫環境是否可以協助發覺異常行為以及可能因硬體運作因素而產生的潛在威脅

The difficulties of testing design. 第一點同時也導致軟體開發者會面臨如何設計好的軟體測試策略以及測試方案 ( Test Cases )

Code understanding problem of the parallel code will restrict programmers in writing code parallelly. 針對多核環境所編寫的程式碼可能會相當不利於程式碼理解 ( Code Understanding ) 以及檢討 ( Code Review ), 此點同時也會影響軟體開發者撰寫多核程式的意願

Application Issues of QR Train Ticket

2010-06-15T13:41:00.007+08:00

Technology news in Taiwan today :一張車票教你逛巿集

且先別說 QR Code 本身已經是相當 Well-known 的技術, 將之運用於車票上來推廣或便利觀光基本上只是重新實做的問題 (甚至連重新實做都談不上, 如果直接跟日本買技術或是討用部份 OSS 的資源來改的話...)

看了新聞內容直覺遠東的這想法在實用上會有很大的障礙.新聞內容提到 :

方便旅客迅速找到想要的資訊，出門不必再帶地圖或導覽手冊。比賽時評審特地要我們實際上網試試，同學鄭大為說，3G手機上網很夯，但依流量計價動輒得花數十元、上百元，好玩卻很傷荷包，但QR Code直接連到指定的網頁，一次只花2~3元，省很多！

這樣問題就來了. 有別於在日本是各店家自己在海報上, 或是宣傳單上印上可以連到自家網頁或是 Coupon 的 QR Code, 印在車票上對於所有店家來說具有單一性以及排他性, 更白話地說, 請問車票上該如何決定要印上那一家的 QR Code ? 或是哪家網站的 QR Code ? 總不能把這問題交給廣告費多寡來決定吧 ?

如果說要由交通局統一製作一個可信賴的導覽網站, 則又面臨該網站的製作及更新維護費用, 同時瀏覽該往站未必可以達成節省流向以及網路花費的問題, 因為要看的資訊量還是變多了.

而在車票上同時印出多個 QR Code, 一來車票本身沒有這麼大的空間, 二來這也跟新聞內容提到可以節省瀏覽的時間以及花費又相抵觸了.

這樣想來, 在應用上似乎有著重重障礙要克服...

2010 開放原始碼創新應用開發大賽

2010-06-10T08:46:00.008+08:00

今天收到 2010 開放原始碼創新應用開發大賽的訊息通知,今年還蠻想參加看看的.

不過網頁中對於參賽作品的定位其實有很大的問題, 到底比賽目的是要促進國內自由軟體社群的 "量" 還是 "質" 呢 ?

常說自由軟體, 但實質上包含了 Free/Libre/Open Source Software (也就是一般說的 FLOSS), 這之間的意涵是不一樣的. 從競賽主軸以及對於作品的規定, 完全看不出來主辦單位對於參賽作品有明確的定位.

到底是希望可以在台灣 FLOSS 社群激發更多 "Free Applications", 或是創造更多有潛力的 "Open Source Software" 呢 ? 這兩個目標所需要的評量要件應該要有很大的差異性.

前者應該著重在對於使用市場的分析, 介面設計, 作品穩定度, 甚至是利用 Immature Releases 來評估團隊的市場預估以及經營能力. 要作就應該做出大受歡迎的 Free Applications, 而不是持續讓 "絕大部分的 Free Software 都很難用也沒什用" 這樣的印象繼續擴大.

後者的評量其實應該著重在作品架構設計 (Software Architecture Design) 上, 以及社群角色遷移程序 (Community Role Immigration Process) 的設計上. 完成度跟穩定度反而比重可以降低. 因為後者的重點在於 "讓社群中有興趣的成員可以很容易加入開發", 而不是要求把產品做的很完美.

從去年的獲獎來看這比賽似乎是很偏向前者.

而即便是 "應用" 也有小眾與大眾之分, 主辦單位跟評審們會一視同仁嗎 ?

Learn-By-Study versus Learn-By-Programming

2010-06-02T17:57:00.012+08:00

剛剛有大一的學生到實驗室問計概助教一個教科書上的問題.該學生對於書上寫了:

要注意 Escape Character 的使用... 例如 "\1234" 會被視為 "\123" 與 "4" (懶得去抄英文原文, 直接用中文寫)

感到很奇怪, 不懂是什麼意思, 為什麼不是 "\1" 與 "234" ?

我覺得會注意到這個問題代表該位學生很認真地在看書, 想我自己剛學 Programming 時根本也沒注意過這個問題. 但是我覺得該位學生的提問方式, 其實曝露出了她在唸書時的習慣, 很可能是延續唸一般科目的方式, 只在書本上思考跟學習.

事實上, 在她已經會基本的 C Programming 情況下, 一個簡單的程式可以為這個問題帶來解答的線索.

這個簡單的程式在一般的系統中應該會給出 S4 的列印結果. 再多試一下改成這樣 :

會給出 T4 的列印結果.

從這兩個簡單的程式, "\1234" 會被視為 "\123" 與 "4" 是一個學生自己就可以驗證的事實, 因此真正的好問題應該是,

"\123" 是什麼 ? 為什麼系統會認得它 ? 為什麼會印出 S ? 為什麼它不在我學過的 "\n", "\t" 等等特殊字元裡面 ?

從而該位學生或許有辦法根據以上修改過的問題, 進一步分辨 Control Characters 以及 Printing Characters, 以及更深入了解 ASCII Code Table, 最終得到 "\123" 會被印出 S 是因為 123 是 S 在 ASCII 中的 Octal Representation 之猜測.

當然, 不能期待剛接觸 C Programming 幾個月的學生可以獨立得到最後的結論, 但至少在看書之外, 動手去找尋原因, 嘗試, 猜測以修正問題, 對於 Programming Learning 是很重要的.

Knotify4 Crashes Mandriva Sound System

2010-06-02T12:16:00.008+08:00

又是 Mandriva 2010.1 RC 上的問題. 在我的系統一段時間沒操作之後, Knotify4 會開始不斷地運作, 大約佔據 6% 的 CPU, 每隔兩秒出現提醒音效, 然後完全阻斷整個音效系統, 連帶 Audacious 或是 AmaroK 會當掉. 即便重新開啟 Audacious, 也是會在播放時, 每隔一秒強迫重放該首 (應該是因為 Sound System 被佔據, 更準確地說是使用 ALSA 系統會這樣)

查了一些討論, 似乎 MDV 2009 版本開始就有類似的問題, 有回報修好, 但是在後續的 KDE 4 版本還是有人遇到同樣的問題.

找到唯一明顯有效的解法是放棄系統提醒音效...

作法是 (在繁體中文版) 桌面設定 -> 外觀與感覺 -> 通知 -> 系統通知 -> 播放器設定, 請改為 "沒有音效輸出"

不過這樣的解決方案有點討厭就是了, 需要系統通知的使用者就要犧牲了 = =

Firefox 3.6 很慢的問題...

2010-06-02T11:46:00.004+08:00

剛換了 Mandriva 2010.1 RC 不久, KDE 4 雖然很漂亮 (之前是 MDK 2008, KDE 3.5), 但比較討厭的是 Kwin 在我現在的機器上效能表現不佳, 不知道是否與顯示卡有關, 還沒有時間深究. 另外一點是內建的 Firefox 3.6.3 在開啟頁面以及切換頁面時, 超級慢 ~~

今天早上終於受不了, Google 了幾個頁面, 沒想到一下子就找到解決方案啦 :)

問題點在於 Firefox 的 network.dns.disableIPv6 這個設定, 根據 mozillaZine 上的說明, 這個設定在 MacOS X 上是 default True, 而在其他的系統上是 default False. 換句話說, 在我的系統上是預設會去作 IPv6 的 DNS Lookup.

但是這行為在台灣是無意義的, 因為目前台灣的 ISP 大多未更新到 IPv6 的系統 (或是讓 IPv6 與 IPv4 相容), 因此把這個選項設為 False 只會讓效能變慢而已.

在 Firefox 的網址列輸入 about:config 後, 找到 network.dns.disableIPv6 把它改為 True, 開啟頁面以及切換頁面就正常了 :)

International Computer Symposium 2010 上線

2010-05-31T10:41:00.005+08:00

International Computer Symposium 2010 悄悄上線了 (其實是我消息不靈通 XD), 沒想到今年是在成大舉辦, 雖然應該是不會投稿, 不過實驗室學弟有上就不用跑遠了.

雖然 NCS/ICS 很多實驗室都不太願意投, 不過怎麼說 NCS/ICS 也是台灣 CS 領域唯一資源最多的會議, 如果台灣想要擁有至少有點小名氣的自家國際會議, 在不去搶既有會議主辦權的情況下, 個人認為從 ICS 改造是最快的辦法.

所以基本上我覺得 ICS 好好辦還是挺重要的... 就看主掌的教授們怎麼想了.

不過目前的 Chairs 名單未免失衡地太嚴重, 感覺區域性太強. 扣掉掛名的教育部名單跟榮譽主席等等, 8 位 Chairs 全部都是成大的, 而 Workshop Chairs/Co-Charis, 共有 21 位左右, 其中成大佔了 5 位, 國外學者 4 位, 其他除了海洋大學 1 位之外, 全部都是南部的學校... 北部台清交中央全部絕緣... 這是怎樣 ?

筆記: AIO 觸控生活應用程式競賽

2010-05-29T15:14:00.068+08:00

由經濟部工業局主辦, 工研院執行的 AIO 觸控生活應用程式競賽告一段落, DBSE 實驗室的 SIMPLE Touch 最終是獲得第三名 (複賽共 19 隊晉級, 取第一名一隊, 第二名兩隊, 第三名三隊). 雖然頒獎典禮結束後的隔天有不少平面媒體報導, 但是受限於篇幅以及作品賣點問題, 只有 B+ 的蒼蠅王2 得到比較多的說明吧, 網路影片也多集中於各家廠商及經理的說話...

週末趁整理相關投影片分享給實驗室的機會, 把一些有看到的東西, 以參加者的角度也紀錄一下, 其中也包含一些自己的看法. 以下的影片是 SIMPLE Touch 的隊員趁四下無人亂動的, 所以很多操作其實不到位, 加減看就好 XD

1. 蒼蠅王2 (B+ Studio 作品)

蒼蠅王2 是 B+ Studio 先前作品蒼蠅王 Lord of Flies 的二代作. 第一代的作品在先前的微軟 Windows7 多點觸控程式設計大賽就拿下過第一名, 這次再得到首獎, 真是相當厲害.蒼蠅王2 的遊戲概念很簡單, 把自己的手當作蒼蠅拍來拍死蒼蠅 (不過是用手指, 用手掌可能 AIO 電腦會先垮), 以兩人競爭或過關的方式進行遊戲.作品的 Context 設定清楚, 完成度也極高, 美工很漂亮, 以我看到的參賽作品來說, 是兼具高吸引力以及高完成度的作品, 拿下首獎相當合理.

B+ Studio 目前的主要領導者是陳承佑先生, 也兼任 RD (事實上就我所知目前只有一位 RD), 工作室含美工及經理等等目前共只有 4 位人員. 另外值得一提的是決賽時第一次遇到陳承佑先生, 在準備室相當專心地一次又一次, 不厭其煩地反覆準備面試講稿, 相當認真的人 :) 因為我就沒辦法作到這樣, 特別有感觸~

另外強力推薦蒼蠅王的開發手冊, 當初決賽之前, 調查競爭對手時就很喜歡他們的手冊, 可以讓別人很容易理解蒼蠅王的創作脈絡, 是很好的展示及宣傳材料.

2. Digifish Dolphia (琦景科技)

琦景科技在決賽時所用的作品名稱是琦景科技數位魚, 很容易讓人聯想到先前流行的數位桌面水族館之類的東西, 不過現場看到其實不是那麼像玩具的東西.

Digifish Dolphia 是利用高強度的 3DVR 引擎為核心, 繪畫出全 3D 的動物生態 (參賽 Demo 是用海豚以及海底世界為主), 搭配 Multi-Touch 技術讓使用者利用手指動作, 例如轉換視角, 驅趕魚群, 呼叫海豚, 對海豚搔癢等等.

從琦景科技的展出內容來看, 其實我會有點懷疑琦景參賽的主要目的是得到曝光跟商談合作的機會, 特別是前三名可以獲得今年 ComputeX 參展的機會. 所以 Digifish Dolphia 比較像是琦景目前的技術結合 Multi-Touch 之後的一種技術展示, 而不是以一個完整使用情境的方式作包裝.

不過因為前兩名的展出場地在演講廳內, 跟第三名的場地分開, 加上琦景的參展人員看起來是經理級以上的業界前輩, 整場就我看到時幾乎都是跟商業人仕洽談, 完全沒機會講到話, 只有一開始跟陳恆大哥來看了一下我們的 Demo, 也就無從問起~

3. Kidd Touch Fun - 3D Blocks Learning Game (智品科技)

智品科技的網站需要安裝 Silverlight 才能看到, 不過我的 Mandriva 要看到比較麻煩...況且我也不太想裝...

智品的 3D Blocks Learning Game 主要概念就是虛擬化的積木系統, 把積木的物理特性 (主要是重心的移動與積木的堆疊) 設定在虛擬的積木上, 讓小朋友們利用 Multi-Touch 去移動或丟擲積木, 積木於是會與現實世界中的真實積木有一樣的行為. 我記得 Lego 幾年前好像有類似的計畫,但是後來決定還是先朝實體積木的電子化發展, 相關資料找不太到了.

相似的概念在前兩年 IEEE Software 有一篇 paper, 討論把玩具汽車的物理行為嵌入到虛擬玩具汽車中, 例如只要放到斜坡上就會自動下滑, 平地上就不會之類的.

# 2010-08-31 補充: 示範影片在 Youtube 上面有:

# 2010-10-09 補充, 另外一個形式的作品

智品的參展人員我從頭到尾都沒有認到 = = , 因為不是去聽演講就是同樣在展出時間, 完全沒機會講到話. 不過稍微玩了一下覺得積木的動作有點不太自然, 可能是為了迎合小孩子的反應跟操作, 所以刻意把積木的移動跟旋轉速度等等都調整的相當慢.

以上是前兩名的作品.

4. All Touch (AHC)

All Touch 的概念主要是嘗試協助傳統 Keyboard/Mouse 應用程式, 在無須更動或修改 User Interface 的情況下, 直接轉換到 Mutli-Touch 的環境. 可想而知 All Touch 就是一個 Adapter 的概念.

但是 All Touch 的解決方案事實上需要面對許多問題, 例如為了迎合所宣稱的 "任何應用程式", All Touch 本身就需要應付可能會相當複雜的操控方式, 而為了方便 All Touch 的使用者, All Touch 的使用者介面如何作到操作方便, 甚至提供編輯器. 再者, 傳統 Keyboard/Mouse 應用程式會想要過渡到 Multi-Touch 環境這件事, 可能是一個過於危險的假設. 到目前為止, 我還沒有看到大量的聲音認為 Multi-Touch 會取代 Keyboard/Mouse 的操作模式. 換句話說, 極有可能這兩種操作模式本身就是有著不同的使用市場, 這時其實傳統的應用程式未必會需要支援 Multi-Touch, 而要轉移的應用程式也未必會想省功夫而不重新設計 User Interface -- 畢竟為了省下 UI 成本而讓使用者操作不便絕對不是一個好決策.

All Touch 沒影片~ 因為拍攝時剛好陳恆大哥不在, 雖然看過一次但是還是沒法複製操作, 只好殘唸只放立牌照片.

代表 AHC Technology 參賽的陳恆大哥 (其實是大叔吧 XD) 是個超級活潑的人, 先前待在資策會, 也聽到一點小內幕, 是在會場跟我們講最多話的人之一, 感謝陳大哥讓我們稍微不緊張一點 :)

5. Smart eVision (聯銓資訊)

聯銓資訊長期來都專注在研發企業決策軟體, 據 VP 說, 已經投入 18 年了. 沒錯, 他們家副總有來 XD

產品本身的資訊在公司網站上就很很清楚了, 沒什麼好多說, 而此次參賽的版本主要是利用 Silverlight 開發介面, 搭配幾種操控的 Multi-Touch 指令, 使得介面的轉換可以在企業主進行 Presentation 時更加方便. 嚴格來說跟 Multi-Touch 的重要相關性不大就是了.

在展出前期跟聯銓的展出人員沒有說到太多話, 只有介紹跟 Demo SIMPLE Touch 給他們看而已. 不過後半的演講時間, 副總似乎跟我們一樣對演講內容沒什麼太大興趣, 在外面溜達, 有機會聊了一下, 特別是聯銓一路來的辛苦, 以及副總對於 Cloud Computing 被台灣企業接受的可能性分析, 收穫良多 :) 沒想到台灣跟美國的情況會差距這麼大

聯銓近來正式在美國設立據點, 總裁本身在美國督軍中, 預祝拓展順利~

其他

以上是除了 SIMPLE Touch 以外的前三名. 其他通過第二階段的隊伍中, 因為決賽時間錯開, 沒有太多機會看到. 有看到的是台大電機的 Electrical Automatic Handicraft, 基本上應該是電子陶藝模擬, 搭配 Multu-Touch 去作形塑的作品, 沒記錯的話應該是獲得佳作. 另外朝陽科技大學的阿公阿媽戰起來, 好像需要用到除了 Mutli-Touch AIO 以外的 Wireless AP, 不過很遺憾沒有機會詳細了解內容, 只是決賽時剛好是我們上一組, 感覺評審室裡面很熱鬧, 有演短劇的感覺 XD

第一次參賽對於很多事情的拿捏都不太有經驗, 包含進度掌控, 比賽進行的重點, 作品展示方法等等, 幸好有老師的指點, 以及先前 Cox 學長幫忙打下 SIMPLE Touch 的基礎, SIMPLE Touch 隊員, DBSE 以及 DCL 同仁的合作, 拿下第三名. 雖然不夠完美, 但總是個開始. 雖然很遺憾因為種種原因要放棄 ComputeX 2010 的展出機會, 但是相對來說其他的機會也正找上門來, SIMPLE Touch 還有很長很需要謹慎的路要走.

最後還是感謝工研院的執行人員, 退出 ComputeX 的展出勢必給你們帶來不小的麻煩, 希望工研院以及其他隊伍展出順利 :)

最後補一張頒獎人及得獎隊伍代表的合照, 左一我記得是智品代表 (記錯請見諒), 左二是 SIMPLE Touch 辛苦的首席解說員倩瑋, 左三是陳恆大哥, 左四是聯銓副總, 右四是琦景代表 (記錯請見諒), 身上有大大的 B+ 的自然是首獎代表陳承佑先生啦 ~ 早知道 SIMPLE Touch 也穿實驗室的紫衣去... 不過可能太搶眼就是了 XD 長官與各廠商經理課長等等請恕我忽略 ~

OpenFoundry Attack (三) Downloads versus Lifespan

2010-04-22T10:55:00.011+08:00

延續 OpenFoundry Attack (二) , 把 Project Downloads 與 Project Lifespan 來比對看看.

Project Lifespan 指的是一個 Project 自創造出來到目前為止 ( 2010-04-20 ) 的時間, 在此以天數 (Days) 作為計量單位.

由於在 OpenFoundry 中, Downloads 數量有顯著量級差距, 因此全部一起看反而看不出甚麼. 以下分為幾個不同的 Scales 來看.

首先是 Downloads 在 0 ~ 100 之間的 Projects. 在此不包含 Downloads 為 0 的 Projects, 在圖上會佔據 Y = 0 的軸線, 意義不大.

較明顯的是 Lifespan 在一年半到兩年之間的 Projects 比較集中一點, 這跟 OpenFoundry Attack (一) 中提到 2008 年 10 月前後的大量註冊 Projects 自然有相關. 但是從 Downloads 的角度來看, 其實並沒有特別的傾向, 算是還蠻平均的. 而從其他 Lifespan 的角度來看, 其實在 Downloads 的表現上也是很平均, 並沒有說 Lifespan 長的 Projects ( 也就是比較老的 Projects ) 就比較容易有高的 Downloads 數量.

事實上同樣的情況放到其他 Scales 也是類似.

底下是 Downloads 在 0 ~ 500 之間的 Projects 分佈. 請忽略左下角那團, 那在上圖中已經說明過了. 其他部份也是均勻分佈.

Downloads 在 0 ~ 1000 之間的 Projects 分佈.

Downloads 在 0 ~ 5000 之間的 Projects 分佈.

Downloads 在 0 ~ 10000 之間的 Projects 分佈.

Downloads 在 10000 以上的 Projects 數量相對少很多, 代表性低就不看了. 基本上結論是, 在 OpenFoundry 上, 目前看來 Lifespan 跟 Downloads 的關聯性並不高.

OpenFoundry Attack (二) Project Downloads

2010-04-21T07:26:00.025+08:00

接續前篇 OpenFoundry Attack (一) 的 Data Crawlng 設定, 對於 Project 績效最容易理解的指標 : Downloads 數量作統計, 數據如下表.

其中 Intervals 為下載數量間隔, 第一個 0 為特殊的間隔, 代表下載數量為 0 的計畫數量, 而的間隔為下載數量大於等於 1 次, 小於 50 次的意思, 其餘的間隔依此類推. 最後一個 50,000,000 ~ 的間隔代表下載數量在五千萬次以上的計畫數量.

Intervals	Downloads
0	695
1~ 50	133
50 ~ 100	60
100 ~ 500	132
500 ~ 1000	48
1000 ~ 5000	69
5000 ~ 10,000	18
10,000 ~ 50,000	23
50,000 ~ 100,000	6
100,000 ~ 500,000	12
500,000 ~ 1,000,000	2
1,000,000 ~ 5,000,000	1
5,000,000 ~ 10,000,000	1
10,000,000 ~ 50,000,000	0
50,000,000 ~	1

其中下載次數為 0 的計畫共有 695 個, 佔所有此調查中所查看計畫總數的 57.87 % , 而除此之外, 算是很正常地在 1 ~ 5000 次下載的計畫佔餘下的大多數.

換成長條圖可以比較容易看出比例差距. ( 圖中的 maximum 就是下載數量大於五千萬次 )

當然對於下此數量在五十萬次以上的少數 Projects 難免讓人好奇, 這些 Projects 分別是可攜應用程式套件中文化 ( 508,946 次 ), Wow! USB VirusKiller 可攜式儲存設備防毒軟體 ( 734,802 次 ), 新同文堂 ( 1,149,864 次 ), Wow! USB Protector 可攜式儲存設備防毒偵測 ( 8,389,615 次 ), 以及 PCMan 驚人的 104,258,467 次, 這數字即便在 Sourceforge.net 都很驚人. 另外兩個名列前茅的 USB 防毒相關計畫都是中研院同一個研發小組的成果, 所以計畫名稱基本上很類似.

另外隨手附上 Sourceforge.net 在 2006 年左右的圖表, 詳細蒐集日期不太確定, 應該是 9 or 10 月左右. 當時共觀察 58794 個 Projects, 其中下載數量為 0 的有 20751 個 Projects, 約佔 35.29 %

這兩個圖表中, 感覺 Downloads 在 500, 5000, 以及 50000 次似乎有形成三個門檻的趨勢. 不過還需要再觀察, 以及設法跟 Project Lifetime 作交叉比對就是.

OpenFoundry Attack (一) : Project Creation Statistics

2010-04-20T15:11:00.021+08:00

因為現在好像沒用 OpenFoundry 的話國科會計畫會比較難過了的樣子, 既然這樣就來研究一下.

不知道系列會寫多長, 也許到終於被禁止 crawling data 為止 ? 系列命名採自 Korea MBC Battle.net Attack -- 其實沒什麼意義, 純粹好玩又想不到要取甚麼.

資料蒐集日 : 2010-04-20

至資料蒐集日為止, OpenFoundry 上共有 1219 個專案, 但是專案編號事實上是從 1 ~ 1470, 換句話說其中有些專案已經因為某些原因被移除了 ( Deactivated ), 被移除的專案共有 241 個左右, 例如編號 14 的專案.

自然資料蒐集就只有針對活動中的 1219 個專案. 而同時由於未知的原因, 我的 Crawling Tool 只能抓下其中 1201 個專案的資料, 不過數量已經相當接近了, 因此餘下的 18 個就當作沒看到 ( 其實是懶得一個一個去找 XD )

把這 1201 個專案依照其 Creation Date ( 以 Month 為單位作收納 ) 來整理, 可以得到下面的分佈長條圖.

很自然地會注意到幾個特別的分佈. 由於 Blogger 的顯示限制, 點選上圖可以看到比較清楚的 X 軸年月份標籤.

其中在 2004 ~ 2006, 以 4 ~ 6 月為中心的 Project Creation 數目明顯比周圍的月份來的高, 2007 年整年相對普通, 而 2008 及 2009 年則是變成 9 ~ 10 月份有相對高檔, 特別是 2008 年 10 月份一舉超過單月 70 個新開設計畫.

基本上一年之中 1 ~ 3 月新計畫的開設量少是可以理解的, 因為剛過完新年, 接近農曆年, 然後馬上又是四月初的春假, 這三個月正好是減溫到加溫中. 不過其他月份在 2008 以及 2009 年的反差實在有點大就是了. 話說這兩年的 10 月究竟有甚麼特別的呢 ?

本來還想做一張 Creation Date 對上 Last File Update 的時間關係, 不過做到一半驚覺 OpenFoundry 有未來檔案的問題. 例如 Simple PHP Blog 正體中文與補強計畫的最新檔案日期是 2019-11-17, 另外也有 2030 年的, 這樣讓時間可靠性產生很大的問題, 所以還是摸摸鼻子算了.

How Matplotlib and NetworkX Work Together : A Case Study on Figure Instances

2010-04-14T23:17:00.020+08:00

最初是因為以下的 Code 讓我對這個問題有興趣. 這段簡單的程式碼 Matplotlib 以及 NetworkX 來合作畫圖. 其中 NetworkX 負責 Graph Model 的建立, 而 Matplotlib 則負責 Figure 繪圖的部份.

最後繪出的圖, 如同程式碼所指定的位置, 畫出三個圓點.

而我覺得程式碼有趣的地方在於, 細看程式碼, matplotlib.pyplot 只有在 line 6, 以及 line 20 被使用, 期間 line 9 到 line 18 都是 networkx 的運作.

而, 在此 Script 中, networkx 跟 matplotlib.pyplot 表面上是沒有任何互動的, 沒有任何 Message Passing 或是 Object Communication 出現. 如果單單依照此 Script 中的 Program Logic 作 Program Slicing, 或許就會被乾脆地切成兩個 Program Slices 了.

不過想當然爾, 既然最後可以順利地畫出圖來, 這兩部份的程式碼肯定在背後有進行某種 Communication, 否則不可能在 networkx 中建好 Graph Model, 在 matplotlib.pyplot 中就知道要畫出甚麼樣的 Figure.

經過漫長的 Code Tracing, 大致上可以把 Dependency Graph 整理如下圖 :

其中比較關鍵的是 Matplotlib 在 Figure Management 上, 允許同時間有數個 Figure Instances 存在, 而目前要畫在哪個 Figure Instance 上, 則視乎目前哪個 Figure 被設定為 Activated.

在 plt.figure() 中 ( 事實上為 matplotlib.pyplot.figure() ), 可以透過參數 num ( 可參考 Online Document, 即 Figure Instance Identity ) 指定要 activate 那一個 Figure Instance, 如果 Instance 不存在, 則會產生一個新的 Instance.

而在綠色的流程中 ( 即程式碼 line 9 到 line 18 ), networkx 在 nx.draw_networkx_nodes 進行中會透過 matplotlib.pylab.gca 取得目前為 Activated 的 Figure Instance 其 ax object ( 座標軸物件 ), 之後透過 ax 把要畫出來的 nodes 加進去.

最後 plt.show() 透過 matplotlib.backend_gtk 把圖畫出來.

這 Matplotlib 中的 Figure Instance 取用機制大體上是為什麼原本的 Code Script 中, 在乍看之下 networkx 跟 matplotlib.pyplot 沒有 Communication, 但是還是可以把圖畫出來的主要原因.

Consultant Community Service

2010-04-14T08:00:00.000+08:00

RWW Report : Get Quick Impressions of Your Latest Product Iteration with Concept Feedback

又是一個從一個極端到另外一個極端的權衡.

現在的 Web 環境, 讓我們可以很容易地, 無花費地把任何想法, 計畫, 設計, 產品, 介紹給任何人, 然後收取任何的多元意見. 缺點就是過程可能會極度沒有效率, 也沒有保證性的正面結果, ex. Yahoo Knowledge+

當然, 花錢找顧問公司則是完全相對的作法, 是最有效率, 也可以得到保證性結果的作法. 缺點是顧問費用是一定要給的, 即便結果你不是那麼滿意.

ConceptFeedback 取了個中間的位置, 透過 "仲介" 具備一定水準的 Consultant Community, 來給予付費的顧問服務. 這之間自然就會有許多付費模型可以選擇. ConceptFeedback 是允許使用者選取三個 Best Advices 來給予實質的 Money Reward. 不過想來應該會允許使用者提高或增加 Reward 的數量, 畢竟如果是有價值的產品, 利用 ConceptFeedback 作為一個蒐集意見的平台也是值得的. 另外 ConceptFeedback 應該也有一些防止 Cheating 的機制才是.

其實除了 Consultant 的實質功能之外, ConceptFeedback 整合了相當多過去的概念, 例如網路商業廣告 ( 還記得上一個網路泡沫之前, 滿天飛的 "邊上網看廣告邊賺錢" 嗎 ), 知識分享社群, 網路問卷調查服務, 網路拍賣平台 ( 管理與貨物提供者的責任分離 ) 等等.

但相對來說, 就跟網路拍賣平台一樣, 可能會面臨容易出現強力競爭者的情形. 不知道 ConceptFeedback 或是其他的競爭者, 要用甚麼樣的策略來勝出 ? 跟有實力的 Consultants 具體簽約 ? 或是在 Profiling 上有過人之處 ?

Online Web Service Monitoring based on Constraints from Requirements

2010-04-13T20:17:00.001+08:00

The idea behind Wang et al.'s paper "An Online Monitoring Approach for Web Service Requirements" [1] is simple and useful. The challenges their study faced is to ensure the behavior of Web services consistent with their requirements. To achieve that, a monitoring approach is taken. They built a monitoring model including five specific system event types. Further, a monitoring framework is also built to providing probes, agents, and analysis components based on the monitoring model. In short, this study contributes an external behavior monitoring approach to ensure the Web service behavior to be consistent with requirements.

Extended Questions and Remarks:

Is the same chanllenge ever discussed in conventional software development, ex. CBSD ?
What's the trade-off applying this approach in practice ? ( required extra human resource, development and maintenance effot, and so on )
Can some constraints mentioned in this study be validated using Web service testing tools in development phases ?
The security issues behind this approach : Who can be the administrator and What services can be monitored ?

References

[1] Q. Wang, J. Shao, F. Deng, Y. Liu, M. Li, J. Han, and H. Mei, "An Online Monitoring Approach for Web Service Requirements," IEEE Transactions on Service Computing, vol.2, no.4, pp.338-351, Oct./Dec. 2009

Operating NS3 with Python

2010-04-12T20:00:00.036+08:00

最近可能會要很奇怪地使用 NS2 來作一些 Simulation, 雖然還不是很確定需不需要使用, 最近趁空未雨綢繆一下.

但, 說真的 NS2 雖然大量地被 Network Research 人員使用, 也有很多已高度開發的模組, 但是一來我需要的使用方式其實不是模擬傳統的 Network, 二來不熟悉的大量程式碼真是看不下去. 所以其實我早早就把目標鎖定在 NS3.

NS3 的基本中文介紹在 morechr 的 blog 很早就寫了, 不過一年半來中文的資料也沒增加多少, 想來 NS2 就足夠現在的研究人員使用了吧, 況且 NS3 的重點擺在完全地利用 Script 來操控, 許多需要利用到 Pointer 的模組應該短時間內也很難轉移. NS3 架構概圖 ( 取自 NS3 Official Site ) :

但是對我來說, NS3 看起來似乎比 NS2 易用多了. 主要的操作介面已經提供 Python Binding, 也有實驗性的 PyViz 模組. 光是安裝時一個 $> python build.py 就感覺很爽快 : p

在 Tutorial 上, 我覺得 NS3 官方的 Tutorials 跟 Overview 投影片都很難讓我這初次接觸的人看懂, 倒是 G. Carneiro 的這份投影片(PDF 檔案) 我覺得做的不錯, 搭配 NS3 的 example/tutorial/first.py 程式碼, 一下子就可以了解個大概.

PyViz 模組最近的 ChangeLog 看的不是很明白, 照 changeset 5973 的訊息, 應該是已經 merge 到 NS 3.7.1 了才是. 但是實際下載 NS 3.7.1 看起來是沒有包含 PyViz 的, 所以或許他的意思是在 http://code.nsnam.org/gjc/ns-3.7-pyviz/ 底下 merge 了 NS 3.7.1 , 一番嘗試最後還是使用 Mercurial 複製了一份 http://code.nsnam.org/gjc/ns-3.7-pyviz/ 下來. ( 請跟 ns-allinone 分開 )

在 PyViz 的網站說明中, 提到要再跟最新的 NS3 作 merge 的動作. 不過因為 clone 下來的 ns-3.7-pyviz 已經被開發人員進行過 merge 了, 就不需要再做一次.

使用 PyViz 還需要額外安裝許多模組, 除了基本的 Graphviz 之外, 還有 PyViz 頁面中提到的 pygraphviz, kiwi ... 等等. Ubuntu 的使用者安裝似乎比較方便, 可憐的 Mandriva 使用者 ( 而且還是 MDV 2008 = = ) 就直接乖乖自己安裝吧.

其中

pygraphviz 可以利用 easy_install 從 pypi 安裝,
python-kiwi 直接從 Package Manager 找出來裝 ( 不要直接找 Kiwi 來裝, 不一樣的東西 <= 犯錯的笨蛋 ), python-kiwi / Kiwi framework 是連接 GTK+ 的套件
PyGoocanvas 也沒辦法從 pypi 安裝, 但是手動安裝要補充的套件太多, 相當麻煩, 最後我選擇從 MDV Package Manager 裝比較舊版本 0.9.0 的套件 ( 目前最新為 0.14 ), 反正這是 GTK+ 跟 GooCanvas 的 Binding Package, 從 Package Manager 裝可能還比較安全
python-gnome2 也是從 Package Manager 裝, 但是在 MDV 裡面似乎是叫做 gnome-python 套件
python-gnomedesktop 我猜測是等同於 MDV 裡的 gnome-python-desktop 套件
python-rsvg 在 MDV 底下真的找不到東西裝了, 猜測是裝在 pycairo 裡, 這之前透過 Package Manager 裝過了
最後記得到 pybindgen 抓取 1.14.0 版本 ( ns-3.7-pyviz 需求 ), 解壓縮到 ns-3.7-pyviz 底下

接著在 ns-3.7-pyviz 底下執行 :

$> ./waf configure --with-pybindgen=./pybindgen-1.14.0
$> ./waf --pyrun examples/flowmon/wifi-olsr-flowmon.py

首次執行因為要重新 build 整個 ns-3.7-pyviz 所以要跑一段時間. 最後還是出現幾個小問題,

缺少 libgraphviz.so.4 , 因為我的 MDV 2008 裡面只有裝 libgraphviz3 , 所以又更新了 libgraphviz4 .
找不到 gnomedesktop module, 此模組不知道為什麼被藏在 gnome-python-applet 套件裡, 同樣從 Package Manager 裝上

再重新跑一次:

$> ./waf --pyrun examples/flowmon/wifi-olsr-flowmon.py

這樣一番折騰 ( 所謂的 Dependency Hell 阿 ) 終於把 PyViz 跑起來了.

左下角有一個 Advanced 延伸調整選單可以展開, 右下角有 Snapshot, Shell, 以及 Simulate 命令. Snaphot 可以擷取目前截圖存成 PDF 檔案, Shell 可以開啟動態 Manipulation Command Line, 在 PyViz 的說明中有提到. Simulate 就是開始進行 Simulation 的命令.

以下是進行中的畫面, 懶得錄下來放到 Youtube, 截圖就好 XD

可以調整 Zoom 以及速度, 方便檢視 Simulation 可能出錯的地方.

初步的嘗試大概到此為止, 花了不少時間跟功夫, 不過至少有成功執行. 通常這樣的嘗試超過一半的機會最後是不了了之的 : p

Continuous Game Content Provision

2010-04-11T20:00:00.008+08:00

今天看到 Nintendo 跟 Google 合作的遊戲安藤ケンサク, 雖然看不太懂遊戲的進行方式, 但是從少量 blogs 跟 forums 的簡短說明, 大致上可以知道跟 Search Engine 的 Search Keywords 有關, 利用 Google 在 Search Engine 上所累積的統計資料來產生新型態的 Q/A 遊戲, 最大的特點是問題的答案可能會隨著時間改變 -- 因為 Google Search Engine 所累積的資料也在變動中.

緊接著又在 JustineTV 看到人家在玩暴雨殺機 ( Heavy Rain ), OMG, 我真的脫離新遊戲太久這遊戲的畫面真棒, 運鏡跟電影拍攝手法好像. 剛好看到玩家操縱的角色在房間裡探索, 看起來應該是遊戲初期, 中間有一度打開電視, 看到跟案件劇情相關的新聞報導, 然後把電視關掉.

這在一般追線索的解謎遊戲中常常看到類似的橋段, 但是今天我卻忍不住再想, 如果再打開電視一次會怎樣 ?

遊戲的 NPC 或裝置 ( 包含電視 ), 通常都是有固定集合的對話或是資料, 為了避免太死板, 又會循環或亂數出現這些對話. 但從安藤ケンサク的例子, 是否我們可以開始考慮跳脫這樣的限制, 讓遊戲更加跟已經有的 Online Data 作結合 ?

例如上面的開電視, 如果遊戲本身把該電視跟 Youtube 或其他 Onlive Vedio Service 作結合, 就可能在重開時看到其他的新聞, 這樣似乎也會很有趣 :)

Cloud Computing Bibliography for Software Engineering

2010-04-11T08:29:00.017+08:00

All bibliography articles were made available online before 2010-04-10.

This survey covers only representative Conferences and Journals in software engineering and cloud computing domain. All articles were retrieved by keyword "cloud computing". Surprisingly, literature directly related to "cloud computing" and "software engineering" is still rare.

J. Cappos et al. developed a cloud computing education environment "Seattle" [1][14] (Thanks to Ivan). ~~Unfortunately I did not find further information about "Seattle"~~. On the other hand, Eucalyptus is used in E. Caron et al. work [11]. Maybe Eucalyptus will be a good start for cloud computing practice for those who have no resources accessing Amazon S3/EC2, or limited by Google GAE.

E. M. Maximilien et al. [2][3] revealed a part of IBM's directions to the cloud computing. The idea to build cloud-agnostic middleware is definitely not new. Is not Hardware-Server-PHP-MySQL-PHPWebsite similar to this solution ? Of course the scale is totally different, but the middleware idea is basically the same.

Some considerable statement can be found in ACM roundtable series on cloud computing [6]. For example, G. Ramleth, CIO of Bechtel, said : "This is not a technology game but a change-management game."

L.-J. Zhang et al. tried to pull cloud computing back to connect with service-oriented computing / SOA [7]. Some other related work can be found in International Conference on Cloud Computing ( IEEEXplorer link here ).

Althoug the data service is one of the ealiest applications in service-oriented computing and cloud computing, there seems still much to do in this field [8][9]. Same as the study of cloud computing in the end user living environment [4][12]. Is that cloud computing the game of IT companies ? Or the users will be forced to involve in the cloud computing ? To this issue, A. Lenk et al. [13] organized the cloud stack and adds an extra layer : Human-as-a-Service (HuaaS) which is not general mentioned in other studies. Unfortunately, no further discussion is made.

Bibliography

[1] J. Cappos, I. Beschastnikh, A. Krishnamurthy, and T. Anderson, "Seattle: A Platform for Educational Cloud Computing," SIGCSE, pp.111-115, Mar. 2009

[2] E. M. Maximilien, A. Ranadahu, R. Engehausen, and L. C. Anderson, "Toward Cloud-Agnostic Middlewares," OOPSLA, pp.619-625, 2009

[3] E. M. Maximilien, A. Ranadahu, R. Engehausen, and L. C. Anderson, "IBM Altocumulus: Across-Cloud Middleware and Platform," OOPSLA, pp.805-806, 2009

[4] C. Ragusa, F. Longo, and A. Puliafito, "Experiencing with the Cloud over gLite," Proceedings of the 2009 ICSE Workshop on Software Engineering Challenges of Cloud Computing, pp.53-60, 2009

[5] J. S. Rellermeyer, M. Duller, and G. Alonso, "Engineering the Cloud from Software Modules," Proceedings of the 2009 ICSE Workshop on Software Engineering Challenges of Cloud Computing, pp.32-37, 2009

[6] M. Creeger, "CTO Roundtable: Cloud Computing," CACM, vol.52, no.8, pp.50-56, Aug. 2009

[7] L.-J. Zhang and Q. Zhou, "CCOA: Cloud Computing Open Architecture," ICWS, pp.607-616, 2009

[8] M. Vrable, S. Savage, and G. M. Voelker, "Cumulus: Filesystem Backup to the Cloud," ACM Transactions on Storage, vol.5, no.4, article 14, Dec. 2009

[9] R. Agrawal et al. "The Clarement Report on Database Research," CACM, vol.52, no.6, pp.56-65, June 2009

[11] E. Caron, F. Desprez, and D. Loureiro, "Cloud Computing Resource Management through a Grid Middleware: A Case Study with DIET and Eucalyptus", International Conference on Cloud Computing, pp.151-154, 2009

[12] K. Kumar and Y.-H. Lu, "Cloud Computing for Mobile Users: Can Offloading Computation Save Energy ?" IEEE Computer, preprint, Mar 2010

[13] A. Lenk, M. Klems, J. Nimis. S. Tai, and T. Sandholm, "What's Inside the Cloud ? An Architectural Map of the Cloud Landscape," Proceedings of the 2009 ICSE Workshop on Software Engineering Challenges of Cloud Computing, pp.23-31, 2009

[14] Seattle, https://seattle.cs.washington.edu/html/

CCE Posters

2010-04-10T13:37:00.008+08:00

大約兩個禮拜前我幫成大電通所做的兩張海報終於印好公開展示了 :)

這海報是要把成果展示給高中生看的 ( 話說為什麼要作這種事阿 = = ) 當初我申請入學的時候怎就沒有這等待遇... 現在既有交通車, 還有午餐點心, 還有教授解說...

Here's the original design of the two posters :

左邊黑色那張是用 SE4PP/SIMPLE 為主設計的 ( Head-First 風格 XD ), 右邊那張是林輝堂老師 NSDA 實驗室的天使之眼, 加上詹寶珠老師 SMILE 實驗室提供的部份計畫材料完成的. 其他 Lab. 沒提供材料就沒辦法摟~

本來覺得藍黃底色配色很普通有點擔心, 但是其實出來的效果還不錯.

左邊那張被實驗室的 DC 照醜了, 其實做出來的質感搭配木框很不錯, 右邊的漸層效果也很不錯, 唯一的缺點是 NSDA 的 Logo 可能因為輸出軟體跟 Inkscape 在解讀透明圖層上有點差異, 結果變成了色塊了, 不然那邊應該也是漸層的.

兩張一起照, 這張看起來好點 :

稍微看了一下其他組的, 覺得還是自己做的這兩張好, 其他很都多都只是貼圖跟文字資料, 還有只有精神標語的, 以及錯別字錯很大的 XD

海報製作除了 DBSE 實驗室自家材料以及兩個實驗室支援的材料, 純粹使用 Inkscape, GIMP, cwTeX 字體, OpenClipArt 素材加以修改, 十分感謝 :)

A Very Very Short CSCST 2010 Review

2010-04-10T06:00:00.000+08:00

前幾個禮拜, 3/27, 3/28 到圓山參加 CSCST 2010, 簡短作個紀錄. ( 聽說第一天 Prof. Jane 跟金仲達教授的 Panel 戰很大 -- 當然不是這兩位戰啦, 沒跟到真是可惜 : p )

因為時間還有我的新西裝修改不及等因素, 第一天只有到最後的 Cloud Computing Panel, 值得記下東西不多. 老師在 Cloud Computing Panel 的總結在 Lab. 會議就已經聽過了, 其他除了台大劉邦峰教授相當 "中肯" 的 "擔憂" 之外, 大多聽起來並無新意, 只是把就有的研究方向拉上 Cloud Computing, 除非有更深切的動機, 這樣作的意義其實不大.

第二天一早的 Software Technology for Green Environment Panel 也差不多, 主要提到的 Smart Traffic Control System, Algorithm Improvement, Multi-Core Processors, Cloud Computing 是都可以跟 Green Environment 扯上關係啦, 但是我個人覺得 Green Environment 不等於 Energy Saving 以及 Environment Protection, 而且應該跟日常生活更加緊密的結合才對. 舉例來說好了, 垃圾分類之所以難達成, 很大的原因是因為人都很懶, 丟在一起比較方便, 這也是事實. 現在垃圾分類的政策是要求使用者要分類, 也就是要改變原本大家都丟在一起的行為 ( Behavior ).

Rule 101 : DO NOT TRY TO CHANGE THE USER BAHAVIOR IN THE BEGINNING

為什麼就沒人想結合控制跟影像辨識, 在合理的花費下研究自動的垃圾分類機制. 或許機制無法完美, 但是清潔人員要花的功夫就更少, 這樣不是也不錯 ?

另外對岸一位女教授 ( 抱歉因為 Panelists 沒有在 Program 上列出名單, 當場記不得 ) 稍微提到 :

Will the environment protection and weather concern become the “new” non-functional requirement ( constraint ) ?

其實這兩種 "Forces" 一直都在 Requirement Engineering 中, 只是份量不重, 因此我認為更適切的問題是, 是否這兩種 "Forces" 會被更加嚴格地要求並在 Spec. 中變得更加重要 ? 不過這個話題在這樣的 Panel 自然只是一閃而過沒有被深入討論.

第二場的 Panel 主題是 Software Tool and Environments. 主持人是對岸的董淵教授.

董教授一開始的開場很有意思, 提到 Environments 的雙關性 ( 特地加了複數形 "s" ), 不過基本上整場 Panel 都只在討論 Programmer 所認知的 "Environment" 而已, 真是多虧了董教授一開始有意思的開場. 前半段討論的一些事項在我看來非常的瑣碎, 而且不如說更偏向 "Software Running Environment" 的討論, 直到清大的白曉穎教授提到工具的量與質, 還有是否我們需要如此多工具, 有如此多工具但是 Software Development Process 還是充滿了困難等問題時才有趣一些.

後面我自己的 Regular Presentation, 以及後來額外聽了一場 Presentation, 都覺得沒什麼特別可以提得, 有些甚至只是前幾年已經提過了的東西.

Game-based Competitive Learning

2010-04-09T22:04:00.001+08:00

News from GamePro : Game design professor beta tests a new grading system ( Prof. Lee Sheldon's project )

It's not a noval idea, but always an interesting practice.

我還記得唸大學時, 聽過成大資工的密碼學課程, 期末的 Final Project 是要各組設計一套 Public Key/Private Key 機制, 然後互相嘗試攻擊, 被攻破的組別會被扣除一定分數, 相對來說攻破其他組則會加一定分數, 當時就覺得這樣作很有趣. 類似的概念我最早接觸到應該是國小時看 MacGyver, 其中有一集是大學生各自設計獨特的門鎖, 也是要設法突破對方的設計. 我們 Lab. 也早在幾年前就開始嘗試 Game-based Programming Learning 給大一學生.

多元的上課跟訓練方式絕對是好事, 但是難免會受到設計品質跟評量標準一致性的限制. 但是話說回來, 出了學校, 哪裡還有一致的評量標準呢...

不過換個角度來想, 如果不要把眼光侷限在傳統學校內, 而是放到更加專業的公司訓練課程, 或許很有發展空間. 許多公司的工作其實充滿大量的 routine work, 有遠見的老闆會設法保持員工的活力, 如果有專門的課程訓練公司, 可以為不同種類的公司及團體設計特殊, 有趣的學習課程, 而不是像目前許多應付了事的電腦職訓課程, 或許意外地有商機 ?

Johnny Mnemonic Again

2010-04-09T11:49:00.005+08:00

看到這個 Do Crew (RWW 連結) , 一定要再提一次經典的 Johnny Mnemonic 啊. 當初基諾李維的操控, 過了 15 年之後, 連小孩子用的設備跟效果都比當初好了.

Johnny Mnemonic 跟珊卓布拉克的 The Net 是個人認為好萊塢早期引入具體的電腦科技想像, 最重要的兩個嘗試, 雖然兩部片評價都很低, 也讓在 Speed 中紅起來的兩人各自迎接第一個低潮期...

Platform Selection in System Analysis - About Apple's Policy

2010-04-09T08:57:00.007+08:00

Mashable news article : "The Apple-Adobe War Escalates: Using Flash to Build iPhone Apps Banned" brings me an interesting thought.

在 System Analysis 或決定 Software Features 的時期, Platform 的選擇一直是一個很重要的考量因素 ( Factor ). 不過在一般的系統中, Platform 往往被過份忽略 -- 因為我們主要的選擇就是那些, 同時看起來對後面的 Software Development Phases 很少有極具限制性的影響. 大部分時候, 似乎主要的限制都是還來自於問題本身 ( 例如 Embedded Systems 中的資源限制, 可用背景函數限制 ), 而不是受限於 Platform 的選擇.

而在 Windows / Linux ... 層級的作業系統 Platform 選擇上, 真正會影響到一般 Apps 開發的因素就又更少了. 於是我們在 Software Development Phases 有很高的自由度去決定其他的事情, 例如可用的 Framework, API, Programming Languages, Compilers 等等.

但是 Apple 的限制提供了一個反向思考, 是否我們真的一定需要有如此高的自由度 ? 限制越多, 是否 Software Development Process 可以越簡單 ? 以及選擇 Platform 在開發限制上的影響對比更重要的商業利益, 是否的確微不足道 ?

增加延伸分析連結, 2010-04-11 : http://daringfireball.net/2010/04/why_apple_changed_section_331

Online Game that Requires Specialists...

2010-04-08T15:15:00.008+08:00

昨晚在看 Caprica 時, 想到一個很有趣的對比.

Caprica 是 Battlestar Galactica 的前傳, 講述複製人 ( Cylon ) 的誕生以及疑似毀滅 12 Colonies 的計畫起源. 不過這劇情在此無關緊要. 在 Caprica 中, 女主角 Zoe 的父親 Daniel 所開設的公司透過 AI 以及全息影像技術, 發明了 "Holo-Bands", 類似眼鏡的裝置, 不過戴上時要閉起眼睛, 透過該裝置給予眼睛的刺激來讓使用者置身虛擬世界 ( VR ). 我覺得這篇 Singularity Hub 上的簡介寫的不錯, 不需要知道劇情, 只要對目前的相關技術略知一二即可對照.

有這樣的技術跟裝置, 當然衍生出很複雜的虛擬遊戲世界. 但是不同於目前的 Online Game, 在 Caprica 中的虛擬世界是很嚴峻的, 你在每一個虛擬世界中死亡的話, 將永遠不能再次進入該虛擬世界, 因此真人跟自己的 "Avatar" 是 One-to-One 的對比.

而在這樣的設定下, 當你必須在該遊戲中達成某項任務或是目的時, 非常有可能是你一個新加入的人作不到的 ( 例如要在充滿黑幫的市區中找尋特定角色, 同時該市區還不斷地被飛空艇轟炸 = = ). 而遊戲本身也不會給予你的 Avatar 任何特殊技能 -- 說穿了你的 Avatar 跟本人在一開始的能力是完全一樣的.

因此在 Eposide 106/107 的劇情中, 某劇中角色就需要在遊戲中僱用類似傭兵/領路人的角色 ( 也是真實世界中的某人 ), 然後付費給真實世界中的玩家, 來完成找人的任務.

這樣的模式跟目前 Online Game 會有上班族花錢請人練角色等級看起來很像, 但是這兩種遊戲在設計本質上有極大的差別. ( 當然, 兩者所預設面對的 "Problems/Requirements" 其實也是不一樣的 )

在一般的遊戲設計中, Challenge Levels 的規劃是一項很重要的議題, 通常會避免只有單一的 Challenge Level ( 遊戲極簡單或是極難的情況 ). 當然這也是要視情況而定, 例如很多小遊戲本來就只想你花幾分鐘玩完就算了, 達到宣傳或其他效果就好, 這樣的 Challenge Level 就單一且極低. 但是 Caprica 中的遊戲, 其 Challenge Level 在我看來是極高的, 在那樣的世界中, 單獨一個人的生存率極低, 而依靠已經成功在該世界中生存下來的專家 ( Specialists ) 才會有比較高的存活率.

這樣的 Game 在現在的 Online Game 觀念中應該很難賣, 也不可能被做出來賣吧 ( 想像你在 Diablo II 中的角色, 死亡一次就掰掰要整個從新世界玩起... ), 但對某些人來說卻是刺激度滿點的遊戲, 同時這時候遊戲中的合作嚴謹度也可能會完全不一樣.

這樣, 才是真的靠玩遊戲當作職業賺錢吧, Specialists 死亡一次就失業了 XD

Paper Bad Smell Detection (2)

2010-04-07T17:57:00.012+08:00

OMG, 我居然回了自己兩年前的文章 ( Paper Bad Smell Detection, 2008/03/23 ). 話說當初寫的時候以為很快就會做看看了, 結果是最近接連寫投 SEKE 2010 以及 ICSEA 2010 的 Papers 時才驚覺沒這 Tool 不行, 我寫 Paper 很粗心, 邏輯上問題不大但是就是很容易犯一些 Bad Smells.

事實上如果以 English Grammer Check 之類的關鍵字去找, 可以找到許多 Online Services, 但是一來這些 Services 大多沒有提供 Web API, 二來用這些 Services 檢查 Paper 內容難免會有高度的 Security 問題 ( 不過這個問題很有意思... ), 因此在這些考量下就先被我打槍了, 稍後再試試看.

另外在 PC 上用的工具目前試過了老牌的 Diction & Style, 真是有趣的工具, 更加佩服以前的 Unixers 了, 為什麼以前都沒發現這工具呢 ?

不過這類工具基本上還是 Tools for General Purposes, 屬於一般性的檢查, 對於科技論文內容, 或是為領域特定的撰寫風格做調整還是有一定困難. (總之我就是想寫寫看啦~)

總而言之, 最後還是利用 Python 寫了一個簡單的 Tool. 這 Tool 的雛形事實上在去年的 First DBSE Hack Day 被我提出來做, 但是大家七手八腳結果是沒做完, 餘下的 Code 可利用性也不高, 所幸 Dynamic Rule Instantiation 的部分可用, 省下我一些功夫. 從這次經驗再次驗證 (1) Documentation 不可少, (2) 不要在 Prototyping 時要求完美.

完成的 Tool 其實只是很簡單的把 Abstract 跟各個 Sections 的內容抓出來而已, 輔以 Regular Expression 檢查區分正常的文字內容跟圖表, 我連句子中的 Tags 都不額外處理了. 再利用 Regular Expression 來制訂一些 Bad Smells 會出現的情況, 最後簡單的把結果輸出成 HTML Table, It's Done !!

目前可以檢查 ( All are Customizable ) :

Long Sentences
Vague Words
Countable/Uncontable Words
Similair Words
Verb Auxiliary + V-ed Violation

雖然功能還有待加強啦, 而且準確率也有問題, 不過本來這些 Bad Smells 幾乎都是作者需要自行確認是否屬實的, 況且改 Papers 時是寧可錯看 100 個 False Alarms 也不願意漏掉任何一個 Fault ( 安慰自己 XD )

拿來驗證之前被老師批改的 Paper 初稿們, 的確可以抓出不少被老師訂正的地方 :)

Dynamic IEEEXplorer Online Limitation ?

2010-04-07T11:18:00.001+08:00

當你 24 hours 都有機會使用 IEEEXplorer 時, 就會察覺某些特定的時間, "All Seats were Occupied !!"

這些時間包含了正常工作日的下午 1 ~ 4 點, 晚上的 10 ~ 凌晨 02 點 (偶爾, 打完電動該查個 paper 了是吧). 以及禮拜天晚上, 禮拜一早上 (要趕 survey 給老闆交代是吧). 遇到這些時段受人數限制連不上當然就很討厭.

當然 IEEEXplorer 要付費限制上線人數絕對有道理, 目前成大買的是同時間 15 seats, 但是考量沒有正常 logout 導致的 penalty (很多人習慣不好阿), 真實的 availability 應該是會小於 15 seats 應該有的效果.

但是如果我們以 IEEEXplorer 的伺服器總負荷量以及總頻寬量, 以及全球服務的角度來看的話, 其實不同國家的研究人員使用 IEEEXplorer 的頻繁時段是不一樣的, 像是台灣的深夜幾乎不可能遇到 all seats occupied 的情況. 不同時區顯然使用曲線不同. 是否 IEEEXplorer 應該在同樣的費用下, 採用動態調整, 讓使用效益最佳化 ?

After You Re-Install the SCIM...

2010-04-03T21:26:00.002+08:00

上週去參加 CSCST 2010 前夕, 我那本來就有點不太聽話的 SCIM 正式掛點了. 原因不詳, 總是當初隨 Mandriva 2007 裝的 SCIM 1.0 很容易在快速切換 Apps. 以及輸入法時陷入短暫 Idle 的狀態, 特別是當 Firefox 參與其中時...

索性移除所有 SCIM 相關 Packages, 整個重裝, 不過結果是只要進 KDE 所有 Apps 都開不起來, 會被 SCIM 或是 SCIM-Bridge 暴衝卡住 CPU, 就算砍掉 SCIM processes 還是會再跑起來. 直到現在我還是搞不懂為什麼 Apps 跑起來的時候都要先跑 SCIM 或 SCIM-Bridge ?

不過參加會議在即, 就先不管他, 直到回來又花了一天才修好. SCIM 跟 SCIM-Bridge 的選擇姑且不提, 在安裝新酷音 chewing 時, 又遇到裝上了, 卻無法開啟 SCIM-setup 來調整的情況, 當然也就無法使用 chewing. 倒是其他的輸入法就沒這問題.

總之, 後來發現 SCIM 重裝跟 chewing 重裝都注意把 .scim 跟 .chewing 先移除或是清空, 否則就出現上面奇怪的情況.

是否利用 Package Manager 移除 Package 時, 應該更 "Smart" 地主動考量 Configurations 一併移除的問題呢 ?

The Importance of Vision

2009-11-18T18:16:00.002+08:00

昨天在掃 CACM Nov. 的文章, 看到 Scratch : Programming for All, 複雜的心理又出現了.

高興的是, 當初 SIMPLE 跟今年龍騰微笑競賽落敗的 Idea, 我們所努力的方向, 跟 MIT 頂尖人員所想的是如此一致; 失落的是, 我們總是做得如此慢, 表達得如此不清楚.

看著手上還在跟同仁討論中的兩個 Idea, 驚覺 Vision 竟是比想像中更加重要的東西.

不是因為 Vision Document 可以為產品的開發帶來清楚的輪廓, 而是我們能夠把自己想法描述得多清楚, 我們的 Vision 有多吸引自己 ?

沒有共同的 Vision, 討論再多也是在兜圈子, 不然就是在教跟學.

沒有吸引人吸引自己的 Vision, 做出來要花雙倍的力氣賣出去.

Discussion your Vision Early, Refine your Vison Often !!

Analysis, Design and Implementation

2009-11-17T15:18:00.002+08:00

Software Analysis => 通盤了解情況
Software Design => 找出選項, 分析選項, 做出選擇
Software Implementation => 實現選擇

USB keyboard light

2009-05-02T02:57:00.001+08:00

Engadnet : Mr. Brightside USB keyboard light illuminates your keys, taste in music

最近兩三年圍繞在 USB 上建立 Notebook / Handheld PC / PC 用的許多小部品忽然熱門起來 XD

從單純的裝飾用部品, 到實際上沒人會真的去用的煮咖啡裝置, 還有像是這種實用的 USB 小檯燈都有.

不過這些應用似乎都還是非常低階, 甚至可以說這些部品都是以 USB 當作電源的 "機械部品", 甚麼時候會出現真正的 "電腦部品" 呢 ?

Ultra Motor A2B electric bike

2009-05-02T02:28:00.002+08:00

Engadget 的報導 : Engadget's delightful cruise on the Ultra Motor A2B electric bike

人力/動力複合車似乎越來越會是一種趨勢, 雖然說馬力不如一般的機車, 但問題是, 我們還有多需要一般的機車 ?

時代在改變, 只要附得起運送費用, 待在家裡等待上網採購訂購的東西送上門來的情形逐漸變得平常, 偶爾想出門附近走走才會需要輕量交通工具, 出遠門則是大眾運輸 + 汽車, 似乎一般機車的攻擊範圍逐漸淡出大部分人的實體生活圈, 再加上未來石油資源只會更貴, 但是靠自己的身體是健康又不用多花錢的 :p

就如同 EeePC 類型的電腦開發及攻下它的市場, 類似上面的 A2B Electric Bike 也許也能詢一樣的模式成功 ?

在 Compiz 下讓 SMplayer (MPlayer) 能播 RMVB 的簡易方法

2008-09-21T11:20:00.004+08:00

不知道為什麼我的 Mandriva 2008.0 在 Compiz 啟動模式下, RealPlayer 沒辦法正常地播放 RMVB 檔案, 會出現以下的錯誤, 但是關閉 Compiz 模式就沒有問題.

The program 'realplay.bin' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadAlloc (insufficient resources for operation)'.
(Details: serial 37 error_code 11 request_code 141 minor_code 19)
(Note to programmers: normally, X errors are reported asynchronously;
that is, you will receive the error a while after causing it.
To debug your program, run it with the --sync command line
option to change this behavior. You can then get a meaningful
backtrace from your debugger if you break on the gdk_x_error() function.)

之前嘗試換不同版本的 Real Player 也無解, 找額外的 MPlayer Codec 安裝也不太順利, 最終在 MacBlog3 發現了一個超級簡易的方法 : 直接把 Real Player 底下的 /codec/* 複製到 /usr/lib/win32 (如不存在請自行建立) 底下就可以了.

不過由於是 share library, 因此不用複製的, 直接利用 link 從 /usr/lib/win32 連結到 /codec/* 應該也可以, 這樣以後更新 Real Player時就可以順便更新 MPlayer 用的 library.

Pixnet 高招阿

2008-09-20T15:29:00.003+08:00

剛剛看到別人在討論 Pixnet 可以打的小狐狸, 覺得這真是高招阿.

如果點選看誠意...

就可以打小狐狸巴掌...

受傷了...不過如果不滿意還是可以繼續打 XD

前一陣子的新後台造成服務出大問題的事件, 其實直到現在也還沒完全解決, 但是看來大部分的問題似乎都已經解決, 但是很難補回來的是使用者的信心. 這隻小狐狸巧妙的把不滿轉成博君一笑, 在這個重建使用者信心的關鍵時刻, 我覺得真是高招阿 @@ , 記得以前在哪裡也有看過, 要偷學起來 :p

大學網路排名 : 不知道是評比的人有問題, 還是解讀的人有問題 ?

2008-09-19T14:50:00.016+08:00

前幾天老師提到 (其實是批到 XD ) 的西班牙做的大學網路排名被我找到相關報導了 : 大學排名的另類思考─西班牙世界大學網路排名, 然後這裡有 2008 年版的 : 2008年新版「世界大學網路排名」三項重要變動與創新.

我本來以為是什麼新的, 原來跟我年初看到的一樣, 當時看到台大的成績我就想糟了, 系上一定會想跟台大比, 這樣我系網頁就累了, 沒想到現在才有反應 :p

採用的三項指標 : 規模 (Size)、能見度 (Visibility) 及學術論文 ( Rich Files ) 有點值得討論. 在規模上, 稍有邏輯的一般人也會質疑, 量多就是好嗎 ? 能見度我倒沒有甚麼太大的意見, 基本精神就跟 Page Ranking 一樣吧. 而 Rich Files 的部份, 我倒很好奇他怎樣評比 Files 的內容, 特別是有語言的問題存在. 更別說, 只用這三項指標去評比大學網站本身就有很大的問題, 這種 Ranking 只能夠提供部份面向的量測跟解讀而已, 並不適合只看最終的 Ranking 就來比較.

不過聽說我們的所務會議結論就是, 成大怎麼能輸中山, 以後不管什麼東西, 能作成 Files 的就盡量上傳到網路上, 然後各種活動包含老師跟學生 Meeting 盡量有照片放到網路上, 務求增加網路上的檔案數以及網頁, 照片影片數量. ( 難道最近系辦卯起來發一堆跟電機系師生相關度不大的公告要我登上系網頁也跟這有關 !? )

老師很無奈, 開完笑地叫我們記得把以前所有的 Group Meeting 時 paper presentation 投影片不要弄丟, 都丟上去好了, 還有無關緊要的計畫資料, 反正也不是沒東西可丟 :p

不知道是評比的人有問題, 還是解讀的人有問題 ?

惡臭夜襲府城...

2008-09-19T14:50:00.006+08:00

話說當天我倒是沒有聞到甚麼怪味就是了. 節錄自自由電子報的新聞稿 "惡臭夜襲府城瀰漫2/3市區" :

〔記者黃文鍠／台南報導〕惡臭襲府城！台南市區昨天凌晨空氣中瀰漫惡臭，涵蓋安南區、北區、安平區、中西區及南區，影響範圍超過2/3市區，110及119報案台接到不少投訴電話，市警局及消防局動員近百名警消搜尋逾兩小時仍一無所獲。

這時候如果有部署好的 Smell Sensors, 搭配各種 Weather Sensors, 應該可以利用既定的演算法來推算出最可能的問題發生區域 ( ~ Charlie Eppes 的唬人數學秀上演 ), 可以大幅降低所需要的時間.

擴大內需的錢應該拿來建這種系統才對, 幾年前就聽過美國學者相關的 Talk, 系統應該已經成熟了才是, 這才是十分重要的城市及工業區基礎安全設施阿. ( 上面的圖示亂畫的啦, 拿自己家裏開玩笑摟 :p )

意外的發現

2008-09-17T08:30:00.003+08:00

在回學長信件的時候, 看到不熟悉的字 "Pedagogical Issues", 特意去查了一下, 結果在其中一個搜尋到的頁面看到意外的東西.

這跟圖樣的 design 跟成大圖書館新的網頁設計感覺上好像阿~~

成大圖書館新網頁的設計第一次看到覺得很怪, 不過看久了覺得還蠻特別的, 難到這種設計跟圖樣在教育界有特殊的意義 ?

There's Plenty of Room at the Bottom

2008-09-01T14:16:00.021+08:00

在 Numb3rs , Season 3, Episode 7 : Blackout (不知道為甚官方網站沒有這一集的 Recap ) 中後段, Fleinhardt 提到了費曼 ( Richard Feynman ) 的一場演說 : There's Plenty of Room at the Bottom ( 原文, 中文 ).

在費曼的原文中其實跟物理學淵源比較深, 但是 Fleinhardt 在劇中的解讀卻很有意思.

Fleinhardt : Well, what I mean to say is... you see,all along you've been applying
a kind of bottom-up analysis.
Fleinhardt : It all started with the unfortunate gentleman who was electrocuted.
Reeves : Alejandro Munoz.
Fleinhardt : That's right,and then you worked your way up to Donahue
Fleinhardt : And now you're working up to someone above Donahue.
Reeves : That's standard procedure. We're always looking for the bigger fish.
Fleinhardt : Yeah,but how you know you're even fishing in the right direction ?
Fleinhardt : You see, in 1959, Richard Feynman gave a very famous lecture.
Fleinhardt : It was called,"there's plenty of room at the bottom," and it altered the thinking of a whole generation of scientists
Fleinhardt : Because it changed their focus to thinking smaller and smaller instead of larger.
Fleinhardt : Now,see,you've gone from Munoz to Donahue, and now you're long even farther up the chain.
Fleinhardt : Perhaps you need to go in the opposite direction.
Reeves : You're suggesting that the plan to blow up the substation just started with Munoz.
Fleinhardt : I think it's worthy of consideration.

我覺得也很適用於軟體工程中的研究. 很容易地我們在書上, Paper 上會看到貌似很了不起的 Process, Theory, Architecture, 或是 Tool, System, 但是沒有仔細深入想卻很難回答一些極為基本的問題 : 為什麼 Paper 作者會想到解決這個問題 ? 這個問題會在哪裡出現, Paper 作者怎們知道這是一般性的問題 ? 我會不會遇到這個問題 ?

我覺得我直到博二才認識到, 一切從小地方做起想起. 很多 Paper 所真正解決的問題, 都起源於作者在實際作 Software Production 的過程中所遇到的小問題 ( 也有可能是大問題啦, 但是通常大問題就是一堆小問題 ), 而小問題總是在不同的 Software Production 中會反複出現.

好的研究題目其實就在你每天寫 Software 的思考過程中而已.

音樂情緒研究問卷

2008-08-31T07:15:00.000+08:00

偶然看到台大電信所的研究生在 PTT 徵求進行音樂情緒問卷, 因為對 yihsuan ( Perosnal Blog, 但是很少更新) 這個名字有點印象(後來發現他是 [1] 的首位作者, 之前實驗室有同仁報過這篇 paper, 難怪有點印象), 加上之前實驗室也有同仁在做音樂情緒相關研究, 就特意點進去看看.

問卷網站有點慢, 同時是 IE Only, 我還特地開 Virtual Box 來連 = =

問卷分成幾個大部分, 首先是 Introduction 進行一般音樂情緒說明,

不太確定分類是如何決定的, 但是根據之前聽過數次同仁的 presentation, 猜想應該跟 R. E. Thayer 的 AV Emotion Plane [2] 有相關.

第一階段是直接用聽的請 Visitor 給分數, 很單純的從悲傷到開心的分數. 至於分數怎樣對應到 AV Emotion Plane 就不知道了.

第二階段使用了一個 Tournament 來讓使用者從不同音樂的比較中給予相對的情緒關係分數 ( 比對本身可以算是一種分數 ).

這個手法感覺比較有意思, 跟男女糾察隊 London Hearts 的節目中使用的臉蛋好壞球 (顔面どストライク) 很像, 之前在看 Paper [1] 時我也有想過把臉蛋好壞球搬到 Music 領域來玩玩看 :p

底下來個上戶彩的作參考 (取用自這裡 -- Orz 有沒有這麼巧, 隨便找一下連到的居然是緯來當家美女主播的 Vlog ) :

最後一個階段則是對於使用者標示音樂情緒的一般性調查, 不過我覺得裡面出乎我意料地缺少相當多對於使用者 Context 的調查, 換句話說上面的音樂情緒標定是無法根據使用者的個人背景以及目前的情緒, 環境工作等等作進一步解析的. 這對 Data 的 Reliability 我認為是一種傷害, 特別是 Music Emotion 這種在判定時會受到相當多 Factors 影響的東西.

其實我對於音樂情緒一直不太相信, 最主要的原因即在於 Emotion 這種東西的判定 Variation 太大, 而音樂的創作又跟相當多的 Factors 有關, 有時候創作者是因為環境, 有時候是因為故事, 有時候是因為其他的音樂, 不確定加上不確定實在沒辦法讓我相信會變成一個確定. 而 Emotion 的 Variation 太大也導致多數的 Researches 都停留在諸如 Kate Hevner [4] 的八個分類, 或是 [1] 使用的 AV Emotion Plane 上, 但是這麼粗的分類感覺實在不實用.

另外就是音樂情緒的應用, 實驗室的學弟做的 [3] 是跟 Music Therapy 有關, 在 Therapy 上音樂可能有用這個我就相信, 但是很多 Papers 都會提到利用音樂情緒對於大量的音樂作自動分類判定 -- OK, 我相信可以自動分類, 但是為什麼我們要自動利用音樂情緒分類大量音樂 ? 到底誰會是使用者, 誰需要對於大量音樂進行音樂情緒的自動分類 ? 這個問題我一直想不透阿, 也許這也跟我本身有關, 我會留著的音樂大多是自己聽過喜歡的, 但是卻不會刻意去區分所謂的音樂情緒.

我想, 如果同樣的問卷是詢問使用該音樂的情境, 應該會比較有用吧, 很多時候我們想找音樂是希望配合目前的 Context 來用, 雖然說也可以透過情緒的轉換去作 Matching, 但是為什麼要如此麻煩呢 ?

P.S. 在閱讀 [1] 時我覺得其實內容很 Tricky, 主要是在 Data Collection 的地方做了大量的 Assumptions, 這讓我很不舒服 (Feel Uncomfortable), 另外歌詞的影響也被計量在內, 作為 Music 的一部分, 雖然說得通, 但是就讓我很不舒服, 對於我個人來說, 當你聽的懂歌詞時, 往往歌詞的影響力跟 Music 本身會不相上下, 這樣一來究竟你是在辨認 Music Emotion 或是 Lyric Emotion 就很難說了.

References

[1] Y.-H. Yang, Y.-C. Lin, Y.-F Su, and H.-H. Chen, “A Regression Approach to Music Emotion Recognition,” IEEE Transactions on Audio, Speech, and Language Processing, vol. 16, no. 2, pp. 448-457, Feb. 2008.

[2] R. E. Thayer, The Biopsychology of Mood and Arousal, New York Oxford University Press, 1989

[3] Yin-Kai Wu, Discovering Musical Features for Automatic Emotion Classification in Music Therapy, Master Dissertation, NCKU, 2008

[4] Kate Hevner, Experimental Studies of the Elements of Expression in Music, American Journal of Psychology, Vol. 48, pp. 246-268.

Manage Correlated Data Across Services ?

2008-08-30T10:15:00.015+08:00

利用不同的 Services 來存放不同的 Data, 然後在一個統一的 Blog 展示是目前 BSP 系統的標準設計模式. 然而 BSP 對於整體 Data 的管理策略可能還有值得討論的地方.

以無名的例子來說, 進行 Blogging 的使用者可能同時利用他的網路相簿跟網路影音服務, 但基本上該兩項服務的 Data 跟 Blog 本身是分開的, 只是在 Blog 上提供可以存取該 Data 的介面. 有時候使用者如果因為特殊原因要暫時關閉該 Blog, 原則上相關的 Data 應該也無法取得才對.

例如無名的 tiger302 這個 Blog, 因為某些理由被使用者關閉, 因此相關的相簿影音等資料也無法取得. 但是如果你從無名影音進行搜尋的話, 事實上還是找的到相關的 Index, 只是連結進去後一樣是無法讀取.

然而, 雖然無法透過尋常的 Blog 或是搜尋介面看到影片資料, 如果有心人在 Blog 開放時留下影片連結的話, 居然是可以直接看到理應被禁止存取的影片 Data, 例如同樣是 tiger302 上傳的這隻影片 :

顯然地, 無名是利用禁止某些 Service 被執行, 來達到禁止 Data 被取得, 但是這樣作就會產生上面的這種漏網之魚 -- 也就是某些公開的 Service 還是可以取得該資料.

同樣的情況在其他的 BSP 上也可能出現, 如果 BSP 沒辦法讓使用者把相關的資料都綁在一起作管理的話, 就可能出現文章被禁止存取了, 圖片跟相關影片卻還是可以被取得的情況. 然而, 以使用者的角度來說, 文章就包含了圖片跟影片, 而非只有文字而已. 因此相關 Data 都應該被禁止存取.

在無名的例子中對於此問題還算好解決, 只要 BSP 願意多花點心思調整一下 Data Model 或是 Access Model, 提供給使用者在發表文章時作選擇即可. 然而當這個問題是跨服務 (Across Services) 時就會複雜許多.

在幾年前的台灣 BBS 也存在類似的問題. 當時全台灣大大小小的 BBS 可能有上千個, 透過 Mailing List 原本的機制, 彼此轉信變成一種風潮. 但是轉信的看板之間卻出現一種問題, 當有使用者錯發文章, 或是不恰當的文章要被刪除時, 只有原本的發信站做了刪除, 其他收信站還需要該站或看板的管理者再做一次判斷. 造成垃圾文章需要花費大量的人力管理刪除. 後來的 BBS 發展出 control.cancel 協定, 只要支援該協定, 可以透過轉信機制自動刪除在發信站已被刪除的垃圾文章.

但這要在不同的 Services 之間, 支援共同的 Protocol 似乎難度大的許多, 況且允許的動作也不是簡單的刪除而已.

Pixnet 出包的第七天

2008-08-27T09:14:00.015+08:00

從 8/19 晚上 Pixnet 停機更換新架構, 進行資料轉移, 預計 8/20 重新上線, 但因為資料轉移所需時間預估錯誤, 因此僅部份功能可以使用, 直到 8/21 仍舊一片混亂, 管理後台無法正常使用, 文章編輯有問題, 無法進行迴嚮, 部份資料疑似遺失, 使用者的部份草稿文章會被公佈 ( 這點我覺得很嚴重 ), 還有其他一堆問題等等.

iThome 也進行了相關的報導 : Pixnet 改版出包恐重演無名用戶出走潮 .

Ptt Blog 版發起的回報活動, 可以看到究竟已被發現了多少 Bugs :

如此多的問題, 讓人懷疑究竟新架構決定上線前, Pixnet 的工程師是怎樣進行必要的 Testing 的.

雖然說期間每天都有公告說明進度狀況, 但是顯然整個新架構所導致的問題百出.

即便中間有無數使用者建議暫時改為舊版 ( 請參考 kunghc 的給Pixnet總經理李俊廣的公開信: 這是你展現危機管理最重要的時刻 ), 讓使用者可以正常使用, 等新版完全測試成功再重新上線, 但是 Pixnet 似乎不為所動, 直到今天, 8/27, 算是第七天了, Pixnet 還是堅持要玩 Bug Online 嗎 ? User Community 不是 Debugging Community 阿 = = ( 話說 Ptt 也開始討論搬家的方法了)

不是要幸災樂禍, 不過這真是一個好的 Case Study, 真希望有機會可以知道整個內部的來龍去脈. 從這個 Case 可以想到的幾個延伸問題 :

除了 Testing 的問題以外, 是否 Pixnet 工程師也沒有考慮過會出問題的可能, 新系統沒有任何 Backward Compatibility 考量, 導致現在不是 Pixnet 不想回復舊版, 而是根本回不去 ? Online Software/Service 的 Backward Compatibility 有哪些東西要考量 ?

個人資料被 BSP 或 Web Applications 綁架的議題, 在無名及 Pixnet 相繼出問題之後, 是否會浮上檯面呢 ?

提供服務的 BSP 或 Web Applications 背後的工程師素質顯然也相當重要, 但是一般使用者基本上不會去注意這點--直到出大問題之前, 這種情況是否會有所改變 ? 如何評估 BSP 的安全可信度 ( Security Reliability ) ?

我們會有定期的防空演習, 是否提供服務的軟體公司應該進行類似的演習 ? ( 可能是由內部的 QA 小組製造狀況, 或是有專門的外部公司介入, 就跟 CMMI 驗證一樣, 這跟單純的 Software V&V 不同 )

Joomla 1.5.x 重大密碼漏洞, 需升級至 1.5.6

2008-08-15T10:26:00.008+08:00

8/12 發佈的 patch (Core - Password Remind Functionality), Joomla! 台灣則是 8/13 刊登此消息, 不過我知道的有點晚了, 剛剛才注意到這個問題, 回頭去檢查系網頁發現密碼已經被改掉了 == , 有沒有這麼快阿 orz

幸好網頁內容沒有被作大量修改, 不然要回覆備份就有點麻煩.

補救的方法請到 Joomla 官方網站下載 upgrade patch 檔案 (請指明官方網站), 注意相對的升級版本, 然後解壓縮蓋掉原本的程式就好了 (擔心的話就先備份一下再蓋掉). 我從 1.5.1 升級到 1.5.6 在頁面上基本沒有甚麼需要再進行修改的地方.

至於被改掉的密碼, 如果你的 1.5.x 沒有辦法在登入的地方直接透過寄回信箱的方式, 那可能就要到 database 進行修改. 利用 phpmyadmin 的話很方便, 找到 jos_users 資料表, 點選要修改密碼的使用者資料,

在 password 欄位選擇 MD5 編碼, 然後在右側的 password 密碼內容直接改寫為你想要設定的密碼, 然後拉到最下方進行儲存. 雖然填寫的時候是明碼, 但是在儲存過後 phpmyadmin 會自動利用 MD5 進行編碼, 這也是 Joomla 預設的密碼編碼.

這樣就大致修正完畢啦.資料沒毀損真是不幸中的大幸.

這是誰的問題 ?

2008-08-13T15:32:00.004+08:00

前幾天重新在找一些 CloudAV 相關的文章資料時, 意外注意到一個讓我想不透的搜尋結果.

當我之前的文章 Will the AntiVirus Cloud Works ? 寫完後不久(8/10), 如果使用 CloudAV 進行查詢, 是可以在 Google 上找到的, 而且如果只鎖定繁體中文網頁, 基本上相關的網頁不多, 只有四個網頁分布於三個網站.

但是就在我再度查詢的那天(約兩天之後, 8/12), 當再次查詢時, Will the AntiVirus Cloud Works ?的文章卻不會在 Google 上出現了.

為此我特意把原本的文章發表時間做了修改, 改成比較新的時間(8/12)重新發表一次, 大約過了半小時, 於是文章又重新出現了. 結果就跟第一張圖一樣.

然而在過了一天後的今天(8/13), 文章又從查詢結果裡消失了, 而且這次連另外一個網站也消失了, 只剩下 Only Perception 的網站文章可以被查到.

如果使用 AntiVirus Cloud 作為關鍵字組也會是一樣的情況.

如果說是因為搜尋結果量多, 導致被過濾掉或是排到後幾頁去, 我可以理解文章會從搜尋結果中消失, 或是移到後幾頁去, 但是當搜尋結果極少時 ? 而且是才 post 沒幾天的文章, 也出現了這樣的情況 ?

我真的很好奇為什麼會這樣 @@

Will CloudAV, the AntiVirus Cloud Works ?

2008-08-12T06:30:00.001+08:00

( 修改一下發表時間以及Title 進行實驗 )

根據 Computer World 的一篇報導 : Researchers look to cloud computing to fight malware, 密西根大學的幾位學者 ( Jon Oberheide, Evan Cooke, and Farnam Jahanian ) 嘗試利用不同的 AntiVirus Softwares 利用 Cloud Computing 概念結合來防範 malware, 所打著的算盤當然是截長補短, 讓 virus 或是 malware 需要克服更多的難關. 這跟趨勢最近在講的 Cloud Computing 應用 ( 前幾期的財訊在訪問趨勢某人時有提到比較多, 不過內容同樣不甚具體 ), 應該是不同的方向.

這項計畫稱為 CloudAV ( 應該是 Cloud AntiVirus 之意吧 ? ), 相關網站在這, 同時有電子論文可以抓取. ( 以下圖片均取用自 [1] ) 基本上可疑的 File 會傳送到 ClondAV 所提供的 Network Service 作檢驗, 這跟早期的網路掃毒類似.

看起來最終的決定是採用類似 Voting 的機制, 透過許多 AntiVirus 的結果, 決定是否該 File 是有問題的.

我在去年修 Embedded Middleware 作 Final Project 時有提過類似但不相同的想法 ( 我要集合的不是 AntiVirus Softwares ), 最終是卡在系統本身的 Security 問題, 以及 Privacy 問題. 針對 Privacy 問題, 在 [1] 中 Section 3.1 花了一小段說明, 但是也不算正面回答, 只是透過把 CloudAV 的應用環境作限制, 來降低 Privacy 的影響.

除了 Privacy 之外, 對於 CloudAV 是否能成功, 我還有另一個商業上的疑慮, 雖然 Paper [1] 內有談論了實驗本身所使用的 Software 的 License 問題, 但是在商業應用上不知道是否防毒軟體大廠會同意這樣的使用方式, 或是願意加入這樣的服務團體. 這裡就牽涉到商業利益的問題, 也可能給防毒效益不好的公司帶來更大的壓力.

不過, 往好的方面想, CloudAV 可以克服以往我們幾乎無法在一套系統內裝設兩套防毒軟體的效能問題, 以及 Mobile Device 不方便把資源用來跑 AntiVirus Software 的問題, 同時又能帶來更好更可靠的服務, 只要防毒軟體大廠願意進行類似的合作, 那麼就良性競爭以及防毒技術的進步來說應該是正面的. 這樣的 AntiVirus Cloud 似乎也跟我之前認為 Cloud Computing 會帶來軟體產業的二次分工相關.

References

[1] Jon Oberheide, Evan Cooke, and Farnam Jahanian, "CloudAV: N-Version Antivirus in the Network Cloud," Proc. of the 17th USENIX Security Symposium, July 2008

Bookmark Mindmap

2008-08-09T07:37:00.016+08:00

前幾天在 RWW 上有一篇文章, 介紹了可以幫助 Bookmark Favorite Images 的三個 Sites : 3 Cool Sites to Bookmark Your Favorite Images on the Web. 昨天在看到一篇與 Cloud Computing 相關的文章, 並把他利用回應的方式附加到我之前的文章時, 忽然想到, 往往我們在 Web 上會看到跟之前一些想法相關的資料, 包含文章圖片影像動畫等等 -- 姑且稱為 Web Materials 好了 -- 是否可以有很容易的方法來蒐集組織他們呢 ?

之前用過 Google Notebook, 在蒐集上是很方便, 但是後端的組織就比較弱. 這種類似的系統由於缺乏比較系統化的組織工具, 因此容易出現蒐集了一堆, 後續處理反而麻煩的情況.

如果我們把自己的 Blog 視為表達紀錄自己知識的媒介, 那麼其實可以把這種組織的行為以 Blog 文章為中心作連結, 等同於以 "Adding" 的方式連結別人的知識到自己的知識上, 同時這是屬於個人式的知識累積. 很直覺的會想到利用 MindMap 來作整理. 借用 FreeMind 作個假想圖 :

利用 "Bookmark MindMap" 在 Google 做了一下搜尋, 發現有一些類似的 Tools, 例如有人替 Del.icio.us 作了 Delicious Mind Map Maker, 可以吃進你的 Del.icio.us 資料, 製作出 MindMap 來.

另外 DeliciousMind 也同樣是幫助把 Del.icio.us 上的資料以 MindMap 形式作整理與呈現的工具, 他利用了 FeeeMind. ( 這裡有額外的介紹跟 Examples )

不過這些都跟我想要的還是有一段距離. 我認為一張 MindMap 應該是以一篇 Post 為中心, 而往外擴展關係, 然而整個網站未必要是多張獨立的 MindMap, 這樣會讓 Blogger 整理到死. 相對的, 一個 Blog 本身是 Personal Knowledge Web, 而以單一 Post 為中心可以得到一個以上的 MindMaps. 這也跟之前 Library 2.0 的討論有相關之處.

The Connected OS and Midori from Microsoft

2008-08-09T06:38:00.003+08:00

Microsoft 在 Windows 7 之後的繼任者已浮現雛型 ?

Ray Ozzie, CTO of MS, 在最近 MS 的年度 Financial Analyst Meeting 會議中提到 (原始內容在 MS.com 上面有刊載) :

We believe in a future, again, in many ways analogous to Xbox LIVE, in which Windows Live acts as a strategic extension to both Windows on the PC and Windows Mobile on the phone. You can think of this as the connected OS, Windows beyond the level of a single device or PC. How the OS connects to services and how it synchronizes with other devices are key. Your PC's config settings, your apps and their settings, your files and folders, are transparently synchronized across a mesh of PCs and other devices by Windows.

再加上最近查詢度很高的 Midori OS, 讓人不把這兩者想在一起都難 :p

但我相信 Ray Ozzie 真正要說的 Key 應該還是對於 Resources 的管理與需求, 而不是單純的 Service Connection 以及 Device Synchronization. 恐龍本一開始就把 OS 的目的跟主要工作寫得很清楚了, 只是在未來 -- 也許是 Cloud Computing 的未來 -- Resource 的型態也許會跟現行的 Computer Resource 會有很大的差異, 例如 Memory Service Resource, Computing Service Resource 之類的, 同時可能會再異化出更多的 Resource 種類出來, 與單純在硬體上的 CPU/Memory Resource 搶奪大不相同.

但對於 Operating System 的需要以及定義, 我想基本上還是相同的.

Two Final Projects Inspired by Audi for Beginners

2008-07-31T07:34:00.000+08:00

前幾天寫了關於 Audi 的 Travolution,進而想到了兩個相關的題目, 蠻適合給大一學生作 Final Project 的. ( 話說為什麼我會在颱風風雨中騎機車時想到這個呢 = = )

1. 真人版 Travolution

第一個是利用 Wireless Device 直接模擬 Audi Travolution 的運作. 可以在電機系館一樓的空間劃定線格代表街道跟路線, 架設假的紅綠燈, 用不同的 Wireless Device 放置在紅綠燈定點, 就跟 Audi 在真實的紅綠燈上作的一樣.

學生手上拿的是 Notebook 或是 UMPC, 同時學生寫的作業就是要模擬 Audi 在汽車上的 Client Software, 必須時時提醒駕駛員目前的時速應該控制到多少. 整個距離可以用等比例作規劃, 學生就拿著 NB 把自己當作汽車在跑, 感覺有點像大富翁 :p

中間可以加上一些特殊事件, 道路速限, 道路維修, 臨檢等等, 就更像大富翁了. 同時學生之間是需要彼此競爭的. 不過由於這是給大一學生的 Project, 因此基本的環境架設就要由 TA 負責.

2. Travolution 模擬遊戲

跟真人版的一樣, 只是在模擬遊戲中, 學生必須寫出 Strategy 來控制所有的車輛, 從一個既定範圍的四周會不斷的有新的車輛湧入, 要到達特定的出口 ( 一張圖有許多出入口 ), 同樣道路有許多的特性, 中間當然也會有紅綠燈的出現, 而最終目的是要讓所有車輛所使用的平均時間最少.
這樣的模擬遊戲當然也可以讓不同的學生彼此競爭, 只要讓新湧入的車輛分別受不同的 Strategy 控制即可. 同樣的, Strategy 可以執行的 Environment 也需要由 TA 去建構.

這兩個遊戲的目的都是希望透過進行跟業界真實產品類似的作業, 讓學生可以比較容易想像自己的 Programming 可以用在甚麼樣的地方, 發揮甚麼樣的價值.

Something about Library 2.0 (1) : Digital Library

2008-07-30T07:51:00.000+08:00

Library 2.0 的議題在國內外已經有數年的討論了. 關於命名當然跟 Web 2.0 有關, 但是整體概念的演進早在 Web 2.0 被 Tim O'Reilly 拋出之前.

我現在有在訂閱的幾個 Bloggers 也持續的關注此議題, 不過大多是以圖書館員, 或是圖書館界人士的角度. 正巧我之前跟老師的討論中整理了一些關於 Library 的想法, 是從 Architecture Evolution 的角度整理的, 順手搬到 Blog 上, 從不同的角度看 Library 2.0

跟其他的 XXX 2.0 一樣, Library 2.0 絕對不是獨立的技術跟概念, 而是同一個趨勢在不同領域的展現, 透過搬移其他領域的成功經驗, 以及解決其他領域一樣遇到的問題, 才有可能讓 Library 2.0 的理想獲得成功. ( 當然, 還要主事者不腦殘 = = )

1. The Definition

引用 Wikipedia 上對於 Library 的部分敘述 :

A library is a collection of information, sources, resources and services, organized for use, and maintained by a public body, an institution, or a private individual. In the more traditional sense, it means a collection of books. This collection and services are used by people who choose not to — or cannot afford to — purchase an extensive collection themselves, who need material no individual can reasonably be expected to have, or who require professional assistance with their research.

從這段敘述中可以推想出幾個關於 Library 的特性, 我認為也適用於 Library 2.0 :

Library 內的東西可以有很多種, 而非只有 book 而已
Library 內的東西必須經過特定的整理以方便使用
Library 的 maintainer 可以是單一個人, 一小團體, 一個機構, 甚至是大眾, 並沒有特別限制
Library 的大小並沒有特別的限制
Library 的使用者數量也沒有特別的限制

2. The Conventional Solution

目前常見的 Library 所採取的做法是, 由 Maintainer Role 負責為 Library 內的各種 contents, 例如 books, 事先以特定的分類方式作分類, 然後 User Role 必需去學習這樣的分類方式, 以便有效率地進行搜尋以取得想要的 contents.

在此做法下, Maintainer Role, Library, 以及 User Role 之間的關係像是這樣的 :

Maintainer Role 除了要負責維持 Library 的 functionality 運作之外, 同時也負責設計及實施 classification scheme, 而 User Role 是在 Maintainer Role 所決定的 Classification Scheme 下所使用 Library.
這樣的 solution 基本上是可以運作並實現 Library 的功能, 但是這樣的 solution 並不夠好 :

在此 solution 底下, User Role 被迫必須接受並使用 Maintainer Role 的觀點, 而難以較有效率且符合自身需要的方式來重新分類 Library 內的 contents
對 Maintainer Role 來說, 也因為此 solution 而限制了他們可以嘗試的 classification scheme. 因為大多數 Users 會希望到各個不同 Library 可以以自己習慣的方式作 contents 找尋的動作, 而不是每到不同的 Library 就需要面對不同的 classification scheme. 因此 Maintainer Role 其實只能被限制在數種主流的 classification scheme 中

我認為之所以會產生這些 imperfect 問題的原因, 其實跟過去基於人力所能負擔的 effort 有限, 以及 Library 是實體的 ( Physical ) 有關, 例如圖書館.

由於過去主要以人力進行管理與維護, 因此如果 classification scheme 不由 Maintainer Role 所掌控, 並強迫 User Role 依照統一的 scheme 使用, 則為了應付不同 Users 的需求, Library Maintainer 必須花費相當巨量的 efforts 來提供服務, 但如此一來 cost 也相對大量增加, 這將與 Library 概念的初衷之一, 減少整體社會接觸知識所需要的 cost, 產生相違背的情況.

3. The Digital Solution

在 Computer 被發明並普及化後, 其實我們應該回頭去思考, 是否可以利用 computer 的 computation power, 重新去改進過去限於人力考量, 所無法圓滿解決的 Library 問題.

利用 computer 的特點在於, (1) computer 具有較為低廉的 computation power, (2) 基於 computer, 許多 Library contents 得以數位化 ( digital ) 的形式存在, 以及被取用. 底下稱呼利用 computer 來解決的做法為 digital solution.

鑑於 application context 的不同, 我認為 digital solution 可以分為下面兩者, 兩者的差別在於 Library 內所管理的 contents 是否具有實體而定.

Semi-Digital Library : 其內的 contents 仍然具有實體, 因此我們不可能使用不固定的 classification scheme 來管理這些 contents, 在實體世界中必然要選擇一種 scheme 來管理這些實體 contents. 但是對於 User Role 在進行搜尋來說, 由於可以把這些實體 contents 以虛擬的物件 ( Virtual Object ) 來表示, 因此在 User Role 端可以保有自己的classification scheme, 透過 computer 進行管理, 不需要花費 Maintainer Role 的 effort. 因此在此 solution 下, Maintainer Role 的責任略小, 只負責實體 contents 的管理, 以及 Semi-Digital Library functionality 的正常運作.

Digital Library : 其內的 contents 完全是 digital contents, 因此完全可以使用 computer 進行儲存以及其他管理. 因此在 classification 部分, Maintainer Role 完全不需要介入, Maintainer Role 將只需要負擔維持 Digital Library 的 functionality 正常運作的責任即可. 而 classification scheme 將完全基於 User Role 運作.

上述的 Semi-Digital Library 以及 Digital Library 兩個 solutions 之共同特點在於, 利用 computer, 將 classification scheme 的調整以及決定, 曝露 ( expose ) 給 User Role. 進而 classification scheme 有機會具備 personalization 的特性. 而回頭去看 conventional solution 中的 imperfect 部分, 將可以藉由此種方式被滿足.

4. Personal Small Library

另外在此想特別針對較小的 Library 討論其應用 digital solution 之後的改變.

在 1999 年日本偶像劇場有一部戲劇叫做 Lipstick, 其內有一句台詞大概是這樣說 :

如果有一個夠小的公共圖書館, 是由一個人單獨維護管理 ( 包含選書以及整理 ), 則透過仔細觀察這個圖書館裡的書, 你將能夠窺視管理者的個人思維.

許多小型的 Libraries 事實上具有特殊的用途, 可能是學者或是作家私人的參考資料庫, 或是一個實驗室共用的圖書研究資料蒐藏, 一個機構的歷史文件彙整等等. 因此裡面所放置的 contents相當程度反映了 Maintainer Role 或是 User Role groups 的相關訊息, 極有可能這些 contents 本身就具有一定的相關度, 而此相關度反映在使用該 Library 的 users 身上. 同時這樣的小型圖書館有一個極大的特點, 在於 User Role 的使用方式以及用途有極高的相似度, 使得嘗試統整所有使用者的 classification scheme, 以及 logic, 來為彼此的搜尋提供幫助, 具有很高的可行性以及實用性.

然而這在 conventional solution 中較難以實現, 理由是各 Users 的使用觀點事實上會隨著時間而有所變動, 進而牽動整個 group 的整體共通觀點改變, 換句話說這樣的改變是動態地, 隨時發生的, 且是藉由許多 Users 的意見交錯協調條而達到一個穩定的狀態 ( Stable Status). 在 conventional solution 中, 這樣的改變較難以達到, 因為這需要所有 Users 定期舉行會議, 討論大家都可以接受的 classification scheme, 相當地耗費時間.

相對來說, 在 digital solution 中顯然就較為容易做到, 藉由 computer 以及 network 的幫助, Users 的使用模式以及使用邏輯 ( Logic ) 可以被紀錄與分析, 進而彼此影響, 達到一個 group 內共享的觀點. 而且此共享的觀點可以隨著 Users 端的改變而動態地調整. 而在此同時, 各 Users 保持有自己的觀點仍舊是可能的.

而由此觀點而言, Semi-Digital Library 以及 Digital Library 使得 Library 不再只是靜態的 content data 的分類存放以及取用場所, 而是轉變為 group 內 users 的意見彙整平台之一, 透過在 Digital Library 內分享觀點, Digital Library 轉變成為引導 group 前進方向的動態角色之一.

5. Public Large Library

Large Public Library 的情況就與 Small Library 的情況不盡相同. 差異在於 Large Public Library 的使用者通常較多且雜, 使用目的也差異較大, 因此利用 digital solution 可以達到的好處應該會比較偏向 personalization 部分. 然而在統計數據的支持下, 或許可以考慮把 Large Public Library 切割成數個 clusters, 然後將每個 cluster 視為 Small Library 來處理. 在此情況下, 需要每個 cluster 有固定的 Users 才可行.

目前在 Web Recommendation System 上已經出現了類似的概念被實現, 例如 Reddit, Mixx 都有讓使用者建立自己的 Community 的能力, 而 Digg 也準備跟進. 當然這只是在 Web 的部份而已.

恐怖的 Adeona

2008-07-29T07:30:00.000+08:00

過去兩三個禮拜 Adeona 忽然變成了一個熱門關鍵字 :p

原因是 Adeona 這個 Open Source Project, 號稱是第一個可以對於你的 Laptop Notebook 進行 Tracking 的 Open Source Software, 對於追回失竊的 Notebook 來說特別有用.

其基本的概念是在 Notebook 上安裝一個 Client Software, 每當 Notebook 連接上網路時, 會自動將該 Notebook 的位置 ( IP 以及相對存取周遭網路設備的位置 ) 進行 AES 加密後, 利用 OpenDHT 技術存到特定的 Server 上, 該加密過後的位置資料只有原始擁有者可以開啟, 如此一來 Notebook 的擁有者就可以對於 Notebook 的位置進行追蹤, 並確保自己的隱私.

關於 Privacy 部份, 事實上 Adeona 作的考量更多, 包含無法簡單透過 Location Update 去鎖定特定的 Device 等等, 務求達成 Anonymous, Unlinkable Updates, 詳細內容請見 Adeona 的發表 Paper , 在講述 System Goal 的部份有列舉說明.

我之所以覺得 Adeona 很恐怖是因為, 同樣的概念幾乎可以用在任何可以運作 Software 的地方(或東西). 甚至我可以說, 一般 Notebook 並非 Adeona 最好的利用環境. 理由是一般 Notebook 或是 Laptop 的系統都很容易被重新安裝或是修改. 重新安裝會使得 Adeona 失去作用, 而修改則可能使得竊賊進一步利用 Adeona 對於追蹤進行欺騙.

反倒是其他的高價物品, 利用 Adeona 的可能性以及有效性極高. 例如在無線環境下的汽機車, 高單價的 Mobile Device, 重要的文件盒保險箱等等 ( 不用再害怕忘在公車或是計程車上摟 ). 可以簡單把 Adeona 作成一個具無線網路功能的訊息送出嵌入式設備, 讓使用者自行安裝在要追蹤的物品上. 這種嵌入式系統就可以避免掉上述的問題, 只要不被從保護物品上拆除就好. ( 使用者可以裝在很隱密, 或是無法拆除的地方 ). 從這個角度來看, 其實跟 RFID 又有點像, 但是安全性以及範圍又比 RFID 大很多.

而除了這些可能之外, 最恐怖的是, Adeona 也可能被裝在 Software 或是 Data 身上, 讓我們可以對於 Software 或是 Data 的 Distribution 作追蹤, 例如公司內重要的電子文件管理, 怎樣確保每一份被複製的重要文件, 沒有在允許以外的地方被開啟.

這樣一想, Adeona 的概念幾乎可以用在任何地方, 這能不恐怖嗎, 光用想的我雞皮疙瘩就起來了 = =

James Gosling's Q&A Podcast at Java One 2008

2008-07-28T16:38:00.029+08:00

James Gosling 在 Java One 2008 的一個 Q&A Session 內容現在可以利用 MP3 下載聽了. 不過我覺得大多問題其實沒有很深入地回答, 本來看到網頁上寫到 java.net 的未來還蠻有興趣的, 以為會跟 SOA 有很強的關聯, 不過就我聽到的內容, 似乎也是輕輕帶過而已.

大概有以下重點 ( 邊聽邊隨便打打, 內容文法可能...ㄜ, 語句應該也不是很連貫, 重點節錄, 跟 Java 關係不大的議題我就自動跳過了 ) :

有人問道 : If you develop Java all over again, what will be done differently. 於是 Gosling 就說啦, Properly wont develop AWT (觀眾笑), and left over calender class ( 這點不是很確定, 因為 calender 不是被大修過, 為什麼是 left over ? ), won't done closure at the first time.

有人關心 Balance between continuous adapting, evolving, changing of Java and the the mature of Java, 可能是想問究竟 Java 算不算成熟, 持續的有改變是否是好事之類的. Gosling 回答道, Java 5 is really a change ( 事實上直到 Java 5 才真正做了比較大的改變 ) . There are still many Java 7 proposals on debate. The way people use it is changing. Java works out better then expected. Many proposals, such as bound property proposal, are more complicated than just writing the code. Must consider some issues, such as explosion and chaos of APIs. ( 我覺得這跟一般的 Software 增加新的 Features 是差不多的 )

Something about Generic, seems similar with last question.

Favorite IT/IS topics of James Gosling. Depend on who he talks. ( No very related with Java. )

Future of "small Java" ( Nothing new actually )

Favorite Language despite Java ? James Gosling : It's an easy quesiton, Scala. ( 一點都不熟阿 = = 要檢討 )

有人問道 Java is similar to an OS ( 指在很多表現上很像一個 OS ), platform, not simply a Programming Language environment. James Gosling 順著接手說, bycode is general for many languages. 雖然 JVM 將可以支援很多不同的語言 ( More and more services can built upon JVM in next 10 years. ), 但是某些語言是難以被完整支援的, 特別是跟 pointer 有關的語言. 即便如此, Give up C/C++, that was no-brainer. 中間還有說道 James Gosling 其實很 appreciate Microsoft 對於 C/C++ 的付出貢獻 ( 我應該沒聽錯 XD )

有人問道 Java 7 的時間表. Time frame for Java 7 or new features, or progress. James Gosling 說 It not technical question, but policy, JCP, something related ( 就是說沒辦法單單從 Technology 角度給答案啦, James Gosling 目前是 Sun 的 Client Software Group CTO ). There is no schedule, hope yesterday :p

給大家的話. Last word for developers : Drink more Beer ^^ (這應該是給 Java One 參加者的話) , Make sure you working on projects for fun.

整個錄音中其實我最有興趣的是 James Gosling 反覆提到的那個 Slide Program, 但是只有發音 ( 類似 Hextor 的發音 ) 不知道怎樣查, 嘗試幾個都找不到 @@

中央氣象局什時會整合 Google Earth ?

2008-07-28T07:00:00.011+08:00

颱風夜寫這篇真是應景阿 ^^

長久以來中央氣象局都只有提供俯瞰的衛星雲圖, 但是 Abstraction Level 太高, 也沒辦法任意變更 Granularity, 說穿了只是往往在颱風來時, 只是看到台灣整個被淹沒而已, 沒辦法調整 Granularity 來看自己居住地區的最近幾小時情況. 雖然也有提供即時影像, 但是一來都是定點, 同時一下子又把視野調到太小, 參考度其實也不高.

我相信中央氣象局手上握有的資料一定比利用衛星雲圖給一般民眾看到的更多, 只是受限於經費以及技術限制, 沒辦法在網頁上提供更先進, 更詳細且好用的 Visualization 介面給訪客.

既然如此, 是否中央氣象局應該考慮採用整合既有的技術, 例如 Google Earth, 作為平台, 附加屬於中央氣象局的有用資訊呢 ?

目前 Google Earth 已經可以讓使用者即時觀察颱風以及颶風等天氣狀態, 並且上面可以看到許多有用的天氣資訊, 如果中央氣象局可以讓資訊部門成立一個小組負責把中文化的資訊整合上去, 我相信只有初期會花比較多心力, 之後就會很輕鬆.

甚至當 Google Earth 的 3D 化成熟之後, 將可以進一步把颱風的面貌用 3D 的圖像顯示, 這樣應該有助於一般民眾對於颱風強度以及危害的認識與警覺性, 而不是僅透過一些聽不懂的數據去了解颱風. ( 以下圖片引用自 Google Earth Community )

稍微查了一下, 颱風與氣象相關資料的 3D Visualization 也是有在作呢, 希望可以早日成熟, 一定會很有用的 :)

Audi's Travolution, Towards Future Traffic Control : Act After Negotiation

2008-07-27T15:00:00.001+08:00

德國汽車大廠 Audi 開始在試驗名為 Vehicle-to-Infrastructure (V2I) 的交通控制概念, 名為 Travolution -- 顯然地是 Travel + Evolution 的併詞.

最近釋出的初期產品是透過在 Traffic Light 上安裝可以透過無線網路回報目前 Traffic Light 狀態的裝置, 使得安裝在汽車上的提醒裝置可以進行計算, 並告知駕駛員應該減速或加速到多少, 以便能夠一路上不會遇到紅燈, 以最有效率的方式駕車.

不過從新聞稿中看不出此裝置是否會考量現實的交通狀況, 畢竟在車量多時要駕駛到指定的速度有可能是辦不到的事. 相關的新聞可以參考 AutoBlog 以及 Traffic Technology Today. ( 以下圖片取用自 AutoBlog )

我覺得從 Audi 的這項產品可以看到, 相對於期待電影裡出現的車輛交通自動控制, 採取的是比較務實的作法. 基本上車輛的控制還是由人來執行, 但是車子本身則是設法提供有用的交通資訊以及建議給駕駛員, 協助整個旅程的順暢, 並消極地達成對於整體的交通控制.

透過這類的裝置, 原本不同的車子是在表現出行為之後才彼此影響, 而未來將可能是經過協調 (Negotiation) 之後, 才表現出行為, 然後造成可預期的影響. 換句話說, 也許在車子上, 此類裝置最後會給出一個 "Traffic Preview" , 告訴你這樣開的話, 五分鐘後會是怎樣的情況. 不過這需要除了 Traffic Light 與車子之外, 車子與車子之間的 Communication 才能達成.

不過這在台灣應該用處不大就是了 :p

Travel Plan Digg + SOA Travel Planning

2008-07-27T10:00:00.001+08:00

最近要到蘭嶼去玩幾天 (8/1-8/4), 發現行程規劃實在是件有點複雜的事情.

從台灣本島到蘭嶼有搭飛機以及搭船兩種方式. 飛機的話目前只有台東機場有德安航空到蘭嶼的航班, 其他地方沒有.搭船的選擇就比較多了, 台東富岡有, 也可以從屏東後壁.

如果說旅程規劃沒有任何彈性, 事情就簡單許多, 但是選擇也相對變少. 比如說就是要從台北到蘭嶼, 然後日期就是 8/1 到 8/4, 那麼大約只剩下台北搭火車夜車到台東, 一早坐飛機到蘭嶼, 不過這樣的旅程很累 ; 或是 8/1 早上搭火車, 但是這樣到蘭嶼的時間就變成下午了.

而如果旅程規劃有很多彈性, 像是我們的規劃, 可以接受先到台東住一兩天, 然後從容地搭飛機到蘭嶼 ; 甚至可以接受先到台南待一天, 然後從台南搭火車到台東 (大約只要三個半小時), 這樣比台北到台東快上不少, 旅程也比較不會累. 其他像是先到花蓮, 再到台東等等, 都在可以接受的範圍. 這時候再考量旅館, 交通, 食物等等相關事項, 整個規劃作業瞬間就變的很複雜.

在 Web Service 與 SOA 的研究中常見以 Traveling 作為 Service & Workflow 的 Example. 常見以 Time 為根據作行程的銜接, 以及基本的條件設定, 然後加上一些進階條件的選擇, 像是不搭船, 以及 Quality 的要求等等. 這樣 SOA 的 Solution 事實上存在很多複雜度, 除了上面說的以外, 像是 Service 的狀態要能由 Service Provider 更新, 確保 Service Abailability 以及 Quality 等等.

但是若單純以 Bottom-Up 的方式去產生可能的 Workflow, 固然可以得到最多的可能性, 但是畢竟使用者要的通常只有一兩個, 因此中間就需要透過使用者的參與來降低可能的選擇數目, 這又變成了 User Interaction 的問題.

也許因為這樣的複雜度, 許多國內的旅遊服務都只停留在 Information Portal 或是 Service Portal 的階段而已, 而不是真正的 Service Provision Forge.

我認為類似的應用應該考慮利用 Top-Down 以及 User Community 來夾出可能的選擇, 進而大幅降低一般使用者的負擔, 同時確保規劃結果的品質與可行性.

方法就是利用現成的 Travel Plan 作為 Incomplete Workflow 去套可得的 Services. 可以想像一個類似 Digg 的 Travel Plan 推薦子系統, 由一個 Community 維護. Community 成員可以貢獻自己的 Travel Plan, 作為基本的 Template, 而其他成員是以一個 Travel Plan 為單位進行推薦以及參考. 而反過來, Community 也能夠提供 Single Service 的資訊, 有利於一般 Service 資訊的更新與正確性.

當然, 免不了地 User Interface 依舊會是關鍵, 必須要能夠盡量降低使用者輸入以及推薦 Travel Plan 的 Effort, 才能夠在使用者可以得到的幫助與付出之間取得平衡. 另外必須有 Formal Travel Model, 而不是向許多旅遊網站只是讓使用者以 Natural Language + Free Style 分享旅遊心得. 既然要從使用者端取得資訊來再利用, 就應該有系統地蒐集以及使用.

不用把資訊的取得想的太複雜, 也不要期望旅途中相關的商家旅館會時時更新訊息, 單純依靠 Community 的力量來建構這樣的環境, 有效地在資訊進來之前就先篩選, 同時也讓回給使用者的規劃有最高的有效性.

Defining Operational Scalability

2008-07-26T12:36:00.028+08:00

Wayne Fenton, Director of Architecture at eBay Inc., 在 JAOO 2007 上給了一個 Talk : Operational Scalability in the Next Generation Web World (連結內有側錄影片 + Slides), 雖然影片長達 48 分鐘, 不過內容其實很簡短, 雖然提到很多次 eBay, 但是其實內容是獨立的, 有認真上 Fault Tolerance 的人應該都很容易聽懂內容, 因為都是基本的概念.

事實上我沒有真的找到對於 Operational Scalability 較為嚴格的定義, 看看幾個從不同網頁 Copy 下來的 :

From SOA Magazine [1] :

Operational scalability is the ability of a service-oriented solution architecture to establish and maintain highly efficient and adaptive, cost effective day-to-day operations as the solution grows and scales with time. It is also represents the ability of the architecture itself to be efficiently re-factored to accommodate change and dynamic business requirements.

From Rajith’s Column [2] :

Operational scalability is a software problem and you need to think about operational concerns right from the beginning. Pay attention to,
Logging metrics, Monitoring.
Controlling/updating/tuning live apps without disrupting traffic.

與 Rajith 類似的說法在 CoverPages 的一篇 Sybase 新聞中也可以看到, 不過搞不太清楚算是甚麼, 比較像是文宣, 就不納入參考.

Leticia Duboc 的 PhD Work [3][4] 認為 Scalability 基本上不容易也不適合有一個通用的定義, 需要視乎不同的系統以及面對不同的 Stakeholder 而異. 因此他們也建立了一個 Scalability Framework, 在不同的情況下去 Initiate 此 Framework, 定義不同的 Scaling Dimensions, Independent Variable, Dependent Variable, 以及 Evaluation Standard ( Scalability Claim ).

We define scalability as a quality of software systems characterized by the causal impact that scaling aspects of the system environment and design have on certain measured system qualities as these aspects are varied over expected operational ranges.

(以下圖片引用自 [4])

這樣我差不多可以稍稍做出結論. 基本上可以說有 Operational Scalability 這東西, 也可以說沒有. 在 [1][2] 中基本上是在特定的觀點下, 面對特定的 Stakeholder 去定義 Operational Scalability, 而其中 [1] 又更偏向一般性的 Scalability 敘述. 而在 Wayne Fenton 的 Talk 中事實上提到了許多不同的 Stakeholders, 不僅僅是一般的 Customers 而已. 因此他的 Operational Scalability 與其說是以 Stakeholders 作區分, 不如說是以 Operational Reliable Service 為中心思想, 並且放在Community 多變的 Web Service Context 下作說明.

Operational 指的是 Service 本身是必須持續運作的, 你幾乎不能考慮停止這項 Service, 必須隨時 Ready for Use, 概念同於古老的 Non-Stop System 概念. 而 Reliable 指的是 Service 可能會更新 Features, 但是不能夠因為新的 Features 而造成不可逆的改變. 這兩項在新時代的 Web Service 上更顯關鍵. 我們很容易有了想法, 很快的成立網站提供服務, 但是隨之而來的使用者人潮跟對於新功能的需求非常難以預料, 這跟過去 Software 面對的情況有顯著不同, Community 的形成之快是超乎預料的, 但是 Community 的衰落之快也同樣難以預期.

而 Operational Scalability 在此情況下, 我認為其實就是針對 Community Change 的 System Scalability.

References

[1] Ted Barbusinski, "SOA Engineering Focal Points," The SOA Magazine, Issue XIX, June 2008
[2] Rajith Attapattu, "Scaling your system - What I learnt from Dan Pritchett’s (eBay) talk"
[3] Leticia Duboc, David S. Rosenblum, and Tony Wicks, "A Framework for Modelling and Analysis of Software Systems Scalability," Proceedings of the 28th international conference on Software engineering, pp. 949 - 952, 2006 ( Syposium Presentation )
[4] Leticia Duboc, David S. Rosenblum, and Tony Wicks, "A Framework for Characterization and Analysis of Software Systems Scalability," in Proceeding of the The 6th joint meeting of the European Software Engineering Conference and the ACM SIGSOFT Symposium on the Foundations of Software Engineering, ESEC/FSE '07

Beyond Single-Page Web Search Results, and ... What's The Next ? Community Page Ranking ?

2008-07-25T17:00:00.033+08:00

本週實驗室會議由學長報告了 [1] 這篇 Paper. 其實之前我旁聽實驗室另外一個 Project 的進度會議時就已經大略看過這篇了, 不過本週趁機重新看一次, 反而有些新的想法 -- 可見得有些 Paper 時不時要多看幾次.

這篇 Paper 的基本概念很簡單, 解決的問題很小 ( 或者該說精準 ) 但很實在.

目前的 Web Search Engine 基本上是以 Single Web Page 作為單位進行關鍵字比對, 然後把符合或部份符合的 Pages 傳回, 通常會依照符合的程度進行排序 (Ranking). 不同的 Search Engine 可能會有額外的 Ranking Factors, 像是 Google 有自己著名的 Page Ranking 演算法, 另外考量商業廣告因素, 關鍵字出現頻率等等, 可以對於排序演算法再做調整.

但不管怎樣作排序跟 Page Ranking, 以 Single Web Page 為單位就會出現, 用了多重關鍵字進行搜尋, 但是沒有任何一個 Page 完全符合關鍵字組的情況. 使用者必須由列出的 Pages 之中, 瀏覽排前面數名的 Pages, 才有可能得到真正想要的資訊. 這大致符合我們的使用經驗.

Paper [1] 的想法則是, 把原本 Single Web Page 的情況, 進步到 Multiple Web Pages -- 既然我們本來就會需要瀏覽多個 Pages 來得到我們想要的東西, 為什麼不在 Search 時就直接給我 Multiple Pages 的比對結果呢 ?

( 下圖修改組合自 [1] 內容的截圖 )

因此 Paper [1] 把 Multiple Pages 結合起來成為一個 Composed Page 作為搜尋結果. 但是 Multiple Pages 也不能亂選, 否則可能造成內容事實上差距很大, 不相干的東西被包裝在一起, 因此考量了 Pages 之間應該會有 Hyperlink 的關係. 同時 Composed Page 內也要避免因為 Pages 太多不好快速瀏覽, 因此針對一個 Page, 也提供了 Query-Specific Summarize 的演算法, 藉由把一個 Page 的文字內容作切段, 以 Query 用的關鍵字組為依據, 利用 Text Information Retrieval 的方法, 以及 LSI 技術, 建立一個 Page Graph, 然後計算出具代表性的部份作為 Summary. 而多個 Pages 在 Summarize 過後進一步把 Summary 結合成為 Composed Page. 詳細的演算法在 [1] 中有說明.

從 User Query 的觀點來說, Paper [1] 注意到越來越多使用者傾向使用關鍵字組作為 Search Context 的 Abstraction, 並期望找到的資訊可以填到 Search Context 中. 而過去 Single Web Page 的作法使得使用者要自己負責彙整 Single Web Pages, 透過 Hyperlink 去找尋 ( Explore ) 更廣的資料, 然後歸納出一個有用的 Page Set 出來. 而此篇 Paper 稍微前進了一步, 在可以幫忙進行事前整理的範圍內, 先把相關的 Pages ( 可能橫跨 Websites ) 做了整理, 同時以 Summarize 過後的內容結合成一個 Composed Page, 來逼近 User 的 Search Context.

從 Single Web Page Ranking 到 Multiple Web Page Ranking ( Summarized, Composed Page ), 下一個階段會是甚麼呢 ?

Community Page Ranking 或許有機會. 不管是 Single Web Page Ranking 或是 Multiple Web Page Ranking, 基本上如果你輸入的是一樣的關鍵字組, 結果應該是一樣的, 換句話說對於所有使用者來說是一視同仁的. 這也是因為我們無法事先預測可能的使用情況 ( Search Context ), 因此只好這樣作. 但是如果可以鎖定一個 Community, 透過 Community Member 就可能定義出屬於該 Community 的可預測 Search Contexts, 這時候要更進一步對於 Pages 作事前組織就是有可能的事情. 同樣的 Pages Set 在 Travel Community 與 Local City Community, 使用同樣的關鍵字組, 可能會是得到不一樣的 Composed Page.

感覺 Google 已經開始透過 Knol 希望逐漸建立可信賴的 Knowledge Group 了, 或許將來與 Community 在 Knowledge Search 方面會有更加深入的互動.

References

[1] R. Varadarajan, V. Hristidis, and Tao Li, "Beyond Single-Page Web Search Results," IEEE Transactions on Knowledge and Data Engineering, vol.20, no.3, pp.411 - 424, March 2008

Twitter + Google Maps Should Go Beyond TwitterVision

2008-07-23T15:00:00.001+08:00

Google Maps 現在也加上 Walking Direction 的資訊了( RWW 也有相關文章 ), 這基本上是一個必然的動作, 能夠讓地圖提供更有效率的幫助. 即便是在有了各種電子地圖後, 查閱地理資訊變得更加容易, 自動規劃路程也變得可能, 然而缺乏更加詳細的資訊卻讓許多理想的服務無法完成.

像是 UrMap 也遲遲未能提供台北縣市以外的大眾交通工具資訊, 以及路線規劃只能提供汽車, 沒辦法照顧到機車族群. 我認為問題不在於 Algorithm 的設計以及 Computation Power 的限制, 而在於 Valid Data 的取得.

透過 Sensor 或是 GPS Devices 固然是一種方式, 也常用於自然災害偵測與防治以及疾病控管等大範圍監控系統上, 但是幾乎都是透過衛星傳輸資料, 要在城市中使用, 為了降低成本需要仰賴於城市無線網路基礎設施, 同時即便如此, 大量的 Sensor 裝設費用仍然很嚇人.

在這些困難下, 其實過去的警廣交通網作法, 反而是可以讓人考慮的一條路. 台灣主要道路的路況是由熱心的駕駛回報到警廣, 然後由警廣彙整略加查核後由廣播通知鄰近其他駕駛人

同樣地, 我們可以期待類似 Twitter 與 Google Maps 的結合. 透過 Twitter, 使用者可以時不時地簡短報告自己周圍的地理狀況, 然後以 Google Maps 作為具體呈現的平台, 廣播給大家知道. 已經有類似的服務在 TwitterVision 被實現. 相關的主題也可以在 Google 上利用 "Twitter Google Maps Mashup" 作為關鍵字找尋, 有相當多的討論.

然而 TwitterVision 也只是讓 Twitter + Google Maps 發揮 1 + 1 = 2 的效果而已, 我們需要讓 1 + 1 > 2 .

透過 Twitter 而來的 Message 或是 Media (Photo, Vedio Clip, etc) 應該可以在使用者輸入時先作簡單的分類或是 Tagging, 然後在後端利用 Semantic Analysis & Semantic Web 以及 Image Recognition, Image Classification 對於這些資料根據 Google Maps 的基本地理條件 (Constraints) 作彙整, 針對不同使用者的使用需求, 提供即時的相關資料整理.

交通以及路況就是一個很容易處理的應用. 只要在輸入者提供一些簡單的 Template, 很容易就能得到使用者身邊有用的 Data, 然後就能夠整理成該地區有用的交通及路況資訊. 當然, 這依舊仰賴於無線網路基礎設施的鋪設, 以及手持式電子裝置的普及 -- 不過話說回來, 這時代有哪項網路服務不是建立在這樣的預想 (Assumption) 之下 ?

期待很快能看到這樣的 Product 出現 :)

Something about Cloud Computing : 軟體產業的二次分工 ?

2008-07-23T09:30:00.000+08:00

RWW 上的一篇文章 : Reaching for the Sky Through The Compute Clouds, 我覺得寫的不錯, 算是從一個容易理解的角度說明 Cloud Computing. 同時他提出 Google Data Cloud 的例子來輔助他畫出的 Clouds 概念圖增加不少說服力. ( 不過 You vs Them 段落之後感覺有點混亂, 不是很能同意 )

其中請注意到底下回應中, Avner Algom 的回應 ( No.15 ). 為了紀錄方便, 完整轉錄 (稍加編排) 如下 :

It is to remember that without the convergence of grid, virtualization and SOA concepts, the cloud implementation cannot be done. In fact, the Cloud Computing concept is a Grid based business model that provides utility Computing services and/or SaaS services

Terminology Synch:
Grid provides the Service-Oriented Infrastructure Virtualization (SOIV) that enables IT scalability and flexibility
Service Orientation - Service-orientation is a design paradigm that specifies the creation of automation logic in the form of services. It is applied as a strategic goal in developing a service-oriented architecture (SOA).
Virtualization - a technique for hiding the physical characteristics of computing resources from the way in which other systems, applications, or end users interact with those resources.
Utility Computing – Pay-per-Use for network based Compute and Storage services
Software as a Service (SaaS) - Pay-per-Use for network based software applications’ services

目前來說, 我傾向認同這樣的歷史觀點, Cloud Computing 並非技術面上的突破, 而是技術面上的成熟代表. 然而, 僅僅是相關技術的成熟, 有必要 Google 大張旗鼓的推廣此概念嗎 ? 僅僅是為了對於顧客的商業包裝, 推廣相關技術到一般人面前嗎 ?

我覺得除了把 Cloud 跟過往 Network 上的雲狀圖示作聯結之外, 是否應該想想取用 "Cloud" 這個字所隱含的意義呢 ?

在 Webster's Dictionary 上可以查到下面的解釋 ( 只取較為相關的部份 )

1. Any collection of particles (e.g., smoke or dust) or gases that is visible.
2. A visible mass of water or ice particles suspended at a considerable altitude.
3. Out of touch with reality; "his head was in the clouds".

然後我們又知道, Cloud 的形狀, 大小, 高度, 都會因為各種氣候條件而有所不同, 如果再結合 RWW 文章中的這張圖, ( 引用自 RWW, 由 Alex Iskold 繪製 )

霎時卻讓我想到了, Cloud Computing 從軟體工業的角度來說, 或許代表的是軟體產業的二次分工.

第一次分工是著重於軟體製造業的分工, 從 System Design, Software Analysis & Design, 到 Implementation, Testing 的分工. 這在目前世界軟體產業已經是普遍的模式, Global Software Engineering 也早已被討論多時.

而我所指的軟體產業的二次分工, 則是軟體服務業的分工.

上圖中的各種 Cloud 都可以被視為是一群提供相關服務的業者 ( 服務提供者, 未必是真實人類 ) 所組成, 但是與單純的 Service Group 不同的是, 在此 Cloud 內的 Particles ( 服務提供者 ), 必須遵守同樣的 Protocol 規範, 包含 Interface, Quality 等等, 因此對於採用該 Cloud 服務的顧客而言, 面對的是整個 Cloud, 而非單一個服務提供者.

這個觀點相信也與 RWW 的該篇文章(特別是 You vs Them 段落), 以及網路上的許多文章應該是相容, 只是從產業改變的觀點來說.

不過必須再加說明的是, 我不認為此分工模式會導致軟體服務創意被壓縮. 事實上, 這種分工模式是一個把餅做大的分工模式, 而不是為了要做出很多不同口味的餅. 在此情況下, 最大的得利者會是開發出新口味大餅的業者, 其次則是某種口味大餅做的最好賣得最好的業者, 最後則是勉強作一種口味的大餅可以餬口的業者. 而 Google 跟其他在推 Cloud Computing 的業者這當然是前兩者 :)

Linux 市佔率提昇的影響 ?

2008-07-22T11:14:00.029+08:00

前陣子 Acer 自打嘴巴地推出了 Aspire One, 加上今天看到了 ComputerWorld Blog 上的這篇文章 : PC Vendors Want to Sell You Desktop Linux, 其實很顯然的, 在 EeePC 的成功之後, 不僅是在 Desktop PC 上, 各種 NB, 小 NB, Mobile Device 上, 廠商業者考量採用 Linux 的傾向得到了更為強烈的市場反應支持, 加上 Desktop Linux 系統的成熟, 產品廠商在付出額外的 Desktop Linux 修改成本與降低銷售成本以提高顧客購買率與競爭力之間, 只要能取得有利的平衡, 就是對於他們可行的方案.

反正, 改用搭配 Desktop Linux 是一個進可攻退可守的方案, 君不見 EeePC 還是會推出附有 Windows 的版本嗎 ? 甚至更奸詐的把改裝 Windows 的選項留下來, 任由顧客自己去找盜版的 Windows 進行重新安裝. 或許有很多人是會改裝回 Windows, 不過不管如何, Desktop Linux 的市佔率提高是一定的事情, 只是速度快慢而已.

乘著這個趨勢, 可預見的, 產品廠商還是會持續的考慮採用 Linux, 除非 Microsoft 釋出更有利的方案. 而這會形成一個有趣的現象, 這些本來是整合硬體跟軔體, 然後採用 Microsoft 軟體的產品廠商, 會不會開始做起軟體 ( OS, Desktop, Apps ) 的部份呢 ?

ASUS 的 EeePC 在軟體操作介面上並不是只套用常見的 Linux Desktop, 而是再進提供了 Easy Mode, 以 Task-Oriented 為主. 雖然不是創新的設計, 但是怎麼說也是自家要做的東西, 變成了整個自家產品開發的一部分. 過去我們買 NB 時在 OS 方面沒辦法比, 因為都是一樣的系統跟介面, 所以幾乎都是比同樣價格下硬體的規格, 穩定度, 主要用途適用性, 售後服務等等. 但說穿了, 除了售後服務, 其他大概都差不多, 一般使用者也鮮有機會感受到差異.

但是 Software 就不一樣了. 光是 Desktop 使用介面的設計的差異就會造成使用者極大的不同感受, 更別說對於使用者安裝新軟體的便利性以及常用軟體的穩定性. 這些都會比其他方面對於使用者造成更直接更巨大的影響. 也許在這方面沒有一家公司可以取得獨特的領先地位, 但是誰也不敢落後太多吧 :p

在此考量下, 不知道這些產品公司會不會開始成立自己的軟體部門--有別於過去只有處理軔體跟驅動程式, 以及 MIS 的部門, 而是會負責建立或是修改 Open Source OS, Desktop, 以及 Apps 的部門. 或是採取外包的方式, 有專門的軟體公司來與這些產品公司合作進行 Customization, 就跟過去 Microsoft 的角色一樣.

Either way, Software Rules. ^^

從LED七段顯示器到用宿舍燈光玩貪食蛇

2008-07-20T07:00:00.012+08:00

昨天經過別人的推薦在 YouTube 上看到芬蘭學生利用宿舍大樓玩貪食蛇的影片. 在 YouTube 上利用PIOW 或是 P.I.O.W. 作搜尋可以找到應該是同樣的一群人玩的其他花樣.

這其實不算是甚麼新的東西了, 也常看到夜晚利用商業大樓作同樣的事情, 像是求婚, 假日煙火節慶等等.

雖然不是很清楚背後的工作原理, 不過對於電機資工學生來說應該也不難想像. 比較笨一點的就是在電燈開關上裝設可程式控制的電機裝置, 但是這很麻煩, 也可能會破壞原本的電燈開關設施. 或者我們可以製作簡單的嵌入式設備, 結合電燈以及可程式化的 IC 版作控制. 但是這會有同步的問題, 很可能無法做到影片中那麼完美.

不過呢, 加上個簡單的 Wireless 裝置, 利用一台 PC 作 Server 來發出命令給所有房間內的嵌入式電燈裝置, 應該就差不多可以做到類似的事情. 如果需要不同的顏色, 可以在一個房間內準備多個電燈設備, 或是複雜點利用多顏色的電燈, 一樣透過程式控制.

想起來很複雜, 不過其實只是中間加上了不同的 Components 接起來而已, 基本的控制概念與想法, 其實跟所有電機資工學生大概都會碰過的七段顯示器控制, 其實沒什麼兩樣. ( 圖片取用自這裡 )

不過有多少電機資工大學部學生, 會聯想到七段顯示器呢 ?

不過反過來說, 這也未嘗不是一個好的教材. 可以把簡單的七段顯示器控制, 加上 Wireless 網路概念, 馬上就可以讓學生玩一樣的事情. 去建議系上的微算機實驗課程, 把簡單的七段顯示器控制換成這個好了, 然後期末要利用電機大樓玩一樣的事情 :p

搞不好幾年後會出現學生用這招在學校裡玩告白 XD

也是一種 Biosignal Decvice

2008-07-19T10:17:00.008+08:00

或許該說是 Behavioral Biosignal Device 比較貼切 ?

根據 Engadget 的報導, 一家名為 Airun Plus 的公司準備發佈一款特殊的運動鞋, 針對一般運動員設計了 BMI 計量以及卡路里熱量消耗計量, 同時還具有走路時的重力 ( 應該是指施加於鞋子的壓力吧 ) 與速度感應器. 可以協助運動員或是一般人的運動計畫成效, 同時避免腳部因為過大的壓力而受傷. ( 圖片引用自 Engadget )

我在想這個運動鞋除了自身的功能之外, 如果他的偵測資料可以從外部下載, 或是由他主動上傳到外部的裝置, 這也可已是一個十分有價值的 Biosignal Device.

除了熱量消耗資料外, 像是走路運動時的速度以及腳步承受的壓力, 其實一般人進行一般的運動行為時, 固然有可能因為瞬間的壓力過大而受傷, 因為長時間姿勢不正確或是習慣不好, 導致慢性傷害的也不在少數. 同時慢性傷害往往更加難以復原,

對於可能進行中的慢性傷害, 將可以透過分析一般的運動行為, 像是日常走路, 來作可能的偵測與預防. 不過針對於一雙鞋子來說有點負擔太大了, 再說常走路的話, 其實一雙運動鞋大概一年多就要換一次, 還有人是每天刻意要換不同的鞋子. 透過外部的生理訊號分析, 可以整合到同一份資料中, 還可以跟其他相關的生理訊號作結合, 應該還是比較正確的作法.

Document Built-In Formation Test

2008-07-18T19:48:00.011+08:00

昨天幫一個學弟進行碩士口試的 Dry Run, 投影片裡面要改正的小缺點相當多, 雖然說我當初在準備碩士口試時也是有不少地方需要修改, 不過倒沒有像學弟一樣出現很多有點離譜的錯誤 -- 以我們實驗室兩年的 Training 來說.

這種同 Hierarchy 字體大小不一, 條列式內容的標示混雜地以數字跟符號組成, 同時並沒有特殊意義. 還有同一頁的文字表格太多太雜等等問題, 表格文字超過虛擬邊框 (Soft Boundary) 等等.

現在的編輯軟體大多有提供 Spell Checking 功能, 可能是自身內建的, 也可能是利用外部的 Spelling Checking Component, 像是 GNU Aspell 等等.

雖然說可以利用建立 Template 來軟性規範一些可能出現的 Inconsistency, 但是手殘的時候還是有可能像是上面的 Format Inconsistency.

不知道是否在編輯軟體上, 可以支援對於特定 Document Template 加上 Built-in Formation Test, 來確保 Document 中不會有不經意的 Inconsistency 出現. 像是同一個 Hierarchy 的文字大小, 粗細設定以及字體應該一致, 同一頁的文字數量以及行數應該小於某個數值, 甚至可以根據整頁的字數跟圖的複雜度所含的資訊量作檢查, 避免同一頁的內容太多且雜.

其他一些投影片製作的 Rule of Thumb 或許也可以變成一些 Tests 來協助製作在 Formation 上具一定水準的投影片.

利用 Twiddla 遠距討論 Design Diagram

2008-07-18T11:54:00.015+08:00

Twiddla 是一個免費的電子白板服務, 之前為了跟在美國的學長討論 Paper 上的 Architecture 圖, 其實在 Survey 時有注意到, 但是當時以為只是普通的畫圖用電子白板, 鑑於畫起 Design Diagram 實在太累, 加上動作過快會讓網頁上的 JavaScript 陷入暴走狀態, 把整個 Browser 鎖死, 因此後來沒考慮使用 Twiddla.

今天看到 Library Views 圖書館觀點的一篇介紹文章, 才發現原來 Twiddla 可以開啟特定的網頁網址, 在上面進行文字或畫圖註解討論. 這樣一來問題就好處理多了, 可以先把要討論的 Design Diagram 放到一個可以取用的 Web Server 下, 然後再利用 Twiddla 去開該檔案的網址, 就可以當作底圖進行討論, 畫註解等等.

在技術面上, Twiddla 有利用 Scribd 的 iPaper 的服務, 把許多不同的檔案格式轉成 Flash, 因此可能可以直接開啟, 然後在上面討論. 嘗試了幾個不同的常用 File Format, 像是 Python Source Code 會被當作普通的純文字檔轉成 Flash, Block 會亂掉, 沒辦法好好看 Code. 而 PDF File 可以開, 但是非常 lag, 相對來說 OpenOffice 檔案倒是還好.

這樣 Twiddla 加上 SkyPe 以及各種 IM Software, 基本上就可以是窮人版的 Web Meeting Solution 摟 :)

Multi-Languages Adapter

2008-07-16T17:35:00.022+08:00

不是正式的 Pattern Documentation, 只是隨手記記, 這種情況其實還蠻常遇到的. 但需要進一步討論的是, 如果我們說 Programming Languages 的選擇決定通常是在 Design Phase 末期或是 Implementation Phase 初期, 那麼這個情況是否應該出現呢 ? 而如果出現了, 是否下面的能夠使用呢 ?

Context

Used when components developed in different programming languages, which with low interoperability between each other, have to communicate and collaborate together.

Solution

Use a common infrastructure as a language-independent third party media, and develop a common protocol as communication standard.

The ProtocolAdapter is responsible for maintaining the Protocol, translating language-specific message into message under Protocol, and vice versa.

Example

An example using socket and TCP/IP network is illustrated bellow.

Consequences

Increase the reuse of components implemented in different programming languages.
The language-independent third party media usually contributes to constraints on usage of the applied application. Usability may be somewhat sacrificed.
There will definitely be performance issues.

Associated Patterns

Mediator Pattern
Adapter Pattern

街頭垃圾壓縮機與 Service-Oriented Computing

2008-07-15T18:45:00.015+08:00

在癮科技看到的這篇新聞 : 費城將在街上設置垃圾壓縮機很有趣, 等同於是把小型的垃圾車放置在城市中固定的地點, 透過科技的進步來增加垃圾收納量, 以及降低環境污染度, 克服過去公設垃圾桶會有的許多缺點.(以下圖片引用自 KYW Newsradio)

不過之所以會特別想在這記上一筆, 並非僅是因為這事有趣.

過去在談論 Service-Oriented Computing 時, 我們似乎都會很自然的想到各種商業應用, Shopping Services, Business Services, Travel / Hotel / Transportation Services 等等, 然而回歸到現實面, 其實還有很多非常小, 但是很實用的 Services 經常就被忽略.

像是很常遇到的, 走在街上, 可能是因為剛剛買了小吃, 飲料, 或是打噴嚏的衛生紙, 很容易的手上就會有想丟掉的垃圾. 如果是在不熟, 非生活圈的地方, 一時之間要找垃圾桶就不是如此容易的事情. 如果費城的垃圾壓縮機可以在 Service-Oriented Computing 基礎設施上搭配提供這種垃圾 Service, 應該會讓計畫的效果更好吧.

這種垃圾 Service 看起來很小很無聊, 可是需要的時候功用卻是很大的.

Keep Watching : Software Quality Observatory for Open Source Software (SQO-OSS)

2008-07-15T16:04:00.013+08:00

記得大約是兩年前作 OSS Quality Measurement Project 時看到 SQO-OSS 這個計畫網站的, 當時裡面還甚麼都沒有, 但是畫了很多 Vision 的大餅. 同時間注意到的還有 Ohloh.net ( 之前文章 Assessing Open Source : Ohloh.net ). 後來 Ohloh.net 陸續公佈了許多新的功能以及介面調整, 而 SQO-OSS 不愧是學術計畫, 一直停留在只聞樓梯響的階段.

而現在, Finally, SQO-OSS 也進入 alpha-testing 的階段了, 公佈了一個 Quality Checking Tool, 名為 Alitheis Core. 不過 Demo 網站好像掛點了, 真是不太捧場阿 :p

雖然 Demo 掛點, 不過需要的話可以下載 0.8 或是 0.8.1 的版本, 在這裡可以找到. ( 主要開發語言是 Java, 大心 ^_^ )

Alitheia Core 的 Architectural Overview 可見下圖 (引用自 SQO-OSS 網站 ). 其實並沒有甚麼特別的地方. 值得注意的是此頁的 Title 是寫 Alitheia Core and Metrics, 但是圖中沒有出現 Metrics, 因此也不確定是用在 Information Extraction 或是 Data Mining 的部份. 不管怎樣, 整個系統的運作其實不難理解.

在 Source 裡面的 Metrics Package 含有很多 Sub Packages, 甚至包含 Productivity Metrics. 不過細看很多內容都是空的 ( 這是怎樣 = = ), 也許正在實做中吧.

既然玩不到 Demo, 改來看看公開的 ScreenShots ( Alitheia Core 0.8.x ) 也好. 但其實從 ScreenShot 看來也蠻讓人失望的.

是的, 看起來有很多 Metrics 可以安裝來用, 但是從 Source Code 以外的 Project Artifacts 進行分析的部份看起來還是缺乏. 而即便是已經有的 Metrics, 在能夠連結到更 High Level 的意義之前, 我想對於 OSS Community 的吸引力也不是很大.

不過不管怎麼說, 人家也是有 Product 了, 我們實驗室的還在難產中. 加油吧~~

Borland's New Tools : TeamDemand, TeamFocus, and TeamAnalytics, to Make SDP More Transparent

2008-07-14T19:57:00.016+08:00

Borland 今天正式公佈了三個預計於秋季釋出( release ? 販售吧 :p )的新工具. 詳細情況可以參考 Computer World 的這篇新聞 : Borland adds tools aimed at making application development more transparent.

三個 Tools 分別為 :

TeamDemand : 這個是三個 Tools 裡我覺得最沒想到的. 企圖把 User Requirements 連結到 Development Tasks 以及 Development Process, 想要提供 Business Users ( Customers ) 一個可以即時 ( Real-time ) 獲知目前進度的溝通管道. 我認為這要做得到其實不難, 但要做的好不容易. 簡單的來說, 能夠讓 User 根據 Requirement 隨時輸入 Test Cases 其實就成功一半了, 接下來只要自動找到相對的進度作 Testing 就是另一半, 不過這之間都還隱藏許多問題.

TeamFocus : 看來應該是用來連結 Developers 使用的 Tools, 彙整相關的 Information, 產生開發過程中的相關 Reports. 預計可以大幅降低 Developers 需要花時間在整理 Intermediate Report 的時間.

TeamAnalytics : 根據 Project 內部可以獲得的各種 Information, 結合在特定 Domain 下適用的不同 Metrics 組合, 量測出 Project 目前的狀態, 對於不佳的情況可以事先給予 Warning. 尚不知內部怎樣管理 Metrics,不過如果是用類似 GQM 方法的話, 應該可以想像 Goal 沒有達到預期就是一種 Warning 了.

現在我在做的其中一個 Project 其實就是 Team Focus + TeamAnalytics, 另外其實再結合另外一個小 Project 也可以朝 TeamDemand 去作, 只是之前沒想到. 不知道該向 Borland 投以敵視的眼神還是感激的眼神 XD

Borland 真是 IDE 界的巨人阿~~

Will Dual-Touchscreen Brings More Issues to the GUI Design ?

2008-07-14T19:13:00.009+08:00

今天看到 Laptop 的這篇文章 : V12 Designs’ Dual-Touchscreen Notebook Coming within Two Years, 裡面提到 V12 Design 的 Dual-Touchscreen Notebook.

這怎麼說呢, 雖然乍看之下就是兩片 LCD 螢幕合在一起, 然後其中一片可以用作鍵盤顯示以及使用, 理想的話還會有 V12 Design 宣稱的感應回饋 ( Haptic Feedback ) 能力, 但是把 Notebook 上鍵盤那側變成 LCD 所帶來的 User Interface 改變還是很巨大的. ( 以下圖片引用修改自 Laptop )

把目前的 Notebook 具有固定式鍵盤, 到 Optimus Maximus 萬鍵之王的想法, ( 以下圖片取用自 Optimus Maximus 網站 )

再到 V12 Dual-Touchscreen, 硬體輸入裝置給了 Software 越來越多的自由. 在萬鍵之王上, Software 可以更加容易的改變按鍵的定義跟配置, 這在之前需要具備一定電腦知識的使用者才能辦得到. 而在 Dual-Touchscreen 上, Software 將甚至可以自行定義輸入用的 "鍵盤" 長甚麼樣 ( 如果他還長得像鍵盤的話 ), 而且不像過去會佔用到 Software 用來呈現 Data 的空間.

Software Usability 與 System Usability 的定義之間或許會更加的模糊, 真難想像這是會帶來無限的可能還是混亂 :p ( 更別提 Multi-Touch Screen 摟 ~~ )

Realtime Mining Applied

2008-07-09T10:23:00.020+08:00

上學期修課跟學弟合作的一個期末計畫是建立一個巴士系統的 Embedded Middleware. 目前這東西也慢慢延伸變成學弟的 Master Research. 在整個 Vision 中, 有一部分就是關連到即時地蒐集巴士系統中 Customer 相關的資訊, 以及整理分析這些資訊, 產生出足以作為決策支援的資訊 ( Structured Information ).

類似的東西已經開始有人用 GPS 得到的資料做出 Prototype 來摟.

6/22 的 NY Times 報導了此一 Prototype : Predicting Where You’ll Go and What You’ll Like , 由 Sense Networks 這家公司開發 ( 我覺得他們名字取得不錯 ) . 基本概念是利用 GPS 得到 Location Data 以及 Movement Data, 然後透過適當的 Mining Algorithm 分析, 就可能得到關於行為模式的猜測結論. 在文章中期時也提到, 可以用來被追蹤 (Track) 的東西很多, 不見得只有 Location 可以用來追蹤猜測人們的行為. ( 以下圖片引用自 Sense Network Media Center 公開資料, 上面還有 Vedio 可以下載 )

Realtime Data Mining 技術本身其實不是困難點, 困難的是怎樣讓整個 Process 可以真正應用到商業行為中使用. 期間需要考量的, 整合各種軟硬體設施, 同時城市無線網路的基礎也不可或缺. 另外就是使用者願意曝露自身資料的意願.

不過從過去的成功經驗來看, 其實這個世界的人們對於自身的資料隱私其實不是真的那麼在意 -- 只要有利可圖的話.

Sense Network 做出了很合理且聰明的決定, 他們不是一廂情願的向使用者買 Data 或是期望使用者會自動主動提供資料. 而是利用提供給使用者相關服務來換取資料 ( 原文為 : Sense decided to trade services for data. ) 而 Sense Network 自然可以從操作廣告以及服務之間得到適當的利益. 從 Google 以來, 這似乎已經是 Web 2.0 唯一具有足夠商業成功案例的模式了.

但是 Sense Network 是否能夠獲得足夠久的成功卻還很難說, 相當仰賴於他們的商業操作手段. 使用者的 Location 資料並非是會有長久價值的資料, 其 Lifecycle 可能只有短短的數個小時, 因此 Sense Network 不可能像是某些 Blog Supplier 一樣透過累積大量的懶惰使用者讓自己不倒, 而就算是在使用者 <-> 手持裝置 <-> 位置及其他資料 <-> 可得服務的 Cycle 中, Sense Network 也不是居在任何不可取代的位置. 因此一切都還很難說.

唯一能肯定的是 Realtime Mining 相關應用的這個趨勢應該確實會發生.

BASE : An ACID Alternative

2008-07-08T08:25:00.030+08:00

上個月的 ACM Queue 趕在最後幾天刊出了 Dan Pritchett, Technical Fellow at eBay, 的一篇文章 : BASE: An ACID Alternative.

BASE ( Basically Available, Soft State, and Eventually Consistent ) 相對於傳統的 ACID 以強調 Consistency 為主, 改為採用犧牲 Consistency 來換取 Availability 的概念.

基本上 Consistency 跟 Availability 常常是唱反調的, 因為要確保 Consistency 免不了需要在每個動作之前進行妥協 ( Negotiation ) 或是動作之後的檢查, 例如經典的 Two Phase Commit ( 2PC ), 而這就會傷害到 Availability. 在 BASE 的方法中, 把 Consistency 的檢查做了延遲, 先允許部份動作的進行與 Commit, 等所有的動作完成之後再設法確認無誤.

在文章中舉了一個例子 : 在 eBay 上有兩個角色, Seller 以及 Buyer. 當 Seller 把商品賣給 Buyer 之後, 首先要更新交易紀錄表, 再來兩邊的 Account 資訊都要進行更新 ( Schema Design 請參考文章 ). 在傳統 ACID 的角度上來說, 通常這些動作會收集在同一個 Transaction 內部, 只進行一次 Commit, 確保兩邊 (交易紀錄表以及使用者紀錄表) 的 Consistency. (以下範例及圖片引用自 [1] )

而 BASE 的作法則是, 把交易紀錄表的更新與使用者紀錄表的更新分開, 變成數個 Transactions. 首先進行交易紀錄表的更新 Master Transaction, 然後再執行兩個更新使用者紀錄表的 Sub Transactions ( Seller 以及 Buyer ). 在 Master Transaction 中除了更新交易紀錄表之外, 事實上還發出了進行接下來數個 Sub Transactions 的要求到一個 Message Queue 中, 然後進行 Commit. 而在 Message Queue 中的 SQL Statement 則會在之後個別以 Transactions 作包裝進行 Commit.

基本概念大略是這樣, 文章後半段還有討論到 Peek Queue Message 以及 Remove Message 的細節, 以及使用 SQL Statement 作整個敘述上的簡化.

BASE 的作法當然可能在 Sub Transaction Fail 時引起 Inconsistency 的問題, 但是透過適當的 Traceback 機制, 我想應該可以快速的作 Error Recovery, 例如在 Master Transaction 送出的 Messages 上標記特殊的 Tag, 一旦出問題就可以追蹤到所有相關的 Transactions. 但是文章內容沒有對 Error Recovery 的處理部份著墨太多.

BASE 的應用關鍵我認為是在 Transaction 的結果事實上是應對到不同的使用者上, 包含 eBay 系統本身, Seller 以及 Buyer. 由於並非同一個角色, 因此在這些 Transactions 進行時所實際短暫產生的 Inconsistency 不會被三者察覺到 ( 除非 Seller 跟 Buyer 即時溝通確認 Consistency ). 而技術上來說, BASE 也沒有刻意隱藏 Temporal Inconsistency 的事實, 只是當 Seller 與 Buyer 角色分開時, 他們各自無法透過 Partial Information 去推知 Inconsistency 的發生罷了 :p -- 當然, 這也暗示了 BASE 的應用領域相較於 ACID 來說是會比較受侷限的.

從這點回頭來看這篇文章被放在這期的 ACM Queue 是很有趣的事情. May /June 這期的 ACM Queue 主題是 Object-Relation Mappers. 其他三篇文章都在講 ORM, 唯獨這篇殺出 ACID 與 Consistency/Availability 的問題. 是意外嗎 ? 或是 BASE 的方法事實上是把 eBay System 中的 Objects 與其 Behaviors, 給 Mapping 到了 Relational Database 中了 ?

References

[1] Dan Pritchett, "BASE: An ACID Alternative," ACM Queue, vol.6, no.3, May/June 2008, visit online version

Tool Support for the Navigation in Graphical Models

2008-07-07T21:30:00.021+08:00

這篇 Short Paper [1] 以及所建立的 Tool ADORA, 包含重點大致可以歸納為兩點.

首先是使用 Fisheye View 的概念改進目前大部分 Tools 在協助使用者瀏覽整張 Software Design Diagram 時的問題. 既有的 Tool 在面對相當複雜且巨大的 Diagram 時大多無能為力, 往往需要使用者自行將 Design Diagram 從 Object Analysis ( 如果是在 OO Paradigm 中 ) 以後, 分為 Class Level 0, Class Level 1, ...... 等詳細程度不同的數張 Design Diagrams, 方便在不同的 Abstraction Level 間切換. 少部份 Tools 可以自動隱藏 Details, 但是當進行 Zoom In / Zoom Out 時卻是會對於整張圖作變化, 無法自由地只 Zoom In 想要進一步觀察的部份. Fisheye View 則讓此操作方式成為可能. ( 以下 ADORA 圖片皆取用自 [1] 並稍加編輯, 且無修改圖片本身內容 )

關於第一點在去年底我們實驗室有一位同仁在進行實驗室會議報告 Paper 時也有提到類似的概念, 當時他是用 StarCraft 當作例子, 在 StarCraft 中同時有主操作畫面 ( Local ), 以及左下方的微縮地圖全圖 ( Global ), 來說明如果 Design Tool 有類似的支援好像不錯. 當時大家討論都集中在使用方式上, 看了 [1] 的實做, 好像在 Layout 計算位置上也不是那麼容易實現, 畢竟要兼顧到整張圖的 Re-arrangement, 不能因為 Fisheye 使得整張圖亂掉. 我想這也是 [1] 裡面要強調可恢復性 (Stability) 的原因. ( 以下 StarCraft 插圖引用自 http://spyhunter007.com/game_over.htm )

第二是對於 Single Integrated Model 的理想. 在 Paper 尾段嘗試性的把不同時間點的一些 Diagrams 疊合在一起, 包含 User & Context, Use Case Diagram, 以及 Class Diagram. 可以想見的, 這樣一來就可以透過 ADORA, 在 Software Development Phases 之間快速自由的移動, 瀏覽相關的 Analysis Diagrams, Design Diagrams.

不過我認為 Single Integrated Model 的需求, 使用時機及模式, 以及呈現方式都還有很多探討的空間, 在本篇 Paper 中也沒有再著墨太多. 像是上圖左, Use Cases 跟 Classes / Components 混在一起的感覺就很奇怪, 也沒有因此曝露更多 Information. 如果改用 Use Case Map [2] 來作整理可能會好點. ( 話說 Use Case Map 是怎樣, 不紅到原本的介紹網頁都消失了, 現在只依附在 jUCMNav 底下了 XD )

或許之後在 Software Design Tools 中會出現更多這種 Visualization Information Mash-Up 的應用.

References

[1] T. Reinhard, S. Meier, R. Stoiber, C. Cramer, and M. Glinz, "Tool Support for the Navigation in Graphical Models," Proceedings of the International Conference on Software Engineering, pp.823-826, 2008
[2] R. J. A. Buhr and R. S. Casselman, Use Case Maps for Object-Oriented Systems, Prentice-Hall, 1995

My Activity, My Life Calendar, My Swurl: Operating the Lifestream

2008-07-04T21:22:00.020+08:00

跟隨著 RWW 文章 Swurl: Your Lifestream, Made Beautiful 的腳步去試用了Swurl -- another Lifestreaming Service.

基本功能上其實沒有甚麼好說的, 跟 FriendFeed-like 的 Services 雷同, 甚至可以說現階段功能上不如 FriendFeed 來的好. 但是我喜歡他的 Visualization, 雖然概念簡單, 但是很強大.

Swurl 並非像 FriendFeed 一樣只是把蒐集來的資訊依新舊排列, 而是再多提供了一個類似 Calendar 的整理方式, 以時間軸, 只紀錄有活動天數, 形成一個 Life Calendar Matrix. ( 以下借用 RWW 文章的圖, 我的只有文字不太好看 :p )

Visualization 的目的一般是為了把 Invisible Information 變成 Visible.

在 Swurl 的 Life Calendar 上, 提供了一個介於統計式每日每週文章照片數量, 到 Blog 式落落長文章串之間, 折衷的摘要總覽介面. 輔以 Calendar 的 Metaphor, 我們會很自然地把相近日期的事件連結起來, 於是過去一天, 一週, 一月, 一年, 很快地就可以在你的腦海中流逝而過. 在每天每天每週每週 Blog 文章跟照片, 多媒體資料之間, 其實我們都遺漏 / 篩選掉了很多細節, 心情的轉換...... 這些東西我們沒辦法, 也不可能一一記錄下來, 但是透過 Life Calendar, 就像整理舊相簿一樣, 時間可以在手上流過, 本來一點一點的文章照片, 就可以銜接變成一整串記憶之流.

我想 Swurl, 以及他的相似 / 後繼者,會逐漸揭露一個方向 : 把Lifestream 的焦點從紀錄, 開始轉移到操作上. 就像編輯家庭錄影帶, 透過不同的操作, 我們可以再次提供不同的觀點, 不同的交集, 不同的思考, 以及不同的懷念 -- 為什麼我又會想到羅賓威廉斯的迴光報告 ( The Final Cut, 2004 ) 呢 ?

btw, My Swurl : http://selain.swurl.com/

FireFox 3 Download Day Certificate

2008-07-03T16:15:00.005+08:00

六月中的時候跑去 FireFox 3 Download Day 湊了一下熱鬧, 今天收到來自 FireFox 的通知信, 除了說明登上金氏世界紀錄之外, 還有提供個人 Certificate, 紀念一下摟 :p

話說不知道是不是我看錯, 我記得在 Download Day 之前台灣的 Promise 人數好像遠低於後來的 Download 人數 ? 另外最令我驚訝的是德國, 不管是當時的 Promise 人數跟後來的 Download 人數都高的嚇人 ( 當然是比不過美國啦... ).

StarCraft II 如果 Open for Download, 應該可以打破這個紀錄吧 XD

When to Reject the Customers/Users from Participating Your SDP ?

2008-07-02T20:47:00.014+08:00

在 Software Development Project ( SDP ) 中, 理論上在哪個時間點之後, 絕對不能再有 Users ( Customers ) 的參與 ? 這是約莫一年半以前, 我的 Advisor 問所有 Lab. 同仁的問題, 但是直到現在, 我也依舊沒有肯定的答案 ^^b

先來看看手邊幾本的說法. 當然, 這是依我的解讀做的時間點判斷及說明, 同時內容以及最後我自己的想法都侷限在 Conventional Object-Orientation Paradigm. 同時只考量 General Customer, General Software ( to-be-built ), 以及 No Changing Requirements ( during development process ).

[1] Dean Leffingwell and Don Widrig, Managing Software Requirements: A Use Case Approach, second edition, Addison Wesley, 2003

我的理解 :

書中分為六個階段的 Team Skill, 我認為在 Team Skill 2 結束時也同時代表 customer 的參與告一段落.
在 software GUI 部份, 書中傾向於使用 Use Case 以及 Storyboarding 解決. 鑒於內容是以 Storyboarding 方式, graphically 呈現 Use Case, 因此我還是認定為 Storyboarding 的應用, 屬於 Team Skill 2 的範圍內.

判定的時間點 :

After Requirement Elicitation, Feature Listing, Interviewing, Brainstorming, and Storyboarding
Before Use Case Diagram

[2] Steve R. Schach, Object-Oriented and Classical Software Engineering, fifth edition, McGraw-Hill, 2002

我的理解 :

書中於 Requirement Phase 到 Object-Oriented Analysis Phase 之間, 特別分出了一個 Specification Phase. 在 Specification Phase 中提到 :

...this document must be clear and intelligible to the client, who probably is not a computer specialist. After all, the client is paying for the product, and unless the client believes that he or she really understands what the new product will be like...

因此我認為以書中的觀點, customer 至少會參與到 specification 的制定.
書中所指的 Specification Phase 事實上等同於一般說的 Analysis Phase[2], 而 Object-Oriented Analysis Phase 是作為 counterpart 存在.
同時書中也提到, 在 specification 訂立之後才能進行較準確的 project time and cost estimation, 而 customer 會根據評估結果決定是否繼續委託開發. 從 project 角度來說, customer 在此時仍影響 project 的進行, 但是從 software development 的角度來說, 並未影響 software development 的各種 decisions.

判定的時間點 :

End of Specification Phase
Right after Project Time and Cost Estimation and Evaluation

[3] Eric J. Braude, Software Engineering: An Object-Oriented Perspective, Wiley, 2001

我的理解 :

書中把 Requirement 分為 C-Requirement ( Customer Requirement ), 以及 D-Requirement ( Detailed Requirement ) 兩部份. 其中 C-Requirement 包含了 Use Case 的建立與撰寫, 以及 Draft User Interface Design. 此階段仍有 customer 參與.
D-Requirement 的撰寫雖然主要是提供 software developers 一個之後進行 design 以及 implementation 的共同基礎,但是書中也提到 D-Requirement 需要 customer 參與 validation 的工作. 但是由於書中對於 D-Requirement 的內容敘述, 甚至包含了 Classes / Objects 的辨認, 因此 customer 協助確認的應該不是全部的 D-Requirement 內容.

判定的時間點 :

Right after D-Requirement ( Detailed Requirement ) is released
Very close to the end of Object-Oriented Analysis Phase

[4] Roger S. Pressman, Software Engineering : A Practitioner's Approach, fifth edition, McGraw-Hill, 2001

我的理解 :

書中提到 :

A review of the Software Requirement Specification ( and / or prototype ) is conducted by both the software developer and customer.

而依據書中所述, Software Requirement Specification 是 Requirement Analysis 的產物, 因此在此 customer 的參與應該是到 Requirement Analysis 結束之後, 或是 Software Requirement Specification 的 review

判定的時間點 :

End of Requirement Analysis
Review of Software Requirement Specification

[5] 我的想法

由於我對於 OO Paradigm 底下的 Software Development，主要的認識來自於 [1][2][3] ，因此以這些書中所提的觀點以及方法 ( Techniques ) 來回答此時間點。

我所 prefer 的時間點為， Use Case Diagram 的建立。

但此時間點僅包含 Use Case Diagram 的建立，不包含 Use Case 的 Pre-Condition， Post-Condition，以及中間的 Event Flow， Alternative Flow 的撰寫。

我所持的理由為， Use Cases 能夠將 Scenarios 化為數個合理大小的 User Action Sets。雖然 Use Cases 本身仍然用 nature language 描述居多，但是比起一般的 Scenarios 描述， Use Cases 提供一個更適切的 granularity，讓 customer 認識自己與 software 之間的互動。而適切的 granularity 也是此時間點僅止於 Use Case Diagram 的理由。我認為 Use Case 的內容又過於仔細，對於一般的 Customer 來說反而可能造成困擾，如果要求 Customer 參與 Use Case 內容的撰寫，對 Developer 來說也會是一種困擾。

但是在 Customer 參與 Use Case Diagram 的制定時，所提出的一些意外的要求或是 Concerns，有可能會影響到 Developer 對於 Use Cases 內容的撰寫。

另外我認為要特別考量的一個問題是 Software GUI。鑒於我所知道的，在 OO Software Development，並沒有公認的時間點來決定 customer 所 prefer 的 GUI 樣式，但是 software GUI 又是影響 software usability 甚鉅的部份，因此大部份情況下，與 customer 針對 GUI 作溝通是免不了的。因此在 software 有 GUI 的設計考量下， customer 能參與的 software development 的時間點我認為就會受到 software GUI 要在何時與 customer 取得共識的影響。不過此時間點僅與 GUI 設計有關，與其他部份無關。

Zero-Day Copy ?

2008-07-01T21:34:00.011+08:00

剛剛又看到一個複製網站說你這行 (ShowUrJob) , 很顯然想法是來自於 Glassdoor.com . 透過 Community Member 的群體力量, 讓許多公司的薪資跟待遇透明化.

在 Software Security 領域有 Zero-Day Attack, 在 Internet Venue 領域也要有 Zero-Day Copy 了嗎 :p

不過我並不是想嘲笑 Zero-Day Copy 的行為, 相反地, 這類網站能獲得成功也相當不錯, 沒有人會嫌可以用的服務太少, 不是嗎 ?

Zero-Day Copy 的可行性我認為與 Localization 關係極大, Glassdoor.com 對於非英語系的國家還沒有那麼大的 Community, 而缺乏 Community 就缺乏資訊. 如果有相似的網站可以快速複製實現類似的功能以及制度, 藉著語言以及文化優勢搶在開拓者 ( 如 Glassdoor.com ) 之前嘗試建立夠大的 Community, 成功的可能性並不低.

在 Zero-Day Copy 中, 最難得到的 Idea 來自於別人, 要搶佔的 Resource 本來就在 Community 中, 而中間快速複製才會是重點. 因此在 Zero-Day Copy Company 中, 最重要的角色可能會是兩種人 : Reverse Engineer 以及 Project Manager. ( 為什麼我會想到 Pay Check 這部電影 :p )

這裡的 Reverse Engineer 包含不只軟體技術上的 Reverse Engineer, 還包含可以從 Social 角度進行 Reverse Engineering, 分析開拓者成功因素跟行為模式的 Reverse Engineer. 換句話說, 需要的是一個 Socio-Technical System Reverse Engineering Team.

Project Manager 就不用說了, 能夠在合理的時間跟成本下領報開發團隊完成 Software Development 的 Manager 是每家軟體公司都想要的人.

也許將來 ( 或是現在就有 ? ) 會出現專門支持 Zero-Day Copy 的創投公司也說不定. 平常就養一堆技術高超的資訊人食客, 在 DEMO 展之類看到有價值的外國網站就馬上進行 Zero-Day Copy 工程, 反正現在軟體服務專利幾乎是沒有辦法申請的狀態. 有這種公司也是蠻有趣的, 跟我有點合得來 :p

Functionality versus Capability ? A Case in Java OpenCV

2008-07-01T20:07:00.023+08:00

這兩天跟學妹一起在對 Java OpenCV Match Template (以下簡稱 Java OpenCV ) 這個 Tool 作一點修改.

Java OpenCV 其實是一個 Adapter, 把 OpenCV ( 著名的 Computer Vision Library ) 內的 cvMatchTemplate Function ( 用 C++ 寫的 ) 包上 Java 的外衣. 而 cvMatchTemplate 的主要能力就是比對基底影像 ( Source Image ) 與模板影像 ( Template Image ), 找出在基底影像中哪些地方存在著與模板影像相似的影像, 以及該處的位置 ( 在圖片或影像截圖上的 ).

為簡化敘述, 先不論 Java OpenCV 其實是 Adapter 而已, 假設把 Java OpenCV 跟 cvMatchTemplate 包在一起看成一個單一的 Component, 而這個 Component 提供一個 Interface 可以輸入基底影像以及模板影像, 而會回傳一個最佳的比對結果影像物件 ( Java Image Object ), 以及位置. 由於這是此 Component 唯一能夠提供的 Service, 因此就說這是 Java OpenCV 的 Functionality.

但是我們需要的是能夠提供多個比對結果的 Functionality. 例如下面的 Java OpenCV 測試圖, 在四個角落都有幾乎同樣的圓點, 但是 Java OpenCV 只會傳回最相似的一個結果而已. 而我們希望四個結果都可以傳回給我們作選擇.

由於短時間內沒有找到其他的 Tool 如此符合我們的需求, 加上 Java OpenCV 的程式碼其實不長, 因此我們去查看了一下原始碼. 在 Java OpenCV 與 cvMatchTemplate之間是使用 JNI 作連結, 而主要的 Image Matching 都是 cvMatchTemplate 進行的沒錯. cvMatchTemplate 是以逐一影像區塊進行比對的方式, 比完整張圖, 因此用了一個很大的 array 來存所有的比對結果.

而 cvMatchTemplate 回傳給 Java OpenCV 的內容其實包含了所有的比對結果, 而不是只有最佳的比對結果. 換句話說, 是在 Java OpenCV 內被做了過濾. 更嚴格來說是在 matchTemplate method 回傳之前, 在 findMaxPoint 裡面被過濾掉了, 只留下最佳的比對結果位置.

public Point matchTemplate(int x, int y, int w, int h, int method ) { float[] sourceImgData = getFloatPixels(sourceImgBI, x, y, w, h); //Print sourceImgData //displayBufferedImage(getImageGrayFromFloat(sourceImgData, w, h), "sourceImgData"); this.cvMatchTemplateFloat = cvMatchTemplate(sourceImgData, w, h, this.templateImgData, this.TEMPLATE_W, this.TEMPLATE_H, method); RESULT_W = w-this.TEMPLATE_W+1; RESULT_H = h-this.TEMPLATE_H+1; //System.out.println("result: <"+RESULT_W+","+RESULT_H+">"); //System.out.println("result.length =" + this.cvMatchTemplateFloat.length); Point resultPoint = null; if ((method==MatchTemplate.CV_TM_SQDIFF) || (method==MatchTemplate.CV_TM_SQDIFF_NORMED)) { resultPoint = findMinPoint(x, y); } else { resultPoint = findMaxPoint(x, y); } //getMatchImage(); //displayImages(x, y); return resultPoint; } private Point findMaxPoint(int x, int y) { int maxIndex = 0; float maxValue= Float.MIN_VALUE; for(int i = 0 ; i< this.cvMatchTemplateFloat.length; i++) { if (this.cvMatchTemplateFloat[i]>=maxValue) { maxValue = this.cvMatchTemplateFloat[i]; maxIndex = i; } } int max_h = maxIndex / RESULT_W; int max_w = maxIndex - max_h*RESULT_W; //System.out.println("max point: <"+(max_w+x)+","+(max_h+y)+">"); return new Point(max_w+x, max_h+y); }

這樣一來事情就很簡單了, 我們另外加上了一個 matchTemplateMultiple method, 使用動態決定 Threshold 的方式來過濾出最好的幾個比對結果, 因此可以獲得多個比對結果.

但我覺得有趣的是, 很顯然地 Java OpenCV Component 本身就具有偵測到所有可能比對結果的 Capability, 只是由於他只提供了 matchTemplate 的 Interface, 因此形成了 Functionality 與 Capability 不相稱的情況. 基於 Encapsulation 的原則, 我們不可能從 Interface 就得知 Java OpenCV Component 的真實 Capability, 但是透過知道 Java OpenCV 原本的 Capability, 卻使得我可以評估花較少的 Effort 去增加 Java OpenCV 的 Functionality, 變相地增加了 Java OpenCV 的 Re-usability.

之前會說希望把 Java OpenCV 看成單一 Component 而不要管 Adapter 身份是因為此 Case 有點特殊, Adapter 本身本來就可能對於原本的 Component Functionality 有遮蔽的作用. 但我認為對於一般 Component 來說也可能會有此現象發生, 如果可以有辦法偵測或是表達 Component 本身的 Capability 與 Functionality 之間的差異, 或許會是一件很有用的資訊.

Software Cinema

Restaurant versus Application, Service, and Cloud

Recovering A Missing Simple Configuration File

Graph Cut Image Segmentation with A Center ( Star Shape Prior )

That's Not What I Sent

Know both Design Abstraction and Implementation Detail ever Resourceful

Play Sound using Virtual MIDI Piano Keyboard

最初學 Programming 時的作業樂趣

Proceedings Review of the 5th International Conference on Software Engineering Advances (ICSEA 2010)

"Implicit" Software Engineering Journals

To Have More "Replaceable" Distro. is Good

神速的 Justin.tv 守門員

真是夠了...

Picasa 3 Web Connection Failed (Login Failed) on Linux

Boot and No Screens Found [Solved ... ?]

Supporting SQL in DBMS

SE 的研究工作是你想的這樣嗎 ?

Notes on SEKE 2010 (二)

Notes on SEKE 2010 (一)

Application Issues of QR Train Ticket

2010 開放原始碼創新應用開發大賽

Learn-By-Study versus Learn-By-Programming

Knotify4 Crashes Mandriva Sound System

Firefox 3.6 很慢的問題...

International Computer Symposium 2010 上線

筆記: AIO 觸控生活應用程式競賽

OpenFoundry Attack (三) Downloads versus Lifespan

OpenFoundry Attack (二) Project Downloads

OpenFoundry Attack (一) : Project Creation Statistics

How Matplotlib and NetworkX Work Together : A Case Study on Figure Instances

Consultant Community Service

Online Web Service Monitoring based on Constraints from Requirements

Operating NS3 with Python

Continuous Game Content Provision

Cloud Computing Bibliography for Software Engineering

CCE Posters

A Very Very Short CSCST 2010 Review

Game-based Competitive Learning

Johnny Mnemonic Again

Platform Selection in System Analysis - About Apple's Policy

Online Game that Requires Specialists...

Paper Bad Smell Detection (2)

Dynamic IEEEXplorer Online Limitation ?

After You Re-Install the SCIM...

The Importance of Vision

Analysis, Design and Implementation

USB keyboard light

Ultra Motor A2B electric bike

在 Compiz 下讓 SMplayer (MPlayer) 能播 RMVB 的簡易方法

Pixnet 高招阿

大學網路排名 : 不知道是評比的人有問題, 還是解讀的人有問題 ?

惡臭夜襲府城...

意外的發現

There's Plenty of Room at the Bottom

音樂情緒研究問卷

Manage Correlated Data Across Services ?

Pixnet 出包的第七天

Joomla 1.5.x 重大密碼漏洞, 需升級至 1.5.6

這是誰的問題 ?

Will CloudAV, the AntiVirus Cloud Works ?

Bookmark Mindmap

The Connected OS and Midori from Microsoft

Two Final Projects Inspired by Audi for Beginners

Something about Library 2.0 (1) : Digital Library

恐怖的 Adeona

James Gosling's Q&A Podcast at Java One 2008

中央氣象局什時會整合 Google Earth ?

Audi's Travolution, Towards Future Traffic Control : Act After Negotiation

Travel Plan Digg + SOA Travel Planning

Defining Operational Scalability

Beyond Single-Page Web Search Results, and ... What's The Next ? Community Page Ranking ?

Twitter + Google Maps Should Go Beyond TwitterVision

Something about Cloud Computing : 軟體產業的二次分工 ?

Linux 市佔率提昇的影響 ?

從LED七段顯示器 到 用宿舍燈光玩貪食蛇

也是一種 Biosignal Decvice

Document Built-In Formation Test

利用 Twiddla 遠距討論 Design Diagram

Multi-Languages Adapter

街頭垃圾壓縮機 與 Service-Oriented Computing

從LED七段顯示器到用宿舍燈光玩貪食蛇

街頭垃圾壓縮機與 Service-Oriented Computing