不客气。要是这么做的话，别忘了 robots.txt 也要设置不允许访问图片，或者某个目录下的图片。

看了你的场景，这些 images 肯定不能放在 assets 里面，因为它们本来就不是 assets，而是用户上传的文件。应该放在 uploads 或类似文件夹下，就像@meeasyhappy 说的。

对于这个场景，我觉得可以这么处理：

1. 网站本身的图片也不放在 assets 里面，而是另起目录。因为这些图片在这里严格来说已经不是 assets 了，而是数据，需要在数据库里面有记录。而且作为 assets 可能比较多，compile 很费时间。
2. 用户 A 修改 1.jpg 后，生成一个带 token 的文件名。这个文件可以外部访问，但基本不可能拿到 url, 除非用户 A 主动分享。同时数据库存入这个文件名。user_a.images << complex_token.jpg
3. 用户 A 在界面上可以看到他修改的文件。这个很简单，数据库取文件名即可。

@wcc526 这种场景好像不多见，能具体描述一下吗

那没有选中的 2 是不是也没有问题？既然都没有问题了，那问题是什么？ ：）

你新建的时候没有选中 2，但修改里面有 2，说明新建时其实是存错了。把 controller 也贴出来吧。另外那些价格不知道哪里来的？没见你存价格？

{<img src="https://badge.fury.io/rb/cancancan.png" alt="Gem Version" />}[http://badge.fury.io/rb/cancancan]
{<img src="https://travis-ci.org/CanCanCommunity/cancancan.png?branch=master" alt="Build Status" />}[https://travis-ci.org/CanCanCommunity/cancancan]
{<img src="https://codeclimate.com/github/CanCanCommunity/cancancan.png" />}[https://codeclimate.com/github/CanCanCommunity/cancancan]
{<img src="http://inch-ci.org/github/CanCanCommunity/cancancan.png" alt="Inline docs" />}[http://inch-ci.org/github/CanCanCommunity/cancancan]

Travis, CodeClimate 这些都是对开源免费的。你注册一个帐号，加入开源项目。设定流程，然后加入生成 badge 链接就可以了。比如这个： http://docs.travis-ci.com/user/status-images/

图片不是太多且变动不大可以直接放在 repo 里面，做 binary 存储。

不熟 jeklly, 不过这种应该是预制好的 html 或者是依赖 cache 吧，处理速度慢有什么好害怕的。

肯定是查询出来就封装 json 效率高了，至少要给出一部分比如一页的数据。要前端自己去多次请求，每次要耗一个网络请求，加多一个网络延时，后端又要多开一个进程，前端也显得慢。

去掉 js 的不知道这样行不行

document.original_write = document.write;

document.write = function(args) {}
  // stop it if contains flash logic;
  document.original_write(args);
;

@zacker330 不是的，按你的代码的原意，是这样

def initialize(name)
  @name = name
  @block = yield if yield
end

不过，这种直接定义@block的方式很少见，至少我是没有见过。

这里的&特指 block, 意思是这个参数是一个 block。其实也可以省略，在内部用 yield 代表。这种明着说出来的表达方式会好一点。

另外注意 initialize 里面直接把 block 参数做成了一个 instance variable。它本质上是一个 proc，所以调用时要加call。

用法

# 注意这里带了一个block         
tax = TaxCalculater.new('foo') do |amount|
           amount * 0.1
         end

tax.get_tax(100)
#=> "foo on 100 = 10"
#问题中有笔误， @name没有加{}

@wcc526 当然也可以不用 git，但那样的话每次都要全部文件上传。耗时也多，中途掉线也麻烦。

Windows 各种坑，解决了这个还有那个，无穷无尽。用 Ubuntu 或者 Mac 吧。

用 git 来确定更改的文件，这个是必需的。

不一定是 github 的地址，任何 git 地址都可以，托管的，远程主机里面的，或者本地的都行。不想用 github 收费的，你可以用 bitbucket，可以有好几个私有 repo。

@wcc526 我看了一下我的那个本地文件夹，核心逻辑和密码什么的都在 nodes/里面，都 ignore 了 :)。你可以看看这个https://github.com/TalkingQuickly/rails-server-template 我基本是照这个改的。

实在有困难就先手动吧，这个东西就像@blacktulip 说的也是个锦上添花，不是必要的。

我做过类似的，就是游客登录。

我的方法不是直接赋予用户，而是等待游客做出某个动作才赋予。这样既达到效果也比较节省数据库资源。

打个比方，比如你的 app 类似 ruby-china，然后要给予访客发评论的权利，可以这样：

1. 访客来时自动在内存生成用户名，基于时间戳和随机数，这样就基本不会重复。

2. 在 comment 提交按钮旁提示，"you are not signed in, post comment as user12345"

3. 如果提交了，可以 spam checking(后台 job 也可，此处省略)，然后创建用户，自己赋予用户名和密码。用户名表单里面就有。

你说的 token 也可以实现，只要用户保存了带 token 的链接就行了。认证时做个 fall back, 如果没有 cookie 就从 token 里面认证。

@wcc526 流程写出来好多。你可以看看那本部署之道的书。也不是很陡，掌握概念就行了，无非是流程自动化。然后大量使用 DSL

我的做法大致是这样：

1. 某 app 第一次部署先设定 staging, 可以是本地 vagrant 或者在线的。然后以下均基于 staging，除非特别声明。

2. chef 文件单独做 git。然后设好所有选项。

3. 安装 chef 到服务器。knife prepare

4. cap deploy staging

这样基本就好了，人工看看大致没有问题就 cook 到 production, 以及 cap deploy production

修改服务器设置的时候改本地 chef git，然后 cook。不需要动 capistrano 就不动。

多个应用就用 Chef 或 Puppet，需要单独作为一个应用。

单个 VPS 可以用 Chef solo 和 Knife。我用过 chef solo。第一次麻烦点，以后很好用。

@pynix 都是用 JSON API 啊，有什么好奇怪的。

@2033391318 你说的是前端效果吧，那个和 ruby 无关，用 JS 的。

没错，没有经过初始化，config 变量里面没有这个东西，所以关联建立不起来的。

@iBachue ，我觉得，比较多的场景是有一个项目 A 是先大致成熟的，然后其他项目 B，C，D 等才会考虑共享数据库或 API，根据 A 的情况，大致有以下几种场景：

一、A 是打算不久后被替代的老项目。

这种情况我觉得共享数据库比较合适。A 可以暂停开发，只解决 bugs。开发精力放到新项目。API 也可以滞后甚至不需要。

二、A 是在用的项目，并且期待继续发展。

这种情况我觉得共享数据库就不合适了。而且也不需要立刻设计一套完整的 API 系统才能做新项目。可以根据 B，C 的需求先在 A 里面加上必需的 API 以及内部路由。需要什么就开发什么。等成熟后再考虑是否迁出 A 里面部分或全部的 API，或者不迁也可以。

三、A，B，C 都是新的，同时设计的

这种情况我觉得根据需要可以直接从头开始设计一些独立的服务，比如用户、通知等等。让 A，B，C 等消费。

@iBachue 谢谢你的探讨，我也加多了很多理解。

@iBachue 如果大量依靠 SQL 语言来写应用，那真没必要用 Rails 或其他类似框架了，直接 PHP 加一个 template engine 就可以搞定需求了，速度还快。

还有一个情景。假设有个需求变更，需要更改或加减某些 attributes。如果用 API 的话，作为维护 API 的人，我可以轻松做一个 version，或者看实际情况用 ruby 写出向下兼容的 API。但如果是共享数据库呢？谁可以决定？需不需要所有 team members 一起开个会看看怎么改 db?

before_save :set_price

def set_price
  self.price ||= 0
end

@iBachue ActiveRecord 好不容易把这些东西从数据库里拿出来，做到简单易用可扩展可移植少依赖。你倒好，又费同样的劲全给放回去了。

@hiveer 再次不客气。那个 relish 链接里面有两个测试是我交的 PR, 所以比较熟一点，嘿嘿。

@iBachue 共用数据库可能比共用 models 的问题只多不少。

问题一：validation

举个例子，假设现在好几个类似 redmine 的 rails app 同时跑在一个数据库上。其中有一个表是 issues，一个 app 要求 issue 必须 50 个字，一个只要求 20 个字。因为是不同 team 在维护 models，这个很可能出现。那么好了，一个 app 写入了 20 个字的 issue, 完全没有问题。另一个 50 字的 app 可以读到这个 issue, 但当用户要修改它时，bingo! invalid! 怎么办？

问题二：数据一致性

假设 app1 的 User model 会有一个 callback, 自动把用户名变成小写并存入。但 app2 没有这个，那么存入数据库的用户名就会有大有小，造成不一致及各种麻烦。

共用数据库的情景下这些问题的唯一解决方法就是 team 之间互相沟通（指责？），但没有任何代码和机制保证不会出问题。

@hiveer 不客气。其实你第一段测试里面的路由也是有问题的，get, post 是达不到的。只是你的 examples 根本没有通过路由，所以看不出来。