db48x, aka Daniel Brooks, joins APN

Just a quick note from my Batcave: I’ve got a new coworker, a fellow Mozillian. His name is Daniel Brooks, and he’s just moved to the SF Bay Area. He doesn’t have a Planet Mozilla blog, so I decided to announce it for him. 🙂

I’ll have to convince him to talk about some of what he’s done for the Mozilla community. It’s a pretty long list.

Paired methods (start*, stop*) are a bad idea

By paired methods, I mean a pattern like this:

manager.startWatching(node);
doSomething();
manager.stopWatching(node);

In pure JS land, this is unnecessary. If your API requires both the start and stop methods execute, around user code, your API is fragile. You might require customers to call both startWatching() and stopWatching(), but you can’t guarantee they’ll do it. It’s far better to have a single watcher method which takes a callback function:

manager.watchObject(node, function() {
doSomething();
});

The watchObject() can guarantee both the start and the stop methods execute, even in the face of an exception from the callback, with a try… finally statement:

watchObject: function(obj, callback) {
innerManager.startWatching(obj);
try {
callback();
}
finally {
innerManager.stopWatching(obj);
}
}

This blog post isn’t a rant against any Mozilla code in use, specifically. This is something I realized when working on my own pet project.

Though to be fair, a lot of XPCOM code requires this pattern – SAX, TransactionManager’s batched transactions… it’s kind of annoying. The only current solution for this would be to introduce a callback interface, with a single method and “function” defined in the interface attributes:

[scriptable, function, uuid(...)]
interface nsICallback : nsISupports {
void callback();
};

Technically, you could reuse nsIRunnable for that, but that violates the intent of the interface. Somehow, I don’t think we’re going to see that pattern introduced into the Mozilla code base anytime soon, even as a new XPIDL argument type. (“lambda”, bsmedberg?)

UPDATE: John J. Barton raised an excellent point in comments: that if the start method and the stop method are from two separate user interface events, such as a start button and a stop button, then it’s appropriate to have two separate methods. I wrote this article in the context of a single event triggering both.

Do you have a tech hobby that needs some love? Let me know!

I’m thinking about scheduling a week-long retreat in July for a small group of techies – say, six to ten people.

In past years, I’ve found that a week at OSCON was some of the most fun I’ve had – particularly being around lots of high-powered brain talent. It wasn’t so much that their fields paralleled mine – far from it – but the inspiration of seeing what others can accomplish has usually propelled me to some of my best moments as a tech myself.

So that’s the why. Get a whole bunch of bright people together for something other than their day jobs, and interesting things begin to happen. An informal brain trust, basically.

I have my own tech hobby, but I work on it alone. I’m not asking for help on it, but I am asking if there are other people like me in the same situation. Here’s what I’m suggesting, in concrete terms:

  • People involved (this means you!) must have a hobby involving technology.
  • That hobby must not be their day job!
  • People involved should be able to commit one week’s vacation time.
  • They must be willing to spend that week around ten to twelve other tech hobbyists, in a relatively small space – say, a large conference room.
  • They must be willing to spend that week somewhere away from home… say, Napa wine country
  • They must be willing to work extensively on their hobby during this week.
  • They must be willing to talk about their own projects – and to listen to others talking about their projects.
  • They must be willing to take some time as regular vacationers… say, a trip around the vineyards in Napa Valley. 🙂
  • They must be willing to have fun!

If there’s enough people interested, I can try to set up a “Week For Hobbies” tech retreat somewhere. If I get a lot of people, I’d probably go so far as to invite a couple students (who may not have hobbies yet, but an interest). Talk to me in the comments!

(Also, if you have blogs that are syndicated to other tech Planets than Planet Mozilla, feel free to post links to this blog where others will see it. I specifically do not want this to be a Mozilla-friends-and-family-only event!)

Gonzo programming (or “Fear and loathing in JavaScript”)

A few months ago, I took my ideas about DOM bindings and aggregation by proxy (I really should’ve called that “mix-in by proxy”), and started writing something… a little wild. A little out there. Of course, it’s not finished yet – very few great things in software ever are – so I still don’t have anything to show for it. (I will, though… I’m planning on posting a FF add-on demonstrating my work here, in miniature.)

In any case, with what FF4 betas gave me earlier, I kept thinking of where this was all going, and I realized the best way to say it was to “borrow” the words of Hunter S. Thompson:

“I had two bags of hash… sixty four bits of desktop machine… five sheets of high-powered design notes… a saltshaker half full of membrane… and a whole galaxy of multipurpose strings, numbers, booleans, functions… Also, a quart of tests, a quart of make, a case of select, a pint of raw pointers, and two dozen cookies. Fig newtons. Not that I needed it all for the hack, but once you get hold of a serious tool collection, the tendency is to push it as far as you can.

And yes, I do need somebody to love… (warning: NSFW @ 1:50)

Continue reading Gonzo programming (or “Fear and loathing in JavaScript”)

We are still here!

It’s kind of amazing to think about all the people who’ve been with the Mozilla project for a very long time. For me, I also take note that I’m now a member of that group – maybe not the respected (and very competent!) elder that Mike Shaver, Boris Zbarsky or even Brendan Eich are, but still someone who’s been around the block a bit.

Specifically, for ten years now. On March 4, 2001, I filed my first Bugzilla bug. I don’t remember whether I was working on my book at the time, or if I was just tinkering around with JavaScript, but I do remember that zeal I had – because that zeal has never gone away. The feeling that says, “This is just wrong, we should fix this.” I still get that feeling quite often, though usually more about my code than Mozilla’s. (I love our automated testing frameworks, by the way… they make it much easier to have confidence in code I write!)

Of course, I filed a lot of bogus bugs back then, by which process I learned the hard way about reading specifications, and that specifications are often “wrong” (incomplete, useless, or impractical). I also learned the hard way that I’m even more often wrong. It’s why I started saying three months later, “The first step in confirming there is a bug in someone else’s work is confirming there are none in your own.” (June 30, 2001, if anyone’s curious.)

If I had to summarize the most important thing I’ve learned over the last ten years, it’s that. Sure, there’s a long list of technologies, but it’s that human factor which is biggest. In simple language, the quote means “make sure you’re right before accusing someone else.” In Biblical language,


Why do you notice the splinter in your brother’s eye, but do not perceive the wooden beam in your own eye? How can you say to your brother, ‘Let me remove that splinter from your eye,’ while the wooden beam is in your eye? You hypocrite, remove the wooden beam from your eye first; then you will see clearly to remove the splinter from your brother’s eye.

— Matthew, 7:3-5

Also, the fact Mozilla’s been around for that long is pretty good stuff too. Indeed, we need not fear the machines. I remember that which matters most: We are still here!

Aggregation by proxy, part 1

(I was tempted to call this Integration by Parts, but I think the other calculus fans reading Planet Mozilla would raise a pitchfork or two.)

In my last blog entry, I talked briefly about an idea I had:

Aggregation by proxy, though, means you could daisy-chain several JS objects in front of the original DOM node, in terms of method and property priorities. If you need to replace a binding, you swap out one object in the daisy-chain. No __defineSetter__ mess, though pulling it off will require a bit of custom JavaScript code. I’d love to see someone else write it up for me – I see it as a trivial extension of the forwarding proxy examples.

Okay, it’s not that trivial. But I do believe it’s doable. If you exclude the DOM node and just daisy-chain a bunch of JavaScript objects, you get something like this. (Note this will only work in recent FF4 beta builds.)

Tom Van Cutsem saw my sample this way in an e-mail he sent back:

If that’s the case, I think your code here actually demonstrates two nice use cases of proxies:

  1. it shows aggregation of object properties.
  2. it shows how you can create a “side-effect-free” proxy for an object (or a graph of objects), which provides the illusion of side-effects (adding/deleting properties) to the proxy client without affecting the wrapped object.

I can imagine proxies that support only 1) or 2) to be useful in their own right. It may even make sense to separate out the functionality into two proxies and then chain them together so that we have:
client -> side-effect-free-proxy -> aggregate-proxy -> target

The version I’m posting here has Tom’s annotations in the source code.

There’s room for improvement. This code will work only with pure JavaScript objects, and can violate rules for setters. I’m thinking this design only takes me part of the way there. I imagine aggregation by proxy as meaning “I can combine implementations of two different IDL interfaces into a single callable object”. That means fun with QueryInterface, for starters. I also need to work on a SingletonHandler (hint: I’ve already prototyped that too), so that document.getElementById(“test”) returns me the same object every time.

I’d love to work on this with fellow Mozilla contributors, to build a complete aggregation by proxy script for the DOM. Anyone interested?

A different way to add bindings to DOM nodes – with proof of concept!

Several years ago, before HTML 5 reached its current adolescence, it was in
diapers. There was a sub-specification called Web Forms 2.0, and it included
a
repetition model for blocks of HTML markup
. The idea has long since
been dropped from HTML 5 (it’s probably in a landfill with someone’s diaper),
but it’s remained an inspiration (or maybe an obsession!) for me ever since.

Making it work is quite challenging. I think a repetition model could be
very useful for any web page editor – or for Verbosio, my experimental XML
editor. There’s a few drawbacks, though:

  • I can’t use XBL to pull it off. XBL wants me to insert content as
    children of the bound node, and I think that could just mess
    things up badly for CSS. Inserting the anonymous content as previous siblings makes more sense, and is cleaner, both for DOM and CSS manipulation.
  • I can’t use XTF for it. Well, I could, but the code gets very
    ugly. Unmaintainably ugly.
  • I really do need to hide these inserted elements from the DOM, and yet
    show them in layout. This is one of the issues that prevents a JS-based XBL
    2.0 implementation, or a JS-based XBL 1.0 implementation.

Given all that, I finally hit on a solution: copy the DOM. Give one
DOM tree to the primary JavaScripts, and another DOM tree to the web browser.
Unfortunately, I couldn’t copy it just once. I had to copy it several times,
maintaining private copies of the full DOM tree, one for each new “layer” of
bindings.

If all this is boring and you want me to show you something, here’s a
screenshot:

Yes, that’s a chrome Mochitest, with a DOM Inspector window. DOM-I (and the
browser window) sees the “anonymous content” DOM, but all the tests I ran
against the “scriptable” DOM.

Let me play with this!

Okay.

hg clone http://hg.mozdev.org/verbosio --rev 06a72a32d6ec unstable
cd unstable
python client.py --target=floor13 --mozilla-rev=--latest-beta checkout
python client.py --target=floor13 build
. run_bindings.sh

Source code for this experiment lives at

http://hg.mozdev.org/verbosio/file/06a72a32d6ec/experimental/floor13
.

How does it work? Can this be used for XBL 2? What about my own
properties?

Extended entry, please. For those who don’t wish to read on, well,
Happy New Year!

Continue reading A different way to add bindings to DOM nodes – with proof of concept!

What if we held an Add-On Con at OSCON?

Recently a few of my coworkers visited the Add-On Conference in Mountain View, CA. (I elected to stay behind, and with our schedule it worked out nicely for everyone.) As most people reading Planet Mozilla are aware, it’s an annual event in December, talking about extensions for web browsers.

The Open Source Convention just put out another call for speakers for their July 2011 gathering in Portland, OR. OSCON actually hosts several smaller annual tech conferences as well at the same time. There’s a Python track, a PHP track, a Perl track (they must be planning to write Duke Nukem in Perl 6), etc. There’s even been, from years past, a small Mozilla presence there.

What if we made AOC a twice-annual event, once in Mountain View in December, and once at OSCON in July? I know it’s hard to prep for a conference, that it takes a lot of work to plan a speaking session. I’m just throwing the idea out to see who bites – particularly among those who spoke at AOC this year. On the plus side, if you’ve ever seen Damian Conway speak on Perl… well, it’s a treat.

At least then, a few of us could show up clean-shaven. :-)}}

Gaudete, gaudete!

Whether you’re Christian or not, there’s some good music out there from Christianity. Here’s one called “Gaudete”.

(In case you’re wondering, I listen to a wide variety of music, including some based on other religions. Some of it’s really good.)

Someone once told me that the human voice in song was one of the few aspects of heaven we could experience on Earth. I wish I could remember the exact quote.

A distributed-computing app store, for browsers?

Chalk this up as an idea that may have been done… or someone’s planning it and I don’t know.

Anyone familiar with the Einstein@HOME project? The idea’s pretty simple: you have a large number of calculations to perform, but supercomputers are a little expensive. Instead, you write an application which many home computers can download and run, and communicate with your main server.

I used to participate in it, but a couple features kept me off. First, I couldn’t share it between computers. Second, when I had to get rid of a machine, I couldn’t transfer the results to a new one. The final straw for me was when I found out a few years ago the Einstein@HOME project had accidentally been recycling data – sending me and several others data to crunch which had already been through the whole verification process. (What’s the point of leaving my machine on for days or weeks then?)

Now, imagine writing your distributed-computing application for a web browser. A little HTML, maybe some canvas work to make it look pretty (and show what you’re doing), and a whole lot of JavaScript.

Suddenly, you’ve got a lot of the necessary infrastructure built for you. Portable user accounts? Yep, we’ve been doing that for the last fifteen years (log-in pages). Communication with the home server? XMLHttpRequest. Fast calculation times? All the major browsers are implementing just-in-time compilation for frequently executed JavaScript – which is ideal for distributed computing (it executes a section of code very frequently).

There’s a few other benefits, too. It’s very hard to crash the platform in JavaScript – you have to go out of your way to do that. The whole WWW opens up to you, in a well-tested platform. Oh, and there are literally hundreds of millions of users of the major browsers. (Dare I say billions, plural? If not now, soon.) Distribution of your application becomes even easier than it is now: it’s just a web site. Plus, users can see when they’re on a secure connection to you (that little padlock in the corner).

When your application lives in a web page, your users can be fairly confident you’re not doing something evil to their machine. Security holes aside, outside the browser there’s few traces left behind. So it’s even environmentally friendly to the computer’s eco- and operating- system!

Of course, when you write something to force a JavaScript engine to do lots and lots of calculations, you’re going to start pushing the boundaries of what the platform is capable of. Which isn’t necessarily a bad thing: with Mozilla, you get an open, competent and somewhat responsive platform support community. If a bug is easy to reproduce – especially if it breaks the JavaScript engine (less so if it breaks something else) – and is filed in the right place on Bugzilla – and you’re nice to the community in question (politeness and patience helps!), you can get a pretty good response.

An obvious downside is that a distributed-computing web application could really wreak havoc as a botnet or a denial-of-service to the browser’s users. Here, the infrastructure of the browser could help again: for Firefox, Mozilla simply could put the dangerous application’s web site on their dangerous sites blocklist. Once that happens, and the user loads the web page, they see a big red warning page first, with a traffic cop icon scaring them off. The botnet disappears (or at least is seriously reduced in size, and thus, potency).

Commercializing a distributed-computing web application – where the end-user gets paid a little at a time for their results – might be practical too. (PayPal, anyone?) That could lead to a few dangers, though: who do you trust with tens of thousands of computers?

Right now, this is just an idea. I have no idea who might be working on that already, or if it’s just not practical. Comments welcome, though.

Alex Vincent's ramblings about Mozilla technology, authoring, and whatever he feels like.