Planet CDOT

The Fedora qemu-system-arm package provides pretty good ARM processor emulation, which can be used to run the Fedora ARM secondary architechture. This is an easy way to get started working with ARM -- for example, while waiting for your plugcomputer, beagleboard, or OLPC XO 1.75 to arrive

The previous wiki notes on using ARM with QEMU didn't cover using qemu-system-arm under libvirt management. This meant that you couldn't easily take advantage of libvirt benefits such as automatic network setup (with DHCP and NAT), the virt-manager GUI tool, guest autostart, or disconnection/reconnection to the console.

I've updated https://fedoraproject.org/wiki/Architectures/ARM/HowToQemu to include some basic notes on setting this up, and provided some files to simplify and speed up the process. Jump in and join Fedora-ARM, the water's nice!

We’ve just released Processing.js 0.6, and with it a bunch of bug fixes and more WebGL-based 3D support.  You can download it here, and read the full blog-post here.  We had hoped to get a rewrite of the color implementation in this time, which will bring with it some nice performance gains, but that is going to slip to 0.7.  If you’re using Processing.js, please file bugs and show us what you’re building.

mock is a Fedora package building tool. When invoked to build a specific package from a source RPM (which contains the package source plus a spec file), it creates a chroot environment, populates that environment with a very small set of base packages plus the build requirements specified in the spec file, and then attempts to build the package in that environment. This permits the build environment to be (somewhat) isolated from the host environment, so that a different set of build dependencies (tools, libraries, and headers) can be used for building. It's ideal for proving that the build requirements are correct, and it also permits you to build a large set of packages without installing a lot of build dependencies on the host system. It's also a highly automated and very convenient way to build

I've been experimenting with building for and on the ARM architecture. Fedora 12's mock package does not include a config file for ARM; here is a config file I've cobbled together as a starting point:

config_opts['root'] = 'fedora-12-arm'
config_opts['target_arch'] = 'armv5tel'

# The chroot_setup_cmd is usually 'groupinstall buildsys-build' but that hasn't been defined for ARM yet.
# Instead, the package list is specified here.
config_opts['chroot_setup_cmd'] = 'install bash bzip2 coreutils cpio diffutils fedora-release findutils gawk gcc gcc-c++ grep gzip info make patch redhat-rpm-config

rpm-build sed shadow-utils tar unzip util-linux-ng which bash curl cvs fedora-release gnupg make redhat-rpm-config rpm-build shadow-utils'
config_opts['dist'] = 'fc12'  # only useful for --resultdir variable subst

config_opts['yum.conf'] = """
[main]
cachedir=/var/cache/yum
debuglevel=1
reposdir=/dev/null
logfile=/var/log/yum.log
retries=20
obsoletes=1
gpgcheck=0
assumeyes=1

# repos

[fedora]
name=fedora
mirrorlist=http://mirrorlist.fedora-arm.wantstofly.org/?repo=fedora-12&arch=arm
failovermethod=priority

[updates-released]
name=updates
mirrorlist=http://mirrorlist.fedora-arm.wantstofly.org/?repo=updates-released-f12&arch=arm
failovermethod=priority
"""

This uses the existing fedora-arm repositories along with an explicit list of base packages for the mock environment. Ultimately, the buildsys-build package group will be specified in a special-purpose repository, but the explicit package list given here provides a good starting point.

Update: here's a link to this mock config file: http://cdot.senecac.on.ca/arm/fedora-12-arm.cfg

I’m happy to announce that Processing.js version 0.5 is now available for download.  This release fixes many bugs and adds new features, including the first support for WebGL based 3D functionality (PMatrix3D, box, camera, etc.).  Please note that you’ll need a WebGL enabled browser (e.g., Firefox nightly as discussed here) to use these 3D features.  See the changelog for full details.

Our focus continues to be on keeping the release cycles short (0.4 was released on Feb 3) as we close in on 1.0, which we anticipate releasing in early May.  As a result, now is a very good time to test your code and file bugs when you find things are wrong, slow, etc.  We work in the #processing.js irc channel.

We’re seeing more and more people doing interesting things with Processing.js, from putting it on the iPhone, to using it to teach Game Development to university students, to creating real-time interactive visualizations on the web.  It’s great to see, and we look forward to unlocking much more functionality and speed in the coming releases.

Yesterday I was frustrated.  I’m teaching my open source Mozilla courses, and I happened to look at our blog planet.  Right now we’ve got more than 30 students working on various open source projects, and to look at their blogs, you’d think they were all on holidays.  I view blogging as a barometer for development activity.  “I don’t have anything to write about” is synonymous with “I am not doing anything worth writing about.”  I went around the room and asked my students why they hadn’t done the coding I’d assigned (I asked them to modify something simple in Firefox).  The answers were weak.

I’ve been teaching long enough to know that students often do the minimum required to get a grade.  And while that might be a reasonable way to get grades, it’s not going to turn them into software developers.  Software is hard.  I was commenting to Chris yesterday that a computer is basically just a box built on a system of reason you don’t understand yet.  Programming is mostly about overcoming your own limitations.  It’s creative, problem solving work, and it is something you have to spend a lot of time to get the hang of before you’re any good.

Some of my colleagues talk about students either getting it or not getting it.  I’m not sure I believe this.  I think the right way to think about this is that there are students who push themselves, and those who don’t.  I know some developers who seem to just be built for the task of thinking through these problems.  I also know that they’ve worked really hard to get to this place, and that it’s easy to confuse their ability now for something innate vs. something acquired.  Sure, you have to have certain qualities in order to get there; but the one we don’t talk about enough, which I think is the most important, is that you have to be willing to put in the time and push yourself.

While I was getting after my students, I pulled up a favourite essay of mine, Peter Norvig’s Teach Yourself Programming in Ten Years.  He’s writing about a phenomenon I don’t see as much today–the “Learn X in 21 Days!” books.  What I wanted to show my students, though, is how well what he’s saying maps onto open source development.  Here are some examples:

• Get interested in programming, and do some because it is fun. Make sure that it keeps being enough fun so that you will be willing to put in ten years.
• Talk to other programmers; read other programs. This is more important than any book or training course.
• Program. The best kind of learning is learning by doing. To put it more technically, “the maximal level of performance for individuals in a given domain is not attained automatically as a function of extended experience, but the level of performance can be increased even by highly experienced individuals as a result of deliberate efforts to improve.” (p. 366) and “the most effective learning requires a well-defined task with an appropriate difficulty level for the particular individual, informative feedback, and opportunities for repetition and corrections of errors.” (p. 20-21) The book Cognition in Practice: Mind, Mathematics, and Culture in Everyday Life is an interesting reference for this viewpoint.
• If you want, put in four years at a college (or more at a graduate school). This will give you access to some jobs that require credentials, and it will give you a deeper understanding of the field, but if you don’t enjoy school, you can (with some dedication) get similar experience on the job. In any case, book learning alone won’t be enough. “Computer science education cannot make anybody an expert programmer any more than studying brushes and pigment can make somebody an expert painter” says Eric Raymond, author of The New Hacker’s Dictionary. One of the best programmers I ever hired had only a High School degree; he’s produced a lot of great software, has his own news group, and made enough in stock options to buy his own nightclub.
• Work on projects with other programmers. Be the best programmer on some projects; be the worst on some others. When you’re the best, you get to test your abilities to lead a project, and to inspire others with your vision. When you’re the worst, you learn what the masters do, and you learn what they don’t like to do (because they make you do it for them).
• Work on projects after other programmers. Be involved in understanding a program written by someone else. See what it takes to understand and fix it when the original programmers are not around. Think about how to design your programs to make it easier for those who will maintain it after you.
• Learn at least a half dozen programming languages. Include one language that supports class abstractions (like Java or C++), one that supports functional abstraction (like Lisp or ML), one that supports syntactic abstraction (like Lisp), one that supports declarative specifications (like Prolog or C++ templates), one that supports coroutines (like Icon or Scheme), and one that supports parallelism (like Sisal).

Notice how your grades aren’t really what matters here?  Some of the best programmers I know never went past high school, and some of them went to Harvard.  It turns out that there is something other than grades that makes you good at this stuff.  I honestly believe that involvement in open source for students is one of the most critical things to doing what he describes.  How do you do some of this stuff without open source?  How do you work on projects with other programmers if you can’t get hired somewhere (no experience? no job)?  How do you get to work with programmers who are better than you if you don’t know any?  How do you get to work on large code bases after someone else has written them if you can’t access them?  How do you learn half-a-dozen languages without a need for them all?  How do you learn how to read code without code to read?  Open source might not be the only way to do what he describes, but it is the most readily available way for large numbers of students.

The last thing that happened in my day before I went home was that another student (not in my class) came to see me to ask about how to fix his Firefox debug build.  He came to me a while ago looking for a bug he could do in Mozilla.  “I want to learn, what do you suggest I work on?”  I gave him a non-trivial C++ bug in Mozilla’s XPCOM system that is causing some strange crashes.  Since then he’s taught himself a lot, started to ask some useful questions, and gotten underway on his 10 years to becoming a software developer.

What is necessary to get students to do this kind of work?  They have to want it.  They have to push themselves.  There’s not much you can do to make them do it, since no course lasts 10 years.  It’s not that there are those who are good at this and those who aren’t.  There are those you push themselves and those who don’t make the time.  Want to get good at this stuff?  What are you doing about it?

I finished up some work today on the Processing.js automated test tools.  Previously I wrote a test harness to allow JavaScript based unit tests, as well as parser tests.  However, after watching some of my students struggle through bugs during the lead up to their 0.5 release, I decided we needed a way to also be able to write them in Processing.  Right now I see a lot of tests being drawn into sketches, and then manually comparing results.  It’s sub-optimal to say the least.

Having written the unit test functions already, I decided to simply load them into Processing via a library.  Processing.js, like Processing, has the capability to load “native” libraries.  In Processing.js, such libraries are JavaScript functions written like so:

(function() {
  Processing.lib.Foo = function() {
    this.something = function() {...};
    ...
  }
})();

Then, in your Processing.js sketch code, you initialize the library by calling its constructor (e.g., Foo();), and then any function (e.g., something();) will be available to your code.

Using this technique I added the same set of _check* functions already available to JavaScript unit tests, such that I’m now able to write small unit tests in Processing like this:

// Tests for Processing str() function - http://processingjs.org/reference/str%28%29
boolean b = false;
byte y = -28;
char c = 'R';
float f = -32.6;
int i = 1024;

_checkEqual('false', str(b));
_checkEqual('-28', str(y));
_checkEqual('R', str(c));
_checkEqual('-32.6', str(f));
_checkEqual('1024', str(i));

I’ve fully documented the setup and use of the new automated testing features. All Processing.js developers (especially my students), should read through this. Beginning with the 0.6 code, we’ll start using this by default for all regression and API testing.

I did a rewrite of the Processing.js test suite code to get around a bug Al hit on Linux.  In doing so, I hit another nasty bug that Ted eventually solved.  I needed to get an escaped version of JavaScript or Processing code loaded into the js shell via the -f flag.  Previously I had been passing this as a string via -e, but we were erroring out as the size of the files increased beyond the max arg length allowed.  My solution was to create a temporary file in Python, stick the encoded script in, pass that into the shell for processing, then delete it.

It worked great on OS X, but on Linux we were getting an exception about half-way through the test run “Too many open files.”  We have 855 test files at present, so it seemed unlikely that we had hit a real OS maximum.  I tried adjusting the number of file descriptors per process (ulimit -n 8192) and it worked.  Looking at my code I first thought that I must be accumulating pipes (I use stdout and stderr to communicate with the js shell).  Nothing I could think of was fixing it, and it seemed crazy to me that subprocess.Popen() wouldn’t close them properly.

Eventually Ted figured out that my issue was that I wasn’t closing my temp files properly.  Here’s the relevant bit of what I was doing:

tmp = tempfile.mkstemp()

t = open(tmp[1], 'w')
t.write(es)
t.close()

“But I am closing it,” I protested. “No, sir. You’re not!” said Ted, and he was right. Looking again at the docs for mkstemp(), and reading more carefully, I noticed this:

mkstemp() returns a tuple containing an OS-level handle to an open file (as would be returned by os.open()) and the absolute pathname of that file, in that order.

Did you catch that?  “…an open file…”  I missed it totally.  I have said it before, but it is worth repeating: Python has really amazing docs.  I should read them more often.  Here’s the fix:

tmp = tempfile.mkstemp()
os.close(tmp[0])

The Globe picked up a Canadian Press article today, whose title echos the favourite refrain of big media and other institutional onlookers of so called social media: “Students failing because of Twitter, texting.”  In it the author cites some “solid evidence” for the demise of writing skills at the post secondary level:

Ontario’s Waterloo University is one of the few post-secondary institutions in Canada to require the students they accept to pass an exam testing their English language skills.

Almost a third of those students are failing.

…

“What has happened in high school that they cannot pass our simple test of written English, at a minimum?” she asks.

Even those with good marks out of Grade 12, so-called elite students, “still can’t pass our simple test,” she says.

Poor grammar is the major reason students fail, says Barrett.

“If a student has problems with articles, prepositions, verb tenses, that’s a problem.”

We’ve heard all this before.  Poor writing?  Increased use of social media?  Let’s connect the dots.  A little further into the article, we find some other interesting bits; let’s start with grammar:

Some students in public schools are no longer being taught grammar, she believes.

…

“When I went to high school in the ’70s I was never taught grammar in English. I learned grammar from Latin classes.”

…

“We haven’t taught grammar for 30-40 years…(and it) hasn’t worked.”

“It’s not that hard to teach basic grammar,” he says.

I learned grammar studying classical Greek through four years of university.  I was never properly taught grammar in high school, because that final statement above is false: it is hard to teach grammar, or perhaps it is hard to teach it well.  Grammar, as an abstract system, is very difficult to grasp when you only know one language.  Without being able to step outside English and examine it from the vantage point of Greek, I don’t think I would have ever understood it.  But in the context of learning a second language, especially its literature, one is forced to map grammatical structures back and forth.  You can be a very good speaker or writer of English and not know the names for the constructions you use.  You can’t learn to read another language without them.  In other words, the need for grammar has to be real if one is to learn and then retain it.  I think many of the high school students who failed these tests did in fact learn grammar; they just didn’t retain it beyond the final exam.

Another issue discussed at length is spelling, contractions, and other short forms:

Emoticons, happy faces, sad faces, cuz, are just some of the writing horrors being handed in, say professors and administrators at Simon Fraser.

…

“Instead of ‘because’, it’s ‘cuz’.

…

“The words ‘a lot’ have become one word, for everyone, as far as I can tell. ‘Definitely’ is always spelled with an ‘a’ -’definitely’. I don’t know why,” says Paul Budra, an English professor and associate dean of arts and science at Simon Fraser.

I find the last example particularly funny.  The use of alot vs. a lot frustrates me, I’ll be honest.  I have a friend who uses ‘alot’ exclusively, and one day I decided to send him a private note telling him of his mistake.  He replied politely that he knew, and had made a conscious decision to change the spelling as a way of normalizing ‘alot.’  I was blown away at first, but later, upon reflection, had some respect for his decision.  Spelling reforms have happened throughout history, whether through decree or by means of popular usage shifts.  If ‘definitely’ is always spelled ‘definately,’ it soon will be.  Is it E-Mail, E-mail, e-mail, or email?  Spelling is very much influenced by usage, just as meaning.

Students haven’t learned grammar.  Students haven’t learned to spell.  Ergo:

Cellphone texting and social networking on Internet sites are degrading writing skills, say even experts in the field.

“even experts” notwithstanding, how do we make the leap from an obvious lack of focused study on particular areas of language learning, and the increased use of cellphones, social networking, and the web?  Furthermore, how is it that these are degrading writing skills?

I have spent the past decade teaching software engineering to third and fourth year undergraduate students.  I teach in what is often thought to be an illiterate discipline (in addition to English and Greek philology, I also studied Computer Science, so I can speak from experience).  What does programming have to do with writing?  A lot (or should I say, Alot).

In my courses I expect students to do a great deal of writing and reflecting.  Students are asked to keep a blog, use Twitter, collaborate on wikis, and communicate in real time using irc.  My experience in doing this over the years is that students have a lot to say, are thinking in ways that help move the class forward when shared, and most of all, that they have much to teach the other students and myself.

Do I see them make mistakes in terms of punctuation, grammar, and style?  I do.  Do they see me do the same thing?  Most certainly they do.  But we’re all writing.  Can students write?  Yes, if you let them.  Yes, if you model writing, and reading for them.  One of my students asked me a few weeks ago if I’d ever done a word count on my blog.  I hadn’t but decided to try.  It turns out I’ve written the equivalent of 3 good sized novels since 2006.  I haven’t written a novel, though, and don’t expect I ever will.  Instead, blogging, Twitter, social networking, and the web have insured that I exist in a literate age, where writing every day is the new normal.  I would argue that if students were allowed to use the web more, they’d be in even better shape.  As David Eaves notes of his blog, “if writing is a muscle, this is my gym.”

I’m less skeptical of students’ ability to write than I am of the intentions of educators decrying the demise of writing.  When all we have of writing is a “simple test,” education is reduced to a set of questions you can use in order to substitute real reading and ideas for a bell curve.  We’ve seen “simple tests” before, and they often have very little to do with real writing.  Writing, like many worthy pursuits, is easily stifled by pedants, who confuse the rules of writing for writing itself.

Today I finished-up my work writing automated tests for the Processing.js parser and a full unit test infrastructure.  It has been an interesting bit of work, and resulted in a lot of good info.  Today I imported Ben and Casey’s sample code from their Processing books, and it was interesting to watch things pass and fail.

Of the 855 Processing files I tested today, 623 were parsed correctly (72%).  This leaves 232 that fail for one or more reasons.  It’s actually not as bad as it sounds, since there are six main errors I see over and over, for which I’ve filed bugs, and a bunch of other failures that are likely related to my python/js scripts.

I’m pumped to have some new students about to start writing tests and doing more investigations into these bugs.  At the same time, we’ve got a new project coming online to do an antlr-based rewrite of the parser.

If you’ve got Processing code that you want to make sure works on the web, let us know so we can add it to our automated test suite.

This is the story of my favourite kind of programming.  The kind of programming where you have a handful of existing tools, a bunch of data, and you need to make it all fit together somehow.  There’s no neat-shrink-wrapped-sofware-download-it-from-the-web way to do it (none of this stuff was meant to go together), so you start hacking your tools, abusing data formats, work in multiple languages, and otherwise get round pegs to slide smoothly into square holes.

Today’s fun comes as a result of the need for a test harness to drive automated tests for the Processing.js parser.  I tell it in large part to help my students see how one leverages open technologies and formats on the way to solving otherwise unsolvable problems.  There’s no button in Visual Studio for what we’re about to do here.

The story is set within the Processing for the Web project, which is making a JavaScript version of Processing.  The past few days we’ve been trying to track down some bugs related to the parser.  Right now, there is a clever hack in place to take Processing code, and using a series of regular expressions, turn it into pure JavaScript.  It’s a nice bit of code, and works pretty well turning the Java-style syntax into something the browser can understand.  It’s also very brittle.

What we really need here, and what Processing itself uses, is an antlr based grammar to build our parser on top of JS.  Processing basically subclasses the Java antlr grammar, and we could do the same thing, only use the JavaScript target.  Probably doing this in parallel to a parser-lite version in the browser, so that you could choose to create your pure JS Processing code once, and then include that in your web pages.  I’ve filed a bug, and some unsuspecting student is going to get the chance to work on it soon…

But!  before you can go reimplementing a parser, and before you can properly fix regressions in the current one, you need a proper test suite.  We really need a simple way to take valid Processing code, and make sure our parser produces valid JavaScript.  And we need it now, so we don’t break more code while we fix these bugs.  I debated making it a student project for this term, but Al convinced me that we needed it for the next release.  So today I wrote a test harness.

The problem is actually pretty simple, but automating it required some thinking.  I have a parser written in JS that is meant to be run in a web page, and I need to take lots of Processing code and run it through, some of which I want to pass, some of which I want to fail, etc.  In order to automate this, I really want to decouple this from the browser, and do it from the command-line.

A lot of these problems are already solved in the Mozilla context.  With Firefox we have a whole slew of testing frameworks and tools to drive our various automated tests.  To run a lot of these, we don’t need a full browser, just a JS shell that can execute our JS code and report to stdout.  I spoke with Ted today about our issues, and he recommended modeling it on how xpcshell tests work (i.e., js + python + makefile).

The first step was to take a directory of Processing files and turn them into something I could feed into a test harness running in the jsshell.  The jsshell can run the Processing.js parser, since it’s just JS, and as long as I can feed the Processing code in, I’m good.  There’s even a handy load() function I can use to get files into the jsshell.  However, what it loads has to be valid JS and Processing code is anything but.  I needed a way to trick the jsshell into loading the Processing code in so I could get it into the parser and tested.

I chose to use python, and decided to write it such that it would scan the test dir for all the files, and turn them into JSON strings, which I could pass on the command-line to the jsshell executable (i.e, ./js -e ‘{code: “x =7;\ny=5;\n…}’), along with my test harness scripts.  I then wrote my test harness in JS, which also loads the Processing.js code (i.e., the parser), and then I basically do this:

try {
  eval(Processing(canvas, processing-code));
  _pass()
} catch (e) {
  _fail()
}

The Processing function takes a canvas element (where the graphics will get drawn), and the Processing code, and tries to parse it.  What it gives back is pure JS, so we can use eval() to try and execute it.  If that works, the generated JS is good, so our test passes; if not, we fail.  But there’s another problem: the Processing code assumes there’s a canvas element and a DOM–basically, it assumes it’s running in a web browser as part of a page.  But we’re nowhere near a web browser when this runs, so we have to fake it.

The nice thing about JS is that you can create and modify objects, data, functions, whatever on the fly.  In my case, I needed to fool the Processing.js parser into thinking that it had access to various DOM functions and objects (e.g., document, setInterval, etc.).  My solution was to create dummy functions and object literals that could stand-in for the real thing.  The parser doesn’t actually need to call this code; it just needs to be there and non-null.  Here’s my setInterval implementation:

var setInterval = function() {};

Using this trick I was able to slowly write all the bits of the fake DOM I needed to get the parser running.  As I’ve tried running a few other larger tests, I’ve noticed other bits of the DOM I need to implement, but it’s pretty trivial to add them as I go.

I’ve filed a bug and am waiting for some feedback before a I fix a few more things and get it checked-in.  Once I do, I plan to find some other students to write a ton of tests to try and break the parser even more, and then file bugs so we can fix them.  Writing tests may not be the most fun you can have, but honestly, writing a test harness is pretty close.

There’s a great post over at Mashable by San Francisco mayor, Gavin Newsom, on the city’s new open source policy.  In it he discusses the democratic, fiscal, and technical advantages of open source.  He writes:

One of the greatest technology changes of our times is the rise of open source software…Open source software is created by the people for the people and as such is ideal for government. To that goal, I am extremely proud to announce today the nation’s first open source software policy for city government.

San Francisco’s new policy requires city departments to consider open source software equally with commercial products when purchasing new software. The opportunities with open source are tremendous: lower costs, greater agility, better reliability, improved security, and increased innovation.

Under the leadership of our City CIO, Chris Vein, and the Department of Technology, we have witnessed the benefits of open source with shorter implementation times and lower costs. We have seen this with my web site, DataSF.org, RecoverySF.org and our 311 integration with Twitter.

This week I’ve been introducing our students to open source, and a lot of our discussions have focused on how open source isn’t a fringe movement anymore–individuals use it, big companies use it, and governments use it.  As government budgets continue to shrink, and fiscal responsibility becomes front page news again, open source is being discussed by an ever increasing number of people.  Developers in San Francisco have long understood the value of open source on a technical level, but it’s another thing when the mayor’s office gets in the game, too.

If you’re interested to watch this same phenomenon happening in Canada, keep one eye on David Eaves.  Hey Mayor Miller, where’s our open source policy?

I’m working with an ever growing group of web and Mozilla developers, along with some talented audiophiles, on a project to expose audio spectrum data to JavaScript from Firefox’s audio and video elements. Today we bring out the demo reel.

Last time I wrote about our success getting the browser to make dynamically generated sound.  Since then we’ve continued our work to expose and use raw audio data, and it has produced some delicious demos.  Today I finally got setup to record some of them and show a bit of what’s possible.  NOTE: I’ll provide links for all of these, but you need a patched Firefox to see things happen.

The first demo is a visualization of audio spectrum data using the C++ FFT code (the one Corban did before was done with JavaScript).  This particular song is perfect for demonstrating beat synchronization, wave changes, etc.  Al MacDonald wrote both the code and music (click here to watch video):

The second demo shows how the <video> element can be used in the same way as <audio>.  In this video of whales singing to one another, Al once again visualizes the spectrum data, but this time in 3D, and overlays it on the <video> element using <canvas> (click here to watch the video):

The third demo shows both visualization and dynamic generation of audio using JavaScript. In this demo an oscillator module generates a signal which is sent through a Low Pass filter and ADSR Envelope and then written to an <audio> element. The demo was created by Corban Brook, who also wrote the PJSAudio library especially for the task (click here to see the video):

For my part I’ve been busy thinking about how to rewrite my browser implementation so it is done properly.  In the third demo you’ll hear some static, since I’m not doing any buffering, which we need in order to deal with latency in generating the audio frames.  I’ve got a number of email threads going with people who can help me figure out the API and implementation directions.

In addition to working on code, we’ve also been chatting about the other things we might do with audio in the browser.  Here are some of the ideas that have come-up:

Audio Data and Experiencing 3D

As WebGL gets closer to being released, I’ve been thinking about accessibility within 3D scenes.  Reading this inspiring article about a blind architect, it made me think about sound in a new way.  I’ve got students right now working on light and cameras in 3D web environments, but what about sending sound in too?  What if you dynamically sent sound into a 3D scene and had it echo back to you, such that you could judge depth, objects in front of you, different materials, etc.  Doing this well requires dynamic transformations of the sound, which is exactly what this work is making possible (Corban’s demo shows the first steps).

Audio Data and Seeing Sound

Still on the subject of accessibility, I’ve been thinking about sound data, and especially the visualization of sound, for those who can’t hear it well, or at all.  One of my colleagues first got me thinking in this direction.  She can’t hear a lot of the sound her computer makes, and is often unaware that web pages are even making sound.  In cases like this, it would be great to have even simple indications that there is sound, how loud it is, etc..  Taking this further, one can imagine exploring ways to make the browser more like the Emoti-Chair or other similar devices, which bring the experience of sound to those who can’t hear it.

Audio Data and Programmatic Approaches to Music

Then there’s the possibility of making music specifically for this medium.  We (I’m thinking of people like me who can’t play instruments) tend to think of music as a consumable end-product vs. something you build or assemble.  Music is something you buy, something you download, something you play.  That’s what text used to be, too.  But putting text on the web, and specifically, assembling text using code, changed that forever.  Just as we mix text from different sources, dynamically overlay it, transform it, translate it, etc., what if you could listen to music being mixed and altered live in your browser?  What if music was one part drum loops and one part repeating sample and both were written in JavaScript?  What if those got layered over audio being played from an .ogg file, or got mixed into something happening in a video?  What if the music was changed in response to what you were doing in the page?  When music becomes algorithmic, scriptable, and composable, any number of new things will happen.

This portion of our experiments has really been about imagining what you might do with something new.  The browser hasn’t traditionally been the place where sound gets made.  But what if it was?  How would music adapt to its new surroundings?  What would we expect of it?

I’ll leave you with a quotation from a recent interview with Brian Eno, as he talks about the synthesizer, and innovation in music and sound.  When he says ’synthesiser’, replace it with ‘browser’ in your mind, and think about it for a moment:

One of the important things about the synthesiser was that it came without any baggage. A piano comes with a whole history of music. There are all sorts of cultural conventions built into traditional instruments that tell you where and when that instrument comes from. When you play an instrument that does not have any such historical background you are designing sound basically. You’re designing a new instrument. That’s what a synthesiser is essentially. It’s a constantly unfinished instrument. You finish it when you tweak it, and play around with it, and decide how to use it. You can combine a number of cultural references into one new thing.

I’m working with a group of web and Mozilla developers, along with some talented audiophiles, on a project to expose audio spectrum data to JavaScript from Firefox’s audio and video elements. Today we teach the browser how to sing.

Our experiments to expose audio data to JavaScript have really started to get exciting.  Since I last posted, a number of new features and demos have been created, and our group of developers has continued to expand.  This was greatly helped by the fact that the story was picked up by Ajaxian, Hacker News, and Reddit.  If you’d like to help us experiment more, please get in touch.

Previously I linked to a video of a demo made by Corban Brook, in which he uses JavaScript to calculate an FFT, and then visualizes the resulting spectrum data.  After this test we wanted to see how expensive these calculations were in script, so I ported his code to C++ and stuck it into the audio element’s decode loop.  A number of people have expressed concern over the idea of doing this in JavaScript and the cost in terms of speed and time you could spend on other work (e.g., complex real-time graphics).  Therefore, I wanted to have a good way to compare speeds.  I’ve already received feedback in the bug that native FFT calculations probably aren’t warranted, and we should optimize the JavaScript case.  I anticipated this, and having been involved with as much 3D in the browser as we have, I know that JavaScript is up to the challenge of doing very fast calculations.  As soon as I convert over to the faster WebGL arrays I’ll do some tests comparing JS-FFT and Native-FFT so we have better numbers.  In the mean time, the C++ FFT is working really well, and a number of new visualizations have been done with it, including this one by Thomas Saunders.

Another thing we’ve got working is generating and writing audio directly from JavaScript.  So far in these experiments, I’ve been focused on creating a real-time event with raw audio data.  I did this in response to the various Flash and other audio developers who have all told me they need some way to get data as it’s being played.  Now that this is working well, I decided to turn my attention to what Vlad suggested in the bug, namely doing a get/set style method.

I’ve been stumped on the right way to do this for a while.  Actually adding the method is pretty easy.  What I’ve been trying to think through is how you deal with the linearity of audio, and the fact that unlike a canvas (which also lets you do a get/set) the audio data isn’t necessarily there to get (e.g., it is yet to be downloaded/decoded).  I’m sure there are good solutions to these problems, but they’ve eluded me thus far.

I ended-up chatting about it with Rob Campbell and Ted Mielczarek, and together we hatched a plan: what if, for the sake of experimenting, you just added a “write” method, and let JavaScript dump raw audio?  Imagine an <audio> element with no source, totally controlled by JavaScript.  Since I already have an event that gives data as it’s decoded, it would then be possible to have one audio element decode, get the data and transform it somehow in script, then dump it into a second audio.  Is this the right way?  Probably not (the implementation is completely wrong no matter what).  But it was simple enough to do a Friday-afternoon-evil-hack and write a patch.  So I did.

I added two new methods to audio/video:

• mozSetup(channels, rate, volume) // called to create the audio stream
• mozWriteAudio(buffer[], bufferCount) // called to write buffer to the stream

Ted then wrote a simple Tone Generator, and Al MacDonald took that and wrote what I believe to be the first ever HTML document that can play scales using nothing but JavaScript (seriously, check out the source for yourself)!  Here’s a video of it in action:

Next time I hope to show some other demos that my colleagues have created or are creating now.  It is ridiculously fun to iterate on this stuff.  That’s partly due to the fact that I’ve got such a talented group of people working with me.  But it’s also due to how “hackable” this code is to begin with.  The fact that we can go from a back-of-the-napkin idea and then turn that into a working (if somewhat evil) patch in a couple of hours speaks to how well this stuff was written in the first place.  There’s a good discussion going right now about View Source, and how important it is.  What we’re doing in these experiments is View Source all the way down: we work in terms of HTML5 and the Open Web, but underneath is this amazing browser and platform, and underneath that the audio lib, etc.  The only thing that enables this kind of experimentation and collaboration is the existence of View Source, and the kinds of communities that can form around it.

For the past month I’ve been working with some audiophile friends on a project to try and expose audio spectrum data to JavaScript from Firefox’s audio element.  Today I finally have something more than raw numbers to show off.

When I last wrote about our experiments with the <audio> element in part V, I had successfully written a patch to add a new DOM event (onAudioWritten), which is dispatched every time a frame of audio is decoded (this works for <audio> and <video>).  I make this raw data available via a list type object called MozAudioData, which exposes .length and .item() for accessing the data in script (I’m hoping to move to the new WebGL arrays as soon as Vlad lands them).  As I finished up for holidays, I made a very crude but promising demo that proved things were working:

, second test by humphd, on Flickr">, second test by humphd, on Flickr" href="http://www.flickr.com/photos/11280278@N04/4195120423/sizes/o/">, second test" />, second test" width="500" height="301" />

Now it was clear that the data could be had, but we wondered whether it was possible to consume it fast enough in js.  Corban Brook decided to try, and wrote a Cooley-Tukey FFT algorithm in JavaScript to work with the raw data in real time.  He then wrote a very cool visualization in Processing.js, and the end product is nothing short of amazing (you have to see this video demo of it running on Vimeo to get the full effect):

hack. Click for video" /> hack. Click for video" />

I want to do some more work to see what moving the FFT into C++ would mean in terms of performance.  Having the ability to do even more complex analysis or visualization (imagine real time speech-to-text coming out of <video>) in script is our goal.  I’m also starting to wonder about how best to add write capabilities to go with this read-only version.  Imagine being able to do equalizing, filtering, etc. on the audio from script.  I have no idea how to tackle this yet.

It’s been fun working with these guys who know so much about audio.  I know almost nothing about the data I’m extracting, and it’s humbling to learn from them.  We’re approaching the point where input on API design would be useful, as I get this patch in better shape for review.  If you’d like to get involved or try it out yourself, drop into irc.mozilla.org/processing.js, where we are working, and join the discussion in the bug.  I’ll continue to blog this series about our work, and I know the others are working on posts and more demos, too.

I’m working on a project to try and expose audio spectrum data from Firefox’s audio element.  Today I ponder arrays and fix some things.

Today is my last day of work before the Christmas break begins, and I just submitted my final grades.  This gave me a little bit of time to rewrite some of my code in order to fix a few things.  Here’s my latest demo:

, second test by humphd, on Flickr">, second test by humphd, on Flickr" href="http://www.flickr.com/photos/11280278@N04/4195120423/sizes/o/">, second test" />, second test" width="500" height="301" />

After talking with some more people who work with audio, I realized that I’d be better off giving floats vs. integers for the data.  In this demo you can see both my code, which uses event.mozAudioData, and the output in Firebug.  I’m pretty happy with our progress to date.  Twelve days isn’t bad to go from clueless to slightly-less clueless and with a working patch.  I want to draw attention to this, because a large part of why I’m doing this is to inspire my students and others to take risks and work on things that scare them.  You hold yourself back if you don’t.  I don’t know what I’m doing most of the time, I just keep at it until I do.  There’s no reason you can’t, too.

Anyway, this is looking good, but I’m far from done.  What I spent the most time on with this iteration was getting my arrays working properly.  I’ve been doing a lot of reading in our code, looking for ways to expose pure arrays in content (e.g., in the DOM).  In the comments of my last blog post, a few suggestions where given, and in the bug another was mentioned.  Here are the ways I’ve come-up with (there might be others):

1. Create a DOM class that wraps your array and provides getter/length semantics (that’s what I’ve done for now).  See nsIDOMClientRectList.
2. Use an nsIVariant type, and let XPConnect coerce the type for you.  See nsAnnotationService::GetPageAnnotationNames.
3. Go around IDL altogether and grab raw JS values.  See nsCanvasRenderingContext2D::GetImageData.
4. Use the (currently not landed) WebGL Array (Vlad recommends I move to this, so I’ll explore that in subsequent work).

Now that I have it running, I’m starting to think about performance vs. just getting it to work.  A lot of questions I am getting relate to doing Fourier Transform in JS vs. navtive code.  I’ve been around Mozilla long enough to know that the first answer to questions like this isn’t to drop into C/C++.  Maybe it won’t be possible in JS; but I need to have that proven before I’ll make that conclusion.  I’m also concerned that my time-based events for exposing the data are going to be problematic.  I really wonder about keeping up with the timing of the audio as it’s played.  A lot of people I talk to are excited about doing precise visualizations that are timed to music.  I know my current code can improve a lot here, so it’s too early to assess whether this will be possible.

I’m not sure when I’ll post my next part of this series.  I am going to celebrate this success with some much needed holiday time.  Rest assured, though, that I’ll be back at it again soon.

I’m working on a project to try and expose audio spectrum data from Firefox’s audio element.  Today I get raw data into the browser.

This blog post was going to be very different than the one you see now.  That’s because our DOM code kicked my ass all day yesterday and into the night.  I stopped coding when my eyes stopped working.  And the result was very much, “…so close, what is causing this error!!!!!????”  But then this morning, through the power of irc debugging, the answer came!  Let me show you a picture before I go on:

Previously I wrote about my idea to add a new method to the audio element, which you’d call whenever the onaudiowritten event occurred.  I thought a lot about this and couldn’t figure out how I was going to deal with the synchronization issues: the decoding (and raw data) is produced on a separate thread, and I need to expose it without blocking on the main thread.  I decided to get some advice and went to speak with Chris Jones, who is one of the people working on Electrolysis, Mozilla’s project to rewrite Firefox with a multi-process architecture.  Chris knows a lot about threading and synchronization, and he confirmed what I suspected–I should make this data available as a parameter of the event vs. adding another function call and trying to deal with the locking semantics.

I was hoping to avoid this.  The very first thing I ever did with Firefox, back in 2005, was to work with some students to add a new event with data to the DOM.  And it was hard.  Very hard.  But dealing with thread issues is hard too, so I dug in and went to work.  Luckily for me all these years later, there are a lot more examples in the code I can follow.  The MozAfterPaint event is pretty close to what I need to do: an event that contains a list of data.  So I spent much of the day studying the code that implements it, and it’s a wild ride.

Eventually I was able to add nsIDOMNotifyAudioWrittenEvent and nsIDOMAudioData, with implementations.  The way this code works now is this:

<script>
function audioWritten(event) {
  for (var i = 0; i < event.mozAudioData.length; i++)
    console.log(event.mozAudioData.item(i));
}
</script>
<audio src="song.ogg" onaudiowritten="audioWritten(event);"></audio>

As the audio is decoded, this event fires for every “frame” and you get an object with the event named mozAudioData. This contains all the raw audio data, basically a list of numbers like I discussed here. You can iterate through them using .item(n) and .length. Simple, right? Well, I can tell you it wasn’t simple to implement!

Last night I had all the code in place, but when I quit I was staring at an assertion being caused by my code:

###!!! ASSERTION: hmm? CanCallNow failed in XPCWrappedNative::CallMethod. We are finding out about this late!: ‘rv
== NS_ERROR_XPC_SECURITY_MANAGER_VETO’, file /Users/dave/moz/mozilla-central/src/js/src/xpconnect/src/xpcwrappednative.cpp, line 2206

I knew I must be doing something wrong with my nsIDOMAudioData class, since the event was working, and is very similar in terms of the plumbing it needs to get dispatched to the DOM.  This morning, feeling thoroughly stuck, I went in search of Olli Petty (smaug on irc), who knows this code really well:

09:28 < smaug> AudioData isn’t an event
09:28  * smaug is surprised that even compiles

Me too!  In my sleep deprived state last night I’d copy-pasted my nsDOMClassInfo code for the event and reused it for nsIDOMAudioData without removing the line that makes it an event.  After deleting that line it works!

My patch is getting a lot bigger, but it needs more yet–I don’t even want to think about what they’ll ask me to change as I move to getting it reviewed.  But that’s trouble for another day.  Today I’m thrilled to have gotten this data exposed to script and lived to tell the tale.  In part V I’ll try to get this into a state others can use, and then set my audiophile partners loose on doing something cool with the data.

I’m working on a project to try and expose audio spectrum data from Firefox’s audio element.  Today I add a new event to the audio element.

Last time I wrote that “I’m going to have to get this wrong before I get it right.”  So here goes some “wrong that feels right.”  Having located the proper audio data, I’m up against the problem of how to get it exposed to content (i.e., script running in a web page).  We’ve been starting to talk more about how to structure the API, but I’m a ways off from needing those decisions made.  Since my last experiment I’ve been realizing that we’re going to need a notification so as to let scripts know that audio data is available.

Today’s experiment was to add a new DOM event to the audio element, such that web developers could be notified whenever raw audio data was available.  Since it comes in a “frame” at a time out of the decoder, we get the song or “sound” in chunks as it is played.  Here’s how you use what I’ve done today:

<audio src=”somesong.ogg” onaudiowritten=”doSomething();”>

At the moment, there isn’t much you can do in doSomething(), since I haven’t exposed the data with the event.  Instead what I’m planning to do is add a method named mozGetAudioData(), which you’ll call whenever onaudiowritten occurs.

Adding a new DOM event is accomplished by carefully studying how other events are implemented  The audio element has a bunch of events, for example onloadedmetadata.  I had to make a dozen or so changes to the following files (look for the string loadedmetadata as an example in these files):

• widget/public/nsGUIEvent.h
• content/base/src/nsContentUtils.cpp
• content/base/src/nsGkAtomList.h
• content/events/src/nsDOMEvent.h
• content/events/src/nsDOMEvent.cpp
• content/html/content/public/nsHTMLMediaElement.h
• content/html/content/src/nsHTMLMediaElement.cpp
• content/media/ogg/nsOggDecoder.cpp
• content/media/ogg/nsOggDecoder.h

The only tricky part was marshaling the call from the decoder thread over to the main thread, so the DOM event could be safely dispatched.  I’ve put the patch up here if you want to look at it.  WARNING: I’m just experimenting, and I wouldn’t look at this code for anything other than curiosity.  This hasn’t been reviewed, and shouldn’t be mistaken for the right way to do this.  This is just me learning out loud, as it were.

In part IV I hope to get the decoded frame data exposed via a new method on the audio element.

I’m working on a project to try and expose audio spectrum data from Firefox’s audio element.  Today I give an update on yesterday’s progress, since there are pretty pictures, and then ask some questions.

Yesterday I wrote about our first steps to find and extract audio spectrum data from the <audio> element.  At the end of my post I wondered aloud whether or not the numbers I’d produced were meaningful.

After that post I spent some time working with Al MacDonald and Thomas Saunders–my partners in these experiments–and a number of interesting things happened.  First, what were simply numbers to me proved to be meaningful to them, and after helping them build Firefox with my changes, they started playing with the data.  Al made a simple audio test case, and Thomas worked the data into a JavaScript friendly form.  Next Al took the audio and analyzed the wave form in Audacity, before creating a real-time canvas visualization of the data we’d extracted from the browser.  The results speak for themselves.

Having an early success is encouraging, but like one of my students is fond of saying, success brings you to your next problem.  Knowing that this data is meaningful means I now need to figure out the right way to expose it in the DOM.  When I get this data I’m deep in C++, nowhere near JS running in the browser.  What I need is a proper API for making this data available.

My choice of words is important: “right way,” “proper API.”  I could (and probably will for my next test) just drop-kick the data across the the content boundary.  But what’s the right way to do this?  I did some investigations into our implementation of DOM events last night.  I was thinking that maybe I should pass the data out within a custom DOM event.  However, I don’t see any events that use this model.  There doesn’t seem to be much data pushed with the event.  Another option is to dispatch an event and then fill a buffer that can be read via a getAudioData() call.  But even when I get this working (if this is the right thing to do), I’ll next have to worry about how to make that data meaningful in terms of sync with the actual audio that the user is hearing.  A little bit out of sync is almost as bad as being totally random, especially if you’re trying to time visualizations or other UI updates to sound.

So I’m convinced we’re on track, and also feeling a bit lost.  I know that “the perfect is the enemy of the good,” so I won’t halt my work until I can settle all these questions.  It’s clear to me that I’m going to have to get this wrong before I get it right.  But I’d value some input from those closer to our DOM implementation and the JS community on which paths to explore.  Thankfully, Chris Blizzard has started that ball rolling by introducing us to some more people.  The most enjoyable part of experiments like these for me is the chance to work in community.

I’m working on a project to try and expose audio spectrum data from Firefox’s audio element.  Today I document some of my background research and initial first steps at locating this data.

The <audio> element is part of the html5 spec, and you can already use it in Firefox 3.5 and above.  Here’s a page that uses it, for example.  If we go spelunking through the Firefox code, we can see that <audio>, and the bits needed for these experiments, are spread across a number of files.

First, and perhaps least interesting, is the IDL definition of nsIDOMHTMLAudioElement, which inherits everything from nsIDOMHTMLMediaElement (note: if you are unfamiliar with IDL, and Mozilla’s use of it, I’ve written about how we use it here).  This tells us the sorts of things one can do with an audio element, which attributes or functions it has.  One important thing to note, for purposes of this experiment, is the presence of Mozilla-specific additions to this list, namely,  mozAutoPlayEnabled and mozLoadFrom.  Similar to Mozilla’s CSS additions, which are named -moz*, we’ll have to name our additional features for audio with a moz* prefix.

Next we see the actual implementation of the nsIDOMHTMLAudioElement interface in nsHTMLAudioElement.cpp.  Here are the aspects of the audio element relating to “content” or the DOM.  Just as with the IDL, most of the functionality we care about is really in the nsHTMLMediaElement.cpp instead (e.g., here is the code for mozAutoPlayEnabled).

Reading through this code, I’m interested to find some sort of connection to the underlying sound device, and the location where spectrum data is dealt with.  I notice numerous references to objects of type nsMediaStream, which sounds interesting.  This directs my attention to the content/media/ directory, and I notice nsAudioStream.cpp, which includes a Write method.

I decide to try adding some debugging info and see what the data being written down to the audio handle looks like.  The code seems to imply that I’m in the right spot, as data is being written down to the audio stream in a series of shorts.  Using the same audio test page I linked to above, I run my modified build, and here is what I see:

[43 43 -1063 -1063 -70 -70 1350 1350 658 658 -414 -414 -476 -476 -1631 -1631 -3145 -3145 -2758 -2758 -1988 -1988 -2282 -2282 -2488 -2488 -2204 -2204 -2371 -2371 -1514 -1514 -230 -230 243 243 1950 1950 2835 2835 2398 2398 3106 3106 3970 3970 3281 3281 1736 1736 992 992 1482 1482 2162 2162 1552 1552 681 681 -69 -69 -835 -835 -1182 -1182 -884 -884 267 267 703 703 140 140 -187 -187 238 238 86 86 -724 -724 -1004 -1004 -683 -683 226 226 412 412 -366 -366 -2132 -2132 -3578 -3578 -3118 -3118 -2473 -2473 -1405 -1405 -1053 -1053 -2695 -2695 -3086 -3086 -2081 -2081 -1906 -1906 -1992 -1992 -2153 -2153 -2688 -2688 -2127 -2127 -1160 -1160 -409 -409 718 718 676 676 248 248 553 553 275 275 -105 -105 327 327 586 586 1110 1110 2734 2734 3373 3373 1627 1627 673 673 1353 1353 944 944 1712 1712 3272 3272 2751 2751 1092 1092 -116 -116 223 223 275 275 -1367 -1367 -2829 -2829 -837 -837 1115 1115 -401 -401 -437 -437 ...]

Looks just like the song sounds, doesn’t it?  I have no idea, but I’ve sent my patch and the data off to my audiophile colleagues for analysis.  Maybe we’re on the right track, maybe I’m just pulling numbers out of the air.  At any rate, I’m learning more about this code.  Next time I hope to do a bit of work to get this data exposed in a more usable way (right not it’s just a console dump).  That will likely be the subject of part III.

This post marks the beginning of what I expect to be a somewhat regular series of posts in which I will document my thinking, learning, and progress related to some Firefox development.  I say “Experiments” above, because I am going to try a number of things.  First, I’m going to push into a part of the Firefox source code where I haven’t worked before, namely, the DOM implementation (note: it scares me, to be honest).  Second, I’m going to do so in an open and pedagogic way, attempting to cast aside my own ego and hesitation at looking foolish–I don’t actually know how to do what I’m going to try, and will learn and fail as I go–on the way to producing an authentic model of open development for my students.  Third, I’m going to work with a few others who are also interested in extending themselves and extending the web.  The only thing I can assure you of at this early date is that these posts will be an honest account of the attempt.

First, I should say something about <audio> and what we’re planning to do with it.  The <audio> element is part of HTML5, and allows web developers to embed audio, music, sound effects, etc. directly in a web page.  This same ability has been achieved in the past through the use of Flash.  The <audio> element, like the <video> element, is still in flux and presents an excellent target for experimentation and play while the spec continues to wend its way toward completion.

I don’t know anything about audio or have any need for <audio> personally.  However, I have spent the fall working with creative designers, visualizers, and developers as part of the Processing for the Web project.  It has opened my eyes to what the browser and web might become, if these people are given the right tools.  And while I can’t do anything more with audio than press ‘play’ (I struggle to get this to work sometimes, too), I can bring my knowledge of Mozilla, its code, and the web to this effort.  So my role in these experiments will be to help get things working in Firefox, and to help my partners (who do understand and need audio and <audio>) understand how to do this work.

Thomas has written a nice post about why the web needs more data exposed from <audio>.  He has also created an interesting demo, which uses Processing.js, JavaScript, and Flash, and shows what we should be able to do with pure html5 and JavaScript.  His demo is a visualization of the audio’s left and right channels, getting data about the underlying sound wave.

Our goal is to make the same sorts of interactions with audio possible, but not rely on Flash.  This will mean making it possible for web pages to get at more data within the <audio> element from JavaScript, and therefore that we have to expose more data within the underlying implementation.  The way you get something like this done is to file a bug.  Thomas filed this bug, which we later discovered was a duplicate of an older bug.  This practice is common, and helps to keep discussions focused in one place.  After closing the first bug, we’ve moved to the second.  If you want to follow along from home, you can make an account on Mozilla’s bugzilla, and then CC yourself to this bug.

In my next posts I’ll show some of the work I’m doing to understand the process of exposing more data to content.  We have some existing DOM elements (e.g., canvas) that do similar things now, so that’s where much of my reading is currently taking place.

Yesterday I spent the day attending day 1 of FUDCon Toronto 2009.  It was my first time attending a FUDCon, and I found it an interesting experience all around.  I was especially pleased to be able to attend one being held at Seneca, due to the hard work of my colleague, Chris Tyler.

I have attended and organized many open source events in the past, and I was most interested to observe Chris’ community, in order to see what they do differently.  FUDCon is a conference for Fedora Users and Developers, and while I tend to think of myself primarily as a developer, in the Fedora context I’m mainly a user.  As such, it was nice to be able to attend such a gathering and not feel like I was in the wrong place: so many developer related events are dismissive (or hostile) to non-developers.  This point was re-iterated by my colleague, Peter Liu, as we chatted outside one of the sessions.  He observed that this community was very friendly and welcoming.  I expressed a similar feeling, while also noticing that the two of us where standing under a giant Fedora poster with the word ‘Friends’ taking up the lower third.

The conference was organized using the Bar Camp style.  I have never been a fan of Bar Camps, as I think they tend to lead to unpreparedness or disappointment in having prepared and not having your talk chosen.  I also find them unnecessarily chaotic–something that appeals to some people, but turns me off.  FUDCon confirmed many of my feelings about Bar Camps.  We lost nearly half a day getting all the talks pitched (half of the ~200 attendees wanted to give at least one talk) and many of the talks were rejected.  Having been a conference organizer many times in the past, I do think it’s nice to spread the work of finding and scheduling talks across the community; but why not do it online in advance of the event and set the schedule so as to avoid wasting time on the day?

Once the chaos was over and the talk schedule taped to the wall, the day got rolling.  I attended a number of talks that were quite good (all of which had been well prepared in advance, with lots of demos).  The first was a group talk led by Andrew Overholt on the Eclipse Linux Tools and CDT projects.  Prior to the talk, Fardad and I had been discussing the difficulty his students have in doing cross platform C++ development, since they have become so dependent on Visual Studio.  “What I really need is an equivalent for Visual Studio on Linux and Mac.”  I told him he needed to attend this talk, and I was right.  The talk demonstrated doing C++ development using visual tools for things like gdb, oprofile, valgrind, etc.  They made a very convincing argument for moving our students to Eclipse for both Java and C++ development.

Another talk I really enjoyed was Sami Wagiaalla’s on the new features they’ve added to gdb.  Despite the bad rap it gets, I have really come to like gdb.  I use it for all my Mozilla development on Linux and Mac, and appreciate the fact that I don’t need to learn a new tool moving between the two platforms.  The ‘interface,’ while spartan (disclaimer: I love the command line), is not hard if you’re willing to invest a few hours learning some basics.  Sami demonstrated a lot of new C++ features in gdb from the Archer project.  The thread debugging and gdb python pretty-printers were perhaps my favourite.  It made me wonder if there would be value using Dehydra to auto-generate pretty-printers for complex types in Mozilla.

I also gave a talk on Mozilla Tools, and presented Dehydra, Treehydra, JSHydra, Pork, and DXR.  I wanted to make the case to the Fedora/Linux/Eclipse communities that these tools can and should become a part of the way we work.  For example, during the Eclipse talk I was interested to learn how they currently collect auto-complete information for C++.  Using Dehydra it would be possible to do this in a much more accurate way.  During the talk I was also able to demonstrate some ways in which Mozilla has done automatic rewrites, including Ehren’s work to optimize away functions that always return zero.  Chris also joined me in the presentation, and gave some ideas for Fedora-specific uses of these tools, for example a Fedora-wide DXR.

Half-way through the day, Fedora’s project leader, Paul Frields, stopped me in the hall to see how my experience had been so far: “Are you enjoying yourself?”  I could honestly answer in the affirmative.  I think that it’s interesting to see the attention of the project’s leader being focused on the experience of the attendees.  It says a lot about him, and a lot about the culture of this community.  A big thanks to Chris Tyler and others for making this event possible.  I’m looking forward to attending some more of it on Monday.

Yesterday on our Mozilla Education call, I was giving a quick update about what’s happening with the work on the Processing for the Web project, which I introduced here.  A lot has happened since then, but we’ve waited to talk about it so as to give the students time to find their way.

Since my last post the students have managed to pick-up 60 of the outstanding issues, a third of which went in today.  Another batch of fixes are currently being reviewed (including the first support for Processing’s 3D functions on top of WebGL) and the last batch for 2009 are due in a little over a week.  After the Christmas break, we get started again, and I anticipate the entire port will be done by late winter or early spring (there are another 60 tickets to get done).

Up until this past week, the majority of the work was done by a group of 9 students in my class at Seneca, Al MacDonald, and myself.  However, lately we’ve seen a doubling of the community, as a whole bunch of talented developers and data visualizers has shown up looking to get involved.  They’ve been fixing code, filing bugs, and creating amazing demos.  In addition, Didier Coutard’s students arrived on the scene this week–his students are also working on Mozilla projects in France.  The influx of new people and energy is making an already great project even better, and it’s amazing to be a part of it all.  It’s also amazing to see some of the cool demos and applications being built by this community with processing.js and html5, for example:

• Askken visual search engine
• Multi-touch demo
• Crayon Physics demo
• Motion Tweening demos

Just wait until the rest of the Processing language is there!  Every little bit of work that gets done makes more and more existing Processing work “just work” on the web, which is a big motivator.

I’ve been really pleased with the work thus far, and with how amenable Firefox, Canvas, and JavaScript have been to the task of porting Processing to the web–John Resig deserves a lot of credit for having the vision to see that this was possible and doing the initial heavy lifting.  One of the best ways for students to learn how to write good code is to read the code of good developers, and you couldn’t hope for a better model than John for JavaScript.

I’ve also been blown away with the work and dedication of Al MacDonald (f1lt3r on irc) on this project.  It has brought to life something that I’ve read Mark and Mitchell blogging about in the context of Mozilla Drumbeat.  As Mitchell says, the goal of Mozilla Drumbeat is to:

find, energize and build a Mozilla community of people who are — or want to be — working with technology to build participation, understanding and control into Internet life.

Mission accomplished.  Sometimes its easier to understand things when you have concrete examples, and Al is the best example I’ve seen yet of what Drumbeat is all about.  As an independent web developer, he needs to put as much time as he can into finding and finishing work for clients.  However, he also knows that innovating on top of the open web means that his work is easier in the long run.  And so he pours a lot of time into helping me manage these students, reviewing code, answering questions, guiding the community, etc.  It’s a non-trivial investment of time, but it’s paying off in spades, and has the potential to completely change the web and how we build graphical content.  You need vision and commitment to stay on that path, and that’s what I see in Al.

If you’re interested in finding out more about this work, or want to get involved, I’d encourage you to:

• visit the main Processing.js page and Mozilla’s Processing for the Web page
• join us on irc in the processing.js channel
• get involved in the bug tracker, helping triage, manage milestones, etc.
• help us finish remaining issues, fix bugs, write tests
• test, port, and create Processing content on the web.  This is the time to see what works and what doesn’t, what’s fast, what’s buggy, and report it

Processing.js began as one-man project and has grown into an energized community.  It’s still growing, and there’s room yet for you.

Chris Tyler’s SBR600 student, Boris Chao, is the kind of fearless student I love.  A week ago we approached him to see if he’d be interested to work on doing a backport of the new plugin code in GCC 4.5 to GCC 4.4.  Without really knowing what he was in for, he said yes, and started working.  As he’s gone along he’s hit some bumps, and in every case used those as catalysts for learning new things.  What he’s doing isn’t really obvious or easy, but it’s also not hard–it’s just a bunch of tools and processes that are new to most students, and many developers.

I was all set to write a post today about backporting, svn diff, patch, etc. and then I see that he’s beat me to it!  However, I thought I’d add a bit more to what he’s started and talk about how one deals with patches that don’t go in cleanly.

First, a brief word about patches.  Patches are text files that describe differences between two versions of a file or set of files.  They are typically created with some form of the diff command, either using the stand-alone diff command or via your revision control system (e.g., svn diff, hg diff, …).  Patches are designed to make it possible for me to do work locally, and share my changes with others (i.e, on a mailing list or in a bug) without having to send them everything I did.  A patch is then applied using the patch command, hence the name.  So when people talk about ‘diffs’ and ‘patches,’ they mean the same thing.

I happen to be looking at a patch right now for another bug I’m following, so let’s use that as an example.  In this patch (which was created using the hg diff command), you can see a few things.  First, you can see that there are two hunks.  A hunk is a change to a part of a file, and a patch can contain many of them.  Here’s the first hunk:

diff -r d76583175408 accessible/src/atk/nsAccessibleWrap.cpp
--- a/accessible/src/atk/nsAccessibleWrap.cpp	Wed Nov 25 02:40:46 2009 -0500
+++ b/accessible/src/atk/nsAccessibleWrap.cpp	Thu Nov 26 16:58:34 2009 -0500
@@ -342,16 +342,24 @@ void nsAccessibleWrap::SetMaiHyperlink(M
         if (maiHyperlink) {
             delete maiHyperlink;
         }
         g_object_set_qdata(G_OBJECT(mAtkObject), quark_mai_hyperlink,
                            aMaiHyperlink);
     }
 }

+const char *
+nsAccessibleWrap::ReturnString(nsAString &aString)
+{
+  static nsCString returnedString;
+  returnedString = NS_ConvertUTF16toUTF8(aString);
+  return returnedString.get();
+}
+
 NS_IMETHODIMP nsAccessibleWrap::GetNativeInterface(void **aOutAccessible)
 {
     *aOutAccessible = nsnull;

     if (!mAtkObject) {
         if (!mWeakShell || !nsAccUtils::IsEmbeddedObject(this)) {
             // We don't create ATK objects for node which has been shutdown, or
             // nsIAccessible plain text leaves

You can see that this hunk relates to the file, accessible/src/atk/nsAccessibleWrap.cpp.  Next, you can see that, in particular, it deals with the following section (or range) of code:

@@ -342,16 +342,24 @@ void nsAccessibleWrap::SetMaiHyperlink(M

The @@ -342,16 +342,24 @@ is the chunk’s range information.  This says that in the original file, this chunk begins at line 342, and goes for 16 lines.  In the patched version of the file (i.e., after applying these changes), it is line 342 and goes for 24 lines.  These two ranges are needed so that multiple hunks to the same file can take into account proper offsets from applying previous changes.

The hunk above takes code from line 342 to 358 (342 + 16) and shows it for context.  Patches always have some amount of context (Mozilla uses 8 lines as a default, some projects use 3).  The more context you have, the easier it is to figure out where this change should go.  This hunk then specifies that  8 new lines need to get inserted, and indicates them with a + sign.  There are three characters that can begin a line in a hunk:

1. [space] this is a line of context (nothing will be changed)
2. + this is a line that needs to be inserted
3. - this is a line that needs to be removed.

Now, take a look at the second hunk in this patch:

@@ -106,21 +106,19 @@ public:
     static AtkObject * GetAtkObject(nsIAccessible * acc);

     PRBool IsValidObject();

     // get/set the MaiHyperlink object for this nsAccessibleWrap
     MaiHyperlink* GetMaiHyperlink(PRBool aCreate = PR_TRUE);
     void SetMaiHyperlink(MaiHyperlink* aMaiHyperlink);

-    static const char * ReturnString(nsAString &aString) {
-      static nsCString returnedString;
-      returnedString = NS_ConvertUTF16toUTF8(aString);
-      return returnedString.get();
-    }
+    // member function cannot be inline due to a known bug in GCC 4.5
+    // see http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42171 for details
+    static const char * ReturnString(nsAString &aString);

 protected:
     virtual nsresult FirePlatformEvent(nsIAccessibleEvent *aEvent);

     nsresult FireAtkStateChangeEvent(nsIAccessibleEvent *aEvent,
                                      AtkObject *aObject);
     nsresult FireAtkTextChangedEvent(nsIAccessibleEvent *aEvent,
                                      AtkObject *aObject);

Here you can see 5 lines being removed, and 3 new lines being added in their place.  This is what an edit looks like in a patch.

This patch is pretty easy to understand once you know the format of a diff file: take this file, find this line, add these lines, remove these lines.  But, it’s not so simple.  When you apply this patch (you’d do it like this: patch -p1 < patchfile), here is what patch will try and do (from the patch MAN page):

For each hunk, the patch utility begins to search for the place to apply the patch at the line number at the beginning of the hunk, plus or minus any offset used in applying the previous hunk. If lines matching the hunk context are not found, patch scans both forwards and backwards at least 1000 bytes for a set of lines that match the hunk context.

If no such place is found and it is a context difference, then another scan will take place, ignoring the first and last line of context. If that fails, the first two and last two lines of context will be ignored and another scan will be made. Implementations may search more extensively for installation locations.

If no location can be found, the patch utility will append the hunk to the reject file.

Now we’re to the part I wanted to write about.  In Boris’ post, he shows output from applying a patch and having hunks fail.  This happens when patch can’t locate the place to make your change, or can locate it but it differs so much so that it can’t decide what to do.  Patches that don’t apply cleanly are said to have “bit rotted,” meaning that the version you made your patch against is now old, and new changes to the file keep it from applying cleanly.  When this happens, you end-up with a file named original-file.rej.

The reject file is a list of all hunks that failed to apply for this file.  As such, it is simply a patch.  The thing to do with a failed patch is to open the file you’re trying to patch along with the .rej file, and see what’s going on.  The hunk will tell you the context for the change, plus which lines need to change.  What you need to do is look at those changes, find the right spot in this file, and make them manually.  You might also decide to ignore them.  Whatever you do, once you’ve addressed all the failed hunks in your file, you can delete the .rej file.

This process seems intimidating at first, but is really not that complicated.  There are also tools to help with this (e.g., some editors understand diff/patch, and graphical 3-way merge tools will save you much hair pulling).  More than anything, it’s just a bit of surgery to carefully remove and add lines of code.  Don’t be afraid of it, just take your time.

The paradox of the web is that one must write the thing for which you search.  I am repeatedly confronted with this in my work, and it is part of why I blog technical information: I know I will want to search for it later.  And, in knowing that I will want to search for it, I know that it is being sought by others.  Another way of saying this is that the web is what we write.

I was reminded of this today while speaking with a student that is working on an interesting project related to Firefox.  He was feeling somewhat frustrated about the lack of content on the web related to his work.  After a 30 minute discussion on irc, in which he met two Mozilla developers who took him through a large part of the solution to his problem, he felt content to move forward.  So I asked him, “are you going to blog what you just learned?”  His response was less than I’d hoped for: “I’ll have to see if I’m allowed to do that.”  I’m not sure I ever fully succeed in showing him that the only way information gets onto the web is if someone writes it.  The fact that there is no one writing what you need, yet there are people telling you what you want to know, that’s enough to close the loop.  The only step left is to transcribe what you learned.

When you do a search, and it comes back with no results, it’s a sign that you need to write something.

There’s an interesting paradox in teaching programming.  We (and by we I mean ‘they’) love to teach our students to use comments in code.  We (’they’) deduct marks if they are missing, return work that isn’t fully commented, etc.  But!  I’m going to go on record as saying that comments are evil.  The reason that students are told that comments are good and have no down side is because 99.999% of programming done by students involves code that will never never have to be maintained.  I only teach using old, large code that we have to maintain and evolve.  And in the context of evolving code vs. the one-off, you don’t want to see a lot of comments.

My in-laws just replaced a really beautiful wooden railing around their porch with one made of aluminum.  Despite ten years of painting and repainting, the wood had rotted.  Comments are evil because, like the wood trim you loved when you originally built the house, they have to be carefully maintained separate from the things they surround.

I was just talking with a student on irc about a piece of code he’s porting.  He was stuck on the right answer because he had decided to read the comments instead of the code itself.  If you ignore the comments and just read the code, you get most of the way there.  If you then read the tests that go with the code, you get the rest of the way: code + tests > code + comments.  Reading code is hard.  Reading comments only seems easier until you realize that they are wrong.

So far I’ve been talking about well meaning comments, the kind that are meant to shed light on a tricky algorithm to follow.  These are written at the time of the first commit, and then as the code evolves, they drift out of sync.  But what’s even worse are bits of code that are left commented-out and stay in the code!  No one is brave enough to delete them (note: this is what version control is for), and everyone carefully dances around them in case they need to be re-awoken some day.

The problem with comments is that they are deemed sacred.  They seem to come from a person instead of a machine.  When I look at code, it’s all of a kind: the syntax and vocabulary is that of the computer, and you can safely rewrite it without fear.  But comments seem to come with some sort of deep sincerity.  They whisper things long forgotten, like a faded photograph that falls from between the pages of a book.  Who are these people?  Where were they when this was taken?  Why is it in here?

The way to use comments is to do so sparingly, and to put your efforts into tests instead of prose.  Don’t get me wrong, I want to read your prose piece; just not before I try to understand your function.

Alexander Larsson answered my Dear Lazyweb on finding a PID given a Window ID, to implement Richard Jones' View Source Button idea. I hacked up a tiny bash script to see what kind of info we could easily get about a window. Running that script and clicking on the Gnome calculator, I see:

$ show-source
Click on a window. Avoid clicking on a window border.
PID:             6272
Binary:          /usr/bin/gcalctool
RPM:             gcalctool-5.28.1-1.fc12.x86_64.rpm
SRPM:            gcalctool-5.28.1-1.fc12.src.rpm
Upstream URL:    http://directory.fsf.org/gcalctool.html
Fedora release:  12
Bugzilla search: https://bugzilla.redhat.com/buglist.cgi?query_format=advanced&classification=Fedora&product=Fedora&component=gcalctool&version=12
PackageDB page:  https://admin.fedoraproject.org/pkgdb/packages/name/gcalctool
Transifex page:  (None)

There's a lot more that needs to be handled -- for example, clicking on a script window reports the interpreter instead of the script, clicking on a window border reports nothing, clicking on the window of a consolehelper'd app fails on access to /proc/$PID/exe, and clicking on a terminal window reports the terminal program instead of the character-mode app that is running (obviously).

All of these can be solved fairly easily, and the idea looks workable! As I noted in a commend on Richard's original post, it would be cool to make this View Source applet capable of taking the user to the pkgdb page, a source code browser (I'm thinking DXR, once we get it indexing all of Fedora), a bugzilla search, the upstream web page, or the translate.fedoraproject.org page; or, if the user chose, the applet could download and install the .src.rpm.

As far as I know, there is no way to reliably get a process ID from an X window ID for local clients (to implement Richard's View Source idea). I would love to be wrong!

Questions:

(1) Did I miss something? Can this be done now?

(2) If this can't be done now, what would it take? Could we create an X extension so that the server can supply connection info for a window, and then trace that connection info back to a specific process?

The best part about this stage of the term in our Seneca Mozilla and Open Source development courses is that the students are really digging into some interesting work, and it makes my morning coffee and blog-reading an incredibly satisfying experience.  Here’s some of what I woke-up to today, and it’s inspired me (I need a lot of inspiration these days):

• Andor got 3D hacked into Processing.js, opening the door for his colleagues and the community to start accelerating their work.
• Ehren has got his static analysis of Mozilla done, and found hundreds of functions he can optimize away with his new gcc plugin
• Johnathan Deni has got my View Source analysis tool packaged
• Boris Chao has done the same for Dehydra
• Alex Londono is tearing through remaining Processing array functions
• Anna is set to finish PImage this week, and has a plan to knock off a bunch of 3D stuff as soon as Andor’s stuff lands
• Roger Dicke has got his static analysis scripts running on Mozilla’s string API
• Daniel Hodgin has a bunch more Processing math functions working, and also got a bug tracker setup for the Processing.js work
• Nadim Michaty has his Thunderbird full-screen extension working and ready for people to test.

The list goes on, but my coffee is almost gone.  These are students who didn’t know what open source was two months ago, and are now pushing themselves beyond what used to be their perceived limits.  It’s exciting to think where we’ll be in another month.

There’s one more student blog I read this morning, and I was in the process of leaving a comment when I realized I should probably blog about it instead.  The question is related to things we’re studying this week and next (i.e., XPCOM), so let me deal with it here.

Michael Dennis is waiting on a review of a Thunderbird bug he fixed for his 0.1 release, and instead of sitting there making excuses and wasting time, he’s decided to jump into a second bug (fantastic!).  His first bug was a UI issue that had him working with JavaScript, CSS, and XUL.  His second bug is down in the bowls of the C++ code.  He writes:

So, here comes my new bug, 286760, which was given to me last week. Basically, this bug is about mail addresses that are saved in the address book ending with a space cause problems later on when they are used. From this, I figured it wouldn’t be so hard to fix the error, because how much implementation code do you need to concatenate a name and an email address into, for example, the following:

ex: Mikey <mikey@something.com>

Well, I definitely got surprised once I saw the code to actually do this. All these OOP344 flashbacks came back to me.. * cries *. From pointers, to memory allocations, just ugh… I am definitely not a fan of C++. Keep in mind, I am still not even sure if this is the right place. Starting from an interface, I searched for the makeFullAddress(…) and chose the only match that had an implementation for it; however, the uncertainty is because the makeFullAddress(…) should only accept two parameters, yet the implementation shows that is accepting three parameters, which makes me ask myself if I am going in the wrong direction.

Anyways, let’s say I am on the right track. Exploring the makeFullAddress(…), I ended up at msg_make_full_address, which contains code that seems helpful. However, there is one problem: new keywords are popping everywhere, for example, PRUint32 and PR_Malloc(…). To overcome this, I assume what it is or what it does, but how far can I go by doing this…

Heh, feel free to offer me suggestions.

I have a few suggestions.  First of all, you’re in the right place.  In Mozilla, all (there are a few exceptions, but…) XPCOM methods return a numeric result code to indicate success or some failure.  You’ll see lots of references to things like NS_OK (it worked!) and NS_ERROR or NS_ERROR_NULL_POINTER or a host of other specific error results to tell you that it failed and why.  These are simply 32-bit integer values that are defined in the code using macros.

The reason for all these result codes is that Mozilla doesn’t use C++ exceptions (again, there are a few ‘exceptions’, but…) for historical/compiler reasons.  This means that every method you write has to return an integer value indicating success/fail, and a lot of the C++ code is devoted to checking those values and responding accordingly, much of it hidden inside convenience macros.

What does this mean for the case where you want to have a method return a value?  If you’re forced to return an integer result code, how do you also return a string or object?  The answer is that you add a third parameter to take the result.  Let’s look at the IDL signature for the method Michael is calling (IDL is the interface language Mozilla uses to declare its XPCOM classes and members):
/**
* Given an e-mail address and a person's name, cons them together into a
* single string, doing all the necessary quoting.
*
* @param aName The name of the sender.
* @param aAddress The address of the sender.
* @return A string of the form name <address>.
*/
AString makeFullAddress(in AString aName, in AString aAddress);

It even has comments!  Notice how you have a method that takes 2 arguments (Mozilla’s abstract string type), and returns a third.  No mention of a result code.  Now, when you build Firefox or Thunderbird, the xpidl compiler will take this IDL declaration and translate it into C++, creating a header file that other parts of the C++ code include.  Here’s what that looks like:

NS_IMETHOD nsMsgHeaderParser::MakeFullAddress(const nsAString &aName,
const nsAString &aAddress, nsAString &aResult)

Here the nsMsgHeaderParser is implementing the nsIMsgHeaderParser interface (notice the ‘I’), which includes the makeFullAddress method.  When it turns into C++ the name changes to MakeFullAddress (in JavaScript it would still be makeFullAddress, see below), and the signature has been rewritten to include a new third argument, aResult.  Also, the return type is changed to nsresult (which is what the NS_IMETHOD macro does, and nsresult is just a typedef of a PRUint32 which is just a cross-platform compliant unsigned 32-bit integer).

Notice how the first two arguments are const, and the third one is not.  That’s because the third argument is going to be modified, and a resulting string is going to get “returned” via this argument.  This makes more sense when you see it being called:

parser->MakeFullAddress(pDisplayName, newRecipient.mEmail, newRecipient.mAddress);
if (newRecipient.mAddress.IsEmpty())

Here you see 2 strings being passed, and a third string being given for the return value.  This example is somewhat opaque in terms of the use of the result code, since the caller is ignoring it, instead choosing to look at the length of the third argument after the call has returned.  It comes to the same thing.  Another common way to write this would have been:


nsresult rv;
rv = parser->MakeFullAddress(pDisplayName, newRecipient.mEmail, newRecipient.mAddress);
if (NS_ERROR(rv))

Just to complicate things, this same call can be made from JavaScript, and looks different again:

var address = gHeaderParser.makeFullAddress(card.displayName, card.primaryEmail);

Here there are only 2 arguments, and notice how the resulting string is once again returned from the method, just as the IDL specified.  That’s right, you have to understand that it works differently in C++ and JavaScript, but is the same method either way.  It’s not as hard as it seems, but it’s hard enough to cause new developers to stumble.  Being able to declare, define, and call code across language boundaries is powerful and complicated.

All of this to say, I can understand why Michael is confused about whether or not he’s looking at the right code.  The answer is ‘yes’ but it takes some understanding of how our code is structured to see why.  If you didn’t get all this, don’t worry.  There will be more XPCOM lore in class this week and next, and lab to help you get more experience with it.

To my students working on Processing.js, I wanted to share a video that Ben Fry linked to on Twitter today (if you guys were all on Twitter this would be so much easier, btw).  You don’t have to be able to create things like this yourself: helping to enable the tools that are used to build them is part of that process.  I’m just finished marking all the first round of bug fixes and new features, and can’t wait for more next week.  Open this video beside your editor to inspire you as you work:

toxiclibs showreel from postspectacular on Vimeo.

One challenge of teaching inside an open source community is finding projects which are appropriately for students to work on: they shouldn't be really trivial, because that won't provide a challenge or allow the student to engage with the community; they can't be huge, or the student won't finish them within the semester; and they can't be blockers or part of the critical path to a release, because the student may not be able to complete the project on the community's timeline.

My colleague David Humphrey introduced a new keyword into the Mozilla bugzilla tracker last spring, and it has been successfully used to identify many potential student projects (108 at the time of writing).

Good ideas are worth copying -- and since I'm bringing students into the Fedora community, and the POSSE-APAC professors will bring even more, I asked Dave Lawrence to add the StudentProject keyword to the Fedora/Red Hat bugzilla (thanks Dave and Paul!).

Your help in adding this keyword to any appropriate Fedora bugs you file, triage, or notice would be appreciated. Let's aim to identify 100 suitable bugs by FUDCon!

Blake mentioned on Twitter that Gamercamp is coming-up in Toronto on November 21.  It looks like a great event for our game dev students, and those working on 3D in the browser with C3DL, WebGL, and Processing.js.

An unfortunate side-effect of removing underlines from links on a web page is that one can easily miss side-by-side links.  Here’s an example from a blog I was reading today:

How many links are there in that section?  One?  Two?  Three?  The answer is three, but just like with this image, you can’t tell by looking at it.  There’s a different meaning to multiple, concurrent links in a sentence like this.  Someone might argue that if you care about the links, you’ll go and visit each one anyway, so the end is the same.  The problem is that links don’t always take use places, they also give us the possibility of another place without leaving our current position; the link out of the document has meaning within the document.

The effect of multiple, concurrent links is to add semantic weight to your point via a visual cue.  It overflows the sentence with examples without you having to go to them in order to get the point.  However, when the underline is removed, you are led to believe that there is only one link, and unless you check, that’s all you’ll ever know.

Two is twice as many as one, and three even more.

I’m reading papers right now, written by my students about their experiences attending open source talks at FSOSS.  Quite a few of them are thinking about the problem of the economics of open source, looking at business models and comparing them to closed source companies.  In the middle of this, Al shares a video on Twitter, and I’m forced to put the marking aside (you should watch it too), and reflect on what else open source does.  Open source allows one to do without.  That is, it enables what is otherwise not possible with what is at hand.  It makes available.  It is ready to be co-opted, ready to be appropriated, ready to become the ready-made.

There are good reasons to think about the economics of open source.  I’m lucky to have a job, and a job that allows me to work on open source.  But there are other types of questions that open source lets us ask, for example, how to do without being one of the most powerful.  We should ask all those questions.  I’m asking some of them even now.

Tomorrow will be the 14th day that my email has been broken.  I’m just going to call it now, because I’m done expecting it to get fixed.  Our IT department has bungled this so badly it has left my colleagues and me speechless.  There are official statements like this one, which leads me to believe they rolled-out ZFS and are now paying for it, but the technical issues aren’t my concern right now.  I want to write about something else.

I have been amazed how badly this outage has broken my workflow.  You see there is a “web” client (I have read the code, so I hesitate to acknowledge it as anything that belongs on the web), and it allows you to get your email, and sometimes send email.  So why are we all still saying we don’t have email?

It turns out that email is a good portion of my workflow.  It’s how I get my bug info and updates from Mozilla.  It’s how I see that changes to wikis I use have occurred.  It’s how I work with various groups through mailing lists.  Thankfully it’s not how I work with my students (we use irc, wikis, blogs, etc.) or I’d be completely dead.

But what I’m lacking more than anything else is the ability to work with my existing mail and address book.  Writing mail means looking through old mail.  I have tons of things I need to go look-up in order to answer questions for people.  I have reports to work on, grant applications, open source projects, requests from other projects and professors, inquiries from students, etc.  Almost all of it requires me to go get a name, a number, a link, whatever.  And I can’t do it.  It’s brought my productivity to a halt.

There will be people who will say that I should just move to gmail, that this is all solved that way.  I know what they mean, because I also use gmail.  But for me, and this is a personal choice I don’t care to argue with you, a rich client is the only way for me to work.  I’ve been made much more aware of this over the past few weeks.

So to those of you who are still waiting for replies from me, or who wonder why I haven’t mailed–I will get back to you, but I’m struggling to cope with the volume of mail I get in a 1994-era “web” mail client.  And to the Thunderbird team, who are working hard to release Thunderbird 3, I say this: I’m going to enjoy it even more when it arrives.  There’s nothing I can say to our IT guys at this point they haven’t heard from the thousands of other people like me who are screwed.

Last week, at both FSOSS and the Teaching Open Source Summit, I heard a word that jarred me slightly, because I had dropped it from my professional vocabulary a number of years ago: "Kids".

I stopped using the word "kids" to refer to students for several reasons -- including the fact that I had a student twenty years my senior, and another who was a fully accredited Civil Engineer in his home country -- but the main reason that I dropped it was that it is simply incompatible with the way open source communities work. In open source, roles are defined by contribution, not age or formal training. Some of the youngest members of the community are the most active, and make crucial and valuable contributions.

If we're teaching inside open source communities, then it's important that we value students as full members of those communities -- and I think that the term "kids" is dismissive of their abilities.

Just a quick note to users of the CDOT OpenSource@Seneca wiki -- I've added a version of the Admonition templates from the Fedora wiki. This lets you easily format warning, information, prohibition, and tip boxes into wiki pages:

You can see the markup at the bottom of the current Sandbox page.

I came across a couple of bugs today in the Thunderbird code that need a fix, and they are both easy fixes for a student looking for contribution.  Basically, in DXR I have a C++ parser to create HTML files with markup versions of source code.  My parser chokes on 2 files, because someone did a bad thing and put an extra 0×0c (e.g., \f, form-feed) char in there.  This causes all sorts of bad things to happen with tools that try and work on the source and expect things like \n or \r\n or whatever.

[dave@scotland dxr]$ find ./mozilla-trees -name '*.h' -o -name '*.cpp' | xargs grep -n '^L'
./mozilla-trees/comm-central/mailnews/mime/src/mimeenc.cpp:852:
./mozilla-trees/comm-central/mailnews/mime/src/mimei.h:414:

NOTE: to get that ^L you have to type: CTRL+V CTRL+L.  This will take you about 1 minute plus the time to build Thunderbird, file a bug, and submit the patch.  Interested? If so, leave a comment here or talk to me on irc/email.

Today I learned something new.  Last night I integrated callgraph into dxr (I’ll blog about that later, once I rebuild dxr indices for mozilla-central and comm-central), and that meant that I needed to be able to run a Treehydra script in addition to my existing Dehydra one.  Dehydra scripts are basically a subset of Treehydra scripts (the same callback functions still work), and you can use the gcc_treehydra.so plugin to run them both.

Taras had mentioned that there is code in the Mozilla build system to handle this case, and after speaking with Benjamin I had the answer.  The file static-checking.js deals with running multiple treehydra/dehydra by loading them as needed.  All you need to do in order to make this work is specify that your C++ compiler is one that supports plugins (e.g., CXX=/path/to/dehydra-aware/g++), set DEHYDRA_PATH (e.g., the path to your gcc_dehydra.so or gcc_treehydra.so file), and list your scripts with one or both of DEHYDRA_MODULES and TREEHYDRA_MODULES.  The rest happens automatically.

I’ve been down and out with FSOSS followed by flu, so haven’t blogged this yet.  But I wanted to add my voice to the others who have already written about Mozilla’s new Jetpack for Learning Design Challenge.  As Frank Hecker writes,

We invite you to help turn the open Web into a rich learning environment and explore new possibilities for using Firefox add-ons to support learning online, by participating in the Jetpack for Learning Design Challenge sponsored by the Mozilla Foundation with support from the John D. and Catherine T. MacArthur Foundation as part of its digital media and learning initiative.

We’re looking for designers, educators and software developers who want to turn their innovative ideas about learning online into working prototypes in the form of Firefox add-ons. We’ll help you refine your designs and teach you how to create Firefox add-ons using Jetpack and other Mozilla technologies. Participants creating the best prototypes will be invited to the Jetpack for Learning Design Camp and the SXSW Interactive conference in March 2010.

One of the more interesting things that’s happened with Mozilla in the time I’ve been involved is that it has gotten easier and easier for people to work with technologies like Firefox extensions.  Things like Jetpack open the door even wider to welcome students, new developers, web developers, designers, etc.  Combine this with an educational context and mentorship model in which to learn how to do this, and you’ve got a winning recipe.

There’s still time to make submissions (you can do that here), and I’d encourage students and educators to get involved.  The Mozilla project is a great place to be a student, and this is just one more reason why.

Since I’ve got some time to kill here while I wait for just about every piece of software I need on my box to rebuild, I thought I’d reflect on what I’ve been doing the past few evenings.  I want to try and show what I mean by “contribution” when I ask my students to contribute to other projects.  At the same time, I want to show how failure can itself be an important source of contribution.

I’m concurrently working on two problems.  First, I’m trying to add JavaScript code to DXR.  Second, I’m trying to integrate a complete callgraph for Mozilla’s C++ code.  Both are turning out to be somewhat non-trivial, and are presenting me with the right level of personal challenge and failure in order to provide me with equal parts frustration and teachable moment.

I think a lot about failure.  As a professor taking students into the bowls of a web browser, you have to think about failure.  Failure is what will happen.  It isn’t something you can avoid.  It’s where you spend the majority of your time when you work at the scale of something like Mozilla.  As I’ve written elsewhere, failure is data.  Failure is information on the road to getting things done.  You avoid failure at the risk of avoiding success.

Tonight I’m failing:

<@taras> lol
<@taras> humph: it’s just not your day today
< humph> I’ll pull a teachable moment out of it for my blog/students
< humph> otherwise it’s a disaster
< dwitte> humph: lol, that’s unfortunate
<@taras> humph: valgrind should tell you where it’s going wrong
< dwitte> start with upgrading to 4.3.latest, since i’ve tested on that
< dwitte> after that, bust out the debugger
< dwitte> or valgrind!

I’m failing, but it’s not for lack of trying.  I started out by trying to rewrite the Mozilla build system to preprocess JavaScript files such that they end-up in the source dir instead of being put in jar files or getting copied to the object directory of a build.  I got pretty far, but then I hit a wall.  My hacks to our build system and preprocessor came to a crashing halt when I hit files that included files that included…you get the idea.  Why do we even allow includes?  Clearly no one has ever tried to extract a complete set of parsable JavaScript files from all of our .js, .xul, .xml, xhtml, etc.  I got within inches of the end, only to see that the road curves off to the left for another 10 miles.

Rather than give up, I did what you do in software development, and switched tasks.  At the same time that I was failing on the JavaScript extraction, I saw a familiar plea on irc: “How can I find all the callers of nsXULAppInfo::GetName?”  This is a very common type of question, and it is hard to answer.  One of the things I’m working on is making it easier to get this info.  To that end, I decided to switch over to working on integrating Dan Witte’s fantastic work to build a complete Mozilla callgraph.

Luckily Dan has kindly provided some documentation on building and using his tool (it’s great to see that the Mozilla static analysis tools group all seem to do this).  I began by building Treehydra and quickly hit a wall.  Even though it built, it couldn’t be used to build Mozilla.  I did some checking and noticed that I was failing a bunch of treehydra tests.  I tried rebuilding a few other things to see if I’d missed something, and still couldn’t get it to work.  Asking on irc brought no help.  After deciding it was not just something stupid I was doing, I filed a bug.

A little while later, Taras offered to look at my box.  After poking around for a while, he agreed that this was not just me, and represented a bug in Mozilla’s JS implementation, SpiderMonkey.  He offered to write a work-around patch for me if I’d help him by finding a regression window.

Regressions are bugs where you suddenly break something that previously worked.  They are accidental side-effects of making other changes, and often don’t show-up for some time.  When you do notice them, you want to go back and figure out where you introduced the bug.  In other words, you want a window of time where it went from ‘working’ to ‘not working’.  Finding regression windows can be time consuming, and depending on the bug, laborious.

In my case I needed to try various versions of the SpiderMonkey code combined with my Treehydra build, and then run the build tests.  Without version control, this would be a nightmare, as it would require downloading many builds and testing.  However, with version control, and especially Mercurial (which keeps the entire history on your local machine), this is pretty easy.

Mercurial revisions are numbered two ways.  First, there is a local incremental number–an integer.  Second, there is a hash that represents the changeset globally, and is the same on everyone’s machine.  To make this job easier, I did what any sane programmer would do, and wrote a quick shell script that took one argument, the local revision to use for my update, and updated/rebuilt/tested.

Next I started making some guesses.  Talking with people on irc, I guessed that this had worked sometime in the past 1-2 months. I tried going back to September and running my script.  Very quickly I found a revision where all the tests passed.  After that it was a matter of bisecting the revisions between my current (failing) revision and the passing one some months back.  After a dozen attempts, I had it: here was the last time it had worked.

At the end of all this, I still have a broken build (it finished while I was writing this).  I haven’t fixed my problem yet.  However, my problem turned out to be a bug that had been silently introduced a few months ago.  Someone needed to fail for it to get found and fixed.  Someone needed to do the work of figuring out when it got introduced.  Someone also needs to fix it.  But the fix only comes after it has been identified.

I tell this story so as to encourage my students (and all new contributors) to not lose heart when they fail at things.  Your failure may be pointing at a much larger issue.  In an open project like Mozilla, there are no personal bugs.  The community owns them.  You become part of that community when you contribute to finding and fixing them, and failure is how you get there.  You can’t contribute without failure.

My friend Mike Hoye has done something important for the web:

It’s small, just a start, but the world doesn’t work this way yet and I think a lot more of it should. PatchCulture.org is live. Might work, might not. I’m hopeful.

This is exciting for me because it’s the realization of the thinking I wrote about here.  Mike’s done one better and named this gesture, making it available for others to use:

With your help, the Web can be the largest, most vibrant open-source community in the world.

That sounds right to me.  Please share this, and help Mike achieve his goal.

A number of colleagues have pointed me at Joel Spolsky’s latest post, Capstone projects and time management.  In it, Joel argues for the inclusion of real-world projects in computer science programs and laments the near universal dismissal by (top) schools of any grounding in things like version control, debuggers, testing, etc.  He writes:

It is amazing how easy it is to sail through a Computer Science degree from a top university without ever learning the basic tools of software developers, without ever working on a team, and without ever taking a course for which you don’t get an automatic F for collaborating. Many CS departments are trapped in the 1980s, teaching the same old curriculum that has by now become completely divorced from the reality of modern software development.

Where are students supposed to learn about version control, bug tracking, working on teams, scheduling, estimating, debugging, usability testing, and documentation? Where do they learn to write a program longer than 20 lines?

He ends with this interesting observation (emphasis mine):

The only reason the real world gets this right where all-student college teams fail is because in the real world there are managers, who can set deadlines, which a team of students who are all peers can’t pull off.

This echoes another conversation I had on Mozilla’s Education irc channel today.  Sid, Blake, and I were talking with about the complete lack of version control use among most students:

< sid0> bwinton: I’ve even tried convincing several people to switch to version control, but I guess zips are “good enough” for the kind of assignments we get (at most a thousand lines or so, 1-2 people)
<humph> sid0: exactly.  you have to need it before you need it. they don’t need it with that stuff
< sid0> yep, exactly
< bwinton> So, sid0/humph/jcranmer, how would you get people to switch to version control? Just give a really big/long assignment?
< sid0> bwinton: I guess a more productive way would be to get people into open source
<humph> if you want people to learn things like this, you have to insert them in a mature environment that already does this stuff and have them do what the others do.  if they do what the others do, and the others are just their peers, they never learn anything new.

You can sum up this conversation and Joel’s conclusion by asking a simple, but important question: who are your peers?  As a student, with whom do you surround yourself?  As a professor, who are the people collaborating with your students?  As a developer, manager, or other industry professional, with whom are you (and your employees) engaged on a daily/weekly basis outside your company?  Who are your peers?

Joel’s solution to this problem is also the same reason Sid knows version control, and uses it as a student studying computer science in India: the only way to learn real-world skills is to engage with the real world, and more specifically, with the problems of the real world.  Sid’s a professional software developer even though he’s still in school because he’s taken it upon himself to work on Mozilla development now, and in so doing diversified his peer group to include some of the best software developers in the world.  That problem you can solve the night before it’s due for class, the one whose code you are swapping back and forth across email with your group members, it’s not real.  The fact that you can work on it like this, and get away with it, necessarily disqualifies it from any definition of ‘real.’  It’s not real, it’s simply due.  It’s uninspired, unimportant, and unnecessary.

It doesn’t have to be this way.  Despite Joel’s broad statements, there are schools where this is understood.  I know because at Seneca we’ve spent the past five years doing what he describes, and it’s been a huge success.  The key to making it work, though, is missed by many of my colleagues in academia, who assume that the only way to approach this is to partner with closed-source companies.  I liked how Joel said that he was going to sponsor a group to work on Mercurial–one of the best version control systems there is, which also happens to be open source.  What’s significant about that?  It comes back to the possibility of connecting students to a new peer group.

Let me give you a real and current example.  I have a student in my Mozilla Open Source Development course named Ehren Metcalfe.  In this course, students are asked to work on a real project/bug within the context of the Mozilla project.  We don’t let them choose the project out of the air; it has to be real, which is another way of saying, Mozilla needs to care about it enough that they will get involved, will become a peer for the student(s).  Ehren came to me on the first day and said, “I want to work on gdb.”  I probably don’t need to tell you that I don’t hear this often from a student.  But my philosophy in the course is to let students get passionate about a topic, so if you want to hack on gdb, JavaScript, python, whatever, let’s do it.  There are crazy people at Mozilla who do work on gdb, so I knew it was a possibility.  But as I introduced Ehren to a tool developer at Mozilla, a new idea emerged:  “Want to make Mozilla really fast?  We have some gcc optimization work we want done.  I’ll help you.”

So before I continue, let’s summarize what we have so far: a student who wants to push himself in a certain direction but with no formal background to do it coupled with a need from a real-world software project/company who is eager to see it happen.  It’s important to note, before we go further, that this sort of apprenticeship can only happen in the context of open source software.  No closed shop, no matter how much they believe in the cause, is going to risk letting a bumbling student look and poke at their internal code, or allocate the time of an employee to training him/her.  Students drop courses, they procrastinate, and sometimes that succeed wildly.  How do you like those odds?  Ready to bet your company on them?

Back to gcc, Mozilla, and Ehren.  How far has he gotten two months into the project?  Pretty damn close.  How is this possible?  It comes back to the question of peers, and the potential of open source communities to mentor new contributors.  I don’t want to pretend that I’ve taught him how to pull this off.  I’m not a gcc hacker.  Instead, I’ve taught him how to be lost productively, how to manage fear and turn it into forward momentum measured in inches.  And more than this, I’ve gotten him connected to some amazing new peers:

The next morning I tried a new approach by consulting GCC’s bugzilla. Searching for bugs marked enhancement and containing the word “attribute” I came across Bug 36892 Support __attribute__((deprecated(“text string”))).

“Did you notice that your student just copied source from the web for his assignment?”  I did, and he’s getting bonus marks for it.  More than that, I’ve seen him overcome his fear of sounding like a fool, and asking questions:  “The other night I was stuck on this function, and so I asked on irc.  A gcc dev gave me some info, and later I noticed that he’d written the file I was working in!”  To date Ehren has had interactions with developers at Mozilla, Google, and Red Hat, all of whom are actively developing gcc.

Who are your peers?  Who are your students allowed to talk to about their code?  Who are your employees allowed to help?  Ehren is doing great work this term, but he’s not unique.  I’ve got a class full of students like this, and it isn’t because of something I’m doing, or something they bring (we’re not a “top” school, by any means).  It comes back to peers.  We throw our students into the midst of the best developers in the world, we let them work on meaningful work, and we let them become peers with professionals.

Open source projects like Mozilla aren’t just about code you can download.  They are about peers you can work alongside.  Every computer science student needs this opportunity for growth.  This is how you teach software.

This week there are a whole bunch of open source events in the city, one of which is our own FSOSS.  Over the years Chris and I have been involved in running this and many other tech events at Seneca.  In that time we’ve had hundreds (literally) of industry and open source people come and give talks to our students, speak at dev days, participate in workshops, and generally hang-out with us and our students at Seneca.  A lot of the reason we do it (and I don’t mind telling you that it is a lot of work) is so that we can create a community that reaches outside the classroom walls.  It is our firm belief that you can’t become a software professional without engaging with real software or real software professionals.

But we can only do so much.  We can work with our friends and partners to put on some great talks and workshops, can arrange to have people fly and stay here, do all the logistical and technical setup we want, but none of that guarantees any of what I described above.  The reason is simple: as an attendee, you get out of these events what you put into them.

I’m saying “attendee” and in my mind I’m really wanting to speak to the students who will attend.  Going to these events as a student is a tremendous opportunity.  It allows you to get to know who is out there and to hear about the work they are doing now and they work they plan to do.  That’s why you go to a tech event or conference, right?  You go to listen, right?  I think that’s only half the reason, or maybe less.

Conferences and other tech events are about people coming together.  As a student going to one of these events, it’s easy to feel like you’re just an observer or let intimidation silence you.  However, that can’t be your response to being among the very people you want to work with in the coming years.  You have to decide that you belong there, and take the chance to meet these people.

So how do you do it?  “What do I have to say to someone who knows so much more than me?”  For starters, you could talk to them about the talk they just gave.  What did you find interesting?  What was surprising to you?  People who travel far to give talks don’t come so they can speak and then have no one give them feedback.  They are looking to reach out to people, looking to connect with their audience.  Obviously you don’t want to be pushy or dominate a speaker when others are also trying to see them.  However, it’s quite acceptable to go and introduce yourself and have a brief conversation about what they have said.  It might grow into a larger conversation, and it might end right there.  Either way you’ve taken an important step and chosen to become part of the event instead of just an observer.

I’ve known students who have come away from FSOSS with jobs, and others who have sat there and gotten out of it exactly what they put in (i.e., nothing).  It’s not important that anything profound happen.  It’s enough to simply be present and to learn how to be among your peers in the industry.  That in itself is a skill worth learning.

<@taras> you should blog that

< andrew> you should blog more about that project

My students have a first release due today by midnight, and all day I’ve been watching attachments go up on bugs and demos getting posted online.  It’s been really cool to watch how far many of them have gotten with their 0.1 release on a Mozilla project.

I blogged earlier in the term that I would be working on my own stuff in parallel, in the form of DXR (though I ended up doing a bunch of Thunderbird bugs too, which were also useful for teaching).  DXR is a web-based source code indexing tool that incorporates static analysis data.  You can read more about it here, watch a demo, and try it out yourself.

My work since then has been focused on plumbing vs. new features I can easily demo.  I’ve rewritten the back-end in order to make it faster.  When I started this work it took ~400 mins to do a full index and generate static html for the source of mozilla-central (Firefox) and comm-central (Thunderbird, Suite) together.  After lots of experiments, deleting code, and digging into python, I have this down to ~100 mins.  This means it’s now fast enough that I can start doing constant re-indexing of our source.  I’m going to be testing this over the weekend to work out a few more kinks.  Taras has been working on getting a dedicated box at Mozilla, so we can use it in production, which will make it better than the demo I have up now.  Once that’s in place, I’ll see about setting it up there.

I’m also working on front-end fixes and data improvements, as described on this wiki page.  If you have other ideas for things you’d like to see, add them to the wiki or talk to me on irc (humph).  Many very useful things are easy to add, for example, bz wanted a way to query for derived:nsIFoo::GetBar so I added that today (it’s not in the demo yet, but will be next week), .  You can also file bugs for DXR in Mozilla’s bugzilla under WebTools:DXR.

Next week Taras Glek and Benjamin Smedberg descend on Toronto for FSOSS (Taras and I have a talk at FSOSS about Dehydra and DXR), and we are going to spend some time Tuesday planning more of the work that will be done in the coming months.  Benjamin has already written a patch to move my changes to xpidl into his python version of the same.  I’m looking forward to seeing them again after so much time just on irc, and to getting to talk with them about ideas I have for next steps.

The fall has been tremendously exciting and busy, with Mozilla Education and Seneca Mozilla teaching taking the bulk of my time.  It’s fantastic to be so busy with my own and other students, and to be helping profs get started doing the same.  However, I haven’t lost track of DXR, and am actively working on it with the remaining time I have.  Thanks to all of you who have given me feedback, reported bugs, and generally encouraged me with this work.  It’s very rewarding when you know that others are interested and cheering you on.

P.S. I was also asked to add a new web front-end for Mozilla’s static analysis tools, dehydra and jshydra.  Jason Orendorff named “View Source” and you can try it out here, download a tarball here, or get the source here.  It is much easier than setting up your own environment for doing debugging of analysis scripts or looking at small test cases.  Here’s what it looks like:

Chris has just posted about the final set of presentations for FSOSS 2009, happening next Friday October 30.  This year, after more years of running or working on FSOSS than I can remember, I’m going to finally get to attend and participate as a speaker.  Taras and I will be wowing the crowd with talk of static analysis tools, dehydra, and dxr.  In addition to us, there are other great Mozilla-related talks going on, including:

• Cathy Leung on 3D in the browser and C3DL
• Al MacDonald on Processing.js
• Benjamin Smedberg on different communication styles in open source

Be sure to check out the entire list.  There’s also the Teaching Open Source Summit on Thursday October 29th.  In fact, the entire week has got a bunch of open source events happening around the city, so much so that the Mayor has proclaimed next week as Toronto Open Source Week!

I’m looking forward to seeing lots of friends and colleagues as they travel to Toronto, and hopefully you’ll be there too.  Register online here.

The presentation slate for FSOSS 2009 has been finalized, and it looks like a interesting and diverse line-up including such topics as:

• Apache Qpid (AMQP)
• technical writing and documentation
• Mozilla Dehydra and DXR tools
• Processing.js
• open source in South Africa's universities
• communication in open source projects

...and more.

I'm looking forward to a great conference! If you're within driving distance of Toronto, please consider joining us on October 30. Advance registration -- and the corresponding discount -- ends this weekend as the Toronto Open Source Week gets underway.

I had a fun conversation with tdot on #seneca last night. He was trying to get his mouse working with ncurses -- and even though vim and mc worked fine with the mouse, this example didn't work at all.

This looked like too much fun to ignore, so I dove into it a bit and found that KEY_MOUSE isn't reported correctly through wgetch() in ncurses 5.6 -- you have to use getch() instead -- and that the example used BUTTON1_PRESSED (button down) instead of BUTTON1_CLICKED (button down & released within click timeout). With those two fixes, this revised example works fine.

Sure, I’d be happy to do just that.  Yesterday I wrote about the new Mozilla course getting underway this week in France, and today Didier (Desiderius on irc in #education and #comete) spoke to me on irc looking for info about the projects his students could do.  When I wrote yesterday, I ended by saying that Mozilla seeks people who want to use their passion to solve interesting problems related to the open web, and that you can work on everything from compiler fixes to JavaScript libraries, and everything in between.  “Show me.”

There are two main places I want to point students looking for project ideas.  The first is to look at the list of potential student-project bugs, available here.  This list (106 bugs at the time of writing) is constantly changing as people add new things, and students take others.  While I’m on the topic, I have to thank a few people who work hard to keep this list fresh: Boris (bz), Benjamin (bsmedberg), and Mark (Standard8).  These three are the names I see most often when I get notifications from bugzilla of new things being filed/flagged.  These guys are among a group of a dozen who regularly take the time to triage bugs for new contributors and students.  We need more like them (in many ways), and always need more project ideas for those times when 31 French students show up (it happens!).

The second main project area where we have a lot of students working right now is on something we’re loosely calling Processing for the Web.  The part of this project where we’re currently focusing our energy is on implementing the rest of the processing.js, see the task list here, which includes adding the 3D support.  As we go we are keeping track of performance issues, too, and hope to feed these back into the platform team so we can insure things get faster as we build more and more.  This week, the ten students I have working on this have their first set of functions due, and we’ll be adding a baker’s dozen or more new function implementations to the library.  Here’s Andor’s demo of mag() and Matt’s demo of pushStyle() and popStyle(), for example.

So as you can see, I wasn’t lying when I said you could work on everything from compilers to JavaScript libraries.  The best way to learn more about any of this work, or to sign-up and join the fun, is to get in touch with me on irc (I’m humph in #education) or via email.

Today Mark Surman and I had the pleasure of taking part in the start of the Course on Mozilla education and Technologies @ Evry (CoMeTe for short) in France.  We each gave a talk via video link to the assembled professors, students, and industry partners.  It was very exciting to see all the hard work that Didier Courtaud and others have done to get the program off the ground.  We are really looking forward to helping their 31 students get started working on Mozilla projects, and to help them join the Mozilla community.

The event also gave me yet another unique experience doing a remote talk.  I’ve done a number of them as part of various Mozilla Education events and courses.  In every case I’ve walked away feeling like there is still so much room for this technology to improve.  Want to talk to someone on the other side of the world with video/audio?  Solved.  Want to share your slides with people via the web?  Solved.  Want to do both at once?  Lots of people will tell you this is “solved” but my experience using both open and closed solutions (some very expensive ones, I might add) is that they all have a long way to go.

Today as I wrapped-up my talk, I asked the students in France if they felt nervous or excited, or just what their response to getting started on something as big as Mozilla was.  One student said that he felt unsure about what he might work on, that he was unclear what sorts of things you could do or contribute personally.  This is a common reaction I hear, and not just from students.  I plan to write about it at length in the coming weeks, but for now I’ll repeat my answer to him: Mozilla is the business of transforming passion into open products and tools.  Some people work on scripting languages, some people in native code, some people on compilers, some people on tools, some people on technical documentation, some people on translation, some people on graphic design, … the list of topics is very wide, and just as deep.  For the most part working on Mozilla is less about changing yourself into something else, and more about leveraging the skills and interests you already have.  It’s an ecosystem of technologies, projects, and people, and they are all driven by passion.  That’s where you begin.  What’s your passion?

Next week our students’ first project release is due (0.1).  In the past few days I’ve had quite a few conversations with students working on their Processing.js work, and a lot of it is coming along nicely (Andor, for example, has been blogging and coding up a storm).  Al will be coming to Toronto in a couple weeks to meet with the students, and for the first set of code reviews and landings of new features.  There’s a lot of energy.  But I want to keep that energy level high, so I thought I’d share the following thoughts.

When you work on a technology from underneath, that is, when you work on implementation, it can be hard to imagine how writing silly little functions will have any great effect.  The creation of a tool feels very different from the creation done using the tool.  So I was interested to see that Gen has posted about a cool use of html5 and Processing.js to explore smooth wave forms.  I wanted to draw my students’ attention to it, because it shows how unlocking the potential of a technology makes it possible for others to come along and build interesting things using it:

In the end, I came up with both something that “floats naturally” and also a serendipitous encounter with the simplicity of working with only HTML and JavaScript, which has been very rewarding.

The simplicity of the encounter is the goal of a well designed tool.  To my students I say this: keep doing what you’re doing because there are many people waiting to work with all the stuff you’re building, waiting to have similar rewarding, serendipitous encounters with the simplicity of these technologies.

Today in class we were taking the skills and knowledge of the past few weeks and applying them.  The students have learned how to build Mozilla, how to work with the code, how to make changes and get those changes compiled back into the application, how to work with revision control and make patches, what bugs are, how reviews work, etc.  Now it was time to have them all fix a simple bug together, and reflect on the process.  Many of them have already fixed bugs, or are in the process of doing so as part of their project work.  However, this was the first time we all worked on the same task.

So I came to class ready to dive in and get them started, hoping that most would be able to finish in the 2 hours we had together.  And then the network went down.  Or more specifically, MXR went down.  Went down again.  It’s been down every single time I’ve tried to show it to the students this term.  I’m talking about 5-nines of downtime.  It’s uncanny.

Since we’re talking about bugs in class, I thought I’d use this as a learning experience (note: that’s what you call it when your lesson plan explodes on you and you’re left to ad lib).  I started by asking on irc if anyone had noticed this same issue.  Many people had.  Next I asked if anyone had filed a bug already.  Silence.  This silence speaks volumes, and what it says is, “No, but could you do it?”  So I filed a bug.  Within an hour and a half, it was fixed.  When we spoke in class earlier about how a bug is more than just a problem in your software, and can represent just about any task that has to get completed and tracked, this is the sort of example I had in mind.

The second follow-up from class today is a bit of source code.  Since we couldn’t do the lab, I had to quickly switch gears, and decided to instead work on a bug I had to fix myself.  I took the students through the code and showed them what was going wrong.  Next I explained, at a high level, what the code did, and where I thought the bug might live.  Then I asked them for strategies to debug and isolate the problem, leading them toward a solution that would make it possible for QA and beta testers (who are able to reproduce the bug, while I can’t) to get me the info I need to fix it.

Very quickly the students had the idea of using the Error Console as a way of logging debug info.  The code where we were working was all C++ instead of JavaScript (all examples on how to use the Error Console from code are in JavaScript), so we had to start by understanding how to use it from native code.  Doing this without the help of MXR makes the work more painful, since you can’t go and look for examples in the code.  However, we worked slowly, and by the end of the class had 80% of the solution done.  All that remained was to figure out some tricky bits of the string API.

After class was over I finished off the code and created a patch.  I was finally able to do it because MXR came back up (thanks to this other bug), and I could search for what I needed:  nsTextFormatter::ssprintf().  This allowed me to format the string the way I needed and then dump it to the console.  Once the patch was up, I got some help to create 2 public builds with the code that others could test with.  Within 30 mins I had a response back from one of the testers with the data I needed.

When you’re trying to teach your students how open source works, what a bug is, etc. there is no better way than to just dive in and work on real things.  You can tell people about how amazing the community is in theory, but its much better when you can show it happening.  Same goes for trying to demonstrate what a bug is, and what their life cycle is like.  You can make up examples, but why go to all that trouble?  There’s no shortage of real-world examples you can use if you take the time to look.

Every time I use JavaScript’s regular expressions I inevitably have to relearn something.  Today I am putting the finishing touches on a new web-based static analysis tool I’ll blog about later, and I needed to do something simple: given a dehydra JS object that has been pushed through SpiderMonkey’s uneval() function, I want to find and replace all instances of “Line: #,” with the actual line of code I’m analyzing.  Using the js shell, I did some quick tests:


js> x
"blah blah blah line: 2, blah blah blah line: 3, blah blah line: 4, blah blah"
js> /line: (\d+),/g.exec(x);
["line: 2,", "2"]


No matter what I tried, this always gave me the first match, and no more.  Luckily, Gavin had the answer: exec() is meant to be called in a loop, and position info is cached.  It’s about the least obvious API choice I can imagine for doing this, but here you are:


js> var r=/line: (\d+),/g; while (m=r.exec("blah blah blah line: 2, blah blah blah line: 3, blah blah line: 4, blah blah")) print(m);
line: 2,,2
line: 3,,3
line: 4,,4


Now you know, and I’ll have something to search for on Google next time I have to relearn this!

In the last month I’ve encountered the term Technical Debt a great many times.  If the term is unknown to you, consider it a sort of borrowing against your future (e.g., time in most cases, but also money to pay for employees’ time) in order to more quickly deliver something now (e.g., a software product).  Technical debt is what happens when you don’t do now the proper work you’ll have to do later.

It’s not hard to imagine why we would begin to think about the work we do as software developers in terms that map onto the world most discussed of late by the news media.  The over saturation of news coverage devoted to the financial crisis, subprime mortgages, financial bailouts, etc. has caused many of us to privilege certain metaphors because they come so easily to mind, and seem to be most characteristic to our time.  The ready-to-hand of the financial metaphor makes its meaning and assumptions harder to see, since it’s all we see, and how can that which we see be anything other than that which is?

Today I was reading Martin Fowler discuss what he categorizes as the four types of technical debt.  He does a good job making the case that technical debt needs to be divided into four quadrants: “reckless/prudent and deliberate/inadvertent.”  To say that borrowing is always reckless is clearly wrong.  However, to only imagine it on a continuum from reckless to prudent misses something too: was the debt taken on deliberately or inadvertently?  Does the team understand the costs of their choices?  Are they choosing to pay-off the interest now, knowing they’ll have a period coming later on when the principle can be tackled?  Or, is the team naive and working faster than they are careful?

It’s a good analysis, but the sentence that really resonated with me was this one:

Technical Debt is a metaphor, so the real question is whether or not the debt metaphor is helpful about thinking about how to deal with design problems, and how to communicate that thinking.

Fowler recognizes the limits of his procedure from the beginning, and more, he draws attention to the mechanism by which it works.  In doing so he implicitly asks an important question: are there other metaphors that would be as, or more helpful?  I think there are.

Part of why the financial metaphor works so well for software is that most of the people I see using it are working on software that is being sold as a product.  In this sense, the fact that it is software is really secondary to its primary meaning: they are building “apps” for the “store.”  There’s another kind of software, though, and this other kind of software is where I do almost all of my work.  The software I’m working on day to day is open source, and much of it represents the building of tools, libraries, and other meta-software as opposed to end-user products.  I mention this not to pass any kind of moral or ethical judgment, but to try and further loosen the de facto link between software development and a financial metaphor of debt.

So if not debt, then what?  Just as the financial metaphor is used because of its fitness and readiness, as seen by its users, I am drawn to the metaphor of writing.  We can already make a case for the appropriateness when we listen to ourselves talk of “writing software,” “creating libraries,” “documenting our code,” etc.  The movement toward a metaphor of writing gets the backs of some of my colleagues up, who begin to hear overtones of “software as art” vs. “software as science.”  You’ll forgive me if I seem to sidestep this problem, since I don’t see the distinction as absolute.  Writing can be artistic, can be scientific, can move fluidly between the two.  We never expect writing proper to decide once and for all whether it is art or science, and nor should we have a similar expectation when we invoke it as metaphor.

What happens when we replace the image of the bank approved loan for that of the writer working on a text?  First we notice that the implied contract that existed between ourselves and an unnamed institution, which had the power to lend what we didn’t have, is replaced by something we can refer to in shorthand as the tradition.  The tradition is the context out of which we work.  Where the institution is legally structured, the tradition is historically structured.  To replace the institution with the tradition is to give up certain rights and responsibilities in order to adopt a more tentative and dynamic relationship with what has come before.

Writing still obliges us.  Writing is never free of the tradition, is never isolated, even, and especially, when it pretends to be original.  Writing-as-reading is only available via the backdrop of the writing that precedes it.  Writing-as-writing always points back to what has come before, whether by assuming the conventions of form or the language, using shared images and phrasing, or by creating itself out of, or on top of existing texts.

When we replace the idea of capital obtained through borrowing with the availability of the constellation of ideas, forms, images, language, etc. of the tradition, I think we arrive at an interesting place in which to think about the writing of software. Instead of thinking only about the product, and doing so in isolation, we start to use words like influence and reaction.  The process of writing software starts to look less like goal-oriented work, and instead emphasizes ‘ just writing something’, doing it with discipline, reworking what you’ve written, throwing things away, quantity over quality tempered with merciless editing and being willing to start over (again).  Software-as-writing also looks a lot less assured and professional while it’s being created.  It flounders, grows out of experiments, moves fast then slow, gets stuck at critical sections.  It is always drawing on what one knows or is seeing in other similar writing.  The idea that it gets easier, that you can master it, that it’s just a matter of “time plus materials”–that’s what comes of thinking about this like building houses.  But it’s not like a house.  It’s like a book, like an autobiography: it has to be lived and written simultaneously.

Above all, software-as-writing helps to humble you.  You’re not paying down a debt you can measure.  Instead, you’re working against the limits of yourself, of the language, and of the tradition.  You are necessarily outmatched and under prepared.  If you take your eyes off your empty emacs buffer long enough to notice the company you’re among, it can feel hopeless some days, and inspiring to be with them the next.  And you’re never done.  You have to decide to stop at some point, which isn’t the same as working off a fixed cost.  There’s no good way to measure a lot of what lies before you when you start.

Software-as-writing is just as flawed as technical debt, perhaps more so.  However, it more closely resembles what I’ve come to understand about the process of creating software.  It mimics my existence and experience working on big software projects.  It’s no more a universal than is the experience of writing is: it looks quite different to different writers.  But all of them will agree that it’s hard.  It’s hard and it’s endlessly inspiring work.

“The original is unfaithful to the translation.” –Jorge Luis Borges

A post with this title could take me one of two ways, and tonight I’m going to follow it down the road paved with silicon.  I had a guy tell me this week that the holy grail of software is what he called “freedom from translation”  (once again I’m going to leave the literary opportunities in that phrase for other posts, but don’t think I didn’t want to).  The world he envisions is one where you can take functional specs and have that get reliably turned into software.  It’s the fantasy of CEOs and CIOs the world over.

Regardless of what this says about me, I’m going to come out and admit to you that what gets me most excited about computers is the exact opposite–I love the delicate game of translating things from one layer to another.  For example, I love RFCs and have implemented almost all of the mail server RFCs (I stopped with MIME for reasons that will be obvious if you ever read them), and I did it all simply for the joy of it.  I know, it’s sick.  I can’t help myself.  I find the work of transforming one language, grammar, or protocol into another endlessly fascinating.

I can remember the day I first discovered this love (or became sick, as the case may be).  I was a second year CS student, who had to complete an assignment to add a new feature to a toy LISP implementation written in Pascal.  I had never really thought about the fact that I could extend the language from underneath–I was used to extending LISP from within LISP, which is the more obvious choice.  But as I started to work, I became enamored with the work of understanding how one programming language could sit comfortably on top of another.  It’s such an obvious thing when you’ve gotten used to thinking this way–all of software is just translation and reduction–but it was a brand new personal revelation to me at the time.

I’m enjoying watching my students go through the same process as they work on porting Processing from Java to JavaScript.  For example, Andor ran headlong into it today as he tried to sort out the proper boundary between code in the library vs. users of the library.  A week ago, another student was struggling to understand how to map Java’s method overloading onto JavaScript.  “What do you mean I have to use the arguments object instead?”  When the problem is viewed as being one of mirroring vs. translating, it always results in frustration.  One can see the heritage of Java in the design of the Processing API most clearly when you move away from it.  Translation gives you that critical distance and perspective.

Translation, if you are to do it properly, requires you to come to terms with the spirit of the original.  Expecting 1:1 mappings between two things is necessarily going to end in frustration.  What’s required is a creativity to see the essence of the original constructed from the pieces of the new.  There is almost never a single way to do it because while the interfaces might remain identical, the bodies never can.

I blame Steve Lee for the fact that I’m having to write this.  Previously I wrote an account for my students about what it’s like to fix a bug in an open source context.  The occasion of my post was a bug related to the use of a deprecated (and memory leaking) OS X API call in Thunderbird.  I was primarily interested in drawing attention to the way I had done the work, namely, to the way in which it had been a community effort vs. a singular idea that had lept fully born from my head.

Steve wrote a nice analysis of what I had written, and then made an interesting further observation:

I will make one point. Dave also learned  something of the kind of real world messiness and compromises that often have to be made when dealing with existing code and many complex requirements. Messiness such as complex build systems, a mixture of languages, incomplete support for platforms . In the relatively isolated academic world of the classroom you can often get by without having to consider such constraints and dubious architectural decisions such as ‘just copy the code into my file, and later, when we move to 10.5+ support, remove it’. The complexities of the real world can only be learnt by engaging with real developers on a real project. Open source projects provide an ideal place for students to learn important skills whilst contributing their energy.

Well, how right he is.  On Friday my work was approved by my reviewers (with minor corrections) and then checked-into the Thunderbird source tree.  I smiled and started my weekend.  Success.

Failure.  This morning I woke-up to find that my fix had been backed-out because it was causing our 10.4 builders to break.  The NSDockTile type I’d used for the 10.5 code paths was not defined as part of the 10.4 SDK, and without it, we can’t build this code.  I made myself some coffee and pondered how to deal with this.

The first thing to note is that I had no idea how to fix it.  I had some guesses, but nothing solid.  So I did what you do when you have a problem like this; I went on irc and idly described my problem, and that I had no idea how to fix it.  Two hours later the answer came.  Ted mentioned that I could consider a dirty trick, and use the Objective-C generic type, id, instead of the specific NSDockTile.  I made the change, and did a simulated 10.4 build (I only have 10.5).  Now I have a dozen new warnings due to using a generic type, but no errors, and once again a working build!

As Steve points out, there are no easy solutions to a lot of these problems.  They are, by definition, real world problems that require real world answers.  The most important thing to note about the real world here is that it is populated with people.  To work on open source is to work in community, and to ask for and accept help at every step of the way.

I’ve been spending a lot of time lately thinking about 3D in the browser.  It’s to the point that I have to blog about it, and try to get it out of my head and onto the web where it belongs.  Part of the reason I’m writing this tonight is that my colleague, Cathy Leung, has just put up a demo so awesome I’m compelled to share it (video here):

She put the video together after this article was written about her work to make 3D accessible to web developers via C3DL.  Cathy has been working with a team of students at Seneca College for the past few years, focused on an experimental 3D technology created by Mozilla.  Her work proves how valuable 3D in the browser can be.  I think a lot of people misunderstand its significance: “Doom in the browser?”  Sure, but it’s way more than that.  There is no shortage of tea pots on the web these days, as various browser vendors start to show-off early releases of WebGL enabled builds.  However, Mozilla has been at this game a long time.  I know because we’ve been using their stuff as long as they’ve been building it.  And it’s really reached a new level now.

As Mozilla pushes WebGL further, and Cathy continues her work on C3DL, I’m focused on another project to harness the power of 3D in the browser.  Together with Al MacDonald, I’m leading a Mozilla Foundation project to complete the work begun by John Resig to port the Processing language to JavaScript (aka processing.js).  The processing.js port, while unfinished, is already amazing.  Imagine if we took eight students, finished it, and added 3D support from C3DL?  I know, exactly.

Part of what makes me so excited about all this work is the deep intersection of things I love.  I’ve long been a fan of the work of Processing creators, Ben Fry and Casey Reas, ever since they were part of the Aesthetics and Computation Group.  I’ve always thought that their work belonged on the web instead of on the desktop.  At the same time, my own work with Mozilla and the open web has proven to me the need for richer ways of working with things like open data.  The web is at an interesting point in its evolution.  We now take for granted that it can do what was once only possible via desktop apps.  Looking forward I can already see a time when the web will also be the proper medium of artists, designers, data visualizers, and others pushing the limits of the second and third dimensions.  I’m thrilled to be a small part of this effort now.

If you’d like to get involved with any of the work discussed above, please do get in touch with me.  The most exciting aspect of everything I’ve told you remains that it’s all community developed, from Mozilla to C3DL to processing to processing.js.  That’s how you build the software stack of the future.

Curtis Bartley has a fantastic post up describing his use and abuse of the C++ preprocessor:

A few months back I got this wild idea that you could insert trace-logging code (not jit-tracing, that’s something else) into more or less arbitrary C++ by redefining certain C++ keywords as macros.

He goes on to describe how he redefines if, for, switch, and do.  In the process he uses the highly useful __FILE__ and __LINE__ macros.  I love this.  All of my work on DXR to extract every last drop of semantic info from the Mozilla source and build relies on shenanigans just like this.  I’ve had to use, abuse, rewrite, and hack our build system, preprocessor, xpidl, JS preprocessor, C++ code, etc.  You can’t be afraid to bend your tools in order to have them fit new uses.  Open tools and source code aren’t just open to study and improvement; they are also open to new uses and re-imagined purposes.

I for one hadn’t thought to do what he’s done here, and I plan on keeping the idea in my back pocket as I continue my work to add more data to DXR.  Thanks, Curtis!

UPDATE: apologies to Curtis for calling him Chris, corrected.

When I teach open source development, the very first thing I do is get students blogging.  It’s a trick I learned from Chris.  Last week we spent the entire week learning to use blogs, blog planets, wikis, irc, newsgroups, teleconferences, twitter, etc.  Why take so much time teaching students how to use that many parallel communication channels?  Shouldn’t we be teaching important stuff like licensing first?  No, I don’t think so.

Open source development is globally distributed, collaborative and community based work.  You can’t do it at all without understanding this.  Open source means working in a community, and working in a community means that you have to go where the community is.  In the case of Mozilla (and pretty much all large open source projects), you have to get on the web and really learn how to use it.  Mozilla uses just about all of the web in one way or another.  My experience is that students coming into the course use a fraction of it.  So our first job is to fix that and teach them how the web works.

So we get them blogging day 1, because blogging is at the heart of what the web is all about.  This week I’ve been reading student posts as they learn how to write for the web.  I spent a few minutes at the start of class just scrolling through all the posts, and asked them what they noticed.  Nothing really stood out to them.  It just looked like a lot of text.  The very first thing I noticed was exactly the same thing, or more specifically, that their posts were all in black.  There wasn’t a link to be found on any of them.

Learning to write for the web takes time.  Like all good writing, it is informed by reading, and before you can really learn to write for the web, you have to start reading it.  When you do, you notice that the web is not named accidentally: the web is lots of loosely connected things, with space in between for yet more connections.  It’s perhaps too obvious to say this, but reading these posts, I realized that the obvious is only obvious when you’ve come to know it.  The web isn’t a set of destinations, or a collection of content.  It’s a provisional series of paths.

Writing for the web means learning how to do two things well.  First, it means learning how to respond to things you read (which, of course, implies reading).  The web is an ongoing conversation and evolving mashup.  You know you’re doing it right when your starting point for writing is a reflection on something you’ve seen somewhere else online, or something in the real world you’re pulling online.  The primary mode of expression on the web is personal response.

The second thing you have to do is write yourself into the web.  This means using links.  Not only do you need to respond, you need to provide a way back to your sources.  Response doesn’t negate the need to read the whole thing; it makes the original even more important by layering further readings on top of it.

I’ll leave you with a quotation from a recent post by James, who does a better job than me showing how this works:

The recent series of posts here about learning, thinking and education were triggered by my friend Luke Hill’s post, which then led me to a post by Dave Humphrey, who was referencing a post by Eugene Wallingford, who was inspired to write in part because of a conversation on Twitter (which was initiated by one of his students). As a result of the dialogue, I now find myself reading the blog of an elementary school principal in Windsor as well. The internet is an amazing thing, kids. This is yet another classic example of “blogosphere learning” that I was contemplating earlier: this is now a conversation of hyperlinks, informed by unique geographies and contexts, providing a platform for discussion that could not exist apart from the technological engine itself.

Exactly.

A big thank-you to Jesse Keating for being a virtual guest in our SBR600 Software Build and Release class via teleconference last Thursday! Jesse is the Release Engineer for the Fedora Project and candidly discussed his role in getting Fedora into the hands of millions.

With his permission, a recording of the interview is available.

You need a browser that supports the <audio> tag to play this directly in the browser. Consider updating to Firefox 3.5 or higher.