Loving IRCCloud

I tend to use pretty basic (and preferably cross-platform) software so I can be comfortable on systems that aren’t highly configured to my specific taste. I don’t change the software I use on a daily basis very often. However, I recently switched away from the IRC client that I’d used heavily for many years, and started using IRCCloud instead. I’m so happy with it that I thought I’d write about it.

I used Colloquy, and I was pretty happy with it. It’s about as good as a native application IRC client can be. It has two major down-sides though, both of which are consequences of its being a native application.

First of all, when my computer was off or asleep, or I forgot to start the application for some reason, I was offline. I frequently missed interesting public conversations and private pings.

The second problem is that Colloquy only works on OS X, and if I’m using different machines I have to configure an IRC client on each one. I’m frequently using a couple of machines at the same time, like an Apple laptop with a bunch of OS X-specific applications open (e.g. iTunes, Word) and a Linux machine that I’m writing code on. If I want to copy/paste something to IRC from the machine that isn’t running Colloquy, I can’t unless I quit Colloquy on OS X and start some other IRC client on the other machine. Not being able to easily be on IRC with the same nick from multiple machines was annoying.

About six weeks ago I signed up for IRCCloud, based on a blog post I had read. Once you create an account, you can configure it just like any other IRC client and connect. The connection is persistent, so you’re online on IRC even when you’re not on the site. When you log on again, you can see what you missed in public rooms, as well as any private pings you might have missed. Fantastic. Because it’s a web application, it works on all platforms. You can even be logged in from multiple machines at the same time!

Switching to IRCCloud has improved my IRC experience immensely. I highly recommend it if you’re a regular IRC user.

Posted in Miscellaneous, Mozilla | 6 Comments

Simple Code Review Checklists

What if, when giving a patch r+ on Mozilla’s bugzilla, you were presented with the following checklist:

You could not actually submit an r+ unless you had checked an HTML check box next to each item. For patches where any of this is irrelevant, just check the box(es) – you considered it.

Checklists like this are commonly used in industries that value safety, quality, and consistency (e.g. medicine, construction, aviation). I don’t see them as often as I’d expect in software development, despite our commitments to these values.

The idea here is to get people to think about the most common and/or serious classes of errors that can be introduced with nearly all patches. Reviewers tend to focus on whatever issue a patch addresses and pay less attention to the other myriad issues any patch might introduce. Example: a patch adds a null check, the reviewer focuses on pointer validity, and misses a leak being introduced.

Catching mistakes in code review is much, much more efficient than dealing with them after they make it into our code base. Once they’re in, fixing them requires a report, a regression range, debugging, a patch, another patch review, and another opportunity for further regressions. If a checklist like this spurred people to do some extra thinking and eliminated even one in twenty (5%) of preventable regressions in code review, we’d become a significantly more efficient organization.

For this to work, the checklist must be kept short. In fact, there is an art to creating effective checklists, involving more than just brevity, but I won’t get into anything else here. My list here has only four items. Are there items you would add or remove?

General thoughts on this or variations as a way to reduce regressions?

Posted in Mozilla, Programming | 11 Comments

New Gecko OS X Widgets Module Owner: Steven Michaud

I’ve been Gecko’s OS X (Cocoa) Widgets module owner for a long time. The code in this module is Gecko’s OS X compatibility layer.  Today I’m handing over the reigns to Steven Michaud.

We’re fortunate to have such a capable and active new owner. Steven has been working on this code with me since before Firefox started using it by default in 2006, and in more recent years he’s been doing the bulk of the maintenance work. In addition to knowing the module well, he’s got great debugging skills. Those skills are joined by some serious perseverance, which means he can get to the bottom of just about any bug.

Thank you, Steven!

Posted in Mozilla | 1 Comment

Informal Test: Building Firefox with VMWare vs. VirtualBox

I needed to set up a Linux virtual machine on a Windows host for working with Firefox OS. I don’t like working in slow VMs, so I did an informal test of VMWare vs. VirtualBox. I prefer to use open-source software when I can, so if VirtualBox is as fast as VMWare, or close, then I’ll just use VirtualBox.

Mozilla developers often work with VMs, and minimizing build times is a frequent topic of discussion, so I thought I’d post my results in case anyone finds them useful. If you have anything to add on the subject, please do so in the comments.

Host Software and Hardware:

  • Windows 7 Professional 64-bit, all updates applied as of Sept 12, 2013
  • Intel Core i7-3930K CPU @ 3.2 GHz, 6 cores
  • 16gb RAM

Guest Software:

  • Ubuntu 13.04 64-bit, fully updated as of Sept 12, 2013
  • Approximately the minimum number of packages installed in order to build Firefox

VirtualBox Config:

  • VirtualBox 4.2.18
  • 4 CPUs (VirtualBox does not have CPU vs. core distinction that VMWare does)
  • 6002mb RAM assigned to VM

VMWare Config:

  • VMWare Workstation 10, purchased
  • 2 CPUs with 2 cores each, for a total of 4 cores
  • 6004mb RAM assigned to VM

The test was was to create a Firefox nightly debug build (latest code as of Sept 12, 2013) with the command “time make -f client.mk”, using the “-j4″ flag for make.

VirtualBox Build Time

  • real: 28m53.005s
  • user: 88m32.932s
  • sys: 10m6.376s

VMWare Build Time

  • real: 29m31.595s
  • user: 89m22.548s
  • sys: 11m6.192s

Given these results, I’m just going to use VirtualBox. I’ll note, however, that graphics performance (and subsequently, UI responsiveness) in VMWare does seem to be noticeably better than VirtualBox. I don’t care, but if you do, VMWare’s advantage here is fairly noticeable even in simple interactions. VirtualBox is not bad though. Also, I didn’t test device support or too many different VM configs for the sake of tweaking performance. Take my results as a rough guide at best.

I did test VirtualBox with fewer CPUs, to test a rumor I’ve heard in the past that adding CPUs to a VM doesn’t improve performance much, or could even hurt it. That rumor seems to not be true, or is no longer true, at least with VirtualBox and my setup. Build times went from 101m, to 52m, to 28m, for 1, 2, and 4 CPUs, respectively.

Posted in Mozilla, Programming | 3 Comments

Exciting Stuff: Firefox 19’s Built-in PDF Viewer

Firefox 19’s built-in PDF viewer is pretty exciting — not just because Firefox (finally!) has a PDF viewer, but because it’s written in JavaScript. Why is that exciting?

First, we’re always looking to extend the web platform’s capabilities. Writing a PDF rendering engine in JavaScript pushed the platform’s boundaries. We learned quite a bit while working on our PDF viewer, and we used that information to improve Firefox and the web platform in general [1].

Second, being written in JavaScript is great for security. The alternative, pursued by all other browsers with built-in PDF viewers, is to include another binary rendering engine alongside the HTML and JavaScript engines. Adding hundreds of thousands of lines of C and C++ code to render PDFs is not a good thing for security. Complex binary engines are hard to secure, and PDF engines are no exception — ask Adobe or FoxIt. Mozilla’s built-in PDF viewer will not be without vulnerabilities, but they will be vulnerabilities in the web platform that we’re already committed to securing — we’re not adding to the problem.

There’s still work that needs to be done, but Firefox and the Web took a big step today!

[1] e.g. improved font handling, canvas APIs, and JavaScript performance.

Posted in Mozilla | 15 Comments

Mozilla Joining ISOC in Support of IETF Activities

Mozilla has been significantly increasing its participation in IETF working groups over the past couple of years. This has coincided with increasing investments in the networking layers of our software and the Web platform. Today we’re heavily involved in IETF working groups relating to key Internet technologies such as TLS, HTTP and HTTP/2, RTCWeb, WebSockets, and others.

We think it’s important to support the standards groups in which we participate, so I’m pleased to announce that Mozilla has become an ISOC (Internet Society) Silver member. Among other things, ISOC provides administrative and organizational support to the IETF. We believe supporting ISOC and, by extension, the IETF, is a solid investment in terms of our mission to promote openness, innovation and opportunity on the Web.

Posted in Mozilla | 2 Comments

Mozilla Removing Support for the ‘java’ and ‘Packages’ DOM Objects

We have removed direct access to Java from the DOM in Gecko. Specifically, we have removed support for the ‘java’ and ‘Packages’ DOM objects. These are not part of any web standards and we don’t believe they are good for the web.

Script can still interact with Java plugin instances via NPRuntime, authors simply have to instantiate a Java plugin instance to script against.

This change will be in Firefox 15. See Mozilla bug 748343 for more information.

Posted in Mozilla | Leave a comment