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.
One of the more exotic features of Vim is its remote control functionality. Basically, if you invoke Vim with
--servername SOME_NAME, you’ll be able to send commands to it with another Vim instance. Using this, I’ve recently attempted to fix a common annoyance with vimscript – its limited testability. By spawning a remote instance and controlling it through ruby code, we can use cucumber to perform simple integration testing for Vim plugins.
This is not something I’d do for all code I write, but in some cases, it could be a life-saver. My splitjoin plugin is one example of a project that I wish I had a good test suite on, considering the amount of regressions I’ve had when modifying functionality. In this blog post, I’ll describe some ruby code to drive a Vim instance remotely and a few sample cucumber steps you could write to make use of it.