I love to solve problems with computers. I've been doing it since I was 7, and aside from a brief flirtation with pursuing a music and choral major, I knew precisely from that moment that creating software would be my career. About five years ago, I was between jobs and intended to write a database-driven web application that would track basic information about an application's life cycle (requirements, tasks, features, bugs, etc.). I was writing the project for SQL Server 2005 and .NET, and using a solid wall of stored procedures for any access to the database was a tenent to my architectural philosophy. Realizing that this was:

a) A lot of work, and
b) Heavily redundant work, that could be derived entirely from the data model

I decided instead to focus my efforts on writing a C# WinForms application (which I was fairly new to) to take an XML file (called "Source") that described a logical model (objects, properties, relationships, inheritance), and used a another XML file (call a "Config") to apply XSL Transforms against different queries against the Source, and create one or more files in different folders. This became the first iteration of Lazarus, and let me very quickly get solid tables, views and stored procedures. However, it wasn't much more than a rules-based XSLT processor. And using XPath to navigate inheritance hierarchies was painful, at best, and resulted in very unreadable templates, and tons of work to make small improvements to the generated code.

Lazarus 2 was borne out of this effort, adding a second, heavily denormalized model (called "Compiled"), and a Compiler object that would turn Source into Compiled. This made the Transforms far easier to work with, but the Compiler itself was a giant mass of C# XML code and XPath strings. Transformations were then added that created detail and collection classes, that understood how to load and save themselves as XML. Two new "Source" projects were created, one to manage the structure of the "Compiled" model, and the other to manage "Source" itself. It was at that point that Lazarus began to play a significant role in improving itself. Lazarus 3's Compiler was built against the Object Model, rather than the XML file, which vastly improved the readability, and the ability to extend the compilation process. Lazarus 4 added more robust transformation code, a switch to control the inheritance behavior in the database, an improved API to further reduce redundancy in the Compiler logic, signficantly improved error messaging, and an improved UI.

Looking forward, Lazarus will be implemented as a Domain-Specific Language project in Visual Studio, which will allow Source and Config objects to be added and modified entirely though a designer experience. It will maintain support for the current Config and Transform capabilities, though they would be implemented as MSBuild tasks. The current Windows Application would instead be implemented as a Visual Studio extensibility solution. There are many possibilities at this point, in terms of real-time generation/updating, semantic understanding of code logic to enable more adaptive self-improvement, and abstracting the Compiler process itself into an XML-driven task (and therefore also modelled).

Last edited Jan 11, 2008 at 9:16 PM by JoeMu, version 2

Comments

No comments yet.