目前Flash是不支持運行時加載SVG的。必須使用Embed的方式。
已經有人向Adobe提出了請求，不知道什么時候才能實現了：
http://bugs.adobe.com/jira/browse/SDK-11619
目前來說，使用SVG就會增Flash的體積，用來做些Logo之類的小東西還可以，做別的還是免了吧。
用了twitter之后這些小小的心得都有點不想往博客上寫了。
這兩天用BlazeDS做個小軟件，在用BlazeDS的時候發現，服務端的異常會被直接拋到客戶端，去了我心里一個疙瘩。雖然我還不知道他給拋哪去了，是去了回調函數，還是在調用代碼那里。不過他既然能拋回來，我就能處理咯，這都是小問題。
另外服務端返回的Java中的List，在BlazeDS中，都是給映射成了ArrayCollection。以后可以放心的處理了。
BlazeDS的文檔還只有在線的，看著十分不方便，尤其是公司那個網速，整個就是撥號時代的速度啊。
BlazeDS文檔地址：
http://livedocs.adobe.com/labs/blazeds/html/index.html
最終確定，這個東西是用flexmdi做的，而不是用的ventanas。不管用哪個，我都郁悶了一天，想不明白他是怎么做的旋轉，結果看了代碼發現，他把Flexmdi給改了。把人家的MDIWindow改成繼承ViewStack的了，恍然大悟。。。。。
【前言】早在半年前的項目之處就想采用TDD的開發方式，最起碼也要做到較完備的自動化測試。當時調研了很久找到一個叫FunFx的開源框架。可惜這個框架的試用之路并不平坦。最初找到的只有文檔，照著文檔做，失敗了。看到文檔上還是Flex2的，換成Flex2，編譯都通不過,原來Flex2需要lcds的license只好回到flex3。被逼無奈去看代碼，我的Ruby水平是二把刀，盡管改代碼了，但還是通不過。懷疑是不是不支持Flex3，而且項目進度又容不得我們慢慢研究，只好自己寫了一個功能有殘次的測試框架，湊付著用，后來因為框架的擴展速度慢慢跟不上開發的速度，最終連寫自動化測試用例的計劃也放棄了。隨著FunFx出了0.0.2，又對這個測試框架產生了一點希望，再次搭建的結果還是一度失敗，經過不懈努力，總算在大年三十的下午運行了第一個Hello World！。
【正題：搭建TDD測試環境】（下面我說的過程是我個人運行的過程，應該是運行FunFx的充分條件，但不保證都是必要條件，如果有人發現哪個步驟是不必要的。請在回復中指出。）
FunFX是一個基于Ruby的自動化測試框架，所以，我們必須要裝Ruby，我安裝的Ruby版本是Ruby-186-26。我的Ruby IDE是eclipse上的RDT插件。我的操作系統是筆記本自帶的Vista Home Basic，因此我的IE是ie7。我的Flex IDE是Flex Builder 3 beta3。
運行環境就這些，那么開始講解搭建過程吧。我們從下載開始說起，首先，我們要去
RubyForge下載FunFx 0.0.2，那是一個zip文件，記得要把Source包也下載下來，在后面我會說到它的用處。
下載完畢之后，將其解壓，我們可以看到三個文件：
- AutomationGenericEnv.xml
- FunFX-0.0.2.gem
- FunFXAdapter.swc
接下來，我們在FlexBuilder3中新建一個工程：LearnFunFx，在libs文件夾里加入下面三個swc文件：
- automation_agent.swc
- automation.swc
- FunFXAdapter.swc
這里面的前兩個swc文件來自flex的sdk里面。后面的一個就是FunFx里面的swc，但是這個swc有可能是無法使用的，因為它是為flex 2編譯的，這時就需要我們前面下載的源代碼文件了。源代碼文件解壓開之后可以找到FunFXAdapter文件夾。里面就是FunFXAdapter.swc的源代碼（包括測試代碼）。將其編譯成swc（如果你不會編譯成swc，請查閱相關文章或自己琢磨，給你個提示，可以用library project）。將我們自己編譯出來的swc文件拷到libs里。這樣我們就收集全了所有的類包。
接著將AutomationGenericEnv.xml拷貝到src文件夾下，然后在LearnFunFx.mxml中加入如下代碼：
<?xml version="1.0" encoding="utf-8"?>
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" layout="absolute">
<mx:Script>
<![CDATA[
import mx.controls.Alert;
]]>
</mx:Script>
<mx:Button id="test" x="255" y="146" label="Button" click="Alert.show('Hello World!');"/>
</mx:Application>
代碼實現的功能很簡單，單擊按鈕，彈出Hello World!的對話框。
代碼準備完了，接下來是編譯了。下面我們在我們的工程：LearnFunFx上點擊右鍵：選擇Properties，再選擇Flex Compiler，在Additional compiler arguments文本框中輸入：-include-libraries "XXXX\LearnFunFx\libs\automation.swc" "XXXX\LearnFunFx\libs\automation_agent.swc" "XXX\LearnFunFx\libs\FunFXAdapter.swc"
XXX表示工程根文件夾，自己補齊。
接下來，一個囫圇的swf文件就被編譯出來了。這里還有一個問題,html文件里面的Object標簽一定要有一個name屬性，其值要跟id一樣，這就需要我們改html-template文件夾下的index.template.html了。我的做法是把body標簽里的js代碼刪掉，只留下html標簽版本的，然后在Object標簽里面加上一個屬性：name="${application}"。再次編譯一個，將 bin文件夾下的所有文件拷到一個web應用中。
flex端的處理完畢了，接下來是Ruby，還記得那三個文件嗎？
在三個文件所在的文件夾中地址欄里運行cmd（這是vista的小技巧，其他的windows可以通過傳統的方式進入cmd窗口,并進入該文件夾），在命令行上輸入：
gem install FunFX-0.0.2.gem等待一小會兒，屏幕上提示：Successfully installed FunFX,
version 0.0.2，表示已經安裝成功。
然后進入Eclipse 新建一個ruby項目LearnFunFx，也將AutomationGenericEnv.xml拷到源文件同級目錄下，新建LearnFunFxTest.rb，輸入代碼：
require 'test/unit'
require 'funfx'
class LearnFunFxTest < Test::Unit::TestCase
def setup
@ie = Funfx.instance
@ie.start(true)
@ie.speed = 1
@ie.goto("http://localhost/.../LearnFunFx.html", "LearnFunFx")
end
def test_control
@ie.button("test").click
end
end
“...”是web應用的名字，自己補齊。代碼非常簡單，功能是打開網頁，找到名為LearnFx的swf，點擊id為test的按鈕。在運行之前，我們還要做一件事，不然的話，我們之前的所有努力都白費了。打開IE，按下alt，選擇“工具”-> “Internet選項”，點擊“安全”tab頁，將“本地Intranet”安全級別設為低，將http://localhost加入可信站點，并將可信站點的安全級別設為低。（這里是我不確定是否多做了什么的地方之一）。做了這些之后，ruby調用js就不會被瀏覽器阻攔了。（剛才試了一下，運行完測試用例之后再改回去也不會被阻攔了，搞得我很郁悶，但是在我修改這里之前，確實是無法運行的。）
然后我們運行該測試用例，我們就會看到一個瀏覽器窗口被彈出，swf中的按鈕被按下，一個Hello World!的對話框彈出。一切成功：）
（完）
因為二把刀的Ruby水平，導致我反反復復研究FunFX，最后問題居然出在IE的安全性上。不管怎么說，終于在今天測試通過了。新年里，這是一個非常鼓舞我的事件，終于可以給自己一個交代了，Flex對TDD是友好的。
最后，新年新氣象，跟所有看到這篇blog的朋友們拜個年。
今天在首頁看了一篇很有意思的博文：
談一談在家辦公的利弊
其實在家辦公對我來說是一個很遙遠的夢想。但是人總不能放棄夢想啊。也來一個假想吧。
說是假想，其實這些手法也是來源于一些分布式開發的討論。而在家辦公在一定程度上構成了分布的情景。
最早聽說分布式開發是一篇講分布式敏捷的文章，之后一直對這種神奇的開發模式十分向往，也看過一些討論貼，借著這個話題也來寫一些東西，主要考慮一下Web2.0產品對分布式開發可能會有的一些幫助。在那篇文章曾說到分布式開發的基本原則：
（注：可以接觸到實際客戶的一端一般稱為on-site，另一端可相應的稱為off-site）
原則說得很到位，總之，無條件的提高交流的效果。在手段上我覺得在web2.0時代，我們有很多更好的工具可以幫助我們進行交流。
首先，對那個MSN和Y！的做法我就不是很同意，相比較的話Twitter不是更好嗎？項目組成員一人注冊一個Twitter帳號，所有人互相Follow。制定一個制度（先不考慮制度的建立過程）每隔一個小時寫一個正在干什么。Twitter不就是干這個的嗎？就像Twitter輸入框上面寫的：“What are you doing？”Twitter還能對話，而且所有的對話都是公開的，方便每個人加入進來，天生是個開放的環境。Twitter還能發到手機上，外出有事也能接到小組成員的工作動態。并且隨時插入討論。當然Twitter畢竟是國外的，可能會有很多問題，比如哪天被盾掉，那么嘰歪，飯否也是可以選擇的。相傳磯歪的功能比Twitter更強大。
接下來我說的更多像是給Google做廣告了，但是不管你承不承認，Google這些工具確實很有幫助。
第一個，Google日歷，Google日歷可以拿來做計劃和工作日志，每個人一個日歷，項目組再做一個計劃日歷。每個人的日歷寫自己的計劃和日志，項目組的日歷寫項目計劃和日志。可以幫助項目組跟蹤計劃和統計工作量。甚至項目經理或組長可以拿日歷分配任務。拿任務日歷和日志日歷跟蹤進度情況。
第二個，Google Group，google的這個論壇可以拿來做項目組討論的地方，每一個發起的討論都可以記錄下來，還避免了平常口頭討論時不容易回溯的問題。但是單純的GoogleGroup還是比較麻煩的，只有在結合了Google的另一個拳頭產品之后，這個手段才是可用的。那就是Gmail。
第三個，沒錯，Gmail，Gmail中可以直接對Group發帖或對討論貼進行回復，并且每一個討論貼都可以折疊和展開起來。同時各個Gmail用戶可以直接聊天，聊天記錄也可以被保存在Gmail中。一切都是便捷且可回顧的。
第四個，Google Doc，不管我們怎么討厭文檔，大多時候文檔是逃不掉的。大家分布的情況下，文檔的管理和共享是個問題，但實際上，即便是不分布的時候，我們的文檔的管理共享也是問題（我總是在飛鴿上收到大量的文檔，導致我的文件夾中文件膨脹速度太快，產生大量垃圾，每次到找的時候總也找不到需要的文檔。）。為啥不使用Google Doc呢？文檔可以輕松共享，且大家可以協作完成一份文檔。且支持版本控制。
第五個，Google NotePad,這是一個很有趣的記事本工具，他有很多種用途，在我看來，他可以做能夠共享的TODO List，而且一些點子可以隨手記在上面，當哪天差不多了可以導出到Google Doc，我們可以用它來制定自己的計劃，并共享給組長或組員。
Google的廣告做完了，再來吹吹Adobe的，Adobe推出了一款在線會議室：BRIO，目前還是測試版。
我申請了一個個人會議室試用了一下，還是挺不錯的。可以共享桌面、聊天、語音對話、視頻，上傳文件。這些對于幫助在家辦公的人開會是很有幫助的。不過因為外國服務器的關系，速度有點慢。
即便這個東西因為網速等人力不可戰勝之原因跑不了，我們還有qq嘛，雖然因為眾所周知的原因，用QQ一般是降低工作效率的，不過我們可以申請一個工作用QQ嘛，這樣聊天、語音、視頻、共享桌面也都全了。而且在twitter的幫助下，配上TDD和持續集成的手法，偷懶應該是很容易被發現的。
以上就是我想到的可以輔助我們在家辦公或者說分布式開發的web2.0產品。
===========================
寫完之后我到回來想，其實有些用在辦公室里也未嘗不可。
FunFX是flex平臺下的一個開源自動化測試工具，可以對Flex進行TDD開發，目前，我已經進行了三次嘗試,可FunFX總也搭建不起來，心情極度惡劣。
最近突然想回顧一下設計模式，很多東西是要回過頭來總結一下的。今天先回顧一下單例吧。
很多時候覺得挺搞笑的，去面試的時候如果人家問你設計模式，一般都是要你寫個單例模式。去年來北京好幾家面試都是問我這個。當時我就想這個能反映出一個人的水平來嗎？還是說更多的是反映出這個公司的水平呢？
隨著一年的應用，很多地方都用過之后覺得，單例這個東西雖然簡單，可是現實是復雜的。所以單例這個簡單的模式也不能太小瞧咯。
單例其實有很多種實現，這是其中的一種，延遲加載的（好像英文叫Lazy？）：
[下面代碼中所有的構造器都是私有的，這里我就省略不寫了。]
public class ClassName {
public static ClassName getInstance(){
if(instance == null)
{
instance = new ClassName();
}
return instance;
}
private static ClassName instance;
}
這種的好處是我們的單例使用時才進行初始化，這樣方便我們在系統啟動時做些小動作。但是這個方式不是線程安全的，想要完成一個線程安全的單例，有幾種方式：
（一）
public class ClassName {
public static ClassName getInstance(){
return instance;
}
private static ClassName instance = new ClassName();
}
這種方式，可以保證我們的單例是線程安全的，畢竟我們唯一的實例在系統初始化的時候就構造了。可是Java的機制是static級別的變量初始化時互相調用是會報異常的。所以隨著系統的擴展，尤其還會有一些新手或者粗心大意的家伙（比如說，我）會亂用你的方法。一不小心就造成問題了。而且，你也失去了第一個方式中的一個小優勢，不能在系統啟動時做點小動作了。
（二）
public class ClassName {
public static synchronized ClassName getInstance(){
if(instance == null)
{
instance = new ClassName();
}
return instance;
}
private static ClassName instance;
}
這樣倒是線程安全了，也可以延遲加載，但是從今以后這個getInstance方法就是
synchronized的了，那絕對是很影響效率的。我跟朋友討論提出了幾種寫法，以期既能使單例可以在系統啟動不至于數據已經煮成熟飯又是線程安全的：（少數人討論結果，代碼可能會比較丑陋，僅供參考，歡迎拍磚）
public class ClassName {
public static ClassName getInstance(){
if(instance == null)
{
instance = ClassName.createInstance();
}
return instance;
}
private static synchronized ClassName createInstance(){
if(instance == null)
{
return new ClassName();
}else{
return instance;
}
}
private static ClassName instance;
}
這種寫法就很好的解決了這些問題。
還有一種寫法是這樣的，這個不是延遲加載的。而是采用了一種取巧的方式。
public class ClassName {
public static ClassName getInstance(){
if(!instance.isInit)
{
instance.initSingleton();
}
return instance;
}
private synchronized void initSingleton() {
if(!isInit)
{
reset();//這名字是有點怪異，我沒時間想太好聽的名字
isInit = true;
}
}
public void reset(){
//.....真正進行數據初始化的地方
}
private boolean isInit = false;
private static ClassName instance = new ClassName();
}
將所有的初始化代碼搬到構造器之外。這是專為數據初始化和復位進行的設計。所以我把reset開放了出來。
（【轉載者按：】雖然不是技術文章，相信對我們很多人都有教育意義，所以發到了首頁）
=========
剛在天涯看見一個HR的文章，總結他的經歷，以一個面試官的角度看求職者的種種。
不能不說寫的很好，總結得相當全面，而且非常體現細節決定成敗的觀點。
但是，一如一個網友所說的，這些東西對剛畢業的學生比較有用，對于打滾過幾年的人，就幫助不大甚至相反了。
當你的能力處于同一水平線的時候，一家公司要你不要你，開多少價錢，你選擇去哪家公司，都是很隨機的事情。只要沒有嚴重出格的行為，那么幾乎就是運氣主導一切。
就像《太傻十日談》中所說的那樣，各種各樣的面經都是成功者歸納的，也許他們注重了某一方面，在某個地方做得比別人好，所以他們就將自己的成功歸功于哪一方面。
而實際上呢？可能和他們總結的原因南轅北轍。
同樣，經驗都是失敗者總結的，心有郁郁者對自以為的某一失策耿耿于懷，于是將自己應聘失敗的帳算在這頭上，實際上也可能根本不是這么回事。
運氣，真的是運氣而已，一切都是命運的隨機。
唯一提高自己應聘成功可能的只有能力而已。
當你是不可取代的一員的時候，你可以穿任何一件衣服應聘，甚至可以以任何態度來對待面試官，無他，硬營銷而已。
當你的水準超過其他應聘人員，足矣讓對方眼前一亮的時候，一些細節可以忽略。
當你水準和別人差不多的時候，你必須三分人才七分打扮，才有十足的力氣去拼。
當你遠遠不適應這個職位的時候，再熟讀面經也是無用，就算是對方一時眼花招了你，且不說對他，光是干一份自己不適合的工作就夠痛苦了。
那天和朋友聊起她最近的一次面試，很平淡地談著，雖然也積極展現自己，但是不再扭曲，懶得偽裝，也不會激動甚至忘形。而她看見一個小男生面試，激動地面紅耳赤，一如我們當年。
呵呵，我第一次應聘失敗，把原因歸結于我要回學校寫論文和答辯；
第一份實習工作面試，我連自創營銷學派的狂言都說得出口；
第一次辭職，差點掉眼淚；
對于一個有著試用期女郎名聲和作為職業跳蚤的我來說，面試過無數公司，拿到過無數個OFFER，也被無數個公司拒絕過，回想起來，其實自己的成功和失敗，選擇與放棄，都是相當隨機的事情，并沒有什么很確定的理由。
而對于公司，選擇我還是選擇別人，為什么拒絕我，大多數時候只怕也是很隨機的事情吧。
而我在哪家做，做得如何，同樣也是這個詞語可以概括了。
成功的經驗也是那么多，名人們寫著出，飛來飛去地演講。比起來，我更喜歡他們的人生態度而不是具體到某個公司的工作經歷，或者自己總結的一些職場勵志類東西。
所處的環境不一樣，成功的方式怎么可能復制？
病癥不同，難道亂吃藥？只怕就是好了，也是撞大運罷了。
以前我一直覺得自己混得不夠好的一大原因是因為自己不夠堅持，不會忍耐，求成心切。當然，這也的確是我的毛病，但是并不能就將失敗歸結于此。
曾經想過要改，但是看看兢兢業業踏踏實實的人混得還不如我的時候，又迷茫了，到底該如何？
如今，我只做我自己，除了努力提高自己外，個性上的東西，不再做什么強求了。
也許這錯了，但是誰又能確定地說什么是對呢？
當你的能力有所局限的時候，你所能達到的高度也有了瓶頸，這是所有的技巧都不能彌補的。無論你如何在面試中偽裝，在工作中積極，能力缺陷始終會是你的天花板，即使偶爾沖破這層玻璃，但是碎玻璃一樣會劃傷自己，一旦跌落，體無完膚。
的確，一個好的平臺會給你很多，甚至有可能從此在職場上一帆風順，但是這真的只是運氣而已。我們敢用自己的一輩子去賭運氣嗎？
這個輪盤上唯一能增添獲勝幾率的，還是能力。至少，有能力的時候，你可以多一些選擇機會，這家不合適，換一家，還可以選擇自己做老板。相反，則是你必須去適應公司。
扭曲自己是很痛苦的，也會影響發揮。當然，很多成功人士說適應環境的重要性，但是同樣我們可以找到大量的案例說明扭曲自己不但沒有獲得成功反而弄得自己痛苦不堪。
然而時間是單程的，所以我們永遠不會知道自己如果選擇了另外一家公司，換了另一種做法，會是什么樣的結果？更好，更差？
想多了那個問題，只會給你帶來現實的困擾。
都是不確定的未來，為什么非要扭曲自己呢？有禮有節，不卑不亢，就足夠了。
也許，只是因為我老了，累了，懶了，開始給自己找一個玄乎乎的借口罷了。
但是真的不愿在為什么而扭曲自己，不想再去拼命考慮自己該如何做如何說，除非這不會違背我的本性，并且我知道這么做有一個很確定的好結果。
其實十多年前我就明白一件事情，為什么這么多年我卻忘記了？
當你知道該說什么的時候，就說；當你不知道該說什么的時候，就說實話。
回憶起來每當這么做的時候，事情也許沒有變得更好，但是的確沒有變得更糟。
祝我們好運！
=================================
轉自非著名作家--白水加冰的博客，更多精彩文章請移步：
http://blog.sina.com.cn/gyy101081
過去的半年，因為對于Flex的認識較淺，全部采用的HttpService的方式構建的我們程序的通信，這里面java對象與as對象的映射與解析是一份工作量不小的工作，不是沒考慮用DataSerive的RPC，因為考慮到收費就放棄了，前不久從InfoQ上一篇新聞得知，有開源的DataService：GraniteDS，而Adobe自己也在去年12月14日開源了一個:BlazeDS。
這下清除了我們成本和許可的障礙。前天下載了BlazeDS，稍微研究了一下，部署了一個應用。
結果非常的成功，一切都變得那么簡單了，我們可以輕松的調用后臺的Java方法。就好像調用flex本地的方法一樣。而且不用寫Java類和as類的映射(還是要寫兩行代碼的，在映射的類上寫這些：[Bindable] [RemoteClass(alias="Java全類名，自己替換")])，我昨天試了，非常好用。傳參和返回值都是跟直接調flex的函數一樣（除了是異步的。這里我們看得出Flex對Java是非常友好的），還沒試異常。而且配置也是非常簡單的，在WEB-INF/flex/remoting-config.xml 下配置一個類似這樣的標簽就可以了：
<destination id="product">
<properties>
<source>flex.samples.product.ProductService</source>
</properties>
</destination>
調用也非常簡單（以mxml中的調用為例）： <mx:RemoteObject id="srv" destination="product"/> destination屬性的值就是配置文件里<destination>標簽的id屬性的值，之后我們就能像使用as對象一樣使用他了。
前后臺的對象保持一致的辦法也只是有一個什么樣的Java對象就寫一個什么樣的as對象。
部署也非常簡單，將BlazeDS下載到之后，解壓完畢我們可以看到三個war包，三個文件夾，和一個license,其他的不看，三個文件夾分別是：
顧名思義，第一個是文檔（現在還不全，想看全的還得去網站上看在線的）；第二個是一些可能會用到的資源，比如Jar包什么的；第三個是保存有例子的tomcat，webapps里面有三個web應用，分別對應那三個war包，但其中最有用的就是blazeds-samples這個了從里面我們可以看到所有豐富的例子，而且單擊右鍵選擇View Source還能看到代碼，而blazeds就是我們部署一個基于BlazeDS的web應用的空文件夾，所有該web應用需要的Jar包和配置文件都全了，而且都在他們該在的文件夾里。不過你要真的跑起來，在你的tomcat里還要部署些server級的東西，那個就在我們的resources/security/tomcat里，參照該文件夾下的readme.txt部署。
另外，即便是對HttpService和WebService的應用方面他都有一個很好的框架，他還有一個message框架，目前我還不清楚是干什么用的，猜測也許像JMS。
在對J2EE的支持方面，GraniteDS號稱已經支持EJB3.0,Spring,Guice,Seam，BlazeDS我還不知道，不過GraniteDS的作者對BlazeDS是持一個開放的態度的，且兩者的開源協議是同一個，可以互相拷貝代碼，所以我相信將來兩者都會更強大。
簡單的配置，清晰的結構，強大的功能。在試用之后，我堅信Flex中J2EE開發的王道一定是各種Data Service。
=========================
BlazeDS的網址：
http://labs.adobe.com/technologies/blazeds/
題外話，推薦一個Flex for Java的網址，希望對Java程序員有幫助：
http://flex.org/java/
短到只有幾個字的前一篇就當是序好了。還不至于厚臉皮到那么幾個字就當成是一，雖然我是很想。。。。
我想了一天，我為什么要選Ajax？或者說Ajax的優勢在哪里？大概有：
- 對公司而言，有豐富的現有資源可供整合（Applet、ActiveX控件）。
- 完全開放的平臺、完美的技術組合：HTML+CSS+Javascript、技術框架已經非常成熟。
- 容易上手，普及率高（這對項目經理來說是多致命的誘惑），足夠多的在線資源可供搜索，無數同行的blog和論壇為你的應用之路保駕護航。（尤其在中文方面，一個js的問題查找解決辦法很容易的，幾乎你的每一個問題都有人解決過了，而一個Flex的，麻煩輸英文吧，還不一定有人解決過，我就找到了好多許愿的帖子，愿這個問題在下一個版本中解決。。。。。。）。
- 單個頁面足夠小，幾乎沒有加載時間（相對于Flex）
- 各層次完美的分離，而且是真的分離了（相對于Flex，Flex只是程序結構上分離了，部署了之后不會有太大的區別）。你不得不承認，作為前輩Ajax的結構相當完美。
- 對“敏捷”友好，容易TDD。
- 配有強大成熟的自動化測試工具助你完成健壯的程序。
如果以上還不足以讓你覺得Ajax有什么吸引人的，那么麻煩點擊下面幾個鏈接：
什么叫豐富的資源，以此為例：
http://www.java2s.com/Code/JavaScript/CatalogJavaScript.htm
http://www.java2s.com/Tutorial/JavaScript/CatalogJavaScript.htm
http://www.java2s.com/Code/JavaScriptReference/CatalogJavaScriptReference.htm
http://www.java2s.com/Code/HTMLCSS/CatalogHTMLCSS.htm
http://www.java2s.com/Code/HTMLCSSReference/CatalogHTMLCSSReference.htm
什么叫成熟的框架，HTML和CSS已經在全世界廣泛應用了許多年，在JavaScript領域也有成熟的類庫和控件庫，比如：
http://www.prototypejs.org/
http://www.extjs.com/ 不知道ext又怎么踩著gfw尾巴了，鏈接被重置，友情提示，請準備好穿墻工具查看
http://jquery.com/
如果上面的那些還不能讓你滿足，那么Tin的ppt應該可以喂飽你了，其中甚至推薦了可以使ie6的bug消失的神奇js庫和CSS框架：
http://www.haokanbu.com/story/5889/
http://www.haokanbu.com/story/5892/
如果你覺得Flex的開發工具非常好，相對于Flex Builder我們也有這些開發工具（雖然他們也支持Flex）：
http://www.aptana.com/
http://www.jetbrains.com/idea/features/javascript_editor.html
有上面的這些東西輔助，基本的項目我們都可以搞定，為什么要選擇Flex呢？而且根據我的開發經驗Flex有下面幾個缺點：
- Flex編譯出的程序過于龐大，什么都不做都有幾百K，如果加入一個字庫的話更是會有上M的大小，雖然現在采用了RSL的方式，解決了一些尷尬局面，但是也不能改變其無法廣泛使用在廣域網上的境地。
- Flex的編譯速度慢，相傳全部用as而不使用mxml可以提高編譯速度（可問題出來了，那我的Flex操作性就變差了，跟Ajax有啥區別）
- 如果選擇AIR，那就不能利用公司現有的web資源，比如一些activex控件、applet等，需要重新開發。說句題外話，當你不得不調用這些本地相關的玩意時，從一定程度上影響了他的跨平臺的能力。
既然這樣，Flex這種玩意還有啥選擇的必要嗎？
休息。。。。。。
聽Tin的Topic之前就在考慮自己應該在什么情況下用Flex，聽了Tin的topic之后更得考慮這個問題了。
Ajax（我暫且借用這個名詞）在強大的開源庫及現代化的ide的支持下，已經很強大。
Flex這時過來橫插一杠子，實在是很沒意思。取代Ajax，絕不是一個很好的主意。（雖然我曾經這么想過）
面對強大的Ajax和超炫的Flex，我總是會問自己很多問題：
Flex可堪大用嗎？Flex和Ajax是進一步互補還是在一次握手之后分別向兩個領域發展呢？Flex會是前端的Java嗎？AIR是Flex的未來嗎？BS模式會不再成為主流，CS模式會再一次流行嗎？
夜已深，悍然歇晌，暫時先給自己挖個坑好了，省的自己忘了這個問題。
早在AgileChina上聽過關于Lean的只言片語，OpenParty上沖著這個名字于是跑去聽路寧的《Lean Thinking with Examples》。
這個Session很有意思，討論也很激烈，以至于嚴重超時。雖然聽了之后還是對單件流一知半解。即便Google了一些也沒完全搞明白這個東西在生產中的價值，以及操作的手法。不過對于Lean--識別和消除浪費的技術（路寧的ppt中還有對浪費的解釋：不產生附加值的活動。我個人認為這個解釋反而讓我糊涂，于是給去掉了。），總算有了一定的初步認識。
路寧在講演中，一直在強調要考慮端到端、對最終用戶價值的重視。這是一個很棒的新思維。我們的思維慣性里，對短板效應比較重視，總是對最短的那個木板進行優化，但是豐田直接把木桶扔掉了。因為在他們的模式里，木桶接水，是一種浪費。這種讓人耳目一新的思路，不由得使我想起了郎咸平的那個案例：時裝行業的SARA。
他們為了解決3家大工廠和400家小工廠之間的物流問題，建了200公里的地下隧道，用高壓空氣運輸；他們用空運而不是海運；他們款多量少；他們根據銷售情況快速反應制作下一個款式；他們從設計到出現在店里的時間（又稱前導時間）為12天。而我們國內一般最快的是60天，最慢的能到180天。因為我們會怎么做？3家大工廠與400家小工廠太分散，集中。海運便宜，選海運。一個款式還在熱銷我傻了我不大量生產？比較來看，我們的手法從常識上來講似乎是減少了浪費：集中了，更有效率，減少了運輸浪費。海運便宜，減少了運輸成本，把每一個款式的銷售額發揮到了極限。結果，我們的前導時間是他們的幾倍甚至十幾倍更不要提他們因反應敏捷帶來的快速設計新的款式的加成效果了。他們引發了時裝界的革命，我們只能惡性競爭，一塊死掉。
這就是說，浪費有很多是反常識的。讓我們考慮，時裝行業，對最終用戶來說最大的價值是什么？新潮、時髦的衣服。最好能不要跟人撞衫。
從這個角度上再來看，考慮端到端，最大的浪費是什么？前導時間、同一款式過多的量。現在你再倒回去看Sara模式，他不成功誰成功？咱不失敗誰失敗？
李劍在session中提到一個故事，一個人外出，準備了各式各樣的預防措施，最后走到橋上，橋折斷了。這個故事說明，我們經常為了害怕的風險做一些無謂的預測行為，反而變成了浪費。我們要找到我們真正的問題，我們軟件開發中，也常常做預測（預先設計），以防項目中會發生的變化措手不及。這本無錯，可是我們經常把本質問題扔到一邊，熱衷于預先設計了。做那么多預先設計不一定能預防項目中發生的變化造成的措手不及，這是一種極大的浪費。（有時候我看到人們對預先設計的熱衷，不由得感覺，那有點像對祈雨之舞的迷信，同學們，我們的目的是讓他下雨，不是跳舞，當然你一直跳一直跳他總會下雨的，不過你不覺得那是蒙的嗎？）我們真正的問題是為了變化不會殺死我們的項目（起碼最壞的打算是這樣的），別的都是手段而已。再回到sara的例子上，3家大工廠與400家小工廠的分散，從表面上看，不集中會帶來浪費。但實際上，真正的問題是不集中會導致物流的不暢通，這個問題解決了，管你集中不集中呢，對吧。集中往往還會因為臃腫而導致效率低下呢。
我們要透過現象看本質，消滅慣性思維。通過這個session，我又一次認識到了這個思維的重要性。。。。。。
=========
附：
路寧Session的報道：
http://www.infoq.com/cn/news/2008/01/lean-2008-beijing
如果使用VideoDisplay，那么他有一個屬性，叫cuePoints，值類型為數組，數組中的每個元素要求有兩個屬性，一個是name，類型為字符串，一個是time，類型為數字，表示觸發時間的秒數。例如下面的代碼，當播放到3s時將彈出一個對話框。這用來解決一些播放到某一時間點觸發某事件的情況。
<?xml version="1.0" encoding="utf-8"?>
<!-- LearnCurPointEvent.mxml -->
<mx:Application xmlns:mx="http://www.adobe.com/2006/mxml" layout="vertical" creationComplete="init()">
<mx:Script>
<![CDATA[
import mx.controls.Alert;
import mx.events.CuePointEvent;
[Bindable]
private var myCuePoints:Array = [
{ name: "first", time: 3}];
private function init():void{
this.c_mainVideoDisplay.cuePoints = myCuePoints;
this.c_mainVideoDisplay.addEventListener(CuePointEvent.CUE_POINT,cue_PointHandler);
}
private function cue_PointHandler(event:CuePointEvent):void{
c_mainVideoDisplay.pause();
Alert.show("It plays " + event.cuePointTime +"s.","",4,null,go);
}
private function go(event:Event):void{
c_mainVideoDisplay.play();
}
]]>
</mx:Script>
<mx:VideoDisplay id="c_mainVideoDisplay" width="320" height="240"
cuePointManagerClass="mx.controls.videoClasses.CuePointManager"
source="phone.flv"
autoPlay="false" />
<mx:Button label="播放" click="go(event)"/>
</mx:Application>
高陽爆發
http://www.tudou.com/programs/view/avvIlA-G7xI/
文章來源:
http://tj19832.blogcn.com/diary,12102578.shtml
海豚音再現：
http://www.tudou.com/programs/view/BKOeNi5keRY/
文章來源:
http://tj19832.blogcn.com/diary,12178392.shtml