JoeBork's Weblog

So Long, and Thanks for All the Fish

joebork — Thu, 05 May 2005 02:59:00 GMT

To say that I have been remiss in maintaining my weblog here would be a serious understatement. Whether or not I've been a meaningful contributor to MSDN Blogs (and by essentially every metric, I have not), I have enjoyed reading the entries of other bloggers here, and I have certainly learned a lot from them.

Today is my last day at Microsoft. For a variety of reasons, I have decided to leave and pursue other (as-of-yet undetermined) adventures and challenges. My three years here have been, at times, both tumultuous and rewarding. I have been privileged to work with some of the most intelligent and passionate people I have ever met and it is those people that I will miss the most.

For those interested, you will be able to contact me at joe@headblender.com. Good luck and thank you.

Give the Visual C++ for Devices guys some love

joebork — Sat, 06 Mar 2004 04:56:00 GMT

A couple of my teammates on the VCD team, Josh Heitzman and Jeff Abraham, also have blogs. If you're a current eVC user and you want to know more about the integration of the native development tools for devices into Whidbey, these are the guys to talk to.

Josh has a couple of great entries today; one is about native support in the upcoming MDC community drop of Whidbey that will be available soon, and the other one provides answers to recent native device development questions his readers have asked.

Also, I'm pretty late in mentioning this, but Jeff has been soliciting feedback on how native project deployment should work in Whidbey. If you have any thoughts on the matter, Jeff and the rest of the VCD folks would be glad to hear them.

Three quick tips for reporting GUI bugs

joebork — Sat, 06 Mar 2004 04:16:00 GMT

This entry doesn't have any deep insights into software testing in general (or even GUI testing specifically), but I'd like to share some simple tips that can come in handy if you're reporting a GUI bug. There's nothing particularly special about them but I'm always surprised at how many people don't know them, and they're all easy to use.

(Almost) Never send a capture of the entire screen

It's pretty well known in Windows that the “PrtScn” key will capture the current screen as an image on the clipboard. For a lot of UI issues, it's incredibly helpful to know exactly what someone is seeing on their screen rather than to try and have them describe it in detail. Since it's common to have systems running in pretty high resolutions these days (1280x1024 or higher, for example) a full-screen capture produces a very large image, both in terms of resolution and in terms of the size of the saved image.

Instead of using “PrtScn”, use “Alt+PrtScn” instead. This will capture only the window that currently has focus instead of the entire screen. Of course, if you're taking a capture of a maximized window, or if you need to capture overlapping windows, this won't help you. In general, try to capture the smallest amount of the screen that is helpful in describing the problem. Windows still comes with Paint (or “Start | Run | pbrush.exe” as I like to think of it), and Paint has a very simplistic cropping tool.

Save screen captures in PNG format, not in BMP or JPG format

Since at least Windows 2000, Paint has had the ability to save files in PNG format. This is the best image format for sending screen captures for two reasons: It is compressed, unlike BMP (which can result in huge file sizes for high resolution displays in 24- or 32-bit color depths), and it's compression algorithm is lossless. The latter means that PNG files will generally be larger than the corresponding JPG file, but JPG compression is lossy, and for some kinds of UI bugs that deal with pixel-level details, the compression artifacts introduced by the JPG compression can do more harm than good in trying to determine the root cause of the bug.

Send the message text of an error dialog instead of a screen capture

This is the least-well-known of the three tips. For almost all of the error dialogs that Windows applications generate, it's very simple to capture the text of the dialog in lieu of an image of the dialog window. It's very simple: when the dialog box has focus, press Ctrl+C to copy the text of the dialog to the clipboard. Windows even formats the text nicely, so you'll get something that looks like this when you paste:

---------------------------
Paint
---------------------------
Save changes to untitled?
---------------------------
Yes No Cancel
---------------------------

Being able to send the actual text of the error dialog has a lot of advantages: It avoids transcription errors (particularly helpful when reporting some arcane error messages with hex error codes or exception typenames), it's even smaller than the PNG image of the dialog would be, and it makes it much simpler to search for other reported bugs with similar error messages.

So there you go. No great philosophical discussions, but at least you have a few concrete, practical tips. If you're a beta tester and you keep these things in mind when reporting bugs (either via the public newsgroups or Betaplace), I guarantee that the people who will be following up on your bug reports will appreciate it.

Why hobbyist programmers matter

joebork — Thu, 04 Mar 2004 07:02:00 GMT

Rory asks the question, “Should the hobbyist programmer matter to Microsoft?” His answer, basically, is no, saying “I would prefer to think that Microsoft is going to continue to do what it's been doing for the past few years: Refine the development tools and technologies so that they make more and more sense to developers, rather than worrying about whether or not they make sense to niche markets.”

I respectfully disagree; I believe that Microsoft has an undeniable responsibility to the hobbyist programmer. There are a lot of reasons why this is so, but the most important one is this: The hobbyist programmers of today are the professional developers of tomorrow.

Perhaps my disagreement stems from a matter of semantics. Depending on how you define “hobbyist programmer,” you'll get wildly different groups of people. To me, “hobbyist” is painting with a wide brush -- anyone from a student doing a homework assignment to a businessperson who writes Excel macros can probably fit somewhere into the “hobbyist” bucket. I cut my programming teeth on QuickBasic 4.5 and Turbo Pascal 5.5 when I was in school, and one of the things that made these tools so appealing was they did a good job of satisfying the needs of hobbyist and professional developers alike.

There are several factors that make successful tools for the hobbyist programmer. Certainly the cost of development tools is one -- there's a reason that tools like Eclipse and SharpDevelop are fairly popular. But more importantly, having a toolset that makes it easy for a hobbyist to be productive is vitally important. There are a lot of people for whom a development tool (and programming in general) is not a journey but a means to an end. Building tools that make it dead simple to give people a taste of success in solving their problems is enormously important. The success of the .NET platform depends on the success of .NET developers, professional or hobbyist, and we need to make sure that Visual Studio is always getting better at helping developers be successful (and happy!).

Many so-called “hobbyist features,” like wizards and designers, can be useful to developers of any variety. Even if you're a professional developer, is it worth your time to manually crank out hundreds of lines of code to wrap your DataSet in a strongly-typed class when you can get a typed DataSet essentially for free using a wizard? It's tempting to try and draw a bright line between tool features for professional and hobbyist developers, but the reality is that the distinction is blurred. As the demands on a developers time increases and as the complexity of software grows, this line will become even less distinct.

Everything else aside, for me the desire to see Microsoft “worry” about hobbyist programmers is a personal one. Coming from such a hobbyist background, I want to see us excite and encourage other hobbyists as much as possible. And then we should hire them as software testers, and give them all window offices, Tablet PCs, and Smartphones. (But that's just my opinion...)