BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

Rails从互联网走向企业

| 作者 Jeff Xiong  他的粉丝 发布于 2007年4月23日. 估计阅读时间: 3 分钟 | GMTC大前端的下一站,PWA、Web框架、Node等最新最热的大前端话题邀你一起共同探讨。

在过去的两年里,已经有太多的讨论围绕着“用Rails要快多少多少倍”展开。但是,对于复杂的企业级应用来说,开发的效率只是一方面。至少还有其他几个方面是必须关注的。

  1. 非功能性需求,也就是软件的-ilities:性能,并发吞吐量,伸缩性,安全,等等。
  2. 完整的生命周期支持:需求,设计,开发,配置管理,质量保证,部署,维护,升级。软件生命周期的各个环节是否有适当的工具和/或最佳实践来覆盖。
  3. 系统整合。与遗留系统是否能够协同工作。这主要体现在两个方面:(1)消息系统;(2)遗留数据库。

实际上动态语言早已在各种企业IT系统中扮演胶水的角色,一些成熟的组织早已认识到它们并不止是急就章拼凑软件的法宝。动态语言本身的特点使得它们能够相当漂亮地描述各种领域,这正是为何Rails只会在Ruby上出现的原因。来自InfoWorld的文章这样写道:

值得注意的是,PHP、Perl、Python和Ruby等动态语言在企业中扮演着越来越重要的角色。IT管理者们很快地意识到:比起传统的、较为低级的企业主流开发语言,使用这些动态语言能够更快、更轻松地写出易于维护的好代码。

另一篇InfoQ的文章在介绍ChangingThePresent.org的案例时这样写道:

有人说Rails对复杂解决方案的扩展支持能力不够,我不赞成这种说法。和同类技术相比,Rails的生产力是最高的。Rails对我们的开发过程、团队组建和管理都产生了戏剧性的影响。所用技术的生产力越低,迭代周期就越长;团队越大,花在检查和协调上的时间就越多——在Ruby和Java项目管理我都经历过后,更为支持这个观点。使用别的技术,就需要组建更大的团队(比如10到15人),而我们则可以保持团队最小化。

至于前面提到的、企业级应用环境所看重的三个方面。结合ApacheMongrelHAProxy的部署方案已经被证明具有轻松超过任何J2EE应用服务器的性能和吞吐量,无共享架构使其具有完全线性的水平伸缩能力;至于安全性,Unix本身就已经构造了完备而可靠的安全体系。在今年的RailsConf上,我们将看到关于“如何部署高性能企业级Rails应用环境”的产品和最佳实践。

在生命周期方面,我们已经有了CruiseControl.rbCapistrano;我们即将看到Mingle的正式亮相,以及基于这些工具的最佳实践。系统整合或许是目前最不明朗的一个领域:我们有ActiveMessaging,我们有复合主键支持,但是很明显这离着“方便的遗留系统整合”还有相当距离。在未来的一年中,这可能是“企业级Rails”最有看头的一个领域。

总而言之,不难看到,即便是对于企业级超复杂的要求,Ruby和Rails也已经做好了——至少是大部分的——准备。Rails已经像J2EE那样成熟了吗?不,远远没有。但对于那些愿意承担一定风险来提升IT效率的企业而言,是的,Ruby和Rails整装待发。

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我
社区评论

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT