Results of testing this locally (the exit value of the last command is
in my prompt):
```
0 $ TRAVIS=true TRAVIS_REPO_SLUG=growstuff/growstuff
TRAVIS_PULL_REQUEST=1007 script/check_contributors_md
Checking to see if you're in CONTRIBUTORS.md...
Thanks for your contribution, ctlewitt!
Please add your name and GitHub handle to the file CONTRIBUTORS.md,
commit it, and update your PR.
1 $ TRAVIS=true TRAVIS_REPO_SLUG=growstuff/growstuff
TRAVIS_PULL_REQUEST=1008 script/check_contributors_md
Checking to see if you're in CONTRIBUTORS.md...
- Miles Gould / [pozorvlak](https://github.com/pozorvlak)
0 $ script/check_contributors_md
Checking to see if you're in CONTRIBUTORS.md...
- Miles Gould / [pozorvlak](https://github.com/pozorvlak)
0 $
```
This allows us to use maintenance mode without installing the full
Heroku toolbelt, which we can't do on the (much faster!) container-based
infrastructure.
We add a (temporary) deployment to my sandbox from the travis_containers
branch: muckingabout with one branch for both container-based and
VM-based approaches was starting to get confusing.
It seems that heroku generally denies us access to ENV['...'] during asset
compilation. They have reasonably good reasons for this, and yet I don't
know how else we're meant to get at our API keys (other than hardcoding
them into our config files, which we don't want to do).
So, to work around this, I'm recommending the use of the (experimental,
subject to removal/change, sigh) user-env-compile heroku addon. This
lets us use ENV during asset compilation.
For more info see
https://devcenter.heroku.com/articles/labs-user-env-compile
Also removed the superfluous .plantings_count method on Crop, which was
causing some confusion.
A thing we learned today: we should use .size to find the size of
ActiveRecord collections, not .count, because .count doesn't use the
cache (while .size does).
