It appears that the Mysql/Ruby library blocks all threads for the current process when executing a query. If you are running a multi-process web application this is not an issue, but for a multi-threaded application that has long-running queries this can be problematic.

I have a simple reporting service written with the Merb framework. In Merb you can make it handle multiple requests at once by setting use_mutex to false in the config/merb.yml file. This works great until you have a long running mysql query and it forcefully blocks ALL threads in the process. During this query your Merb app, which you thought was multi-threaded, is no longer multi-threaded.

A programmer that I work with did something today that got me thinking about a twist on pair programming. He swept through the application we are working on and cleaned up some little things that have irked him lately. It's clear there are benefits in being a "cleanup" programmer once in a while, but are there benefits to being a "leadoff" programmer? What if we paired up on each task, but not at the same computer and instead in complementary roles -- a leadoff programmer and a cleanup programmer.

The way I see it, the main benefit of pair programming is having two sets of eyeballs on any given piece of code. I've tried pair programming in the past with varying levels of success. There's no doubt that the resulting code is of a higher quality, but it's been my experience that most people have different styles of getting stuff done; and trying to get stuff done at the same computer with another person can be tiring and frustrating. So let's pair up on tasks, but in a specific batting order rather than at the same terminal.

In a baseball batting order there are 9 positions. The first position is called the "leadoff," the fourth is the "cleanup hitter," and the ninth is the "last." In the spirit of pair programming I'm going to skip all but the first and fourth. Here's a brief description:

1. The "leadoff" batter is usually the fastest base-runner. He bats more often than anyone else and needs to have a high on base percentage so that he can score when the power hitters are up
2. The "cleanup" hitter (the fourth position in baseball) is usually a highly talented hitter whose job is to "clean" the bases by driving home the base-runners to score runs.

These two roles could work really well for programming. Put a programmer in the leadoff role that is a fast coder. A person that can whip through a task and get it to a functionally complete state. Then, put someone in the cleanup position that can review the task, tighten up the code, and push it out to production. Might work well. You get two sets of eyeballs on the code and the programmers can work in their own way focusing on their role for each task.

I think it would be very beneficial and refreshing to swap roles on different tasks, but I wonder if different programmers would ultimately settle into one position or another. On a given team, I would guess the lineup would become fairly stable after a while.

With a team of more than two programmers, what if you set an order for a given set of tasks and rotated through the line-up for each task? Let's say you had a team of 3 programmers. On the first task, the first batter would be the leadoff and the second the cleanup. On the second task, the third programmer would leadoff and the first would cleanup, and so on... It might be interesting.

Most applications display lists of various things and they usually display these lists in slightly different ways. In my opinion, there isn't a one-size-fits-all solution to building these lists, but there is a pattern that seems to work pretty well. It consists of three parts: the list, the list-item, and the item. In addition to partitioning your lists into smaller pieces that are easier to deal with, it also makes it very easy to add both css styling and ajax behaviors to your lists.

Code readability is an undisputed contributor to increased programmer productivity. Ruby on Rails shines in this department by effectively using two main pieces of Ruby — the hash and the symbol. These two things are used all throughout Rails, but most importantly as method parameters. There are two keys to keep in mind when writing methods:

1. When passing multiple data parameters to a method, pass a hash
2. When telling a method how to behave, pass a symbol

Ruby on Rails migrations rule! They're easy to get started with and have changed the way I approach database-driven application development. However, I was recently shocked when I used capistrano to deploy a new version of an application and one of the migrations exploded. It turns out that using ActiveRecords in your migrations can lead to unexpected results, but by following two simple guidelines you can ensure that your migrations will remain reliable throughout your application's life-cycle.