README.md in sidekiq-apriori-0.0.1 vs README.md in sidekiq-apriori-0.0.2

- old
+ new

@@ -1,4 +1,119 @@ sidekiq-apriori =============== - Prioritization Middleware for Sidekiq + +[![Build Status](https://travis-ci.org/enova/sidekiq-apriori.png)](https://travis-ci.org/enova/sidekiq-apriori) + +Overview +-------- + +sidekiq-apriori simplifies dynamic prioritization for sidekiq by supplying a +simple sidekiq middleware, related active record hooks, & some additional +argument handling (for ruby 2 users). + +Installation +------------ + +Manual installation is always an option. From the command line: + + $ gem install sidekiq-priority + +Or, if you're using bundler, simply include it in your Gemfile: + + gem 'sidekiq-priority' + +Priorities +---------- + +By default, sidekiq-apriori supports four priorities: immediate, high, nil +(default), and low. If you would like to use different priorities you can +add something along these lines to (as an example for you railsy folk) your +sidekiq initializer: + +```ruby +## config/initializers/sidekiq.rb + +Sidekiq::Apriori::PRIORITIES = ['wut', 'huh', 'ok', nil, 'not_even_a_little'] +``` + +The nil is meaningful insofar as it represents the default priority. Unless you +want to disallow unset priorities, leave the nil in. + +sidekiq-apriori is inspired by (a response to?) [sidekiq-priority](https://github.com/socialpandas/sidekiq-priority), in which the +order of the priorities is important. Contrary to the approach taken by +sidekiq-priority, sidekiq-apriori uses sidekiq's built in mechanism for +configuring the order of processing. So, for example, if your sidekiq.yml +currently looks like this: + +```yaml +## sidekiq.yml + +verbose: false +:pidfile: /tmp/sidekiq.pid +:concurrency: 5 +:queues: + - postback + - background +``` + +you might want to change the 'queues' entry to look more like this: + +```yaml +:queues: + - postback_wut + - postback_huh + - postback_ok + - postback + - postback_not_even_a_little + - background +``` + +Use +--- + +In addition to the use described in the PRIORITIES section, some tooling is +provided for active record classes with priority as an attribute: + +```ruby +## app/models/prioritized.rb + +class Prioritized < ActiveRecord::Base + include Sidekiq::Apriori::Arb + + prioritize do + self.priority = nil unless + Sidekiq::Apriori::PRIORITIES.include?(self.priority) + + self.priority = (...) + end +end +``` + +Alternatively, you can pass a method name to prioritize: + +```ruby +## app/models/prioritized.rb + +class Prioritized < ActiveRecord::Base + include Sidekiq::Apriori::Arb + + prioritize using: 'some_method' + + def some_method + (...) + end +end +``` + +If you're lucky enough to be using ruby 2, you can save yourself some work by +including ```Sidekiq::Apriori::Worker``` instead of ```Sidekiq::Worker``` in your +worker classes. This will have the nifty side effect of saving you the effort of +changing the definition of the classes' perform method & its invocation. +```Sidekiq::Apriori::Worker``` uses ```prepend``` to define a perform which will +take an optional hash containing a priority designation. + +License +------- + +sidekiq-apriori is released under the MIT License. Please see the [LICENSE](LICENSE) +file for details.