Some of you may have noticed that for a while WikiJava wasn’t quite as usual.

Because of a problem in the CMS I had to switch the website to a “static” version. I basically spent a night to download and save to html files the whole site. So that for some time it was the static pages serving the website, instead of the mediawiki CMS.

I now upgraded every single bit of the portal’s software, and I hope the problem won’t pop up again.

It all looks like working again, quite faster and more efficiently than before.

I hope you’ll like it. Please let me know if you see any flaws.

Giulio

Who knows what’s the output of the following program and why?

public class Swap {
 
	/**
	 * @param args
	 */
	public static void main(String[] args) {
		String first = "first";
		String second = "second";
 
		System.out.println("first: " + first);
		System.out.println("second: " + second);
 
		swap(first, second);
		System.out.println("variables swapped");
 
		System.out.println("first: " + first);
		System.out.println("second: " + second);
	}
 
	private static void swap(String first, String second) {
		String temp = second;
		second = first;
		first = temp;
	}
}

I’ll write some more about this soon.

I happened in a weird situation where I was debugging my project and I had a NullPointerException from one of the libraries I used.

The weird part was that even though I had recompiled the library and regularly attached the sources in Eclipse project, the debugged would not catch the right lines it was executing, but just showing some other lines from the source code.

Now I’m personally not an estimator of the NullPointerException. I believe that the JVM should at least put in the exception message the name of the variable that was found null.

The situation wasn’t too nice, because the library was a complex one. So I didn’t want to touch it too much by adding too much code to it, but at the same time, Eclipse would not help so I had to do something.

After thinking a bit I realized that really I could exploit the NullPointerException itself as a runtime exception to investigate the problem. NullPointerException is thrown when you try to use an object, but the variable you use to reference it is null.

For example:

String something = null;

if (something.equals("nono")) {
// the line above throws a NullPointerException
}

I loved this solution because this is really transforming your problem in a solution. Let me tell you something about runtime exceptions.

A runtime exception is one exception that you don’t need to explicitly catch in your programs. It’s like a ghost that can climb up your runtime stack and make you get crazy to debug.

So, how I exploited the NullPointerException? I just filled the source code of the library (just in the area where I got the problem) with if clauses like this:

if (inst == null) {
throw new NullPointerException("inst was null");
}

Basically I was manually checking which of my objects were null and throwing the NullPointerException writing in the message the name of the variable. This helped me in understanding where the problem was. and since NullPointerException is a runtime exception and I don’t need to explicitly throw runtime exceptions. I didn’t have to change any of the method signatures.

For once the problem helped to find its solution.

My good friend Orlando created a google group for the wikijava community, we’ll use it to discuss of Java and development related topics in an interactive way.

It will be used also to announce news about WikiJava.

To visit the group  : http://groups.google.com/group/wikijava

Register to stay tuned.

Whenever I choose to use a new program one of the factors I always take in consideration is its complexity and the difficulty of installation. In general I tend to prefer programs that are standalone and portable. The perfect program for me does not require installation and I can move it to different directories or even to a USB stick, and it still works keeping the configuration as well. If additionally the program is in Java then I’m very happy, because I can install, move and use the program freely even across different platforms.

Creating such software is not too complex for the programmer, and with very few adjustments it becomes very easy to make your software portable and standalone.

I just wrote a new article (first of a serie) that explains a technique for creating Java programs that can be distributed as single, executable files, no installation required.

Check it out at:

http://www.wikijava.org/wiki/Packing_library_packages_into_a_jar_file

I will write soon about how to automatically generate your jars like explained using ANT build files. Finally, for completeness, I’ll write an article about how jars are intended to be, without tricks. This last article will describe the build file and file structure of BatBot, because this is the way I’m implementing it.

Enjoy the reading

Few weeks ago I needed to read the user manuals for software that was written just for internal company use. It was a nightmare. It is very often a pain to read documentation that was made for internal use.

Imagine Paul, he just entered joined the team, his first task is to produce the workload reports for the team, for doing this he’s got to use the internal tool, that was created ad-hoc few years ago. Nobody in the team is available to explain him how to create these reports, they all say: “have you read the manual?” or “read the manual first, then I’ll answer your questions”. The manual was written when the program was created and never update since. Paul can’t almost understand a single concept in it. The very first phrase in the manual is: “In case you need to create a report for a new week  [cut]“. After reading Paul is quite disconcerne: “In case you need to”? What is this program for? what does it do? How does it do it? Why do I need it?

The fact is that the developers may be very good at writing software, but when they have to write code they fall more often than not into some common errors that practically make the manual unusable:

1. Too technical
2. Lack of updates
3. Assume the reader knows exactly what they are talking about
4. No examples
5. The “it should look like” formula
6. No document owner
7. No version number

It’s easy to solve these problems. It doesn’t require too much effort, and it’s something very valuable to get.

1. There must be an owner of the document, responsible of keeping it updated
2. The documentation responsible must have some kind of training in making documentation
3. The document must be versioned
4. Must be written in proper english.
5. Good idea is to write documentation before coding.
6. Write the documentation in a way that it is interesting to read.
7. Help understanding with lots of examples
8. Keep the documentation up to date
9. Explain every concept, don’t assume the reader knows anything about the subject
10. Explain the goals, always say what you are going to explain before explaining it.
11. Do not assume the reader knows what you are talking about.
12. Say it, then repeat it, then say it once more.

I repeated few of them, it’s because they are important.

Share your good/bad experiences with documentation in the comments below.

In the meantime I write about evolution of programming languages, I found something that I find hard to define.

The language is called ..  Continue reading »

Lately I’m checking out how to send SMS messages from within a Java Program. It’s actually quite easy.

There are basically two ways for sending text messages to mobile phones either by connecting a mobile phone to a the computer or to use an SMS Gateway.

Connecting the mobile phone to the computer port (serial or USB Port) and using it for sending text messages is very convenient, as for example one could set up his service and test it just by plugging the mobile phone, and without involving any third parties into the game. This is also very useful when an internet connection is not available, but phone coverage is.

I would say that this cannot be considered a definitive approach, as sending messages via mobile phone may turn up to be quite expensive, unless you have an SMS flat rate. But these normally come with clauses that sound pretty much like “don’t use it for commercial purposes”.

Additionally most of the Java implementations Continue reading »

• Real programmers don’t write specs. Users should consider themselves lucky to get any programs at all and take what they get.
• Real programmers don’t comment their code. If it was hard to write, it should be hard to read.
• Real programmers don’t write application programs, they program right down on the bare metal. Application programming is for feebs who can’t do systems programming.
• Real programmers don’t eat quiche. Real programmers don’t even know how to spell quiche. They eat Twinkies, Coke and palate-scorching Szechwan food.
• Real programmers don’t draw flowcharts. Flowcharts are, after all, the illiterate’s form of documentation. Cavemen drew flowcharts; look how much it did for them.
• Real programmers don’t read manuals. Reliance on a reference is a hallmark of the novice and the coward.
• Real programmers programs never work right the first time. But if you throw them on the machine they can be patched into working in only a few 30-hours debugging sessions.
• Real programmers don’t use Fortran. Fortran is for wimpy engineers who wear white socks, pipe stress freaks, and crystallography weenies. They get excited over finite state analysis and nuclear reactor simulation.
• Continue reading »

Please design and build me a house. I am not quite sure of what I need, so you should use your discretion. My house should have somewhere between two and forty-five bedrooms. Just make sure the plans are such that the bedrooms can be easily added or deleted. When you bring the blueprints to me, I will make the final decision of what I want. Also, bring me the cost breakdown for each configuration so that I can arbitrarily pick one.

Keep in mind that the house I ultimately choose must cost less than the one I am currently living in. Make sure, however, that you correct all the deficiencies that exist in my current house (the floor of my kitchen vibrates when I walk across it, and the walls don’t have nearly enough insulation in them).

Continue reading »