Bread and Circuits | Philosophy for the programming set, served on home made bread

Learning to type

By david.humphrey | Published: January 22, 2012

Learning to type, when I learned to type, meant learning to become a typist. The premise on which typing was taught will, for some of you reading this, be foreign; there was a time when typing was a kind of suit that writers put on when it was time to go out into the world. One wrote in long hand and had work typed as a matter of course, and only at the end.

It’s important enough to repeat: there was once an end to writing, an outside to the writer’s inside, or at least we were taught there was. Typing was the end of writing. To type was to focus on something already written, to lock onto it with your eyes, letter by letter, to finger each letter at the keyboard, and to know, more through sound than sight (of course you didn’t look), that you’d faithfully reproduced it on paper. Typing required all your senses to be engaged together, and to share the work between them: your gaze focused on the scrawls of pen, your fingers feeling for the key offsets from ‘F’ and ‘J’, your ears detecting the telltale sign of multiple key strikes where only one was expected. I was taught that writing ceased in typing. The typist looked into the past, into what was written, not into what was being produced. Nothing is produced in typing, only reproduced.

Typing today is something quite different. I’m typing even now, as I contemplate this sentence, as I wander through this thought I hope to write. The thing I want to say is not yet available. I have no way to look into it, as though it were somehow solid and approachable. I’m left to pull it out of what is already before me on the screen. I have no access to a past that might comfort or control me. The typewriter has been replaced with the writer. Writing no longer ends in typing; writing no longer ends.

I’m unclear if they still teach typing. Is it simply the great prerequisite for all writing today? I grew up at a time where it still made sense to have both a computer and a typewriter in our house. They weren’t the same thing, and you’d want both for different tasks. It wasn’t yet clear, when I learned to type, that only one would be needed going forward. I learned to type and to write, and it wasn’t yet clear that only one would be needed going forward.

Posted in Digital Swag, Idea Factory | 1 Comment

What I’d do: software teams as indie bands

By david.humphrey | Published: January 21, 2012

I’ve often thought that it would be interesting to see software teams do indie band style pictures along with their releases. I’d like to see the people who write my software. I know hundreds of people who release libraries and tools, apps, demos and games, drivers and converters and utilities–yet they never really show up.

Long after the death of the album as a physical medium, we still expect to see who made the sounds contained within the music. They are seated in a semi-circle, posed at different levels, wearing plaid; they have their backs to one another at the counter of a bar; they are lined up in a wheat field and captured with a hazed filter on the lens; they have neck beards or wear scarves; they want you to notice their glasses and have washed their hair and styled it in order to look like they haven’t; they do their best not to smile; they are arranged like the spokes of a wheel as the camera looks down from above on their laughing faces.

When I download version 1.3 of your software, I want an album cover. I want to feel like I’ve encountered something human, something created. I want to watch your style change over subsequent releases. I’d like to see some of what we know as ‘the band’ happen in software.

That’s what I’d do.

Posted in Digital Swag, Idea Factory | 7 Comments

Return early, return often

By david.humphrey | Published: January 20, 2012

I’m fixing some code we wrote for the Mouse Lock implementation, based on review comments. I had forgotten how many of my colleagues teach our students that you should avoid multiple exit points from a function. It meant that our implementation code had a bunch of deep nesting in order to avoid early returns. We need to stop teaching that. There’s nothing wrong with “bailing early.”

Here’s the code in question:

    // When exiting fullscreen, if the pointer is also locked to the fullscreen element,
    // we'll need to unlock it as we the document exits fullscreen.
    nsCOMPtr window = aDocument->GetWindow();
    if (window) {
        nsCOMPtr navigator;
        window->GetNavigator(getter_AddRefs(navigator));
        if (navigator) {
            nsCOMPtr navigatorPointerLock = do_QueryInterface(navigator);
            if (navigatorPointerLock) {
                nsCOMPtr pointer;
                navigatorPointerLock->GetMozPointer(getter_AddRefs(pointer));
                if (pointer) {
                    // Unlock will bail early if not really locked
                    pointer->Unlock();
                }
            }
        }
    }

Here’s how it should look:

  // When exiting fullscreen, if the pointer is also locked to the fullscreen element,
  // we'll need to unlock it as we the document exits fullscreen.
  nsCOMPtr window = aDocument->GetWindow();
  if (!window) {
    return;
  }

  nsCOMPtr navigator;
  window->GetNavigator(getter_AddRefs(navigator));
  if (!navigator) {
    return;
  }

  nsCOMPtr navigatorPointerLock = do_QueryInterface(navigator);
  if (!navigatorPointerLock) {
    return;
  }

  nsCOMPtr pointer;
  navigatorPointerLock->GetMozPointer(getter_AddRefs(pointer));
  if (!pointer) {
    return;
  }

  // Unlock will bail early if not really locked
  pointer->Unlock();

The value of early returns is that it’s easier to read and less likely to contain bugs (i.e., variables can’t change all of a sudden and break algorithm). If you know that some code path is dead at a particular point, it’s better to return right there. After you’ve returned, it’s much easier to deal with the remaining code, since you don’t have to worry about hitting this spot due to state changes in a variable. Plus, it’s way easier to read when you don’t have to visually trace the indenting so far to the right.

Here’s a tip: return early, return often.

Posted in CDOT, Implementing Mouse Lock, Mozilla Education, Seneca, Teaching Open Source | 4 Comments

Occasionals

By david.humphrey | Published: January 7, 2012

I write to myself in the future, when I retire, and in case I own a winery, chocolate or cheese shop; at which time I want to remember to create a line of occasional fare, one very narrowly cast for a particular clientele, those appropriate only for particular occasions, and as gifts for such individuals.

These will want labels, with instructions, that express the intended way and means by which they should be enjoyed. For example: a bottle of Merlot indicating it is only to be drunk by a person with writer’s block; a box of chocolates that is to be consumed within 4 hours of love making; a bottle of Pinot Grigio that must accompany a summer stroll along a river; a truffle that should be eaten only in sadness, and ideally great sadness; a cheddar so old it must be nibbled while reading a novel of equal age and sharpness.

These ideas I leave here until then.

Posted in Food, Idea Factory | 3 Comments

Holiday Reading

By david.humphrey | Published: January 5, 2012

I’m coming to the end of my Christmas holidays. It has been a very restful and slow time. I’ve filled it with family, long, slow recipes, and reading. I logged off irc, closed my mail program, ditched twitter, and allowed myself to become properly isolated from my daily routines.

I also tried an experiment. My reading tends to follow the paths begun in my literary degrees. Studying literature causes one to accumulate huge lists of books that need to get read. I mostly read philosophy, capital ‘L’ literature, and essays. And I read some of this over the holidays.

But in addition to my usual reading, I game myself permission to venture off the lists. While in line at the local drugstore I noticed a shelf of books next to the magazines. Among the paperbacks on the shelf, I recognized two titles. First, Stieg Larsson’s “The Girl with the Dragon Tattoo,” a book I could remember my brother loving and telling me to read. Second, Suzanne Collins’ “The Hunger Games.” I’ve heard various people mention this book, not least my niece and nephew, who were both amazed and horrified I’d never read it, and implored me to correct this oversight.

I found both books nearly impossible to put down, with fast, clever plots. It was fun to get swept up in dark, unrelenting stories. The down side of plots this fast is that you don’t linger, don’t need to, the point is what happens next. I can’t imagine rereading either.

Encountering Larson’s Lisbeth Salander next to Collins’ Katniss Everdeen was interesting. Both girls (Lisabeth, though an adult, is still very young) have no father, lack a loving relationship with their mother, fend for themselves by breaking the law, and take care of their own safety in ways traditionally left to male characters. Neither girl lets the world around them into their inner life, and even the narrators struggle to understand much of what is really happening in their heads. And yet, it’s hard as the reader to not love them both. It is their very rejection of love that draws so many people to them, makes them so desirable.

Beyond these two strong female characters, the books deal with violence and death, lust (both sexual and otherwise), and power and control. The books are very different, and intended for different audiences (adult vs. teen). I found Larson’s repeated graphic rape scenes disturbing and hard to read; though I didn’t find them gratuitous or unnecessary. However, the novel’s ending was harder to believe than its beginning. At some point violence piled on violence isn’t achieving more, but begins to create a landscape where such things are common enough that they must be accepted or ignored. Collins, on the other hand, intentionally creates such a landscape, where children killing children is simply good television. Her presentation of the Capitol, and its mostly unseen populace, is haunting in what it doesn’t reveal about this acceptance. Who are these people who take such pleasure in such horror and pain? Larsson wants us to understand that they are the people we least expect, the people who are most completely unlike what we expect.

Friendship plays a central role in both books. For Larsson, the word is sometimes used as a euphemism, sometimes as a threat, and often as an impossibility. Lisabeth and Katniss are both right to distrust the people around them, both so well practiced at it that the impossibility of real friendship is really the point. Neither book affords its character the chance for anything more than temporary agreements: friendship as deep relationship is simply not available in either of Collins’ or Larsson’s worlds.

Reading the books also put me in mind of other similar books I’ve read, especially in the case of “The Hunger Games.” In the first third of this novel I was repeatedly taken back to Herman Hesse’s “The Glass Bead Game,” a book so incredibly different in many ways, but eerily similar in others, especially in its narrative of children being taken from their families and trained for games that the rest of the society will witness. The latter part of the book echoed Tom Brown’s “The Tracker.” The scenes with Katniss caught up trees, hunting, and tracking through the woods were very well done.

Both books are first in a trilogy. I don’t think I want to continue in Larsson’s world. The first book was gripping, horrifying, and stands on its own. Much as I feel about the evil in Charles Williams‘ novels, I understand its point in the story, but don’t want to subject myself to more of it than necessary. I will likely read the next Hunger Games book, though. I thought that there was much left to do in that story, and I’m interested to see how Collins will manage it.

Will I continue to read using the drugstore as my guide? I’m not sure I will. However, I loved this holiday from my usual patterns of reading.

Posted in Reading | 3 Comments

The Canadian Apple TV Experience

By david.humphrey | Published: December 31, 2011

For Christmas I bought my wife an Apple TV, which is the second generation of the device. We’ve been using it for the past week, and I thought I’d share some of my thoughts on what it’s like.

tl;dr It’s fantastic for movie rentals via iTunes, makes no sense for television.

Living, as we do, in northern Canuckistan, there are many strikes against us when it comes to accessing media. First, our only option for television service is satellite. We use Bell Express Vu with a PVR, allowing us to receive a few hundred SD and HD channels. For television this works quite well. We basically “tape” (I know, I’m old) all the shows we care about, and watch them when we want, skipping commercials or other objectionable content for our children. We never watch live TV. Ever (we refuse to watch commercials, and despite what some people tell us, we don’t want to “interact with brands.”) We can’t really access TV in any other form, since any legal web option is blocked at the US border–no Hulu, lots of “Sorry, you suck” messages on YouTube, etc. It probably doesn’t matter that much, since I don’t want to “watch” much on my computer and would rather watch on the couch with my wife or kids.

Movies are another story. While I don’t really watch television, I do enjoy movies. We live quite far from any movie theaters, and with young kids, my wife and I probably end-up going to the movies once or twice a year. A decade ago, our answer to this would have been to rent movies at Blockbuster or the like. Today that’s impossible, as the local video rental businesses have all gone out of business, literally. The paradox is that while we’ve entered a time of logarithmic growth in digital media, we’ve simultaneously found ourselves almost completely in the dark where we live. There are thousands of movies from the past 5 years or so that we’ve never seen because we simply can’t access them in a way that makes sense for us.

We could use Bell Express Vu’s Pay-Per-View channels. This typically costs $5.99 per movie, and is incredibly limited. At any given time there are a dozen movies on offer, each playing on regular rotation on as many channels. We can’t choose to watch a movie now (it might be starting again in the next 2 hours, though). We also can’t choose which movies we want to watch–the selection is a joke. Why they don’t make more movies available, I don’t understand. But then, it’s Bell: doing what their customers don’t understand is how they roll.

We could buy movies on DVD. Neither of us are film fanatics, and while I do reread books, I rarely rewatch movies–owning them doesn’t make sense for us practically. As such the price of most DVDs is crazy for a single viewing. We could subscribe to some sort of DVD-by-Mail service, however these are quickly going out of style. Also, the lack of immediate access is a problem for me. We could use NetFlix, but their Canadian selection, while quaint, isn’t what I’m after (I know many of my friends like it, though).

We could get movies from the library, which we do on occasion. However, this always involves multiple steps, since nothing is ever on the shelves in our small branch, and has to be ordered. The fact that this is possible at all is amazing, and for certain types of content, it continues to be a good option. However, like DVD-by-Mail, it isn’t instant, lacks selection, doesn’t give us access to more recent titles, and requires multiple trips into town. Another viable option would be stealing content using BitTorrent. Yes, I think it’s stealing and it doesn’t appeal to me. I won’t scold you for doing it, but it isn’t something that I can justify doing myself.

Then there’s Apple TV. We plug it into our TV (HDMI) and it connects by wireless to our home network (if we had an ethernet drop by our television, that would work, too). There are many videos of what it’s like to use, so I won’t repeat that here. The point is that it’s suddenly possible for us to once again rent movies. Lots of movies. Renting a movie costs either $3.99 or $4.99, depending on how new it is. Before you rent you can preview, which means either a trailer or 1-2 minutes of the movie itself. Once rented it is available to watch for 30 days, and after you press play, you have 48 hours to complete it. We’ve rented half-a-dozen movies this week, and it’s been a seamless and enjoyable experience. Never have we had to wait before watching, nor buffer in the middle of a viewing. We choose to use SD content (configurable in the iTunes settings on the device) since we only have a 5Mbps connection and Apple recommends 2.5Mbps for SD and 6 Mbps for HD in order to stream. This matches our television use, since we watch 95% SD content there.

Apple TV also includes a Television menu. Here we can buy television shows and/or seasons in much the same way we access movies. I said buy. Gone are the days of the $0.99 TV show rental (I mean, they never existed here in Canada). An episode costs $2.49. Most shows have a dozen episodes or more per season, and in some cases you can buy a Season’s Pass, which adds new episodes as they become available. The purchased items are available via iCloud, making it unnecessary for you to buy large storage devices or manage media locally.

I’m willing to pay $4 or $5 to rent a movie. I think that’s reasonable–I’d love to pay less, but it used to cost more than that to rent them at Blockbuster, and I had to drive there and back. I’m not willing to pay $2.49 for TV shows. It seems like Apple, and whoever else is behind this pricing, isn’t serious about television yet. I could buy a season of a show on DVD and format-shift it into iTunes for a lot cheaper if I wanted to (which I don’t). Also, with the possible exception of kids shows, owning a television episode makes even less sense to me than owning a movie.

The device also allow us to access YouTube, Vimeo and other web content. However I find its “browse” style interface a deal-breaker: YouTube’s only value, as far as I’m concerned, is deep linking. And with no bluetooth keyboard access (dumb if you ask me, Apple, since I own 3 of them), I’m not going to do Search either and hen-peck my way through the onscreen keyboard.

So the combination of television through satellite and movies through iTunes looks like the future for us. As someone who writes software myself, it’s painful to watch how far behind these technologies are compared to what’s technically possible right now. As I write this on New Year’s Eve, I’m hopefully that it can only get better. In the meantime Apple TV with movie rentals on iTunes gets two thumbs up from us.

Posted in Digital Swag | 5 Comments

Using LaTeX to publish a novel on Lulu

By david.humphrey | Published: December 20, 2011

I’m going to blog about this because I can already feel myself forgetting key bits of the process. You’re welcome to the information too, but please note, dear reader, that I’m sure there are more appropriate ways to accomplish some of what I did.

My friend Luke wrote a novel for his children, which he’s self-publishing (he published chapters to his blog as he went, if you want to see it). It’s really good, and I wanted to see it look really good too. So I convinced him that he should use LaTeX to typeset it. “Sure, if you’ll help me.”

I know LaTeX in the same way that I know Julian Barnes–I’m a fan and appreciate what it can do (in the hands of experts). I am not a LaTeX expert, but I was willing to learn it. After having spent some time with it I’ve come to the conclusion that it’s criminal that I wasn’t formally taught this in either my English or CS courses–how often did I needlessly fight with MLA or APA styling for formal papers?

I won’t begin to try and teach you LaTeX, but will instead give some tips on what worked for us:

On my Mac, I used TeXShop, which is part of http://www.tug.org/mactex/2011/
We used the memoir class for the novel’s layout. The memoir manual is useful, though daunting: memman.pdf. I consulted it many, many times.
In order to produce a Trade Paperback formatted page (6 x 9 inches, 152 x 228 mm) in memoir, I had to use the not-so-obvious ebook documentclass:

\documentclass[ebook,12pt,openany]{memoir}

Producing a simple dedication was rocket science. Luckily I found others who had been to the moon already:

\newenvironment{dedication}
{
   \cleardoublepage
   \thispagestyle{empty}
   \vspace*{\stretch{1}}
   \hfill\begin{minipage}[t]{0.66\textwidth}
   \raggedright
}%
{
   \end{minipage}
   \vspace*{\stretch{3}}
   \clearpage
}
...
\begin{dedication}
To my children
\end{dedication}

I found this document [pdf] incredibly helpful for choosing a chapter style. We ended-up using dash:

\chapterstyle{dash}

Quotations have to be rewritten to differentiate opening- and closing-quotes. That means “quoted” becomes
```
``quoted''
```
For the page style, we chose to have the numbers appear in the upper-left corner of the left-hand page, and the upper-right corner of the right-hand page:

\pagestyle{simple}

To create a final pdf with fonts embedded–something numerous sources underscore–I followed the advice here:

pdf2ps doc.pdf
ps2pdf13 -dPDFSETTINGS=/prepress doc.ps doc2.pdf

I’m pleased with the outcome. And while I know there are things I’d do differently if I knew how to properly wield LaTeX, I’m pretty impressed with what it can do on its own and despite me.

UPDATE: Luke has blogged a link to the book on Lulu.com.

Posted in Digital Swag | 4 Comments

Reading Hitchens, Remembering Chesterton

By david.humphrey | Published: December 18, 2011

Reading the various obituaries and reflections on the occasion of Christopher Hitchens death, caused me to go back and re-read some of his articles, especially those in Vanity Fair and Salon. As a Christian believer myself, I disagree with much of his thought; but as a writer and thinker, I appreciate his style, his enormous intellectual breadth, and the way he brought literature back to journalism. I was reflecting last night, wondering what he might have looked like, as a writer, had he instead believed. I realized that I probably already know what a Christian Christopher Hitchens might have read like. Chesterton was also 62 at his death.

Posted in Idea Factory | 1 Comment

Implementing Mouse Lock, conclusion

By david.humphrey | Published: December 12, 2011

This post is the last in a series I’m writing about my work to implement the Mouse Lock API in Mozilla. I’m doing the work with students in my Mozilla Open Source course at Seneca College, and so these posts are intentionally didactic and self reflective. The aim of the series is to show how a new feature gets implemented in Firefox. Please note that all code discussed is unreviewed and not part of a shipping Firefox at this point.

We’re done. Friday was the last day of classes, and I’m happy to report that we’ve finished our patch and got it up for review. We’ve also gotten 80% of the way on the tests, which I’ll talk about below. I’ll tell you honestly that I didn’t think we’d get it completed by the end of the course, so it was all the sweeter to actually get to post it on the last day of class. Even better, for me, is the fact that we’re done on time because of the hard work of quite a few students.

We’ve had a working Mouse Lock for many weeks now, but it took us a long time to iron out all the wrinkles in the spec (and we still have more). We managed to complete almost everything we set out to do. I’m still stumped on the best way to handle a few things, and am glad to be into review now, where I can get advice on implementing the final few bits.

Review is one of the most important parts of open source development. It’s not about people criticizing you so much as helping you make your code the best it can be. I do expect to get lots of constructive criticism of our code, and also to fail our first review(s)–it will likely take 3-5 iterations on this patch before it’s ready to land. In the meantime we’ll get expert advice from people who really know the code where we’ve been working. If you can get over your own ego long enough to listen to the feedback, review can be a wonderful process.

Since my last post we’ve been working (and working fast) on so many separate bits of the code in parallel I’m having trouble remembering all of it. I’ll focus on three things that stand out for me: 1) giving up control and running a mini-Mozilla on github; 2) the challenges of keeping a patch working against trunk; 3) the complexity of testing.

Many open source projects, Mozilla included, have sayings: “if you have to ask who owns it, you do;” or “if you find it you fix it;” and “no good deed goes unpunished.” There’s so much work to do on code this large that the only way things get done is if people take ownership of issues and–to borrow yet another phrase–”drive them into the tree.” Without strong ownership, bugs quietly sit unnoticed, and issues persist. In order to teach my students how a feature gets into Mozilla, I decided to use these same approaches. It’s the reason Matthew ended-up fixing bug 334573. It’s the reason Raymond ended-up managing check-ins for all the students’ tests.

[Side-note: I'd love Mouse Lock on github's Network View]

At a certain point it made more sense for me to give up control of the tree and let Raymond manage it. He’d been doing a great job merging my code with other students’, so he obviously could be trusted with more responsibility. Open source isn’t (or shouldn’t be) about holding on to power. Rather, it’s about finding opportunities to share that power with others. Going it alone doesn’t scale. It’s also the case the people end up in roles vs. seeking them out. You become the person who does X by doing X. It’s often that simple. Running a mini-Mozilla project on github was interesting. I chose git and github simply because the students already knew it, and I didn’t want to add Mercurial as yet another layer of complexity. By having a distributed version control system, it was easy to give the students the chance to take control of the entire process of getting this code written and managing the tree. It was very successful, and I’d do it again.

Speaking of version control, another aspect of adding a feature like Mouse Lock is that you have to keep a non-trivial patch working against trunk. The foundation on which you’re doing your work is constantly shifting. For example, on the day we submitted our patch, we had to deal with changes to the navigator object, as well as changes to the fullscreen API, both of which broke our code. Obviously not every change to trunk is going to touch code where you’re working. But if you’re making changes to things that are in heavy traffic, you’re going to get run over. A lot.

To keep the students from getting overwhelmed by this, I chose to do a weekly merge with mozilla-central. On any given day that’s 50-100 checkins, many of which are big merges from feature branches. It adds up to thousands of changes every time we merged, and often conflicts, especially in our DOM code. However, this is what it’s really like! Only in a few cases did we get into trouble with bad merges (I was to blame for one of the worst ones). I think it was a great lesson for the students. It also showed them why you want to get things done as soon as you can, and that understanding your tools is key to having your work progress.

The aspect of our work that took the longest this time was writing our tests. Tests are an important part of any new feature or bug fix in Mozilla, and without them, no well meaning feature is going to ship. I misjudged how complex the students would find writing Mouse Lock tests, assuming that having done as much JavaScript as we had, they’d just pick it up. I was wrong.

Mozilla has many types of automated tests, and the kind we need is Mochitest. A Mochitest is a web page with test assertions similar to jQuery’s QUnit test framework. It also has ways to do things normally not allowed by a web page, including interacting with the browser’s Chrome, and moving the mouse. Our tests would need to cover as much of the spec as we could. Writing tests is something of an art, since you’re trying to produce the conditions for edge cases. As a group we came up with a list of tests that needed to get written, and then divided them up among students in the class. The students then wrote lots of tests. After writing their tests, I asked them to review and help each other fix issues in their code.

Almost none of the tests I saw would have been accepted in review, either for style issues, broken code, or timing bugs. The number one anti-pattern I saw in the tests was that people didn’t understand the flow of asynchronous functions and events. The tests would be a mix of asynchronous and synchronous calls, and would fail in strange ways due to timing issues. I wasn’t prepared for how hard they’d find this, and in future I’ll spend more time teaching them these fundamentals. Here’s a typical, simplified example:

...
var pointer = navigator.pointer;

// Test 1: Setup some code that should allow mouse lock to work
...
pointer.lock(
  element,
  function() {
    ok(pointer.islocked(), "Pointer should be locked!");
  }
);
// Test 2: Setup some code that should force mouse lock to fail
...
pointer.lock(
  element,
  function() {
    /* shouldn't happen */
  },
  function() {
    ok(!pointer.islocked(), "Pointer shouldn't be locked!");
  }
);

In the code above, the author rightly uses callbacks to check for success or failure, but then calls pointer.lock twice in a row, the second time before the success callback of the first has completed. The same kind of problem was evident with tests involving focus, blur, fullscreen (which nearly every one of our tests required!), the DOM being ready, etc.

Once we got these issues fixed, and the majority of the tests in place, we still had a problem, since every single one was failing when run as part of the full mochitest suite. This turned out to be a restriction on iframes and needing fullscreen mode. The fix, as with so many things, involved studying how others had faced similar issues. One good side effect to the issues we hit is that our tests seemed to have caught a crash bug in another part of the code.

As we were doing final tests I made try server builds so we could test on different machines without needing to build. Within a day of those builds being up, and me blogging about it, Brandon Jones had added Mouse Lock support to his amazing WebGL Quake 3 demo. I recorded a video of what it looks like, which you can see here:

It’s rewarding to see people taking your work and doing such cool things with it so quickly. I don’t think I’ve ever had a last class where I got to show something as cool as Quake 3 with Mouse Lock running in the browser and been able to say, “you did this.”

While our work on this feature isn’t 100% done, since reviews will inevitably mean more fixes and tests, this series is at an end. I got an email from one of the students today asking, “Sir, can I still work on this after the course is over?” The answer is obviously ‘yes,’ and if you too would like to continue following along, please add yourself to the bug.

I hope in this series I’ve managed to do a few things. First, to show you that it’s not as hard as you think to contribute to a project as large as Firefox. Second, and at the same time, that while it is pretty hard to contribute to code this large, it isn’t impossible. Getting things done involves patience, persistence, and the willingness to ask good questions when you get stuck. The Mozilla community wants to see you succeed, and is, for the most part, quite helpful.

Lastly, to professors and students reading this series, I’d encourage you to work on real code together. You don’t have to be at the “right” school, to do work that changes the web, and you don’t have to be experts. You can be a bunch of college kids in Toronto, and as long as you’re hungry and willing to push yourselves, you can get there. The risks are part of what makes it so much fun. It doesn’t have to be Mozilla, obviously. Any open source project would be glad to get a patch for something like Mouse Lock from you. Most of all, don’t be afraid to fail, since that’s exactly what it takes to win. I think we won.

Posted in CDOT, Implementing Mouse Lock, Mozilla, Mozilla Education, Seneca, Teaching Open Source | 3 Comments

Level Up: Mouse Lock + Gamepad builds

By david.humphrey | Published: December 7, 2011

I’m finishing up the Mouse Lock patch today so I can get it into review by Friday, which mostly means I’m waiting on my students to get their tests finalized (hurry up, guys!). Meanwhile, I’ve had a bunch of people ask for builds, and also to fold the Gamepad and Mouse Lock APIs into one build. So I did that. You can download custom builds here. The code is in my mouselock-gamepad branch on github.. These custom builds will go away soon, so get them while their hot (note: they’re smoking hot)–I hope they’ll be shipping in Firefox soon so it won’t matter Here’s some simple Mouse Lock demos, and a simple Gamepad demo.