Everyday Coder

Need a website? Want to give your store an online presence? Just want to share photos with family and friends? If you need a reliable, local (Chattanooga area), experienced software developer, then I'm your man. I give solid estimates, and have fair prices for every project. Check out the services I offer and please send me a message. I make websites everyday for everyday people and businesses. I can make one for you. Oh yeah, I'm also an experienced software developer, so I can handle just about any project.

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 explanation 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.

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.

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.