Uncategorized

Eclipse Workspace Template

2 Comments

Following on from my Installing Eclipse post, I put together an empty workspace using my recommendations, as well as a couple from the Ivan Moore and Mike Hill session Programming in the Small.

Unzip the template into your workspaces directory and rename it to whatever you want your new workspace to be called. When you start Eclipse, browse to the new workspace directory and have all your code templates set up already.

Download the Eclipse Workspace Template

Please feel free to make suggestions for further improvement.

Uncategorized

Do you have enough oil?

3 Comments

I was talking to someone who had had a project manager mention in a retrospective that he felt that the testing was slowing down the delivery. They wanted to stop “wasting time” on testing and refactoring.
When I heard this, I said “That’s a bit like going on a car journey and your passenger telling you to ignore the oil pressure light because they don’t want you wasting time topping up the engine oil”

Admittedly, you will get underway faster, but that’s going to be very little comfort when you come to a grinding halt a few miles down the road.

Uncategorized

Code should start out messy

2 Comments

Earlier today Antony said on Twitter:
“stop apologising if your code starts out messy… it’s how it ends up that counts…. you can’t make an omelette without breaking some eggs”

I replied:
“Code _should_ start out messy. Finding the right places for things is harder when they’re already neatly in the wrong place”

If you have a preconceived idea of where your code should go, you will put it there by default. Antony told me an experience he had with this when he was untangling dependencies in jnarrate. By moving everything into a single package, then repackaging based on affinity, a much better package structure revealed itself.

At home, I would really like to re-organise my kitchen so that the pans are closer to the cooker. It makes sense from an ergonomics point of view. However, they already have a home. In order to rearrange the pans, I would have to empty the existing cupboard and the destination cupboard. It’s less work for me to put the pans back in their existing space, but it bothers me whenever I think of it. I really should fix that

Uncategorized

Installing Eclipse

1 Comment

I’ve just bought myself a netbook, and following the example set by John Smart with his article on installing Eclipse, I’ll document what I do with a clean install of Eclipse.

First Things First

I download the Eclipse IDE for Java Developers. The download is less than half the size of the Java EE edition, and I can always add the extra plugins later (if needed)

Plug it in

I install the mercurial plugin. There is a pattern that I use for pushing mercurial changes to other SCMs (eg. subversion) that I will describe in another post. I intend to use Ivy for my dependency management, so I install IvyDE. I then install the code quality plugins that John mentions, as well as the Metrics plugin. (the following links are the urls for the update sites)

I also install JUnitMax. This is a new plugin from Kent Beck that runs your unit tests after every save. It’s currently on paid beta, and I highly recommend it. Subscribe here, it’s only $2/month

Templates

I update the following templates in Java -> Code Style -> Code Templates

Method Body

// ${todo} Auto-generated method stub
${body_statement}

This evaluates to an empty (apart from the comment) method for void types, or return null;. I’ve already discussed my thoughts on returning null, and I would rather my code failed if it hits an unimplemented method rather than continue in a potentially unsafe manner. So, I change this to:

throw new UnsupportedOperationException("TODO: Implement this method");

Catch block body

// ${todo} Auto-generated catch block
${exception_var}.printStackTrace();

I’ve also discussed my thoughts on checked exceptions. I prefer to not silently hide the exception with a stack trace, I also don’t want to make my callers deal with checked exceptions, so I change this template to:

throw new RuntimeException("TODO: Handle this exception better", ${exception_var});

Test Templates

I also create a new test template in Java -> Editor -> Templates. I copy the Test method (JUnit 4) and add some Behaviour Driven Design style guiding comments. Because I’m lazy, I name it T 🙂 

@${testType:newType(org.junit.Test)}
public void should${DoSomething}() throws Exception {
  // Given 
  ${cursor}
  // When
  // Then
}

Favourite Imports

I add the following classes to Java -> Editor -> Content Assist -> Favorites so that I can get type completion on my favourite static imports

  • org.hamcrest.CoreMatchers.*
  • org.hamcrest.Matchers.*
  • org.junit.Assert.*
  • org.mockito.Mockito.*

Code formatting

These are the changes I make to the default Eclipse settings for my personal code.
In Java -> Code Style -> Formatter 

Indentation -> General Settings -> Tab Policy => Spaces only 
Indentation -> General Settings -> Indentation size => 2
Indentation -> Indent -> Statements within 'switch' body => on
Control Statements -> General -> Insert new line before 'else' in an 'if' statement => on
Control Statements -> General -> Insert new line before 'catch' in a 'try' statement => on
Control Statements -> General -> Insert new line before 'finally' in a 'try' statement => on
Control Statements -> 'if else' -> Keep 'return' or 'throw' clause on one line => on
Line wrapping -> Line width and indentation levels -> Maximum line width => 132

I also make the following changes to the compiler warning settings (Java -> Compiler -> Errors / Warnings)

Potential Programming Problems -> Serializable class without serialVersionUID => Ignore
Unnecessary Code -> Unused Import => Error
Uncategorized

Happy New Year

1 Comment

It’s a new year, and I thought I would write down some of my goals for the next twelve months.

Uncategorized

Something to talk about?

1 Comment

During my current day to day role as a coach, I get a lot of opportunity to find out where people are having problems, which things are causing them pain and we can talk about ways to move things forward.

Having real problems helps to focus the mind on the pragmatic rather than the academic. It’s great to talk about how things would be better in a functional world without mutable state, but when we’re living in a Javabean world, that’s simply not possible.

With that in mind, I’d like to try and discover what is causing real people real problems. If you’re currently finding something hard (implementing a particular agile practice) or if there is some common convention that causes you to see red, or you feel strongly about something I’ve said previously (I reserve the right to change my stance 🙂 ), let me know (comments or email) and I will try and capture (and share) the generated discussion.

Hopefully this will be a fun exercise, as well as helping to focus on some of the current issues affecting our industry.

Uncategorized

Forming good habits requires discipline

Leave a comment

A long time ago, I went on an advanced driving session. One of the things that my instructor taught me was a mnemonic for checks that you should do before every journey. The mnemonic was POWER[1][2], which stands for:
Petrol – (or Phuel for diesel cars) check that you have enough
Oil – Check the dipstick level
Water – Check the level in the header tank if you have one
Electrics – Headlights, Tail lights, Brake lights, Indicators, Windscreen wipers and washers
Rubber – Tyres are inflated to the correct pressure, and the tread is within limits

These checks require very little in the way of skill or time. We should do them at least once per day, and preferably before every journey.
I don’t do these checks as often as I should, mainly because they are not habit and forming habits (good or bad) takes time and discipline.
If we were taught these checks as the first part of our driving instruction, it would seem unnatural to not do these checks before every journey. This is called Primacy and states that what is learnt first (good or bad) is hard to unlearn.

When learning to fly gliders, one of the first things I learned was the pre-flight check. This has the mnemonic CB SIFT CBE. To ignore this check would require a significant effort on my part. Even if I have already been through another, more comprehensive checklist, I will still run through this basic test before starting a flight, no matter what the aircraft. This significantly increases my chance of discovering a problem while I am still safe on the ground. Better to be on the ground, wishing you were flying, than to be in the air, wishing you were on the ground.

I know that writing software test-first leads to a better design and gives me a safety net within which to refactor. I know this in the same way that I know that I should check my oil regularly, but this is not the way that I learned to program. I still sometimes start writing code before I write the tests and find myself wishing I was down there, writing the tests first. It’s a hard habit to break.

Like the POWER checks, writing code test first is not difficult, it doesn’t take much extra time, and it pays benefits when we uncover problems before they get too serious. Until we unlearn the habit of jumping straight into the driving seat, we need the discipline to do our checks before hand.
Right now, I’m going to write two sticky notes. One for my car steering wheel that reads “POWER” and one for my computer monitor that reads “Have you got a test for that?”.

[1]Kent RoSPA Advanced Drivers and Riders
[2]Up2Speed
Uncategorized

Checked Exceptions are Waste

4 Comments

I can’t get no satisfaction, I can’t get no satisfaction
‘Cause I try and I try and I try and I try

(I Can’t Get No) Satisfaction – The Rolling Stones

Checked vs. Unchecked Exceptions

It’s a controversial subject; searching Google for checked versus unchecked exceptions reveals a lot of heated discussions both for and against Checked Exceptions.
Charles Lowell has a particularly succinct (and possibly NSFW) view

My view is similar. I can almost see a situation where I would like to ensure that exceptions are dealt with in a certain way, but it doesn’t quite reach as far as using checked exceptions.

Noisy IDEs

I think my issue is largely to do with the way that the IDEs (and compilers) deal with checked exceptions.
In Eclipse, if a method throws a checked exception, then auto-fix suggests two options; “Surround with try/catch” and “Add throws declaration to method”
I particularly have a problem with the second one. The further you get away from the source of the exception, the less likely you are to deal with it in a useful way. Not dealing with the exception is a reasonable option, but why does everyone in the call chain need to know about an exception that someone in the lower levels didn’t care enough about to handle?
Using unchecked exceptions gives us the choice to handle or propagate the exception, without polluting the higher levels with knowledge of unhandled exceptions.

The default Eclipse template for try / catch is to catch the exception and print the stack trace. This isn’t really handling the exception, it’s ignoring it (even if we’ve logged it). There is no way to know if this is an acceptable default without understanding the underlying code. Unfortunately, if we are leaving it as the default we probably don’t understand the underlying code (yet).

An alternative to Checked Exceptions
One of the nice things about checked exceptions is that they let you know the types of exception you can get. You get the IDE auto-completion and compiler checking.
A checked exception is essentially saying, “You might get this exception, and I insist that you deal with it in the way that you feel is most appropriate”
How can we continue to do this, and at the same time prevent boiler-plate or unnecessary pollution?

Something that I’m thinking about (but haven’t had the need to implement yet), is the concept of an ExceptionHandler class. This is an ideal place for Java Generics to come into play.
For example:

public void someCodeThatMayThrowAFileNotFoundException(String fileName, ExceptionHandler<FileNotFoundException> exceptionHandler) {
try {
open(fileName); // throws FileNotFoundException
}
catch (FileNotFoundException e) {
exceptionHandler.handleException(e);
}
}

By coding in this way, we can provide sensible default actions, such as:

// The Generic stuff has not been checked and is for illustration purposes.
// Let me know if I need to correct it :-)
public class PropagatingExceptionHandler extends ExceptionHandler<T extends Exception> {
public void handleException(T exception) {
throw(exception);
}
}

public class LogAndIgnoreExceptionHandler extends ExceptionHandler<T extends Exception> {
public void handleException(T exception) {
exception.printStackTrace(); // or log4j equivalent
}
}

This reduces the try / catch noise, gives us the compiler checking and type completion, and explicitly details the strategy that we are using for handling the exceptions for this part of code.

I’m open to someone showing me a really good use of checked exceptions, but for the time being, I won’t be using them.

Uncategorized

What should my code tell me?

Leave a comment

When I’m reading code, there are a number of things that make my job much easier.
The most important (in my opinion) is good naming, but how can we choose suitable names?
This is the pattern that I am starting to see (and recommend), and I think it is pretty effective.

What? How? Who? Why?

If we think of the code as a medium of communication, what questions should the code be able to answer?

What are we trying to achieve?
The method name should be a summary of what we are trying to achieve. For example, public void selectTheCustomerNamed(String customerName) {...}
It is (hopefully) clear from the method name what will happen when we call it, and what we need to pass in in order for the code to work.

How do we do this?
The body of the method should be the steps needed to achieve what it is we said we would do in the method name. The steps should be at the same level of abstraction. (See Composed Method)

public void selectTheCustomerNamed(String customerName) {
theUser.clicksOn(Application.SEARCH_BUTTON);
theUser.types(customerName,into(SearchPage.CUSTOMER_NAME));
theUser.clicks(SearchPage.BEGIN_SEARCH);
theUser.clicks(ResultsPage.FIRST_RESULT);
}

Who is doing the work?
In the example above, by naming the receiver of the messages after the actor who is likely to perform these steps, it helps focus the mind, and can help with appropriate method naming. For example, we can ask ourselves “What does theUser need to do next?”

Why are we doing this?
At one time or another, you will probably come across a comment like this:

// Add one to foo
foo++;

This kind of comment is irrelevant at best, it is telling us what the next line is doing. If the methods are well named, or the code is idiomatic, this is unnecessary. One negative consequence may be a kind of “comment blindness” where your mind filters the majority of comments as “noise”.
A better use of comments is to explain why we are doing things in a certain way, especially if it seems unusual. Martin Fowler briefly mentions this in the “Code Smells” chapter in Refactoring.
An example of this type of comment is shown below. This represents a hard-won piece of knowledge, and will hopefully prevent a well-meaning programmer from replacing the code with the getFooByQuery variant without checking the caching behaviour.

// We query the id first before trying to retrieve the object, because if we try to
// retrieve the object directly (with getFooByQuery), it always bypasses
// the cache (see @link{...})
Integer fooId = findFooIdByQuery(query);
return getFooById(fooId);

JavaDoc can also be used to tell your users why they might need to pay special attention. If the code is well named, you are unlikely to need JavaDoc for all classes.
Here are some examples of where you might like to use JavaDoc:

  • If you have a number of pluggable modules, why would you want to use this module

  • Reasons why a user might want to provide their own implementation of this class

  • Reasons why this code throws exceptions, and why a user might want to handle them

This is still a work in progress, but the results that I have seen so far have been encouraging. Please let me know in the comments if you have any suggestions for refinements or improvements.

log4j java stack-trace

Well, how did I get here?

Leave a comment


And you may find yourself living in a shotgun shack
And you may find yourself in another part of the world
And you may find yourself behind the wheel of a large automobile
And you may find yourself in a beautiful house, with a beautiful wife
And you may ask yourself, “Well… how did I get here?”

Once in a Lifetime – Talking Heads

Logging a Stack Trace in log4j

A while ago, I was trying to replace a number of hard coded strings with an appropriate Enum. Unfortunately, the design of the code I was working on meant that it was difficult to find all the possible values for the strings.
I decided that the behaviour that I wanted was:

  • If the string method was called with a new value, log that value, so that I can make a decision about whether I wish to add it to the Enum

  • If the string method was called with a value that matched a value in the Enum, I wanted a stack trace, so I could replace that call with the appropriate Enum call

The code I ended up with was something like this:

public void doSomething(String theDestination) {
if(weKnowAbout(theDestination)) {
logger.debug("doSomething called with a known destination of " + theDestination, new Throwable());
}
else {
logger.debug("doSomething called with unknown destination of " + theDestination);
}
doWhatWeNeedToDoWith(theDestination);
}

Passing the new Throwable() into log4j creates a stack trace in the log output. I’ve found a number of places that tell you how to do this (now that I know how to do it), but it took me quite a bit of searching when I was first looking.