Archive for the ‘Ruby’ Category

Emulating Ruby’s “method_missing” in Python

Tuesday, November 2nd, 2010

I don’t pretend to be a huge fan of Ruby. That said, I can respect when a language has a feature that’s pretty damn neat and useful. For the uninformed, method_missing in Ruby is something like the following:

Obviously, this is a trick that should be used with caution. It can make for some unmaintainable code, as a class with many methods could get difficult to trace through and figure out just what the hell is happening. It can be put to good use, though – take an API wrapper, for instance. What’s it consist of? Generally, nothing more than the same function calls made over and over to various service endpoints.

Cool, let’s use this in Python!

I recently rewrote Twython to support OAuth authentication with Twitter (as of Twython 1.3). It ships with an example Django application to get people up and running quickly, and the adoption has been pretty awesome so far.

The funny thing about the Twython 1.3.0 release is that it was largely a rewrite of the entire library. It had become somewhat unwieldy, some odd two thousand lines of code with each API endpoint getting its own method definition. The only differing aspect of these calls is the endpoint URL itself. This is a perfect case for a method_missing setup – let’s catch the calls to non-existent methods, and grab them out of a dictionary mapping to every endpoint.

The source above is fairly well commented, but feel free to ask in the comments if you need further explanation. This resulted in a much more maintainable version of Twython – for each function that’s listed in a hash table, we can now just take any named parameter and url-encode/combine it. This makes Twython pretty API-change agnostic of the entire Twitter API. Pretty awesome sauce, no?

On Date/Time/DateTime in Ruby, and why they suck

Sunday, July 18th, 2010

Yeah, there, I said it – this is a stupid situation for a language to be in. The concepts of Date, Time, and DateTime are all pretty well related – Date is a point in Time, DateTime is a really nice representation of Date and Time mashed together.

In a world that actually makes sense, you’d be able to easily convert between these types (e.g: DateTime should be able to easily convert over to a Time object). Some people might suggest patching the aforementioned classes (like Rails does, for parsing relative dates), but this just feels like an incredibly hacky solution.

Now, normally, I’m not much of a Ruby guy, give me Javascript any day. However, there are a lot of awesome projects written in Ruby, and it’s hard to deny that they’ve easily got the best packaging solution for any language. As it so happens, earlier this week I was hacking on a little Sinatra side project. DataMapper was my ORM of choice here, because it’s just so beautifully plug and play.

In the example app we’ll look at, it’s your basic Post/Comment scenario. For each Post/Comment, we want to be able to render the relative time ago that the item in question was submitted (e.g, “16 hours ago”, etc). Rails has conventions for this baked in by default (because they, y’know, enjoy polluting namespaces, go figure). When you’re outside of Rails and want to do this, it’s somewhat more difficult.

Originally I started by storing the creation time as DateTime; makes sense, we should be able to convert this to Time to do easy comparisons against Time.now, right?

Well, uhh, no. Definitely not that simple. After some digging around, I discovered the dm-types gem, which adds some extra types to DataMapper. One of these types is known as EpochTime, which is (you guessed it) the time since Epoch that the entry was created.

With that, we can pretty much stay within the realm of Time. Ripping apart ActionView gives us a good base to work with on the act of getting a relative string; putting it all together, we get the following Sinatra app (two files – the main Sinatra app, and our custom date_helper library).