dahamwirdensalat

Oh joy. Childhood is back again.

See, the first computer I’ve got was a Commodore C64 (first, the original one, but it had a hardware error, and I received a C64C as a replacement). One of the most fascinating things about it was not the interesting selection of user interface colors, but the fact that there was a BASIC interpreter built into the console; You could start coding right at the prompt.

I spent hours and hours typing code published in computer magazines (no floppy drive!) and sooner or later wrote my own programs. That – granted – never evolved beyond some basic PRINT commands.

Anyway, time has passed, and so has BASIC. Or so I thought. I recently discovered FreeBASIC, a free QBASIC compiler. OK, it’s not the good old C64 BASIC, but QBASIC is nearly as fine.

Finally, locate and cls made it back into the reportoir of words I regularily type.

Finally a project that allows me to try out a bit of this AJAX-thingy you youngsters out there keep talking about.
Neat, actually. I still hate JavaScript (who doesn’t?) and the DOM (again, who doesn’t?) but for this project, it actually makes a lot of sense.
I still wouldn’t touch this method with a 10-foot pole if I had write a real webapplication, but for a small pet project, it’s ok. Then again, maybe it’s just because I don’t have a useful development environment for js and php. Writing and debugging with a simple text editor and the JavaScript console from Firefox is a bit tiresome, to be honest.
There are some very interesting AJAX frameworks out there, I hope I’ll be able to check them out sometimes.
But now back to the texteditor.

<@kazin> why does php have 'echo' and 'print'? Do they do different things?
<Bluefoxicy> kazin: echo prints in a big empty room.

http://bash.org/?667677

Well, if it isn’t our overprotective mommy again. Sometimes, this Overprotection against technology is comfortable and gives a warm, snuggly feeling. And sometimes, it’s just brain dead. Whatever your personal opinion about iCal may be, you will have to agree that it falls into the latter category. I always suspected as much (at least since I found out that you cannot drag an eMail message from Mail to the ToDo list), but never paid too much attention to it. iCal looks nice, the name is confusing (because iCal is also the abbreviation of the file format it is using), it is simple and does what it should do.
This impression might change if you have to interact with it. Meaning: Exchange data with it. At first, you might be as naive as I am, and think: Well, it’s just a bunch of files. You can read and write them, so what could be the problem?
First of all, this is correct: It is just a bunch of files. The question is: Where are they? On OS X 10.3, they are in ~/Library/Calendars/. On OS X 10.4, every iCal file has its own folder inside ~/Library/Application Support/iCal/Sources, complete with additional files, indices, and a list of all available calendar files.
Supposing you solved the problem of finding the files you want to read from or write to, you will face another one:
iCal reads the calendar files (.ics) only on startup. For everything else, it uses its own, probably indexed, version that is burried somewhere in the caches part of the Library. That means that if your application changes the contents of the file, these changes will not be reflected in the iCal user interface.
Even better: Whenever iCal quits normally, it writes the contents of its own cache file back to the original calendar file, reverting all changes you made to the file.
To be fair, Apple does support synchronization between iCal and other applications through a Synchronization conduit (basically what the iPods are doing). But of course, there is no Java support for this method.
This leaves me with the not very attractive option of using a HTTP server inside a desktop application to export data into a different desktop application running on the same machine. I think I’m kidding, but actually, I’m not sure …

It’s been a while since I last wrote something about Timesheet. Sometimes, silence is a sign of work. The reporting and iCal code was thrown out. Relunctantly, I’ve taken up work on a caching mechanism that will make the startup of Timesheet much faster.
The user interface will present a cached version of the last state of the interface, while the actual data from the database is loaded in the background. It’s a bit tricky, because I’ll have to handle user-input in a queue, while keeping the fact that you’re not actually working on your data completely transparent. I hope I’ll be able to finish this in this week.

Axel just asked me for some help with a rather complicated query he tried to perform on a database. After looking at what he tried to do I finally realized that it is time to update my SQL-skills again. Silly Joins.

If somebody would actually have the nerve to compile a list of all technologies that most likely have been created simply to annoy people, I’d like to suggest Swing to be somewhere in there. Maybe Number 1 or 2, but definitely in the Top 5.
And I’m not even talking about the LayoutManager from Hell (also known as GridBoxLayout to its more intimate enemies), but just those little quirks that make working with Swing so difficult.
It took me the better part of two afternoons to figure out the answer to this question:

What do you do when you want to replace a component in a Window with another one?

Answer 1
Use component.repaint() on the parent of the changed component. After all, the component should be repainted as soon as possible after this call. Of course, this is a rhetorical entry, because I have to build up some drama.
Answer 2
Use component.invalidate() on the parent of the changed component.
This should also invalidate all parents of the component, so everyone should repaint itself. Sounds fine, but it’s also not working.
Answer 3
Both of them. Use repaint() and invalidate() liberally in the method that changes the component. Change the sequence of the calls, mix and shake it. Set this or that to null, just in case.

As you might have guessed by now, after I arrived at answer 3 (which, of course, is not the correct answer), I was rather furious. More or less by accident I discovered
Answer 4
Use component.revalidate().

As everyone will have guessed by now, Answer 4 is correct. I don’t know why, but I’m sure there is a very plausible explanation for it.

Ceterum censeo LayoutManager esse delendam!

Cross-platform or not, sometimes it’s important to know on which operating system your program is running on (because you need to know where your jar file is, for example).
Maybe not the nicest way to do it, but working:

private static final String MAC_ID = "Mac";
private static final String WINDOWS_ID = "Windows";

private String OSIdentifier;
private boolean isMac;
private boolean isWindows;
private boolean isUnix;

private String dataPath;
private String configPath;
private String jarPath;

private void init()
{
	OSIdentifier = System.getProperty("os.name");

	if (OSIdentifier.indexOf(MAC_ID) > -1)
	{
		isMac = true;
		dataPath = System.getProperty("user.home") + "/Library/Application Support/myProject/";
		jarPath = "./Contents/Resources/Java/";

	}
	else if (OSIdentifier.indexOf(WINDOWS_ID) > -1)
	{
		isWindows = true;
		dataPath = System.getProperty("user.home") + "\\myProject\\";
		jarPath = ".\\";
	}
	else
	{
		isUnix = true;
		dataPath = System.getProperty("user.home") + "/.myProject/";
		jarPath = "./";
	}

}

Add getters and setters, and you’re good to go. Of course, you might further differentiate between different Unix systems according to your needs.

Version information is important for applications and libraries alike. Somebody using your jar file (be it an application, a library or a part of a larger framework) should be able to tell which version of your program they are using. Equally, giving the users that information should be as little effort for the developer as possible. Some library authors solve this by creating versions of their libraries with the version information in the filename (for example, avalon-excalibur-vm14-20020705.jar, which happened to linger around in a lib directory I have open in my shell, so I used as an example), but this approach is not working very well for applications. Besides, using “versioned” filenames has its own problems (no drop-in replacement of newer versions because the classpath needs to be changed).

Another way to give the users informations about what version of a jar file they are using is to store it in the jar file itself, in a file called the manifest, which is present in all jar files.

This little tutorial shows you how to automatically generate the manifest for your jar file and access the information later on in your Java program (for example, in an “About” dialog). The insertion of the version information will be part of your automated build-process, and your Java application will read this information directly from the jar file. All you need is a text file containing the version name (or number). If you’re working with the subversion SCM, you can also easily add the current revision number to the jar file.

The main advantage of this approach is that version information (or any other information, for that matter) is stored in one place, and set at the time the jar file is created. No need for additional configuration files or hardcoded version identifiers in your classfiles.

Read the rest of this entry »

Changelogs (a list of changes between two versions of an application) are a valuable way to watch the progress of development and easily spot major changes in the code.

Whenever I create a new tag for a release version, I add a changelog to the commit message that states what the differences are between this version and the previous one.

Usually, this means creating a seperate textfile in which I keep track of all the changes I made while working on a new version. As I commit more and more, the list grows and grows. But actually, there is no need for a separate textfile. Commit logs should be little changelogs between revisions, and all information that is needed for a changelog is already in the repository. Why not use these messages as a starting point for a release changelog?

So, before creating the tag for the new release, we want to get a list of all changes made from the last tag up to now.

If you know the name of your last tag, but not the revision, do a

svn log -q --stop-on-copy http://svn.example.org/svn/project/tags/tagname

The result will look like this:

r360 | peter | 2006-04-14 16:46:42 +0200 (Fri, 14 Apr 2006)

r360 means that the tag was created in revision 360 of the repository.

If you don’t know the name of the last tag,

svn log -q http://svn.example.org/svn/project/tags/

will give you a list of all revisions of all tags. The first one in the list is the newest one.

All changes between revision (in our case, 360) and now are new. To get the logmessages for them, issue

svn log -r 361:HEAD

(of course, you need to use your revision number, not 361).

This cummulated changelog gives a good overview of what happened between the last tag and now and can be reduced in detail to make a good changelog for your next release.

Of course, this only works if you exercise some discipline when creating tags for releases (like never creating a release tag by going back in the trunk to a previous revision and tagging it; if you did that, you would have to not use HEAD, but rather the revision number you tagged).

I have a ticket here telling me that I should refactor two classes to get rid of visually unpleasant, intellectually boring and most of all redundant code that actually is working and took me some time to get right, inducing the nagging fear of creating new problems because both of them are at the core of the application.

So, what should I do? Keep rescheduling the ticket to the next upcoming milestone so it stays in the pipeline, or schedule it to a milestone so far up the road that we might never actually reach it?