Check out the latest Concern Map screenshot, notice anything different?

The big news is... rounded corners! This alone warrants a version number. More importantly, I added 10 new "query shortcuts" to the existing query mechanisms which bind diagram elements to source code artefacts. These are:

These are aimed at supporting the more code-centric of the key scenarios for the tool: capturing cross-cutting concerns, consolidating program logic, correlating code and pattern roles, and correlating code and architecture

Under the covers, these shortcuts back onto the existing XPath and XQuery mechanisms I've built for querying source code, but insulate the user, getting rid of a lot of the knowledge required (and tedium). There is still some work to do - it would be nice to optionally allow type names for GetsField, SetsField, CallsMethod (e.g. CallsMethod [type name, method name]), and I'm yet to bring interfaces and structs into this properly. Nonetheless, it beats typing in long XQueries.

"I wonder what sort of off-the-cuff comments you made when someone presented a theory that you found implausible or not cohesive."

XML is a hot topic at the moment: W3C Technical Plenary: The Future of XML, Faster XML ahead? (CNET)

As an end user, I've got a slightly different take on binary XML. Infoset has always felt a little odd to me - on one hand, it adds some respectability to the XML data model, but it also opens up the possibility of other representations. This is a dead end, because it discounts the reason that XML has been wildly successful. It's a lot more than the data model. It's the simple, plain text format that anyone can write a parser for, eyeball, hand-craft and understand. This means that when I have to interoperate with someone using different technology and tools, in a different location and different company, XML is a great lowest common denominator. This goes beyond technical loose coupling - it's more like loose coupling of people and capabilities.

If the focus is shifting to XML on mobile devices and the need for speedier XML in embedded apps (cnet examples), the discussion is really about a whole new thing - use within a more controlled domain, with much less emphasis on the lowest common denominator advantages. Do we need a standard for this?

Keith Short puts together a neat case in his elevator speech for software factories. The pitch makes me wonder about the audience for this stuff - who needs to know what, and when? I think there are a few important groups and two different paths that software factories will take:

• Horizontals start appearing in Visual Studio
• Verticals get momentum through bottom-up, covert adoption

Horizontals
Horizontal domains will increasingly be managed through DSLs and mapped onto component infrastructure. This is happening right now in Whidbey with web services and DSI, and I think these will be massive hits and could be a 10x factor for some development shops. To the extent that a Microsoft or whoever makes these tools a painless extension of the programming environment, they should be adopted as a matter of course.

Verticals
Vertical domains will take longer, and I think they will be suprisingly developer lead rather than architect lead, at least initially. Where companies already have generative or domain-analysis approaches in place the shift will be relatively easy and driven by the architects who own these tools and processes. But who actually has this kind of stuff? Let's face it, most of us are living hand to mouth and are glad to be reusing System.String between teams.

Without much of an architectural legacy to build into a software factory, the DSL tools will initially get picked up by senior devs trying to model/automate relatively simple domains and promulgate to a very small audience. Only after this stuff is built and proven will architects begin aggregating and refining the results into something to fit the vertical domain and the company.

So we really need three elevator stories, for the three different sales - firstly, the senior programmer or architect who is going to steal some time to play with the DSL tools and create mini-factories ("i need a little language right now"), secondly the architect who needs to take the outputs from this and combine them into something for the enterprise six months later ("it looks like powerpoint, which is comforting"), and thirdly the big wheel who will hear about it once it is all done.

My associate supervisor Prof. John Gough puts in some kind words for managed code on Channel 9: CLR Compiler Geek Roundtable. Note the deft plug for his book

The "long tail" meme gets around, but this post is worth reading: Of Searches and Psychics: The Costs of Long Tail Businesses.

Lastly - check out Eric Schmidt's lecture at Stanford GSB, if only for the early days photos and questionable hardware.

Spent the weekend troubleshooting my installer, which is finally done. I came within a whisker of not requiring the DSL tools on the target machine, but my diagrams would not layout correctly without them installed. In writing up the user guide I noticed that I didn't support queries against custom attributes on methods, so I added it.

It is now possible to write something like:
//method//attributes/attribute[@type='Foo']

I'm now trying to catch up on reading - RSS, books, magazines - which hasn't happened over the last two weeks. First stop: Appel's Modern Compiler Implementation in ML.