has_many :through

A project I'm working on now is up to 57 model classes and is still growing. That's a lot of classes - welcome to domain modeling. In my opinion, the number of classes is a fair tradeoff that keeps each class simple enough to understand. In some ways it moves complexity out of the model class internals into the inheritance hierarchy, which is an important part of object-oriented design. I've worked on projects with many more model classes than that too. (Financial applications seem to require a lot of classes to model the complicated workflow and permission systems.)

The place where it starts to get hard to manage is when I look at the file system and see so many files in one directory. My brain usually starts to overload when I see more than a dozen or so classes in a directory. My first inclination is to throw some related class files into a subdirectory. The problem is that the standard way to do that in Rails is to put those models classes in a namespace (module). Rails used to have big problems with namespaced models, mainly with the dependency auto-loading code that finds class files based on the model class name. Most of those problems have been fixed, but there are still some usability issues with namespaced models.

Continue reading...

Symbols are one of the basic features of Ruby that give it that certain charm we all love. They aren't unique to Ruby (look at Smalltalk or Lisp), but they are a fundamental piece of the language. I'm not going to review what symbols are in this article since there are plenty of other explanations a short google away. However, I do want to say a few words about what I consider a common misuse of symbols.

The way I see it, symbols are great for naming things in your code, but bad for using as domain data. Over the last year or so I've seen a growing number of cases where symbols are used as an alternate syntax for plain old strings. I guess some people like to see :thing instead of "thing" in their code. Well, I don't like it. Sure you get to save a character, but at what cost? Won't somebody think of the children?

Continue reading...

If you hadn't heard, GitHub had their public launch today. Congratulations to Chris, Tom and PJ on such an awesome product. I'm sure there's a bright future there.

I keep getting surprised by how different using GitHub is for me. Last week someone I never met or had even heard of found my migration_condordance repo and submitted a fixes for two bugs. It wasn't quite as big a thrill as my first kiss, but I sure got more of a rush from that than from seeing Beowulf in 3-D IMAX. On the other hand, when I saw someone else stopped watching my repo I was actually a bit sad. Yes, this is geek social networking with both value and impact.

You've probably heard that the Ruby on Rails is moving the official repo to GitHub. It's not active as of this writing, but give it a few hours. It's now active at http://github.com/rails/rails. I'm looking forward to seeing what this does to the contribution process. I expect there could be a rich ecosystem of forks of Rails where you can see a bunch of variations integrated into a consistent whole. A lot of folks keep what is effectively a fork of Rails, but it's often in the form of a collection of monkey patches. Using git means that those patches can be managed more effectively, and even made available to the public in a form that can be easily consumed. Then it becomes much easier to evaluate whether a change has enough support to justify including it in Rails core - just see how many people are actually using the change, instead of merely of the opinion that it might be useful. I don't know how to track how many people are using a repo that way, but I'm sure someone will think of something - maybe just a count of how many clones were made or tarballs were downloaded.

At any rate, today feels like some kind of milestone. Or perhaps a furlongstone.

Simple things should be simple, complex things should be possible. — Alan Kay

Here's a tiny little tip for handling those boiler-plate pages that aren't part of your app's functionality but you usually need anyway. It's good for setting up about, contact, copyright, etc. You can always throw those pages into /public as static html files, but if you want them to get styled with layouts, they need to be rendered as actions. This is a way to do that simply. It's not rocket science, but I haven't done a noob post in ages and I'm getting over a cold and I haven't posted in too long so gimme a break.

Say you want to have a simple landing page and a few typical boiler-plate pages. Let's start with the routes.

In config/routes.rb

map.root :controller => 'home'
map.home ':page', :controller => 'home', :action => 'show', :page => /about|contact/

In app/controllers/home_controller.rb

def index
  # render the landing page
end

def show
  render :action => params[:page]
end

Throw your about.html or about.html.erb and other pages into app/views/home and you're good to go. If you've set up page caching, this won't even slow your app down.

The :page => /.../ bit in the route constrains it to match only those specific urls. If you want, you can change that to a constant, like HomeController::PAGES, so it's easier to manage.

If you want to link to those pages, you can use the route helper methods, home_path and home_url

link_to 'About', home_path('about')

You could always unroll the routes and have a separate route for each page, but I find this way a bit drier. But if you'd rather have a specific named route helper for each page, that's an okay way to go. Either way, you get to use layouts in your pages, and have a nice simple way to get them rendered.

If you are a solo developer, Rails' migrations are the neatest thing since sliced bread. If you work on a team, you know that often it can be a real pain dealing with migrations. Someone on your team checks in a new migration and you don't notice it when you svn up or git pull, and suddenly all your tests are breaking. Or even worse, someone modifies an old migration and you need to reset and migrate up from zero (we're talking development here, not production). I'm not a fan of automatically running migrations (I'll leave the reasons for you to guess), but I do like to be informed of when I'm about to run headfirst into a wall. Saves so much wear and tear on my noggin.

And so I give you the migration_concordance plugin. It's pretty darn simple. From the README:

This plugin extends Rails migrations to provide notification when you need to run migrations. It will detect both new migrations and modifications to previously run migrations. It is primarily of use for team development, but is also useful when deploying a release to a new environment to determine when migrations need to be run. This plugin does not run migrations automatically, but will notify you whenever you need to run them.

Continue reading...