I recently read The Art of Agile Development by James Shore and Shane Warden and thought I should write up a brief review here.  Full disclosure: I participated in review draft chapters of the book as it was being written, and as a way of saying thanks, I received a courtesy copy of the book.

As I understand it, the book began its life as an updated, second edition of Warden's (a.k.a. chromatic) Extreme Programming Pocket Guide, but quickly grew in scope to become its own book.

There are many variations on agile development these days, and even variations on the Extreme Programming (XP )practices.  The authors cut through all of that to choose a good, solid set of practices and present them as a way to get started with agile development that will work well enough to get to the point where you can start to learn and adapt on your own.

After presenting the case for agile development in Part I, the authors move into the meat of the book in Part II, where they present the various practices.  For each practice, the authors explain the practice and how to do it, answer common questions about the practice, discuss the expected results of following the practice, and then discuss "Contraindications" - things that might be true in your situation that may make it difficult or impossible to introduce the practice.  Often, they present alternative practices to work around these cases.  Part III of the book is for the more experience agile development team.  Once you've gotten good at the practices, you need to start learning and adapting to make agile development really work for you.  Part III gets people started down that road.

While I don't agree with the authors on every point, I found the book very good overall.  It gives an excellent introduction to the current wisdom of the agile development community, and there are lots of ideas to consider and think about here.  I recommend it for any team that is doing, or thinking about doing, agile development.

I've had two presentations accepted to Smalltalk Solutions 2008.  One is a short technical talk entitled "Automating Smalltalk Builds with CruiseControl".  The other is a tutorial called "Acceptance Testing with Fit". 

This latter tutorial is a follow-on from a short talk I did at Smalltalk Solutions 2006 introducing Fit and Fitnesse.  The tutorial will go into more detail about how to actually use these tools in a Smalltalk environment.

I don't have any scheduling infomration for these talks yet, but I hope to see you there.

Cruisecontrol 2.7.2 was released this week.  Why do I care?  This version contains the patch I submitted to make Cruisecontrol able to monitor VisualWorks Store repositories for changes as part of an automated build.  See my previous posts on the subject for more information.

I've been using the NewPrerequisiteEngine for a long time.  Over the years, various people have enhanced it to the point where it's a pretty decent tool.  It still has some holes: there are prerequisites it should pick up and doesn't, and there are others it picks up but shouldn't.

For example, the package SymbolValue defines the method #value: on Symbol.  There is really no way for the NPE to pick this up, and yet if I take advantage of it, I have a dependency.  If a class definition has been overridden in some package, then the NPE thinks that anything using that class now depends on the overriding package.  That may or may not be true.

Travis, Michael, David,and James were discussing this on the last Industry Misinterpretations podcast.  I believe Michael made the comment that it would be nice to be able to give the tool some extra information to handle the cases where it falls down.

I've been working through our code base trying to clean up the pre-requisites.  We often don't re-compute them because the tool will mess things up on us.  I was tired of fighting with that, and Michael's comment turned the light on in my head.

I just replicated some new versions of the NewPrerequisiteEngine up to the public repository.  The latest version is the 7.6 branch moved onto the head, plus a couple of other changes.  The 7.6 branch should continue to run in 7.5; it just removes a menu option that has been integrated into the base in 7.6.

The minor change is that I put the engine classes into their own namespace so that they could be loaded into an image without the RB. 

The more major change is that you can now right-click on one or more entries in the prerequisite list (in the pre-req tool) and choose either "Ignore" or "Make Explicit". 

If you Ignore pre-reqs, they will be removed from the list and will also be added to a property on the package so that the NewPrerequisiteEngine will no longer include those pre-reqs when it performs its computation.

If you choose Make Explicit, the pre-reqs will be added to a property on the package so that the NewPrerequisiteEngine will always include them as pre-reqs.  The Why? menu will also report them as explicit pre-requisites.

Using these tools, I was able to clean up all of our spurious pre-requisite problems, and I'm now more comfortable trusting the NewPrerequisiteEngine.

I just published a new version of RBPrerequisiteGraph to the public repository.  This version highlights the node for the current package, and displays nodes for any packages that depend on the current package.

I chose not to show any links for those parent packages other than the link to the selected package, because in many cases, it just over-clutters the graph.

Thanks for the suggestion, Runar.

I've been doing some work lately on cleaning up prerequisites in our code base. As I was working on this, I thought that having a visual view of a prerequisite graph might be nice. I had a bit of free time, so I built a new CodeTool for the RefactoringBrowser (7.6 and later only) that shows a prerequisite graph for the current package.

Here's a basic view of a moderately complex graph:

And here's the same graph after I temporarily added a fake dependency from HashesBase to HTTP (to create a dependency cycle):

I didn't spend a lot of time on graph layout, but what's there isn't too bad. It is designed in such a way that dependencies flow left-to-right unless there is a cycle. Obviously, some dependency chains are going to be a mass of spaghetti.

Try it out and let me know what you think.

I was interviewed for the latest Industry MIsinterpretations podcast, where we talked about how we use Smalltalk at Key Technology (where I work). We talked mostly about our automated builds and the CruiseControl interface to VW Smalltalk that I've written about before. We also touched on Fit and Fitnesse, which I haven't written about here yet, but will at some point in the future.

See James' blog for the link to the audio.

Now I have to go listen to myself to see what I said :-).  Thanks to James, Michael, and David for having me on. 

Since I first talked about it, I've been using my test auto-runner a fair bit.  I thought it would get annoying very quickly, and it turns out I've really been liking it.  However, the first version I published had a minor problem and an annoying limitation.

The problem was that it would always run, even if you got an interactive compiler error warning dialog and canceled it.  The annoyance was that it wouldn't run after a refactoring.

I built a new version that solved these two limitations, however, it also had a bug.  Because of where I hooked into the acceptance of a new method, the wrong test would be run when I edited an existing test method to create a new test method.

I finally gave in and did a version of the auto-runner that uses an override to do the job right.  Now, the test auto-runner will run the correct test(s) after you save a method, or when you do a method-level refactoring (anything accessible from the context menu in the code editor).  It also runs when you change a class definition.  I haven't tested this, but it should also work with Travis' new string editor.

Once again, this only works in the 7.6 pre-release versions of VW; it doesn't work with 7.5 or earlier   To try it out, load SUnitToo(ls)-AutoRun from the public repository.

When bringing forward our code base to the not-yet-released VW 7.6, we discovered that our UI translations were no longer working.  We use SimpleMessageCatalog from ExtraCatalogs to handle our translations.

It turns out that a new abstraction, MessageCatalogManager, was introduced for 7.6.  7.6 adds the ability to have per-process locales and message catalogs, and MessageCatalogManager is part of that solution.  What it means for ExtraCatalogs, though, is that UserMessage lookup no longer goes through the class side of MessageCatalog and its subclasses.

I have published a 7.6-specific version of ExtraCatalogs to the public repository that works with MessageCatalogManager.  It also uses the now-built-in implementation of per-process locales (it had its own implementation before that).  This implementation will work with the jan08.2 build and later; prior builds didn't have all of the hooks necessary to make it work.

Thanks to Martin Kobetic and Steve Dahl for getting in some late-breaking changes to MessageCatalogManger to make this possible.