# Tuesday, January 04, 2011
Ok, perhaps it's not news that a keynote is fundamentally different from a breakout. But many keynotes look just like breakouts - the way the slides are written, for example - and many keynotes leave a lot of attendees unsatisfied. A meme began to rise among presenters that "bullets are bad" and "bullets can kill you". I agree completely for keynotes. I don't agree for breakouts, and I've been to breakouts with the pictures of kittens and the single emotionally loaded word and then a picture of a tree and just hated them. But the a-ha! for me is the simple statement: a keynote is not a breakout.

It just makes the whole anti-bullet / pro-bullet thing click for me. The keynote can be full of pictures and super simple words, because it's a keynote. The breakout can still have slides with bullets, tables, charts etc because it's a breakout. Of course the deck for a keynote is not of value without the presenter. It's a keynote. This works for me. Major credit to me "getting" this goes to (of course) Garr Reynolds of Presentation Zen. His post on how dramatically Bill Gates has changed his keynote style - slides, posture, tone, and more -- really lit a light bulb in my head about keynotes and breakouts, whether that was the intention or not. The post itself is highly informative and if you ever speak in from of an audience, you should read it and look at the pictures. These two are from 2005 and 2010 and I think they show you quite a difference:



So, a keynote is a not a breakout (something Bill clearly gets now) and a breakout is a not a keynote. Meaning the kitten content of my talks isn't likely to increase until someone invites me to keynote for them :-).

Kate
Tuesday, January 04, 2011 8:36:55 PM (Eastern Standard Time, UTC-05:00)  #    
# Sunday, January 02, 2011
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

Sunday, January 02, 2011 11:00:29 AM (Eastern Standard Time, UTC-05:00)  #    
# Friday, December 31, 2010
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

Friday, December 31, 2010 8:01:25 PM (Eastern Standard Time, UTC-05:00)  #    
# Wednesday, December 29, 2010
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

Wednesday, December 29, 2010 7:54:05 PM (Eastern Standard Time, UTC-05:00)  #    
# Monday, December 27, 2010

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

Monday, December 27, 2010 7:49:10 PM (Eastern Standard Time, UTC-05:00)  #    
# Saturday, December 25, 2010

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

Saturday, December 25, 2010 7:40:06 PM (Eastern Standard Time, UTC-05:00)  #    
# Thursday, December 23, 2010
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

Thursday, December 23, 2010 4:48:30 PM (Eastern Standard Time, UTC-05:00)  #    
# Tuesday, December 21, 2010
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


Tuesday, December 21, 2010 1:50:01 PM (Eastern Standard Time, UTC-05:00)  #