Daniel Schneller's Blog

Due to some discrepancies between the Eclipse 3.2.2 compiler and Sun's javac we needed to upgrade our development environments to Eclipse 3.3. Otherwise we could not tell for sure that something that looked ok in Eclipse would compile in the daily build process. Even though I had used 3.3 privately for some time now, there is always some tension when switching a whole bunch of developers in a really large project. At first everything seemed fine, apart from some minor issues that could be easily worked around. However I ran into a nasty little bug regarding the CVS integration when I had to switch a workspace that had been checked out on HEAD to another branch. That branch had been created to keep the Helpers- and Utilities-Refactoring I wrote about before separate from the HEAD until it is complete. Within Eclipse you can just select "Switch to another branch or version" from the context menu on any project (or file for that matter) and select the branch you would like

With any code base of a reasonable size there are lots of issues you would normally take care of immediately when you come across them, however often there is just no time for it. In the end you will have to live with the knowledge that you had to leave some ugly hacks in it just to meet the deadline. Because we have recently finished development of the next major release of our software product, there is some time now to do code cleanup and get some more automated tests on the way. Because one of the bugs that almost prevented us from holding our schedule was a particularly nasty - but well hidden one - there has (again) been some discussion about coding guidelines and quality. People always seem to agree that you need to talk to each other, think in larger terms than just your specific problem at the time and strive for code readability and re-usability. For starters I personally would sometimes even do away with just a little more of the former one... The bug I mentioned ab

I remember when I got my first hard drive. It was part of the first PC machine I ever had, a 386DX40. Before that I owned an Atari 800XL and an Amiga 500 . While there were hard drives for the Amiga I couldn't afford one at the time. The 386 came with a 52MB Quantum. Back then I had to decide whether I wanted to have Windows 3.0 on the disk or Wing Commander 2 . While I'm not really too eager to go back to those times I recently noticed (again) that the vast amounts of disk space we have today are not always a good thing in a manner of speaking. Over the years I owned several computers, with each new one came a new, bigger hard drive. As I usually sold the old machine - and the smaller hard drive with it - I just copied (almost) everything into some sort of "old_disk" folder on the new machine. When the next upgrade came, I had (of course) not reviewed everything in that folder and so, just to be on the safe side, just put it into the next "layer of archive&quo

One of the key features MySQL often uses to advertise for their database is the modular architecture that allows them to have different storage engines below the same SQL layer. In practice the application and/or database designer can choose from a variety of low level data storage implementations that each offer different characteristics and may be chosen on a per table basis. (Even though I personally believe most designs will use one type of table for all tables of a particular schema). The idea behind this is that for example people who do not need transactions should not have to worry about them at all – maybe there is a performance impact involved which they cannot afford to take. Moreover some specialized types of index or column might not be available on all engines. Basically the concept is very interesting and can be really useful for developers. However there is a weakness that in my opinion needs some severe work to be done: The interface between the common SQL layer an