Most software engineers that I've talked to over the years believe that the mind-set and personality of a good software tester are different from those of a good software developer. This idea is somewhat important. Finding good software testers at a company like Microsoft is very difficult -- on any given day, Microsoft has well over 500 open job positions for software testing -- and understanding what make a good software tester can help find and develop SQA engineers. Well to cut to the chase, I performed a lightweight, preliminary study which compared the personality traits of several hundred software developers, software testers, and non-software engineers. Because my study was just a first investigation I cannot state with certainty any strong conclusions, but I did find strong indications that there are in fact significant differences in personality traits between good developers and good testers. For example, testers tend to be more experimental and more methodical than developers. Anyway, I've written up a paper on my study and will be presenting my results next month (June 18-21) at the Better Software Conference and Expo in Las Vegas. See http://www.sqe.com/BetterSoftwareConf/ for details. Looking at the bigger picture, it's well known that the number of computer science graduates at U.S. universities continues to decline. It is not an exaggeration to state that nothing short of U.S. technological supremacy is at risk. See for example an article that describes how universities are seeking computer science students at http://seattlepi.nwsource.com/business/1700ap_reprogramming_programmers.html. And see also an article about how difficult it is for companies like Microsoft and Google to find software engineers at http://seattlepi.nwsource.com/business/317557_google29.html. My parent company, Volt Information Sciences, places thousands of contract and full-time software engineers at Microsoft and other companies, and Volt definitely feels this pain. Understanding the psychology of good software testers may help recruiting.

I got a FlipStart yesterday. FlipStart is a new Ultra-Mobile PC (UMPC) device. It's an extremely small (about 6" by 5", by 1.5" tall) essentially complete PC running Windows XP. See the photo at the bottom of this blog entry. I've read a hand full of reviews which approach FlipStart from the perspective of a person who travels a lot (a sales person for example), but I'm looking at FlipStart from the perspective of a software engineer who sometimes travels. My basic question is: "In which situations (if any) will I want to use FlipStart rather than one of my regular laptops?" So, over the next few days, I'm going to experiment by attempting to install and use my standard suite of geek software -- including Visual Studio 2005, SQL Server 2005, and Windows PowerShell.

 

But before I go technical, here are my first subjective impressions. First, the physical form factor. At an initial glance FlipStart does not have an ultra slick look; it's kind of chubby, especially compared to its competitors. But after using the device by holding it in both hands and by placing it on my desk, I actually like the relative thickness. The FlipStart is a matte black color (as opposed to silver) which also isn't currently in vogue for chic gadgets. The main usability issues with any UMPC are screen, keyboard, and mouse pointer. The screen is about 4.75" by 2.75" (or about 5.5" diagonal) which is really, really small. My eyesight isn't that great but I have no problems with the FlipStart screen. FlipStart has a built-in eraser-style pointer device and two very handy left-click, right-click buttons. However, I had trouble getting the built-in pointer to position exactly on screen icons because the icons on the screen are so small. But FlipStart has a small (about 1.5" square) touchpad which works very well. FlipStart has a neat port replicator that plugs into the back, and I put a USB mouse there and much preferred that approach. The keyboard does not lend itself to touch-typing -- the keys require quite a bit of oomph. But I am a really bad typist so (like any keyboard) you'll have to try it yourself.

 

So, what's the initial-impression bottom line? The FlipStart packs full laptop-like functionality into an amazingly small package. So far, I like what I've seen. FlipStart is quite pricey -- about $1999. I have every reason to believe that the FlipStart which host Visual Studio and SQL Server, but after that, the FlipStart's ultimate usability for me personally will depend entirely on subjective factors that I'll just have to experience.

In a recent series of blog posts, I described how to write a custom COM object using C++ and the ATL wizard in Visual Studio 2005, and then how to call the COM object using classic C++, JavaScript and VBScript, and C#. In this entry I'll show you how to call the COM object using Windows PowerShell. My COM component is named MyMathLib and contains a class ("coclass") named MyFuncs which in turn holds a single method -- Sum(x,y) which just returns the sum (result of addition) of two long ints. Let's suppose that my COM component project is saved in a root directory arbitrarily named VS223.

 

PowerShell is Microsoft's new command shell and scripting language. You can think of PowerShell as a dramatic upgrade to the old cmd.exe shell and .BAT files. PowerShell is currently a separate install and is available for Windows 2000, Windows XP, and Windows Vista. PowerShell will ship as part of the upcoming Windows Server "Longhorn" in a few months. Let's see how to call MyMathLib interactively. Launch an instance of PowerShell. Issue a "set-location \" command to change the working directory to the system root, then issue a "clear-host" command to clear the screen. (You can also type shortcuts "cd \" and "cls"). Now type:

 

PS C:\> $obj = new-object -comObject 'MyMathLib.MyFuncs'
PS C:\> $obj | get-member
PS C:\> $ans = $obj.Sum(4,8)
PS C:\> $ans

 

The first statement instantiates an object $obj as an instance of the MyFuncs class which is part of the MyMathLib namespace (realized as MyMathLib.dll). PowerShell objects/variables are preceded by the '$' character. The new-object is an intrinsic PowerShell cmdlet ("command-let"). There are about 130 intrinsic cmdlets and they form the heart of PowerShell functionality. The second statement pipes the $obj object to the get-member cmdlet, which will display the available methods in $obj. The third statement calls the Sum() method and assigns to variable (actually an object) $ans. The fourth statement displays the value of $ans (I could have explicitly typed "write-host $ans" too). Using PowerShell to call classic COM components is very clean and very easy. In addition to using PowerShell interactively, I can also write PowerShell scripts to call COM objects. 

In a recent series of blog posts, I described how to write a custom COM object using C++ and the ATL wizard in Visual Studio 2005. My COM component is named MyMathLib and contains a class ("coclass") named MyFuncs which in turn holds two methods -- Sum(x,y) and Product(x,y) which just return the sum and product (result of multiplication) of two long ints. Let's suppose that my COM component project is saved in a root directory arbitrarily named VS223. In previous blog entries I have shown you how to call the Sum method of the MyFuncs class using classic C++ native code, and from JavaScript and VBScript scripts. In this blog entry, I will show you how to call the COM object using C# managed code. Launch a new instance of Visual Studio 2005. Do a File | New | Project. Choose the Visual C# Project Type, and select the Console Application template. Save at any convenient location (say, C:\VS223) with any convenient name (say, CSharpDriver) and click OK. In the Solution Explorer window, right click on your project, and select Add Reference. In the Add Reference dialog box, select the Browse tab, then navigate to the MyMathLib dll file and click OK. Basically you have told Visual Studio you want to use the DLL file. Now modify the VS-generated code to get this:

 

using System;
namespace CSharpDriver
{
  class Program
  {
    static void Main(string[] args)
    {
      Console.WriteLine("\nBegin COM test\n");
      MyMathLibLib.MyFuncsClass mf = new MyMathLibLib.MyFuncsClass();
      int val1 = 5;
      int val2 = 4;
      int answer = mf.Sum(val1, val2);
      Console.WriteLine("Five plus four is " + answer);
      Console.WriteLine("\nEnd test");
      Console.ReadLine();
    } // Main()
  } // class Program
} // ns

 

Compared to calling COM using native C++, the .NET environment greatly simplifies using classic COM. The key line of code is:

 

MyMathLibLib.MyFuncsClass mf = new MyMathLibLib.MyFuncsClass();

 

Notice that Visual Studio calls my namespace MyMathLibLib (appending a "Lib"), and that .NET identifies the MyFuncs coclass as MyFuncsClass (appending a "Class"). Here I instantiate an object named mf, which is type MyFuncClass, and which is a friendly face to my actual underlying COM interface/component/class. I could also have declared mf as an Interface (MyFuncs). Once instantiated, I can call the Sum() method just as I would a non-COM method.