fuzzylizard

If anyone wants to watch a really dark video of my little robot passing the final demo, I have uploaded a quicktime video. Enjoy.

One problem in the past with NetBeans 4.x was that, when it came time to create a new project, you could either use your own build script and loose a lot of the capabilities of the IDE or use a straight NetBeans project and loose the advantage of having your own build script. This, in my opinion was one of the biggest problems with NetBeans. If you used your own build script, you lost the ability to run a web application and run individual JUnit tests (unless you could put that functionality into your build script).

With NetBeans 5 this has changed. The other day I tried to create a new project from existing sources. The existing sources already had a build file. In the past NetBeans would have failed trying to create the project. Now, it pops up a little dialogue telling you that there is an existing build file and what would you like to call NetBean’s build script. It defaults to nbbuild.xml.

This is a very nice little feature. Now I can have my build script and the power of the IDE. At this rate, the NetBeans crew are going to release a top notch IDE when they release version 5. This will be the release to compete head to head with Eclipse and Intellij IDEA.

I found a link to this video, _An Evening with Steve Wozniak_, on Digg.com. It is a presentation that Steve Wozniak did for the the “Computer History Museum”:http://www.computerhistory.org and offers a glimpse into what it took to start Apple from an engineers perspective.

I have one complaint against many open source projects and that is the lack of good documentation. An example of this happened yesterday, I wanted to find out if Hibernate 3.1 had a dialect for the Derby database. I searched the web site and the documentation and found that it did not. The only real note that I could find stated that there was experimental support for it, except that this support was for Hibernate 2.x.

I resigned myself to looking for a new database, one that was supported by Hibernate. So I downloaded the code and went to check out the HypersonicDB website. I also checked the 3.1 documentation to see what dialects were offered, once again, it said that Derby was not supported.

I decided to look inside the jar file to double check this. What I found was that there was a dialect for Derby. I have not tested it out, but since it is in the base jar file I can only assume that it is fully supported.

My question is why has the documentation not been updated to show this? If Derby is supported, it should be listed somewhere in the docs or on the website, and it is not.

I would really like to provide a full tutorial on how to install Oracle XE onto CentOS 4, however, the install was so simple and easy that reading a tutorial would take longer than the install. Plus, Oracle provides a nice little flash based tutorial anyway, just take a look through their online tutorials and you should find it.

I did have one problem; I was missing one dependency. I inserted the CentOS install DVD, found the missing library, installed it (with no problems) and then simply ran the Oracle rpm. Once the rpm was finished, I had to go through a little config script that basically sets passwords, sets the default ports for the web server and the database itself, and asks if you want Oracle to run on startup. That’s it. It really is incredibly simple.

I don’t know if it is this easy on all versions of Linux, CentOS is, after all, a clone of Red Hat Enterprise Linux 4, so that probably accounts for a lot of the simplicity. But I have to say, Oracle has made working with Oracle XE incredibly easy on either Linux or Windows.

Marttin Fowler has put a post up on his website that is causing quite a stir in the Java/Ruby world. The article is about creating what he calls a Humane Interface.

The essence of the humane interface is to find out what people want to do and design the interface so that it’s really easy to do the common case.

The obvious contrast to a minimal interface is that humane interfaces tend to be much larger, and indeed humane interface designers don’t worry too much about the interface being big. This isn’t to say that classes with humane interfaces need be larger in terms of implementation. The fundamental functionality of the two is often quite similar.

As an example, he contrasts the java.util.List class in Java with the Array class in Ruby. The first has 25 methods and the latter has 78. However, as I do not know Ruby, yet, I can not really comment on the example.

At the end of the article Fowler has a list of blog articles all written as a reaction to what he posted or to what other people have posted. Some agree with him and others oppose him. The comments and posts that I have read have all been excellent and have done a really good job of staying on topic. The posts are definitly educational.

The entire thing raises an interesting point, should a class only contain the bare minimum of methods to accomplish its task or should developers create methods simply for the sake of making the class easier and more humane to work with?

db4o looks pretty interesting and is definitely something worth checking out for project:TeamDocs. It would be nice to replace all the SQL and deal with POJOs everwhere.

One thing that stands out is that db4o allows you to persist plain ‘ol Java objects as plain ‘ol Java objects. POJOs need not extend any magic base class or implement any special interface. POJOs need not have any special id field. POJOs need not have any special constructor. There is no requirement for a no-arg constructor or even a public constructor. db4o doesn’t require any object descriptors (XML or otherwise) and doesn’t require you to mark persistent classes up with annotations. db4o does not require that persistent fields have Java Bean compliant getters and setters. db4o pretty much will take your objects as they come.