这两个话题都是一个很大的话题，本不应由我这个对ruby或rails都半通不通的人来说，昨晚看到了@keakon 这篇文章 你该选择Ruby on Rails吗？ ，发觉似乎大部分人对它们误解都比较大，所以我在这稍微说下个人见解
大部分语言，静态的动态的，其实都更偏向于机器语言，是人类对机器说话，目的是让我们的话能让机器懂得。
而ruby，大家都知道它似乎很「自由」，一个函数可以有多个别名，比如得到 Array 的长度，有size，length甚至count，很多人费解为什么非得安上那么多别名，一个不就好？但如果以人类语言的「语境」来理解这个，就相当明了，以之前我的一段关于Notifications实现的代码为例子
def notifs_count
self.notifs.count
end
以上是说得到未读提醒计数，用self.notifs.size或者self.notifs.length都可以得到一样的结果，但却没count那么符合人类的「语境」。可以说ruby的自由，最大的目的是为了让语言看起来更像「人」说的语言，比如这一段代码
user.notifications.build(:attachable_id=>topic_id, :attachable_type=>'Topic', :content=>content).save
以上一段代码的解释是：用户的提醒条目建立并保存下来
所以一般我分辨别人的ruby写得好不好，就看它的代码能不能让人类易懂，
正如之前 @wtl 所说的，读起代码来就像读新闻一样。
对于rails，以下：
大家都知道一个小部落，「首领」直接说了算，甚至不需要什么「部门机构」，只要「首领」足够英明，小部落便能打理得井井有条。但一个「小部落」逐渐发展壮大，成为一个国家时候，就不是单单「首领」说了算就能解决管理问题，这时候不论你选择「君主制」，「总统制」还是「议会制」，都需要足够规划，将各个「部门机构」的职能确立下来。而rails采取了「MVC制」的web开发框架，「约定胜于配置」的本质意义在于「规划部门」，将「部门」确定下来并将「各个部门该负责干什么确立下来」，但这里它会「预先安排好一支精干的工作人员队伍」，免得你这个「头」对着这个空壳机构无处下手，无事可做。如果你有好的眼光物色到更好的工作人员如js库「jQuery」，测试框架「RSpec」，或者非关系型的数据库MongoDB的ODM「Mongoid」，你完全可以招来代替rails本身给你标配的「工作人员」，当然，你新招来的人员你要用得了驾驭得住。而这一切，一般都是你在熟悉你整个机构规划后并且对原有「工作人员」（Active Record之类）试过过后才会考虑换新人，刚刚上位连哪个「部门」哪个「人员」该干什么都还理不清，就乱搞搞反而更乱了。一般来说，rails原本标配的的「工作队伍」都是久经考验，相当有能力的。
ruby是门自由的语言，而如果rails「约定胜于配置」的意义在于死板硬定，那么两者就是完全对立的理念，在理念完全对立下rails断然不可能发展起来（完全死板硬定，开发人员能认可吗？完全不可能阿），并且蓬勃至今，所以对于「约定胜于配置」的意义需先了解清楚，才能更好的熟悉rails。
每个人对于语言与技术内心处都会转为自己独自的理解，独自的道，以上闲话只不过是本人内心对ruby和rails的主观意识而已，所以大家如果观点不同，实属正常，请勿恶言相向，自己悟自己的道就好。
PS:
1. rails的路由设置功能（routes）相当之强大，正则表达式支持的用法rails的路由基本都支持，并且拥有更多的功能，但很多资料并没有完全介绍清楚这一点，但熟手都知道如何用。（不论 http://www.example.com/2011/03/22/MacBookPro 还是 http://www.example.com/2011-03-22-MacBookPro 这类型的路径都相当简单配出来，有兴趣的同学可以自己找相关资料去）
2. rails3.1.0开始标配的js库已经是jquery