Corner of Seven

I received a phone call from my Mom earlier this week, posing what would seem to be a simple question: “Could you help come up with something to manage the pinewood derby at the beginning of March?”

Little did I know that it was going to become a rather taxing endeavor.

The first step has been figuring out the best way to generate heats.  Given m entrants and n lanes, there must be m/n, rounded up, ‘heats’ in order to make sure everyone has raced the same number of times.  Some of these heats would be less than the number of lanes, but should be set up to be not only most fair to racers, but keep the scoring as even as possible.

I started out to see if, given m entrants and n lanes, if it was possible to have a true round-robin tournament; that is, make every racer have a race against every other entrant, and have each racer have the same number of races.  That would make the calculations for the winner the simplest.  Unfortunately, while easy on paper, it becomes impractical in real life.

For example, say we had 8 racers on 4 lanes.  In order to achieve a true round-robin state, we need to have ₈C₄ races, or 70 heats, in order to satisfy the above conditions.  Now, in practicality, do you think it’s possible to have 8 elementary school students sit patiently enough through seventy races?  I didn’t think so either.

My current goal is to make a heat generator out of some form of predictive system.  Using a map of entrants to see how many times one has competed against another, the generator picks the least raced candidates, in order to keep fairness at a maximum.  There are some other things to take into account for the day, like damage, re-races, and run-offs for ties, but those become part of the operation logic.  The true core of this is creating the heats for each level, and keep track of the points received for those races.

Since deciding to start working with Android and see just what I would be able to accomplish with the SDK and devices, my biggest hurdle so far has been Eclipse.

Now that most of the Java developers have now either cringed, cried, or shot themselves, I’ll explain why. From the outset, I have never liked Eclipse. Something about the way the program is presented, coupled with the fact that I could never seem to get it to act the right way (either something was going haywire, or breaking, or the IDE would crash in front of me). During college, there was a brief push to get us to try Eclipse, and that’s where my dislike of it began. We were moving from BlueJ (which, although it serves as a nice Java text editor, doesn’t really count as an IDE in my mind) to Eclipse, roughly around the same time that Netbeans 5.0 was coming out (late 2005, for those keeping track). Once I started working in Netbeans, I saw no reason to move back – things behaved when I asked them to do something. When I made a new class, it automatically put it in the right package (Eclipse: Default package? What?), When I added a wsdl reference, it allowed me to edit it on the fly, and auto-generate the interface class for me. It was perfect for any big Java job I needed. Anything smaller, and I’d drop to a text editor, like KDE’s Kate, or vim. I essentially lost any reason to go back to eclipse.

Fast forward 4.5 years. Android is coming out big. I mean, Really Big.Phone announcements like the HTC Hero, Motorola Droid, and Sony Ericsson XPeria X3 have captivated the tech world, and even some people outside of it. It’s around this time that I decide to buckle down and really start on some Android development (it gave me a reason to buy a new phone, too, but that’s beside the point ). Unfortunately, I found that Google, in their infinite wisdom, had chosen Eclipse as their base platform for Android development.

Naturally, I first tried it on it’s own again, to see if anything had improved. Certainly it did in the four years of not using it. But things still felt uncomfortable. Load times were atrocious, and the interface was not nearly as snappy as what Netbeans provided. When I tried a plugin for Android in Netbeans, though, things were shaky at best. I wasn’t sure whether or not the correct things were loaded, it didn’t have AVD controls, and other issues kept me at bay.

It wasn’t until this morning that I found the answer. Often times, when I’m faced with editor anger, I turn to a more lightweight friend: VIM. I know that there is a lot of power packed inside this text editor, I’ve just never had the energy to learn about all of it. That may change, as I stumbled upon this page in my android search today: http://jyro.blogspot.com/2009/05/android-development-with-vim-eclim.html. Go ahead – visit. Take a while to soak in all that it says and provides. I’ll be here when you get back.

See, that’s awesome. I went out and immediately pulled down this Eclim extension, which acts as a handshake between what Eclipse provides on the back end (error checking, dependency resolution, and automatic imports) without the headache and body of running eclipse on it’s own. I’ve been working with this for the better part of the day so far, and let me tell you, it’s been fantastic. I’ve been working on the Sudoku example given in Ed Barnette’s book “Hello, Android!” (get it if you’re interested in Android Development), and can’t believe how fast it’s being put together. Best of all, it lets you do this in VIM:

Now, if you ask me, that’s pretty cool.  Back to code.