Blog | object.io

Serving Rails assets with nginx

Using the Rails asset pipeline makes it safe to cache assets forever in browsers. Rails is configured for this out of the box, so you only need to ensure that you precompile assets before or during each deploy.

With that out of the way you can simply add this snippet to your nginx config to allow assets with digests in their name to be cached forever in clients:

# From https://object.io/site/2015/rails-nginx-easy-assets
#
# Cache forever publicly: files for generated assets
#   /assets/application-2565b50fc38a0b3a44882faa3e936262.css
#
# This setup means a CDN may cache these files
location ~ "^/assets/.+-[0-9a-f]{32}.*" {
  gzip_static on;
  expires     max;
  add_header  Cache-Control public;
}

# Try serving request as a static file, no caching:
location / {
  try_files $uri/index.html $uri.html $uri;
}

This gives special treatment to files in /public/assets/ with a 32-character hex digest in the filename. These files are exactly the ones built by the asset pipeline, and they are allowed to be publicly cached forever, as they are guaranteed to never change their contents. With this configuration in place you can also trivially use your nginx as the origin server for a CDN.

Any static files not matching the first rule are not allowed to be cached forever and will have to be re-requested with each visit. The more you can build as digested assets, the less strain you will see on your nginx server and your bandwidth bill.

Happy caching!

Maintenance development - freestyle

How do you get started doing effective maintenance development? This topic is near and dear to me, as I’ve spent most of my career writing new functionality, but also to a large degree getting good at cleaning up and extending code written by others. There are some knacks to doing it well, and I’m in the process of writing write a practical guide to help you learn it faster.

Style guides are topic with the potential for endless discussion. The ruby community has some good ones, and you are of course free to write your very own as well. One thing you will typically find taking over a project that has lived for a while, maybe with multiple maintainers, is inconsistent code styles. This is obviously not the end of the world, but it can sidetrack you when trying to reason about the current behavior of a piece of non-obvious code.

Fortunately it is easy these days to setup rubocop and ensure a consistent style is used. It is even partially possible to automatically clean up most of it to conform. Consistent hash style, yay.

Some large codebases are a beautiful and valuable mess. They often have a large gap between the current state and an ideal state of syntax consistency and well-managed complexity. All is fortunately not lost, The Rewrite is typically not the answer. Instead, a processes is needed to break things down and attacking the problem in smaller chunks over a period of time, without halting all other progress. It is such a process I’m describing in the guide.

Update

The guide is ready and now available as a free article on getting started with Rubocop for Large Projects. Enjoy!