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 [](http://travis-ci.org/tomykaira/clockwork) [](https://gemnasium.com/tomykaira/clockwork)
+Clockwork - a clock process to replace cron [](https://travis-ci.org/Rykian/clockwork) [](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: