剖析短迭代
敏捷教练Dave Nicolette提出:我们应该如何设定迭代长度?是要根据发布周期的时间么?使用短迭代又有哪些好处?
作者 Werner Schuster译者 马家宽 发布于 2008年1月2日 下午11时31分
07年12月22日,Ryan Davis宣布了ruby_parser的发布。ruby_parser是一个纯Ruby实现的Ruby源代码语法分析器。这个语法分析器的编写过程中使用了Ruby yACC (RACC),一个包含在Ruby标准库中的语法分析程序生成器。
ruby_parser(RP)是一个纯Ruby实现的Ruby语法分析器(借助了racc——它在缺省情况下使用C语言的扩展). RP的输出与语法分析树的输出相同:用ruby中的数组以及基本类型来表达的s-expression。
这个库很容易使用:
RubyParser.new.parse "1+1"上面的语句会返回
s(:call, s(:lit, 1), :+, s(:array, s(:lit, 1)))
Ruby世界中一直缺少纯Ruby实现的Ruby语法分析器。“纯Ruby”意味着该语法分析器:
上面这些属性对于保证代码能够通用于各种Ruby运行时至关重要。如果一个语法分析器的实现使用了基于C语言的本地扩展,那么它就无法在不支持这些扩展的Ruby版本上运行,例如JRuby、XRuby或者.NET上的IronRuby和Ruby.NET。即便这些Ruby版本支持了本地扩展(JRuby正在考虑这一方案),它还会造成部署问题,因为这要求扩展所使用的库或DLL必须被移植到任何可能的OS/CPU组合之上(否则某些用户将无法使用该语法分析器)。Ryan Davis的另一个项目RubyInline,通过自动编译那些内联的C代码一定程度上的改善了这一状况。但要RubyInline要求目标系统需要包含一个C编译器——这一条件并不是总能满足,尤其是对于Windows系统来说。
因为可以使用类似语法分析树(ParseTree)的通用方法来对Ruby代码进行分析并获得抽象语法树(Abstract Syntax Tree),所以在Ruby历史上的一定时期内,纯Ruby语法分析器的缺失被忽视了。然而自从各种Ruby运行时雨后春笋一样的出现以来,Ruby语法分析器被反复实现了很多次——两次使用Java(JRuby和XRuby),一次使用C#(Ruby.NET所编写的语法分析器也被IronRuby所使用)。所有这些分析器提供了不同的抽象语法树以及获取它们的方式。
这造成了Ruby源代码工具的一些问题。例如,目前Aptana/RDT(基于Eclipse)中包含的Ruby重构工具就被绑定到Java和JRuby的抽象语法树上,这使其无法被用在其他的Ruby实现上。类似的,针对其他基于Java的Ruby IDE的工具也正在被开发,这造成了大量代码分析管理工具被限制在Java和JRuby上。除此之外,这些工具的逻辑使用Java而不是Ruby编写,这对Ruby开发人员来说不够友好。
纯Ruby语法分析器提供了改变这种情况的机会——Ruby IDE(或者其他工具)可以获得Ruby的抽象语法树,同时避免被绑定到特定的语法分析器实现上。例如,一个基于Java的IDE可以在开启JRuby的同时使用ruby_parser进行语法分析。为了达到这一目的,目前版本的ruby_parser需要在输出中增加源代码位置的信息,例如,每个抽象语法树的节点需要了解其在源代码中开始和结束位置的偏移。这对源代码工具来说至关重要,因为虽然纯粹的语法树结构信息也很有用,但是如果工具无法了解节点在源码中的位置,它就不能对源码进行修改。
ruby_parser的另一个使用者是Rubinius。Rubinius是一个绝大部分代码使用Ruby编写的Ruby虚拟机,不过它使用的是Matz的Ruby参考实现(MRI)中所包含的语法分析器,而通过使用ruby_parser可以使Rubinius移除这一部分的C语言代码。此处还存在一个问题:“如果语法分析器是Ruby编写的需要Ruby虚拟机来运行,那么依赖语法分析器的Ruby虚拟器要如何工作?”,这是一个类似“鸡大生蛋,蛋破生鸡”问题。为了避免这个问题,在Rubinius的虚拟器中,ruby_parser的Ruby源代码会被编译为Rubinius字节码。当Rubinius启动时,它通过读取ruby_parser的字节码文件——这些文件不需要进行语法分析——来运行一个Ruby语法分析器。
对于ruby_parser来说,还有许多工作要做。发布说明中列出了其中的一些问题:
查看英文原文:ruby_parser 1.0: a Ruby Parser written in Ruby
- 已知问题: 速度还很不尽如人意。运行5500个测试用例目前需要21分钟。
- 已知问题: 代码有些难看。不过这不全是我的错,我会尽快改进这一状况。
- 已知问题:目前还不支持newline节点。
- 已知问题:功能还可以更加强大。
- 已知问题:ParseTree中的dasgn_curr声明可能会乱序。
- 待做事情:加入注释节点。
本文主要讲述了如何用JBoss Portlet Container 和JBoss Portlet Bridge创建新项目,怎样配置一个JSF应用去使用JBoss Portlet Bridge,以及JBoss Portlet Bridge所具备的功能。
在这篇文章里,Bryon Jacob和Chris Berry将和我们继续探讨AtomServer,它是基于Apache Abdera的完整Atom存储实现。作者还创建了几个Atompub规范扩展,其中包括自动标记、批处理和Feeds聚合。
InfoQ中文站的电子杂志《架构师》试刊第二期出版了!相比于上期,我们在内容的选择安排和版式上都根据读者的意见重新做了修正。“细节决定成败”,我们希望基于InfoQ中文站的专业内容,《架构师》能逐渐成为大家喜欢的电子刊物!
在本文中,Steven Haines探讨了Web应用性能调优问题。该领域过去更像是一门艺术而不是一门科学。他提出了一种称为基于等待调优的方法,使整个调优过程更加可度量,也因此更具科学性。
通常来说,改变技术路线时最艰难的部分是辨别语言语法之间的不同。这篇文章就为Java开发者提供了一份如何转向Flex基础语言ActionScript的指南。
本视频主要以财帮子为例,介绍了如何创建一个PV为百万级的Rails应用。其中包括:Rails应用的服务器架构、Rails Cache的优化、负载均衡的处理、Web服务器的调试、分布式解决方案、Open API的设计等等。
InfoQ首席架构师Alexandru Popescu在采访中谈论了InfoQ架构、Webwork与DWR、Hibernate与JCR、Hibernate可扩展性、最新的InfoQ视频流系统和InfoQ的未来规划。
1 条回复
回复