Unfortunately I missed JAOO this year which was a shame as Intentional are starting to talk about the work they've been doing with CapGemini in the Pensions space.

I know it's old news, but I just got a chance to watch Charles Simonyi discussing the Intentional language workbench and it's really interesting for anyone interested in the future of working with DSLs.

After a *lot* of prevarication, we've finally made the business decision to open source our LightBase framework. There is a lot of clean up work to do over the next couple of months, but I'd imagine we'll be releasing the project at either Scotch or CF United.

It's going to be an interesting year . . .

I've always been impressed by the team at Metacase. They have already come up with solutions to problems like statement evolution in DSLs and inter-related Domain Specific Languages that are only starting to be seriously considered in the wider code generation/domain specific modeling community.

They have been developing solutions for 100% code generation for over ten years in a wide range of domains and they have just released a new version of their flagship product today - MetaEdit+.

I have not had a chance to play with the latest product, but it's something I am going to make the time to do this weekend. If I was ever to give up my homegrown system for commercial tooling, MetaCase is the company I'd very probably go with.

If you have any interest in the possibilities of code generation, I'd thorough recommend checking out MetaCase's website. If nothing else, it's a great example of what can be done in terms of 100% code generation.

And in case it isn't clear, I don't get paid for referrals/etc. I just think that they are *that* good. MetaEdit+ may or may not meet your use case, but it's definitelty worth checking out as an example of what can be done - even if you don't use it for your projects.

Here's the information on the latest release.

One of the interesting challenges when you have a software product line is determining how best to market the solutions you provide. A SPL is neither a product nor is it completely custom code, and while it can be hugely beneficial to both the developing company and their clients, the marketing of such solutions is a bit of a tightrope.

[More]

You've just built an e-commerce application. The client comes back asking for some changes. They've decided that despite all of their protestations to the contrary in the design phase, products actually must be associated to multiple categories, not just one. This is when traditional development starts to suck . . .

[More]

If you can't make CFUnited Europe or just want to have an idea of what I'll be talking about, I'll be previewing the talk online this Thursday at 6pm EST.

If you get a chance, you might also want to tune in earlier in the day to hear what Kevin has to say about the work he's done on the Fusebox Scaffolding. That's at noon EST which is 4am Sydney time, so I'm going to have to catch the recording, but it looks like being interesting stuff.

Many thanks to Charlie Arehart for all his hard work in putting this together.

I've been getting more involved recently with the XP and test driven development lists. One thread that has come up is the appropriateness of unit and integration tests within a software product line. That lead to the following exchange which raises the question: "when does configuration become programming"?

[More]

You're building web applications. You want to simplify and de-skill as much of the work as possible so a programmer is only required for the code that is absolutely unique to a specific project. Describing screens, actions, business object, relationships, properties, validations, value lists and the like shouldn't require someone with a degree in computer science. The question is, what kind of interface do you provide for entering such data and how do you store it? This is a problem I struggle with time and time again as I keep trying different approaches each of which has relative strengths and weaknesses . . .

[More]

I realized while writing a recent article why I seem to obsess over potential variabilities that most developers don't worry about. It is the difference between creating a software product line designed to create hundreds or thousands of web applications over a number of years and architecting an individual application and it's an important distinction to understand for anyone interested in improving the efficiency of their software development processes . . .

[More]

In the first part of this series I looked at how we could describe simple forms more concisely and DRYly. In the second part I came up with some small syntactic wins, but really nothing to justify the approach. I'm hoping to strike paydirt (or strike out and move on) in this third posting which looks at encoding intent of rich fields and client side validations . . .

[More]