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.
Refactoring
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 »
Nextpoint Lab 
