JRuby on Rails的真实案例：传染病报告与处理系统-InfoQ

越来越多的项目都在使用 JRuby 和 JRuby on Rails。在 Mingle 、 Oracle Mix 和 Sun重写的 mediacast.sun.com 之后，又一个使用 JRuby on Rails 的新项目浮出水面。

Collaborative Software Initiative (CSI) 是一家把志趣相投的组织联合在一起，用很少的成本联合开发软件的公司。今天，CSI 发布了其第一个基于网络的开源传染病报告和处理系统。犹他州牵头的此疾病报告和处理系统将会在开源许可模式下，今年晚些时候推广到全部 50 个州。该系统不仅能帮助本地健康部门对个体案例和本地传染病群进行早期检测和调查，同时也能满足州和联邦对疾病爆发控制、疾病监控和流行病学研究的需求。

要注意的是，新闻还提到了这一点：该项目使用JRuby。我们采访了 Collaborative Software Initiative 的项目经理Mike Herrick，来谈一谈在此项目中使用 JRuby 的经验。

InfoQ：能不能简要概括一下你们所实现的软件？哪些部分使用了 JRuby？主要是网站吗？有没有涉及（商业）逻辑的部分——这些部分也是用 JRuby 实现的吗？

再过 6 个月，这个应用程序就达到两年的开发周期了（根据《精益软件开发》）。目前为止用的都是 JRuby。现在还都是网络程序，但在我们广阔的蓝图中还包括有分析程序、离线客户端和大量的整合工作。我们还没决定这些部分要用什么技术，不过我们想尽量还用 JRuby 和 Java。

InfoQ：你们用了 JRuby and Rails 的哪些技术？使用什么服务引擎（servlet engine）？有没有用过 Warbler 或者别的什么工具？

我们在 Java 6 和 JRuby 1.1.1 中使用这些程序包（gems）：
* Rails 2.0.2
* hpricot
* mechanize
* postgres-pr

我们还使用了如下这些 Rails 插件：

auto_complete

validates_date_time

model_auto_completer

haml

calendar_date_select

betternestedset

我们也在开发一个插件，叫做 acts_as_auditable。如果成功的话，可能在开放整个项目之前先开放它。我们做测试用的是 RSpec 和 Selenium Grid（也使用 RSpec），做持续整合（Continuous Integration）是用 Hudson，而开发工具则使用 NetBeans 和 vim。

数据库用的是 PostgreSQL。我们之前考虑过用 Solr 来做全文搜索，后来还是选择用 PostgreSQL 来做，因为它既能满足我们的需求，又不用引入新的可动部件。

服务引擎用的是 Tomcat，它工作得很好。我们了解了 GlassFish 的很多信息，打算试一下。Warbler 非常棒。Nick Sieger 还让它变得更好用（抛弃了原先基于 Goldspike 的包）。我们也为 JRuby 社区做了一点贡献，在 Warbler 刚发布在 JRuby wiki 上时，我们提供了怎样在 Rails 2 上使用 Warbler 的详细文档。我还写了一篇博客文章来介绍 Warbler 并指向它的 wiki 页面，至今为止，每天都有很多大公司来点击。我把这看成是 JRuby 正在被接受的标志。

InfoQ：从上面链接的信息中可以看出，项目的团队很大——有多少人在编写 JRuby 代码？

Collaborative Software Initiative (CSI) 利用社区的力量来组建项目团队，并为开发协作软件提供了中心项目管理服务，包括开发、测试和持续的代码支持。CSI 使用开源许可模型或者软件即服务（SaaS）模型来把软件分发给大量用户。我们的公共健康社区现在有 100 多人。社区是由学科问题专家（Subject Matter Experts，SMEs）和开发者组成的。其中，学科问题专家包括流行病学家、护士和医师。核心团队包括 10 名学科问题专家和 5 名开发者。还有两名兼职开发者。在七名开发者中，有四五个都积极使用 JRuby。Ed Copony 和 Pete Lacey 是该项目的高级开发者。另外，我们还在招募一位核心开发者。

InfoQ：你在使用 JRuby on Rails 时遇到过哪些问题？是怎样解决的？（工具，解决办法，给 JRuby 团队报告 bug）？

在每天结束时，即使在我们这样的理想状况下，开发核心的软件也非常难。我们雇佣了知名的专家来组成开发团队。不论好坏，我们有一些 JRuby、Ruby 和 Rails 的开发经验，但也不是太丰富。Collaborative Software Initiative 的金融服务项目主管 Ross Cooperman 有丰富的 MRI Ruby 和 Rails 经验。他在项目的初期引领我们走在正确的方向上。不过学习起来自然就绕了点弯路。一旦走过去，Ruby 和 Rails 是非常高产的，然而这并不能一蹴而就。我们曾有过一段难捱的日子，不过现在的问题少多了。

一路上我们依靠过 JRuby 邮件列表、wiki 和聊天室（IRC）。社区也给了我们很多帮助。在 Rails 2.0 第一次发布时，我发现了 Goldspike（JRuby Rails 服务程序）的一个 bug： http://jira.codehaus.org/browse/JRUBY-1879 。我们和社区一起只用了一个周末就解决了这个问题。三月份，在我们第一次发布软件之前的那几天，JRuby 1.1 也即将发布。可是我们突然发现了一个 bug，于是就无法像之前希望的那样跟 JRuby 1.1 一起发布了： http://jira.codehaus.org/browse/JRUBY-2314 。JRuby 社区马上集结起来，迅速解决了问题，让我们的软件最终和 JRuby 1.1 一起发布了。

InfoQ：为什么用 JRuby 而不用常规的 Ruby？

我们选择 JRuby 而不是 MRI 有很多原因：

容易部署

全球所有的企业都在用 Java

我们的开发团队有 Java 积累

我们的项目将来必须是可以扩展的，而单独靠 Ruby 恐怕很难做到

我们希望其背后的语言是 Java 而不是 C。

InfoQ：你希望在 JRuby 和 JRuby on Rails 软件栈中看到哪些功能和改进？

JRuby 社区的推动力给我们留下了无与伦比的深刻印象。它既有雄心也讲究实用。其核心团队由一些杰出的开发者组成。他们眼光很准，好像总在关注正确的东西。他们追求更好的 Java 集成和持续的性能改进，并和 JVM 开发者协作改进各种动态语言的 JVM。这些都很棒。

我也曾向 Pete 和 Ed 提出这个问题。他们主要谈了 Rails，而不是专门针对 JRuby。我们想看到更好的多模型支持，也许是通过嵌套的 has_many 和 has_one。我们也想看到更加一贯的验证支持，包括把验证错误上报至顶层模型。还希望看到更加灵活的 URL 格式，也许包括 URI 模板。

根据我们目前的经验，Rails 非常棒。我刚才提到，JRuby 和 Rails 是非常高产的环境。但我们正在构建的是一个大型应用程序——不论采用什么技术，都有非常大的工作量。我们当然希望看到明显高于 Java 和 Java and Sping 的生产效率，但 Rails 也不是终极武器。有人说，Ruby 社区中有很多创新的工具和想法，即使在艰难的学习道路的上，Rails 也给我们带来了许多欢乐时刻。

InfoQ：你希望 Ruby 语言和标准库将来增加哪些功能？

依我们的经验，JRuby 就挺好了。我们曾有个议题专门比较 JRuby 和 MRI 的兼容性。当然了，现在还有一些程序包没有移植到 Java 上，但又不是非得用它们。

InfoQ：用 JRuby 作为实现技术，让人（管理层和客户）接受这点有没有遇到什么问题？如果遇到过的话，你是怎样对付的？

创作场景

JRuby on Rails 的真实案例：传染病报告与处理系统

评论

更多内容推荐

推荐阅读

电子书

大厂实战PPT下载