2011年10月31日 星期一

在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,接著即可使用前述的指令碼抓取到資料,如果你要像上述程式碼一樣把樂曲BindingListBox物件上,必須先幫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的撥放,非常的方便。

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

2011年10月24日 星期一

關於雲端運算

[引言]這一篇,是幾個月之前應邀寫的一篇討論雲端運算的文章的原稿,因為篇幅的關係,這篇文章在刊出的時候做了相當大程度的刪減,幾個月過去了,重新看到,只貼在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,都將讓軟體產業重新洗牌。不僅如此,由於雲端運算的態性,我們面對的已經不只是台灣的市場,而是全球化競爭與機會。
        回顧軟體業,每一次的改變,都是梟雄崛起的全新機會,每一次的改變,也伴隨著不少巨人的殞落,面對這個趨勢,恐怕你立刻就必須決定下一步該怎麼走…

2011年10月13日 星期四

台灣的軟體人才在哪裡?

        最近,政府舉辦了不少的App設計比賽,大概是看到了芬蘭在沒了Nokia作手機界的霸主之後,居然還可以有一個能撐住半邊天的紅色小鳥,回頭想想台灣雙A品牌在小筆電上碰到的挫折,又環顧了一下過去幫台灣掙錢的代工產業前景茫茫,想說反正比起花在兩兆雙星上的銀兩,辦些個App比賽只是九牛一毛,搞個不好給他異軍突起,成為未來的一條生路...不知道是不是因為這樣,所以最近常常聽到各式各樣的App新聞,甚至也有跟前陣子雲端綁在一起炒的,不管如何,至少這個產業似乎被推廣開了,只要有動作,我都認為是好事...

        但是前陣子跑了不少學校,並且和業界一些前輩們聊天,大家都有一個一樣的感慨,台灣的軟體人才真的越來越少了。雖然學校的科系開的琳琅滿目,從遊戲開發到機器人設計都有,各樣五花八門的學科讓人目不暇給,但是同學畢業之後,真的在職場上撐在那裡寫程式的,能有多少?

        我不用算也知道,因為部落格會說話,全台灣軟體相關部落格一個月的點擊率加起來,能不能打敗教人化妝的部落格,或是隨便一個所謂的人氣美少女外拍部落格,不用我說大家也知道。前陣子流行金釵文化,一些大學的資工系學生寧願當Model走演藝路線,也不願意坐在辦公室寫程式,雖然我不知道人家在學校的成績怎麼樣,但我想就算人家小姐C++寫得很好,java駕輕就熟,畢業之後當Model或藝人大概還是比較划算,隨便一個主持通告比我們這些所謂講師的鐘點還要高,人家不願意自甘墮落寫程式,我也就不那麼在意了...

        但是這凸顯出一個很有趣的落差,台灣很多軟體公司的開發人員其實不在台灣(這大家都知道),而台灣土生土長的程式設計師,薪資結構上也並沒有比其他行業要來得高(這邊先不論畢業生的技術能力如何),程式設計師薪資低,工時長,只有乍看之下很高檔的社會地位(因為以前大家都以為程式設計師是科技新貴,後來才慢慢發現搞錯了,那是指製造業寫韌體的),結果不僅台北市的房子買不起,連台北郊區的也很拚...這時候,能留住所謂的人才才真的見鬼。

        這薪資結構其來有自,如果市場上對一個軟體專案,對一個手機App,對一個套裝軟體...的價格始終是低估的,而內需市場又硬是比其他產業小,而外銷能力又還沒成熟到足夠與國外廠商車拚,那這個產業該怎麼扶植起來? 如果政府對某個產業的投資是矇著眼睛撒錢(其實總比沒撒錢來的好,我們現在的標準已經自動降低了),那能夠培養出紅色小鳥才怪。

        程式設計師學習了很多(而且每天都在持續更新與變多)的專業知識,每天昏天暗地不打緊,到頭來你依舊買不起工作地點附近的房子、對外常常被客戶抱怨、對內當專案或公司資源有限時,PM, Sales沒法壓縮(其實是已經壓縮過了,很多公司常常一個PM, 一個Sales跑遍全台灣),老闆只好先砍Developer人力,使得增加工作量與加班變成常態。Developer常常一個人兼顧維護案加上新軟體的開發,在這種情況下軟體品質只是老闆與客戶第一次見面時高談的口號和夢想,資源不足時最先槓掉的就是品質這個空泛(不會立刻賺到錢)的指標...這樣的環境得適應並持續支撐下去... 因此你看到Developer頂著自己的專業背景(和花了錢考來的證照),改行去開咖啡店賣咖啡或是做網拍也就不足為奇了。

        昨天有個寫手機App的朋友跟我說,他吃炸醬麵的時候覺得很感慨,一個手機App賣0.99美元,折合台幣約莫30元,他寫了數個月,還附了錢請美術人員,但是每次吃麵的時候,他都覺得應該改行賣炸醬麵...很多人吃一碗麵付錢的時候眼睛都不會眨一下,但付費買App的時候,不僅要先試用,而且要弄了半天沒法下載到破解版的時候,才願意付那區區的0.99美元。而炸醬麵大概配方就是這樣,如果好吃可以一直賣,但他的App就算好用好玩,如果沒有持續改版,大概一兩個月後就無人問津了...這邊都還沒有算進去軟體技術的改變和改版所帶來的額外成本...

        有些廠商跟我抱怨,現在賣軟體跟賣水果一樣,客戶總是愛挑挑價格,看看賣相好的,選好之後不忘要個折扣,順手再拿包梅子粉之類的。內需市場價格被壓得太低,卻依舊有廠商硬是可以把品質擱在一邊,硬生生吞下去低到不行的價格,而客戶也不太管一個軟體到底背後要花多少時間和人力進行優化,反正短期績效達成,三年的軟體專案結案時雙方PM早就換了好幾輪,是非對錯已經無從釐清。政府單位的發包也不管其實案子被大包廠商綁標之後,切割丟給小軟體公司時,這些小企業如何被壓榨,政府以為自己花了錢培植軟體產業,其實只是被上游那些大資本額的系統整合廠商給剝削了。

        說來無奈,這個情況跟果菜市場的大盤收購香蕉的狀況很像,最基層的蕉農慘兮兮,但政府大官員們則是渾然不知,只看到果菜市場的批發價格之後沾沾自喜,覺得自己努力地照顧農民了所以感到很欣慰...

        台灣怎麼會沒有軟體人才呢? 怎麼會沒有人喜歡寫程式呢? 為什麼資工系的學生寧願去網拍、寧願去當通告藝人呢? 是誰趕跑程式設計師的呢??? 我想不用多說了...很多持守在這個領域的朋友或前輩們,倚靠的純粹只有自己的興趣,沒別的,就只是興趣。但我相信,會持續待在這一行,絕對都是有夢想的~

        所以,當產業界在問,當政府或研究單位在問,台灣的軟體人才,軟體產業在哪裡,其實很簡單,不用作研究報告,不用去找104調查,你自己下來當一兩個月程式設計師就知道了。

後記:這篇文章得到很多朋友們的迴響和意見,路不好走是我們都知道的,但我們從來沒有想過要放棄,現在的情況,套一句說得很貼切的俗話『前途是光明的 ,但道路是崎嶇...』。然而有夢想,總是可以支撐下去;有方法,總是可以開創出一片天地...

ref1 : 韓國軟件競爭力孱弱的五大原因
ref2 : http://forum.gamer.com.tw/C.php?bsn=60076&snA=928472&locked=F&page=1&gothis=13407958#13407958

2011年10月10日 星期一

[VS2010]在Build時自動update專案版本

最近比較多開發WP7的Apps, 每一個App都不大,但是版本編號(Build Number)的建立卻很重要,因為我時常在submit同一支卻不同版本的Apps。而公司最近的雲端運算開發平台上的Apps也有這個問題,每一個App其實都是一個小功能,更新的頻率非常高,因此常常需要讓User再回報問題的時候,提供Build Number給我們,才比較容易區分是哪一個版本的App。

開發團隊的新成員問到,如何在每一個build自動update版本編號?
我記得有一個工具,叫做Build Version Increment Add-In Visual Studio, 可以從底下這個位置下載:http://autobuildversion.codeplex.com/releases/view/60932#DownloadId=208247

用起來很簡單方便,安裝後只需要在VS2010的主選單上按下Tools->Build Version Increment->Settings:

即可進入設定畫面:

主要是上述幾個項目,設定完成之後,每一次Build時的版本編號就可以自動依照規則遞增了。你也可以透過 Assembly.GetExecutingAssembly().FullName.Split(',')[1] 抓取到當前App的XAP版本, 提供給Developer參考...
更詳細的使用說明可以參考這裡:
http://autobuildversion.codeplex.com/documentation



分享