Have you ever wondered where the term “jewel case”, referring to CD cases, actually comes from? I always assumed it had something to do with the shiny, transparent-as-crystal cases somehow reminding someone of a jewel. Nope, not even close.

From Wikipedia:

The name is not derived in any way from containers for jewelry, or from the fact that the case is typically made from transparent plastic as is sometimes believed. Instead, the name originates from watchmakers’ use of the term jewel to refer generally to a polished hemispherical bearing used in a mechanism (high-quality mechanical watches and clocks commonly use gemstones, typically rubies, for such bearings because of their low friction properties). A jewel case has two molded hemispherical plastic bearings, in its hinges, hence the use of the term “jewel.”

Now you know.

On the Revolution Systems blog, the author has a good, common sense approach to making source code more programmer friendly: use better names and be consistent.

Though this is kind of like a “duh” moment, it’s amazing how frequently these practices are ignored. I’ve looked at a lot of source code that was simply horrible because the variable names were concise to the point of being worthless; for example, $tobj could be “temp object”, “time object”, or even “total observational bone joint”. You get the idea.

Alternatively, I’ve also seen code that had an object named something like “Group.classObject.Frame.Widget1.VariableTimer.CountdownToNextEvent”. Even using auto tools like in Visual Studio, it’s still a pain in the butt to write out a name like that every time.

Consistency is another big item. There always seems to be a push to standardize things, especially at my current shop. But even with all the SOPs and policies, I still haven’t actually seen anything discussing variable naming conventions, commenting standards, or even how source code should be put into the code repository. I think part of this is because we rely on the configuration manager to handle things like these; just give the code to the CM and he’ll take care of the logistics.

But what happens when he’s not around and you have to do it yourself? How do you train new people? What about audits or showing senior management how work is accomplished? Standards are made for a reason. They make life easier for everyone.

I took this picture the other day while waiting in line at McDonald’s. I thought it was quite humorous that a Driver’s Ed car would be going through the drive-thru. What was even funnier was, when it drove off, I saw that the only person who got anything was the instructor as he stuffed his face; the students in the car had nothing to eat.

Of course, one has to wonder how appropriate this is. Did the instructor tell the student to do it for his own benefit or did he ask if anyone else was hungry? Perhaps a better question is, why didn’t the instructor simply wait until the lesson was over? Even if the instructor is diabetic, they should normally carry snacks with them. At least eat before taking the car out.

Found via Slashdot, some professors at NYU have written an article in a software engineering journal about the hazards of teaching students Java as their first programming language. It’s very enlightening, especially when they talk about the advantages other languages have to offer for problem solving. They also talk about how CS, as a discipline, is declining since students aren’t learning the fundamentals needed to actually solve problems; all they know how to do is fit the right part into the project and hope it works. When it doesn’t, they are at a loss to deal with it.

Here’s a quote from the article:

Because of its popularity in the context of Web applications and the ease with which beginners can produce graphical programs, Java has become the most widely used language in introductory programming courses. We consider this to be a misguided attempt to make programming more fun, perhaps in reaction to the drop in CS enrollments that followed the dot-com bust. What we observed at New York University is that the Java programming courses did not prepare our students for the first course in systems, much less for more advanced ones. Students found it hard to write programs that did not have a graphic interface, had no feeling for the relationship between the source program and what the hardware would actually do, and (most damaging) did not understand the semantics of pointers at all, which made the use of C in systems programming very challenging.

It is worth noting that the authors do have an interest in the Ada programming language, being part of AdaCore Inc.  Obviously they make a stand for learning Ada, so there is some bias to be expected. However, some of the ideas coincide with what I’ve learned over the years, especially having taken Java as my first programming course.

Personally, I think I learned more when I taught myself Python. It was the first time I actually understood OOP even though I “learned” it through Java and C++. I guess ultimately it’s whatever continued learning you do that makes you better. School is designed to make you “well rounded” and expose you to different ideas. Learning what’s needed to actually excel in your chosen field is left up to you.