lixo.org

Thanks to Demetrius Nunes, Obie and I are the new maintainers of the great acts_as_taggable Ruby on Rails plugin.

This is just a quick post to give you all a few pointers, as I haven’t any new code to show for now. For instance, you might be interested in knowing what it’s all about (more here or here or here or here…), reading some documentation (more coming, promise!) or having a look at the source code in the CVS repository I set up yesterday - and thus might still be a bit flaky, so let me know if anything goes wrong.

I plan on opening an announce-only mailing list, but I don’t know if anyone would actually care for that (and just let Ruby Gems do its magic whenever they need to use it). As always, suggestions, ideas, improvements, bug reports, fixes, patches and millions of dollars in non-sequential $100 notes are all welcome!

Sam Newman is surprised to know that Flickr doesn’t use many automated tests because, “being such a high profile and successful application I assumed there would be a more mature approach towards automated testing.”

Actually, that surprises me a bit too, but I think I know why they don’t really care that much about testing, and my take is that they’re not just a bunch of the regular outdated dot-com era cowboys throwing code at a wall to see what sticks, the ones who often get criticized for not testing their stuff and told to do better by the usual agilist (rhymes with pugilist?) at conferences and papers. There might be some reasons to not bother testing, and I’ll try to explain them here, even knowing this post is going to be a bit inflammatory. First, let me propose two different scenarios, with the numbers representing some imaginary unit of cost during a given period, after which a new project phase starts:

Assuming ceteris paribus, and also that the code was well-written by competent developers, which the Flickr folks surely are, a table like that sounds plausible: where A uses automated testing to find regressions and bugs, saving on the maintenance, B spends solely on maintenance, both with the same results (on that phase, at least).

In A, the company has to spend money upfront in order to get the testing suite up and running so they don’t have to spend with future maintenance. Now break out the pitchforks and torches and quote me to death, but this is a bad economic decision, unless the cost of writing the automated tests is lower than doing all the maintenance work, where the cost would be spread. The risk of this cost not being lower though, seems, at least in my experience, much higher than what most companies are willing to accept, hence the good results of this approach we hear about it from most, if not all, agilists.

Now quote this bit too: I am a fan of automated testing because I’ve seen how maintaining software sucks out every last drop of happiness I happen to have on my poor soul after a few months doing it. I’d much prefer writing fresh code, even if that code isn’t used in the final production environment, like test code, instead of going through another frustrating day hunched over a debugger. I am sure Sam and most of you reading this are also on the same boat.

B is, in my theory, what Flickr is doing: less upfront and more maintenance costs over time. As a startup (well, before they were acquired by Yahoo, anyway), this makes sense: the whole point of a startup is that you can do riskier things, and they guessed at some point that automatically testing anything but the most significant bits (smoke tests?) wasn’t as important as getting code out the door, fast, and obssessively listening and reacting to user feedback. This probably required keeping insane levels of attention to detail and commitment, which is quite rare I might add, but a great part of what I attribute to their success.

As Joel Spolsky put it, almost three years ago, over a similar situation:

You need some kind of economic model to decide where to spend your limited resources. You can’t make sensible decisions reliably by saying things like “load testing is a no-brainer” or “the server will probably survive.” Those are emotional brain droppings, not analysis. And in the long run we scientists will win.

So, I’m not sure who’s right, here: I know most of the projects I’ve participated in would have been (and some actually were) completely fucked without automated tests and heavy test-coverage-keeping work. But then, I’ve never worked for any startup quite like Flickr.

I’ll be the first to admit I have a serious procrastination problem, but I’ll refrain from examplifying much, here: let the tall pile of dirty dishes by the kitchen sink that’s been hanging around for as much as a week be enough proof of that.

So, I heard about Getting Things Done, and it sounded like a good idea, but sound doesn’t really propagate in the comfortable vacuum of slacking off the whole weekend on the couch, feet up, reading a book. I needed something to enforce it, something that would beat me up if I didn’t do what I had to do. I tried all sorts of calendars, to-do lists, a big whiteboard next to the fridge, and nothing really worked.

Last night I came across a brilliant solution by Merlin Mann. You should have a look at the link if you want to understand the details, but it basically boils down to this:

require 'active_support'

def kill_procrastination(count=5, work=10, rest=2)
  count.times do
    puts 'get moving!'
    sleep work.minutes

    puts 'take a break'
    sleep rest.minutes
  end
end

kill_procrastination()

That’s it, really. But puts doesn’t quite work, as it’s easy to miss a line being printed on the console. I could add a ‘\a’ (beep), but it gets annoying too quickly. Also, it doesn’t really enforce anything.

What if we had two users logged on the machine, one for actual work and another for your web-browsing, instant-messaging, mail-reading, kittie-porn-dwelling lazy ass, and used this script to automatically switch between them?

The Fast User Switching feature of MacOS X can be controlled via shell commands, so it’s a perfect fit. Here’s the script I’m using:

require 'active_support'

def kill_procrastination(
       # tweak these values to your attention span and environment
         work_user='work'
         rest_user='rest'
         count=5,
         work=10,
         rest=2)

  # should be in a single line
  cmd = '/System/Library/CoreServices/Menu\ Extras/User.menu/Contents/Resources/CGSession -switchToUserID '

  count.times do
    `#{cmd} #{work_user}`
    sleep work.minutes

    `#{cmd} #{rest_user}`
    sleep slack.minutes
  end
end

kill_procrastination()

I made Adium change my status to away everytime I switch away from the user, so neither my work nor personal IM accounts interfere with what I’m doing. I still haven’t decided what to do about iTunes, though. Any suggestions welcome!

Yesterday I went to Gilberto Gil’s talk on what the Brazilian Ministry of Culture has been doing about digital and cultural inclusion lately, and I was quite impressed - even despite being somewhat familiar about it from the last few months’ mentions on BoingBoing and a few other blogs. Plus, the talk took place in one of my favourite venues in London, Guanabara - where a table football championship took place (I lost on the first round), and the caipirinhas are quite decent.

Mainly, his project is about creating digital culture hotspots all over the country using whatever resources are available - recycled or donated computers, mobile phones and multimedia equipment, giving them a broadband connection (DSL or satellite) and getting those groups talking to eachother using open wikis and bulletin boards, offering some technical support and encouragement on the first few weeks or months, and then sitting back and watching what happens.

One of the fascinating things is that the hotspots quickly become self-sustainable: after a few workshops on computer recycling and some help setting them up on the net, users of those hotspots start adding more machines as they become available and more people join it. Of course, there’s a central server somewhere with good infrastructure and bandwidth supporting the forums, wikis and picture galleries, but all the rest is mostly just a huge scrapheap-built mesh, managed by people who had never even seen a computer, and much less thought they were allowed to do so or would manage to learn how to use them.

Those groups are becoming more and more organic, and they’re growing in fascinating and unforeseen ways. Examples are many, and some of the most amusing ones include people in distant regions of Brazil finally being able to immortalise local rhythms as digital recordings - Creative Commons licensed, freely distributable, widely accessible recordings, no less. Some of those were remixed and blended with other rhythms from other places and are playing on the radio, although most don’t really find out about where the samples used actually came from. This certainly encourages more and more artists to produce music, so my opinion is that there’s a boom just waiting to happen here - or maybe it is happening already and we just haven’t noticed.

Actually, Gilberto Gil himself pioneered the whole thing and offered a few of his songs on a CC-based license. But this is not just limited to music: many contributions to the Portuguese version of Wikipedia come from people hanging around those cultural hotspots. There are also video producers, self-taught electronic engineers, poets, writers and all that sort of stuff. Quite fascinating, really, and most importantly, an irreversible process: these early adopters are hackers, probably ones that will never be interested in coding or low-level computer stuff, but people who find ways of doing new amazing things or to share the amazing things they already do with a much wider audience.

Oh, and speaking of hackers, have I mentioned this is all built exclusively on top of free software?

Stuff worth keeping an eye on, surely. If you want to know what hotspots are like, have a look at the picture galleries - even though the descriptions are in Portuguese, I think the images speak for themselves.


Update: see also Patrick Kua and The Guardian for more.