Groovy on Grails 交流活动

活动宣传页：

2008 年上半年，一次活动中的翻译稿。Groovy on Grails 一些文章的翻译：

通常情况下所谓 “新” 的东西出现总是会伴随着许许多多的流言与困惑，Grails 也不例外，许多人也许会因为这个而放弃继续使用它。以下是一个简要的 Grails 流言列表：

“Grails 只是一个 Rails 的拷贝罢了。”Grails 确确实实引进并统一了一些 Ruby On Rails 不错的创意，Grails 将它们中的一部分应用到了 Groovy/Java 世界里，但更添加了许许多多 Ruby 中根本不存在的新特性与新概念，而这一切所作所为对 Groovy/Java 程序员而言都是充满意义的。

“Grails 对我来说并不成熟。” 我想日益增长活跃的社区站点是对这一说法最好的驳斥了。Grails 本身就封装了 Hibernate、Spring 和 SiteMesh 等几个早已扬名远播的技术框架，当然更别提那个已经熟透了的 Java JDK 了，还有别忘了，Groovy 已经三岁了。

“Grails 使用了一种解释型语言（Groovy）。”Groovy 是在运行阶段被 Java 虚拟机编译成字节码的，它绝对不是解释执行的——从来都不是，并且以后永远也决不会是。我说了 “永远” 吗？是的，毫无疑问！

“Grails 需要它特有的运行环境。” 不！你只需要使用 “grails war” 命令将应用打包成一个 WAR 文件，并将其部署到你最喜欢的应用程序容器中即可。当然，在开发的过程你大可使用 Grails 绑定的 Jetty 容器，这样完全可以做到开发的零配置与无需容器重启的动态载入功能。

“我的经理是不会让我用 Grails 的，因为它不是 Java。” 你真该敲他脑袋几下（注）！Grails 源码是由大约 85% 的 Java 语言完成的，它运行于 Java 虚拟机上，部署在你的 servlet 容器里。Groovy 实为一个 Java 强大的扩充，并在开发效率上比 Java 强出几倍。你当然也可以写一些简单的 Java 类并将其对象持久化在数据库里，也可以像在 Java 中一样将源文件或 JAR 包引入应用程序，例如 EJB、Spring bean 等等。一般说来一种新的技术总会因为其代码生涩性而难以推销出售，但无论什么也无法比 “嘿，我刚趁午餐时间花了一个小时搞定发布了我们的新应用——喏，这是网址。” 这样一个有趣的场景更有说服力了。（注：看起来我是有些过于喜形于色和小孩子气了，其实我不是这样的。）

“Grails 只适用于常规的增删改应用程序。” 有很多注重于 Grails 增删改的应用脚手架的例子，但那些只能体现这一小部分功能而已。Grails 是适用于各种方向 web 应用的框架。

“脚手架功能需要我在每次改变后生成。”“脚手架” 即是可以自动生成控制器和视图之增删改代码的样板控制器。对控制器和视图的显式重建通常毫无必要，除非你不愿应用动态脚手架的功能。“def scaffold = Classname” 就可以是你所需要的全部，它可以变戏法般地创建其它一切东西并在开发模式中自动重载。接下去，当然，如果你愿意的话，你可以生成个性化的控制器和视图代码。

“Grails 和其它框架一样，最终总有局限性。” 所有的 Grails 应用程序都有一个 Spring bean 上下文，你可以自由添加任意 Java bean 进去，并在你的应用程序中访问它们。Grails 有一个精巧的插件架构，用户标签库可以轻而易举地由 JSP 标签库导入并改变而来。

“我没法找到 Grails 程序员。” 任何一个 Java 开发者都可以很容易发展成一个 Grails 人员。开发 Grails 应用使用比标准 Java 少得多得多代码，让他们有更多时间休息吧，从此程序员清早起床的速度将会大大加快了。

“Grails 会令你在女性中更受欢迎。” 很抱歉，事实是截然相反的。你会更加热衷于编码而不再乐于时不时地去拈花惹草。是的，我们将把许多类似的忠告写入读我文件中，当然除了一个由于连续数小时泡在 Grails 里而导致离婚的潜在可能的案例。

为什么不来听听其他用户对于免 FUD 编程和双倍的 web 应用开发速度的谈论呢，Grails2007 交流大会即将开始，门票正火热销售中。

[来自：http://www.anyware.co.uk/2005/2007/07/02/10-common-misconceptions-about-grails/]

今天 Graeme Rocher——Grails 项目的带头人，收到了一封来自 David Heinemeier Hansson——Ruby On Rails 项目带头人的邮件，邮件中他对 Grails 第一版的发布表示祝贺，但也希望我们不要使用 Groovy On Rails 这个名字。

我们团队一致决定不再用 Groovy On Rails 这个名字了，但我对于这个请求依然抱有相当的疑问。我认为这个请求有些过分，特别在 Ruby On Rails 这个名字并未注册商标专利的情况下。我完全可以理解 Ruby On Rails 的支持者们想要保护他们的商标，但他们应该选择一种合法手段，而不是主动疏远别人。

再次申明，以上是我们团队的意见，也是我的意见。我们与 Ruby On Rails 社区依旧保持良好的交流关系，即便是在今天这样看起来有些气焰盛起的时候。我们将公布 Grails 邮件发送清单并通知大家官方名字的变更。

[来自：http://www.jroller.com/sdevijver/]

2008 年 2 月 5 日

现在你登陆 Grails 网站的话你就可以下载到 Grails1.0 版本了，它是目前可获得的最好的版本，而且，正如你看到的那样，它已经率先在 Codehaus 服务器上应用了！Codehaus 程序员们只用了很少的时间就让整个系统流畅运转起来，显然它在服务器上的负载表现很优异。

大多数人心理上能够理解 1.0 版本发布的重要性，它设定了一个东西的对未来发展进步的基准和起点。Grails 1.0 版本拥有难以置信的极其丰富的核心特色，并且有一组正在日益壮大的开源插件来不断增强功能。

现在 Grails 1.0 有一个强大的 ORM DSL 来完成 Hibernate 幕后做的许多工作，包括索引生成，这里我们可以找到 Hibernate 的二级缓存。不必将自动编集功能吹嘘得多天花乱坠，但它确确实实能将 JSON/xml 请求以一种经得起讨论评估的形式将有效载荷分布到 bean 中去。

我们也将自动运行功能的网站测试框架作为一个 SVN 支持的范例放到 Grails 的持续一体化中去了。在服务器环境中确实也出现了一些初始困难，但是整个进程却在本地开展了，我们只是将一些简单的优秀测试应用加入了 SVN，但重要的是，其中的某些网页测试脚本已经得到应用。

这将有效地形成一系列的 “TCK” 以确保 Grails 在 1.0 基础上的稳定性，此外，一组大量的 Grails 单元测试为持续整合平台的构建而稳定执行。我们要感谢这些广泛的单元网络测试所做出的不平凡的贡献。

Graeme 所做的一切让 Groovy SVN HEAD 和 Grails SVN HEAD 握起手来，不断的集成确保了 Groovy 中任何的特性变化都能到 Grails 中尽早地有所体现，除此以外，他还给了 Groovy 团队一大笔股票以支持他们去进行改变的尝试。

我们无比无比兴奋地与 Grails 新用户谈论 1.0 版发布的消息！

[来自：http://www.anyware.co.uk/2005/]

人超越一切动物进化之根本乃源于强烈的好奇心与求知欲。

——Alfred North Whitehead

欢迎来到 Groovy 的世界。

也许你已经在博客或邮件中听说过 Groovy 了，甚至你都已有所了解。如果你的某一位同事指出，你写的满满一页代码可以用短短几行 Groovy 语句完成，那么你翻起这本书的原因就不该仅仅是因为它上口的名字。好，到底为什么要学 Groovy 呢，你又能从中获得些什么呢？

Groovy 会让你很快就获得短期回报的，它令你将代码写得更简捷，替你自动地完成某些任务，甚至生成一些特别的脚本帮助你日常程序员式生活。当然，它也会令你获得长效的回报，它让你的代码从未有过地清晰易读，更重要的是，对它的使用一直是充满快乐的。

学习 Groovy 是一项睿智的创新工程。它带来了强有力的语言特性，比如闭包，动态载入，还有 Java 平台的元类型对象。在这一切过程中，你的 Java 技能却永不过时，因为 Groovy 正是建立在对 Java 平台的体验与熟知的基础上的。你可以选择这两套语言工具中的任一款，也可以将它们完美地契合起来。

如果你还在对 Ruby 阵营鼓吹可以在一下午时间内轻易完成一整套 web 应用的逻辑感到惊奇，Python 支持者和 Perl 迷们却早已通过敲打几个按键搞定了一套服务器集群，或者是干脆把他们一系列项目代码重写了一遍，正慢慢回味这整个过程中语言特性的使用呢。而另一方面，Groovy 创造的目的也正是为了在遵循 Java 对象模型和顺从 Java 程序员惯性思维的基础上扩展该语言的能力。

第一章将带你领略 Groovy 的背景并且为你准备一下必要的知识。而一切都是从这个 Groovy 的故事开始的：为什么要创造 Groovy，它的设计是怎样的，它在语言大家族里面又处于怎样的地位呢？第二章将带你领略更多 Groovy 的才华，让你切切实实体会到它是可以令你的生活轻松不少的，无论你是 Java 程序员、脚本狂，还是敏捷开发者。

我们坚信，学好一门语言的必经之路是：实践。在出现一些可以被 IDE 广泛使用的插件，以及 Groovy 的最新信息发布之前，你可以用我们提供给你的一系列脚本来模拟编译、解释，界面化运行。

到这一章的最后，你就会对 Groovy 有一个基本了解，并且知道可以用它来搞什么东西了。

我们作者和评论家，包括整个编辑团队，衷心祝愿你在使用这本书学习实践 Groovy 的时候，能真正享受快乐。

在 Groovy 的处子年——2004 年，一群 Groovy 的开发者聚集到了伦敦，James Strachan 组织了一次中心演说，告诉了大家这个让 Groovy 诞生的创意。

就在几年前，Strachan 夫妇还习惯性地等迟来的航班。一次，当 Strachan 夫人去购物，Strachan 先生来到网上冲浪，他还是习惯性地访问了 Python 站点，并且继续尝试对 Python 的学习。在这期间，他萌发了一个想法：作为一个老练的 Java 程序员，他意识到几乎快成为他母语的 Java 实在是太缺少 Python 独具的活泼和有用的特性了，例如表达文法对普通类型的本地语言支持，还有一些动态行为。于是新想法产生了，他要为 Java 添加特性。

以上也引出了 Groovy 开发的最主要原则：特性丰富多样，与 Java 契合友好，将动态语言吸引人的优势与强支持平台的健壮性结合起来。

我们不想诋毁任何一种语言，因为每一门语言都是有其特定的适用场合和应用能力的，但我们对 Groovy 在语言家族中的发展充满信心。

也许有些语言会比 Groovy 具有更多的特性，也许有些语言能与 Java 更好地结合，但到目前为止，能将这两方面几乎完美地结合起来的，唯有 Groovy：是的，没有一门语言可以向它那样提供与 Java 那么好的契合性却又同时具有如此多的现代语言之特性。

既然你已经知道了一些创造 Groovy 的意图，那现在就让我们来看看它具体是什么样的吧。

[出处：《Groovy In Action》作者：Dierk Konig]

呃，我正从 2GX——Groovy/Grails 体验大会回来， Jay Zimmerman 和一群热心的工作人员将其办的完美无暇。还有一个好消息，如果你错过了它，那么在秋季的加拿大 San Jose 还将举办一届。

参加这次令人瞩目的大会的共计约两百人，都无比热闹地讨论 Groovy 和 Grails。我将 “Grails 现状” 作为周四晚上的主题，从 Grails1.0 发布以来不断发展和技术的双重角度进行了分析。

我本不打算发布幻灯片，但一些与会人士向我索取幻灯片，以便于能从不单单的从技术角度，更能谈到发展和社区的角度，去说服经理们对 Grails 的使用。如果你也有相同的志趣，看看我的幻灯片吧，它的大意如下：

当我们发布了 Grails1.0 版本，Codehaus 的访问带宽总量难以置信地上涨了 40GB。面对新版本发布后每 10 秒钟数以千计的下载量，Codehaus 好心的组织者 Contegix 决定再为我们提供增加额外带宽的服务器。

请看 Grails 邮件列表统计，这已经突破了先前的记录，在一月达到平均 140 条每日的数量，看来在二月，这个情况也会差不多。

根据 Nabble 的这个统计，Grails 成为了 Java web 框架中最醒目的社区，并做出了巨大贡献：

更有进一步的 Grails 插件和生态系统社区的增长迹象表明，如今，Grails 插件库中已有了超过 47 组用户贡献的插件，其中包含二百万行代码：

博客统计也说明了用户迅速的增长，一年前 Grails 的博客统计还几乎为零（搞不好仅有的那几篇就是我写的，呵呵），不像现在，技术专家们会经常讨论 Grails。

显而易见的，要让 Grails 像 Spring 和 Hibernate 一样具有巨大的普及性，还有很长的路要走，但这些好消息都无一例外地说明我们正走在正确的道路上。

[来自：http://graemerocher.blogspot.com/]

全美最大并且是新闻公司（Rupert Murdoch 等）旗下的卫星广播天空（商业上称 BSkyB）公司，新发布了采用 Grails 完成的网站。

这个站点的完成需要充满热情工作，需要坚实的商议，干得好，伙计们！

这体现了一个大型 Grails 商业应用（至少我们在 G2One 公司可以谈论这个事情了，呵呵）的成功发布，此时已经有每月约 186 百万页的访问量了。非常高兴看到有那么多公司转而关注和使用起 Grails 来，但愿这个势头能维持下去！

[来自：http://graemerocher.blogspot.com/]

×Scan to share with WeChat