程立谈架构、敏捷和SOA实践
支付宝首席架构师程立在本文分享了支付宝技术架构的发展，对架构的认识，成功架构的特点，如何避免架构设计的失败，以及在敏捷和SOA方面的实践等。
新闻
Steve Yegge把Rails移植到JavaScript/Rhino
作者 Geoffrey Wiseman译者 李剑 发布于 2007年6月30日 上午2时0分
在上周末的Foo Camp上，来自Google的Steve Yegge发表了一个名为“Google Rails Clone”的演讲，Johm Lam报导说，Steve Yegge主要谈的是他在Google中把Ruby on Rails移植到Javascript上来的工作经验：
为了提高Google中开发人员的生产力，Steve一直在力求劝服公司引入Rails（乃至Ruby）作为开发语言之一。可惜公司对此置若罔闻（Google并不想增加他们基础架构上所要支持的语言种类），这时候Steve就决定做一件任何其他决心受挫的程序员都会做的事情：他把Rails逐字逐行的移植到了JavaScript上面。
可以想象的出，这件事情在软件开发社区中引起了极大的反响，而大家也是各抒己见，争论不已。这项努力也让我们联想起其它一些项目，尤其是TrimPath Junction，这是另外一个打算用Javascript移植Ruby on Rails的项目，当然还包括Phobos和Helma。很多人认为这证实了Yegge的“Next Big Language”就是JavaScript或者ECMAScript，并提到了Steve最近所发的Marshmallow（译者注：很不幸的是这个链接似乎被GFW了）和丰盛的编程大餐两篇帖子。有些人开始考虑它与.NET on Rails的关系，还有些则对Steve付出的努力表示质疑。这之后Steve又写了篇博客来详细解释他的想法和感受。
InfoQ有幸对Steve Yegge进行了采访。在采访中，他对相关的问题进行了逐一答复。不过他很快就指出，他的话只代表个人意见，与Google无关，并希望大家不要依此来臆测Google的整体战略。
很多人最关心的就是他们如何才能参与到这个项目中来，这项成果是否会公开和/或开源，以及发布的日期，Steve表示他们已经讨论过这件事情，将来也会认真考虑，但绝对不会在近期内进行：
我们商量过把我们的“Rhino on Rails”开源的问题，不过到目前为止我们还只是随便闲扯而已。原因之一在于我们只能把开发框架安排在比开发相应实际应用次要的位置，最多不过20%的工作时间，所以它的进展一直比较缓慢。另外就是我们同时还要依赖Google内部的一些基础架构组件，它们自己还在被开源化的过程中，我也不知道有哪些已经被公布出来了。
但问题的关键在于，我们正在观望基于JVM上Rails风格的Web框架这个领域内的争战。现在已经有了很多处于不同成熟期的Rails克隆产品，它们包括：JRuby on Rails，Grails，Phobos，TrimPath还有半打左右的其它产品。
如果经过几年以后，它们中有一个能够站上舞台成为事实标准，并且符合Google内部关于安全、性能、可伸缩性和国际化支持的质量标准，那么我们干嘛还傻乎乎的不移植到那上面去呢。
也许它会做大，也许它用过不久就会被扔到一边，永远不会飞出我们这个小组成为开源项目。不过无论如何，要到几年以后才能看出它会走上哪条道路。任何一款平台都要用很长的时间才能趋于成熟，而Web框架这个领域至今还仍是动荡不休。
所以这项成果任何面向公众的版本都要依赖于未来2～3年内开源市场的状况，以及Google内部的支持——这一点在一年左右还是很难有定论的。
谈到Rails，以及Rhino到底是一个“移植版”或者只是一个由Rails引发灵感的框架时，Steve说：
我从Rails一出现的时候就喜欢上了它。我也喜欢Ruby，即使是完全抛开Rails来看的时候。但就开发Web页面而言，我从来没有遇到过像 Rails这样优美的框架。再加上不尽其数的关于我们的女英雄——Rails的话题，还有默默支持着她的精灵伙伴——Prototype和 Scriptaculous，更不用说为数众多的从各种语言脱胎而出的Rails克隆版本，我不得不说，DHH在创建Rails的时候，确实探索出了一条独一无二并且意义深远的道路。赞！
记者又就Rhino是一个“移植版”或是一个由Rails引发灵感的Javascript框架进行了重点提问，Steve说：
我已经尽我所能的在JavaScript的限制内做到了真正意义上的移植，不过还限于ActionView和ActionController的部分[还有Railities]，没有ActionMailer……嗯，还应该再加上一丁点的ActiveRecord，虽然我们在很大范围内都被限制在如何和后端通信的问题上。从长远角度看，我觉得后端应该会使用Hibernate。不过我们已经对它进行了逐步扩展，来让它比Rails拥有更好的性能、安全性和国际化支持。所以这个Delta版可以说是相当精彩的，一本讲解Rails的书也不过最多能让你精通这个框架60%的特性而已……我们还为它开发了一些很漂亮的工具支持，包括优秀的调试器和其它一些用于Eclipse和Emacs上的IDE功能。
在说到为什么没有直接使用Ruby on Rails的时候，Steve回答说：
编程语言都是些令人惊讶的小动物，就像照料一头完全服服帖帖的宠物东北虎一样。你可能会以为你们两个会相伴的很愉快，但是对于那些诸如Python、 Ruby或者JavaScript这种富有表现力的语言来讲，如果你没有制定一套严格的纪律的话，它们说不定什么时候就会狠狠咬你一口。你必须要考虑那些要在你的环境下工作一段时间的临时用户，他们会有什么样的感受。限制语言的种类就是首先要做的事情，这样从内部来讲，每一个人就可以更容易的向他所喜欢的内部代码库提交代码（也就是用那20%的工作时间作的事情），而不必担心因为未知的语法而犯错。
在一个公司里，你需要为你“正式”支持的每一种语言付出很大的代价——要提供对基础架构的支持、文档、对开发人员的培训、代码冗余以及其他一些不利因素。编程语言都有一套众所周知的核心功能，但后面总是跟着拖着一条长长的模糊语义的尾巴，而这条尾巴会变得日益难以辨认。这个特点在那些没有实际规范的动态语言身上尤为突出，比如Perl，Python，Ruby还有它们同族的成员。Google一直很谨慎的保持着开发语言的数量，把它限制在一个实用的范围内。这样我们就可以建立起一个庞大的专家组，而他们都是精通我们所选择的语言的。Google的代码库一直保持得如此整洁和统一的一个原因就是， Google已经在C++、Java、Python和JavaScript的基础上建立了标准，我们只能使用它们作为产品开发工作中的正式语言。这同时还有助于防止因为语言的互操作性而带来的组件之间相互组合的问题的遍地开花。
所以我没法用Ruby。为了保证可以和代码库中的其它代码相互操作，我只能停留在JVM上（请相信我这一点——它根本不是我可以通过RPC调用来解决的问题；我必须要在JVM上运行）。由于这个利用，C++和（原生）Python也被舍弃了。
针对选择JVM语言的话题，Steve Yegge解释了他如何在Java、Jython和Rhino这几种语言中做出了选择：
在Rails API中，我们可以看到它的特色之一就是可以把散列表字面量（hash literals）作为参数传递，Java根本就不可能做到这一点。Ruby没有方法重载，而且Ruby和Rails都有着各种各样的惯例用来传递 varargs或者block（function）参数。Java与Ruby的区别之大，完全可以让人因为障碍重重而放弃努力。所以我决定还是选一门动态语言。
Jython在第一眼看上去的时候很明显是个不错的选择，但它从2001年起就没有什么进展了。它曾经是最好的非Java的JVM语言。Jim Hugunin确实干的非常漂亮。但是不幸的是，在过去的六年内，它再也没有受到过任何宠爱，它已经远远滞后於Python好几个重要版本了（一个是 2.2，一个是马上要推出2.6）。
相反，Rhino一直都是人们的宠儿。它存在的时间甚至比Jython还要长，它一开始是作为SpiderMonkey (Netscape/Mozilla) JavaScript C引擎的移植，并且在开发的过程中就一直关注于性能问题。Rhino代码读起来很像C程序：它避免过多的分配，并且尽量多地使用跳转表（Jump Tables）来避免虚方法查询（Virtual Method Lookups）的额外开支。它有两种代码执行方式：一种是无限循环运行的字节码解释器，一种是优化过的Java字节码解释器，可以把很多消耗资源的JavaScript属性查询转成Java局部变量或实例变量查询。Rhino这个软件实现得非常严谨。
Steve还对JVM语言做了一个总体上的评论：
你还要把语言和JVM实现的语义差异作为一个考虑因素。大多数的动态语言都没有特别严格的规范，而JVM实现和C的实现之间的差异也是没有文档说明的。我很喜欢Rhino的一点就是JavaScript确实有着一套规范（ECMA-322），而且Rhino做的最好的地方就是它把自己与ECMA的差异全都记录了下来（比如它的多线程语义）。但即使这样，还是有很多JavaScript与Java绑定的问题需要考虑，Rhino有很详尽的文档说明，我们也还是花了很长时间来协同工作，来完成对边界条件的处理，并解决类似于类型映射和重载方法调用的问题。对任何一种给定的JVM语言，你所能找到的专家都要比对应的C语言实现的专家数量少的多。从这个角度来看，引入JVM语言要比引入它们原始版本的风险大的多，会抵消掉很多你从库的互操作性和Java支持的微架构上得到的收获。
Steve Yegge已经在博客上发表了更多的相关信息，您可以访问他的博客，并请对InfoQ的相应报导保持关注。
查看英文原文：Steve Yegge Ports Rails to Javascript/Rhino
没有回复
回复