Called Paint, the idea is to have four main colors at the edge of the screens. By the phone's tilt, those colors will bleed into the screen itself, causing the animation, and interactivity with the phone regardless of whether or not you're actually accessing an app. The LWP actually becomes as fun to use as anything else on the phone.

The basic setup is contained in this Gist.  There's more to add, but I made my quota for the day, and I want something to work on tomorrow.

I'm giving myself a challenge, and having my blog (Corner of Seven, for those of you reading this via Facebook) become the record of my success or failure of this challenge.

Starting today, my goal is to write *at least* 50 (fifty) lines of code per day.

This idea came about through the previously mentioned "Don't Break the Chain" post on this blog (which worked oh so very well...),  and a recent experience that I had at work.

Most of my work duties are currently system configuration and setup, and less actual development on said systems.  With that, my ability to get code written has diminished.  I was asked recently to create a component in our software that renamed a file going out, based off of metadata contained within that file.  After sitting blankly at the computer screen, with my brain screaming, "I know what to do!!!!" and my hands frozen, unable to regain the muscle memory of the common actions of Java, I looked inside, and realized this had to change.

In a sense of betterment, I want to complete at least a small project daily.  Maybe it's a coding kata. Maybe I work on stuff in Android.  Maybe I continue work on RBEQ.  Maybe I add new things to Corner of Seven.  Maybe it's something I haven't even thought of yet. All I know is that new code needs to come out of me, before I can't do it any more.

Fortunately, I have tools at my disposal.  The afforementioned projects can keep me busy for a while, but what do I have to show the work that I've put in? Enter the Gist system at GitHub. This allows you to put small snippets of code out, configurable by language; it gets your code available on the internet, and embedded into a blog or webpage.

So there you have it.  Look to see some Gists from me shortly.

Cheers!

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.

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.