I'm only a few days away from starting to teach a week-long crash course on Mozilla development (I'll fill-out the page as I go). This is going to be a real experiment. I've taught a 14-week version, where students work on projects; but this is different. Here I'm going to work quickly in order to take the students through everything from community development practices to version control to building/developing/debugging/patching to writing binary XPCOM and chrome extensions--and all in 5 days over their break week. Should be exciting (read "exhausting").
I was a little worried that there wouldn't be enough students. However, 40 people signed-up in the first week of registration, and now there's a waiting list. _Note to others who might be thinking of teaching Mozilla: students love this stuff, at least mine do.
_
For the past few days I've been banging my head trying to make some examples work, some simple examples. After I show them how to build and debug Mozilla's C++ and JS, I want to jump right into XPCOM. My plan is simple: build a binary component, and do it in the tree so they can get some build-system scars. Then, write some tests to make sure it's all in order before sprinkling on a bit of chrome.
What one wants in teaching situations like this is a walkthrough/demo that "Just Works" so you're not scrambling at the podium trying to explain why your code sucks. However, this story has a different ending.
I've written XPCOM extensions using the build-system before, and there are some good docs, which when taken together, basically get you where you want to be--so I know it works. That's what made it all the more frustrating when this time it wouldn't. Not only did it refuse to work, make refused to give me anything approaching a helpful error message. Just before I smashed my laptop, luser identified the error as a trailing space after my XPI_NAME in Makefile.in, resulting in bug 371201.
Next I focused on writing some tests. One of my goals during the week is to show the importance of proper testing (automated and manual) in the Mozilla context. I'd chatted with Robert Sayre about it previously, in order to make sure I was right in focusing on xpcshell unit tests. So, I wrote some tests and ran make check only to discover that my component wasn't being loaded. It loads in the browser, but xpcshell disavows any knowledge. Nice. An hour chatting with shaver, sayrer, and ispiked, and another bug is born: turns out you can't (currently) use make check with XPI_NAME-built extensions.
So, to recap, I start teaching on Monday and as of right now my stuff won't work. Let me tell you why I'm happy about this. Everything I've just said will come as no surprise to those of you with experience developing Mozilla. Of course there are bugs, and of course you hit them at the worst times. I realized last night what a great opportunity this is to show the students what it's really like: write all that code and end-up in bugzilla.
Seth and I have been having a conversation about what it's like to teach Mozilla. I was trying to describe to him how it's different than teaching something like .NET, which I've also done. I think what I've just described illustrates my point: with .NET you work with releases only and are completely detached from the development work going on in-between those releases. It's nice because it takes a long time and so books get written, knowledge accumulates on-line, etc.
What I'm trying to do is totally different. By having students work with trunk builds, throwing them into the newsgroups and irc, etc. you open the door to all sorts of problems, but all sorts of opportunities too. Sure, it means that my examples aren't going to work in class. It also means that I get to open the hood on Mozilla and show the students that there are some really great people underneath working hard to help make things better. I'll take that over the sterility of a shrink-wrapped textbook any day.
Now, if sayrer wants to make good on his joke to fix 371329 before next Wednesday, I'm not going to complain :). I'm sure I'll hit another bug I can show before then! Oh, and if you want to stop into #seneca next week and say 'hello' to the students, please do. It's going to be busy in there.