The sessions have been selected for DevTeach and I was pleased to see one of mine accepted. I'll do my "Advanced Windows 7 Programming" session:

Windows 7 development in managed code can be very simple, especially for those using the Windows API Code Pack. But there's more! Your integration with Windows 7 doesn't have to be limited to simple interactions with the new API. This session goes beyond the simple and into aspects of Windows 7 development that have in the past been left for you to explore on your own. See how to create a jumplist with a task that delivers a command to your application, as Messenger and Outlook do. Explore a simple and powerful recipe for connecting to Restart and Recovery with minimal effort. Discover how Trigger Started Services can reduce your power footprint while giving your users better responsiveness. Explore all that Libraries has to offer beyond "File Open" and why using a library is a better approach than having a user setting for "save directory."

This is all managed code, C# and VB. The conference is after Tech Ed US this year, (Tech Ed is May 16-19, DevTeach is May 30 - June 3) so rather than you seeing a Tech Ed talk before the Tech Ed attendees do (my usual DevTeach offer) you can see a Tech Ed talk after it's been refined a bit by giving it to a Tech Ed audience. Even better!

Montreal in the early summer is a beautiful place and there's a great crop of speakers coming! Many are friends, all are top-notch. Sign up now for only $899 Canadian for the full 3 days! That's less than half the price of Tech Ed, and you travel only to Montreal. If you're a developer, give this conference serious attention. Of course, if you can do both Tech Ed and DevTeach, you will gain maximum benefit and a chance to learn all that is current in our field. That's my May 2011 plan.

Kate

I was lucky enough to be part of a spirited email discussion recently on the topic of exceptions. And luckier still that Diego Dagum, the new C++ Community PM, has summarized it on the VC team blog. You should enjoy reading the "best practices" we worked our way around to, like:

Most MVPs agreed that, despite not being illegal in C++, throwing primitive types like int, long, etc., or similarly Windows-based ones like HRESULT, etc. is a coding horror as inabilities to catch those in the proper place will make the application crash with a hard post-investigation to determine where they are being originated.

Of course, we ended up talking about checked exceptions, one of the things I really hated about Java personally, and RAII which is a critical way of thinking if there are exceptions flying around your app. STL joins in with a comment that could be worth gold to someone dealing with SEH:

I strongly recommend AGAINST using the /EHa compiler option. Either /EHs or /EHsc should ALWAYS be used, with /EHsc being preferable (it's faster because it assumes that extern "C" functions won't emit exceptions - while technically permitted by the Standard, sane code should never attempt to do such a thing, so giving up that ability is worth the performance gain).

And I am sure the comments will continue to grow and the conversation continue. This is how we all get better, by discussing and sharing and occasionally defending our practices. It's a must-read.

Kate

Visual Studio 2010 comes with a whole pile of project templates (C# WPF project, that sort of thing) and snippets. They get you started on new projects and save you a lot of time. But if you're a StyleCop user, they can frustrate you, because the code they generate for you can generate plenty of warnings.

The solution: new versions of these snippets and templates that are StyleCop-compliant. Plenty of XML comments, nothing left to default, generally nice code. Doug Holland has a blog post on this with plenty of examples and links. Take a look!

Kate

I'm a big fan of Visual Studio 2010 extensibility; I've given talks at various places about extending Visual Studio yourself and using the gallery to find great extensions. I recommend specific extensions as part of other talks and there are many I can't live without. I came across a fun list by Terje Sandstrom of the extensions they like to use at Inmeta. I completely agree about Pro Power Tools, but I would also add Presentation Zoom and Code Snippet Designer. By the way, the All in One Code Framework is also listed on the gallery. It's just a link over to the CodePlex site, but it's a way to find it if you missed one of the zillion links from my blog.

If you're using Visual Studio 2010 and you're not taking a little time to explore the gallery and tweak the way your copy works, you're missing a chance to be more productive and to enjoy Visual Studio more. Take a look!

Kate

A while back, I blogged about an empty jumplist for Windows Explorer and how I fixed it. I've come across another no-jumplist issue, this time in a blog post by Rick Strahl. This app never gets a jumplist, and can't be pinned to the taskbar or start menu either. Believe it or not, the reason is the executable name. I've seen all sorts of people running into issues with UAC elevation being triggered by certain executable names, but this is the first I've heard of the jumplist being taken away because of it.

Rick looked into it, found the documentation, even found the Registry key and the list of "magic" words in your executable name (Documentation;Help;Install;More Info;Readme;Read me;Read First;Setup;Support;What's New;Remove) that cause the problem. Nice work! Your options, if you find yourself here, are to rename your exe, or (if, like Rick, you have a lot of stuff depending on that name thanks to COM etc) to change the Registry key so that whatever string you're using isn't the problem.

Kate

It's the time of year where people set themselves goals - for the whole of 2011, for the next few months, or just in general. And you can read a lot about SMART goals and how great they are. Opinions vary on exactly what the letters stand for but I'll go with Specific, Measurable, Attainable, Relevant, and Timely. So if I'm giving you a performance review and I say "you should be more helpful", that is not a SMART goal because we can't measure your helpiness and it's also not terribly specific and I haven't given you any kind of time frame for improvement. If you're not helpier tomorrow, have you failed your goal? What about next week? Next month? How long do you have to get more helpful? If I say "you should fill out your timesheet more often" it's still not a SMART goal because it's vague and doesn't have a time element and so on. I can make it a SMART goal by saying something like this: "over the next 6 weeks, at least 5 weeks' timesheets will be completed by 10am of the next Monday morning." The relevance will have to come into play when I explain to you that late timesheets delay our billing of clients and mess up our cash flow. (Or whatever; we actually don't use timesheets here, but that's not the point.)

So OK, we have this concept. And it seems like a pretty good one. After all, if you write it like that, we can come back after 6 weeks (or whatever) and say "pass" or "fail". But let's look at the timesheet-laggard above. Let's say that person misses week 1 and week 2, then goes flawless after that. Still fail? If you feel that way, then as soon as the laggard misses week 2, why keep trying? You've blown the goal, right?

Then there's the matter of the consequences of blowing the goal. Am I going to fire you for messing up my invoicing and causing cash flow headaches and just generally not caring about the business? (I might.) But if you have a goal to pass a particular cert, and you fail it, is anyone going to fire you? Or you have a personal goal to run some distance under some time and you don't get to that time, will you give up running?

Here's I. M. Wright on why having a dozen year-long SMART goals is just wrong - they take so long to write, if people meet 11 out of 12 they can still have a fail of a year, they're all about you when you're actually part of a team, and so on. Since they're unavoidable at some companies, he has some suggestions how to have 4 or 5 really good ones. He also doesn't like SMART for stretch goals, and I agree. Christophe is more about how things change over an entire year, so the goal is probably not relevant by the time limit. The top answer to this StackOverflow question says they're not good for developers, period.

In answering this StackOverflow question I realized something. SMART goals are good for "shape up or else" goals, put on a person by someone else, that allow just a few weeks to achieve something really, well, specific, measurable, and relevant. Do your timesheets. Come to work on time. Include a decent comment when you check in your work. They're really not good for "be a better person", "lose weight", "make more money", or even "get a paid acting job". You just need a different way to express and measure progress on those kind of goals. If you're setting a goal for yourself, unless you think you're correcting a deficiency and have consequences lined up for failure, don't make it a SMART goal.

Kate

According to Darryl Taft, the top languages for next year (and this may surprise you) are going to be Java, C, and C++. You're probably all ready to disagree, but understand the criteria:

... the workhorse languages such as C and C++ continue to remain at the top end of the software development landscape in terms of language use and job potential (despite growing more slowly and even decreasing, according to some sources). Moreover, this list is not intended to highlight the hot, hip new languages on the horizon, but to focus on where programmers can go to look for work.

There's a large body of work being done in languages that are not new, or hot, or trendy, but that have been around for long enough to develop a body of developers and libraries that enable getting things done. The volume of code that will not be ported to new and exciting languages, and will be maintained in its current language for years and decades, will always outweigh the volume of code that is being written from scratch right now or being ported. If you want a job, knowing an "old workhorse" language is a good thing.

Darryl profiles 18 languages in all: Java, C, C++, C#, JavaScript, Perl, PHP, VB, Python, Ruby, Objective-C, ActionScript, Groovy, Go, Scala, Erlang, Clojure, and F#. That is an awful lot of curly brackets, a very high placement for Objective-C given that it really does only one thing, and a fair dose of hot/new/trendy once you get past the top ten. Worth a read!

Kate

Many people really don't understand where P/Invoke signatures come from, or what they mean. They head over to pinvoke.net, which - don't get me wrong - is a hugely important resource, and then blindly paste in whatever they find and try compiling and running their code. Or they use the superbly helpful P/Invoke Interop Assistant. Again, paste, build, run, works on my machine.

This is a great way to start. The problem is assuming that once one run worked, you're done. You need to read and understand the P/Invoke signature you are using. Especially when you are passing in a pointer, or getting a pointer back, you must know who owns that memory and who will clean it up. Are you handing it over to the native code to manage? Is there a risk your managed code will clean it up before the native code is done with it? Is there a risk the native code will clean it up, and then later the managed code will also try to clean it up? Don't think these things don't happen, they most certainly do.

Here's an example: a long running intermittent bug that was caused by a P/Invoke declaration that said the managed side would clean up, but that should have said the native side would (since the native side did.) And here's a nice summary of ways to make sure that native resources (like handles) aren't cleaned up too soon by the managed side. Sorry, but you need to understand this stuff in order to interop successfully. That's where the phrase "head spinning interop" came from, after all.

Don't like it? Don't want to learn it? Then use an interop library like the Code Pack that takes care of those sorts of things for you and exposes an entirely managed interface. Have to learn it whether you want to or not? Consider using the Code Pack as a reference for how to do interop properly. The full source code is available, and nicely commented too.

Kate