XMLSerializer, part 2

After spending more time fixing bugs and digging into XMLSerializer (see my previous post), I've come the the following conclusions:

1. I'm still satisfied with my design where I split the "data" into a separate class. It makes it much easier to quickly see what is being serialized and what is not. If I hadn't done this, I would have reorganized the fields in my objects to put all the serializable fields together, so I could put all the unserializable fields (with their corresponding noisy attribute tags) in a separate section of the class definition.
2. I figured out my problem (mentioned in bullet item 3 in the previous post). I had not provided a default value for an enum in the class definition. Once I did that, the uninformative error message went away and my object was sitting happily on disk.

On to the next learning experience...

Dealing with .NET XMLSerializer

I've found that the clearest (e.g., fewest lines of code) and quickest (e.g., fewest surprises) way to deal with XMLSerializer is to create "data" classes. These instances of these classes are then owned and used by instances of "code" classes. This gets around the following issues:

• XMLSerializer will only serialize Public fields. It isn't good programming practice to have to declare fields as public. To reduce this ugliness, I moved the serializable fields down into the data class and made the reference to the data class Private. I then put Public Property(s) on the code class that reference the field in the data class.
• XMLSerializer doesn't support hashtables, which I find much more useful (and natural in many cases). I used hashtables on the code class. I then added code to a GetSerializable method that sits on the code class that populate the corresponding array on the data class on demand.
• XMLSerializer doesn't provide very good error messages. My first attempt at changing a class to user XMLSerializer hit many problems with many different fields in the existing class. Using a data class, I don't have to figure out all the problems all at once. I can move fields from the code class to the data class incrementally, and figure out the particular problem with that field before moving on to the next. One specific example of this are issues with using Public Property. I haven't figured out what they are yet, but I'm suspicious of either:

• Public Properties that aren't simple "return" and "assignment" Properties.

  Public Properties that wrap a field that is also Public.

The downside is that I have a few extra public fields on various objects that are only used for serialization. The upside is fewer lines of code and a (somewhat) straightforward paradigm for dealing with XMLSerializer.

Thank you, EasyBCD!

And I don't mean Binary Coded Decimal.

I recently set up a test machine with a dual-boot XP/Vista configuration. Being the cautious type, I went to make a disk image of the Vista side. That is the side I would be using for testing, and would need to be able to quickly and easily restore it to a clean state (e.g., not have to tediously reinstall Vista each time).

I first tried an old version of DiskImage. Nope, won't run off an NTFS drive and I have no floppy in that machine. Toss the CD and recycle the manual.

Next tried a 2003 version of Norton Ghost. Things seemed to go well for a while, but went south really suddenly. I believe that it choked when it tried to deal with the Vista BCD (Boot Configuation Data) stores. Toss that CD and recycle that manual.

Trying to then reinstall Vista failed repeatedly because the reboots kept trying to reboot a corrupted operating system. I couldn't get to the BCD data from the XP side until some Googling turned up EasyBCD, which saved my sorry butt. Now I'm re-installing Vista.

I think I'll next try Ubuntu with PartImage to back up the disk image. I've paid Symantec enough money over the past few years.

Cassandra, Take a Bow

I've always considered myself a realist. Some may call me a pessimist, but many of my predictions have turned out correctly. I don't like being seen as negative, so I do try to lighten up a bit. This led to an amusing incident at my current job.

After telling my boss a number of times that I thought an expectation was too optimistic, I decided to tell him the legend of Cassandra (because I was starting to feel like the prophet-not-listened-to). After I told him the story, I told him (jokingly) that I considered myself the Cassandra of my group.

A couple of days later, my business phone rang. I get very few calls on that line, since my group tends to use GTalk if possible. I therefore get a higher percentage than usual of wrong numbers. I was in the middle of debugging something, so I was focused on that task rather than the phone call. I picked up the phone and someone said, "Is Cassandra there?"

I almost hung up, but decided to be polite and ask the person what number they dialed (expecting that it was a wrong number).

It was my boss. Given my past history with him, I should be careful what I ask for, because he does have a keen sense of humor.

A more reliable test bed

I've been working on putting together a test bed for the product that my company currently offers. My first cut at the test bed used AutoIt to drive the GUI and NUnit for the testing framework. This worked, but I felt it was too fragile (and perhaps too complex) for our QA folks. I therefore wrote an embedded test framework using my simple command parser that worked better.

First, it didn't require multiple executables (e.g., a separate application to drive the GUI using AutoIt). This reduced the complexity of the system, which was immediately reflected in the amount of documentation and support I had to produce.

Second, one can go off and do other tasks (e.g., read email) while the tests are running. This happened because the test bed no longer sent mouse and keyboard events to the application, so there was no contention for those resources. Responsiveness isn't what I would like, but that's the price I pay (until I get a machine with a multi-core CPU). Note that the window of the application running the tests may come to the top, so you may lose keystrokes if you are typing into another application. This shouldn't, however, interfere with the tests. E.g., the application with the embedded test-bed should ignore those keystrokes.

Third, I realized that this does away with synchronization issues. I am intimately familiar with the problems of dealing with variable wait times. For example, when using a GUI driver such as AutoIt or Silk, the testing application that drives the GUI may need to wait for a network to respond or for a long-running calculation to finish. It is usually unclear how long to allow the GUI driver to wait before assuming that something went wrong. Since this framework is "synchronized" with the application, this issue just disappeared. Admittedly, I should probably add some "time-out" feature (in the future) to handle any hangs, but I'll wait for the QA folks to ask for that before I put any effort into it.

Fourth, since there is no need for the test framework to wait, the test sequence will run faster.

The downside is that adding more tests requires some coding in the application. This, however, is usually straightforward. I find where the event from the GUI is handled and add a little hook function to call that same code, with parameters as necessary.

It's a pleasant suprise to have some positive unintended consquences, instead of (more common) negative side effects.

Ageism?

Don't bother applying for a job at Facebook if you got your college degree before 1980.

The dropdown for "Graduation Date" on their job application doesn't go back that far.

Addendum:

In an industry survey, a majority of technology companies candidly said they would not hire anyone over 40.

New York Times, article in "This Week" section on June 22, 2008, titled "For a Good Retirement, Find Work. Good Luck."

Today's lesson...

I went searching for a line continuation character in DOS. I needed to make my CMD scripts more readable (if such scripts can ever be made readable - I'll use Ant next time). Searching around I found that the caret ("^") was supposed to be the continuation character. I tried it and it didn't work at first, until I realized that I was using it in the middle of a quoted string.

Re-jiggered the long command to put the caret(s) outside of quoted strings and it works like a champ. Not that I want to claim to be an expert in CMD scripts...