Intro to Efficiency Across Your Rails Application's Life

06 September 2016

Electric cars: Tesla P90d, the picture of efficiency

Intro to the Intro

Roughly one year ago I decided to take up developing in Ruby on Rails full time. The reason I picked up rails was how quick it is to build applications out with it. Developing quickly and efficiently is a, if not THE, strong point of Rails as a framework. As such, I’ve put together a list of posts which I’ll write to dive into increasing your efficiency across the various stages of an application’s lifecycle.


How to Setup PaperTrail for Polymorphic Whodunnit Tracking

26 August 2016

Monday Night Brewery Here in Atlanta. A man of mystery, whodunnit?

The Limitation of PaperTrail

PaperTrail is fantastic, but in every app I’ve worked on, there’s at least two classes of users: Admin and User. Now, admins can change things and in some applications, users can, too. In business environments, different user classes may be able to edit your models. Any financial clients or ones with business sensitive information will want to keep an audit trail to see who’s updating what across the app. Out of the box, PaperTrail doesn’t support keeping track of multiple types of users. Good for us that PaperTrail’s provided us APIs to alter its behavior.


Get Your Data to Glass 180x Quicker: How to Setup Clusterize.js with Rails and Coffeescript

24 August 2016

Atlanta Glass

Fast Server, Slow Browser

Here’s the situation: Your amazing developer team has rocked your world with caching and other optimizations to get data from your client’s Rails server over to the users’ browsers. Your monitoring shows requests that were taking a whole 80-90 seconds to serve are now only taking 1500ms (and all that time is actually spent transferring megabytes of html to the browser, actual data retrieval is ~10ms). These numbers come from a recent project I did for a client with production data. Now, to tackle the last piece of speeding it up… Chrome browser is taking MINUTES (6 minutes, actually) to fully build and render the page after it’s received the data. 100% unacceptable. Time to drop in some asynchronous data transferral and a specialized js library to keep things snappy client side!


A 1588x Render Speed Increase With Solr Caching on Rails to Solve All Your Performance Issues

23 August 2016

Powerful Rails Report and View Generation

Solr Saves Your Bacon. Again.

I’ve recently covered setting up and storing calculated functions and attributes using Sunspot and Solr in your Rails application. Today, I’m continuing on that with an insanely fast way to keep your reports up to date. A roll your own partial caching on Rails with Sunspot and Solr was pretty damn fun to build. The best part? It only takes a few lines of Ruby to give expensive, large reports an unbelievable performance boost. Quick, cheap, easy and bleedingly fast performance sound too good to be true? I thought so before today, too.


Increase Your Rails Application Reporting Speed by 10x with Sunspot's Stored Values

22 August 2016



In my previous post I introduced Solr and Sunspot along with a basic use case to get up and running with Rails. Here, I’ll dive in to what originally brought me to Sunspot, stored attributes. Wouldn’t it be great if you could dynamically generate a field to save complex calculations on your models with having to add columns to your database, and be sure that these calculations are kept up to date? This would especially be helpful for generating reports or views where you have lots of complex data that would normally take long to both load and calculate. Look no further, Solr’s stored attributes on hits have you covered.


Previous Page: 8 of 11 Next