(Follow-up on part 1)

One of the great and powerful things about Ruby is its ability to expressively extract common patterns through metaprogramming. Even the standard library in Ruby provides some good examples. One of my favorites is the generation of getter/setter methods for instance variables, the attr methods:

class Person
  attr_reader :name # adds 'name' method (getter)
  attr_writer :phone # adds 'phone=' method (setter)
  attr_accessor :address # adds both 'address' and 'address='
  attr :gender # same as attr_accessor
end

Using the metaprogramming techniques like this, we’re going to clean up a few things in feed_tools.

Last week, a couple of unrelated sites I’ve worked on converged on the same problem: slow loading of data from RSS feeds. In one case, the site at times refused to load a feed at all, then at other times added a whole second to the page load time! The culprit, of course was feed_tools. While a very versatile and flexible library at parsing even ill-formed feeds, feed_tools is notorious for poor performance and huge memory usage. I was inspired by Charlie Savage’s resurrection of libxml-ruby to do the same for feed_tools, partly because it’s an old library (started in 2005) and because it would be an excuse to use the new hotness that is libxml-ruby.

To get a sense of my progression on this, follow my Twitter page. Here’s a few:

If FeedTools were to have a mental disorder, it would definitely be paranoid schizophrenia. Let’s hope I can be an anti-psychotic.

FeedTools’ largest problem is a lack of DRY (and poor Ruby style). The real intention of the code is lost in the repetition.

FeedTools uses ObjectSpace. EPIC FAIL