James Wilding's Weblog

Some lessons I’ve learnt working on my latest Rails project, a piece of tidy-and-fix work on an existing Rails application. Working on this project has really taught me a lot about the right and wrong ways to use Rails.

1. Routes are important

The app that I was asked to rebuilt had no routes. Nothing.

That’s not to say that no URLs worked with the app, just that the mappings between URLs and controllers/actions was defined in the code itself — mostly using the old Rails convention:

This makes it very difficult to discover how a Rails app responds to a particular URL, without hunting through the controllers to find a corresponding action. It also makes working with REST a nightmare!

Lesson learnt: use routes.rb

2. Conventions are important

Rails is all about convention over configuration, of course. But when you’re coding a Rails app — especially if you’re new to Rails — it’s easy to ignore those conventions, or just be plain unaware of them.

This leads to a lot of unnecessary work. I’ve spent a lot of time over the past few months translating unconventional code into code that more closely fits the Rails way of doing things: the result is code that’s easier to test, easier to maintain, and much, much faster.

Lesson learnt: take some time to understand Rails’ conventions

3. Simplicity is important

The more I write code, the more I find myself thinking: complicated code is a Bad Thing. Of course, as a kind pedant once told me, there’s a difference between complicated and complex.

(If you don’t have a dictionary handy, “complicated” roughly means messy, difficult to understand; “complex” means many interconnected parts, or a large system. The key difference is that complex systems can be well designed: complicated systems are not.)

OK, dictionary rant over :) Messy, complicated Rails applications come about when a developer doesn’t take the time to think things through. Simplicity is normally easy if you take some time to plan your work upfront — messy code happens when things are rushed or not thought through.

Lesson learnt: think before you start coding

4. Ruby is important

Obvious, but very true: Ruby is important to Rails applications. If you’re new to coding, or new to Rails, then take some time to learn Ruby first: otherwise, you’ll miss out on the power (and beauty) of a great language and a great framework.

Lesson learnt: learn Ruby and Rails, not just Ruby on Rails!

You are important, too

Conclusions? All of the above (and more) is important when you’re developing a Rails app. And you, the developer, are important too — have fun, keep learning, and don’t work too hard. Rails should be fun :)

This tweet from Saul Kaplan got me thinking: there are really two ways of looking at passwords.

Developers, geeks, and the security conscious think like this:

I need to protect this website/application so criminals don’t steal my personal details, bank account number, or email address. I should choose something secure: preferably a random collection of letters, numbers, and symbols. Plenty of websites store passwords as plain text, too, so I should pick a password that’s unique. I won’t be able to remember it, but my browser/keychain can handle that and the website/application will be much more secure.

Ordinary users think of passwords like this:

I have to type something into this box to make the website work. I’ll type “12345″: that’s easy to remember.

This is a problem.

Most ordinary users are aware of security as a vague, secondary concern: “someone might take my credit card details” or “emails can contain bad stuff”. Most ordinary users do not see passwords as a key part of security, and even if they do, they don’t really understand the implications of choosing a bad one.

To ordinary users, a password is not a security feature: it’s a hurdle to be jumped before they can do what they want to do.

How do we combat this? I don’t know. The tough option would be to check password strength and force users to choose a strong password. In the same way that websites validate email addresses on signup forms, they could validate passwords too.

Imagine if, in HTML5, you could do this:

Where “secure” is some attribute that requires the browser to validate the strength of the password” (alert message “The password you chose is too weak: please pick another”).

I don’t know how well-recieved this would be by users. At the moment, there is a slight attempt to encourage users to understand the importance of strong passwords, but this is second- or third-hand information to most users, at best.

As developers, we have a responsibility to help users understand the importance of passwords. I do it all the time, but I’ve come to think that a simple password field (with no validations) isn’t enough. Something needs to change.