Mircosoft Azure 的野心

有在注意產業相關新聞的人應該都知道微軟已經和Zend(PHP)合作了。很多人可能覺得很奇怪，也有些人認為這樣很好，讓PHP能夠更容易在Windows伺服器上使用...

哪有那麼簡單！！！

Sam 覺得微軟是為了他們的雲端平台Azure，畢竟一開始就落後了Google, Amazon, IBM，想要及時迎頭趕上是蠻麻煩的，於是乎只好搬出這招，打著PHP的光環吸引更多PHP開發者(為數驚人的高市占率)，而且其他家平台都是 Java、Python 之類的語言，較為小眾市場或不是那麼容易入門，相對的以商業角度來看，微軟下對了一步險棋。

但就Sam開發的經驗來看，PHP似乎在系統動態套件擴充部份有一點糟糕，有玩過PHP設定的人都知道要把套件 1.重新編譯(Unix-like) 2.套件檔放到lib下然後修改設定檔(Windows) ，不過雲端平台表示碰不到系統，自然就無法安裝這些東西，這是Sam目前比較大的疑問，當然，微軟也有可能做出一套虛擬設定環境，到時候可能會改觀。

相較於其他廠商，以 Google 使用 Python 來看，雖然 3rd Party Library 以往要採 setup.py 安裝，但其實它們都有附上源碼檔案，也就是說你只要把該檔案放到應用程式裡一樣可以叫用 import XXX ，和目前微軟比起來哪個比較方便就見仁見智了。

不過身為使用者的我們還是樂見許多大廠爭相開發平台，畢竟有利無弊，多了許多選擇

GAE ( Google App Engine ) 模式為什麼將來會流行?

一開始寫這篇文章標題時，本來想下"為甚麼GAE( Google App Engine )在台灣乏人問津..."，但是與其批判，不如說一些真正吸引廠商或老闆的條件比較實在。

講到GAE就不能不提雲端，雲泛指網路世界，其實中國把Cloud Computing稱作雲運算，但Sam還是覺得台灣翻的好，因為重點是終"端"使用者。Google之所以能夠讓用戶端幾近立即的得到搜尋結果，在於內部程式幾乎都實作了Map和Reduce方法去驅動機器讓資料中心平行同步幫您處裡，才能夠達到如此高的效率(參見Map-Reduce)。 這時候我們開始回歸到現實面，如果您擁有一家軟體開發，或目前已經在提供現上應用服務的企業(無論大小)，您會怎麼處理資料? 目前情況不外乎是砸錢設機房、買伺服器、請網管維護、負擔線路費用，或是中小企業租用虛擬伺服器。但如果以上都能省略呢? 俗話說 "打蛇打七寸"，既然公司是以軟體與服務為主，我們就應該縮減實體設備造成的負擔。

GAE的聲明便是不需要再負擔實體設備成本(或極小化)，只需要專心在軟體構思與服務。GAE採用的技術完全都是OpenSource，並且就算付費，也是使用公用運算(Utility Computing)的計費標準，用多少付多少，不用再像以往為了負載短時間高流量，承擔一整年其餘沒用到的費用。以下幾點為與傳統比較的好處:

1. 風險降低(不用再擔心本地伺服器硬碟毀損，雲端資料中心機器會自動複製到其他台)
2. 擴充、縮減的問題無須考慮(基本上雲端資料中心能夠任意增縮設備，當然這已經不再是您的問題)
3. 成本降低(省下設備維護費用全力開發產品)

目前GAE支援的環境為Windows、Linux、MacOS，也就是跨平台，而編寫語言除了原本的python之外，今年也加入了Java成為第二個支援語言 http://code.google.com/intl/en/appengine/。

Sam 目前只有實作python的api，在安裝完GAE SDK與python2.5後便能開始編寫，裡頭大致上是追隨django這個框架的標準，包含設定檔使用yaml，與資料儲存(datastore)採ORM用物件來設定，Google也很貼心的設計了像phpMyAdmin那樣的介面來做資料表管理，而且datastore背後採用BigTable，不用太擔心效率的問題，然後除了官方API(Images, Memcache, Mail, URLFetch, Google Accounts)外，也能夠使用第三方資源庫(3rd party library)，系統還能定期排程，真的甚麼事都能處理(當然還是有sandbox規範，像是socket那些不行)，並且他們的free quota(免費額度)對於一般企業根本一天不會用到超量(因為非常之大)，作網路服務或網站是綽綽有餘。

寫到這裡好像Sam都在幫Google打廣告，但是各位要了解，除了Google外, IBM blue cloud, Amazon EC2, 甚至微軟都在發展這個服務，拿Google來說只是因為它有free support，其它都要付費的...。

依照台灣對國際的資訊速度(差不多慢了一年或兩年)，目前還很少人知道這種服務是正常的，過了不久就會像當初Google Adsence一樣在全世界掀起熱潮，只是這頭Cloud Service的小浪在Sam眼中將會是下一波科技海嘯，而未來掌握資料中心與搜尋技術的企業則會領導世界!

Web標準可能讓Flash過氣 ... 嗎?

早上起床看到一篇文章 Opera：Web標準可能讓Flash過氣，大致上是敘述Opera的執行長說下一版HTML網路程式設計語言推出後，可能讓Adobe公司(奧多比)的Flash技術顯得多餘。

當然不可否認的 HTML 5.0 的確新增了許多讓人心動的功能，如:

‧ 本機儲存(Local storage)，在個人的電腦上儲存資料的技術。此功能可讓你在離線狀態下使用網頁電子郵件，儲存瀏覽器擴充套件的個人設定。

‧ 影像支援(Video support)，讓影片更容易嵌入網頁，並且更容易與Flash等影像技術整合。

‧ 網路工作者(Web workers)，此功能讓瀏覽器在背景執行繁雜的處理任務，讓複雜的網路程式完成任務，又能避免造成使用者介面變得太笨重。

另外還有一些標籤更詳細的定義等...不過不要忘記，就算功能再如何增加，還是在處理Client端的事情，而目前flash真正有用的部份在於與Server端溝通，並“動態“的顯示資訊，像是 swfUpload 就是個很好的例子。

反而Sam較為擔心的是 Flex，推出時非常轟動，但目前感覺慢慢在衰退，Sam之前使用的一些感想如下:

1. 檔案笨重: 把所有套件一起編譯，又不好將不同頁面分成數個swf批次載入，導致有些用戶端載入非常久。

2. Flex 能辦到的事，Flash 也做的到。

3. 組件還是一樣不好用。

4. 排版採用類似 Java 的方式，沒錯你可能想吸引 Java 開發者，但 Flash 開發者會慢慢遠離你...

5. 自己定義的語言標準 ... 恩 ... 不與置評。

其實論網路服務實用性 Flex 很低，而被取代性很高。

哪些 Flex 所謂的應用程式拖移功能，事件等動態方式目前 javascript 做不到？而且就使用者而言，原生性的（使用html + javascript）永遠比要安裝外掛 （Flash, java, silverlight）好，尤其是現在 js 引擎速度那麼快!

總之Flash不容易被淘汰，它仍是設計師最快最好呈現的工具，只是以往用Flash開發應用程式的大概得考慮一下換個方式走以後的路。

學習 CakePHP

之前回絕掉一個cakePHP的案子, 實在是因為要寫報告和找資料太忙了...。

說到cakePHP, 最重要的就是 MVC(Model-View-Controller) 的設計模式, 以往由於php是比較近似於程序導向語言, 故大家都會把所有動作與畫面顯示寫在一隻程式上, 當然這樣是很方便的, 不過萬一遇到的不是網站而是大型的網路應用程式, 可能這個做法會讓你非常頭痛, 等到寫幾百隻php時回頭除錯真可形容為"欲哭無淚"。而 MVC 所指的是把 1.資料處裡 2.流程邏輯 3.畫面顯示 分開, 這樣針對不同的功能產生清晰的分類, 維護與除錯就不再是一件惱人的事。

傳統的寫法

MVC的寫法

此外 cakePHP 在資料層(Model)做了物件關連映射 ORM(Object-Relational Mapping) 的處理, 可以以物件導向的方式操作資料庫欄位(做了映射, 欄位變成物件屬性或方法), 對於不熟悉關連資料庫的朋友也是一大福音。

長久以來物件導向與程序導向都各擁有一派死忠者, 但我個人認為並沒有甚麼好擁護的, "適得其所"才是最重要, 一個小型程式不需要把它用大工程的方式進行, 而一項大工程基於良好的時效與後續維護, 也應該採用物件導向而非程序導向。

但說來說去還是沒有好好研究cakePHP, 或許等以後有案子碰到在說, 畢竟重點是觀念而不是技術。