It was a brisk Fall Sunday morning in Redmond as Katy waited for me on the patio of Victor's Coffee Company. I was inside ordering the lattes; hers a Black Forest, mine unflavored. Victor makes an awesome latte. Katy had the dogs, Elvis and Gracie, on leashes, and that wasn't going to work if she was to enjoy her warm beverage. So I clipped the two leashes together on the backside of a post on a patio rail. Now as one dog moved toward us, the other dog moved away. Slipping back into my chair I said, smugly, "A zero sum game."

"Aargh," Katy moaned, "I hate that phrase of yours. Where did you first hear it?"

"Johnny Von Neumann."

"And who's he?"

"Oh, just about the most important mathematician of this century. He's the one who first suggested computer programs as data... Oh, my gosh!"

"Now what?"

"That's where my preoccupation with getting programs back to being data came from!"

In spite of how it sounds, Katy and I really are happily married, mainly because over the years she's learned to put up with my idiosyncrasies. But the point of my little vignette is at the heart of my work. For most of my professional career I've treated programs like everybody else, as something that processes data. But for the last few years I've been obsessed with developing technology that helped me manage my programs the way I used my programs to manage my application data.

First came my experiments with using the Model-View-Controller design framework in web apps. Then Erik Fuller extended that work with the JSML and MVC.JSML frameworks. Then I extended MVC.JSML with the Model-Based Development Framework (where I include a High Level Petri simulator inside the application to control the program's behavior).

Now I'm getting totally jazzed about modeling with the Abstract State Machine Language (AsmL). More precisely, I'm exploring the possibility that I can create an equivalent schema-based HLPN from an AsmL model. I'll come back to this in the Lab Rats section in a future Confessions.

Anyway, all the way through this evolution, models are everywhere. These Confessions will be a history of the processes and pitfalls that get us all, especially those of us who aren't formally trained programmers, to writing code at a new level of quality.

One more thing before we dive into this month's Confessions. Last month I mentioned Grady Booch's interest in model-based development, so clearly I'm not the first person to use the phrase "model-based development" or "model-based programming" or even "model-oriented development". You can search the Internet for several other commentators who've used these appellations. And though I'll work very closely with Grady's technologies in these Confessions, from my reading, however, think I can safely say that I have a very different MBDF strategy than all the others. It begins with something I've been calling " Schema-Based Programming" (SBP).

SBP is the general rubric for any technology that is based on or uses, directly or indirectly, an XML schema, explicit or implicit. Now before I sound any more like a lawyer, let me describe briefly the three levels of SBP. At level one, XML is just another data format; this is XML outside the program. At level two, XML is a messaging medium; XML between programs. At level three, the schema is an API; XML is the program. To properly distinguish my approach to MBDF from others in the literature, I should refer to my work as SB-MBDF. But that seems over the top, so in this column, MBDF will suffice. Oh, and my MBDF uses SBP at all three levels.

As a consequence, the chief architectural difference between my approach and others is that, today, I don't need a separate modeling or simulation language (Design/CPN is an example of a separate HLPN modeling tool, and Simula is a language others in model-oriented development have used). I say "today" because with .NET the differences between languages blur and any given application can be built and debugged with as many Common Language Specification-compliant languages as you want. I'll come back to this point later when I get deep into AsmL.

So with that introduction out of the way, here's what I have planned for this Confessions. Since most of the content of this column for the next few months will be based on the MBDF and since the MBDF is based on the JSML and MVC.JSML frameworks (including the Model-View-Controller design framework) I mentioned last month, I thought it prudent to stick with the basics of the frameworks (covered in the Shop Talk section) and a tutorial of high level Petri nets (covered in the Lab Rats section).

As I've said before and will say again, this stuff is still very speculative technology and shouldn't be used in prime time unless you're extremely comfortable with it. We use it on my team at work, but then my team has one obvious advantage... it's my team.

News Desk

Last summer I was having one particular problem with some VBA code I wrote that used VB.NET to serialize Word XP as XML. I mentioned that by going to managed XML I got the process down from over ten minutes to just over 30 seconds. An old friend of mine, who now happens to be an editor at MSDN, asked me to write an article for MSDN Online about the program. I did, and Jean-Pierre just told me it's now online: Using Visual Basic .NET from VBA to Serialize Word Documents as XML.

Another friend, my old managed XML mentor, Chris Lovett, has already pointed out that one of my functions could be better written using a recursive descent strategy, so when I figure out what he means, I'll post the updated code here in Confessions.

Also, in a future Confessions I'll be discussing the Socrates program documented in my MSDN article because the specs written with Socrates are a model of software test (as opposed to a model of the application under test documented by the test spec). Just so I don't leave you scratching your head, a Socrates-compliant spec is a model of a test. A Socrates spec can also include a separate model of an application under test; e.g., an AsmL model. Again, we'll be talking a lot about AsmL in future Confessions.

Shop Talk

To get us off on the right foot for this column, I'm going to show you how to quickly install the JSML and MVC.JSML frameworks on your development machine. I'm also going to give you my interpretation of the Model-View-Controller design framework.

Installing JSML

Let's begin with JSML, a non-visual framework of base JScript classes that helps you develop ASP.NET applications that use object-oriented JScript classes, including classes for manipulating strings and XML. The framework generates consistent JScript code and includes built-in applications for automatically rendering application documentation using the JSML Class Browser (in other words, program docs come for free with JSML).

The first step is to download the Jsml.1.5.zip file from http://jsml.net/?WROXEMPTOKEN=383589ZPs16T7yc2PndLwWUF2W. The fastest way to get JSML up and running is to unzip the JSML distribution into your wwwroot folder. Take care with the /bin folder. Don't let it overwrite any existing wwwroot/bin folder you may have, and, just as importantly, don't forget to add the Jsml.net.dll file to an existing wwwroot/bin folder.

Later you can choose to make the JSML and MVC folders into their own web applications; and if you do, remember to copy the wwwroot/bin folder to the JSML folder and the MVC folder. Since JSML is written in C#, there are other twists if you need to add the files to an existing VB.NET solution. Those details are beyond the scope of this column, so email me if you need more information.

So, with the files copied to your dev box, it's time to run a test or two to see if all's in order. The fastest way to do this is run inetmgr.exe (mine's in C:\WINDOWS\system32\inetsrv\inetmgr.exe). Drill down into the Default Web Site and open the jsml/1.5/examples folder.

Right-click on the loader.aspx file and select Browse from the context menu. Click the "load it!" button on the resulting web page and you should see this:

Incidentally, this test not only ensures JSML is properly installed; it also gives you an example of the kind of JScript that's generated by JSML every time the JSML classes are run on the client. I strongly encourage you to study this JScript output because your programs will rely on it. If your static code analysis finds any bugs or you have any suggestions, please contact me immediately.

If you give the loader.aspx file any JSML file name you will see the JScript that the Jsml-processor.xslt generates from the specified JSML source code.

Another view of the JSML base classes is available with the JSML Class Browser. I'll come back to this in a minute since it's the MVC.JSML classes that are rendering the Class Browser application documentation.

Troubleshooting

Here are some tips in case you run into trouble.

A few weeks ago I rebuilt my laptop, and when I tried to run the JSML samples I kept seeing my aspx files open up in VS.NET instead of running. My old friend and team mate, Mark Ingalls, suggested I run aspnet_regiis.exe (mine's in the folder C:\WINDOWS\Microsoft.NET\Framework\v1.0.3705\). I did, and that did the trick. The KB I found on http://support.microsoft.com/?WROXEMPTOKEN=383589ZPs16T7yc2PndLwWUF2W noted that sometimes ASP.NET fails to register with a new install of VS.NET, and there's no known cause for this anomaly.

The most common problem, however, is forgetting to copy the Jsml.net.dll to the wwwroot\bin folder. If you forget you'll raise all kinds of runtime errors because your aspx files can't find the core JSML functionality that's in the dll.

Back to Basics

Ok, now that we have the base classes installed, tested, and debugged, it's on to the user interface.

But before I show you how to use the MVC.JSML classes, we need to be on the same sheet of music with respect to the underlying design framework upon which MVC.JSML is based, the Model-View-Controller design framework.

Understanding MVC

The MVC first appeared in the user interface for Smalltalk. In the last few years it's been getting more attention in the web development literature and provides the foundation for our own Web Service Faceplates book from Wrox. A UI built with the MVC framework partitions an application into (usually) one object for data called the Model (and sometimes, to distinguish from separate behavioral models, the MVC model is called a data model), one or more objects for Controllers, and one or more Views. Each View is responsible for rendering some data from the model and controllers mitigate between the user and the View. Most of the time we use controllers to interact with the model, as well. When the user does something to change the data (e.g. selects a headline from the SBPNews app that we'll see later) the controller changes the model and the model fires an event after the change is complete. Views register their interest in certain events, and when those events fire, the view goes back to the model for the latest value(s).

A key characteristic of the MVC is that views can be totally ignorant of any other view. Since the architecture is loosely coupled, views can come and go in the app without side effects due to interdependencies (a side effect that's common with non-MVC designs).

A second characteristic that's especially powerful in the MVC.JSML framework is that much of an MVC.JSML application is the relationships between these MVC components, and those relationships are basically the same across all instances of the MVC.JSML frameworks. For example, compare the output of the AppBrowser (using the AppBrowser sample, on my machine it's " C:\Inetpub\wwwroot\mvc\1.1\Examples\App Browser\index.aspx") with the output of the AppBrowser after it analyzed the HLPN Simulator (look in the Lab Rats section below for a screenshot). The language in both reports is the same; only the instance data is different.

In the MVC.JSML frameworks we've generalized the MVC architecture by adding an MVCManager object (see the content in the Class Browser image below). This singleton object (a super controller, really) mediates all events moving between all MVC components (model and views) and between multiple MVC objects in the application.

Now this is crucial to grasp if you want to appreciate the power and potential of the MVC.JSML framework: MVC under MVC.JSML is holarchical. That is, an MVC.JSML application is a holon (meaning something of intrinsic interest) that's composed of one or more clonons. If you drill into each holon you'll find that it's structured the same way its "parent" is. In other words you have an application that's based on MVC and is composed of sub applications that are also based on MVC.

For example, you can write a user program (MVC application) that can stand alone (the MVCManager is only mediating events fired between the program's model and controller/views); the SBPNews application is the canonical example. You can also use the HLPN simulator that ships with the MBDF to write an MVC program that models the user program. Now you have two independent MVC.JSML applications, two holons.

The presence of the MVCManager, however, enables these two holons, these two standalone MVC.JSML applications each to become clonons in a super program where both the user program and its model are running side-by-side, blissfully (virtually) unaware of each others' existence (as any two views in a single MVC application are unaware of each others' existence). The user, equally oblivious, thinks they're using the user program, but are actually using the model, and model (data) model changes are raising events that the user program is listening for. In this way you have a rather novel form of runtime verification at work: the user program can never be in an unspecified state - the program's HLPN can look before the user leaps and can ignore any user actions that would put the user program in a problematic state.

If you install the faceplates sample code from the JSML.net web site and run the SbpNews.mbdf.aspx file, you'll see something like the MBDF SBPNews screen shot in the Lab Rats section below.

Using the MVC.JSML Framework

In this section I'll show you three samples: the Class Browser (that documents the JSML and MVC.JSML classes), the SBPNews app (where I'll show you how an MVC.JSML app is put together), and the App Browser (documenting the SBPNews application). Static pictures can never do justice to any of these applications. Any time you invest in reading the content of the App Browser or the Class Browser will provide an education into the nature and use of JSML and MVC.JSML frameworks. Incidentally, reading the content of the SBPNews app will give you a sense of the history of SBP research.

The Class Browser

The Class Browser content is coming directly from the JSML base classes. Erik has done a superb job of properly documenting his code. As a reward, the Class Browser uses the MVC.JSML classes to render that documentation in a very readable fashion.

One way the Class Browser works so well, is that most of the source code of a JSML application is metadata. The Class Browser exploits the natural relational nature of this metadata to convert the source code and its comments into a fully functional web application.

To see these samples for yourself, note the Address drop down's value in the following three images.

SBPNews

SBPNews is the canonical example of schema-based programming and the MBDF. It's a simple newspaper format. Indeed, the same format is used on my real-world (though shamelessly neglected) newspaper, The Abolitionist. As we speak, Charles Curtis and I are rebuilding "The Abolitionist" (and another of my favorite projects, the "Fractal Market Analysis" home page) using the MBDF. I'll include announcements of the completion of these projects from the News Desk of future Confessions.

At any rate, here's the SBPNews application:

At this point I'm going to take another shot at underscoring an important architectural feature of MVC.JSML development, this time by defining two related terms: application and program. Generally, these terms are synonyms, but in MVC.JSML development it's helpful to use each in a very specific manner. An MVC.JSML application is a container (a single aspx file) of one or more MVC.JSML programs. An MVC.JSML program consists of at least four files: a JSML file, an MVC.JSML file, an XML file that contains XSLT that's used to transform the fourth file - an XML data file - into HTML that's contained in the MVC.JSML application's aspx file.

Though this might sound complex, this architecture means MVC.JSML applications can be very powerful and feature rich. The SBPNews sample that ships with MVC, for instance, is not just a newspaper; it includes a cute little application called Dictionary that lets users highlight words in the newspaper and hit ctrl-? to get online and display the word's definition. To unplug the Dictionary program from the SBPNews application just remove the few lines in SBPNews/index.aspx that instantiates the Dictionary object. No other program change is necessary because all MVC.JSML applications are loosely coupled and event-driven. This feature is non-trivial when the second program that's added to the SBPNews application is the High Level Petri Net simulator, something we'll start to get into in the Lab Rats section below.

Steps to Create an MVC.JSML Application

There are two major things to accomplish when concocting an MVC.JSML application. You must create an MVCManager object and you must create as many MVC objects as necessary to implement the desired feature set of your application. Let's now take a closer look at the work you need to do to accomplish these two overall goals.

Your MVC.JSML application will reside in a single aspx file. In the present discussion I'm using the SBPNews/index.aspx file. The index.aspx file holds two important things. First, it holds the base html elements that will display the various Views on the data in the Model. For SBPNews, data in the Model include the text for headlines, abstracts, and story contents. Within the story contents are other data points such as <a> elements. Each of these data points has their own Views in the previous screenshot.

The second set of components of the index.aspx file is the JScript that instantiates the JSML and MVC.JSML objects that make the SBPNews application run. But before the JScript can actually instantiate objects, the classes need to be in memory. Currently, JSML does this by rendering the JSML or MVC.JSML XML files through the JsmlRenderer.aspx file on the server. The JsmlRenderer.aspx file uses managed XSD, XML, and XSL to ensure the JSML files are valid and to transform the XML into JScript source code. The following script elements will generate the JScript source code for SBPNews.

<script language="javascript" 
src="/jsml/1.5/JSMLRenderer.aspx?jsml=/jsml/1.5/Jsml.jsml"></script>
<script language="javascript" 
src="/jsml/1.5/JSMLRenderer.aspx?jsml=/jsml/1.5/Xml.jsml">
</script>
<script language="javascript"    
  src="/jsml/1.5/JSMLRenderer.aspx?jsml=/jsml/1.5/String.jsml">
</script>
<script language="javascript" 
  src="/jsml/1.5/JSMLRenderer.aspx?jsml=/jsml/1.5/XmlDomProxy.jsml">
</script>
<script language="javascript" 
  src="/jsml/1.5/JSMLRenderer.aspx?jsml=/mvc/1.1/MVC.jsml">
</script>
<script language="javascript" 
  src="/jsml/1.5/JSMLRenderer.aspx?jsml=/mvc/1.1/Examples/SBPNews/
NewsModelProxy.jsml">
</script>
<script language="javascript" 
  src="/mvc/1.1/MVCRenderer.aspx?jsml=/mvc/1.1/Examples/SBPNews/SBPNews.mvc.jsml">
</script>
<script language="javascript" 
  src="/jsml/1.5/JSMLRenderer.aspx?jsml=/mvc/1.1/Examples/Dictionary/
Dictionary.jsml">
</script>
<script language="javascript" 
  src="/mvc/1.1/MVCRenderer.aspx?jsml=/mvc/1.1/Examples/Dictionary/
Dictionary.mvc.jsml">
</script>

The first five JSML files are from the JSML and MVC.JSML base class frameworks. The NewsModelProxy.jsml and the SBPNews.MVC.JSML files are the ones we wrote for the SBPNews application. The last two JSML files are for another MVC.JSML sample that Erik wrote, and we thought its functionality as an online dictionary would be helpful to a reader of SBPNews. If you highlight a word and press Ctrl-?, the dictionary application will go online and lookup and display the definition of the selected word.

Once the JSML classes are in memory, the following body_onLoad event handler takes over:

function body_onLoad()
{
  try
  {
    var handler = new JSMLObject();
    handler.handleBoundEventException = handleBoundEventException;
  
    var mvcManager = MVCManager.getInstance();
    var eh = new JSMLEventHandler(handler, handler.handleBoundEventException);
    mvcManager.events.exceptionEncounteredWhileFiringBoundEvent.addHandler(eh);
  
    // add all the view groups
    mvcManager.loadViewGroupsForFile("SBPNewsViews.xml");
    
    var mvc = new SBPNewsMVC(new NewsModelProxy("news.xml"));
    
    mvcManager.addMVC(mvc);
    
    // add the dictionary mvc
    mvcManager.loadViewGroupsForFile("../Dictionary/views.xml");
    var dictModel = new DictionaryManager("../Dictionary/dictionary-model.xml");
    var dmvc = new DictionaryMVC(dictModel);
    mvcManager.addMVC(dmvc);
  
    mvcManager.start();
  }
  catch (e)
  {
    if (e.jsmlClassName)
    {
      err.innerHTML = e.toString();
    }
    else
    {
      err.innerHTML = e.description;
    }
    err.style.display = 'block';
  }
}

The first highlighted code is boilerplate for any MVC application. That bootstrap code creates an instance of a standard JSML exception handler to handle the exceptionEncounteredWhileFiringBoundEvent exception - an exception that generally indicates a bug in your code or configuration as opposed to some unexpected user interaction (that may indicate a spec bug for your code). The other thing the bootstrap code does is the first step in activating an MVC.JSML application: create an instance of the singleton class, MVCManager. One of the main things MVCManager does, is handle all model events (fired when data in the Model changes) and bound events (usually fired when the user interacts with the MVC.JSML application.

The second highlighted code is the second step in activating an MVC.JSML application: create as many MVC objects as necessary; in the SBPNews sample, this means two MVC.JSML objects. This second activation step has three steps.

First, a call to the MVCManager's loadViewGroupsForFile() function loads the XML file that contains the XSLT code that transforms Model data into HTML for each View in the MVC.JSML app. The second step in the activation process is to create an instance of your application's MVC class (passing the XML file that holds the Model data as an argument). The third step is to have the MVCManager add the new MVC object to its collection.

Remember, every custom MVC.JSML file (for example, my SBPNews. MVC.JSML file) inherits from the MVC base class, and any and all MVC objects that are part of your application go through the same three-step process. When all your MVC objects are under the MVCManager's control, you start the MVC.JSML application by calling the MVCManager's start() method.

Since everything in an MVC.JSML application is event-driven, the rest of the application's behavior is predicated on the particular events specified in the JSML and MVC.JSML files. I'll continue the Shop Talk next month by elaborating on the event structure of the SBPNews application.

Your homework assignment, then, is to explore the SBPNews application in the App Browser as the first screenshot in the App Browser section, below, shows. You can activate the App Browser for SBPNews by selecting the link in the lower left corner of the SBPNews screen, as in the next screenshot.

The App Browser

The App Browser translates the arcane interrelationships between XML nodes and attributes that make up an MVC.JSML application into something approaching a natural language description of the MVC.JSML application. In the figure below, the App Browser is documenting the SBPNews application:

The App Browser will organize its information for all MVC.JSML applications the exact same way. The App Browser lists your application's Model(s), Views, and Controller(s). Under each section the App Browser lists the relevant static and dynamic elements of the application. For example, each Model has at least one model-generated event, and the App Browser lists all of them along with the View that is listening for the listed event (if you click the View name you'll see the XSLT that transforms the Model data into HTML).

After Events, the App Browser will list the methods in the program's JSML file, and if you click a method declaration, you'll see the node in the JSML file that holds the JScript that an event handler calls to, for example, change some property in the Model. For instance, trace the steps before and after setCurrentStoryId() is called from the event trace below:

You can get this trace by clicking the headline-clicked link in the Controllers section of the App Browser documenting the SBPNews app.

I want to stress again, that this level of program documentation is a by-product of developing your programs and applications with the MVC.JSML frameworks. This is one of the by-products that accrues when you return your programs to data.

Ok, that's enough MVC.JSML for one Confessions. Before I close shop for the night, I'm going to give you a high level overview of how the High Level Petri Net Simulator interacts with the SBPNews application. Next month, I'll go into the fundamentals of High Level Petri Nets and the HLPN simulator I built using nothing but XSLT.

Lab Rats

Remember the difference between a program and an application in MVC.JSML application development? Since all JSML development is fractal, if you get down deep enough there is no difference between a program and an application. That is, each MVC.JSML program, can run alone, and when it does, that program is running as an MVC.JSML application (with only one MVC.JSML program running under the MVCManager's control).

For example, in the screenshot below, you see the App Browser documenting the HLPN simulator. When I run the HLPN simulator and SBPNews together under the SBPNews.mbdf.aspx application, the HLPN simulator becomes a program, as does the SBPNews application, which, remember, consisted of two MVC.JSML programs: the SBPNews program and the Dictionary program.

The screenshot below has the same structure as the one we discussed above, only the instance data is different. I'll delve into the details of this HLPN architecture next month, in the meantime, I encourage you to download the Faceplates sample code from http://jsml.net/?WROXEMPTOKEN=383589ZPs16T7yc2PndLwWUF2W and click the link in the lower right corner of the HLPN screen to see the App Browser's report on the HLPN application.

If you look closely at the next screenshot you'll see that both SBPNews and the HLPN simulator are running in the same instance of Internet Explorer. Also, I've enabled the "Preview" button on the HLPN simulator. You can follow along at home, but I've selected the first abstract's headline (it's turned red). However, SBPNews has yet to display that story.

Now, once I press the enabled "Simulate" button on the HLPN simulator, I get the last screenshot below: the selected story is visible, the HLPN marking has changed, and the Simulate button is disabled.

Here's the trick: normally, SBPNews listens for the selected-story-id-changed event to fire. However, in the version of SBPNews we wrote for the MBDF, the event handler in the SBPNews JSML file checks to see if the Model has a useIntentions property set. When useIntentions is true, the Model data not only has story data, it has XML that's used by the HLPN simulator when the simulator decides which, if any, transition will fire in the HLPN model of the SBPNews application. Here's the XML included in the SBPNews.mbd f sample:

  <intentions>
    <intention id="headline">
      <token xmlns="">
        <i>
          <s />
        </i>
      </token>
    </intention>
    <intention id="abstract">
      <token xmlns="">
        <i>
          <a />
        </i>
      </token>
    </intention>
  </intentions>

Anyway, if the Model data does not include that special XML, then the event handler in the SBPNews.jsml file fires the selected-story-id-changed event, and the SBPNews application responds by showing the story contents. If the intentions node is present in the Model's XML file, then SBPNews.jsml fires no event (which is why, when the Preview button was selected, there was no visible story content), but the event handler does call the SBPNews.jsml file's useIntentions() method, which does fire an event that the HLPN simulator listens for. This intention-encountered event includes an argument that identifies the intention of the user, in this case, "headline" is the value passed to the simulator. The handleIntentionEncountered event handler in the HLPN simulator takes over, eventually enabling the Simulate button. When the user selects the Simulate button, a different series of events occurs, culminating in the display of the selected story.

There are two things I want you to take away from this overview. First, by loosely-coupling a program (SBPNews) with its HLPN model we can keep the program in a specified condition. That is, SBPNews can't get into a state we hadn't anticipated in the SBPNews program spec (an HLPN model). As a consequence, if we change the spec, we change the program.

The second thing that's important, especially as we get into the XML and XSLT details next month, is that by implementing an HLPN simulator in nothing but XSLT (program as data) we are able to treat the model the same way we do the program it models. In other words, since the program and its HLPN model are both schema-based MVC applications, we can do things that other developers (who have an architecture for HLPN design and simulation (e.g., Design/CPN) that's different to their modeled program's architecture) can't.

Bully Pulpit

After months of late nights at work and a seemingly unending list of things to do around the house during the weekends, I woke up on November 2, 2002 resolved to do nothing but write; to finish this month's Confessions, as a matter of fact.

Then the phone rang. It was my brother, Brian, "Mike [only my family calls me that], are you sitting down? Mom died this morning..."

It goes without saying that this Confessions is late because that Saturday morning I didn't retire to the study to write. Wrox, God bless their corporate heart, gave me a break on my November 5th deadline. I'm still not fully re-engaged with the world, so I've decided to limit work on this Confessions to finishing up the notes I left in the preceding three sections.

One thing that distinguishes this column from other content on ASPToday is that I imbue these words with personality. This column won't just be a collection of technical facts; it'll be a story about one guy's adventures in the world of software development. To be so personal takes either great courage or great carelessness, I haven't decided which. So, with your indulgence, I want to use the Bully Pulpit this month for one simple, and very personal purpose: Though my Mom never could explain to her friends what her oldest son did for a living, I think she was proud of that work, nonetheless. So if you guys don't mind, I'd like to devote this column to the memory of me mum.

This is for you, Mom.

Until next month... read well and prosper.