I’ll be giving a talk at BarCamp Copenhagen January 25th. I haven’t decided exactly what I am to talk about yet, but it is going to be on the tech track (called Geeky Sh*t), and it is going to be about some facet of Ruby on Rails - or perhaps just Ruby.

I could give a general introduction to Ruby, and to Ruby on Rails, but I guess the technical people at this conference are probably curious enough to have tried out the language and framework by themselves, and I know that a few of them will be equally or better skilled Ruby programmers than me, and therefore utterly bored at a basic introduction.

I could of course be preaching test-driven development (TDD) and show how Rails makes this approach quite easy, but haven’t TDD’ed much in my latest projects, because I was tired of having this huge, always-breaking test suite, which rarely caught any real bugs, and mostly just indicated that my tests was buggy. I’m starting to get a feeling that Cope is right when he says that unit testing can be harmful.

When I got the opportunity to start working full time with Rails - well, not full time, since I’m still a student, but all my 20 work hours a week - last spring, I was quick to decide on basing most of the sites on Radiant CMS to get a bit of common infrastructure. This turned out to be a good choice, but it did put a few limits to my opportunities for using the newest Rails features, as I had to follow the Rails version used by Radiant. As of today, Radiant has still not been upgraded to Rails 2.0. I have gained a lot of insight on how to get the most out Radiant - especially through extensions - but it is probably pretty irrelevant to hear about if you don’t use Radiant or are planning - or do not even use Rails at all (what a horrible thought!).

But I’ve learned a lot of what I think fits into the category of Ruby metaprogramming writing these extensions. I have had to override and extend quite a few methods and classes in Radiant through extensions, to get it act like I needed it to, and that has not been entirely painless. There are different techniques depending on whether you need to add or override stuff, and whether it is class methods or calls, or instance methods. You also have to consider when to use alias and alias_method, and you have to know the difference between them.

In fact, there is one trick I feel like sharing right here: How to re-enable sessions for a controller, if you can’t just (or at least don’t want to) remove the session :off statement in the original controller code. In this case I needed to re-enable sessions for the Radiant SiteController without modifying the Radiant code. This code did the trick:

module SiteControllerExt
  def self.included(base)
    base.class_eval {
      # This reenables the session for the SiteController - session :on does not work!
      session :disabled => false
    }
  end
end

You also need to include this module in SiteController in your extension’s activate method, or in environment.rb in other Rails apps:

SiteController.send :include, SiteControllerExt

Of course there is a lot more to metaprogramming than class_eval, but it is a start. I think this could a good subject for my talk, I just hope it is not too geeky for the audience. I might want to throw in some general dynamic vs. static typed languages and the whole - in my opinion very nice - duck typing philosophy of Ruby, just annoy the C# and Java guys. Yeah, this is going to be interesting - there is still a few open spots left at BarCamp Copenhagen!