The cowbell of the Interwebs
It seems there’s a fair amount of interest in MongoDB in the Seattle area, so a few of us are getting together to talkshop next Wednesday. Here’s the skinny:
You can check out all the details on Plancast.
Thanks to Jesse over at Blue Box Group for hosting!
At reQall we started out using the standard ActiveRecordStore for web session data, but switched along the way to MySQLSessionStore. Lately we’ve been trying to reduce DB load and decided to move our sessions into memcached (they’re soft state, after all). So, easy enough to do in Rails 2.x right? Switch your session container, restart your thins and you’re off to the races.
The catch is, we didn’t really want to force all our users to re-log into the app. We could, and most probably wouldn’t notice, but that’s not how we roll. So, we decided to migrate all the existing sessions from MySQL to Memcached. Turns out it’s pretty easy. MySQLSessionStore keeps everything in a data column in the sessions table, which contains the base64-encoded output of Marshal.dump(<your session hash>). The built-in logic in memcache-client handles the marshaling and unmarshaling when creating the new sessions, so migrating looks something like this on the console:
Simple, no? A word to the wise, though – do it in batches of 1000. Session.all would be bad.
You know the drill:
Or:
Or even:
I know, I know. “But I don’t do that!” Sure, you don’t. But what about that person in the Duluth office? You know, the one who still thinks that the whole project should be written in JSP and can’t wait to get all this done so he can go back to working on his port of “Leisure Suit Larry” for HP printers? I bet if you look hard, you’ll find a few exception handlers that are overly broad in scope, don’t provide sufficient context in their error message or just plain hide problems.
“But my tests!” you cry. “Surely the finely crafted specs I’ve been working on will save me!” The problem is that overly aggressive exception handling in your code will mask the true cause of errors, resulting in a false sense of security. Sure, assert_nothing_raised and should_not raise never fire: your code is consuming the warnings and continuing blithely on its way.
This is why most ActiveRecord reference material emphasizes the user of find (vs. find_by_id), save! and the like, but doesn’t include begin and rescue blocks – it’s often better to have things blow up on you than guess at what error conditions might arise and attempt to handle them as you’re writing the code. You can write tests around the exceptions, insuring that your code errors out in the appropriate manner when faced with bad input or exceptional conditions.
On the other hand, when something unexpected happens in production and your site starts giving everyone an eyeful of your funny 500 page you’re unlikely to be so happy with all those uncaught exceptions. Ah, the usual tension between development and production. Enter tattletale.
tattletale is your hall monitor, your prison snitch: it tattles on all the exceptions raised during a particular test run, including messages, backtrace and the test that raised it. All of your existing exception handlers will work as expected, so your code doesn’t change. I’ve written a Tattler for Test::Unit for starters; extending to your favorite test framework should be as easy as writing your own Tattler. Grab the gem off github and take back your exception handling.
Ah, the <blink> tag. The internet’s version of the cowbell. In an effort to start giving back more to the Ruby community (big fan!), I’ve decided to start a more technical blog and talk a bit about programming languages, software development with distributed teams and sundry other topics. As this blog’s title might imply, I will endeavour to entertain as well as elucidate.
As a way to kick off my new year’s resolution to blog more about technical matters, I thought I’d share this nugget of Ruby syntax fun. Say you’ve got the following code:
Simple enough, no? Well, then this is exactly what you’d expect:
Hold on. Why does calling foo with nil as an argument result in ‘nil’ being printed out?
The answer is actually spelled out in the Pickaxe book, though it’s rather subtly worded:
Ruby lets you specify default values for a method’s arguments—values that will be used if the caller doesn’t pass them explicitly.
In the first case, we’re explicitly passing the value nil, so our default parameter value isn’t used. In the second case, we’re passing no arguments to the method, so we get the default.