Simple Software Scheduling

How about scheduling this way? When you're in the SWAG (Scientific Wild-Ass Guess) stage (or even later), just pick one of the following for each task:

1 day
1 week
1 month
1 quarter
forever

Note that there is no "year" category. If you think something is going to take a year you're not scheduling at the right granularity (and maybe even a quarter is too much).

C++ References "syntatic sugar" or not?

When I first learned about references in C++, I dismissed them as "syntactic sugar." That is, they are equivalent to

* const

See the Dan Saks article at http://www.embedded.com/story/OEG20010311S0024 for a good explanation. Lately, though, I've be re-thinking that stance.

I can now see how collapsing the * const into a & might make the code easier to understand. I say "might" because I can also see how it can cause confusion for beginners, since the "&" symbol is also used as the "address-of" operator. However, it does reduce the general confusion caused by pointers in more complex type declarations. such as

const SomeType* const varName

See Marshall Cline's article at http://www.parashift.com/c++-faq-lite/const-correctness.html#faq-18.5 for an explanation of how to actually read and understand these declarations.

The thing I still don't like about references is that they give no clue whether an object is a stack-based local object or a parameter passed into the method. I can always hope that whoever wrote the method kept it short enough so I don't have to keep scrolling up and down to look at locals and the parameter list. That doesn't, however, always happen. At least some Interactive Development Environments like Visual Studio allow you to hover over a variable to see its type. I haven't used Eclipse in quite a while, so I can't recall whether the various language plug-ins support it. I assume (or at least I hope) that it works for Java.

Who's Fooling Who?

This morning our San Francisco Chronicle didn't arrive by its appointed time, so I called the Chron's 800 number. I got the usual voicemail with voice recognition and started answering the prompts as instructed. After a few prompts I realized there was a subtle difference about the system. Instead of "dead air" while the system was processing my replies, there was the sound of someone typing on a computer keyboard.

I was vastly amused. Then (per my usual "look on the dark side" view of the world) I started wondering how many people actually believe they are talking to a human being. Or did the human interface guru or gurus determine that (even if customers knew that it was a machine) the sound made the interaction more pleasant? As I said, it made ME grin...

It is P. T. Barnum's "there's a sucker born every minute" or actual useful social engineering?

Yesterday's Minor Victory

A few years ago (31.Aug.2004, if GMail remembers rightly), I switched from AOL Mail to GMail. I still have my AOL account, as that is still the primary email for my wife. I also still monitor my AOL account to see where that email address has gotten to, either through my own actions or someone else’s. After the first few months of using GMail I had cleaned out almost all references to that address, but a couple eluded me. I kept getting email from Dartmouth College, where I got my undergraduate degree. I followed their unsubscribe instructions, only to get an automated response saying that the AOL email address was not in their list.

Yesterday I remembered an incident from a few years ago. I manage the email list (using Google Groups) for the United Parents of San Leandro, the PTA equivalent at our local high school. As an aside, I still do this, even though my kids are years gone from the institution. I do try to be a good citizen. At one point I got a list of email addresses from a former member of United Parents, supposedly of individuals who would like to get our emails. I added all those email addresses to the list. Within a few days I started getting emails from one individual threatening us with a lawsuit for spamming her. I went back and reviewed the list of addresses in the Google Group, but couldn’t find the address that this person was sending from. The threatening emails kept coming.

I then realized that this person could have set up a forwarding mechanism from some other email address. I went back to the list and searched for email addresses that were (in any way) similar to the return address on the threatening emails. I found one that looked somewhat close, and took it off the list.

The threatening emails stopped, and no one else complained about not getting their emails.

Coming back to the more recent past, I began wondering if I had put that AOL address as a secondary (e.g., forwarding) address for any other email address. I realized that Dartmouth did provide an email address for alumni, and went to check that. Voila. There was my old AOL address. I don’t know how long ago I put there, but I’ve used AOL since before 2001. I lost my emails previous to that year, so I don't know how far back they really go. I do, however, remember trying to get onto AOL with a 2400K Baud modem, and that must be further back than 2001. In any case, I put that AOL address into the Dartmouth system many years ago.

I changed the reference from that old AOL address to my (no longer new) GMail address. We’ll see what happens, but I’m assuming (and hoping!) that I will not get any more emails from Dartmouth to that AOL address.

Now the only reference to my AOL address is from Pacific Bell (oops, sorry, now AT&T), and I can't get to their page where I (supposedly) can remove my old address from their list. One of these days I'll debug that problem.

Six vs. Twenty-Four Jams: Too Many Choices

As much as I have fond remembrances of Perl, I'm glad languages like Python are around. As I mentioned in a previous post, one of the reasons I left Perl behind was TMTOWTDI. Note the reference in this Wikipedia article to the Python principle that espouses the opposite philosophy. I've now found more support for the idea that more is not more, and is sometimes less.

I've read a few articles that cited a study where consumers were presented with different numbers of choices for buying jam. Searching for those terms turned up this article. I found it interesting that more choices made more people stop and look, but more choices reduced the number of people that actually bought any jam. I, like many others, like to feel that I know enough to make an informed choice. I also realize, however, that I am just as happy to have someone (who I hope is more knowledgeable than me) winnow down those choices to a set to which I can actually give decent consideration. This also reduces the time required to make a choice.

I know that for Perl, once I figured out how to do something, I actively rejected trying to find other ways to do that same thing. I never felt the need. I also never had a case where performance was an issue (which would have forced me to look at other ways). I also, thankfully, never had a Perl prophet try to convert me to the "Many True Ways" of Perl.

This also makes me think of all the sales vice presidents that have touted their "pipeline," but weren't able to translate that into actual sales. It's the end result that matters (both the quality of that result and how long it took to get there), whether you're on the making, selling or buying side of things.

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.