Woo hoo! STL/CLR is back! It made an accidental brief appearance in a Whidbey beta, but wasn't ready for prime time at all and went off for some retooling. If you grab the September CTP of Orcas, you can give it a whirl yourself. Here are some links stolen from Nikola's blog announcing it:

http://www.microsoft.com/downloads/details.aspx?FamilyID=82243606-d16d-445c-8949-9ee8c10cda2e%26DisplayLang=en to download the CTP.

http://connect.microsoft.com/VisualStudio/ to report bugs or issues with the CTP including STL/CLR.

http://blogs.msdn.com/vcblog/archive/2006/09/30/777835.aspx  Known issues and some workarounds.

So many paying projects to finish... but I will get working with this soon. Time to adjust my November talks to stop using the old unofficial version and start using the CTP version.

Kate

Fall is here and that means hammock time is pretty much over for another year. I just had to mention the hammock we got this year: small and light enough to take camping, to the beach, or anywhere else. Sets up in a minute or so. Here it is on my front lawn:

It weighs less than a pound and when it's in its stuff sack, I bet it would fit in a roomy jacket pocket. It certainly takes up less room in a beach bag than a towel, and it adjusts to handle trees of varying distances apart. It came from Lee Valley, where so much of my money has gone over the years. They'll ship anywhere. If you decide you want a Lee Valley catalog, drop me an email. I'll refer you to them and the company will give some money to charity.

Kate

I saw this interesting graph over at Language Log:

It compares "empathizing quotient" with "systemizing quotient" -- the extent to which you connect to others' emotions and the extent to which you like to categorize things and people, and fit them into your system of understanding. (This is just for one sample of people and doesn't necessarily apply to the entire world.) You can score very high in both, or very low in both, but as this graph shows, women tend to have higher EQ and men tend to have higher SQ, though the difference between the groups is less than a typical difference between individuals. Engineers and scientists tend to have much higher SQ and also lower EQ. The green symbols on this graph are results from people with Aspergers, or people diagnosed as High Functioning Autistic. Their SQ varies but their EQ is very low. You can take the test yourself if you like. I was surprised by questions like "When I read something, I always notice whether it is grammatically correct" -- that is 100% true of me but I thought it was my little quirk, not something that would appear on a test for personality traits. Then there was "Whenever I run out of something at home, I always add it to a shopping list." Who doesn't?

My results are perfectly ordinary for someone with a PhD in engineering, I think: EQ 36, SQ 77. That puts me about where the S is in the "extreme S" label. Interesting.

Kate

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