If it is displayed only at the place of the closest source code, debugging is becomes more comfortable.
See: ```ruby class Example private def self.example end end puts (class << Example; self; end).private_method_defined?(:example) class Example2 class << self private def example end end end puts (class << Example2; self; end).private_method_defined?(:example) ``` I chose to implement this in a Ruby 1.8.7 compatible way. Maybe it's time to be clear about ruby version support. /cc @jipiboily
This solves the following error: ``` ruby -Itest /Users/senny/Projects/queue_classic/test/lib/queue_classic_test.rb -n test_unlock_jobs_of_dead_workers ~/Projects/queue_classic 1 ↵ Run options: -n test_unlock_jobs_of_dead_workers --seed 2356 E Finished in 0.050837s, 19.6707 runs/s, 19.6707 assertions/s. 1) Error: QueueClassicTest#test_unlock_jobs_of_dead_workers: NoMethodError: undefined method `execute' for nil:NilClass /Users/senny/Projects/queue_classic/lib/queue_classic.rb:109:in `unlock_jobs_of_dead_workers' /Users/senny/Projects/queue_classic/test/lib/queue_classic_test.rb:29:in `test_unlock_jobs_of_dead_workers' 1 runs, 1 assertions, 0 failures, 1 errors, 0 skips ``` This also prevents random build failures when the random execution order picks `test_unlock_jobs_of_dead_workers` as the first test to run.
In every project I'm using QueueClassic we end up writing our own Worker. This is also encouraged in the README. The process is very smooth but one drawback is that you can't continue to use the rake tasks, which ship with QC. Or at least not `rake qc:work` as this would always use the default worker. I think we should encourage custom workers and make it trivial to inject them into QC's rake tasks.
…igrations Since the release of 3.0.0 the created_at column is "out in the wild" and probably being used to keep track of when a job was created. It should not be used for something semantically completely different like scheduling therefore I introduced a new column for that aspect.