Further to that video of Brian Noyes and client technologies, Tim Huckaby has written a terrific paper on the topic. His personal history and experience position him perfectly to understand the real technical reasons (as well as the make-your-boss-happy or the go-home-on-time ones) why you should use a "smart client", "rich client", "Windows client" application for certain kinds of applications. He also knows when you shouldn't. Definitely recommended reading and if you want to tell him your thoughts, he's set up a blog post for comments.

Kate

We have all worked with star developers. When I come into a client to mentor, occasionally they have one developer who is just a star. I can pretty much spot them in the first half hour these days. Other times they have a developer who would say "I am a star" but who wouldn't get that designation from me. Tim Stall has a nice list of things that make a developer a star. As I went through the list I was thinking "yes! yes!" and finally "hire! hire!" which is also what happens when I meet real stars. (Don't worry, I have never poached a dev from a client and never would, but "would you hire this person" is still an incredibly useful summary of someone's skills.) I especially like "22. Knows when the rules do not apply". It can't be taught, and dear heaven can people get this one wrong. When you meet someone who gets this right, it is such a relief.

The list doesn't tell you how to become that sort of person, but I am quite sure the rest of the Internet has some hints. So will I if I meet you in a mentoring context.

Kate

An illuminating post from Dr. Rick Kirschner on bringing out the best in others. He gives ten specific rules, which act as nice reminders only after you've read the paragraphs that go with each. A lot of this maps well to things I am doing and things I have read elsewhere, but in far longer than a paragraph. Other things, like "useful assumptions" are new and bring me an "aha" that I enjoy.

Read it over and see if you don't learn something.

Kate

Stephan has blogged some breaking changes to the STL in beta 1 of VS 2010. These are breaking in the sense that your old code, which worked, might not work when you move it to the latest release. I had this with a demo (not real code) that didn't bother #including <iterator> because it was including something else that included it etc. So my old code wouldn't build in Dev10. Simple enough fix to add the #include.

That alone (4 simple problems, and how to fix them) makes the post worth reading. But it's also a fantastic example of the transparency and visibility the team blog provides. Look at this sentence:

In VC10 Beta 1, I added operator->() to CAdapt , allowing v[i]->Something() to compile unchanged. 

Not "we added". Not "it was decided to add". Not "some faceless decider, whose motives and reasoning are not accessible to the mere mortals who just read our decisions, added". Simply "I added". Stephan, STL, a real person whose posts we can recognize by font alone, added an operator. I think as C++ developers we are a very lucky lot, to have this kind of window into how and why the tools change as time goes by.

The conversation continues in the comments, btw. On the C++ team blog, if a post interests you, you should always read the comments too. Folks ask stuff and team members (not always those who posted the original) answer.

Kate

Oooh, I like this a lot.

That is a little snippet from a query of work items in VS2010 (cropped from a larger pic obviously). You can add a work item and then add other work items that are part of it, break it down into smaller pieces just as though you are in project. This is a huge deal for me! I found this as part of an incredibly long and comprehensive post (with a dozen screenshots) on Brian Harry's blog. This is going to be a must-upgrade for me just for the VSTS stuff - and I love the new editor, and plenty more besides. So far not a single project I've upgraded has had any issues, they've all just worked.

Kate

Paul Sheriff provides a link to a panel he was on at Tech Ed about setting up a consulting business. I've watched the video and I agree with so much of what the panelists said. Watching this video will give you a good insight into the common problems we tend to run into, and some practical tips to keep yourself out of quagmires. Recommended.

Completely without sarcasm, I am pleased with Air Canada for introducing cell-phone free areas in their lounges. While it seems plenty of people come there to hang out, drink free booze, ask when the soup will be available, and have long loud conversations, I go there to have some peace and quiet and a wireless connection. (Though I do like the soup.)

Yes, that's a regular phone in the foreground, just outside the cell-free zone. Irony? Only if anyone ever used them.

Kate

I just could not keep from laughing when I read parts of this Register column on C++0x. And that's good, because that's what Verity no doubt had in mind. And it's mostly accurate, though not a good first reference on C++0x. I would recommend the Wikipedia page or the many excellent entries on the Visual C++ team blog (sorry about the order) to learn what it's really all about. But let's say you have actually read and understood what STL has to say about rvalue references - well done! Your reward for that will be to understand the humour in the Register piece :-). And if you haven't understood rvalue references, well all you really need to know is that they let template writers and library writers make their code "smokin' fast" for you.

Kate

I have pretty well always sucked in air through my teeth when I see calls to memcpy. So much of the time it's a marker of premature optimization and a developer who is sure "my code is faster than what the stupid compiler emits". Even when that's not what's going on, it's so darn vulnerable to things changing size over the decades. It just scares me. As result, there isn't much (or even any?) of it in my code, so I'm not directly affected to read that memcpy() is joining the ranks of the "you shouldn't use it" functions, along with strcpy etc.

I blogged about strcpy and some cousins being replaced with more secure versions five years ago. (I had not thought it was that long, but it turns out it was.) Now it's memcpy's turn. The Security Development Lifecycle blogs this, and shows you how to deprecate things yourself. It's probably no surprise to be told you should use memcpy_s instead. There's a scary list of security bugs that are apparently due to misuse of memcpy that memcpy_s would have caught, so if you are an memcpy user, change your ways!

Kate

I have a collection of USB drives in my laptop bag, as I suppose we all do, and recently I wanted to use one to give someone some files. This wasn't a temporary hand-it-over-they-copy-get-it-back scenario, so I wanted a pretty much empty drive. I found one with only 3 files on it, but the bad news was one of the files was called ReadyBoost.sfcache. That means at some point I had put the drive into my machine and told Windows 7 it could use it to speed up my machine. That's a good thing, and I'm a ReadyBoost fan and all that, but I wanted to use the drive for files and it was pretty much all filled with the cache file.

I tried deleting it, but no go. I tried ejecting the drive and putting it in again so I could say no if I was asked about using it, but I should have realized I hadn't been asked earlier when I put it in so not surprisingly I wasn't asked this time either. A little searching revealed the trick. Put the drive in, open My Computer, right click the drive and choose Properties. Go to the ReadyBoost tab. Presto!

Check "Do not use this device", click OK and tada - the cache file disappears and I have my drive back.

Kate