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 blogged last month about my goals and where I wanted them to be. In response to that I built a site that helps me track where I am for the 7 days trailing. That site can be found at http://training.wraithan.net/.
Users log into my site via Dailymile using OAuth2 since I need to get their API token in order to collect their workouts and display them. You can see my profile at http://training.wraithan.net/profile/Wraithan. At time of writing I am nearing my goal for biking but my running and hiking have suffered.
I built this site using Django, I did all the OAuth2 stuff myself because when I last surveyed the existing work with OAuth2 and Django, I found I would have to write my own. I turns out it is pretty simple, and because of the many drafts that exist, it would be pretty trying to have a more generic app for this. This will hopefully change when OAuth2 is finalized.
Dailymile’s API has some warts but it is usable and they were rather responsive when I had some requests for features and the one or two bugs I ran into. Plus their terms of service for their API are really reasonable. I can’t say the same about other workout tracking sites I looked into, either they had a horrible ToS or they plain didn’t have an API.
GitHub Repo Widget was rejected during its review due to the GitHub library I was using doing JSONP which (quite legitimately) the add-on reviewers flagged as remote code injection. This was a setback as I relied on that library to do most of the work for me.
In response I started writing another GitHub library that used AJAX to hit the API and get the data back I wanted. I was stumped when I was getting a status of 0, status text of “error” and no explanation of why this was happening. Turns out it was being block for doing a cross-domain request. Next, I learned about CORS and thought that might be my savior, until I realized I wasn’t executing from my own context but from my tab’s context so it is that domain that things have to come from.
I gave up and asked in #jetpack on irc.mozilla.org and was pointed to the request module that is part of the add-on SDK. I was a bit bummed as I knew this would require quite a bit of rethinking how I do things. Fortunately it wasn’t too bad, two hours and a whole bunch of message passing later I had a module that would work with v2 of the GitHub API and filled all the needs of my add-on for now.
I’ll toss another update on my blog when it is finally accepted as a full add-on and is searchable.
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.