The `$HOST` environment variable is used by zsh; overriding it affects other programs that depend on it. The `$HOSTNAME` environment variable is used similarly by GNU Bash. Change the name of the environment variable that we depend on, to avoid complications.
suspenders as a gem relies on version ranges for its dependencies defined in its gemspec. Precise patch versions declared in `Gemfile.lock` don't need to be tracked. We expect suspenders to always work well with latest patch versions of all its dependencies. More information: http://yehudakatz.com/2010/12/16/clarifying-the-roles-of-the-gemspec-and-gemfile/
> Heroku now recommends using the Puma webserver. The previously > recommended webserver, Unicorn, is susceptible to slow client attacks. https://devcenter.heroku.com/changelog-items/594 * Specify deploy settings - Set values that DATABASE_URL won't override / set - Add staging - Use max of thread count or db pool, since @schneems says: > You need your pool to at least be as large as your puma thread > count.
Using db/seeds for data which must be loaded in a production environment is a standard Rails convention. We cause confusion by using the word "seed" elsewhere in a Rails app, where that is not the context. The `dev:prime` task is actually providing local fake/sample data for developers to see the app in use, but not production-required data to actually run the application.
This is the result of two discussions on our research board. The first was to replace Travis with CircleCI: https://trello.com/c/Se4mELMh/199-hosted-ci-for-continuous-deployment A few reasons we've enjoyed using Circle: * Faster builds due to parallel builds * Built in bundle caching * Easy deployment * Really easy setup * The ability to ssh into the CI server during a test run. This has been great when debugging a test failure. It's not something you use a lot but it is so great when you need it. * A free plan for private repos that supports small MVPS This also adds automatic deployment to staging when the build passes. This is the result of this discussion: https://trello.com/c/Se4mELMh/199-hosted-ci-for-continuous-deployment A few reasons for those who don't have access to the trello card: * Part of the CI now is whether or not you can actually deploy successfully. If you merge to master, it will automatically try and deploy to staging. If that fails, your build will actually fail. This should be treated with the same urgency that any other failing build on master would be treated. * Staging is always up to date. This makes it really nice for verifying stories for clients. * Automate more things!
RSpec 3.3 added some very handy commands for filtering examples. With the addition of the status persistence file configuration we can now: * run `rspec --only-failures` to re-run only the examples that failed. * run `rspec --next-failure` to re-run only the first failing test from your previous run. If that passes it will run the successive failures until one of them fails again Additionally, rspec 3.3 includes stable random ordering (even when you add new examples), the ability to bisect failures when debugging ordering-dependent failures, better failure output... http://rspec.info/blog/2015/06/rspec-3-3-has-been-released/
Locking down the rails version to the patch level means we need to edit the Gemfile every time a security update is released. By locking to the 4.2.x series instead, we can just run `bundle update rails` to get the latest security patches. Because this is locked to an explicit minor version, only security patches should get pulled in automatically. Assuming that Rails follows SemVer properly, unexpected changes should only come in minor or major versions. I ran `bundle install` and pulled in the security patches released for Rails 4.2.2 (see http://weblog.rubyonrails.org/2015/6/16/Rails-3-2-22-4-1-11-and-4-2-2-have-been-released-and-more/ for details and CVEs)
This ensures that the `require` order is the same on all machines, including CI. For example, we mainly use OS X as our local development machines, while CI runs on Linux. We've run into ordering issues before due to the different OS's, and this changes has historically fixed it.
- It's unneeded and overly verbose - sass-rails recently deprecated this suffix, rails/sass-rails@d355de9