Random Thoughts on Software

Microsoft and Sendmail must have read my February 11th blog entry.

They are coming up with a solution to stop spam which essentially uses authentication. This sounds promising.

Here is a simple (homegrown) Timer class that I use to capture execution time in Java:

import java.io.PrintStream;

final class Timer
{
	private long	startTime;
	private long	endTime;

	public Timer()
	{
		reset();
	}

	public void start()
	{
		System.gc();
		startTime =
			System.currentTimeMillis();
	}

	public void end()
	{
		System.gc();
		endTime =
			System.currentTimeMillis();
	}

	public long duration()
	{
		return (endTime - startTime);
	}

	public void printDuration( PrintStream out )
	{
		long elapsedTimeInSecond =
			duration() / 1000;
		long remainderInMillis =
			duration() % 1000;

		out.println(”nTotal execution time:”
			+ elapsedTimeInSecond
			+ “.”
			+ remainderInMillis
			+ ” seconds”);
	}

	public void reset()
	{
		startTime = 0;
		endTime = 0;
	}

	public static void main( String[] args )
	{
		Timer timer = new Timer();
		timer.start();

		for (int i = 0; i < 500; i++)
		{
			System.out.print(”#”);
		}

		timer.end();
		timer.printDuration(System.out);
	}
}

I’ve recently been experimenting with XDoclet and I have to say that it really seems to simplify things. But when you think about it, it seems like somewhat of a round trip.

Developers have gone to great lengths to externalize properties and deployment-related information out of source code and into XML files. They have gone so far as to require you to define all of this information externally. For example, Struts uses the struts-config.xml file to define the interaction between pages in a Web application. So far as I know, you cannot define the action responses directly in your code.

So, XDoclet is now providing us with a way to pull all of the externalized definitions back into the source code. Why not just provide an underlying framework or interface to define these things directly in the code? Why do we have to resort to JavaDoc to define system behavior?

This article outlines a new strategy for combating spam. P. Oscar Boykin and Vwani Roychowdhury of the University of California, Los Angeles came up with the idea of turning to social networks (life Friendster) to determine if the source of the e-mail that you are receiving is “friendly” (pun intended).

Yahoo is probably in a very good position to implement something like this. If you receive an e-mail from an address that is in your addressbook, then it will end up in your inbox. Let’s say that your have 100 people in your address book and 10 of those people are also yahoo users with 100 people in each of their address books. If I could tell Yahoo that I wanted to whitelist going 1-level deep, I would have a whitelist of 1000 people. If Yahoo allowed you to whitelist people going N-levels deep, your whitelist could be even more powerful.

I wonder how this would work with legitimate “non-social” e-mail such as coupon mailouts from Office Depot. What would be the model for a non-spamming company (or any entity for that matter) to participate in this system? I guess that somebody in the company would register as a user of the social network, and then people would associate with it. For example, on Friendster, I have my high-school listed as a friend.

My wife and I use our cell phones as alarm clocks. We have two phones on which we set alarms that are 5 minutes apart, to act as a sort of snooze. (I don’t know why we haven’t just invested in a real alarm clock, but that’s besides the point).

These phones usually reside on a window sill away from the bed so that we have to actually get up out of bed to turn them off (otherwise we’d just stay asleep). The window sill used to be nearer to my wife’s side of the bed, but she recently redecorated, making the sill closer to my side (completely unintentional I’m sure). After about 2-3 days of waking up and turning the first alarm off and stumbling back to the bed half asleep, I commented to my wife (who was also half asleep), “There used to be a time when you would get up and turn off the alarms. That used to be your role.” To which my wife promptly replied, “We don’t have roles in this family, just instances of responsibility.”

That was the most inspiring maxim I’d ever heard from a half-awake woman at 6:30 in the morning. I thought it was a fitting phrase to describe collaborative code ownership: “We don’t own code in this team, we just have instances of responsibility”.

The use of checked exceptions is a frequently debated topic. Java uses checked exceptions and many Java developers promote them. But Java is the oddball when it comes to this topic. Practically no other OO language uses checked exceptions, and many developers think that checked exceptions are trouble.

I personally think that checked exceptions are annoying. I don’t think that its worth introducing an exception as an explicit part of an API. Many developers will simply do the following:

try
{
   someOperation(…);
}
catch(Exception e)
{
}

or

try
{
   someOperation(…);
}
catch(Exception e)
{
   e.printStackTrace();
}

I typically do the following:

try
{
   someOperation(…);
}
catch(Exception e)
{
   throw new MyCustomException(e);
}

.
.

public class MyCustomException
   extends RuntimeException
{
   MyCustomException(Throwable t)
   {
      super(t);
   }
}

Then at the top-level of my code, I have a single try-catch block that actually handles all of my exceptions. This makes it easy to know what to do in the face of a checked exception: you always rethrow it.

The very core of the problem with checked exceptions is that people frequently don’t do anything with them besides print them to the console.

I have come to the practice of rethrowing almost all of my Java exceptions as RuntimeExceptions or a subclass of RuntimeExceptions. I propogate all my errors up to a top-level handler that knows how to provide the right type of error screen or code to the client.

If I need to catch an exception and handle it on a lower level, I am free to do that. For example, if I am reading data from an external hardware device and it times out, I may want to handle that exception by retrying 3-4 more times, then rethrow the exception if I’m still unsuccessful. But situations like this are rare, and checked exceptions introduce an intrusive infrastructure into your code to encourage you to handle a rare occurrence. From my perspective, this is unwarranted.

By always rethrowing checked exceptions as unchecked exceptions (or runtime exceptions) in my APIs, my method signatures don’t get clogged with exceptions, and any client code that calls my code is free of having to wrap every other method call with a try/catch block. This strategy allows you to only have to think about and handle exceptions in one place for the majority of cases, but still allows you to handle exceptions at a lower level when you need to.

I enforce the contract for exceptions in my unit tests rather than in my method signatures. I actually use either a unique subclass of RuntimeException, or a subclass of RuntimeException that contains a unique error code passed into the constructor. I do this so that I can make sure that I don’t get false positives in unit tests that test for exceptions. It’s never good when you catch an exception that was thrown from a different line of code in the method that you are testing.

Here are some other references:

Checked Exceptions Are Of Dubious Value

Does Java need Checked Exceptions?

I am currently feeling the pain of a geographically divided project. I am working on a relatively small integration project for a client, but most of the people who are providing me with the software, data, network access, etc. that I need are located clear across the country. Literally 90% of my time has been spent waiting, and unfortunately, my client (which is a rather large corporation) is wasting thounds and thousands of dollars because of it.

I have no doubt in my mind that if most of the major players for this project were loated at the same site and had enough face-to-face time, that the project would be done in 1/4 the time. Voicemails and e-mails do not elicit the level of accountability and expediency necessary to meet deadlines on software projects. At least not that I’ve ever heard of or witnessed.

Wild ID is pretty cool. It allows you to obtain a Digital ID for free, with Wild ID acting as the certificate authority.

Now, here is my theory on how to put an end to spam. Everybody signs up for a free digital ID with one of several trusted certificate authorities. These certificates would cost exactly 1 cent each, thus forcing you to provide accurate credit card information with a name and address. Mail servers are set up to only accept e-mails that are digitally signed. That’s it.

If somebody starts spamming you, you can pull up their information from their certificate and turn them over to the spam cops.

What about people that don’t have credit cards, such as people in third world countries? Don’t they deserve to sign up for these certificates too? I didn’t say my plan was perfect.

I’ve been pretty annoyed that recent versions of Internet Explorer don’t show the status bar at the bottom by default. When I turn it on, and exit IE, it ends up losing my settings. This page shows you how to get the status bar to stay up permanently.

To avoid having your e-mail address become a victim of Web-based e-mail-harvesting software, you can use Javascript code that dynamically generates your e-mail address when a page is displayed. Here is the one that I used to provide my e-mail address for this page. There are others out there too.