chamber 2.4.0 → 2.7.1

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA1:
-  metadata.gz: a19c582ad4ae2594ba0dfcfd503c23f9232e6b9a
-  data.tar.gz: 995cacf1dd2e6e76b8164c07baf30da73dda1c63
+  metadata.gz: e4a3d686721e6b3ccbf6352227cfa0a6bdfb2b43
+  data.tar.gz: 798f1cec12ea2648a916d7830739f0ef50647679
 SHA512:
-  metadata.gz: 6ad8ca10bb03ddbe3d74956a4b7dd2b1e3fccfa284cab7371f7e095593e8cb360a5b2ae58fa5b1ea003ced8f7cac001b4beca10b92c39b0fb0fd17278e30e435
-  data.tar.gz: 79881de27b677269a5ace887a04f1deeb295fa80dffe81e825b68a64c07f11e6d207549b097e355d79fb0d5e6adc784648be4db444de6b611fac28aff3002172
+  metadata.gz: 68c4c8c96652a068514f1ac17edda03d06977b11dfc776f06d4b5f39fd75a579efde318806c29d8169d899f562bd75cd41de743b81d088b7721af2afc4adf197
+  data.tar.gz: 0de18f64eb779247df51a06085287f73eaf56acd9662a1643e75a5b5864c4cfc060a46ce6562f2ee67ad23560d9dfab4d39b64fcb3f43fd1d99b5f946b838b89

data/README.md

@@ -4,942 +4,28 @@ Chamber is the auto-encrypting, extremely organizable, Heroku-loving, CLI-having
 non-extra-repo-needing, non-Rails-specific-ing, CI-serving configuration
 management library.
 
-## But What About Those Other Configuration Management Gems?
-
-We reviewed [some other gems](#alternatives), and while each fit a specific need
-and each did some things well, none of them met all of the criteria that we felt
-we (and assumed others) needed.
+[![TrueFact](https://cloud.githubusercontent.com/assets/285582/4803823/ad8110fa-5e5e-11e4-90d6-59320045a786.png)](https://www.youtube.com/watch?v=NNG1OoH2RwE)
 
 **Our Ten Commandments of Configuration Management**
 
 <img src="https://akiajm7spx4gtbhaxe3qcomhaystacksoftwarearp.s3.amazonaws.com/photos/readmes/ten-commandments.png" align="right" />
 
-1. Thou shalt be configurable, but use conventions so that configuration isn't
-   necessary
-1. Thou shalt seamlessly work with Heroku or other deployment platforms, where custom
-   settings must be stored in environment variables
-1. Thou shalt seamlessly work with Travis CI and other cloud CI platforms
+1. Thou shalt be configurable, but [use conventions so that configuration isn't
+   necessary](https://github.com/thekompanee/chamber/wiki/Basic-Usage#convention-over-configuration)
+1. Thou shalt [seamlessly work with Heroku](https://github.com/thekompanee/chamber/wiki/Heroku) or other deployment platforms, where custom
+   settings must be stored in [environment variables](https://github.com/thekompanee/chamber/wiki/Environment-Variable-Compatibility)
+1. Thou shalt seamlessly work with [Travis CI](https://github.com/thekompanee/chamber/wiki/TravisCI) and other cloud CI platforms
 1. Thou shalt not force users to use arcane
-   long_variable_names_just_to_keep_their_settings_organized
-1. Thou shalt not require users keep a separate repo or cloud share sync just to
-   keep their secure settings updated
-1. Thou shalt not be bound to a single framework like Rails (it should be usable in
-   plain Ruby projects)
-1. Thou shalt have an easy-to-use CLI for scripting
+   [long_variables_to_keep_their_settings_organized](https://github.com/thekompanee/chamber/wiki/Accessing-Settings)
+1. Thou shalt not require users keep a separate repo or cloud share sync [just to
+   keep their secure settings updated](https://github.com/thekompanee/chamber/wiki/Encrypting-Your-Settings)
+1. Thou shalt not be bound to a single framework like Rails (it should be usable [in
+   plain Ruby projects](https://github.com/thekompanee/chamber/wiki/Basic-Usage#in-a-plain-old-ruby-project))
+1. Thou shalt have an [easy-to-use CLI](https://github.com/thekompanee/chamber/wiki/Command-Line-Reference) for scripting
 1. Thou shalt easily integrate with Capistrano for deployments
-1. Thou shalt be well documented with full test coverage
-1. Thou shalt not have to worry about accidentally committing secure settings
-
-## Installation
-
-Add this line to your application's Gemfile:
-
-```ruby
-gem 'chamber'
-```
-
-And then execute:
-
-```sh
-$ bundle
-```
-
-Or install it yourself as:
-
-```sh
-$ gem install chamber
-```
-
-Once the gem is installed, you'll want to add it to your project.  To do this,
-type:
-
-```sh
-chamber init
-```
-
-This creates a public/private keypair for you to use with your project.  The
-private key will be called `.chamber.pem`.  The public key will be called
-`.chamber.pem.pub`.
-
-`.chamber.pem` will be added to your gitignore file so that it is not
-accidentally checked in.  *Keep this file safe* since anyone who has it will be
-able to decrypt any settings that Chamber encrypts for you.
-
-Lastly, it will create a sample `settings.yml` file for you which you should
-modify as needed.
-
-## Basic Usage
-
-### Convention Over Configuration
-
-By default Chamber only needs a base path to look for settings files.  From
-that path it will search for:
-
-* The file `<basepath>/settings.yml`
-* A set of files ending in `.yml` in the `<basepath>/settings` directory
-
-### In Plain Old Ruby
-
-```ruby
-Chamber.load basepath: '/path/to/my/application'
-```
-
-### In Rails
-
-You do not have to do anything.  Chamber will auto-configure itself to point to
-the `config` directory.
-
-### Accessing Settings
-
-The YAML data will be loaded and you will have access to the settings
-through the `Chamber` class.
-
-**Example:**
-
-Given a `settings.yml` file containing:
-
-```yaml
-smtp:
-  server:   "example.com"
-  username: "my_user"
-  password: "my_pass"
-```
-
-can be accessed as follows:
-
-```ruby
-Chamber[:smtp][:server]
-# => example.com
-```
-
-or via object notation syntax:
-
-```ruby
-Chamber.env.smtp.server
-# => example.com
-```
-
-### Securing Your Settings
-
-Certain settings you will want to keep from prying eyes.  Unlike other
-configuration management libraries, Chamber doesn't require you to keep those
-files separate.  You can check *everything* into your repo.
-
-Why is keeping your secure files separate a pain?  Because you must keep those
-files in sync between all of your team members who are deploying the app.
-Either you have to use a separate private repo, or you have to use something
-like a Dropbox share.  In either case, you'd then symlink the files from their
-locations into your application.  What. A. Pain.
-
-Chamber uses public/private encryption keys to seamlessly store any of your
-configuration values as encrypted text.  The only file that needs to be synced
-*once* between developers is the private key.  And even that file would only be
-needed by the users deploying the application.  If you're deploying via CI,
-Github, etc, then technically no developer needs it.
-
-#### Working With Secure Configuration Settings
-
-After running `chamber init` as described above, the hard work is done.  From
-here on out, Chamber makes working with secure settings almost an afterthought.
-
-When you create your configuration YAML file (or add a new setting to an
-existing one), you can add a secure key by prefixing the key name with
-`_secure_`, like so:
-
-```yaml
-# settings.yml
-
-_secure_my_secure_key_name: 'my secure value'
-```
-
-To encrypt the secret with your key pair, use the `chamber secure` command:
-
-```sh
-$ chamber secure
-```
-
-This will replace the plaintext secret with an encrypted version, looking
-something like this:
-
-```yaml
-# settings.yml
-
-_secure_my_secure_key_name: 8239f293r9283r9823r92hf9823hf9uehfksdhviwuehf923uhrehf9238
-```
-
-Now, only users with the private key file can access the secret value. Once
-the private key is in your application's root directory, you can access the
-secret by name:
-
-```ruby
-Chamber.env.my_secure_key_name
-# => 'my secure value'
-```
-
-### Using Existing Environment Variables
-
-If deploying to a system which has all of your environment variables already set
-(eg Heroku), you're not going to use all of the values stored in the YAML files.
-Instead, you're going to want to pull certain values from environment variables.
-
-**Example:**
-
-Given a `settings.yml` file containing:
-
-```yaml
-smtp:
-  server:   "example.com"
-  username: "my_user"
-  password: "my_pass"
-```
-
-If an environment variable is already set like so:
-
-```sh
-export SMTP_SERVER="myotherserverisapentium.com"
-```
-
-Then, when you ask Chamber to give you the SMTP server:
-
-```ruby
-Chamber[:smtp][:server]
-# => "myotherserverisapentium.com"
-```
-
-It will return not what is in the YAML file, but what is in the environment
-variable.
-
-## Deploying to Heroku
-
-If you're deploying to Heroku, they won't let you upload custom config files. If
-you do not have your config files all stored in your repo, or some of your
-settings are encrypted, it becomes more difficult to gain access to that
-information on Heroku.
-
-To solve this problem, Heroku allows you to set environment variables in your
-application.  Unfortunately this has the nasty side effect of being a pain to
-deal with.  For one, you have to deal with environment variables with unwieldy
-names (eg `MY_THIRD_PARTY_SERVICE_DEV_API_KEY`).  For another, it makes the
-organization of those variables difficult.
-
-Fortunately, Chamber allows you to organize your environment variables in
-separate files and access them easily using hash or object notation, however at
-the same time, it provides a convenient way to push all of those sensitive
-configuration settings up to Heroku as environment variables.
-
-When Chamber accesses those same hash/object notated config values, it will
-first look to see if an associated environment variable exists.  If it does, it
-will use that in place of any values inside of the config files as [described
-above](#using-existing-environment-variables).
-
-To update Heroku with all the proper environment variables so that your app
-works as expected, run the following from the root of your app:
-
-```sh
-chamber heroku push
-```
-
-And all of your settings will be converted to environment variable versions
-and set on your Heroku app.
-
-_**Note:** For the full set of options, see [The chamber Command Line
-App](#the-chamber-command-line-app) below._
-
-## Deploying to Travis CI
-
-When deploying to Travis CI, it has similar environment variable requirements as
-Heroku, however Travis allows the encryption of environment variables before
-they are stored in the .travis.yml file.  This allows for that file to be
-checked into git without worrying about prying eyes figuring out your secret
-information.
-
-To execute this, simply run:
-
-```sh
-chamber travis secure
-```
-
-This will add `secure` entries into your `.travis.yml` file.  Each one will
-contain one environment variable.
-
-_**Warning:** Each time you execute this command it will delete all secure
-entries under 'env.global' in your `.travis.yml` file._
-
-_**Note:** For the full set of options, see [The chamber Command Line
-App](#the-chamber-command-line-app) below._
-
-## Advanced Usage
-
-### Explicitly Specifying Settings Files
-
-Using convention over configuration, Chamber handles the 90% case by default,
-however there may be times at which you would like to explicitly specify which
-settings files are loaded.  In these cases, Chamber has you covered:
-
-```ruby
-Chamber.load files: [
-                      '/path/to/my/application/chamber/credentials.yml',
-                      '/path/to/my/application/application*.yml',
-                      '/path/to/my/application/chamber/*.yml',
-                    ]
-```
-
-In this case, Chamber will load *only* the `credentials.yml` file *without ever*
-looking for a namespaced file.  Then it will load `application.yml` *and* any
-associated namespaced files.  Finally it will load all \*.yml files in the
-`chamber` directory *except* `credentials.yml` because it has previously been
-loaded.
-
-### Predicate Methods
-
-When using object notation, all settings have `?` and `_` predicate methods
-defined on them.  They work like so:
-
-#### '?' Predicates Check For Falsity
-
-```ruby
-  Chamber.env.my_setting                    # => nil
-  Chamber.env.my_setting?                   # => false
-
-  Chamber.env.my_other_setting              # => false
-  Chamber.env.my_other_setting?             # => false
-
-  Chamber.env.another_setting               # => 'my value'
-  Chamber.env.another_setting?              # => true
-```
-
-#### '\_' Predicates Allow for Multi-Level Testing
-
-```ruby
-  Chamber.env.empty?                        # => true
-  Chamber.env.my_setting_group_.my_setting? # => false
-```
-
-#### 'key?' Checks For Existence
-
-The `?` method will return false if a key has been set to `false` or `nil`. In
-order to check if a key has been set at all, use the `key?('some_key')` method
-instead.
-
-Notice the difference:
-
-```ruby
-  Chamber.env.my_setting                    # => false
-  Chamber.env.my_setting?                   # => false
-
-  Chamber.env.key?('my_setting')            # => true
-  Chamber.env.key?('my_non_existent_key')   # => false
-```
-
-### ERB Preprocessing
-
-One of the nice things about Chamber is that it runs each settings file through
-ERB before it tries to parse it as YAML.  The main benefit of this is that you
-can use settings from previous files in ERB for later files.
-
-**Example:**
-
-```yaml
-# settings.yml
-
-production:
-  my_secret_key: 123456789
-```
-
-```erb
-<%# settings/some_service-production.yml %>
-
-my_service_url: http://my_username:<%= Chamber[:my_secret_key] %>@my-url.com
-```
-
-Because by default Chamber processes `settings*.yml` settings files before
-anything in the `settings` subdirectory, this works.
-
-But it's all ERB so you can do as much crazy ERB stuff in your settings files as
-you'd like:
-
-```erb
-<%# settings.yml %>
-
-<% %w{development test production}.each do |environment| %>
-<%= environment %>:
-  hostname_with_subdomain: <%= environment %>.example.com:3000
-
-<% end %>
-```
-
-Would result in the following settings being set:
-
-```yaml
-development:
-  hostname_with_subdomain: development.example.com:3000
-
-test:
-  hostname_with_subdomain: test.example.com:3000
-
-production:
-  hostname_with_subdomain: production.example.com:3000
-```
-
-### Namespacing
-
-If, when running your app, you would like to have certain files loaded only
-under specific circumstances, you can use Chamber's namespaces.
-
-**Example:**
-
-```ruby
-Chamber.load( :basepath   => Rails.root.join('config'),
-              :namespaces => {
-                :environment => ::Rails.env } )
-```
-
-For this class, it will not only try and load the file `config/settings.yml`,
-it will _also_ try and load the file `config/settings-<environment>.yml`
-where `<environment>` is whatever Rails environment you happen to be running.
-
-#### Inline Namespaces
-
-If having a file per namespace value isn't your thing, you can inline your
-namespaces.  Taking the example from above, rather than having `settings.yml`,
-`settings-development.yml`, `settings-test.yml`, `settings-staging.yml` and
-`settings-production.yml`, you could do something like this:
-
-```yaml
-# settings.yml
-
-development:
-  smtp:
-    username: my_development_username
-    password: my_development_password`
-
-test:
-  smtp:
-    username: my_test_username
-    password: my_test_password`
-
-staging:
-  smtp:
-    username: my_staging_username
-    password: my_staging_password`
-
-production:
-  smtp:
-    username: my_production_username
-    password: my_production_password`
-```
-
-You can even mix and match.
-
-```yaml
-# settings.yml
-
-development:
-  smtp:
-    username: my_development_username
-    password: my_development_password`
-
-test:
-  smtp:
-    username: my_test_username
-    password: my_test_password`
-
-staging:
-  smtp:
-    username: my_staging_username
-    password: my_staging_password`
-```
-
-```yaml
-# settings-production.yml
-
-smtp:
-  username: my_production_username
-  password: my_production_password`
-````
-
-The above will yield the same results, but allows you to keep the production
-values in a separate file which can be secured separately. Although I would
-recommend keeping everything together and just [encrpyting your sensitive
-info](#securing-your-settings)
-
-If you would like to have items shared among namespaces, you can easily use
-YAML's built-in merge functionality to do that for you:
-
-```yaml
-# settings.yml
-
-default: &default
-  smtp:
-    headers:
-      X-MYAPP-NAME: My Application Name
-      X-MYAPP-STUFF: Other Stuff
-
-development:
-  <<: *default
-  smtp:
-    username: my_development_username
-    password: my_development_password`
-
-test:
-  <<: *default
-  smtp:
-    username: my_test_username
-    password: my_test_password`
-
-staging:
-  <<: *default
-  smtp:
-    username: my_staging_username
-    password: my_staging_password`
-```
-
-#### Multiple Namespaces
-
-Multiple namespaces can be defined by passing multiple items to the loader:
-
-```ruby
-Chamber.load( :basepath => Rails.root.join('config'),
-              :namespaces => {
-                :environment => ::Rails.env,
-                :hostname    => ENV['HOST'] } )
-```
-
-When accessed within the `test` environment on a system named `tumbleweed`, it
-will load the following files in the following order:
-
-* `settings.yml`
-* `settings-test.yml`
-* `settings-tumbleweed.yml`
-
-If a file does not exist, it is skipped.
-
-#### What Happens With Duplicate Entries?
-
-Similarly named settings in later files can override settings defined in earlier
-files.
-
-If `settings.yml` contains a value:
-
-```yaml
-smtp:
-  server: "generalserver.com"
-```
-
-And then `settings-test.yml` contains this:
-
-```yaml
-smtp:
-  server: "testserver.com"
-```
-
-The when you access the value with `Chamber[:smtp][:server]` you will receive
-`testserver.com`.
-
-### Outputting Your Settings
-
-Chamber makes it dead simple to output your environment settings in a variety of
-formats.
-
-The simplest is:
-
-```ruby
-Chamber.to_s
-# => MY_SETTING="my value" MY_OTHER_SETTING="my other value"
-```
-
-But you can pass other options to customize the string:
-
-* `pair_separator`
-* `value_surrounder`
-* `name_value_separator`
-
-```ruby
-Chamber.to_s pair_separator:        "\n",
-             value_surrounder:      "'",
-             name_value_separator:  ': '
-
-# => MY_SETTING: 'my value'
-# => MY_OTHER_SETTING: 'my other value'
-```
-
-### The chamber Command Line App
-
-Chamber provides a flexible binary that you can use to make working with your
-configurations easier.  Let's take a look:
-
-#### Common Options
-
-Each of the commands described below takes a few common options.
-
-* `--preset` (or `-p`): Allows you to quickly set the basepath, files and/or
-  namespaces for a given situation (eg working with a Rails app).
-
-  **Example:** `--preset=rails`
-
-* `--rootpath` (or `-r`): Allows you to quickly set the rootpath of the
-  application. By default this is the directory that the `chamber` executable is
-  run from.
-
-  **Example:** `--rootpath=/path/to/my/application`
-
-* `--basepath` (or `-b`): Sets the base path that Chamber will use to look for
-  its [common settings files](#convention-over-configuration).
-
-  **Example:** `--basepath=/path/to/my/application`
-
-* `--files` (or `-f`): Allows you to specifically set the file patterns that
-  Chamber should look at in determining where to load settings information from.
-
-  **Example:** `--files=/path/to/my/application/secret.yml /path/to/my/application/settings/*.yml`
-
-* `--namespaces` (or `-n`): The namespace values which will be considered for
-  loading settings files.
-
-  **Example:** `--namespaces=development tumbleweed`
-
-* `--encryption-key`: The path to the key which will be used for encryption.
-  This is optional unless you need to secure any settings.
-
-  Additionally you may pass in the actual contents of the key for this option.
-
-  **Example:** `--keypair=/path/to/my/app/my_project_rsa.pub`
-
-* `--decryption-key`: The path to the key which will be used for decryption.
-  This is optional unless you need to decrypt any settings.
-
-  Additionally you may pass in the actual contents of the key for this option.
-
-  **Example:** `--keypair=/path/to/my/app/my_project_rsa`
-
-_**Note:** `--basepath` and `--files` are mutually exclusive. `--files` will
-always take precedence._
-
-#### Somewhat Common Options
-
-_**Note:** Only select commands support the following options. Use `chamber help
-  SUBCOMMAND` to verify if a particular command does._
-
-* `--dry-run` (or `-d`):  The command will not actually execute, but will show
-  you a summary of what *would* have happened.
-
-  **Example:** `--dry-run`
-
-* `--only-secured` (or `-o`): This is the default. Because most systems have no
-  issues reading from the config files you have stored in your repo, there is no
-  need to process *all* of your settings.  So by default, Chamber will only
-  convert, push, etc those settings which have been gitignored or those which
-  have been encrpyted.
-
-  To process everything, use the `--skip-secure-only` flag.
-
-  **Example:** `--secure-only`, `--skip-secure-only`
-
-#### Settings
-
-##### Settings Commands
-
-###### Show
-
-Gives users an easy way of looking at all of the settings that Chamber knows
-about for a given context.  It will be output as a hash of hashes by default.
-
-* `--as-env`: Instead of outputting the settings as a hash of hashes, convert
-  the settings into environment variable-compatible versions.
-
-  **Example:** `--as-env`
-
-**Example:** `chamber show --as-env`
-
-###### Files
-
-Very useful for troubleshooting, this will output all of the files that
-Chamber considers relevant based on the given options passed.
-
-Additionally, the order is significant.  Chamber will load settings from the
-top down so any duplicate items in subsequent entries will override items from
-previous ones.
-
-**Example:** `chamber files`
-
-###### Secure
-
-Will verify that any items which are marked as secure (eg `_secure_my_setting`)
-have secure values.  If it appears that one does not, the user will be prompted
-as to whether or not they would like to encrpyt it.
-
-This command differs from other tasks in that it will process all files that
-match Chamber's conventions and not just those which match the passed in
-namespaces.
-
-**Example:** `chamber secure`
-
-###### Compare
-
-Will display a diff of the settings for one set of namespaces vs the settings
-for a second set of namespaces.
-
-This is extremely handy if, for example, you would like to see whether the
-settings you're using for development match up with the settings you're using
-for production, or if you're setting all of the same settings for any two
-environments.
-
-* `--keys-only`: This is the default.  When performing a comparison, only the
-  keys will be considered since values between namespaces will often (and
-  should often) be different.
-
-  **Example:** `--keys-only`, `--no-keys-only`
-
-* `--first`: This is an array of the first set of namespace settings that you
-  would like to compare from.  You can list one or more.
-
-  **Example:** `--first=development`, `--first=development my_host_name`
-
-* `--second`: This is an array of the second set of namespace settings that
-  you would like to compare against that specified by `--first`.  You can list
-  one or more.
-
-  **Example:** `--second=staging`, `--second=staging my_host_name`
-
-**Example:** `chamber compare --first=development --second=staging`
-
-###### Init
-
-Init can be used to initialize a new application/project with everything that
-Chamber needs in order to run properly.  This includes:
-
-* Creating a public/private keypair
-* Setting the proper permissions on the the newly created keypair
-* Adding the private key to the gitignore file
-* Creating a template `settings.yml` file
-
-**Example:** `chamber init`
-
-#### Heroku
-
-As we described above, working with Heroku environment variables is tedious at
-best.  Chamber gives you a few ways to help with that.
-
-##### Heroku Common Options
-
-* `--app` (or `-a`): Heroku application name for which you would like to affect
-  its environment variables.
-
-  **Example:** `--app=my-heroku-app-name`
-
-##### Heroku Commands
-
-###### Push
-
-As we described above, this command will take your current settings and push
-them to Heroku as environment variables that Chamber will be able to
-understand.
-
-**Example:** `chamber heroku push --namespaces=production --app=my-heroku-app`
-
-_**Note:** To see exactly how Chamber sees your settings as environment variables, see
-the [chamber settings show](#settings-commands) command above._
-
-###### Pull
-
-Will display the list of environment variables that you have set on your
-Heroku instance.
-
-This is similar to just executing `heroku config --shell` except that you can
-specify the following option:
-
-* `--into`: The file which the pulled settings will be copied into.  This file
-  *will* be overridden.
-
-  _**Note:** Eventually this will be parsed into YAML that Chamber can load
-  straight away, but for now, it's basically just redirecting the output._
-
-  **Example:** `--into=/path/to/my/app/settings/heroku.config`
-
-**Example:** `chamber heroku pull --app=my-heroku-app --into=/path/to/my/app/heroku.config`
-
-###### Diff
-
-Will use git's diff function to display the difference between what Chamber
-knows about locally and what Heroku currently has set.  This is very handy for
-knowing what changes may be made if `chamber heroku push` is executed.
-
-**Example:** `chamber heroku diff --namespaces=production --app=my-heroku-app`
-
-###### Clear
-
-Will remove any environment variables from Heroku that Chamber knows about.
-This is useful for clearing out Chamber-related settings without touching
-Heroku addon-specific items.
-
-**Example:** `chamber heroku clear --namespaces=production --app=my-heroku-app`
-
-#### Travis CI
-
-##### Travis Commands
-
-###### Secure
-
-Travis CI allows you to use the public key on your Travis repo to encrypt items
-as environment variables which you would like for Travis to be able to have
-access to, but which you wouldn't necessarily want to be in plain text inside of
-your repo.
-
-This command takes the settings that Chamber knows about, encrypts them, and
-puts them inside of your .travis.yml at which point they can be safely
-committed.
-
-_**Warning:** This will delete *all* of your previous 'secure' entries under
-'env.global' in your .travis.yml file._
-
-**Example:** `chamber travis secure --namespaces=continuous_integration`
-
-### Basic Boolean Conversion
-
-One of the things that is a huge pain when dealing with environment variables is
-that they can only be strings.  Unfortunately this is kind of a problem for
-settings which you would like to use to set whether a specific item is enabled
-or disabled.  Because this:
-
-```yaml
-# settings.yml
-
-my_feature:
-  enabled: false
-```
-
-```ruby
-if Chamber.env.my_feature.enabled?
-  # Do stuff with my feature
-end
-```
-
-Now because environment variables are always strings, `false` becomes `'false'`.
-And because, as far as Ruby is concerned, any `String` is `true`, `enabled?`
-would return `true`.  Now, you could completely omit the `enabled` key, however
-this causes issues if you would like to audit your settings (say for each
-environment) to make sure they are all the same.  Some will have the `enabled`
-setting and some will not, which will give you false positives.
-
-You could work around it by doing this:
-
-```ruby
-if Chamber.env.my_feature.enabled == 'true'
-  # Do stuff with my feature
-end
-```
-
-but that looks awful and isn't very idiomatic.
-
-To solve this problem, Chamber reviews all of your settings values and, if they
-are any of the following exact strings (case insensitive):
-
-* 'false'
-* 'f'
-* 'no'
-* 'true'
-* 't'
-* 'yes'
-
-The value will be converted to the proper Boolean value.  In which case the
-above `Chamber.env.my_feature.enabled?` will work as expected and your
-environment audit will pass.
-
-### In Order to Add Advanced Functionality
-
-In any case that you need to set configuration options or do advanced post
-processing on your YAML data, you'll want to create your own object for
-accessing it.  Don't worry, Chamber will take you 98% of the way there.
-
-Just include it like so:
-
-```ruby
-class Settings
-  extend Chamber
-end
-```
-
-Now, rather than using `Chamber[:application_host]` to access your
-environment, you can simply use `Settings[:application_host]`.
-
-## Best Practices
-
-### Organizing Your Settings
-
-We recommend starting with a single `settings.yml` file. Once this file begins
-to become too unwieldy, you can begin to extract common options (let's say SMTP
-settings) into another file (perhaps `settings/smtp.yml`).
-
-### Full Example
-
-Let's walk through how you might use Chamber to configure your SMTP settings:
-
-```yaml
-# config/settings.yml
-
-stuff:
-  not: "Not Related to SMTP"
-```
-
-```yaml
-# config/settings/smtp.yml
-
-default: &shared
-  smtp:
-    headers:
-      X-MYAPP-NAME: My Application Name
-      X-MYAPP-STUFF: Other Stuff
-
-development:
-  <<: *shared
-  smtp:
-    username: my_dev_user
-    password: my_dev_password
-
-staging:
-  <<: *shared
-  smtp:
-    _secure_username: my_staging_user
-    _secure_password: my_staging_password
-
-production:
-  <<: *shared
-  smtp:
-    _secure_username: my_production_user
-    _secure_password: my_production_password
-```
-
-Now, assuming you're running in staging, you can access both `username` and
-`headers` off of `smtp` like so:
-
-```ruby
-Chamber[:smtp][:headers]
-# => { X-MYAPP-NAME: 'My Application Name', X-MYAPP-STUFF: 'Other Stuff' }
-
-Chamber[:smtp][:username]
-# => my_staging_username
-
-Chamber[:smtp][:password]
-# => my_staging_password
-```
-
-## Alternatives
-
-* [dotenv](https://github.com/bkeepers/dotenv)
-* [figaro](https://github.com/laserlemon/figaro)
-* [idkfa](https://github.com/bendyworks/idkfa)
-* [settingslogic](https://github.com/binarylogic/settingslogic)
-
-## Thanks
-
-Special thanks to all those gem authors above @binarylogic, @bendyworks,
-@laserlemon and @bkeepers.  They gave us the inspiration to write this gem and
-we would have made a lot more mistakes without them paving the way.  Thanks all!
+1. Thou shalt be [well documented](https://github.com/thekompanee/chamber/wiki/) with full test coverage
+1. Thou shalt not have to worry about [accidentally committing secure settings](https://github.com/thekompanee/chamber/wiki/Git-Commit-Hook)
 
-## Contributing
+## Full Reference
 
-1. Fork it
-2. Create your feature branch (`git checkout -b my-new-feature`)
-3. Commit your changes (`git commit -am 'Add some feature'`)
-4. Push to the branch (`git push origin my-new-feature`)
-5. Create new Pull Request
+Visit the [wiki](https://github.com/thekompanee/chamber/wiki)