之前不知道做了什么，搞得Flex Development里面的AS项目无法自动检错，写了错误的代码它也不会检错，后来还一度打算换FDT呢，不过那个太卡了，没法用，只能硬着头皮解决Eclipse问题。

重新弄了个Eclipse，然后扩展了FB插件，问题依旧，在FB打开也是，初步判定是工程的设置有问题。

进入项目，右键属性设置，建立Main文件夹，并且设置Main函数，也就是项目启动后第一个运行的程序，（在ActionScript Applications 和ActionScript Build Path都要设置），另外还可以设置Run，那样当你点Run时，就会自动编译生成swf了，太强大了。

我使用svn一直很顺利，今天在改了两个地方之后，提交时输入了两句话(只有两行)做为注释，但是确定提交时失败，说“Cannot accept non-LF line endings in 'svn:log' property”，中文翻译就是标题所示。

我晕，以前都是很正常的，没有碰到过这种情况，好像注释多少没有什么关系的

把第二行的结尾处增加了一个回车，这样有三行，第三行是空的，但提交还是一样的错误，

然后只好上网上查了一下，很多是英文的，找了三篇文章，其中一篇中文的解决了：每一行以空格结尾

我删除第三个空行，在前两行的后面都增加了一个空格，然后就提交成功了

这篇文章上还有人说需要以标点符号做为结尾，但我试了，以“.”结尾还是无法提交

终于发现，很“牛”的软件，也有这么傻瓜式的bug存在

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/jszj/archive/2009/05/25/4214626.aspx

职位描述：
你将出任团队的ScrumMaster角色，直接与产品及研发团队工作，计划并保证在每一个开发冲刺中提交高商业价值的产品功能；
推动每日例会，解决团队碰到的障碍，跟踪团队进度，持续沟通寻求产品和研发双赢的解决方案；
你还需要担任Srum导师的角色，培养更多能推动Scrum方法的人才。

职位要求：
计算机相关本科或硕士学位；
5年研发项目经验，3年项目管理或QA经验；
有Scrum开发项目实战经验，担任过Scrum Master角色；
熟悉feature驱动开发模式，了解配置管理，持续集成；
出色的人际交往能力，优秀的计划及沟通技巧；
有直接与产品部门及技术团队合作的经验；
熟悉至少一种开发语言和一种脚本语言。

Scrum Master

学历要求：本科|工作经验：3-5年|工作地点：上海  |月薪：1000-50000元/月|发布日期：2009-12-10

Job Description - Keep the team focused on delivering highest business value - Strong emphasis on teamwork and close collaboration across all roles and functions - Work with other Scrum Masters to coordinate and mitigate dependencies across teams - Ensure that projects have a clearly defined release scope and meet overall objectives, standards, quality and user needs - Must possess personal leadership skills, initiative, and strong attention to detail - Manage multiple projects simultaneously and work with outside vendors - Work with team, cross-team resources, and stakeholders to mitigate risks and remove barriers - Synchronize with non-technical teams to deliver product releases smoothly - Coordinate system and project dependencies for releases - Engage, motivate and focus the team to stay on task and on target - Serve as a change agent to coach and mentor team on Scrum practices - Guide the Product Owner on how to maximize ROI and meet their objectives through Scrum - Provide visibility to the organization regarding team's progress and release schedules Required Experience - Proven experience releasing software products to market successfully - Bachelor's Degree or equivalent experience and approximately 4-6 years related experience - Excellent leadership and interpersonal skills to motivate the team and interact with the various stakeholders - Ability to understand technical subjects - Strong written and verbal communication skills - 4-5 years project management experience - 2-3 years Scrum experience Highly Desirable - Experience with transitioning an organization to Scrum - Experience leading teams in the development of .Net-based software development - Experience with Microsoft Team Foundation Server - Scrum Master certification

摘要：产品负责人的详细职责包括三个主要领域：客户需求，项目成功和团队合作。在Scrum中，产品负责人要与客户沟通需求并理解这些需求；保证项目成功是产品负责人的第二个职责；最后一条也很重要：产品负责人要与整个团队进行沟通协作，在整个过程中与利益相关者保持一致。

Scrum中，产品负责人这个角色具有很大的影响力，但要想运用得当，可没那么轻而易举：如能成功应用，就可以在客户/产品管理和开发者之间建立起全新而融洽的关系，企业也将因此而受益，甚至有可能增加竞争优势。不过天下没有免费的午餐：为了发挥其作用，组织要经常要做出有针对性的调整。这篇文章揭示了成功发挥产品负责人角色作用的奥秘。阅读之后，读者就可以明白：成功的产品负责人需要具备哪些素质。

强力胶

在Scrum中，产品负责人扮演着重要的角色。它根本不是为老职位设置的新名称，而是重新定义了业务和开发/IT之间的关系。需求的处理方式也在改变，不必再像过去那样，在项目一开始就必须完整描述，冻结之后再转交给开发团队。将管理项目的责任单独指派给项目经理，整个过程中没有客户代表的参与，这种项目管理的方式也变了。取而代之的是，产品负责人通过沟通了解客户的需求，指导产品的发布，并根据眼前的实际情况，不断在团队和项目干系人之间协调。可以这样说，产品负责人扮演了粘合剂的角色，他需要帮助最终客户、产品管理负责人、开发人员和项目干系人达成一致，确保大家都在朝着同一个方向前进。

这个角色通常是由客户或者产品经理承担的，所以业务层面也要开始了解Scrum，并做一些必要的变化与之相适应。虽然实际操作上有不少难度，但产生的结果物超所值。不仅能在业务人员和开发/IT人员之间建立起更融洽的关系，而且能给企业增加竞争优势：用户需求得到顺畅沟通；有专人负责版本目标的定义和发布；决策流程得以提速；误会和工作方向不一致的情况也得以避免。

工作描述

产品负责人的详细职责包括三个主要领域：客户需求，项目成功和团队合作。

在Scrum中，产品负责人要与客户沟通需求并理解这些需求。不妨将产品负责人想象成企业家：他们从业务价值的角度来制定软件产品的未来发展规划，并与别人沟通自己的想法。产品负责人要填写产品 backlog，并根据实际情况随时修改这些内容：可能要增加新需求，修改已有需求，这通常都是实时性的，而且这些修改都要在下一次sprint 计划会议之前完成。另外，产品负责人要对产品backlog上的条目排定优先级，确保团队总是在处理最重要的需求。

保证项目成功是产品负责人的第二个职责。这包括满足项目目标以及财务目标，如投资回报率（ROI）。产品负责人决定功能、发布时间，从使客户满意度最高和获得最高ROI的角度出发安排预算。产品负责人还要创建并更新发布计划及发布报告。

最后一条也很重要：产品负责人要与整个团队进行沟通协作，在整个过程中与利益相关者保持一致。产品负责人要和团队一起确认详细的需求。在产生疑问的时候，产品负责人解释需求，并根据当初就“完成”标准达成的共识对工作结果进行评估。最后，产品负责人要针对sprint计划会议做准备工作。在会前需要逐步分解需求，让会议可以顺利进行。

担当产品负责人的角色应该是全职工作，特别是涉及到需要大量创新或者很复杂的项目。根据项目的特性和规模，这项工作可以由最终客户、产品经理、市场人员或者客户来担任。

常见陷阱

老实说：产品负责人这个角色可不是那么好做的。这些年来，我见过许多产品负责人所犯的常见错误。下面这些是我想告诉大家的。

有些组织认为仅由一个人来担任这个职位很困难。为解决这个问题，他们会让多个人分担产品负责人的角色，例如产品经理负责用户需求，ScrumMaster负责项目成功和团队协作。我把这个问题称作“虚拟产品负责人综合症”。一旦陷入其中，公司将失去产品负责人所带来的很多好处，而且还丧失了本可以因此变得更好的机会。多人执行产品负责人的职责，只适用于多个团队参与同一个项目的状况。在这种情况下，我愿意与一组产品负责人工作，而且其中有一位负责整个项目（有时此人被称为产品总负责人）。

让IT人员或者程序员担任产品负责人，这是另外一个常见的陷阱。这意味着产品管理人员或者最终客户不愿意进行改变，不想担当起产品负责人的职责。“IT 产品负责人” 仅仅是技术和业务的中间人。这个角色将不再具备原本的影响力，也没有人来理解和沟通客户需求。业务人员和开发/IT人员不再为了合作而进行必要的改变，关系无法得到改善。跟以前一样，业务人员将需求交给开发部门之后就不再过问。（话虽这么说，也有特殊情况：如果是涉及多个团队的项目，其中有一个组件开发团队，那么让架构师充当这个团队的产品负责人，盯着他们的工作，这还是挺不错的。）

最后的问题是“蹦极产品负责人”（当然，这个名字来自Dilbert漫画）：一个几乎没什么作用的产品负责人，只参加sprint计划会议和复查会议。这类型的产品负责人很难主动控制和指导项目。许多没有答案的问题只能通过ScrumMaster简单的猜想或推测来回答。另外一些产品负责人还会妨碍项目取得进展。无论是什么原因，工作过度还是有其他更重要的工作——不能正常发挥作用的产品负责人会对产品发布起负面作用。

成功公式

如何能够避免上述陷阱，并成功发挥产品负责人的作用？我发现了三个关键因素：

1. 产品负责人必须得到授权
2. 担当该角色的那个人必须有足够的时间完成工作
3. 产品负责人必须称职

过去的经验证明，这几个因素非常关键。我发现：一个被授权的、能够全心投入的、称职的产品负责人，和Scrum项目的健康和成功之间，有着密不可分的关系。

“授权” 的意思是指：产品负责人有权力做决定，能为决定所产生的结果负责。这要求产品负责人能够快速做出相关决定，不需每次都要得到管理层的批准。我常常遇到这样一些公司，他们低估产品负责人的重要性，因此而使得产品负责人得不到足够的授权。如果产品负责人被任命领导重要的项目，那么高层管理人员应该为其提供直接支持。另外，产品负责人应该积极参与到发布目标的设定中，这样他就会完全负起达成目标的责任。

“缺乏参与” 最后将影响到项目的产出效率。必要的准备工作无法完成，决策延迟。正如前面提到过的，“蹦极产品负责人”只参加sprint计划会议和复查会议，因此很难迅速、全面地解决项目中出现的问题。他们无法与团队形成持续的协作，导致自己控制和指导项目的能力被削弱。

“称职”包括两个意思：完全了解客户的需求，具备敏捷和Scrum的实用知识。第二点包括能够实行相关的实践，例如准确填写和修改产品的backlog，或以用户故事的形式描述需求。在Scrum里，产品负责人需要接受适当的培训，这样他们才能很好地完成工作，就像ScrumMaster一样。一般说来，将 “Scrum认证产品负责人™”课程和上岗培训/指导结合起来，会产生最好的效果。

为了让产品负责人顺利发挥作用，你可以试试下面的方法：保证管理层都了解这个角色的重要性，并小心选择产品负责人的人选。此外，还可以让这个人投入尽量多的时间以胜任该职位，并远离其它工作的干扰。最后，要从长远发展的角度出发：培养产品负责人——要注意培养现有的员工，让他们准备好担任产品负责人的角色。这要求建立起内部的培训和指导能力。

陈年旧闻

产品负责人能够为组织带来很好的作用，当想做好却不容易。要培养员工成为好的产品负责人同样面临不少困难。有意思的是，丰田、本田以及其他一些精益企业，在很长时间内成功实施了产品负责人的机制。事实上，这种机制在丰田已经实施了差不多一个世纪。丰田公司的产品负责人被称作“首席工程师”，只有为人称道的资深工程师才能担任这个职位。首席工程师承担了产品负责人职责中的一大部分，同时还要承担首席架构师在开发项目中的工作。虽然首席工程师的工作要比 Scrum中产品负责人更有难度，丰田仍然成功实施了这个角色，并让它成为了强大的精益系统中的基石。丰田的例子说明，如果企业愿意作出必要的改变，产品负责人能够增强企业的竞争优势。

总结

毫无疑问：要发挥产品负责人角色的作用非常困难，但是适当的应用是成功Scrum的必要因素。削弱这个角色的权力也许可以让其更容易发挥作用，可是带来的好处也因此而减少了，所以要抵抗改造这个角色的诱惑。相反，要利用发现的问题和障碍，使之驱动组织进行必要的调整，这将对整个企业起到改善作用。企业可以利用这个角色来增强竞争优势。做出必要的改变是很艰难的工作，也需要花费一些时间。不幸的是，我没有发现Scrum有什么神奇的魔力可以让变化轻而易举地发生。如果我找到了，一定会让你们知道。我保证。

           讨论Web开发技术的历史，当然要先说说Web的起源。众所周知，Web这个Internet上最热门的应用架构是由Tim Berners-Lee发明的。Web的前身是1980年Tim Berners-Lee负责的Enquire（Enquire Within Upon Everything的简称）项目。1990年11月，第一个Web服务器nxoc01.cern.ch开始运行，Tim Berners-Lee在自己编写的图形化Web浏览器"WorldWideWeb"上看到了最早的Web页面。1991年，CERN（European Particle Physics Laboratory）正式发布了Web技术标准。目前，与Web相关的各种技术标准都由著名的W3C组织（World Wide Web Consortium）管理和维护。

　　 从技术层面看，Web架构的精华有三处：用超文本技术（HTML）实现信息与信息的连接；用统一资源定位技术（URI）实现全球信息的精确定位；用新的应用层协议（HTTP）实现分布式的信息共享。这三个特点无一不与信息的分发、获取和利用有关。其实，Tim Berners-Lee早就明确无误地告诉我们："Web是一个抽象的（假想的）信息空间。"也就是说，作为Internet上的一种应用架构，Web的首要任务就是向人们提供信息和信息服务。

　　 很可惜，在Web应用日新月异的今天，许多搞技术的人似乎已经忘记了Web架构的设计初衷。他们在自己开发的网站或Web应用中大肆堆砌各种所谓的"先进"技术，但最终用户能够在这些网站或应用中获得的有价值信息却寥寥无几。这个问题绝不像评论者常说的"有路无车"或"信息匮乏"那么简单。一个Web开发者倘若忘记了Web技术的最终目标是提供信息和信息服务，他的愚蠢程度就丝毫不亚于一个在足球场上只知道卖弄技巧，却忘记了射门得分的大牌球星。从这个角度来说，评价一种Web开发技术优劣的标准只有一个，那就是看这种技术能否在最恰当的时间和最恰当的地点，以最恰当的方式，为最需要信息的人提供最恰当的信息服务。

　　客户端技术的萌芽和演进

　　 Web是一种典型的分布式应用架构。Web应用中的每一次信息交换都要涉及到客户端和服务端两个层面。因此，Web开发技术大体上也可以被分为客户端技术和服务端技术两大类。我们先来谈谈客户端技术的萌芽和演进过程。

　　 Web客户端的主要任务是展现信息内容，而HTML语言则是信息展现的最有效载体之一。作为一种实用的超文本语言，HTML的历史最早可以追溯到上世纪四十年代。1945年，Vannevar Bush在一篇文章中阐述了文本和文本之间通过超级链接相互关联的思想，并在文中给出了一种能实现信息关联的计算机Memex的设计方案。Doug Engelbart等人则在1960年前后，对信息关联技术做了最早的实验。与此同时，Ted Nelson正式将这种信息关联技术命名为超文本（Hypertext）技术。1969年，IBM的Charles Goldfarb发明了可用于描述超文本信息的GML（Generalized Markup Language）语言。1978到1986年间，在ANSI等组织的努力下，GML语言进一步发展成为著名的SGML语言标准。当Tim Berners-Lee和他的同事们在1989年试图创建一个基于超文本的分布式应用系统时，Tim Berners-Lee意识到，SGML是描述超文本信息的一个上佳方案，但美中不足的是，SGML过于复杂，不利于信息的传递和解析。于是，Tim Berners-Lee对SGML语言做了大刀阔斧的简化和完善。1990年，第一个图形化的Web浏览器"WorldWideWeb"终于可以使用一种为Web度身定制的语言--HTML来展现超文本信息了。

　　 最初的HTML语言只能在浏览器中展现静态的文本或图像信息，这满足不了人们对信息丰富性和多样性的强烈需求--这件事情最终的结果是，由静态技术向动态技术的转变成为了Web客户端技术演进的永恒定律。

　 　能存储、展现二维动画的GIF图像格式早在1989年就已发展成熟。Web出现后，GIF第一次为HTML页面引入了动感元素。但更大的变革来源于1995年Java语言的问世。Java语言天生就具备的平台无关的特点，让人们一下子找到了在浏览器中开发动态应用的捷径。1996年，著名的Netscape浏览器在其2.0版中增加了对JavaApplets和JavaScript的支持。Netscape的冤家对头，Microsoft的IE 3.0也在这一年开始支持Java技术。现在，喜欢动画、喜欢交互操作、喜欢客户端应用的开发人员可以用Java或JavaScript语言随心所欲地丰富HTML页面的功能了。顺便说一句，JavaScript语言在所有客户端开发技术中占有非常独特的地位：它是一种以脚本方式运行的，简化了的Java语言，这也是脚本技术第一次在Web世界里崭露头角。为了用纯Microsoft的技术与JavaScript抗衡，Microsoft还为1996年的IE 3.0设计了另一种后来也声名显赫的脚本语言--VBScript语言。

　 　真正让HTML页面又酷又炫、动感无限的是CSS（Cascading Style Sheets）和DHTML（Dynamic HTML）技术。1996年底，W3C提出了CSS的建议标准，同年，IE 3.0引入了对CSS的支持。CSS大大提高了开发者对信息展现格式的控制能力。1997年的Netscape 4.0不但支持CSS，而且增加了许多Netscape公司自定义的动态HTML标记，这些标记在CSS的基础上，让HTML页面中的各种要素"活动"了起来。1997年，Microsoft发布了IE 4.0，并将动态HTML标记、CSS和动态对象模型（DHTML Object Model）发展成了一套完整、实用、高效的客户端开发技术体系，Microsoft称其为DHTML。同样是实现HTML页面的动态效果，DHTML技术无需启动Java虚拟机或其他脚本环境，可以在浏览器的支持下，获得更好的展现效果和更高的执行效率。今天，已经很少有哪个HTML页面的开发者还会对CSS和DHTML技术视而不见了。

　 　为了在HTML页面中实现音频、视频等更为复杂的多媒体应用，1996年的Netscape 2.0成功地引入了对QuickTime插件的支持，插件这种开发方式也迅速风靡了浏览器的世界。在Windows平台上，Microsoft将客户端应用集成的赌注押到了1990年代中期刚刚问世的COM和ActiveX身上。1996年，IE 3.0正式支持在HTML页面中插入ActiveX控件的功能，这为其他厂商扩展Web客户端的信息展现方式开辟了一条自由之路。1999年，Realplayer插件先后在Netscape和IE浏览器中取得了成功，与此同时，Microsoft自己的媒体播放插件Media Player也被预装到了各种Windows版本之中。同样值得纪念的还有Flash插件的横空出世：1990年代初期，Jonathan Gay在FutureWave公司开发了一种名为Future Splash Animator的二维矢量动画展示工具，1996年，Macromedia公司收购了FutureWave，并将Jonathan Gay的发明改名为我们熟悉的Flash。从此，Flash动画成了Web开发者表现自我、展示个性的最佳方式。

　 　除了编写HTML页面之外，客户端应用的开发者还可以利用一些成熟的技术将浏览器的功能添加到自己的应用程序中。从1992年开始，W3C就免费向开发者提供libwww开发库。借助libwww，我们可以自己编写Web浏览器和Web搜索工具，也可以分析、编辑或显示HTML页面。1999年，Microsoft在IE 5.0中引入的HTAs（HTML Applications）技术则允许我们直接将HTML页面转换为一个真正的应用程序。从1997年的IE 4.0开始，Microsoft为开发者提供了WebBrowser控件和其他相关的COM接口，允许程序员在自己的程序中直接嵌入浏览器窗口，或调用各种浏览器的功能，如分析或编辑HTML页面等。Windows 98及其后的Windows操作系统甚至还利用WSH（Windows Script Host）技术将原本只在浏览器中运行的JavaScript、VBScript变成了可以在WIN32环境下使用的通用脚本语言，这大概也可算作我们对Web客户端开发技术的一种巧妙利用吧。

　　服务端技术的成熟与发展

　 　与客户端技术从静态向动态的演进过程类似，Web服务端的开发技术也是由静态向动态逐渐发展、完善起来的。

　 　最早的Web服务器简单地响应浏览器发来的HTTP请求，并将存储在服务器上的HTML文件返回给浏览器。一种名为SSI（Server Side Includes）的技术可以让Web服务器在返回HTML文件前，更新HTML文件的某些内容，但其功能非常有限。第一种真正使服务器能根据运行时的具体情况，动态生成HTML页面的技术是大名鼎鼎的CGI（Common Gateway Interface）技术。1993年，CGI 1.0的标准草案由NCSA（National Center for Supercomputing Applications）提出，1995年，NCSA开始制定CGI 1.1标准，1997年，CGI 1.2也被纳入了议事日程。CGI技术允许服务端的应用程序根据客户端的请求，动态生成HTML页面，这使客户端和服务端的动态信息交换成为了可能。随着CGI技术的普及，聊天室、论坛、电子商务、信息查询、全文检索等各式各样的Web应用蓬勃兴起，人们终于可以享受到信息检索、信息交换、信息处理等更为便捷的信息服务了。

　 　早期的CGI程序大多是编译后的可执行程序，其编程语言可以是C、C++、Pascal等任何通用的程序设计语言。为了简化CGI程序的修改、编译和发布过程，人们开始探寻用脚本语言实现CGI应用的可行方式。在此方面，不能不提的是Larry Wall于1987年发明的Perl语言。Perl结合了C语言的高效以及sh、awk等脚本语言的便捷，似乎天生就适用于CGI程序的编写。1995年，第一个用Perl写成的CGI程序问世。很快，Perl在CGI编程领域的风头就盖过了它的前辈C语言。随后，Python等著名的脚本语言也陆续加入了CGI编程语言的行列。

　 　1994年，Rasmus Lerdorf发明了专用于Web服务端编程的PHP（Personal Home Page Tools）语言。与以往的CGI程序不同，PHP语言将HTML代码和PHP指令合成为完整的服务端动态页面，Web应用的开发者可以用一种更加简便、快捷的方式实现动态Web功能。1996年，Microsoft借鉴PHP的思想，在其Web服务器IIS 3.0中引入了ASP技术。ASP使用的脚本语言是我们熟悉的VBScript和JavaScript。借助Microsoft Visual Studio等开发工具在市场上的成功，ASP迅速成为了Windows系统下Web服务端的主流开发技术。当然，以Sun公司为首的Java阵营也不会示弱。1997年，Servlet技术问世，1998年，JSP技术诞生。Servlet和JSP的组合（还可以加上JavaBean技术）让Java开发者同时拥有了类似CGI程序的集中处理功能和类似PHP的HTML嵌入功能，此外，Java的运行时编译技术也大大提高了Servlet和JSP的执行效率--这也正是Servlet和JSP被后来的J2EE平台吸纳为核心技术的原因之一。

　　两种重要的企业开发平台

　 　Web服务端开发技术的完善使开发复杂的Web应用成为了可能。在此起彼伏的电子商务大潮中，为了适应企业级应用开发的各种复杂需求，为了给最终用户提供更可靠、更完善的信息服务，两个最重要的企业级开发平台--J2EE和.NET在2000年前后分别诞生于Java和Windows阵营，它们随即就在企业级Web开发领域展开了你死我活的拼争。平台之争让整个Web世界在最近的几年里不得安宁，但从某种意义上说，也正是这种针锋相对的竞争关系促使了Web开发技术以前所未有的速度提高和跃进。

　 　J2EE是纯粹基于Java的解决方案。1998年，Sun发布了EJB 1.0标准。EJB为企业级应用中必不可少的数据封装、事务处理、交易控制等功能提供了良好的技术基础。至此，J2EE平台的三大核心技术Servlet、JSP和EJB都已先后问世。1999年，Sun正式发布了J2EE的第一个版本。紧接着，遵循J2EE标准，为企业级应用提供支撑平台的各类应用服务软件争先恐后地涌现了出来。IBM的WebSphere、BEA的WebLogic都是这一领域里最为成功的商业软件平台。随着开源运动的兴起，JBoss等开源世界里的应用服务新秀也吸引了许多用户的注意力。到2003年时，Sun的J2EE版本已经升级到了1.4版，其中三个关键组件的版本也演进到了Servlet 2.4、JSP 2.0和EJB 2.1。至此，J2EE体系及相关的软件产品已经成为了Web服务端开发的一个强有力的支撑环境。

　 　和J2EE不同的是，Microsoft的.NET平台是一个强调多语言间交互的通用运行环境。尽管.NET的设计者试图以.NET平台作为绝大多数Windows应用的首选运行环境，但.NET首先吸引的却是Web开发者的目光。2001年，ECMA通过了Microsoft提交的C#语言和CLI标准，这两个技术标准构成了.NET平台的基石，它们也于2003年成为了ISO的国际标准。2002年，Microsoft正式发布.NET Framework和Visual Studio .NET开发环境。早在.NET发布之前，就已经有许多Windows平台的Web开发者迫不及待地利用Beta版本开发Web应用了。这大概是因为，.NET平台及相关的开发环境不但为Web服务端应用提供了一个支持多种语言的、通用的运行平台，而且还引入了ASP.NET这样一种全新的Web开发技术。ASP.NET超越了ASP的局限，可以使用VB.NET、C#等编译型语言，支持Web Form、.NET Server Control、ADO.NET等高级特性。客观地讲，.NET平台，尤其是.NET平台中的ASP.NET的确不失为Web开发技术在Windows平台上的一个集大成者。

　　XML语言及相关技术

　 　如果说HTML语言给Web世界赋予了无限生机的话，那么，XML语言的出现大概就可以算成是Web的一次新生了。按照Tim Berners-Lee的说法，Web是一个"信息空间"。HTML语言具有较强的表现力，但也存在结构过于灵活、语法不规范的弱点。当信息都以HTML语言的面貌出现时，Web这个信息空间是杂乱无章、没有秩序的。为了让Web世界里的所有信息都有章可循、有法可依，我们需要一种更为规范、更能够体现信息特点的语言。

　 　1996年，W3C在SGML语言的基础上，提出了XML（Extensible Markup Language）语言草案。1998年，W3C正式发布了XML 1.0标准。XML语言对信息的格式和表达方法做了最大程度的规范，应用软件可以按照统一的方式处理所有XML信息。这样一来，信息在整个Web世界里的共享和交换就有了技术上的保障。HTML语言关心的是信息的表现形式，而XML语言关心的是信息本身的格式和数据内容。从这个意义上说，XML语言不但可以将客户端的信息展现技术提高到一个新的层次，而且可以显著提高服务端的信息获取、生成、发布和共享能力。为了将XML信息转换为HTML等不同的信息展现形式，1999年，W3C制定出了XSLT标准。同一年，IE 5.0增加了对XML和XSLT的支持。

　 　现在，网站的开发者可以直接使用XML语言发布信息了。针对不同的应用领域，人们还制定了许多专门的XML规范。例如，2001年W3C发布的SVG（Scalable Vector Graphics）1.0标准就是一种用XML语言表达的、全新的二维矢量图形格式。开发者可以用SVG格式描述大多数已有的Flash动画。与Flash格式相比，符合XML标准的SVG格式显然更有利于信息交换和共享。

　 　Web本身就是一个最大的分布式应用系统。对于分布式开发而言，XML技术也大有用武之地。一个明显的事实是，如果能让分布式应用借助XML格式交换信息，那么，以往横亘在分布式架构上的信息交换难题也就迎刃而解了。1999年，W3C和相关的企业开始讨论设计基于XML的通信协议，2000年，W3C发布SOAP（Simple Object Access Protocol）协议的1.1版。人们把利用SOAP协议传递XML信息的分布式应用模型称为Web Service。2001年，W3C发布了WSDL（Web Services Description Language）协议的1.1版。SOAP协议和WSDL协议共同构成了Web Service的基础。随后，J2EE和.NET这两大企业级开发平台先后实现了Web Service，并将其视为平台的一项核心功能。

　 　Web Service对于Web开发者的重要意义在于，当我们需要在不同的服务端、不同的客户端乃至不同的应用类型、不同的计算设备之间传递信息的时候，以往的分布式开发技术或者因为适应性不强，或者因为扩展能力不足，都难以满足现代Web开发的需要，而Web Service正好填补了这一空白。

　　Web开发框架和应用模型

　 　2000年以后，随着Web应用的日益复杂，人们逐渐意识到，单纯依靠某种技术多半无法达到快速开发、快速验证和快速部署的最佳境界。研究者开始尝试着将已有的Web开发技术综合起来，形成完整的开发框架或应用模型，并以此来满足各种复杂的应用需求。

　 　Microsoft在客户端的技术集成方面走在了最前面。1998年时Microsoft推出的Windows 98就可以在桌面上集成Web页面，这实际上是将资源管理器和Web浏览器的功能有效地结合了起来。2000年后，Microsoft陆续推出了MSN Explorer和与之相关的MSN在线服务。这一应用模型将Web浏览、视频点播、邮件处理、网上游戏、在线聊天等许多种用户常用的Web功能集成在了一个统一的界面中。从信息利用的角度看，MSN试图让用户在一个最舒适的环境中获取足够的信息，这种努力的确值得人们称道。另一个与客户端技术集成相关的例子是搜索引擎Google在2003年展示给大家的Google工具栏功能。虽然Google工具栏有炒作和广告的嫌疑，但安装Google工具栏之后的IE浏览器将信息浏览和信息检索有机地结合了起来，这种小小的功能改进确实是对用户的体贴和帮助。

　 　在Web服务端，2000年以后出现了几种主要的技术融合方式。首先，越来越多的Web开发环境开始支持MVC（Model-View-Contorller）的设计模型，为开发者提供了全套的开发框架。实际上，J2EE和.NET平台本身就是这种开发框架的典型代表。其次，门户服务（Portal Server）和Web内容管理（Web Content Management）在最近几年里成为了应用集成的重点模型。这两种应用模型可以直接为开发者或最终用户提供构建Web应用的高级平台，可以让Web开发和信息发布工作大为简化。在商业软件领域，这一类应用的例子包括Microsoft的SharePoint、IBM的WebSphere Portal、FileNet的Web Content Manager等等。开源项目在Web开发框架和应用模型方面表现得非常积极，Struts、Jetspeed、jPortlet、Cocoon、Lenya、XOOPS等都是开源世界里与MVC开发框架、门户服务和Web内容管理相关的优秀解决方案。

　 　当然，技术集成绝不等于技术堆砌。一些Web站点和Web应用的开发者把XML语言、MVC框架等时髦技术拼凑起来，却不管它们是否能适应具体的应用环境，结果，他们的系统要么运行效率低下，要么功能残缺不全。反之，一个值得注意的事实是，像新浪、搜狐或网易这样的门户网站，在他们的信息发布页面（如新闻页面）里，尽管信息内容时刻都在刷新，但Web服务器上存放的始终都是静态的HTML页面。这种"落后技术"的优点是，在大量并发访问的情况下，门户网站的响应速度仍然很快。深入到技术层面，我们通常会惊讶地发现，这些网站使用的大多是自行研发的Web内容管理系统。当网站的内容编辑提交新的信息时，系统会自动将信息转换为HTML格式，发布到Web服务器集群的每一个结点上。在新浪网的一个角落里，我们可以找到"新浪网站发布系统"的研发历程：

　　V 1.0（1997）：基于文件的版本，实现新闻首页、正文和专题的发布。
　　V 1.1（1998/12）：采用数据库后台、实现跨服务器发布，自动化程度高。
　　V 2.0（1999/3）：创立模版和域的全新概念，奠定了该系列的基本设计思路。
　　V 2.1（1999/9）：增加周边模块，如搜索、自动采集。
　　V 3.0（2000/1）：优化传输方式，增加相关新闻和评论。
　　V 3C（2000/6）：V3.0的编译版，也是商业版的原型。
　　V 3.1（2000/7）：优化数据库结构，采用内存CACHE大幅提速，增加了集中监控功能。
　　V 3.1C（2000/8）：商业用测试版本。
　　V 3.2（正在制作中）：重点解决备份系统的自动化切换，在机制上实现永不宕机。

　　这一份有趣的历史记录再一次印证了我关于Web开发技术的基本观点：一种技术只要能为用户提供高水平的信息服务，它就是最好、最先进的技术。

　　 Web开发技术的未来

　　所有人都在关心Web的发展前景，所有人都想知道十年以后的Web会长成什么样子。要回答这些问题，没有谁比W3C更有权威了。W3C明确地告诉我们，Web的未来是语义化的Web（Semantic Web）。今天的Web可以自如地生成、传递和展现各式各样的信息，但它还只是一个信息的"容器"，很难揭示出信息本身的内容和特性。与此相对的是，未来的语义化Web是一种懂得信息内容的Web，是真正的"信息管理员"。

　　从技术角度看，XML语言统一了信息的表达方式，但这离揭示信息内容的目标还相距甚远。1998年，W3C和一些研究机构开始对元数据（Metadata）进行研究。元数据是描述数据的数据，可以揭示信息的内容特性。1999年，NetScape提出的RSS（Rich Site Summary）建议标准是用元数据技术描述新闻等信息内容的第一次尝试。1999年，W3C的研究小组提出了RDF（Resource Description Framework）标准草案。RDF在XML语法的基础上，规定了元数据的存储结构和相关的技术标准。使用RDF语言，我们可以用统一的、可交换的格式揭示出信息本身的各种特性。2001年，W3C又开始着手制定OWL（OWL Web Ontology Language）标准。OWL语言也是一种符合XML标准的语言，它比RDF又前进了一步，可以更加深入、细致地描述信息内容。在RDF和OWL语言的帮助下，我们能让Web上的信息内容变得更容易理解、更便于交换和共享。2003年，W3C成立了语义化Web Service研究小组（Semantic Web Services Interest Group），研究在Web Service中加入语义技术的相关问题。2004年2月，W3C宣布RDF和OWL标准正式成为W3C的建议方案，这标志着语义化Web的大厦已经破土动工。

　　随着语义化Web的诞生和发展，Web开发技术也必将经历更为重大的变革。可以预见的是，在未来的几年里，还会有许多新的开发技术或开发平台出现。从静态技术到动态技术，从开发平台到应用模型，从传统Web到语义化Web……为了让更多的人获得更有价值的信息服务，Web开发者们也许还会经历一次又一次的技术浪潮，还会面临更为严峻的技术挑战，但这和信息共享的最高目标相比，又算得了什么呢？
所谓的流星闪过，留下一堆影子，其实就是一系列同样的星星次第爆发而已。

笔记本装的系统是Win 7，很烦人。
一段时间没用笔记本上面的Flash CS4和Flash Builder 4，今天上的时候发现提示说Licensing for this product has expired，然后两个都要求输入序列号了，而且FB4输入啥序列号都不行，怀疑是我的版本Out了一时没找到序列号，要么就下载个最新的，要么就下载回FB3，于是重新下载FB3，但是要等很久，于是趁此机会重新找找看能否找到FB4的序列号解决这个问题。

回顾之前解决CS4这个问题的方法是：

要先往 C:\WINDOWS\system32\drivers\etc\Hosts 中最后面添加
127.0.0.1 localhost
127.0.0.1 activate.adobe.com
127.0.0.1 practivate.adobe.com
127.0.0.1 ereg.adobe.com
127.0.0.1 activate.wip3.adobe.com
127.0.0.1 wip3.adobe.com
127.0.0.1 3dns-3.adobe.com
127.0.0.1 3dns-2.adobe.com
127.0.0.1 adobe-dns.adobe.com
127.0.0.1 adobe-dns-2.adobe.com
127.0.0.1 adobe-dns-3.adobe.com
127.0.0.1 ereg.wip3.adobe.com
127.0.0.1 activate-sea.adobe.com
127.0.0.1 wwis-dubc1-vip60.adobe.com
127.0.0.1 activate-sjc0.adobe.com
::1 localhost

然后运行软件，会提示输入序列号，这时就输入这些：
1325-1110-3786-4687-3270-8979

问题又来了，我用的是自己的账户登录，没有管理员权限，Win7死活不给我修改系统文件，于是只得继续百度：
http://www.ylmf.net/read.php?tid=1374858&page=e
好长，长到我都快没耐心了~~最后总算坚持搞定了，于是可以改hosts，其实我改它不止是因为现在要用，估计以后会经常要改，它是用来设置主机域名映射的。

然后CS4没问题了，刚好FB3下载好了，就安装，总算搞定~

《Flex 3 权威指南》这本书确实不错，我要利用晚上下班的时间搞定它。
（不定期更新）
1.负责Web网游客户端开发
2.针对开发功能进行分析、设计和实现
3.针对公司的需求，制作Flash AS3演示
1.使用Action script两年以上 ，精通AS3编程及Flex ，熟悉OOP
2.一年以上团队管理经验，有主持大型Flash项目和多人合作项目开发经验 。
3.精通Action script与Java 后台做Socket网络通讯编程、熟悉XML、Ajax、JavaScript及数据库等技术
4.熟知游戏或软件开发流程，熟知游戏常规算法。
5.掌握多种开源框架，善于使用设计模式开发，掌握FLEX/FLASH代码和素材安全机制以及性能优化技术。
6.程序编码规范，文档编写能力良好。
7.具备一定项目管理知识，能合理分配任务，能协调并指导其他团队成员完成项目开发。
8.热爱游戏行业，善于沟通和钻研技术，工作认真、负责、有激情、能承担较大工作压力
良好的数学、物理、计算机及操作系统知识，熟悉各种运算法则和公式；
 有跨平台的良好开发能力，Java（J2ME/J2SE）

具体Flash技术：
事件机制：对AS3的时间冒泡机制了如指掌并会依照实际情况进行优化
安全机制：有能避免安全砂箱出错的处理办法
Preloader机制：深入了解Proloader机制，并且优化过Proloader的加载顺序
模块化编译机制：知道原理并进行过优化
Flex的Profile使用：尝试使用他来优化我的程序
垃圾回收：清楚理解垃圾回收以及内存泄露的关系，有针对性地进行优化
采用Flash Builder, Flex Builder, FDT, Flash Develop开发
IDE技巧：编写过jsfl脚本完成重复的工作
外部资源(MovieClip, Image, Font)使用：针对外部资源进行过优化
嵌入字体：用IDE或者代码方式嵌入字体，并解决过相应BUG
有自己的开发类库
用AIR开发过项目
能通过UML图表达自己的思想以及程序逻辑
知道MVC的优劣和适用范围
使用过UI框架（ASwing，Flex）、辅助类库（As3Corelib,Swfaddress,Tweenlite)、常见MVC框架(PureMVC,Cairngorm,RobotsLegs)、3D类库(Pv3d,Away3d)
用过几种IOC开源框架

Flash动画设计与开发：
岗位职责： 
1.能够独立构建全Flash框架下的交互站点 ; 
2.为站点创作合适而充满乐趣的动效表现 ; 
3.项目前期/需要对框架的合理性提出明确想法和可行性计划 ; 
4.项目中期/需要从动效及AS部分对交互体验进行实施和效果负责 ; 
5.项目后期/需要了解及测试体验成果并将成果进行知识转化 ; 
6.我们需要你积极的与互动研究小组的其它动效或AS专家、设计师以及后台功能程序师进行多方面沟通 ; 
7.对思路与想法通过故事脚本或流程图的方式表达你的意图 ; 
8.知识分享与继承，包括了培训和常用模块建设. 
任职要求：
1.2年以上Flash应用经验 ; 
2.动画特效经验丰富,具备音乐编辑能力 ; 
3.熟悉Action Script,了解面向对象编程，精通FLASH软件，熟悉网站技术 ; 
4.愿意深入了解用户可用性，对交互设计有一定研究 ; 
5.有独特的视角,富有创意表现欲; 
6.良好的团队沟通和协作能力 ; 
7.具备严谨的开发规范和书面文档能力; 
8.具备职业道德和职业恒心者优先

一个Flash项目团队需要的人员：
工作职责：承接并如期交付我司交予的项目，保证项目质量。
要求：
1、有较成熟的flash动画项目开发队伍（4人以上），
2、熟悉Adobe Flash 各版本的操作；团队中至少两人精通Action Script，能制作flash游戏及互动动画。
3、团队中至少一人有美术功底，有较强的手绘能力，能设计卡通人物造型，绘制卡通场景；
4、团队中至少一人熟练应用photoshop, AI等图像处理软件；
5、工作认真负责，有时间观念及团队精神。 
1、应征团队请列明主要项目经验及提交3个以上项目成品（2个互动游戏）
2、请列明队伍人数及分工情况。 .


AS3.0中的异步异常处理捕捉 http://www.caoyusky.com/blog/as3-try-catch/
AS3 中URLLoader和Loader的区别 http://www.jb51.net/flash/actionscript/18319.html
玩转Flash AS 3D  http://space.flash8.net/bbs/viewthread.php?tid=323970&highlight
asp.net上传文件权限问题 http://www.iecn.net/read-html-tid-29087.html
TMD,加班中，下被子绝对不当程序员，文件上传权限问题 http://study.qqcf.com/web/720/261271.htm
一个在服务器上模拟客户端上传文件的问题 http://topic.csdn.net/t/20060506/03/4732107.html
FLASH AS3 urlloader调用ASP.NET,2032流错误 http://zhidao.baidu.com/question/70037072.html
FLASH asp.net后台通讯 IOERROR2032的问题,完美解决!http://hi.baidu.com/kidcdf/blog/item/623114d15a0132d5562c84c0.html 
梦境家园flash 3D虚拟社区游戏 http://tieba.baidu.com/f?kz=614183511
Flash AS 3D贴图教程[1]  http://hgfghw1.javaeye.com/blog/633027
as3和后台数据交互(转) http://cid-d37fb67ef2993635.spaces.live.com/blog/cns!D37FB67EF2993635!157.entry
asp.net上传文件 http://luckyjaky.javaeye.com/blog/350697

哼哼哈嘿。
有些歌能够让人很是亢奋，提起精神工作。

出埃及进行曲
蝶舞天涯
男儿当自强

谁是大英雄

再推荐一些好听的歌：
偏爱
擦肩而过——李圣杰
花样年华
南山忆
庐州月
平凡的浪漫 一、 分享第一条经验：“学历代表过去、能力代表现在、学习力代表未来。”
      其实这是一个来自国外教育领域的一个研究结果。相信工作过几年、十几年的朋友对这个道理有些体会吧。
    但我相信这一点也很重要：“重要的道理明白太晚将抱憾终生！”所以放在每一条，让刚刚毕业的朋友们早点看到哈！
二、   一定要确定自己的发展方向，并为此目的制定可行的计划。
    不要说什么，“我刚毕业，还不知道将来可能做什么？”，“跟着感觉走，先做做看”。因为，这样的观点会通过你的潜意识去暗示你的行为无所事事、碌碌无为。
    一直做技术，将来成为专家级人物？向管理方向走，成为职业经理人？先熟悉行业和领域，将来自立门户？还是先在行业里面混混，过几年转行做点别的？这很重要，它将决定你近几年、十年内“做什么事情才是在做正确的事情！”。
三、
     软件开发团队中，技术不是万能的，但没有技术是万万不能的！
    在技术型团队中，技术与人品同等重要，当然长相也比较重要哈，尤其在MM比较多的团队中。在软件项目团队中，技术水平是受人重视和尊重的重要砝码。无论你是做管理、系统分析、设计、编码，还是产品管理、测试、文档、实施、维护，多少你都要有技术基础。
    算我孤陋寡闻，我还真没有亲眼看到过一个外行带领一个软件开发团队成功地完成过软件开发项目，哪怕就一个，也没有看到。倒是曾经看到过一个“高学历的牛人”(非技术型)带一堆人做完过一个项目，项目交付的第二天，项目组成员扔下一句“再也受不了啦！”四分五裂、各奔东西。那个项目的“成功度”大家可想而知了。四、   
详细制定自己软件开发专业知识学习计划，并注意及时修正和调整(软件开发技术变化实在太快)。
    请牢记：“如果一个软件开发人员在1、2年内都没有更新过自己的知识，那么，其实他已经不再属于这个行业了。”
     不要告诉自己没有时间。来自时间管理领域的著名的“三八原则”告诫我们：另外的那8小时如何使用将决定你的人生成败！本人自毕业以来，平均每天实际学习时间超过2小时。
五、
    书籍是人类进步的阶梯，对软件开发人员尤其如此。
   书籍是学习知识的最有效途径，不要过多地指望在工作中能遇到“世外高人”，并不厌其烦地教你。
    对于花钱买书，我个人经验是：千万别买国内那帮人出的书！我买的那些家伙出的书，100%全部后悔了，无一本例外。更气愤的是，这些书在二手市场的地摊上都很难卖掉。“拥有书籍并不表示拥有知识；拥有知识并不表示拥有技能；拥有技能并不表示拥有文化；拥有文化并不表示拥有智慧。”只有将书本变成的自己智慧，才算是真正拥有了它。
六
      不要仅局限于对某项技术的表面使用上，哪怕你只是偶尔用一、二次。“对任何事物不究就里”是任何行业的工程师所不应该具备的素质。
    开发Windows应用程序，看看Windows程序的设计、加载、执行原理，分析一下PE文件格式，试试用SDK开发从头开发一个Windows应用程序；用VC＋＋、 Delphi、Java、.Net开发应用程序，花时间去研究一下MFC、VCL、J2EE、.Net它们框架设计或者源码；除了会用J2EE、 JBoss、Spring、Hibernate等等优秀的开源产品或者框架，抽空看看大师们是如何抽象、分析、设计和实现那些类似问题的通用解决方案的。
    试着这样做做，你以后的工作将会少遇到一些让你不明就里、一头雾水的问题，因为，很多东西你“知其然且知其所以然”！
七
      在一种语言上编程，但别为其束缚了思想。
    “代码大全”中说：“深入一门语言编程，不要浮于表面”。深入一门语言开发还远远不足，任何编程语言的存在都有其自身的理由，所以也没有哪门语言是“包治百病”的“灵丹妙药”。编程语言对开发人员解决具体问题的思路和方式的影响与束缚的例子俯拾皆是。
    我的经验是：用面对对象工具开发某些关键模块时，为什么不可以借鉴C、C51、汇编的模块化封装方式？用传统的桌面开发工具(目前主要有VC++、Delphi)进行系统体统结构设计时，为什么不可以参考来自Java社区的IoC、AOP设计思想，甚至借鉴像Spring、Hibernate、JBoss等等优秀的开源框架？在进行类似于实时通信、数据采集等功能的设计、实现时，为什么不可以引用来自实时系统、嵌入式系统的优秀的体系框架与模式？为什么一切都必须以个人、团队在当然开发语言上的传统或者经验来解决问题？？？“他山之石、可以攻玉”。
    八
    众所周知，对软件开发人员而言，有、无经验的一个显著区别是：无经验者完成任何任务时都从头开始，而有经验者往往通过重组自己的可复用模块、类库来解决问题（其实这个结论不应该被局限在软件开发领域、可以延伸到很多方面）。这并不是说，所有可复用的东西都必须自己实现，别人成熟的通过测试的成果也可以收集、整理、集成到自己的知识库中。但是，最好还是自己实现，这样没有知识产权、版权等问题，关键是自己实现后能真正掌握这个知识点，拥有这个技能。
    养成总结与反思的习惯，并有意识地提炼日常工作成果，形成自己的个人源码库、解决某类问题的通用系统体系结构、甚至进化为框架。  
九
    工程师的内涵是：以工程师的眼光观察、分析事物和世界。
    一个合格的软件工程师，是真正理解了软件产品的本质及软件产品研发的思想精髓的人（个人观点、欢迎探讨）。
掌握软件开发语言、应用语言工具解决工作中的具体问题、完成目标任务是软件工程师的主要工作，但从软件工程师这个角度来看，这只是外在的东西，并非重要的、本质的工作。学习、掌握软件产品开发理论知识、软件开发方法论，并在实践中理解、应用软件产品的分析、设计、实现思想来解决具体的软件产品研发问题，才是真正的软件工程师的工作。站在成熟理论与可靠方法论的高度思考、分析、解决问题，并在具体实践中验证和修正这些思想与方式，最终形成自己的理论体系和实用方法论。
十、
    书到用时方恨少，不要将自己的知识面仅仅局限于技术方面。
    尽量参加开源项目的开发、或者与朋友共同研制一些自己的产品，千万不要因为没有钱赚而不做。网络早已不再只是“虚拟世界”，网上有很多的开源项目、合作开发项目、外包项目，这都是涉猎工作以外的知识的绝好机会，并且能够结识更广的人缘。不要因为工作是做ERP，就不去学习和了解嵌入式、实时、通信、网络等方面的技术，反过来也是一样。如果当别人拿着合同找你合作，你却这也不会，那也不熟时，你将后悔莫及。