Tell me more about this intriguing future

Firefox 1.0 was released on the 9th of November of 2004, and I still remember the buzz. We were all excitedly downloading it because our browser had finally reached v1.0.

Using Firefox at that time, with all the developer extensions, gave you such an advantage over other web developers. Adding in the tabs, and the way it was predictable (CSS standards wise), and that it wouldn’t get infected with stuff as often as Internet Explorer, made it into such a joyous experience.

Now, if you had told me back then that I’d be contributing code to Firefox, I’d be laughing in your face. But then I’d stop and ask: Wait… what? Tell me more about this intriguing future!

Fast forward thirteen years. I am working at Mozilla, and tomorrow we release Firefox Quantum to the general public. It’s, as the name says, a “quantum leap” between this and previous Firefox versions.

I’m personally excited that I’ve contributed code to this release. I worked on removing dependencies on the (now defunct) Add-on SDK from the code base of Developer Tools. This means that the SDK code could be finally removed from Firefox, as the new WebExtensions format that Firefox uses now does not make use of that SDK. Results? Safer and leaner Firefox (the old SDK exposed way too many internals). Oh, and that warm and fuzzy feeling after deleting code…

So I didn’t contribute to a big initiative such as a new rendering engine or whatnot, but it’s often the little non-glamourous things that need to be done. I’m proud of this work (which was also done on time). My team were great!

Another aspect I’m very thrilled about is how this work has set us up for more successes already, as we’ve developed new tools and systems to find out ‘bad stuff’ in our code, and now we’re using these outside of the Firefox “core” team to identify more things we’ll want to improve in the upcoming months. There’s a momentum here!

Who knows what else will the future bring? Maybe in 10 years time I’ll be telling you I shipped code for the new rendering engine in Firefox indeed! One has to be open to the possibilities…

Update: my colleague Lin has explained how Firefox Quantum is a browser for the future, using modern technology.

How to solve the “aborting due to worker thread panic” error message while compiling Firefox on a virtual machine

Short answer: allocate more memory to your virtual machine.

The error is produced because the build process ran out of memory when compiling Servo’s style crate.

I tried with 4096Mb and it seems to be happily chugging along now. I guess your mileage may vary, yadda yadda… 💁🏻

This is nothing short of miraculous as it’s a Virtual Machine running Linux in a Macbook retina (with 8 Gb of RAM), which is a moderately underpowered-for-compiling-things laptop. But hey, lightweight, right?

“*Utils” classes can be a code smell: an example

You might have heard that “*Utils” classes are a code smell.

Lots of people have written about that before, but I tend to find the reasoning a bit vague, and some of us work better with examples.

So here’s one I found recently while working on this bug: you can’t know what part of the Utils class is used when you require it, unless you do further investigation.

Case in point: if you place a method in VariousUtils.js and then import it later…

var { SomeFunction } = require('VariousUtils');

it’ll be very difficult to actually pinpoint when VariousUtils.SomeFunction was used in the code base. Because you could also do this:

var VariousUtils = require('VariousUtils');
var SomeFunction = VariousUtils.SomeFunction;

or this:

var SomeFunction = require('VariousUtils').SomeFunction;

or even something like…

var SomeFunction;
lazyRequire('VariousUtils').then((res) {
  SomeFunction = res.SomeFunction;
});

Good luck trying to write a regular expression to search for all possible variations of non-evident ways to include SomeFunction in your codebase.

You want to be able to search for things easily because you might want to refactor later. Obvious requires make this (and other code manipulation tasks) easier.

My suggestion is: if you are importing just that one function, place it on its own file.

It makes things very evident:

var SomeFunction = require('SomeFunction');

And searching in files becomes very easy as well:

grep -lr "require('SomeFunction');" *

But I have many functions and it doesn’t make sense to have one function per file! I don’t want to load all of them individually when I need them!!!!111

Then find a common pattern and create a module which doesn’t have Utils in its name. Put the individual functions on a directory, and make a module that imports and exposes them.

For example, with an `equations` module and this directory structure:

equations
  linear.js
  cubic.js
  bezier.js

You would still have to require('equations').linear or some other way of just requiring `linear` if that’s what you want (so the search is “complicated” again). But at least the module is cohesive, and it’s obvious what’s on it: equations. It would not be obvious if it had been called “MathUtils” — what kind of utilities is that? formulas? functions to normalise stuff? matrix kernels? constants? Who knows!

So: steer away from “assorted bag of tricks” modules because they’ll make you (or your colleagues) waste time (“what was in that module again?”), and you’ll eventually find yourself splitting them at some point, once they grow enough to not make any sense, with lots of mental context switching required to work on them: “ah, here’s this function for formatting text… now a function to generate UUIDs… and this one for making this low level system call… and… *brainsplosion*” 😬

An example that takes this decomposition in files to the “extreme” is lodash. Then it can generate a number of different builds thanks to its extreme modularity.

Update: Another take: write code that is easy to delete. I love it!

Organising files in Google drive

We use Google Drive at work and for a particular project we ended up in a situation where there were multiple documents related to it, but not an easy way to have “links” to all of them on the same place.

One solution would be to create yet another document and link to the documents. Another one is to bookmark documents in your own browser—but the issue is that if someone wants to collect all the links together in their computer, then they have to bookmark the stuff individually as well.

But there’s an easier way: you can make a folder in Google Drive and add any file to it (whether it’s owned by you or not). Then you can share the folder, and voilà! everyone has access to the collection of documents.

To make a folder in your drive, first go to your google drive. Click NEW… folder. Give it a name, for example: Magnificent folder.

Then go to the document you want to add to the folder, click on the File… menu, select Add to my drive. A little pop up will show up, click on the Organize link… Choose Move to folder, and choose the Magnificent folder you created before.

If you refresh the folder in your drive, the document should be present there.

To share the folder, click on the down-facing arrow on the right hand side of the name of the folder. This opens a drop down menu and you can select “Share…” to open the usual Google docs interface to share stuff with people.

Done!

I’d also suggest that changing the folder view from grid to list, showing the document titles, might be useful in many cases, as the document titles tend to get truncated way too easily.

If using ES6 `extends`, call `super()` before accessing `this`

I am working on rewriting some code that used an ES5 “Class” helper, to use actual ES6 classes.

I soon stumbled upon a weird error in which apparently valid code would be throwing an |this| used uninitialized in A class constructor error:

class A extends B {
  constructor() {
    this.someVariable = 'some value'; // fails
  }
}

I was absolutely baffled as to why this was happening… until I found the answer in a stackoverflow post: I had to call super() before accessing this.

With that, the following works perfectly:

class A extends B {
  constructor() {
    super(); // ☜☜☜ ❗️❗️❗️
    this.someVariable = 'some value'; // works!
  }
}

Edit: filed a bug in Firefox to at least get a better error message!