#24 楼 @bunnysyz 有女款的

没必要，需要的场景用一下就好了

#41 楼 @lilijreey 200 多包两顿午饭，外加 T 恤，等于是白送了

#1 楼 @Rei

看 Rails Guides 啊

http://guides.ruby-china.org/security.html#csrf-%E7%9A%84%E5%AF%B9%E7%AD%96

深圳南山区 - 这是腾讯么

为何要用 form_for，看看我 4 年前发的一个小技巧：

https://ruby-china.org/topics/4972

所以，不是那些东西不好用，而是你目前需要做的事情太初浅，你理解不到这些东西存在的价值。

simple_form 则是更上层的东西，它能帮你统一解决：

• Label 的名称
• 每行表单的统一格式（实际每个项目绝大多数表单结构都是一样的），同时利用统一调整表单结构
• I18n 管理方式的 Placeholder 和 说明文字（hint）
• 更简单的使用方式，绝大多数情况只需要一行，例如 f.input :name
• 在你不需要的时候，你还可以混写 Rails 默认的 form 写法或 HTML 写法
• 突然有天要从左右布局（Label 左、文本框右），变成上下布局

例如 GitHub 个人设置这个场景 https://github.com/settings/profile，用 simple_form 能让整个网站有一个非常固定、稳定、不会因为有个别人漏写了几个标签或 class 导致样式不统一的问题。

当然，simple_form 不是适用于所有的场景，如果你的项目表单结构总是不固定的（我认为这是设计有问题！），你不需要它。

浮躁，英文不好就怪工具么

用 Aliyun OSS 好了，权限控制都有的，将 OSS Bucket 设成 private 空间，上传用 carrierwave-aliyun 来管理，每次浏览生成出来的下载地址是有有效期的鉴权地址。

https://github.com/huacnlee/carrierwave-aliyun

把你的网站地址给出来

#1 楼 @mimosa 关 Turbolinks 什么事？

尝试杀掉 spring 进程

puts 党

使用进程外的内存作为交换器，例如 Memcached, Redis 等

他们都是 Atomic（原子性操作，也就是你想要的锁机制）或有 Atomic 的功能：

• https://github.com/memcached/memcached/wiki/ProgrammingFAQ#is-memcached-atomic
• http://redis.io/commands/INCR
• http://redis.io/topics/transactions

然后，Redis 是可以持久化的，你还可以用 redis-objects 更简单的使用。

这个是因为 RVM 在 Ubuntu 下面尝试用 Travis CI 打包好的二进制安装包来安装，而 https://cache.ruby-china.org 没有提供哪个。

请用这样的方式安装：

$ rvm install 2.3.0 --disable-binary

希望你能坚持活下去

http://benchmarksgame.alioth.debian.org/u64q/ruby.html

看看 Rails MVC 里用来打造 View 的模版。在默认情况下，这些 Helper 允许我们从 View 抽取出代码，抽出来不过是一堆函数！这些函数甚至存在于同一个 Namespace 下面。噢，惊讶了吗？感到恐惧了吗？正是像 PHP 那样呢！ 但我认为 PHP 在单一函数之间，很少需要互动这点上事对的，就像 View 有着许多的抽象一样。根据这个目的，单一的 Namespace，一堆的方法，这不只是个合理的决定，还是很棒的决定。 - The Rails Doctrine

https://ruby-china.org/wiki/the-rails-doctrine#多元化的设计模式

不！要！用！Windows！不！要！用！Aptana！

你的问题，那是你的问题，因为你环境才有这样的问题！你不愿意尝试换环境，那就不要浪费大家时间。

0o1l 已经去掉了的，小写是为了让字母 i 容易识别，实际上据我观察来看，小写字母更容易辨识

https://github.com/huacnlee/rucaptcha/blob/master/lib/rucaptcha/captcha.rb#L23

MySQL 主键、基于索引的查询，哪怕几百万的数据，也是非常快的。

不要听传言说 Redis 快、MongoDB 快就去用那些东西，前提还是你懂他们不？你知道他们适用的场景不？

飞机比汽车快，但你会开么？以及飞机能在城里开么？

前面都说了，要看场景选择合适的方案。至于怎么知道什么适合你，你需要去了解这些东西（MySQL、Redis ...）它们适用于什么场景，优缺点是什么。

你的第二句我没看懂...

应用层只有一个 Model，以照片应用为例（实际上我们就是照片应用）

Photo 表，背后是 photos_1 - photos_1024，但 Model 只有一个，查询在 Rails 输出的时候还是：

select * from photos where user_id = ?

但到了 MySQL Proxy 层（阿里内部的非开源系统），将会分析这条 SQL，找到 user_id 关键字，并基于之前的分库分表设计，将 photos 换成 photos_(n)，最后再往后面的 MySQL 发送请求。

但这样做有局限性，无法跨表查询或跨表查询会相对较慢，例如这样的语句场景会有问题（同时查询 user_id in (1, 2, 3))，1, 2, 3 的用户的 Photo 可能分布在不同的 photos_(n) 表里面，Proxy 需要分别查询最后再组合在一块儿，所以很多的实现都需要避开这样的问题。

所以，根据实际业务场景，选择合适的分表字段是很重要的！例如订单的场景，绝大多数场景一定都是自己看自己的订单，所以基于 user_id 拆分表是可行的。同理，Timeline，Notification 也是可以的。

以上都是理论，实际执行的时候比较复杂。并且，核心点还是你需要中间层的分库框架。

#10 楼 @happyming9527 你还没有回答我的第一个问题！

#9 楼 @hww 此外，直接用 Serialization 的方式可能还有问题，目前那些 Array 字段合理的设计应该改成多对多关系

#9 楼 @hww 我知道，但不想折腾了

Gemfile 里面 source 是 ruby.taobao.org 吧