Very nice. I use it on every app nowadays. Throtteling off course, but also to deal with probes:

Rack::Attack.blacklist('block admin probes') do |req|

  # Request are blocked if the return value is truthy

  block = false

  ["php" , "jsp" , "cgi", "asp", "cfm," "proxy.txt", "soapCaller", "Win32" , "HNAP1" , "w00tw00t",

    "pma" , "mysql" ,"msd" , "MySQL" , "jmx-console" , "ervlet" , "xml" , "cart" ,"install"].each do |no|

    block = true if  req.path.include?(no)

  end

  block

end

Thanks, actually for that whole series on sidekiq. Maybe some testing coming up ?

Having deployed the cron, i had to restart the sidekiq service. Off course. 

As you have everything else nicely setup for copy/paste, adding the schedule.yml file would make it even easier for the next guy.

And i must admit that at first hearing i also understood that this was only for use with enterprise edition. Only a bit of checking and listening again cleared that up.

Thanks

Torsten

Nice idea of splitting large route files. 

But am i misunderstanding something or could you just as well use require_relative , either directly or instead of the instance_eval ?

Yes, thanks for that.

Did you see a way of getting from actual addresses to those coordinates that you used ?

Nice one.

Creating the models with factory_girl makes for much better reuse and smaller code.

And adding guard and autosave in the mix, the workflow has less steps and is much faster.