内容很详细，先赞一个

BUT 说不出来为啥，感觉有点乱，牵扯了略多和 cap 不是强关联的内容，如果打算做 wiki 的话建议再精简一下

另：一图胜千言，如果能把 cap 的部署流程画一画，也许不需要码这么多字，贴这么多截图（个人感觉）

在 Web 场景下使用可能不多，但是在做一些小工具时还是可能会用到

看了你这篇文章后，知道可以放心大胆的用原生切日志，心里还是爽爽的

看一下 gems/railties-5.2.0/lib/rails/generators/rails/app/templates 里面有没有 README.md.tt 这个文件

https://github.com/mperham/sidekiq/wiki/Error-Handling#automatic-job-retry

这个章节里面有个小三角，点开可以看到一组数据，应该可以解答你的疑问

首先明确一点，重试机制是用来给你『亡羊补牢』的，当你线上遇到 bug 时，让你有机会去修复它，它不是定时任务，不会去关心时间间隔是否严格

以任务开始时间来计算可不可以？可以，但是会增加很多不必要的麻烦，比如：

1. 需要记录并读取任务开始执行的时间
2. 计算出重试时间后，已经是一个过去的时间了，此时该跳过还是马上塞回队列呢？
3. sidekiq 的 Scheduled Job 本身也不能保证一个任务是严格的按时执行的，因为队列还可能在排队

所以，我的结论是：

Sidekiq 的设计没毛病，而且很合理。

至于『导致追溯问题时间不精确』，为什么你要用时间去追溯问题？如果有两个基本完全相同的任务在交错的打 log 呢？如果有 1000 个这样的任务在打 log 呢？

当然，如果你是处女座或者患有不对齐会死强迫征，啊哈，那也有办法~

你可以在这个 job 上禁用掉 sidekiq 的重试，然后自己写个定时任务去检测任务执行情况，遇到出错的就立马重跑，记得是重跑，不是塞入队列，因为队列还可能在排队

取绝对路径用

Rails.root.join('public', 'plans', @plan.file)

线上进 console RAILS_ENV=production bin/rails c

Dir.entries("public/plans").grep(@plan.file) 

看看输出啥

建议直接到线上的 console 里面调试一下，排除下是不是权限问题什么的

看上去就是你在 ActiveJob 操作里面使用了异步任务 send_file？是这样么？

看报错是 文件没找到啊，你的生产环境上真的有这个文件么？

在 csdn 写博客？汪汪汪？

服务器上的 ruby 是怎么装的？rvm 还是 rbenv

https://github.com/capistrano/rvm

https://github.com/capistrano/rbenv

rails 在编译静态资源的时候会预生成 gzip 格式的资源文件，在 nginx 简单配置一下就可以直接使用，不需要 nginx 来压缩，节约 cpu 资源，加快响应速度

执行 rake assets:precompile 没有生成 .gz 的资源包么？

干。。。打脸了，突然想起还有个多行版本

h = Hash.new(0); arr.each{ |(k, v)| h[k] += v.to_i }; h

事实证明这个更快

文章在这里，还好我有 Pocket，还能找出来

http://stackoverflow.com/questions/3230863/ruby-rails-inject-on-hashes-good-style

朱老师 666，居然拿出了 benchmark

B 大说过：『成功人士才跑 benchmark』，我等屌丝写代码就是一把梭，哈哈哈~~~

记得之前看过的文章提过：

1. 下标操作比 merge、update 等操作快
2. each 应该是这些个枚举方法里面最快的，毕竟被用得最多

所以，@luikore 的应该是所有解法里面最快的（没有之一），我想不出还能怎么更快了，不服的同学可以再战！！

PS：（这个和主题无关，只是因为我喜欢 inject）虽然下标操作更快，但是在 inject 里面最好还是使用 merge、update，因为 inject 以 block 的最后一行作为返回值，用下标操作你就需要在最后一行显示的返回修改后的 hash，会拖得更慢，当然这时还不如直接用 each_with_object 好了

朱老师 你居然来逛社区了，工作量不饱和啊

当然不对了，单引号和双引号能一样么

建议还是花点时间熟悉一下正则吧，以后要用的地方太多了

https://www.rubydoc.info/github/sparklemotion/nokogiri/Nokogiri/XML/Searchable#css-instance_method

#css 就是一个元素选择器，class 的空格本来就是有意义的

Nokogiri::HTML(str).css('.eee.-fff_ggg').inner_html

如果是因为换行等其他原因意外引入的空格，且你确保那儿只有一个 class 的时候，可以先对 str 进行一点处理

str.gsub(/class=\".+?\"/) { |m| m.sub(' ', '') }

class Singleton
  # 这个 count 准确的说是『类的实例变量』，因为 Singleton 这个类本身也是 Class 这个的父类的一个实例
  # 它的行为更接近类变量，用来储存类的一些状态
  # 区别是它不能在类的实例里面直接被调用（当然你可以再给它定义一个 getter/setter）
  @count = 0

  def initialize
    # 这才是我们通常意识里面的实例变量
    # 并不存在于类中，也不能在类里面声明或调用
    # 只在类的实例里面使用
    # 当然，你也可以在任何一个实例方法里面去声明或这修改它
    # attr_read、attr_write、attr_accessor 声明的也是这种的
    @count = 0
  end
end

这两个 count 其实不是同一个东西

class Singleton
  @@uniqueInstance = nil

  def self.instance
    unless @@uniqueInstance
      @@uniqueInstance = new
    end
    @@uniqueInstance
  end

  def initialize
    @count = 0
  end

  def plus
    @count += 1
  end

  private_class_method :new
end

并没有什么误解，只是故意抬一下杠

如果在一个多人协作的项目中看到一段代码洋洋洒洒 7、8 行，做的事情就是拼一个 hash，而且很有可能是一些 Hash/Array 的现有方法可以很容易完成的内容，一方面还是会觉得不够简洁，另一方面也就或多或少的体现了写代码的人对这些内部 API 不够熟悉吧

所以我才会在一开始就给了一个看似另类的解法，用了两个看上去不常用但其实很有用的方法，我是希望 LZ 能看了自己去查查 API，或许他这一查就查出新大陆呢，哈哈哈~~

写成一个表达式还有一个好处是可以接着链式调用去做其他处理，在我的印象里好像挺多人喜欢这么干的，虽然有时候确实会牺牲一些可读性

Anyway，开心就好

思维够敏捷呀 感觉这个都可以拿去当面试题了

纳尼？陈独秀你坐下，我李大钊表示不服

他有两行，而且 each 相当于没有返回值，接下来的操作还要调用 h 才能取结果，也就是三行

我的才一行，返回值就是结果，除非他改用 inject，不然我不会承认是在下输了

哈哈哈哈～

arr = [["小黄", "2000"], ["小猪", "2500"], ["小猪", "2500"], ["小黄", "1500"]]
arr.group_by(&:first).transform_values { |v| v.sum { |_, v| v.to_i } }

答案给你，不过这个要 2.4 以后的 ruby 才能这么用

至于他是怎么工作的，还是期待你自己解读一下

确实以后打包可以考虑 alpine 了，现在做得还真不错，挺惊喜的

试了一下用 ruby:2.5.1-alpine 跑一个普通的 rails 应用，除了 therubyracer 不能用（用 nodejs 代替）以外，其他几乎无感，所以整体感觉还行

不过当你把一个 Rails 塞进镜像以后，会发现镜像包比直接用 ruby:2.5.1-slim 打的也没小多少

之前忘了删除编译时依赖的包，删了之后发现还是小很多的

内存占用到是基本没差别（我只是简单的测试，大流量下讲道理应该也不会差很多）

噫，为什么内存占用会小？

咦~ 是么，这就不知道了

我记得我当时要做一个 Sidekiq 监控聚合，本来觉得这个有什么难的，秒秒钟的事儿。然后就发现他们把 sinatra 干掉了…干掉了……基于原生 Rack 重写了。于是我又花了几天研究 Rack 直接写应用，从此开启了一条不归路，同事要写个什么小东西，我就会跑过去丢一句：这个用什么 Rails，来跟我写 Rack 吧

不看文档先干活踩坑系列 +1

【毕竟所有干活快的方法，都已经写在文档里了】