Update README.md
Merge pull request #26 from jrhorn424/ppod-fixes

My fixes
Remove settingslogic and mina, deploying to heroku

- `mina` has been removed since heroku provides deployment
- `settingslogic` has been removed since we can't upload configuration
  files to heroku
- Configuration is now done through environmental variables, which have
  been added to heroku
- Support has been added for using `unicorn` on heroku
- New Relic has been added for alerts and error reporting
Merge pull request #31 from jrhorn424/jrh-heroku-deployment

Remove settingslogic and mina, deploying to heroku
message
fixing merge conflict
Use seed_fu in nuke_pave task
Re-add newrelic configure

DO NOT remove this without reason. It breaks development.
Reset ruby-version to latest installed patch on developer machine

Ruby core team is working on issues relating to OpenSSL updates and OS X
Mavericks, but they have yet to release patches. The current latest
patches do not play well with Apple's post-Heartbleed OpenSSL update.
For now, we'll use whatever patch-level is highest on the box running
the app, whether it's development or production.
Update dependencies after downgrading ruby patch.
Make sure delayed_job is started on heroku after deploy
Remove dotenv gem from development and test environments

Dotenv will load settings from the `.env` file in development. This
file should be used to save settings for heroku deploys. In the future,
we should try setting things up to leverage a different `.env` file
locally, for example `.env.development`. The `.env` file should be
reserved for pushing settings changes to heroku.
Rails 12-factor gem necessary to configure rails 4 for heroku
Re-add schema.rb as canonical representation of production database

This was removed previously due to using conflicting database adapters
in production and development. We've recently simplified this by using
postgres both locally and in production.

We need schema.rb to fix another issue: difficult migrations. Migrations
can be run locally several times to get past errors, but in production
they only run once. Rather than spending a lot of effort debugging
migrations, we'll build the correct schema based on the most recent
migrations. Then, we'll remove the migrations and dump the schema into
it's own migration.

This ensure parity between local and production databases. A similar
pattern should be performed after each major deploy to production.
Using this workflow in conjunction with our `rake db:nuke_pave` task, we
can safely edit migrations in development until they are deployed.
Combine migrations into a milestone migration
Use heroku environmental configuration to define the url for mail messages
Ensure all pages are redirected to bare domain
Merge pull request #49 from jrhorn424/feature/jrh-fix-host-setting

Feature/jrh fix host setting
Merge branch 'refs/heads/develop'

Conflicts:
	.ruby-version
	Gemfile
	Gemfile.lock
	Procfile
	config/environments/production.rb
	config/unicorn.rb
	db/migrate/20131003190250_create_profiles.rb
	db/migrate/20140307211155_create_sessions.rb
	db/migrate/20140310150737_create_categories_experiments_join_table.rb
	db/migrate/20140311213717_add_references_to_session.rb
	db/migrate/20140312091001_create_registrations.rb
	db/migrate/20140312091021_create_assignments.rb