I discovered that the geokit_rails plugin doesn’t support named_scope. For those unfamiliar, named_scope methods can be chained to narrow down a query while only performing one query. Here’s an example:

class Business < ActiveRecord::Base
  acts_as_mappable 
  named_scope :active, :conditions => {:active => true}
  named_scope :nonprofit, :conditions => {:nonprofit => true}
end

@active_businesses = Business.active
@nonprofits = Business.nonprofit
@active_nonprofits = Business.active.nonprofit

Geokit has a really nice syntax for locating businesses within a certain distance.

@businesses = Business.find :all, :origin => "742 Evergreen Terrace, Springfield IL", :within => 10

However, you simply cannot, out of the box, use this with named_scopes. So I cannot do

@businesses = Business.active :origin => "742 Evergreen Terrace, Springfield IL", :within => 10

The way Geokit exposes itself to ActiveRecord is just not compatible.

RailsCasts to the Rescue!

Ryan Bates, Railscasts producer and all-around awesome guy, has posted a solution in which you can build your own dynamic named scopes. We can create our own scope for Geokit, because the Geokit-Rails plugin provides a public method to retrieve the distance SQL fragment.

First, we add a new named scope to our model

   named_scope :map_conditions, lambda { |*args| {:conditions => args} }

Next, we add our own method to handle the scopes.

    def self.by_location(options ={})
      scope = self.scoped({})
      scope = scope.map_conditions "#{distance_sql(options[:origin])} <= #{options[:within]}"
      scope
    end

We use this method to append our own conditions to the anonymous scope. we use the distance_sql method which takes whatever we pass in via our :origin option, and we concatonate the equality. In this case, we want distance less than or equal to our distance.

We can now do exactly what we wanted, although with modified syntax.

@businesses = Business.active.nonprofit.by_location :origin => "742 Evergreen Terrace, Springfield IL", :within => 10

Pretty amazing stuff.

When working in Rails, I often find that several classes have the same behavior. A common approach to share code between objects is the tried-and-true method of inheritance, wherein you create a base class and then extend your subclasses from the parent. The child classes get the behaviors from the inheritance. Basically, Object Oriented Programming 101.

Languages like Java and Ruby only let you inherit from one base class, though, so that isn’t gonna work. However, Ruby programmers can use modules to “mix in” behavior.

Mixing it up and Mixing it in

Let’s say we have a Person class.

class Person
  def sleep
    puts "zzz"
  end
end

Now let’s say we need to define a Ninja. We could create a Ninja class and inherit from Person, but that’s not really practical. Ruby developers really don’t like changing the type of a class just because its behavior changes.

Instead, let’s create a Ninja module, and put the behaviors in that module.

module Ninja
  def attack
    "You are dead."
  end
end

We can then use this multiple ways.

Mixing it in to the parent class

In a situation where we would like every Person to be a ninja, we simply use the include directive:

  class Person
    include Ninja
  end

Every instance of the class now has the Ninja behaviors. When we include a module, we are mixing in its methods to the instance. We could also use the extend method, but this mixes the methods in as class methods.

Notice here that we redefined the class definition. This appends to the existing class; it does not overwrite it. This can be a dangerous technique if used improperly because it can be difficult to track down. This is the simplest form of monkeypatching.

There’s an alternative method.

Mixing in to an instance

We can simply alter the instance of an object, applying these behaviors to a specific instance and affecting nothing else.

  @brian = Person.new
  @brian.extend Ninja

Here, we use the extend method because we need to apply these as class methods to the object instance. In Ruby, classes are objects themselves. Our instance needs to be extended.

A more practical exaple – Geolocation

I was working on a project this weekend where I had several models that needed latitude and longitude data pulled in via Google’s web service. I used the GeoKit gem and the Geokit-Rails plugins to make this happen, but I soon noticed I was adding the same code to multiple classes.

acts_as_mappable
after_validation_on_create :geocode_address

def geocode_address
  geo=Geokit::Geocoders::MultiGeocoder.geocode (address)
  errors.add(:address, "Could not Geocode address") if !geo.success
  self.lat, self.lng = geo.lat,geo.lng if geo.success
end

It seemed immediately apparent that this should go in a module which could be included into my classes. However, I wanted to also make the two class method calls – the after_validation_on_create callback and the acts_as_mappable macro.

Ruby has a facility for that type of situation

self included

def self.included(base)
#
end

This method is called when a module is included into a class, and it gives you access to the class that’s doing the including. You can use this as a handle to call any class methods. With that, my geolocation module looks like this:

module Geolocation
  
  def self.included(base)
    base.acts_as_mappable
    base.after_validation_on_create :geocode_address
  end

  def geocode_address
    geo=Geokit::Geocoders::MultiGeocoder.geocode (address)
    errors.add(:address, "Could not Geocode address") if !geo.success
    self.lat, self.lng = geo.lat,geo.lng if geo.success
  end
  
end

So now any class that needs geolocation just needs to look like this:

class Business
  include Geolocation
end

class Nonprofit
  include Geolocation
end

Summary

The above problem could have been solved by using a parent class like MappableOjbect that included the code, but it then makes putting in additional behavior more difficult. Using modules to share code is the preferred way to attach behaviors to objects in your applications.

Many types of users make use of alternative text for images. Users who use screen reading software rely on those tags to describe the images they can’t see. Mobile users with slow connections or ‘pay by the minute’ plans often times turn off images to speed up the process.

Rails does something a little crazy with the image_tag helper… it automatically generates the ALT tag, which is just a horrible horrible idea.

  <%= image_tag "rails.png" %>

generates

  <img src="/images/rails/png" alt="rails" />

This is an absolutely awful idea, and I presume this was done just to shut up the XHTML Transitional validator which will complain if you leave ALT text off of your image elements.

You shouldn’t be adding ALT text to images to satisfy a validator. You should be doing it because it’s The Right Thing To Do.

ALT text is designed to describe the image, to be an alternative to the image. So, when placing the image on the page, take a few seconds to describe what it is.

  <%=image_tag "rails.png", :alt => "The Ruby on Rails Logo"
  <%=image_tag "banner.jpg", :alt => "Awesome Consulting Services - We Make Websites" %>

And for goodness sakes, please don’t prefix your description with “An image of…”. Screenreaders and other devices will make it completely clear to us that the content is supposed to be an image.

Some images convey more information than the ALT may allow, and so we’ll talk about that next.

This is the first in a series of articles on developing accessible Rails applications. Accessibility is really important to me as I spend a lot of time working on web sites and applications that need to adhere to Section 508 guidelines. Making web sites accessible is also the Right Thing To Do.

JavaScript and Accessibility

When developing Rails applications, I try really hard to develop the entire application without using JavaScript, since a lot of users who rely on screen reading software can experience problems with AJAX, so these people tend to disable scripting. Using a screen reader is a lot like looking at a web page through a paper towel tube. You can’t see the whole thing at once, and it’s not likely that you are going to see something changing on the screen, and I’ve never come across screen reading software that can really let you know when a section of the page has been replaced. It might tell me that the content has changed, but I have to make it read the whole page back to me again and figure out what happened. Popup advertisements add to the problem, so people tend to just turn of the JavaScript completely.

Accessibility doesn’t just mean the users with disabilities, though. It can also mean those BlackBerry users who have horrible JavaScript support. So, what we’re really talking about is the age-old idea of “progressive enhancement.” Make a low-tech version work first, then spice it up.

Rails and REST

When you develop Rails applications and you’re working to keep your applications adhering to a RESTful design, certain URLS can only be accessed by certain methods. For example, to delete a record, you’re supposed to send a DELETE request to the destroy action of the controller.

Web browsers can only do GET and POST requests. GET requests are only supposed to read data, and POST requests are intended to change data. You POST to create something. Rails uses hidden form fields to emulate the DELETE and PUT methods.

However, Rails allows you to build links that can do other types of requests, like the DELETE request that’s planted in the default scaffolding. Honestly this is one of the single biggest mistakes the Rails core team has ever made. Here’s why:

This code:

  <%=link_to "Delete", project_path(@project), :method => :delete %>

actually produces a hidden HTML form. When you click this link, it actually submits the hidden form. This requires JavaScript to run and also mixes behavior with HTML markup. It’s a truly ugly situation that really should never be used.

A simple solution

The simple solution is to use the button_to helper instead. It generates the same form, but requires no JavaScript to activate it.

  <%=button_to "Delete", project_path(@project), :method => :delete %>

But I don’t want a button!

You don’t have to have one. As Tore Darell points out on his blog, the appropriate way to handle this is to do the opposite of what Rails was doing. You build the form yourself using button_to, but use unobtrusive JavaScript to replace the form with a link, by simply hiding the form, adding an observer to the newly created link which submits the form.

Add this to your application.js file to replace all of your button_to instances.

document.observe('dom:loaded', function(){
  $$('form.button-to').each(function(form){
      var link = new Element('a', {href:'#', 'class':'button-to'});
      link.update(form.down('input[type=submit]').value);
      link.observe('click', function(e){
        e.stop();
        form.submit();
      });
      form.insert({after:link});
      form.hide();
  });
});

Tore got it right, and the Rails team got it wrong. This solution is great because

• It’s accessible. With JS disabled, the buttons will work and perform the appropriate actions.
• It’s clean. The JS is unobtrusive. It’s not intermixed with your code, and it doesn’t use DOM Level 0 “onclick” which, in some instances, is considered deprecated or invalid markup.
• It makes it look like a link without the need to resort to crazy CSS antics.
• A single fix replaces all occurrances. You’re not generating duplicate JavaScript code all over your views like you would with link_to :method => :delete.

Replacing a single instance

You can replace button_to instances that contain a specific class if you simply wrap the JavaScript code in a simple if... block:

   <%=button_to "Dismiss", user_message_dismissals(:message_url => message.id), :class=>"dismissible" %>

    if(form.descendants().any(function(element){ return element.hasClassName("dismissible")})){
         var link = new Element('a', {href:'#', 'class':'button-to'});
         ...
    }

And I’m sure there are better ways to do that, too.

That’s it for now. I welcome your comments and suggestions on this topic and others.

lazy_developer is a Ruby on Rails plugin I use on a lot of my projects to make my life easier as a developer. It’s a collection of Rake tasks that automate some common operations. Some of the more interesting features it provides are

• the ability to dump a database to YAML format and then pull it back in again
• a simple way to obliterate models, controllers, views, helpers, and related files easily (in the case of a refactor or a fat-fingered typo
• a method to compact your migrations into a single migration file
• and of course, automatically clone your test database whenever you migrate

Today, Kevin Gisi and I gave this plugin some much-needed love and attention after we discovered a few problems. Here’s what’s new:

Data exporting works with Rails versions prior to 2.0

Got an old database you’d like to pull in? This now works in Rails 1.2.3!

Data dumping works much better now!

We noticed some duplicate records sneaking into the output files, and it was due to a mistake I made when I implemented my own version of record pagination. It wasn’t limiting correctly, and Kevin quickly spotted the reason why. It also wasn’t storing records in the YAML file properly either, which I also resolved.

This is tested on Microsoft SQL Server, MySQL, and SQLite3.

Migration compacting works now

This was patched a few days ago and merged in, but I flip-flopped a couple of lines during a merge and it made it into the master branch that way. Kevin decided he’d like support for Subversion for this, so he added it. I’ll add in Git support very soon.

Interested in using this on your projects? Go get lazy_developer right now!

As promised, here’s the slide deck from my talk “Learning To Walk In Shoes” from April’s Twin Cities Code Camp. After the slides, we went over some demo applications, and you can get those from Github so you can play around with them yourself.

Learning To Walk In Shoes

Here are the slides from my RailsConf 2009 talk. You can watch the slides below, download the PDF.

Rails and Legacy Databases (PDF slides)

I had the extreme pleasure to watch Bob Martin talk at RailsConf. He is an amazing speaker for more than just his delivery style (which is amazing). He’s incredibly bright, and has a wealth of experience that everyone can learn from. The majority of his talk was focused on acting professionally, and his definition of professionalism means, specifically, writing tests for every line of code in your application.

I can’t agree with this more. Without a robust test suite, your application is garbage. As Bob said in his talk, without tests you will be afraid to change your coe because it will break and you’ll have to spend hours finding out why. When you have tests, making changes is much easier because you no longer have fear.

If you have applications without tests, write them. Follow Bob Martin’s rule – “Check the code back in a little cleaner than you found it.” If you don’t know how, let me know. I offer effective one-on-one or group virtual training sessions.

If you are writing applications for clients, you need to test your code. If you’re working with a development firm, you should ask them how they test the code you pay them to write. Professional developers write tests and can then respond quickly to changes. Amateurs just hack things together, and then charge you hourly to fix their mistakes.

David Chelimsky gave a great presentation on mocking and stubbing. I liked the fact that he talked about a lot of the fears that people have when they do rely on mocks and stubs. It was also nice to see someone clearly state that one of the problems we have in the Rails community when it comes to testing frameworks (and most other libraries) is that people tend to promote their own projects while trashing other libraries. He challenged an audience member to create a site where we could write up comparisons.

Highlights of the talk:

• Stubs vs. mocks
• “Ravioli” code where everything is clumped up in nice separate concerns
• “Calzone” code, like Rails, which is harder to test in isolation.
• Stubble, a wonderful-sounding library that can completely stub out an ActiveRecord object, which will be usable in every testing framework.

The Rails Config Model gem makes it extremely easy to create a “settings” table in your application. It creates a configuration controller and model that can be used to quickly create configuration table for your system so you can store system-wide variables that you’d like the site administrator to be able to set.

You can see instructions on usage or contribute to the project.