Sometimes, it’s worth stating the basics for all to see:

• Follow the Model-View-Controller paradigm.  In particular, your views house your user-interface, your models handle the application and your controllers mediate between the two.  Controllers do not contain rules, conditionals dealing with business conditions, queries looking for objects related to the one in question.  All those things belong in the models.  
• Use ActiveRecord conventions at all times.  It may not be the most efficient thing in the world but for most of you out there, it doesn’t matter.  
• Use ActiveRecord and migrations to define and manage your database.  All your business related stuff stays in one place - the models - including defining relations (associations), validations and rules.  In particular, ActiveRecord associations makes some tasks easy (very simple many to many relations) and gives you things (such as polymorphic associations) that you can’t safely define using straightforward SQL.  With judicious use of validations you can ensure that the data stays safe.  
• Use RESTful designs in your controllers.  This means that your controller very rarely grows beyond seven actions (index, show, new, create, edit, show, destroy) - and RESTful routing ensures that GETs and POSTs go to the right places.  If you need to extend things then add a sub-controller.  For example, if you were transferring an employee to another, you could have a route: /employees/1 for the employee him/herself, /employees/1/transfers/new to let the user define which company the employee is moving to and /employees/1/transfers/create to actually do the transfer.  And if you’ve defined your model correctly, the implementation of /employees/1/transfers/create should be as simple as @employee.transfer_to(@company)
• Write your tests (or specs) first.  One - this gives you a series of small wins, which is good for your self-esteem.  Two - it helps to clarify your thinking.  ”I need to write something that does X and Y, resulting in Z … oh hang on, do I really need Y?  What about U and V?”
• Use mock objects when testing your controllers.  Why bother coming up with lots of test data when all you really need to say is “if I the model saves correctly then redirect to X, if it doesn’t save then show Y”.  In the “transferring employees” example above, you only need to test that the controller calls “transfer_to” on your model.  Of course, your model will have already tested that transfer_to does what is expected of it.  
• If you find yourself repeating a bit of code, or writing something similar then STOP and refactor.  Add methods to the application controller, create a new controller descendant, stick it in a view helper, add a module to your models, write a partial (and if it needs parameters, write a helper that takes a set of parameters and does the call to render :partial for you)
• Did I say write tests and specs first?
• Oh, and if it starts getting complicated you’re almost definitely doing it wrong.  

rake db:fixtures:load is probably one of the most useful commands I have used recently.

You see, I was meeting some people about some potential work. They wanted to see an example - preferably related to payment systems. I had some code but unfortunately, the service that is part of had been switched off (a number of reasons, none of which connected to my supreme stylings). I had a copy of said code on my machine, but no database and I had no time to prepare.

So how could I demo it? Easy peasy.

cd ~/Source/my_apprake db:migraterake db:fixtures:loadruby script/server

And then start Camino.

Because the application had been developed test-first I knew that there was a decent set of data within those fixtures. Data designed to show all the edge cases, all the complexities of the application. From users and logins through to payment records and customers.

It is fair to say that when writing your applications, test-first, the fixtures are the hardest thing. It can take ages and it is detailed, painstaking work. Especially if you are trying to build a narrative (:dave logs in, selects a :cucumber, goes to the :checkout, pays with his :expired_credit_card which is rejected).

But the benefit is there. Building a narrative helps you when you come back to the code in six months time. Defining a wide-range of test fixtures helps you when you make changes and need to ensure that it won’t break a feature over there. And it helps you demo your code in front of a prospective client when faced with the unexpected.

Data Highway by KLatham.

You know how it is - there are some things that you are just not comfortable without. My phone in my back pocket, my wallet in my front pocket, the key in the front door when I go to bed (just in case there’s a fire and we have to make a hasty exit), the dog under my feet (tripping me up), one of my large collection of jackets (current favourite: leather biker jacket).

And so it is with Rails projects. Before I do anything I do the following:

• Load the Exception Notification plug-in and configure it with my email address
• Load the form_test_helper plug-in so I can confidently test my forms
• Load the ARTS plug-in so I can confidently test my AJAX user interfaces
• Load Markaby so my views are beautifully coded and semantically correct
• Create the Rails session store within the database (rake db:sessions:create)

Of these, the one I really can’t do without is Markaby (although ARTS comes a close second). I don’t know what it is (apart from Why the Lucky Stiff is genius). I can’t stand looking at rhtml files any more - too many angle brackets for a start. Instead, my mabs are things of beauty - and as I write the code to produce the views, I find that they are more semantically correct as well. For example:

div.row do  label “Email Address: “  text_field :person, :email_address  p.explanation “Please supply a valid email address so that we can send you a confirmation email”end

As I’m writing the Markaby code, class names like “explanation” seem to fit naturally - the code reads better, the HTML is semantic and the CSS is simple.

What more could you want?

or why Jeremy Kemper joined 37Signals.

Ok. All that being said, I’m looking forward to using Rails some day when I start a brand new project from scratch, with Rails in mind from the beginning.
But I hope that this reaches someone somewhere thinking, “God our old code is ugly. If we only threw it all away and did it all over in Rails, it’d be so much easier!”

I really like Test-Driven Development. Think about what you need to write, write a test (that fails), then make it pass. Repeat. Refactor.

Obviously, the major benefit is that further down the line you can be sure that what you are writing today won’t break what you (or someone else) wrote six months ago. The tests also serve as a type of documentation (why is that method on the invoice class so complicated? let’s simplify - oh, that test fails - it appears you can’t allow the invoice value to be less than £3 on a Wednesday) - especially if you are using RSpec.

But one advantage, that I feel is often overlooked, is because you are starting from the point of view of a user of your code, your method names and parameters are automatically designed from the user’s perspective, not the implementor’s perspective.

One of my favourite examples is

dave.hit nail, :on => :head, :with => hammer.

This makes your method definition look like

def hit target, options  place = options[:on] || :head  object = options[:with]  …end

In other words the method definition does not reflect how the caller would actually use your method. If you started from the method definition you would probably come up with

def hit target, place, object
…
end

This makes much more sense from the implementers point of view, but our call becomes

dave.hit nail, :head, hammer

which is slightly less readable from the point of view of someone examining the call in six months time. And those tiny annoyances add up without the reader realising it, till they are tired, the last few lines of code didn’t really sink in and they think fondly back to that other chunk of code that was a joy to read. “Why can’t all code read like that?” they think.

Well, it takes a switch of perspective - one that test-driven development encourages and most other “methodologies” don’t even acknowledge.

Why should you use unless when it is little more than if !?

Because unless let’s you write code like this:

dave.punch george unless george.is_hard?

Isn’t that what code should look like!

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 …

In my brief exploration of Seaside one of the points that caught my eye was that the components render themselves in HTML.

 html table:    [html tableRow:        [html tableData: [html bold: ‘Name’].         html tableData: person name].     html tableRow:        [html tableData: [html bold: ‘Age’].         html tableData: person age]]

Two points: firstly - I read in one interview (sorry, can’t find the link) that this leaves the designer to control the CSS and the programmer to control the HTML. This immediately struck me as a good thing - for the HTML to be properly CSSable it needs to be well-structured and semantically rich. Which you should do anyway but it’s easy to forget. And secondly, that code snippet above looks great compared to your typical .rhtml file (I think it’s something to do with the angle brackets in HTML which make it hard to read).

So, in the interests of making my application more beautiful, I started investigating how to do something similar in Rails. Which lead me to Markaby - Markup in Ruby. Install the plug-in and, instead of creating rhtml views you create mab views.

Which look like this:

div.contents! do  error_messages_for :booking  form_for :booking, :url => booking_path(@public_course, @booking).to_s, :html => {:method => :put} do | form |    h3 “Customer Details: “    p do       label “Contact: “      collection_select :booking, :contact_id, @contacts, :id, :name    end    p do      label “Notes: “      text_area :booking, :notes, :rows => 5    end    p.explain “Add any arbitrary notes here”    p do      blank_label      submit_tag “Save”      text ” or “      link_to “cancel”, booking_path(@public_course, @booking), :confirm => ‘Are you sure?’    end  endend

Doesn’t that make you feel good? Especially the p.explain (which outputs a P tag with the class “explain”) - immediately you can see how semantic markup becomes integral to your views.

I did have a few problems with the helper methods - I had to set @output_helpers = false and I switched from using the form.text_field :method helpers to the old-style text_field :object, :method helpers (which also meant losing my labelled_form_builder). But it’s a small price to pay for such superior looking markup.

Mr Hansson has been winding people up recently, with his Twitter Controversy. But one of his more polite recent posts is about Seaside - a Smalltalk web framework that uses stateful objects on the server to allow a modal-style flow of control within your web application. One component receives a callback as the user clicks a link, it calls into another component and sits and waits until the second component returns control to the first - just like calling a subroutine.

I’ve made no secret of my love of Smalltalk - it’s what attracted me to Ruby and Rails in the first place. There’s a beauty about Smalltalk code (although please forgive any typos in the code below as I’ve not done any for a while) that you rarely see anywhere else, although Rails has it in places. I could go on for hours about:

  under21s:= people collect: [ person | person under21 ].  

Is that better than:

  under_21s = people.collect do | person |     person.under_21?   end

Not much in it. Ruby has the question mark - I like that as it makes the code read better. But Smalltalk has less superflous punctuation to make it read better still. And I love the full-stop to finish the sentence.

How about:

  nail needsHitting ifTrue: [ nail hitOn: #TheHead with: aHammer ].

Versus:

  nail.hit(:on => :the_head, :with => hammer) if nail.needs_hitting?

Ruby has the if at the end of the sentence, which I really like - and it’s even better when using unless. And Smalltalk has its slightly weird “everything is an object or message” ifTrue: method on the true and false instance variables that lead to something that is a bit less readable than the Ruby. But Smalltalk doesn’t need the parenthesis. And blocks are passed as normal objects (not weird add-ons that may or may not be tacked on to the end and sometimes implicitly converted to Procs). And if is not a reserved word.

Recently I’ve noticed the Smalltalk creeping into my Ruby style. Things like:

  validate(course, :against => template, :on => this_date)

Which is reasonable. But the brackets just kill me.

And then I had to write this:

  form_for(:course_template,     :url => course_template_path(@course_template),     :html => {:method => :put} do | form |     # form.stuff  end

It’s awful (yeah, yeah, I need SimplyHelpful).

What about, in config/routes.rb:

  map.resources(:course_templates,     :member => {:build_courses => :get, :do_build_courses => :post}) do | course_template |    course_template.resources(:course_details)  end

They really ought to read:

  courseTemplates:= map resourcesCalled: #CourseTemplates;    withAnAdditional: #GetMethod :called #BuildCourses :on #Members;    withAnAdditional: #PostMethod :called #DoBuildCourses :on #Members;    nesting: (map resourcesCalled: #CourseDetails).

Note: the nested call to resourcesCalled is actually sent to map, not to a nested object as in the Ruby original.

A literal translation would be:

  map.resources_called(:course_templates).with_an_additional(    :get_method, :called => :build_courses, :on => :members).with_an_additional(    :post_method, :called => :do_build_courses, :on => :members).nesting(      map.resources_called(:course_details)    )

The semi-colon chains method calls together (assuming each call returns the original return value from map.resources_called. But it’s really really ugly in Ruby.

The closest I can think of for this is:

  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)  )

which is a lot better but still pretty ugly (nested brackets - urgh).

Of course, map.resources is probably an instance of DHH’s syntactic vinegar - I’m sure that in his mind you should never add extra calls as it breaks the nice clean REST architecture. Well tough. I think myserver.com/course_templates/23;build_courses describes what I want very succinctly.

It’s definitely something that’s on my radar now … I want my Ruby and Rails code to be beautiful. Otherwise I may just be looking at Seaside in more depth.

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)