bentness

Well, I submitted my first Rails patch proposal to Lighthouse today.

At work we have some awfully large database tables, so it’s important that queries hit an index. Apparently MySQL has to be persuaded to use an index sometimes. So, we use the ActiveRecord :from option — which allows you to specify the table name as a string — and include USE INDEX(my_index_name) in there:

HighScores.find(:all, :from => 'high_scores USE INDEX(index_type_statistic_date_value)', :conditions... )

However, when we tried to use the same :from option that we used on a find query on a count query, we discovered that the Calculations module (which provides the AR::count method, amongst others) did not accept the :from option.

So, I checked out a fresh copy of rails from github, made my own branch, made my changes and made a patch file. Then I submitted that to the Rails Lighthouse project. You can add your comments (preferably plus ones) at:

http://rubyurl.com/lOJ3

Now, I’ll just have wait and see if this gets accepted. It’s a pretty minor change, is matching existing functionality in Base, and I included tests, so hopefully it’ll be a no-brainer.

By the way, I used the most recent railscast, “113 - Contributing to Rails with Git“, to figure out all the stuff I needed to do to with Git and Lighthouse and whatnot. It was very helpful and I highly recommend it if you’re interested in contributing to Rails. In fact, they should just put a link to it in the Rails Lighthouse project.

So, let’s see… I learned a bit about using Git, some more about the inner workings of ActiveRecord, set up my account on Lighthouse, etc. A good learning experience to be sure.

– epilogue:

Posted that patch to Lighthouse and pasted the url in #rails-contrib and it was accepted and applied in about 10 minutes! I have to say that my first experience contributing to Rails was a very good one. I never dreamed it would be so fast and easy.

Experienced the face-melting, breakcore blast of Venetian Snares last night. I was reminded of the scene in Mozart where the prince says Mozart’s work simply has “too many notes”. That prince’s head would have exploded were he exposed to the high-speed, mind-bogglingly intricate barrage of beats and bleeps produced by Mr. Aaron Funk.

I definitely did not have any qualms with the voluminous amount of notes Funk spewed out. It was a bit of a challenge to stick with him through the whole set (especially because of the ridiculous amount of smoke in the club… I think I probably inhaled over a carton’s worth of smoke over the night), but that wasn’t because he ever ran out of things to say.

The glitchy, spastic, sonic tapestry was downright hallucinogenic at times… had me jerking and twitching in my chair. I felt for the people who actually tried to dance! VSnares are definitely an acquired taste — probably requiring a somewhat masochistic streak as well — but I’m definitely glad to have experienced it.

The ever insane Otto Von Schirach opened. I’ve dubbed him “smirkcore”… cuz you just gotta have a smirk on your face the entire time you’re watching his somewhat Mexican-wrestler inspired stage presence and weathering his blasts of electronic noise.

On quite a different musical note (heh), I saw Firewater last Wednesday (before I started this blog). That was something of a spiritual experience as well. Firewater is Tod A (from Cop Shoot Cop) putting his great, plaintive vocal style in front of a five-piece band that mixes up an eclectic stew of ethnic musical influences. In addition to guitar, bass, and drums, there was also a trombone player (who was really hot… she reminded me of Salma Hayek) and a percussionist (dressed in traditional garb of some eastern country — perhaps Pakistan? — including a turban).

On several songs, the percussionist played a large drum, hung on a strap around his shoulders, with curved mallets on both ends. He would just bop around a bit without playing until the right moment and would then cut loose with a flurry of beats and carry the song through the chorus, jumping up and down and beating the hell out of that drum. It was great. All in all, very emotional and powerful music.

Oh, I also saw Portland punk rock legends Poison Idea Saturday night at my old stomping grounds, Satyricon. It was packed to the gills and — fearing for my rickety old bones — I stayed toward the back, so I didn’t really get the full effect. However, they played a bunch of their classics and the crowd ate it up.

Jerry A is the only original member anymore, but the young rockers he’s got backing him now definitely seem to be worthy of the PI mantle… cranking out the blistering riffs and breakneck tempos just fine. Jerry was his usual smirky, quirky self. He even drank a “beverage” (club is all ages now) out of a Converse that would up on stage. Not quite as punk as the old razor blade days, but heck, I wouldn’t do it!

I recently used Ruby’s Timeout module to help deal with a potentially slow call to Facebook. This is a neat little bit of code. It simply spawns a thread that sleeps for the number of seconds passed to the timeout method call. If the original thread is still alive, it raises an exception… in the original thread.

This has an interesting side-effect. I was initially a bit annoyed that timeout raises an exception because the code I am wrapping in the timeout is already in a rescue block. I was thinking I would need to wrap my call to timeout in another rescue block… like this:

begin
  timeout(30) {
    begin
      # make facebook API call
    rescue Exception => e
      logger.error("Calling facebook raised: #{e.message}"
    end
  }
rescue Exception => e
  logger.error("Calling facebook timed out")
end

However, I’m lazy. I was initially just catching Exception, as above. Before I got around to putting in the outer rescue block, I discovered that my tests were passing even when I forced the timeout to trigger.

This is because timeout raises it’s exception in Thread.current. That’s right, when the timeout thread sees that the original thread is taking too long, it reaches into the other thread and makes it throw. Consequently, the inner rescue catches the timeout exception raised by a time out block wrapping it.

This means that I can just do this:

timeout(30) {
  begin
    # make facebook API call
  rescue Exception => e
    logger.error("Calling facebook raised: #{e.message}"
  end
}

I suppose this isn’t really that magical… just a side-effect of multithreaded programming. However, I think the common expectation (at least from your typical sequential programmer’s point of view) would be that the inner rescue block could only possibly catch exceptions raised within the previous begin and itself. Not so.

Here’s a review I wrote a while back (Feb. 2008) of Brad Ediger’s Advanced Rails. I have review copies of The Rails Way by Obie Fernandez and The Ruby Programming Language by Matz and David Flannagan, but haven’t made much of a dent in them. I will try to post at least a quick review of both soon.

Read the rest of this entry »

I tried doing a blog years and years ago as part of my static website, but I quickly ran out of things to say. I’ve decided to give it a shot again… and to try not to be so worried about posting regularly or having profound things to say.

So, that means that it may be quite a while between my posts and some posts (heh, probably most posts) will probably be pretty short. I do, however, have a few things already ready to post about. The first is a review of the book Advanced Rails that I wrote a while back. I’ll put that up in a new post. I have several other things to post, but I think I should do some work around the house before doing more blogging.