I know it's been a while (almost three months now) since I wrote anything about the Microsoft technologies I work with, and haven't reported anything more on the ModelCalc project that I started on last summer. Priorities do change, and throughout most of the fall I was very much focused on merging two MSDN Developer Centers, specifically Data and "Oslo" (now SQL Server Modeling). Both of these live on www.msdn.com/data, and I wrote a post on the Data team blog to tell that story. A big piece I wrote as part of this effort is Data Development Technologies: Past, Present, and Future, a piece that's been very well received (e.g. by Douglas Purdy, for whom I'm now working). I very much encourage anyone working with data development to give that one a read.

That merger was also timed with the Microsoft Professional Developer's Conference in Los Angeles in late November, which was the first conference I've attended in quite a few years. What worked great about the timing of the conference was that we immediately went into the holiday season after that, which was for me mostly a time to catch up with everything I'd been neglecting while focused on the other tasks, and to clean out all kinds of old data, emails, etc., to get a fresher start here in 2010. (I also spent some time figuring out how to combat comment spam on my blog here.)

That said, as my reality rapidly expanded last fall to include various data development technologies like ADO.NET, Entity Framework, and WCF Data Services, I've been focusing lately on projects to get myself up to speed on those goodies. In particular, I'm working up some samples around my personal reading history. I've been keeping this data first in a Word document and then in an Excel spreadsheet since I got out of college in 1990. The list of unique titles (that I've actually) is up now to 497, which is a nice set of data to work with. Eventually that whole set will be accessible through my personal website through WCF Data Services; before then I'll have some portions of the data out with the schema as part of other samples. In fact, the first piece I'm working on has to do with different ways to define and deploy database schema, as I've been working through the different options that Microsoft has to offer.

Any thoughts on such projects are welcome here in the comments, of course. (And I look at the comments before approving them, since most of them are garbage. But I do look and approve the real ones!)

“Modeling” in Code

(Continued from Part 1) Now there are four very important facets of the code structure that have to do with modeling.

(1) First is the inherent disconnect in how these buttons are classified: there are four appearance classifications but only two behavioral classifications, the latter being implicit in the assignment of the Click event hander assignment, which is why I call it an “informal” classification. To tighten up these relationships, we should really have event handlers for each conceptual button type: digit, memory, operator, and function. At the same time, we don’t want to combine the visual and behavioral classifications: each button should have a visual classification that only affects appearance (for the purpose of visual design) and a behavior classification that only affects function (irrespective of a button’s color, for instance).

(2) Second, the OnWindowKeyDown event handler expresses all the keyboard mappings in code such that they cannot be changed unless program is recompiled. To support a class of applications in a runtime, this has to be converted to a data-driven implementation that can accommodate arbitrary mappings.

(3) Third, the two sets of variables clearly separate those that are external—that is, those that have meaning to a user of a calculator—and those that are strictly internal implementation details. I did this intentionally when rewriting the code because the conceptual behavior of any button can be expressed in terms of these few external variables (Accumulator, Stack, Op, Mem, and AllowRepeatEquals). The internal/state variables, on the other hand, are necessary to create the behavior of specific kinds of buttons, such as digits, operators, or =.

I reworking this code, it took considerable tweaking to get a few behaviors working correctly, such as the repeat = key, overwriting the display value at the appropriate times, and suppressing an operation when an operator key was pressed. The problem was that the original code sample overloads the semantics of its EraseDisplay variable with all of these behavioral implications. It’s used not only in the same capacity as our new OverwriteAccumulator, which has a similar meaning obviously, but is also used to decide whether to suppress computation when an operator key is pressed. It’s also used to ignore a repeated = keypress. As a result, it really complicated my effort to clone the repeat = behavior of the Windows Vista Calculator.

More...

As described in the earlier outline for my modeling project (and yes, I know I've been slow getting new posts up), the first step in creating a model-driven runtime for calculator applications is to have a working single-calculator program upon which to base the work—something, that is, that can be turned into a generic, configurable runtime. The primary benefit here is that we’ll then be able to see the incremental stages of development of the process that will, I imagine, shed some light on the general nature of runtimes as compared to specific applications.

It also affords the opportunity to explore “modeling” itself in its different expressions. Fact of the matter is that all software engages in modeling processes: the purpose of software is to essentially configure a universal machine (the computer) to behave in ways that reflect various tasks and processes (whether human or automated). To give a simple example, a spreadsheet models forms and processes that originally existed on paper; the software was modeled after some real artifact. Indeed, when I wrote the Windows 3.0/3.1/NT/95/98/2000/XP/Vista Calculator program, I directly modeled it after the $9.95 “Dynatone” job I’d bought at K-Mart when I was in high school. That is, I made the program behave pretty much like the physical device.

In this two-part article, then, we’ll discuss how the conceptual “models” of appearance and behavior typically manifest themselves in a combination of code plus data, which in our case means and C# and XAML. As you may already realize from your own work, appearance and behavior end up being spread around throughout an application’s code, mostly because writing a single application simply doesn’t require a cleaner separation. Granted, facilities like XAML and “code-behind” have gone a long way to at least separate appearance and behavior, which is fabulous for collaboration between designers and programmers. Yet still, the behavioral “models” in a typical application are not only spread around within the code itself, but is also expressed to some degree in the very structure of that code.

More...

As Microsoft's program manager in charge of the "Oslo" Developer Center on MSDN (since merged with the Data Developer Center http://msdn.microsoft.com/data), you'd naturally have every reason to expect that I wholly "get" what all this "Oslo" stuff is about. After all, I acquire, publish, and manage the DevCenter content that's intended to tell the "Oslo" story. [It's now called SQL Server Modeling, by the way, as we've retired the "Oslo" name.]

I must confess that this is actually not the case, at least not yet. Frankly, I still ask myself—quite often, in fact—just what's it's all for and what, in fact, someone really does with it--with the whole of it. Like many people, I can see how certain pieces like the "M" toolchain are useful in and of themselves (writing nifty languages and such), but when you start talking CLR and UML domains or "middle-tier" applications, I'll listen politely while trying to pretend my eyes aren't going glassy.

To my credit, this state of affairs is actually by design, which gives me a perfect opportunity to bore you with the backstory of how, after a hiatus of around 12 years, I found myself back at Microsoft and eventually working on "Oslo." People are going to ask about this anyway, so…well, OK, originally I wrote that whole section right here, conveniently forcing you to indulge my penchant for storytelling. But charity won out in the end and I moved it into its own piece.

So like I was saying, this present state of affairs is intentional. Since the beginning of February, when I officially began this role and could at least differentiate between Microsoft code name "Oslo" and a city in Norway, much of my time has been consumed in just getting my bearings on the project while keeping the DevCenter reasonably fresh. Combined with the demands of the "Oslo" May CTP and my wife's recovery from abdominal surgery, it was only in late summer that I was able to delve into a serious learning project of my own.

My hope is that this effort will lift me out of the slums of ignorance, so to speak, and in the process lay a path for other developers (and mind you, this particular post is just a start, not the complete story). For as much as being embedded in a team that eats middle-tier for breakfast (and effortlessly speaks of app servers, repositories, and domain-specific languages with every breath) makes me at times feel quite alone, it's certain that I'm not. Many developers are surely wanting to slake their thirst for understanding, even while they skillfully feign competence. (But that's OK. We're friends and I promise I won't rat on you.)

More...

Written June 30^th, 2009

This is meant to be an insert within a forthcoming "What Exactly Does One Do With 'Oslo'?" article; originally it was part of that piece but tended to make the whole thing somewhat lengthy!

Some of you may remember the work I did in my "version 1.0" career at Microsoft, which spanned the years between 1990 and 1996. During most of that time I worked as a software engineer in the Developer Relations Group (which eventually turned into Developer & Platform Evangelism) with the purpose of helping developers outside of Microsoft understand and apply our technologies. In this capacity I ended up as the industry expert on the OLE and COM technologies. This put me on stage at many developer conferences and saw the publication of Inside OLE 2 (1993) and Inside OLE 2^nd Edition (1995).

At that time, the focus was pretty much on desktop applications; client-server applications were really just starting to hit the mainstream, including web applications. And that was the very point at which I retired from the high-tech scene altogether. (For the complete story of my first career, which many people tell me isn't actually boring at all, see my book, Mystic Microsoft.)

Thus I completely missed out on the evolution of Microsoft's component technologies beyond the desktop. While people like my friend Don Box were circling the globe talking about DCOM, .NET, and all kinds of new middle-tier and enterprise-level stuff like Microsoft Transaction Server, App Server, BizTalk Server, and what have you, I was off doing completely different things (see www.kraigbrockschmidt.com). To what extent I fiddled with technology, it was pretty much still limited to client apps, managing a few Access databases, and putting together some simple websites. What I learned of .NET was pretty slim, just enough to be mildly confused.

Ironically, the chap who was my direct manager when I wrote this, the very visible Chris Sells, got started in all this shortly before my exit. Having started his path with COM at one of my presentations, he eventually worked with Don Box at DevelopMentor where he earned his living, as he puts it, "telling people how to minimize round-trips in DCOM." Since then he's been pretty deeply immersed in the heart of efforts like Microsoft code name "Oslo."

More...

A Short Introductory Guide to the Microsoft code name “M” Modeling Language (Part 2 of 2) [Complete article available in Word Format (196K) for nice printing]

Compiling "M"

Of course, having a bunch of "M" code sitting around is well and good, but to make all those types, extents, and functions useful they must be turned into actual database constructs.

This basically means compiling the "M" code and generating output that can be used to populate a database. For this there are two options:

• Compile "M" from the command-line using the m.exe tool (generally found within Program Files\Microsoft Oslo\1.0\bin)
• Compile "M" from within Visual Studio using the "MCompile" element in a project file. (This option is installed automatically with the "Oslo" SDK. This option instructs MSBuild.exe to invoke m.exe automatically.

Note: it is also possible to dynamically parse and compile "M" programmatically, but that's beyond the scope of this article.

The "M" compiler, as shown in the diagram below, simply parses the "M" and generates some kind of output that can be used to create a database. Typically this is an "M" image (or MX) file that can then be fed to the image loading utility, mx.exe, for deployment into a database. (At which point it becomes accessible to applications or runtimes that make use of that database. Note that "Repository" is shown in this diagram but can be any SQL Server 2008 database.)

Alternately, you can use the "M" compiler to generate SQL statements that can then be deployed using the sqlcmd.exe command-line tool. Let’s look at these different compilation methods in turn. We’ll come back to the matter of installation/deployment later.

More...

A Short Introductory Guide to the Microsoft code name "M" Modeling Language (Part 1 of 2)  [Complete article available in Word Format (196K) for nice printing]

Note: the contents of this series of articles originated from a PowerPoint presentation from Chris Sells that we used to ship with the code name "Oslo" Community Technology Preview (CTP). Since a slide deck isn't the most accessible format for publication, I converted its contents into a more textual form here.

Hello "M": Types, Extents, and Functions

"M" is the code name for Microsoft's new modeling language. It came about because the team developing Microsoft's set of modeling tools (code name "Oslo") realized a certain class of developers—mostly those who are accustomed to writing source code in text—would want to have a means of modeling data and application behavior that didn't force them to use visual tools. And, of course, that other means is itself text.

"M" was thus born as a human-friendly textual language to augment or complement graphical tools as well as machine representations. It's meant to have direct correlations to T-SQL and, as we will see, the code name "Intellipad" tool gives you the ability to view T-SQL equivalent output for "M" statements. "M" is also intended to be a modern type system that enables compile-time verification and validation while not imposing any particular data storage or access technology. For complete details, see the "M" Overview (MSDN Library), "Oslo": The Language (video from PDC'08), and the "M" Language Specification (MSDN Library). Here we'll just dive right into the basics of the language.

Everything in "M" begins with a module statement like this:

module
    {
    }

A module in "M" can then contain four different constructs:

• Types specify constraints over sets of values
• Extents specify storage locations
• Functions specify parameterized queries (these were formerly known as "computed values")
• Languages define the tokens and syntax rules for domain-specific languages

In this article we'll be covering the first three. For more information about defining domain-specific languages in "M", see the "M" Language Specification (MSDN Library), DSL Tutorials (MSDN Library), and the video Modeling in Text (in five parts).

More...