My real name

The latest 5.0.0 update of Skype is atrocious.

The app’s main interface is no longer a slim bar of contacts (that’s what iChat and Yahoo have always done), instead it occupies the same amount of screen real estate as iTunes, looks like iTunes and simply sucks.

I’ve never been a big fan of Skype’s user interface and have found the buttons, pop-ups and user-software interactions confusing. But the latest update makes the app impossible to use. I no longer am willing to keep it open, from now on its default mode is going to be Hidden.

And now we seem to have a new service called Skype Access added and enabled by default. What were they thinking!

Another foreign movie with subtitles that I’ve seen recently. Although the two movies don’t have much in common, this one made me think of “Slumdog Millionaire”.

Recommend.

I doubt that I’ve recently seen another movie as weird and disturbing as the “Oldboy”.

This South Korean film came with no voice dubbing, just the subtitles. Awkward at first this made for a much more intense viewing, since the actors’ performance is outstanding and a lot is conveyed in the intonation and speech.

The movie constantly keeps you guessing, wondering what’s going on and sympathizing with the main character. The story is carefully crafted and told at a fast but logical pace.

Although this movie is South Korean, its origins come from Japan and one can certainly feel that.

Highly recommend this movie, but beware - it is not for the faint of heart. The subject matter is disturbing, I doubt this would make for a nice weekend movie watching experience.

Current Mac OS X Snow Leopard comes with Maven 2.2.1 installed. Let’s go ahead and update it to the latest version 3.0.2.

First, download it from Apache Maven site.

Unzip the downloaded file into the desired folder. You can put it in /usr/local. However in my case I prefer /app folder.

Create a simple alias:

air:app dmitry$ ln -s apache-maven-3.0.2/ maven
air:app dmitry$ ls
apache-maven-3.0.2	eclipse			maven

We are almost done. Update your .profile to setup PATH

export M2_HOME=/apps/maven
export M2=$M2_HOME/bin
export PATH=$M2:$PATH

Source your .profile file and we are done. Let’s make sure of that:

air:~ dmitry$ mvn -version
Apache Maven 3.0.2 (r1056850; 2011-01-08 19:58:10-0500)
Java version: 1.6.0_22, vendor: Apple Inc.
Java home: /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home
Default locale: en_US, platform encoding: MacRoman
OS name: "mac os x", version: "10.6.6", arch: "x86_64", family: "mac"

Anytime one needs to load Java resources (XML, jpeg, PDF, etc) from the classpath, using Class.getResourceAsStream or ClassLoader.getResourceAsStream is the way to go. However, there seems to be some confusion on how each one of these methods deals with the path in URL. I hope that this detailed experiment will serve as a helpful reminder of what the requirements are for both methods.

To make things more interesting I’ve put together a little program that should demonstrate the results on practice. I’ve covered three scenarios for where the file may reside in a typical Java application.

Assume that directory structure looks like this:

/
/rootFile.txt
/src/
/src/srcFile.txt
/src/com/letor/example/
/src/com/letor/example/packageFile.txt

• rootFile.txt resides in the root folder
• srcFile.txt resides in the src folder, will be included in the classpath (alternative to this is your typical cls folder
• packageFile.txt lies in the same package directory as the class invoking the call

The program I wrote looks like this:

package com.letor.example;

import java.io.IOException;
import java.io.InputStream;
import java.util.logging.Level;
import java.util.logging.Logger;

public class ResourceLoader 
{
	private static Logger log_ = Logger.getLogger(ResourceLoader.class.getName());
	
	public static String[] FILE_NAMES = { "rootFile.txt",
										  "/rootFile.txt",
										  "srcFile.txt",
										  "src/srcFile.txt",
										  "/src/srcFile.txt",
										  "packageFile.txt", 
										  "com/letor/example/packageFile.txt",
										  "/com/letor/example/packageFile.txt" };
	
	public static void main(String[] args)
	{
		StringBuilder sb = new StringBuilder();
		sb.append("\n");

		try
		{
			for (String filename : FILE_NAMES)
			{
				// Class
				sb.append("Class\t\t");
				InputStream in = ResourceLoader.class.getResourceAsStream(filename);
	
				if (in == null)
				{
					sb.append("NO");
				}
				else
				{
					sb.append("YES");
					in.close();
				}
	
				sb.append("\t[").append(filename).append("]\n");
				
				// ClassLoader
				sb.append("ClassLoader\t");
				in = ClassLoader.getSystemResourceAsStream(filename);
				
				if (in == null)
				{
					sb.append("NO");
				}
				else
				{
					sb.append("YES");
					in.close();
				}
	
				sb.append("\t[").append(filename).append("]\n");
			}
		}
		catch (IOException ioe)
		{
			log_.log(Level.SEVERE, "Failed to load a resource", ioe);
		}
		log_.info(sb.toString());
	}
}

Running the program produces the following output. Class indicates Class.getResourceAsStream() call. ClassLoader indicates ClassLoader.getSystemResourceAsStream() method.

Class		NO	[rootFile.txt]
ClassLoader	NO	[rootFile.txt]
Class		NO	[/rootFile.txt]
ClassLoader	NO	[/rootFile.txt]
Class		NO	[srcFile.txt]
ClassLoader	YES	[srcFile.txt]
Class		NO	[src/srcFile.txt]
ClassLoader	NO	[src/srcFile.txt]
Class		NO	[/src/srcFile.txt]
ClassLoader	NO	[/src/srcFile.txt]
Class		YES	[packageFile.txt]
ClassLoader	NO	[packageFile.txt]
Class		NO	[com/letor/example/packageFile.txt]
ClassLoader	YES	[com/letor/example/packageFile.txt]
Class		YES	[/com/letor/example/packageFile.txt]
ClassLoader	NO	[/com/letor/example/packageFile.txt]

Now let’s go over each one of the lines and figure out what is happening

Class		NO	[rootFile.txt]
ClassLoader	NO	[rootFile.txt]
Class		NO	[/rootFile.txt]
ClassLoader	NO	[/rootFile.txt]

In all four cases files are not visible to the class loader since the root directory is not in the classpath.

Class		NO	[srcFile.txt]
ClassLoader	YES	[srcFile.txt]

Class does not see this file since it looks in the same directory where it resides. ClassLoader, however starts at the root of the classpath and finds the file.

Class		NO	[src/srcFile.txt]
ClassLoader	NO	[src/srcFile.txt]
Class		NO	[/src/srcFile.txt]
ClassLoader	NO	[/src/srcFile.txt]

In all of these cases the file is not found. Notice that prepending slash to the path does not help.

Class		YES	[packageFile.txt]
ClassLoader	NO	[packageFile.txt]

This is the exact opposite of what we saw when looking for srcFile.txt. Here the Class finds the file since it is in the same package, but ClassLoader fails

Class		NO	[com/letor/example/packageFile.txt]
ClassLoader	YES	[com/letor/example/packageFile.txt]

The last four cases are the most interesting. Notice the inverse relationship. Here the Class fails to find the file since it starts looking from its own directory. ClassLoader looks from the classpath root and easily finds the file

Class		YES	[/com/letor/example/packageFile.txt]
ClassLoader	NO	[/com/letor/example/packageFile.txt]

Finally Class figures out what to do, since we’ve specified a slash. Now it knows to go back to the beginning of the classpath. ClassLoader is less lucky, that slash confuses it.

I hope that this has been as educational for you as it was for me. Let’s sum all of this up.

Class.getResourceAsStream() will always look in its own package directory first. The only way to tell it look elsewhere is to provide it with an absolute path

ClassLoader.getSystemResourceAsStream() will always start looking at the root of the classpath, but do not confuse it by a forward slash.

“Pragmatic Project Automation” does a good job of introducing us to the world of continuous software integration. It covers all aspects of the software lifecycle, mainly focusing on the build, deployment and monitoring. You will learn how to organize your software release process so as to utilize a number of automatic tools, services and techniques.

The end result should be a process where a large number of human errors during deployment would be caught or avoided, gaining better confidence in what has been released.

Technologies used in this book are: Java, Ant, CruiseControl, scripting, JUnit. There is talk of Maven, but I guess that it was not yet as prominent in 2004 as it is today. The same techniques can easily be applied to .NET, PHP, Python or any other development environment.

Since most examples assume a website for a project, I wish that there would be a section on how a client-server app with a database would fit this model.

One thing that I find awkward is the choice of Version Control, it is still CVS. This book was published in 2004, when SVN has already showed its superiority over CVS.

This book does contain everything one need to know to start using project automation at your shop. I would recommend a place on developer’s bookshelf for this book.

P.S. This book is still not available on Kindle. :(

In the past two months I’ve been getting this message quite frequently when using Apple Mail with Gmail. “The server returned the error: Account exceeded bandwidth limits. (Failure)”.

Having googled online I’ve found quite a few occurrences of this error out in the wild. Some say that this may be triggered by sending an extra large file as an attachment. Now I have not done that recently so it can’t be it.

My guess that this has something to do with Apple Mail and the way it communicates to Gmail. There must be some sort of an overhead that causes this “bandwidth exceeded” message. The forums indicate that this problem presents itself mostly on Snow Leopard OS X.

Usually this problem goes away in 24 hours. Unlocking your Google account from did not seem to do the trick.

There is an ongoing discussion of this issue at Google.