On a recent project, I had need again to use GeoIP (by the lovely people at MaxMind). I decided to take some time to benchmark a handful of various GeoIP gems, both for GeoIP v1 (legacy) and the newer GeoIP v2.
I decided to benchmark the extraction of 3 pieces of data, using the GeoIP Lite City database:
I’m busy upgrading several apps to Rails 4.0. As is to be expected, there are a few gotchas here and there. Most are documented somewhere… deep in a changelog… mixed in with dozens of other things that probably won’t bite you.
I’ve been posting some of my notes along the journey. This particular post will serve as a central reference point, a table of contents of sorts, and will just contain links to other posts. I’ll try to keep it updated as I add new posts.
In addition to the asset path changes covered in part 1, there are some changes in how processed asset files are exposed to web clients.
In this case, the problem shows up with asset files that are referenced by name without the md5 fingerprint. Previously, plain-named asset files were also exposed to the webserver. Now they don’t seem to be.
The most likely culprit here are files referenced from within a CSS file, such as:
The asset pipeline was introduced in Rails 3.1. It continues to exist in Rails 4 and has seen a number of changes.
In one key change, Sprockets (the brains behind the asset pipeline) now looks in fewer places for asset files.
In Rails 3, Sprockets looked in app/assets, lib/assets, and vendor/assets for assets. Importantly, this applied not only to your main app, but also to any asset-providing gems, such as font-awesome-rails.
In Rails 4, Sprockets only looks in app/assets (both in your app and in gems). If you have any assets that aren’t working properly (most likely fonts, images, or CSS files not loading), first check for updated versions of any gems.
If it’s your own gem or a gem that hasn’t been updated, it may be as simple as moving lib/assets or vendor/assets to app/assets.