Sequence diagrams without wasting time in Visio

Just stumbled across websequencediagrams.com which lets you create UML sequence diagrams online without having to fire up Visio or your UML editor of choice. Not only that, but you actually generate them from text (it always seems that I end up wasting time fighting tools for these diagrams).

For example, here's the diagram created by this text:

   User->A: DoWork
  activate A
  A->B: <>
  activate B
  B->C: DoWork
   activate C
  C-->B: WorkDone
  destroy C
  B-->A: RequestCreated
  deactivate B
   A->User: Done

Pretty nice, and well worth checking out, especially if all you want is a quick diagram without wasting a lot of time.

Adventures in classpath scanning...

On a recent project I've run across a number of scenarios where I wanted to generically apply some logic across a large number of classes. Previously, I've done things like using Ant for this or used find and grep to create an input file with a list of matches and then writing code that read that file.

But what I really wanted was something much simpler that could easily be used in Java code without a lot of gymnastics. And Spring's ClassPathBeanDefinitionParser had almost everything I wanted, except that it was written specifically to generate Spring bean definitions and didn't expose the internal features that I wanted to use.

So I looked at the ClassPathBeanDefinitionParser source and wrote ClassPathScanner.java
(NOTE: It uses numerous Spring classes internally, so it requires Spring.)

It's a crude start, but the basic idea is there. And the results have been suprisingly easy to work with. For example, if you want to write a generic JUnit test that runs all of your tests:

public class AllTestsRecursively extends TestCase {
public static TestSuite suite() throws Exception {
    TestSuite suite = new TestSuite();
    ClassPathScanner scanner = new ClassPathScanner()
        .basePackage(AllTestsRecursively.class.getPackage().getName())
        .assignableFrom(TestCase.class)
        .includeFilter(".*Test");
    for (Class testClass : scanner.findClasses()) {
        suite.addTestSuite(testClass);
    }
    return suite;
}
}

Not rocket science, but it makes it pretty easy to write a lot of generic code. For example, you could use it to write tests that assert characteristics that might otherwise require aspects to enforce.

Or you could use it to dynamically generate Spring beans in ways not directly supported by ClassPathBeanDefintionScanner (e.g. you could search all of your services and create CXF bean definitions for all services that have the @WebService annotation).

I was surprised that something like this hadn't already been implemented in one of the Apache commons projects (or maybe it has and I just couldn't find it). But it seems like something that could be genuinely useful in many different scenarios.

Struts 1 Plugin for Grails

This one is hitting all of the Grails lists, but it's worth repeating. A Struts 1 plugin for Grails was just released.

Not only can you use this plugin to migrate your legacy Struts 1.x application by copying your config xml files, java files, and jsps into a Grails app. But you can also have your struts 1 actions use GSPs for rendering or even write your controller login in Grails controllers.

This is a shining example of how Grails' (and Groovy's) peaceful co-existence with Java can pay huge dividends.

So if you're stuck with a Struts 1.x app and desperately seeking a way to modernize your architecture, check it out yesterday.

Make sure you have GUTs

There was a pretty good article on InfoQ today titled: "Cockburn on Testing: Real Programmers have GUTs". Basically, it talks about how TDD is just one way to achieve the more important goal, which is Good Unit Tests, aka GUTs.

Alistair Cockburn continues to be one of my favorite of the "methodologists" in that he's one of the few to actually recognize and stress that people are first order components in software development. Because you can push process til the cows come home, and some processes certainly are better than others, but at the end of the day it's the people that make software development projects successful.

And he hits the nail on the head once again with his GUTs observation. People pushing things like TDD, CDD, etc often just come across as methodology bigots trying to push their latest process du jour onto people. And they are losing sight of the bigger picture.

But GUTs is something much easier to agree on. Because GUTs are a measurable artifacts (e.g. using coverage tools), not a process. And at the end of the day, it really doesn't matter if your wrote your tests first, wrote them last, wrote them on a plane, or wrote them on a train. What matters is that if you have them, you can measure them, and they provide tangible benefits.

So I hope that the GUTs term achieves mindshare. If it does, it will make it easier to advocate GUTs in whatever process your company uses in whatever way makes sense for that process without having to fight the uphill battle of advocating an entirely new process. Translation, less time dealing with politics and FUD and more time spent actually getting things done.

P.S. If you are struggling to find a way to emphasize the importance of tests, I highly recommend a tool that can generate a "treemap" showing your test coverage (e.g. Panopticode). Because it's an amazingly concise, visual way to convey coverage.All black is bad. All green is good. Put a picture in your project's weekly status report to convey where you're at.