Trying out The Pomodoro Technique

The Pomodoro Technique

In the raging, aeon-spanning battle against procrastination, I am constantly on the lookout (while procrastinating, of course) for ways to improve my productivity and help me work more efficiently. This is how I stumbled on The Pomodoro Technique, and gave it a try.

The rundown

At it’s core, the technique consists of splitting your work in 25 minute intervals, with a 5 minute break between each interval, and a longer break (15-30 minutes) after 3-4 such intervals (pomodoros).

In theory, it should help you stay focused and productive, by timeboxing your tasks into undividable chunks and then help you analyze and measure your productivity in uninterrupted pomodoros.

The trick is, if you somehow get distracted during a pomodoro (either by other people or by yourself), that pomodoro no longer counts. Even if you happen to take “just a peek” at reddit’s homepage in the 23rd minute (although you and me both know there is no such thing as “just a peek” when it comes to reddit.com).

After the first few days with just a few finished pomodoros per day, you will do your best to avoid interruptions.

Will it help me avoid said interruptions?

No, it will not. It will only make the measure in which these interruptions affect you crystal clear, by showing you just how little actual uninterrupted work you do each day. The book does have an entire chapter dedicated to interruptions and how to handle them, and it’s a short read.

Is it worth it?

First of all, it’s not a silver bullet. There are no silver bullets. It all boils down to your own resolve in sticking to a pattern and work in a less chaotic manner. I find it worthwhile and plan to keep using it for now, for the following reasons:

So go ahead, give it a try, but keep in mind, it will be hard at first; it will hurt your feelings, and like with all things that shine a light on existing problems, you will be tempted to give it up pretty soon.

June 29, 2010 | Filed Under Development, Lifehacks | 4 Comments 

Why testing doesn’t really happen until after D-Day

It happened to all of you. You work on a project and keep delivering features at a steady pace. You test your own work, and get constant confirmation from your project managers that each feature has been tested, and you have a green light to move on from the customer.

The release date is closing in, you manage to wrap everything up, and launch. You lean back in your chair and think to yourself “ahh, another job well done”.

Then, out of nowhere, after just a few hours in, your task list / inbox gets filled with things like “How can I do X?”, “We have an issue with Y” and the dreaded “Z isn’t working”. You open the list, scan the first few items, and it hits you:

“Wait a minute, we’ve been over these, this is the way this feature was supposed to work, it’s been tested.”.

Ahh, but you see, it wasn’t.

But how could this happen?

Here’s the thing: your customers don’t really test. Your project managers don’t really test. You don’t really test. Not until the lauch date that is. That’s when everyone really starts testing.

“But, we had at least 6 people involved in this project at all times. Surely between them they tested everything”.

Well, not really, no. You see, every person involved in your project has a certain way of  looking at it.

You have a list of features that needs implemented. While you churn out feature after feature, you only tend to test the specific behavior you built into each one. “Right, so the user clicks this, fills out this form, and ends up here.”.

You don’t really try to break your own application, so you only interact with it in the way it’s meant to work. And of course, it works … “on your machine”.

Your project managers don’t test because they don’t have the time for it, because they have that meeting about that other project with that other client in 10 minutes, just pop them an email and they’ll look it up later … They won’t. They’ll be too busy.
They’ll rephrase parts of your email (because really, you suck at writing to corporate clients), and forward it to the customer. And they will not get a chance to test it again … until after the lauch date, when …

… the customer will start testing. The customer, the person you build the entire project for, doesn’t even remotely start testing until after the project has set sail. Why? Because until then, to them, the project is not real yet. It’s “under construction”.

They will open it up, have a peek, and unless something is downright wrong, they will not notice it. They will not follow the individual interaction flows, they will not start using the project like they will use it for real. “Oh, I can see some products, that probably means the entire administering, checkout and billing processes must be working.”.

Most of the problems that will rise from the customer’s lack of testing are those when he expects a feature to work a certain way, but he described it to your project manager at first in a totally different way. And she described it to you in yet another way. And you developed it “your way”.

Who’s fault is it?

No one’s really. All of yours.

Who should test?

First of all, nothing beats professional testing. Ideally, you should have dedicated testers, but odds are you will have to make do with what you have available.

So there is good news, and bad news:

The good news is that, when searching for bugs, it’s easy! Grab a few members of your team that don’t work on this particular project. Best to do this with all types of colleagues: other developers, account managers, even the office secretary.

Sit down with them, and politely ask them if they can spare any amount of time to test your product. Then assign them some user roles, and let them loose.

The bad news is that application bugs are the easiest to find and fix. The biggest issues come from what I said earlier: miscommunication.

My bet is that shorter release cycles, more customer involvement (the project managers really have to step up here), and enhanced communication can at least lessen the impact of these problems on the typical project. Also, the User Stories and Acceptance Tests agile development concepts fit perfectly.

June 8, 2010 | Filed Under Development, www | 2 Comments 

Redirect all requests (including POST) from one Apache server to another

In order to test POST callbacks made by a payment gateway without having to work via FTP on a publicly-accessible server, I needed a simple solution to redirect all requests from said server to my workstation, that is on the same network as the server, but is not accessible from outside.

The easiest thing to do was to use the mod_rewrite, mod_proxy and mod_proxy_http Apache modules. You can easily activate all of them in Ubuntu with:

1

sudo a2enmod rewrite proxy proxy_http

I created an empty folder on the server and placed a .htaccess file with the following lines in it:

1
2

RewriteEngine On
RewriteRule ^(.*)$ http://10.4.2.155/$1 [NC,P]

The [P] at the end of the RewriteRule specifies that the request should be handled by the proxy module so all GET and POST data are preserved. Therefore, all requests made in that directory will be automatically forwarded to my machine.

April 28, 2010 | Filed Under Development, Linux | Leave a Comment 

Closure: Extend ui.DatePicker to highlight events

I got a change to play with the new Google Closure Library a bit, and since the DatePicker component is pretty nice, i figured i could enhance it a bit to suit a need i had some time ago: overlay data from a database, highlight the dates that correspond to events, and jump to the event’s page when clicking on a highlighted cell.

Example page
Example script

Step 1: provide the JSON events in HTML:

1
2
3
4
5

var events = [
    {date: '2009-11-05', url: 'http://www.example.com'},
    {date: '2009-11-07', url: 'http://www.example.com'},
    {date: '2009-11-10', url: 'http://www.example.com'}
];

Step 2: extend goog.ui.DatePicker:

1
2
3
4
5
6
7
8
9
10

goog.provide('goog.ui.EventsDatePicker');
 
goog.require('goog.ui.DatePicker');
 
goog.ui.EventsDatePicker = function(opt_events, opt_date, opt_dateTimeSymbols) {
    goog.ui.DatePicker.call(this, opt_date, opt_dateTimeSymbols);
 
    this.events = opt_events;
};
goog.inherits(goog.ui.EventsDatePicker, goog.ui.DatePicker);

Notice how inheritance is handled with Closure. Even though we call goog.inherits(), we must also call the superclass constructor for it to work.

Step 3: highlight events:

goog.ui.DatePicker has a setDecorator() method, that accepts a function as it’s parameter. The function should take a Date object and return a CSS class name to decorate the corresponding cell with.

It’s basically called once for every cell in the picker, and we are going to use this by checking whether an event exists for the date and return “goog-date-picker-event” if so:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

goog.ui.EventsDatePicker = function(opt_events, opt_date, opt_dateTimeSymbols) {
    goog.ui.DatePicker.call(this, opt_date, opt_dateTimeSymbols);
 
    this.events = opt_events;
 
    // new line:
    this.setDecorator(this.eventDecorator);
};
goog.inherits(goog.ui.EventsDatePicker, goog.ui.DatePicker);
 
/**
 * Searches the events array and returns the event corresponding to passed date
 */
goog.ui.EventsDatePicker.prototype.findEventByDate = function (date) {
    var dateString = date.toIsoString(true);
    var event      = goog.array.find(this.events, function (event) { return event.date == dateString; });
 
    return event;
};
 
/**
 * Returns a CSS class name to use for cells that have events
 */
goog.ui.EventsDatePicker.prototype.eventDecorator = function (date) {
    var event = this.findEventByDate(date);    
 
    if (event !== null) {
        return 'goog-date-picker-event';
    }
};

Notice the use of goog.array.find() to find the event that matches the date.

Step 4: click events:

We will use the findEventByDate function defined above and DatePicker’s SELECT event to jump to an event’s URL when clicking on it’s date:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

goog.ui.EventsDatePicker = function(opt_events, opt_date, opt_dateTimeSymbols) {
    goog.ui.DatePicker.call(this, opt_date, opt_dateTimeSymbols);
    this.events = opt_events;
    this.setDecorator(this.eventDecorator);
 
    // new line:
    goog.events.listen(this, goog.ui.DatePicker.Events.SELECT, this.dateClicked, false, this);
};
/**
 * Checks if an event cell was clicked, and jumps to the event's URL if true
 */
goog.ui.EventsDatePicker.prototype.dateClicked = function (event) {
    var date  = event.date;
    var event = this.findEventByDate(date);
    if (event !== null && event.url != '') {
        document.location.href = event.url;
    }
};

That’s it :). It’s a short example, but it covers some of the basic aspects of inheritance, event listeners, and some of the utility methods. Closure looks nice :)

Example page
Example script

November 8, 2009 | Filed Under Development, JavaScript | 3 Comments 

Synchronizing tasks between Trac and Netbeans

Cube°n is a NetBeans plugin that integrates and synchronizes the IDEs tasks with some of the most common issue-tracking systems, including Trac.

It has some very nice features, including support for multiple Trac repositories, custom ticket filtering based on Trac queries, and many more.

To install and start using Cube°n you will need to:

wget http://cubeon.googlecode.com/files/TracXMLRPC-1.6.6-py2.6.egg
easy_install TracXMLRPC-1.6.6-py2.6.egg
[components]
tracrpc.* = enabled
httpauth.* = enabled
 
[httpauth]
paths = /login, /login/xmlrpc

That’s it. You can now use the plugin (Window -> Cube°n -> Task Repositories and Task Explorer), and start adding Trac repositories and adding / synchronizing tasks.

July 27, 2009 | Filed Under Development | Leave a Comment