Google IO大會上Guido van Rossum對於GAE的演講

由於python創始人Guido van Rossum被Google收錄進去...所以python可說是google開發的主力,而GAE也是基於python + django的環境改寫而成, 我們來聽聽去年Google IO大會上Guido van Rossum對於GAE的演講

然後也有介紹python的特性與其他相關部分

Flash Loader 載入外部 swf 時 stage=null 的問題

剛剛寫as的時候發生一個問題，由於被載入的swf裡頭有運用stage作場景控制，故被主頁載入時出現 TypeError: Error #1009: Cannot access a property or method of a null object reference.

原因在於被載入的swf在主頁尚未將它加入至場景上時就呼叫了建構子，因此，我們可以運用以下的方法解決：

public function Page05DocumentClass()
{
    if (stage){
        initApp();
    } else {
        addEventListener(Event.ADDED_TO_STAGE, initApp);
    }
}
        
private function initApp(evt:Event=null):void
{
    stage.scaleMode = StageScaleMode.NO_SCALE;
    stage.align = StageAlign.TOP_LEFT;
}

先判斷stage是否存在，如不存在則以stage.ADDED_TO_STAGE作為啟動的依據。
但...這感覺是bug...

創造「耐心練習周期」(轉)

的確我是一個極度沒有耐心的人，所以要從現在開始訓練...

耐心是心的一種性質，可以藉由蓄意的練習而大幅提升。我發現可以磨練耐心的一個有效方法，就是創造真正的練習周期，也就是在心中設定練習耐心藝術的時間周期。生活本身變成了一間教室，課程叫做「耐心」。

你可以從短短的五分鐘開始，然後逐漸延長你的耐心的容忍度。剛開始的時候，不妨告訴自己：「好，接下來這五分鐘，我不要對任何事情生氣，我要保持耐心。」你將會有驚人的發現。保持耐心的企圖，尤其是你知道只要忍耐一下子，就會立刻加强耐心的容忍度。耐心是那種食髓知味的特質，你將會發現，你確實有能力保持耐心，即使時間長一點也可以。日子久了以後，你甚至會變成一個很有耐心的人。

當我們保持鎮定時，不讓自己生氣或懊惱時，就可以冷靜而堅定地控制行為，這比發怒生氣有效多了。這個讓心靈朝耐心努力的過程簡單易學，重要就是把持自己想發脾氣的情緒，不再鑽牛角尖。

有耐心讓自己得以維持心靈的平衡。没有耐心的話，一件小事就會化為緊急大事，以嘶吼、挫折、傷感情、和高血壓收場。這樣真是不值得，不論你是需要跟孩子、上司、或一個不可理喻的人打交道，如果你不想「為小事抓狂」，改進你的耐心功力，成就高度的EQ，這是最佳有效的調合劑，就從現在開始吧！

前瞻與創意思考

創新事實上是指創意加變革，單單只有創意但未付諸行動，就還不是創新。例如 明基科技董事長 李焜耀 說過“創新是一種行為的習慣，習慣獨特的方法、理念與結果，勇於做自己”，不隨波逐流，不盲從，正是創新的根源。

但是，創新並不是突然靈光乍現就足夠，必須還得包括詳細的分析與系統化的流程一步步實現，然而時代在變，人也在變，整個外在環境都在劇烈變動，組織的管理與運作也必須改變，不過需要改變什麼？什麼需要改變？可以奇異的領導力四個“Ｅ”為其重點：

(一) Energy : 高度的幹勁
(二) Energize : 激勵他人的能力
(三) Edge : 制定艱難決策的精準度
(四) Execute : 貫徹執行達成目標的能力

由此可見創新是能夠被管理的，但如何能有效領導創新呢？身為一個創新領導的角色，該員必須要有幹勁，並能影響其他人使他們同樣有幹勁，另外必須要精準不莽撞(瞎忙)，並要真正做的到。換句話說，改變與變革必須從領導者本身做起，先革自己的命，在帶領整個企業完成變革大業，整個關鍵在主管思維的改變。邱教授認為可在日常生活中實際做出五種改變：

(一) 閱讀(而非瀏覽)
(二) 溝通(而非命令)
(三) 欣賞(而非排斥)
(四) 寬容(而非封閉)
(五) 思考(而非情緒)

創新立基於四項要素：資源、組織文化、組織氛圍、程序，四種要素都等同重要，必須善加整合才能有機會成功創新。而當條件均完備後，則必須揪出阻礙創新的幾項因子，諸如：策略模糊不清、欠缺事務輕重緩急概念、領導風格過於集權與放任、高階團隊缺乏效率、中階主管協調與溝通能力不足，部門間沒有生氣與缺乏互信等...，排除上述條件後，最後仍需要有效的前瞻性思維，如此才能將成功的機率提高。

適當地運用研發與創新

"研發"囊括了"研究"與"發展"，並可細分為三個部分:

1. 基礎研究 - 主要為了增加科學知識，或許沒有後續的商業應用。
2. 應用研究 - 增加特定應用或需求的知識。
3. 發展 - 應用知識產生有用的實體產品。

Sam感覺大部分在台灣的中小企業都是先產生3的想法再回過頭去研究2...至於1基本上是無產值所以不太被重視。因為總是要在最短時間內得到成效，如果不好才能評估改進或淘汰，或許因應各國的風情不同會產生差異性的結果，但從過去歷史的經驗上，很多大賣的產品都不是專門為了商業利益所開發，可能是機緣巧合，也可能只是對該項事物有極大化的熱情，而促使個人與團隊不惜成本去研究，最後出乎意料的受到好評。

日前感謝"大Sam"的關照，有榮幸去參加Google Marissa Mayer的座談會，她也敘述了Google為外人津津樂道的80/20理論。Sam認為，20%的時間拿來計畫員工真正想做的事的確是有其必要，當然公司或許會有很好的idea產生，另一方面也是舒緩了員工的一週內的長期工作壓力，人就如同橡皮筋，久了之後會彈性疲乏，效率越來越低，如果在此能得到一些成就感之類的激勵，將會快速且有效的恢復"彈性"，也為公司帶來好績效。

當員工自行利用空閒時間進行基礎研究時，應該要感到相當高興，因為他可能是真正熱愛這份工作，千萬不要認為不能為公司帶來財富就去遏止，機會是隨處可見的，遇到對的人、對的時間，就有很大的機率能夠成功。

Objective-C 初級讀本翻譯

由於目前 Sam 開始寫 iPhone 程式，但又完全不熟悉 Objective-C，所以只能依照 Apple dev center 內的教學流程走，當然也要從 Objective-C 的一些觀念下手，Sam 花了兩天時間將 Learning Objective-C: A Primer 這篇文章翻譯成中文，畢竟有關資源實在太少，也只能希望未來更多人能夠幫忙翻譯裡頭一些好文章，讓大家一起加入 iPhone 開發的行列。

如果翻的不好還請多多見諒。

文章下載

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, 或許等以後有案子碰到在說, 畢竟重點是觀念而不是技術。