对于 @zhangyuan 提到的问题， @aptx4869 你可以看看下面的链接 https://github.com/rails/jbuilder/commit/e0d9acc9a0869c4014ca671c4bf92b9eec627c40

#4 楼 @hooopo 弱弱的问，你用过 Rack Cache 么？

为避免你误会我第一句是反讽你不懂装懂。我要声明一下，我是诚心求教，如果在使用 Rack Cache 有什么心得体会，请不吝赐教。使用这套解决方案之前，我试图用 Rack Cache 来解决问题，毕竟没人喜欢重复造轮子，结果很沮丧，也许是我用的不对。本道士英文比较差，读了很久文档也没发现 Rack Cache 如何设定给某些请求 不加缓存 以及如何设置某一缓存 定时失效。如果要全站静态化的话，选择 Rack Cache 用起来倒是够简单。

#2 楼 @aptx4869 #1 楼 @hooopo

似乎你们没注意我说的是 HTTP caching

#3 楼 @dxwts 不需要 ajax，直接用 JavaScript 修改预览图的 src 地址就好。请看 http://stackoverflow.com/questions/18189330/rails-3-best-way-to-preview-image-before-upload http://saravani.wordpress.com/2012/03/14/preview-of-an-image-before-it-is-uploaded/

打不开就翻墙

1 在服务器后台看看 public 目录下是否能找到这个图片 2 看看你的 nginx 配置信息，对于 uploads 文件夹的请求，做配置了么

1460 cd 842 rails 562 rvm 334 bundle 294 ls 289 curl 189 rackup 161 rake 136 gem 102 git

ActionScript 基本没啥出路了

#2 楼 @newbie rvm list 确认自己装了这个版本的 ruby

rvm use 1.8.7-p374

刚起床，一会到公司就去试试。希望可以解决 vendor/assets 引入 几十个外部 js 和 css 文件，造成无法升级第 3 方 js 库的问题。下面是简单翻了一下原文

---

Assets management solved: we released Rails Assets

过去的几周我们一直在整 Rails Assets 终于可以在这周给 Ruby 社区提供一个管理 assets 的解决方案了。

展示

Tymon 在 London Ruby Users Group meeting on Monday 展示了 Rails Assets

Watch the video from the talk 或者看看我下面的简单翻译

目前面临的问题

• Rails 项目中管理 assets 很难
• 大量的 JavaScript libraries 不兼容
• 遗留项目不可维护

目前的解决方案

• vendor/assets
• bower
• component
• browserify(npm)
• asses gems

Rails Assets 用法示例

上午没空翻，看 #7 楼

优点

• 不用 vendor/assets
• 适当的版本
• 解决依赖问题
• 无需额外的编译
• 在部分真实产品中已经使用也没发现啥大问题

工作原理

上午没空翻，看 #7 楼

挑战

上午没空翻

故事

自从 Rails 3.1 引入 asset pipeline 之后，在 Rails 项目中管理 client-side libraries 总算脱离石器时代进入青铜时代了。再也不用手动把那些需要用到的 JavaScript/CSS frameworks 上传到 /public 文件夹了。

但是当你真正做项目的时候才发现，其中的苦楚真是：如人饮水，冷暖自知。我们仍然要管理每个项目中得 vendor/assets 文件夹，已期自己版本库中的这些第 3 方代码和它们原始库保持同步。RubyGems 上的版本通常会有几周才会更新，当然也有坑爹的数月不更新。它没有像 Ruby-China 这样的社区支持。主要是这货是纯手动的，以致于想保持 gems 和外面的最新版本一致特别繁琐。

另一面，前端开发者们完全忽略 Rubyists。他们捣鼓出来了一个叫 Bower 的玩意来管理软件包。并且解决了让我们深恶痛绝的问题，那帮熊孩子们可不关心 Gemfile。

在 Rails 应用中合理的管理 asset 好像缺了一个环节。明显的一个场景：每次手动更新特定项目中较旧的 client-side libraries 文件。然后在其它的项目中定期重复这个动作。总有一天你会掀桌子：玩儿蛋去吧，就让这些文件保持初始状态，我用它就是想实现 XXX 效果，实现效果之后我再也不想动这些文件。 technicaldebt

考虑到本帅近期是泡着温泉做着 SPAs 编代码，上述情景成了一个大问题。因为每天开发结束的时候，总要有专人手动来管理我们程序中使用的 core libraries 和 toolkits。这感觉就像回到 1999 年的时候，完全不符合我们高富帅的身份。

Rails Assets 的出现正是为了解决这个问题。在 Bower 和 Bundler 之间提供一个代理，完美调和 front-end 和 back-end 的矛盾。

感谢我们的 CTO，感谢我们的 UI 设计师，感谢天，感谢地，感谢 CCTV。

我们用了许多我们开发的，仍在运行的项目来验证了这个方案的可行性。当然我们也不能吹牛 X 说这个方案帮我们提高了工作效率，改进了工作流程，省了多少时间和客户的银子。呵呵呵，你懂得。

Technical highlights

呦呦切克闹，这个功能将成为杀手级的说。

What happens next

作者需要你的帮助和支持，有啥问题请给作者提供反馈。

#3 楼 @Rei 看来

• 使用 CoffeeScript
• 不玩定时器
• 不在 document 和 window 绑事件

就不用担心内存泄露了，新技能 Get √ 谢谢

1. 怎么引起内存泄露呢？求指导

Server-generated JavaScript Responses

Basecamp 的绝大多数 Ajax 操作是由服务器端生成并返回 JavaScript (SJR)，它的工作流程如下：

1. 通过 XMLHttpRequest-powered 来提交表单
2. 服务器端创建或更新一个 model 对象
3. 服务器端生成并返回 JavaScript，它包含更新该 model 的 HTML 模板
4. 客户端解析这段由服务器返回的 JavaScript, 然后更新 DOM

这个简单的模式有许多重要的好处。

好处 #1: 重用模板且不牺牲性能

可以在第一次渲染 model 和后续更新中重复使用同一模板。例如在 Rails 项目中，你可以在这两种情况下都使用 messages/message 这个局部模板。

如果你只返回 JSON, 为了显示 messages 你需要执行两次动作 (一次是服务器端的 first-response, 一次是客户端的 subsequent-updates) —— 除非你正在做一个单页面的 JavaScript 应用程序，甚至第一次响应也是 JSON/client-side 生成并完成的。

使用第 2 种方法可能非常缓慢，因为你不能显示任何东西，直到你的整个 JavaScript 库都加载完毕，然后客户端生成的模板。(这是 Twitter 最初使用的方法，后来抛弃了)。但至少在某些情况这是一个合理的选择，且不需要重复模板。

好处 #2: 客户端做更少的运算

嵌入 HTML 模板的 JavaScript 的响应时间可能略大于纯 JSON 的响应时间 (当你使用 gzip 压缩时，这种差距通常可以忽略不计)。它不需要客户端的运算来更新。

考虑到这些模板的复杂性和客户端的计算能力，且服务器端生成模板通常可以缓存并在多用户间共享 (参考 Russian Doll caching)。这意味着，从 end-to-end 的角度发送 JavaScript+HTML 有可能比 JSON 配合客户端生成模板更快。

好处 #3: 浅显易懂的执行流程

SJR 是一个很容易遵循的执行流程。请求机制是一个标准化的 helper 逻辑，例如 form_for @post, remote: true。没有必要为每一个请求定义 action 逻辑。控制器执行逻辑，然后渲染部分视图生成响应，以完全相同的方式呈现一个完整的视图，只是模板变成 JavaScript, 而不是 HTML。

完整的例子

0) First-use of the message template.

<h1>All messages:</h1>
<%# renders messages/_message.html.erb %>
<%= render @messages %>

1) Form submitting via Ajax.

<% form_for @project.messages.new, remote: true do |form| %>
  ...
  <%= form.submit "Send message" %>
<% end %>

2) Server creates the model object.

class MessagesController < ActionController::Base
  def create
    @message = @project.messages.create!(message_params)

    respond_to do |format|
      format.html { redirect_to @message } # no js fallback
      format.js   # just renders messages/create.js.erb
    end
  end
end

3) Server generates a JavaScript response with the HTML embedded.

<%# renders messages/_message.html.erb %>
$('#messages').prepend('<%=j render @message %>');
$('#<%= dom_id @message %>').highlight();

最后一步反应是由 form_for 生成的 XMLHttpRequest-powered 自动处理，视图更新新消息，新消息通过 JS / CSS 动画实现高亮效果。

超越 RJS

当我们第一次开始使用 SJR 时，我们使用一种叫 RJS 的编译器，它允许你用 Ruby 编写模板，并转换成 JavaScript。RJS 是一个屌丝版本的 CoffeeScript 你也可以了解一下 Opalr, RJS 让许多人离开了 SJR 模式。

现在我们不再使用 RJS, 但是我们仍然坚定的推荐 SJR。

这并不意味着由服务器端生成 JSON 然后由客户端生成 views 的情况不再需要。如下场景我们会用到这个模式：UI 保真度非常高并且大量的视图状态需要维护。例如日历。当你遇到这个情况时，我们建议使用 Eco template system(think ERB for CoffeeScript)

如果你的 web application 全都是 high-fidelity UI, 它完全合适这种路线。当然自己选择的路跪着也要走完！爷们不哭，站起来撸。但是如果你的程序更像 Basecamp 或者 Github 或者绝大多数基于文档的 web 站点，那么你真的应该使用 SJR。

最后，DHH 大大认为 Russian Doll-caching, Turbolinks 和 SJR。绝对是一个牛 X 的技术组合，能够让你高大强的为 web 应用写出漂亮的代码。颤抖吧凡人。

简单翻译了一下，同学们有发现翻错漏的麻烦 @ 我一下

基本都不行了，下行短信需要审核，上行短信丢失率奇高。我们跟 #2 楼的方案基本一样。

想想还有点小期待呢。。。要去

#4 楼 @winnie 这个插件去了之后，速度明显好转。但是因为评论消息的表字段较多，复杂查询较多，增加了索引，后来还做了其他的优化，效果还不错

#2 楼 @zangcw 当时我也没想那么多，做了个回复功能，可以多级回复（可以给回复添加回复）。做完项目就回去修行，半年后回来一看，同事们说已经挺不住了，每个月新增几十万数据，撑到百万级别的时候就慢的不行，只好去掉了

#5 楼 @seveniruby 谢谢，非常好的资料

个人真实的使用经验，超过 100 万条数据，直接崩了，随便搞点啥就是慢查询，只好把它又去掉了

#26 楼 @felixding 那我把邮件删除了

#23 楼 @felixding 这里是一个交流技术的论坛，恰当的使用 MarkDown 语法和 在单词前后加空格 这些排版技术，可以方便大家阅读。

如果你觉得我刚才的回复伤害了你，属于对你的人身攻击，那我在这里对你郑重的说一句 对不起 。我本人是有宗教信仰的，最怕伤害别人。你若觉得我的道歉不够真诚，我的邮件是 ***@gmail.com 把你的电话用邮件发给我。我打电话道歉。

#13 楼 @felixding #14 楼 @lgn21st #10 楼 @huacnlee

管理员只是把 1+1=2 改成 1 + 1 = 2 又不是改成 1+1=3。论坛的初衷是方便大家讨论，交流 Ruby 相关技术。改成空格便于大家更好的阅读，不是挺好的吗？

如果这也觉得自己的权利被侵犯，那是管理员的攻击力太高，还是自己的防御力太弱呢？

haml

#9 楼 @twm 多态

如果 MySQL 也不太熟悉的话，那我也建议用 Postgresql 理由和 #3 楼 @winnie 一样

@winhong 别误会，我想 @adu 的意思是：这么高的要求，这么低的薪水。真的没有开玩笑吗？

还是重新靠谱点

好像错过了什么重要的东西

脚扭过的同学用跑步机就知道，那玩意脚着地的时候不太符合人体结构容易旧伤复发。