I’m digging the new Custom Domains service from Windows Live. Setup couldn’t have been smoother:

• Sign up on Custom Domains
• Change the MX record of my domain
• Add Users

The only even slightly tricky point is that I had set up a passport for harry@devhawk.net in the distant past and long forgotten the password. However, Custom Domains allows be to “evict” a user from the domain so I was able to recreate it with little trouble.

I do have two feature requests that I’m guessing are on the horizon for the Custom Domains team:

• Aliases: I’d like to set up “webmaster@devhawk.net” to simply forward to my main devhawk email. This is a pretty common feature of other email systems, so I expect some future release will include this.
• Non-Web Client Access: I can use Outlook to access my personal hotmail account, but I had issues accessing my devhawk email.

Grady Booch @ the OOPSLA 05 Structured Design and Modern Software Practices Panel at (according to the transcript)

The most important part is the executable code. I typically throw my models away, but I always save my source code. I design because I need abstractions to help me reason out my projects.

Grady Booch ranting on his blog:

It’s sad how one can be misquoted and then for that misquote to be picked up by someone else with both then making a spin of the events to support their position. How silly is that.

Juha-Pekka Tovanen quoted me from my OOPSLA panel as saying that “when the project gets closer to the delivery you normally throw away UML models.”

<snip>

Let me be excruciatingly clear: Over the years I have been consistent in saying that in a) the most important artifact of any software development organization is executable code and yet b) modeling is essential in constructing such executables. This is because c) models help us reason about, specify, construct, and document software-intensive systems at levels of abstraction that transcend source code (and the UML is the accepted open standard for doing so). That being said, it is a pragmatic reality that d) some models are essential (and should be retained) while others are simply scaffolding (and should be discarded). I have never said and do not say now that one should throw away all models, as Juha-Pekka then Harry then Steve imply.

First off, Grady claiming to be misquoted his pretty disingenuous. Juha-Pekka’s account of what Grady said on the panel is pretty spot on. Furthermore, Grady claming that I implied he said “throw away all models” is also disingenuous. I specifically wrote that I thought Grady was being taken out of context:

I’ve gotta believe that this comment was somehow taken out of context and that the Grand Poobah of the Common Semantic Model doesn’t actually believe that tossing the model at the end of the project is a good thing.

But he-said/she-said nitpicking aside, where’s the guidance on which models are essential and which are “simply scaffolding”. Last time I checked the UML spec, none of the models are labeled as disposable. How about Rational Rose? Any dialog boxes that pop up reading: “Don’t worry keeping this model up to date, it’s just scaffolding”? I don’t think so.

Obviously, working at a higher level of abstraction helps you reason about a project. But reasoning at high levels of abstraction doesn’t mean you’re modeling. When a building architect sits down with a prospective customer and a sketchpad, they may be working out great ideas but no one is going to call the result a blueprint. Grady’s scaffolding “models” break nearly every tenant of Code is Model. Scaffolding isn’t precise or deterministic. And if it ends up in the recycle bin, I guess it’s not intrinsic to the development process.

Actually, it’s good that scaffolding isn’t a model. It means Grady is specifically not suggesting to throw away models. He just needs to get his terminology right.

As for Grady’s request for “just one DSM out there in production”, Don lists a few: Workflow languages (XLANG and WF), Business Rules Engine Languages and Build lanugages (MSBuild, Ant and NAnt). Juha-Pekka pointed to this list of DSM case studies. I’d also add UI Designers such as the Windows Forms and ASP.NET designers in Visual Studio. In the Window Forms case, the code is stored in a seperate file (yay partial classes) and are specifically marked: “do not modify the contents of this method with the code editor.” In the ASP.NET case, the code for an ASPX file isn’t even generated until runtime. And how about HTML itself? I’m thinking HTML qualifies as “in production”?

After an extended absence, DevHawk is back on the air (so to speak). My pal Tom had a hardware failure and we’ve moved DevHawk onto a hosting service. As it turns out, Tom had the hosting service set up over a month ago and I just never got around to making the switch. So, I have no one to blame but myself for being offline so long.

There’s much to blog about, but I’ll get to that tomorrow. This is as much a test post as anything else.

One quick note, thanks to the relatively-new Windows Live Custom Domains, my blog email is also working again.

Can you tell it’s a slow day in the office? 😄

Speaking of raising the level of abstraction as well as browser based applications, check out Nikhil’s JavaScript Utilities project:

The project introduces the notion of .jsx (extended JavaScript) and .jsa (JavaScript assembly) files. JSX files provide the ability to include conditional code via familiar preprocessor directives such as #if, #else, #endif and so on…The tool processes these directives in order to produce a standard .js file. JSA files build on top of .jsx files. While they can include normal JavaScript and preprocessor directives, they are primarily there for including individual .jsx and .js files via #include directives. This allows you to split your script into more manageable individual chunks.

Now, that’s not raising the level of abstraction much, but here’s another example of working in a higher abstracted environment (jsx and jsa) and then compiling down to something the underlying platform can execute (js). Nikhil provides three ways of doing this compliation:

1. A set of standalone tools that output standard .js files that you can then deploy to your web site. Command line parameters are used to control the behavior of the tools.
2. A couple of IHttpHandler implementations that allow you to dynamically convert your code into standard .js files. This is the mode where you can benefit from implementing per-browser code in a conditional manner. AppSetting values in configuration are used to control the conversion behavior.
3. As a script project in VS using an msbuild project along with an msbuild task that comes along with the project. MSBuild project properties are used to control the conversion behavior.

If you’re going to raise the level of abstraction to do implement a preprocessor, you could also go all the way and implement an entirely new language that gets compiled down to JavaScript for execution in the browser. For example, I’m not as familiar or comfortable with JavaScript’s prototype based approach. But I could imagine a more class based language that compiles to JavaScript. That’s the same way early C++ compilers worked – they were a preprocessor pass that converted the C++ into C, which could then be compiled with traditional C compilers.

I wonder what JavaScript++ would look like

Chris Bilson left the following comment to my Thoughts on CAB post

I hesitate to agree that raising the abstraction level of tools is a good idea. That’s just hiding the complexity that’s already there inside of more complexity. If you ever need to look under the hood, it’s even harder to grok. I think it would be better to go the other way. Try removing stuff to combat complexity.

Given that the software industry has been raising the level of abstraction of tools since the start, I found this comment surprising. Assuming Chris doesn’t write in assembly code, he’s leveraging something at a higher level of abstraction that’s “just hiding the complexity that’s already there”. As I wrote in Code is Model:

The only code that the CPU can understand is machine code. But nobody wants to write and debug all their code using 0’s and 1’s. So we move up a level of abstraction and use a language that humans can read more easily and that can be automatically translated (i.e. compiled) into machine code the CPU can execute. The simplest step above machine code is assembly language. But ASM isn’t particularly productive so work with, so the industry has continuously raised the level of abstraction in the languages they use. C is a higher level of abstraction than ASM, adding concepts like types and functions. C++ is a higher level of abstraction than C, adding concepts like classes and inheritance. Each of these levels of abstraction presents a new model of the execution environment with new features that make programming more productive (and sometimes more portable).
[emphasis added]

I feel like Chris has mischaracterized what I wrote. Here it is again:

If you can’t lower the complexity of your framework, it’s time to raise the abstraction of your tools.

Note I’m not advocating raising the level of abstraction for abstractions sake. Believe me, I’m hate overly complex code. The project I’ve been on (and can blog about soon I hope) had a tone of overly complex code that wasn’t particularly germane to solving the problem. I yanked all that code and have reduced the framework to a quarter it’s original size while adding functionality. But the reality is, simplification can’t always be achieved by removing code. To paraphrase Albert Einstein, solutions to problems should be as simple as possible, but no simpler.

CAB is the simplest solution to the problem it addresses, and no simpler. Since we can’t make CAB simpler and still solve the problem, the only alternative we have is to have the tools hide that complexity. Given how well this has worked in the past, I see no reason why it can’t work again in the future.