2005 Events Calendar - Very Preliminary

I'm not sure what jmaynard's schedule will be for much of this year, mainly since so much can change at the last minute. But my plans, so far, are these:

Late May: Rocket City FurMeet. I'll be driving down a bit early to hopefully arrive on Thursday, and then I don't plan on leaving until Tuesday morning. This should give me time to not only attend RCFM but maybe also see stuff in the area. Last year I went to Huntsville and didn't go see the rockets. That must be rectified.

June 4-5: Siouxland Renaissance Festival. Actually I expect to go to Sioux Falls on the afternoon of the third. I expect it'll be like last year - only better. That's what Siouxland does.

Later in June? - Jubilee Faire. I think that's it. One that has been much recommended but somehow it always seemed to conflict with something else. This year it seems that the faire(s) that would normally conflict are likely not happening.

August/September: Minnesota Renaissance Festival. Probably only a couple times. Jay and I decided not to bother with the season pass this year, so we won't be going every chance there is, most likely. I like opening day since that's the least crowded time.

Early September: Probably one day at Iowa Renaissance Festival

Mid-November: Midwest FurFest. I had a good time last year, so I'm planning on doing it again.

Misdiagnosing the Problem

I've seen discussions, or rather arguments, about whether MixedCaseVariableNames are better or if underscore_linked_variable_names are better. I have dealt with both. From my Forth background, I rather prefer the MixedCaseVariableNames as one of the Forth tools I have results in printouts with underlines, which make underscores indistinguishable from spaces - this is a Bad Thing when trying to debug. Of course, in Forth I can use ~Variable-Names-With*Unusual-Characters-in-Them! if I am so inclined.

Now that my bias has been revealed, I'll address one of the notions of some of the underscore users. The idea is that say, this_is_a_test won't have the missing capital problem that ThisIsATest might if someone flubs and uses ThisIsaTest instead. This error could be found with a system that demands all variables be explicitly created. But not all systems are like that. Many are, or can be, quite lax and let the first instance of something substitute for an explicit declaration.

But the problem is not even that. The problem is that of case sensitivity. In an ideal system, case would be preserved, but not distinguished between. That is, if I make a variable named CustomerID the system editor won't go changing it on me to be customerid or CUSTOMERID but will leave it alone as CustomerID. But it will also accept CUSTOMERID and customerid and customerID and they will all point to the same information as CustomerID. Not that the programmer should go around not caring about case. Ideally each instance of the variable would look like all the other instances of the variable - but that's something the search-and-replace function of an editor can handle if need be.

"But that means you can't use each separately!" That's right. Which means I'd have to think up names that won't overlap in mental name-space and be confusing. It would require that I not obfuscate my code, at least not by abusing case.

Now, MiXedcAsevaARiabLeNAMe is something that does deserve to be editted out of any respectable program. Unlike MixedCaseVariableName, nothing is gained in readability by random capitalization. Rather, it just makes the programmer look like an idiot.

I guess it's not obvious to everyone.

With this post, rillaspins reminded me of a bit about the water dispensers at work. We used to have the typical water cooler with the 5-gallon or so jug that would need replacing every day or two. Then a while back we got these gadgets that filter the city-supplied water into something that doesn't taste as miserable as city-supplied water.

These dispensers have three buttons. One button is blue. Two buttons are orange. It was obvious to everyone that the blue button resulted in cold water being dispensed. That was no problem. What was a surprise was how many people didn't realize that both orange buttons had to be pressed to get hot water. I can understand trying one button, then the other, then both, but it came as surprise that the simple safety feature had to be explained to some. It is a safety feature, too. The hot water is steaming hot - I don't need to bother microwaving the water for hot tea.