剖析短迭代
敏捷教练Dave Nicolette提出:我们应该如何设定迭代长度?是要根据发布周期的时间么?使用短迭代又有哪些好处?
作者 Rob Thornton译者 郭晓刚 发布于 2007年11月8日 下午6时51分
最近关于ECMAScript之未来的讨论颇为活跃。Brendan Eich引发了关于ECMAScript 4的一阵狂风暴雨的讨论。它是否正走在正确的道路上呢?
ECMAScript 4是JavaScript和JScript这两个实现所依标准的下一代版本。随着ECMAScript 4概览的发表,JavaScript的创造者Eich将我们要如何让JavaScript向ECMAScript 4靠拢的问题提到了大家面前。虽然ECMAScript 4的工作一直在进展中,仍然有很多人对这个规范不满,认为它走得太快、太远,却又没有解决语言现今面临的一些严重问题。
在发布规范概览之后,Eich狠批了Microsoft缺席讨论。Microsoft的JScript团队被激起了回应,他们整理了一份列表,列出了JScript与规范或一般公认的做法之间的所有差异。Microsoft认为ECMAScript 4的步子迈得太大,而IE的平台架构师Chris Wilson也详列了他个人的想法。
Douglas Crockford这位在Yahoo!工作的广受尊敬的JavaScript专家也同样有所保留:
很多人都觉得JavaScript烂,并且希望新语言能少烂一点。我的担心是它可能更烂。一门新语言如果能证明自己,就会被人接受。但在它得到证明以前,不应该就先标准化并用以取代稳定的旧技术。
Ajaxian汇集了讨论这个题目的若干帖子,就连Dave Thomas也对ECMAScript 4有话要说:
单单浏览一下Wiki我已经可以看到这个语言包含prototype、类、multi-method(?)、静态类型、动态类型,等等等等。这让我这个老头子想起了其他由委员会设计出来的大型语言,像PL/I、Algol 68和ADA。这些雄心勃勃的语言无论设计还是实现都集中了一帮子聪明人,但不幸都搞得太复杂,面世也太晚。JS是要给一般人用的语言,不是什么只有技术天才才能理解的语言。如果你是一个Ajax开发者并且关心动态语言的发展,我觉得你是时候站出来发表意见了,去帮助ECMAScript 4转向一条不那么好高骛远的路径。对语言来说,小才是真好。
关注JavaScript的未来,请继续留意InfoQ的报道。
查看英文原文:Is the future of JavaScript ECMAScript 4?本文主要讲述了如何用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的未来规划。
3 条回复
回复