Posts Tagged ‘rails’

As a user, one of the best ways to improve your online experience is to avoid downloading repetitive files. It’s a two way street though: If the site you’re visiting doesn’t put any effort into it – you’re (often) not going to be able to do much from the user perspective.

A great place to start is with the YSlow extension for Firefox.  I wouldn’t necessarily be concerned with the score that it churns out, but it will give you useful (and some not so useful) tuning pointers.


Pretty simple concept that we’re all probably familiar with: Compact a file down to a smaller version – transmit – restore to it’s usable form.  We’ve got Apache serving up most of our content so we let mod_deflate do most of the work here.  Pretty simple, just make sure not to waste your time trying to compress things that are binary or already compressed.


These aren’t really for us.  Balancing requests over a set of multiple servers doesn’t necessarily mean ETags can’t work… but it does make it trickier to really get a benefit.  In the end, we just left them out.

Add an Expires Header

This is a little trickier than it may seem.  You never want people to download “the same file” if they can help it, but when you’ve changed that file — you need them to get the changed version immediately.

After playing with a wide variety of approaches, we settled on conditionally adding an expires header.  That’s been in our app for more than a year now and we’ve been pretty pleased with it.  The initial catch was symlinks being overwritten when we re-deployed.  It was a pretty simple addition to have our Capistrano scripts recreate it and we were quickly on track.

Here’s a sample YSlow shot of our savings.  It’s “pretty nice” to reduce what our users need to download on each request from their desk at work, but the savings for those using the site via a handheld device (or other slow connection) is pretty incredible.

Read Full Post »

As we announced earlier, our newest release had many behind-the-scenes changes in addition to the new user facing features. This post will deliver a more technical look at what’s going on under the covers.

Rails Upgrade

Nextpoint relies on multiple frameworks and technologies but at the heart of our user facing site is Ruby on Rails.  One of the most major behind-the-scenes changes in this release is our upgrade to Rails 2.1.

Partial Updates

One of the features we were most looking forward to in the newest version of Rails unfortunately fell completely flat for us: Partial Updates (and to some extent “Dirty Objects”).  First reading about this functionality, it really sounded appealing: don’t spend (even minuscule amounts of) time saving data that hasn’t actually been changed.  In practice though, the implementation seems pretty impractical for most non-trivial applications and for existing applications: I can’t imagine trying to retrofit (and maintain!).  Unfortunately, we quickly came to the conclusion that we just need to “turn this stuff off”.

XML Handling

XML handling took a couple steps in the right direction for Rails 2.  The change to start flagging null values, instead of just leaving them “blank”, caused a couple hiccups but will come in handy in the long run.  And a bug fix to a pesky regular expression error in the framework (that we had fixed ourselves previously) will make for one less monkeypatch in our codebase.  (Bad regular expressions can really add up when you deal in the volume that we do!)

Eager Loading

Changes to eager loading gave us a bit of trouble as statements that used to result in :include items being joined right into a single large query now (may) result in several smaller statements.

Does it make queries more efficient?  Probably.

Does it increase db traffic?  Probably.

Is it a bad thing?  Probably Not (overall).

Is it a bad thing that stuff that worked before doesn’t?  Yeah, that’s annoying.

Our specific problem is on an association defined with a :select => “distinct labels.*”.  We played around a bit with potential changes down in the AR guts but in the end (unfortunately), ended up basically tricking it into running it as a single statement.  It’s not at all difficult to make it happen but it’s also not straightforward – and it stinks when the framework makes you write a big comment.

Search Changes

Search is at the core of our product and we want (almost) every release to make that experience better.  We’ve added designation labels and issues to our transcripts and depositions search indexes, providing users with the ability to search those sections of the applications for them.  We love to see our users submitting really detailed search queries – getting straight to the data that they need to get their job done instead of forcing them down the road of an endless stream of links that never quite get the job done.

Ajaxy Goodness

We’re big believers in the “right tool for the right job” mantra.  We actively try to avoid throwing in flashy javascript features just for their own sake, but sometimes it just plain makes the process much more useful.  To that end, we have a couple new/reworked ajax features that we really like.

The most obvious is the new version of our “case selector”.  Instead of waiting for a new page containing all your cases in alpha order – we’ve made changes to get people to their cases faster.  The list now drops down with most recent cases accessed first.  If you need to get something you haven’t been to in a while, those are there in the select box but for the most part: you’re really only working in a couple cases at once (at most).

In this initial implementation the dropdown is actually populated post-rendering of the requested page to avoid slowing down the “real” request.  In future releases we might find ourselves not actually rending the drop until you request it.  This would mean a (quite short) wait when you want to switch cases, but it would eliminate the extra work we’re doing on each request.

The most useful ajax implementation in this release is probably in our designation editor.  We’ve always had the ability to designate by clicking on a preview window (click the line of text for the beginning – click the line for the end, etc).  This release improves on that by tying the “edit box” to the “preview” window more directly and reworking the way that ajax is being used in the background.  Page elements will only be re-rendered when absolutely necessary (this page carries ~6 individual components).  This allows for smaller requests/responses and relieves the burden of constantly re-rendering elements “to their previous state”.

User Experience

Nextpoint prides itself on providing an application that is easy to use.  We have a great UX process and each release brings big improvements.  This release includes the changes mentioned in the section above, new images and branding, cleaner interfaces and cleared up real estate issues.  We’ve also provided more cross-product integration, making it easier (for example) to find something via the primary Search product and quickly be editing in the Transcripts section.


As with any major production system, we always have a list of places that we’d like to cleanup and consolidate when we get the chance.  This release gave us the chance to remove some deprecated code and rename some elements that have been re-tasked.  This improves our development environment, making future releases more straightforward for our software engineers and thus making new feature delivery more efficient.

Read Full Post »