I've been dying to announce this one. I'm leaving Tech Ed Developers one day early to go to Copenhagen and do a C++ day November 10th. There's an announcement in Danish on the msevents site now. Here's the agenda:

Agenda 

The sessions for Tech Ed Africa in Sun City are now available online at http://msevents.microsoft.co.za/teched2006/Sessions.aspx. I have three sessions there, here's how they look:

Notable names on this speaker list:

• Andre de Beer
• Ayal Rosenberg
• Colin Erasmus
• Dave Webster
• Hilton Giesenow
• Jay Schmelzer
• Ken Everett
• Kimberly Tripp
• Ruari Plint
• Simon Harris
• Steve Riley

Folks I've seen speak here before, for the most part. This is always a very enjoyable conference for me and I'm looking forward to seeing everyone again.

Kate

You can search sessions and see the schedule now, at http://www.mseventseurope.com/Teched/06/Pre/static/Developers/SessionSearch.aspx. Here's how my talk looks there:

Some names I know in the speaker list:

• Anders Hejlsberg
• Ayman Shoukry
• Brian Randell
• Carl Franklin
• Catherine Heller
• Christian Weyer
• Clemens Vasters
• Ingo Rammer
• Jackie Goldstein
• Jan Tielens
• Jay Schmelzer
• Jeff Prosise
• Kimberly Tripp
• Mike Fitzmaurice
• Patrick Tisseghem
• Richard Campbell
• Scott Hanselman
• Stephen Forte
• Steve Teixeira
• Steve Lasker

RDs, blogs I read, MS people... it's going to be a great time!

Kate

Shankar Vaidyanathan, who's been on the VC++ team for over 12 years, talked to Channel 9 in late July about why C++ devs actually do use and care about the IDE. He also shares some of the challenges for writing an IDE for very demanding customers. Watch this one immediately after the Boris one and you'll be an IDE guru!

Kate

I don't know why I didn't see this earlier, but then again I had a tough summer. Here is Boris talking about the C++ IDE and a lot of the tips that were in my Tech Ed IDE talk ... the one with no slides. If you weren't at my talk then I guarantee you will learn something about VC++ from this video, and even if you were, you still might.

Update: I really should have included this link to Boris' blog. Maybe he will update it more often if he gets more traffic.

Kate

No, I'm not talking about where the brace brackets go! Coding guidelines are so much more than style guidelines. One of the things that sets me apart from many other developers I know, and especially the authors of code I am asked to fix, is a drive for simplicity. For me, that comes down to three things:

• Start by solving the problem you're actually facing, not some enormous superset of it
• Write the straight ahead way first, then adjust for the exceptions and strange corner cases
• When it's all working, and every time you touch it from then on, look it over to see if you can make it simpler.

That last one is the one so many people seem to skip. Then later when I come along and read the code, I see how it could be simpler, but I hesitate to change it. They must have done it this complicated way for a reason, I think to myself. It can take quite a long time to prove to myself that no, they just settled for 'working' and ran away as fast as they could, leaving this mess for someone else to sort out later.

A mentoring client gave me a pointer to an article ostensibly on Coding Guidelines which is as much philosophical as anything else. I like it. The rules are:

1. Make your code look like other people's code.
2. Use the simplest design possible.
3. Don't re-invent the wheel.
4. Document your code.
5. Keep security in mind.
6. Work in increments.
7. Work in iterations.
8. Have your code reviewed.
9. Don't stay blocked.
10. Do unto others as you would have them do unto you.

There are no false notes in this list and I endorse this set of philosphies whole-heartedly.

Kate

The other day I spotted this:

It's two people around a bowl of salsa, holding a nacho chip as big as each of their heads (which is why it takes both of them to hold it, I guess.) But I had never noticed it before:

That reminded me of something else I never saw even after looking at the logo a million times:

That obvious arrow is lurking here:

So subtle, till someone shows it to you. Then so obvious. So it is with bugs, eh?

Kate

How many Visual Studio Developers know about autoexp.dat? My guess is not many. This file, located in C:\Program Files\Microsoft Visual Studio 8\Common7\Packages\Debugger for a typical install, controls how the debugger shows values in the Data Tips, locals window, auto window, etc. The file is yours, it's on your own computer, and you're free to edit it. Here's how to do so for a really simple (and redundant) type, Point:

class Point
{
private:
 int x, y;
public:
 Point (int xx, int yy)
 {x=xx; y=yy;}
 int getx()
 {return x;}
 int gety()
 {return y;}
};

I ran a really simple app that constructed a point, and paused in the debugger for a data tip:

Then I edited autoexp.dat, adding this line:

I saved it and ran the debugger again, and now the tip looks like this:

You can do this for any class you write. It's your program, you might as well make your debugging life easier.

Oh, if you're wondering why my data tips are actually readable instead of in some tiny 3 point font, I blogged that earlier this summer.

I find it really surprising how much I am enjoying owning this kettle:

It is just what it appears to be, a glass electric kettle. When the water is at a full boil it is actually more dramatic than this picture shows. Like all modern electric kettles, you lift it off its base, leaving the cord and such behind, to pour. It's faster than the stove, won't boil dry, and it's fun to watch. Who knew?

I got mine at Canadian Tire. It wasn't even the most expensive kettle there.

Kate