README.md in envied-0.4.0 vs README.md in envied-0.5.0

@@ -1,60 +1,53 @@
 # ENVied [![travis](https://secure.travis-ci.org/eval/envied.png?branch=master)](https://secure.travis-ci.org/#!/eval/envied)
 
 ### TL;DR ensure presence and type of your app's ENV-variables.
 
-For applications that are configured via ENV-variables, this gem will provide:
+This gem will provide:
 
-* A fail-fast check for presence of required ENV-variables
-* A fail-fast check for type of required ENV-variables
+* A fail-fast check for presence of ENV-variables
+* A fail-fast check whether the values can be coerced to the correct type
 * Access to typed ENV-variables (instead of just strings)
 
-### Current status
+## Quickstart
 
-![](underconstruction.gif)
-
-## Usage
-
 ### 1) Configure
 
 Let's configure the ENV-variables we need:
 
 ```ruby
-# e.g. config/application.rb
 ENVied.configure do
   variable :FORCE_SSL, :Boolean
   variable :PORT, :Integer
 end
 ```
 
-### 2) Check for presence and type
+### 2) Check for presence and coercibility
 
 ```ruby
 ENVied.require
 ```
 
-This will throw an error if not:
-* both `ENV['FORCE_SSL']` and `ENV['PORT']` are present
-* both the values of `ENV['FORCE_SSL']` and `ENV['PORT']` can be coerced (to resp. Boolean or Integer).
+This will throw an error if:
+* not both `ENV['FORCE_SSL']` and `ENV['PORT']` are present.
+* the values can't be coerced to resp. Boolean and Integer.
 
-(The error contains exactly what ENV-variables are missing/faulty.)
+### 3) Use coerced variables
 
-### 3) Use typed variables
+Variables accessed via ENVied are of the correct type:
 
-Variables accessed via ENVied have the configured type:
-
 ```ruby
 ENVied.PORT # => 3001
 ENVied.FORCE_SSL # => false
 ```
 
 ## Configuration
 
 ### Groups
 
 Groups give you more flexibility to define when variables are needed.  
-It's just like you Gemfile:
+It's similar to groups in a Gemfile:
 
 ```ruby
 ENVied.configure do
   variable :FORCE_SSL, :Boolean
 
@@ -83,10 +76,12 @@
 * `:Boolean` (e.g. '0'/'1', 'f'/'t', 'false'/'true', 'off'/'on', 'yes','no' for resp. true or false)
 * `:Integer`
 * `:Symbol`
 * `:Date` (e.g. '2014-3-26')
 * `:Time` (e.g. '14:00')
+* `:Hash` (e.g. 'a=1&b=2' becomes `{'a' => '1', 'b' => '2'}`)
+* `:Array` (e.g. 'tag1,tag2' becomes `['tag1', 'tag2']`)
 
 ### Defaults
 
 In order to let other developers easily bootstrap the application, you can assign defaults to variables.
 Defaults can be a value or a `Proc` (see example below).
@@ -102,11 +97,11 @@
 
 Please remember that ENVied only **reads** from ENV; it doesn't set ENV-variables.
 Don't let setting a default for, say `RAILS_ENV`, give you the impression that `ENV['RAILS_ENV']` is set.  
 As a rule of thumb you should only use defaults:
 * for local development
-* for ENV-variables that your application introduces (i.e. for `ENV['DEFAULT_SENDER']` not for `ENV['REDIS_URL']`)
+* for ENV-variables that your application introduces (i.e. for `ENV['STAFF_EMAILS']` not for `ENV['REDIS_URL']`)
 
 ### A more extensive example:
 
 ```ruby
 # We allow defaults for local development (and local tests), but want our CI
@@ -124,10 +119,10 @@
   # generate the default value using the value of PORT:
   variable :PUBLIC_HOST_WITH_PORT, :String, default: proc {|envied| "localhost:#{envied.PORT}" }
 
   group :production do
     variable :MAIL_PAAS_USERNAME
-    variable :DATABASE_URL, :Symbol
+    variable :DATABASE_URL
   end
 
   group :ci do
     # ci-only stuff
   end