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 draft of his new 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.

The idea here is that the mind works best when single-dispatched, and that changing work habits to accommodate this reality increases effectiveness.

The more philosophical ramification is that instead of worrying about the passage of time (becoming), you simply work and record the activities. As Staffan says in a summary blog post:

Anxiety about not being done before some point of time is eliminated with Pomodoro Technique. One completed Pomodoro is the result. One more X marked next to the activity proves that I’m climbing higher. And the systematic reducing of interruptions gives me the opportunity to plan what used to be event driven actions.

I really think that this speaks to the sustainability of the work. Staffan noted that it reduces procrastination.

Before the pomodoro begins, you look at a list of tasks that you created at the beginning of the day and pick the best one to work on next. If you get distracted by an internal or external distraction, you need to 1) recognize and stop the distraction 2) write down the distraction so that you can reevaluate it at some point 3) get back to the pomodoro as quickly as possible.

Once a pomodoro begins, it must ring. This means that if you start working on something, you should work on it for the whole pomodoro. If you finish five minutes early, take the remaining five minutes and “overlearn” by ensuring you understand the solution completely. In the case of coding, perhaps you look over the comments to ensure that they make sense, or do some quick refactorings to make the code base more readable.

The first time I tried this, the internal distractions were quite numerous (“drink water”, “check bank balance”, etc.) However, once you can separate your desire from actually implementing the thing, your work goes a lot smoother. Really, this works with the Getting Things Done system by dumping things that seem important into another bin before actually dealing with them. However, if you don’t write down this distraction or review it in a timely manner, it keeps coming back. As David Allen would say with GTD, you need to keep the contract with yourself for it to be effective. But once you can file the distraction away, you are ready to get back to work!

Planning your day helps immensely to prioritize what you are working on. This is similar to sections of The 4-Hour Workweek that ask you “if you had a heart attack and could only work two hours today, what would you spend those two hours on and know that you had accomplished something significant?” When things come up during the day (which they invariably do), having a list of things that are important to you helps to put them in perspective. Moreover, by deferring things that are not really critical but merely seem that way, you allow yourself to get in a better rhythm. Ordering tickets to the show or emailing someone real quick might seem really important, but impedes your flow.

The system is simple, meaning that you get the maximum results for minimum overhead. The overhead in this case is winding up the timer and recording what you did. If you already track your time, the overhead is minuscule.

My thoughts

The greatest benefit to me is that instead of thinking in terms of fifteen minute or hour-long periods, I instead focus in terms of what I can do in twenty-five minutes. I think that this is a more natural time period and helps break tasks down a bit better, which helps with estimation. I haven’t gotten to the point where I have been able to estimate the tasks, but Staffan says that this is the next step. This makes sense, as it gives you feedback on how well you are estimating your tasks.

I also like seeing what my progress is like and where exactly I’m spending my time and doing a retrospective each day to see any personal process improvements. In a sense, the system is similar to the Personal Software Process promoted by SEI.

The hardest thing for me so far has been dealing with external distractions (other people. :) ) I shut off auto-alerts on emails. If there’s anything that can’t wait about twenty minutes, then that person should have called me or walked over. But it’s kind of tough when my manager walks over to chat about work. I can’t just say, “hey, come back in 16 minutes and I will have time for you.” So the result is a major interruption, which cannot be filed as a pomodoro (“a pomodoro is indivisible.”) I don’t have a solution other than to either seriously tell the important person to come back later or to just accept that there will be large but important interruptions at times and to optimize the whole by accepting them.

Part of my early success might lie in the fact that I have primarily been working in a non-team environment since I started the experiment. I found that often focusing for a few more minutes than I normally would have gives me additional insights and I solve the problem quicker. Moreover, taking a quick break helps to clear the mind. Often I see something in the first few minutes of the pomodoro that I missed at the end of the previous one. Staffan also suggests trying this for pairing, with similar results.

I think the real takeaway here is getting in the groove and not spreading your attention too thin. I think that this has been a large realization for me in the past year or so.

Mindmapping

Staffan also suggests mindmapping to more intuitively understand your day and to let the creative side of your brain work. Perhaps I will write more about that in the future, but here’s one that I created that I thought was representative and noncontroversial.

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.

Imagine that you had a magic wand that removed delays in your work. In other words, you’d do things the same way, but when you needed someone, they’d immediately be available. Perhaps your specifications or work description would be ready for the next task right when you got done implementing your current feature. What would happen if you didn’t have to wait for feedback from test or customers? In other words, as soon as code was written, you knew whether it worked or not. As soon as code was written and tested, a customer would tell you if it was what they wanted or not.

So the questions to answer are:

• What delays would you remove? If you had to pick one, what would it be?
• What would achieving this do for your productivity?
• What is currently in the way of achieving this?

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.

Of course, this doesn’t work for all applications, but it seems like it’s useful for my case. I just realized that this is a pretty cool subject, something that gives ad-hoc testing more value and more credibility as a testing methodology. This is vague and my understanding limited, so if you want more information, check out the Wikipedia entry for exploratory testing for starters, along with James Bach’s PDF that’s there.

Image recognition

It seems like we could improve on verifying the look in all of the browsers we are tasked with using (IE6 & 7, FF 2 & 3.) It would be best if the site looks essentially the same on all browsers at the supported resolutions. At this time, however, the CSS is not very well decoupled, so what happens is that someone changes the CSS on one page, and somewhere else something is misaligned on one of the browsers or something. It’s time consuming to verify just one page on all browsers, let alone pages that you don’t think might have been modified. This leads to mistakes because we are not getting feedback quickly enough.

To mitigate these mistakes, we might employ a technique mentioned at the September IWST. You create a script that goes through the site for the supported browsers and takes screenshots of them at the supported resolutions for all of the pages on the site. You have a baseline of some sort, which is how things looked when you last got latest from the repo. Then, if you make any style changes, you run the script and look to see if anything changed. If things look good, you check in. If not, you know and fix them. By making the right choice easier, we improve the quality of our product.

Pop Quiz

So, which one of these blogs is not like the others?

Well, it was kind of a silly quiz, you probably already knew that it was going to be IE that was going to be different. :) (RSS icon) Kind of reminds you of those “find the six things that are different between these pictures” things in the Sunday comics?

The point here is that it’s pretty quick and painless to go through the site and see if there are any major differences between what the site used to look like and what it will look like after you check in. It should ideally take less than ten minutes to go through the entire site if you didn’t mess anything up. This is much better than using some fully automated system, because you can disregard changes that are irrelevant (for example, the changes that you presumably made for this check-in.) I would envision the images being considerably larger so that you could see differences, but you get the idea.

It seems like this should be something someone has already solved. Is there an open-source product that you know of that does something like this? I don’t think that a solution where we allow an external service to view the pages is applicable. Perhaps a Selenium solution of some sort, but this seems somewhat expensive to create. One thing that would be very handy would be to be able to see the entire contents of the page (not just one vertical screen’s worth of information.) This combats the problem where the top half of a long page looks correct but the bottom half is messed up.

Passing along some information from Mike Kelly regarding the 2009 schedule for the Indianapolis Workshops on Software Testing (IWST.) It’s pretty short and dense, so I’ll just copy from here:

We’ve posted the 2009 schedule for the Indianapolis Workshops on Software Testing. We’re looking for people willing to share experience reports and people who just have a general interest in the various topics and would like to attend and ask questions.

Here’s a summary of the lineup:

• February 26, 2009: Presenting test results

• March 27, 2009: Test-driven development

• June 27, 2009: Test design and development

• August 28, 2009: Testing mobile devices

• September 26, 2009: Automation and performance logging

• October 29, 2009: Time management for testers

• November 21, 2009: Managing your focus while doing exploratory testing

If you’re interested in attending any of the workshops, please drop me a line at mike@michaeldkelly.com.

I sent him an email saying that I would be interested in the March and October sessions. Perhaps you have some interest in the same/other sessions?