Great Features you see, Great Features you don’t

I love the song “Standing Here” by the Stone Roses (you may notice a Roses-bent to this blog). Not only does it have some of John Squire’s finest noodlings, great lyrics and fantastic work by Mani - it also includes one of my favourite bits of backing vocals in the world. A simple “ooh ooh” from Reni. That’s not the clever bit though. In the first verse there is no “ooh ooh”. In the second verse there is one “ooh ooh”. In the third, there are two “ooh ooh”s. I can still remember the first time I noticed it (months after I first heard the song). I pointed it out to my friends and they were all impressed too.

Just a tiny detail.

Hard to spot.

But once you’ve seen it you notice those same, tiny, details in their other songs. That craftsmanship, that attention to detail, is what made them great songwriters (at least till the Second Coming when Squire shoved Geffen’s money up his nose).

In the same vein, I have just spent twenty minutes adding a similar detail to our application. One that most people will never ever notice. But if they do, they will think “that’s nice” and for thirty seconds they will feel good about their choice to shell out cash on us. And the feature? It’s this:

Spotted it yet? How about here?

That’s right - the person object has a gender field and, based upon the gender, it displays the correct possessive - his or her (or their if not known) in the menus. Again, a tiny detail. But they all count.

Can you use the same controller in two places at once?

I’m currently wrestling with a problem. My application has Attendees that either belong to PrivateCourses or Bookings. It uses a polymorphic association for this: has_many :attendees, :as => :attendable.

However, in both cases the UI is pretty much identical. So I figured I could set up routes like so:

map.resources :private_courses do | private_course |  private_course.resources :attendees, :name_prefix => 'private_course_'endmap.resources :bookings do | booking |  booking.resources :attendees, :name_prefix => 'booking_'endmap.resources :attendees

This gives me three options: either reference the attendee in the context of a PrivateCourse private_course_attendees_path(@private_course), in the context of a Booking booking_attendee_path(@booking) or all on its own attendee_path(@attendee). I was thinking I could examine the supplied parameters to figure out what the Attendable should be:

if !params[:booking_id].blank?  @attendable = Booking.find params[:booking_id]elsif !params[:private_course_id].blank?   @attendable = PrivateCourse.find params[:private_course_id]endif @attendable.blank?   @attendee = Attendee.find params[:id]else  @attendee = @attendable.attendees.find params[:id]  end

Looks good so far.

But it turns out my view code is turning into a conditional nightmare. Take the “new” form:

if @attendee.attendable.is_a?(PrivateCourse)  form_for :attendee, :url => private_course_new_attendee_path(@attendee.attendable) do | form |   ...  endelse  form_for :attendee, :url => booking_new_attendee_path(@attendee.attendable) do | form |    ...  endend

Of course, not only is this ugly but there needs to be code in the controller to set up the new Attendee’s Attendable. In which case I should just make the controller look like this:

@attendee = @attendable.attendees.buildif @attendable.is_a?(PrivateCourse)  render :action => 'new_attendee_for_private_course'else  render :action => 'new_attendee_for_booking'end

Yet as I went through this, I kept thinking that every single action needs the same conditional logic - actual form definitions aside, there is actually nothing that is shared between the two conditions.

So, my answer, barring a flash of inspiration, is “No, you cannot use the same controller in two places at once”.

Now I need to rework my body of code to have two controllers - PrivateCourseAttendees and BookingAttendees that both make use of a set of shared partials, probably in an Attendees folder.

Markaby Gotcha

One thing to watch out for, when using Markaby:

  link_to_remote 'whatever', :url => some_path(@something), :before => do_this, :complete => do_that

will not work.

Instead you need:

  link_to_remote 'whatever', :url => some_path(@something).to_s, :before => do_this, :complete => do_that

Spot the difference? The :url parameter has a .to_s appended on the end. Otherwise Markaby intercepts the call and eats the output.

Rails 1 - 0 Smalltalk

One thing has struck me over my recent Rails-beautification tangent.

My fictional resource-routes example:

  map.resources_called(:course_templates,     :adding => [      GetMethod.called(:build_courses, :on => :members),       PostMethod.called(:do_build_courses, :on => :members)    ],     :nesting => map.resources_called(:course_details)  )

looks better than the fictional Smalltalk example.

Likewise my (real) Markaby view example looks better than the (real) Seaside/Smalltalk example.

Things are not so bad in the world of Rails …

Single Table Inheritance and Virtual Controllers

I have the following models: a “base” class, Event, with two descendants, PublicCourse and PrivateCourse. Although, data-wise, they are pretty similar, behaviour-wise they are quite different. So Single Table Inheritance (STI although that could mean something completely different) is the way to go. (The alternative, of course, is a mix-in - which in most cases is far more preferable to inheritance).

I also have a public_courses_controller and a private_courses_controller. As each needs their own user-interface, distinct from the other.

However, there are places in the user-interface where I am showing a list of Events and I wanted to link to them - either private or public. I started by writing a helper:

def event_link(event)  event.is_a?(PrivateCourse) ? link_to(h(event.title), private_course_path(event)) : link_to(h(event.title), public_course_path(event))end

Meaning I could write views like so:

  @events.each do | event |    event_link(@event)  end

However I didn’t like it - the way events used a totally different link syntax to every other entity in my application.

So instead I created a “virtual” controller, events_controller, that has a single show action.

def show  @event = Event.find(params[:id])  @event.is_a?(PrivateCourse) ? redirect_to(private_course_path(@event)) : redirect_to(public_course_path(@event))end

Now my view looks like

  @events.each do | event |    link_to(h(event.title), event_path(event))  end

The upside - my views are consistent, regardless of entity. The downside - if you click that link it forces a database hit and a redirect. However, I’m not expecting 11000 requests per hour, let alone 11000 requests per second (this is a commercial service, not a social networking phenomena) - so I’ll deal with the scaling issues if and when they happen

Internet Explorer "quirk" of the day

I happilly deployed the latest version of my application to our test server last night and posted a message saying “here it is - please test away”

I come in to work this morning and see a mail saying “when you click lots of the links you get an RJS error”. Weird - I fire up Safari and it works fine. I fire up Internet Explorer 7 - RJS errror. But only on some of the links. I try a different machine with IE6. Same thing. Try in Firefox. All OK.

After lots of wasted time I find out what the problem is. I have this in my page:

  <p id="new_staff_assignment">   <%= link_to_remove 'assign a new staff member', :url => new_staff_assignment_path, :before => show_progress_indicator, :complete => hide_progress_indicator %>   </p>

which fires the following bit of RJS:

  page.replace_html 'new_staff_assignment', :partial => 'new'  page.visual_effect :highlight, 'new_staff_assignment'

As I say - works fine in Safari/Camino/Firefox but not in IE6 or IE7.

But then I changed my page to:

  <div id="new_staff_assignment">  <%= link_to_remove 'assign a new staff member', :url => new_staff_assignment_path, :before => show_progress_indicator, :complete => hide_progress_indicator %>   </div>

and what do you know? It works fine.

I guess a P tag doesn’t have an innerHtml property whereas a div does.

Whining about 37signals (part 2)

Does your product pass the Subway Test?

The key fault with Basecamp is that people have to use it for it to be useful. And clients, in particular, are happier using e-mail. My number one improvement would be to create project-specific e-mail addresses - so clients could e-mail the project (the mail becoming a message or comment - although how it tells is something for the smart people to figure out). And I did put that in my customer satisfaction survey.

There used to an old joke about software - it’s not finished till it does e-mail. Unfortunately, it’s funny ‘cos it’s true. My application, when it goes live, has full in-built e-mail support - it’s just a necessity.

Whining about 37Signals

I love 37Signals, I love Rails and I love Basecamp. But I do not like this banner in my Basecamp account. It’s not really a System Announcement is it?

Ruby on Rails is the MacOS to Java/.Net’s Windows

Pierre Igot rants about the user interface for Apple’s Mail.

John Gruber rants about click-through in background windows in OSX.

Both of these (and there are many more if you search the interweb) show the extremely high standards that Apple is held to when it comes to user-interface details. You don’t often see criticisms of Linux or Windows applications that go into such intricate detail:

If you select “Sending…” while Mail is in the process of sending the message, Mail continues to display your list of sent messages, excluding the message currently being sent. In other words, not only does the text label temporarily display a status message instead of the text that should normally describe its contents, but on top of it that temporary message misleads you into thinking that you will be able to see the message that Mail is currently in the process of sending by clicking on it, when actually it does not show you that message.

The reason I mention it is not in some sense of Apple vs Microsoft superiority (I’ve not used Vista or Office 2007 and they are supposed to be OK on the UI front - although I bet you could find a folder caption being used to display a status message if you looked hard enough) but more a sense of Rails vs everything else superiority.

I was talking to another developer today about what I should call a method on one of my objects. My colleague is one of the most talented developers I have ever met but he has never used RoR.

I said “I’m not sure if I should call it account.number_of_events_remaining or account.number_of_remaining_events“. He said either would be fine - “if the name reads right then that’s good enough“. To which I replied “but no matter which one I choose I seem to type the other name“. To Nick this was “operator error” - a problem of typing. To me it was symptomatic of something deeper. The words didn’t feel right. And as we all know if it doesn’t feel right it probably isn’t right. It was a folder caption being misused as a status label.

I could alias the method names - in other words use both. Nick said programmers need consistency. I agreed - aliasing is useful but I think it just adds unnecessary confusion in this case. He suggested I choose one and type it out one hundred times so it becomes imprinted in my brain. This proved to me that the name was wrong - “if i have to force myself to do all of that just to get a property name right then it’s the property that’s at fault - not me“. Plus if we have five developers, with a hundred properties, think how much typing that is before you even write a line of code!

Esoteric discussion by developers with too much time on their hands (I wish)?

In a way, yes; no paying customer will ever see that property (apart from indirectly through the UI).

But, looking deeper, it’s important. Vitally important. Because it’s all about meaning and understanding. When you are looking for the status message do you look to the status bar or your folder list? When you are trying to find out how many events you have left do you have to try different combinations of valid words?

Is it designed so that you “get it” straight away or do you have to rehearse it till you understand?

(In the end, I went with account.remaining_event_allowance)

REST, Rails, Skinny Controllers and Resources

Some time ago I wrote about how I was struggling to understand how the new style RESTful controllers work. In particular, it struck me that everything became a noun, when verbs were equally important.

After a few months of actually using RESTful Rails, I’m still struggling. The new-style controllers are significantly simpler (in particular I love nesting resources). Skinny controllers are a good thing.

But what if you need to create the same model from multiple places? For example, you may have a list of customers - so you can create one from there. But what if you need to create one “on-the-fly” whilst building an invoice?

In the “olden” days, I would have had an InvoiceCreationController that handled all the details of creating an invoice, including the new customer creation. As you can imagine, these could get pretty big and complex.

Should you reuse the original CustomersController? That means your controller needs to be told who is calling it, so it can render the correct response (in the “list” case you would want to return to the list of customers, in the “invoice-creation” case you would want to return to your partially created invoice).

So, who better to ask than Mr Buck himself? I mailed the Rails Way asking this very question and got this response back:

The “1-1 between controllers and models” is definitely not the case, and I tried to debunk that misconception somewhat in Part 1 of the SignOut refactoring. There is this idea in the community that resource == model, and that is not true. A resource _can_ be a model, but it can also represent an aggregation of models, or a slice of a single model. It can even represent something that isn’t a model at all. A resource is something like “permissions”, “sessions”, “people”, “logos”, “files”, “colors”, etc. Basically, any noun you can extract from your domain can be a resource (though you probably don’t want every noun in your domain to be a separate resource).

This sort of fits with an idea I had ages ago, about an object’s aspects (this was pre-AOP) - that was also sort of hit upon by Allen Holub with his visual-proxy architecture. In other words, controllers are part of your user-interface, just as much as views are. They do not represent models. In fact, your user interface never represents models. Instead it represents things that matter to the user. That may map to a model. It may map to a collection of models. It may map to three attributes from one model and two from a related one.

So I guess for my example I want three controllers (keeping them nice and skinny) - one for creating your invoice, one for creating your customer (in the context of creating an invoice) and one for managing customers in general.