Michael Hunter and I headed over to building 40 this week to interview Ivo Manolov, the test manager for Windows Presentation Foundation. Ivo has some great insight on what it takes to be a great tester.
We're trying out these videos on Channel9 instead of just on MSDN Tester Center. Feel free to leave a comment on the video if you have thoughts about the switch.
http://channel9.msdn.com/posts/Charles_Sterling/Ivo-Manolov-Interview-Test-Manager-for-Windows-Presentation-Foundation/
Are you going to PDC this year? Be sure to stop by some of the Connected Systems Division talks to hear about the project I work on. There are plenty of people more qualified than me to give the talks, and that's just fine with me. I'll be hard at work back here in Redmond making sure you have a great experience. We're all very excited to show you what we've been working on!
[List copied from Chris Sells's blog.]
I'll admit that prior to coming to Microsoft, I rarely clicked "Send report to Microsoft" when something would crash, and I never participated in the customer experience improvement option when offered. Now that I'm participating on some teams that deal with servicing the product after it's released, I see how valuable this data really is. They've gotten extremely good at dealing with those crash dumps in the error reports and the usage data from the customer experience improvement program. So please send us that data! It's really useful and will help make our products even better! Even if you think you've submitted the same one before, submitting it again is a pseudo vote for getting it fixed.
I have been meaning to make a post listing out the blogs of some of Microsoft's senior testers, and I was reminded of that task today when I found out that James Whittaker has started blogging. If you're interested in testing, these are great places to see inside the minds of some of the industry's best testers!
James Whittaker
Alan Page
Michael Hunter
Keith Stobie
If you want more from these guys, we are all part of the Tester Center team so you can keep an eye out for articles and videos there too.
Michael Hunter and I recently recorded an interview with Bryan Lipscy, a tester on the Windows help team. I never thought about all the work that goes into testing the help system, but it's quite impressive. The video is currently on the front page of Tester Center or you can find it in the Tester Spotlights column.
Thanks to the team over at Microspotting.com for sending me an "I Am The Empire" t-shirt!
One of my favorite parts of my job at Microsoft is the wide variety of people that I get to interact with on a daily basis. Want a meet a guy who toys with buying a hovercraft? How about the guy who wrote a bunch of the code books on my shelf? What about a competitor in national foos ball championships? I can introduce you to all of them.
There's a blog called Microspotting that takes time to profile a few of the people who work for our company. If you come work here, maybe you'll work with a member of Harvey Danger or the former Technical Director of Farts and Explosions for South Park.
We recently ran into an interesting issue with our installer which requires elevated permissions to run on Vista SP1. The installer wrote registry entries to HKCR. This is a virtualized hive and the entries are actually written to HKCU. When we ran the app with elevated permissions, the app could not find the entries in HKCR. This is because elevated processes do not see the per-user entries and can only see COM registrations in HKLM\Classes for security reasons. When we changed the installer to write to HKLM instead of HKCR, everything worked fine. However, this means that we cannot do a per-user install when the installer runs with elevated permissions. If you're dealing with strange COM issues when running elevated vs. non-elevated, you may want to look into this.
MSDN has more information.
Here's a quick testing tip: make it as difficult as possible for your test to pass. Otherwise, a failure to fail may be reported as a success and mask a real problem. For example, if your method returns non-zero for a failure, initialize your result code to a non-zero value and only set it to 0 when you're positive that everything has finished and worked correctly.
I recently had the pleasure of meeting both Michael Hunter (the Braidy Tester) and Rob Straavaldson to videotape a Tester Center Spotlight interview. You won't see me on the video, but those two guys are much more interesting than me anyway. I'm lining up some more of these videos and will hopefully be getting them posted through the summer.
The video is currently highlighted on the front page of the Tester Center, or you can find a permanent link to Rob's interview here on the spotlight videos page.
If you haven't read the question yet, you can read it here.
The answer for this lies in the C# specification. Specifically, read section 8.13. There are two different ways you can use a using statement and in this case we are interested in the second way. The key words from the spec are "in this case ResourceType is implicitly the compile-time type of the expression, and the resource variable is inaccessible in, and invisible to, the embedded statement."
So effectively what the code in our question means is:
Foo x;
using (/*y =*/ x = new Foo())
{
} // this calls y.Dispose();
In this example, y is effectively the copy of x that is made so that x becomes inaccessible and invisible to the embedded statement. If Foo is a reference type, you don't really see the difference because x and y point to the same type. However, if Foo is a value type, it is actually making a copy of the value and you're dealing with a completely different memory location.
This brain teaser also comes courtesy of Simeon Cran.
What will the following code output? When you think you know, copy the code into Foo.cs and run “csc Foo.cs” and then run “Foo.exe”. Did it output what you expected? The brain teaser is to come up with the correct explanation for why the program outputs what it does.
using System;
struct Foo : IDisposable
{
bool disposed;
public void Dispose()
{
disposed = true;
Console.WriteLine("Disposed");
}
static void Main(string[] args)
{
Foo foo;
using (foo = new Foo())
{
}
Console.WriteLine(foo.disposed);
using (foo = new Foo())
{
foo.Dispose();
}
Console.WriteLine(foo.disposed);
}
}
Have read the question yet? Read it here.
- The problem is pretty simple if you have 00111 (where all the bits after the first 1 are also 1’s.) You shift right, run the NOT operator, and then AND that result with the original. For example:
ORIGINAL = 00111
SHIFT RIGHT = 00011
NOT = 11100
AND with ORIGINAL = 00100
- The question now becomes, how can I take a number like 001xxxxxx and make sure all those subsequent values are 1? Well if you take 001xxx, shift right 1 and OR, you’ll have 0011xxx. Then shift right two and OR and you’ll have 001111x. Make sense? Shift by 4, then 8, then 16, 32, 64 and you’re done.
Here's the code:
// Clears all the bits on the given value except
// the leftmost bit that was set
static ulong KeepHighestSetBit(ulong value)
{
value |= value>>1;
value |= value>>2;
value |= value>>4;
value |= value>>8;
value |= value>>16;
value |= value>>32;
return value & ~(value>>1);
}
Congrats to Raj Kaimal for figuring this out!
This brain teaser comes courtesy of a co-worker named Simeon Cran.
Using C# and no branches, and no method calls, no allocations, and no unsafe code, write a method that takes a ulong and clears all the bits in it except the highest bit that was set. Use as few operations as possible.
e.g.:
0 -> 0
1 -> 1
2 -> 2
3 -> 2
4 -> 4
5 -> 4
6 -> 4
7 -> 4
8 -> 8
9 -> 8
10 -> 8
…
