spout

August 3, 2001 spout

Hanging Out My Shingle

Friday, 8/3/01

For the last three years, I’ve been in management. Oh, it started innocently enough. When the team was small, I was only managing a little bit. However, as the team grew and we got closer and closer to shipping our first product, I spent less and less time doing anything technical and more and more time managing. Eventually, I was doing nothing but dealing with the rest of the company and potential customers and enabling” everyone else. Luckily, Don Box, co-founder of DevelopMentor and my long-time mentor, noticed that I’d been swept right out of the things that I loved the most. And he made me an offer I couldn’t refuse…

Now I’m back on the consulting, teaching, writing, development train and loving it. I’ve been all over .NET for about a year, but now I get to concentrate on it full-time. If you’d like any consulting help in the area of .NET (or even COM and ATL), I’m here for you. Pass the word along. Thanks!

June 9, 2001 spout

Choose Your Defaults Carefully

Saturday, 6/9/01

In the last week, I’ve been bitten twice by developers that have chosen defaults poorly and, therefore, have adversely affected my life. The first was on my Nokia phone. I was in a meeting” with some of my key engineers (read: we were goofing off at a movie on a Thursday afternoon), and I had set my phone to Silent mode. Now, I have a Nokia 8260 (blue) that I dearly love. It kicks butt on the silly Ericsson that I used to have. However, I noticed when I came out of the meeting that their had been several calls from my blushing bride. The Nokia is cool not only because it’s small enough to fit into my pocket (where I keep it during our meetings”), but also because it has a vibrate mode. So, I figured that if the phone was in Silent mode, but the phone was still on, if someone called, I’d get the vibrate in my pocket (separate from my change and my keys to honor the spirit of the Nokia Silent profile). Unfortunately, this was not the case. Calls came in, but no vibration was forthcoming. This happened a couple more times in the next few days until I had a free moment to check the settings for Silent mode (ironically this free moment came while waiting for another movie to start today — “Operation: Swordfish,” which I enjoyed, btw). The default for the vibrate setting in the Silent profile was *off*. How could this possibly be right? It’s a phone! It’s on! Sure, I want it silent so it doesn’t bug people around me, but I still want to know when someone calls! Hence the vibrate mode! Needless to say, my blushing bride was less than pleased.

The second time that incorrect defaults interrupted my life happened to be a bug recently found in Gen<X>. Because Gen<X> installs some COM components, we require it to be installed by an account that’s part of the Administrator group. Unfortunately, the bug is that once Gen<X> is installed, another user can’t use it on that machine unless they are also part of the Administrator group. Of course, since 98% of developers run with Admin privileges on their own machines, this bug was never reported by the secular community. So how did we find it? It was reported by none other than Keith Mr. Security” Brown, who was experimenting with running at a lower level of security for some perverse purposes that I can only imagine… Anyway, when Keith calls you with a security bug, you listen (at least it was the good kind of security bug, i.e. offering less access then we should instead of more. I can only imagine what the phone call would be like if Keith discovers that we’ve opened a hole…). The problem with security? Defaults.

The author of CRegKey, a class in ATL we were using to read the serial number out of the Registry, built in a default access level setting. We use the Registry key when our tools are started to make sure that user has a valid serial number on their machine — standard stuff. You need to be an Admin to write the key, but you shouldn’t have to be just to read it. However, the default setting in the CRegKey::Open method is set to allow read-write permissions, as show here:

LONG Open(HKEY hKeyParent, LPCTSTR lpszKeyName, REGSAM samDesired = KEY_ALL_ACCESS);

The developer who wrote the code (let’s call him Shawn”), being a human with many tasks interested in doing them all efficiently, left off the default value, assuming that the default would be read-only. This was the correct assumption to make if you assume that the CRegKey author was specifying his defaults properly. Unfortunately, he wasn’t, so when we tried to merely read the SN out of the Registry, we were asking for read-write permissions, and the read failed, causing the SN validation to fail, keeping Keith from using Gen<X> and motivating him to call me and complain about it. All due to bad defaults.

Rules for Defaults

Defaults are often set to save typing. That’s a bad idea. If the Nokia guy and the CRegKey guy had but followed the these simple rules for determining defaults, my life would have been better:

  1. Apply the principle of least surprise.” I’m sure he didn’t invent this rule, but it’s one I learned from Don Box and it sticks with me as one of the seven good ideas” that exist in our field (a story all its own). The principle of least surprise says that you make interface design decisions based on what people expect. Shawn expected the default access level to be read-only. I expected my phone to vibrate in Silent mode. Pretend that the default isn’t even an option. What would people expect?
  2. Minimize the harm of inadvertently choosing the default. Assuming the defaults are not changed (a very common occurrence), what bad things could happen? If the default had been read-only on CRegKey, unit testing a code path that required read-write would have immediately uncovered that greater access was needed, a fix could have been immediately supplied and no harm done (except some extra typing). However, because the default was read-write, we introduce an invisible bug that Keith has to find. Likewise, if the default had been vibrate in Silent mode, when a call came in, it would still have been silent, but I would have been notified of the call. Again, no harm (assuming no holes in your pockets and that you’re wearing underwear). However, because of the default, I missed calls and angered my wife. That didn’t happen with the Ericsson.
  3. Change defaults sparingly. Once you’ve chosen your defaults and released your thing, people are going to learn those defaults and depend on them. For example, we can’t go back into our ATL source and update the default to CRegKey::Open because we’ve got all kinds of code paths through our code depending on the default. If you change a default, even if the default was set incorrectly to begin with, you’re doing more harm than good. Unless you can change the defaults without inducing harm, don’t.

Unfortunately, not all developers follow these rules, so when you make use of defaults, please double-check them first.

May 16, 2001 spout

Other Blogs

5/16/2001

My spout page is just one of literally thousands of web logs (“blogs”) available on the net. These are a few of the ones that I like:

  • SlashDot. This is the first blog I ever saw and it’s still really cool. Lots of Linux stuff, of course, but also lots of fun  general-purpose technology stuff.
  • BetaNews. This has no commentary. It’s just a list of software that’s gone into beta recently. I often find interesting stuff here.
  • Joel on Software. Joel Spolsky is an ex-Microsofty who runs Fog Creek Software and has a lot of really good ideas when it comes to how to build software. He often says what I think, so I think he’s a genius. : )
  • Dot Net Dan’s. Dan Green aka Dot Net Dan,” is a guy who really likes .NET and once mentioned me right between Joel Spolsky and Stephen Hawking, so I think he’s cool. : )
  • The CodeProject. This is my favorite code posting site by far. There’s something new there daily and I almost always start there when I’m looking for a hunk of code.
  • ActiveWin. This one is mostly an excuse to pay homage to Microsoft, but there’s interesting Windows news up often enough that I still visit pretty regularly.
  • Jason Whittington: Managed Space blog. Jason’s another DevelopMentor guy heavy into .NET and particularly garbage collection (at least for the moment — most of us have fairly short attention spans… : ).
May 15, 2001 spout

Rules of Engagement

Tuesday, 5/15/01

This is a page where I can just spout off about whatever. I keep it separate from my Tools page so that you don’t mix up any of my spoutings with facts.

Before I  get started, I’d like to lay some ground rules. First and foremost, I’d like to warn you that every human on the planet has an agenda, often more than one. These are some of mine:

  • I want to make people’s lives better. This drives pretty much everything I do. Since my education is in computer science and my sphere of influent is developers, most of what I do is to help that sub-species of human known as developers.” Recently I’ve been experimenting with ways to help normal humans, but what these people want is foreign to me, so it’s slow going.
  • I’m interested in putting food on my table. For the same reason, I’m interested in what’s good for me and my family. This drive is the most potentially dangerous to you if you’re going to put any stock into my spoutings. Be warned.
  • I’m interested in what I’m interested in. Once I like something, I often like it for a long, long time. However, only one thing at a time can really consume me and you’re likely to hear about it here.

The second ground rule is that while I try to be as accurate as possible, I’m human and I make mistakes. If you find a mistake or you think my opinion is just so wrong that it requires a response or you’d just like to respond in general, feel free to send me email at csells@sellsbrothers.com.

May 15, 2001 spout

Object-Orientation is Over

Tuesday, 5/15/01

Java, and Java 2.0 (aka .NET), have brought with them the end of object-orientation. Of course, by that I mean that object-orientation is no longer a question — it’s just how we program. Even our scripting languages have classes and objects now. That fight is over, as are the advances in that area. Object-oriented programming, with inheritance, polymorphism and encapsulation, is just the way we do things now and Java and .NET represent the end of that line and the beginning of several others:

Generic Programming

Generic programming (aka generics”) provides the ability to write a partial type or function and let the compiler or runtime environment fill in the details based on client usage. Of course, C++ templates have provided generics via templates for a long time. Unfortunately, no modern object-oriented languages, i.e. Java and C#, have generics as yet, but they’re coming. My favorite research paper in this area describes how generics can be added to  .NET languages, using C# as an example, written by Microsoft’s own researchers, Andrew Kennedy and Don Syme.

Generics have been around for a long, long time, so if you aren’t already familiar with them, you’re behind. Only C++ programmers do this now, but very soon, everyone will be.

Component-based Programming

Components differ from objects in that they are binary objects, often callable from languages other than that in which they were written. COM, Java and .NET are popular modern component development environments, but even DLLs have provided component-like features since Windows. Components provide a degree of encapsulation that often exceeds that of source-based OO environments, often at the expense of ease of use (although both Java and .NET work real hard to make components look and feel like objects).

Aspect-Oriented Programming

Aspect-oriented programming (AOP) provides the ability to define a set of characteristics of an object or a component that are actually implemented by the hosting runtime. The benefit, of course, is that it’s much easier to declare the need for some feature, e.g. method tracing or the need for a component to be part of a transaction, than it is to write the code. To date, we’ve had pretty primitive support of AOP in the popular programming environments, but it’s been there, e.g.

  • COM+ catalog attributes that describe services provided by the COM+ runtime to components or groups of components (called applications”), e.g. transactions, object pooling or role-based security.
  • Keywords in Java, e.g. the transient keyword that signals to the serialization engine whether to serialize an object’s member variable or not.
  •  .NET attributes that extend a component’s metadata, which is available via .NET reflection to clients, some of which are built into the .NET runtime and some of which that are custom to your particular application.
  • And my personal favorite, as pointed out to me by Don Box, is the PE attribute that marks an EXE as a Win32 Console application. This is primitive, but this attribute tells the OS to set up a console window for routing of stdio.

The .NET attribute mechanism represents a giant step forward in AOP. It’s the first popular environment that provides a convenient, extensible mechanism for not only declaring attributes, but also implementing custom attribute provides, i.e. those bits of code that are activated when an attribute is encountered. Extensible .NET metadata is replacing the COM+ catalog and providing exactly what the Java serialization keywords provide and I expect most language to converge on the AOP style that .NET provides.

Generative Programming

Generative programming is the newest of these new programming styles. The term itself was boasted into popular usage by the book of the same name by Krzysztof Czarnecki and Ulrich Eisenecker. Generative programming is about representing your system’s design requirements in some computer-readable form, e.g. SQL schemas, XML, UML, etc, and feeding it to some kind of metaprogram that will generate your program. The main benefit of generative programming is that as the design requirements change, your programs can be regenerated, saving you from manually replicating design changes into the code. Likewise, as the implementation choices need to change, e.g. from Java to C# or from Linux to Windows, the metaprograms can change and your programs can be regenerated, saving you from doing the porting work.

Macro languages, e.g. the C preprocessor, are generative languages for generating code within files. ASP and PHP are both generative languages for building web pages. Of course, DevelopMentor’s own Gen<X>, was built from the ground up to be a generative programming tool (although we designed and built it long before we’d heard the term). Generative programming has a vast potential, I think (although I’m biased), because it encourages you to specify your design requirements and keep them up to date with the code, but also because of the potential for generating large parts of a system’s code, testing data and even documentation. In fact, in building Gen<X> itself, we find ourselves generating more and more of the next version using the previous version. We don’t use it for unique code, but we use it for the repetitive horizontal or hierarchical code as well as reference docs and test data. Highly recommended.

[new] Comment from Mickey Williams [mickey.williams@codevtech.com], Mon 7/2/2001 10:54 AM:

I’d like to remind you that Eiffel has had generics longer than C++, and Eiffel’s generics work on .NET. So there.

Best regards from the Eiffel bigot,
Mickey”

That’s true, Mickey. I knew that Eiffel supported templates, but I didn’t know that Eiffel# (the .NET version of Eiffel) did, so that’s really cool.

April 21, 2001 spout

From COM to .NET

Saturday, 4/21/01

Enough people have asked me what I think about the transition from COM to .NET that I thought I’d publish my thoughts instead of responding to each individual email. This is the question that finally lead to me publishing this page in the first place.

In the early days of C, ASM was much more efficient, but C was much easier to use and as machines got faster, and C compilers got better, ASM was relegated to use by only a few. During the transition, ASM programmers were valuable and continue to be so for very targeted tasks, but they grow increasingly unnecessary. For example, in all the time that I’ve developed software (17 years), I’ve needed ASM exactly *once* (and then I just used Keith Brown : ). To this day, I have to admit that I can neither write nor even read x86 assembly. I’ve always meant to learn and I admit to being embarrassed that I can’t, but I’ve never needed it. Each platform I programmed for, I started after the platform had moved away from ASM being the dominant programming environment.

As Microsoft ships increasingly stable betas of .NET towards a final release, we’re nearing the end of a long and messy transition from processor-specific low-level programming to programming at a higher level on the Windows platform. To be honest, most Windows programmers are already there and have been for a while. They’re the forward-thinking Visual Basic programmers. They recognized that they had no need to learn Win32 or COM. They could program at a comfortable level and make their C++ programmer friends do the grunge work for them. C++ programmers that haven’t moved to VB yet had two reasons: the programs run too slowly and VB doesn’t let me do what I want. With each successive release of VB, the efficiency argument has gotten weaker and weaker. Now that VB6 uses the same intermediate language and backend compiler that VC6 does, speed’s really no longer an issue. The 2nd reason, VB doesn’t let me do what I want,” is real and continues through VB6. The problem is really the language. There is one feature that no C++ programmer can live without: implementation inheritance. It’s so useful for day-to-day programming chores that we can’t give it up.

This one fatal flaw in VB6 was made very clear to me the other day when I was doing .NET programming using C#. Before we go any further, let me make one thing perfectly clear: VB.NET *is* C#. The only difference is the syntax. The language features are all the same but one: you can write unsafe” code in C#, but not in VB.NET. Unsafe code in C# is the equivalent of  inline ASM: when you need it, you can’t live without it, but you probably won’t need it. So, when I’m programming C#, I could as easily be programming VB.NET. And the beauty of my experience of programming C# caused me to examine the difference between my previous VB6 experience and my current C# experience. I had a form-based drag-n-drop environment in both. I had IntelliSense in both. I had a programming model that was much simpler than raw Win32 in both. In short, C# and .NET gave me everything that VB6 gave me, but with one addition: implementation inheritance. When I needed to model the data for my application, it was so easy because I had inheritance but would’ve been so much harder without it. That feature made all the difference to me and is the reason that C++ programmers will finally feel free to move into the VB-like environment that .NET provides.

Will everyone abandon the Win32 API when .NET ships? No. Will everyone eventually move their code over to .NET? No. Will most folks spend most of their time programming .NET within 18-24 months of ship? Absolutely, yes. It’s too compelling a platform with too many real advantages to ignore.

Does that mean you should stop all development and wait for .NET to ship? Absolutely, no. Build you components in COM today and you’ll be able to move them over to .NET when the time is right (which may be never). The .NET backwards compatibility story is a good one. You’ll be able to continue to make use of most of your COM components and DLLs in .NET, which means that the code you’re working on today will continue to be useful long after you’ve moved your day-to-day programming activities to .NET. To ease the transition, I recommend marking your COM interfaces with [oleautomation] if possible. This limits your method parameters to types and attributes that .NET is particularly good at marshaling.

 .NET via C# and VB.NET is the future of programming for Windows, leaving Win32 and COM as the ASM of .NET.