Whew! Seems like a pretty clean one? Ran `rails app:upgrade` and stuff, and made some corrections to keyword arguments for `translate` calls. There might be more such problems elsewhere? But that's hard to search for, and we'll have to see.
This one was pretty straightforward yaay! Main thing was the change from `render file` to `render template` in a couple places, oh and a thing with complex `order()` clauses.
During this upgrade process, `rails server` hasn't been updating its logic when files changed, so every change had to be accompanied by a restart.
This turned out to be because Vagrant's networked filesystem to share between the host and guest systems doesn't support the filesystem update events Rails is listening for. So, we switch to a simpler file watcher that does more work but doesn't depend on the filesystem events!
It's unused, and I'm just double-checking that it's not somehow causing the issues with the rails dev server not reloading classes. (The `threadsafe!` option would do that, but I don't thiiiink this is the env we're running? But I'm wondering if the loader is getting confused by the prefixiness of the name or something. Unlikely!)
This is recommended by the Rails 4.0 upgrade guide:
> The caching method changed between Rails 3.x and 4.0. You should change the cache namespace and roll out with a cold cache.
I noticed too that old cache entries with old character encodings were a real problem, so yeah making sure we're working with a cold cache is smart!!
NOTE: This doesn't boot yet! There's something changed in the `devise` API that we'll need to fix!
```
/vagrant/config/initializers/devise.rb:46:in `block in <top (required)>': undefined method `encryptor=' for Devise:Module (NoMethodError)
```
But yeah, we navigated the gem upgrades, and also I ran `rake rails:update` and hand-processed the suggestions it had for our config files.
