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

@@ -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: