ruby

One of the things that I've learned over my years at EchoDitto — that's been hammered home again and again — is the importance of email. Twitter's cool, social networking is great, but your online strategy absolutely has to account for email. It's not glamorous, but it's important.

The same is true on the tech side of things. It's easy to forget: on a day-to-day basis, my wranglings with email generally include dealing with spam blacklists, ensuring that scripts don't function as open relays, and writing templating systems that'll be used to send mail. All of it's pretty boring. But it's worth keeping in mind that email, when piped to a script, can serve as the infrastructure for some pretty neat services, too.

I did this two years ago for SXSW, building an SMS app on the cheap by counting on the mobile carriers' SMS-to-email functionality. It worked pretty well, although it was a rat's nest of Perl scripts.

This week I took a pass at another application in Ruby (with a PHP frontend), and this time the resulting code is a bit less cringeworthy. The idea is simple: set your Twitter "new follower" email notifications to go to a custom email address. They'll be piped to a script, disassembled and the new follower's statistics analyzed. If it looks like the new guy is a spammer or bot, they'll automatically be blocked. If not, they won't be. Either way you'll get an RSS notification about it. You can try it out here, if you'd like.

It's not exactly going to set the world on fire, particularly since Twitter is expected to release similar functionality soon. But the project does serve as a pretty good template for how a piped email service can work.

It was too terribly long ago that I posted a simple Twitterbot here. I'm sure you'll be absolutely shocked to learn that it had a few, uh, shortcomings. If you're making a TwitterBot (and particularly one in Ruby), here's some advice:

I've written my fair share of fly-by-night SMS services. Not for clients, of course — when someone needs a mobile campaign we talk to folks who live and breath text messaging. But I've hacked together a few hobby SMS apps on the cheap. There was this one, for example, which used email-to-SMS gateway functionality to provide a rating system for SXSW panels. Before that was LastCall, a genuine (if not shortcoded) SMS app I wrote for DCist that allowed users to check subway times, query OpenTable for available reservations and perform a number of other questionably-useful functions.

The DCist mobile service was a nightmare to put together. I bought a cracked-screen cellphone off Ebay, an unlimited-SMS mobile account and went through a half-dozen USB-to-serial cables before finding one with a Linux-compatible chipset. The software I used to spool messages from the phone to the server was a bit flaky, requiring a ton of configuration. And then WMATA changed their website and something went screwy, sending tons of unwanted text messages to hapless subscribers. The whole effort took months. The moral was clear: rolling your own SMS gateway is a huge pain in the butt.

That's why I used the email-to-SMS approach for the SXSW service. It worked beautifully, but everyone knows it's a little unprofessional — the mobile carriers can always shut you down, and users get confused when asked to send a text message to an email address.

To borrow a phrase from the execrable band Linkin Park, I'm breaking the habit... tonight! Or I was planning to, anyway. The habit in question? Perl.

I was powerless even as it strengthened its hold on me. It's not that I love the syntax — different operators for strings and scalars? A vast collection of frequently-unintuitive file test flags? No thanks. And the procedure for passing parameters to functions is frankly inexcusable.

But it's installed everywhere, and it's got bindings for everything. Yes, it's slow and unglamorous, but Perl reliably gets the job done.

Still, the cool kids were leaving it behind just as I was discovering the full, terrifying power of a scripting language and a well-stocked package manager. I tried to follow those cool kids, but a flirtation with Python went nowhere. I hated tying whitespace to logic, and when I realized how cumbersome its regex syntax was I threw in the towel.

So now I'm giving Ruby a shot, and I'm cautiously optimistic. I worked through the downright-awesome Try Ruby interactive tutorial and liked what I saw. Getting the language installed on my OS X and Linux machines was a snap, and Gems broke in ways that didn't seem outrageously worse than CPAN. Still, tonight hasn't been encouraging.

How can you have a scripting language with Flickr API bindings that are this bad? Of the three Ruby projects that claim to talk to Flickr, one is a partial implementation that is now outdated and broken; another got folded into a larger project that's never actually released anything; and the third is completely undocumented and doesn't work unless you authenticate with Flickr — a step that's complex and should be completely unnecessary for many operations.