Monica’s latest party had a fun “super star” Hanna Montana theme, and I made her this electric guitar piñata. We had a lot of fun making it, because of the shape there was no need for balloons or any messes with flour. I basically just used a box from one of my RC airplanes, cut the shape with one face of the box and traced the bottom part with the other side. The corners were just slices from the same box folded to form the necessary shape. Lots of tape was needed for this.

Because I was using a box and no paper mache, I was afraid the kids were going to have a hard time breaking it but no, it stood its ground and then broke when the bigger kids started hitting it.

One fun little detail where the knobs and the cords made out of colorful threads. Also added a little Hanna Montana sticker to keep up with the theme of the party.

BTW one of the top searches I keep getting is for “transformer piñata”, which almost makes me try to do one (Starscream or Optimus I guess). Too bad my girls are not really into the Transformers, but maybe I could do just for fun or give it to a friend.

We all went to Disney’s Magic Kingdom last weekend, and I like this picture we took of the castle at night. Makes it look a bit spooky.

So the other day I’m looking at somebody’s code and notice a class name that caught my attention; “GenderEditor”. I think it was just your normal JTable class to show a “gender” property, but I thought it was kind of funny because the class name implied you could use this program to switch a user’s gender very easily (with no surgery!).

I talked to the developer and we had a good laugh about it. Then I noticed in the code a class called “GenderRenderer”. Well, you don’t have to use a lot of imagination to figure out how this class could be potentially a problem (what should we use to represent gender … hum).

There’s nothing wrong with these class names of course, but it made me think about how hard it is sometimes to come up with good names for our classes and how easy it is to come up with some awkward and sometimes embarrassing names.

I can’t remember any similar to GenderEditor, but I do know somebody that got carried away with naming everything *Broker. UserControllerBroker, GroupManagerBroker, SaveTheDolphinsBroker. If that wasn’t enough, then actual “broker” implementations just appened “Impl” at the end of the name, making things even more convoluted; UserControlerBrokerImpl, GroupManagerBrokerImpl, etc. I guess good descriptive names are nice, but you can get carried away trying to define what the object does in the name. We do have comment blocks in most languages, so sometimes it’s best to just say what the thing is supposed to do there.

I’m also not a big fan of putting a big “I” in front of interfaces. IUser, IConsumer, ICreditCard, this convention is used a lot by Microsoft and IBM. You look at the Eclipse code and it is littered with it. I see the point though, sometimes you want to make clear people separate interface from implementation, but we do have IDEs that let us know quickly and visually what is a class and what is merely an interface.

The again, having some basic naming conventions is often better than none at all. As long as you apply a bit of common sense and make sure you read the names you are using out loud, you won’t end up with weird names or potentially offensive sounding classes.

Two people sent me this code blooper the other day, again, class and parameter names have been changed to protect the identity of the offender(s).

public SomeObject(
boolean lowSetting,
boolean highSetting,
boolean currentSetting,
Color lowColor,
Color highColor,
Color currentColor,
Color otherColor)
{
   super();
   lowSetting     = this.lowSetting;
   highSetting    = this.highSetting;
   currentSetting= this.currentSetting;
   lowColor        = this.lowColor;
   highColor       = this.highColor;
   currentColor   = this.currentColor;
   otherColor      = this.otherColor;
}

I have to admit I didn’t get it in the first couple of second, but it should be clear that this constructor is basically not doing anything. It basically overrides the constructor parameters with the current values in the object, which is more than likely not what we want to do.

BTW it also has a pet peeve of mine, it calls “super()” (the parent’s public no arg constructor). A lot of people don’t know that this is done automatically for you, no need to write code to for it.

Anyways, this one could have been prevented if you had a policy saying that method parameters should be named differently from class members. However, I personally like naming them the same. I guess it shouldn’t be unreasonable for the compiler to give you a warning when you do this, I’m going to guess most of the time you don’t want to do this.

Last post of the year. I haven’t updated the blog in a while, had kind of a longish vacation from work and was taking a bit of a break from the internet. In the middle of that, I had a very good trip to Panama and spoke at the corresponding JUG over there about JavaFX, more on that in a later post.I wish everybody a happy new year, and hope to update the blog more frequently. This year has been good in my life and I’m hoping things get even better in 2008.

Feliz Año Nuevo!

Hope everybody has a happy thanksgiving. After a long year of working, we’re finally getting to the holidays, so I’m really looking forward to spending to more quality time with the family. That and of course eating some turkey tonight and my favorite, leftover turkey sandwiches.