Author Archives: Richard

Thoughtbot Clearance & mongomapper

Written by Richard. Posted on January 18, 2010. Filed under rails. 1 Comment.

Having a play with mongomapper and wanted to get Clearance working with it. Seemed to just be a simple case of doing the following in my user model.

  def self.attr_accessible(*args)end
  include Clearance::User

My full user model ended up looking like this:

  class User

    include MongoMapper::Document

    def self.attr_accessible(*args)end
    include Clearance::User

    key :email, String
    key :encrypted_password, String
    key :salt, String
    key :confirmation_token, String
    key :remember_token, String
    key :firstname, String
    key :email_confirmed, Boolean
    key :lastname, String

    timestamps!

  end

Perhaps if I have time, I will look into adding attr_accessible support to mongomapper myself.

Getting out of bed hack: Eat an apple

Written by Richard. Posted on January 15, 2010. Filed under food, health. 2 Comments.

I just can’t get out of bed in the morning. I hate it. I’ve tried having two alarms, tried putting my alarm on the other side of the room (I just end up getting back into bed) and setting my alarm an hour early and constantly hitting the snooze button until the last moment, but nothing has ever worked. Recently though I’ve found a simple way of getting myself into a state where jumping out of bed is easy: I eat an apple while in bed.

I had been feeling a bit sluggish in my morning workouts so wanted to increase my pre-workout carbs, but as I live close to the gym I wanted to ingest them as early as possible so as to not upset my stomach too much while exercising. I decided that an apple first thing suited the bill perfectly in terms of carbs and placed one on my alarm clock that evening so that I could just pick it up at the same time as turning off the alarm. Eating one in the darkness and while lying down was strange at first, but I found that afterwards getting out of bed was incredibly easy. And it’s been that way ever since. I’ve been doing this now for a few weeks and it has made such a difference compared to days where I don’t have to get up particularly early.

I think I may have found a new habit for life.

Broken Window Policy of Programming

Written by Richard. Posted on January 14, 2010. Filed under programming. Tagged , . No comments.

There comes a point in every software projects life where everything just feels wrong. No one wants to touch the code as it stinks and everyone working on the project just feels demotivated and would rather just go home then have to do anything more on it. On projects like this, when it comes to adding new features or bits of code, because everything else is such a mess, the changes are just hacked in rather than being properly thought out and coded up well.

We’ve all been there and the frustrating thing is that our opinion of the project, from good to bad, seems to happens over night. If you sit down and think back, you can probably pick out all the things that were just shoved in that eventually led to the project becoming a mess, but at the time we never chose to do anything about. It’s almost always a case of deferring better solutions or a round of refactoring to some point in the future. “I’ll knock this up now and come back to it later.”. The problem is that later never comes. This is the essence of technical debt. You may only go into debt by a fraction, but do it a few times and eventually all those fractions add up. Until one day when you go to check your balance, you find yourself swimming in the middle of the ocean with no land in sight.

Implementing a broken window policy can go a huge way towards keeping a project healthy. If there is a broken window (bad code) fix it as-soon-as-possible. It doesn’t have to be that instant (although if you can, you should), but fix it. Part of the policy also means trying not to break windows yourself. Write the best code you can, as often as you can. Set the benchmark of quality for the rest of the team, even if they don’t follow suit. The danger is that many people are very “me too” about things. “Well if such-and-such can do it like this, then so can I *hack* *hack* *hack*”.

Of course we all write crap from time to time. TBH most of the stuff I write is crap. But I honestly feel more motivated to work on code that’s been loved and looked after, rather than something that’s hanging together by a thread.

Beggars can’t be choosers

Written by Richard. Posted on January 8, 2010. Filed under life. Tagged , . No comments.

Whenever I hear the quote “Beggars can’t be choosers”, I take it to mean that those of us in a poor position can’t always choose what we want. This is probably what the quote literally means and what is meant when someone says it. I know that when I’ve said it, this is the meaning I want to convey. We can’t all be masters of our own destiny.

But what if the true meaning is that if we choose the role of beggar, then we can never assume the role of chooser. That the choice to become a chooser is for us to make. Being the beggar is not a position we’ve been put in, but a position we’ve either consciously or unconsciously chosen to take. We all take many of our day to day situations as being out of our control, but really how many of them really are? We all have the ability to choose, we just may not all have the capacity to do it.

I choose to be a chooser, not a beggar!

Prioritizing Web Usability Notes

Written by Richard. Posted on December 4, 2009. Filed under books. Tagged , . 2 Comments.

Here are my most important extracts from Jakob Nielsen’s “Prioritizing Web Usability”. I have all my notes typed up. Just drop me a line if you want them all.

Users spend 25-35s on a homepage. Even with an avarage reading speed of 200-300 WPM, this only leaves enough time for about twenty words to be read.

Five biggest causes of user failure:
1. Searching
2. Information Architecture
3. Content
4. Production Information
5. Workflow.

Page design is more of an annoyance then a direct cause of failure for sites.

Don’t defend your interface, fix it!

Before adding design elements, ask yourself:
1. Does this element simplify the user’s task?
2. Does this element add value to the user?

Design for your users. Not for what you or your manager likes. The key to creating a good experience for your user is creating something with them in mind.