@camel 我建议你 不要和别人合租 vps，自己申请一个独立的 vps 好啦， 我建议你使用 EC2，因为 EC2 的微型服务器，第一年是免费使用的。

Rails 中

return if data.blank? # 等效于 return if data == nil return if data == ""

Ruby 迷很不错，我经常去。唉！！！太悲哀了。 备份太重要了

#4 楼 @Rei 我也是刚刚发现的

beginrescueend.com 这个域名的缩写应该是 BRE

begin rescue end

本来是个好域名，但是用在 rvm 上，感觉 要多烂，就有多烂。

500 Internal Server Error

#22 楼 @azhao 我觉得在某些情况下，的确需要测试服务器，但是就目前而言，我希望从软件技术上进行改造，来提高测试速度。

#23 楼 @Rei Ruby 1.9.3-p0 Rails 3.2.1

#11 楼 @Rei 谢谢你的方案，我尝试过啦，这个方法可以提高几秒钟。

#10 楼 @bluecoda +1 我也猜测 硬盘速度是瓶颈。我目前没发现 require 是负担。我依然把注意力放在 IO 操作上。

#9 楼 @xds2000 不是笔误，我们的确同时使用 factory_girl 和 fixtures。CPU 和内存的配置上面有，请问，你觉得我还需要说明那些主机配置？ #8 楼 @kgen 我的机器是笔记本 ThinkPad SL410K 是台低端笔记本。我们是创业团队，资金匮乏，所以我想从软件方面优化。

#3 楼 @linjunhalida +1

#1 楼 @kgen 我相信升级硬件，效果肯定能立竿见影，但是烧钱啊，而且，团队中所有人都有这个问题，大家一起升级，太伤钱了。

#2 楼 @xds2000 我的每个测试的在开始的时候，都会用 FactoryGirl 创建 10 个左右的基础数据。我猜测这个地方目前是 test 速度的瓶颈。

#26 楼 @jhjguxin 贼激动

编程和创业，不需要自制力，需要的是 兴趣 热情 信心 勇气。

#8 楼 @ensonmj http://feeds.feedburner.com/railscasts Railscast.com 右上方有个 rss 按钮

#3 楼 @hlcfan 用 rhythmbox 订阅的确不错

#1 楼 @lgn21st iTunes 官方不支持 Linux

diff git diff SourceGear DiffMerge

老爸老妈，生活大爆炸，好汉两个半，夏目友人帐，银魂，RubyChina，京东

这是官方文档 http://ruby-doc.org/core-1.8.7/Object.html 第一 其实这两个函数的在功能上的区别很大 block 参数的内容通常是固定的，比如

instance_exec {|x| p x }

而 string 参数的内容可以是动态产生的， 可以产生无限的可能性，比如

instance_eval "#{y} x"

y变量，可能是任何函数名，极度危险。

第二 instance_eval 的 string 参数，导致 动态的代码可读性很差， 相比之下，instance_exec的 block 参数，可读性很强

结论 当两者都能满足需求的时候，尽可能使用 block 参数方式， 因为这样代码可读性很强，而且还易于 debug。 只有在迫不得已的情况下，才使用 instance_eval 的 string 方式。

我基本上天天都看 ITEye 的 RSS，RSS 的内容还是不错的

#11 楼 @jiffies 1 可以省略，但前提是 find 方法不是 private 方法 2 起床上班

#8 楼 @jiffies self 是一个相对的变量。

以下代码中 self 是，Order 对象 (注意 不是 Order 类的对象)

class Order def self.foo end end

以下代码中 self 是，Order 类的对象

class Order def foo self.find end end

难点在于，Order 即是类，又是对象，Order 是 Class 类的对象。 还有一种理解方式， Order 是一个变量，变量的类型是 Class。

http://guides.rubyonrails.org/ 是王道

看样子很不错哦，可惜人不在上海

如果没有什么特殊原因的话，最好少用继承。 继承虽好，但不能滥用。

如果你要定义一个新的 model movie 的话， 首先我建议你先不要用继承，model 层和 controller 层都先不要继承。

先从没有继承的结构开始编码， 编码完成后，如果发现重复度很高的话， 可以考虑提取共用的函数。

其次，给你个建议， controller 的 action 最好不要定义在基类中， 否则代码会很混乱，这种混乱带来的危害， 远远高于，因为继承，代码量减少，所带来的好处， 正所谓得不偿失。

避免重复编码 这个原则 要有一个尺度，不能太过分。

#13 楼 @tumayun 明白了，先说事务处理， 如果业务逻辑要求 deals.save 和 n_deals.save 应该一起成功，或一起失败， 不能一个成功且另一个失败， 那么就要使用事务处理， 否则，没有必要使用事务处理。 至于业务逻辑，是产品经理或者项目经理决定的。

另外一个问题，我很奇怪，有这种关系，为什么不在 model 上做关联。 而且，在 action 中调用两次 save 是很不好的设计， 至少应该把两次 save 封装到一个 model 的 public 函数里。