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.

Julython!

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.

StarCraft 2 On Sale

The price is down to $39.99 in the Blizzard store.

Normal Folks

A lot more stomachable by the casual or younger gamer who doesn’t put forth the same spending power as those of us who have jobs and love gaming.

Smurfs

It also brings down the cost for people who would like a smurf account. This phrase is newer in the online gaming community, only a few years old at best. It means to get a new account with the goal of playing against lower level people and/or climbing up through the ranks.

In SC2 the primary use case appears to be for race switches. Say someone makes it to platinum with Protoss then decides they want to play Terran. They are going to get crushed in their current league with Terran, so they start a smurf account and play Terran on that until they are comfortable enough to take it back to their primary accounts.

My First Week as a Mozillian

So I started at Mozilla about a week ago. Here are my experiences and thoughts:

Code Reviews

This is my first company where code reviews are common. I’ve worked places with pair programming which achieves the goals of code reviews to certain extents. Unfortunately that is less possible in a distributed team. I can’t tell you how nice it is to have someone looking over your code before it goes into the codebase. Code is rarely isolated so having the eyes of someone who knows more about the other systems your code might affect and questioning things, finding edge cases you forgot to test or letting you know better ways of doing things.

Warm Environment

And I don’t mean because HQ is in California. I feel comfortable asking any of my co-workers and managers questions. They’ve all been there, Mozilla is a big place with lots of code. Not sure how/why some code works the way it does, link it in the project channel and ask. Not sure the policy on something ask anyone you’ve met so far, if they don’t know the answer, they know who to ask. Feeling lost or getting stressed, talk to your manager, they genuinely want to help you be the best ‘you’ you can be.

That last one bears being expanded on. Your managers don’t want you to be successful just so you are a more productive member of the team. They want to do what they can to help you be great all around. They have a focus on goals and these goals are not just things like “Fix this part of infrastructure at work.” They should be things you want to do/be/learn as part of your life. For me these are things like giving talks at big conferences, learning to write high scale code.

Idea Sharing

So many companies want their employees to share ideas, this way they can use them to make marketable products. At Mozilla, I feel comfortable sharing ideas I have. This is because if/when I work on them I know that they’ll be open creations. My co-workers decide to help or support me in an endeavor are also striving to make the web an open great place for everyone. It also helps that you are surrounded with brilliant people who are involved in the community in various ways. If you propose something, someone probably knows of some similar prior art, or maybe even the exact thing you are looking for. It is a culture of people coming up with ideas, so no one will just shoot you down, instead they’ll probably help you flesh the idea out into something even greater!

Right not Rushed

Another thing I’ve never seen said so much in a company. I am trying really hard to be a fully productive member of the team right away. So much so that I feel like I am slipping a lot because I can’t get things done as fast as I think I should be able to. The slowdown comes from learning a new codebase and the overhead inherent in that process. Complexity lurks behind every branch.

The thing I keep hearing from multiple people on the team is to not worry, things take as long as they take. They all know, as well as I do when I think objectively, that rushing through something to try to get it out because you feel like it has to be out ASAP is a good way to make mistakes. Take time, understand the problem, write code and tests, then put it forward for review. This is something everyone on my team seems to value. I can’t tell you how much of a relief it is. I’m still striving to be as useful as I can as soon as I can, and I know I have my team supporting me.

Conclusion

Mozilla is a wonderful place to work. Big, but wonderful. The best advice I can give anyone who decides to read this because they are just starting at Mozilla, or perhaps considering applying at Mozilla: relax, take your time, and ask questions. Everyone is as excited to have you on the team as you are to be on it.