Planet Mozilla Education

Building an add-on for Fennec (mobile Firefox) can be a bit tedious. We release desktop versions of Fennec that allow developers to test and play with their add-ons without the need for a mobile device. However, there are a few things that the desktop versions of Fennec do not expose: Performance characteristics of running on a mobile device; and the affect of small screens and high DPI.

I have blogged before about the potential performance issues and we have created some documents to help developers watch out for problems. I’ve blogged about mobile screen sizes before – about how you can use CSS to handle different sizes and orientations. This time I wanted to make the point about images sizes and the effect of DPI on fixed sized images.

On the desktop version of Firefox, 16px images are used for many of the UI elements. The trend in mobile device screens is big screens and high DPI. The DPI on desktop monitors has been below 100 for many years. Recently, we are finding monitors and laptops with higher DPIs. However, mobile devices can have displays with above 200 DPI, some even hit 300 DPI. Even the crappy iPhone display has 160 DPI. Using a 16px image on a 200 DPI (or greater) display will look tiny. It also has usability problems if the image is part of a touchable element. Fennec tries to keep touchable UI elements at ~ 6mm.

With the DPI issue in mind, add-on developers should really never use 16px images unless you are sure Fennec is running on a low DPI device. The Fennec UI uses 32px images for all favicons, list images and button images on high resolution screens. You can use the same CSS media queries I blogged about to control the images used in your UI:

/* high-res screens */
@media all and (min-device-width: 401px) {
  #myimage {
    list-style-image: url(chrome://myaddon/skin/images/cool-image-32.png);
  }
}

/* low-res screens */
@media all and (max-device-width: 400px) {
  #myimage {
    list-style-image: url(chrome://myaddon/skin/images/cool-image-16.png);
  }
}

You should not hard-code image URLs in XUL. This is considered bad practice:

<image src="chrome://myaddon/skin/images/cool-image-16.png"/>

Also note that the Fennec CSS is designed to stretch some element images to 32px. If you use 16px images for things like favicons or search providers, the result will be a pixelated mess.

November 06, 2009 10:31 PM

To help spread the word about the Jetpack for Learning design challenge, I worked-up a design for a Jetpack for Learning t-shirt for Second Life avatars. But that didn’t really do justice to Sean Martell’s nifty Jetpack design.
So… since almost anything is possible in Second Life, an actual flyable virtual Jetpack seemed like a much better idea.

<object height="344" width="425"><param name="movie" value="http://www.youtube.com/v/dxin2fDNnHg&amp;hl=en&amp;fs=1&amp;"><param name="allowFullScreen" value="true"><param name="allowscriptaccess" value="always"><embed allowfullscreen="true" allowscriptaccess="always" height="344" src="http://www.youtube.com/v/dxin2fDNnHg&amp;hl=en&amp;fs=1&amp;" type="application/x-shockwave-flash" width="425"></embed></object>

Thanks to Sean for the inspiring design!

Now if we can just get Mozilla Marketing to make Jetpacks like these available in the real world Mozilla Store!

November 06, 2009 08:24 PM

<script id="fedora-banner" src="http://fedoraproject.org/static/js/release-counter-ext.js?lang=en" type="text/javascript"></script>

Fedora 12 is almost here!

For the past several releases, we've held a release party in Toronto, complete with freshly-burned discs and origami disc covers. This time around, we'd like to invite all Toronto-area Fedora users to instead come out to FUDCon Toronto 2009 (where, in addition to great presentations, discussions, and hack sessions, I'm sure there will be real pressed discs with printed labels and real sleeves!).

Please help us get the word out! Point your friends, colleagues, and neighbours to http://tinyurl.com/fudcon

November 06, 2009 02:30 PM

Sigh. The time has come. I'll try to develop a more detailed post mortem, might create some content for a small bit of a thesis.
Partly in an effort to find a memory leak, way back in March I went about splitting the Bittorrent XPCOM work into separate reusable components. With hope, things like BirdTorrent could make use of these components, as the code is reliant on Mozilla's platform rather than any direct system calls.
Things attempted:

• Splitting the work into parts eg. Server, PeerFactories, Torrents, Bencoding library, BitTorrent Wire library, BitTorrent Utility library
• One step build
• Testing of individual components

These didn't go well. Things didn't go well at all. The fact that the last release of something usable was February, and it's now November, isn't a particularly thrilling fact. Pretty much each task I've gone along with in that time has stalled at some point, so now my project has more loose ends than functioning ones. There's been times when I've thought it might get better, but I don't really have the support needed for this development (or not willing to ask for it, because it needs too much). It's damn irritating, but at this point I think fixing what's broken would take more time than just starting again.
My aim is to let the current work die. Start afresh, and as it goes I hope to pick through the bones for what may be used, without inheriting the bits that caused this collapse.

November 06, 2009 08:54 AM

November 06, 2009 12:09 AM

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.

November 05, 2009 08:15 PM

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.

November 05, 2009 06:19 PM

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.

November 05, 2009 05:28 PM

November 04, 2009 03:57 AM

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.

November 04, 2009 03:16 AM

November 03, 2009 12:03 PM

November 01, 2009 11:32 PM

October 31, 2009 03:01 PM

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.

October 30, 2009 09:51 PM

Today Joe Drew, Olli Pettay, and I have gotten Mobile Firefox (Fennec) working with a separate process for rendering. It’s a significant achievement, because even though we had to hack out some Fennec features, it’s already a fairly functional browser. Olli made a screencast showing the browser in action:

<video controls="controls">
<source src="http://benjamin.smedbergs.us/blog/wp-content/uploads/2009/10/mp_fennec_simple_demo.ogg" type="video/ogg">
I’m sorry; your browser doesn’t support HTML 5 video. Go get one that does.
</video>

Getting Fennec working was difficult partly because the mobile Firefox code uses a different drawing system: instead of displaying a native scrollable widget, the mobile code uses a cache of “tiles” to display the web page. This allows them to display certain kinds of content over the web page, as well has have better control and speed when scrolling, zooming, and performing other interactions.

In order to get all this working with multiple processes, the group attacked pieces of the problem separately. Joe Drew implemented a new method on the canvas element: asyncDrawXULElement. This call, very similar to drawWindow, will asynchronously ask the content process to draw a tile (or part of a tile).

Olli implement various interaction fixes: forwarding mouse events from the tiles to the content process, forwarding some important events such as MozAfterPaint from the content process back to the chrome process, and fixing widget focus in the embedded browser so that keystrokes are sent to it correctly.

Finally, I modified the Mozilla frame loader and subdocument frame such that “remote frames” could work correctly even without a docshell. I then hacked up the Fennec sources so that it would also work without a docshell, mainly by commenting out the security UI and zoom-to-element features which require additional information from the content process.

Now that it’s working, we hope to be able to bring additional developers in to fix up the features which we hacked around, fix DOM features which are currently broken such as link targeting, and start getting much better measurements for interactive performance and memory usage.

October 30, 2009 06:10 PM

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.

October 29, 2009 12:40 AM

In Firefox, you can make the page text larger and smaller by holding down the Control key and rolling your mouse scroll wheel up and down. Before continuing to read, I want you to think about which direction makes more sense: should scrolling down make the page get bigger or smaller?

My natural intuition is that I should scroll down to make the page get bigger. This doesn’t match the default Firefox setting, or my wife’s natural intuition. For a long time I’ve wondered why I would have such a strong feeling that scrolling down would make the page bigger. Today, while doing morning browsing activities, I’ve finally figured it out.

When the page gets bigger, the bottom of the page scrolls down. The opposite happens when the page scrolls up. So I’ve been using a visual cue of the page scrolling for the scroll wheel. My wife thought about this and said “I’m not a visual learner, so I never thought of it that way. I just thought ‘up is zooming in’.” (She’s a teacher, can you tell?)

I have the exact same problem in Google maps: I think of it as “zooming down to see something” and consistently get it wrong. I’m not proposing that we change the default: my intuition is probably a strong minority. I just wonder whether there are other people like me, and whether there are common UI interactions where visual cues and logical cues don’t always match up.

For those of you who care enough, you can change the default in Firefox. Navigate to about:config in your URL bar, click through the scary warning, find the pref “mousewheel.withcontrolkey.numlines” and switch the value from “1″ to “-1″.

October 28, 2009 02:06 PM

October 28, 2009 02:02 PM

October 26, 2009 07:12 PM

October 26, 2009 06:21 PM

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.

October 26, 2009 02:05 PM

October 25, 2009 09:46 PM

October 25, 2009 01:40 PM

<@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:

October 24, 2009 03:51 AM

With bug 523817 fixed, you can now write an interface like this:

  void getSomething([optional] out unsigned long count,
                    [retval, array, size_is(count)] out whatever outArray);

and js consumers can do:

  var myArr = foo.getSomething();

to get an array without having to have a dummy argument for the length. Word of warning: this only works if the length has no required non-retval arguments after it, so put that length at the end, right before the retval array.

October 24, 2009 12:19 AM

October 23, 2009 07:28 PM

October 23, 2009 05:55 PM

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.

October 21, 2009 06:30 PM

The best lunches are those that provide more food for thought than food for my already overweight frame.

My favorite lunches used to be those put on by Lunch 2.0 which mixes lunch with a presentation or a panel discussion at an interesting technology company somewhere around the valley. They almost always attract an interesting crowd for networking.

I say “used to be” because Lunch 2.0 has been dormant for a while, and I’ve discovered a new favorite. Oddly, it seems to be the best kept secret in Silicon Valley!

Mozilla.com, the folks that do the awesome Firefox browser, are not just an open source company, but a pathologically open organization from top to bottom. Every Thursday, Mozilla Labs has an open Design Lunch. It’s a bring-your-own-brown-bag affair open to anyone. Topics vary from week to week, but it’s usually design issues for future versions of the Firefox browser or one of the other Mozilla Labs Projects.

The format is a presentation from some of the best designers on the planet and an open discussion, so you not only get a peek into the future, but a chance to change it. I highly recommend joining the discussion. Pack a lunch or order one online for pickup downstairs at Le Boulanger.

Mozilla is at 650 Castro Street in Mountain View. Check the Mozilla Wiki for exact times (usually 12:30) and topics. Be aware that topics are often not posted until the day before, and sometimes even as late as Thursday mornings, so check back often.

October 21, 2009 04:30 PM

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.

October 21, 2009 01:55 PM

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.

October 20, 2009 03:38 PM

October 19, 2009 07:16 PM

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?

October 19, 2009 07:11 PM

The rain turned to snow a few hours back. Too bad it's too warm for it to stick... First snow of the season, though!

October 18, 2009 09:10 PM

I've recently been running into a number of "benchmarks" where some rendering engines achieve better performance by simply doing the wrong thing because the right one would be "too slow". Here's a good example:

    // FIXME: This check is good enough for :hover + foo, but it is not good enough for :hover + foo + bar.
    // For now we will just worry about the common case, since it's a lot trickier to get the second case right
    // without doing way too much re-resolution.

and here's a testcase demonstrating that in this particular open-source rendering engine performance in selector matching and dynamic change handling is achieved at the expense of correctness:

  <style>
    div { color: red; }
    .foo + div + div { color: green; }
  </style>
  <body onload="document.getElementsByTagName('div')[0].className = 'foo'">
    <div></div>
    <div></div>
    <div>Text</div>

This is not exactly an isolated incident; a number of the performance issues I've run into recently in Gecko have had to do with correctly handling edge cases that this particular open-source engine happens to just not handle. I guess it's easier to do well on tests if you cheat.

More interestingly, Opera's performance on this sort of thing is still quite good, and I have yet to discover them cheating...

October 18, 2009 06:39 PM

So bug 227305 finally landed, and so we can finally expect to be able to drag and drop messages from Thunderbird to the desktop or to a file manager window when Thunderbird 3 gets out.

But here’s the catch - it only works with ONE message. Multiple drag-drop (out of Thunderbird) doesn’t work, and as expounded in numerous earlier posts, I can’t make it at this point - because as far as we can tell Core (that is, the core XUL platform) doesn’t presently allow it. Phil has filed a bug on this. When that gets fixed up (probably not soon, unfortunately), I’d be happy to do whatever front-end work that may remain to get multiple drags working properly.

October 17, 2009 08:35 AM

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.

October 16, 2009 01:33 PM

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.

October 16, 2009 03:42 AM

October 15, 2009 12:21 PM

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!

October 14, 2009 09:18 PM

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.

October 14, 2009 06:41 PM

I recently watched Rich Hickey's presentation on Persistent Data Structures and Managed References. I've been impressed with Rich Hickey's ideas on managing state since I first read about it, and this talk didn't disappoint. He begins with what he calls a “little bit of philosophy”. It's essentially an introduction to the ideas he uses in thinking about concurrent programming, and thus those that guided his designs for Clojure. I haven't done much concurrent programming nor really any Clojure, but a lot of these ideas resonated with me and I think that they can inform our understanding of programming in general.

The concepts he defines and uses here are Values, Functions, Time, State, Processes and Identity. I've capitalised these words to signify that I'm referring to Rich's definitions, as I currently understand them. Here's a quick summary:

Values

Values represent data in the problem domain that doesn't change, e.g. 1, π, true, '의', ♣, m, etc. Values may be composites of other Values, e.g. [1,2,3,4] or {red: 0, green: 127, blue: 255}

Functions

Functions are simply an abstraction of expressions on Values, e.g. x => x + 1, or (a, b) => a && b

The expression is constant, though the input Values used may differ. By definition, however, the output is always the same for a given input. These are often called pure functions, or mathematical functions.

Neither Values nor Functions have any notion of Time.

Time

Time is about before/after relationships. It describes the sequencing of events, and thus it is always relative. Time is observable through changes in State, i.e. if asking the same question at a later Time gives you a different answer. The concepts of Time and State are intrinsically linked.

Processes

Processes are programs with State that changes over Time. This gives them observable effects, which is ultimately required in order for them to be useful.

For example, suppose the question were

“What are the files in this directory?”

and the program were

$ mktemp new_file.X

the answer to that question should be different before and after executing the program. mktemp causes an observable change in the State of the filesystem.

Identities

But how do we manage this State safely, particularly in the presence of concurrency?

Clojure's answer is:

State is a Value of an Identity at a Time.

An Identity is a single conceptual entity that takes a sequence of Values over Time. There is a causal continuity between these Values - each one being some Function of the previous. But in changing the Identity's Value, we don't forget that the Identity had a different Value before, nor do we assume that the current Value is the Value it always had. There is an explicit understanding that an Identity's Value is only meaningful in the context of a particular Time.

Rich Hickey summarises this point with: “Things don't change in place”, because “place includes time”.

Finally

Rich goes on to talk about how these ideas are implemented and employed in Clojure, which is interesting. I'd definitely recommend watching the whole talk, even two or three times if necessary :-)

October 12, 2009 04:57 PM

Mark Surman and others at Mozilla have been mulling over Drumbeat, an effort to promote awareness of the benefits of an open web. In his most recent blog post, Mark asks “what concrete things could Mozilla and Drumbeat do to support people creating civic and social value on the web?” …and he has posted a survey looking for your input.

The open web is a difficult concept to convey to the average browser user. As both the user interface designers and the support team at Mozilla will tell you, the average Firefox user has trouble distinguishing where the browser stops and the web begins. “Openness” is an even more abstract concept for most web users.

This leads me to believe that giving the user a good WIFM (”what’s in it for me”), argument is the best way to illustrate the advantages of the open web. The recent Internet Health Check initiative that accompanied the Firefox 3.5 release is an example of what’s in it for the average user. But, internet security is an issue fraught with technical complexities that make the eyes of even advanced browser jockeys glaze over.

I’m beginning to think that the easiest way to illustrate the advantages of the open web to the largest number of users is to take up the banner of the open data movement. It’s pretty easy to show how the availability of public data for remix can enable great things on the web, and the lack of it can stifle innovation on the web.

The Open Data Foundation, the Open Knowledge Foundation, and OpenGovData.org all have definitions of what constitutes “open” data. But, David Eaves said it best in his Three Laws of Open Government Data:

1. If it can’t be spidered or indexed, it doesn’t exist
2. If it isn’t available in open and machine readable format, it can’t engage
3. If a legal framework doesn’t allow it to be repurposed, it doesn’t empower

Eaves calls these “Find, Play and Share”. It’s a simple concept that anyone can comprehend. If we can show people how being able to find, play with, and share more data can make it possible for them to do more things on the web, we will make more non-technical users allies in the open web movement.

And the open data movement needs all the help it can get right now. Even in free countries there are pressures coming from government institutions to lock up data collected, cataloged, and stored using public funds.

In the UK last week, the Royal Mail used the threat of legal action to shut down EarnestMarples.com a website named for the British Postmaster General who created the postal code. The site had a postal code lookup API that was freely available. Fortunately, at least one major UK newspaper, The Guardian, is championing the open data cause. I believe we should take advantage of the media focus in the UK and lend Mozilla’s voice to the chorus in favor of open data.

In the US, the mainstream media is less aware of the open data issue. As a consequence we have also been losing battles for free data. Zip code data, including both post office geolocation data and zip code boundary data is available for a fee from private sources, but does not appear to be available on data.gov or the US Postal Service web site.

Post 9/11 there have been actions such as the U.S. Department of Defense withdrawing the Defense Aviation Flight Information File (DAFIF) from public access. The DAFIF is a database of airports around the world with runway and radio frequency information of critical value to aviation safety. While there was a comment period preceding the withdrawal of the DAFIF, there was no media coverage, and too few people commented to persuade the government to leave this critical resource openly available as it had been for more than a quarter of a century. The open data movement in the U.S. was neither large enough, nor organized enough, to affect the outcome.

More awareness of the value of open data on the part of both the public and lawmakers might have prevented these examples of data being locked up by government. Mozilla can help by becoming a focal point for those interested in opening the web by opening data.

It’s encouraging to see that the Australian Government 2.0 Taskforce, runs data.australia.gov.au a government website serving government created data sets offered under Creative Commons licenses. They are currently sponsoring Mashup Australia, a contest offering more than $20,000 in prizes for data mashups using data sets hosted on the site.

The Australian experience provides a model that we could use to point out the advantages of open data to media and lawmakers worldwide. Sadly, airport information is notably missing from the Aussie data sets. Australian government pressure to remove public access to Australian airport data was believed to be one of the reasons for the DAFIF withdrawal in the U.S.

In conclusion, the open data issue is one that provides easy-to-understand examples of how a more open web is more useful to everyone. I believe it offers one of the best places to focus Drumbeat efforts to open the web. As a suggestion for a first step, how about putting up a page structured like Planet Mozilla that combines feeds from open data organizations and bloggers around the world?

October 12, 2009 12:00 PM

October 09, 2009 11:54 AM

“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.

October 09, 2009 02:06 AM

October 08, 2009 10:20 AM

The Mozilla Mobile Team is happy to announce the release of Fennec 1.0 beta 4 for Maemo. As promised, we have been working hard on user experience and UI polish. Here’s a few changes you’ll find in this release:

• Improved touch-friendly theme
• Improved panning and zooming performance and behavior
• Add search providers from the site identity panel
• Manage search providers from the Add-ons Manager
• Simplified the Download Manager (removed searching and find file on disk)
• Streamlined the bookmarking process
• Simplified the bookmark management
• Popup notification when background tabs open
• Bookmark list now displays the URL and tags associated with a bookmark
• Added a product information page (about:fennec or use the button in Preferences)
• Support for add-ons options in the Add-on Manager
• Support for updating add-ons
• Support for the HandheldFriendly meta-tag (support for the viewport meta-tag is coming)

In addition to the changes, there are plenty of bug fixes and enhancements going on under the hood. The tile system we implemented for beta 3 is still providing benefits and areas where we can increase performance.

Speaking of new things, Nokia released Maemo 5 and the very cool N900 device. We have spent some time making sure Fennec runs well on the N900. Some of the changes include adding task and close buttons to the Fennec URLbar when in fullscreen and making some theme changes to handle the default N900 themes.

If viewing on your N900 or N810, install from here. In addition to Maemo build, you can also download desktop builds for Windows, Mac, and Linux.

October 06, 2009 11:23 PM

Mozilla Labs has a plug-in for the awesome Firefox browser that helps them collect information about how people use the browser. As with all things Mozilla, the Test Pilot plug-in is open. It shows you all of the data it has collected and lets you decide whether or not to send it along to the Mozilla Labs team. Also, the folks over at Mozilla Labs are careful not to collect any personally identifiable information about individuals.

Mozilla takes openness one step further. Unlike data collected by that other browser company, the data collected by all of the Test Pilot plug-ins on the planet is freely available for download. This means that if you’re a Math or Statistics teacher, you can build lessons around Test Pilot data-sets from the real world that your students helped create by having installed the plug-in. …or you can just look at the interesting ways that others interpret the data-sets.

Take a minute to visit the Test Pilot web page and download the plug-in. Encourage your students and colleagues to do the same. You’ll be helping to make future versions of Firefox work better for you and your students, as well as making the open web a better place for all of us.

If you’re a Math teacher who has built a lesson plan around Test Pilot data, please post the lesson plan on Curriki.org, the open curriculum wiki, and leave a comment here so we can spread the word to other teachers.

October 06, 2009 07:56 PM

October 06, 2009 02:07 PM

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.

October 05, 2009 07:05 PM

October 02, 2009 11:22 AM

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):

<object classid="clsid:d27cdb6e-ae6d-11cf-96b8-444553540000" codebase="http://download.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#version=6,0,40,0" height="344" width="425"><param name="allowFullScreen" value="true"><param name="allowscriptaccess" value="always"><param name="src" value="http://www.youtube.com/v/n3tQd7UT09k&amp;hl=en&amp;fs=1&amp;"><param name="allowfullscreen" value="true"><embed allowfullscreen="true" allowscriptaccess="always" height="344" src="http://www.youtube.com/v/n3tQd7UT09k&amp;hl=en&amp;fs=1&amp;" type="application/x-shockwave-flash" width="425"></embed></object>

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.

October 02, 2009 02:48 AM

October 01, 2009 12:24 PM

September 30, 2009 08:32 PM

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.

September 30, 2009 04:17 PM

Having become more interested in functional programming in the last year or so, I've been attending the Sydney Functional Programming group when I get the chance.

After a chat about my Rhino GSoC work at the post-talk drinks, I was asked to present about it at the following meeting. So I did. It kind of became three talks combined, firstly about Rhino, and particularly the features it has the other JavaScript implementations don't, then about EcmaScript 5 and finally about my experiences with Google Summer of Code.

The slides are here. Enjoy.

September 26, 2009 03:03 PM

Just for those who might have regularly checked up on my patch... (Ha!)
I have made an update to my patch which relocates text/messages to a localization file, allowing it to be translated if it gets added to the patch.

It can be found on this bug: https://bugzilla.mozilla.org/show_bug.cgi?id=413792

Thanks David for reviving this bug (So far still rather deserted but... a notification was given out right?)

Tony Lai

September 24, 2009 07:25 PM

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.

September 23, 2009 08:43 PM

September 23, 2009 06:44 PM

September 22, 2009 02:15 PM

I read the phrase “bearing witness” twice tonight.  It’s a phrase that has been going through my mind for the past three weeks.  During this same period I’ve been spending a lot of time thinking about Open Data.  They’re connected in important ways.

I seem to encounter the term Open Data everywhere these days.  People like David Eaves are writing about what it means in the context of civic spaces.  Greg Wilson is exploring it in an academic context.  Still others are thinking hard about questions of access.  Personally, I vacillate between thinking about it technically and philosophically.  Tonight I’m focused on the philosophy, and I’m concerned that we don’t really know what Open Data is, or how it works.

In order to get closer to an understanding, I’ve been focused on these two words and what they say.  Do we know what Open Data is?  What makes Open Data different from Data?  How does Open Data do what it does?  What is the nature of Open Data?  If we ask the web, it has some things to say.  Here’s Wikipedia:

Open Data is a philosophy and practice requiring that certain data are freely available to everyone, without restrictions from copyright, patents or other mechanisms of control.

But it goes on to say:

The concept of Open Data is not new; but although the term is currently in frequent use, there are no commonly agreed definitions

Besides Wikipedia, we find the Open Data Foundation, the Open Data Commons, the Open Data Consortium project, and many more.  They all have great examples of Open Data in the wild, boilerplate text for licensing, and other pragmatic information.  But for me, none of them ask, or try to answer, the difficult question of what Open Data actually is, and how Open relates to Data.

It’s a serious enough problem that I set myself the task of attempting to define it.  The result is this essay.  I don’t intend it as the final word on the subject.  It’s meant to get us started on the way to understanding Open Data, and to open a larger discussion about what it is and how to understand it.  My discussion is informed by the fact that I’m going to do the opposite of what most other people writing in this space do and ignore all instances of Open Data.  I’m not going to collect and distill examples from the wild into a general concept.  Rather, I’m going to put these two words–Open Data–on the table and take a long, hard look at them, and listen to what they say.

It’s too long to put down here, so I’ve written it up as a separate page.  You can read it here: Reading Open Data.

September 22, 2009 04:29 AM

I read the phrase “bearing witness” twice tonight.  It’s a phrase that has been going through my mind for the past three weeks.  During this same period I’ve been spending a lot of time thinking about Open Data.  They’re connected in important ways.

I seem to encounter the term Open Data everywhere these days.  People like David Eaves are writing about what it means in the context of civic spaces.  Greg Wilson is exploring it in an academic context.  Still others are thinking hard about questions of access.  Personally, I vacillate between thinking about it technically and philosophically.  Tonight I’m focused on the philosophy, and I’m concerned that we don’t really know what Open Data is, or how it works.

In order to get closer to an understanding, I’ve been focused on these two words and what they say.  Do we know what Open Data is?  What makes Open Data different from Data?  How does Open Data do what it does?  What is the nature of Open Data?  If we ask the web, it has some things to say.  Here’s Wikipedia:

Open Data is a philosophy and practice requiring that certain data are freely available to everyone, without restrictions from copyright, patents or other mechanisms of control.

But it goes on to say:

The concept of Open Data is not new; but although the term is currently in frequent use, there are no commonly agreed definitions

Besides Wikipedia, we find the Open Data Foundation, the Open Data Commons, the Open Data Consortium project, and many more.  They all have great examples of Open Data in the wild, boilerplate text for licensing, and other pragmatic information.  But for me, none of them ask, or try to answer, the difficult question of what Open Data actually is, and how Open relates to Data.

It’s a serious enough problem that I set myself the task of attempting to define it.  The result is this essay.  I don’t intend it as the final word on the subject.  It’s meant to get us started on the way to understanding Open Data, and to open a larger discussion about what it is and how to understand it.  My discussion is informed by the fact that I’m going to do the opposite of what most other people writing in this space do and ignore all instances of Open Data.  I’m not going to collect and distill examples from the wild into a general concept.  Rather, I’m going to put these two words–Open Data–on the table and take a long, hard look at them, and listen to what they say.

It’s too long to put down here, so I’ve written it up as a separate page.  You can read it here: Reading Open Data.

September 22, 2009 03:59 AM

September 21, 2009 05:46 PM

Next week in our Open Source Mozilla Development class, the students will be building Firefox from source, and learning about the Mozilla build.  In preparation for it, I worked on a couple bugs today, to get back into shape after a summer of reading books instead of compiler warnings.

Before I start my weekend, I want to take a minute to reflect on what the experience of working on, and within open source is like.  I write this for the benefit of my students, who are just getting started doing the same thing.  I’ll have much to say in the coming weeks about the importance of failure, and also how to succeed.  But both failure and success look the same from the proper distance–they are simply the attempt.  This is the story of what it’s like to make an attempt in the context of an open source project.

A while back I finished work to fix how Thunderbird does the message count on the dock icon (see bug 274688).  Since that fix went in, people have been using the new code in Thunderbird Nightly builds, and they’ve noticed some more bugs.  First, it appears that messages are being double-counted due to the new Smart Folder feature (see bug 516477).  I need to fix this before Thunderbird 3 ships, so I took the bug (e.g., assigned it to myself) and started looking at the code.  However, I got distracted throughout the day, and at one point read this neat post by Daniel Glazman on Planet Mozilla.

Daniel was interested in making it possible for XULRunner apps to put a number on the dock icon, and he mentioned that he had taken code from nsMessengerOSXIntegration.cpp.  I spend a lot of time in this file, and it instantly made me wonder how he’d done it, reminding me of another bug I need to fix related to our current drawing code, which leaks memory (see bug 508001).  I looked at his code and realized that he was going to suffer from the same memory leak that I am.  I left a comment in his blog.

The next day Daniel emailed me, and then posted his code.  Another person commented in his blog with details about how to do this using the new Leopard API, and then he posted a third version, which is really elegant and much more simple.  After looking at his code I realized that I couldn’t do what he’d done because it will only work on OS X version 10.5 and later (e.g., it won’t work on 10.4, which Mozilla still supports).  So I forgot about it.

Except, I couldn’t seem to forget about it.  What if I could use this same method?  I decided to do a test.  I took the current code, and his code, and merged them.  To do it, I had to call Objective-C from within my C++ file.  It’s possible to mix C++ and Objective-C/C++ (we do it all over the place in Mozilla).  What you have to do is make your .cpp file an Objective-C++ file (i.e., an .mm file) and then tell the build system about it.  In your Makefile.in, you have to add your file to CMMSRCS instead of CPPSRCS.

I made the change and did a test.  After some fiddling with the build system (it still wanted to build my .cpp because I hadn’t deleted the old file), I had a working Thunderbird.  When I ran it I saw the look-and-feel of a native OS X dock icon.  Now I was convinced I needed to do this for real.  But how to deal with the differences between OS X 10.4 and 10.5+?

I wasn’t sure, so I did what you do in open source: I a) looked at the other Mozilla source code for clues; b) asked some people who might know.  Looking through the code I saw lots of compile-time checks, but nothing at runtime.  I needed to know when the app started-up what version I was on, and therefore which API to use.  Next I tried asking on irc, in the #macdev channel.  It was almost midnight, but luckily three people were around, and they each had a different idea for me: 1) I could consider using nsToolkit::OnLeopardOrLater(); 2) I could try doing what was done for the wifi scanning code (e.g., try, fail, fall back); 3) try to add this version check to another bug that was doing similar things.  I read through all the options, and went to bed unsure of the best solution.

The next day I decided to ask two more people.  One of them was the person who would eventually review my code, so his opinion mattered to me.  The other was a friend who works for Mozilla and knows a lot about dependencies between various parts of the code.  I really wanted to use nsToolkit::OnLeopardOrLater(), but it isn’t exported (e.g., it’s an internal API, and the .h file is not accessible to my class).  They both suggested I just copy the code into my file, and later, when we move to 10.5+ support, remove it.

I made the change, and now the code supports both 10.4 with the existing drawing code, and 10.5+ with the new drawing API.  I’m quite pleased with it, and hope that it gets accepted by my reviewer.  Regardless of  what happens, I learned a lot through this process.  I learned how to mix C++ and Objective-C code, version differences between OS X APIs, build system tricks, how we do dynamic version checks in other parts of the code, etc.  I was also reminded how much faster you can work when you work in a community setting vs. on your own.  Through blogs, public source code, and irc I was able to get this done with only a couple hours of learning and work.  It was time well spent, both for Thunderbird and for me.

September 19, 2009 02:18 AM

September 17, 2009 06:03 PM

Okay, so this is one of those nerdy type posts, and it’s for my independent study at school.  Ignore it if you don’t understand…

(5:12:07 PM) ehenry5: alright, can you explain the general idea behind ispdb?
(5:12:07 PM) ehenry5: it sounds like it stores more than just the email connect info…
(5:12:25 PM) bwinton: What else do you think it stores?
(5:12:33 PM) ehenry5: i couldn’t gather all of that
(5:12:38 PM) ehenry5: but when i was searching ispdb
(5:12:45 PM) ehenry5: there was a lot going on
(5:12:51 PM) bwinton: Also, do you have a blog set up? Cause I’m going to ask you to post the results of this conversation.
(5:12:58 PM) ehenry5: sure
(5:13:30 PM) bwinton: Where is it (so that I can subscribe)?
(5:14:04 PM) bwinton: So, lets start with http://svn.mozilla.org/mozillamessaging.com/sites/autoconfig.mozillamessaging.com/trunk/hotmail.com
(5:14:17 PM) ehenry5: ok
(5:15:39 PM) bwinton: So there are a bunch of domains that it applies to.
(5:15:52 PM) bwinton: A name so that you can see what it is.
(5:15:57 PM) bwinton: And then the connection info.
(5:16:06 PM) ehenry5: right on
(5:17:26 PM) ehenry5: so that’s all that’s stored?
(5:18:03 PM) bwinton: For now, yeah. At some point we might need an “owner” field, to let people update their own.
(5:18:20 PM) bwinton: Or an “accepted” field, if we go with submission-and-manual-approval.
(5:18:32 PM) ehenry5: so what is the work that needs to be done on ispdb?
(5:19:24 PM) bwinton: Well, I’ve hinted at a bit of it.
(5:19:37 PM) bwinton: User submitted email configs.
(5:19:47 PM) bwinton: Unit tests. A lot of unit tests.
(5:19:48 PM) ehenry5: right
(5:20:09 PM) ehenry5: because it’s all django and you want to be sure that it runs smoothly
(5:20:36 PM) bwinton: Yup.
(5:20:55 PM) bwinton: There are also some fixes, suggested by AndyM, to make it more Django-y.
(5:20:55 PM) ehenry5: but the functionality is mostly working?
(5:21:12 PM) bwinton: Yeah, most of the functionality is mostly working.
(5:21:31 PM) ehenry5: what about in thunderbird
(5:21:37 PM) ehenry5: does it use it yet?
(5:21:44 PM) bwinton: Almost, kinda.
(5:21:48 PM) ehenry5: lol
(5:22:01 PM) bwinton: We’re about to release Thunderbird 3.0 beta 4, which has the autoconfig in it.
(5:22:09 PM) bwinton: beta 3 also did, but it wasn’t very good.
(5:23:47 PM) ehenry5: who is/has worked on that part of tb?
(5:24:03 PM) bwinton: Me!
(5:24:14 PM) ehenry5: and it comes full circle…
(5:24:31 PM) bwinton: Ta-da!
(5:24:37 PM) ehenry5: so, i take it you also have other things to work on too?
(5:25:17 PM) bwinton: Yeah. Some of what I’ve been working on is at: http://moxie.fligtar.com/thunderbird/3.0b4-blockers//sort:bugsFixed
(5:25:46 PM) ehenry5: okay
(5:26:02 PM) bwinton: And now that beta 4 is out of the developer’s hands, it’s off to the rc1 bug list.
(5:26:27 PM) ehenry5: so, what would be best case scenario for ucosp in this project?
(5:27:30 PM) bwinton: We get the user-submitted autoconfig working.
(5:27:34 PM) bwinton: With tests.
(5:27:44 PM) bwinton: And it makes it in to Thunderbird 3.1
(5:27:55 PM) ehenry5: where would the users submit their autoconfig info?
(5:28:02 PM) ehenry5: is that something that tucows was talking about?
(5:28:08 PM) bwinton: Not quite.
(5:30:03 PM) bwinton: So the grand vision is the user types in their email address. TB tries to get the config from the database. If it fails, TB makes some guesses and sees whether they work. If one of the guesses works, a button/dialog appears saying something like “Would you like to submit this info back to Mozilla Messaging to help other people on the same ISP?”, and if they click Yes, the config is sent back to our database.
(5:30:32 PM) ehenry5: okay
(5:30:52 PM) ehenry5: so, are you going to be working on the c++ side and we work on the python side?
(5:30:57 PM) bwinton: Tucows also wants to be able to make an HTTP call to add a new domain to our database when someone signs up for their email service.
(5:31:33 PM) bwinton: We’ll see. I think there is probably not enough work on the python side for everyone, so some of you will switch over to the client.
(5:32:02 PM) bwinton: (Which is really mainly javascript. After three and a half months, I think I’ve only made one change that touched a C++ file…)
(5:32:51 PM) ehenry5: interesting
(5:37:44 PM) ehenry5: so of the items you’ve talked about, what’s the priority?
(5:37:50 PM) ehenry5: er priorities…
(5:38:22 PM) bwinton: Tests first, cause if we don’t have those, we don’t know if it works or not.
(5:38:28 PM) ehenry5: right
(5:38:42 PM) bwinton: Then probably Andy’s fixes, cause they should be quick.
(5:39:17 PM) bwinton: And from there, we’ll see what the other requirements are. (I’m expecting those to take up the next couple of weeks at least.)
(5:40:04 PM) bwinton: (And hopefully after that, we’ll have some email from Tucows and DavidA, with more stuff to do.)
(5:40:11 PM) ehenry5: right on
(5:40:48 PM) ehenry5: so getting done for next week is any unit test or one specifically for ispdb (or django)?
(5:41:28 PM) bwinton: If you can run ispdb on your local machine, feel free to add a unit test to it.
(5:41:35 PM) ehenry5: okay
(5:41:43 PM) bwinton: If you can only run django, and have created a test app, write a unit test for that.
(5:41:58 PM) ehenry5: okay

September 16, 2009 09:59 PM

It’s a common misconception that the web isn’t a useful educational tool for very young students, particularly pre-readers. That is simply not true.

Over the last year and a half, I’ve been working on a project called Curiosity Clubhouse that uses computers, both in the classroom and at home, to help kindergarten students learn. It’s a web-based system that uses a collection of flash-based learning activities to help kids learn their letters and numbers and get started learning to read.

It came about after some conversations with an extraordinary kindergarten teacher named Barbara Brisson. Barbara, who has also worked for IBM and NetSchools Corp., is one of the most technology-savvy teachers I’ve ever encountered. She was able to put her finger on a number of issues that limited the utility of computers in the kindergarten classroom. There are 5 computers in her classroom and with 20 kindergartners in the class she doesn’t have the luxury of having everyone working on the same activity at the same time. The class is divided into several groups, and the groups rotate through different activities at tables and at the bank of computers. Typically a student is at the computer for 20 to 30 minutes before that group rotates to another activity.

Before our project, the following factors limited the effectiveness of the machines as learning tools for the kids:

• The learning activities she was using were at web sites spread around the net. Navigating using the address bar of a browser, or even a list of bookmarks was difficult-to-impossible for non readers who didn’t even know the whole alphabet.
• Many of these sites placed the mostly flash-based activities on pages with ads and other links to material that is not relevant to the specific learning activity. In the case of ads, these are often professionally designed to attract attention, and so they would seduce the students away from the intended activity. Once off-task, students often were unable to find their way back to the page where they should have been working.
• Making assignments by trying to maintain bookmark lists on multiple machines for groups of students with differing reading and math skill levels was at best arduous.
• The typical assignment takes less than 10 minutes to complete, and setting up each machine with the next assignment for each student meant that it required a minimum of two volunteer aids to keep 5 students (a quarter of her class) working on the right page. Rarely was that possible.

Curiosity Clubhouse, our experiment in the web for pre-readers has solved these problems and added additional capabilities that have resulted in improved end-of-year reading and math scores for Barbara’s kindergartners.

The core of the system is a web site written in PHP running on an Apache web server and a MySQL database. There are pages on the site for teachers, students, and parents.

On the pages there are web forms that let the teacher enter the class roster. In addition to the student’s name, the database holds the current reading level and math skill level for each student. The database also contains a table of the URLs for learning activities (called resources) selected by the teacher. Where possible, these are deep links directly to the activity SWF file, eliminating lots of extraneous links and ads. Each resource is rated with a minimum and maximum reading and math skill level for which the teacher deems it appropriate. There is also a table containing a list of each of the state curriculum standards addressed by each activity. (More about that later).

Another of the teacher pages lets teachers build assignments. Each assignment has a reading and math level range, and a start and end date. This makes it possible to program activities for each group of students for an entire school year if the teacher wishes. As students progress, the teacher can change the skill levels in their student record and they will automatically be presented with appropriate activities.

At the start of the school year each student is invited to choose a personal icon that will serve as their login to the system. There are more than 140 tokens like the ones above, so even the last student in the process has many from which to choose. This is important because the token must be memorable, so letting the child choose an image with which she or he feels a connection minimizes forgotten logins.

To set up a machine for use in class, the teacher (or an aid) logs the machine into the web site and selects which class is in session. The system is then ready for student login. It presents the screen you see above. All of the student tokens for the current class are displayed, and to log in a student simply clicks the token chosen at the beginning of the year.

Here we see the assignments page that greets Sue after she logs in by clicking on her personal token. She is presented three assignments from those selected by the teacher for Sue’s reading and math skill level. The images on the assignment tokens are chosen by the teacher when the assignments are made, and illustrate letters and numbers currently receiving emphasis in the reading readiness lessons. Sue picks an activity to work on by clicking on one of these assignment tokens and is presented with her first work page.

Work pages present the learning activity in a simple screen with minimal distractions. The two assignment tokens that were not selected on the assignment page appear on the left. When Sue finishes the fish counting activity, she can click on one of these to move on to the next assignment. If she finishes all three assignments before the work period is over, she is taken to a “fun” activity. While these “fun” activities also have educational value, they are chosen from the assignments that have proven the most popular with kindergarteners.

Clicking on an assignment token logs the student id, the time, and the assignment resource to an activity log in the database. Since the resources are correlated with state curriculum standards, it’s easy to get reports of how much time each student has spent on activities correlated to each standard.

When the work period is over, usually 20 to 30 minutes a timer in the classroom rings. Students know that when the timer rings they must click on the alarm clock token in the lower left corner. This resets the machine to the student login page where it is ready for a student in the next group to begin.

Our experience with the Curiosity Clubhouse has been that it drastically reduces the amount of teacher time spent setting-up and managing the computer resources. Students quickly learn the skills necessary to navigate the sytem and stay engaged in their assigned activities rather than getting sidetracked and wandering off-task.
One problem encountered early in the project was students who would quickly click through the first three assignments to get to the “fun” tasks. We dealt with this problem by adding a teacher page called the “Task Monster”. Typically this page is open on the teacher’s computer, usually with the screen facing the class. It displays a recent activity log, and an image of a door opened into a darkened room with the task monster lurking in the darkness. If a student fails to spend a predetermined minimum time on any assignment, the image of the door is replaced by one of several monster images and the teacher can see who was skipping assignments. The students quickly learned that the task monster knew what they were working on and the assignment skipping problem vanished.

Because the system is web-based, students can use the system from home. Parents are given logins to parent pages. A parent can prepare a computer at home to operate like one of the classroom computers by logging-in and then selecting a student login page. That page looks like the class login page except that only student tokens for children in that household are displayed. By having assignments available at home the system effectively extends the school day and minimizes the “learning loss” that occurs over long weekends and holiday breaks. Both parents and students have enthusiastically embraced the idea of using the system at home.

Other parent pages on the site include class calendars, a bulletin page with school news, links to the district and main school web sites, as well as mailto: links to encourage parents to communicate with teachers.

We are currently contemplating what the next version of the system will be. Because this was undertaken as an exploratory experiment, the system was implemented in a piecemeal fashion, and would benefit from a top-to-bottom rewrite. The next version will make more extensive use of technologies such as Mozilla Labs JetPack and Prism to minimize distracting browser controls. We also want to explore implementing lesson activities in a more standards-based manner, perhaps making use of the html5 canvas tag and AJAX to replace the flash-based activities. Also under consideration are changes to allow students to engage in learning activities using mobile devices such as the iPod Touch or Sony PSP.

In conclusion, we’re convinced that the web can be a useful instructional tool even for very young students who cannot yet read. Please leave a comment if you know of similar projects or have experiences you can share using the web to support early education.

September 16, 2009 12:43 AM

September 14, 2009 05:28 PM

There are some projects over at Mozilla Labs that just might make it possible to turn Firefox into the “killer-app” for K-12 education, both in North America, and around the world.

• JetPack is a set of tools for extending the browser using open, standards-based technologies like CSS, HTML, and Javascript.
• Prism is another labs project that lets you wrap a website into a bundle that looks, feels and works more like an application than a web resource.
• Weave, also from Mozilla Labs, will synchronize browser content across multiple machines, so you can start a project on a machine at school, and continue it on a mobile device or your computer at home.

So here’s how we could use these technologies to make Firefox the next K-12 “killer-app”:

The ultimate ne plus ultra K12 killer app has lots of different features, and lives in a moderately complex environment. But I believe it can be implemented incrementally as a series of small open source projects using Jetpack and Prism. Schools and even individual teachers could then select which extensions fit their needs. With luck, they will even be able to choose between competing extensions created by developers with different viewpoints about how to approach these problems.

Schools today make heavy use of curriculum materials that are “aligned” to state curriculum standards. Teachers want to use materials, including web resources, that directly address the curriculum standards they need to cover in class. As I lament in a previous post, the current state of these standards is a problem, with only three states offering their curriculum standards in XML, and the lack of a set of national standards. Many districts also modify the state standards by extending or sub-setting them.

There are proprietary search engines such as netTrekker that correlate some of the web to curriculum standards. But these are, for the most part, closed, proprietary solutions. We need to encourage the creation of open, shared curriculum alignment data. Certainly Wikipedia is an existence proof for large collective efforts of this kind. But the creation mechanism is slightly different.

Imagine a Jetpack Firefox extension that lets teachers collect, and correlate web resources to the curriculum standards in use in their districts, as well as rating them for quality with only a few additional clicks in the course of their normal lesson planning. Teachers could optionally submit those correlations to a central database to share with the education community. As the dataset matures it also becomes a driver for teacher lesson preparation, think of somthing akin to StumbleUpon that knows the curriculum requirements.

This data set can be integrated into student mentoring Jetpacks as well. When a student has difficulty with a particular concept in a homework assignment, a student Jetpack could recommend alternate presentations of material correlated to the same standard.

Another useful tool would be a Jetpack that takes a list of urls aligned with curriculum standards and tracks time-on-task for each standard. This should provide persistence across browser sessions, and the ability to track results for individual students in shared computer environments.

There should also be support for curriculum alignment meta tags that would allow web content creators to provide both direct correlations to various curriculum standards and “hints” to appropriate alignment of the content as well as the range of grade level for which the material is intended. Organizations like the Corporation for Public Broadcasting, National Public Radio, NASA, and many corporations currently offer on-line lesson plans to teachers, but there is no standardized way for them to supply curriculum alignment information in a machine readable manner.

Because the system will, of necessity, transparently support more than one correlation standard, it will also allow the use of “synthetic” correlation standards derived from the combination of all of the various individual state and district standards. This will provide a platform for discussion of possible national and international curriculum standards in a far more rational manner than is possible today.

First steps toward this ambitious project would provide real benefits for teachers and students even before the creation of a large database of correlated web content. Consider the following (more modest) possiblites:

• A Lesson-Plan Assembly Jetpack that lets teachers fill-in lesson plan templates in a point and click fashion while browsing for educational resources.
• A “compound URL” packaging Jetpack that enables teachers to bundle an assignment with supporting bookmarks, and documents (PDFs, image files, text files, etc.) into a single file that can be either emailed or posted on a web page for download.
• A companion Jetpack for students that can open these bundles and present them to the students in an encapsulated assignment workspace (color-coded tabs for the the assignment text, links, documents, and perhaps text editing tab). Include a way for students to add student-generated content to the bundle, save and reload the workspace after doing work, and turn-in work by sending the bundle (or just the student additions) back to the teacher (http upload or email).
• A Jetpack that lets a student do research on an arbitrary (Jetpack equipped) computer, and save results (and browser state) to a thumb drive (or synced to Weave) so that when work resumes on another machine the student can pick up where he or she left off.

What I’ve presented here is really just the beginning of what could be done to turn Firefox into the ultimate “killer-app” for K-12 education. Not everything presented here can be implemented quickly, but all this and more is possible with using the projects currently being worked on in Mozilla Labs. The sooner we start the sooner we can make a difference in educational outcomes. Use the comment form below to contribute your ideas to the discussion.

September 14, 2009 07:53 AM

Today I came across a great post by Eugene Wallingford, in which he considers what it means to teach thinking, especially in the context of students studying computer science and software.  He writes:

Today one of my students tweeted that he had started doing something new: setting aside time each day to sit and think. This admirable discipline led to a Twitter exchange among students that ended with the sentiment that schools don’t teach us how to think.

…Some courses take aim at how to think, or at least do on paper, but they tend to be gen ed courses or courses in philosophy that most students don’t take, or don’t take seriously.

I love encountering other people who are also thinking about these things.  After spending the entire summer off from teaching software and reading Heidegger, and in particular, “What is Called Thinking?”, I understand his dilemma exactly.  On the one hand, the answer is obvious, and involves students doing both CS and something like philosophy together.  But as I lamented earlier this week, and as Walliingford suggests above, this isn’t a serious option for most people.

However, while I’ve mostly given up on trying to convince my students to do this directly, I am convinced that in my teaching, I need to bring elements of this approach–yes, even to the study of software and computing:

We come to know what it means to think when we ourselves try to think. (Heidegger, “What is Called Thinking?”)

That ‘we’ is not rhetorical, nor is the ‘try.’  If we are to teach thinking, we must try to think ourselves, and more, we must do it in full view of our students, must do it with them.  I wrote yesterday that this means getting in amongst our students and working with them.  In so doing we offer not so much an additional set of hands, but rather the ability to analyze and reflect on what we ourselves are doing.  If we are willing to do this with them, we present a model of working that is more often informed by thinking, reflection, and analysis.  Thinking is harder than learning, harder than teaching.  If we aren’t still striving to learn thinking ourselves, we have no hope of teaching our students how.

As a side note, I also loved reading Wallingford say that he found this in a student’s tweet.  We need more profs meeting their students where they’re at.  Great stuff.  This is how you do it.

September 11, 2009 09:08 PM

September 11, 2009 01:58 PM

I’m just back from the first lecture in our Seneca Mozilla Open Source courses.  Chris and I are team teaching it this time, and we spent today introducing our way of working, and what open source is all about.  This year we’re going to try and film our talks and demos, and we’ll be posting today’s next week.  Here’s a test video and introduction we did yesterday.  I don’t know how I’m going to take to being filmed all the time, but I’m going to give it a shot.

One of the reasons I’ve always been hesitant to film what we do is that our method of teaching is very here and now.  We’re often asked for teaching materials, curriculum, things so that others can reproduce what we do, etc.  We’ve tried to create some of this over the years, but the truth is, most of what we do is respond to, and reflect on what we see happening.  We don’t teach something that sits still long enough to be photographed.  You really have to come with us to see it, and the experience is different every time.

I learned this my very first time teaching Mozilla, when I asked the students to build Firefox and document their method.  I wanted them to hand it in.  That night students started working together on the wiki, posting, improving, and correcting info until it was all done.  Like done as in, “you can’t do this assignment again, Dave, cause the answer is right here on the web.”

Over time we learned that this was a good thing, and not something to be controlled.  Don’t want your students to collaborate and publish their work?  No problem, you can clamp down on such things.  But why would you want to do that?  All of the academics I know collaborate, publish, and try to continually absorb existing knowledge as they innovate on top of it.

When you don’t teach with a curriculum, and instead look toward real events and people to provide an authentic experience of learning, you have to make a decision to radically alter your gaze.  Where previously you watched students go round the race course (that’s what curriculum is), this new method involves opening the gate at the end of the track, and having them run through it.  The students still run, they just don’t run in a circle.

Something else has to happen, though.  If you want to watch them now that they’ve left through the gate, you’re going to have to go with them.  You can’t stand in the middle of the stadium any more, behind your lectern, and simply officiate.  You have to get on the road with them, right there among them.  You have to keep pace.

I’m pleased to say that I know other professors who understand this, and are committed to it also.  I had two of them, two friends, get in touch with me today, inviting me to participate in their classes with them.  Think about that for a second.  I’m also a professor at another school with my own students and research, and they want me to spend my time working with them and their students.  Can you imagine how ridiculous this is?  I said yes to both.

Luke Hill is teaching a class on literature, and he’s decided to teach his class in the way I’ve described above.  He knows that the only true account of reading he can offer his students is the one that comes from his own reading, and showing them what happens.  You can join his class too if you like, and I’d encourage you to consider it.

Greg Wilson is teaching a capstone project course on open source.  He’s made good on an idea he told me about a few years ago to bring students from different institutions together in order to work on the same software projects.  He’s playing a coordinating role in Toronto, and helping to connect these students and institutions not only to each other, but also to the open source community at large.  That’s how you teach software in 2009.  You can follow the work of his students on their blog planet here.

I said earlier that you have to run along side your students, and I also plan to do just that with mine.  Before I went on holidays I released a piece of open source software that I’m particularly proud of called DXR.  When I say “proud” I don’t mean of the code itself–it’s a horrible mess of hacks that needs tons of work.  But, in it’s current 0.1 state, it points toward something great.  This year I’m going to be working on DXR as my project for our open source course.  I’ll be releasing updates to it on the same schedule as my students, blogging like they will about my progress, failing and succeeding just like they will.  Just as Luke plans to offer his own reading to his students, I’m going to offer my experience of open source in a Mozilla context to the students.

Now let me throw this challenge out there, to my colleagues at other institutions: open the gate and let your students run, and go run with them.  We love to talk about “just getting out of students’ way,” as though we regularly do that.  But I hear more people saying it than doing it.  I’d love to hear about more people who are doing this now.  We need to know about each other, and encourage one another because too often, the institutions in which we exist don’t understand the value of doing real things in collaboration with each other.

September 10, 2009 07:44 PM

Ellie drew this in kindergarten today. Her younger siblings, from left to right: Claire (curly hair, 4), Maddie (1), Micah (2), Ellie (5), Abigail (3), and Bekah (4 months). I love how she drew Bekah lying down, since she can’t walk yet, and how everyone else is in height order.

September 10, 2009 06:52 PM

IPDL is the language that Mozilla is using to describe all the messages between processes. Invented by Chris Jones, the IPDL language makes it easier for us to write type-safe and secure code by generating a lot of the basic validation code involved with messages.

When Chris was at Mozilla Headquarters a few weeks ago, he presented a tech-talk on IPDL which has been recorded and is available for download or viewing:

<video controls="controls">
<source src="http://videos.mozilla.org/serv/air_mozilla/chrisjones-full.ogv" type="video/ogg">
<source src="http://videos.mozilla.org/serv/air_mozilla/chrisjones-full.mov" type="video/quicktime">
<object autoplay="false" data="http://videos.mozilla.org/serv/air_mozilla/chrisjones-full.mov" type="video/quicktime">Your browser/feedreader/feed aggregator does not support the video element or have the QuickTime plugin.</object>
</video>

In the presentation, Chris explains the motivations for IPDL, demonstrates basic usage, and answers many questions about the limitations and benefits of using IPDL. I encourage anyone who is interested in Mozilla’s Multi-Process work to watch the presentation.

There are also some IPDL protocols in the tree if you’d like to read them: see the dom/ipc directory in the Electrolysis branch.

September 08, 2009 09:17 PM

Wow, so it seems I have misplaced my blog this summer. However getting married, moving and taking an epic honeymoon can do that to blogs. It’s been a whirl wind kind of summer, full of change. It’s hard to know where to start, so I’ll start with what matters most.

Being a married man, now for over a month, I can safely say I am both lucky and very much in love. It seems all those years Tasha and I enjoyed as a couple has us well prepared for the life of husband and wife. We have fallen into a wonderfully collaborative effort of eating, cleaning and entertaining. We have both spent a great deal of time preparing our home and we are finally enjoying the fruits of our labour, and it’s fantastic!

When I last blogged my internship at Mozilla had just begun, as I write this I find it came and went too quickly. Opportunity doesn’t always come at the right moment, but you need to seize it nonetheless. I’m so happy that I took the chance to work with Mozilla this summer — even if life had me pulled in too many directions. Spending time in California meeting Stuart, Doug, Mark and others was rewarding. During these last few months I have kept my eyes and ears open and the thing I take most from the experience is how dedicated and passionate they all are. It has inspired me to find that same passion in what I choose to do from now on. I’m spending my time now to take a look at the job market to find what best suits me, my skills and my passions. My home life is already proving to be rather fulfilling and I have decided I will settle for nothing less in my professional life.

I’m choosing to leave this blog post on the shorter side, it’s impossible to catchup with everything that has happened. However, some parting notes, I plan on remaining a contributor to the Mozilla project – the experience can only be surpassed by it’s importance, these are world class developers and I still have so much to learn and contribute.

I also would like to take a moment to thank Silvana from Impulse Photography, she has a track record of producing some of the most unique and creative photography around, and our wedding was no exception. With that I leave you with moments from our big day – Thanks Silvana!

September 08, 2009 08:13 PM