jerakeen.org

Cunning trick to avoid polling on leopard for autotest

http://rails.aizatto.com/2007/11/28/taming-the-autotest-b...

Recently I got dropped in the deep end and had to learn both Ruby and Rails very quickly. I didn’t think this would be a problem - everyone raves about how easy Rails is to pick up, right? - and it wasn’t. The problem is actually arriving now, as I start trying to use Ruby for things other than Rails applications. And I can’t, because I’ve learned all sorts of nice Ruby tricks that looked like they were core language features but actually turn out to be added to the built-in Ruby objects by Rails.

For instance, I really like the 3.days convention for turning numbers into time intervals. That’s added by this extension. In fact, in digging for this, I found out just how many things Rails adds to core Ruby. I’m scared.

I’m torn. I’d like to consider messing with the built in objects confusing and dangerous. And I’ve been bitten by this before. I’ve also had problems where one module’s patching to a Ruby builtin interferes with another module’s patching of the same object. Lovely.

At the same time, though, I love it. I love both the huge convenience and readability of being able to write Time.now + 3.days, and the fact that the language lets me do this. All languages should be this consistent - none of this ‘some types are special’ crap.

There are trade-offs. I love Python, but I hate that map is a global function and not a method on arrays, and I hate that certain types are special and immutable. But I’m sure there are scary speed benefits from doing things this way.

I wonder if part of the reason that Ruby has this ‘just for Rails’ reputation is because, having learned Ruby for Rails, you can’t use that Ruby for anything else without unlearning a stack of habits?

I’m trying to speed up a rails app here, and I’ve been making some assumptions that I’ve realised may not actually be true.

Specifically, if I have a list of IDs, I’ve been assuming that

list_of_ids.map{|id| Model.find(id) }

is going to be slower than

Model.find( list_of_ids )

Presumably, the latter will only make one SQL call to fetch all the objects, but the former will make a call per ID. This is because I’m used to perl, where the ORMs are stupid, the language is fast, and the DB is always the bottleneck.

But the sort of SQL produced by the supposedly slower approach is much more cacheable. The supposedly faster approach will tend to generate a different SQL query every time, whereas a sufficiently smart cache layer could intercept the SQL calls of the later approach and just hand back the models.

Initial benchmarking seems to have the one-SQL-call approach faster anyway. It does turn out to have a disadvantage, though - Model.find( ids ) doesn’t return objects in the same order that the IDs were in, whereas the map approach does. That’s fairly easy to fix, though:

class ActiveRecord::Base
  class << self
    def find_in_order( ids )
      # return all instances with the passed ids, in the order that the ids are in
      objects = self.find( ids )
      objects = objects.sort_by{|o|ids.index(o.id)}
      return objects
    end
  end
end

write swing apps in rails. This scares me.

http://monkeybars.rubyforge.org/

the python/django typogrify filters, ported to ruby/rails.

http://code.google.com/p/typography-helper/

Rails-style routing for Helma. I find the default Helma URL dispatching very annoying - this is far better.

http://grazia.helma.at/pipermail/helma-user/2005-November...

Gah, I really resent having to do this.

http://hivelogic.com/articles/2005/12/01/ruby_rails_light...

I’m going to this. I should try to learn some rails, I guess.

http://europe.railsconf.org/

http://blog.unixdaemon.net/cgi-bin/blosxom.pl/2005/10/27