OpenSymphony.com gets a facelift
OpenSymphony.com is looking nicer these days.
Joe Walnes
Software development. And stuff.
Archive for the ‘ Software ’ Category
Discuss your maintainability patterns
If you’re anywhere near London on Tuesday 29th July, come along to the eXtreme Tuesday Club (XTC) and we can talk about the coding and design practices that make for maintainable code in the long term.
This is how we’ll do it. Prepare in advance.
Meanwhile, I’ve seen some excellent feedback on what makes for good maintainable code. There is a central overlap of core techniques that developers who have to maintain code in the long term have grown to adopted. And yet, even knowing these things work, they often slip our minds.
Design by contract: testing implementations of interfaces
Here’s a nice way of associating contracts with interfaces and testing the implementations conform.
A sample interface:
interface CheeseMaker {
int getCheeseCount();
void addCheese(Cheese cheese);
}
With the contracts:
* there should be zero cheeses on creation.
* adding a cheese should increment the count.
* unless the cheese is a duplicate.
* when adding a cheese, the cheese cannot be null.
You can create an abstract unit test for this interface that tests these contracts. The only thing it doesn’t do is provide an implementation – instead it has an abstract factory method.
public abstract class CheeseMakerTest extends TestCase {
// abstract factory method
protected abstract CheeseMaker createCheeseMaker();
public void testZeroCheesesOnCreation() {
CheeseMaker cheeseMaker = createCheeseMaker();
assertEquals(0, cheeseMaker.getCheeseCount());
}
public void testAddingACheeseIncrementsCount() {
CheeseMaker cheeseMaker = createCheeseMaker();
cheeseMaker.addCheese(new Cheese("Cheddar"));
cheeseMaker.addCheese(new Cheese("Wensleydale"));
assertEquals(2, cheeseMaker.getCheeseCount());
}
public void testDuplicateCheesesDoNotIncrementCount() {
CheeseMaker cheeseMaker = createCheeseMaker();
cheeseMaker.addCheese(new Cheese("Cheddar"));
cheeseMaker.addCheese(new Cheese("Cheddar"));
assertEquals(1, cheeseMaker.getCheeseCount());
}
public void testNullCheeseCausesIllegalArgumentException() {
CheeseMaker cheeseMaker = createCheeseMaker();
try {
cheeseMaker.addCheese(null);
fail("expected exception");
} catch (IllegalArgumentException e) {} // good
}
}
Now, every time you create an implementation of CheeseMaker, the test should extend CheeseMakerTest and you inherit the contract tests for free.
For example:
public class BigCheeseMaker implements CheeseMaker {
// ... ommited for sanity
}
public class BigCheeseMakerTest extends CheeseMakerTest {
// factory method implementation
protected CheeseMaker createCheeseMaker() {
return new BigCheeseMaker();
}
// ... any additional tests go here
}
It’s important to note that this tests the contract but does not enforce them. It’s very flexible and there are very few contracts (if any at all) that couldn’t be expressed in a unit-test.
This helps defensive development with the added safety of unit-tests.
As a bonus, you can use TestDox to generate documentation for interfaces (much more useful than implementations), like so:
h4. CheeseMaker
* Zero cheeses on creation.
* Adding a cheese increments count.
* Duplicate cheeses do not increment count.
* Null cheese causes illegal argument exception.
Maintainability patterns
I love tech. Look at all the fun stuff that’s happening in this development wonderland at the moment.
We have libraries to do everything under the sun. Persistence, web-apps, security, code generation, presentation, remoting, messaging, concurrency, XML processing, testing, containers, you name it. In Java-land, opensource seems to be dominating the market and we’re even starting to see books dedicated to the subject (end of shameless plug).
It’s easy to get seduced by the sparkle of how these tools can make magic happen quickly. With these tools, a system can be delivered in record time. Win!
But delivery is really just a short term win. After delivery comes maintenance and this is where most development teams get stung in the long term. It becomes harder and harder to add or refine features as time goes on. Chris Matts pointed out that over the life of a project, the cost spent on development is insignificant compared to the cost of maintenance.
It’s impossible for a sexy library alone to make your code maintainable. Using JUnit or an AOP library will not solve the problems. It’s the *techniques* that complement these that make applications more maintainable. The tools are just the icing on the cake and you really don’t have to use them.
The techniques are unfortunately less seductive than the tools, yet far more important. I often find myself answerless when faced with explaining the benefits of separating the interface from the implementation, using mock objects, inversion of control, aspect oriented programming or avoiding statics.
In most cases, I found there is no benefit of using a technique in isolation. Instead, they benefit each other. It’s the relationship between the techniques that are important and they all support one thing – maintainability. The relationships are patterns.
So, I have a theme for upcoming posts on the blog: *maintainability patterns*. What techniques we can employ to make code more maintainable and how they relate to other techniques.
Agiledox
Chris Stevenson, fellow team-member, has started Agiledox, a small project to collect ideas and tools for automating documentation.
It is typical in agile projects that the code and design changes so quickly that the documentation (if any) never keeps up. We are using Agiledox on our current project to help give us all a high-level map of what the system does at all times.
When practicing *collective code ownership* it is vital that all developers know how the entire system works, not just _their_ bit (they have no bit). With bigger systems that are constantly evolving it is unlikely that any one person knows how it all works, so it’s nice to have a higher level roadmap of the system to look around before drilling into some code. Of course, this is no substitute for good communication – but it helps.
The first deliverabe in Agiledox is Testdox . It autogenerates documentation from testcases. Wow! How?
Simple. All it does is look at a test class and all the test method names and convert them from camal case Java names to sentences. Genius!
You may laugh, as I did. But I was amazed at what it produced for our project.
There’s a catch though. It worked for us because we are well disciplined in the way we write tests. For a start, we were already in the habit of writing test case method names that describe what a class should _do_ rather than what all the methods are. Don’t moan that this low emission petrol isn’t great when you’re trying to put it in a deisel engine.
Here’s a handful of docs generated for our project. Sweet huh?
h3. MenuModel
* View can be bound to a model
* Two views can be bound to one model
* Model contains menu text
* Model contains menu text after it is renamed
* View is populated from prepopulated model
* Model can be cleared
* Model can contain separatorh3. CsvTableModel
* Column definitions are read from first row
* Values can be read from rows
* Column definition values return underlying value
* Model can be reloaded
* Column can be marked as dateh3. NewOrderFinder
* Order with fills are returned
* Old orders and old fills are filtered out
* Old orders with new fills are not filtered out
* Assumed legs are filtered out
* Last check is maintained
* Spread components are grouped together
StaticMesh first cut
Rune Toalango Johannesen has created a first cut of StaticMesh – an offline version of SiteMesh for building static web-sites.
Like SiteMesh, it takes a plain HTML document (content) and an HTML decorator (presentation) to generate some pretty content as its output.
Unlike SiteMesh, it does not require a runtime Servlet engine to do this. It gets it content and decorators from files and outputs to more files.
You can run it as a standalone application, embed it in existing apps or use Ant to invoke it.
The Ant task usage is as simple as you’d expect:
Content pages are plain old HTML. Anything can generate these (even MS Word!).
Decorators are also plain HTML with lots of prettyness. SiteMesh parses the content pages, which are made available to the decorator using Velocity variables such as $title and $body. Velocity is very friendly and doesn’t confuse web-development tools such as DreamWeaver.
SiteMesh.NET in CVS
Jeremy Clymer has ported SiteMesh to .NET. And it works like a charm!
Here’s the feedback that I’ve had so far.
bq. “SiteMesh.NET rocks dude!”
bq. “I downloaded and it just worked.”
You can get it from “CVS”:http://sourceforge.net/cvs/?group_id=26435 if you can’t wait for a release. It’s already stable.
MockObjects Java 0.09
The latest release of the Mock Objects Java project is available. The dynamic mock generation API has been improved greatly and it now allows a lot more flexibility in setting up expectations and return values resulting in less brittle tests.
“Website”:http://www.mockobjects.com/
“Download”:http://sourceforge.net/projects/mockobjects/
NMock 1.0
After many months of little changes, we deemed NMock production quality. It stabilised quickly many months ago and has changed very little since.
Documentation is somewhat sparse – contributions welcome!
“http://nmock.truemesh.com/”:http://nmock.truemesh.com/
Blogging software
My last blog was powered by “Radio”:http://radio.userland.com. It was a great introduction to the blogging world.
Apart from being easy to use (single client download, no server setup necessary) it was a very elegant all in one blog poster and blog aggregator. Many bloggers I know still don’t use aggregators and miss out on the joys of inter blog communication. Blogging isn’t an excuse to stand on a box and shout loudly – it’s a two way thing (two ears, one mouth). If you’re blogging and not using an aggregator, please explore what you’re missing.
My new blog is powered by “MoveableType”:http://www.moveabletype.org/ and “SiteMesh”:http://www.opensymphony.com/sitemesh/ (“Mike’s”:http://blogs.atlassian.com/rebelutionary/ suggestion). MT powers the content and SiteMesh powers the presentation – orthogonal components at their best!
I am still experimenting with aggregators, but so far “Newz Crawler”:http://www.newzcrawler.com/ seems to be me favourite as it has an intuitive interface allowing me to (quickly!) read blogs, websites and newsgroups all in one place – even offline. Here you go, a “screenshot”:http://joe.truemesh.com/images/newzcrawler.gif.
So if I loved Radio so much and wanted its babies, why did I switch? Here’s the advantages the new setup has:
* Ability to post new entries from anywhere via a web-interface instead of a fat client sitting on one machine only.
* Decoupling the presentation from content allows me to add new content sources (static pages, forums, wikis, …) without having to duplicate the presentation.
* More control.
* Eating my own dogfood (SiteMesh).
Saying that I’d still recommend Radio to any blogging newbie.
Update Jan 2009: I’ve now switched to WordPress.com, so I don’t have to manage my own servers.
Recent Posts
Me, Elsewhere
- An error has occurred; the feed is probably down. Try again later.
Joe Walnes 
