Merb新闻和社区站点

让我这个没有实际工作经验的失业者说几句我区分rails和merb，首先想到的就是：
1，Merb社区会否比Rails社区更开放，提供更多帮助?
之前都说过Rails core死活不肯实际一些东西，很多人都不爽这一点，并且如果大家看过Zed shaw这家伙的blog就会知道Zed抱怨了上万次Rails社区没对他提供过帮助是吧（据Zed称，DHH对mod_rails提供了不少），如果你的业务达到一定的程度，你自然而然会deept into他的core（核心），这时社区里的核心群体鸟都不鸟你的，在个人来说，肯定不好受是吧。
看merb的core成员的一些文章，我觉得他们极期大度
[援引Brainspl.at的一段话来证明他们有多大度：
I wrote Merb for a reason, if Merb’s philosophies agree with your tastes then great, use Merb. If Rails is your thing then that’s great too! We do not need a monoculture]
一种语言好不好，内部的实现我觉得还不是根，根本是背后的人，到底有多少有能力的人在为他添枝加叶。比较一种语言，我觉得非常有必要加上他的社区支持。

2，既然Merb是不满于raisl的一些东西，那么肯定是有它的长处（至少在作者自身看来）。

这不是一个好的理由。虽然集思广益在通常情况下是好的主意，但是太照顾所有用户的需求，而不进行必要的取舍甚至拒绝的话，那软件最终会变成一个庞大的怪物，今天的Springframework就是一个明证。所以我不觉得Rails core team独裁一点会对Rails项目的前景产生不好的影响。毕竟DHH还在开发和运营37signals的web软件，团队没有脱离实际开发，那么他拒绝很多东西也不见得就是性格孤傲，更可能有更多的考虑因素在内。

这不是一个好的理由。虽然集思广益在通常情况下是好的主意，但是太照顾所有用户的需求，而不进行必要的取舍甚至拒绝的话，那软件最终会变成一个庞大的怪物，今天的Springframework就是一个明证。所以我不觉得Rails core team独裁一点会对Rails项目的前景产生不好的影响。毕竟DHH还在开发和运营37signals的web软件，团队没有脱离实际开发，那么他拒绝很多东西也不见得就是性格孤傲，更可能有更多的考虑因素在内。

持久层的可选择性。在我看来就是白白多交复杂税而没有收益。如果真的需要比ActiveRecord更复杂的持久化机制，那也不需要yet another framework，完全可以并且应该以standalone library+rails plugin的方式来实现。RHibernate的动议到现在快两年了，实际的事情我看还是没人去做。

看了这篇文章，对Merb兴趣更浓厚了，从这篇博客的介绍来看，Merb有如下优点：

1、merb有一个slice的概念，从django的模块化概念借鉴而来，可以在多个web项目之间进行代码的共享和复用，这个功能非常好！而且是目前Rails所不具备的功能，这个功能在大规模团队的应用开发当中会很有用。

2、承诺保持public API的稳定性，即使更新，也会保持好的文档描述。这又是一个Rails的软肋。

3、比Rails轻便，节省内存、性能更好

4、Matz的最爱。说Matz更喜欢merb不自己造DSL的做法(Matz言下之意显然是不爽Rails的DSL扩展了ruby的语法)

其实我对slice很感兴趣，这个非常好，OK，有空的时候看看merb。

controller。我赞同return view_name的方式比render view_name and return要更合理。但这个decision带来的收益少少，（从Rails迁移的）成本却多多，怎么说服我要去做这个迁移？

简而言之怎么看怎么像一帮人气忿之下的针锋之作：Rails独裁我就要大度，Rails这样我就要那样，总之要处处显出比Rails强。
但我需要的不是一个处处都能把Rails比下去的框架，而是一个让投资产出比最大化的框架。

这其中有些入rubyInline明显不能在Windows上面跑嘛。看来在Windows上面还真不受人待见。

gem install merb --ignore-dependencies
gem install ...

不过看起来目前文档确实缺失的很厉害，我个人决定等merb文档完善一些了再看merb，光看源代码，还是有些浪费时间。

已经支持windows了,merb-action-args依赖它,我前两天写的merb程序在家里windows上能跑得挺好.