Dynamic Typing

Nice little entry over at the Martin Fowler blog on Dynamic Typing. The last three paragraphs I found particularly interesting and part of the reason I still want to learn and use Lisp on a more regular basis.

I am a bit amazed that the XP community and the Lisp community aren't more closely associated. Maybe because XP has come out of the land of Smalltalk? When I started looking at Lisp, I really started getting the feeling that Lisp and XP have a lot of ideals in common...

When is a SAX Parser not a SAX Parser?

I was talking to someone about ANT the other day and we got onto it bad points, to which, being written in XML came up. This lead me to think about how you could rewrite ANT to not use XML, as a simple solution.

After a quick bit of investigation, I realized that ANT uses SAX for parsing the build.xml file. SAX is just a set of interfaces that a parser must use in the parsing of XML, but there is no requirement that what it is parsing is XML (from a technical point of view). So, why not write a parser that can respond in an intelligent way to the interfaces while parsing something else?

After a day's worth of work, I now have a naive parser that parses something that isn't XML. The easy part was writing the parser, thanks to JavaCC. The language at the moment just uses identifiers for tag names followed by identifiers and string literals for tag attributes and either a body or a semicolon. Bodies start with { and end with } and can include more tags recursively. I'm also toying with the idea of using a lisp list syntax. Just for fun...

The hard part for me was setting up the ANT build to build the parser. And I ended up working on Linux with emacs, which was a nice change, though I missed some of the features of Eclipse. After this, I translated the build.xml file into a file in the new language. The parser successfully parses this new file, though the parser has no actions associated with it. So basically, I can just confirm that a file is in the proper syntax.

The really hard part is getting my head around JAXP and how ANT gets a parse from it. I've got the bare bone basics started, but I ran out of time. I'm hopeful that given another day or two, I'll have a naive SAX parser that will allow me to use something other than XML to define ANT builds. I'm tentatively calling this project Clarinet. 8)

After this is successful, I can then fine tune the parser to be specific for ANT and lose some of the XML generality. There's no guarantee that I'll get this far or even take another step beyond where I currently am, but I haven't had a good excuse to play with JavaCC in a long time and I am enjoying myself...

And all this takes me back to when I tried building a tool that would allow the definition of GUI with XML files. That is, an application that would dynamically produce GUI's from definition at run time. Now I'm thinking that I might be better served to scrap the XML from the whole idea and just do it with JavaCC. So many things to do and so little time.

Cobertura bug

The distribution of Cobertura had a bug in it that rendered the jar useless. Basically, the Javancss library is not specified in the class path of the manifest. I'm betting that it was copied straight from JCoverage and assumed to work. It does up to the point where reports are generated.

After a bit of poking about, I've managed to update the manifest file to include javancss.jar and everything works.

Now, can someone tell me why must the last line of a manifest file must end with a new line?!?

What good is a coverage tool?

Don't get me wrong, I think a coverage tools gives valuable feedback. But it occurred to me yesterday that you could have a coverage tool reporting 100% when in fact, the true coverage is 0%! That is, you have unit tests that "exercise" ever line of code, but make absolutely no assertions.

It's an extreme example, but it then flags that it is possible to exercise code without making an assertion against the change it creates. Which then leads me to thinking about developers working independently writing tests and checking in code. Therefore, another reason to pair (though it doesn't guarantee that some code will not be "asserted").

Conclusion: coverage tools are good for feedback, but I don't think they should be treated as an end in themselves. They could be lying...

Red Bar, Green Bar, Red Bar, Green Bar, ...

Unit testing is so satisfying! I wanted to say that it was more satisfying than refactoring, but then that is wrong. Not that I didn't feel that it was, but wrong in the sense that it is the wrong way to be looking at the practice, i.e. in isolation.

The satisfaction comes, I feel, more from the craftsmanship that I am experiencing, then the joy in a practice. I really am not sure how to describe what I'm seeing, but the practices are acting as guidelines to help me to realize the craftsmanship that can be found in software development. But then I seem to be digressing a bit from what I wanted to record...

I'm wondering now why I had any resistance to start unit testing my legacy code. Note to future self - when in doubt, do it anyway and look at the feedback and only then decide the course of action to take.

Anyway, I've got testing happening. Lots of red bars followed by green bars. Immediate and positive feedback. But I've got legacy code that already "works", so how come the red bars? I've been purposefully writing failing tests. For example, a method should return false, therefore my first assertion is that it is true. Red bar. Ok, now I think that I've tested what I meant to test. Change the assertion to be what I thought it should be. Green bar. Now I have the confidence that what I thought was testing is now automated. So I've been writing tests, but writing failing tests first, which is normal for TDD. But I'm not changing my code base yet.

During this, I felt the need to expand on what I was doing. So, next step is an Ant script for build and testing. Then installing and set up Cobertura for coverage feedback. Finally, set up CruiseControl for automated builds. I suspect that most of this isn't something that I'm going to want to do after hours. Hence, I need a free weekend, which I may not have for a while. Once I do, though, I plan on moving forward.