你的需求是需要记录每一次点击，才能统计出来

如果没那个实力存储和维护这么多点击数据，你可以用 Google 分析之类的三方工具

可能是验证的 Bug，我看看

结合昨天凌晨和今天凌晨的问题分析了一下，怀疑是服务器内部的备份动作导致的，出现问题的时间点（4:00）和备份点切合，今天关掉，晚上看看是否还会出现。

但从 UCloud 的流量统计图上来看还有入口流量，备份应该都是出口流量。

已经联系 UCloud 先给我们恢复，我关掉那个备份动作，观察看看。

楼主一天到晚朝三暮四的寻找替代 Ruby 的语言，怎么可能学得会

不能把 vendor/bundle 加进去，gem 安装的时候和系统有关

你的 Dockerfile 可以改进一下，先 ADD Gemfile Gemfile.lock 进去，然后 bundle install，然后再将源代码 ADD 进去。

这样一来，Gemfile 没改变的时候能利用 Docker build cache 减少重复安装花费的时间

你都要禁用 Assets Pipeline 了，为何还有 stylesheet_link_tag ?

可以忽略它，各种各样的扫描器天天在扫描

我们做文档管理平台的时候，早期正文都是存在主表里面的，后来发现那个表因为大量正文越来越大，而主表又时常因为业务调整，调整结构（加字段、调索引之类），由于表大，DDL 特别困难，后面也是将正文拆成了一个独立的 contents 表。

这样主表只有我 meta 信息，尺寸小了很多。而 contents 表结构固定，设计好以后几乎不会再调整。

另外，查询主表列表，关联查询之类不需要正文的场景也不再需要排除正文字段了。

你在 volume 的地方加上

• public/packs
• tmp/cache

两个路径，这样之前 Webpacker 的编译结果就有缓存可以重复利用了

试试把 tmp/cache 目录设置 Docker Volume

你可以读读 Ruby China 的实现，原理是用户名的 DOM 有标记，@ 的时候取出来去重即可

关键点找出来：

• Upgrade early and upgrade often The closer you are to a new version of Rails, the easier upgrades will be. This encourages your team to fix bugs in Rails instead of monkey-patching the application or reinventing features that exist upstream.
• Keep upgrade infrastructure in place There will always be a new version to upgrade to, so once you’re on a modern version of Rails add a build to run against the master branch. This will catch bugs in Rails and your application early, make upgrades easier, and increase your upstream contributions.
• Upstream your tooling instead of rolling your own The more you push upstream to gems or Rails, the less logic you need in your application. Save your application code for what truly makes your company special (i.e. Pull Requests), instead of tools to make your application run smoothly (i.e. concurrent testing libraries)
• Avoid using private API’s in your frameworks Rails has a lot of code that’s not private but isn’t documented on purpose. That code is subject to change without notice, so writing code that relies on private code can easily break in an upgrade.
• Address technical debt often It’s easy to think “this is working, why mess with it”, but if no one knows how that code works, it can quickly become a bottleneck for upgrades. Try to prevent coupling your application logic too closely to your framework. Ensure that the line where your application ends and your framework begins is clear. You can do this by addressing technical debt before it becomes difficult to remove.
• Do incremental upgrades Each minor version of Rails provides the deprecation warnings for the next version. By upgrading from 3.2 to 4.0, 4.0 to 4.1, etc we were able to identify problems in the next version early and define clear milestones.
• Keep up the momentum Rails upgrades can seem daunting. Create ways in which your team can have quick wins to keep momentum going. Share the responsibility across teams so that everyone is familiar with the new version of the framework and prevent burnout. Once you’re on the newest version add a build to your app that periodically runs your suite against edge Rails so you can catch bugs in your code or your framework early.
• Expect things to break Upgrades are hard and in an application as large as GitHub things are bound to break. While we didn’t take the site down during the upgrade we had issues with CI, local development, slow queries, and other problems that didn’t show up in our CI builds or click testing.

如果无法掌握，用 Docker 的方式安装

你 Docker 理解错了，你不能 docker exec -it 263fc /bin/sh 进去修改文件，修改没有效果的。

上面的修改过程都是没有任何作用的。

homeland/homeland 这个 Docker Image 里面已经处理好权限的，/var/tmp/nginx 这个路径是 app 用户的权限，Nginx 的配置也设定好用 app 用户来执行的。

我刚才用 homeland-docker 拉下来启动验证了一下，上传是没有问题的。

看看 log/nginx-error.log

Docker 打包，用 Docker 来执行

打包 Docker 发布，不需要搞这么多事情了

逻辑拦截，使用要求登陆，登陆要求复杂验证，防止机器登陆

未登陆 Rate Limit 限制

之前是 2M 带宽，现在是 5M

Ruby 2.5

你的项目是不是还依赖了 will_paginate ?

如果是，你可以把 notifications 的分页方式改成 will_paginate 的方式。

不要绕复杂了，你的附件、图片上传直接上传到云存储里面，如 S3、OSS、UpYun 这种，应用服务器不要放文件或数据库。

描述不清楚

go.freessl.dev 看起来是本地部署的，你确定部署对了的？404 可能是：

1. 如果是直接用 Docker 部署的话，应该域名绑定不对；
2. 如果你是手动部署，或者改过 Nginx 那得自己检查一下配置。

我们尊重并支持任何对于 Ruby 社区有贡献的事情。

但因为我们对 @rocLv 不了解，这件事情保持观望态度。

作为一个有意义的 Ruby 社区活动，这件事情我们当然会支持给予置顶，就如同 Ruby Tuesday 活动一样。

有两点我们得声明：

1. Ruby China 没有参与本次活动的组织，望周知。
2. 鉴于之前 Xdite 在 Ruby 社区的负面问题（具体请翻历史），再请她作为讲师不合适。

一直在用这个 App!

保留了一个页面作为公告

https://gems.ruby-china.org

已经过度很久了，依然还有人没切。

gems.ruby-china.org 的跳转之前是放 Ruby China 服务器上的，结果导致大量的请求（RubyGems 服务时常有人全量镜像），严重占用网站的带宽。

所以我不得不将 gems.ruby-china.org 直接停掉了。

Ruby China 首页就有公告，而且已经放了很长一段时间了。

不发邮件，往数据库写，实现管理界面来看

http://github.com/rails-engine/exception-track