Monthly Archives: August 2012

A Year of Open Source

This last year has been quite an interesting ride for me. A year ago, basically to the day, I first met the crazy people I now work with everyday on Popcorn and Popcorn Maker: Scott Downe, Jon Buckley, David Seifried and Chris De Cairos back at a friendly gathering to watch a UFC pay per view. I was pretty much set on taking the first course in open source taught at Seneca by David Humphrey but it was rather interesting to meet these new people and learn more about it and the kinds of things they did.

A year ago I literally didn’t know much. I had the basics skills taught to me by the previous courses at Seneca but honestly they didn’t prepare me for a lot of things with the web. Working on Popcorn introduced me to a lot of things that I didn’t know, especially with javascript. Man, I remember when I had no clue how to really use an XHR request and was so stumped on what to do for my really crappy tumblr plugin. Compared to today it’s quite amazing the differences. I can’t claim I know everything or even a lot right now but I find myself able to tackle a lot of different things but more importantly I’m able to work with others on the things I can’t figure out and discuss different approaches to finding a solution for a problem.

More importantly it’s the opportunities I get working on this project. It’s so cool to work with, collaborate with and meet all the ridiculously smart people with Mozilla. Some of those include:

Bobby Richter
Secretrobotron. Pretty much a genius. He’s sort of the software lead and an awesome guy. He also likes long walks on the beach, morning sunrises and phish.

Kate Hudson
Popcorn Makers designer. Truthfully she is also one hell of a programmer and could easily just work on any of the bugs the rest of us do. Honestly quite amazing. Don’t ever get her angry though.

What’s even better has to be some of the reactions of people when we show them the software and seeing how they use it. Yesterday and today we have been doing user testing and just watching them use the app is awesome. When you write up all of this and think about user experience for the app you feel like you have it covered pretty well but then all of the sudden someone brings up something completely different. You thought maybe the purpose of something was obvious but it isn’t at all and basically get’s ignored or some cool feature that get’s overlooked completely because it isn’t apparent at all that it even exists.

Honestly, I can’t wait for what the future brings. We have so many cool things left that we want to do and I just want to keep on working harder and harder. There’s so many cool things I want to do and working on all of these has given me many ideas for what I’d like to do in the future and the best part is with open source I can easily make that happen 🙂

Anyways, back to work!

Advertisements

Dealing with Bugs in Other Software

This is a well over due blog post. Honestly, we’ve been so busy with Popcorn Maker it’s been hard to just stop and take sometime to write one of these up 🙂 Anyway, I wanted to talk about one of the things that came along one day out of the blue.

Sometimes there actually isn’t bugs in your code!
We’ve always been striving to make our tests better and it’s an ongoing process. However one day out of the blue we quickly discovered that our tests literally would just stop running in Firefox after the update to version 14. Now our tests load a lot of video; It’s just part of the territory when your library is involved with video on the web it’s just going to happen. Now, recently in Firefox 14 there was a limit placed on the amount threads that can be used to decode media. Combine this with a bug in the code and our test runner would literally just stall in Firefox.

This is obviously a problem and we can’t just ignore the problem and let our tests just “not work” in Firefox until it gets fixed. At this point our tests were all grouped up into single files based on what they were testing. All media module tests were in one single test file, all trackevent test files were grouped together and so on. This meant that we weren’t giving the browser as much time as possible to teardown every single piece of media. In the end what we wound up doing was breaking down every single QUnit qsyncTest block we had into it’s HTML page. This not only means that it’s easier to trace problems with failing/stalling tests but it helps solve our issue of loading too much video too quickly for the browser.

Often one solution creates another problem
As the title suggests, this only opened the door for another problem with our how we load our node server locally. To replace having to use a generic makefile system we use shell.js along with various node modules like CSLINT, JSHINT etc and this allows us to avoid writing annoying makefile code with javascript instead. In particular we use their exec command which allows us to execute typical commands on the command line. For an easy way to start our server we have a shortcut command that changes into the cornfield app’s directory and starts the server.

Now the problem here was another bug that’s present with running shell.js’ exec function asynchronously. Without it our node app would eat a lot of system resources and with it our test runner would cause the server to crash by loading so many resources quickly. If you manually started the app no problems would arrise. Alas, we were blocked by another bug.

However, a clever solution was found! Our code went from:

target.server = function() {
  echo('### Serving butter');

  cd( CORNFIELD_DIR );
  exec('node app.js', { async: true });
};

To….

target.server = function() {
  echo('### Serving butter');

  cd( CORNFIELD_DIR );

  // Use child_process.spawn here for a long-running server process
  // (replaces `exec('node app.js', { async: true });`).
  var server = spawn( 'node', [ 'app.js' ] );

  // Mostly stolen from http://nodejs.org/docs/v0.3.5/api/child_processes.html#child_process.spawn
  server.stdout.on( 'data', function( data ) {
    process.stdout.write( data );
  });

  server.stderr.on( 'data', function( data ) {
    process.stderr.write( "" + data );
  });

  server.on( 'exit', function( code ) {
    console.log( 'server process exited with code ' + code );
  });
};

This allowed us to properly have the server be started asynchronously and no longer have any issues with the tests running in Firefox!

Still need that continuous integration stuff though so we can have our tests always running upon checkin, allowing us to catch any problems earlier.