# A9n

[![Gem Version](https://badge.fury.io/rb/a9n.png)][gem_version]
[![Build status](https://secure.travis-ci.org/knapo/a9n.png)][travis]
[![Code Climate](https://codeclimate.com/github/knapo/a9n.png)][codeclimate]
[![Coverage Status](https://codeclimate.com/github/knapo/a9n/coverage.png)][coverage]

[gem_version]: https://rubygems.org/gems/a9n
[travis]: http://travis-ci.org/knapo/a9n
[codeclimate]: https://codeclimate.com/github/knapo/a9n
[coverage]: https://codeclimate.com/github/knapo/a9n

A9n is a simple tool to keep ruby/rails apps configuration maintanable and verifiable. It supports Rails 2.x, 3.x, 4.x and Ruby 1.9, 2.0. 2.1. Ruby 1.8 is not supported since version 0.1.2.

Why it's named a9n? It's a numeronym for application (where 9 stands for the number of letters between the first **a** and last **n**, similar to i18n or l10n).

## Installation

Add this line to your application's Gemfile:

    gem 'a9n'

And then execute:

    $ bundle

Add `configuration.yml.example` and/or `configuration.yml` file into the config
directory. When none fo these files exists, `A9n::MissingConfigurationFile`
exception is thrown.
If both file exist, content of `configuration.yml` is validated. It means that
all keys existing in example file must exist in local file - in case of missing
keys `A9n::MissingConfigurationVariables` is thrown with the explanation what is missing.

Set application root and load configuration by adding to your `application.rb` or `environment.rb` right
after budler requires:

    A9n.root = File.expand_path('../..', __FILE__)
    A9n.load

This step is not required ,if you don't use `a9n` in the environment settings or initializers.
It works with `Rails` by default. If you want to use `A9n` with non-rails app
you may need to tell that to A9n by:

    A9n.local_app = MyApp

## Usage

You can access any variable defined in configuration files by delegating it to
`A9n`. E.g:

    defaults:
      email_from: 'no-reply@knapo.net'
    production:
      app_host: 'knapo.net'
    development:
      app_host: 'localhost:3000'

is accessible by:

    A9n.app_host   # => `knapo.net` in production and `localhost:3000` in development
    A9n.email_from # => `no-reply@knapo.net` in both envs

## Custom and multiple configuration files

If you want to split configuration, you can use multiple files. All files from `config/a9n` are loaded by default, but you may pass custom paths as an argument to `A9n.load` e.g. `A9n.load('config/facebook.yml', 'config/mongoid.yml')`. In such cases config items are accessible through the scope consistent with the file name.

E.g. if you have `config/a9n/mandrill.yml`:

     defaults:
       username: "joe"
       api_key: "1234asdf"

You can access it by:

     A9n.mandrill.username # => `joe`
     A9n.mandrill.api_key # => `1234asdf`


## Capistrano

If you use capistrano and you feel safe enough to keep all your instance ( staging, production) configuration in the repository, you may find it useful to use capistrano extensions.
Just add an instance configuration file e.g. `configuration.yml.staging`, `configuration.yml.production` (NOTE: file extension must be consistent with the capistrano stage) and add

    require 'a9n/capistrano'

to your Capfile. This way `configuration.yml.<stage>` overrides `configuration.yml` on each deploy.

## Contributing

1. Fork it
2. Create your feature branch (`git checkout -b my-new-feature`)
3. Commit your changes (`git commit -am 'Added some feature'`)
4. Push to the branch (`git push origin my-new-feature`)
5. Create new Pull Request