一些 Flex 2 实例
原文地址: http://shigeru-nakagaki.com/index.cfm?Content=Flex2Samples
打开实例, 点击右键菜单第一项查看源码.
原文地址: http://shigeru-nakagaki.com/index.cfm?Content=Flex2Samples
打开实例, 点击右键菜单第一项查看源码.
作者:Jon Rose 译者:张龙
原文地址:http://www.infoq.com/cn/news/2008/04/top-10-flex-mistakes
英文原文:Top 10 Mistakes when building Flex Application
在这篇新闻中,Adobe的James Ward与InfoQ.com一起为你带来了Flex的另一种10大(Flex最新的10大)。Flex是一个开源的应用开发框架,用来构建运行在web(使用 Flash Player)或者桌面上(使用Adobe AIR)的富Internet应用。总之,Flex是一个强大易用的框架,但是今天让我们瞧瞧构建Flex应用时经常犯的错误。
对于Flex新手,请阅读InfoQ最近的Adobe Flex Basics以对该框架有一个快速的了解。下面是易犯的错误列表:
1. 使用RIA框架去构建Web1.0应用(新技术换汤不换药)。
从Web 1.0到RIA的过渡中最大的挑战之一来自思考方式的转变。Flex给予开发者一个高级的组件库,使其可以完成很多以前不可能完成的任务。但是很多时候,Flex的这种能力被忽略了,它仅仅被用来实现更加传统的Web 1.0应用。
构建Web 2.0应用不仅仅意味着页面的局部刷新和旋转的圆角图标。例如,Flex开发者应使用矢量图向用户提供数据的可视化表示,以及对于富应用流的高级控制。最近Stephan Janssen与InfoQ.com一起讨论了该议题:
作为一个Java开发者,对于面向对象的ActionScript和UI标记语言的学习简直就是小菜一碟。但是对于(Java)开发者来说真正的挑战在于我们不是设计师,并且这两个技术对于RIA来说是必不可少的。
2. 破坏标准的浏览器体验
尽管Flex确实提供了一个优秀的平台以改善用户体验,但是保持用户习惯,如后退按钮、书签和自动完成也是相当重要的。
Flex 3包含了新的深层链接特性以支持后退按钮和书签。你可以访问labs.adobe.com来了解更多。那有很多组件能够实现自动完成。你可以使用来自于Adobe Exchange的AutoComplete Input组件。
3. 使用过多的容器导致应用变慢
Flash Player使用了一个按层次显示的对象图,这一点与HTML的文档对象模型(DOM)很相似。容器嵌套的层次越深,渲染所花费的时间就越长。Adobe的Flex开发者中心有一篇文章讨论了关于Flex性能的最佳实践,包括了容器的使用细节:
Flex最大的性能风险来自于对容器的滥用。嵌套太多的容器会影响应用的性能。这是Flex开发者面临的最严重的性能风险——不过还好,它完全能被避免。
4. 使用XML而不是其他更优化的协议导致应用变慢
Flex向开发者提供了多种选择以在Flex客户端和服务器之间进行数据传输,包括AMF3、XML、SOAP及直接的HTTP请求。Ward在他的人口普查应用中阐述了这些技术的使用及性能。
对于后端使用Java的新项目来说,应该考虑一下BlazeDS。BlazeDS是Adobe最近的一个开源数据服务产品,它使用了AMF3协议。AMF是一个二进制传输协议,很容易与Java集成,其性能要优于XML。对于所有主要的后端技术都有相应的AMF开源实现。
如果你不选择BlazeDS,那么你还可以选择Hessian。Hessian对二进制的web services协议提供了ActionScript/Flex支持。
5. 试图雇佣Flex开发者
现在很难找到有经验的Flex开发者。Flex现在正处在上世纪90年代Java所处的位置。Flex开发者已经供不应求了。这就造成了难以寻觅 到有经验的Flex开发者的后果。然而,这给Java开发者创造了一个很好的机会以扩充技能,并且从事一种新兴且有趣的技术。很多寻找Flex开发者的公 司直接对Java或者其他web开发者进行几周的Flex培训,并且大获成功。对于熟悉Web和GUI编程的开发者来说,学习Flex语言和APIs易如 反掌。
6. 特效的过度使用
开发者可以很容易地通过Flash增加特效。但是要确保特效有意义并且与上下文是匹配的。否则他们只会让用户反感。特效的时间选择也很重要。交互设计器可以帮助我们决定何时应使用特效,何时不应该使用。交互设计器还能为我们推荐最佳的特效类型、间隔和最简化的功能。
关于特效的使用在laair.org上有一篇好文:
大多数的特效简直太长了。它们不但长,而且还慢,甚至让人反感。关掉它。如果我遇到这种事情的话,我就会转身离去,因为我实在讨厌这种等待。
千万不要误会我,我并不是反对特效。我只是反对为了目的而做的太长或者太过分的特效。每个特效都可以依照其目的进行分解。找到你要特效的目的,然后再使用它。
7. 没有搭建企业生态系统
就像其他的软件项目一样,为于你的Flex应用建立企业生态系统是非常重要的。
测试驱动开发(TDD)在当前是大多数企业项目的首选方案。对于Flex来说,FlexUnit框架可用来编写单元测试。在Adobe的开发者网络上,Neil Webb讨论了面向Flex开发者的TDD及FlexUnit的使用。此外,Flexcover可用来度量代码覆盖率。
当多个开发者协同工作时,持续集成(Continuous Integration)被证明是良好的实践。与Java应用类似,也有相应的Ant和Maven插件对你的Flex应用进行持续集成。
8. 没有使用整个框架
在Adobe Flex中有大量可选的特性,你应该考虑在你的应用中使用它们。例如,运行时共享库(Runtime Shared Libraries,即RSL)可用来减少应用的大小。
你可以将共享资源集成到单独的文件中,这样就可以在客户端单独下载和缓存了,通过这种手段可以减少应用产生 的SWF文件的大小。很多Flex应用可以在运行时加载这些共享资源,而每个客户端只需下载一次即可。这些共享资源叫做运行时共享库(Runtime Shared Libraries)。
框架的另一个特性是内建的辅助功能。你可以通过Adobe在线文档了解更多的关于Flex的辅助功能的信息。除了内建的辅助功能外,框架还提供了对于本地化的内在支持。请访问Adobe新手上路来了解最新的Flex3框架特性。
9. 使用复杂的渲染器降低了DateGrid的速度
针对DataGrid开箱即用的itemRenderer已经有过很好的优化了。误解#3讨论了嵌套过深的容器的性能问题。在Flex中有一个地 方很容易造成容器的深层次嵌套,那就是DataGrid的item渲染器。由DataGrid所渲染的item渲染器数量等于可见的行数乘以可见的列数。 定制的DataGrid和List item渲染器应该经过非常好的优化才行。当需要在item渲染器中使用复杂的布局逻辑时,最好使用UIComponent(或者其他底层类)并且手工完 成该单元格内容的定位。
10. 没有准备离线应用。
RIAs的传统模型在于浏览器。然而像Adobe AIR和Google Gears这 样的技术使得应用可以离线运行。如果用户需要可以离线对应用时而你尚未准备好的话,那将你的应用改为支持离线特性将变得异常困难。典型地,在web应用 中,业务逻辑存在于服务器端。在离线RIAs中,业务逻辑必须转到客户端。为了使应用既支持离线,也支持在线,那就很有必要提前决定某些业务逻辑的位置。
原文地址: http://www.jasonbartholme.com/101-adobe-air-resources-to-add-to-your-toolbelt-of-awesomeness/
The Adobe Integrated Runtime or AIR is a runtime environment for developing rich Internet applications. These applications can be deployed as a desktop applications. AIR applications can operate offline and can take advantage of additional functionality when connected to the Internet.
原文地址: http://tech.nitoyon.com/blog/2008/01/as3query_alpha.html
as3Query 是 John Resig 的 JavaScript 库 jQuery 1.2.1 的 ActionScript3.0 版.
该版基于 MIT 和 GPL 许可协议(和 jQuery 一样).
目前还木有文档. 但可以参考 jQuery Documentation.
2008年6月12日,北京
北京亚运村北京国际会议中心

和Google的工程师、业界同行们交流利用Google的各种开发工具去构建您的社区应用、移动应用、地图应用,或者基于 AJAX/JavaScript的网络应用。
原文地址: http://kb.discuz.net/index.php?title=MySQL%E4%BC%98%E5%8C%96%E5%AE%9E%E4%BE%8B
在Apache, PHP, MySQL的体系架构中,MySQL对于性能的影响最大,也是关键的核心部分。对于Discuz!论坛程序也是如此,MySQL的设置是否合理优化,直接 影响到论坛的速度和承载量!同时,MySQL也是优化难度最大的一个部分,不但需要理解一些MySQL专业知识,同时还需要长时间的观察统计并且根据经验 进行判断,然后设置合理的参数。
下面我们了解一下MySQL优化的一些基础,MySQL的优化我分为两个部分,一是服务器物理硬件的优化;二是MySQL自身(my.cnf)的优化。
(1) 服务器硬件对MySQL性能的影响
a) 磁盘寻道能力(磁盘I/O),以目前高转速SCSI硬盘(7200转/秒)为例,这种硬盘理论上每秒寻道7200次,这是物理特性决定的,没有办法改变。 MySQL每秒钟都在进行大量、复杂的查询操作,对磁盘的读写量可想而知。所以,通常认为磁盘I/O是制约MySQL性能的最大因素之一,对于日均访问量 在100万PV以上的Discuz!论坛,由于磁盘I/O的制约,MySQL的性能会非常低下!解决这一制约因素可以考虑以下几种解决方案:
使用RAID-0+1磁盘阵列,注意不要尝试使用RAID-5,MySQL在RAID-5磁盘阵列上的效率不会像你期待的那样快; 抛弃传统的硬盘,使用速度更快的闪存式存储设备。经过Discuz!公司技术工程的测试,使用闪存式存储设备可比传统硬盘速度高出6-10倍左右。
b) CPU 对于MySQL应用,推荐使用S.M.P.架构的多路对称CPU,例如:可以使用两颗Intel Xeon 3.6GHz的CPU。
c) 物理内存对于一台使用MySQL的Database Server来说,服务器内存建议不要小于2GB,推荐使用4GB以上的物理内存。
(2) MySQL自身因素当解决了上述服务器硬件制约因素后,让我们看看MySQL自身的优化是如何操作的。对MySQL自身的优化主要是对其配置文件my.cnf中的各项参数进行优化调整。下面我们介绍一些对性能影响较大的参数。
由于my.cnf文件的优化设置是与服务器硬件配置息息相关的,因而我们指定一个假想的服务器硬件环境:
CPU: 2颗Intel Xeon 2.4GHz
内存: 4GB DDR
硬盘: SCSI 73GB
下面,我们根据以上硬件配置结合一份已经优化好的my.cnf进行说明:
以下只列出my.cnf文件中[mysqld]段落中的内容,其他段落内容对MySQL运行性能影响甚微,因而姑且忽略。
禁止MySQL对外部连接进行DNS解析,使用这一选项可以消除MySQL进行DNS解析的时间。但需要注意,如果开启该选项,则所有远程主机连接授权都要使用IP地址方式,否则MySQL将无法正常处理连接请求!
指定MySQL可能的连接数量。当MySQL主线程在很短的时间内接收到非常多的连接请求,该参数生效,主线程花费很短的时间检查连接并且启动一个新线程。
back_log参数的值指出在MySQL暂时停止响应新请求之前的短时间内多少个请求可以被存在堆栈中。 如果系统在一个短时间内有很多连接,则需要增大该参数的值,该参数值指定到来的TCP/IP连接的侦听队列的大小。不同的操作系统在这个队列大小上有它自 己的限制。
试图设定back_log高于你的操作系统的限制将是无效的。默认值为50。对于Linux系统推荐设置为小于512的整数。
查询排序时所能使用的缓冲区大小。注意:该参数对应的分配内存是每连接独占!如果有100个连接,那么实际分配的总共排序缓冲区大小为100 × 6 = 600MB。所以,对于内存在4GB左右的服务器推荐设置为6-8M。
读查询操作所能使用的缓冲区大小。和sort_buffer_size一样,该参数对应的分配内存也是每连接独享!
联合查询操作所能使用的缓冲区大小,和sort_buffer_size一样,该参数对应的分配内存也是每连接独享!
指定MySQL查询缓冲区的大小。可以通过在MySQL控制台执行以下命令观察:
如果Qcache_hits的值非常大,则表明查询缓冲使用非常频繁,如果该值较小反而会影响效率,那么可以考虑不用查询缓冲;Qcache_free_blocks,如果该值非常大,则表明缓冲区中碎片很多。
指定MySQL允许的最大连接进程数。如果在访问论坛时经常出现Too Many Connections的错误提 示,则需要增大该参数值。
指定一个请求的最大连接时间,对于4GB左右内存的服务器可以设置为5-10。
该参数取值为服务器逻辑CPU数量×2,在本例中,服务器有2颗物理CPU,而每颗物理CPU又支持H.T超线程,所以实际取值为4 × 2 = 8
开启该选项可以彻底关闭MySQL的TCP/IP连接方式,如果WEB服务器是以远程连接的方式访问MySQL数据库服务器则不要开启该选项!否则将无法正常连接!