06 September 2016
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.
26 August 2016
The Limitation of PaperTrail
PaperTrail is fantastic, but in every app I’ve worked on, there’s at least two classes of users:
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.
24 August 2016
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!
23 August 2016
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.
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.