Beeminding ZenIRCBot 3.0

ZenIRCBot is a topic I’ve written on a few times. Once upon a time it was my primary project outside of work. These days it has mostly become an unmaintained heap of code. I’ve grown significantly as a developer since I wrote it. It’s time for a revival and a rewrite.

I have a project I started about 7-8 months ago called clean-zenircbot which is a reimplementation of the bot from scratch using a custom IRC library I hope to spin out as a separate project. The goals of the project are things like being able to test the bot itself as well as making it possible for service developers to reasonably test their services. As well as documenting the whole thing to make myself no longer ashamed when I suggest someone write a service for an instance of the bot.

Going along with having written about ZenIRCBot in the past, I’ve also promised 3.0 a few times. So what makes this time different? The primary change is that I’ve started using beeminder (click to see how I’m doing), a habit tracking app with some nice features. My goal will be to fix at least 2 issues a week, or more which grants me a bit of a buffer. This will keep me pushing forward on getting a new version out the door.

I’m not sure how many issues or how long it will take, but constant progress will be made. I currently have two issues open on the repo. First one is to assess the status of the code base. Second is to go through every issue on all of the ZenIRCBot repos and pull in all of them that make sense for the new bot. This includes going through closed issues to remind myself why the old bot had some interesting design decisions.

Below is a graph of this so far. I’m starting with a flat line for the first week to give myself time to build up a buffer and work out a way to fit it into my schedule. Hopefully if you are viewing this in February or March (or even later!) the data will be going up and to the right much like the yellow road I should be staying on.

2 thoughts on “Beeminding ZenIRCBot 3.0

  1. I’m looking at your framework from the perspective of one who’s written a framework too (Tennu in this case – if you want to look at it), and the idea of adding services looks interesting.

    It seems to lock you into a case where you can only use events, and you have to maintain state in each service to figure out which events correlate. I was running into complexity problems writing code like this, and that it’d be better for the platform to instead return a promise for the command (useful for whois for examples), but that doesn’t look like it’d be possible to do something like that here. Or can you actually facilitate casual events in Redis somehow?

    It also looks though, like you should be able to just take an existing framework and write a plugin for exposing the services idea. It’d be inner-platform effect, but it seems like a better idea than reimplementing everything yourself. For instance, you could create a plugin “tennu-services” that has a “*” message handler that then passes it to Redis, and then switches the responses to calling the appropriate client methods.

    Should you decide to dismiss that idea, you shouldn’t have your own IRC Socket code in there. I published a library ( ) specifically so that each author doesn’t have to reinvent that. Furthermore, expr created a library for parsing IRC messages ( ) in a performant IRC3 compatible way. I write my own extensions to the output of the irc-message in Tennu (/src/lib/message.js), and if you want to use that, I can move it to its own package (probably named irc-message-extensions).

    • This bot framework already has a following mostly because of the fact that the bot and the plugins don’t need to be written in the same language. This makes it much simpler to pull in other bot plugins or use languages that may be better for the job. Also most IRC commands (like WHOIS) also return who they are speaking about so a promise like thing would be needless complexity. The only type of problem I’ve ran into is the case when you have multiple services that could reply to a message and you only want one of them to reply. I have a couple experiments I want to play with in that area and come up with something.

      I have no intent to write a plug in for some other bot and replace my bot with that. I may write one as a way for other people who are stuck with various other bots or would just prefer a different one, but it wouldn’t replace ZenIRCBot itself. My framework has more stars but is a bit less maintained. The bot has been implemented in many languages, several protocols translated to the ZenIRCBot service protocol so people can reuse services, services written that run on an arduino and manage to push events to IRC.

      I’m writing my own library partially for fun, partially as a challenge to write the fastest one around. I spend all day caring about performance at work, it would be nice to apply those skills outside of work and see if I learn anything new in the process. Also I want to make sure my bot is very testable and I’m designing the IRC library with that in mind.

      I appreciate the reaching out, but my bot is older and has a fair amount of users that I know of (and periodically find more that I don’t). I’m going to keep on with what I’ve been doing.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s