englishteeth.co.uk

I read an great article Gin, Television, and Social Surplus via eirikso.com, that I was determined to post on but haven had the chance. To much watching TV no doubt!

I have some fun playing with a this java testability explorer from a guy called Misko Hevery.

Then a I had a frustrating delve back into J2ME with a little help from J2ME and My RAZR and in particular this Guide to getting started in J2ME for the Motorola v3x phone. Though I must admit that the bundled MOTODEV Studio for Java ME v1.3 from The Motorola developer network covers pretty much everything.

In the end I was just let down with unlocking my phone. I’ll give it another go, but I’m not holding my breath. Perhaps this Motorola V3 RAZR Unlocking Kit might help. If it’s as straight forward via Blue Tooth as instructions in this post suggest, I’ll eat my hat! I hate it when technology you pay good money for is senselessly hobbled.

I was needing to brush up a style sheet and wanted a clean way to apply drop shadows, which I found here.

I often use the in-line lists for page navigation, but I hadn’t come across the use of floats described in this post here and here. However, while looking for a slick way of producing “rounded corners”, I found an implementation using sliding doors that happened to have the drop shadow I was after as part of the border image here, though I must admit to preferring the variation I found here.

And when I needed to print CSS background images, this post proved most helpful.

Along the way, I stumbled across the site Position Is Everything which looked like it might be worth making a note of.

Following the news of the Spring Source Application Platform I need to look back at this post on web applications and OSGi.

I also enjoyed this post on converting Java to Groovy.

Following a little foray down the path of UML modelling XML Schemas for a colleague, this article articulated what I was trying to get across much better than I could have. Rational Software Architect unfortunately couldn’t quite grasp it quite as easily. No change there then…

Having come across Alex Miller’s blog, I’ve enjoyed a number of his posts. However, whereas I am definitely in-line with his dislike of the Singleton pattern, I couldn’t agree with his conclusions on the use of the template pattern.

1. Communicates intent poorly - The template method pattern is often used as part of the effective API in some mini-framework where the framework user is expected to subclass the template class. My experience has been that it is difficult to communicate that usage intent to users of the framework. Often the template class has some non-private methods that are exposed for use by the framework but are not intended to be used by the framework user, some that are intended to be overridden, and some that are both. Also, you may need to say whether the super’s version of the method can, should, or must be called. Communicating all that clearly is impossible in an API of any complexity.

I think that this describes a poorly implemented template. Certainly I agree that the pattern (or any other), can be misused, but when applied correctly I have found it very useful in directing correct usage and taking away the worry that it what needs to be done gets done.

Let me try to concoct some example that is illustrative while not having so many holes in it to detract…

Take the struts Action for example.

It quite conceivable/normal that within an application some high level activities that are common to all actions find their way up into some super class that extends org.apache.struts.action.Action

As a result is is quite common to find implementations of the abstract execute method in Action that look something like

public class NewAction extends TopLevelApplicationAction {

    @Override
    public ActionForward execute(ActionMapping mapping, ActionForm form,
    		HttpServletRequest request, HttpServletResponse response)
    throws Exception {

	// Do the stuff that must always be done
    	super();

	// Do the stuff that My Action needs to do
	while(stuffToDo())
	{
		doStuff();
	}

    	return mapping.findForward(SUCCESS_FORWARD);
    }

I don’t like to see super(). It make me think what’s going on up there (which encapsulation dictates is none of my business) and it also makes me think what if it wasn’t called? This is basically relying on the implementer doing what is expected, rather than the design ensuring that it happens.

And this is where the Template pattern steps up to the mark.

Changing the TopLevelApplicationAction a little…

public abstract class TopLevelApplicationAction extends org.apache.struts.action.Action {

    @Override
    public final ActionForward execute(ActionMapping mapping, ActionForm form,
    		HttpServletRequest request, HttpServletResponse response)
    throws Exception {

	// Do the stuff that must always be done
 	while(stuffThatMustAlwaysBeDoneToDo())
	{
		doStuffThatMustAlwaysBeDone();
	}

    	return executeAction(mapping, form, request, response);
    }

    public abstract ActionForward executeAction(ActionMapping mapping, ActionForm form,
    		HttpServletRequest request, HttpServletResponse response) throws Exception;

This then constrains this implementation of this and removes the responsibility of calling the super class from the implementer of the specific action.

public class NewAction extends TopLevelApplicationAction {

    @Override
    public ActionForward executeAction(ActionMapping mapping, ActionForm form,
    		HttpServletRequest request, HttpServletResponse response)
    throws Exception {

	// Do the stuff that My Action needs to do
	while(stuffToDo())
	{
		doStuff();
	}

    	return mapping.findForward(SUCCESS_FORWARD);
    }

A bit of a noddy example, but surely that must be better than the first (and in my experience, the most commonly seen) approach!?

As my dentist is persistently asking me, “is it safe?”…

Having been asked to make some enhancements to an existing on-line application, I checked out the code from source control and made my way to the tests. Well you would wouldn’t you!

Selecting the root of the test source, I right clicked and selected run as JUnit test.

It was horrible; like a train crash or something.

After about an hour, I’d removed the errors my correcting path’s and references in the configuration. Unfortunately, I wasn’t in a position to address all the failures since I didn’t know what was bad tests and what was bad code. (Though since the application was live, with no outstanding bugs, it seemed reasonable to assume that the tests were stale.)

Within the tests I was disappointed, though not overly surprised, to find database dependencies to a database on some server. Luckily, the server and the database instance still existed, but I wasn’t really sure what it was used for.

A couple of days after tiding up the tests I was tracked down by team maintaining the mail servers. It appeared that the application I was looking into had been firing emails off to now defunct addresses that were collecting in their dead letter box.

Mixing unit and integration tests is not big and it’s not clever. Dependencies like these may seem reasonable to the developer in the heat of implementation, but they are not safe and make the subsequent support or enhancement of that software much more difficult.

Please test responsibly.

I’ve borrowed the Marathon Man image from this post from Freddo Fungus.

Some of my poking around in groovy on grails led me to a tutorial here.

This seemed well written and worked well and I explored a little more of his site and along the way I picked up a reference to a text on grails here.

Which itself enticed me along to the authors site here.

Where I found a link to an interesting take on the closures in Java debate here.

and an application that, if it works, might just negate the need that resulted me in dusting off my weblog here.

Useful, or at least vaguely interesting stuff on browser usage and trends here.

How to make a Sawed-off USB Key here.

Oh and that voice mail to text thing on last week’s gadget show that I must check out further here.