non-random ramble

Situation: you have a hibernate component which itself has a link to another object (e.g. many-to-one)

When loading, if hibernate is not able to satisfy the dependency, it will NOT set the field for your component.

e.g. we have :

Just so i dont forget:

log4j.category.org.hibernate.SQL=DEBUG

log4j.category.org.hibernate.type=TRACE

These are my four solutions which seem to cover most situations. I particularly like 4) because I’m lazy.

• 1) Add a class (aka add another level of abstraction)
• 2) Remove a class (aka remove a level of abstraction)
• 3) Move stuff from one class to another (aka put the logic near the data or separation of concerns)
• 4) Don’t do it! (aka the thing you are trying to do is too complex or not well defined, so find another way)

I have created this page in the mind-web with the update sites for various eclipse plugins that are useful so i dont have to keep finding them over and over and over again.

Here it be:

http://jimbarritt.com/mind-web/index.php?title=List_of_useful_Eclipse_plugins

At the end of our last couple of retrospectives, we ended up with a set of actions that were really for the whole team to think about. Actually they were more like principles we should be following for the next iteration, rather than specific tasks.

Whilst retrospectives should really come out with very specific achievable and measurable actions, these more general themes can also be useful.

One of the team, Jeremy started writing the basics of the actions on cards as statements, like “Challenge Requirements”. We put these “mantras” on the wall and so we can see them and sometimes refer to them during standups.

This Iteration we did the same thing and it seemed to be a good way of capturing and making visible a result of our retrospective.

So far we have :

• Challenge requirements
• Understand Story Intention
• Challenge the spike
• Its not over until UAT (User acceptance testing or signoff)
• Keep stories focused and SIMPLE
• Migration code will ALWAYS be used again
• Transfer ownership (of stories, if people leave or move teams)
• Share Knowledge (as people roll off the project)
• Is it releasable? (an individual story)
• Demo Early