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]

In the first part of this series I looked at how we could describe simple forms more concisely and DRYly. I'm not convinced that I made the case that a generator would be "the simplest thing that would work" - it all really comes down to how likely you would be to need to refactor your form markup during a project. Still, in this posting I want to look at some of the additional types of information required to describe a form to see if I end up with sufficient benefits to make it worthwhile to write a simple form generator that'll take XML or method calls and generate the appropriate HTML . . .

[More]

I find that I keep returning to the simplest elements of building web applications, continually asking how we can make our code more concisely express intent. All other things being equal, less characters = less code to review, less cognitive load leading to quicker development times and simpler maintenance (excluding the time for developing and learning the tighter syntax). There is no question that you can go too far with terseness. A quick skim of most Perl programs proves that conciseness doesn't equal maintainability, but in web development it seems to me that there are areas where we are still repetitive and where a DRYer representation of intent would be ideal. One example of this might be forms . . .

[More]

As you start getting into using Domain Specific Languages, one of the biggest issues is how to handle legacy statements in your DSL as your grammar evolves . . .

I'm actually presenting a paper at the DSM Workshop at OOPSLA on our approach to solving the problem (categorizing different types of grammar transformations to allow for the automatic transformation of statements within the language). However, I just saw a really nice posting on how MetaEdit+ handles this. Well worth checking out the video to get an idea of how powerful the system is. Very cool stuff!

Code Generation, Software Product Lines, Domain Specific Languages - they really can have a huge impact on developer productivity, improving the speed of development, reducing the cost of maintenance and improving the overall quality of code. But how do you get started? . . .

[More]

I was just thinking about how Rails does db schema migrations and how I generate my db schemas from a collection of XML object models and I realized that a fusion of the two approaches would allow for some pretty cool automated refactoring of code, schemas and data . . .

[More]

If you only build three or four applications a year and use a framework like Mach-II or Model-Glue with a 6-24 month release cycle, framework versioning is annoying, but not a major pain point. When you plan to generate 1,000+ custom applications a year using a framework with a monthly upgrade cycle, a different approach is required . . .

[More]