Faster web page requests in Rails development

Photo of hummingbird Photo by James Wainscoat on Unsplash

Nobody likes waiting for a web page to load.  Pity, then, the Ruby on Rails developer, proud of the the development platform’s famous efficiency of code, combating the slanderous claims of a slow production environment, and then condemned to watch the browser bar spinning and spinning for the 500th time during today’s coding session.  Because Rails requests in the default development environment are s l o w.

Why?  By default, every web page request is verifying and recompiling every referenced asset — every Coffeescript, Sass, and Less file.  Ajax requests with responses that don’t include the application layout (and its application.js and application.css manifest file burdens), are delightfully zippy, but loading a simple home page?  Over and over throughout the course of the day?  Goodbye delight and efficiency.

Debug off

Until you make one simple change in development.rb: (more…)

Custom fields in Rails

Photo of train tracks by Julian Hochgesang on Unsplash

What approach do you take when adding dynamic attributes to model objects stored in a traditional database?  Let’s say a bug model with static fields like name and species also needs to support any number of additional dynamic fields specified by different bug collectors.  There are a number of possible solutions to this common problem, so let’s consider the options.

  1. Serialize a hash ({ color: "brown", arms: 2 }) into a column at save, and de-serialize at load.  This serialization would be easy from a configuration standpoint, but would scale poorly and would be rubbish for searching on key values.  Rejected.
  2. Integrate a NoSQL datastore like redis.  A NoSQL datastore would offer speed and a task-appropriate API at the expense of integrating, configuring, and maintaining a new storage component for a minor feature.  Reasonable, but not appropriate in the context.
  3. Add a series of “CustomField#{n}” columns to the bugs table.  No, just no.  Don’t make me cry.
  4. Dynamically add columns to the bugs table (or to per-collector dynamic tables) when new custom fields are defined.  These columns would allow strict type validation at the DB layer, but would limit the total number of columns and would be difficult to maintain with standard ORMs.  Decidedly too much trouble.
  5. Design a standard relational mapping from the bugs table to a custom field table with key and value columns.  This approach is widely used as it fits a standard RDBMS schema.  Its only obvious downside is increasing the number of table rows and objects that need to be managed and read.
  6. Use PostgreSQL’s hstore extension, which provides a key/value hash column type.  If PostgreSQL is already your RDBMS or is an easy switch, using hstore essentially mixes in a NoSQL approach with minimal extra configuration.

Let’s consider the custom field table (cftable) and PostgreSQL hstore (hstore) approaches in more detail, in the context of an application running on Ruby on Rails. (more…)

Another Look at RubyMotion

A few months ago I took a look at RubyMotion and wondered if it would garner enough developer interest to be successful and I think it is. There have been several significant updates to the core product, its creator Laurent Sansonetti has given a number of talks at conferences around the world about the project, and open source and commercial projects are being built for RubyMotion apps.

EverClip is built with RubyMotion, recently won a development award from Evernote, and is available on the iTunes App Store.

 

Cabify is an international version of Uber and has had great success developing their iOS apps with RubyMotion alongside their Rails apps. Cabify is also available on the iTunes App Store and works in several South American and European cities at the moment.

 

Along with commercial apps there’s a growing open source community surrounding RubyMotion on GitHub. One of the most active contributors is Clay Allsopp who’s recent contributions include:

HipByte also just announced that they’ve hired Watson, the most active MacRuby contributor, to help with RubyMotion development so it will be great to see what new features and changes they have in store for RubyMotion in months to come.

RubyMotion Brings Ruby to iOS

Ruby Motion Logo

RubyMotion is a new development toolchain that allows you to build iOS apps using Ruby created by Laurent Sansonetti, a former Apple engineer and contributor to the MacRuby project. It has garnered a lot of attention the past few weeks and some detailed reviews have already been written:

The MacRuby project (which is an open-source project  supported by Apple) allows developers to create Mac OS X apps using ruby, however it doesn’t work with iOS. MacRuby relies on the Garbage Collected (GC) Objective-C runtime that isn’t available on iOS. With the introduction of ARC for iOS and Mac OS X Apple will likely drop support for the garbage collected (GC) runtime in a future version of Mac OS X and won’t bother to bring it to iOS. This move by Apple called into question the future of MacRuby for OS X and made the prospect of developing iOS apps using ruby look even more remote.

Enter RubyMotion. It takes a different approach than MacRuby and based on early results looks to be a good solution for rubyists looking to build iOS apps.  However, the lack of support for creating UI elements in Interface Builder, dependence on Apple’s developer tools and SDKs, and other risks are being called into question already as well. It will be interesting to see Apple’s reaction to RubyMotion, especially considering that Sansonetti is a former employee and MacRuby contributor. I’ve bought my copy and am hoping the project succeeds and finds its way back to OS X too.