Until today. Well, technically yesterday night. Whatever.

Yesterday, I had the wonderful experience of meeting a fantastic group of gentlemen called MadRailers.  These are not angry train workers, but a Madion, WI based group of software developers with an interest in the Ruby on Rails framework.

Through their discussions (dubbed “lightning talks”, based on the nature of the size of the presentations), I was able to pick up on some valuable pieces of the rails environment: some things I had already heard about, but got to see them in use, some things were new to me, and made things easier, which is every developers dream.

A discussion on proper testing techniques with Cucumber spawned a rigorous discussion on the correct use of the tool, and how the tests should be best written. One side had that the tests should test one logical piece of the feature, while the other side believed that the tests should be written in a way to show the full flow of the feature, from beginning to end. I would tend to agree with the first argument; if your tests aren’t clearly defining something to test, then they aren’t going to be very helpful if they break, and you’ll spend your time hunting down the error that caused all your tests to fail, instead of having one test tell you the error, and fixing the problem.

Another discussion was from a newer member to the community (relatively – as it was my first meeting, everyone had been there longer than I had) about why he found rails, and what he enjoyed most about it. These types of presentations can be more helpful than they set out to be: I found out about RVM, which is supposedly an indispensable tool (I’ll have to look into picking it up), and based off of a discussion generated from the presentation, I was able to see Haml in action. I had heard of Haml previously, but hadn’t had the chance to use it; now I really want to.

One of the later discussions focused on a rails plugin called active_scaffold, and a javascript library called Top Up. These were both new to me, active_scaffold greatly simplifies the amount of work needed to get a fast, decent looking data presentation available to make sure that all of your information works together correctly, and Top Up allows you to create modal windows as a container for virtually anything: text, html, swf, and even avi.

Overall, I think my greatest gain from the night isn’t a technical one, it is one of attitude.  From the level of organization that was provided, to the way that the conversation easily flowed between presenter and audience, and to the level of interest shown in the technologies presented, it showed to me that there really are more people like me. Living in Dubuque has some benefits, but the drawbacks are present as well; I never would have had the chance to do something like I did last night in Madison around home.  Some people were surprised at the fact that I would drive over an hour to come to a program like this; I think it was completely worth the trip (even through the weather, which was somewhat less than cooperative). Things that I’ve striven for and missed at work, like automated testing, simplification, and comfort with a product are things that these guys have at their disposal; it shows that there is light at the end of the tunnel, and there’s something to aim for.  After talking with some of the members, it looks as though they had been in similar situations before, so it looks like there is hope for me yet.

If they end up reading this, thanks for a wonderful evening, guys.

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.

Found on http://www.makinggoodsoftware.com/

Basically, as described on the link above, the idea is that you keep a daily calendar of all the specific goals you want to accomplish.  Every time you do something related to a goal,  mark off the day on the calendar.  Once you have a few days consecutively, that is a chain.  The object of this motivational strategy: Don’t Break the Chain. Seems like a simple enough thing.

In the spirit of bringing in new ideas in order to make things work, I’m going to use a modified schedule, but the chain still takes effect.  Different days for me will be devoted to different goals/tasks.  Mondays and Thursdays I tackle some Ruby code, so I can stay fresh and learn about some of the newer developments that I’ve missed, having been out of the Ruby loop for a while.  Tuesdays and Saturdays are devoted to Corner of Seven.  That’s right, you might actually see more blog posts. In addition, I’m looking at building new and experimental pieces onto the domain, including rails and Java webapps, and playing around with php and python, so I can apply these to the blog, and keep the site as a form of digital portfolio.  All of my things will be up here, so it makes it more centralized.

Motorola Droid

Finally, the big hurdle in my calendar, and what is to be the biggest chain – Android.  I’ve been looking at the mobile phone operating system for a while now, but haven’t had the drive to fully enter in and create things for it.  That is, until I saw (and afterwards, held) one of these.So, starting today, once a day I will try to do something new in terms of Android development, in an effort to increase my skill and knowledge in the mobile OS.  Hopefully we’ll get to see some neat little apps come out of this “Don’t break the chain” mentality.  Hope you’re along for the ride – I guess we’ll see come every Tuesday and Sunday.

Cheers for now.