Original Whatever

I decided to give the JetBrains TeamCity 1.0 beta a try. JetBrains is the company that makes IntelliJ IDEA, the best Java IDE by far, and TeamCity is their new continuous build tool. You can download TeamCity as either a WAR or a ZIP, which includes Tomcat. I downloaded the ZIP and unpacked it into a directory on my iMac. It looked like a pretty standard Tomcat layout. I ran the startup script, and (after giving me a warning about a missing work directory) it started up. So far, so good. I accessed TeamCity on its default port of 8111. The main page appeared and invited me to create a new administration account. What could be easier than that? I didn't have to configure anything beforehand; the software was smart enough to know that the first account created has to be an administrator account. After logging in, I headed to the Administration page and created a new project. I use Perforce for source control, and TeamCity supports Perforce directly. I created a new client

I'm sure that everyone is familiar with the data access object or DAO pattern. The basic idea of a DAO is that you encapsulate the nitty gritty details of saving and loading data to and from a persistent store in an object so your application logic isn't riddled with SQL or filesystem access or whatever it is that your DAO does. In the two years that I've been working with Hibernate, the DAO pattern continues to bother me. I always seem to be writing the same code over and over again: save this, load that, run some query, etc. Whenever I have to repeat myself a lot, I start to think that something's wrong. I eventually put some of the common stuff into a general-purpose DAO class that I used as the superclass for all my other DAOs, but then it seemed that my DAO superclass was just a less-functional wrapper around the Hibernate Session interface. I also kept having to write code to do things that Hibernate already supports, for example, query by example. A deeper