Software Cinema

在 Object-Orientation Paradigm 中, 由於 OO 的特性有別於 Conventioanl Paradigms, 因此 Authors 為採用 Object-Orientation Paradigm 的 Project Team 以及 Developers 提出了兩種 Processes. 分為 Macro Process 以及 Micro Process, 分別適用於較大型的軟體長期開發, 以及少數 Developers 甚至單一 Developer 的短期開發. 同時解決, 在 Software Development Project 過程中, 無可避免的, 兩種 Processes 必然共同存在並 競爭 的問題.

由於本書特別分為兩種 Processes 提出, 適用於不同的情況, 且在同一個 Project 內往往需要這兩者的互相存在配合, 達到 Balance.

• Macro Process : 分為 Conceptualization, Analysis, Design, Evolution, Maintenance, 以 Waterfal 為基礎而建立, 適用於較中大型的 Projects, 較 High-Level 的 Control

• Micro Process : 分為 Identify Class and Objects, Identify Class and Object Semantics, Identify Class and Object Relationships, Specify Class and Object Interfaces and Implementation, 並且持續循環.

對於以上兩個 Process 的每一個步驟, 作者都用以下五個 Factors 作分析,

• Purpose
• Product
• Activity
• Agent : Agent 的用詞比較不常見, 同常會用 Developers, 但是在此書中, 在此探討 Project Staffing 的議題, 的確用 Agent 的詞會比 Developers 的用詞較為廣而貼切
• Milestones and Measures
  

雖然在書中提到了兩個 Processes 在Pproject 中必須維持合適的 Balance, 但是隨著不同的 Projects, 可能會需要不同的 Balance, 書中對如何達到這樣的 Balance 並無提供明確的 Solution, 或許這仍是未解的問題.

References

[1] Grady Booch, Object Solutions : Managing the Object-Oriented Project, Addison Wesley, 1996

今天在改 Project 內一部分程式碼的 Bug, 看到 Team Member 用了 os.chmod 來改系統檔案的權限. 之前沒用過, 因此 mode 的部份怎樣調整就查了一下 API Document. 沒想到 Document 裡也只有 mode 的選項列表, 沒解說 = =

查了一下才發現解讀法, 整理如下 :

S_IRGRP    S_IROTH    S_IRUSR

S_IWGRP    S_IWOTH    S_IWUSR

S_IXGRP    S_IXOTH    S_IXUSR

S_IEXEC = S_IXUSR
S_IWRITE = S_IWUSR
S_IREAD = S_IRUSR

S_IRWXG = S_IRGRP | S_IWGRP | S_IXGRP
S_IRWXO = S_IROTH | S_IWOTH | S_IXOTH
S_IRWXU = S_IRUSR | S_IWUSR | S_IXUSR

解讀方式如同上述的顏色標示, R = read, W = write, X = execution ; 而 GRP = group, OTH = other, USR = user, 對照到 Unix 系統的權限設定其實就很清楚了. 而後面的更為複雜的標示, 就是前面基本標示的混合而已.

前幾天在看 AntiPatterns [1] 時發現一個有趣的地方, 在書一開始, 作者就先來了個 AntiHype Pattern, 直指過往的 Software Technologies 每一個新的世代都描繪了相當的理想, 但是最終卻都沒有夠達到當初的承諾.

書中總共列出了七個主要的趨勢 ( Trends ), 以及他們應該要能夠做到的事, 分別是 Structured Programming, Artificial Intelligence, Networking, Open Systems, Parallel Processing, Object Orientation, 以及 Frameworks.

而下一頁則是畫了一張圖來表達 AntiHype ( 引用自 [1] )


但有趣的是, 上面明明提到了七個趨勢, 但圖上卻只有畫出前五個 Paths. 是單純的因為圖畫不下七個 Paths, 還是說在當時的時空環境下, 作者其實也無法對 Object Orientation 以及 Frameworks 做出判斷呢 ? 如果是後者, 那麼真好奇將近十年後的現在, 作者是否會想改這張圖呢 ?


References

[1] William J. Brown, Raphael C. Malveau and Thomas J. Mowbray, AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis, Wiley, 1998

Conky 1.5 在 Mandriva 2008 沒有辦法直接從 Package Manager 安裝, 而手動安裝進行 ./configuration 之後, 接著進行 make 時會出現以下的錯誤訊息 :

<br />/usr/include/linux/if.h:119: error: redef inition of 'struct ifmap'<br />/usr/include/linux/if.h:155: error: redef inition of 'struct ifreq'<br />/usr/include/linux/if.h:205: error: redef inition of 'struct ifconf'<br />
這是由於 ifmap, ifreq, 以及 ifconf 分別在 /usr/include/net/if.h 以及 /usr/include/linux/if.h 中被重複定義了的緣故.

由於 Conky 在 make 過程中還是會需要 /usr/include/net/if.h , 因此也不能直接暫時把他移除掉. 取而代之, 先把 /usr/include/net/if.h 備份之後, 編輯 /usr/include/net/if.h , 然後把 ifmap, ifreq, 以及 ifconf 都暫時註解掉.

這裡要注意的是, 如果仔細比對 /usr/include/net/if.h 以及 /usr/include/linux/if.h 兩個檔案, 會發現 ifmap 是相同的, 但是 ifreq , ifconf 有許出入.


不過我很勇敢地還是把 /usr/include/net/if.h 的部份註解掉了. 於是就能夠順利作 make, 同時 make install 後, 就能夠直接在 command line 執行 cronky 了.

最後記得要把 /usr/include/net/if.h 給恢復原狀 :)

今天因為實驗室的 MoinMoin 有使用者忘記密碼, 但是透過 MoinMoin 自動寄回 encryption 過後的密碼串雖然可以登入, 但是看不到明碼還是不太方便, 要進行修改密碼時卻發生 exception, 因此想透過管理者權限修改使用者密碼. ( 其實後來發現是該使用者檔案的權限不知為何被設成 -rw-r-----, 一般的使用者權限是 -rw-rw----, 使得該使用者要重設密碼時, MoinMoin 的修改被系統擋了下來, 因此發生 exception. )

不過當時我沒有注意到這個原因, 直覺地想說利用 admin 去改應該很輕鬆, 結果找來找去, 不知道怎樣直接修改使用者密碼, MoinMoin 的使用者裡面只有詳細的說了 ACL 頁面存取設定, 其他使用者帳號的管理似乎沒有提供好用的介面.

一時衝動, 想說那我直接去改使用者 data 好了 XD

結果費了一番功夫, 不過也多知道了 MoinMoin 對於使用者資料方面是怎樣處理. 在 MoinMoin 下, 使用者資量是放在 instance/data/users (instance 要看當時創造 Wiki instance 時採用甚麼命名) 裡面, 透過特定的編碼方式形成以一連數字命名的檔案. 檔案名稱應該跟創造帳號時間有關, 但是詳細計算演算法未知.

而個別使用者得資料, 除了密碼之外, 其實是以明碼的方式, 紀錄在檔案中. 換句話說, 使用 cat 就可以輕鬆看到使用者資料, 而利用 vi 就可以進行編輯. 但是有一點很奇怪的是, 使用 vi 編輯時, 原本已經在檔案中的內容沒有辦法使用 backspace 刪掉, 只能新增內容進去.

另外注意的一點是, 密碼的 SHA 運算似乎跟帳號以及其他因素有關, 因此即便兩個帳號使用同樣的密碼, 得到的 encryption code 是不一樣的. 也因此我本來想把自己的帳號設定成某個 password, 再把 SHA encryption code 複製到密碼有問題的帳號這個想法最終是失敗.

最後採取的作法是, 修改密碼有問題帳號的 mail address ( 因為無法直接修改, 因此先利用 # 註解掉原來的, 然後加上新的一行 ), 讓我可以在自己的電腦上收到問題帳號的目前 encrypted password, 然後利用此 encrypted password 登入, 再進行密碼修改. 之後就是上面說的, 發現其實不能 reset password 是使用者檔案權限的問題, 所以修改權限後就 ok 了.

而修改後, MoinMoin 不是只有更新使用者檔案內的該項 properties 而已, 而是會將整個使用者檔案重寫, 因此前面註解起來的部份會被抹除.

簡單來說我就是繞了一大圈, 解了一些本來只要調整檔案權限就可以解的問題就是了 Orz

不過從機制看起來, MoinMoin 的使用者資料在系統管理內要很小心作權限控制, 一般使用者應該是連進行閱讀都必須被禁止才是.

最近在上柯泰德老師的短期英文編修訓練課程, 邊上就在想一些有的沒的. 最初的三週課程在說明基本的編修原則, 舉很多例子說明. 而其中有很大一部份, 例如精確寫作 (Write for Conciseness) 以及明白寫作 ( Write for Clarity ) 兩大項目中的一些原則, 功用在於不破壞原本要表達的意義下, 讓文句更通順易讀, 同時避免因為一些混淆不清的寫法, 錯誤的時態, 導致讀者誤解了要表達的原意.

這讓我想到 Refactroing. 雖然不是說兩者是一樣的, 但是如果把 Paper 內容當作 Source Code, 的卻有很多相似的地方. 同時柯泰德老師也提到在他的網站上, 蒐集了很多台灣人寫 Paper 常犯的錯誤模式, 建議我們有空可以多看, 並嘗試練習修改, 平日寫 Paper 就比較容易發現不順的地方. 因此很正常地我就想, 如果有一個 Paper Bad Smell Detection Tool 不是很好嗎 ? 邊寫 Paper, 就會自動根據常見的錯誤模式, 提醒我可能要多加修改的地方.

稍微想了一下, 其實只要有一些錯誤模式的 Knowledge 已經存在了, 系統本身似乎也不是那麼難作, 不過準確率可能會是一個問題就是了. 但無論如何, 應該還是比自己看有效率
如上圖, Bad Smell Pattern Repository 用來存放常見的 Paper Bad Smells, 亦即常見的錯誤撰寫模式. 而 Paper Bad Smell Detector 首先對於輸入的 Latex Document 進行拆解,　可能是以單句為單位拆開. 然後將每一句利用 Regular Expression 與 Paper Bad Smells 進行比對, 辨認出可能需要修改的地方. 最後責成修改指引報告 ( Modification Indication Report ), 給 Paper 撰寫者作為參考. 最終的修改決定權還是在於撰寫者, 畢竟此 Tool 不可能猜測撰寫者的原意, 只能根據編修的累積知識給予建議.

有這樣的 Tool, 要寫出通順的 Paper 應該會輕鬆一些吧 :)

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

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

在物件導向概念裡, 一個 Object 可以看成是 Data 以及允許改變這些 Data 的 Method 之集合. 在一份文件上, 很顯然地文件裡面用文字或是圖片, 甚至是影音檔案所想要表達的知識是我們需要的 Data. 過去我們可能習慣於直接把文件當作 Data, 但是上述的文字似乎是想把文件當成 Object ? 如果一份文件除了本身所紀錄的 Data 之外, 還紀錄了可以調用哪些 Web Services 來對於文件作存取, 那麼其實可以把整個文件視為一個 Document Object. 此 Document Object 具有 State : 就是 Data, 以及目前執行中的 Web Services, 也具有 Dynamic Behavior, 視乎調用了哪些 Web Services.

這樣一來過往 Document Editor 的角色就更有趣了, 將會變成一個 Web Service Management Tool, 負責結合不同的 Web Services 到 Document Object 上, 每一次的編輯事實上是在不斷的調整Workflow.

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.

在 Lotus Symphony 的網站中也提到了採用 Eclipse Rich Client ( ERC ) 想法, 對於 Lotus Symphony 特別加強 Plug-ins 的支援. 從這點看來 Lotus Symphony 可能是 IBM 在過往 Lotus Smart Suits 的失敗後, 歷經 Eclipse 轉投 Open Source Community 的成功, 以及自身在 Web Service Development & Solution 的領導地位後, 轉而想在 Microsoft Office 以及 Google Docs 兩個極端之間殺出一條不同定位跟發展模式的產品.

Jiglu 能夠自動擷取你的 blog 內的文章內容(當然是在你的允許之下), 經由適當的分析(其實是不知道他怎樣分析), 會自動產生出一組標籤, 可以用來作為你的 blog 內的文章之 index terms (tags).

(以下圖片取用自 Jiglu 官方網站)


如上圖所示, 你可以根據自己的生活在的 context 紀錄下各種主題的 information (articles), 存放累積在一個 blog 內, 而 Jiglu p 分析結果產生的 index terms (tags), 把這些 articles 作 grouping 以及 connection.

connection 的方式是透過在不同 group 內的相同文章作 group 間的 connection.

我認為 Jiglu 算是 Horris Wu [1] 等人的 collaborative document repository 的簡易版之實現, 透過在 Jiglu 官方網站提供對於不同的 blogger 之間的 articles, 利用共同的 tags 進行收納, 則可以連結不同使用者的 information (articles).

不過實際試用一陣子, 覺得 Jiglu 在 blogger 上的使用還沒有想像中的強大 :

• 第一, 還沒有支援中文, 只有英文的部份,
  
• 第二, 只會整理 blogger 目前頁面上可以看到的文章, 之前的似乎不會列入關鍵字統計分析 ( 或是我沒有設定好 ? )
• 第三, 利用他額外的功能, 例如 TreeMap 等等, 速度超級慢, 不是一般使用者願意等待的時間
• 第四, 我本來期待他的 service 真的 smarter [5] 一點, 但是結果似乎也只是一般的關鍵字分析, 沒有類似 ontology 的關鍵字關係幫助使用者建立較具有意義的文章連結結果, 或是會自動推測文章的 related contexts
  

所以用了一陣子就把他 disable 了 XD , 希望 Jiglu 已後會變得更強大, 當時候我再來用吧 ^^b


References

[1] H. Wu and M. Gordon, "Collaborative Structuring: Organizing Document Repositories Effectively and Efficiently," Communications of the ACM, vol. 50, no. 7, pp. 86-91, July 2007
[2] Jiglu 官方網站 : http://www.jiglu.com/
[3] Jiglu 社群網站 : http://www.jigluhood.com/
[4] 相關文章 : Jiglu 用自動化標籤來找出部落格內的相關文章, http://playpcesor.blogspot.com/2007/10/jiglu.html
[5] 相關文章 : Jiglu: Smarter Contextual Tagging, http://www.zoliblog.com/2007/10/15/jiglu-smarter-contextual-tagging/
[6] 相關影片 : Jiglu: Automatic tag creation for bloggers and web publishers, http://www.downloadsquad.com/2007/10/16/jiglu-automatic-tag-creation-for-bloggers-and-web-publishers/

在 Martin Fowler 的 Refactoring 書 [1] 中提到 :

Refactoring is the process of changing a software system in such a way that it does not alter the external behavior of the code, yet improves its internal structure.

然而, 究竟 external behavior 如何認定, 甚麼算是 external behavior, 而甚麼又不是呢 ?

也許我們應該從 refactoring 的目的來看. refactoring 的目的是為了整理目前的 code ( 目前探討 refactoring 停留在 code level 居多, 因此沿用 ), 以便以較少的 time & efforts 進行後續的 software changes [2][3] . 因此 refactoring 可以視為是一種 data pre-processing 的技術, 目的在於把 data, 也就是 code, 調整到一個方便進行後續處理的狀況. 而對於後續要進行的處理來說, 其實 refactoring 的步驟並非是必須的, 只是為了降低整體程序的花費而進行 refactoring, 因此自然不希望在進行 refactoring 的過程中, 會改變 code 本身對於原本要進行的 software changes 之意義. 而這些不允許被改變的部份, 就是 external behavior.

換句話說, 在 refactoring 中, external behavior 的認定跟所要進行的 software changes 有關, 而所要進行的 software changes 又跟 software engineers 有關. 最常見的可能是由 test cases 所保證的 external behavior, 這類型的大多跟 software functionality change 比較有關, 也比較容易理解.

但是從另外一個角度來說, refactoring 畢竟還是改變了 code structure, 對於整個 source code 的意義還是造成了些許的改變, 只是這樣的改變對於要進行的 software changes 來說是否需要關心罷了. 比如說 pull-up-method, 改變前後的意義考量到原始的設計還是有差別的. 只是當我們的目的是方便後續的 maintenance 工作時, 這個差別就會被忽略不計.

然而這樣對於 software maintenance 長期來說是好事嗎 ? 或者只是炒短線的作法呢 ? 畢竟在 [2][3] 中似乎都沒有針對往後其他無關原本預計進行的 software changes 作探討. 然而所作的 refactoring 的的確確影響到了之後相關的 maintenance 工作之進行. 我們應該不能僅僅針對所預計進行的 changes 作有效評估才是.


References

[1] M. Fowler, Refactoring: Improving the Design of Existing Programs, Addison-Wesley, 1999.
[2] E. Stroulia and R. Leitch, "Understanding the Economics of Refactoring," In Proceedings of the 5th International Workshop on Economics-Driven Software Engineering Research (EDSER-5): The Search for Value in Engineering Decisions, May 3-4, 2003, Portland, OR, USA, pp. 44-49.
[3] R. Bahsoon and W. Emmerich, "Applying ArchOptions to Value the Payoff of Refactoring," In Proc. of the 6th Int. Workshop on Economics-Driven Software Engineering Research, Edinburgh, Scotland. pp. 66-70. IEE.

StarCraft II 剛剛在韓國完成還很神秘的 Zerg 初次亮相, 雖然 Blizzard 向來對於正式發表商品相當謹慎, 不過就現狀看起來應該很快就會有 beta 版本出現了 ?


目前對於 StarCraft II 的討論大多集中在新單位的能力, 以及跟舊單位的比較, 相關的評論也因此而生. 相對於遊戲本身, 似乎沒有看到關於 StarCraft II 整體商業運作模式的討論.

與 StarCraft 一代相比, 目前的整體遊戲環境已經改變很多 -- 不管是在網路科技的演進以及社會對於電子遊戲的觀感, 最顯著的例子就是韓國電競的發展, 以及 WarCraft III, World of WarCraft 的成功. 因此很好奇是否 Blizzard 會想藉由 StarCraft II 在遊戲業界做出革命性的發展 ( Blizzard 的傳統就是令人驚艷阿 ).

舉例來說, How about Game 2.0 !?

到目前為止, 大部分成功的 Game, 不管是 Online / PC Game, 其開發都還是掌握在遊戲公司手裡, 而非放手到玩家身上. StarCraft 一代最偉大的事情有兩項, 其一是出乎想像的種族平衡性, 其二就是偉大的地圖編輯器. 這兩點也是韓國電競在 StarCraft 項目如此成功的最重要因素之一. 地圖編輯器在某個程度上算是把遊戲的一部分開發讓玩家可以參與, 然而地圖編輯器使用的門檻其實有點高, 同時受限於 StarCraft 一代本身的限制, 能做出的新遊戲效果其實有限. 因而投入開發新地圖以及設計任務的玩家其實不夠多, 若非韓國電競延續了 StarCraft 的生命, 恐怕地圖編輯器被發揮的空間要更小一些.

如果我們轉個彎, 套用 Web 2.0 上 Google Adsense 的概念, 讓製作優良 StarCraft II 地圖以及任務的玩家可以因而獲利呢 ? 是否因此可以擴大 StarCraft II 的玩家族群, 同時提昇整體遊戲的耐玩度 ? 這不是不可能, 至少 WarCraft III 在台灣就演變成三國外掛模組遠比正式遊戲受歡迎的奇特現象. 不過相對來說, 地圖以及任務製作器必須更加強大以及易於使用才行. 同時下載新的地圖任務付費機制也必須相對明確建立.

更甚者, 如果 StarCraft II 開放部份 API 以及 License, 使得其他小型遊戲公司可以基於 StarCraft II 製作嶄新的遊戲, 或是支援不同的平台, 進而在Blizzard 的收費授權之下販賣. 換句話說, 是把 StarCraft II 作為一個 Product Family 的 Backbone Framework.

在 SourceForge.net 上有一個 project 就對 StarCraft 一代做了類似的事情. StarGus, 這個 project 建立一個依賴於 StarCraft 的模組, 內含一個取代原本 StarCraft Engine 的 StarGus Engine. 透過 StarGus, 可以在 Linux 上運作, 以及可以自行對於不同單位作不同的參數設定. (以下 ScreeShot 取自 StarGus )


不管如何, 期待 StarCraft II 能夠帶來除了 Game 本身以外, 給予整個世界更大的影響以及改變 : )

在射手網下載的字幕檔案有時候雖然內容正確, 但是搭配的影片本身版本不對, 因此時間軸不合, 字幕與影片中的對話會有一段時間的差距. 之前在 Windows 上會利用一些調整字幕時間的軟體做處理, 但是在 Desktop Linux 上似乎還沒有類似的軟體.

幸好 SMPlayer 可以直接在播放的同時動態調整字幕以及音訊的速度. 預設調整音訊的速度可以利用 - 以及 + 鍵調整, 而字幕的速度可以利用 z 以及 x 鍵調整.


小缺點是, 如果是直接開啟 SMPlayer, 沒有辦法知道究竟目前偏離開始調整的位置多遠了 ( 例如是已經調快了 10 秒或是 13 秒), 缺乏基準會讓調整過程變得比較不容易, 就像瞄準時有參考物會比較容易一樣.

這點可以透過使用 command line 啟動 SMPlayer 解決. 每一次按鍵調整後, 目前的偏移量都會出現訊息在 command line 中, 如上圖標示的地方, 這讓動態調整可以變得更加方便.

剛剛在 癮科技 看到這篇新聞介紹 : Vodafone將推出Otello圖片搜尋服務 , 簡短介紹 Otello 的服務以及使用方式. 覺得相當有趣的是, 在 Otello 的使用情境 ( usage scenario ) 下, 我們只需要利用既有的各種可進行數位攝影的 device 就能夠進行相關資訊的搜尋, 間接的把搜尋引擎 ( search engine ) 嵌入 ( embed ) 在 device 上變為一種 "service" 的概念, 而不是一個 "software" 或是 "website".


這樣的使用方式無疑地是更符合以及簡化我們的使用習慣. 原本我們就希望看到的東西到進行搜尋之間可以是無縫地進行, 而不是還要把圖片存下, 然後上傳到某個圖片搜尋引擎再進行搜尋, 這樣分開使用不同的 services 實在是太麻煩了.

而很容易聯想到的, Otello 現在支援圖片的搜尋, 未來如果結合光學辨識技術 ( OCR ), 要能夠直接把看到的文字用來搜尋應該也不會是甚麼難事. Seeing is Searching, it's cool !!

奧運 8 搶 3 的錦標賽官方網頁出現了令人傻眼的投手防禦率排行表, 居然把投手防禦率由高至低排名, 是在選爆爆樂投手第一名嗎 ?


負責網頁製作的是 yam 天空, 我說 yam 的工程師阿, 就算你不懂棒球也該做好 domain analysis 吧, 另外承辦單位負責作 validation 的人也在混阿. 雙方都在系統沒有經過 validation 的情況下就上線了, 或許他們有測了 "functionality", 但是原本所建的 test case 就是錯的阿 XD , 再怎樣測結果也會是錯的.

這個例子也充分說明, test case 的確不是在 design phase 或是 implementation phase 再建就好, 而是應該從 domain analysis 一路下來, 階層式地 ( hierarchically ) 建立 test cases.

今天看到某家電動刮鬍刀公司的廣告, 加上手上正在改一篇 Biosignal database 的 paper, 再加上好歹我也算有在作 context-aware 主題, 忽然想到以後是否會有廠商嘗試在電動刮鬍刀上加上完全無關的 biosignal detection device ?

像是這樣 : ( 自 PCHome 購物借用一下德國百靈的商品樣品圖片 )


在括鬍刀片附近, 接觸到下巴臉皮的部份, 可以設置偵測皮膚狀況的 sensor, 在再下方一點可以設置嘴巴氣味的 sensor. 手握的部份, 拇指接觸的部份可以裝設 pulse meter, 側邊可以設置 body temperature meter. 以上這些都跟電動刮鬍刀本身的功能無關, 但是透過電動刮鬍刀本身的 hardware interface, 轉化成為其他 biosignal detection devices 的 interface, 進而把這些 biosignal detection devices "嵌入" ( embed ) 在電動刮鬍刀上.

或許電動刮鬍刀本身不是一個理想的 "母體", 同樣的概念也可以用在其他的日常電氣用品上, 進而讓我們可以在最小的 user interface intrusion 之下, 享受 embedded system 帶來的嶄新服務.

剛剛看到這篇新聞 : 風力發電和鳥類安全, 在報導風力發電引起的鳥類生態問題, 以及一些構想中的解決之道. 風力發電所需要建造的高塔以及風力推動的葉片會改變空中的正常氣流, 影響鳥類的飛行, 尤其對於候鳥的干擾可能造成大量的鳥類死亡意外. 針對這個問題, 其中有個 solution 引起我的注意, 為免新聞連結失效, 節錄內容如下 :

羅賓斯說，較先進的技術也能限制傷害。他說，風力發電機的葉片上可以裝上感應器。羅賓斯說：「如果一隻鳥或者一隻蝙蝠撞上那個葉片，會引起足夠的震動，使得葉片能夠暫時改變角度，避免其他飛鳥撞擊，直到當時的這種緊急情況過去。」

改變葉片的角度，主要的意思是，讓風從葉片上面吹過，而不是推動葉片旋轉。這樣，飛鳥就不會被吸進去了。基本上，這是風力發電機的制動系統。有些人說，甚 至不需要風力發電機上的感應器。他們說，工程師能夠監視雷達和熱成像設備。這就會告訴他們這個地區有沒有任何候鳥群，如果有，就改變葉片的角度。

改變葉片的角度可以使得風在葉片上的施力降到最小, 從而降低葉片的轉速, 加上固有摩擦力以及煞車系統, 應該可以在意外發生時, 甚至是意外發生之前停下風車運轉.

不管是頁騙上的振動偵測, 或是利用監視雷達和熱成像設備偵測, 基本上這都是一個 context-aware 的應用, 對於風車發電來說, 無法忽視來自於 context 的影響. 同時這也是 system security 的考量.