1. 性能比 Discourse 好（因为某些实现比 Discourse 更简单），配置只是推荐方式
2. 有，Ruby China 页脚的 API
3. 有 RateLimit 机制，可配置，相见配置配置部分

simple_form 卡住了 upgrade

关联更新内容：

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

... 我才看到上面的错误。我一直以为是 Like 的问题...

你为何不将数据库字段改为小写，或设置数据库忽略大小写？ PostgreSQL 默认大小写敏感，不建议这么做。

另外，试试

Trap.where("`resourceId` LIKE ? AND `resourceType` LIKE ?", "%#{query1}%", "%#{query2}%")
Trap.where('"resourceId" LIKE ? AND "resourceType" LIKE ?', "%#{query1}%", "%#{query2}%")

Trap.where("resourceId LIKE ? AND resourceType LIKE ?", "%#{query1}%", "%#{query2}%")

你老大既然提这个思路，那他应该有具体的实现方案，指导你来实现。

或者你这些想法可以整理整理好，和他讨论看看是否可行。

其实用 Engine 来搞弊端挺多的：

• 难于测试，因为 Engine 里面有可能需要项目的功能（如果你要用来拆分业务的话）；
• 联调困难，需要多个项目一起协调；
• Migration 分散不利于统一管理；

如果没有特别的必要原因，最好不要那么做。

我一直认为 Engine 只适合于一些特有的公共基础功能，而不是业务。

你用 <font> Tag 的问题：

https://developer.mozilla.org/en-US/docs/Web/HTML/Element/font

试试不就知道了

会往下执行的，除非有 return

分享的想法很好，社区需要这样的文章，就是这排版要好好整理整理

大量的图、大量的代码不一定是好事情！

当你发现确实是问题的时候，你可以提 Issue，或提 PR 修正

https://github.com/stefankroes/ancestry

好使，这样就可以 Hash 省略 {} 了

概念混淆了

用 jQuery 或其它框架，和前后端是否分离没关系

Rolling restart

app, app_backup 两组 Container

Nginx proxy 将 app 优先级提高，fallback 到 app_backup

部署重启的时候先重启 app，断掉的时候会自动切到 app_backup

等 app 启动好以后再重启 app_backup

都用两个空格，你要用 4 个

这是病 得治

已修复，并上线

一堆人中标

手动

你 60G 的数据，有多少条记录？

你要考虑下面的问题：

• 有没有老的 API 什么的需要向下兼容的？
• 有没有足够的人一起干这个事情？
• 如果有老功能，老 API 需要兼容，是否有测试团队帮你验证？
• 有没有足够能力确保新做一次，比之前好很多，让老板支持？因为这个周期比较长。
• 等你开发完升级上线的时候，需要做数据迁移，你有没有能力在不停机，或短时间停机快速迁移完成？

关于老数据迁移

反正这种大量数据（上百万条）迁移，你要想当然的用 Rails 来写，走 ActiveRecord 的流程是很慢的（因为有各种验证、Callback ... 等等和迁移无关的动作），不适合大量迁移。

要大量迁移，得写成并发执行（Ruby 也写成可以并发执行的），最好是批量原生 SQL 插入，避免无谓的动作降低速度。

量更大的时候，你可能需要分布式，例如 (Hadoop 集群）的方式来执行迁移动作，不仅是并发，还多机器并发。

你还得考虑迁移过程中断（例如开发环境验证没遇到的奇怪数据）以后能增量迁移的问题，这样可以在升级前先把存量的老数据前迁移到新的库里面。等到最终测试完成，要上线的时候再增量跑一次后面新增的少量数据（这样能减少停机时间），完成以后一次切换掉。

不懂别乱说，数据量和框架有毛关系！

http://api.rubyonrails.org/classes/ActionController/Parameters.html

你不可能靠里面自己的物理服务器来做这件事的。

最大的问题是你们的服务器带宽，例如 Ruby China 只有 5M。

5M 的概念等于同一时刻最大传输只能 5M。

上面思路都已经有了，核心就是这个量的上传文件，文件不应该经过应用服务器（不管是 Puma 还是 Nginx），否则你的应用服务器的正常功能会受到这写文件上传影响。

当然，Nginx 这样的异步 IO 没问题，但 Ruby 的应用服务器是同步 IO 的，意味着上传过程会堵塞，直到上传结束。

如果你们确实无法使用云存储服务，必须用自己的物理机来存储这些上传文件，那你可以考虑把上传服务独立部署，和应用服务器分开。

前提是服务器带宽（用户端 -> 你们的上传服务器）得够大。那种 5M 的带宽的云服务器你就别想搞了。

可以做大小限制的一般云服务都有这样的参数支持

直接从客户端提交到云服务哪里，不要经过应用服务器

http://docs.upyun.com/api/form_api/

如果你可以使用 Rails 5.2 的话，可以尝试用 Active Storage，我实现的 activestorage-aliyun 已经支持直接从客户端上传文件到阿里云 OSS 了。

详见 http://edgeguides.rubyonrails.org/active_storage_overview.html#direct-uploads

然后 Carrierwave 也有 direct upload 的插件 https://github.com/dwilkie/carrierwave_direct

你要用 sudo service mongod start 的方式启动，然后看那个日志文件。

这个明显是权限的问题，你直接执行 mongod --config /etc/mongod.conf 没问题，不代表 sudo service mongod start 也没问题，两种执行方式权限是不一样的。

看我第二句...

直接执行 mongod --config /etc/mongod.conf 看错误日志

如果配置里面错误日志没有直接输出，请阅读 /etc/mongod.conf 找到日志文件，就可以找到错误原因。

先用于段时间看看

而实际上 Ryan 后面 Mention::EavesdropForMentions 的例子，人家 Basecamp 也在用的：

我认为有点过度解读了！

Callback 仅仅是一个辅助方式，让你可以在通过 Concern 的方式剥离各种各样复杂业务的时候，能将他们（各种 Concern 实现和基础 Model）组织起来，也可以給 Model 设定必要的基础处理流程。

Callback 被许多人看作是“Callback Hole”，我觉得是理解不够，或者是没有足够的把握好尺度！ 这也是理解不够，组织不好（当前也包括我早些时候的一些项目实现，例如 Quora）。

preload 不影响这个，搞出来的都是局部变量

preload 是 copy on write 在有改变全局变量的时候，copy 到 worker 里面，否则和 master 共享在启动是载入的内容