Software Cinema

不知道為什麼我的 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 可以打的小狐狸, 覺得這真是高招阿.

如果點選看誠意...


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


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


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

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

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

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


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

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

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

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

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

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


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

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


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


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

在 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 的思考過程中而已.

偶然看到台大電信所的研究生在 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.

利用不同的 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 似乎難度大的許多, 況且允許的動作也不是簡單的刪除而已.

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

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

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

• 目前已解決/常問的FAQ整理
• 痞客邦新後台BUG匯集區
• 三天內就修好你才爽的 Bug

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

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

• [公告] 8/20 目前站上狀況報告
• [公告] 8/21 目前網站狀況報告
• [公告] 8/22 本日重點修正進度
• [公告] 8/23 目前網站狀況報告
• [公告] 8/24 網站現況說明
• [公告] 8/25 重點事項說明與修正進度報告
• [公告] 8/26 網站狀況說明

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

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

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


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


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


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

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 預設的密碼編碼.

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

前幾天重新在找一些 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 沒幾天的文章, 也出現了這樣的情況 ?

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

( 修改一下發表時間以及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

前幾天在 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 的討論有相關之處.

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 的需要以及定義, 我想基本上還是相同的.

前幾天寫了關於 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 可以用在甚麼樣的地方, 發揮甚麼樣的價值.

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 忽然變成了一個熱門關鍵字 :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 在 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 的發音 ) 不知道怎樣查, 嘗試幾個都找不到 @@

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

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


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

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

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


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

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

德國汽車大廠 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

最近要到蘭嶼去玩幾天 (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 的力量來建構這樣的環境, 有效地在資訊進來之前就先篩選, 同時也讓回給使用者的規劃有最高的有效性.

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

本週實驗室會議由學長報告了 [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

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 出現 :)

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 的業者這當然是前兩者 :)

前陣子 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. ^^

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

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


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

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

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


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

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

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

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

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


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

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

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

昨天幫一個學弟進行碩士口試的 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 是一個免費的電子白板服務, 之前為了跟在美國的學長討論 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 摟 :)

不是正式的 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
  

在癮科技看到的這篇新聞 : 費城將在街上設置垃圾壓縮機 很有趣, 等同於是把小型的垃圾車放置在城市中固定的地點, 透過科技的進步來增加垃圾收納量, 以及降低環境污染度, 克服過去公設垃圾桶會有的許多缺點.(以下圖片引用自 KYW Newsradio)

不過之所以會特別想在這記上一筆, 並非僅是因為這事有趣.

過去在談論 Service-Oriented Computing 時, 我們似乎都會很自然的想到各種商業應用, Shopping Services, Business Services, Travel / Hotel / Transportation Services 等等, 然而回歸到現實面, 其實還有很多非常小, 但是很實用的 Services 經常就被忽略.

像是很常遇到的, 走在街上, 可能是因為剛剛買了小吃, 飲料, 或是打噴嚏的衛生紙, 很容易的手上就會有想丟掉的垃圾. 如果是在不熟, 非生活圈的地方, 一時之間要找垃圾桶就不是如此容易的事情. 如果費城的垃圾壓縮機可以在 Service-Oriented Computing 基礎設施上搭配提供這種 垃圾 Service, 應該會讓計畫的效果更好吧.

這種 垃圾 Service 看起來很小很無聊, 可是需要的時候功用卻是很大的.

記得大約是兩年前作 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 今天正式公佈了三個預計於秋季釋出( 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 界的巨人阿~~

今天看到 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 摟 ~~ )