Open Source Bridge has generously given SE Portland Coders’ Night a free ticket to their conference to be given away at random. So what do you, as an interested party, have to do to win it? It is really simple, show up to the next SEPoCoNi which is on Thursday, March 29th, at 6pm. Show up by 8pm and get your name entered. Win and it is yours! Lose and well, you still get to hang out, talk code/tech/etc with us and eat delicious nachos. Details below.
Open Source Bridge takes place on June 26–29, 2012 in Portland, Oregon. If you can’t make it to this please do not enter. If you enter, and find out later you can’t make it, contact me and we’ll see if we can give back your ticket for another one to randomly give away at one of our meetups.
SEPoCoNi is a social and coding get together once a week at The Side Door on Thursday at 6pm. We are language, framework, and platform agnostic. Come and eat nachos with us.
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.
I’ve spent a considerable amount of time in the last two days writing my first Firefox add-on. I have the pleasure of working with their new SDK for add-on development: Jetpack. So far it has been a rather pleasant experience. A few times I had to ask questions on IRC because something was phrased differently than I expected so it didn’t seem like the thing I was looking for. Other than that, most things have been pretty intuitive.
I’m in the process of writing a little add-on that will sit in the bar, and when clicked will show a window of all of the user’s GitHub repositories with quick links next to them for code, issues, wiki, and home page. This has stemmed from my dislike of the 3+ page loads needed to get to the issues for a given project, which can be pretty bad on crappy cafe wireless. I considered a desktop app, but then I’d have to make it cross platform as I develop on OSX and Linux.
The source is on GitHub, unsurprisingly. It is currently a work in progress, but I have a list of issues for 1.0 and once those are all complete (and any other that come up as blockers) you’ll be able to find my add-on on the Firefox Add-ons site.
One of the parts of the process that made me really get into going with this project was their new Add-on Builder which lowered the barrier of entry incredibly. After a few hours of docs reading and fooling around with it, I ended up moving to local development. Not due to any flaw in their Add-on Builder, other than it isn’t Emacs.
I started using their command line tool cfx which also made it really to change some code, save, then run it in a clean browsing session. I was surprised how nice these tools are, they are head and shoulders above most language/framework development tools I’ve used. I look forward to using the “cfx xpi” command then publishing it to the web, just as easily as I got started. Overall I highly recommend the experience to anyone who has any desire to build a Firefox add-on.
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.