Leading up to Microsoft’s Professional Developer Conference last November and the release of another “Oslo” CTP, now called the SQL Server Modeling CTP, I had the pleasure of working with the “Quadrant” Program Management team on the series of “Quadrant” videos on the MSDN Data Developer Center.

One of those videos particularly impressed me, and even got me really jazzed about the product itself (a rare event as my friends know that I’m generally not that excitable). This is the “Quadrant” UI Overview, a four-minute demo recorded by “Quadrant’s” UI designer, Stephen Danton that really shows the essential gestures for working within the program’s unique paradigm.

What’s particularly impressive is watching Stephen’s fluidity with these gestures, something he’s of course practiced in the course of working on the product. Those gestures, as you can see in the video, are very simple in themselves, yet mastering those actions will really help one to master whatever database you’re viewing in “Quadrant.” For what “Quadrant” offers is a way to efficiently move in and out of a database across whatever levels of detail you want to see. Ctrl+mouse wheel zooms in and out to any degree. A simple Ctrl+double click on the infinite canvas (workspace), or pressing F12, zooms out to see everything; a Ctrl+click (or F10) on a workpad then quickly zooms into that area. Doug Purdy, in the talk that he and Chris Sells gave at PDC, likens this to the map zooming functions of adventure games. “World of Warcraft for data” is how he uniquely describes “Quadrant”.

Another simple feature is the ability in “Quadrant” to float workpads up above the zoom-and-pan workspace, essentially up into another layer in the third dimension. This gives you a hub from which you can quickly set up islands of certain entities one some other part of the canvas. This is especially powerful when the canvas is zoomed out, as Stephen demonstrates.

The easy and fluidity that these features and gestures provide open up many possibilities. The effortless browsing of relational tables that Stephen shows about three minutes would probably take more like 30 drudging minutes in a typical database tool like SQL Server Management Studio (SSMS). Navigating even through simple datasets in SSMS might involve writing some complex queries, and your views are always somewhat limited (database diagrams, for example, are meant to those relations between tables and allow little customization). But in “Quadrant”, with a few mouse clicks, you can explore as much of the database as you want, organized however you want, and then also edit the database in a far more natural, fluid, and time-efficient manner.

So if you haven’t checked out “Quadrant,” I honestly encourage you to download the latest SQL Server Modeling CTP and give it a try, especially after watching Stephen’s video.

And as a final note, I want to point out a feature of the video to which Mother Necessity gave birth. After Stephen had recorded this video, I suggested that he more explicitly describe the gestures he was using, so it could serve as a training video for the kind of fluidity he demonstrates. However, Stephen went away on vacation shortly before PDC and didn’t have time to make another recording. So Sidney Higa, who was doing the post-production (he’s our technical writer for the “Quadrant” documentation in the MSDN Library), added the little visuals in the video that specifically call out gestures. While these add a little bit of text to read while you listen to Stephen’s narration, to me it seems just the right amount to actually increase my level of engagement with the video, rather than being a distraction. I hope we can employ the same technique in future videos for the Data Developer Center.

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

Launching a Learning Project

As Microsoft's program manager in charge of the "Oslo" Developer Center on MSDN (http://msdn.microsoft.com/oslo), 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.

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

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