README.md in clockwork-2.0.0 vs README.md in clockwork-2.0.1

- old
+ new

@@ -1,10 +1,10 @@ -Clockwork - a clock process to replace cron [![Build Status](https://secure.travis-ci.org/tomykaira/clockwork.png?branch=master)](http://travis-ci.org/tomykaira/clockwork) [![Dependency Status](https://gemnasium.com/tomykaira/clockwork.png)](https://gemnasium.com/tomykaira/clockwork) +Clockwork - a clock process to replace cron [![Build Status](https://api.travis-ci.org/Rykian/clockwork.png?branch=master)](https://travis-ci.org/Rykian/clockwork) [![Dependency Status](https://gemnasium.com/Rykian/clockwork.png)](https://gemnasium.com/Rykian/clockwork) =========================================== Cron is non-ideal for running scheduled application tasks, especially in an app -deployed to multiple machines. [More details.](http://adam.heroku.com/past/2010/4/13/rethinking_cron/) +deployed to multiple machines. [More details.](http://adam.herokuapp.com/past/2010/4/13/rethinking_cron/) Clockwork is a cron replacement. It runs as a lightweight, long-running Ruby process which sits alongside your web processes (Mongrel/Thin) and your worker processes (DJ/Resque/Minion/Stalker) to schedule recurring work at particular times or dates. For example, refreshing feeds on an hourly basis, or send @@ -67,12 +67,12 @@ The clock process only makes sense as a place to schedule work to be done, not to do the work. It avoids locking by running as a single process, but this makes it impossible to parallelize. For doing the work, you should be using a job queueing system, such as [Delayed Job](http://www.therailsway.com/2009/7/22/do-it-later-with-delayed-job), -[Beanstalk/Stalker](http://adam.heroku.com/past/2010/4/24/beanstalk_a_simple_and_fast_queueing_backend/), -[RabbitMQ/Minion](http://adam.heroku.com/past/2009/9/28/background_jobs_with_rabbitmq_and_minion/), +[Beanstalk/Stalker](http://adam.herokuapp.com/past/2010/4/24/beanstalk_a_simple_and_fast_queueing_backend/), +[RabbitMQ/Minion](http://adam.herokuapp.com/past/2009/9/28/background_jobs_with_rabbitmq_and_minion/), [Resque](http://github.com/blog/542-introducing-resque), or [Sidekiq](https://github.com/mperham/sidekiq). This design allows a simple clock process with no locks, but also offers near infinite horizontal scalability. @@ -90,11 +90,11 @@ ``` Using a queueing system which doesn't require that your full application be loaded is preferable, because the clock process can keep a tiny memory footprint. If you're using DJ or Resque, however, you can go ahead and load -your full application enviroment, and use per-event blocks to call DJ or Resque +your full application environment, and use per-event blocks to call DJ or Resque enqueue methods. For example, with DJ/Rails: ```ruby require 'config/boot' require 'config/environment' @@ -160,11 +160,11 @@ - `attributes` returning a hash of [attribute name] => [attribute value] values (or really anything that we can use store on registering the event, and then compare again to see if the state has changed later) - (optionally) `at` return any acceptable clockwork `:at` string - - (optionally) `name` returning the name for the event (used to identify it in the Clcockwork output) + - (optionally) `name` returning the name for the event (used to identify it in the Clockwork output) - (optionally) `if?` returning either true or false, depending on whether the database event should run at the given time (this method will be passed the time as a parameter, much like the standard clockwork `:if`) - (optionally) `tz` returning the timezone to use (default is the local timezone) @@ -461,20 +461,28 @@ every(1.day, 'check.leap.year') do Stalker.enqueue('leap.year.party') if Date.leap?(Time.now.year) end ``` -In addition, Clockwork also supports `:before_tick` and `after_tick` callbacks. -They are optional, and run every tick (a tick being whatever your `:sleep_timeout` +In addition, Clockwork also supports `:before_tick`, `:after_tick`, `:before_run`, and `:after_run` callbacks. +All callbacks are optional. The `tick` callbacks run every tick (a tick being whatever your `:sleep_timeout` is set to, default is 1 second): ```ruby on(:before_tick) do puts "tick" end on(:after_tick) do puts "tock" +end + +on(:before_run) do |event, t| + puts "job_started: #{event}" +end + +on(:after_run) do |event, t| + puts "job_finished: #{event}" end ``` Finally, you can use tasks synchronised from a database as described in detail above: