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.

I finally tried out Passenger (mod_rails) and Ruby Enterprise Edition. Two words come to mind: easy and awesome!

For those of you that don't know, Passenger is an apache module that makes Ruby on Rails deployment super easy in the same way that deploying php can be super easy. You simply point apache at the public directory of your Rails application and you're good to go. Ruby Enterprise Edition is written by the same folks as Passenger and it improves Ruby's garbage collector and memory allocator. They claim that with Ruby Enterprise Edition your Rails apps will use 33% less memory.

I highly recommend checking it out.

Like everything else, computers get messy! Even Macs. However, it turns out there are 3 little scripts hiding in your Mac that are intended to periodically clean your system. The problem is if you use a laptop they probably never get run. They're scheduled to run in the middle of the night and laptops are rarely left on overnight.

Whenever my Mac seems like it's getting a little sluggish I run these scripts. It may all be in my head, but I feel like the system is a bit more responsive after having run them. Here's how:

1. Open a terminal (for those of you that don't spend your days in a terminal like I do, open Finder, go to Applications > Utilities, and double-click Terminal)
2. Type:

   sudo periodic daily

   and hit return (it will ask you to enter your password).
3. Type:

   sudo periodic weekly

   and hit return (this one might take a few minutes).
4. Type:

   sudo periodic monthly

   and hit return.

It's that easy! If you're interested, read more for quick descriptions of what they do.

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.

About a week ago I stumbled across an option that you can pass to the submit_tag form helper in Rails — :disable_with.

Now (thanks to some automatically injected javascript) when you press this "Save" button it will disable itself, change its text to "Saving...", and then submit the form. Cool, right?

Yeah, most of the time it's cool. It's nice to do anything that gives the user an indication of what's going on — especially in a way that prevents them from repeatedly pushing a button on a form that takes a second or two longer than it should.

However, there is one time it's not cool! It's not cool if you have a form that contains more than one submit button and you expect to do different things depending on which button is pushed. A button is simply an input tag just like any other input tag in a form. It has a type, "submit" in this case, a name and a value. The GOTCHA is that, like any other input field, if it's disabled it doesn't get posted to the server. Oooops! So much for using :disable_with on this particular form!

Surely you use the Rails generator script to create your models! You fill in the blanks in the migration for the new model, run the migration, work on the model and its tests, and then commit to Subversion. Right? And, surely after you've worked on a project for a while you've needed to remove one of these models. You write a new migration to remove the table that maps to your stupid_model and then you...

script/destroy model stupid_model --svn

Ooops! See what just happened?

D         db/migrations/002_create_stupid_model.rb

You conveniently used the --svn switch to delete the files from subversion and it not-so-conveniently deleted the initial migration for the model. It may not be obvious at first, but the next time someone tries to rake db:migrate through your series of migration scripts from start to finish it will fail when it tries to drop a table that never existed in their database (assuming it didn't fail earlier).

This morning I needed to remove a model and rather than doing it by hand (to avoid the above problem) I thought I'd take a quick look through the generator source to see if it would be easy to add an option that told the destroy model script to skip the migration. Turns out it's already there (--skip-migration) it just isn't documented!!

script/destroy model stupid_model --skip-migration --svn

Perfect! However, it might be nice if this were the default behavior...

I've been looking for an easy way to backup my iTunes library to an exteral hard drive. Here's a simple solution.