Tag Archives: butterjs

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!

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.

Popcorn Maker 0.5.x Releases – Story Camp

370 Tickets

That’s how many tickets we have staged/resolved for our 0.5, 0.5.1 and 0.5.2 releases and all over the span of a little more than 6 weeks (June 19). That doesn’t even include the tickets we have landed specifically in our 0.6 branch or the tickets we have landed in Popcorn that were filed/solved for Popcorn Maker. We’ve been kicking ass and taking names, although mostly kicking ourselves in the ass.

Here is a summary of how a felt whenever someone discovered a new bug over the last 2 weeks.

It’s been incredibly tiring as all of worked many, many overtime hours. It was a crazy push over the last 2 weeks but due to everyones incredible work we managed to pull it off and honestly the code feels really robust at this point. Granted, that doesn’t mean there isn’t plenty of work to still be done but there aren’t really any big features left ( that is, until the UX redesign coming in 0.7 ). However that still doesn’t change the fact that we really need to get a good testing infrastructure in place so we occur these problems less. If we could get testswarm working ( our continuous integration system for Popcorn ) in combination with botio then we could easily have our tests run whenever someone ran a simple /botio check command in a pull request.

We specifically need good UI testing in place, however the road to there has proven to be very difficult. We have tried multiple libraries ( CasperJS + Phantom, Selenium ) and none seem to have worked as well as we have wanted. Not having this stuff in place could have easily solved a lot of the bugs/problems we have been experiencing.

Mozilla Story Camp

This has been the driving reason behind why we have been pushing this much over the last bit. It is an initiative of Mozilla to get people involved with creating content on the web using all the cools tools/libraries they have been building. All kinds of events have already gotten underway and it has been really amazing to see what people have come up with thusfar. Surprisingly I haven’t seen lighthouse spammed with bug reports! Although, maybe that’s because we haven’t made it quite as accessible as we may thought we have. None the less it’s going to be an exciting summer seeing what people can come up with and just play with it in ways maybe we didn’t think of.

If you ever get a chance, please check out Popcorn Maker here. The team would love to get any feedback you have about it. User experience, bugs or whatever else you can think of. Or just pop by #popcorn on irc.mozilla.org if you want to as well!

With Great Power…… Comes more tickets

And responsibility. I don’t quite recall where I was going with that line but, I was trying to play off the idea that I recently received admin access to Mozilla’s Butter/Popcorn repos. Now I can help stage tickets as well and we aren’t completely reliant on people like Jon, David, David or Scott to do it.

Anywho, the last week has been a very busy one in Popcornia. We finished a mini release, v0.5.1, which was intended to work over the kinks and other smalls bugs that would be associated with our introduction of the Django front end that will act as the template library and project management for users. Truth be told it felt more like an extended release because we wound up just throwing in as many bugs as we can into the release, especially ones deemed ground breaking for the upcoming Story Camp with Mozilla. The week started off at about 36 tickets and we wound up getting in about 60. Whatever we couldn’t get done, but was still deemed necessary for the Django front end and “beta” release of Popcorn Maker, was pushed to v0.5.2.

It is due to be finished June 15th and it’s ticket total is at 68 with 44 still to be resolved/staged.

I definitely think that isn’t too farfetched of a total, but I know we always managed to find a good 15 more bugs in the final 2 days of a release. Oh, and we have our 0.6 release due to be finished for July 1st which still has 162 tickets left.

Needless to say, the last few weeks have been interesting and so will the next few as well. It’s like we have the pedal down the entire time, with no time to really rest much. This is where we are going to have to cherish our weekends because otherwise we won’t have much time off at all!

Canada Day long weekend camping can’t come soon enough.

That said, it’s still fun and exciting. I’m able to learn more areas of the code and I find myself able to easily take on new tickets and feel confident enough that I can’t handle them. I’m still the king of absurdly long review periods for no good reason though. No one will ever be able to take that crown away from me.

Push it to the Limit – Completing the Code Freeze

This week we finished our code freeze for 0.5. Code freezes are important because a project always needs concrete and frequent updates because these help give it presence in the community. We brought up this very issue when discussing what the team was planning on doing with our upcoming 1.3 Popcorn.js release. It’s important for a project to maintain some sort of release schedule even if the fixes are minor because it helps it helps keep the project look like it’s active and not forgotten.

One of the big advances for this release has been better support for our flash players. Most of the features have all worked pretty well with HTML Video/Audio because Popcorn.js is designed to make use of the extensive library made available by Media Elements Draft, but our Youtube/Vimeo/Soundcloud players have always had issues. They prove to be difficult because they are either missing a lot of pieces of information available to us, meaning we are forced to hack in some sort of implementation or their API wasn’t ideally designed around the experience created by Popcorn.js. There have also been a lot of fixes in the background of the code ranging from simply refactoring for efficiency or better implementations of previous features such as our config files.

Monday and Tuesday this week were intense being the final two days before the code freeze (Tuesday). I spent time polishing up our manual tests, butters test harness, other quick fixes and review lots and lots of tickets. The two days we were like a well oiled machine, firing off fixes and reviews for tickets in quick order. In total we set 180 tickets to resolved/staged over the month of May with a lot of them being some feature rewrites to smaller bugs. Truthfully that number is misleading because a lot of our bugs were exposed by things with Popcorn.js itself, which caused us to file appropriate tickets there first, fix it and then finalize things over in Popcorn Maker land. Out of the 89 tickets that have landed for the 1.3 release of Popcorn, probably 60 of them were spawned in relation to Popcorn Maker. While this week was really intense, it also allowed me to gain basic grasps of more areas of the code. For example, I now have a pretty solid grasp on a lot of our server-side stuff with cornfield because of the rewrite of tests and time spent looking at that code.

That said, we still had to reduce things down. Tuesday morning we started off with something like 30 tickets left and by mid day it dwindled down to about 23. However the entire day we were fighting with our lack of solid testing in place because we would constantly find small bugs along the way and be forced to file them, fix them and then head back to some of the bigger ones we had already knew about. By 4pm we still had around 19 tickets left because of it, forcing us to quickly to do a mini triage and push some of these to our mini release of 0.5.1. That release is focused around integration of our current system with the Django front end that has been in development for some time and is due for June 15th.

One thing I really want to push and get in soon is some sort of back end for our manual tests. I spent some time today bringing together a basic implementation of it and thus far it is looking promising. One thing I definitely want to do is force the two requests I have added for cornfield to send information to a different server/database rather than using the on local to the machine it’s being hosted on. This way whether we are running our manual tests locally on our own machine or from a hosted version elsewhere everyone’s results are posted to the same places.

I’ve also put what I imagine are the final touches on our media spawner plugin. It’s funny because I originally started that way back in January to facilitate a feature being used in a project I was working on to have embedded content as events, which eventually scrapped the idea because they wanted to ensure people with lesser performing connections could view it all. That and tiny 5 to 10 second events didn’t really fit well with loading things like youtube or vimeo videos. Since then I have changed it numerous times because of various improvements to the Popcorn API (such as Popcorn.smart) to make it more efficient/robust. Eventually this plugin became pretty important to some of the templates Kate Hudson has been working on for various projects. Several months later and I think it’s finally ready to land 🙂

Been a crazy week, but there is still plenty more crazy to come. Till next time readers (A.K.A my Mom)!

Code Code Code …. Review Review Review

Code freeze for the 0.5 release of Popcorn Maker/Butter is coming up Tuesday and we have a lot to do before we close the code merging flood gates. In addition to this week being 1 day shorter for most of us because of Victoria day, we also had people venturing off to a conference downtown Thursday making things even tighter schedule wise. Needless to say we have needed to pick up the load to nth level to make up for all the lost man power (or maybe it’s finger power?)!

This week I finished off a few things. One was adding a test harness system for Butter. Now we can have one file that will run all of our QUnit based tests all at once, helping make testing much easier. It will land Monday since it’s now the weekend and whatnot.

I also finished updating the the cornfield tests. They now are use the proper updated methods and on top of that fixing them exposed a few problems with our validation for passed in data. On top of that they are just plain better than they were before. A lot of places in the tests previous used timeouts to call QUnit’s start() method to QUnit know it could run each assertion which could cause potential issues. They now follow a “cascading” style if you will that will have subsequent calls to browserid to happen withing the callback function of the previous call, allowing us to know that the previous work has finished preventing any asynchronous issues. For example:

asyncTest("Async API", 7, function() {
 var foundProject = false;

 butter.cornfield.list( function( res ){
 ok(res, "The project list response has data" );
  equal( res.error, "okay", "Project list status is \"okay\"" );
  ok( res.projects, "There is a list of projects" );

  for( i = 0, len = res.projects.length; i < len; i++ ){
   if( res.projects[ i ].name === filename ){
    foundProject = true;
    break;
   }
  }

  equal( false, foundProject, filename + " is not present in the projects list" );

  butter.cornfield.load( filename, function( res ){
   deepEqual( res, { error: "project not found" }, "The project load response is project not found" );

   butter.cornfield.save(filename, stringedData, function(res){
    equal( res.error, "okay", "The project save response is okay" );

    filename = res.project._id;

    butter.cornfield.load(filename, function(res){
     deepEqual( JSON.parse(res.project), data.data, "The project is the same" );

     start();
    });
   });
  });
 });
});

With this setup we know start won’t be called until our servers has completed our requests with browserid and our database holding project information.

On top of that I took over the manual tests that we are making. These tests contain a list of instructions for people to run and what they expected outcome should be if they follow those instructions. They can then report if the expected results were achieved or not. Eventually these will be linked for a database of some sort where we can monitor the results people will be reporting. Most of the real issues that we had were because the tests themselves were being loaded into an iframe. This caused issues with the sources provided for various plugins and other scripts because they were relative links in our config file. I also realized we were missing some vendor prefixed versions of linear-gradient on the index.html page, causing the links for the manual tests not to appear in browsers that weren’t FF, making it look like nothing loaded at all.

On top of all this there were many reviews. While reviews require that the person doing the reviews takes their time looking over it and is a very important task, it also means that someone has sort of gained enough experience in the project that they can be “trusted” so to speak which is a nice sign that I am progressing a lot within the Butter and Popcorn projects.

Other Cool Stuff
We also have basically a complete rewrite to our flash players in the works. David Humphrey started the work to basically mimic the HTMLMediaElement spec and early testing is showing it’s going to work quite awesome.

We also have the Django front end coming up for the 0.5 release, slated to be available on June 15th. This will create a new template management system and bring a lot of new cool stuff to the project.

0.5 is slated to be about 200 tickets! Yikes.

Can’t wait for the rest 🙂

OCE Discovery and more Popcorn popping

This week has been a shorter work week for me in the typical sense. I was asked to go help represent Seneca College down at OCE Discovery 12, a conference held by Ontario Centres of Excellence aimed at bringing together key players from industry, academia, government, the investment community as well as entrepreneurs and students to pursue collaboration opportunities.

This event was very interesting for me. It was a great opportunity to work on my presentation skills, although not in the typical sense. One thing that was said to us back at the beginning of the summer was that we need to be able to talk about what we are working on to anyone at anytime; Be able to describe our project on a high level so that anyone could understand it. I spoke to people of varying knowledge levels: from nothing all the way to other programmers from other schools, such as Niagara Research.

However, I feel that something like Popcorn is hard to show off at that kind of event. All we have are computer monitors showing videos on screen. In particular we were demoing our open source work done in conjunction with Native Earth and that particular demo is not particularly eye caching. It would have been better to show off some of more flashier demos that are out there on the net or maybe make one ourselves. What might have been even better would be to have multiple computers setup allowing people to play with Popcorn Maker. That is something more people can understand and the fact that they would be creating something themselves would make it a more lasting experience.

Still, there was a lot of cool things on display, including but not limited to: the U of T electric car that was used as part of a race across Australia and an app that was able to read your brains waves measuring focus levels that got you to controls the physics of a game. Going to this kind f event has definitely given me more thoughts about the kinds of things I want to do in the future. I never would have thought this 3 months ago but perhaps the career of a tech evangelist is in my future!

    Oh Yeah, I Did Some Coding Too

This week consisted of more fixes for butters unit testing and many code reviews. We also spent a lot of time discussing key aspects of the Django app that is going to make its way into Popcorn Maker soon along with new UI/UX stuff. While I am learning a lot more when it comes to JavaScript, I’m still very humble in my skills levels. Projects like these keep you humble because the code can be very hard to follow and learn. I’m sure if someone else was handling my tickets it would take them 1/4 of the time but that’s why we are all here; to learn.

I’m looking forward to finishing this stuff up so I can switch gears back to UI testing now that we have additional tools available, such as David Humphrey’s addition of Firefox’s “special powers” chrome access JavaScript. Going to be awesome!

Implementing Testing for Popcorn Maker

For the foreseeable future my main focus is going to be beefing up the testing system in place for Popcorn Maker. As it stands Popcorn Maker doesn’t have the same sort of testing environment and infrastructure that Popcorn.js has and this needs to be changed. Some basic QUnit based tests are present however they are never run and most are severely out dated, basing themselves off of an older version of the Butter SDK behind all of this. This is due to the culture the project currently has and my goal is to be apart of the change behind it.

All the Areas that Need Testing

  • Comm
  • Dialog
  • EventEditor
  • Cornfield
  • PluginManager
  • Timeline
  • TrackEditor
  • UI Testing
  • Test Harness so all the above testing can be run easily all at once

Needless to say, it’s a long list. A lot of it involves areas of the Butter SDK that I don’t know much about. On top of that there doesn’t seem to this one framework that can handle everything we want to do on the UI Testing side all nice and neatly like QUnit does for everything else. I have played around with Selenium a lot and that proved to be quite the nightmare. I’m still not 100% certain if it’s what we want to use because there are definitely elements to it that work and a lot that seemingly don’t. Right now I’m playing around with two frameworks, called PhantomJS and CasperJS, which CasperJS is built on top of PhantomJS to provide additional functionality.

As it stands, CasperJS doesn’t appear to allow me to send key events in any way to the page it interacts with. This is bad because it basically means I can’t run any of our tests that rely on some sort of key press from the user. On top of that there doesn’t appear to be anything available to test dragging and dropping of elements on a page. Once again, this is also a problem because we wouldn’t be able to test moving things like track events, track containers, track handles, events onto a track and anything else I haven’t included.

Thusfar I have only been able to have these run on the command line. I’m sure there is some sort of way that to integrate all of this together, so I went and asked their google group to see if someone more knowledgeable can assist me. In the mean time, here is some of what I have come up with thusfar:


casper.test.comment( "Testing iFrame Dialog Closing with Esc Key - Popcorn Maker" );

var p = require("webpage").create,
    t = Date.now();

casper.start( "http://localhost:8888/templates/test.html", function(){

  t = Date.now() - t;

  console.log( "Loading Time: " + t + "msec" );

  // Ensure template has loaded
  this.waitUntilVisible( "#butter-header-new", function(){

    // Confirm button exists
    this.test.assertExists( "#butter-header-new", "The button did load" );

    // Move mouse over button
    this.mouse.move( "#butter-header-new" );
    // Click zee button
    this.click( "#butter-header-new" );

  });

});

casper.then( function(){

  // Our iFrames don't have IDs, but all use the same class and this class is
  // only ever present in the DOM once
  this.test.assertExists( "iframe[class=' fade-in']", "The iFrame Loaded" );

});

// Run the whole test suite (all the above)
casper.run( function(){

  // Sends a test done message when all the of the above has finished running
  this.test.done();
  this.test.renderResults( true, 0, "iframe_esc_close.xml" );

});

This set of tests opens our testing template and then wait’s for our content to load. Once it has, it ensures an element with the id butter-header-new is present in the DOM. It then moves the mouse of that element, and clicks it. After the click has finished it will check if an iFrame with the class name fade-in is present. All of our iFrame dialogs use this class name and there will only ever be one iFrame dialog open at one time.

One of the interesting things that is run after all the tests are done is Casper.renderResults. What it does is send the results of our testing to the file I specified in an XUnit formatted XML file. From what I read we might be able to hook this into another continuous integration service such as Jenkins.

Here’s what running that code looks like:

What’s next?
Hopefully we can sort this out sooner rather than later. Once we can solve exactly what frameworks/technologies we will use to write out tests we can actually go about and well, write them! Hopefully my next post will include some of that 🙂

Until then!