I am Paul Wilson; Mere Complexities Limited, sells my consulting, coaching, and coding services. I am passionate about Agile, particularly Test Driven Development.
PD James’ Death of an Expert Witness gave me an insight into the roles and culture of a forensic science team in the 1970s. It occurs to me that detective fiction might be used to shed light on an XP team. Of course to provide the right level of barely concealed tension, strained alliances, and discomfort appropriate to a murder mystery it would have to be a team in transition.
One of the most important programming skills is the ability to make abstractions, and there are some quite talented programmers out there. Unfortunately many use their powers of abstraction for evil instead of good. Consider the following Java:
public class ActionServlet extends HttpServlet
{
private ActionService actionService;
protected void doPost(HttpServletRequest request, HttpServletResponse response)
{
Action action = actionService.createAction(request.getParameter("actionCode"));
action.setNote(request.getParameter("actionNote"));
action.setTargetId(request.getParameter("actionTargetId"));
action.setActionDateAndTime(toDateAndTime(request.getParameter("actionDate")));
actionService.handleAction(action);
....
}
.....
}
Nice! They’ve abstracted out the domain. I bet if you follow the code into handleAction() you’ll just find more framework. I come across too much code in which I can’t find the domain for the design.
This is the kind of thing I’d prefer to see:
public class ParcelArrivedServlet extends HttpServlet
{
private ParcelRepository parcelRepository;
protected void doPost(HttpServletRequest request, HttpServletResponse response)
{
Parcel parcel = parcelRepository.findParcel(request.getParameter("parcelId"));
parcel.hasArrivedAt(toDateAndTime(request.getParameter("arrivalDateAndTime")))
.withDeliveryNote(request.getParameter("deliveryNote"));
.....
}
.....
}
It’s nice to see work on a Ruby/Erlang bridge. I’ve a suspicion that a Ruby / Erlang combination would be a perfect combination for the kind of Straight Through Processing applications I often end up working on: the ideal is usually for massive scaleability at the back-end and a nice looking GUI for monitoring and exception handling.
Years ago I used to miss the C++ pre-processor when programming in Java. I got over it, but others obviously didn’t: they invented Apect Oriented Programming, which essentially does the same kind of thing, except in a more complicated and clever kind of way.
I admit that declarative transactions are neat, and using AOP for tracing can be handy. But intercepting method calls and messing with parameters, return values, and exceptions is wrong and dangerous in the same way that is wrong and dangerous to store your bleach in old lemonade bottles.
Please don’t use magic to change code behaviour: I don’t like that kind of surprise.
Once you have a good excuse, you open the door to bad excuses. Thud, by Terry Pratchett
From time to time the present situation may force you to compromise: maybe you need to add technical stories to the backlog, be unable to stop the line when errors enter the system, or make a code change without a failing test (the horror!).
Watch out for cognitive dissonance. Just because you are doing these things, doesn’t make them right. Keep an eye on where you want to be, and work to improving your environment and resources so you can get there.
Instructions on how to deploy a Rails Application on Tomcat. I've got to try this out. Wonder if I can get it working without installing PostgreSQL.
Via Ruby Inside.
In 1973 my Mum and Dad opened a building society account for me with a few quid from my Grandad. I was only four, but in the time of Green Shield Stamps having a long term building society account was a crucial help in securing a mortgage. Twenty nine years later it didn’t help when buying our first house.
I was reminded of the building society account when I saw that google-ability was influencing baby name choices.
(Via Freakonamics.)
Have you tried running the shell on your system? If not, please stop and try it now. If you just read the text without typing in the commands, you may think that you understand what is happening but you will not have transferred this knowledge from your brain to your fingertips — programming is not a spectator sport.
I’ve just started the Pragmatic Programming Erlang book. It’s well written and fun to program along as I read. Functional languages are (mostly) new to me, but Ruby is sooo last year.
You don't need it.
You don't need it.
You don't need it.
You don't need it.
One way of looking at unit tests is in terms of Design by Contract: most tests define postconditions and there can also be value in having tests showing that a class fails-fast on precondition failure. While helping out on a TDD course this week it occurred to me that Junit 4 provides a simple mechanism for checking class invariants in unit tests: it’s particularly useful to be confident invariants hold even after exceptions have been thrown.
For example, a game of Blackjack may allow dealing only once.
@After
public void ensureInvariants()
{
assertTrue(game.canDeal() == !game.isDealt());
}
Of course, it wouldn’t be rocket science to do the same in Junit 3.8:
protected void runTest() throws Throwable
{
super.runTest();
ensureInvariants();
}
public void ensureInvariants()
{
assertTrue(game.canDeal() == !game.isDealt());
}
(PS credit to Malcolm Sparks for suggesting that I blog this.)
![Contact email to pwjobs [[ at ]] merecomplexities.com](email.gif)