我正在构建一个依赖于预定作业的Heroku应用程序.我们之前使用的是Heroku Scheduler,但时钟进程似乎更灵活,更强大.所以现在我们正在使用时钟进程在特定时间/间隔排队后台作业.
Heroku的文档提到,与所有dynos一样,时钟dynos每天至少重启一次 - 这会导致时钟进程跳过预定作业的风险:"由于dynos每天至少重启一次逻辑需要在时钟进程启动时存在,以确保在dyno重启期间不会跳过作业间隔." (参见https://devcenter.heroku.com/articles/scheduled-jobs-custom-clock-processes)
有哪些建议的方法可以确保不会跳过预定的作业,并重新排队错过的任何作业？
一种可能的方法是在作业运行/入队时创建数据库记录,并在时钟作业内定期检查预期记录的存在.最大的缺点是如果时钟dyno存在系统性问题导致它在相当长的一段时间内停机,那么我不能每隔X小时进行一次轮询以确保预定的作业成功运行,因为轮询发生在时钟dyno内.
你是如何处理时钟dyno弹性问题的？
谢谢!
我正在为一个接触多个模型的服务对象编写Rspec测试,但我觉得我的测试过于依赖于方法的内部,因此不是很有意义.这是一个例子:
class MealServicer
def self.serve_meal(meal, customer)
meal.update_attributes(status: "served", customer_id: customer.id)
order = customer.order
OrderServicer.add_meal_to_order(meal, order)
CRM.update_customer_record(customer) // external API call
end
end
我想使用双打/存根来模拟行为而不实际保存任何东西到测试数据库(为了性能).但是如果我创建响应消息的双精度数,那么感觉就像我正在测试serve_meal()方法的一个特定实现,并且这个测试太过耦合到那个特定的实现.例如,我需要确保我的customerdouble响应order并返回一个order存根.基本上,当一切都只是一个双重的时候我必须通过确保双精度返回其他双精度来明确说明所有依赖关系,感觉测试最终变得毫无意义.看这里:
it "has a working serve_meal method" do
meal = double(:meal)
customer = double(:customer)
order = double(:order)
allow(customer).to_receive(:order).and_return(order)
allow(OrderServicer).to_receive(:add_meal_to_order).and_return(true)
allow(CRM).to_receive(:update_customer_record).and_return(true)
expect(meal).to receive(:update_attributes).once
expect(OrderServicer).to receive(:add_meal_to_order).once
expect(CRM).to receive(:update_customer_record).once
end
除了实例化实际的膳食,客户和订单对象(可能保存到数据库)之外,还有其他方法可以彻底而有意义地进行测试,然后检查MealServicer.serve_meal(...)是否将对象属性更新为预期？这将最终保存到数据库,因为update_attributes执行保存调用,因此我打算在我的Service对象方法中包含几个方法.
最后因为测试依赖于实现,我不能在方法之前编写测试,这是TDD倡导者所推荐的.这只是感觉倒退.有关编写高效但有用的测试的建议吗？
Rails 4使用cache_digests(https://github.com/rails/cache_digests)来协助片段缓存失效:cache_digests创建模板的MD5哈希及其所有已知依赖项,允许片段缓存通过在分配新密钥时变为无效模板或其依赖项更改.
我的问题是:stylesheet_link_tag如果application.css文件的MD5哈希在期间发生变化,片段缓存包装是否会失效rake assets:precompile？现在在标题中执行此操作:
<% cache("header-cache-key") do %>
<%= stylesheet_link_tag "application" %>
<%= javascript_include_tag "application" %>
<% end %>
这样安全吗？我担心的是,当CSS或JS发生变化时,application-xxxxxxx.css会变成application-yyyyyyy.css,但我们的标题会被旧的缓存application-xxxxxxx.css.然后如果application-xxxxxxx.css离开public/assets,这将导致一个丑陋的页面.
来自DocuSign"API要求信息":
>[Y]our API certification review involves verifying that you do not exceed 1 status request per unique envelope per 15 minutes for polling compliance for the following methods: ...
>REST API: GET /accounts/{accountId}/envelopes
这是唯一受限的REST端点吗？我是否可以GET /accounts/{accountId}/envelopes/{envelopeId}更频繁地向其他终端(例如:)发出请求？