And, despite the IE slant, the game works really well in Firefox!  Check it out:

Visit http://www.cuttherope.ie to try it out!

When he’s not designing / building reactors for Atlantic Hydrogen in New Brunswick, he’s learning all sorts of cool skills.

Skills like leather-working.

Look what he gave me as an early Xmas gift:

View at Picasa A hand-made leather wallet by my friend Joel Beck10-Dec-2011 22:44, google Nexus S, 2.6, 3.43mm, 0.017 sec, ISO 50

View at Picasa Thunderbird!10-Dec-2011 22:44, google Nexus S, 2.6, 3.43mm, 0.008 sec, ISO 50

View at Picasa Firefox!10-Dec-2011 22:44, google Nexus S, 2.6, 3.43mm, 0.008 sec, ISO 100

View at Picasa 10-Dec-2011 22:45, google Nexus S, 2.6, 3.43mm, 0.008 sec, ISO 100

View at Picasa 10-Dec-2011 22:45, google Nexus S, 2.6, 3.43mm, 0.008 sec, ISO 50

View at Picasa Just look at that detail.10-Dec-2011 22:45, google Nexus S, 2.6, 3.43mm, 0.003 sec, ISO 50

View at Picasa Mind = blown.10-Dec-2011 22:45, google Nexus S, 2.6, 3.43mm, 0.004 sec, ISO 50

This is a one-of-a-kind, hand-made leather wallet, made by my good friend Joel Beck.

Thanks Joel.

And it was awesome.

Now, I know that I had originally told you that I’d be working on Thunderbird + Unity integration.  That’s still on my TODO list, but today, I put some contributions in with the Firefox team for the upcoming Firefox 4 release.  There are still a few bugs that need to be squashed before Firefox 4 is ready for the prime-time, and we’re all psyched to see it happen, so I lent a hand.

This was the bug I decided to tackle today. Basically, in the new add-ons manager, add-ons are listed alphabetically, regardless of their state (and by state, I mean enabled, disabled, incompatible, blocked, etc).  This leads to kind of a strip-ey look for large numbers of add-ons.

What we’d like instead is to have the add-ons grouped by state, and then sorted alphabetically within that state.  Here’s a mock-up by bug-reporter (and Firefox UX team member) Jennifer Boriss:

I got to work around 8:45AM this morning.  Around 10:13AM, I had finished most of my introductions, had my tour, had my accounts set up, found my desk, and started work.

The first thing I did was locate where exactly the code was for listing the add-ons.  Blake pointed out a particularly useful resource called MXR (Mozilla Cross Reference), which lets me search through the source code very quickly.  I had originally been using grep, but this was way better.

My approach to finding the code:  I find a string in the interface that seems unique to the area I’m working in (in this case, it was “Search all add-ons”, which is found in the search text input of the add-ons manager).  I did a search for that string, and it returned the file mozilla-central/toolkit/locales/en-US/chrome/mozapps/extensions/extensions.dtd.

But this only takes us half-way.  Since Firefox is translated, the strings are stored separately from where they’re used.  In extensions.dtd, the string I searched for is given the key “search.placeholder”.

Searching for “search.placeholder” with MXR gives me paydirt:  mozilla-central/toolkit/mozapps/extensions/content/ holds the files extensions.css, extensions.js, extensions.xul and extensions.xml.

So I tool around in extensions.js a bit, reading the developer documentation, and getting to know the code.  The code contains quite a few classes, including something called gViewController.  Digging deeper into it, it looks like gViewController controls (brings up, shuts down) the various “views” available in the add-ons manager.  Cool – so now I just need to find the view that lists the user’s add-ons.

Ah hah!  Found it:  gListView.  gListView grabs all of the installed (or to-be-installed) add-ons, and populates the interface.  So this is where the sorting needs to happen.  I tested to make sure I was in the right place in the code by using dump calls to a terminal.  Bonus:  edits in this portion of the code do not require a full browser restart – instead, I just close and reopen the add-ons manager to see my changes.  Nice!

Initially, my idea was to have 4 “buckets”, one for each of the 4 states (“enabled”, “incompatible”, “disabled”, “blocked”).  I’d divide up the add-ons into those 4 buckets, and then sort each bucket, and then join the 4 buckets for the final result.

Blake came up with a better solution: the Schwartzian Transform (straight out of Space Balls, I know).  The idea is that, instead of having separate buckets like before, we just go through the entire collection of add-ons, and “label” them based on what bucket they belong to.  Then we sort the entire collection, giving the bucket-label a high-order sorting priority.  It sounds complicated, but it actually wasn’t that difficult to code.  It’s a tiny piece of code, its readable, and quite elegant.  So kudos to Blake for that solution.

Anyhow, I wrote my patch.  I just figured out how to run the interface tests for Firefox (they use something called Mochitest).  I set those tests off on one of the fast machines in the office, packed up my gear, and headed home.

It was a solid days work.  Tomorrow, I hope to write some new tests for the Schwartzian transform, and submit my patch to Bugzilla.  Woop!

One of the talks I attended was an open discussion about getting students involved in open source software.

I’m going off of memory there, but I believe one of the speakers at that talk said something like:

Students generally don’t have to deal with large code-bases in their school assignments…1000 lines of code is really nothing.  When students work on an open source project, they get dropped into a massive code-base with only a fork, a spoon, and a compass.  They have to find their way around, and that’s where the real challenge and learning is.  This is a skill that most students just don’t get with normal school assignments.

Again, I’m paraphrasing.

So is this true?  Hm.

During my undergraduate career, I’ve certainly had to explore strange code that someone else has written.  But nothing even close to the size of, say, the Mozilla Firefox code-base.  Or the Chromium code-base.  I mean, these are massive wads of code.  This is not a criticism of my teachers or the UofT CS program by any means – it’s just an observation.

But some students explore these large code-bases on their own in their free time.  During my (admittedly brief) break before summer work began, I started poking around the Firefox code.  I made two discoveries:

1. The code that I saw was, in my opinion, very well written
2. I was completely lost, and didn’t know where to start

I still haven’t worked on any software that is nearly as large as Firefox.  Not even close.  MarkUs is a nice chunk of code, but minuscule in comparison.

So just go with me on this for a second.  Let’s assume that a large code base is intimidating and difficult for students to wrap their heads around, and this is one of the main challenges in getting those students to contribute to open source software.

Again, I only have my own experience to back up that claim.  Looking at Firefox, I didn’t know where to start.  I didn’t know where to go.  I didn’t know which way was up.  I was lost.

So how can students get a better grasp on a mountain of code?  A few ideas:

1. Write tests for the code, starting small and going big.  This is a relatively easy way to play with the code without having to change it. This assumes, of course, that the software has been designed to be easy to test…
2. Ask someone else.  Go into the appropriate IRC channel and ask around.  This, of course, has it’s own problems.
3. Read up on the developer documentation.  Let’s just hope it’s up to date and relevant…
4. Read up on someone else’s experiences exploring the same code base.  Good luck finding those.

Not Quite Blueprints

I’ve always thought of computer software as being like an invisible machine inside my computer.

And to me, the source code is a bit like the description of the blueprints for that invisible machine.  It’s not the top-down crystal-clear cutaways that a blueprint provides…it’s a flat, textual interpretation of those blueprints.  And it takes quite a bit of reading before those descriptions sink in, and the “personality” of the machine becomes clearer.

In his article “Code Spelunking Redux“, George V. Neville-Neil says:

Working in this way is a bit like trying to understand the United States by staring at a street sign in New York City. The ability to look at a high-level representation of the underlying system without the fine details would be perhaps the best tool for the code spelunker. Being able to think of software as a map that can be navigated in different ways—for example, by class relations and call graphs—would make code spelunkers far more productive.

I was thinking a lot about that on my ride home from FSOSS.  When I got home to my computer, I found out that there are some really cool alternative ways of viewing software.  Here are three that I found quite interesting:

Codecity

Imagine that you’re curious about developing on Firefox.  You can wade through the swaths of source code…

or you can stroll through a city that represents the software:

CodeCity

CodeCity is an integrated environment for software analysis, in which software systems are visualized as interactive, navigable 3D cities. The classes are represented as buildings in the city, while the packages are depicted as the districts in which the buildings reside. The visible properties of the city artifacts depict a set of chosen software metrics, as in the polymetric views of CodeCrawler.

Imagine virtually driving around that city, hearing a guided tour through your headphones…you can walk into buildings, check out the different floors…check the plumbing.  Interesting idea.

Cocoviz

Or how about a neighbourhood…

CocoViz

CocoViz address software comprehension by a combination of visualization and audio. It uses common place metaphors (like houses) for an intuitive understanding of software structures and evolution.

For each source code entity, evolution and structural aspects are mapped to such metaphors and annotated with different audio, to represent concepts such as design erosion, code smells or evolution metrics.

The tool is used in the software evolution analysis domain but offers DB-, XML-importer and a plugin architecture to extend its use into other domains.

EvoSpaces

Another attempt at using the architecture/neighbourhood metaphor.  This one does a neat job of displaying execution traces though – check out the video demo.

These are cool ideas.

But are they useful? Are they usable?  Do they work? Could they help students get a firm grasp on a large code-base?  Can they help visualize the evolution of software?

Has anyone actually used any of these?

Some updates:

• alertCheck just went public on Mozilla Add-ons after being reviewed by an add-ons editor
• As of this writing, alertCheck has 740 downloads
• As of this writing, alertCheck has 4 reviews – all positive

Not bad for my first add-on!

I finally decided to post it on Mozilla Addons.  Now compatible with Firefox 3.5.*.

Here you go.

Originally, when I started this project, I set a goal for myself:  I copied the text from Project Gutenberg’s First Folio version of Shakespeare’s Hamlet into OpenOffice Writer, recorded the word/line/character count statistics, and set that as my projected goal for my first iteration of my extension.

But there’s a problem with this approach:  I’m supposed to be copying the behaviour of Unix’s wc, not OpenOffice Writer’s word count.  Normally, this wouldn’t be a problem – a word count is a word count, a line count is a line count, and Writer should pump out the same numbers as wc.

Not so.

In my last post, I wrote:

According to OpenOffice Writer, this text has 32230 words, 173543 characters, and 4257 lines.

However, upon passing the same text (saved in the textfile “count.txt”) through wc, I got the following output:

5302 32230 178845 count.txt

Writer and wc agree on the number of words, but disagree on the number of lines – 5302 (wc) vs 4257 (Writer).  It’s a disagreement of about a thousand lines.

Brutal.

Anyhow, I’m going to focus on wc’s approach to line counting – simply returning the number of newline characters in the file.

And guess what…it works.  For Hamlet, my extension pumps out:

Document statistics:

Word Count:  32230
Line Count:  5302
Character Count:  178845
Character Count (no spaces):  142368

Nice.

Hamlet’s just the simple case though.  There are plenty of other cases to consider, but this is a start.

Anyhow, download here.

In this version, I’m using Mozilla’s TreeWalker implementation to stitch together the page text.  So far it seems to be working alright, but if it somehow ends up falling through, I might end up using something like Andrew Trusty’s code with the jQuery library to do the text stitching.

So there it is.  Maybe I’ll keep working on this, pretty it up a bit, etc.  However, work starts on Monday, and that’ll probably take up most of my technical attention.

We’ll see though.

Prof. Greg Wilson recently sent me an email, saying the following:

I’d like a Firefox plugin that does ‘wc’, i.e., counts characters, words, and lines on the current web page, and displays the results in the status bar.

Cool, I thought.  No problem.  That doesn’t sound too hard.

But I’ve been mulling and chewing this around in my head, and it’s actually a harder problem than it first sounds.

“wc“, short for word-count, is a small, simple, yet extraordinarily useful Unix utility that reads in some file, and spits out the number of words, characters, and lines for that file.

So what’s the problem?  What’s so hard about coding something like this for web pages?

Well, for starters, users of this proposed extension are probably only interested in the visible, readable text on a web page.  That means filtering out all of the HTML tags, all of the JavaScript, etc.  Also, many modern web pages make use of IFRAME’s, hidden DIV’s, etc.  Not to mention, most browsers do automatic word-wrapping, which could throw off the “line” counting.  How should I treat these cases?

I certainly don’t think this is an impossible task, just harder than it first sounded.

So here’s what I’m going to do:

First, I’m going to take care of the base case.  I’m going to take care of the case where users are viewing a page of all text, with almost zero HTML.

My test page will be an “etext” copy of Shakespeare’s Hamlet (first folio), hosted by Project Gutenberg.

According to OpenOffice Writer, this text has 32230 words, 173543 characters, and 4257 lines.

So that’s my target.  I’m going to create an extension that sits as a button on the status bar.  When the button is clicked, an alert will pop up with the statistics.  If all goes well, the numbers will match.

Sure, it’s not the most elegant interface, but it’ll do for now.

I’ll post more as it comes.

Someday, when I’ve got more extension development experience under my belt, I’ll probably come back to this and fix it up.  Until then, this will have to do.

Click here to download.

If you’re interested in looking at the source, just change the file extension from “.xpi” to “.zip”, and decompress.  It’s all there.

There’s no license on this thing, no GPL, MIT, nothing.  Use it however you want.  If you find it useful though, I’d love to hear from you – send me email, post a comment, Facebook, Twitter, whichever.

Whew.  I think I’m going to reward myself with some orange sherbet.  Om nom nom…

Here’s a really annoying website to test the extension with.  I really don’t recommend that you visit it without my extension installed.

The window hops around a bit, so just double click on the location bar, and type in something like “http://www.google.ca”.  This will start up the flood of alerts, and (hopefully) you’ll be able to suppress them after the first one hits.

Here’s the site.  Visit at your own risk.

UPDATE:

I’ve moved the extension to Mozilla Addons, and added Firefox 3.5 compatibility.

I’ve updated alertCheck.xpi so that it’ll play nice with Firefox 3.0b5, and hopefully Firefox 3.1.*.  Let me know if there are any behaviour foulups, and I’ll do my best to fix them.

The trick, was not to rely on the DOMContentLoaded event to fire to do the override.  Instead, I used the DOMWillOpenModalDialog to detect the first alert().  After detection, I overrode with an alertCheck which asked the user whether or not to “suppress more dialogs”.  If the user answers in the affirmative, alert() is simply overwritten with an empty function.

Piece of cake.

A couple of issues though…

Security

In order to override the alert() function, I have to write to document.getElementById(‘content’).contentWindow.wrappedJSObject.alert.

Remember how I mentioned the distance between the Extension JavaScript, and the inline content JavaScript?  I said it felt like a security layer.

I was totally right.

Check this out. I’ll quote:

You should be aware of XPCNativeWrappers when working with untrusted content. With XPCNativeWrappers turned on (which is the default in Firefox 1.5+), your extension can safely access the DOM of the content document, but not the content JavaScript. Bypassing XPCNativeWrapper to work with content JavaScript directly can lead to security problems.

Hrmph.  So I seem to be violating some security rules here.  So maybe my approach isn’t the greatest idea.  “Mook” from irc.mozilla.net #extdev suggested looking into commonDialog.xul…but I can’t seem to wrap my head around that just yet.

Imperfections

Not sure why yet, but while I can suppress dialog floods like this:

for (i = 0; i < 10; ++i) {
  alert(i);
}

It seems to fail on this:

for (i = 0; i < 10; ++i) {
  alert(i);
  confirm(i);
}

For some reason, regardless of whether or not I choose to suppress the dialogs, they just keep coming.  It works fine when I swap out the confirm() for a second alert().  Not exactly sure why.  Yet.

Ok, so I’m going to clean the code up, and post it soon.  I’ll also post a link to a real, brutally annoying website where you can test the alertCheck extension.  Just give me a bit.