rufus-scheduler 3.5.2 → 3.8.1

data/README.md

@@ -1,8 +1,9 @@
 
 # rufus-scheduler
 
-[![Build Status](https://secure.travis-ci.org/jmettraux/rufus-scheduler.svg)](http://travis-ci.org/jmettraux/rufus-scheduler)
-[![Gem Version](https://badge.fury.io/rb/rufus-scheduler.svg)](http://badge.fury.io/rb/rufus-scheduler)
+[![tests](https://github.com/jmettraux/rufus-scheduler/workflows/test/badge.svg)](https://github.com/jmettraux/rufus-scheduler/actions)
+[![Gem Version](https://badge.fury.io/rb/rufus-scheduler.svg)](https://badge.fury.io/rb/rufus-scheduler)
+[![Join the chat at https://gitter.im/floraison/fugit](https://badges.gitter.im/floraison/fugit.svg)](https://gitter.im/floraison/fugit?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge&utm_content=badge)
 
 Job scheduler for Ruby (at, cron, in and every jobs).
 
@@ -23,7 +24,11 @@ scheduler.in '3s' do
 end
 
 scheduler.join
+  #
   # let the current thread join the scheduler thread
+  #
+  # (please note that this join should be removed when scheduling
+  # in a web application (Rails and friends) initializer)
 ```
 (run with `ruby quickstart.rb`)
 
@@ -58,6 +63,8 @@ end
 # ...
 ```
 
+Rufus-scheduler uses [fugit](https://github.com/floraison/fugit) for parsing time strings, [et-orbi](https://github.com/floraison/et-orbi) for pairing time and [tzinfo](https://github.com/tzinfo/tzinfo) timezones.
+
 ## non-features
 
 Rufus-scheduler (out of the box) is an in-process, in-memory scheduler. It uses threads.
@@ -70,9 +77,10 @@ A rufus-scheduler instance will go on scheduling while it is present among the o
 ## related and similar gems
 
 * [Whenever](https://github.com/javan/whenever) - let cron call back your Ruby code, trusted and reliable cron drives your schedule
+* [ruby-clock](https://github.com/jjb/ruby-clock) - a clock process / job scheduler for Ruby
 * [Clockwork](https://github.com/Rykian/clockwork) - rufus-scheduler inspired gem
 * [Crono](https://github.com/plashchynski/crono) - an in-Rails cron scheduler
-* [PerfectSched](https://github.com/treasure-data/perfectsched) - highly available distributed cron built on [Sequel](http://sequel.jeremyevans.net) and more
+* [PerfectSched](https://github.com/treasure-data/perfectsched) - highly available distributed cron built on [Sequel](https://sequel.jeremyevans.net) and more
 
 (please note: rufus-scheduler is not a cron replacement)
 
@@ -89,7 +97,7 @@ There is no EventMachine-based scheduler anymore.
 I'll drive you right to the [tracks](#so-rails).
 
 
-## Notable changes:
+## notable changes:
 
 * As said, no more EventMachine-based scheduler
 * ```scheduler.every('100') {``` will schedule every 100 seconds (previously, it would have been 0.1s). This aligns rufus-scheduler with Ruby's ```sleep(100)```
@@ -97,8 +105,8 @@ I'll drive you right to the [tracks](#so-rails).
 * The error_handler is [#on_error](#rufusscheduleron_errorjob-error) (instead of #on_exception), by default it now prints the details of the error to $stderr (used to be $stdout)
 * Rufus::Scheduler::TimeOutError renamed to Rufus::Scheduler::TimeoutError
 * Introduction of "interval" jobs. Whereas "every" jobs are like "every 10 minutes, do this", interval jobs are like "do that, then wait for 10 minutes, then do that again, and so on"
-* Introduction of a :lockfile => true/filename mechanism to prevent multiple schedulers from executing
-* "discard_past" is on by default. If the scheduler (its host) sleeps for 1 hour and a ```every '10m'``` job is on, it will trigger once at wakeup, not 6 times (discard_past was false by default in rufus-scheduler 2.x). No intention to re-introduce ```:discard_past => false``` in 3.0 for now.
+* Introduction of a lockfile: true/filename mechanism to prevent multiple schedulers from executing
+* "discard_past" is on by default. If the scheduler (its host) sleeps for 1 hour and a `every '10m'` job is on, it will trigger once at wakeup, not 6 times (discard_past was false by default in rufus-scheduler 2.x). No intention to re-introduce `discard_past: false` in 3.0 for now.
 * Introduction of Scheduler #on_pre_trigger and #on_post_trigger callback points
 
 
@@ -108,26 +116,26 @@ So you need help. People can help you, but first help them help you, and don't w
 
 "hello", "please" and "thanks" are not swear words.
 
-Go read [how to report bugs effectively](http://www.chiark.greenend.org.uk/~sgtatham/bugs.html), twice.
+Go read [how to report bugs effectively](https://www.chiark.greenend.org.uk/~sgtatham/bugs.html), twice.
 
 Update: [help_help.md](https://gist.github.com/jmettraux/310fed75f568fd731814) might help help you.
 
-### on IRC
+### on Gitter
 
-I sometimes haunt #ruote on freenode.net. The channel is not dedicated to rufus-scheduler, so if you ask a question, first mention it's about rufus-scheduler.
+You can find help via chat over at [https://gitter.im/floraison/fugit](https://gitter.im/floraison/fugit). It's [fugit](https://github.com/floraison/fugit), [et-orbi](https://github.com/floraison/et-orbi), and rufus-scheduler combined chat room.
 
-Please note that I prefer helping over Stack Overflow because it's more searchable than the ruote IRC archive.
+Please be courteous.
 
 ### issues
 
-Yes, issues can be reported in [rufus-scheduler issues](https://github.com/jmettraux/rufus-scheduler/issues), I'd actually prefer bugs in there. If there is nothing wrong with rufus-scheduler, a [Stack Overflow question](http://stackoverflow.com/questions/ask?tags=rufus-scheduler+ruby) is better.
+Yes, issues can be reported in [rufus-scheduler issues](https://github.com/jmettraux/rufus-scheduler/issues), I'd actually prefer bugs in there. If there is nothing wrong with rufus-scheduler, a [Stack Overflow question](https://stackoverflow.com/questions/ask?tags=rufus-scheduler+ruby) is better.
 
 ### faq
 
-* [It doesn't work...](http://www.chiark.greenend.org.uk/~sgtatham/bugs.html)
-* [I want a refund](http://blog.nodejitsu.com/getting-refunds-on-open-source-projects)
-* [Passenger and rufus-scheduler](http://stackoverflow.com/questions/18108719/debugging-rufus-scheduler/18156180#18156180)
-* [Passenger and rufus-scheduler (2)](http://stackoverflow.com/questions/21861387/rufus-cron-job-not-working-in-apache-passenger#answer-21868555)
+* [It doesn't work...](https://www.chiark.greenend.org.uk/~sgtatham/bugs.html)
+* [I want a refund](https://blog.nodejitsu.com/getting-refunds-on-open-source-projects)
+* [Passenger and rufus-scheduler](https://stackoverflow.com/questions/18108719/debugging-rufus-scheduler/18156180#18156180)
+* [Passenger and rufus-scheduler (2)](https://stackoverflow.com/questions/21861387/rufus-cron-job-not-working-in-apache-passenger#answer-21868555)
 * [Passenger in-depth spawn methods](https://www.phusionpassenger.com/library/indepth/ruby/spawn_methods/)
 * [Passenger in-depth spawn methods (smart spawning)](https://www.phusionpassenger.com/library/indepth/ruby/spawn_methods/#smart-spawning-hooks)
 * [The scheduler comes up when running the Rails console or a Rake task](https://github.com/jmettraux/rufus-scheduler#avoid-scheduling-when-running-the-ruby-on-rails-console)
@@ -215,7 +223,7 @@ job =
 # also
 
 job =
-  scheduler.in '10d', :job => true do
+  scheduler.in '10d', job: true do
     # ...
   end
 ```
@@ -370,23 +378,40 @@ While paused, the scheduler still accepts schedules, but no schedule will get tr
 
 ## job options
 
-### :blocking => true
+### name: string
+
+Sets the name of the job.
+
+```ruby
+scheduler.cron '*/15 8 * * *', name: 'Robert' do |job|
+  puts "A, it's #{Time.now} and my name is #{job.name}"
+end
+
+job1 =
+  scheduler.schedule_cron '*/30 9 * * *', n: 'temporary' do |job|
+    puts "B, it's #{Time.now} and my name is #{job.name}"
+  end
+# ...
+job1.name = 'Beowulf'
+```
+
+### blocking: true
 
-By default, jobs are triggered in their own, new threads. When `:blocking => true`, the job is triggered in the scheduler thread (a new thread is not created). Yes, while a blocking job is running, the scheduler is not scheduling.
+By default, jobs are triggered in their own, new threads. When `blocking: true`, the job is triggered in the scheduler thread (a new thread is not created). Yes, while a blocking job is running, the scheduler is not scheduling.
 
-### :overlap => false
+### overlap: false
 
 Since, by default, jobs are triggered in their own new threads, job instances might overlap. For example, a job that takes 10 minutes and is scheduled every 7 minutes will have overlaps.
 
-To prevent overlap, one can set `:overlap => false`. Such a job will not trigger if one of its instances is already running.
+To prevent overlap, one can set `overlap: false`. Such a job will not trigger if one of its instances is already running.
 
 The `:overlap` option is considered before the `:mutex` option when the scheduler is reviewing jobs for triggering.
 
-### :mutex => mutex_instance / mutex_name / array of mutexes
+### mutex: mutex_instance / mutex_name / array of mutexes
 
 When a job with a mutex triggers, the job's block is executed with the mutex around it, preventing other jobs with the same mutex from entering (it makes the other jobs wait until it exits the mutex).
 
-This is different from `:overlap => false`, which is, first, limited to instances of the same job, and, second, doesn't make the incoming job instance block/wait but give up.
+This is different from `overlap: false`, which is, first, limited to instances of the same job, and, second, doesn't make the incoming job instance block/wait but give up.
 
 `:mutex` accepts a mutex instance or a mutex name (String). It also accept an array of mutex names / mutex instances. It allows for complex relations between jobs.
 
@@ -396,12 +421,12 @@ Note: creating lots of different mutexes is OK. Rufus-scheduler will place them
 
 The `:overlap` option is considered before the `:mutex` option when the scheduler is reviewing jobs for triggering.
 
-### :timeout => duration or point in time
+### timeout: duration or point in time
 
 It's OK to specify a timeout when scheduling some work. After the time specified, it gets interrupted via a Rufus::Scheduler::TimeoutError.
 
 ```ruby
-scheduler.in '10d', :timeout => '1d' do
+scheduler.in '10d', timeout: '1d' do
   begin
     # ... do something
   rescue Rufus::Scheduler::TimeoutError
@@ -422,15 +447,15 @@ In the case of an "every" job, this will be the first time (modulo the scheduler
 For a "cron" job as well, the :first will point to the first time the job has to trigger, the following trigger times are then determined by the cron string.
 
 ```ruby
-scheduler.every '2d', :first_at => Time.now + 10 * 3600 do
+scheduler.every '2d', first_at: Time.now + 10 * 3600 do
   # ... every two days, but start in 10 hours
 end
 
-scheduler.every '2d', :first_in => '10h' do
+scheduler.every '2d', first_in: '10h' do
   # ... every two days, but start in 10 hours
 end
 
-scheduler.cron '00 14 * * *', :first_in => '3d' do
+scheduler.cron '00 14 * * *', first_in: '3d' do
   # ... every day at 14h00, but start after 3 * 24 hours
 end
 ```
@@ -452,12 +477,11 @@ s = Rufus::Scheduler.new
 
 n = Time.now; p [ :scheduled_at, n, n.to_f ]
 
-s.every '3s', :first => :now do
+s.every '3s', first: :now do
   n = Time.now; p [ :in, n, n.to_f ]
 end
 
 s.join
-
 ```
 
 that'll output something like:
@@ -478,15 +502,15 @@ This option is for repeat jobs (cron / every) only.
 It indicates the point in time after which the job should unschedule itself.
 
 ```ruby
-scheduler.cron '5 23 * * *', :last_in => '10d' do
+scheduler.cron '5 23 * * *', last_in: '10d' do
   # ... do something every evening at 23:05 for 10 days
 end
 
-scheduler.every '10m', :last_at => Time.now + 10 * 3600 do
+scheduler.every '10m', last_at: Time.now + 10 * 3600 do
   # ... do something every 10 minutes for 10 hours
 end
 
-scheduler.every '10m', :last_in => 10 * 3600 do
+scheduler.every '10m', last_in: 10 * 3600 do
   # ... do something every 10 minutes for 10 hours
 end
 ```
@@ -501,16 +525,16 @@ job.last_at = Rufus::Scheduler.parse('2029-12-12')
   # set the last bound
 ```
 
-### :times => nb of times (before auto-unscheduling)
+### times: nb of times (before auto-unscheduling)
 
 One can tell how many times a repeat job (CronJob or EveryJob) is to execute before unscheduling by itself.
 
 ```ruby
-scheduler.every '2d', :times => 10 do
+scheduler.every '2d', times: 10 do
   # ... do something every two days, but not more than 10 times
 end
 
-scheduler.cron '0 23 * * *', :times => 31 do
+scheduler.cron '0 23 * * *', times: 31 do
   # ... do something every day at 23:00 but do it no more than 31 times
 end
 ```
@@ -518,7 +542,7 @@ end
 It's OK to assign nil to :times to make sure the repeat job is not limited. It's useful when the :times is determined at scheduling time.
 
 ```ruby
-scheduler.cron '0 23 * * *', :times => nolimit ? nil : 10 do
+scheduler.cron '0 23 * * *', times: (nolimit ? nil : 10) do
   # ...
 end
 ```
@@ -540,7 +564,7 @@ job.times = 10
 
 ## Job methods
 
-When calling a schedule method, the id (String) of the job is returned. Longer schedule methods return Job instances directly. Calling the shorter schedule methods with the :job => true also returns Job instances instead of Job ids (Strings).
+When calling a schedule method, the id (String) of the job is returned. Longer schedule methods return Job instances directly. Calling the shorter schedule methods with the `job: true` also returns Job instances instead of Job ids (Strings).
 
 ```ruby
   require 'rufus-scheduler'
@@ -558,7 +582,7 @@ When calling a schedule method, the id (String) of the job is returned. Longer s
     end
 
   job =
-    scheduler.in '1w', :job => true do
+    scheduler.in '1w', job: true do
       # ...
     end
 ```
@@ -584,7 +608,7 @@ Returns the scheduler instance itself.
 Returns the options passed at the Job creation.
 
 ```ruby
-job = scheduler.schedule_in('10d', :tag => 'hello') do; end
+job = scheduler.schedule_in('10d', tag: 'hello') do; end
 job.opts
   # => { :tag => 'hello' }
 ```
@@ -594,7 +618,7 @@ job.opts
 Returns the original schedule.
 
 ```ruby
-job = scheduler.schedule_in('10d', :tag => 'hello') do; end
+job = scheduler.schedule_in('10d', tag: 'hello') do; end
 job.original
   # => '10d'
 ```
@@ -641,12 +665,30 @@ job.callable
   # => #<MyHandler:0x0000000163ae88 @counter=0>
 ```
 
+### source_location
+
+Added to rufus-scheduler 3.8.0.
+
+Returns the array `[ 'path/to/file.rb', 123 ]` like `Proc#source_location` does.
+
+```ruby
+require 'rufus-scheduler'
+
+scheduler = Rufus::Scheduler.new
+
+job = scheduler.schedule_every('2h') { p Time.now }
+
+p job.source_location
+  # ==> [ '/home/jmettraux/rufus-scheduler/test.rb', 6 ]
+
+```
+
 ### scheduled_at
 
 Returns the Time instance when the job got created.
 
 ```ruby
-job = scheduler.schedule_in('10d', :tag => 'hello') do; end
+job = scheduler.schedule_in('10d', tag: 'hello') do; end
 job.scheduled_at
   # => 2013-07-17 23:48:54 +0900
 ```
@@ -687,6 +729,12 @@ The job keeps track of how long its work was in the `last_work_time` attribute.
 
 The attribute `mean_work_time` contains a computed mean work time. It's recomputed after every run (if it's a repeat job).
 
+### next_times(n)
+
+Returns an array of `EtOrbi::EoTime` instances (Time instances with a designated time zone), listing the `n` next occurrences for this job.
+
+Please note that for "interval" jobs, a mean work time is computed each time and it's used by this `#next_times(n)` method to approximate the next times beyond the immediate next time.
+
 ### unschedule
 
 Unschedule the job, preventing it from firing again and removing it from the schedule. This doesn't prevent a running thread for this job to run until its end.
@@ -743,14 +791,14 @@ job = scheduler.schedule_in('10d') do; end
 job.tags
   # => []
 
-job = scheduler.schedule_in('10d', :tag => 'hello') do; end
+job = scheduler.schedule_in('10d', tag: 'hello') do; end
 job.tags
   # => [ 'hello' ]
 ```
 
-### []=, [], key? and keys
+### []=, [], key?, has_key?, keys, values, and entries
 
-Threads have thread-local variables. Rufus-scheduler jobs have job-local variables.
+Threads have thread-local variables, similarly Rufus-scheduler jobs have job-local variables. Those are more like a dict with thread-safe access.
 
 ```ruby
 job =
@@ -765,13 +813,29 @@ sleep 3.6
 job[:counter]
   # => 3
 
-job.key?(:timestamp)
-  # => true
-job.keys
-  # => [ :timestamp, :counter ]
+job.key?(:timestamp) # => true
+job.has_key?(:timestamp) # => true
+job.keys # => [ :timestamp, :counter ]
 ```
 
-Job-local variables are thread-safe.
+Locals can be set at schedule time:
+```ruby
+job0 =
+  @scheduler.schedule_cron '*/15 12 * * *', locals: { a: 0 } do
+    # ...
+  end
+job1 =
+  @scheduler.schedule_cron '*/15 13 * * *', l: { a: 1 } do
+    # ...
+  end
+```
+
+One can fetch the Hash directly with `Job#locals`. Of course, direct manipulation is not thread-safe.
+```ruby
+job.locals.entries do |k, v|
+  p "#{k}: #{v}"
+end
+```
 
 ### call
 
@@ -912,24 +976,24 @@ Here is an example:
   scheduler.at_jobs.each(&:unschedule)
 ```
 
-### Scheduler#jobs(:tag / :tags => x)
+### Scheduler#jobs(tag: / tags: x)
 
 When scheduling a job, one can specify one or more tags attached to the job. These can be used to look up the job later on.
 
 ```ruby
-  scheduler.in '10d', :tag => 'main_process' do
+  scheduler.in '10d', tag: 'main_process' do
     # ...
   end
-  scheduler.in '10d', :tags => [ 'main_process', 'side_dish' ] do
+  scheduler.in '10d', tags: [ 'main_process', 'side_dish' ] do
     # ...
   end
 
   # ...
 
-  jobs = scheduler.jobs(:tag => 'main_process')
+  jobs = scheduler.jobs(tag: 'main_process')
     # find all the jobs with the 'main_process' tag
 
-  jobs = scheduler.jobs(:tags => [ 'main_process', 'side_dish' ]
+  jobs = scheduler.jobs(tags: [ 'main_process', 'side_dish' ]
     # find all the jobs with the 'main_process' AND 'side_dish' tags
 ```
 
@@ -954,6 +1018,10 @@ Shuts down the scheduler, ceases any scheduler/triggering activity.
 
 Shuts down the scheduler, waits (blocks) until all the jobs cease running.
 
+### Scheduler#shutdown(wait: n)
+
+Shuts down the scheduler, waits (blocks) at most n seconds until all the jobs cease running. (Jobs are killed after n seconds have elapsed).
+
 ### Scheduler#shutdown(:kill)
 
 Kills all the job (threads) and then shuts the scheduler down. Radical.
@@ -976,6 +1044,8 @@ Returns since the count of seconds for which the scheduler has been running.
 
 Lets the current thread join the scheduling thread in rufus-scheduler. The thread comes back when the scheduler gets shut down.
 
+`#join` is mostly used in standalone scheduling script (or tiny one file examples). Calling `#join` from a web application initializer will probably hijack the main thread and prevent the web application from being served. Do not put a `#join` in such a web application initializer file.
+
 ### Scheduler#threads
 
 Returns all the threads associated with the scheduler, including the scheduler thread itself.
@@ -988,7 +1058,7 @@ Lists the work threads associated with the scheduler. The query option defaults
 * :active : all the work threads currently running a Job
 * :vacant : all the work threads currently not running a Job
 
-Note that the main schedule thread will be returned if it is currently running a Job (ie one of those :blocking => true jobs).
+Note that the main schedule thread will be returned if it is currently running a Job (ie one of those `blocking: true` jobs).
 
 ### Scheduler#scheduled?(job_or_job_id)
 
@@ -996,7 +1066,7 @@ Returns true if the arg is a currently scheduled job (see Job#scheduled?).
 
 ### Scheduler#occurrences(time0, time1)
 
-Returns a hash ```{ job => [ t0, t1, ... ] }``` mapping jobs to their potential trigger time within the ```[ time0, time1 ]``` span.
+Returns a hash `{ job => [ t0, t1, ... ] }` mapping jobs to their potential trigger time within the `[ time0, time1 ]` span.
 
 Please note that, for interval jobs, the ```#mean_work_time``` is used, so the result is only a prediction.
 
@@ -1088,7 +1158,9 @@ def scheduler.on_error(job, error)
 end
 ```
 
-## Rufus::Scheduler #on_pre_trigger and #on_post_trigger callbacks
+## Callbacks
+
+### Rufus::Scheduler #on_pre_trigger and #on_post_trigger callbacks
 
 One can bind callbacks before and after jobs trigger:
 
@@ -1112,6 +1184,21 @@ The ```trigger_time``` is the time at which the job triggers. It might be a bit
 
 Warning: these two callbacks are executed in the scheduler thread, not in the work threads (the threads where the job execution really happens).
 
+### Rufus::Scheduler#around_trigger
+
+One can create an around callback which will wrap a job:
+
+```ruby
+def s.around_trigger(job)
+  t = Time.now
+  puts "Starting job #{job.id}..."
+  yield
+  puts "job #{job.id} finished in #{Time.now-t} seconds."
+end
+```
+
+The around callback is executed in the thread.
+
 ### Rufus::Scheduler#on_pre_trigger as a guard
 
 Returning ```false``` in on_pre_trigger will prevent the job from triggering. Returning anything else (nil, -1, true, ...) will let the job trigger.
@@ -1136,23 +1223,23 @@ By default, rufus-scheduler sleeps 0.300 second between every step. At each step
 The :frequency option lets you change that 0.300 second to something else.
 
 ```ruby
-scheduler = Rufus::Scheduler.new(:frequency => 5)
+scheduler = Rufus::Scheduler.new(frequency: 5)
 ```
 
 It's OK to use a time string to specify the frequency.
 
 ```ruby
-scheduler = Rufus::Scheduler.new(:frequency => '2h10m')
+scheduler = Rufus::Scheduler.new(frequency: '2h10m')
   # this scheduler will sleep 2 hours and 10 minutes between every "step"
 ```
 
 Use with care.
 
-### :lockfile => "mylockfile.txt"
+### lockfile: "mylockfile.txt"
 
 This feature only works on OSes that support the flock (man 2 flock) call.
 
-Starting the scheduler with ```:lockfile => ".rufus-scheduler.lock"``` will make the scheduler attempt to create and lock the file ```.rufus-scheduler.lock``` in the current working directory. If that fails, the scheduler will not start.
+Starting the scheduler with ```lockfile: '.rufus-scheduler.lock'``` will make the scheduler attempt to create and lock the file ```.rufus-scheduler.lock``` in the current working directory. If that fails, the scheduler will not start.
 
 The idea is to guarantee only one scheduler (in a group of schedulers sharing the same lockfile) is running.
 
@@ -1181,7 +1268,7 @@ class HostLock
 end
 
 scheduler =
-  Rufus::Scheduler.new(:scheduler_lock => HostLock.new('coffee.example.com'))
+  Rufus::Scheduler.new(scheduler_lock: HostLock.new('coffee.example.com'))
 ```
 
 By default, the scheduler_lock is an instance of `Rufus::Scheduler::NullLock`, with a `#lock` that returns true.
@@ -1204,7 +1291,7 @@ class PingLock
 end
 
 scheduler =
-  Rufus::Scheduler.new(:trigger_lock => PingLock.new('main.example.com'))
+  Rufus::Scheduler.new(trigger_lock: PingLock.new('main.example.com'))
 ```
 
 By default, the trigger_lock is an instance of `Rufus::Scheduler::NullLock`, with a `#lock` that always returns true.
@@ -1218,7 +1305,7 @@ In rufus-scheduler 2.x, by default, each job triggering received its own, brand
 One can set this maximum value when starting the scheduler.
 
 ```ruby
-scheduler = Rufus::Scheduler.new(:max_work_threads => 77)
+scheduler = Rufus::Scheduler.new(max_work_threads: 77)
 ```
 
 It's OK to increase the :max_work_threads of a running scheduler.
@@ -1231,7 +1318,7 @@ scheduler.max_work_threads += 10
 ## Rufus::Scheduler.singleton
 
 Do not want to store a reference to your rufus-scheduler instance?
-Then ```Rufus::Scheduler.singleton``` can help, it returns a singleon instance of the scheduler, initialized the first time this class method is called.
+Then ```Rufus::Scheduler.singleton``` can help, it returns a singleton instance of the scheduler, initialized the first time this class method is called.
 
 ```ruby
 Rufus::Scheduler.singleton.every '10s' { puts "hello, world!" }
@@ -1240,8 +1327,8 @@ Rufus::Scheduler.singleton.every '10s' { puts "hello, world!" }
 It's OK to pass initialization arguments (like :frequency or :max_work_threads) but they will only be taken into account the first time ```.singleton``` is called.
 
 ```ruby
-Rufus::Scheduler.singleton(:max_work_threads => 77)
-Rufus::Scheduler.singleton(:max_work_threads => 277) # no effect
+Rufus::Scheduler.singleton(max_work_threads: 77)
+Rufus::Scheduler.singleton(max_work_threads: 277) # no effect
 ```
 
 The ```.s``` is a shortcut for ```.singleton```.
@@ -1290,7 +1377,7 @@ class ZookeptScheduler < Rufus::Scheduler
 end
 ```
 
-This uses a [zookeeper](http://zookeeper.apache.org/) to make sure only one scheduler in a group of distributed schedulers runs.
+This uses a [zookeeper](https://zookeeper.apache.org/) to make sure only one scheduler in a group of distributed schedulers runs.
 
 The methods #lock and #unlock are overridden and #confirm_lock is provided,
 to make sure that the lock is still valid.
@@ -1314,6 +1401,8 @@ Warning: you may think you're heading towards "high availability" by using a tri
 
 ## parsing cronlines and time strings
 
+(Please note that [fugit](https://github.com/floraison/fugit) does the heavy-lifting parsing work for rufus-scheduler).
+
 Rufus::Scheduler provides a class method ```.parse``` to parse time durations and cron strings. It's what it's using when receiving schedules. One can use it directly (no need to instantiate a Scheduler).
 
 ```ruby
@@ -1356,7 +1445,7 @@ Rufus::Scheduler.to_duration_hash(60)
 Rufus::Scheduler.to_duration_hash(62.127)
   # => { :m => 1, :s => 2, :ms => 127 }
 
-Rufus::Scheduler.to_duration_hash(62.127, :drop_seconds => true)
+Rufus::Scheduler.to_duration_hash(62.127, drop_seconds: true)
   # => { :m => 1 }
 ```
 
@@ -1539,7 +1628,7 @@ class ScheController < ApplicationController
         Rails.logger.info "time flies, it's now #{Time.now}"
       end
 
-    render :text => "scheduled job #{job_id}"
+    render text: "scheduled job #{job_id}"
   end
 end
 ```
@@ -1550,9 +1639,9 @@ The rufus-scheduler singleton is instantiated in the ```config/initializers/sche
 
 ### avoid scheduling when running the Ruby on Rails console
 
-(Written in reply to https://github.com/jmettraux/rufus-scheduler/issues/186 )
+(Written in reply to [gh-186](https://github.com/jmettraux/rufus-scheduler/issues/186))
 
-If you don't want rufus-scheduler to kick in when running the Ruby on Rails console or invoking a rake task, you can wrap your initializer in a conditional:
+If you don't want rufus-scheduler to trigger anything while running the Ruby on Rails console, running for tests/specs, or running from a Rake task, you can insert a conditional return statement before jobs are added to the scheduler instance:
 
 ```ruby
 #
@@ -1560,23 +1649,25 @@ If you don't want rufus-scheduler to kick in when running the Ruby on Rails cons
 
 require 'rufus-scheduler'
 
-s = Rufus::Scheduler.singleton
-
-
-unless defined?(Rails::Console) || File.split($0).last == 'rake'
+return if defined?(Rails::Console) || Rails.env.test? || File.split($PROGRAM_NAME).last == 'rake'
+  #
+  # do not schedule when Rails is run from its console, for a test/spec, or
+  # from a Rake task
 
-  # only schedule when not running from the Ruby on Rails console
-  # or from a rake task
+# return if $PROGRAM_NAME.include?('spring')
+  #
+  # see https://github.com/jmettraux/rufus-scheduler/issues/186
 
-  s.every '1m' do
+s = Rufus::Scheduler.singleton
 
-    Rails.logger.info "hello, it's #{Time.now}"
-    Rails.logger.flush
-  end
+s.every '1m' do
+  Rails.logger.info "hello, it's #{Time.now}"
+  Rails.logger.flush
 end
 ```
 
-It should work for Ruby on Rails 3 and 4.
+(Beware later version of Rails where Spring takes care pre-running the initializers. Running `spring stop` or disabling Spring might be necessary in some cases to see changes to initializers being taken into account.)
+
 
 ### rails server -d
 
@@ -1588,11 +1679,14 @@ I avoid running `-d` in development mode and bother about daemonizing only for p
 
 These are two well crafted articles on process daemonization, please read them:
 
-* http://www.mikeperham.com/2014/09/22/dont-daemonize-your-daemons/
-* http://www.mikeperham.com/2014/07/07/use-runit/
+* https://www.mikeperham.com/2014/09/22/dont-daemonize-your-daemons/
+* https://www.mikeperham.com/2014/07/07/use-runit/
 
 If, anyway, you need something like `rails server -d`, why not try `bundle exec unicorn -D` instead? In my (limited) experience, it worked out of the box (well, had to add `gem 'unicorn'` to `Gemfile` first).
 
+### executor / reloader
+
+You might benefit from wraping your scheduled code in the executor or reloader. Read more here: https://guides.rubyonrails.org/threading_and_code_execution.html
 
 ## support