Software Cinema

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

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

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

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

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

過去兩三個禮拜 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 的概念幾乎可以用在任何地方, 這能不恐怖嗎, 光用想的我雞皮疙瘩就起來了 = =

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

上個月的 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

我必須承認, 儘管之前略聞 OLPC 帶來的爭議, 在今天看到這篇 One Laptop Per Child Foundation No Longer a Disruptive Force 之前, 我沒有好好想過 OLPC 本身可能的負面影響.

Walter Bender : I would challenge that as being the critical dependency. I think doing it was critical, because it’s not real until you do it. We’ve demonstrated that this can be done. We’ve gotten the world to be interested in doing it. Now we have to let more people participate in the doing and not try to control it and own it.

只在 ZDnet.com 的新聞稿上看到 IBM 的 Lotus Symphony 介紹文章中有一個有趣的觀點 (不過沒找到原文) :

IBM的主管表示，這項策略不直接與微軟Office競爭，而是把文件當作「容器」(containers)，儲存工作流程與協作應用程式內的資訊。

Users can enjoy the easy-to-use interface and online community for templates, tips and support.

Businesses can control software acquisition and upgrade costs, provide ability to compatibility with Microsoft Office file formats, protect future access to documents with support for ODF and support a global workforce with Lotus Symphony's native language support for over 23 languages.

Developers can extend their applications with the power of Lotus Symphony through support for plug-ins and, when the Lotus Symphony editors inside Lotus Notes are used, rich composite applications.

剛剛看到一份寫法有趣的投影片 " MIS 進化論, 綠化你的工作 ", 作者是 KnightFeng (馮正青), 主題在提倡全綠化系統. 詳細內容在投影片中寫的很清楚了, 在此不多說. 此處所謂的全綠化系統很顯然的是只全由 portable components 所組成的系統.


正如投影片中所舉出的已綠化軟體實例, 有大量的常用軟體事實上都可以找到綠化的版本. 然而應用程式與系統環境作綠化切割只是第一步, 我認為比較困難的部份是再把 data 的部份切割出來, 以及整體軟硬體系統的支援. 綠色軟體除了一般認為的體積小, 佔用系統資源少, 以及不需要在系統環境中留下拖慢系統速度的無用資訊之外, 如果會與系統中的 data 有很強的相依關係, 在我看來仍舊跟以前一樣, 是不能夠在不喜歡它的時候, 很爽快地進行 " 分手 ".

另外整體軟硬體系統的支援也是帶起流行的重要因素之一. 目前的環境中, 大部分人還是習慣使用自己的一台 PC, 或是 Notebook, 上面再安裝各種軟體. 這種情況下其實綠色軟體能發揮的優點有限. 但是全綠色系統的好處在於整個系統組成的 Flexibility, 以及我們對於軟體進行選擇的 Freedom. 這方面相關的進展我認為包含投影片中提到的 OLPC, 以及前一陣子有 announcement 的 BUG Labs. 特別是 BUG Labs, 可以想見上面的軟體其實都應該在某個程度上符合綠色軟體的定義.

不曉得到那時候, 過去在 Software Engineering 前期鮮少受到重視的 Portability properties, 會不會變成一個 "Embedded (must-have) Property".

記得在五年前吧, 當時台北捷運剛剛落成不久, 恰好搭上城市無線網路以及寬頻資訊的夢想起飛, 於是在台北捷運內以及台北火車站就出現了兩個後來被證明沒什用的東西 [1]. 一個是捷運生活站, 一個是無線上網桌.

無線上網桌的立意是認為許多現代(當時)台北市民是帶著 Notebook 到處走的, 特別是上班族, 在捷運站內已經有提供無線網路的情況下, 當然會希望手上有 Notebook 的市民如需要收收信件之類的可以利用無線網路. 但是 Notebook 沒有乾淨平坦的地方可以放置, 在使用上是非常不便的. 當時我覺得立意還不錯, 只是看到設立的點少之又少, 不免覺得奇怪, 如果真的評估有此需要, 如此少的設點不會造成供不應求嗎 ?

當然後來的情況證明我錯了, 也顯示出事前的評估, 相關單位應該沒有認真作過調查, 只是提出個看起來覺得不錯, 但是實際上卻沒人要用的方案 (找了許久終於找到有人用的照片了: 看這篇文章). 捷運生活站也是一樣, 我還沒有看過有人用過 ^^b

現在好啦, 就在大家邊用各種 Mobile PC 邊抱怨畫面太小, 操作介面太小, 接鍵盤很不方便, 可攜帶曲捲式的軟鍵盤很難按...blahblah...終於 ! 首先, 我們有了這個 : (圖片來自於 forwarding email, 很抱歉我查了很久查不到出處)



上面的是日本公司的產品, 但是記得幾年前看到的最初 prototype 是印度公司首先做出來的.

然後呢, 我們又有了這個 ( pictures are referred from here [2] ) :


好吧, 雖然說我連他怎樣投射出影像來的都看不清楚, 但是我承認我還真想要這兩個東西...我相信應該很多人也會想要.

如果在不久的將來, 可能是一年內, 這些東西成功量產, 商品化了, 似乎人手一台的可能性也頗高. 這樣我們是不是也要針對這些應用建造公共設施呢 ? 畢竟投影的鍵盤也是需要略為平坦乾淨的平面阿, 畫面的投影也不是隨片找個花花的牆就可以, 如果我們再考慮到 privacy 呢 ? 會不會以後在捷運站看到把平常沒在用的臨時投票所拿出來擺在那裡給大家用, 有點像是公共廁所的公共電腦室 ^^b. 而...會有人用嗎 ?

而這些應用的另一個有趣的觀點是, 似乎電腦的硬體部分逐漸真正的 "embed" 到城市的硬體設施裡了, 而不再是大家需要隨身帶著走的東西. 以後我們待在身上的是屬於自己的 software, 以及 private data, 但是 hardware 卻是利用公共設施來作為 software 的載體, 大部分的 hardware 我們都可以不用再買了. 考慮到產業界會有的轉變, 這是個近在咫呎, 非常有意思的未來.

選擇 software 這條路, 的確是蘊藏著無限的可能 :)


References

[1] 慕容理深, "道具、玩具、證據," URL : http://blog.roodo.com/elysii/archives/3577609.html
[2] Long Tran, "Projection Mobile Phones," URL : http://www.yankodesign.com/index.php/2007/10/16/projection-mobile-phones/

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

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

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

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