Do you have a Windows application? Are you curious if it will run well on Windows 7? Would you like to try something a little more technical than "install on Windows 7 and see if it runs?" Then you need the Application Compatibility Toolkit. The latest version, 5.5, is now available. There is documentation for it on TechNet to help you get started.

Kate

People believe a lot of strange things in this world. They worry specifically that SharePoint won't perform as well as they need, and that they can write some sort of ASP.NET app with a SQL backend that will somehow outperform it. I really liked this post from Eric Shupps that lists a few of them. Keep in mind these are all myths - that is "not true".

• SharePoint Lists Have an Upper Limit of Two Thousand Items
• SharePoint Is Just Too Slow for Common Tasks
• SharePoint Is Not Suitable For Large Public-Facing Web Sites
• SharePoint Isn’t A Scalable Enterprise Document Management System
• SharePoint Pages Take Too Long to Render Over the WAN

Eric goes into quite a bit of detail debunking each of these 5 myths, so if you have a tendency to believe these things, here's a chance to get straightened out on that.

Kate

I think one of the things that really sets good presenters apart from poor ones is what they do when something goes wrong. A poor presenter:

• needs all their cycles to try to figure out what went wrong, and has none left for looking after their audience
• is focused on making the demo work and sticking to the original plan
• is rattled by the experience so that whether the demo works in the end or is abandoned, the rest of the talk is lower quality

A good presenter:

• has rehearsed the demos many times, so that most "boom!" moments have been seen before and can be fixed quickly
• doesn't need as much energy to look after the audience, so is more likely to be able to do it
• is focused on making the talk work
• has backup (screenshot of the result, an exe that was built earlier) so that something can be rescued
• can get through the failure quickly and get back to the flow so that the talk as a whole can go well

I linked a while ago to a picture of Steve Teixeira dealing with a blue screen. Now Brad Abrams has highlighted Bill Buxton (who I quoted a few posts ago) dealing (at Mix) with hardware that refused to co-operate. I aspire to do as good a job dealing with demo failure. Brad includes some other "demo failures at Mix" in his post, too. 

A tip that has served me well over the years: have a stock of optimistic "I am not an idiot" sentences to use while you're either giving up on the demo or doing what you need to do to make it work. "Hey, if it was perfect, we'd be shipping it" is good. So is "told you it would be a short demo". Humour keeps the audience with you, and stock lines don't take up much of your brain, so you can be furiously thinking with most of your brain about how to solve your problem (either how to fix the demo, or what to do with the rest of your talk now that you have ten more minutes to fill.)

Kate

Steve Clayton highlights a neat video that you should probably watch. It's a little corny, but you can't make the world a better place if you're always looking over your shoulder wondering if you're being corny. It's less than two minutes - you can spare that, right?

Kate

If you do any SharePoint work, you need SharePoint Designer. If you're a developer, you probably got it through an MSDN subscription. But is there someone in your company who doesn't use Visual Studio and other developer tools, just some designer-oriented ones? Now that person can have a copy of SharePoint Designer - it's become a free product. Why? There's a video interview that explains the team's thinking on SharePoint as a platform, and making it simpler to build around it.

Download it here, and enjoy!

Kate

I spend a lot of time at a keyboard and screen. Most of the time, I'm working. I might be writing code or a document, reading something to better myself, reading something because it's my job to review it, watching a video or screencast, triaging bugs in TFS, or of course processing email. Some of these tasks involve a lot of typing, others mainly mousing, and some involve sitting almost completely still with the occasional page-down or mouse click. Other times, I'm having conversations with family or friends, reading something for fun, or playing a game. These tasks also have the same spectrum of frantic-typing and clicking through to mostly passive consumption with the occasional click or keypress. And at still third times I'm doing what we might call family administrative tasks - seeing when the grocery store in a nearby town closes, checking the school web site for holiday dates, ordering something, renewing something, banking or billpaying - or business administrative tasks - including invoicing my clients. You can't tell, by looking at the back of my screen or listening to my typing and mousing, what I'm doing. You can't tell by where I'm sitting either ... I might be using Remote Desktop to access the computer where our book-keeping software is installed, or a server that needs to be configured, or a client machine so that I can reproduce a production problem.

So what? Well it isn't how work has usually been. Hundreds of years ago, if someone was working you could tell by looking at them. They had a hammer in their hand, or a paintbrush, or some other tool. Even a few decades ago, if someone worked at a desk by writing on paper it was easy to see what desk they were at, what papers were strewn around them. Reading the paper looked very different from checking the invoices. And of course, leisure never involved the same tools or locations as work. Now, not so much. Bill Buxton has an interesting article on just this topic. He's at Microsoft Research, and it pleases me to think that folks there are thinking about this. I look forward to a future time when people can get a better idea of what I'm doing and how interruptable I am, not just "you're always on your computer."

Kate

Jeff Atwood has a post on "five dollar words" where he discusses (and briefly defines) these three words.  They're helpful, all the more so if you know the concepts but never knew they had a name. Then in the comments people start to talk about Normalization, Instantiation, Canonicalization, Covariance, Deprecation, Atomic, ACID, SOLID and so much more. Many provide links (how did we ever live before Wikipedia?) and if not, well, you have access to a search engine I'm sure. Having these words lets you have conversations you couldn't otherwise have. Reminding yourself of the definitions every once in a while can't hurt.

Most of these are pretty straightforward to remember if you have some Latin and Greek - enough to know the scientific prefixes. For example idem means "same" and "potent" refers to power - the function always has the same power. Mutable means change-able (think about the word mutant) and im- negates that, so the value can't be changed. (Swapping in im- for idem- in the first word results in another perfect valid word whose meaning can be worked out from its parts.) I learned a lot of Latin and Greek prefixes in high school and university, and I'm really glad I did. I can't write a sentence in either language, but I can work out what a lot of "intellectual" words mean just by going through their parts.

Kate

I've heard people use the name "elevator pitch" for a concise answer to a question like "What do you do?" or "What is this company that you run?". I don't think that's a good use of the term. You pitch a specific project or idea (which might be "hire me" but might not.)  Answering a small-talk question isn't making a pitch. It does, however, have a lot in common with the elevator pitch - most importantly that you don't have very long at all. Hi, how are you, that's a cool shirt, where do you work, what do you do there - these aren't essay questions.

So you want a concise answer, so that at least you don't talk people's ear off and bore them. And it would be neat if your answer either led the conversation in a direction you'll enjoy, or brought you business, or both. Steve Pavlina has given this quite a bit of thought. It's a long blog post that leads down to 2 or 3 10-12 word sentences, but that's the thing with short statements - they take forever to write.

I've been working on this for a while with gregcons - what's our 10 word answer to what do we do? Generally I say "We solve people's problems. Sometimes we write them software, other times we give them advice on software deveopment or mentor them." If the person looks even vaguely interested I might elaborate, but often that's all the answer they needed. The process of finding this short answer for us, and the process ahead of me to continue to shorten it, does give useful insight into what parts of my job and what parts of this business matter the most to me. I highly encourage everyone whose answer is "all kinds of stuff!" to take the time to find the common thread rather than just listing off a whole pile of -ing verbs until the person who asked slips into a coma. For more on the "what is my real underlying business" (as opposed to the skills you happen to ply in support of that business) you might also want to read a year-ending post from Mike Gunderloy that's just as valid at this time of year.

Kate