Recently, I went to lunch with some friends of mine from the DevelopMentor Software days (wow, *that* was a long time ago) and they accused me of “radio silence” for the last two years.

“What?” I said. “I blog all the time!”

“Oh yeah? What have you been working on again?”

“Uhhh…”

I’ve mentioned my work on this blog in passing as “model-driven” this or “data-driven” that, but never the details. And I still can’t tell you those kinds of details.

But what I can tell you is how I spend my days, because they are *glorious* days.

Have you ever had one of those jobs where you’re energized about coming to work every single day, because whatever you’re doing, it *really* needs doing and it’s going to be different than yesterday?

You might be pushing to finish writing a talk for an upcoming SDR (Software Design Review) or getting that last bit of code checked in before a big internal drop, digging into security threat modeling for the first time or complaining that the thing your team is building is too damn hard to use, only to be told, “fine, then, fix it!”

You could be holding the hand of a new Jr. PM just joining the team or busting the balls of some Sr. Architect that thinks he’s all that and a box of Cracker Jacks, interviewing the next set of folks that are dying to be on your team and turning some away because as much work as you have to do, it’s better to leave it undone than to lower the bar even an inch on the quality standards you’re committed to living up to.

You could be building your own sub-system that we already have 8 of inside the company, but you need some source code you understand and that you can experiment with so that you can add the one or two features you think could really make a difference, only to find out you’ve just built the thing that your management wants to base the next-gen version of that very sub-system on.

You might be meeting your boss in the ProClub locker room when you’re half naked or soaking in the hot tub laughing about some trick you pulled in a meeting, listing the customers that need special attention or cornering an executive in the elevator asking for a really cool thing we have to do for the PDC, damn the cost.

You’re definitely going to be going into work with the smartest, nicest, most fun, more interesting, most sincerely quality-focused people you’ve ever known. After Don had first come to Microsoft for a while, he told me that he’d found his “tribe.” I’d been at DevelopMentor during it’s heyday, so I couldn’t imagine ever finding another group of people I enjoy working with that much. I was wrong. My tribe (of which Don is one of the chiefs) gets so much accomplished because we lean on each other, we trust each other and we spend *so* much time laughing with each other (and *at* each other : ).

Most of you will be able to see the thing I’ve been working on with my tribe at the PDC. Or, if you’d like to help us build it, we’re always looking for new tribe members.

I friend of mine dropped a book with a funny cover in my lap and said, “Hey, check this out.” I threw it on my pile and didn’t get back to it for a few days. When I did, I didn’t know what to make of it. It was like The Grapes of Wrath by Rory Blyth, with illustrations by a drunk Salvador Dali.

It took a few pages, but I eventually figured out that “Shoes” was a cross-platform GUI framework for Ruby and this 52-page book was a tutorial for it. By page 15, I knew the major concepts. By page 20, I could write my first program. By the end, 30 minutes after I’d started reading, I knew the whole thing.

But it was page 24 that completely blew me away. The use of pictures of dominoes and matches to illustrate layout in stacks and flows was genius. This wasn’t just a random collection of wacky illustrations and  non-traditional font choices — the author of this book really knew how to tell a story.

It wasn’t that I wanted to program Shoes, so went looking for a tutorial. It was the tutorial that made me want to program Shoes. Now *that’s* writing.

P.S. This book is not from a publisher — it’s self-published through LuLu.com for cost. There is no bar code, copyright page, Table of Contents or index. It’s just the stuff you actually need to get started programming a completely new thing. And, if you don’t want to shell out the $8.72 to read a paper copy, you can read the HTML and PDF versions instead.

*blush*

Wahoo! You love us, you really love us! : )

When a book goes to another printing, 100% of the time, there’s a list of “errata” (aka “mistakes”) that are fixed in the new printing. In this case, neither Ian nor I have any fixes to apply. So, it’s official — the book is perfect! : )

Thanks for reading.

My 1997 master’s thesis came online today (he says, trying not to flinch). Here’s the abstract:

Microsoft’s Component Object Model (COM) is the dominant object model for the Microsoft Windows family of operating systems. COM encourages each object to support several views of itself, i.e. interfaces. Each interface represents a collection of logically related functions. A COM object is not allowed to expose multiple interfaces using multiple inheritance, however, as some languages do not support it and those that do are not guaranteed to do so in a binary-compatible way. Instead, an object exposes interfaces via a function called QueryInterface(). An object implements QueryInterface() to allow a client to ask what other interfaces the object supports at run-time.

This run-time type discovery scheme has three important characteristics. One, it allows an object to add additional functionality at a later date without disturbing functionality expected by an existing client. Two, it provides for language-independent polymorphism. Any object that supports a required interface can be used in a context that expects that interface. Three, it provides an opportunity for the client to degrade gracefully should an object not support requested functionality. For example, the client may request an alternate interface, ask for guidance from the user or simply continue without the requested functionality.

COM attempts to provide its services in as efficient a means as possible. For example, when an object server shares the same address space as its client, the client calls the functions of the object directly with no third-party intervention and no more overhead than calling a virtual function in C+ +. However, when using COM with some programming languages, this efficiency has a price: language integration. COM does not integrate well with a close-to-the-metal language like C+ +. In many ways COM was designed to look and act just like C + + , but C + + provides its own model of polymorphism, object lifetime control, object identity and type discovery. Of course: since C+ + is not language-independent or location transparent. it was designed differently. Because of these contrasting design goals, a C+ + programmer using COM often has a hard time reconciling the differences between the two object models.

To bridge the two object models, I have developed an abstraction for this purpose that I call a faux-object class. In this thesis, I illustrate the use of a specific instance of the faux-object idiom to provide an object model bridge for COM that more closely integrates with C+ +. By bundling several required interfaces together on the client side, a faux-object class provides the union of the operations of those interfaces, just as if we were allowed to use multiple inheritance in COM. By managing the lifetime of the COM object in the faux-object’s constructor and destructor, it maps the lifetime control scheme of C+ + onto COM. And by using C+ + inline functions, a faux-object can provide most of these advantages with little or no additional run-time or memory overhead.

COM provides a standard Interface Definition Language (IDL) to unambiguously describe COM interfaces. Because IDL is such a rich description language, and because faux-object classes are well defined, I was able to build a tool to automate the generation of faux-object classes for the purpose of bridging the object models of COM and C+ +. This tool was used to generate several faux-object classes to test the usefulness of the faux-object idiom.

Enjoy.

Wahoo!

Does anyone have both the Anderson WPF book and the Griffiths/Sells WPF book? If so, have you read Don's forewords in both books?

I just saw that Mr. Petzold is re-publishing the paper that started computer science and annotating it so that even I can understand it. I can't wait!