Flex 2 pre-beta 新功能介紹

mark anders’s blog

mark 在結束亞洲四場 max 2005 演講回到美國後終於貼出這篇文章，裏面介紹了過去兩個月(Oct, Nov)來 flex team的最新進展，進步的程度實在很驚人啊~

簡單整理如下：

＊design view:

-新增了 in-place editing：基本上就是把 dreamweaver 那套搬來eclipse，但對flex coder來說用途可能不大，拐designer來玩 flex 的企圖到是挺明顯。

-snapping and guides: 這也是直接把 flash 7裏面的相同功能搬來，因為不算新東西所以只能算是理所當然…(不過，要在eclipse裏實作這種事還是很不容易啊)

-VBox and HBox editing:這兩個元件說穿了原理很簡單，自已用 mc做一個也不會太久，但在flex裏很難用視覺的方式去編輯它，現在直接把 dreamweaver裏 expand view那套搬來不就解決這個問題了嗎？:-)

＊ code editing

基本上alpha 1 與 eclipse 都是挺不錯的東西，我對兩者也有極高的評價，唯一可惜的就是在alpha 1中的 code editing能力簡直陽春到令人髮指的地步，該有、常見的功能幾乎全都沒有，例如 comment out，例如 drag-move/copy等。

但現在可改觀了：

-auto-import： 這真正是無敵好用的神器啊~因為從AS3起，所有東西都是class，因此整個語言的結構變的龐大許多，基本上每次開一個新的class檔就至少要先 import 五六個class進來，不然可能連 trace()都沒辦法用，現在有了auto import 它就會自動將有用到但沒宣告import的class都叫進來囉！

-code collapse, auto adding ASDoc comments, block comment, block un-comment, ctrl-click hyperlinking, quick keyboard filtering：

這些東西光是看到就快掉下感恩的眼淚，終於親愛的 block comment/uncomment回來了，更別提還有 code collapse 與 ASDoc支援，這下誰都沒有理由說不想寫doc 啦~

＊view states 與 new Transitions:

view states 是整個 flex 2裏我最重視的部份之一(呃，好吧，其實AS3更重要，但從framework 與 architecting 的角度來看，view states的角色比較關鍵)，現在不但可以隨不同的操作 state來切換 view state，更多了一狗票的 transition effects，文章是這樣寫的：

The windows would spin, bounce, and move through interesting paths as they shuffled around

實在很難不讓人興奮的想到 os x 裏面的 widgets 或 user切換效果啊~這下子真的可以好好看看那家ajax solution能做到這件事(同時還一樣的優雅…)

＊player performance:

VM for speeding !!?

AS3 + FP8.5 原本就已快到一個不可思議的境界，就算以現在這樣的表現要我掏錢出來埋單都會毫不猶豫的點頭，但現在mm把它變的更快了，舉個例子：

一個50 rows(皆內含複雜 cell renderer ) 的datagrid從上捲到下要多久？

有實際做過這件事，尤其是有使用複雜 cell renderer經驗的人會知道，V2 DataGrid + complex CellRender === “suicidal tendency”，在以往 As2+FP7的時代(現在有人稱這種組合叫做 legacy system了，哈哈), 這樣的操作要 15s，換算成電視廣告託播費大約要30萬。

而現在用 AS3 + FP8.5x 則只要 1.25sec，看清楚，50列內含cell renderer的datagrid 捲動完只要 1秒多，天吶~flash都能變的如此快，世界應該也會變的更美好，再也沒有戰爭，only peace and love….

這下子應該沒人會再懷疑未來在何方了吧？:P

apple genius bar – Concierge

apple 在感恩節 black friday前在全美各分店開始全面採用新的客戶服務系統 Concierge，有趣的是這整套系統都是用 flash 寫成的，然後開啟時變成full-screen就很像一個應用程式。

把玩

這套系統的功能非常簡單，在某些 apple store裏有所謂的 genius bar，也就是類似檢修站的服務，客人帶者自已的電腦或ipod進去排隊就可以找到人維修，以往這個系統是用來查預約時間與送修取件時間之類的；新版本中比較的突改變就是把服務項目分的更細，例如 ipod 就跟 mac 切開來，這樣兩邊的人都不用等太久。

呃，三句話不離本行，會注意到這個程式當然是因為它用flash寫成，所以把玩過後就順手抓下來「分析」一下裏面寫了些什麼。

基本上它的結構就如上圖一樣，是以 screen 為單位來切割，依不同的操作動態載入需要的 screen，有上過我ria課程的朋友們應該會很快的就將它們對比到 form 的概念去，這是完全一樣的系統架構規畫邏輯，只是他很大膽的用load的方式來載入需要的畫面。(這種做法有好有壞，但考量到安全性問題通常不會這選這條路)

整個程式的資料交換部份都是用xml 進行，甚至連介面也是用xml載入的字串去動態生成，這樣做最重要的目地當然就是多國語系，畢竟apple在歐洲與日本也都有直營的apple store。

另外一個比較有趣的地方就是資料傳輸過程有經過 MD5加密，因此在程式碼裏有一長串是MD5的class，只是想來想去這樣做的意義好像不大，一來是它裏面並沒有什麼輸入什麼了不起的資料，只有會員卡號或電話，另一方面MD5實在不是什麼安全的東西再加上swf等於是明碼，裏面的key是什麼都一目瞭然….

或許等Flash Player 8.5 普及後做個 1024bit DES加密才比較有保障

結論是：

1、又是一個 RIA應用的好例子：

雖然app本身難度不高，但卻很實際的解決了商業運作上的大問題(籍由良好的預約系統減少客戶臨店等待時間 –> 進而提升顧客滿意度)，這一直是我們最渴望達到的目地之一。

2、整個程式往發時間估計約一個星期，包含9個form與server端程式 + 資料庫，費用部份，從程式碼的寫作風格來看，非常像是apple自已人(而且應該是個日本人)寫的，所以費用應該是零吧。

恐怖的 3ds parser in AS3

繼 Darron Schall 寫出 AS3版的 vnc client後，今天又看到一個恐怖的 AS3 範例

franto透過 FP8.5裏 binary socket 從 server 將 .3ds 檔案讀進來後，即時parse然後透過 Drawing API生成 3d 物件，上面範例中的章魚就是這樣生出來的，整個render 時間只要 200ms。

這實在是非常有趣的應用，雖然目前只有 wireframe而且不能轉動，但假以時日一定會有人把rendering & ray tracing做出來，想想看屆時把它整理成一組3d API後，可以玩的東西與潛力有多大？想搞數位內容？想創造無敵遊戲境界？未來就是這個了啊~

從這個例子中，可以再一次看出 AS3 + FP8.5 的 JIT Compilation是多麼重要的進展，一旦 VM 自已爭氣，能在上面玩的花樣就多了，可以想見未來一到兩年flash的發展必然是不可限量啊~

unit test 與 AsUnit 3.0 – 關於 testing 與 test-driven的兩三事 (3/3)

testing這件事對許多工程師來說都是：知道它很重要，但從來不覺得應該去做。

在瞭解如何使用 AsUnit這樣一個 test framework後，接者就可以來談談目前一般人進行testing的方式。

比較傳統的做法是先寫程式，然後再做 unit test，也就是程式碼寫好後再用一堆 test case去驗証它的正確性，這種做法初看是非常合理的，也符合一般常見的專案開發流程，先規畫、再寫code、最後測試，然後上線(我們就叫這種為 waterfall開發法)

但這種做法也有不少的缺點，最明顯的一個就是等到全部的code都寫好時才要進行測試，往往會覺得無從下手，因此此時可能已經有數十個class，而且彼此的關連極深，根本不知道該怎麼測起，搞不好連當初寫的工程師自已都忘了某個class是做什麼用的(別笑，你試試看自已寫個class不加註解，然後半年後再拿出來，看看你還能記得多少內容或理解它在做什麼)。

另一個麻煩就是此時才進行測試，即使發現了錯誤，恐怕也很難修改，或是能改但成本變的很大，因為這時一改恐怕就要牽動好幾個其它class，天知道改了這裏其它地方會不會爆炸。

有鑑於此，90年代未期開始出現一種新的聲音，強調不如在寫程式前先把 test case寫好，然後再以通過測試為目標去開發程式，這就是所謂的 test-driven design。

舉個簡單的例子，以前面的money class為例，傳統的劇情是這樣：

1、我希望這個class可以加總兩筆金額，例如原本3元，加上5元後得到結果 8元

2、然後開始寫 Money.addMoney() 這支method：function addMoney(){....}

3、寫好後用幾組不同的數字傳入 addMoney() 去看看結果是否正確

而在 test-driven的劇情則是這樣：

1、我希望這個class可以加總兩筆金額，例如原本3元，加上5元後得到結果 8元

2、接者我先寫些測試的case 做為將來測試使用，例如

3、然後開始寫 Money.addMoney() 這支method：function addMoney(){....}

但由於我已經知道將來會怎麼測試它，因此在寫的過程中就會特別留意傳入的參數與回傳的資料型態等細節要符合這個測試的期盼。

在 test-driven 的開發手法下，工程師寫程式是為了能百分之百通過 test case，因此在整個開發過程中就有了明確的依歸，只要test case有要求，就要在程式碼裏面完成(而且一定要完成)，而 test case 沒提到的事，就沒有那麼高的priority可以丟一邊先不管，因此只要 test case 寫的夠週全，將來成品就一定可用。

另一方面，在寫 test case的過程中，工程師也會有機會先想清楚整個過程，有點類似 forsee/preview 將來程式完成的樣子，然後根據他在腦子中的觀察，去寫下所有功能的 test case，這很像是讓建築師在還沒動手蓋房子前，就在腦中冥想出未來成屋的樣子，然後照者在腦中看到的畫面去建這棟房子；這與傳統先動手蓋房子等到落成那天才能看到全貌是完全不一樣的兩回事。

最後再仔細想想，反正不論早晚都是要寫 test case (當然如果你壓根就沒打算做 testing那就另當別論)，如果早寫可以帶來這些額外的好處，而晚寫卻要面臨種種風險，任何聰明快樂又有遠見的工程師應該都知道該怎麼選吧？

而 test-driven正巧也是近年來漸成主流的 agile development 重心之一，其中最為人所知的方法論就是 eXtreme Programmg (XP編程)，當然 agile development 是個大題目，值得另外撰文聊聊，但這裏的重點只有一個：越來越多的工程師在經歷了幾十年的專案開發歲月後，終於發現先寫 test case帶來的效益是何其之大。

現在flash coders也有了 asUnit 3這個重量級的協力工具，要怎麼發揮它的妙用就看個人囉

note: 寫完這篇心中已經浮起另一個題目 > toward an agile flash development 聽起來還挺炫的吧？(只是有沒有時間寫就看老天了)

Flash Media Server trial download

正式版的 trial已經可以下載了。

10人版不限頻寬也沒有試用期限，但限制做商業用途(廢話...)

整個FMS 2含安裝檔才 7Mb，但可以賣十萬 到 一百四十萬不等，想想真是智慧無價啊~

這是不是將來舉「書中自有黃金屋」騙小孩讀書時的最好明証？哈哈哈