Anthony Panozzo's Blog

When I was growing up, my relatives always seemed to ask me the same questions. "How is school going?", "Do you have any girlfriends?" and, of course, the time-honored classic: "What do you want to be when you grow up?"

While the second question usually flustered me, it was the third question that seemed to evoke the most interest from my relatives. They would say ominous things like, "If you want to be happy in life and make a lot of money, you had better figure out what you want to do." I usually said something like be a doctor or lawyer, and they seemed mollified and the conversation changed to adult topics.

Seeking a way to extend completion in zsh for Capistrano tasks for a Rails project, I found a script that apparently works for OS X. However, it didn't seem to work out of the box for Ubuntu, so I made a few modifications. Put this in a file and source in your .zshrc file, and you should be set!

_cap_does_task_list_need_generating () {
  if [ ! -f .cap_tasks ]; then return 0;
  else
    accurate=$(stat -c "%y" .cap_tasks)
    changed=$(stat -c "%y" config/deploy.rb)
    return $(expr $accurate '>=' $changed)
  fi
}
 
_cap () {
  if [ -f config/deploy.rb ]; then
    if _cap_does_task_list_need_generating; then
      cap -T | cut -d " " -f 2 | sed -e '/^ *$/D' -e '1,2D' >! .cap_tasks
    fi
    compadd `cat .cap_tasks`
  fi
}
 
compdef _cap capompdef _cap cap

The first time that you attempt completion with cap, the available tasks will be analyzed and cached. Then, future completions will work correctly and quickly. If you have any problems, deleting the .cap_tasks file will signal that the generating process needs to happen again.

If you've walked by my area in the couple months or so, you may have noticed that I sometimes have a massive stopwatch displayed on my computer. I was consuming some content produced for the Agile 2008 conference, and came across a very interesting article about the Pomodoro Technique, a way to think about time and work differently. Staffan Nöteberg has a book about the system, and can probably explain it more coherently than my attempt in this post.

What is it?

The Pomodoro Technique is a system that Francesco Cirillo created and used when he was a student to help him focus. Staffan then used this technique successfully in software development, and believes that it can be applied to most things that people do. Pomodoro comes from the Italian word for tomato, which was the form of his original timer.

For the system, you just need a pen, paper, and a kitchen timer. I'm using this online stopwatch and using simple text documents to replace the pen and paper. The online stopwatch is nice because it has an alarm that rings through my headphones so I don't bother anyone.

How do I use it?

So anyway, a pomodoro is a set period of 20 to 35 minutes in which you focus intently on the task at hand. After each pomodoro, you take a 3-5 minute break to stretch, relax, or just kind of space out. Nothing mentally challenging should be done. When you do four pomodoros back to back, it's called a set. After each set, you should take a longer break (15-30 minutes.) This is an ideal time for lunch, running errands, making non-work related phone calls, etc.

OK, here's the plan. Anyone who wants to answer the following question with a comment is eligible for the prize. The winner will be chosen at random from valid, thoughtful answers starting on Tuesday evening. The prize will be your choice of:

• The Mythical Man-Month by Fred Brooks
• More Joel on Software by Joel Spolsky
• Peopleware by Tom DeMarco
• Rapid Development: Taming Wild Software Schedules by Steve McConnell
• Leaving one (and only one :) ) celebratory bragging comment saying that indeed, you are simultaneously a talented and lucky person

If you don't want to leave your full name, just make sure that I can get back to or identify you via the email you put down (which is not shown on the page.) I think this will be an interesting exercise to see where potential delays are and to start a dialog on where we can try to remove delays in our processes. The description talks about code, but your answers don't have to be limited to it.

I've recently been doing some ad-hoc testing at work, and it seems like my process could be improved somewhat. I'm tasked with testing a web application that I'm not exceedingly familiar with. At first, I am just going through the application with IE6 and trying out various functions or details and making sure that things look and behave appropriately with strange inputs. When I see something anomalous or a particular page that looks complicated or strangely laid out, I dig a little deeper and try to see what I can break. I figure that it's these sections that are the most likely to contain bugs. Taking screenshots of likely bugs has been helpful in entering them accurately into our bug tracking system and will hopefully avoid ambiguity in what I'm seeing for whoever tries to fix the bug, which will then require less communication overhead for me.

I heard Mike Kelly talk a bit about exploratory testing, and it seems like what I have recently been trying is similar to this technique. Essentially, exploratory testing is ad-hoc testing's bigger, more refined brother. Instead of just willy-nilly testing things, you have a designated goal and you create a plan that you try to stick to. When you see something interesting or have a clever thought on how to test that things are well done, you can venture off of the path for a bit and explore that idea. In this way, you can use your intuition as well as having a way to document and hold yourself accountable for the testing that you are doing.