对，跟你定义的变量 value 没有任何关系

把 value = 5 这一行去掉就好理解了

写错了，fn = method(:appendX)

也有被动的情况，比如对接方文档在先，并且规定只能用 POST 和 GET 动作。此时就应该完全放弃 RESTful，重新定义一个标准。如果继续强求 RESTful，无法实现的接口再绕个弯（删除，修改操作用 collection）之类的，可能更会把接口定的不伦不类的。

好像都是顶的人，为啥没人指出"一年半以内完成Ruby转golang的开发"这个啊，是招过去之后要全部转岗吗

我对待这类异常的做法是直接从根源上处理，该捕获的直接捕获。虽然搞懂这些一个个异常比较麻烦，但是可以一劳永逸，且写成 lib 共享后，其他项目也可以不再受这些烦恼。

例如简单的有刷接口，访问不存在路径的异常（线上不会报，但是日志会记录一大堆异常堆栈），可以在路由最下方使用 match 匹配所有路径的处理方式。另外像麻烦一点的有 Rack 层的参数解析异常，别人非得设置 json headers 然后在用一串非的 json 格式的参数数据请求你接口，这时候可以 加上中间件拦截 这类明显不正常的请求。

去掉这个就行：

def default_url_options
  {locale: I18n.locale}
end

感觉异步更新索引不传递 record，而是在回调里构建好 elasticsearch 需要的数据传到 job 更好一点，可以很好的实现回调时 record 的状态和执行 job 时 record 的状态统一，避免了上述执行任务时记录已经不存在（或不统一）的情况：

# app/models/concerns/searchable.rb
after_destroy_commit do
  SearchIndexerJob.perform_later('delete', self.class.index_name, self.class.document_type, id)
end

# app/jobs/search_indexer_job.rb
def perform(operation, index, type, id, body = nil)
  client = Elasticsearch::Model.client
  case operation
  when 'delete'
    client.delete(index: index, type: type, id: id)
  end
end

关于软删除的问题，可以在软删除中添加 commit 回调，使得软删除和删除行为一致，然后就可以像上述一样当成普通删除处理了：

# app/models/concerns/soft_delete.rb
def destroy
  transaction do
    # 添加 destroy 回调
    run_callbacks(:destroy) do
      # 添加 transaction 的 commit 回调
      self.class.connection.add_transaction_record(self)
      # 给 commit 回调添加条件(on: :destroy)
      @_trigger_destroy_callback = if persisted?
                                     # 此处逻辑修改
                                     time = Time.zone.now
                                     update_columns(deleted_at: time, updated_at: time)
                                   else
                                     true
                                   end
      @destroyed = true
      freeze
    end
  end
end

上述代码都是在 Rails 5.2 的环境下测试的，其他版本细节可能会有所不同

原来 article 的时候，你是都保持一致，但是换成 example 时，你还有个地方没换啊

controller 里的 '@article' 要跟 form_for 里的 ':example' 对上，参数就是从这里传过去的