CertPal

It was a normal day. The sun rose, birds were singing and everything seemed to be going fine until Kaboom ! A bug appeared in the live environment. Things turned downhill from there that day. But we are more interested in how things got fixed so lets focus on that.

An investigation of the code revealed that the bug had crept in because of a minor mistake. A variable was referring to the wrong column index on a table. ‘Hmmm… simple fix’ I thought. I told my manager it would not take more than 5 minutes to do. ‘Its a one line fix’. Mistake.

There were loads of other things to do after fixing this bug. This is what I ended up doing over the next 4 hours.

• Analyze if any other code flow would explode.
• Code the fix – This only took 5 minutes as expected.

Ever visit sites like topcoder.com and solve a problem or two ? No ? You should and do so regularly. It will help find tune your programming / design skills. This is because solving the problems requires going though the following thought process

1. Understanding the problem.
2. Thinking up a solution that covers all use cases.
3. Executing your thought process through code.
4. Testing.

Now as simple as that sounds, it is not so easy to get right. Especially when you are competing with thousands of fellow coders for time. And when time is a constrain you usually select the first solution that comes to your head, which might not necessarily be the best. So there is that risk of your code timing out even if it is following the right logic. I would love to delve into a problem right about now and throw in some examples and illustration, but you get the point.

I ran into another sweet little bug that I thought I would share with you. This one cropped up after it passed a few tests. See if you can spot the problem. Without further delay here it is

Problem:

A record needs to be inserted with a new identity number. This number is obtained as the next maximum ID value from a set of elements in a XML file. The following code is supposed to obtain the next ID from the XML. Lets skip the XML related code since that just adds clutter.

Code:

int max = 0;
for( DataType data : someListFromTheXml )
{
    if(max < data.getId())
    {
         max = data.getId()+1;
    }
}
s_logger.info(" Max id: " + max);
return max;

See anything wrong with it ? Its got a pretty big flaw. The logic works only for odd number of elements. When the number of elements is even, it fails. Here’s an illustration

Test cases:

public class Test
{
    public static void main(String... args)
    {
        int [] input1 = new int[]{1};
        int [] input2 = new int[]{1,2};
        int [] input3 = new int[]{1,2,3};
        int [] input4 = new int[]{1,2,3,4};
        Test test = new Test();
        test.go(input1);
        test.go(input2);
        test.go(input3);
        test.go(input4);
        test.go(input5);
    }
 
    public void go(int [] input)
    {
        int max=0;
        for(int id:input)
        {
            if(max < id)
            {
                max = id+1;
            }
        }
        System.out.println(" Max id: " + max);
    }
}

Here’s the output:

I came across another silly little bug today. Take a look at the code below (assume ‘days’ is a parameter and that this snippet is part of a larger function)

Date now = new Date();
long nowMillis = now.getTime();
Timestamp nowTimestamp = new Timestamp(nowMillis);
long future = 3600 * 24 * days * 1000;
Timestamp expiryTimestamp = new Timestamp(nowMillis + future);
System.out.println(nowTimestamp);
System.out.println(expiryTimestamp);

Can you tell what is wrong with it ? What the code intends to do is to set an expiry timestamp to an element – X days from today. A caller called this code snippet with the value 5. Well there is nothing wrong so far. Here is the output

2010-04-27 10:37:10.497
2010-05-02 10:37:10.497

So then came along an element that needed an expiry of around 40 days. The caller calls with the value 40. Guess what the output is

2010-04-27 10:38:43.372
2010-04-17 17:35:56.076

I was testing an application today and came across a bug. A screen had some CRUD operations on a resource. The problem was, whatever I did, the system would perform the operation and tell me that the resource already existed. This left me scratching my head for quite a while. I add a resource and it says it already exists and then adds it. Delete and update also do the same.

So the debugging process started and I sat down with eclipse to get to the root of the problem. I verified that indeed the CRUD operations were reflecting in the persistence store. Then I came across these magical lines of code

public static final String S_SOMETHING_EXISTS = "something.already.exists";
public static final String S_SOMETHING_ADD_SUCCESS = "something.already.exists";
public static final String S_SOMETHING_DELETE_FAIL = "something.already.exists";
public static final String S_SOMETHING_DELETE_SUCCESS = "something.already.exists";

This left me smacking my head. It should have been

public static final String S_SOMETHING_EXISTS = "something.already.exists";
public static final String S_SOMETHING_ADD_SUCCESS = "something.add.success";
public static final String S_SOMETHING_DELETE_FAIL = "something.delete.failed";
public static final String S_SOMETHING_DELETE_SUCCESS = "something.delete.success";