Tag Archive
admin agile ant bea classpath hell coding standards common sense design doh eclipse economics ejb Hibernate humour ide IE intellij ioc Java javaworld junit language design learning management maven meh nytimes opinion patterns personal Politics refactoring Ruby struts suncorp tdd testing testng unit testing usa web app web design weblogic weblogic workshop wotif
Interfaces with EJB3
Starting last October, we went through a process of upgrading the main application at Wotif to be running under Java EE 5 (not just Java SE 5). The biggest part of this was upgrading from EJB 2 to EJB 3.
One of the things I noticed was that EJB3 gives you a lot of choices for [...]
JBR’s Postulate 1
From the JUnit mailing list, courtesy of J.B "JUnit Recipies" Rainsberger
JBR’s postulate 1. For every testable design that requires exposing elements “just for testing”, there exists an equivalent testable design that does not require exposing elements “just for testing”.
Peering into the crystal ball: BDUF vs emergent design
There’s always a lot of debate in the various agile groups about what BDUF is, why you should avoid it, when you should avoid it, and why is it bad (or good) for you. I just thought I’d outline my own opinions here.
It’s a bird, it’s a plane… it’s a super call?
Martin Fowler wrote about the Call Super smell. This occurs when you are allowed to override a method in a parent class, but you must (as opposed to can) call the parent implementation in your method.
Your brain on design pattens
Picked up my copy of Head First Design Patterns today (I’d ordered it in a couple of weeks ago). So far I’m loving it.
Testing pattern: don’t test too much at once
This has been said before, I know, but it’s worth re-iterating: a test should test one thing, and one thing only.
First, some scope definition. Using Kent Beck’s terminology, I’m talking about developer tests, not acceptance tests. Also, by one thing, I mean that there should be only one thing that breaks the test (which is [...]
Interfaces are interesting…
Cedric’s got an interesting post on obtaining extensibility via interfaces As usual, he makes a lot of very good points, and (again, as usual when I link to Cedric’s posts), there are a couple that I think could be elaborated on.
Your code sucks because…
I rediscovered this article while doing some research. It gives an extensive list of reasons why your code sucks.
Granularity of types
Elizabeth Keogh has been writing a couple of articles on naming of interfaces. In the process, she’s highlighted a more important issue: granularity of types.
Differences cause problems
This is obvious, but differences between environments cause problems. You can expect bugs to cluster around them.