嗯，说反 OOP 是不大恰当。只是 Rails 有自己的一套理念，不提倡过度设计。其实对简单的项目而言，因为 model 不会太 fat，Rails 的那一套（比如 concern）是既简单又便利的。

Trailblazer 的 service 层有时候还把东西搞复杂了，而且像 model 里面再实现内部类的做法感觉有点强迫症了，比如这个例子：

class Comment < ActiveRecord::Base
  class Create < Trailblazer::Operation
    def process(params)
      # do whatever you feel like.
      self
    end
  end
end

这样不知道怎么分文件存放 operation，但如果都写成一个文件显然 model 太大了。

不过貌似 Trailblazer 也不强制开发者一定要照它的来，就是说简单情况用 Rails 就够了，不知道是不是这样？

一个月前找 Rails app 相关架构的时候找到了 Trailblazer，但扫了一下项目我就没细看了。

这个框架的根本思路是用传统的 OOP 方式去组织代码的。但 Rails 从设计上就是比较反 OOP 的。就像有人在 Twitter 上开玩笑的，有复杂的业务逻辑怎么办？

1. 加 validation
2. 不够？加 concern
3. 还不够？加 callback

最后就见鬼了……

所以我不大看好任何在 Rails 基础上加 gem/library 之类去大规模改变 Rails 做法的事情，但正好 Trailblazer 就这么干的。对 Rails 而言，不是不能用 OOP 解决问题，比如 service object，但要适量，一味 OOP 就失去 Rails 最大的便利性了。失去便利性导致的效率倒退对我而言比软件架构不好更难以接受。

要找基于 OOP 的思路的框架，一切重新来过的 Lotus 也许是个更好的选择。

还在原型设计阶段呢，静观其变吧。

用 Vundle 吧，存一个 .vimrc 就可以了。迁移成本并不高，接近于零。去 http://vimawesome.com/ 找你需要的插件然后加代码到 .vimrc 就行。

@liwei78 同意你的观点。看回帖有越拉越大的趋势了。其实这种事情局外人是看不清楚的，面对不透明的信息，我们只能选择信任或者怀疑。所以就别掺合了。

再说，这里是技术交流社区，不是最高人民法院。

@Rei 这个宣传有意思！Passenger 真算是很会宣传的了。以前 Passenger 4 发布的时候，大家发现首个版本是 4.0.1，没有 4.0.0。Passenger 解释说是为了让更多的人尝试 4，因为开发者往往都会觉得 x.0.0 不稳定然后等到 x.0.1 再去升级。我当时就乐了。这货真是深蕴营销之道。

Rails 并不会死去，这个框架一直在全栈的道路上进化。只是现在的社会对 website 或者说 web app 对富交互的需求导致技术选型越来越倾向于重前端轻后端了。Rails 作为全栈框架的意义更多的在于传统的，轻量级交互的 website。虽然这类 website 还会一直存在下去，但网站交互性越来越丰富是大势所趋。

那个帖子下面有个评论我觉得很有道理。为了适应现在社会的变化，要么就深入学习后端的知识，要么就兼顾学习一门 JavaScript 框架，继续走自己全栈的路线。

其实就算对很多偏后端 Rails 开发者而言，一半的功夫还是在 Rails 之外，数据库，服务器，查询索引，缓存，分布式……后端有很多的东西需要注意，Rails 对整个后端而言只是个壳。对他们而言就算哪天 Rails 真死了，或者因为业务需要换一个框架，也不会受很大的影响。

受影响最大的就是搞了多年 Rails 最后还是只会 Rails 的人。这话换了 Angular/Ember/React 也适用。

@kgen Markdown 的 table 语法足够用了，但对齐比较麻烦（少数用到的情况我都是用 Vim 对齐的）；所见即所的编辑器不知道有没有支持的。毕竟对大多数人来说这是个比较少用到的功能。

@kgen 至于所见即所得的偏好，我前段时间尝试过几个平台，jekyll, ghost, medium 之后，最偏好 medium 的做法。那种流畅的感觉体验过就回不去了的。

相比所见即所得的平台或编辑器，markdown 在保持简单的同时能做更多的我需要的事情，但不代表喜欢，只是因为没有更好的选择。

@kgen 功能的丰富性这点是相对而言的。我一直认为面向普通写作者的写作平台和面向程序员的写作平台是有点区别的。国外的 medium 和国内的简书在普通写作者的写作平台方面已经做得挺好了。但程序员会有些特殊要求，比如我个人：

1. 代码高亮，这是基本的。
2. 嵌入 jsfiddle, jsbin 等做代码示例。
3. 偶尔使用表格。

这两点在使用 octopress 或者 jekyll 定制的时候并不麻烦，对第三方写作平台而言应该也不是麻烦事情，但支持这些功能的往往是写作和展示分开的，大部分就是 markdown 写作，再切换到 view 模式查看。支持所见即所得的平台比如 medium 似乎还不支持我说的第二点（如果说错了欢迎有人告知）。因为这需要从体验上去下功夫，本来就不是件很容易的事情。而且做出来还不见得被目标用户（程序员）买账，因为程序员本来就是不怕折腾甚至喜欢折腾的群体。

molokai，最接近 Sublime Text 的配色，无需折腾，终端和 GUI 都显示正常。 Base 16，GUI 显示还不错，终端下需要额外设置。

可以理解为当初设置“瞎扯淡”就是为自己留后路么……

两者都不是很好的选择。但如果必须选一个，我偏好 Markdown。不用太费神去调整格式，写起来直观，所有内容都是可见的，所以修改起来也方便，尤其是链接。

但是 Markdown 受限于编辑器，显示效果太朴素。这是所见即所得编辑器的优势。如果有一个编辑器能够同时做到编辑的易用性和功能的丰富性，估计会少很多纠结。可惜就算是目前体验最好的 medium 也只做到了前者，没完全达到后者。

个人看法：用 Capistrano

Mina 本身就是个简单的自动化部署脚本生成器，目的是让重复的部署过程变得简单快速，它设计之初就不是为了管理复杂的部署环境的，比如多服务器批量部署。Mina 官方很早就有人提 issue 加入多服务器部署的要求，不过我记得貌似作者响应不是很积极…… 它本来就不是为了这种要求而设计的。

所以本着合适的工具做合适的事情的原则，如果要题主现在（或者以后）有复杂的部署要求，建议用 Capistrano，毕竟别人一开始的定位就是多服务器部署，并且已经做了很多年，论稳定性和需求考虑的全面性不是自己 hack 的方案可比的。

如果是处于某个功能设计阶段（比如 git 开个分支自己干），或者还没部署到服务器上，又不担心清空数据，你可以修改已有的 migration，这样是为了避免设计更改导致无端增加数个 migration 文件。可以用以下命令去回滚然后重建

rake db:rollback   # 回滚，修改表
rake db:migrate   # 重建

或者这样：

rake db:migrate:redo

还可以加 STEP 指定 redo 几个 migration。

其他任何情况下，都建议加 migration。不管以后你部署服务器，或者你的小伙伴更新数据库，都只需要记住 rake db:migrate 就行。你也不希望很麻烦地去手动执行一些 SQL 去更改数据库吧（比如改 version）。能够解决数据结构同步问题，代价只是多一个文件，你觉得呢？

@nightire 没折腾……我当时是想偷懒用本地的 ember app 连 production server 获取数据，后来没效果就没折腾了。

@nightire 嗯，我也碰到过一样的问题，rails server 开 production 就死活接不了数据，development 没问题。

Angular 2 的模块语法不是学的 Python，那是正规的 ES6 module 语法。还有 class 语法也是 ES 6 的。除了 AtScript 加入的 annotation 和 runtime type assertion 之外其余的代码都是 ES6 代码。

至于说等浏览器支持 ES6 的估计都不怎么写 JS，现在 transpiler 多得满地开花，虽说不至于支持 ES 6 全部特性，大部分支持还是没问题的。

@coding 求抱枕，帖子（如果有），杯子（如果有）购买地址…… 另外想听听你们看到 Angular 2.0 后有何感想……

@serco @nightire 说的已经挺好了，补充一点关于 Ember CLI 的。

前端开发用一些工具去自动化流程已经很常见了，Grunt, Gulp, Brunch, Broccoli, Yeoman, Lineman... 用这些工具去写点脚本自动化流程是很方便，但每个项目都会有自己的一套流程，gruntfile.js 这种配置也已经成了项目代码的一部分。时间长了就会有几个问题：

1. 很多项目需要的流程都是差不多的，比如生成目录结构，编译 CoffeeScript，SASS，压缩 JavaScript，等等。所以有人搞了 Yeoman 的各种 template。
2. 如果用 Yeoman + template，那些 template 代码其实也是项目的一部分，以后 template 升级就蛋疼了，所以基本没人选择去升级，而是“反正简单我就自己用 Grunt/Gulp 鼓捣下呗”。

Ember CLI 的目的是做一个平台，既然大多数 Ember 项目都需要这些流程，并且都差不多，那就没必要在项目中去重复。你不需要操心这些琐碎的东西，也不用关心细节是怎么实现的。不管你是需要加入 CoffeeScript, SASS，设置 proxy 或者 mock API，或者装一个 library，部署到 Heroku，你只需要记住：

npm install --save-dev ember-cli-xxx-addon

和定期升级 Ember CLI：

npm install --save-dev [email protected]

就行了。就像 Ruby 世界扩展功能很多时候只需要 gem install 一样，不管功能是什么方面的。

BTW Ember CLI 是我唯一一个碰到的在开发中，不管添加，修改，删除文件，甚至 bower install 都不需要重启 development server 的工具。这应该得感谢 Broccoli。

Medium，目前为止编辑体验做的最好的一个。真正的所见即所得。以前 Rei 搞过一个国内的写作平台，也是类似的概念，但最终没做下去，可惜了。

2012 年的 Macbook Pro，刚升级有点卡，重启一次就好了。除了 Finder 切换文件夹不像 10.9 那样迅速，其他都没什么问题。除非死机一般不关机。

@leeluolee 赞一个！国外有个 HTMLBars 项目，貌似是在 Handlebars 基础上改写了 compiler，跟 Regularjs 是否是一样的理念？

最近很火估计还是沾 Google 的光。没用过，不过挺看好这类服务，中小型应用可以省去后端很多麻烦。JSON API 居然国内有人翻译 :plus1:

@sarah1356 @meeasyhappy 其实现在有项目就在用，一个用的 Ionic 一个用的 Ember，也算有一点点经验。PhoneGap/Cordova 应该会是未来 mobile app 的方向之一，开发效率也迅速一些。

你都不去看看 Ionic 文档的么…… http://ionicframework.com/docs/api/utility/ionic.Platform/

news 是不可数名词，单复数都是 news，而且 Rails 也能自动处理这一点。

'news'.singularize  # news

不过实际写代码还是会碰到一些命名上的麻烦，所以还是改个名字吧。比如改成 article, message 之类的。

@so_zengtao 看我的 profile 就看得到啊。

@so_zengtao 你也是武汉的？握爪~

只是大概扫了一下，没仔细看。我觉得虽然很 cool，但长期发展下去不是个好主意。因为所有试图去代替目标语言的做法都不能长久，对于 Ruby 编译成 JavaScript 我持悲观态度，以前的 RJS 如此，现在的 Opal 也如此。