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.
ZenIRCBot! I haven’t spoken about this for a while on my blog but here I am. I gave a talk on ZenIRCBot yesterday here at Open Source Bridge. The talk wasn’t great but Eric Holscher also gave a talk and his was fantastic.
On to the main topic of this post though, something that I was working on months ago but got side tracked when I decided to finally get a job again is ZenIRCBot 2.2. Most of this update is the change from an internal API to ZenIRCBot API being its own beast that is on NPM and PyPI. The internal API is depreciated and I plan to remove it in 2.4. There will be no continued development on it. Instead the new API libraries will be developed. If you have additional languages that you’d like supported please feel free to write an equivalent library and send a pull request.
There should also be better protocol parity across the various versions of the bot (node.js, python and clojure). And the docs should much more closely match what happens, regardless of what version of the bot you are running. This was facilitated by finally writing a way of doing integration testing. It is still pretty new and developing rapidly but it has already served a great purposed.
If this release breaks anything for you please let me know, preferably as an issue on github.
I just learned about a project that is rather exciting to me: Julython. If you are looking for an excuse to write some python, this is a great one.
The idea is to commit at least a little bit every day of July on a python project, preferably one that is open source. You get 10 points for committing to a tracked project for the first time and 1 point for each commit after that on the project. This is interesting because it encourages people to work on a wide variety of projects, as well as encouraging numerous small commits.
The variety of projects side is pretty rad, you can add tracking to forks of projects (so it at least tracks your fork) so you get big points for working on a lot of other peoples projects. Hopefully people who do that, then send a pull request to get their code integrated. I really enjoy the idea that I get lots of points for helping out and getting involved with a many projects.
The numerous small commits side is interesting as well. Some people subscribe to commit early, commit often. I try to but tend to get side tracked and end up with a lot of changes that I then have to split up into their own commits. If I am being lazy and it is a personal project, I might just be lazy and commit it all in one commit. This will encourage me to fix that habit.
Anyway, my main focuses for this month will be two projects of mine: ZenIRCBot and SC2Clan. I also hope to patch other people’s projects and get involved where I can in as many places as I can.
Today marks the day when the bot’s API should only expand, without removing or changing the currently available messages that the core bot sends.
admin.js now uses forever a Node library for process management akin to runit, god, or supervisord. The big win with forever over those others is that it has both a command line interface as well as the ability to use it as a library. This lets admin.js no longer have to shell out to fabric which shelled out to tmux (you can see why I replaced it).
The types of messages that the bot emits is still more limited than I’d like, but I can add to the API without making backwards incompatible changes. Also the bot is still just a neat bot not a useful one for most people. This will hopefully be changing in the near future.
If you are following the development or using the bot yourself, these are some things you should know. First off, master should remain stable now. All development will take place on develop and in branches. Once I am done with a feature I’ll merge it into master and tag it with the version. Versioning will work as follows: x.y.z
- x will change if there is a backwards incompatible change in the bot. This includes config, protocol, and services API changes that are backwards incompatible.
- y will change if there is a change to the core bot and its protocols that is backwards compatible. This means if I add any new message types or options that default to how behavior worked before you’ll see a y version change.
- z will change when it is just a service changing. For now these wont ever trigger a y or x change unless it is pretty drastic. This may change in the future.
Also, if you use the bot, or would if there were certain features/services available, please post them as issues on GitHub. If you like it or want to discuss it, let’s hear about it in the comments or in #pdxbots on Freenode.
Over the last two weeks or so, a ton of development time has gone into ZenIRCBot. At this point it is still more of a neat project than a good IRC bot. But it is rapidly improving, and as I get more adoption I get more embarrassed about the ways that it is rough around the edges. That embarrassment leads to opening tickets and fixing them.
My last post I mentioned using SemVer which I didn’t really follow through on like I had intended. This is also a point of embarrassment for me. My plan is to get through some more issues and get to where I hope things will stabilize more. I have a 2.0 milestone that is going to be the line in the sand. After that, if I want adoption rates to go up, I have to start tagging versions, developing outside of master and merging in when things are ready, etc.
Other interesting news on the project is that there is now a Clojure version of the core bot. It is a git submodule as there were a number of files needed in order to run it, as opposed to the Node or Python bots where they are single files. The Clojure version of the bot is here and there are instructions for using it.
A final note is if you notice services missing that you expect from a standard IRC bot please open up an issue or even better, write it and send me a pull request. If you need help using, developing, or just want to discuss the bot feel free to hit me up in #pdxbots on Freenode.
Back in August 2011, I started ZenIRCBot both as a learning experience in Node.js and to fill a need which was a IRC bot for personal use as well as for use at Aquameta. Since then a few of my friends have picked up using it to have their own IRC bots that they can easily write services for.
In other people using it, I got some valuable feedback like using executable config files while sometimes really handy, makes it harder to write services that build on each other in different languages. To this end I plan on changing out the executable config files with pure JSON ones. JSON is already required to communicate via the protocol so this makes sense to me.
Another thing that is spawning from others using the IRC bot is I need to start being strict about my versioning. I’ll likely go with Semantic Versioning as it is basically what I’d already do but has more formal specification. The config files will be treated as part of the public API, as well as the protocol. This means when I change the configs to be JSON I’ll also be bumping the version number to 2.0.0.
Other things that will be coming out in the near future are docs for every service, another pass over existing documentation, additional services, a way for services to register themselves, and a new mechanism for running the bot. These things and more are all in the issues on GitHub. If you have any input for additional services that would be useful please feel free to open a ticket, or if you feel so inclined, write it and send a pull request.
This project has been the most interesting IRC bot I’ve ever written. All in all I think this project is going well and I am looking forward to it evolving over the coming months as it get more adoption, better docs, and cleaner code and APIs.