April 18, 2008
Google Maps vs. MS Clearflow: Traffic information
This morning I checked out the traffic information now available from Google (http://googlesystem.blogspot.com/2008/04/google-maps-predicts-traffic-conditions.html) and Microsoft (http://maps.live.com/).
As usual, the Google interface was pretty and easy to use. The text and map were crystal clear and sharp, and the color-coded traffic indicators were clean and easy to interpret. The traffic prediction controls were simple and intuitive.
The problem? I don’t believe the data for Seattle. At 8 am on a Friday, 520 was showing “green” (>50 mph) all the way across. No matter how I played with the predictor, I could not get the 520 to show up as anything but green. And anyone who’s tried to head to/from Redmond during commuter hours will tell you that’s just impossible. Also, there weren’t any traffic incidents in the city – I guess it’s possible, but seems improbable. Finally, on the annoying front, I wanted to refresh the traffic information, so I hit the refresh button – and the map recentered from Seattle to Washington, DC. Ok, that’s just irritating.
On the other hand, the Live Search Maps don’t give nearly as good an initial impression as the Google Maps. At a comfortable zoom level (adjusted so that I can see I-5 on the left edge and I-405 on the right, SR-520 at the top and I-90 at the bottom), the text and map lines are slightly fuzzy. The traffic indicators look sloppy, as if they were drawn by a kid with a magic marker. The key for interpreting the traffic indicators is barely visible in the lower right-hand portion of the screen; same for the scale. Also, the key just tells me relative slowness; it doesn’t give me any information about what “black” or “green” mean in concrete terms.
However – at least I believe the information that Live is giving me! At 8 AM, 520 eastbound shows up solid black (the slowest indicator) all the way across the Evergreen Point bridge. Now that sounds more like it.
Unlike Google Maps, there doesn’t seem to be a way to predict traffic with Clearflow. I did try using the directions feature of Clearflow, which is supposed to route you around traffic situations if you ask it to, but it didn’t appear to have any effect for the destinations I chose. Too bad, since that seems like it could be a really useful feature.
Also, in general, I prefer Google Maps’ mapping and directions functionalities over Live Search Maps for three reasons. First, Google Maps is a lot less picky about addresses and consequently requires less input from me. Second, after getting directions with Google Maps, I can edit the origin/destination without having to click a link or go back to the original web page. And third, with Google Maps, I can drag the route to customize it to use or avoid certain roads.
Bottom line? I wish I had a way to combine Google’s useability with Clearflow’s accuracy. As it stands, I currently wouldn’t use the Google app at all (what use is it, if the information is not reliable?). I might consult Clearflow in a pinch, just for traffic information, but I would still use Google Maps for mapping and directions.
November 14, 2007
CWMPPlaylist::removeItem crashes with DRM-protected content
But, you can use the COM interface (IWMPPlaylist::removeItem) without problems. It nicely returns an error code instead of yakking. Remember that the friendly generated CWMP* classes are just wrappers around the underlying COM interfaces.
So, if you currently have code something like this (code stupidified to save space):
CWMPPlaylist playlist = CdRomCollection.Item(0).GetPlaylist();
CWMPMedia track = playlist.GetItem(0);
playlist.removeItem(track);
To circumvent the crash, you can replace it with code like this:
CWMPPlaylist playlist = CdRomCollection.Item(0).GetPlaylist();
CWMPMedia track = playlist.GetItem(0);
CComQIPtr<IWMPPlaylist> pPlaylist = playlist;
CComQIPtr<IWMPMedia> pTrack = track;
HRESULT hr = pPlaylist->removeItem(pTrack);
Note that we’re using CComQIPtrs here, so they’re going to implicitly call QueryInterface on the IDispatch member of the COleDispatchDriver-derived class. This is pretty neat, actually – COleDispatchDriver does not implement IUnknown, so you can’t QI on it, but it overloads the LPDISPATCH operator to return a pointer to its IDispatch object, which does implement IUnknown.
November 5, 2007
Quality Assurance Personality Archetypes: The Alarmist*
I’ve been working in Software QA or Software Development for 10 years now, and some days it seems like I keep encountering the same personalities over and over. Different job, different products, different people – but the same personality quirks.
One of the more frustrating QA personalities to deal with is the Alarmist. To the Alarmist, every bug is an enormous emergency, regardless of context, stage of the development cycle – or reality. Despite having a defined process for bug reporting, the Alarmist likes to circumvent that process by sending inflammatory emails to upper management. These emails are laden with panicky language and technical detail (often inaccurate) and frequently are cc’d to everyone remotely associated with the project. Within two minutes of receiving the email, the manager is breathing down a developer’s neck, distressed and confused. The Alarmist is equally likely to be agitated about minor bugs as about major ones, but the same level of alert is raised for virtually all bugs encountered.
The Alarmist knows that he is picking a fight. I wonder if the Alarmist also starts flame wars in his free time and moonlights as a troll?**
How to cope with the Alarmist:
1. Respond to all relevant parties with a calm, measured email describing what actions are being/have been taken to deal with the issues. Emphasize that the issues are already being handled (or will be) through existing channels, and be specific (include bug report numbers or history, etc.). Counter the Alarmist’s hysteria with reasoned statements of fact. You may want to do this from the nearest coffee shop in order to dodge the inevitable series of boss visits/phone calls…
2. If the Alarmist is persistent in circumventing the chain of command, you may need to address the issue with his management chain. One way to handle this is by framing it as a discussion of process improvement – is the Alarmist continually inflating issues because too many of them are falling through the cracks otherwise? You may even be able to identify and improve some real problems in your process.
*Yes, this post brought to you courtesy of a recent encounter with my team’s resident Alarmist.
**I’ve worked with both male and female Alarmists. The use of the masculine pronoun is by no means meant to imply that the Alarmist is always male.
October 28, 2007
Tracepoints and Incremental Search in Visual Studio
These are undoubtedly the two hugest time-saving Visual Studio features that I use the most. Tracepoints are new to Visual Studio 2005 (I think); incremental search has been around for a while.
To create a tracepoint, simply right-click on any breakpoint and select “When hit” from the context menu. You’ll get a sub-dialog that allows you to specify a message to be output when the breakpoint is hit. There are also a bunch of variables that you can use to trace contextual information, like the function name, thread ID, or callstack. And you can trace any variable in scope when the breakpoint is hit by enclosing the variable name in curly brackets.
Incremental search allows you to find text matches in the current source file as you type. Press CTRL-i and start typing the text you’re looking for. With each keystroke the focus will leap forward to the next text that matches the string you’ve typed so far (the string is displayed in the status bar, by the way). Press F3 to jump to the next piece of text matching the search string. CTRL-SHIFT-i does the same thing backwards through the file. It takes a little while to get used to using CTRL-i over a find in file, but once you get the hang of it you’ll wonder how you ever lived without it.
February 13, 2007
Find in Current Project: No files were found to look in.
It’s possible (no idea how this happens) to get the VC8 IDE into such a state that whatever text you try to find, it reports “No files were found to look in.” This occurs even if you have perfectly legitimate file extensions and search paths set, and there are files matching the file extensions present in the search paths.
Bizarrely, to get out of this state, simply press CTRL + Scroll Lock. You don’t need to actually have the find dialog open when you do this. Just press the key combinations and subsequent find behavior will be restored to normal. Weird, I know, but at least it’s fairly painless…once you know the magic trick.
February 6, 2007
Rich Edits in VC8
The resource editor in VC8 automatically creates rich edits as type RichEdit20A. If you’re compiling your project UNICODE, this will cause some of the rich edit functions (like FindText(), for example) not to work properly. This can be a subtle effect, though, because ASCII strings will still display properly in the rich edit, causing it to look like it is working properly.
The solution is to modify your .RC file in a text editor and change the type from RichEdit20A to RichEdit20W. What to do if you have to compile both UNICODE and MBCS? Er… I’ll get back to you on that. Fortunately for me, I don’t have that problem.
Note also that .RC files built in VC6 will most likely define rich edits as RICHEDIT, not RichEdit20*. This means you’ll wind up using Rich Edit 1.0, not 2.0 or 3.0. So if you’re upgrading a project and need the features of a later version of the rich edit, make sure you manually edit your .RC file to use the correct type. Also, Rich Edit 1.0 does not support Unicode, so if you want to display Unicode text, you should move to Rich Edit 2.0 or later. If you move from 1.0 to 2.0, don’t forget to change your initialization call from AfxInitRichEdit() to AfxInitRichEdit2().
Here are a couple of interesting blog posts about the Rich Edit:
A brief history of its development
Rich Edit features and availability by version
January 29, 2007
Make #pragma message more useful
Am I the only one who ever wished that I could double-click on a #pragma message’s output and have the source file open automatically at the source of the message? Here’s a macro that you can use to accomplish this:
#define STRING2(x) #x
#define STRING(x) STRING2(x)
#define FILE_LOC __FILE__ “(” STRING(__LINE__) “) : “
Usage:
#pragma message(FILE_LOC “Your message here”)
When compiling, this will generate output like:
c:\My Projects\MyFile.cpp(27) : Your message here
When you double-click on the message, MyFile.cpp will open to line 27. Note that this is IDE-dependent – it relies on mimicking the format that Visual Studio uses for build warnings and errors. I’ve used it in Visual Studio 6 and 2005; your mileage may vary in other IDEs.
December 22, 2006
Beware _tspawnl!
I was writing a little application that assists in the install/update process for an embedded product. Once the product has been installed/updated, my application has to launch the application and another support application. Because we’ve been experiencing a lot of failures in the update process, my application does extensive logging to a file on the hard drive.
In testing, I was running across two or three problems that seemed unrelated. First, sometimes only one of the two applications would launch, even though the _tspawnl calls both appeared to be executed. Second, my log file was never cleared, even though the code to clear it also appeared to execute successfully. And third, even though I could infer that the appropriate calls were being made – because they were not conditional, and the application was running to completion successfully – all those calls performed logging, and the log statements weren’t showing up in the log. Placing message boxes in critical locations caused the programs all to behave properly, and all info to be logged properly.
Long story short (oops, too late), the problem was a “feature” of _tspawnl. When a process is creating by _tspawnl, that process inherits all open handles from the creating process. That means if you have open thread or file handles, the created process gets ‘em, too. Which means a number of potentially ugly things could happen, if you’re not counting on it, from deadlocks to race conditions. And, unless your created process actually knows about all those open handles and is prepared to deal with them, you’ll probably have memory leaks, too.
There are at least two distinct ways to solve this problem. The first is to create your files as “uninheritable”. This can be done using CreateFile or by using MFC’s CFile-derived objects. The second is to use CreateProcess instead of _tspawnl, and set the bInheritHandles flag to FALSE (if you look at the source, you’ll see that _tspawnl always forces it to TRUE). I think the CreateProcess solution is better because it prevents you having to worry about any of the open handles your creating process might have. Creating the files themselves as uninheritable only solves the problem for those file handles, not for any other handles you might have hanging around.
Of course, the moral of the story is, “Read the fine print on MSDN”.
December 6, 2006
Short file names – did you know?
When you change the long file name of a file, the short file name does not change. So if, for example, you were loading a DLL using the short file name, and you wanted to replace the DLL to run a test, so you renamed the original and copied in the new one with the correct long file name…well, you’d still be using the original DLL, since its short file name didn’t change.
