注意，那个 area.json 需要把台湾补上，不然会有问题，网监会找你麻烦

mini_magick 和 rmagick 的区别是，前者依靠 fork 来外部执行 ImageMagick，后者是引入 ImageMagick 实现 C 扩展，在 Ruby 内部调用。

前者执行效率低，后者容易内存泄露

字体之类的搜索 ImageMagick 的相关解决方法，都是一样的

回帖加精

direct_upload: true 的功能很方便，全交给客户端直接往云服务器上传，避免经过服务器，只需要这么一行：

<%= form.file_field :avatar, direct_upload: true %>

require 'open3'
cmd = 'ping www.google.com'
Open3.popen3(cmd) do |stdin, stdout, stderr, wait_thr|
  while line = stdout.gets
    puts line
  end
end

https://medium.com/zendesk-engineering/running-a-child-process-in-ruby-properly-febd0a2b6ec8

对，这样有好处，可以自由增加各种各样的附件类型，无需调整数据库。

class Post < ApplicationRecord
  has_one_attached :image

  has_one_attached :cover
  has_many_attached :images
  has_many_attached :attachments
end

编写 aliyun-oss 存储实现的时候，顺便尝试了一把 ActiveStorage

与 Rails 结合很紧密，使用起来非常快捷简单，比 CarrierWave 好使很多！

增加了两个表：

• active_storage_attachments - 与业务表的多对多关系
• active_storage_blobs - 附件的 Meta 信息，例如文件名，尺寸 ...

假如我有个 photos 需要存储图片，大概是这样：

class Photo < ApplicationRecord
  has_one_attached :image
end

这里，photos 表将不需要 image 字段，而是依靠 has_one 的关系来关联 active_storage_attachments 表。

这样带来了新的问题，每次列表查询，如果需要头像，需要关联查询。

于是问题来了，这样多余的开销怎么办？

可以依靠 Cache 来解决

class Photo < ApplicationRecord
  has_one_attached :image

  def image_url
    # cache_key 带了 @photo 的 updated_at 信息，所以，每次 Photo 更新的时候，缓存能自动失效
    Rails.cache.fetch(self.cache_key("image_url")) do
        self.image.service_url
    end
  end
end

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

https://evilmartians.com/chronicles/rails-5-2-active-storage-and-beyond

文档很少，总共就 6 节，跟《Getting Real》似的，难道是因为就只有 Element 绑定的功能？

https://rails.guide/book/working_with_javascript_in_rails.html#working-with-javascript-in-rails

阅读这一章

然后又自己搞着搞着搞出了 Rails 那些东西

那个 ./fib 文件有多大？

关于这个报错，可以阅读我这个链接的回复

• https://ruby-china.org/topics/30498#reply-300794
• https://ruby-china.org/topics/15623#reply-300797

把当时你看到那个慢的 SQL 的执行日志（SQL 语句和执行时间）放出来看看

然后你拿那个 SQL 到你线上的 MySQL 里面去 EXPLAIN 看看

你开发环境不出问题，有可能是开发环境数据太少了

贴 config/application.rb 和 config/environments/production.rb 的配置

哦 我看错了，那个不是 Rails Session 的查询

你先把 Session 改为 Cookie 模式，避免用户首次请求就要卡数据库那里，然后再看看会不会卡住

其实反而是有些话，作为社区官方这边不好说，另一方面，这种事情不能单纯用对和错来贴标签，商业本来就是这么一回事情。

况且之前已经有不少过不少对这事儿的讨论了，都是成年人，该说的也有人说过了，能不能去，值不值每个人应该有自我的判断力。

社区只能说保持开放的态度保留不同的看法。

难道非得要什么事情，都要表个态么？

应该是低于 16，并发的时候，1s 的响应速度可能会变成 1.5s

控制台 -> 设置 -> custom_head_html

手写 HTML 代码，例如：

<link rel="icon" href="//l.ruby-china.com/photo/2016/c309db0b49cab85a32f756541ea0e2b0.png" />

<style type="text/css">
// 自定义 CSS
</style>

贴配置

你给个正确的 Email 不就可以了么，username 也是，为何给一个字母 + 数字格式的？

顺带还有一个细节：

number of seconds that a connection will be kept unused in the pool before it is automatically disconnected (default 300 seconds)

大概意思是连接实际上有个超时时间（默认 300s）超时以后会自动释放

如果上面 find_each 的 block 异常了，理论上你们这个代码还存在 Connection 泄漏的问题

def update_entries
  # 查询数据库中的记录
  Entry.find_each do |e|
      # 1. 调用第三方api, 查询记录信息
      # 2.  处理信息
      # 3. 保存
  end
ensure
  ActiveRecord::Base.clear_active_connections!
end

参考非 Rails 的场景：

• https://github.com/huacnlee/sails/blob/7a97e3e7c62a1928a6c919bdb0cefde49e2a8d68/lib/sails/service/interface.rb#L68
• https://github.com/mperham/sidekiq/blob/master/lib/sidekiq/middleware/server/active_record.rb#L17

这个 update_entries 函数可能是一些非 Web 的地方调用的，例如 Rake 命令的批量处理动作。

Rails 是会自动处理数据库连接释放的事情，但 ActiveRecord 不会。

在非 Web 的场景，是需要手动调用 ActiveRecord::Base.clear_active_connections! 的

没上下文，无法回答

还是要看代码具体是干啥了

http://image-agileplus.b0.aicdn.com/user/avatar/1/dafa73.jpg!md

你打开这个链接看看说的啥