I haven’t posted here in months, I got married, I’m starting to build a house and I’m going back to school (in the evenings). So there won’t be much to read here in the near future.

I’m doing a lot of Swing lately and there is something that irritates me even harder as people who drive in the middle lane all the time:

This method is defined on the JComponent class so it gets used a lot. It irritates me a lot. How setLogical(false) does this sound? Imagine having to turn off the engine of your car with car.setEngineRunning(false)!

It’s hard to read and it implies changing a property of an object, when instead you are changing the behavior of an object. Of course, difference in behavior of objects is often if not always determined by the value(s) of one or more properties of that object, but I shouldn’t have to know about that. That’s up to the implementation of the object!

Doesn’t this sound better?
setDisabled()

Or even better:
disable()

Now I’m just sending a message to an object saying: dude, disable yourself, I don’t care how, just do it.

Funny thing is that those methods (enable() and disable()) do exist, but they are already deprecated since JDK 1.1 and replaced by setEnabled(boolean). I wonder why that is?

A related but not entirely the same post by Kevin Rutherford, which made me think about this more consciously: avoid boolean parameters

I'm doing some custom rendering of JasperReports designs, this is part of the domain model I'm working with:

There are more subclasses of JRDesignGraphicElement, but not all of them can have a box drawn around them, only the ones in the diagram are 'boxable'. Being boxable as an element adds some extra properties to that element, for example the width of the leftborder or the padding (I omitted most of the properties in the diagram for brevity). The way it is implemented in JasperReports is a bit unhappy (more about that later), but since it is an external library I have to deal with the existing domain model.

So far so good, the problem starts when I want to write a method that takes a Jasper element and draw a border around it. Something like this would seem right:
void drawBorder(Graphics2D gg, JRBox box)

The problem with this approach is that to be able to draw a border around an element, I need also the coordinates of that element and they are not exposed through the JRBox interface, but are defined in the JRDesignElement class. Bummer. I could cast it to a JRDesignElement though when I need the x, y, width and height attributes, and that probably wouldn't be a problem, as there are no other classes which implement the JRBox interface that are used in my code. But doing that would give me an icky feeling. It would create an unchecked (at compile time) precondition for using this method, and since I'm using a compiler anyway, I'd better use it, right?

The following declaration solves the problem:
<E extends JRDesignElement & JRbox> void drawBorder(Graphics2D gg, E e)

What this is saying is that E is of type JRDesignElement and of type JRBox, effectively letting me use methods and properties of both types.

e.getX(); and e.getLeftBorder()

is legal code inside the method declaration, and the compiler will enforce that I don't pass on any objects of type JRDesignElement that don't implement the interface JRBox to the method. Pretty sweet stuff I think. You can even specify more bounds if you want like E extends N & N1 & N2 & .... One remark though, Eclipse 3.1.2 can't seem to handle multiple bounds, the code compiles, but code completion doesn't show all the available methods and sometimes the background compiler shows errors that dissapear after compiling the project. IntelliJ has no problems with this. (of course:))

I mentioned before that I think the JRBox functionality is a bit unhappily implemented, actually I had been thinking about this on the way home the day I wrote the drawBorder method, but couldn't find a better solution myself. The JRBox interface is inconvenient first of all because of the problem laid out before, but also because of the fact that every class that implements JRBox has the same tedious implementation (== code duplication). The easy way would be to create an abstract class JRBox that inherits from JRDesignGraphicElement and let all classes that are boxable inherit from JRBox. Technically speaking this would be a good solution but it would violate some OO principles. Elements can be boxable, which implies a 'flavor' of an element, but doesn't mean they are a box.

How else would you implement this? Any suggestions?

In a more versatile language like Ruby we have mixins which are perfect for this situation. The implementation could look like this:

module JRBox
	def left_padding
		...
	end
	
	def left_border
		...
	end
end

class JRDesignElement
  attr_accessor :x, :y, :width, :height
end

class JRDesignGraphicElement < JRDesignElement
end

class JRDesignImage < JRDesignGraphicElement
	include JRBox
end

class JRDesignTextElement < JRDesignGraphicElement
	include JRBox
end

Writing the method drawBorder wouldn't be a problem either, because of 'duck typing'.
def drawBorder(design_element)
would be enough. As long as the type of design_element has the methods and properties we use in the method the world keeps turning.

I looked a bit around for mixin support in Java, and the closest I could find was the rapt project. I implemented the same domain model using rapt, but the code became so ugly I didn't even compile it (you have to compile with apt, not with javac which would also require some java command line skills which are somewhere in the back of my skull beneath a deep layer of IDE-using brain cells).

Some thoughts I had after attending a presentation on Team System…

Benefits of Team System (besides the functional ones)

The fact that this is a product from Microsoft and not from the open source community means that the barrier to use unit testing, continuus build etc will be a lot lower than it is now for some companies. While using open source products in a Java project is almost a sine qua non, there still seems to be a bit of a distrust against open source in some .NET projects. (relatively speaking, compared to Java projects)

This also means, trusting the gigantic marketing machine that is Microsoft, that Team System will probably reach a lot more (MS) developers than the agile community has been able to so far. Because don’t be mistaken, there are still a lot of people out there who haven’t even heard of the concept ‘agile’, or of unit testing, testdriven development, or even of an issue management system (certainly not only MS developers!).

Everybody will be Agile!

So that would seem like a good thing right? More and more developers/project managers/testers/... are being exposed to agile practices, isn’t that what we want? Well…not exactly.

Practices serve a goal, and the same practice may not always be appropriate in every situation to achieve that goal. If you don’t know or understand the goal of the practices you are following, you may be in for an unpleasant surprise somewhere along the road.

What about MSF for Agile?

In this article by Randy Miller, he explains that MSF for Agile is actually an implementation of the agile philosophy (the agile manifesto), adapted to specific circumstances experienced over the years by Microsoft teams where the classical implementations of Agile were deemed unsufficient.

It [MSF for Agile] also presents alternative practices to those commonly found in many agile processes.

For example, while Microsoft recognizes that having an on-site customer is a key factor for a successful project, they also know that this isn’t always possible, and offer personas (invented by Alan Cooper) as an alternative.

MSF for Agile provides you with a lot of guidance and building blocks, all beautifully integrated with Team System, but it doesn’t provide detailed instructions on how to handle day-to-day stuff like SCRUM does for example. You still have a lot of freedom to determine how the project will be run, and that’s where a good understanding of agile is needed. Using MSF for Agile won’t magically make you agile.

The danger

I think there is a danger that people who have no previous knowledge about agile will start equalizing ‘Agile’ and ‘Team System’. I’ve already seen this happening on a team using a custom build Team System-like product, where project managers were way too rigorous in following the practices laid out by the tools, forgetting (or not even knowing) why the practices were there in the first place, effectively crippling productivity and quality.

What can you do to avoid this?

Start learning Agile. Read about MSF for Agile. I have the feeling that Team System gets most of the attention, but in fact you can’t view at Team System without looking at MSF too. They are intended to be one system.

• There is a list with good books on the Systems Thinking wiki where you can start reading.
• If you live in Belgium you can start attending the XP BE user Group Meetings, I’m sure there are similar user groups in your neighborhood.
• Read blogs.
• Doing a project with someone who knows agile won’t hurt either, but may be a bit more difficult to arrange.

I think I’m one of the earliest adopters of Firefox around. It happened quite by coincidence, just on the day I switched to using Linux, Mozilla released Phoenix 0.1. I was looking for what browsers were available on Linux, and stumbled upon Phoenix. Back then I fell in love with it because of its small footprint, and simplicity (certainly compared to Mozilla). I’ve been using it ever since, going from Phoenix to Firebird, and finally from Firebird to Firefox. I’m singlehandedly responsible for dozens of people switching from IE to Firefox, so it is rather ironic that now I’m switching back to IE (on my Dell box at work, at home I am a Safari loving guy).

The reason is Firefox’s memory usage. Last week I spent half a day debugging an application that failed to insert some records through its JDO layer because it didn’t have enough memory. Okay, granted, JDO (Kodo) shouldn’t fail silently in this case, but still, it was very frustrating. And maybe it didn’t have any relation to my memory at all, but it did make me discover how much memory Firefox actually consumes. >200Mb memory usage for a browser isn’t something I’d call a feature. (the Firefox developers respond to the reactions on the memory usage of Firefox 1.5) I did change the max_total_viewers setting, and I realize that the excessive memory usage may be caused by one of the extensions I use (GMail reportedly also causes a memory leak in it’s use of XmlHttpRequest, although they deny it), but still it annoys me.

So the last few days I’ve been happily browsing along using Avant Browser It has popup blocking, tabs support, and it includes SessionSaver -like capabilities. All that I need (for my non web developing needs)! Goodbye Firefox, maybe I’ll see you again on a browser reunion party or something.

(the default install does like look shit though, you’ll have to tweak it a bit to look a bit decent if you decide to give it a go)