剖析短迭代
敏捷教练Dave Nicolette提出:我们应该如何设定迭代长度?是要根据发布周期的时间么?使用短迭代又有哪些好处?
作者 Mark Little译者 黄璜 发布于 2008年8月28日 上午12时40分
在OSCON 2008大会上, David Recordon宣布了开放Web基金(Open Web Foundation)的成立,其宗旨是:
……为“社区驱动的规范”打造一个家园。遵循和Apache软件基金类似的开源模式,本基金致力于构建一个轻量级的框架,来帮助社区处理必要的法律需求,以制定成功的而且能被广泛采纳的规范。本基金试图打破为每个规范建立一个单独基金的趋势,并且意识到我们可以团结起来推广我们的努力。关于会员资格、治理,以及知识产权等等细节将于接下来几周内发布以征求公众评阅与反馈。
鉴于我们正在商定该基金的具体细节,我们鼓励并诚邀各路朋友参与商讨。如有疑问,请参考我们的Q&A页面。同样,我们更加欢迎您参与到我们的社区里,群策群力,一起讨论你希望看到的这一基金制定的规范。
多么令人称赞的目标啊,背后又有着Google、Yahoo、O'Reilly等等的大力支持,看上去似乎很是有趣。Dion Almaer为这一进展“激动不已”:
想像一下,当你想到一个绝佳的点子,比如OAuth之类的。这个想法越来越引人注意,于是更多的人想要参与进来。你怎么办?人们开始询问关于IP策略,治理,于是你突然意识到你正在创建一个“MyApiFoudation”。等等!不是已经有够多的标准工作组与其它的组织在那里了吗,显然你犯不着去建立一个MyApiFoundation啊?
诚然,我们已经有了W3C和OASIS,但那是给钱才能玩得起的。它们有它们的地位,但对MyApi却并不适合。WHATWG作出了卓越的工作,但IP转出(punting IP)仍然是个问题。
Myapi有一些代码基础了,那么把它放在Apache如何呢?对于代码而言,Apache再好不过了,但它不能处理其它事务,这也是它的好处。毕竟那并不是它的责任。Apache做得非常好,特别是涉及到治理与孵化过程等方面。如果我们能有一个参与人(因此每个人都可以,相对于那些公司)和各社区(而不是老是那些来自同一个公司的家伙)具有相同价值观的类似组织该有多好啊!
这就是为什么我对开放Web基金充满希望。当你的主意对开放Web有帮助的时候,这是一个值得你注意的新的机会,一个能实现你的价值的地方。
尽管OWF声明他们不会与其它的标准实体产生竞争,而是“跟一直我们打交道的社区目前都是以一种非正式(ad hoc)的方式聚集在一起,如果我们能帮助他们理清知识产权,那么将会为社区将开放规范提交给标准团体打开方便之门。”;然而别人却并不认为多一个标准组织有什么必要。像Dare Obasanjo所指出的那样,对W3C和OASIS的猜疑往往是它们收取费用(有时候会很高,但也有$500左右的个人会员资格),但仅仅因为这一成本就有必要或者足够理由另起炉灶吗?特别是自从1992年我们就有了IETF。Dare继续谈到:
IETF的会员政策再直接不过了;加入邮件列表。我在RFC 4287里被列为Atom工作组的一员只因为我参与了atom-syntax邮件列表。关于知识产权,这个组织有着缜密思考而具体的策略,并有相应IETF规范进行详尽的阐述:RFC 3979:IETF技术里的知识产权以及在RFC 4879:关于RFC 3979中第三方公开过程的澄清里面的些许更新。对于其它人关于“除了‘因为我们能这样做’以外似乎没有更好的OWF创建理由”这样的意见,Bill也表示赞同:
我可以理解那些意欲对一个规范的整体社会性和技术导向保留控制权的人们想要避开它们的原因--这有点像启动你自己的开源项目(尽管我觉得OWF在OSCON上的揭幕毫不重要)。我曾经为IETF,JCP以及W3C都工作过,也站在了OASIS的门槛上。我认为毫无疑问你应该使你的努力融入这些组织,无论技术上还是政治上——政治,因为技术规范与开源项目的范围并不相同,它有着极大的经济影响面——换句话说,也许有些人的午餐都赌在里面了。也许这就是OWF存在的原因,谁知道呢。这么说,我实在想像不到为什么有些人想要重做全球性技术部署所要求的那些流程和知识产权(IPR)等等;这是极其重要的,容不得半点散失。Dare抛出了一个问题来作总结:Google搅合到这里面干嘛呢?
我能理解那些刚从学校出来的乳臭未干的小子能够无视IETF并以为他们能重复发明轮子来拯救开放Web。但我想不通的是Google,这个有着不少雇员参与到IETF的流程里面并帮助制定了RFC 4287, RFC 4959, RFC 5023 以及 RFC 5034 等等规范的公司,居然也会加入到这种行为里面来。Google为什么要赞助这样一个与IETF相竞争而又不及IETF完备的单独的标准组织呢,它甚至连公司赞助要怎么运作以及IPR策略如何确定都还不知道?我们会看到这一行为究竟是真的能发挥作用呢,还只是又一个昙花一现罢了。但是随着OASIS,W3C以及IETF的蓬勃发展,OWF要想在短时间内发挥影响恐怕是很难了。
本文主要讲述了如何用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的未来规划。
没有回复
回复