The first view into Literature

By david.humphrey | Published: December 30, 2012

“Yet if the only form of tradition, of handing down, consisted in following the ways of the immediate generation before us in a blind or timid adherence to its successes, “tradition” should positively be discouraged. We have seen many such simple currents soon lost in the sand; and novelty is better than repetition. Tradition is a matter of much wider significance. It cannot be inherited, and if you want it you must obtain it by great labour. It involves, in the first place, the historical sense, which we may call nearly indispensable to anyone who would continue to be a poet beyond his twenty-fifth year; and the historical sense involves a perception, not only of the pastness of the past, but of its presence; the historical sense compels a man to write not merely with his own generation in his bones, but with a feeling that the whole of the literature of Europe from Homer and within it the whole of the literature of his own country has a simultaneous existence and composes a simultaneous order. This historical sense, which is a sense of the timeless as well as of the temporal and of the timeless and of the temporal together, is what makes a writer traditional. And it is at the same time what makes a writer most acutely conscious of his place in time, of his contemporaneity.” –T.S. Eliot, from “Tradition and the Individual Talent”

From the time they were babies I have been buying our daughters books: books for when they were older; books of literature; books that have stood, patiently, for a decade of waiting for the moment when it would make sense for young hands to reach out for them.

My 18th century poetry professor built his course around a unifying idea: all poems respond to, or remember other poems.  To read is to remember.  What makes reading enjoyable, and also difficult, is that reading requires reading.  Reading demands that we have read what is here being re-read in this text: the name of a character; the choice of a phrase; the subtle allusion to a scene from another book.  Reading expects us to bring as much as the text itself provides, perhaps more.  The memory is not the thing it remembers.  It is not here.  It is not available.  Reading is the magic trick of conjuring the past.

Our sister-in-law was over at our house the other day.  She and my wife were looking through a design book, our youngest daughter reading on the couch.  My wife commented on her love of white and red.  “Where did it come from, this life-long love of red?” my wife asked.  “I don’t know,” our sister-in-law replied. “I think it was a passage from a Cherry Ames book I read when I was little, where she described a beautiful red chair in her room.  It’s always stuck with me, and come to represent what is beautiful.”

When she left our daughter came to my wife.  “I know what she was talking about,” she said quietly.  “I know who that is, it mentioned her name in my book.  One of the earlier chapters talked about that character.”  Her face showed that she’d understood a secret, that she herself had done the trick of reading, remembering, recognizing.  It was her first view into literature, a view only she could see from her particular vantage, hidden to me, yet something I can, and do, understand and treasure.

Posted in Reading, family | Comments closed

Code for Christmas

By david.humphrey | Published: December 29, 2012

Today our family gathered to celebrate Christmas on my wife’s side.  After the usual amazing food and gifts, we spent time making room for dessert, with some going for a walk on the newly snow-covered trails of the woods, and others sledding.  My eldest nephew and I stayed back so we could listen for my youngest nephew, who was napping.  Our conversation, as it often does, went to computers.

“I’ve been reading about HTML.”

“What did you discover?”

“Well, I was looking at this site.  It got me thinking.  How do you do what you do with computers?”

The easiest way is to answer this is to do something.

“Which websites do you use?”

“Google and Facebook, mostly.”

“Great, let’s start there.  Open Google.  Now let’s look at the source.”

It’s been a while since I looked at the source for google.com.  Today, it’s first necessary to beautify it in order to even read it.  Having taught him how to cope with minified source, we start scanning through.

“How many people did it take to write this?  Hey, what’s this bit about iPad and iPhone?”

var l = "undefined" != typeof navigator &&
        /Macintosh/.test(navigator.userAgent);
var q = "undefined" != typeof navigator &&
        /iPhone|iPad|iPod/.test(navigator.userAgent),

“Excellent. Let’s use this code and do something.”

Laying in front of us is a MacBook Pro, an iPad, an iPod, and an iPhone–toys of the various family members out on walks, laying there needing to be put to use.

“OK, how do I start?”

A minute later we have a fiddle going, and he’s got the hang of the game.  I’m left to affirm his inclinations as he works out the logic on his own.

“What if we make a page that shows you a picture of the device you’re using as soon as it loads?”

“I like that.”

Before the other nephew’s nap is done we have a piece of code that works, and works perfectly on every device we try.

The level of satisfaction he’s left with, showing his parents on their return, is a gift I’m still cherishing.

Posted in Digital Swag, family | Comments closed

Of dogfood and web making

By david.humphrey | Published: December 5, 2012

One of the things I’m currently doing is helping the Mozilla Foundation figure out how to evolve and grow the Webmaker project.  Mark has been writing about the plan for 2013.  I’m mainly thinking about ideas for tools, products, and how to do work like this at the scale of Mozilla, especially when it comes to large scale community involvement.

One of the ideas I’ve been presenting to the team is that in order for our tools to get better, and in order for a lot of people to not only want to use them, but love using them, we have to use them ourselves–we have to dogfood them.  To that end, I’ve been working on using some of our tools these past two weeks.

Today I decided to try and build something that Mark’s been discussing a lot: Popcorn-powered slideshows that tell a story in time using images.  Popcorn Maker is capable of doing something like that, but capable isn’t the same as appropriate.  Yesterday I noticed a post on reddit about the images sent with the Voyager spacecraft into deep space.

Here was a perfect opportunity to test Mark’s theory.  What if, instead of a page of static images you scroll through, I made a visual slide-show using audio and video?  I’ll skip to the end and share the final product with you, before discussing what the dogfood tasted like.

Overall, I’m pleased with how it turned out.  I think it does something more than a web album can–I get teary watching it, to be honest.  I also think it was harder than it needed to be.

In our planning meetings, I’ve said many times that our tools need to level-up.  When I say this, it seems to get some people’s backs up.  On one level I understand that–doesn’t it mean you’re attacking me if you say what I made isn’t good enough?  On the other hand, I’m so used to this way of working from my time developing in the Mozilla and Firefox communities, where we all know that our code has bugs, lacks features, needs to get better, that I’ve stopped being offended when someone offers a critique like this: “File a bug.”  It shouldn’t be personal.

So to prove that I mean no disrespect, and that I can dish it and take it, allow me to tell you how much work there is to do on Popcorn Maker, which I just spent a good part of a year building:

  • There’s no way to specify that I want to cover the entire video area with an image or colour.  For my purposes, I wanted to black out the video at a certain point, and was forced to put a Text plugin, with black text, black background, and have it fill the entire video area.  Hacky.
  • There’s no way to say, “Use this list of images” and have Popcorn Maker uniformly spread them over a time period.  I had to manually calculate how long to show each image in order for all 116 to fit in the time I had.  It’s finicky to do with the mouse, laborious when entering time codes manually.  I had to do both.
  • When you’ve arranged a whole bunch of equal-spaced images, there’s no easy way to go back and say “Let’s show all these for 1s instead of 1.6s each.”  We sort of support multi-select, but doing it on 116 images over 4 minutes is impossible.  I’d like some way to operate on that group.  Maybe the super scrollbar can give me some better elastic-band style highlighting?
  • I really wanted a way to be able to drag a plugin to a new start time, then enter a duration vs. an end-time, that is, be able to say “+1.6″ and have it figure out what that end time is.
  • I wished I could have lengthened the duration of the fade in/out, as I needed a slower pace for the affect I was trying to get.
  • Having to set the exact same settings each time I drop a new plugin on the timeline is annoying.  Why not use the same font, colour, sizing, placement, etc. as I did a second ago on the last one?
  • When I tried to remix what I’d made, and swap in a new video, all my quotes and double-quotes had been turned into HTML escape sequences.  Annoying.

I could go on.  These are all bugs or feature requests, and I simply need to file them.  However, they are bugs and feature-gaps I’m now aware we have in our tool.  That’s a really humbling, and important realization for a developer.

“How do we know if something’s better?” is another question I’m hearing a lot.  Well, in my case, one real data-point that we could measure here is how long it takes to make something like this.  I think it took me about 3-4 hours to make this with Popcorn Maker.  That’s not terrible, and it’s not ideal.  “Can we make it easier, faster to build a web-based slide show?” is a question I’m asking right now.  I think ‘yes’.  For one thing, we should look into automatically connecting a bunch of images to a timeline, perhaps without having to actually position each one.  What if you specified that the slide show was going to occupy a certain time, and let the tool figure out which image gets shown when, and for how long?  I would have loved that here!

Dogfood doesn’t taste great.  In fact it’s easy to let that foul taste keep you from doing it at all.  Nor does it feel good when someone else tries to use your thing and finds it lacking in a whole bunch of ways.  However, if you want to get to the point where your software is fun to use, you have to admit that it has issues, make plans for improving things, and then execute on that plan.

I’m really pleased that I was able to use nothing but the web to build this.  I think there’s still a bunch of things to do to make it better, but it’s nice to not be starting at zero.  I’m looking forward to improving all our tools, and bringing more web makers into Webmaker.

Posted in CDOT, MoFoDev, Mozilla, Mozilla Education, Seneca | Comments closed

WEBVTT Update, Google Test, debugging unit tests

By david.humphrey | Published: November 23, 2012

With the majority of the webvtt parser now written (untested, unrevewied, but written), we’ve turned our attention back to testing.  Previously the class wrote 300+ validation tests.  These were simple VTT files that allowed us to check that a parser (or validator) correctly passed or failed a particlar VTT file, each one designed to exercise a different aspect of the spec.

What I wanted to do next was convert all these files into unit tests.  We decided to try and use node-ffi so we could write the tests in JS instead of C.  This turned out to be a better idea than reality, and left us with innumerable issues wrapping our code (especially the parse callback), build issues on Windows, etc.  Undaunted, I suggested we try Python’s ctypes, hoping it would be more mature.  This was better, and we were able to make progress; but it added a level of complexity that I don’t think was helping the majority of students.  If you’re struggling with C code, and your professor hands you a half-finished Python wrapper and says “write tests for the C code,” it’s a conceptual leap that’s hard to make.  So I abandoned that, too.

I tell my students to try things and not panic when it fails, so I have to do the same.  At this stage I was looking for a solid solution vs. something hacky that might fail a third time.  In the end I followed Ted’s suggestion of using Google Test (gtest), which he’s often praised from his work on Breakpad.  The students are (mostly) familiar with JUnit from other courses, so the xUnit style of Google Test is perfect.  Furthermore, the docs are awesome, it works cross-platform (and on TravisCI), there’s plenty of examples, and lots of other projects using it, which the students can read.  Win!

I added gtest to our autotools build (this template on github is helpful, if you ever have to do the same), and now TravisCI runs all our unit tests and reports back to github for any pull requests people make.  In order to test our C code with gtest, Caitlin wrote a C++ wrapper, and Rick wrote a test fixture class, allowing our tests to become very simple.  Here’s an example:

/**
* Verifies that the parser correctly parses a "vertical" key, followed by U+003A ':',
* followed by 'rl' (indicating that the text be positioned vertically, and grows towards the left)
*
* This cue should have a Vertical orientation with direction RightToLeft
*
* From http://dev.w3.org/html5/webvtt/#webvtt-vertical-text-cue-setting (09/28/2012):
* 1. The string "vertical".
* 2. A U+003A COLON character (:).
* 3. One of the following strings: "rl", "lr".
*/
TEST_F(CueSettingVertical,RL)
{
  loadVtt( "cue-settings/vertical/rl.vtt", 1 );
  ASSERT_TRUE( getCue( 0 ).isVerticalRightToLeft() );
}

This loads uses the cue-settings/vertical/rl.vtt file, parses it, and makes sure there is 1 cue returned.  It then makes sure that the vertial-right-to-left attribute is true.  Here’s what the file looks like:

WEBVTT

00:00.000 --> 00:10.000 vertical:rl
Payload

Great, right? Even better, our first dozen tests have already found a bunch of bugs in the implementation code. It’s nice to be able to instantly show the students the benefits of writing lots of little tests. They also had to quickly learn how to manage an automated build and testing system with the desire to write and land a lot of tests. What do you do with tests that are known to case things to fail or crash?

Google Test provides a way to disable a test without removing, or commenting it out–you simply use the DISABLED_ prefix in the test’s name.  When you run your tests you get a report that there are disabled tests:

[==========] Running 2 tests from 1 test case.
[----------] Global test environment set-up.
[----------] 2 tests from CueSettingVertical
[ RUN      ] CueSettingVertical.RL
[       OK ] CueSettingVertical.RL (11 ms)
[ RUN      ] CueSettingVertical.LR
[       OK ] CueSettingVertical.LR (0 ms)
[----------] 2 tests from CueSettingVertical (11 ms total)

[----------] Global test environment tear-down
[==========] 2 tests from 1 test case ran. (11 ms total)
[  PASSED  ] 2 tests.

  YOU HAVE 5 DISABLED TESTS

Running these disabled tests is possible with a command-line flag: --gtest_also_run_disabled_tests. Debugging a failing disabled tests requires some more work. Google Test is pretty good at not blowing-up when a test throws or segfaults. To catch such errors in the debugger, you also need to pass the --gtest_break_on_failure flag to your unit test executable. This let’s gdb deal with the crash. For example:

$ cd webvtt
$ ./configure --enable-debug
$ make && make check
$ cd test/unit
$ gdb payloadnode_unittest
GNU gdb 6.3.50-20050815 (Apple version gdb-1515) (Sat Jan 15 08:33:48 UTC 2011)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "x86_64-apple-darwin".
(gdb) run --gtest_also_run_disabled_tests --gtest_break_on_failure
Starting program: /Users/dave/Sites/repos/webvtt/test/unit/payloadnode_unittest --gtest_also_run_disabled_tests --gtest_break_on_failure
Reading symbols for shared libraries ++. done
Running main() from gtest_main.cc
[==========] Running 2 tests from 1 test case.
[----------] Global test environment set-up.
[----------] 2 tests from PayloadNodeTest
[ RUN      ] PayloadNodeTest.DISABLED_NodeCount

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000008
0x000000010001247d in WebVTT::NodeFactory::createNode (otherNode=0x0) at nodefactory.cpp:8
8		if ( WEBVTT_IS_VALID_INTERNAL_NODE( otherNode->kind ) )
(gdb) bt
#0  0x000000010001247d in WebVTT::NodeFactory::createNode (otherNode=0x0) at nodefactory.cpp:8
#1  0x000000010000b2d6 in WebVTT::Cue::nodeHead (this=0x100200ac0) at cue:99
#2  0x000000010000b2fa in PayloadNodeTest::getHead (this=0x100200ba0) at payloadnode_testfixture:11
#3  0x00000001000088d5 in PayloadNodeTest_DISABLED_NodeCount_Test::TestBody (this=0x100200ba0) at payloadnode_unittest.cpp:13
#4  0x0000000100026433 in testing::internal::HandleSehExceptionsInMethodIfSupported (object=0x100200ba0, method={__pfn = 0x21, __delta = 0}, location=0x100035fe3 "the test body") at gtest-all.cc:3413
#5  0x000000010003155f in testing::internal::HandleExceptionsInMethodIfSupported (object=0x100200ba0, method={__pfn = 0x21, __delta = 0}, location=0x100035fe3 "the test body") at gtest-all.cc:3449
#6  0x000000010001d9b1 in testing::Test::Run (this=0x100200ba0) at gtest-all.cc:3485
#7  0x0000000100024748 in testing::TestInfo::Run (this=0x100200090) at gtest-all.cc:3661
#8  0x000000010002489b in testing::TestCase::Run (this=0x1002004f0) at gtest-all.cc:3768
#9  0x0000000100024b9d in testing::internal::UnitTestImpl::RunAllTests (this=0x1002001c0) at gtest-all.cc:5591
#10 0x00000001000268e5 in testing::internal::HandleSehExceptionsInMethodIfSupported (object=0x1002001c0, method={__pfn = 0x100024930 , __delta = 0}, location=0x100035cc8 "auxiliary test code (environments or event listeners)") at gtest-all.cc:3413
#11 0x0000000100030fe8 in testing::internal::HandleExceptionsInMethodIfSupported (object=0x1002001c0, method={__pfn = 0x100024930 , __delta = 0}, location=0x100035cc8 "auxiliary test code (environments or event listeners)") at gtest-all.cc:3449
#12 0x000000010001d161 in testing::UnitTest::Run (this=0x10005d280) at gtest-all.cc:5226
#13 0x00000001000128f6 in main (argc=1, argv=0x7fff5fbff790) at gtest_main.cc:37
(gdb)

Here I’ve compiled the code and tests in debug mode, which will produce an executable gtest program I can run for my unittest named payloadnode_unittest. From within the test/unit directory, I run the program under gdb. I tell gdb to run the program with the appropriate flags for testing. It happily runs the tests, including my DISABLED_ tests, and promptly crashes, dropping me back into the gdb prompt. Here I can ask for a backtrace using the bt command, and a quick look at the stack shows me that we’re calling WebVTT::NodeFactory::createNode with a null node from WebVTT::Cue::nodeHead. Now I know where to start digging in order to fix this.

As we wind down the semester, we’ll churn through all these tests and fix the bugs they find. I’m glad to finally have a working testing infrastructure we can all rely on.  Once we have the tests in shape, and bugs shaken out, we can move onto integration in Firefox and the track element.

Posted in CDOT, Implementing WebVTT, MoFoDev, Mozilla, Mozilla Education, Seneca, Teaching Open Source | Comments closed

TravisCI builds for the webvtt parser

By david.humphrey | Published: November 17, 2012

Last night as a few of us were working on the webvtt code, Dale popped into channel to ask if others were having trouble building.  After a few minutes we concluded that the tree was indeed broken, and that the last commit had failed to add some header files, update Makefile.am, etc.  This kind of thing happens all the time, and it’s the reason that smart developers have learned to never trust themselves, and instead rely on continuous integration.

Some months back I tasked Michael with getting our project building in TravisCI.  If you’ve never used it before, TravisCI is not unlike Mozilla’s Try-Server.  By adding a git hook to your project, a config file to the root of your source tree, and wiring Travis and Github together, you get per-commit, clean-room builds of your code.  Better still, you get this integrated into pull requests, such that anyone wanting to merge is going to see (and show others) that the build is working or failing.

I spent a few minutes integrating what Michael had done into my repo last night so we wouldn’t burn the tree down again.  I’ve added a build status icon to our README.md, which points at our Travis build page.  Anyone doing pull requests from now on will get live feedback from Travis/Github about the state of the build in gcc and clang on Linux.  Once we get the test harness integrated we’ll add tests to this too.

I’ve set it up to notify us on IRC, but there is a bug in Travis which seems to affect irc.mozilla.org.  Hopefully that will get fixed soon so we can see build status there.

I continue to be impressed with TravisCI, and would highly recommend it for your project.

Posted in CDOT, Implementing WebVTT, Mozilla, Seneca | Comments closed

Web App JavaScript Crash Reporting

By david.humphrey | Published: November 13, 2012

We just launched Popcorn Maker 1.0 this weekend at Mozilla Festival 2012, and while the focus of the app is obviously web video remixing, one of our favourite features as a dev team was the JavaScript Crash Reporter.  Bobby and I wrote a little bit about it in our Mozilla Hacks post, but I wanted to say some more about the potential for this technique.

Working on Firefox code, I’ve long been a fan of the Mozilla Crash Reporter, which uses Google’s crash reporting system, Breakpad, and the Soccoro server.  Typing about:crashes in Firefox’s address bar will show you any crashes you’ve logged, which are links to crash-stats.mozilla.com.  Here’s an example.  When you’re lucky you get a stack showing where things went wrong, info about bugs related to this crash, aggregated data for other users’ crashes in the same spot, etc.

For developers it’s an incredible source of information, since often these crashes occur out in the wild, and under circumstances the developers can’t reproduce.  Crash reporting in native apps isn’t new, of course.  OS and application vendors routinely use this data-driven debugging method to gather useful data about edge cases in their code, and to make corrections.

The technique isn’t used as often in JavaScript applications, though.  More often than not, a user’s contribution to the data of a web app is about marketing or tracking vs. improving development and stability.  Another reason is that many pieces of JavaScript are libraries vs. apps, and get used on more than one installation, making it undesirable that code phone-home to report an issue.

With Popcorn Maker we wanted to make it easy for our users to give feedback and report issues.  Because the project isn’t for developers, asking that they find and file bugs in our issue tracker wasn’t realistic.  So we made a Feedback button and form, and also an automated Crash Reporter to deal with top-level exceptions (i.e., those that can be caught using window.onerror).

We’ve been using these techniques now for about about a month, since the beta launch for Ryan’s TED talk on Popcorn, and through the 1.0 launch, and I can now talk about what it’s like using them.  First, and perhaps not surprisingly, people don’t tend to leave much feedback.  It takes time to write free-form comments in a form, and most people don’t want to bother.  So far we’ve gotten between 3 and 6 a day.  The quality of what people say is usually quite high, though.  When they have bothered to do the work of filling out the form, they’ve taken care to do it well, and usually give us ideas for new features.

The crash reports are another story.  This morning when I sat down to check my email, I had over 50 waiting for me.  I was able to file 8 new bugs (many of them were the same issue hit by different people).  I was also able to see that we’ve regressed one bug we thought we’d killed completely, that we’re having issues in the Sogou and Zune/Media Centre browsers, that we have a timezone related bug in some of our date parsing, and that I finally have better data about a crash we first saw last week (i.e., different browsers report the error differently, giving us a more complete picture of what is actually failing). That’s data from just a single day!

I can’t emphasize how drastically this technique has changed our development practices.  In the period between 0.9 and 1.0 we found and fixed 12 bugs that our team couldn’t reproduce (there are another 12 on file that we’re still trying to fix).  We put a lot of effort into automated and manual testing, and work hard on cross-browser testing, but there is no way for us to hit all these issues.  Furthermore, there’s no way people would file all these issues.  What would they say?  “It didn’t work” isn’t helpful for them or us.  We need to know what failed so it doesn’t happen again.  Rather than having a web app that just silently fails, we give our users the chance to become part of the development process by submitting the crash data, and a lot of them do:

You can try simulating a crash by going to http://popcorn-dev.rekambew.org/templates/basic/ and doing `Butter.app.simulateError()` in your console.  If the user wants to add extra info, they can (most don’t), and then if they click ‘Yes’ we send anonymous data about the error.  For example:

  • Which version of our code they were using
  • Which media URL(s) they tried
  • Data from the onerror handler–message, filename, line number
  • States the app had hit before the crash (i.e., which events we’d processed internally, like mediaready)
  • Any DOM nodes that we tried to get and were null

We take that data and store a JSON report on Amazon S3.  Here is an example:

{
    "date": "Tue Nov 13 2012",
    "message": "TypeError: 'undefined' is not a function (evaluating 'tracksContainer.container.getBoundingClientRect()')",
    "appUrl": "https://popcorn.webmaker.org/templates/basic/?savedDataUrl=ted.json",
    "scriptUrl": "https://popcorn.webmaker.org/src/butter.js",
    "lineno": 9805,
    "mediaUrl": [
        "https://www.youtube.com/watch?v=0g2WE1qXiKM&butteruid=1352812826605"
    ],
    "stateList": [
        "trackeventadded",
        "trackeventadded",
        "trackeventadded",
        "trackadded",
        "trackeventadded",
        "trackadded",
        "trackeventadded",
        "trackeventadded",
        "ready",
        "mediaready"
    ],
    "userAgent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_2) AppleWebKit/536.26.17 (KHTML, like Gecko) Version/6.0.2 Safari/536.26.17",
    "popcornVersion": "v1.3-44-g05ac7ef",
    "butterVersion": "v1.0.4",
    "nullDomNodes": ".media-status-container, .youtube-subscribe-embed, [data-tooltip]",
    "comments": ""
}

There are a few gotchas to be aware of:

  • You need to filter your errors by filename so you don’t crash when trivial things happen in scripts you include.  In our case, we use a lot of third-party APIs which can spam the console with errors that aren’t actually a problem–the YouTube iframe tries to read values in the parent document and fails with cross-origin errors.
  • Firefox has an annoying bug where errors in simulated events get eaten, and don’t make it up to the top-level, see https://bugzilla.mozilla.org/show_bug.cgi?id=503244

There are also other things I’d love to figure out how to do better:

  • How should we deal with minified code?  For now we’ve left our code unminified in order to get better data about what the failure was (e..g, function/var names vs munged names), and real line numbers.  It would be great to do something with source maps or the like
  • How to get a stack?  By the time onerror happens, the stack is unwound, and we don’t have good data about the full issue.  Sometimes the top-level error message is useful, sometimes it isn’t.  Knowing what happened before that would be great.  I’ve thought about writing wrappers around our major module blocks to catch exceptions, cache the error (and stack if there), then rethrow.  The crash reporter could look up the last error(s) in the cache and add that data.
  • It would be great to add some kind of assert API to the reporter.  Imagine if you could assert not to the console, but to the reporter, and if there’s a crash, send along failed assertion data.

I’d also love to not have to build a full UI for working with the reports :)   I think it would be great if web app developers could use Mozilla’s Socorro infrastructure to gather and analyze crashes.  Imagine if part of doing a Mozilla Market Place app was getting access to that infrastructure?  Chris Lonnen and I discussed this idea at the Festival.

At some point I’d like to rip the crash reporter out of Popcorn Maker and turn it into a stand-alone repo others can use.  The code is here, if you’re interested in seeing how we do it.  I’d highly encourage other web app developers to go this route.  It’s been a game changer for our team and app.

Posted in CDOT, MoFoDev, Mozilla, Mozilla Education, Seneca, Teaching Open Source, Web Made Movies | Comments closed

Popcorn Maker 1.0 Beta – TED Launch

By david.humphrey | Published: October 19, 2012

We’re about 3 weeks away from the Popcorn Maker 1.0 launch at this year’s Mozilla Festival in London.  Just to raise my blood pressure a bit, we’ve shipped a beta today.  It coincides with the release of an amazing TED talk by Mozilla’s Ryan Merkley about Popcorn.js and Popcorn Maker.  “It would be cool if we could work with this video using the tool he’s discussing, is that possible?”  It is :)

I’m really proud of the work we’ve done here, not least because so many of my former and current Seneca students have worked on it as part of class projects and NSERC funded research at Seneca’s Centre for Development of Open Technology.

A huge thanks and congratulations to:

  • David Seifried
  • Chris De Cairos
  • Matthew Schranz
  • Jon Buckley
  • Scott Downe
  • Robert Stanica
  • Mohammed Buttu
  • Daniel Hodgin

I’ll blog with more info about Popcorn Maker when we ship 1.0.

Well done team, well done.

Posted in CDOT, Mozilla, Mozilla Education, Seneca, Teaching Open Source, Web Made Movies | Comments closed

Implementing WebVTT in Firefox at Seneca

By david.humphrey | Published: September 18, 2012

Fall Teaching

It’s the start of a new semester, and once again I’m teaching the Open Source and Mozilla Development course at Seneca’s Centre for Development of Open Technology.  I love teaching this course for many reasons: it’s different every time I do it and never boring; the students and I get to work on real code together; a bunch of students get to have their first experience of what it’s like to help push the web forward (hint: it’s awesome); we get to work with some amazing people in the Mozilla community.

Evolving Thinking About Student Projects

The way I run the course has evolved over the years, and this year I’m going to try something new and a bit risky.  When I taught it for the first time, I can remember sitting in a room with Shaver at Seneca and coming up with about 15 or 20 projects for things Mozilla needed.  It was literally back-of-the-napkin planning, and it was equal parts amazing/useful projects and probably-not-worth-doing.  Mike and I had no idea what students were capable of, how big to make the projects, how much complexity, what background knowledge they could acquire in time.  As a result, we got some of it right and some wrong.  And we learned for next time.

Since then I’ve tried different approaches to the course project.  Sometimes we’ve sought out “wouldn’t it be nice if we had…” type work, other times we’ve chosen to use existing bugs; sometimes we’ve done individual projects, other times had groups of 2 or 3.  There’s no one right way to do it.

The Pointer Lock Experience

Last fall I assigned students individual bugs, and then spent the second half of the course implementing the Pointer Lock API instead of doing formal lectures.  Each class we’d go a bit further and discuss how things worked, what to try next, comb through the spec, etc.  It was a lot of fun, and a nice byproduct of the effort was that Firefox shipped Pointer Lock.

One thing I didn’t like is that not all of the students got engaged with the code as much as they could have.  About half were eager to do it, and couldn’t be stopped.  The rest saw a bunch of people already working, and decided to sit on the side lines.  I don’t blame them: the code was complicated and we went fast in order to get it done.  Also, the tasks weren’t highly parallelizable, since the spec was fairly constrained and the API small.  Another problem was that I still had each student working on other individual bugs, which meant they had to make a choice between getting their graded work done and getting involved in the class project.

This time I’ve decided to go all in on the larger class project approach.  What I liked about Pointer Lock was that it was real, mattered to the web and Mozilla, and was a strange mix of cutting-edge and non-critical tech at the same time.  I also liked that it allowed the students to form a community of knowledge together around a single spec, API, etc–when students can help one another, my experience is that they do.

When I first agreed to fix the Pointer Lock bug with my class, it wasn’t really on that many peoples’ radar.  By the end of the term I was getting regular emails from people wanting to know when it would land, and reading media reports about how Firefox was shipping it.  There’s a sweet spot in there where students feel safe to learn as they go without too many critical eyes on them, but then also have enough eyes to help them find issues and solutions.  Getting the balance right is hard, in my experience.

Toward WebVTT

Earlier this summer I went searching for another “Pointer Lock”–I wanted a new spec I could implement with my class, one which mattered, but not so much we’d be blocking releases if we took a meandering path in order to get it done.  I emailed a bunch of Mozilla folks looking for ideas, and got some great suggestions.  A few of them were too complicated, too “you’d have to be deep in Mozilla lore to even understand why this matters”, too big for the time we had, or too critical for upcoming releases.  But there was one that sounded possible, “We need someone to implement WebVTT” suggested Chris Pearce.

I’ve spent the past three years working on various projects connected to HTML5 audio and video, and I love the idea of staying in that domain for yet another project.  HTML5 audio and video continue to get more and more exciting, and I’m happy to do more to help it evolve.  Funnily enough I had another student write WebVTT support into Popcorn.js a few terms ago, so it’s nice to circle back and do the native implementation now.  Also, as a member institution of the Inclusive Design Institute, I’m attracted to WebVTT’s potential for improving accessibility for web media.

Working on WebVTT in a Mozilla Context

WebVTT (Web Video Text Track) is a file format that, when paired with the HTML5 track element, allows one to pair subtitle, caption, or other metadata about a media resource with an audio or video element.  Silvia Pfeiffer gave an excellent talk about it at Google in 2011.  Our plan is to start by writing a stand-alone implementation of the WebVTT parser and then to hook that into the track element in Firefox.  Mozilla media hacker Ralph Giles has already started work on both (parser is here, track element work is here).  There’s a long road to finishing WebVTT and track in Firefox, and it’s unclear to any of us how far we’ll get.  Part of taking on a project like this is not allowing yourself to get overwhelmed by the end goal, and instead making small steps that add up over time.

My plan is to work with the students to plan and execute this project.  Our first deliverable, due next week (get busy guys!), is a set of conformance tests for the WebVTT file syntax and parser.  Once that’s done I’ll have people split out on different paths, some people figuring out UTF-8, getting the parser passing all the tests, dealing with edge cases, etc, and others working on DOM bits in Firefox, hooking the parser into the media code, etc.

Because this is real, and because this is open source, you’re welcome to join us.  People often tell me they’d like to come and learn Mozilla at Seneca; well, you don’t have to be physically present to do it.  We’ll be working on the parser in github using Ralph’s repo, and Bugzilla for the DOM/media work (I’ll post bugs as they get filed).  The students will be in #seneca, #introduction, and #media mostly, so if you want to talk to them on irc, those are the places to do it.  Feel free to help us write code, test things, give advice, encouragement, or just say hello.  Working on something this complicated is daunting for a student, and part of the reason I know it will work is because of our community and the support available to them.

As usual, I’m somewhat terrified of the project, unsure if it’s going to work, trying to figure out how to teach all the things the students need to know in order succeed.  At the same time, after living through it in a bunch of other projects with students, I’ve come to recognize that this terror is not really a bad thing: it motivates; it excites;  it humbles.  I want to give the students a realistic experience of being out in the wild, and I can’t do that by playing it safe myself.  So here goes nothing…here comes WebVTT, implemented by a bunch of college students!

Posted in CDOT, Implementing WebVTT, MoFoDev, Mozilla, Mozilla Education, Seneca, Teaching Open Source | Comments closed

On bunkum: a word with Le Carré

By david.humphrey | Published: September 4, 2012

Last week I allowed myself the guilty pleasure of reading nothing but spy novels while at the cottage.  I had wanted to read a number of John le Carré’s books, and loaded my Kindle for the trip.

First, a word on Le Carré.  I really love his writing.  Here are one-hundred pound plots dolled out a teaspoon at a time, and as smooth as honey.  His diction, characterization, and the flow of his words is so enjoyable.  I was so enthralled I even read books of his for which I’ve seen the movie–Tinker, Tailer, Soldier, Spy is a great film, and an even better book.  I’m still burning through the Karla trilogy, and would highly, highly recommend you pick up a Le Carré or 4.  Start with The Spy Who Came in From the Cold.

Now, a word from Le Carré.  The other night I was reading and had to pause at a critical point in the narrative in order to do some etymology.  Here’s the sentence:

I said it sounded bunkum, and rang off…

It sounded bunkum.  I had to consult the OED.  Surely he meant what I would more likely expect to read “bunk,” but that he didn’t, I had to know more.  It turns out that bunkum comes from Buncombe, the name of a county in North Carolina.  It was used in a passionate speech by a member of the US House of Representatives in 1820, and was done in order to curry favour with its voters.  As a result of the grandstanding it came to represent empty political talk, and later, for any and all empty talk, more commonly, bunk.

Today bunk is used more often than bunkum, which is probably why I’ve never encountered it until now.  You can see its historic rise and fall in this Google NGram analysis:

Posted in Reading | Comments closed

Processing.js 1.4.0

By david.humphrey | Published: July 31, 2012

Today we’re releasing Processing.js 1.4.0.  It’s a good solid release, which Jon jokes we’ve been aging for 9 months in order to develop its full flavour.

As we write in the that post, we’re going to change our development process.  In the past we’ve been tracking work in Processing, and chasing performance, parser, and Java-parity bugs.  We don’t plan on doing any major releases for a while, and will instead do minor releases more often going forward.  We still have bugs, and there’s lots of things we could do, but the code has been stable, fast, can compatible for a long time.  And it keeps getting faster as browsers get faster.

The dev team has gotten smaller in the last year, as people have been absorbed into other projects, and as the code has required less attention.  At present it’s Mike Kamermans, Jon Buckley, Yury Delendik, and me, with Mike taking on the leadership role since 1.3.6.  Luckily, quite a few of our current/former devs have been absorbed into the Mozilla Corporation or Foundation as employees and aren’t too far away, including all the names mentioned above plus Scott Downe and Chris Lonnen.  Processing.js has been good for the web, and good for Mozilla, and both make me happy.

Happy sketching!

Posted in CDOT, MoFoDev, Mozilla, Processing.js, Seneca | Comments closed