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.

PDX Games.js

Dave Justice suggested that we have a three.js hack day. I decided to one up him and go for a generic games written in JS hack day, thus PDX Games.js was born!

Currently all the details are tentative. I need to clear it with our office manager as well as work out food/drink sponsorship.

The reason this is exciting to me, is that I have been intending to get back into game development for years. If PDX NodeBots Day is any indicator, a hack day inspires me greatly to get into something.

My project idea: I have attempted a few times (back when I was a very young developer) to build a clone of Final Fantasy Tactics. I’ll be setting out to do this, on the day of I’ll be spending most of my time building the graphics engine for the combat board. If I have spare time, perhaps I’ll spend time on menuing and other things like that. My end goal is less a full clone of FFT but a FFT-like game that I’ve built myself and have running with modern graphics and such.

The hack day, regardless of the specific details, should be a ton of fun.

Uncomfortable and Unsatisfied

I want to build a small website. Django feels a bit heavy for what I want to do, and I would like to give node more of an honest shot for building websites. I need to store some user data (name, email, notification settings). Also I need to store some topics and opinions on those topics. I’d like my users to be able to log in using Mozilla Persona.

The first thing that pops up when one goes to do websites using node is Express. You start using it, maybe asking a couple questions, and you find out noisy parts of the node world hate express and think you should use something else. Unfortunately, they may list one or two alternatives, likely those are things they wrote themselves or a friend of theirs wrote. They are probably especially young, which means there is unlikely to be drop in support for anything.

Once you get past that part, you are told there isn’t support for the 10 things you actually wanted to do, but don’t worry there are 100 modules for each of those things. You’ll have to learn everything about the web package you are using, as well as the packages you want to glue together, praying there is some sort of common api. Sorry though, this one is streams based, but not those streams you are used to, you have to write a compatibility layer. And this one isn’t stream based but doesn’t like the request object you handed it, etc etc.

I get that a lot of this is a matter of comfort. I feel better in django/python because I’ve been here for a long time. I know what modules are good and which ones to avoid. Maybe, if I can get over this uncomfortable feeling, I can make something satisfying. As it stands though, I am unable to find anything that makes me happy when it comes to building websites in node.

ZenIRCBot 2.2

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.

ZenIRCBot 2.0

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.

ZenIRCBot update

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.

The direction and future of ZenIRCBot

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.