#4 楼 @py890000 #6 楼 @lgn21st 这一点甚至在 java 领域也不是必然成立，我一开始就用 editplus 写 java，然后发现有些人几年后还在为 classpath 头疼

#8 楼 @luikore 浮点的事情也不一定了，jruby 会得益于 jvm 的升级，莫枢去年说过，未来的数字计算可能会做优化，在函数内做类似去对象化的事情，所以也是裸计算 #9 楼 @flyerhzm 你们用 jruby 这么久，使用 nailgun 是必须的啊，启动慢应该不是个太大的问题

话说有点跑题了，楼主说的是 jruby vs. groovy 和 rails vs grails

列一下各自的优势：

groovy/grails

和 java 结合比较好，使用的所有对象类都是 java 类，而 jruby 不是，比如：

jruby-1.7.0.preview2 :001 > Java::JavaLang::String == String
 => false 
jruby-1.7.0.preview2 :002 > Java::JavaLang::Integer == Fixnum
 => false 
jruby-1.7.0.preview2 :003 > 1.is_a? Java::JavaLang::Integer
 => false 
jruby-1.7.0.preview2 :004 > Java::JavaLang::Integer.new(1).is_a? Fixnum
 => false 

这会在集成第三方 java 库的时候引入一部分转换工作

ruby/rails

由于植根于 ruby 社区，在 web 开发领域有大量最佳实践和三方库可以使用，和 grails 社区的支持不是一个量级，甚至即使加上 java 社区，在 web 这块，和 ruby 社区也没有可比性

结论

这种问题的的标准建议都是——看情况：如果你的遗留系统是大头，那么用 groovy/grails，这样要花一点时间把 rails 社区的工作再做一遍；如果未来的 web 应用是大头，那么用 jruby，这样要花一点时间分析和整合 java 遗留系统

#6 楼 @leckylao ubuntu 下面一样

sudo apt-get install fortune
gem insetall cowsay lolcat
echo "cowsay `fortune` | lolcat" >> .bash_profile

关键用 gem 之前载入 rvm 之类的环境即可

$ cat .bash_profile
[ -f "$HOME/.rvm/scripts/rvm" ] && source $HOME/.rvm/scripts/rvm
cowsay `fortune` | lolcat

#10 楼 @knwang #8 楼 @xiaolai 纯顶没补充

最后一句亮了

我怎么觉得这个网站本身就应该有足够的人力资源呢，应该考虑的是和 ruby china 这样的技术社区进行人力资源的合作吧，仅仅来招聘有点浪费了

不建议 irb，直接 pry 就可以了，前者不能看作是后者的学习基础

哦，原来 @hooopo 就是在做 iteye 啊，挺好的

#12 楼 @jimrokliu 你弄错了，几千万 PV 不是指一秒中有几千万个请求，而且这里面最重要的绝对不是 web 前端机，瓶颈在有业务逻辑的应用服务器，更进一步，我们可以合理猜测瓶颈是遗留系统的能力，关键指标应该是 TPS

#2 楼 @zhangyuan 基本同一楼，faraday 不方便带着 cookie，所以有前后连续操作的就用 mechanize

#14 楼 @jasl 恩，我只是加强一下你的观点，事实上我认为唯一需要在早期考虑性能的地方是架构，不过架构上能支持到下次重写的版本也就够了

#12 楼 @jasl n+1 也不见得就一定有问题，对象缓存比查询缓存好的场景还是很多的

#7 楼 @reus 是的，我始终觉得外界的说法也不太靠谱，公开信息说到这个项目是包括软硬件，相应的，监控运维系统之类也是不能缺少的，这时再考虑系统集成就不是那么简单了

当然，我仍然认为 12306 是有些浪费钱的，但不是从技术分析得到这个结论，而是从经济和项目实践估计，一般来说，国有背景下，产权不清晰导致低效是必然的，再考虑到现在 12306 并不是公开的招标，没有浪费甚至浪费不大都是不可想象的

一直很佩服楼主的工作

#43 楼 @bhuztez 用 google 百度了一下，网上很娱乐啊。不过我倒是可以理解，姚老板无非是不想分工太明确而已，rails 的做法不也是前后通吃么

#40 楼 @sunbird89629 30 楼没看懂

#20 楼 @bhuztez 这就是我说 rails4 也还没想清楚的地方，而且我也没见过哪个框架是想清楚了的，事实上我怀疑这个问题能否想清楚，屏蔽掉持久层的想法很吸引人，但这恐怕和“透明的分布式处理”一样，只是看起来很美

我觉得 rails 工程师喜欢的是独立创业，对外包恐怕是不感冒的

#14 楼 @yggg 不是把业务逻辑和模型分开，而是把业务模型和持久化独立开，不过我觉的 rails4 对这个问题也还是没想清楚

这个可以排队啊 http://railscasts.com 是个好地方

#41 楼 @doitian 明白了，k，被羞辱了

#38 楼 @ashchan 恩？哪里错了，我还没看出来？

#30 楼 @lgn21st #29 楼 @alvin2ye 确实无敌

#27 楼 @dotnil quora 上看到这个，是仿费马的口吻吧

I know this great UDP joke but you might not get it.

#32 楼 @sailtsao 太 x 了

应该用 Rails.env.test？这种形式这个当然没错，所以我才说自己写了个烂代码。 不过，我依然觉得这里需要一种机制锁死某些 Rails 的“全局属性”，这两个没冲突的

#23 楼 @lgn21st 答案好像不止一个吧，取决于哪家公司。我倒是想起了微软和苹果的工程师一起坐火车逃票的笑话

#13 楼 @xiaolai 说实话，我现在觉得 rails 社区有点象当初 java 社区了，以前最反感 java 程序员的就是“they think they’re the only ones here”

老笑话：某黑客从美国国防部某个机密系统里拿到了一份源码，不过由于时间有限，只有最后几页，黑客想好歹仔细分析也有用，然而打开后就精神崩溃了——

源码里全是 `}`

#14 楼 @zw963 好像是那句话吧 —— Matz is nice, so we are