I just had to capture this for all posterity:

Just two weeks on GitHub, and we’re already in the top 10 forked repositories. Woohoo!

This week I had to figure out how to offload a really long-running task into the background in one of my Rails apps. I had looked at BackgrounDRb (BackgroundRb? I’m not sure if it uses DRb anymore, and it’s easier to type that way, at least for me.) in the past, but it recently reached 1.0 and got a new lead developer, so I gave it another look. The API has improved and matured and it seems easier to get started. However, there were still a few things I didn’t expect:

1. It’s best to stick with internal Ruby classes for sending data from your Rails app to a worker. I had created a sort of “presenter” object that would convert an incoming form hash into a useful data structure that I could manipulate when running the worker. My first attempt involved initializing the presenter with the form hash, then sending the presenter to the worker in a method call. I kept getting deserialization errors, even if I did an explicit require. In the end it was just easier to pass the raw hash to the worker and then wrap it in the presenter when it starts working.
2. Test/Spec/Debug your work as much as you can ahead of time. BackgrounDRb doesn’t automatically reload classes, so when errors occurred, I found myself doing this a lot: >> exit $ script/backgroundrb stop $ script/backgroundrb start $ script/console
3. BackgrounDRb uses three different log files, which can be somewhat frustrating and initially confusing. One, BackgrounDRb_11006.log (where 11006 is the port) displays logger output from your workers. The second, BackgrounDRb_server_11006.log displays anything sent to $stdout or $stderr, from what I can tell. The third, BackgrounDRb_11006_debug.log displays the packets of information being sent across the wire between the client and BackgrounDRb. At one point, I had three terminal tabs open with a tail running for each log file. Ick.

Despite those gotchas, it seems to be much easier to create long-running tasks for your Rails app. I even implemented an Ajax polling mechanism to check the status of a job. Here’s the basic steps:

1. Install the plugin. (Read the docs on the site linked above.)

2. Create the necessary boilerplate.

   $ rake backgroundrb:setup

3. Generate a worker.

   $ script/generate worker jump 

4. Write the code your worker needs to do:

   class JumpWorker < BackgrounDRb::MetaWorker
     set_worker_name :jump_worker
     def create(args = nil)
       # this method is called, when worker is loaded for the first time
     end
    
     def jive(params)
       Rockabilly.new(params, logger).wail
       register_status :wail_away
     end
   end   

You may notice two things here. Every worker has a logger object, so I pass that to my class that does the actual work so it can log useful messages. Second, the register_status call sets an object as the current status of the worker. This lets you keep track of progress of the worker from your application.

1. In your controller, create and invoke your worker. If you want to track progress, make sure to assign a job key that your client can use to poll. I used the current time converted to an integer, which will be enough for my small-usage app.

   @job_key = MiddleMan.new_worker(:worker => :jump_worker, :job_key => Time.now.to_i)
   MiddleMan.worker(:jump_worker,
   @job_key).jive(params[:brian_setzer])

2. In the controller action where you want to poll, grab the status of the worker.

   @status = MiddleMan.worker(:jump_worker,
   params[:job_key].to_i).ask_status

This will return whatever object you set to the current status of the worker using register_status.

There’s the basics for getting started with BackgrounDRb. Happy background tasking!

Tonight I recorded a wonderful conversation with two really cool guys about how they are using Radiant in their business and what it has done for them. Look for the first episode of the Radiant podcast in about a week (once I finish cleaning up the audio). I interviewed them over Skype and used Ecamm’s Call Recorder to record the conversation. Which brings me to my next point…

I recorded the interview uncompressed so that I could keep the quality as high as possible. Once I finished the recording, I used Ecamm’s included tool to split the resulting MOV into two separate tracks (me and the interviewees). I then proceeded to fire up GarageBand to layout the tracks, filter and do some editing. However, once I got one track into GB, whenever I would dump the second track in, I would get the original track duplicated.

I tried renaming the files, renaming the tracks, inserting them in a different order, etc. No dice. I was about to say, “Apple, you are not as cool as you think you are. You gave me a crippled product and there isn’t even any documentation that it is cripppled!”

After hours of searching the help and the intarwebs to no avail, I tried, on a whim, compressing the files using AAC or MP3 and then importing them.

Guess what. THEY WORKED!

So, the moral of the story is: If you want to edit/mix more than one plain audio track at a time in GarageBand, compress them first; or as I plan to do, clean them up, then compress them, then mix them.

So now it’s documented at least somewhere.

In the wake of incredibly successful BarCamps like San Francisco, Austin, and Orlando, it’s about time we had one in Kansas City. On Wednesday afternoon, I met with Pete Thomas who is organizing BarCampKC and we both agree that there is a bunch of incognito innovation in Kansas City. If you are an entrepreneur, designer, blogger, podcaster, programmer, or doing anything creative with technology, this will be your bag, baby. Get in touch with Pete via the BarCampKC blog or shoot me an email if you want more information. We’re looking for venues and a sponsor still, so any suggestions or offers are greatly encouraged!

I’ll be presenting about Radiant and we already have lined up Tom Mornini of EngineYard and a few others. Check it out!