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. |