Over the past few weeks I’ve had the pleasure of working with Dion Almaer on a Browser Memory Tool Prototype. This has been a lot of fun for me; for one thing, I’ve always wanted to help developers diagnose the problem of “I’ve been running my web app/Firefox extension for 8 hours, why’s it taking up 800 megabytes of RAM?”. And I’ve also always wanted to have an excuse to learn about the internals of SpiderMonkey, Mozilla’s JavaScript engine, and play with its C API. ... Read more

Security is hard! It’s tough enough designing a platform that’s powerful, well-documented, and easy to use; but what about security? If we aren’t careful, adding a incorrectly tuned or naive security model negatively affects generativity and usability. Jetpack needs to balance all three. The following is something I wrote at the beginning of June, but didn’t post until now because I’ve had my head in code for a bit too long. ... Read more

A little while ago, Vladimir Vukicevic wrote an excellent blog post outlining the reasons why he’s not a fan of exposing a specific implementation of SQL to Web Content. I agree with everything he says in his post; I’ve also been a fan of CouchDB for some time. A CouchDB-like API seems like a nice solution to persistent storage on the Web because so many of its semantics are delegated out to the JavaScript language, which makes it potentially easy to standardize, as well as easy to learn for Web developers. ... Read more

Over the last two weeks, I gave two tutorials to our Design Challenge students. The first was called Engineering Prototypes, and centers on the most challenging part of working on prototypes for me, which is the balance between expediency of implementation and robustness. Prototyping involves prioritizing the former over the latter, but it’s unwise to throw engineering principles out the door: for instance, a prototype that constantly crashes or runs slowly may not be usable enough to dogfood, and one whose implementation is poorly designed can be difficult to iterate and evolve. ... Read more

The Ubiquity project has been moving pretty quickly and despite the fact that I spend most of my time working on it, I actually have a hard time keeping track of its progress. At Labs we’ve talked about the idea of having “project dashboards” that present the latest developments on our projects, so I thought it might be a good opportunity to play around with new ways of visualizing community activity. ... Read more

With Deb Richardson’s recent posts on the evolution of the about:mozilla newsletter, I decided to try my hand at a new layout for the existing issues, in the hopes that experimenting with new designs could help shed some light on the situation. For reference, this is how the February 24th issue looks: One of the notable things about this layout is that there isn’t actually much useful information in the first screen: there’s a table of contents that has headlines, but the user needs to click on a headline or scroll down to learn more. ... Read more

We want to make Ubiquity awesome at reporting errors. In our original release, a transparent message with JavaScript exception information was displayed, which wasn’t very useful to the average user, and was downright annoying when dozens of exceptions were logged in the same instant. At present, running a command that raises an error just results in that message being logged to the JS Error console, which very few people know how to access—so most people are left scratching their heads and wondering why their command is taking so long to run. ... Read more

As we’ve mentioned before, Ubiquity 0.2 has fairly broad, visionary goals that won’t be fully satisfied for some time. So we’re going to be pushing its changes to the 0.1 line at more regular intervals as we continue to develop it. By “pushing its changes” we mean that we’ll effectively be disguising our work-in-progress 0.2 as a 0.1.x release. For instance, Ubiquity 0.1.5, which we released about a month ago, is essentially the same thing as 0. ... Read more

Yesterday Tempura left a good question as a comment on my blog post concerning Ubiquity’s experimental support for Python: What about http://pyxpcomext.mozdev.org ? They bring Python in an xpi for all major plattforms, without the need of an local installed interpreter. Using PyXPCOM was actually a potential option we had considered, but we ended up going with jsbridge for a number of reasons: PyXPCOM uses XPCOM as its means of communication between Python and the Mozilla platform. ... Read more

A few weeks ago I wrote about Ubiquity Feed Plugins, which are basically just a way of separating the user interface of subscribing to a new feature from the implementation of the feature itself. As I’ve written about before, one of the things I’ve missed about the Mozilla development environment is its support for the Python programming language. Aside from being humane and having a great community, it has functionality that could complement the Mozilla platform quite nicely. ... Read more