a timocracy of one

In my previous post, where I relate my experience using phusion/mod_rails on DreamHost PS, I was not suggesting it as a replacement for a nginx/mongrel_cluster. If you already running those happily, then you already have more control over things, and probably have everything in place to manage them. If you want a quick, easy deployment on a shared/semi-shared host, though, phusion is hard to beat. Especially since, if you are going the DH route, the single mongrel set-up of DreamHost PS requires you to juggle things around, and you’ll end up running nginx anyways.

So, in that case, for something as minor as a blog, or a minor app, it’s pretty easy to just use phusion.

Oh, and I did finally send DH a support ticket to turn my mod_rewrite back on – it’s disabled by default, since the default .httaccess people have routes to FCGI. First, though, I commented those sections out.

#RewriteRule ^$ index.html [QSA]
#RewriteRule ^([^.]+)$ $1.html [QSA]
#RewriteCond %{REQUEST_FILENAME} !-f
#RewriteRule ^(.*)$ dispatch.fcgi [QSA,L]

DreamHost support got to my ticket unusually quickly and sure enough it was enabled… and my site was throwing 500 errors for a minute, in the apparently usual config change hiccups. Before support could get back to me the second time, it started Just Working again. So yes, mod_rewrite and mod_rails on DH PS, seem to be a-okay. On the other hand, I have not tried phusion on purely shared hosting. My venerable Typo install runs my PS up to about 150-200 megs, on average, so that’s probably a no-go for me. I suspect a small merb app wouldn’t have any problems

So, when moving my DH account over to their VPS-ish offering, I decided to stick with fcgi for a while to see how it did under less memory constrained circumstances. My blog stayed up way better, but memory usage definitely climbed consistently, and the server needed restarting every week or two. Killing off the ruby’s and the fcgi’s didn’t seem to be enough, for some reason.

So, with that as a baseline, I switched over to mod_rails. It started with an immediate jump up in memory, which had me slightly worried. And, it was a little spikier on memory usage. But, it is steady and consistent. I haven’t had to restart the module, much less my server, since I switched. It seems to be spikier (and in retrospect, they are pretty small spikes), because it actually grabs and releases memory as it needs it, unlike FCGI, which just seemed to slowly leak memory away to some hidden land where the mallocs play.

One side-note, if you are using rewrites for things like redirecting your rss to feedburner, you may need to adjust them, as the switch can mess with that. I haven’t fixed mine yet, and briefly wondered why my feedburner stats fell way off.

Update: This doesn’t actually quite work, as it can override some scopes when composed. I haven’t quite figured out yet, if the technique is salvageable in some situations, or if it is always unsafe to use for chaining scopes.

I have not been able to find any info on ways to make rails named_scopes call each other, or otherwise handle dependencies. This can come up, for instance, if you have complex scopes that require joins. You might have some scopes that share the same needed set of joins to be valid, and you would like to spin that join out to a separate scope, so they could share it. Or it might be called from a has_many :through, where that join will already be valid, but alternatively called directly, where the qualified column name suddenly won’t make sense (‘other_table.column_name’ will be incorrrect in the unjoined query).

The best solution I have found is to use a class method that returns an anonymous scope. This is a contrived example that could be better handled through the has_many side of the relationship, but with sufficiently complex multi-level has_many :throughs you can easily come up with a situation where you want dependent named_scopes.

class Book
  named_scope :author_join, :joins => 'INNER JOIN authors ON books.author_id = authors.id, order => 'authors.last_name, authors.first_name'
  named_scope :published, :conditions => {:published => true}

  def by_author_country(country_code)
    Book.author_join.scoped(:conditions => ['authors.country_code = ?', country_code])
  end
end

#yes they are still composable
Book.by_author_country('EU').published

Just beware that currently scopes don’t merge joins, so you can only have one joins per set of composed scopes.

If you are hitting mysterious warnings of the format: “RangeError: 0×19ad692 is recycled object” in your tests, after upgrading to Rails 2.1, it might be due to threading issues. Just commenting out the line

require 'thread'

in a library at work, that will run without it, quieted the tests, so it’s possible even just requiring it will cause problems in Rails 2.1 (using ruby 1.8.6 p114).

Which is odd, since thread is required at least one place in the AR code itself, and elsewhere in our app. Maybe it’s an interplay of a couple libraries together, such as the non-threadsafe ‘aws/s3’ and thread?

def hello(message)
  "#{messsage}!" 
end
"1234foo4567foo".gsub /(\d*)foo/, hello($1)
=> "!!" 
"1234foo4567foo".gsub /(\d*)foo/, hello($1)
=> "4567!4567!" 

I needed to pass a backreference ($1 or \1) from a regexp into a parsing method and then replace the match with the result. I tried many ways and couldn’t quite figure out why I couldn’t do it, before realizing that the $n variables get populated based on the last match, so won’t be populated when passed into the method call in the substitution param, or will be populated from the last time it was run. And the ’\1’ for won’t work for similar, if slightly different reasons.

Then I discovered the block form of gsub, which passes in each match to the block, and populates all the relevant regexp backreference/match globals:

"1234foo4567foo".gsub(/(\d*)foo/){|m| hello($1)}
=> "1234!4567!" 

If you are using a has_finder (or possibly named_scope, I haven’t confirmed this myself), remember that unless you wrap your condition => in a lambda it is going to be evaluated early – or at least earlier than fixture creation, it seems. At work we had a case where one model had a finder that depended on its belong_to being in a subset of another, basically:

has_finder :all_active, {  :conditions => {:status_id => Status.active_ids} }

This work in production, where the ids don’t change, but since we are using the newer fixture approach on this model the ids are created dynamically. Given how fixtures load, the table will probably be populated with the old values, at parse time for that class, then the test will run, and the fixtures will reload, and they will not match anymore.

This is easily fixed, when you realize what is happening:

has_finder :all_active, lambda {|| {  :conditions => {:status_id => OtherModel.active_ids} }}

A friend and former employee of mine, Stephanie Geerlings is looking for work. She just put her new portfolio site up, so it’s missing a couple things, like a contact link, so go ahead and email her at stillsmall at gmail if you are interested. If it doesn’t go without saying, she comes recommended by me. ;)

This year was great for infographics of the primary season, over at the NYTimes. Good data visualizations definitely give you a better grasp on the data, and you can see all at once things that might have been hidden before. It seems to me creation of good infographics is a here to stay needed skill for online journalism and reporting now.

For instance, check this out to see that yes, despite the horse-race the media might make of it, Obama is going to win the general.

I wrote an article on the work blog on the basics of how (and why it has t be done this way) to use Google AdSense in a FaceBook FBML app.

It does not matter if you set

ajax.requireLogin = false

it will still just error out. And may I mention that the facebook ajax error gives NO diagnostic information. There is an error handler you can set, but it accepts no parameters, it is just a function call, so you can say, “Ooops, there was an error, who knows why.”

Oddly enough, it works fine in Safari, so I didn’t notice it until I tried to debug something in Firebug. Then I tried IE to compare, and realized that this was only working in Safari, of all things. That’s one step better than having an Opera only feature fer crissakes. Anyways, here is the “bug in the facebook bugzilla on ajax throwing an error unless the user is logged in”: http://bugs.developers.facebook.com/show_bug.cgi?id=1009