Facebook changed their authentication process fairly recently. Instead of using a global user id, users would now get an app-specific id instead. This took me by surprise, and I had to jump through some hoops to get stuff to work with our setup. This is a short post that outlines what we did to work around the problem.
A common piece of advice for dealing with bad rails code is to avoid making huge rewrites all at once. Instead, make small fixes whenever you see a problem. An often-cited variant of this is the “boyscout rule” – leave the code better than you found it.
This is solid advice. Putting hacks and workarounds would only make things worse. Rewriting swaths of code for even small features would take a long amount of time and introduce risk. The best approach is to make small refactorings and build new features with new, better, code.
As with most good advice, this can still backfire. Ever seen an app with five different caching mechanisms and seven different event tracking approaches, all slightly different? This may have been a result of multiple developers going “this is horrible, I’ll fix it”. In the end, they created an even larger mess, despite their good intentions. How did this happen?
In ActiveRecord, you can use the
selectmethod to run the underlying database query with a
SELECTfor particular fields. As a result, the object simply doesn’t have the rest of its attributes. Depending on the particular table and the use case, this could speed things up. Even without the performance argument, the idea to “get only the things you need” seems perfectly reasonable. This has never quite clicked with me, and I recently realized why. I’ve never encountered the problem viewed from this angle, so I figure it might be worth sharing.
I’ve always thought generating select tags was a bit odd in Rails. There are various choices and it might be difficult to decide which to use in a specific situation. A popular article on the topic is this one: Select helper methods in Ruby on Rails. It’s pretty old (2007), but still relevant. I’ll go through the helpers in that post quickly:
collection_select: Mostly used for model-backed data, invoked with all the method names it needs to build up the select box.
select_tag: A lot simpler, requires the option tags as a string, which usually needs to be delegated to another helper.
select: Used with a hash of names and values or with a list of pairs. This means that you can use it for any kind of data, including one from a model, but you need to prepare it first.
What the article doesn’t cover, though, is the grouped select helpers. They’re used when you need to categorize the data with optgroup tags. There’s info on the Net here and there, but I’ll try to give a quick run-down on how and when to use them. I’ll be using the
FormBuildervariants of the helpers, but I’ll also give an example later on for non-resource forms.