Moving On

I hate to say it, but it's time for me to move onto bigger and better things. I recently switched to WordPress and hosting my own blog. It gives me a lot of freedom to do what I want.

Visit the new Everyday Coder.

An Incredible Machine

While working on large projects, it's good to have a distraction every now and then. My son and I can't watch this video enough. If you're into Rube Goldberg Machines, you'll love this video. It's a full 13 minutes long and is absolutely mesmerizing.

I hope you enjoyed it. I can't get that jingle out of my head. Pi-ta-go-ra Su-icchi. See it on google here.

Subversion Goodies

I use Subversion for source code management now on all my projects. Before, I used to use CVS like everyone else. Recently I discovered some things about subversion that I hadn't known.

On Windows, I *can* use putty as an ssh wrapper for subversion (svn+ssh://). This was a welcome surprise, because I was using TortoiseSVN which included its own ssh wrapper. TortoiseSVN is widely accepted among most developers on Windows, but I'm still used to the old CVS command line ('cvs up', 'cvs co', etc) and I always hated wading through Explorer to do an update. Anyway, I happened to notice a Subversion folder in my Application Data folder the other day. I went in there and found a file called config. In that file, I saw the old familier line commented out:

# ssh = $SVN_SSH ssh

I immediatly uncommented the line and changed it to:

ssh = \\putty\\plink.exe

In my CVS days I did know that plink is the program you use to tunnel through ssh. I tried to go in and run svn, but I kept getting a "file not found" error. I then looked more carefully at the config file and noticed there was a commented-out section: [tunnels]. I uncommented this section and it worked! That was easy.

My other great discovery was that SVN does, in fact, support keyword substitution like our old friend CVS. You know, $Id$, $Revision$, etc. I have such a habbit of putting '// $Id$' at the top of my source files; its not even funny. So the following command magically makes keywords work for svn:

svn propset svn:keywords "Id Author Rev" build.xml

There are more keywords, of course, and you can see the reference to them in the subversion documentation. Executing the above command works for the file given, but if you want it to work with every file, you'll need to specify the keywords in the [auto-props] section of your subversion config file (See above). After trolling a bit, I did find a nice example of a subversion config file on an Apache site.

I hope you put these "discoveries" to good use.

Effective Java: A Must Have

Every Java developer must own a copy of Effective Java: Programming Language Guide by Joshua Bloch. If you haven't read this book and you think you're a good Java developer, think again. This book challenges me to be a better coder every day.

The layout of the book is extremely easy to follow and reference. The individual concepts are grouped into "Items" and those items are grouped into topics that are the chapters of the book. At the very least, every programmer needs to read the first 18 items. I'll give you a brief example of the power of this book.

Item 7: Obey the general contract when overriding equals

Every Java developer tends to think he/she knows when and how to override the Object.equals method. This item explains the core concepts of the method and when and how to implement it. It's over 10 pages of explaination with code examples. I have used the techniques that Josh explained in almost every class I've written since I read this item. Before I read this book almost all of my equals methods failed to follow the general contract.

I could go on all day, but I know this isn't the place for that, so I really do hope that if you're a Java developer, you will own this book if you don't already. The full table of contents can be seen on the book's site.

Windows Installer for Java

I have to admit, that I always avoided installers for my Java apps. The last project I worked on was a big one. One that, of course, required a fancy installer for Windows (the only supported platform). Management (not the dev team) dictated that we must use the Wise installer. This seemed all well and good until I noticed the cost. WOW! Something as simple as copying a few files to the right place really costs that much? I was speechless.

Before that big project, I generally had to install on *nix, Mac, and Windows. Most of those projects simply required the user to unzip a zip file. I've been recently working on internal management projects in which Java Web Start is the installation method of choice. That works really well if your target audience already has Java installed.

My current project actually needs a bonafide Windows installer, as it will be distributed on CD and ship with its own JRE. I was given free reign this time (no management mandates). I did a little research and ran across the Nullsoft Scriptable Install System (NSIS). This is the same installer that WinAmp and many other OSS Windows apps use. It's licensed as completely free, even for corporate use.

The scripting language for NSIS is a bit cryptic if you've never done assembly before. But, the plethora of example scripts on their Wiki and in the examples covered everything I needed. More importantly, it just works.

As a side note, there are also examples of making a native launcher for your Java application using NSIS. That means that you can distribute a native EXE with your app that will launch your main class.

Java Persistence: An ongoing battle...

This is my inaugural post. I guess I should hit the ground running with a post concerning database access from Java applications. I'm in the minority in that I'm currently writing a stand-alone Java application, not a JEE Enterprise Application. I know that this may be a shock to some of you, but let's just keep moving.

I used to be in the Roll Your Own camp when it came to database persistence. I'd create a set of classes roughly separated along table boundaries. Those classes would call the classes in the java.sql package directly. This method seemed to work just fine, but it did take a lot of work to get all the code setup to convert ResultSets to real objects. I actually used that method several times in the past with great success. My only regret is that my internal object model usually mapped exactly to my tables -- meaning that references were often represeted by id's rather than an actual object reference.

As new projects arose, I found myself searching for something better suited to persisting objects from my data model. My next attempt was to use Hibernate. The most attractive feature that Hibernate offered was forced separation of the persistance layer and the Java object model. We eventually got Hibernate up and running and the project was done.

Hibernate left a bad taste in my mouth. It seemed that I spent a *lot* of time learning their object querying language as well as fiddling around with the XML mappings. I would much rather have spent the time adding additional features to the software. I know that one of the most attractive reasons that people use Hibernate is that the underlying database can change without too much effort. Sadly, this feature is flat-out usless to me. I have never once had management come to me and force me to change my DB.

I decided to be a little more drastic on my next project and I went with Prevayler. For those of you not familier with Prevayler: it's an object persistence layer relying on Java's object serialization with added transaction support. I have to say that I was pretty enthusiastic after reading up on Prevayler. Prevayler turned out to be a good fit for that application. My only complaint is that I had to create a boat load of transaction objects. I ended up with 50+ classes that handle the individual transactions within the object model. So basically, if I wanted to change a user's first name, I would create a ModifyUserTransaction passing in the new field values and that would perform the modification. Seemed like a lot of work.

Prevayler also left a sour taste in my mouth. I just hated having a package full of classes that were basically one line-ers. Anyway, it did work and given my previous battle with Hibernate, I was happy to see that no XML configuration files were needed. Also, the objects were all stored as serialized java objects in a snapshot file that could easily have been read by another Java application.

Then came my current project. This time, I'm forced to use an SQL server backend. Mostly due to the fact that we will want to take advantage of the stability and host it in a centralized location. I know that a lot of you would have immediatly jumped for the 3-tier JEE architecture. I, myself, chose to do an old-fashioned client-server application. This application will ultimatly communicate via JDBC to the native protocol for the database.

For this attempt, I've deviced to use the SpringFramework's JDBC API. After much reading this seems like a good choice. I'll let ya'll know how it turns out.

After reading back over this post, I realize that it may have rambled a bit, but I'll leave it as-is. After all, I'm just a lazy programmer.