命苦是自找的...

Rick是專案團隊中脾氣非常好的一位工程師，和大多數的工程師一樣，Rick對於寫程式是相當具有熱誠的，在開發領域算是有一定的年資，程式碼的品質堪稱一流，在專案中也時常擔任與客戶端進行技術問題或系統功能溝通的重要角色。

最近一陣子，我們發現Rick常常被突呼其來的電話打斷，隨著電話交談的時間長度，表情上的無奈越顯得明顯而清晰。同時，我們也發現Rick的程式碼開發品質與速度明顯的和過去相比降低了不少。

關心之下，發現Rick其實並沒有任何個人的問題，他只是專注地完成交付公司給他的任務，也就是專案開發的客製化功能設計，但由於客戶端的PM和User，在長期和Rick建立了良好的溝通默契與個人關係之後，開始跳過PM將一些小問題(真的是無傷大雅的小問題)直接請Rick進行系統的極細部調整，也確實，這並沒有花非常多的時間，每一個調整動作都與系統整體的方向不衝突也不相違背，也就是說，這些問題即便依照正常程序經過PM來處理，這些修改依舊不會被PM擋掉，最終還是會發生，Rick也還是會著手修改。而User與Rick也都希望能夠快速地解決這些小問題，省去一些繁文縟節，因此常常跳過雙方PM，進行了規格上的零星修正、UI的小調整或是Bugs的Fix。

發現這件事情之後，我請PM認真地把Rick找來，Rick很委屈的跟我說，他一開始認為這樣能夠提高效率，並且提升對客戶的服務品質，也確實如此，Rick總是擁有客戶端相當好的評價，甚至某些PM無法溝通的技術問題，由Rick出面協助溝通協調，客戶端總是比較能夠理解。時間一長，這樣的溝通模式形成慣例，客戶也在專案中偶而私下請託Rick進行一些工作，但久而久之，Rick的時間開始被無法拒絕的瑣事所佔據，雖然後來推掉了不少，但開了先例，也不好意思每一個問題都直接拒絕，就演變出今天的結果。

這樣的情況，在專案工作中常常發生，不只發生在開發人員，偶而甚至發生在PM身上，儘管制度上我們都設計成必須要記錄每一個修正或程式修改動作，但實務上總是有一定比例的工作在檯面下持續進行著，不僅是專案，在企業內的MIS/IT也常常發生這樣的情況，越過主管的工作指派總是持續在發生著。

程式設計師也很容易依照個人關係，來決定事情的優先順序，PM也容易依照與客戶的交情，來決定規格修改的退讓或調整幅度，長時間下來，讓客戶覺得系統微幅調整的成本其實並非那麼高，甚至專案公司無法堅守最初的專案規格，微幅調整逐漸累積成了架構上的大範圍異動，最終導致專案的時程延誤，成本暴增。

這往往源於一開始的善意，客戶的殺手鐧常常是這樣的一句話：『我知道原本規格是這樣寫的，那這樣的設計，我們實際上根本沒辦法用啊!!!』或是：『我在上個milestone驗收的時候都很幫忙，你這邊稍微調整一下，應該不過分吧』(其實這句話聽起來有威脅的意味)，更多的情形是，雙方在簽約與SA、SD階段，根本沒打算認真把規格搞清楚，很多模糊的空間是刻意保留出來的，為了讓簽約和成交趕快確定。

兩邊PM都在打自己的如意算盤，白紙黑字將來各自表述，規格文字的撰寫模糊到不能再模糊，廠商PM這別心裡想的是，反正將來我生出來的功能只要能符合規格書就好，買方PM這邊想的是反正將來我要你符合我寫出來的規格再簽驗收就行。可是，落在紙上同樣的一段話，只有功能的抽象描述卻沒有具體清晰的量化數字或說明，最終只落得專案在雙方都不滿意的狀況下收場。

規格書上的模糊空間，專案團隊成員與客戶端的私人交情，這看起來八竿子打不著的兩件事情，導致了專案最後的失敗(或瑕疵)收尾，也造成了客戶慢慢覺得：『廠商應該早已把修改或異動成本算在專案裡了』，也難怪台灣的軟體專案總是那麼辛苦，客戶的需求總是那麼難釐清，專案的驗收總是那麼的困難，工程師的異動總是那麼頻繁...

我想跟Rick，也跟Developer說，其實你應該更認真的看待你手上所撰寫的每一行程式，記得，你能夠寫出這一行程式，是累積了少說三五年開發經驗之後的結果，每『一行』程式碼都是你的價值所在，每一段程式碼的修改都是你的產值，請不要也毋須輕易的做人情送給客戶。Starbucks的barista培訓只需要幾個月，他動手花短短的75秒做出一杯拿鐵咖啡大概值85元，而你累積了三五年功力，花了一個下午，喝了三杯Starbucks咖啡才修改完成的功能卻是免費???

Developer, Please, 你的一行程式碼的價值(價格)其實遠遠超過你的想像。

----------------------------------
後記：在台灣，有太多的程式設計師、專案團隊以超級賤價的報價去硬生生地接了專案餬口，最終只是導致專案品質下降，同時也讓客戶覺得不就是寫寫程式或做個App嘛，要花那麼多錢嗎? 畫一幅畫是個專業，寫程式也是專業；畫一幅畫是一門藝術，寫程式也是一門藝術。

台灣的電子代工或製造業，總是以調整製程壓低價格去賺那幾塊錢的毛利，台灣的軟體業也想走這樣的路，步上一樣的後塵嗎?

走進廚房，才知道食材的好壞...

前幾天應邀到社群舉辦的講座，介紹雲端運算與行動裝置的整合，席間提到了Silverlight技術，不免又有一些開發人員問到這樣的問題：『聽說...微軟對Silvrlight的支持和更新將會如何如何...，這部分開發人員要如何因應』?

面對這類問題，我最近一年少說不只回答了10次，首先，『聽說』這個前提就很是問題，雖然報紙偶而會有猜對的時候，但捕風捉影總是佔了大多數。

另外就是開發人員要如何因應這種事情。

我始終覺得，沒什麼好因應的，開發技術本來就是這樣，特別是展示層開發技術，我在這篇文章中曾經說過，展示層技術的持續精進與改變是必然的趨勢。你回頭看，Wii和Kinect都是最近這幾年才發生的事情，但現在已經開始慢慢出現在我們LOB應用的UI裡面了。而觸控技術早就有了，最近五年才出現在手機上，如果回頭看過去20年，從黑底白字的文字模式，到Mac/Windows的圖形介面，到現在的RIA(Rich Internet Appication)開發技術，少說有沒有換過10種開發方式?

請開發人員接受一個事情，就是presentation(展示層)的UI開發技術，是每隔兩三年就會大改一次的，ASP.NET從2002年誕生到現在，共四個版本，也不過八九年，中間還有AJAX技術進來攪局和jQuery的崛起，還有現在的MVC設計模式，這些技術都是持續在精進與改變的，不多人在2005年之前，會預知後面AJAX應用成長的那麼快(中間也跟網際網路頻寬與行動裝置拖不了干係)，而現在也不多人能100%論定是否HTML5將變成未來可能的一種趨勢。

如果你比較Flex/Silverlight/HTML5，然後開始聽到iOS對Flex有些疑惑，Silverlight沒法跑在iOS和android上，HTML5又不夠成熟，那怎麼辦? 要投資哪一個? 哪一種技術可以讓你長治久安?

長治久安? 答案當然是沒有! 沒有一種開發技術是可以讓你在這個變動迅速的時代，軟體生命週期爆低的世代，可以長治久安的。沒有!

但你確實可以選擇一個對自己來說投資成本比較低的方案，例如，著眼在跨平台，不同的device對你來說差不多，只是呈現出一個介面，你不會用到Device上的LBS或Camera，大部分的運算在伺服器端，那ASP.NET/JSP/PHP依舊是比較好的選擇。如果，你要建置的是企業內的LOB，你可以掌握幾乎所有用戶端的狀況，而過去你是.net的開發人員，那Silverlight絕對是不二選擇。其餘均可類推...

不同的技術就是用在不同的scenario，彼此之前從沒有衝突，(我們沒有說Silverlight是用來取代ASP.NET的，兩者甚至依舊常常合作)，微軟的開發技術大多進入障礙低，這其實是一種設計過的優勢，我們希望開發人員不要花很多時間『一直在』學新技術，而是能夠很快地就去『用』新技術，去動手開發出點什麼可以改善這個世界的資訊產品。(寫這篇文章的人，顯然對.NET不是很熟)

在許多人還在爭論Silverlight的前途是否未明之前，我們公司的產品已經把Silverlight技術用的淋漓盡致(有點誇張我承認，但我一時之間找不到類似的詞，請包涵)，那你說我們會不會不管HTML5? 當然不會，她依舊是我們下個世代產品的展示層技術考量之一。

因為我們熟悉Silverlight開發技術，在Windows Phone 7上我們的開發成本相當低，接下來的Windows 8，由於採用了XAML，對於熟悉Silverlight的我們來說，將Application(or Apps) Porting到Win8上當然也不是問題。

很多開發團隊或人員，針對Silverlight開發技術的評估，其實坦白說並不認真，因為從2007年Silverlight出現到現在，始終停留在『評估』的階段，而這三年，已經有數以萬計的產品(包含微軟自己的Windows Azure管理平台)是100%以Silverlight技術打造的。

我要說的是，如果你始終只停留在評估，那不如就乾脆放棄了吧，因為在你評估的同時，很可能競爭對手已經開始實作、已經開始推出產品。我總是覺得，與其花時間看遍報章雜誌去研究一個技術的未來，不如親自動手直接用這個技術開發點什麼。這是技術人員的本質，『評估』絕對不只是收集收集資料，綜合一下大家的意見就好。對技術人員還說，評估是親身的體驗，是自身的感受。

畢竟，走進廚房，你才能真正知道這些食材與調味料的好壞...

通往地獄的路，是由『善意』鋪成的~

        如果你家裡有電視，大概不難知道最近柿子的新聞很是熱鬧。其實我最近已經被搞得很煩了，所以前幾天在FB上po了一小段文。今天早上又不巧看了Jamie的一篇文章，其中談到了軟體工程師以及台灣的整體軟體產業和資訊市場，所以許多不吐不快的想法，需要整理表達一下。

        正打算提筆(其實是敲鍵盤)剛好又看到一篇商周的報導，讓我覺得今天或許是個不錯的時間，我們可以好好討論這個問題。

        我想把順序反過來講，商周今天有篇文章『善意的大政府卻鋪出荒誕之路』，是這期週刊的專題報導的總結與社論，文章很長，如果你有興趣可以自己買來看，但文內有三個標題我直接列出來，跟大家分享一下，來看看我們的政府最近幾年(又一次，兩黨都有份)搞出的投資建設如何：

一、花上百億，架288支大風車，1年發電量只夠台灣用1.5天
二、百億拼裝計畫改造彰化大城鄉，總統支票注定落空
三、4大慘業虧損，全民埋單，每人面臨2萬8千元呆帳風險

細節請大家自己看本期商周，這篇文章主要的意旨在提醒大家，對政府不應該有過度的期待，其實這符合經濟學中對自由經濟市場的理論，也就是政府管的越少越好，才能夠讓市場發揮(創造)最大的價值。關於這個論點我不再贅述，我也沒有那麼大本事關注整個台灣所有產業，我在意的還是台灣的軟體產業和軟體服務業的整個市場。

因此，我要講的是這一路以來，我的觀察和看法。

這麼多年以來，政府對很多產業做了很多補助，從過去的石化、裕隆的汽車、早期的電子業、最近的四大慘業(面板、DRAM、LED、太陽能)，不管是出於善意或是各種利益考量，總之是花了非常多的錢下去，這些錢當然出自於你我的納稅。有些時候主政者用到了還算不錯的政(事)務官，有腦袋有良心，所以這些政府支持的產業交出了還可以看的成績；但不幸的是這幾十年來沒發生過幾次，反而是，在絕大多數的情況下，政府單位中對於產業其實一點也不熟的官員，本著上面交代的政策就多少做一點的上班族心態，把產業政策搞得一蹋糊塗，最後拍拍屁股政黨輪替或是退休去，領著公務人員的退休金，然而對於過去自己做的決策導致多少人沒有工作或生計困難，不知在午夜夢迴會不會覺得良心不安而輾轉難眠?

最近補貼柿子(還有以前補貼香蕉、還有以前補貼...反正一堆)的那些事情，以及兩黨賄絡選民的老農年金，讓我對台灣的政治人物的品格之低下以及選民的短視有了更進一步的認識。

當天我在FB寫了底下這段話：
-------------------------------------------------
我想，我今年要投給有老程(老程式設計員)補助的候選人，再怎麼說，我們這些人對台灣的App和軟體產業應該多少也有那麼點貢獻，而且台灣要是再不補助軟體產業，那繁體中文App以及本土在地軟體開發商都要消失了(這跟台灣沒有人種田其實一樣嚴重耶)...

但我們都沒有領過老程津貼(給老程式設計員的津貼)，我們寫App也沒有政府的保障收購價格，App賣不好的時候，我也不能要求政府來買支持我們一下，這個產業才剛起步，還要面對全球化的競爭和挑戰，政府也沒簽什麼條款來保護我們這些愛台灣的App開發商(例如國外的App一律加上100%關稅)，前陣子簽的ECFA也沒有給我們任何優惠和保障。一個柿子還可以賣二十幾塊，我們的App產地收購價格只有15塊上下，量還賣的沒有柿子多XD。這些候選人都不知道其實我們也很辛苦，也需要補助耶。

雖然微軟好心的贊助了我們一部分免費的生財工具，但人家農民買肥料和柴油也都有減免耶，連計程車司機加油都有補貼和減免，但我買NB和HD只能用PC home的免手續費分期。

每年都有政府出錢辦金馬金鐘金像獎來鼓勵台灣文化產業，其實我們也好希望有一個金柑(肝)獎來鼓勵我們這些辛苦寫Code的開發人員...弄個新光大道什麼的，支持一下在這個產業奮鬥了那麼多年的工作人員吧...
-------------------------------------------------

請不要誤會我的重點，我從來就不希望政府補助軟體業，一分錢都不要，除了App之外，其實台灣還有很多弱勢傳統軟體公司都需要補助，這需要通盤的產業政策(政府看似很在乎軟體業，但，真的有人在研究擬定台灣的軟體產業政策嗎?)，政府只看潮流(App或雲端)或選票來補助是行不通的~因為，我想要說的是，沒有一個產業可以靠補貼政策而茁壯、沒有哪一個產業面對競爭而殞落時政府非拿全民的錢投入火坑而非救不可，最近Nokia在手機市場上節節敗退，Nokia佔了芬蘭近1/10的稅收，但芬蘭政府是怎麼說的?

「企業本來就有起落，他們必須自己reborn（重生）， 這是很自然的情況。」芬蘭國家技術創新局（TeKes）執行董事何睿楷（Riikka Heikinheimo）說。「它失敗就失敗了，政府不該救，損失也是它們自己應該承擔的， 這就是市場經濟。」芬蘭經濟研究所（ETLA）研究主管亞爾柯（.Jyrki Ali-Yrkk?）說。

而台灣人呢? 銀行逾放比太高，呆帳太多要倒了，政府拿人民的錢補貼；小股民虧錢了，政府要國安基金進場；果農稻米欠收，政府要保障價格收購；高鐵要開天窗了，政府叫國營事業投資；四大慘業如今幾乎被證明是個白癡級的政策投資，但政府照樣拿錢繼續往坑裡面丟...

這些補貼的錢，隨便拿個一兩億，都可以幹出更多有價值有意義的事情。別再唬我台灣政府沒有錢了，我們繳的很多稅從我的觀點來看，根本是亂花。

更重要的事情是：我們從來沒有要政府去做這些自以為聰明的蠢事。
請不要再拿我們的錢去東補貼、西補貼，然後以為自己有在做好事，錯，大錯特錯。很多補貼輕則厚此薄彼不說，更多的情況根本是造成官商勾結的弊案，或是轉化成政策買票以及圖利特定產業特定選民的黑箱暗盤。

政府要盡全力去做的『根本只有一件事情』，就是『把基礎的建設弄好』。你把基礎弄好了，再來錦上添花一下搞產業投資，我可能也不會那麼在意，但重點在你基礎沒搞好，這些產業投資根本是聊勝於無的短期作秀而已。

什麼是基礎?
把道路鋪平，把交通弄順暢。
把商業制度與經濟環境弄健全，把行政效率全面提升。
把法律與司法制度貫徹，實現一個公平正義的競爭與投資環境。

讓我們這些廠商在打拼的時候沒有後顧之憂，這樣就可以了。

是誰叫你拼命花錢辦白目的App比賽的? 是誰叫你到處撒錢弄出一堆養肥包商的軟體專案? 是不是可以不要再做這種事情了。

把網路弄通暢，讓價格合理化，讓我們有好的連線品質，讓台灣可以成為真正運籌帷幄的訊息流通中心；把交通弄好、讓我們出國洽商或招待國外客人的時候，不用擔心機場屋頂會漏水或X光機自己燒起來；把台灣的學校辦好，讓軟體研發廠商可以在本地市場找到人才...而不是每年從學校培養出一堆只想繼續躲到研究所裡面好避免失業的蠢蛋。

就這樣，是的，這樣就夠了。
其他的我們自己來，讓產業中的人自己接手，我不需要政府對App或軟體開發有什麼補助，我需要的是法令可以跟上時代，App的銷售和金流可以順暢不被政府過時的法令所牽絆，其他的政府不需要操心，台灣人很努力，我們在全球上是有競爭力的，那些跟國外廠商廝殺的事情，不勞政府官員們您的費心，我們自己就可以搞定。這個道理就跟政府應該專注於農業政策，避免產銷失衡的問題，而不是拚了命在選前搞出各種補貼一樣。

我不知道過去這麼多年來，政府到底是出於善意或是背後有什麼與特定產業廠商之間的利益交換，坦白說我也不在乎，但是如今通往地獄的路是現在是眼睜睜的擺在眼前的，iPhone和FaceBook改變這個世界只用了五年! 才五年，這世界就變了，而我們還有幾個五年可以等待政府腦袋開竅而想清楚到底該怎麼做呢?

[周末留點時間給自己]起初的心情...

『...然而有一件事我要責備你，就是你把起初的愛心離棄了。 所以，應當回想你是從哪裡墜落的，並要悔改，行起初所行的事...』啟示錄 2 : 4~5

最近在寫程式的時候，突然想到上面這段聖經經文。

前陣子有些疲倦，這個疲倦可能不只是身體上的，也是心情上的疲倦。幾天前和一個廠商聊天，他提到收到一些終端用戶的來信，對於公司開發的產品的建議，以及對軟體收費的埋怨...如同我過去說的，台灣很多使用者認為大多數的App應該免費，持有的論點很多，但歸納到最終只有一個，就是能不付的錢當然就要省下來(老實說我異地自處、捫心自問，有時候連我自己也會這樣想，連老張都說未來景氣似乎不會太好，所以能省則省)，這是在市集中，衝動型消費或具有強烈需求的App比較容易讓用戶甘心掏錢的原因。也因此遊戲賣的比應用程式好、辣妹賣的比遊戲好的原因，而服務型或工具型的App則大多透過廣告或其他方式的獲利。而剛好最近我和在南部的App獨立開發商朋友們有一些討論，大夥兒對於台灣軟體業的生態和走向，依舊有點憂心。

然而抱怨大家都會，所以我們要練習不要太多抱怨，今天也不適合來談什麼大道理或遠大的抱負，至於過去很多跟政府單位與長官們提出的建議，也是從整體市場的角度來看，說真的沒什麼私心。關於政府如何花錢這件事情，我就不再多說了，最近還有一些讓人聽起來很不爽的案例，例如一齣劇花上兩億之類。(文中說，曾道雄感嘆「其實只要二億一千五百萬元的一半費用，就夠我做一輩子的歌劇，甚至演到死都用不完」。兩億? 我猜我們大概可以寫一輩子App了。因此我在此宣布，如果我包到兩億元的App政府專案，我立刻先捐出1/4，然後再開放100個周休三日的工作機會，程式設計師們都不用怕無薪假)

軟體產業會有這個狀況，歸納其因素，台灣市場小，是主因，最近從數據上來看， 即便是純中文化(沒有支援多國語言)的App，在台灣的銷量依舊遠小於台灣以外(這表示國外買中文App的消費者遠比台灣多? 這豈不奇怪?)，所以我們現在的App需要全面國際化，每一隻App都做multi-language是必然的，但即便如此，要讓大家願意掏錢，我們還是得要費下一番功夫，例如美術設計的補強，建立競爭者的進入障礙與門檻...等。

不過這都不是這篇文章的重點，重點是，今天我想講一個故事。嚴格說起來，是有關於我個人有生以來的第一個軟體產品的。

事情是這樣開始的，大約二十多年前，有一天下午，我的堂弟很興奮的跟我說，大偉哥哥，我們在上課的時候看到你的名字耶，啥? 我的名字???

『對啊，你的名字在課堂上，而且老師還提到 .... ... ... 』堂弟滔滔不絕的說，他們連續幾次整堂電腦課都在教我寫的軟體。

我當時只是個學生，沒那麼厲害寫出什麼教學系統，細問之下，才知道原來是我在幾年前(如果從現在開始算，大概超過25年)寫的一支個人通訊錄管理程式(DOS版，很遜，找不到Source code了)，用C語言(那時候還沒有C++、沒有Java、沒有.NET)寫的。和我差不多年紀的朋友們，還記得那個freeware和shareware的時代嗎? 很多軟體是用捐款的方式來銷售(其實嚴格說起來根本沒有銷售，是推廣)的，當時是沒有internet的世界，是BBS當道的時代，寫好的程式是由開發人員上傳到BBS站台上去，讓大家自由下載使用的...

就是這樣的一個年代，我們(當時還是學生)在家裡狂寫App，沒別的原因，只是寫了開心。因為資訊較為封閉的原因，當時寫好程式之後，甚至連跟別人炫耀的機會都沒有(那個年代不是每一個人都會奢侈地擁有一台個人電腦的，甚至絕大部分有電腦的家庭，是全家共用一台...)。因此，把自己寫好的App放上BBS，和大家一起分享...是當時很流行的方式。

和我年紀相仿的朋友們，各位還記得那個年代嗎? 還記得寫程式不為別的，只是為了開心，只是在程式設計師的身體裡面有一股創作的動力，讓你源源不絕的想把這些分享出去。為了不讓堆積在腦袋裡的代碼爆炸，所以我們持續的學習，持續的撰寫，持續的分享...我要說的是，那時候，很開心。

曾幾何時，寫程式的人變多了，用程式的人也變多了，整個市場變大了，流通變迅速了，應用程式從電腦跑到手機上，應用軟體從全家人共用變成每個人的私人貼身助理...轉眼間十幾二十年過去了，現在的我每天與程式碼為伍，有時候連作夢都會夢到新的開發架構或Idea，但當年那種純粹寫程式的開心卻時常消失的無影無蹤...

所以我突然想到前面那節經文(我知道可能沒什麼直接關係，但是人的腦袋就是這樣，這是真實世界，我寫的是真實的紀錄，我沒法控制我突然要想到什麼)...我在想，起初的心情...而今晚，這個周末，我想開始找回起初寫Code的心情。

Developers，何妨周末夜，為自己寫個小App吧，不為什麼，純粹只是開心而已。
圖中的文字是...
I am a Programmer. I work for days with little or no sleep. I am always evolving my knowledge. I translate theories into reality. I code in many languages. I tirelessly test the complex so you see just simplicity.

在App中讀取Windows Phone 7手機內的照片資源(Picture Hub存取)

同樣的，和存取音樂檔案一樣，手機上的照片檔案存取，也採用一樣的方式，我們可以透過Microsoft.Xna.Framework.Media.MediaLibrary取得用戶儲存於手機上的照片，關鍵在Pictures屬性：

//透過MediaLibrary存取手機照片
Microsoft.Xna.Framework.Media.MediaLibrary lib = new Microsoft.Xna.Framework.Media.MediaLibrary();
foreach (var item in lib.Pictures)
{
    //動態建立Image物件
    Image img = new Image();
    //加入容器
    StackPanel1.Children.Add(img);
    img.Width = 400; img.Height = 400;
    //設定圖片來源
    BitmapImage bi = new BitmapImage();
    //關鍵在item.GetImage取得圖片
    bi.SetSource(item.GetImage());
    img.Source = bi;
}

開發人員需要比較留意的部分，是動態建立的Image物件，是透過source屬性來設定圖片，但圖片來源必須是BitmapImage，因此我們又動態建立了BitmapImage物件，並且透過SeetSource來設定該物件的binary圖形資料來源，而這個資料來源，當然是從item取得，使用的是GetImage()方法。

執行的結果如下：



請留意，Microsoft.Xna.Framework.Media.MediaLibrary.Pictures取得的每一個物件，其型別是Microsoft.Xna.Framework.Media.Picture，這個物件除了可以透過GetImage()取得圖片之外，還有幾個重要的屬性，諸如：Name, Width, Height, Date, Album…分別可用來表達圖片的相關資訊。

在App中讀取Windows Phone 7手機內的音樂資源(Music Hub整合)

前陣子WP7 Marketplace當中有一隻HTC推出的免費App挺有趣，可以在App當中抓取顯示並撥放手機上的多媒體資源，諸如音樂檔案或是影片，先前我們在討論Silverlight開發技術的時候，並沒有看到API裡面有可以抓取到手機音樂的指令，第一次看到的時候著時讓我有些好奇，找了一下MSDN資料發現難怪之前沒看到，原來是出現在XNA這個Namespace底下。

我們可以透過底下的指令找到手機上的所有多媒體檔案：

void MainPage_Loaded(object sender, RoutedEventArgs e)
{
    //透過Xna抓取手機上的音樂
    Microsoft.Xna.Framework.Media.MediaLibrary lib = 
        new Microsoft.Xna.Framework.Media.MediaLibrary();
    //Binding到ListBox上
    this.ListBox1.ItemsSource = lib.Songs;
}

當然，由於屬於XNA Framework的部分，請在使用前先在專案中Add Reference：



加入Microsoft.Xna.framework，接著即可使用前述的指令碼抓取到資料，如果你要像上述程式碼一樣把樂曲Binding到ListBox物件上，必須先幫ListBox設計Template：

然後將此Template使用在ListBox上：

如此一來就可以在自己開發的App中，呈現出手機上呈現出每一首歌的名稱，以及演唱者與專輯名稱：

由於Silverlight的DataBinding技術，在listBox當中每一首點選的曲子，可透過底下的方式抓取到，甚至可以透過底下的程式碼，撥放選取的Item：

private void button1_Click(object sender, RoutedEventArgs e)
{
    if (this.ListBox1.SelectedItem == null) return;
    //取得選取的樂曲
    Microsoft.Xna.Framework.Media.Song song =
        this.ListBox1.SelectedItem as Microsoft.Xna.Framework.Media.Song;
    //進行撥放
    Microsoft.Xna.Framework.Media.Song item = song;
    Microsoft.Xna.Framework.Media.MediaPlayer.Play(item);
}

在模擬器上也可以操作，你會發現我們的App與Music Hub可以整合在一起，在模擬器(RTW版本)上也有內建有三首曲子，可以方便我們進行測試。

當你在開發測試環境當中，使用模擬器時，也可以按下鍵盤上的F9, F10按鍵，這時可以模擬手機音量鈕，呈現出左方的畫面。

你不難發現，我們的App直接控制了WP7的Music Hub進行音樂的撥放。

如果不想使用DataBinding的方式，您也可以用底下的程式碼列出每首歌的名字：

 Microsoft.Xna.Framework.Media.MediaLibrary lib = 
    new Microsoft.Xna.Framework.Media.MediaLibrary();
foreach (var item in lib.Songs)
{
    //顯示樂曲名稱
    MessageBox.Show(item.Name);
}

透過這樣的方式，我們可以輕易地抓取到手機上的多媒體資源，並且和我們的App進行整合，也可以控制MusicHub的撥放，非常的方便。

如何存取照片資源呢??? 請參考這裡。

關於雲端運算

[引言]這一篇，是幾個月之前應邀寫的一篇討論雲端運算的文章的原稿，因為篇幅的關係，這篇文章在刊出的時候做了相當大程度的刪減，幾個月過去了，重新看到，只貼在blog給有興趣的朋友...另外，這一篇並沒有試圖為雲端運算下定義，因為定義可以從NIST找到http://www.nist.gov/itl/cloud/ 這篇只是說明我們對雲端運算的一些規劃與想法...
  
從虛無飄渺到豁然開朗

        前陣子受邀到某教育訓練中心上課，剛好學員前一堂課的講題是雲端運算，看到學員臉色頗為疲倦，不禁好奇早上的講師是否塞給大夥太多內容而造成學員壓力。因為這個班下午我得要接續著上課，所以不免關切地問了學員一聲：『早上雲端課程上的如何啊?』

        沒想到不問還好，這一問之下，學員七嘴八舌地聊了開來，有個年長的學員用八個字做了總結：『虛無飄渺，無邊無際』。由於學員先前都沒有接觸過相關的概念，聽起來雲端運算好像很厲害，無所不能，但從講師的介紹中，又分不太出現在所謂的雲端運算和傳統的虛擬主機、主機代管、或網路服務有何不同，看起來像是過去我們說的SOA(Service-Oriented Architecture)的一種延伸，又像是ASP(Application Services Provider)的一種變形，那到底雲端是什麼? 早上一整個課程上下來，學員似乎還是摸不著頭緒…

        其實這個話題，得要從20年前開始說起…

二十年前的夢想

        約莫在15年前，Bill Gates出版了一本頗為引人關注的書籍『THE ROAD AHEAD』，清楚地闡述了他早在1990年11月於Comdex中所發表 - 主題為『Information At Your Fingertips』的演講，20年後的今天，你可以看到Bill Gates對未來描述的精準先見。
        當時所提及的概念，已經把網際網路和資訊科技將帶給我們的願景清晰地勾畫出來，可能在20年前你很難想像，任何人，在全球的任何地點，都可以從口袋中拿出一個可以隨身攜帶，只有手掌大小的設備，而這個設備可以提供你所需要的任何資訊，不管是當天全球重大的即時新聞(例如最近的股市崩跌)、或是你家裡大門口的監視器即時畫面。不論你在這個地球上的哪一個角落，只要能夠連上網路，不管是工作還是娛樂，所需要的各種資訊，都在你的掌握之中。
        20年前所說的『Information At Your Fingertips』(資訊彈指可得)，在智慧型手機和平板電腦的迅速普及下，早已從所謂的願景變成今天日常生活中的一部分，拿起你的智慧型手機，你所在位置方圓百里內的吃喝玩樂，也都一手掌握，這(如今我們習以為常的一切)，可是過去人們前所未有的體驗。
        而這一切的資料，都存放在哪裡? 提供這些搜尋或運算的伺服器主機又在何處? 串起這一切可能性的關鍵技術又是什麼? 沒錯，這些都是雲端運算的一部分。

從Application Service Provider到Cloud Computing

        早在十多年前，在網際網路開始普遍之後，就有不少研究單位提出過ASP(Application Service Provider)的概念。打從軟體開始與硬體分開銷售，獨立收取費用以來，軟體的通用性與可複製性，就成為影響這個產業盛衰的關鍵因素。
        簡單的說，從商業的角度來看，開發完成後，只能賣一次的軟體我們叫做專案，能夠重複賣很多次的軟體我們叫做套裝軟件，而套裝軟件的獲利基礎則是建立在客戶群的規模上。軟體公司開發出一套辦公室軟件，銷售給全球的企業，由於使用量大(具有規模)，所以締造出了一個龐大的產業生態鏈。但沒過多久，大家發現這似乎有些問題…
        首先，軟體並沒有辦法如同汽車一樣，一旦買了就一直用下去，而是每隔幾年就需要改版，升級，這不僅僅對於客戶來說是個困擾，對於軟體供應商也是個頭疼的事情，隨著升級改版所帶來的問題，常常需要更多的客服人員才能解決，使得隱含的軟體開發成本更高。由於軟體是安裝在客戶端，每一個客戶端的硬體狀況又有所不同，更造成了維護與服務上的困擾。
        不僅如此，對於廠商來說，軟體的獲利模式是基於複製，也就是我研發一次，可以賣出很多套，但這在某些地方顯然不可行，在某些對於智慧財產權並不嚴謹的區域，軟體的盜版和私自複製侵蝕了軟體公司的獲利。雪上加霜的是，隨著全球化的普及，企業營運的需求瞬息萬變，軟體的生命週期開始逐漸變短，改版的頻率漸高，慢慢地大家發現，軟體的獲利基礎已經不在，漸漸地開始被升級改版以及客服的成本所吞蝕。
        這時候，ASP(Application Service Provider)的概念為軟體界帶來一盞明燈，不少軟體廠商嘗試以服務的概念來替代軟體銷售，也就是說，我不再販賣一套一套的辦公室軟體，而是把軟體免費提供給客戶，由客戶自行安裝或是從網際網路上下載，或甚至直接透過瀏覽器執行，不再依照軟體的銷售來計費，而是依照軟體(或乾脆把軟體視為一種服務)的使用量來計費。企圖製造軟體廠商與客戶兩端雙贏的局面。
        怎麼說呢?因為客戶早就發現，一整套辦公室軟體，可能我只用到20%常用的功能，但每賣一套我還是得付100%的費用，套裝軟體也不像專案，可以分開計費，而即便開發商提供不同版本的功能，如何切割卻也並非由消費者自己決定，而是掌握在軟體廠商的手裡。如果，釜底抽薪的將計費方式改成用多少付多少，對於消費者來說似乎是更有利的。
        而從軟體廠商的角度來看，以租賃替代賣斷，看似降低了銷售金額，但其實後續獲利的可能性似乎更高，怎麼說呢? 過去我一套一套的賣，現在我則是你用一次我收一次錢，首先我隨時可以掌握使用者的狀況，我知道你用了哪些功能，開檔開過幾次，報表印過幾張，軟體廠商可以得知那些功能用戶最喜歡，那些功能客戶根本沒在使用，從而進行改版與更新，提供更好的服務。
        而更重要的是，不像過去一套一套賣的軟體，以租賃方式銷售只要客戶一但使用，要轉換成其它品牌同質產品的難度更高，無形之間增加了品牌向心力，只要你用了我的進銷存系統，大概總帳和會計系統也跑不掉，不久之後訂單就到我手裡了。
        而且這個機制一併解決了軟體被私自複製的盜版問題，所有的使用都需要連線到軟體廠商的伺服器端，經過驗證才能使用，以Web方式提供的軟體服務，更省去了客戶安裝的動作，改版時也不需要擔心客戶端的設備環境問題…過去困擾開發商的問題一一解決。
        這確實是個好的想法，但如同許多新穎的概念一般，由於當時的時空環境並不成熟，硬體與網際網路的效率與普及率稍嫌不足，再加上安全性的考量與收費機制(例如線上刷卡)的法令依據尚不完備，導致這個概念始終只停留於最初時期的測試營運階段，這一等，又過了將近10年。

雲端運算(Cloud Computing)的條件與要素

        10年後的今天，隨著網際網路的普及與頻寬大幅改善，以及虛擬化技術的成熟應用，雲端運算開始以不一樣的風貌重新出現在世人面前。但如果你以為現在我們說的雲端運算技術只是當年換湯不換藥的ASP(Application Service Provider)或是其實大同小異，那顯然這又是一個被媒體胡扯隨便報導下所導致的認知錯誤。

        很多人以為，『能夠用Web方式提供軟體服務，或是以AJAX技術提供軟體服務的產品，就叫做雲端運算』….對於身為ISV的軟體開發商來說，這個解釋不僅錯，而且錯很大。
        請容我這麼說，這或許是沒有技術背景的行銷人員，從無限廣義的泛商業角度下，隨便勾畫出的雲端運算概念。一般人茶餘飯後聊天時可以這麼認知，身為有技術背景的專業人員的你千萬別這麼單純。

        首先，以Web方式提供軟體服務，根本不是必要條件，不然現在的智慧型手機或是平板電腦上的App, 全都要被摒棄在雲端之外，豈不冤枉。況且，著名的DropBox或Skydrive，就是典型的雲端服務，這些雲端服務的用戶端呈現方式，除了Web瀏覽器之外，早就多的是以智慧型手機或PC的原生開發技術所建立出來的應用程式(App或Application)，是不是完全都要走80 port也不一定，所以這個定義顯然是有問題的。

        而AJAX技術則是Web上Presentation(展示層)的開發技術，為了與後端數據庫進行連結，提供用戶更順暢的操作體驗，這更與雲端運算毫無瓜葛。
        唯一說對的大概只有雲端運算是以軟體服務的面貌出現，而非以軟體銷售的概念計費。因此，租用(用多少，付多少)與採購彈性肯定是當前雲端運算的主要定義之一。不過話又說回來，雲端運算的定義之所以如此的模糊，除了媒體所造成的誤解之外，部分軟體廠商刻意模糊焦點也是事實，畢竟定義越模糊，就越容易擠進申請政府補助的門檻，而消費者也更容易在不知所以的狀況下買單。

        然而，對於身為ISV的廠商來說，我們認為雲端運算至少要具備底下特性，缺一不可：

1. 以租用方式提供軟體服務，用多少付多少，而非銷售軟體。
   在雲端運算的時代，軟體開發商需要認知自己所銷售的是服務，而非軟體產品。軟體僅僅是開發商提供客戶服務的媒介(或是載體)。真正銷售的乃是服務，因此軟體的使用也開始有所改變，再也不像過去，是一套一套的賣，更可以想成是免費提供軟體，而客戶租用的是軟體公司所提供的服務品質、以及服務內容。
    
2. 具有延展性，能夠隨時依照當下需求增減服務規模。
   既然軟體是以服務的面貌呈現，當然就需要考慮延展性的問題。所謂『軟體的延展性』是指：『當用戶端需求量瞬間增加或減少時，軟體服務能夠隨之動態調整的能力。』例如，我們建立的ERP服務，目前主機的營運規模，在客戶是500人同時使用的狀況下運行良好，但一夕之間客戶從500人同時使用突然變成5000人同時使用，多出了10倍，原本的軟體服務是否能夠在不改變程式碼，只透過設定的狀況下，就滿足客戶端流量和計算能力突然激增的需求? 這我們稱之為延展性。以網站來說，最典型的例子就是旅遊業的淡旺季，或是熱門表演的售票機制，這些應用都是隨時有可能出現爆量連線的狀況。現今的雲端運算軟體服務，在以『用多少、付多少』的概念為前提之下，要滿足客戶最理想經濟的購置成本，客戶理當可以在需求量較低時，以一兩台伺服器面對最基本的軟體應用需求，一旦發現流量激增，隨時可動態增加數台乃至於十數台伺服器，同時服務以達成延展性的需求。(在過去這樣的軟硬體架構有其實作上的難度，而今天拜虛擬化技術之賜，現在已經可以輕易地達成)
    
3. 具有Load Balance(負載平衡)、與FailOver(錯誤後轉移)的能力。
   Cloud Computing必須提供永不斷線、穩定、且持續性服務，因此除了前述的延展性需求之外，隨之而來的還有穩定性與持續服務的能力。在理想的雲端運算技術架構下，不管是Web, AP, 乃至於DB Server, 都必須要提供Load Balance、與FailOver的能力。也就是說，使用者端(客戶)，連上來使用的每一個瞬間，位於雲端的軟體服務需要提供穩定的連線品質與資料的正確性。
    
4. 以Multi-Tenant(多租戶)作為服務的基礎骨架與必備要素
   對於提供SaaS(Software as a Service)的廠商來說，由於一般性軟體開發的獲利必須建構在複製與一定的市場規模上，因此Multi-Tenant的架構則是這一切的基礎，若提供SaaS服務的ISV，無法以多租戶的技術滿足客戶的需求，還得新增一個客戶就手動開設一台服務器，顯然在競爭力上已經落於人後。

        您大概不難發現，上述這些軟體服務的技術基礎，都建構在虛擬化技術上，現今以虛擬化技術所建構的雲端運算服務平台(PaaS)，能夠在架構上滿足上述延展性與負載平衡等技術需求，並且同時能夠讓ISV搭建出以Multi-Tenant為主體的軟體服務(SaaS)。

        十多年前，ASP(Application Service Provider)之所以無法成功，除了安全性是一大考量之外，當時的網際網路和硬體架構，實難承載上述軟體服務所需要的相關的基礎設施，而十多年後的今天，不僅在台灣隨處可以上網，上網設備更是琳瑯滿目，連線品質早就可以滿足絕大部份的資訊交換與遠端運算需求。同時，由於虛擬化技術的成熟，我們才有可能建構出極具延展性的軟體服務，隨著客戶實際需要的流量，動態調整記憶體、伺服器、儲存體的大小與數量。這些都是過去十多年前ASP(Application Service Provider)廠商可望而不可及的夢想。

        再加上位於應用程式展示層的用戶端操作介面技術突飛猛進，透過現在的Silverlight開發技術可以輕易的設計出相當優質的UI，甚至可以運行在PC、平板、智慧型手機等各種不同的介面，在安全性上也跟著增強，如今ISV比起過去15年更有機會建構出優質的軟體服務應用。

雲端運算是軟體產業必然的方向
        透過上面的說明您大概不難明白，隨著技術的演進與成熟，這段路走了十多年，雖然看是緩慢、波折，但卻堅持而持續著。從歷史演進的角度來看，雲端運算可說是必然會走的方向。
        過去許多人在意的安全性顧慮與隱私的問題，這幾年也慢慢開始改變，從Google, Microsoft, Youtube所提供的免費服務, 一直到SalesForce, DropBox提供的商業應用，市場逐步開始接受資料放置於雲端(遠端伺服器)的可能性，而服務供應商，也透過前述的種種技術，建構出優質、穩定、且安全的軟體服務。
        這形成了另一波的軟體革命，過去的軟體賣錢，未來軟體則是免費，君不見Google App免費的提供了類似Word、Excel的線上服務給個人用戶，而微軟也從今年開始，提供Office 365，讓消費者以租賃的方式使用，如今只需要連上網路，不管是用PC或SmartPhone，你都可以在線上使用Word、Excel編輯檔案，並且和遠端的上下游廠商或合作夥伴共同編輯同一份文件，達成前所未有的協同運作效果。
        而這一切居然都是免費的(微軟與Google都有提供免費的App服務給個人用戶)，靠著銷售軟體獲利的時代已經過去，破壞性創新讓軟體的開發與銷售走上了另一條路。現在你要做的是，讓你的消費者，打開電腦、拿起手機、連上的是你所提供的服務，藉由你的軟體服務，來協助客戶達成日常所需的一切資訊需求，利用你提供的軟體服務，來滿足客戶的資訊化需要。
        數年後的商業環境，使用以雲端服務提供的軟體應用，將會如同日常呼吸一樣的自然，而今天，軟體服務供應商的挑戰與競爭和重新洗牌則已然開始。

以微軟Windows Azure為基礎的具體應用
        從ISV的角度來看，我們很高興微軟在這一塊並沒有缺席，不僅如此，微軟的Windows Azure以及SQL Azure技術有效地提供了良好的開發平台，讓身為ISV的我們，可以在這個平台上以更合理的開發成本，建構出優質的SaaS服務。
        過去半年，我們(光岩資訊)利用了微軟所提供的Azure技術，建構出了大中華區第一套以Silverlight(未來將擴展為HTML5)配合Windows Azure技術所研發的『EasyCloud雲端運算開發平台』，以及相關的辦公室e化應用套件，讓企業得以租用的方式，來使用我們所提供的一切軟體服務。
        不僅如此，為了讓中大型企業客戶也能夠享有安全的雲端運算開發技術，省去購置與維護伺服器的成本與人力，租用EasyCloud雲端開發平台時，可直接搭配微軟的Windows Azure與SQL Azure雲端服務。企業內的IT人員若擁有基本的.NET開發技術，甚至可在平台上自由建置與開發屬於自己的 App，將企業內部所需要的應用，透過我們所提供的EasyCloud開發平台，搭建於微軟所提供的雲端運算中心，享有前述諸如延展性、負載平衡、以及前所未有的穩定性。讓企業內的使用者不管身在何處，透過NB或SmartPhone(特別是Windows Phone 7)連上雲端，隨時可取得自己所需要的任何資料，甚至與地球另一端的夥伴一起合作。
        透過導入雲端運算技術所降低的營運成本，以及節省的管銷費用，更讓資訊化投資在財務規劃上更加透明且容易預測，不至於變成營運上的財務黑洞，這讓客戶對於雲端運算的投入更有信心。
        對於身為微軟ISV的友商來說，我們所開發的平台也有助於ISV在最少的投資下，將產品由現有的Web/Windows應用移轉成以微軟Azure為基礎的雲端運算服務，EasyCloud平台本身所內建的Multi-Tenant機制，可讓開發出的應用立即具有Multi-Tenant與Billing的功能。而這一切都是建構在Windows Azure以及SQL Azure良好的基礎上。

令人引頸期盼的未來
        面對已經成為趨勢的雲端運算，我們隨著微軟邁出了第一步，我們看到的是一個嶄新的可能性，不管是市場狀況、SaaS的概念與Business Model，都將讓軟體產業重新洗牌。不僅如此，由於雲端運算的態性，我們面對的已經不只是台灣的市場，而是全球化競爭與機會。
        回顧軟體業，每一次的改變，都是梟雄崛起的全新機會，每一次的改變，也伴隨著不少巨人的殞落，面對這個趨勢，恐怕你立刻就必須決定下一步該怎麼走…