目前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