ruby-on-rails – 破坏Ruby on Rails神话

我正在为一个为我工作的IT公司的客户提供一个项目,我相信Rails是完美的.我在第二天还有一次会议,恐怕我会因为“为什么Rails？”被轰炸？类型的问题,毫无疑问,像“Rails不扩展”,“Rails只是一个CMS”和人们似乎对 Ruby on Rails的其他一些神话,一堆修辞.

我们似乎都有关于Rails如何扩展的争论,很难部署,或者在任何时刻都会在你的手中爆炸.对于我们每天使用Rails的人,我们知道就像任何其他语言或框架一样.似乎有很多关于RoR的错误信息,并且经常Rails得到坏的包装.为了帮助我参加这次会议,我希望能够编制一个神话清单 – 也许是每个答案的一个神话 – 我们可以投票支持我们以前听过的神话 – 消除恐惧,不确定性和怀疑,这些恐惧,不确定性和怀疑常常掩盖了真相轨.

经过一番搜索之后,我发现了this blog post这是我想在这里整理的东西.正如David Heinemeier Hansson在帖子中所说：

So I thought it would be about time to
set the record straight on a number of
unfounded fears,uncertainties,and
doubts. I’ll be going through these
myths one at the time and showing you
exactly why they’re just not true.

This is not really to convince you
that you should be using Rails. Only
you can make that choice. But to give
you the facts so you can make your own
informed decision. One that isn’t
founded in the many myths floating
around.

让我们澄清一下！

解决方法

神话：“Ruby on Rails不缩放”

胸围：这不是一个具体的问题.请澄清.

说无论什么技术“不扩大”听起来都非常专业,非常有道德 – 但这不是一个明确的问题.这是一个懒惰的方式来解雇未知/未经证实的我会要求澄清：

“你的”规模“是什么意思？你现在怎么衡量呢？”

这可能意味着：

>最大用户会话
>给定负载的平均响应时间
>在固定时间内,每个服务器的给定并发方案的吞吐量.
> …组织项目的困难,所以一大群开发人员可以开展工作.

有很多处理“规模”的方法,但是直到知道你正在处理哪一个,并不总是很明显的.

有大量基于ruby的解决方案,包括

>缓存HTML片段
>跨多个数据库分割应用程序
>用户之间共享的预计算工作
>将大量的视图渲染工作推送到AJAX / Javascript土地上,以便客户端发生
>更有效地使用前端Web服务器
>只是使用更多的硬件(即开发人员的时间昂贵,硬件价格下降),但是这种方法取决于需求的增长率
>做交互作用减少,批量更多的工作
>仅在ruby中进行部分工作 – 例如现有的传统后端轨道前端,或者可能通过功能编程系统的交易轨道前端

如果挑战者无法提出“规模”的具体含义,那么这不是一个有效的考虑.

然而,如果挑战者确实提出了具体和可衡量的内容,那么我会使用一个时间安排的尖峰解决方案(http://c2.com/xp/SpikeSolution.html)来回覆一些数字,也可能有几个选项.