sidekiq-hierarchy 0.1.1

checksums.yaml

@@ -0,0 +1,7 @@
+---
+SHA1:
+  metadata.gz: 33347354bed6c46a62bc8d37ef059999ef0646b1
+  data.tar.gz: f05c181f018f4998493fd855c097add3809f897d
+SHA512:
+  metadata.gz: 960ea4782b087f62c9cdce3b143d43eb6eacbe9bb35ce500444937aced01eb57788435349d4d771a9534617a67bc2c53957b97e66711d7e5c9987341b6de0932
+  data.tar.gz: 072d1ef82b78c226563b0d99e5238b642e8e57091f515c8b6115874f2e326d914ab2d0b0db1548a02f96bd92d5b42c9423cb1407d8d992efd32835c831778e6b

data/.gitignore

@@ -0,0 +1,10 @@
+/.bundle/
+/.yardoc
+/Gemfile.lock
+/_yardoc/
+/coverage/
+/doc/
+/pkg/
+/spec/reports/
+/tmp/
+.sw?

data/.rspec

@@ -0,0 +1,2 @@
+--format documentation
+--color

data/.ruby-gemset

@@ -0,0 +1 @@
+sidekiq-hierarchy

data/.ruby-version

@@ -0,0 +1 @@
+jruby-1.7

data/.travis.yml

@@ -0,0 +1,6 @@
+language: ruby
+rvm:
+  - jruby-1.7
+  - jruby-9k
+  - 2.2
+before_install: gem install bundler -v 1.10.6

data/CHANGELOG.md

@@ -0,0 +1,14 @@
+# Change Log
+All notable changes to this project will be documented in this file.
+This project adheres to [Semantic Versioning](http://semver.org/).
+
+## [0.1.1] - 2015-11-16
+### Added
+- This changelog
+
+### Changed
+- Allowed pushing to rubygems.org
+
+## [0.1.0] - 2015-11-16
+### Initial Release
+- Shipping all launch features: tree tracking, network bridging, etc.

data/CONTRIBUTING.md

@@ -0,0 +1,57 @@
+How to Contribute to Sidekiq-Hierarchy
+======================================
+
+Thanks for your interest in Sidekiq-hierarchy project.  When you make a
+contribution to the project (e.g. any modifications, additions to existing
+work, pull requests or any other work intentionally submitted by you for
+inclusion in the project) (collectively, a "Contribution"), Lookout wants to be
+able to use your Contribution to improve this project and other Lookout
+products.
+
+As a condition of providing a Contribution, you agree to the following terms
+and conditions ("Terms"):
+
+  1. Copyright License: Subject to these Terms, you grant Lookout and to
+recipients of software distributed by Lookout a perpetual, worldwide,
+non-exclusive, no-charge, royalty-free, irrevocable license to make, use, sell,
+reproduce, modify, distribute (directly and indirectly), and publicly display
+and perform the Contribution, and any derivative works that Lookout may make
+from the Contribution.
+
+  2. Patent License: Subject to these Terms, you grant Lookout and to
+recipients of software distributed by Lookout a perpetual, worldwide,
+non-exclusive, no-charge, royalty-free, irrevocable (except as stated in this
+section) patent license to make, have made, use, offer to sell, sell, import,
+or otherwise transfer the Contribution, where such license applies only to
+those patent claims licensable by you that are necessarily infringed by your
+Contribution(s) alone or by combination of your Contribution(s) with any works
+or projects to which such Contribution(s) was submitted. If any entity
+institutes patent litigation against you or any other entity (including a
+cross-claim or counterclaim in a lawsuit) alleging that your Contribution(s) or
+the projects to which you have contributed, constitutes direct or contributory
+patent infringement, then any patent licenses granted to that entity under this
+agreement for that Contribution, work or other project shall terminate as of
+the date such litigation is filed.
+
+  3. You warrant and represent that the Contribution(s) is your original
+creation, that you have the authority and are legally entitled to grant these
+licenses to Lookout, and that these licenses do not require the permission of
+any third party.
+
+  4. Except for the warranties in Section 3, you provide any Contribution(s) on
+an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express
+or implied, including, without limitation, any warranties or conditions of
+TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE.
+
+  5. You agree to notify Lookout of any facts or circumstances of which you
+become aware of that would make any representations made by you inaccurate in
+any respect.
+
+
+Should you wish to submit a suggestion or work that is not your original
+creation, you may submit it to Lookout separate from any Contribution,
+explicitly identifying it as sourced from a third party, stating the complete
+details of its source, and informing Lookout of any license or other
+restriction (including but not limited to related patents, trademarks, and
+license agreement) of which you are personally aware, and conspicuously marking
+the work as "Submitted on behalf of a third party: [named here]."

data/Gemfile

@@ -0,0 +1,7 @@
+source 'https://rubygems.org'
+
+group :test do
+  gem 'pry'
+end
+
+gemspec

data/LICENSE.txt

@@ -0,0 +1,21 @@
+The MIT License (MIT)
+
+Copyright (c) 2015 Lookout, Inc.
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in
+all copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+THE SOFTWARE.

data/README.md

@@ -0,0 +1,396 @@
+# Sidekiq::Hierarchy
+
+
+[![Build Status](https://travis-ci.org/anujdas/sidekiq-hierarchy.png?branch=master)](https://travis-ci.org/anujdas/sidekiq-hierarchy)
+
+[![Gem Version](https://badge.fury.io/rb/sidekiq-hierarchy.png)](http://badge.fury.io/rb/sidekiq-hierarchy)
+
+Sidekiq-hierarchy is a gem that implements parent-child hierarchies between sidekiq jobs. Via several middlewares, it allows tracking complete workflows of multiple levels of sidekiq jobs, even across network calls, so long as a shared redis host is available.
+
+You may want to use sidekiq-hierarchy if you:
+
+- have complex (or simple) hierarchies of jobs triggering other jobs
+- want to understand timing breakdowns (enqueued, run, and completed times) per job and per workflow
+- are investigating how job requeues and retries impact your runtimes, e.g., to maintain SLAs
+- would like to perform actions on job and workflow status changes via callbacks, for instance providing progress feedback or statistical trend data
+- need to pass arbitrary data between parent and child jobs, in order to implement, e.g., prioritized workflows, or fail-fast workflows
+- trigger jobs via network calls and want insight into the call graphs
+
+![Web UI](img/in_progress_workflow.png?raw=true)
+
+Disclaimer: Sidekiq-hierarchy supports Sidekiq 3.x, and thus MRI 2.0+ and JRuby; it may work on MRI 1.9, but this configuration is untested as Sidekiq's unit testing support does not extend to it.
+
+## Table of Contents
+
+- [Sidekiq::Hierarchy](#sidekiqhierarchy)
+    - [Table of Contents](#table-of-contents)
+    - [Quickstart](#quickstart)
+    - [Web Interface](#web-interface)
+    - [Architecture and API](#architecture-and-api)
+    - [Callbacks](#callbacks)
+    - [Network integration](#network-integration)
+    - [Advanced Options](#advanced-options)
+        - [Additional Job Info](#additional-job-info)
+        - [CompleteSet and FailedSet](#completeset-and-failedset)
+    - [More Examples](#more-examples)
+        - [Fail-fast workflow cancellation](#fail-fast-workflow-cancellation)
+        - [Workflow Metrics Dashboard](#workflow-metrics-dashboard)
+    - [Installation](#installation)
+    - [Development](#development)
+    - [License](#license)
+
+## Quickstart
+
+Sidekiq-hierarchy is designed to be as unobtrusive as possible. The simplest possible use case, in which jobs trigger other jobs directly (via `#perform_async`), can be realized via a few lines of code. First, set up Sidekiq and make sure that the gem is installed (see Installation, below). Then:
+
+- Add the Sidekiq middlewares to your global Sidekiq configuration, usually in an initializer (e.g., `config/initializers/sidekiq.rb`):
+
+```ruby
+Sidekiq.configure_client do |config|
+  config.client_middleware do |chain|
+    chain.add Sidekiq::Hierarchy::Client::Middleware
+  end
+end
+
+Sidekiq.configure_server do |config|
+  config.client_middleware do |chain|
+    chain.add Sidekiq::Hierarchy::Client::Middleware
+  end
+  config.server_middleware do |chain|
+    chain.add Sidekiq::Hierarchy::Server::Middleware
+  end
+end
+```
+
+Note that the Client middleware must be added to both the server and client configs.
+
+_Since instrumentation occurs in these middlewares, other middlewares you write that make use of Sidekiq-hierarchy's capabilities must be nested appropriately (inside or outside, depending on whether they make use of workflow data-passing or they modify queuing behaviour)._
+
+- Mark your workflow entry points, the jobs that are the root nodes of your work trees. Only the roots need to be modified: any children (or children or children, etc.) will automatically inherit the setting (though it won't hurt if you add them too). Simply append to the sidekiq_options in the worker class:
+
+```ruby
+class RootWorker
+  include Sidekiq::Worker
+  sidekiq_options workflow: true
+
+# def perform(*args)
+#   5.times do |n|
+#     ChildWorker.perform_async(n, *args)
+#   end
+# end
+```
+
+The main concern is Redis storage space: if you are fine instrumenting all jobs (because your Redis instance is huge, or your job throughput is not very high, or you're debugging), you can set this in your global options:
+
+```ruby
+Sidekiq.default_worker_options = { 'workflow' => true }
+```
+
+You're done! Any new instances of your root worker  will now record their child hierarchies.
+
+---
+
+Some examples to try, given a root `JID`:
+
+```ruby
+# > root_jid = RootWorker.perform_async
+# => "11c3ec3df251ebb646f910d7"
+
+> workflow = Sidekiq::Hierarchy::Workflow.find_by_jid(root_jid)
+=> <Sidekiq::Hierarchy::Workflow...>
+
+> workflow.status  # [:running, :complete, :failed]
+=> :complete
+
+> [workflow.enqueued_at, workflow.run_at, workflow.complete_at]
+=> [2015-11-11 15:00:42 -0800, 2015-11-11 15:00:42 -0800, 2015-11-11 15:01:32 -0800]
+```
+```ruby
+> workflow.jobs.count  # lazily eval'd
+=> 33
+
+> workflow.jobs.map(&:jid)
+=> ["11c3ec3df251ebb646f910d7", "f003db430a0eae99d72f1b7a", "bc2cf8f3de3b87f9a4c3c10e", ...]
+```
+```ruby
+> root_job = workflow.root
+=> <Sidekiq::Hierarchy::Job...>
+
+> root_job.info  # configurable hash
+{"class"=>"WebWorker", "queue"=>"default"}
+
+> [root_job.enqueued_at, root_job.run_at, root_job.complete_at]
+=> [2015-11-11 15:00:42 -0800, 2015-11-11 15:00:42 -0800, 2015-11-11 15:00:42 -0800]
+```
+```ruby
+> root_job.leaf?  # tree traversal helpers
+ => false
+ 
+> root_job.children
+ => [<Sidekiq::Hierarchy::Job...>, <Sidekiq::Hierarchy::Job...>, ...]
+ 
+> root_job.leaves.count
+=> 19
+
+> root_job.leaves.last.root == root_job
+=> true
+```
+
+## Web Interface
+
+Sidekiq-hierarchy comes with a full-featured web UI that integrates into the standard sidekiq-web interface. Use it to investigate your workflows without dropping to the console. Keep in mind, displaying workflows is expensive (Redis-command-count-wise), so it may not be the best idea to leave this live-polling a very large workflow on production over the weekend...
+
+If you've already got sidekiq-web running, just
+
+```ruby
+require 'sidekiq/hierarchy/web'
+```
+
+and you're done; click the "Hierarchy" tab on the web UI and dig in. If you don't, follow the steps at https://github.com/mperham/sidekiq/wiki/Monitoring#web-ui first, then add the `require`. Among the things you can do:
+
+- See overall metrics and search for jobs/workflows:
+![Dashboard](img/dashboard.png?raw=true) 
+
+- Summarize running, complete, and failed workflows:
+![Workflow set](img/workflow_set.png?raw=true)
+
+- Introspect jobs and workflows
+![Job](img/failed_workflow.png?raw=true)
+![Workflow](img/job.png?raw=true)
+
+And more! Try out live polling for even more fun.
+
+## Architecture and API
+
+Most of the API is contained in the `Sidekiq::Hierarchy::Job`, `Sidekiq::Hierarchy::Workflow`, and `Sidekiq::Hierarchy::WorkflowSet` classes. At a high level,
+
+- Information is stored as a number of `Job`s that are identified by their JID (job id, randomly generated by Sidekiq).
+- Each `Job` can have one (optional) parent `Job` and any number of children `Job`s.
+- Together, one job tree constitutes a `Workflow`; workflow data is actually stored on the root `Job` node in Redis, but the workflow class provides a handy abstraction.
+- Workflows are organized by status into the three `WorkflowSet`s: the obviously-named`RunningSet`, `CompleteSet`, and `FailedSet`.
+
+Explore the classes to learn more you can access, including:
+
+- current `#status` (`:enqueued`, `:running`, `:complete`, `:requeued`, `:failed`)
+- timestamps for all status changes (`#enqueued_at`, `#run_at`, etc.)
+- tree exploration (`#root`, `#parent`, `#children`, `#leaf?`, etc.)
+- lazy enumerators over jobs and workflows (`Workflow#jobs`, `WorkflowSet#each`)
+- current workflow and job id context (`Sidekiq::Hierarchy.current_workflow`, `.current_jid`)
+
+Each `Workflow` can be treated as a Redis-backed hash (all values will be coerced to strings). Combined with the fact that the current workflow context can always be accessed via `Sidekiq::Hierarchy.current_workflow` (nil if not in a workflow), you can pass arbitrary information through a work tree.
+
+---
+
+As a quick example:
+
+Say you wanted to push child jobs to a higher-priority queue if the root job was triggered by an admin user. We can implement this trivially using the Sidekiq-hierarchy infrastructure:
+
+- When the root job is triggered, let's store the "high-priority" flag on the workflow.
+```ruby
+class RootWorker
+  include Sidekiq::Worker
+  sidekiq_options workflow: true
+  def perform(user_id)
+    if User.find(user_id).admin?
+      # value will be turned into a string anyways
+      Sidekiq::Hierarchy.current_workflow[:important] = '1'
+    end
+    5.times { ChildWorker.perform_async }
+  end
+end
+```
+
+- Now let's write a simple client middleware to read the flag and act accordingly:
+```ruby
+class PriorityMiddleware
+  def call(worker_class, msg, queue, redis_pool)
+    if Sidekiq::Hierarchy.current_workflow[:important]
+      queue = :ultrahigh  # override worker's preset queue
+    end
+    yield worker_class, msg, queue, redis_pool
+  end
+end
+```
+
+- Make sure the middleware is nested **inside** the Sidekiq-hierarchy client middleware in the Sidekiq config.
+
+That's all it takes! 
+
+## Callbacks
+
+Sidekiq-hierarchy implements a simple pub/sub events system that currently publishes on two topics: `Sidekiq::Hierarchy::Notifications::JOB_UPDATE` and `Sidekiq::Hierarchy::Notifications::WORKFLOW_UPDATE`. These topics see messages whenever a status change occurs for any job or workflow, respectively.
+
+Observers on `:job_update` are called with `(job, status, old_status)`, while `:workflow_update` observers receive `(workflow, status, old_status)`. An observer can be anything that supports a #call method with the necessary signature: a class instance will suffice, as will a simple `Proc`. 
+
+To register an observer, add it to the global callback registry at any point (initialization usually makes the most sense). For example, to subscribe to the `:job_update` event, you could do:
+
+```ruby
+class JobPrinter
+  def call(job, status, old_status)
+    Rails.logger.log "#{job.jid} switched from #{old_status} to #{status}"
+  end
+end
+  
+end
+Sidekiq::Hierarchy.callback_registry
+  .subscribe(Sidekiq::Hierarchy::Notifications::JOB_UPDATE, JobPrinter.new)
+```
+
+or
+
+```ruby
+job_printer = Proc.new do |job, status, old_status|
+  Rails.logger.log "#{job.jid} switched from #{old_status} to #{status}"
+end
+Sidekiq::Hierarchy.callback_registry
+  .subscribe(Sidekiq::Hierarchy::Notifications::JOB_UPDATE, job_printer)
+
+```
+
+Callbacks are triggered sequentially and synchronously, so if you are doing anything slow (e.g., a network call), you might consider moving it to an async task.
+
+Note: Sidekiq-hierarchy makes use of callbacks internally to drive some of its own logic as well. Each subscriber is wrapped in an exception handler to ensure that all subscribers will run at each event publication, even if one or more raise errors.
+
+## Network integration
+
+A somewhat common pattern with Sidekiq is moving network calls to async jobs, preventing the network's synchronous nature from holding up workers. However, if the network endpoint triggers additional jobs, those child will no longer be linked to their parent, as the worker context is lost. Sidekiq-hierarchy solves this with a set of two optional middlewares: one for Rack (deciphering context from inbound requests) and one instrumenting Faraday (passing context in HTTP headers). Together, they transparently bridge the network gap, ensuring that jobs triggering other jobs over a network hop are recorded correctly.
+
+The network integration is not loaded by default. To use it, require `sidekiq/hierarchy/rack/middleware` and `sidekiq/hierarchy/faraday/middleware` (making sure `Rack` and `Faraday` are loaded), then insert them in the appropriate places. For Rails, the Rack middleware will usually go in `config/application.rb`:
+```ruby
+class Application < Rails::Application
+  # ...
+  config.middleware.use Sidekiq::Hierarchy::Rack::Middleware
+  # ...
+end
+```
+
+For Faraday, the connection object should be modified before use:
+```ruby
+Faraday.new do |f|
+  # ...
+  f.use Sidekiq::Hierarchy::Faraday::Middleware
+  # ...
+end
+```
+
+In the background, Sidekiq-hierarchy inserts and decodes two headers:
+
+- Sidekiq-Jid: the job id of the parent worker, if any
+- Sidekiq-Workflow: the workflow JID, if tracking is enabled (`workflow: true` in sidekiq_options)
+
+Even if you are not using Faraday, adding these headers should be easy with your network library of choice.
+
+## Advanced Options
+
+There are a couple of additional configuration options you may want to use, depending on your needs:
+
+###Additional Job Info
+
+By default, Sidekiq-hierarchy only retains two pieces of information from each job, namely the class and queue. A full job hash in Sidekiq is much richer, but storing the full thing will take significantly more space (especially if you enable backtrace recording in the worker options). If there are additional pieces you need (for instance, the argument list could be quite useful), you can specify these per job:
+
+```ruby
+  sidekiq_options workflow_keys: ['args']
+```
+
+The list of keys must be an array of strings, which will be merged with `['class', 'queue']` (the default).
+
+###CompleteSet and FailedSet
+
+While the `RunningSet` is never pruned, so that in-progress workflows will never lose information, completed and failed workflows must be pruned to prevent running out of space in Redis (though note, all keys used expire in one month, so don't expect data to stick around past that time regardless!). Sidekiq itself does not have this issue, since jobs are thrown away after completion, but this is obviously impossible for Sidekiq-hierarchy (else workflows would lose jobs as they completed).
+
+Two pruning strategies are employed, running on every workflow insertion: one which trims workflows older than a certain time, one which trims workflows past a certain count. These limits can be accessed as `CompleteSet.timeout` and `CompleteSet.max_workflows` (likewise for `FailedSet`, which shares the limits). These are set from global Sidekiq settings as follows:
+
+- `timeout`: `:dead_timeout_in_seconds` setting, also used by Sidekiq to prune dead jobs (default 6 months)
+- `max_workflows`: the first of `:dead_max_workflows` and `:dead_max_jobs`, whichever is set; the latter is used internally by Sidekiq to prune dead jobs (`:dead_max_jobs` default 10,000)
+
+## More Examples
+
+These are just a few ways in which Sidekiq-hierarchy could help you:
+
+###Fail-fast workflow cancellation
+
+Let's say you want to enable workflow cancellation: if one job in a workflow fails, you can safely avoid running any of the others. Assuming Sidekiq-hierarchy is installed and running, we can do this with two middlewares.
+
+On the server side, _inside_ the hierarchy middleware to ensure variables are set:
+```ruby
+class FailFast::ServerMiddleware
+  def call(worker, job, queue)
+    current_jid = Sidekiq::Hierarchy.current_jid
+    workflow = Sidekiq::Hierarchy.current_workflow
+    return if workflow && workflow[:fail_fast]
+    
+    yield
+    
+  rescue => e
+    if workflow && Sidekiq::Hierarchy::Job.find(current_jid).failed?
+      workflow[:fail_fast] = '1'
+    end
+    raise  # make sure to propagate exception up
+  end
+end
+```
+
+On the client side, _inside_ the hierarchy middleware (remember to install client middleware on both the server and client):
+```ruby
+class FailFast::ClientMiddleware
+  def call(worker_class, msg, queue, redis_pool)
+    workflow = Sidekiq::Hierarchy.current_workflow
+    return false if workflow && workflow[:fail_fast]  # don't bother queueing
+    yield
+  end
+end
+```
+
+The server middleware will flag the workflow on any non-retriable failure. Meanwhile, the client middleware pre-emptively cancels queuing any job according to the flag, and the server middleware refuses to execute jobs on cancelled workflows.
+
+###Workflow Metrics Dashboard
+
+Every workflow has a canonical representation given by `#as_json`/`#to_s` (depending on desired format), which will be the same for a given set of tree of jobs regardless of their actual queuing and execution order. This representation disambiguates by job class and child set. For example, a `ParentWorker` that kicked off two `ChildWorker`s would have the representation
+
+    "{\"k\":\"ParentWorker\",\"c\":[{\"k\":\"ChildWorker\",\"c\":[]},{\"k\":\"ChildWorker\",\"c\":[]}]}"
+
+Let's put workflow metrics in [StatsD](https://github.com/etsy/statsd), an easy-to-use metrics collector. Assuming we've already set up our statsd client as `$statsd`, we can push the timing info collected by Sidekiq-hierarchy with a few lines of code in an initializer (plugging into the pub/sub system):
+
+```ruby
+require 'zlib'
+
+metrics_pusher = Proc.new do |workflow, status, old_status|
+  if status == :complete
+    uniq_repr = Zlib.crc32(workflow.to_s)
+    time_in_ms = (workflow.complete_at - workflow.run_at) * 1000
+    $statsd.timing("workflows:#{uniq_repr}", time_in_ms)
+  end
+end
+
+Sidekiq::Hierarchy.callback_registry.subscribe(Sidekiq::Hierarchy::Notifications::WORKFLOW_UPDATE, metrics_pusher)
+```
+
+Using something like [Graphite](http://graphite.wikidot.com/), we can then analyze the results in realtime, accessing stats like minimum, mean, maximum, and 95th percentile runtime. You'll probably want to keep a CRC32 -> workflow mapping handy; a simple hashmap (or Redis hash, hint hint) will suffice nicely.
+
+## Installation
+
+Add this line to your application's Gemfile:
+
+```ruby
+gem 'sidekiq-hierarchy'
+```
+
+And then execute:
+
+    $ bundle
+
+Or install it yourself as:
+
+    $ gem install sidekiq-hierarchy
+
+If you want to use the network bridge, you'll need `faraday` as well; if you're using the web UI, make sure `sinatra` is installed.
+
+## Development
+
+After checking out the repo, run `bin/setup` to install dependencies. Then, run `rake spec` to run the tests. You can also run `bin/console` for an interactive prompt that will allow you to experiment.
+
+To install this gem onto your local machine, run `bundle exec rake install`. 
+
+## License
+
+The gem is available as open source under the terms of the [MIT License](http://opensource.org/licenses/MIT).