“Freedom is the recognition of contingency.”
- Richard M. Rorty
Contingency is the custom error page controller you’ve implemented in every project you’ve ever written. It’s compatibile with every framework you’ve ever implemented a project in. A Contingency Plan has been written for every Ruby framework you’re familiar with. And odds are, its better tested than your implementation.
So for the love of god, stop implementing it yourself.
It’s quick to get started, gives you full customization over Exception coverage, gives you full control over rendering your own error page, and has a contingency plan itself in the event that your custom error views trigger an Exception.
It’s also very lightweight: the core functionality (the module in contingency/plan.rb) is less than 50 lines; and only adds 3 integration methods, 2 helper methods, and 1 controller action method to your controller. Everything but the controller method is private. The rest of the codebase else is just a matter of integration. It’s a hard codebase to get lost in.
Experience true freedom, and make yourself a Contingency Plan.
- Installation
- Configuration
- Supported Integrations
- Custom Integrations
- Versioning
- Contributing Integrations
- Contributing to Contingency
- Credits
Add these lines to your application’s Gemfile:
gem 'contingency', '~> 1.0'
gem 'contingency_my-framework-name', '~> x.0'
…where my-framework-name is the name of your framework.
Then, execute:
$ bundle
Contingency
| Contingency Plan | Integration Quality | Version | Maintainer |
| Rails | Poor | 0.0.1 | christhekeele |
If the framework you’re using doesn’t have a Contingency Plan integration, you’re only 3 methods away from integrating it yourself.
It’s easy to integrate Contingency into your own app. Contingency only relys on 3 methods to communicate with your framework:
If you decide to go through this trouble, you really should consider contributing your Contingency Plan integration to Contingency.</a> I’ll be more than happy to help you develop your integration until it meets our minimum quality standards, if it doesn’t out-of-the-box.
Contingency itself is versioned as it changes. It bumps its major version as its API changes, which is rarely, as its public API only requires 3 methods. It uses symantic versioning. This means you should safely be able to install it with loose bundler dependencies.
Contingency Plans should be versioned with their frameworks. Integrations that follow this simple requirement are labeled as great.
Contingency Plans that keep up with at least the major version of their framework will result in the integration being labeled as good.
Contingency Plans that fail to keep up with the major version of their framework will result in the integration being labeled as poor.
Contingency Plans that throw off the shackles of symantic versioning and don’t follow it from the get-go, Pull Request, or fall very behind will result in the integration being labeled as bad.
I keep up with these frameworks through the Bundle Scout. You should, too! Checkest thineself lest thy wrekest thineself.
See contingency_rails as an example.
- Create a new gem named after your framework (
bundle gem contingency-my_integration) - Add Contingency as a dependency to your gemspec and bundle install
- Generate an integration template (
bundle exec rake contingency:generate:plan[my_integration]) - Implement the 3 methods that rake instructs you to
- Commit your changes (
git commit -am 'Created my_integration') - Push (
git push origin master) - Follow the steps below to add autoloading your Contingency Plan in Contingency core and wait get your Pull Request accepted
- Create the intital build of your gem (
gem build contingency-my_integration) - Release your gem (
gem push contingency-my_integration.gem) - Revel in the fact that you’ve provided a Contingency Plan for you and yours
- Continue to mantain your integration over time by handling API changes and bumping the version number in accordance with the framework, lest your integration be marked as deprecated.
## Contributing to Contingency
- Fork it
- Create your feature branch (
git checkout -b my-new-feature) - Add the name of your integration to the integrations array in the contingency/integration.rb file if you’re contributing a Contingency Plan
- Commit your changes (
git commit -am 'Add some feature') - Push to the branch (
git push origin my-new-feature) - Create new Pull Request
- I tell you to go back and write some tests if you haven’t already
- I tell you to go back and update the README.md if you haven’t already
- I accept your Pull Request
- None, aside from the creator. Be the first!!
- Thanks to nathanl and his excellent authorization gem, Authority, the structure of which inspired this one.
- Thanks to ryanb, and his subscription-worthy Railscasts, which have inspired us all. Especially us Pro users.