Creating Rails Plugins, Refactoring Helpers and Deploying Rails at Rails Edge Reston

It’s day 2 of Rails Edge Reston. Right now we’re in the middle of the Rails Golden Deployment Path talk by James Duncan Davidson. Jim Weyrich is pair-presenting. Jim told an interesting story: sometime last year he tried to get a Rails app going with FastCGI at his local Ruby group. They had several different approaches and it took quite a while to get it up and running. The next day Mongrel was released and he got his Rails app running on it right away. Needless to say, FastCGI is not the way to go anymore.

Duncan recommends using the MacPorts package manager for installing Rails. I completely agree though I would augment it slightly:

If you can install a Rails plugin, do that. If you can’t, then install a Ruby gem. If you can’t do that, then install using MacPorts. If you can’t do that, then download, configure, make and make install. The reasoning is because I want to do a) less work (i.e. be more efficient) and b) limit the scope of environment changes.

Tip from JDD: Create a different database user per Rails application. This helps isolate your app and protect your users.

More security tips: JDD: “Use either really huge database passwords or even better, get it from a secure file on the deployment system.” Jim W: “Don’t check your passwords into an open source svn repo.” Marcel Molina: “Put your passwords in environment variables.” Tom Copeland agrees with Marcel.

OK… going back in time, Chad Fowler and Bruce Williams showed us how to write a Rails plug-in and also incidentally how to write a Rails generator. They re-wrote acts_as_ratable which shows you how to add Netflix-like rating functionality to your app, complete with stars. Very cool stuff.

Why should you write Rails plugins? Chad gave 3 reasons: to share functionality that is generic (like acts_as_tree which will be extracted from Rails Core), to monkeypatch Rails (since plugins are loaded later in the initialization), to share models among your apps (we’re doing this at one of my clients.)

Marcel M (who btw is much more mellow in real life than his picture) gave a vapourware talk about the Presenter Pattern which is a proposal for solving the problem of Rails Helpers becoming a dumping ground for methods and getting huge and full of smelly fish. (Well ok maybe I’m taking his slides too literally.) Seems like a good idea – large classes are generally a bad smell as Martin Fowler would say.

By the way – all 9 presenters are here. So the Rails Edge experience is a complete one – you don’t get a subset, you get the complete set. Oh and the wireless rocks – which is what lets me blog from here. I think that’s the new standard for conferences – you gotta have good wireless net access.