我目前还是觉得，assets pipeline 已经干了 require.js 这些前端方案干的事，如果在文件头加注释就可以解决编译问题，那么为什么要在代码里面 require('...') 或者 define('...')，然后再用语法分析器将依赖抽出来呢？

所以我也没怎么考虑要它们融合。实际开发中二选一吧。

#23 楼 @edokeh nodejs 的出现也是想模糊前后端的界限。（哎呀，发现楼上说了）

被 Ruby 社区吐槽之后，Python 社区终于发现并改正了问题，值得表扬。

#21 楼 @darkbaby123 你的看法，又是被 require_tree . 陷进去了。

我未了解 Turbolink 之前，是这样用 pipeline 的。

application.js

//= require jquery
//= reuqire rails_ujs
//= require 其他基础库

topics.js

// topic 页面的代码

编译的时候都独立编译。

pipeline 是一个打包工具，可以按自己想法去用。我是看到了 Turbolink 的好处，才接受把所有 js 打包在一起。

这些工具的目的，都是为了让页面加载更快，Rails 工具链提供了一套方案。相比客户端 MVC，我觉得简单多了。

#110 楼 @Sunnyroger Ruby 用 google，Rails 用 http://apidock.com/

#15 楼 @edokeh 我也是特意看了 basecamp，发现他们依然在用 .js.erb，顿时晴空万里。

新版也就一次性下载，而且有个 hash 文件名，避免了用户端缓存不过期——这才是影响可用性的问题。

#13 楼 @rainchen 奥，明白了。实际用时我放在 $(function() {}) 里面，应该间接避开了

$(function() {
  if( ... ) {
  }
});

#108 楼 @fsword 我看到类比就头疼。

#11 楼 @rainchen 我对 js 了解不深入，.length 会导致全局变量？

#3 楼 @darkbaby123 这两个相互依赖，本来我不喜欢全部 js 打包成一个，看了 Turbolink 的原理之后发现需要全部打包成一个才能发挥作用，然后才 require_tree 了。

#2 楼 @knwang 要一些技巧，相比不用 pipeline 是麻烦点，但是要用 turbolink 就需要尽量打包成一个 js。

有了 pipeline 可以拆成 app/assets/articles/show.js 这么小块的 js 文件，也不用怕文件太多太琐碎，最后都打包成一个。

#4 楼 @edokeh 期待文章。

因为我是先接触 pipeline，然后接触 require.js，所以觉得前端方案挺复杂的，为 js 代码做了很多模块化约定，最终还是要借助服务器预编译。相信如果是纯前端出身，看法会反过来，都会先入为主。

pipeline 的写法，就好像 Ruby 代码，需要什么就先在顶部 require，命名空间不强制。如果用 CoffeeScript 的话，默认所有代码会被包在匿名空间里。模块化就交给开发人员了，pipeline 起一个支撑但不强制的作用。

pipeline 提供了工具但是没有多少文章说明怎么去做，新手掉了不少坑，所以我打算接着写这方面的看法。

#6 楼 @chenge turbolink 之后整站成了个单页应用，意味 js 逻辑不会自动释放，有内存泄漏的可能。

所以写页面逻辑除了要考虑什么时候执行，还要考虑离开的时候释放。所以会有类似代码：

$(document).on 'page:load', ->
  if page is scrollPage   # pseudo code 
    $(window).bind 'scroll', customScrollFunction
    $(document).one 'page:change', ->
      $(window).unbind 'scroll', customScrollFunction

https://github.com/rails/turbolinks/issues/154#issuecomment-11916707

这值得再写一篇文章了，我也是摸索中。

#75 楼 @kevinhua 我记得华顺说过这类用户名就自己承担别人看不到自己资料的后果。

#73 楼 @kevinhua StackOverflow 是有很强的运营力量的，我记得我发的第一个问题，由于新手帐号只能加一个链接，所以我提供的资料里面有两个链接其中一个是纯文本，我发出去后过了一会刷新发现那条纯文本被别人编辑成链接了。

很多设想看着好，如果没有人抽得出时间执行也不行。

提个方案，像 StackOverflow 那样，新手发帖先进入一个发帖指导的页面，打勾下一步才是发帖页。

已发的贴，管理员觉得没有做好功课的，可以移到不显示在主题列表的 notpoint 节点。

广告 spam 是另一个层面了，注册加 captcha，特定的人肉 spam 就加关键词黑名单。

#2 楼 @newnewnew 一般就那样设计，海量之后会各种拆，真到了海量再考虑。

def store_dir
  "upload/#{model.photographic.class.name.downcase}/#{model.photographic_id}"
end

#5 楼 @fredwu 奥，原来可以不带括号啊

.alert class=("alert-#{key}")

#10 楼 @chenge 所以你预设前提是学习者已经懂得管理关系数据库了，我学习的时候虽然学过一些 SQL 知识，但是管理还是外行，所以 Ruby DSL 对我很友好。

我现在要在 MySQL 终端操作的话还是要看着官方文档对着敲，所以我都优先用 migration，console，性能成问题才用 SQL script。

之前一份工作由于 migration 和 schema 没注意维护一致性，新人加进来搭建开发环境没一天都不行，跑通之后就不敢动了只做自己负责的部分。

#7 楼 @chenge 我现在自己弄的项目用的是 Mongodb，没有 migration 这套东西，数据量小有时就备份一下然后控制台操作了。不过这是很不安全的做法，以后还是要找个 mongoid_migration 之类的东西做数据迁移。

Rails 就是大量 Web 开发的经验总结，如果一股脑全接受的话其实还是挺友好的。

我庆幸我学 Rails 的时候是一张白纸，所有 Rails 提供的我都接受了，然后再思考我需要的是什么。

#3 楼 @chenge 如果写脚本的话，migration 就是 Rails 程序员成熟通用的语言。

人工操作，出了问题就不好解释了，谁也不知道你当时操作了什么。