bumping activeresource version to ~>3.2
bumping activeresource to 4.0.0.rc2
removing 1.9.2 from travis since Rails 4 inst compatible anymore
Change gemspec file to make possible run the tests on travis ci.
branching a rails4 gem
Change gemspec file to make possible run the tests on travis ci.
release rails 4 pre version
Merge remote-tracking branch 'origin/rails-4'
update gem to work with rails 4
better readme

added link to Cookbook, fixed code blocks to use syntax highlighting,
added breaklines at first code block to fix how it shows up at yardoc.
better readme

forgot a code block...
changing activesupport dependency to start from 4.0.0.rc2, fixes #50
bump version
restoring gemspec summary

Somehow this migrated from my fork...
gemspec is now a generated file

While we use syscalls like `git ls-files`.split("\n")` for our convenience,these
kinds of calls combined in a plethora of gems which compounds big/huge Rails
applications sum up to be a bootstrap performance hog.

I've added a rake task called `gemspec`, which uses an ERB template located at
the root of the gem directory to generate the gemspec itself.

More about the bootsrap time
============================

I did some dtracing into the Ruby VM while booting some Rails apps, and it turns
out Bundler actually evaluates the gemspec files of all required gems, and as
fast as `git` is, it's still an external call to an application that has a lot
on its plate (check git internals).

A gemspec generally uses:

`git ls-files`/`Dir.glob("...")` to get the contents of the gem for
files/test_files/executables/spec_files/;
`File.expand_path("...")` to get the contents of signing_key;

In special, the `git` call will chain a **huge mass** of low level stat calls
because of the way it uses the filesystem to store the data.
merged upstream master