Background

When we recorded next week’s ATP, we realized shortly before show time that our showbot wasn’t operational. Since the showbot wasn’t even our work, we couldn’t really complain. Brad Choate took it upon himself to be kind enough to fork the open-source bot that is used on 5by5. We owe Brad many thanks for roughly a year of faithful and uneventful service.

If you’re not aware, while we’re recording our podcast, it’s also broadcast live. Additionally, we have an IRC channel (#atp on Freenode) where we hang out with listeners. In this channel, there’s an automated robot that listens to the channel for title suggestions. Those suggestions are logged and placed on a page for us hosts to review at the end of the show. Additionally, listeners can up-vote titles they really enjoy; this lends a completely false air of democracy to the process.

So, what with the bot being down for that episode, Marco took it upon himself to whip together a really quick-and-dirty showbot using his PHP framework in the span of 20 minutes. It didn’t have an IRC component; it was simply a web page that one could use to suggest a title or up-vote an existing one.

A Challenge

That got me thinking… I wonder if there’s an IRC package for Node?

Spoiler alert: there is.

So, during the after show, I started to hack. Within around the same 20 minutes, I had an IRC bot that was POSTing to Marco’s short-lived web form.

The next day, I spent a few hours hacking on it. While I’m certainly not done with it, I’ve come up with something that seems to be functional.

Thus, I’ve open sourced “Accidental Bot”; you can find it at GitHub, of course.

Getting Cute

As is often the case, recently I stumbled upon a new technology that I really wanted to find an excuse to use. In the past, that has been things such as .NET reflection, LINQ, Cocoa Touch, or iBeacons. In the case of Accidental Bot, however, it was two things: Node and WebSockets.

Node has been mentioned quite a few times in relation to Camel, the engine that runs this site.

WebSockets are something I’ve only been able to play with briefly in the past. The general premise is, rather than having a user’s web browser continually asking the bot “Can you send updates?” on a regular basis, instead, I instruct the web browser to take a different approach. In this case, the web browser opens a connection to the bot, and keeps it open. Thus, as new titles or votes come in, the bot can push those updates directly to all connected users immediately. This is far preferred to having a latency between the time that a vote or title comes in and the time a user sees it on the site.

So, Accidental Bot conists of a few components:

1. The bot itself, written in Node.
2. The bot’s connection to the IRC channel, to listen for suggestions made there.
3. The client page, hosted on this site.
4. A websocket connection between the two.

In very quick and brief practice, this seems to work, and work well. What’s on GitHub is the result of less than working day of hacking, and thus, there are plenty of features that could be added, and plenty of bugs lurking beneath the surface. However, when we record next, I plan to have the Accidental Bot running to see if it can handle the load.

Gotcha

First, the titles page is not terribly exciting to look at when the bot isn’t running. And, generally speaking, there’s no point in keeping it running when we’re not recording.

Originally, I would have liked to have hosted the titles page in the same Node server as the bot itself. However, I’m hosting the bot on Heroku. Heroku only allows each dyno to have one port open–in the case of the bot, I need it for web socket connections, and thus can’t open a second port for just plain web connections.

Luckily, since connecting to the bot is done client-side, there’s no reason I can’t host the titles page… anywhere, really. Thus, I looked to the obvious place: the publicly accessible web server hosting this very site.

In a perfect world, I would have opened a web server within the bot and handled sending the static HTML page from there.

I also don’t like that there’s is no persistent storage for titles, should the bot crash during recording. I don’t see the point of rolling an entire database—even NoSQL—for something so ephemeral. However, I can’t even dump a JSON blob on the filesystem because the filesystem is also ephemeral.

Future

Knowing me, as soon as this bot is good enough™, I’ll leave it be and never touch it again. However, there are certainly plenty of improvements that can and should be made.

Nevertheless, my hope is that fledgling show networks may want to build on the work that I’ve done, to help make the experience that much better for their listeners.