Matthew Lang

The named_scope feature in the Rails framework has been kicking about for a while now.  Named_scope is a way to of narrowing down your more common find routines in your ActiveRecord models.  Here’s a quick example:

In a task model we have the following:

This will allow us to query for all tasks that have a duration of less than 2.

Also we can setup a named scope that uses a parameter that we pass to it.

This will allow us to find tasks that have a duration less than the number of hours we pass to the named_scope.

Now while this is all great, I thought about changing some of my associations to use the named scope instead.

We can now iterate through a collection of tasks associated with a project.

Now while it did give me a chance to use named_scope within my project, something about the code just didn’t sit right. It’s hard to determine at first glance what we’re doing in the above code snippet, as the more conventional method is to find the project, and then access the list of tasks for that project.  After adding a couple of more it seemed that the code didn’t read write in my eyes.  A better way of find tasks for a project is to use the more conventional way in Rails.  We can do this like so:

The features in the Rails framework are there to be used, but be careful your not using a feature in your project just for the sake of using it. There are plenty of ways of doing things in Rails, and usually that best way is the more conventional way of doing it rather than exploiting a featureof Rails just becuase you can.

My thanks to Max and Mike over at the RailsForum for their feedback.

You don’t need to be a complete agile guru to use the practices from extreme programming to develop and ship a successful software application.  All you need to do is make sure your application is heading in the right direction.

After reading a post, entitled “I had that idea years ago!” on the Signals Vs Noise blog and this article on systematic approximation in mind mapping, I came to realise that software projects don’t initially need a big specification or a detailed road map of milestones and tasks.  Instead you need an idea, and you need to develop it using continual feedback from the softwares intended users.

Imagine being a tourist in a city that your unfamiliar with and you want to get to a specific tourist attraction.  You would ask for directions, use a mobile device, or even look up a map of the city (yes, you do get maps on paper!).  The feedback you get from these methods helps you go in the right direction and gets you to where you want to be.

What would happen if you just thought you could get there without any feedback?  Chances are you would get lost.

In software projects, feedback is probably the best thing you can get if you want to stay on target for your software idea.  Once you start developing your software application, get feedback on it as early as possible.  It might take more than one pass at a feature to get it right but with the feedback your getting, you’ll only need to make a few small passes at that feature.

What would happen if you wrote the same application without any feedback and then shipped it?  I can guarantee you would have a massive list of feedback that would take you longer to go through than if you got feedback earlier in the project.

So next time you work on a project for a software application and you want it to hit the mark, get feedback on it as early as you can.  Do this and you’ll be well on your way to a successfully shipped application.