Web Logging (blogging) is the wave of the future. Blogging is re-making the internet. Blogging is journalism where everyone is the journalist. Blogging is all that and a bag of donuts.

OK. I guess so. I like blogs. I read a bunch of blogs. But most bloggers feel like they have to update their site at least once/day and most do it far more than that. Because of this, their blog entries end up looking like this:

[burb] Excuse me.

[google this!] [comment on this! (0 comments so far)]

It’s not that I don’t love to read a daily blow-by-blow of these peoples’ lives… oh, wait, no, it is that. Maybe a little filtering would be handy?

And while we’re on to the filtering thing, maybe we could drop the meta-comments about blogging itself? How cool could blogging really be if every other entry is about the power of blogging itself or, even worse, a link to somebody who linked to your cool description of the power of blogging?!?

Anyway, the spout is not a blog. I only update it when I think I’ve got something interesting to say (even if it’s something that only I’m likely to think is interesting), I don’t use any content management software (unless you count ASP.NET and FrontPage : ) and, except for this entry, I don’t spend any time talking about the wonder of blogging itself.

Inspired by my need to know who was calling without hauling my butt off the couch to look at the caller ID on the phone across the room (my father always said that “laziness is the mother of invention”), I built a couple of C# classes for managing an IM connection and an IM session. The test client is a console application that just sends messages and dumps whatever it gets from the IM server to the console, but I think it would serve as the code is the beginnings of a real IM client. It does the MD5 stuff properly and handles being redirected to another IM server, so the hard part of the protocol is already implemented. The sample itself is a handy little program that logs in as an IM user, sends a message to another IM user and logs back off again. Perfect for annoying your office mates. Enjoy.

BTW, Harry Pierson has made a number of updates to this core code to support his full-blown  .NET IM client application. Check it out!

As .NET demands new books and articles and the economy has given a lot of smart folk free time, the world is becoming inundated in .NET books, articles, talks and courses, many of which I am tapped to review. Some are wonderful. Some are awful. Most, however are *almost* good, the path to goodness well within the author’s reach but for the answer to one question: “why?”

Most of my feedback is riddled with questions that start with why: “Why was it built this way?” “Why are there three choices and how do I choose?” “Why should I care?” Please, when you write, remember this question and answer it thoroughly and well. The why is *so* much more important than the how. The online documentation for .NET is fabulous for describing the how, once you understand the motivation for this class, that method or the other namespace.

Prose that provides the how is transient, but prose that provides the why becomes classic because the why itself is surprisingly applicable between technologies. At the very least, if you answer the why, it will save me work if I’m to review your prose.

Standing in the rain, with his head hung low, couldn’t get a ticket, it was a sold out show, heard the roar of the crowd, he could picture the scene, put his ear to the wall and like a distant scream, he heard one guitar, just blew him away, saw stars in his eyes and the very next day, bought a beat-up six string in a second hand store, didn’t know how to play it, but he knew for sure that one guitar felt good in his hands, didn’t take long to understand, just one guitar, slunk way down low, was a one-way ticket, only one way to go, so he started rocking, ain’t never gonna stop, gotta keep on rockin’, someday gonna make it to the top and be a Jukebox Hero….

Jukebox Hero, Foreigner

It’s my understanding that once a musician reaches a certain level of notoriety, they are often asked how they got their start, so that the fan can obtain the level of success that the musician has obtained. Over the years, I’ve received quite a few of these kinds of emails, all of which flatter and surprise me, since I don’t feel like I’ve obtained the level of success that I’d like to. Still, I’m happy to offer, if not advice, than a list of what I did to obtain a level of recognition in our little circle.

It all started in early 1994, when I went to work for DevelopMentor. Don’s strategy, which remains in place to this day, was to give every instructor the opportunity for “stardom.” He had just started to obtain his own notoriety in the industry with his flamboyant personality, teaching and answering every other question on the DCOM mailing list. From there, he used his political acumen to make friends with conference organizers and book publishers, working to add the same level of rigor to Windows development as he was accustomed to applying in the pursuit of his PhD.

Since Don is a fellow that gains happiness in togetherness (or, put another way, “misery loves company”), he dragged the rest of us into his world of course authorship, 24x7 mailing lists, speaker anxiety, article deadlines and demanding book editors. To find my place in this world, I did the following, leveraging the success I had in the early work to make the later work happen:

• Answered every other question on the DCOM and ATL mailing lists and continue to be very active on the .NET mailing list.
• Wrote and gave numerous courses and conference talks.
• Wrote a number of books and articles.
• Put up a web site dedicated, initially, to the various bits and pieces of code I’d built and then expanded it as I had more to say (which turned out to be quite a lot, apparently : ).
• Took as much consulting as I could to gain real-world experience, which I put into my other work.
• Asked fans and happy clients to post their comments on Amazon or allow me to post to my own web site.
• Crazy things just for fun, e.g. pose naked or misinterpret an email on purpose in order to post a humorous response.
• Made friends with the owners and producers of the technology in which I was interested.
• Threw a couple of conferences.
• Started (and stopped) a department to build software developer tools.
• Launched my own (budding) software development tools.
• Launched a couple of source available projects with folks from the community.
• Launched my own mailing list.

It seems like a lot, but practically everything I’ve done since 1994 has been published with my name on it, making me as much an agent for myself as an actual “musician” (I believe the phrase is “shameless self-promotion” : ). Based on this experience, here are the guiding principles that I try to follow:

• Do the right thing. My father always used to say that anything worth doing was worth doing right and that the right thing was easy to spot — its was the hardest.
• You can’t win if you don’t bet.
• Be very thorough so that I can be sure of myself, leading to…
• Take a stand. Have an opinion. Defend my opinion until I have been convinced of my mistake, then admit my mistake and take up the opposite stand with equal vigor.
• Try a lot of things and don’t be afraid to make mistakes.
• Be quick to give credit and admit mistakes, both in public and in private.
• Recognize opportunity and follow up.
• Get down to the real “why” of something, whether it’s computer technology or another kind of technical discipline.
• Recognize the people, on the other hand, don’t always have a “why,” and learn to deal with it (I still work on that!).
• Always strive for quality over the quick and dirty.
• Concentrate on the things that I really want to do. I like to say “Only do those things that you can’t *not* do,” but in a down economy, I’ve learned to temper that with fiscal reality.
• Finish what I start.
• Make sure people are happy with my work and don’t stop ’til they are.
• Have balance in my life. I have a wife and children that I love and spend as much time with as possible.
• Horse trade. I am always willing to offer what I have, e.g. experience, time, contacts, etc, for what I want, e.g. work, money, content, etc.
• Help other people find their own places. I’m constantly concerned with my friends and their happiness and will do whatever I can to help them get to do whatever it is that they “can’t not do.” This is a lesson I learned from Don. He helped me to become all that I could be and, in turn, I do my best to help others.

Actually, most of this I learned from Don, either directly or indirectly. I guess my only real piece of advise is to try to find someone you admire and to do what they do. Don was my main mentor, but I’ve had many over the years and they’re invaluable, even if all I had was a beat-up six string…

Your friend and mine, Don Box, caused quite a stir yesterday with his keynote at European DevWeek in London. Peter Drayton has also written up a summary (which is much more technically meaty), as well as a commentary. There has been some quite spiriting follow up on this talk all over the Internet: the .NET mailing list, the Off Topic mailing list, the REST mailing list and XML Deviant on XML.COM. Also, while I absolutely agree with Don that the way we use HTTP today leads to trouble, I thought that Ian Griffiths, a fellow DevelopMentor instructor, had a wonderful point of view that he allowed me to share:

Guest opinion by Ian Griffiths

Basically Don seemed to be saying that there are two problems with HTTP (and saying HTTP is dead is just an effective way of getting people to listen; I was half tempted to start my Windows Forms speech at the UK MSDN DevCon with “The Web Application is Dead”).

One of these is that HTTP is unidirectional. Surely .NET remoting shows that this isn’t strictly true: individual connections are directional but it’s entirely possible to do callbacks by having connections go in both directions. (Well duh.) The real problem is that the firewall architectures of the internet are designed to make sure the connections only go in one direction; it’s not a problem with the protocol per se, it’s a problem with the infrastructure. In order to fix this problem you need to change the infrastructure regardless of what you do to the protocol. And if you fix the infrastructure you don’t actually need to fix the protocol, since we already know that it’s fine on networks that don’t deliberately break bidirectional communication.

Arguably one of the main obstacles here is the use of NAT - NAT makes it hard for a client behind a firewall to publish an endpoint. But NAT is fundamentally important because we’d have run out of IP addresses already if it weren’t in such widespread use. So the only way to get rid of NAT is for everyone to upgrade to IPv6. This will presumably happen fairly soon since we will run out of IP addresses in any case in about 3 or 4 years. (Windows XP ships with IPv6 support by the way. Type “ipv6 install” at a command prompt if you haven’t already. So Microsoft are quietly making IPv6 ubiquitous on the desktop.)

So presuming ipv6 takes off, that’s a fundamental technical obstacle to the one-way nature of HTTP removed. But another one remains: just because IPv6 pushes the address exhaustion date out of our lifetimes (we hope), doesn’t mean that firewall admins will let connections work both ways through the firewall. The bidirectional problem can only be solved with the blessing of firewall admins. And once you have that you don’t actually need IPv6, strictly speaking - given a suitable protocol between the client machines and the firewall there’s no reason that NAT can’t be done in both directions. (Indeed my sub-$100 firewall appliance can do this on a statically configured basis. It is possible (if a little inconvenient) for machines behind the firewall to publish endpoints successfully.)

UPnP apparently has a solution for this. (A better one than static configuration.) It supports P2P network applications that require clients behind the firewall to be able to accept incoming connections. It defines precisely what you need: a protocol that lets a client machine negotiate with the firewall to open up a port for incoming connections. So it turns out that a technical solution to the problem already exists. (Without even having to invoke IPv6. Although we still need that, due to a shortage of address bits in IPv4.)

So the first problem already has a technical solution. Presume for a moment (and it’s a big presumption) that these solutions can be deployed, and firewall admin policies set up so that they are broadly useable.

At this point, the second complaint Don makes - the fact that long-running requests don’t sit well with HTTP - becomes much less of an issue. We just need to use separate HTTP requests for the request and the response. We connect to the server, send a request, along with some response endpoint info (a URL). When the server is done it connects to us, sends us a response. And we’re done. I’m guessing it would probably be possible to write a .NET remoting channel that works like this. The only obstacle is the ability for clients to advertise endpoints.

So if a client can advertise an endpoint somehow (i.e. it can (a) convince the firewall to let a connection request come in, and (b) work out what the endpoint should be - it needs to be aware of any NAT translation going on) then HTTP can actually solve both the problems raised here. And as far as I can tell, *any* solution to the problems raised is going to have to allow the client to receive incoming requests. In which case why invent a new protocol? Once you’ve solved the fundamental problems in the network that stop you from doing this, HTTP is good enough.

The only issues are: (1) getting everyone to agree on how clients will expose endpoints (UPnP has had nothing but bad press so far, since the only thing most people know about it is that the first security hole discovered in Windows XP was connected to it somehow; so it might have to be something else…), and (2) convincing firewall admins to allow this functionality to be used.

Of course just because a technical solution exists doesn’t mean it’s a great solution. Given that this is a fair distance from HTTP as originally envisaged, it would doubtless be possible to design a protocol better suited to the job. But would the benefits be worth it? Everyone already has an HTTP stack and an XML parser - will they flock to implement a new purpose-built solution?

The problems raised in the ZDnet article can essentially be summed up thus: clients can’t expose endpoints. To me, this doesn’t look like a problem with HTTP, it’s a problem with the infrastructure. Changing the protocol is certainly not sufficient to fix the infrastructure problems; it’s not clear to me that it is even necessary.

So really this is a social problem, not a technical one. ;-)

If you’re interested in this topic or what other interesting things Don will say next, he’s giving the keynote address at the Web Services DevCon on March 21-22 in Beaverton, OR (10 minutes west of Portland).

Chris Sells, 2/19/2002

I woke up this morning with a splitting headache. Just before I woke, I was dreaming that I was interviewing at Microsoft. They held nothing back. It was a group affair with several role-playing scenarios to see how I would handle them. At the end, they threw a mock wedding and sat Tate Donovan (Joshua from the Friends TV show) right next to me while he pretended to be a loud, drunk uncle. I ended up dragging him outside into the street and when he pulled a knife (he was also a Vietnam vet, apparently). I was able to get in one good shot before he “killed” me. Later I attempted to save face by explaining to Tate that I would’ve done better, but I was afraid to hurt him. Tate looked at me as if to say, “At Microsoft, we don’t hold back.” Tough interview.

2/18/2002

Here’s a recent Fortune magazine article about the MS interview process and the culture. Scary…

2/18/2002

 Here’s a quote from an anonymous source:

“I was given your page address from a friend who happens to work at Microsoft and does interviews. He has told me that Microsoft has told all its interviewing employees to keep an eye on your page for ideas and thoughts.”

Figures. I set out to help the interviewees and I end up helping the interviewers. Is there nothing that Microsoft can’t leverage for their own benefit?