We were trying to debug some Hibernate rich objects we had converted from hbm files to annotations, and the objects were blowing up.  One of our more expertish developers with some Hibernate experience insisted that default fetching was lazy.  We decided to accept that as the word and left certain objects with their hbms attributing their failure to annotations not doing something mysterious correctly.

Well, I started to write some unit and integration tests on one of the newer annotated objects and was stubbing the data out with HSQL.  I noticed that there were errors in running the tests of the nature of  failure to hydrate objects.  It smelled like eager fetching. 

So I made the fetching on the many-to-one relationships explicity lazy in an annotation.  I couldn’t believe it.  Searching through the documentation I found this.  Who would have thought that Hibernate and JPA have taken two different approaches!

Fetch strategies and types

In native Hibernate, many-to-one association are lazy by default.
This means that selecting a list of objects with an HQL query will not
initialize the objects at the other end of the many-to-one association.
In JPA the default fetch type is eager (i.e. non-lazy), with separate
selects. This means that any JPAQL query for an entity that has
many-to-one associations in it will result in an N+1 SELECTS problem
even if those associations are not used. To eliminate the unnecessary
queries, simply set the fetch type to LAZY using:

<font color="#000066"><i> @ManyToOne(fetch=FetchType.LAZY)
</i></font>

Then, in any JPA query the association can be eagerly fetched using left join fetch.

Some reasons not to use TDD if the conditions warrant are:

• More code is higher risk for bugs.  Bottom line.
• More expensive.  TDD translates into stories/function points/developer time.  I don’t care what anyone says, I still like TAD a little better to get repeatable regressive costs over time.

Use TDD if you are designing things that will benefit from it.  Don’t if it will not.

Object Design?

TDD is a design pattern, nothing more nothing less. While I have read a few books about TDD . . . I wonder, if true TDD people refuse to do up front object design.  The methodology demands refactoring; and therefore following a Fowler idea that design will emerge, TDD practitioners must let objects emerge via refactoring.  I mean, if they are TRULY doing TDD that’s what they would do.

Timeboxing is Agile’s David

Its an interesting experiment to me; I do refactors and look for patterns.  Then I pull them out if needed.  Unless I come up with an estimate, and the project deadline and my manager says “no way jsut build it quick.”  If you get on one of those projects using TDD (I was on one) a LOT of spaghetti code, with lots of test cases, gets written.  Its about as bug proof as any other design style, that is, in those conditions TDD brings no value.

I think its a failure of a lot of Agile methods . . . ignores the reality of timeboxed projects.  I have never worked on anything but; even being relatively young as my first computer class was on a Tandy PET and my first Basic program on a Vic 20.

A Use Case Where TDD would Fail – SUV Analogy

I am actually using TDD do do some PL/SQL conversion scripts right now.   I have to do it old school; and its taking time.  Sometimes I just write the conditions.  Since the scripts are throw away it we can’t store the unit tests in any sort of DB repository (but that would be great for stored procs etc.).  I ran into a bit of a problem though . . . that writing code in TDD style sometimes causes more problems, depending on what you are trying to accomplish.

Talking with a friend I came up with this real-life analogy of where TDD would fail.

TDD thinks it addresses quality but one thing it introduces is possible defects  due to itself.   You have to make a judgement call based on your input factors of time, money, and risk as to whether its worth it to use this design pattern.  For example, it would absolutely be worth it if designing space shuttle software.  And, you had an unlimited budget.

But here’s an analogy where it would fail:

Suppose you are designing an SUV for extreme conditions.  In one case, it’s a highly wet cool condition and in another, is a hot temperature condition.

The designers decide that testing of everything is very important.  So they design in a hole in the engine that let’s you test sludge buildup in one of the cylinders:  you unscrew something and get a physical look.  Basically, a test has become part of the design.

But now the cylinder head is weakened because of the test.  You have introduced a few failure conditions:  possible weakened gasket that will let in contamination and cause engine failure.

• In the wet condition this may be worth while.  Sludge buildup and moisture may be something causes buildup and there would be value to check the state of the cylinder periodically to make sure you don’t need to run a cleaning process, etc.
• But in the hot condition, the gasket could keep failing and contaminants could be introduced via the testing port.  The strategy is just follow a maintenance schedule (TAD – test after), which you would have done anyway, because everyone has to do maintenance.

It’s just a hypothetical but there are a ton of other things in our life just like this.  Vehicles are easy . . . even now they are building all kinds of testing into the vehicles as part of the design (TDD): emissions, mixture, electric etc.  The payoff is that this is very expensive to pay for, and also in increase costs due to specialized maintenance because your every day Joe or Jane auto mechanic can’t work on their own vehicle.  Do vehicles really last any longer?  I’d argue that they do not.  TDD just extended the period between maintenance’s — i.e. you paid for your time up front instead of over time.

I’m not motivated enough to throw away a methodology if it may be useful, and TDD can teach us some things, but I guess the mantra is:  “TDD: do it only if necessary.“

• On your machine, install jdk 1.6 and change your environment path variables to point to the 1.6 directories.
• In Eclipse, Under Windows->Preferences->Java->Installed JREs make sure jdk 1.6 is  added, and select it.
• In Eclipse, Under Windows->Preferences->Java->Build Path->Classpath Variables make sure jdk 1.6 is added for JRE_LIB and JRE_SRC.
• In Eclipse, Under Windows->Preferences->Java->Compiler set compliance level to 1.6.
• In Eclipse, Under Windows->Preferences->Ant->Runtime set classpath variables 1.6.
• Update your JBoss server/web server to use the 1.6 runtime.
• In each project, change the compiler, the classpaths, the facets, and the runtimes for your servers (as applicable) to use jdk 1.6.

Then you should be good to go.  Build using both the Eclipse and the Ant methods to test . . . remember, the Hudson build server (or any build process) uses the ant scripts so if you check in the app with broken scripts you’ve checked in a bug!

What darcs is:

• It’s an easy to use, distributed, code repository.  It falls into the same category as Mercurial,GIT or Bazaar.
• Distributed?  Yes, patches are exchanged between repositories and there is no one single “mother”repository.
• Super lightweight; runs locally, super portable, cross platform, and easy to learn. The download is 4 megs.
• A great introduction to the world of distributed reversion control.
• Doesn’t do anything to your existing folder and file structures (non-invasive).

What is a distributed respository?

Hmmm . . .this definition is different depending on where you look.  Even as of this date (nov 6 2009) Wikipedia doesn’t have a good definition.

Here is my definition:

• Not tied to a central repository.
• It’s faster.
• Easier to branch.
• Work offline and still create commits.
• Distributed backups — everything is a working copy.
• Collaboration between developers without checking into central copy.
• It can run locally, easily (especially darcs).
• Useful if you are working on a module with a small team within a larger team, and want to revision/track changes with each other but not the full build.

I think subversion is a rock solid repository, and quite honestly, I am not a proponent of using technology for its own sake.  The simpler the better. But the future seems to be distributed repositories and maybe with teams working remotely from each other, the advance of SOA, etc. these types of tools will make more sense.  I suggest trying out darcs just because it gives you an idea very quickly what these are all about.

Repository Workflow

1. Clone a repository to your own repository.
2. Work in the clone — which is now your working copy.
3. Check in and out of your working copy from your IDE/cmd line.
4. When you are ready, commit those changes to another (or original) repository.

One way to look at this is, the “central” repository is the build server’s repository, and you have your own.  But just remember, the only thing central about that repository is that everyone agrees its the place where production bound code must end up.

Maybe this sounds disturbing.

In the “old” days the shops were so used to having copies of everything out of fear of a developer “getting hit by a bus” (which is code for: corporate culture does not trust anyone at all).    Honestly, I have yet to see that scenario. But it does lead us to something I haven’t seen discussed too much:

Best Practices Using Distributed Reversion Control

I haven’t thought about this much until now, but here are some of the guidelines I use for a distributed system.

• Refresh/rebuild in the morning.
• Check in when you get a meaningful amount of work done.
• Physically back up your directories
• Exchange your patches with your team (distributed backups).

Sometime when working in a continuous build environments, I will check things in with my feature sets turned off . . . but usually not, if they are not ready.  Also, you can keep a backup of workin progress in another of your own distributed repositories on a network drive (in addition to your local).

Back to Darcs
The scenario I describe here would be using darcs to sync files from an html blog between your local machine and a usb stick. Let’s assume you have some files at x:\usb\blog and locally, you want to work on them at c:\local\blog. (I actually use this method for a tiddlywiki “getting things done” piece.)

Download darcs and decompress to a desired location.  Add the directory to your path.

Create your first repository.  Navigate to x:\usb\blog and type:

darcs init

Next, recursively add all the files and folders from there:

darcs add -r *

Notice that it skipped all the _darcs files created from the init command!

Run this:

darcs whatsnew

And you can see all the new files and folders you added. But we haven’t saved yet, we have to do this:

darcs record -a

You get asked a few questions (which can be set on the command line as you get better with the tool) and its all checked in!

Time to get a copy of this repo to the local.

Navigate to c:\local\blog (which should be empty) and type:

darcs get x:\usb\blog

You have a local copy! Make changes in your existing files there (on c:\local\blog) and when you are ready, check in your changes:

darcs record -a

And then run this to propogate those changes to your usb stick — first change directories to x:\usb\blog and run:

darcs pull c:\local\blog

And both repositories are sync’d up.  I wrote a little batch file in my case to automate this.

You are probably wondering why in the world I would want to do such a thing.  Well, I can access the files in my tiddlywiki from several spots, and I don’t want a brute force copy over of the file least I lose information.  I need the granular capability  Also I also use it to branch — for instance at year end — very easy!!!

Of course there are a whole slew of other functions but that’ll do.  Darcs is the simplest tool to get your feet wet in the world of distributed version control.