#20 楼 @nightire 我两年前用 jQuery，两年间了解过主流 js 框架，从 backbone 学到了组织代码的方法，从别的框架认识了不同的模版，从 atom 的技术转变认识到原生 js 的效率，但是我依然用 jQuery 完成主要工作，这是不是水平原地踏步？

再举个例子，Twitter 发布了 Flight 框架，依然用着 jQuery，这是不是死抱着 jQuery？

#18 楼 @nightire 你就是过于敏感。luikore 原话说：

现在的趋势就是真正在干活的人被 前后端分离信仰和 micro service 神教夹击

luikore 也没说你是信徒（我现在觉得挺符合），你就是认为对方是说你，把前端所有不好都往身上揽，大段大段反驳。但是你自己说“死抱着 jQuery 不放手”是个现象，不针对个人，所以个人不能反驳这个观点，这不是双重标准嘛。

话说回来，看到 jQuery 和测试工具的结果还是令人挺沮丧的啊，尽管这两年前端发展日新月异，可是总体水平提升还是有点赶不上。

这不表示你看不起现在还在用 jQuery 的人，不是说 jQuery 水平低？如果不是，为什么要沮丧，总体水平会赶不上？

我一旦开始参与讨论，就不会用管理员身份干预讨论，需要管理员请 @ 另外两个管理员。

这个帖子满满的优越感和“说好互相理解，你们怎么还不理解我”，我分不清明确的问题在哪里。

一方面说 make peace，另一方面说别人“死抱着 jQuery 不放手”。不认同你的观点，你就代表一个群体说别人不尊重前端，不认同就别发言，难道别人就只能得出跟你一样的观点吗？我觉得跟楼主讨论前端真是太可怕了。别把前端搞成一个跟外部对立的群体，别认为不是纯 JavaScript 出身的就不懂前端，前端也是 Web 的一部分。

#28 楼 @nouse https://twitter.com/tenderlove

经常在 RailsConf 做 keynote。

#1 楼 @king1990_cool 要用 \A \z 不然会被多行字符串绕过。

感觉设计得有问题。传一个 param 确定好了。

https://twitter.com/5xruby/status/642201523108249600

#2 楼 @roclv 那就看 2012 年的数据。

http://rails-hosting.com/Results/2014/index.html

用 SSL。

#32 楼 @wpzero 淘宝 UED 的方案在他们的场景有合理性，但不是适合所有人。我觉得 Martin Fowler 的 MonolithFirst 也适用于这个问题：

This pattern has led many of my colleagues to argue that you shouldn't start a new project with microservices, even if you're sure your application will be big enough to make it worthwhile.

门户网站没必要，模版复用、SEO、首页加载这些都是前后端分离才引入的问题，用服务端渲染就好。如果是技术人员维护我还推荐静态网站。

官方文档第一部分就是路由……

get '/hello/:name' do
  # matches "GET /hello/foo" and "GET /hello/bar"
  # params['name'] is 'foo' or 'bar'
  "Hello #{params['name']}!"
end

#8 楼 @nouse 奇怪，查看原图又是正的。

#6 楼 @nouse 正在倒立观看。

#28 楼 @fresh_fish 支持 Backbone，一直放在我的后备箱中，它跟我的开发理念很匹配，不过一直没有复杂场景用得上。

我了解过调查问卷里面提及的大部份工具，结论是在我的场景用不上。不是所有网站都有复杂的交互逻辑，我用着 Rails 默认栈感觉良好。

前后端分离有点为了用而用的意思了，劝说使用这些工具之前应该看需求有没有必要。现在就算是前后端分离也向着全栈的方向去，因为后端提供的 api 不一定适合前端，又有很多理由不能改动，这样前端团队就要变成全栈，参考淘宝 UED 的前后端分离：也谈基于 NodeJS 的全栈式开发（基于 NodeJS 的前后端分离）。跟现有的服务端分离后，要重新实现一套基于 js 的框架、库、构建工具、部署工具，而这些工具都还在混战中。同时前端实现的 api 服务器成为服务端面向公众的第一线，就要考虑安全、性能等等各方面原先服务端考虑的内容。

这对 js 程序员可能是好事，因为工作需求增加了；对原有服务端是好事，因为工作量减少了；对大公司也是好事，因为可以并行安排工作给不同团队了。但是对于已经适应全栈开发的团队，换一个语言重新实现一遍没有什么好处，这些工作本来就是自己做的，分割两个程序还需要更多的调试和管理；对于小公司，快速满足业务需求才是最重要的。

另外我不认可前端后端这样区分开发者，我认为 Web 开发就是任何相关的知识都要了解，但是按照纯血 js 前端的定义我就是后端程序员了，似乎先天性缺乏前端基因。实际上我写的 js 也不少，适当的地方使用适当的工具。过于激进的推动前端独立可能会产生被重视的感觉，但是脱离实际就没有生存的土壤，对 jQuery 感到舒适的比例那么高应该看作用脚投票。我喜欢那些跟现有技术栈协作良好的工具。

用 Turbolinks 吗？ request.env["X-XHR-Referer"]

http://guides.ruby-china.org/active_record_validations.html#:message

https://github.com/voltrb/volt

楼主可以写个 demo 然后做分享。

#7 楼 @smallx 我作为管理员有义务处理不适当的发言。第一次警告，第二次封号。

#1 楼 @smallx 只回复“呵呵”是很不友好的。

#31 楼 @liwei78 gitbook 本地生成可以调用系统字体解决。

调试，不要猜 https://www.google.com/webhp#q=ruby%20memory%20leak

http://samsaffron.com/archive/2015/03/31/debugging-memory-leaks-in-ruby

1. 测试是必要的。
2. 测试代码也是代码，有维护成本。

这两点同时存在，不能忽略其中一个。

disposition: 'inline'

http://apidock.com/rails/ActionController/DataStreaming/send_file

去掉 turbolinks。

#10 楼 @douxiance 你已经发过很多“关注”了，如果只是想关注可以点主题下面的关注按钮。

Resque.inline = true

#2 楼 @chenge form_for 脱离 model 也能用：

<%= form_for :book, url: books_path do |f| %>
  <%= f.text_field :name %>
  <%= f.submit 'Submit' %>
<% end %>