Caffeine Driven Development

Years ago I used to hang around in a Danish Usenet channel where people could ask for comments on websites they’d made. You would see comments like:

The HTML and CSS isn’t valid so I don’t like your site.

Or:

Framesets was outdated years ago. Use
<div>’s and specify the layout with CSS.

But as a matter of fact this isn’t very good reasons a site would not be good. We, as web designers or web programmers, design for people, not for colleagues. If your users like your site or application, it’s good. End of story. None of these things has any effect on whether or not a site is good:

• Standards-compliance Your user doesn’t care about whether or not your HTML or CSS is valid. If the site works in his browser, all is good.

• Using the latest and greatest technology This may come as a surprise but your user doesn’t know about jQuery, AJAX, Ruby on Rails, CSS frameworks, or whatever kind of new and nifty, nerd-pleasing technology you’re using.
• Keeping industry standards Again, your user can’t tell the difference between tables and <div>’s. Your choice has no impact on your users’ opinion about your site.
• Performance optimization If your site is fast enough to feel responsive, don’t waste time and money optimizing stuff. It is not humanly possible to tell the difference between 10 and 20 ms.

I am not telling you to start using tables for layout. Or framesets, for that matter. Do not misunderstand me. I love Ruby on Rails, jQuery, and valid HTML/CSS. I like it because I’m a web programmer. It’s important to keep priorities, though. Your user is not a web programmer. This is what matters to him:

• Accessibility If your user can’t access your site, it might as well not exist. There are several types of handicaps that impacts the way your user accesses your site. He may be using a screen reader if he’s blind, or he may see the colors of your site differently if he’s color blind. Your site should support that.
• Usability If your user can’t work out how to use your site, he doesn’t like it. Chances are that he leaves it and never comes back.
• Responsivity Your user looses patience if he has to sit around and wait forever for a site or application to respond. But the performance doesn’t have to be optimal for a site to feel responsive.
• It works in his browser I know. It is very painful to design for Internet Explorer. But truth is that the majority still uses it. Most people don’t know what a browser is. They think Internet Explorer is the web. Don’t blame them. No one told them otherwise.

You may be sensing a pattern. Accessible sites is often standards-compliant, for example. Responsive applications and sites often uses AJAX. If a site lives up to all those definitions of a good site that nerds have, it should only be an effect of what a user care about.

In the most recent episode of Railscasts, Ryan Bates mentioned that he usually wouldn’t recommend updating data in migrations, but that in that case it was the best way around.

That got me thinking. Why is everyone so afraid of doing that? The purpose of a migration is to bring a database from one state to another. A migration should be also be reversable. But in order to cleanly change the state of a database you sometimes need to alter the data. Putting these alterations in your migrations ensures that your data always “fit” in the database. And since you most likely want the ability to rollback the alteration as well, a migration is really an obvious place to locate it.

You just need to make sure that both the self.up and self.down alters both the database schema and the data properly, and make sure to raise an ActiveRecord::IrreversibleMigration exception whenever it isn’t possible to rollback a migration, e.g. when you have been deleting records in self.up.

Update: As Mike Breen kindly points out in the comments below, the specific situation I’m referring to is updating data correspondingly to a schema change. Things such as adding or editing categories should be handled by seed data plugins like seed-fu.