chamber 1.0.3 → 2.0.0

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA1:
-  metadata.gz: 4e991dd80673beb3645505e5b5571cf8c6529edc
-  data.tar.gz: eb74b4013f2bec9a18957ef9c527ee11954e10d0
+  metadata.gz: e5d109673b130deb762adb5bb07bdce3f93c3848
+  data.tar.gz: 7bbce53ee5448ac94a876ca314461ce216ad881c
 SHA512:
-  metadata.gz: 7b6cd7b23ebd25a196e304de3106fb1679c30c0b01c19a9fedccddfe83ee6340198ec1f21526f5a741d5ef3fbec9d440035845a2edf6d3feb43e2e557a39597a
-  data.tar.gz: d39a4b31520431a209bacf8e11973b12981d5a24067f34d14a19bff860ac8e720825cda04762241e4dc82e4b566c834c6ee129c020da27bced522bd83dcb59bb
+  metadata.gz: 8e1cdda8675bdb504657159f52209dd24fa5bd9accecd2cfddbb68a1df08011684b1152eeb975362a0b3452d8a9183655e886f5b3078659a934349229ee5a4a3
+  data.tar.gz: d540cd77c3e966b9f355f1e910b74317254f4d8b6ea32e47db39fc92f567b3e6d71d029daebd059cbe371fcc5d63f7e3e106090dec9bb8f6944245cc3626dd0d

data/README.md

@@ -1,8 +1,34 @@
 # Chamber [![Build Status](https://travis-ci.org/m5rk/chamber.png)](https://travis-ci.org/m5rk/chamber) [![Code Climate](https://codeclimate.com/github/m5rk/chamber.png)](https://codeclimate.com/github/m5rk/chamber)
 
-Chamber lets you source your settings from an arbitrary number of YAML files that
-values convention over configuration and has an automatic mechanism for working
-with Heroku's (or anyone else's) ENV variables.
+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.
+
+<img src="https://akiajm7spx4gtbhaxe3qcomhaystacksoftwarearp.s3.amazonaws.com/photos/readmes/ten-commandments.png" align="right" />
+
+**Our Ten Commandments of Configuration Management**
+
+1. Thou shalt be configurable, but use conventions so that configuration isn't
+   necessary
+1. Thou shalt seemlessly work with Heroku or other deployment platforms, where custom
+   settings must be stored in environment variables
+1. Thou shalt seemlessly work with Travis CI and other cloud CI platforms
+1. Thou shalt not force users to use arcane
+   really_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
+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
 
@@ -24,6 +50,24 @@ Or install it yourself as:
 $ 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
@@ -31,7 +75,6 @@ $ gem install chamber
 By default Chamber only needs a base path to look for settings files.  From
 that path it will search for:
 
-* The file `<basepath>/credentials.yml`
 * The file `<basepath>/settings.yml`
 * A set of files ending in `.yml` in the `<basepath>/settings` directory
 
@@ -43,12 +86,8 @@ Chamber.load basepath: '/path/to/my/application'
 
 ### In Rails
 
-If you're running a Rails app, by default Chamber will set the basepath to your
-Rails app's `config` directory, which is the equivalent of:
-
-```ruby
-Chamber.load basepath: Rails.root.join('config')
-```
+You do not have to do anything.  Chamber will auto-configure itself to point to
+the `config` directory.
 
 ### Accessing Settings
 
@@ -61,7 +100,7 @@ Given a `settings.yml` file containing:
 
 ```yaml
 smtp:
-  server: "example.com"
+  server:   "example.com"
   username: "my_user"
   password: "my_pass"
 ```
@@ -80,15 +119,60 @@ Chamber.env.smtp.server
 # => example.com
 ```
 
-### Keeping Your Settings Files Secure
+### 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 seemlessly 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 format your secure keys like so:
+
+```yaml
+# settings.yml
+
+_secure_my_secure_key_name: 'my secure value'
+```
+
+When Chamber sees this convention (`_secure_` followed by the key name), it will
+automatically look to either encrypt or decrypt the value using the
+public/private keys you generated above into something like:
+
+```yaml
+# settings.yml
+
+_secure_my_secure_key_name: 8239f293r9283r9823r92hf9823hf9uehfksdhviwuehf923uhrehf9238
+```
+
+However you would still be able to access the value like so (assuming you had
+the private key in the application's root):
 
-Check out [Keeping Private Settings Private](#keeping-private-settings-private)
-below.
+```ruby
+Chamber.env.my_secure_key_name
+# => 'my secure value'
+```
 
-### Existing Environment Variables (aka Heroku)
+### Using Existing Environment Variables
 
-If deploying to a system which has all of your environment variables already
-set, you're not going to use all of the values stored in the YAML files.
+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:**
@@ -97,7 +181,7 @@ Given a `settings.yml` file containing:
 
 ```yaml
 smtp:
-  server: "example.com"
+  server:   "example.com"
   username: "my_user"
   password: "my_pass"
 ```
@@ -108,7 +192,7 @@ If an environment variable is already set like so:
 export SMTP_SERVER="myotherserverisapentium.com"
 ```
 
-Then when you ask Chamber to give you the SMTP server:
+Then, when you ask Chamber to give you the SMTP server:
 
 ```ruby
 Chamber[:smtp][:server]
@@ -121,14 +205,15 @@ 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 (which you shouldn't
-if some of the information is sensitive), it becomes more difficult to gain
-access to that information on Heroku.
+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 unweildy
-names.  For another, it makes the organization of those variables difficult.
+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
@@ -137,18 +222,14 @@ 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.
+will use that in place of any values inside of the config files as [described
+above](#using-existing-environment-variables).
 
-Simply run:
+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
-# In the root folder of your Rails app:
-
-chamber heroku push --preset=rails
-
-# In the root folder of another type of application:
-
-chamber heroku push --basepath=./
+chamber heroku push
 ```
 
 And all of your settings will be converted to environment variable versions
@@ -168,7 +249,7 @@ information.
 To execute this, simply run:
 
 ```sh
-chamber travis secure --basepath=./
+chamber travis secure
 ```
 
 This will add `secure` entries into your `.travis.yml` file.  Each one will
@@ -202,15 +283,6 @@ associated namespaced files.  Finally it will load all \*.yml files in the
 `chamber` directory *except* `credentials.yml` because it has previously been
 loaded.
 
-### Object-Based Environment Variable Access
-
-If you aren't a fan of the hash-based access, you can also access them
-using methods:
-
-```ruby
-Chamber.env.smtp.server
-```
-
 ### Predicate Methods
 
 When using object notation, all settings have `?` and `_` predicate methods
@@ -256,28 +328,25 @@ Notice the difference:
 
 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.  This is mainly
-used if you follow our convention of putting all of your sensitive information
-in your `credentials.yml` file.
+can use settings from previous files in ERB for later files.
 
 **Example:**
 
 ```yaml
-# credentials.yml
+# settings.yml
 
 production:
   my_secret_key: 123456789
 ```
 
 ```erb
-<%# settings.yml %>
+<%# settings/some_service-production.yml %>
 
-production:
-  my_url: http://my_username:<%= Chamber[:my_secret_key] %>@my-url.com
+my_service_url: http://my_username:<%= Chamber[:my_secret_key] %>@my-url.com
 ```
 
-Because by default Chamber processes `credentials` settings files before
-anything else, this works.
+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:
@@ -313,9 +382,9 @@ under specific circumstances, you can use Chamber's namespaces.
 **Example:**
 
 ```ruby
-Chamber.load( :basepath => '/tmp',
+Chamber.load( :basepath   => Rails.root.join('config'),
               :namespaces => {
-                :environment => -> { ::Rails.env } } )
+                :environment => ::Rails.env } )
 ```
 
 For this class, it will not only try and load the file `config/settings.yml`,
@@ -383,17 +452,50 @@ smtp:
 ````
 
 The above will yield the same results, but allows you to keep the production
-values in a separate file which can be secured separately.
+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 => '/tmp',
+Chamber.load( :basepath => Rails.root.join('config'),
               :namespaces => {
-                :environment => -> { ::Rails.env },
-                :hostname    => -> { ENV['HOST'] } } )
+                :environment => ::Rails.env,
+                :hostname    => ENV['HOST'] } )
 ```
 
 When accessed within the `test` environment on a system named `tumbleweed`, it
@@ -468,22 +570,63 @@ Each of the commands described below takes a few common options.
 
   **Example:** `--preset=rails`
 
-* `--files` (or `-f`): Allows you to specifically set the file patterns that
-  Chamber should look at in determining where to load settings information from.
+* `--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:** `--files=/path/to/my/application/secret.yml /path/to/my/application/settings/*.yml`
+  **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`
+  **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:** `--basepath`, `--preset` and `--files` are mutually exclusive._
+_**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
 
@@ -499,7 +642,7 @@ about for a given context.  It will be output as a hash of hashes by default.
 
   **Example:** `--as-env`
 
-**Example:** `chamber settings show -p=rails`
+**Example:** `chamber show --as-env`
 
 ###### Files
 
@@ -510,7 +653,19 @@ 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 settings files -p=rails`
+**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
 
@@ -539,17 +694,25 @@ environments.
 
   **Example:** `--second=staging`, `--second=staging my_host_name`
 
-**Example:** `chamber settings compare --first=development --second=staging -p=rails`
+**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.
 
-_**Note:** I'll be using the `--preset` shorthand `-p` for brevity below but the
-examples will work with any of the other options described
-[above](#common-options)._
-
 ##### Heroku Common Options
 
 * `--app` (or `-a`): Heroku application name for which you would like to affect
@@ -557,20 +720,6 @@ examples will work with any of the other options described
 
   **Example:** `--app=my-heroku-app-name`
 
-* `--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-ignored` (or `-o`): This is the default.  Because Heroku has no issues
-  reading from the config files you have stored in your repo, there is no need
-  to set *all* of your settings as environment variables.  So by default,
-  Chamber will only convert and push those settings which have been gitignored.
-
-  To push everything, use the `--no-only-ignored` flag.
-
-  **Example:** `--only-ignored`, `--no-only-ignored`
-
 ##### Heroku Commands
 
 ###### Push
@@ -579,10 +728,10 @@ 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 -a=my-heroku-app -p=rails -n=staging`
+**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](#general-settings-commands) command above._
+the [chamber settings show](#settings-commands) command above._
 
 ###### Pull
 
@@ -598,9 +747,9 @@ specify the following option:
   _**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.yml`
+  **Example:** `--into=/path/to/my/app/settings/heroku.config`
 
-**Example:** `chamber heroku pull -a=my-heroku-app --into=/path/to/my/app/heroku.yml`
+**Example:** `chamber heroku pull --app=my-heroku-app --into=/path/to/my/app/heroku.config`
 
 ###### Diff
 
@@ -608,7 +757,7 @@ 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 -a=my-heroku-app -p=rails -n=staging`
+**Example:** `chamber heroku diff --namespaces=production --app=my-heroku-app`
 
 ###### Clear
 
@@ -616,34 +765,18 @@ 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 -a=my-heroku-app -p=rails -n=staging`
+**Example:** `chamber heroku clear --namespaces=production --app=my-heroku-app`
 
 #### Travis CI
 
-##### Travis Common Options
-
-* `--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-ignored` (or `-o`): This is the default.  Because Travis has no issues
-  reading from the config files you have stored in your repo, there is no need
-  to set *all* of your settings as environment variables.  So by default,
-  Chamber will only convert and push those settings which have been gitignored.
-
-  To push everything, use the `--no-only-ignored` flag.
-
-  **Example:** `--only-ignored`, `--no-only-ignored`
-
 ##### Travis Commands
 
 ###### Secure
 
-Travis CI allows you to use the public key on your Travis repo to encrypt
-items such 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.
+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
@@ -652,7 +785,7 @@ committed.
 _**Warning:** This will delete *all* of your previous 'secure' entries under
 'env.global' in your .travis.yml file._
 
-**Example:** `chamber travis secure -p=rails -n=continuous_integration`
+**Example:** `chamber travis secure --namespaces=continuous_integration`
 
 ### Basic Boolean Conversion
 
@@ -674,12 +807,12 @@ if Chamber.env.my_feature.enabled?
 end
 ```
 
-Will always return true because `false` becomes `'false'` on Heroku which, as
-far as Ruby is concerned, is `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.
+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:
 
@@ -689,7 +822,7 @@ if Chamber.env.my_feature.enabled == 'true'
 end
 ```
 
-but that looks awful.
+but that looks awful and isn't very idomatic.
 
 To solve this problem, Chamber reviews all of your settings values and, if they
 are any of the following exact strings (case insensitive):
@@ -714,7 +847,8 @@ accessing it.  Don't worry, Chamber will take you 98% of the way there.
 Just include it like so:
 
 ```ruby
-class Settings < Chamber
+class Settings
+  extend Chamber
 end
 ```
 
@@ -723,51 +857,11 @@ environment, you can simply use `Settings[:application_host]`.
 
 ## Best Practices
 
-### Why Do We Need Chamber?
-
-> Don't store sensitive information in git.
-
-A better way to say it is that you should store sensitive information separate
-from non-sensitive information.  There's nothing inherently wrong with storing
-sensitive information in git.  You just wouldn't want to store it in a public
-repository.
-
-If it weren't for this concern, managing settings would be trivial, easily
-solved use any number of approaches; e.g., [like using YAML and ERB in an
-initializer](http://urgetopunt.com/rails/2009/09/12/yaml-config-with-erb.html).
-
 ### Organizing Your Settings
 
-We recommend starting with a single `config/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 `config/settings/smtp.yml`).
-
-### Keeping Private Settings Private
-
-Obviously the greater the number of files which need to be kept private the more
-difficult it is to manage the settings.  Therefore we suggest beginning with one
-private file that stores all of your credentials.
-
-### Ignoring Settings Files
-
-We recommend adding the following to your `.gitignore` file:
-
-```
-# Ignore the environment-specific files that contain the real credentials:
-/config/credentials.yml
-/config/credentials-*.yml
-
-# But don't ignore the example file that shows the structure:
-!/config/credentials-example.yml
-```
-
-Along with any namespace-specific exclusions.  For example, if you're using
-Rails, you may want to exclude some of your environment-specific files:
-
-```
-*-staging.yml
-*-production.yml
-```
+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
 
@@ -778,29 +872,48 @@ Let's walk through how you might use Chamber to configure your SMTP settings:
 
 stuff:
   not: "Not Related to SMTP"
+```
 
+```yaml
 # config/settings/smtp.yml
 
-smtp:
-  headers:
-    X-MYAPP-NAME: My Application Name
-    X-MYAPP-STUFF: Other Stuff
+default: &shared
+  smtp:
+    headers:
+      X-MYAPP-NAME: My Application Name
+      X-MYAPP-STUFF: Other Stuff
 
-# config/settings/smtp-staging.yml
+development:
+  <<: *shared
+  smtp:
+    username: my_dev_user
+    password: my_dev_password
 
-smtp:
-  username: my_test_user
-  password: my_test_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 you can access both `username` and `headers` off of `smtp` like so:
+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_test_password
+# => my_staging_password
 ```
 
 ## Alternatives
@@ -810,9 +923,11 @@ Chamber[:smtp][:password]
 * [idkfa](https://github.com/bendyworks/idkfa)
 * [settingslogic](https://github.com/binarylogic/settingslogic)
 
-### Others?
+## Thanks
 
-I'd love to hear of other gems and/or approaches to settings!
+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!
 
 ## Contributing