lixo.org

Git commits: 1688
Xbox 360s bought: 1
Projects created or started: 14
Guitar Hero levels completed with 5 stars: 98 (on medium)
Burglaries: 2
Full-time projects: 3
kiva.org loans made: 7
Languages learned: 2 (Erlang, LOLcode)
Presentations given: 3
Family Guy episodes watched: 116
Presentations attended: 12
Interviews given: 2 (akitaonrails.com and MTV)
Tweets: 979
Flats: 1 bought, 1 lived in
Arduinos: 4 bought, 2 destroyed
Non-fatal incidents with a soldering iron: 3
Flight time: 28.5 hours
Countries visited: 4 (Brazil, France, Ireland, UK)
Google Reader items read: 127524
Pints of London Pride per week, average: 4.33
Books: 18 bought, 7 read
Photos taken: 29355
Semi-naked photo shoots published: 1
Copies of said publication sold: 500k+
Blog posts written: 16
Burritos eaten: 47
Attempts at purchasing an iPhone: 9 (0 of which successful)
Emails written: 1045 (2.8 per day in average)
Times I heard George say “shiiiiiiit” per day, average: 2.19

Jakob Nielsen on the use of Agile methods:

Agile’s biggest threat to system quality stems from the fact that it’s a method proposed by programmers and mainly addresses the implementation side of system development. As a result, it often overlooks interaction design and usability, which are left to happen as a side effect of the coding.

In my experience, mostly as a developer, it is really easy to dismiss interaction and usability design for two reasons.

The first comes from the developers themselves, trading prettiness and consistency of user experience for cleaner and sounder domain models whenever they go in opposite directions. Signs this is happening are developers crying YAGNI when the stakeholders ask for a zoomable chart or DTSTTCPW when a sortable, paginated data table is required.

Next time you see a system where there are enormous listings of items with no search, pagination or sorting, ask the developers if they have ever watched a typical user at work; chances are they have only thought about the system as they see it: since the testing dataset is usually small, a loop spitting out a bit of HTML for each element isn’t such a big deal. They might even say there’s a story to implement all that lovely stuff later on, but they just get moved over and over to the bottom of the backlog barrel… until everyone watches a person struggle to find needles in a tabular haystack all day. This is a simple example – almost too trivial actually, but one I’ve seen happen way too many times.

Changing the perception that usability is just the icing on the cake draws attention to all that wasted time to the stakeholders, and should enable a much better dialogue: developers get to write an application users will love, stakeholders spend their money wisely on something that will actually increase return on investment (as productivity gains), users feel empowered and less likely to make mistakes. Everybody wins.

The second reason UI design and usability get overlooked, and this is the one Frank alludes to in his latest post, is that some agile teams rely a bit too heavily on the stakeholder’s descriptions of what is wanted. It instantly reminded me of one my favourite quotes from Cars:

Lightning McQueen: All right, Luigi, give me the best set of black walls you’ve got.

Luigi: No, no, no! You don’t know what you want! Luigi know what you want. Black-wall tires, they blend into the pavement, but these white-wall tires, they say look at me, here I am, love me.

Lightning McQueen: All right, you’re the expert.

I find it rare for the stakeholders to know exactly what they want, down to what the end-user experience should be like. Thinking about a reasonably-sized application at this level of detail can only be done as a series of small, incremental steps and having someone on the team who is really obsessed about making every single pixel on the screen be in the right place. And if you read the last sentence and thought “well, that’s not exactly the role of my stakeholder!” you get the point: the stakeholders should not have the final word as to what the usability and experience details should be, in the same way they simply delegate to and rely on the expertise of the development team to flesh out the details of a persistence layer.

Have look and feel expertise in your team, and trust it, in the same way you would trust the database or network connectivity expertise.

Lots of Words is a new experiment to mash up a Wikipedia based lexicon with images from Flickr and whatever else I can get my hands on, in the context of building a representative and informative source of translations for any particular word, in any particular language. I’m trying to keep things as machine-readable as possible for now, so others can build on it, too.

My friend Patrick Hall and I have been musing about it for some time, and only now a technology stack allowed me to do this as a relatively small hack rather than putting together months of optimization work.

It turns out, indexing something as big as Wikipedia (check out those dump file sizes!) isn’t really an “idea in the head and 500 lines of code”, unless you use the right tools for the job. In this case, a shiny new CouchDB instance at Amazon EC2, a bit of Ruby and Merb to add a some logic and presentation magic, and JQuery as a finishing touch did the trick. This gets pretty much every Web N.0 buzzword covered, although I haven’t yet made any millions in an iPhone app.

This is a spare-time project, so it made sense for me to try out as many different bits of new technology as possible and make it into a breakable toy. This is its third implementation, and the first I’m really happy with in terms of performance and malleability. CouchDB, even with 21+ million documents loaded in about 120 GB of storage, still responds in under 200ms times on all queries I’ve tried so far. It truly is, even in its pre-1.0 days, a fantastic piece of software.

Now I find myself wanting to put a nice front-end to this, and while the current Flickr mash-up is already very interesting—and, it turns out, solves the problem of cross-language information retrieval for a small subset of Flickr, I’m sure others will have much more useful ideas about what to do with this data. My colleague Robert Rees has helped put together a hackfest here in the ThoughtWorks UK office, together with the nice folks from the London JavaScript Meetup group. Come join us 12 November!

If you just want to get to the code (be forewarned it is ugly!), it’s on GitHub.

It’s been nearly 60 years since the Universal Declaration of Human Rights has been ratified, and Seth Brau has created a amazing typographical interpretation of its text:

While you’re watching it, please take a moment to reflect about the ways in which your human rights have been challenged over the powers-that-be over your lifetime, and think of ways in which you can stop these challenges and abuses from happening.

On the geeky side, it’s also interesting to note that the UDHR is the most translated text in the world. I’d expect no less, and it’s interesting to note how technically challenging that is — apart from getting translators the world over to get the wording just right so it doesn’t become ripe for abuse and misinterpretation, it is also one of the benchmarks for proper character set handling in any particular computer system — and if you think whatever you’re building is up to scratch, you must give the translations a go. Chances are you’ll end up with mojibake all over the place at some point.

Applying the agent nouns are code smells rationale, nicely worded by my colleague Peter Gillard-Moss, controllers are code smells. The more I look at REST and the more I look at how MVC gets typically mapped to it, the more I think the C in MVC is doing the wrong thing, even when it’s skinny as possible.

I’ve only come across very few and extremely limited cases where I need to do more in a Rails or Merb controller than simply delegate to the model and set some options about how the resource is going to be represented. Most of this code can be inferred by simply looking at the available routes and methods on the model, essentially making them declarative statements rather than fully capable objects that encapsulate some behaviour of my system, or coordinate inputs and outputs.

In fact, in a RESTful application where simple and CRUD-like behaviour is encouraged in (or even expected from) all resources of the domain, controllers are just plain unnecessary. If you’ve tried something like CrudTemplate, resources_controller or resource_controller, that’s the sort of thing I’m talking about… only without the the controller as a class.

Sinatra gets this right by doing away with the controllers and allowing you to tie blocks of code to URL matchers. Still, opportunity makes the thief, and allowing a block of code to decide what’s going to be rendered or what models get called is still going to put developers in a position where they have to fight to keep their control code skinny, while moving as much functionality as possible into a rich domain model. It’s fighting an incredibly difficult battle, since the refactoring weapons are just not powerful enough at the moment, and might never be. I’d prefer declarative statements: what, not how.

Because declarative, ladies and gentlemen, is good.