Wednesday Mar 31, 2010

Shelley Autonomous Car Update

Last week the Oracle team which is contributing to the Volkswagen-Stanford Shelley Autonomous vehicle project reached a significant milestone: Software running on the car during trials. During Shelley's testing trials last week the car was running Java-realtime application code for handling GPS data and controlling the CAN bus. In addition to this trial being the first time that Java-realtime and OpenSolaris are running on the actual car it's also the first time that Shelley has combined key systems into a single process.

The project is generating a lot of buzz with coverage from Fox News : VW, Stanford Build High Performance Robot Racecar with a piece that's apparently been running frequently for a couple of days. Also covered by CNET: Audi TTS "Shelley", Wired: Audi’s Robotic Car Drives Better Than You Do, San Francisco Chronicle: Driverless car to test out Pikes Peak climb. There's also coverage in German from Audis geisterhafter TTS "Shelley".

Monday Feb 08, 2010

Updated CSS

Yep, I've adjusted my theme. I'm rather pleased that only CSS changes were required. No changes to the HTML code were necessary.

Wednesday Jan 27, 2010

Exceptionally Bad Code

If there's one Java programming idiom I hate more than any other it's the "ignore null" idiom practiced by some Java programmers. Briefly:
Exceptionally Bad Code
public method(Foo bar) {
  if(null != bar) {
     //  Some operation upon bar

This is a pretty common sample. method() has special handling for bar being null. When bar is null the method has no effect. This is almost certainly evil. Unless method() considers null to be valid input and really does want to act differently based upon a null input value then choosing to ignore null inputs merely masks a problem elsewhere.

Ignoring bad input in this way ignores the principle of failing as close to the source of the problem as possible. Finding the root cause of strange behavior when the "ignore invalid inputs" idiom is used is much more difficult than when bad input causes errors. Don't be afraid of generating exceptions for bad input and/or allowing NPE exceptions to be thrown on your behalf by the JVM when called with bad input. The sooner the bad input is identified, the sooner the programmer looking at the problem can find the source of the error.

I've run into a corresponding problem in loosely coupled APIs such as web services. This is the problem where the web services API returns a 200 result no matter what input it is provided. Yes, it will provide correct results when provide the correct input but it will also happily provide (usually irrelevant) results when provided bad input. This also violates the principle of failing as soon as possible and makes problems a lot harder to diagnose. Because of the decoupling of systems this type of problem can be even harder to diagnose than the "ignoring null" problem.

Generating errors or exceptions is the correct response to your code receiving bad input. Intentionally ignoring invalid inputs is not a good strategy for any system especially when multiple programmers or modules are involved.

Maven and Hudson Trick

Like many projects the Java Store uses Maven for our build description and Hudson for our continuous integration.

We've been trying to do a bit more lately with tagging the build outputs with version and build information for later tracking. Hudson provides a number of environment variables which describe the build environment to Maven (or Ant). We're starting to use some of those variables in our output manifests and elsewhere. However, when building the projects locally the Hudson build variables aren't defined. So I came up with a little recipe which can be added to pom files to provide default values when the project isn't being built by Hudson.

The values used aren't always the best match for the values Hudson would supply but they are the closest I could come up with without adding additional requirements. For your projects you may want to tweak the values used.

Surrogate Hudson Build Variables
    <id>Hudson Surrogate Params</id>
            <!-- Activated if Hudson hasn't already set the BUILD_NUMBER -->
EDIT (20100429) : I have updated the sample source slightly.

Thursday Jan 14, 2010

Why are they called Labrador Retrievers?

I've been telling this story for the last couple of months and I thought I would share it on my blog. I volunteer with Guide Dogs for the Blind as a foster care provider. I take care of dogs that need time in a home environment. When you see me with a dog it's probably a foster care dog and likely a different dog than the last time you saw me. We've taken care of almost 50 dogs over the last two years and it's the most fun I have ever had with a volunteer job.

Recently we had the pleasure of taking care of a 7 1/2 week old puppy for about three months while she was getting old enough for some surgery and then the recovery. When we got her she was fresh from the whelping kennel and had absolutely no training. She didn't know her name, wasn't housebroken in the slightest degree, couldn't walk on a leash, etc. However, if you threw a toy she would bring it back to you ever time. Apparently retrieving is a "built-in" function for Labradors and requires no training. I was kind of amazed at how automatic retrieving was for her since she really hadn't mastered any other skills yet. The "Retriever" name is apparently well deserved.

Because I'd never be forgiven for not including a picture:

GDB foster care puppy Gucci
Gucci @15 weeks in the rarely seen act of sleeping with her head on a toy.




« April 2014