Cedric’s having another go at JUnit Again he misses the point: extensions to JUnit are not JUnit itself, and JUnit can’t be blamed for people extending it to the wrong way.
Working with legacy code can present some, um, interesting challenges. I just hit a wonderful issue to do with dates and timezones, caused by a really piss-poor data model.
A common feature of many IDE are templates, which greatly speed writing code. People often create their own “cut-and-paste” templates as well.
An important rule to remember here is that no template should ever “work” out of the box. This way, if (for whatever reason!) you don’t fill it in, you know it will fail fast. This helps avoid bugs that can be quite subtle: template code which fails slowly. 🙂
Continue reading “Never use a working template”
I had an interesting conversation with a colleague this afternoon. It centred around what was more important: expressing intent (which I was advocating) vs. removing duplication.
Continue reading “Expressing Intent vs Duplication”
I’m now working on my second project with Hibernate, having delivered the first, and I’m playing with some of the features I didn’t have time to figure out last time. And I have to say: named queries rock, big time.
A little while back, I blogged about how static and singleton are not synonymous, and one of the things I mentioned in there was the concept of an “access pattern”. This is a term I’ve been kicking around for a while (in person, anyway… I think that was the first time I’d written about it), and I wanted to explore it a bit more here.
Continue reading “Creational vs access patterns, and other diversions”
Hani makes a surprisingly unbilish point about wrapped exceptions Wrapping already wrapped exceptions isn’t the best idea in the world.
This technique reminds me of the children’s game of “Pass the Parcel”, where you put multiple layers of wrapping on a gift, and the children never know when they will reach the last one.
I’m as guilty of this as the next person, but I think in future I will modify the constructors of my wrapping exceptions so that if a cause already exists, it uses that as the cause, not the one supplied…
(FWIW, I’m not against wrapping exceptions; what is an ObjectNotFound at one layer is a ConfigurationException at another, and should be reflected as such).
This may, of course, just be a stupid idea, but it’s worth exploring.
A gentle reminder to myself: don’t make things more complicated than they need to be.