Gregg Pollack 和他的 Scaling Rails 教学视频

Ruby on Rails 从发布之日到现在短短几年的时间里一直表现上佳，不过在其可扩展性上人们也颇有微辞。开发人员都很清楚任何问题都有正确和错误的解决方法，Scaling Ruby on Rails 也不例外。

Rails Envy 播客和 envycasts 的 Gregg Pollack 与 New Relic 合作，制作了一系列关于 Ruby on Rails 扩展性话题的教学视频，名为 Scaling Rails 。Gregg Pollack 居住在 Florida 的 Orlando，就职于他自己的公司 Rails Envy，从事教学多媒体的制作工作。他活跃于 Orlando 的技术社区，并帮助组织了 BarCampOrlando、Orlando 的 Ruby Users Group 以及 Colab──Orlando 的首个协作空间。

InfoQ 获得了一次采访 Gregg 的机会，就其最新发布的视频教学，以及这些视频将如何帮助开发者扩展 Ruby on Rails 进行了采访。

Robert Bazinet（RB）： 我看了 envycast 系列的介绍，这个系列最初的主题便是可扩展性，现在推出了 Scaling Rails 这个新系列。这是个巧合么？

Gregg Pollack（GP）：几个月前我想 做一些关于 Scaling Rails 的 envycast。不过，我意识到还是应该先从基础开始，这就是为什么我首先发布了”Scaling Rails“的 envycast。当时准备接着制作的 envycast 就是”Scaling Rails“，我真是非常幸运，得到了 New Relic 的赞助，让我可以免费在它们的 Rails Lab 上发布我的视频。

RB： 什么原因让你最终决定来做这个 Scaling Rails 系列？

GP：有下面几个原因：

• 为 Rails 开发者提供成功开发可扩展的 Rails 应用所需的所有技术资料。开发者可能从不需要使用这些技术，但是这些视频有望让他们信心十足地向客户保证：我们能够开发出同时处理数百万用户请求的 Rails 应用来。
• 让其他语言的开发人员看到 Rails 应用的可扩展性是多么容易实现。
• 一些企业仍然存在”Rails 扩展性不好“的观念， 这个系列有望进一步改变他们的这个错误观点。现在任何一个 Rails 开发人员都可以指着 Scaling Rails 视频说：你看，Rails 完全可以做到可扩展，就是这样实现的。

RB： 什么促使你产生了 envycast 这个想法，后来还制作了 Scaling Rails？

GP： 我有两个最大的兴趣：一个是影片制作，另一个是网站开发。Envycast 刚好能够将这两者结合起来，而且还可能赚到足够的收入来抚养我的孩子们。老实讲，我并没有因为这些视频大赚一笔，如果做包工我会赚得更多。不过像我说的，我就是喜欢这个工作。

Envycasts 的目标就是能够以一种妙趣横生的形式来提供教学视频。

RB： New Relic 似乎对 scaling Rails 很有兴趣，这个系列就属于他们的 Rails Lab。你会进一步发展这一合作关系么？这些视频具体有哪些内容？

GP： New Relic 在帮助 Rails 社区发展，以及鼓励企业采用 Rails 框架上很有兴趣。这很合理，因为他们想发展更多的客户，而和我们这样的小社区合作的方式 之一就是自己投资这些社区。在过去 Engine Yard 已经这样做了，它投资了 Rubinius 和 Merb 项目。

New Relic 推出了 Rails Lab 网站，内容以 Rails 性能话题为中心。有了他们的赞助我才能在 Rails Lab 上免费发布这些视频。

RB：你对企业采用 Rails 框架的未来怎么看？你觉得这些视频对帮助 Rails 达到这个目标是否是一条可循之路呢？

GP： 我渐渐发现越来越多大公司里的年轻开发者在说服管理层启用 Rails 作为项目框架。通常都是从内部应用开始，慢慢的进入生产阶段。我毫不怀疑明年会有更多大公司发布他们自己的 Rails 应用。

现在是开始使用 Rails 的一个绝好时机，尤其是考虑到经济因素。因为使用 Rails 可以明显减少代码量，而且维护代价（至少从我的经验来看是这样的）也比其他语言和框架要少得多。大公司很快就会意识到这个问题，并借此在竞争中保持领先优势。

我希望能够有开发者通过这些视频教学来说服老板们，在下一个项目中应用 Rails。当然目前还只是希望而已。

RB：接下来 Scaling Rails 方面还有哪些视频即将推出？

GP：说实在的，我还不太能够确定。现在完成的的 13 讲是：

• 第 1 讲：网页响应性
• 第 2 讲：网页缓存
• 第 3 讲：缓存过期
• 第 4 讲：New Relic RPM
• 第 5 讲：高级网页缓存技术
• 第 6 讲：Action 缓存
• 第 7 讲：Fragment 缓存
• 第 8 讲：Memcached
• 第 9 讲：Taylor Weibley 和数据库
• 第 10 讲：客户端缓存
• 第 11 讲：高级 HTTP 缓存
• 第 12 讲：Jesse Newland 和部署
• 第 13 讲：Jim Gochee 和高级 RPM

RB：是什么原因让大家产生了 Rails 扩展性不好这样的印象？

GP：我想可扩展性上的这个坏印象应该是来自几年前的 Twitter 和 TechCrunch。你可能知道，Twitter 是一个消息平 台，它能够处理每秒数以百万计的请求。Rails 作为像 twitter 这样消息平台的前端可能很不错，但是后端架构对扩展性需求很高，而大部分 web 框架 都无法很好的满足这一点。由于 twitter 确实存在一些扩展性上的问题，所以很多人都认为这意味着 Ruby on Rails 应用都有扩展性问题，但显然事实并非如此。

RB：对于那些开始在公司里创建 Rails 应用，以及创建可扩展的 Rails 应用的开发人员你有什么建议呢？

GP：请观看我的 Scaling Rails 视频教学吧！哈，我这真是王婆卖瓜，自卖自夸啊！

不过，说真格的，有必要学习一下 Rails 下如何利用众多的缓存机制打破性能枷锁。安装一个服务器监控工具，比如 New Relic 的 RPM，这样你就能在研发期间监控应用的状态。利用这一信息能够发现应用到底慢在哪里，应该从哪着手优化。

近来我发现有些公司过早的采用 memcached。不要轻易使用 memcached 去缓存数据库对象，除非你已经认真优化过数据库查询，却仍然达不到性能需求。

最后，在项目最初期，你需要腾出时间安排好”应用优化“的计划，然后再开始项目。这个时间绝对不能省！

RB：除了你的教学视频外，还有哪些其他值得推荐的资料可以帮助开发者开发可扩展的应用呢？

GP：我建议：

• 阅读 Cal Henderson 的《构建可扩展的 web 站点》。
• 学习如何使用 YSlow 并拿到 A。
• 如果你是一个 Ruby 开发者，去看看“ Ilya Grigorik 的博客”。
• 如果你是一个 Rails 开发者，请阅读“ Rails 缓存指南”。

RB：你认为对于企业开发者来说，使用 Ruby 和 Ruby on Rails 有什么优势呢？

GP：嗯… 这超出了我们今天话题的范围。我想企业中使用 Rails 的最大好处体现在项目的维护阶段。

• Rails 应用的开发方法是通用的。这就意味着当新成员加入时不需要详细了解项目的进展情况就可以开展工作。这一点也会给你带来更多的保障，如果负责为你开发这个 Rails 应用的公司出了什么问题，你可以很快找到另一家公司接着做这个项目。
• Ruby 开发的效率更高，用更少的代码做更多的事。代码少自然 bug 就少，维护起来也就轻松得多。而由于一般改动都只需要很少的工作量，所以要保持敏捷开发或维护都相对容易得多。
• Ruby 代码的表达能力强，因而可读性很好。这会帮你节省维护的代价，因为读懂别人的 Ruby 代码很容易。

RB：Gregg，非常感谢接受今天的采访！

Gregg Pollack 是 Rails Envy 播客的主持人之一，也是 Rails Activist Team 的成员。在 Scaling Rails 网站可以找到 Scaling Rails 系列的所有 13 章内容，您可以下载这些视频以及代码实例。

给 InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家加入到 InfoQ 中文站用户讨论组中与我们的编辑和其他读者朋友交流。