Get Involved

Getting involved is something I’ve blogged about a few times on here. Each time has been a pledge to get more involved in the open source community in different ways. I am more involved now than I have ever been previously. I feel comfortable finding an issue in a project, forking it, fixing it and sending a pull request. Also, I find myself writing docs for projects and sending them as pull requests as well.

I was reading a post from Alex Gaynor about funding open source developers. I am all for that and in fact am using Gittip to fund several developers. Currently, I only fund each developer $3/week, which only comes out to $13.50 a month for each of them. But, I am unsure how many people I am going to end up funding and want to feel things out a bit before I commit more than that.

Now I find myself putting forward a little time and money here and there to various projects but I still don’t feel like that is enough. I can’t seem to get past the 2-3 commits on a project then walk away mentality that I’ve built up.

My next goal is to become really involved in some project or community, and not because it is convenient but because I find it fun and engaging. In this goal though, I’m not going to beat myself up for not getting deep into a project. Just getting more commits in—be it docs, tests, or actual code—will improve my impact on the community. If I end up just being a nomad who dabbles in many projects but manages to consistently do that, I’m ok with that.

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.

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.

An Exciting Update

Sometimes when you are waiting for something, time goes by very slowly. But because you are so focused on that one thing, everything else in life moves really fast. I’ve been unemployed since the end of January. During that time I made ZenIRCBot significantly better, I wrote a simple site for tracking your workout stats, I attended two conferences, PyCon and Barcamp Portland. I visited two states that I’d never been to. Flew for the first time and took my longest train ride.

Basically I’ve done a ton in this time. But it feels like it has been a really long time because I’ve been so focused on getting my resume put together with Mozilla in mind. Then once I finally had that to a point that I was happy, I started showing it to friends for them to review and that took forever. Then I handed it off to my friend Jason to apply and write a letter of recommendation for me.

Then I waited another eternity (it felt like at least) to hear back, be flown down and get an offer from them. I was so focused on that, that everything else flew by me and I may not have gotten the most out of things. Which is fine because I’ll be starting at Mozilla on the 29th of May. Working on http://addons.mozilla.org and related sites with the WebDev team.

What that should really read as, is that I am incredibly lucky to be getting the chance to work at a company that I’d only really dreamt of working at before. I’m going to be working with some awesomely brilliant people, for a company who’s mission is to make the web a better place, while working on some really interesting and difficult engineering, doing it in a language I love (Python) with a framework I love (Django). If you know me, then you know how much I love working on interesting hard problems.

I’m writing this mostly as a stream of consciousness because I don’t have a better way to put this stuff together. In the future I’m hoping to take some time, get some peer review for my posts before I put them up and talk about the awesome things I’m doing at Mozilla and in my free time. If you want to be someone to helps me with my writing, let me know, I could use all the help I can get.

-Wraithan

GitHub Repo Widget Update

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.

Hello Firefox Add-on World

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.