# Wednesday, 29 December 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, 29 December 2010 19:54:05 (Eastern Standard Time, UTC-05:00)  #    Comments [0]
# Monday, 27 December 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, 27 December 2010 19:49:10 (Eastern Standard Time, UTC-05:00)  #    Comments [0]
# Saturday, 25 December 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, 25 December 2010 19:40:06 (Eastern Standard Time, UTC-05:00)  #    Comments [0]
# Thursday, 23 December 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, 23 December 2010 16:48:30 (Eastern Standard Time, UTC-05:00)  #    Comments [0]
# Tuesday, 21 December 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, 21 December 2010 13:50:01 (Eastern Standard Time, UTC-05:00)  #    Comments [0]
# Sunday, 19 December 2010
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

Sunday, 19 December 2010 12:10:28 (Eastern Standard Time, UTC-05:00)  #    Comments [0]
# Friday, 17 December 2010
It's over 200 pages long, and over four years old, but I just heard about it recently. A long, dense discussion of whether certain C++ features (templates, namespaces, RTTI, etc) have a performance cost, and how to write code that incurs as little performance cost as possible. Its official name: ISO/IEC TR 18015:2006(E)  Technical Report on C++ Performance. In addition to runtime performance, it also touches on compile slowness, the "brittle base class" problem, and the different performance characteristics of various STL collections and algorithms. If you care about the speed of your C++ code, you should read this, even if some of it is already familiar to you.

I'd like to give some kind of "Restrained Understatement" award to this sentence:

Template meta-programming  and  expression  templates  are  not  techniques  for novice programmers, but an advanced practitioner can use them to good effect.
To be clear about where these authors are placing the "advanced" bar, I don't use meta-programming, I consider it too advanced for me. And I have 20+ years of C++!

The whole report is platform independent (though embedded systems are discussed separately) and compiler independent, too. I wish it were updated for C++0x, but I guess that will have to wait until C++0x is settled :-). There's a 14 page bibliography, and you would do well to read many of them, though my source for the link winkily pointed out another possible paper. That one is old enough to get a driver's license, but I think you might enjoy reading it anyway. As the introduction begins:

It is important to understand how your programming language is implemented. Such knowledge dispels the fear and wonder of “What on earth is the compiler doing here?”; imparts confidence to use the new features; and provides insight when debugging and learning other language features. It also gives a feel for the relative costs of different coding choices that is necessary to write the most efficient code day to day.
It's only 23 pages long, and concludes:
... we have considered many of the significant C++ run-time implementation issues. We see that some wonderful language features are almost free, and others can incur significant overhead. These implementation mechanisms are applied quietly for you, behind the curtains, so to speak, and it is often hard to tell what a piece of code costs when looking at it in isolation. The frugal coder is well advised to study the generated native code from time to time and question whether use of this or that particularly cool language feature is worth its overhead.
Good advice, in 1994 or 2010.

Kate

Friday, 17 December 2010 11:34:31 (Eastern Standard Time, UTC-05:00)  #    Comments [0]
# Wednesday, 15 December 2010
Those hardworking elves at the All in One Code Framework keep releasing more samples. They've added some ASP.NET samples (including a very interesting "get location from IP address" one) and some Windows 7 shell extensions, specifically a preview handler. Ah, the good old .recipe file type - an old friend of mine. But as always the samples are going to save you hours and hours of time.

Here's an index to all the samples for you to explore. You might be a little astonished if you haven't checked it out before, they have:
Slowly but surely the samples are accumulating to live up to the name. This should be the first place you look when you want to take on a new task. Generally speaking, everything is available in native C++, C#, and VB (the exceptions are things you can't do in native C++, like ASP.NET) with the language included in the sample name (look at CppWin7TriggerStartService, CSWin7TriggerStartService, and VBWin7TriggerStartService for example.) And remember, if you don't see what you want - you can ask for it!

Kate

Wednesday, 15 December 2010 10:57:52 (Eastern Standard Time, UTC-05:00)  #    Comments [0]