Here is an interesting video featuring Kevlin Henney (a confident speaker I've seen at SD West before) discussing some philosphy around good and bad OO design. I don't agree with everything he's saying, but I sure am glad he's saying it. The examples are in Java but that will hardly kill you. Worth a watch.

Kate

A lot of applications like to know what version of the operating system they are running on. Sometimes (especially older applications) it's so they can flat-out refuse to run if you're still on, say Windows 98. This is now frowned on, by the way, and if you want a Windows 7 logo you must not refuse to run based on a version check. Other times (and this is bad too) it's as part of some arcane roll-your-own strategy. For example someone I know planned to work out the default hard code paths for user documents (C:\Documents and Settings\ ... vs C:\users\... ) based on OS versions. This is insane! There's already a function you can call that will get you that path, and it works even if the user has changed it from the default.

But there are still legitimate reasons for version checking. If you're using Vista or Windows7 light-up features like the Task Dialog, Restart and Recovery, or Taskbar Jump Lists, you'd better make sure you're on an OS that supports those features. It's pretty easy from managed code: just call System.Environment.OSVersion.Version.Major and System.Environment.OSVersion.Version.Minor. From native code, GetVersionEx() does the same job. Then you have to do some comparing. That's where things can get weird.

For example, a huge incompatibility bucket for Vista was applications whose code checked that the version was exactly 5.1. If not, it would pop up a message box saying it only ran on XP SP2 or better. I've seen these apps in the wild and I just can't keep from laughing. The error message itself says "or better", and that was presumably the intent, but the code is checking for equality. The magic of >= fixes this "incompatibility" bug in the code, and often these applications don't need any other fixes to make them work on newer OS versions. (That's why the logo people frown on refusing to run. How can you know you won't work on a later OS that doesn't exist yet?)

Even if you grasp the magic of >=, comparing major and minor versions can bite you. Larry Osterman shows us this code:

// Example in C#.
 
internal bool SupportsTaskProgress() {
    if (System.Environment.OSVersion.Version.Major >= 6) {
        if (System.Environment.OSVersion.Version.Minor >= 1) {
            return true;
        }
    }
    return false;
}

He rightly points out it will return false if the version is 7.0, or 8.0, or any other .0 that's larger than 6. (Yes, Windows 7 returns 6.1 for the version #, that's a long story and well covered elsewhere.)

Version checking is hard. If you can, use a library that does it for you. Vista Bridge, for example, not only wraps up cool new OS features for easy access from managed code, it also does some checking to see if the feature is there for you or not. Don't reinvent wheels. Also, check for the feature rather than the OS if you can. Larry discusses this in his post for Taskbar features. Any feature you plan to use, you should know how to check for. I hope to post some more links and examples on this soon.

Kate

A quick glimpse of what you'll find if you search for C++ on the Tech Ed Sessions page:

I'm looking forward to it once again!

Kate

Here's an interesting post from Rick Segal. Even if you don't want VC money, it's an intruiging exercise to see how you look from that point of view. Let's see how gregcons does:

1. Our website, www.gregcons.com. "Does the web site's home page tell you what the company does?" Yes: "We program in Visual Basic.NET, C#, Visual C++ (Managed and Classic,) Java, ASP, ASP.NET, XML, XSLT, XSL-FO, HTML, Javascript, Perl, and CGI. We mentor, provide architectural vision and inspiration, write, edit, train, develop courses, design web sites and act as general internet consultants. "
2. Google "Gregory Consulting" and "gregcons". Our site, some sites of other Gregory Consultings in the world (note to self - if I want VC funding, create a sub with a weirdo name with extra vowels or not enough vowels), and some folks linking to blog postings of mine. Not a soul who's actually discussing us as a company. Fine by me but probably an issue if I wanted investors.
3. Google "Kate Gregory" and "Brian Gregory". You can see who the public face of this company is - not one of the Brian hits is the right Brian, and all the Kate hits are me speaking, writing, and general experting. Interestingly Google (which I never use for my own searches but am using in the spirit of Rick's blog) doesn't find the "other" Kate Gregorys that Live tends to return. I'm not actually the only one on the planet.
4. The mission statement. Um. Well, we have a tag line on the website "Leading your developers forward" so I'll give that a try. Interesting way to discover who is mirroring your old content chrome and all, but you don't learn much about us from it.

I think we pass the test of being discoverable on the internet, but it's clear people don't talk about us as a company much (they do talk about me from time to time). Fun exercise. Try it yourself!

Kate

I've been accumulating some links that might be relevant to folks looking for work. I got a lot of traffic to a post last year about trick questions in a job interview, so I thought I'd share these as well.

• How to Answer “Tell Me About Yourself” and Other Tough Job Interview Questions
• What It Takes To Be A Great Technical Lead
• 10 Ways YOU Stop Yourself Getting The Right Job

These posts are very different, but they all have useful information for you.

Kate

Programmers make mistakes, we all know that. But some are worse than others. Say you hardcode a file name, and you make a typo in the name. When you do your own testing before passing it off to others, you'll discover the typo because it keeps the application from working. But if you fix the typo, there's a good chance no-one will notice the other mistake - hardcoding the file name - for a very long time. In fact, if the file never moves, under some circumstances you could claim it isn't even a mistake to hardcode the name. But if the file does move, hardcoding the name is a much worse mistake because it causes a bug that a customer discovers - and that is always bad. Writing your data access code so it brings back the wrong records (say, forgetting to filter by date) will show up the minute you hit F5, but writing your data access code so it's vulnerable to SQL injection is far worse - you'll think the application works, but when you put it into production you'll have opened a large hole into your database for bad guys.

The SANS Institute has created a list of what they consider to be the 25 most important programming errors of all time. There's a lot not to like in this list, to be honest. First, it's not so much a list of errors (John typed this line of code in that application) as it is kinds or categories of errors. Second, a lot of them look like the same error over and over (trusting stuff that people give you as input, for example). Third, the post spends pages and pages on credits, acknowledgements, explaining why they are important, predicting how the world will be made better by this list existing, and so on before finally getting to the errors. Fourth, the names are flat-out weird in a lot of cases. But with those disclaimers in mind, I still think the post is worth reading and the errors are worth thinking about. Here are the 25:

• Improper Input Validation
• Improper Encoding or Escaping of Output
• Failure to Preserve SQL Query Structure (aka 'SQL Injection')
• Failure to Preserve Web Page Structure (aka 'Cross-site Scripting')
• Failure to Preserve OS Command Structure (aka 'OS Command Injection')
• Cleartext Transmission of Sensitive Information
• Cross-Site Request Forgery (CSRF)
• Race Condition
• Error Message Information Leak
• Failure to Constrain Operations within the Bounds of a Memory Buffer
• External Control of Critical State Data
• External Control of File Name or Path
• Untrusted Search Path
• Failure to Control Generation of Code (aka 'Code Injection')
• Download of Code Without Integrity Check
• Improper Resource Shutdown or Release
• Improper Initialization
• Incorrect Calculation
• Improper Access Control (Authorization)
• Use of a Broken or Risky Cryptographic Algorithm
• Hard-Coded Password
• Insecure Permission Assignment for Critical Resource
• Use of Insufficiently Random Values
• Execution with Unnecessary Privileges
• Client-Side Enforcement of Server-Side Security

The full details are in the linked post and it won't take more than a few minutes to read the description of each error. Pat yourself on the back, or go do a quick code review so you can say you don't do any of these.

Kate

Being a Microsoft Regional Director has a host of benefits, most of which are intangible and hard to explain to someone who's not experiencing them. The number one benefit, for example, is the other RDs. They're such a smart and fun group, and the connections have helped me personally and professionally. The only drawback to being an RD is that so few people know what it means. They think perhaps we work for Microsoft (nope) or that it's like being an MVP (nope, though many of us are MVPs as well) or that we get paid to do it (nope again.)

Recently Joel Oleson had a crack at it. The phrase "unbiased evangelist" is a little tricky, isn't it? And we're not exactly evangelists either ... Microsoft already has people for that. I would say that we've chosen Microsoft technologies (not always exclusively) for our own reasons (that is, not because someone compensated us directly for choosing them) and we're happy to share our reasoning with others. It's that sharing that gets us the nod to become RDs.

Kate

I've been doing some training lately and of course conference season is on the way, so I'm starting to think once again about the mechanics of talking to audiences. One relatively recent change in audience is the popularity of Twitter. It is starting to create a far more public backchannel, one that even the presenter (or the presenter's colleagues) can read and respond to during the talk.

Private, even secret, backchannels are nothing new. I've been on many a conference call where 5 or 6 of us are on Messenger discussing the call itself (and we probably wouldn't want the speaker to read what we were typing.) I've also been in physical meetings where a small group of people are privately discussing the meeting itself, whether co-ordinating who will say what when, or just aimless snarking and wondering when we can leave.

But a public backchannel, maybe even one you have an obligation to monitor, is a very different beast. Some folks, like Olivia Mitchell on Tamar Weinberg's blog, think it's all-good all-round: better for the audience, the presenter, the world as a whole. Presenters just have to learn new reflexes: when your audience suddenly starts typing and looking at their screens, it doesn't mean you've lost them, just that you're so interesting and the information is so important that they feel the need to share with the world immediately. Ira Basen is not so sure, especially if the tweets are negative and going out in public before the talk has even finished and without asking the presenter any questions.

Different conferences will probably lead to different conventions and habits. I can imagine a lot of tweeting from a keynote where things are being announced or demo'd for the first time. But if I'm doing an hour on C++ 0x features, I can't really see why "OMG Lambdas r AWESOME" can't wait until the talk is over. "Now showing capturing the whole stack by reference" doesn't seem like a likely tweet. I can tell you that I'm not going to have a window open on my screen where I'm following "my channel" and that if you want to ask me a question, it's going to involve speaking aloud, at least for now. That said, it's a good idea to think about the impact of wireless internet in every room and instantly-constructed channels on speaking, on conferences, and on the way we all share information. I think there will be more room-switching early in talks if people learn that someone else is really doing a great job, and attendees may demand more agility in scheduling repeats and extra sessions on topics that were well received. As always, we live in interesting times.

Kate