So you want to optimize your code, eh? Who am I to blame you? I certainly want you to optimize your code! I spent a few years as part of the Firefox Performance Team, on the frontline of, well, performance. I still bear some of the scars. So, as the grizzled perf-veteran that I have decided to be for the day, let me invite you to sit down for a while and share a little hard-earned experience on code optimization.

(This is meant to be the first entry of a series which will cover individual points more in depth. We’ll see how that goes.) We’re the tech industry. We have ideas. We have ideas all the time. And we’re used to turn our ideas into applications. So, how does it go… here’s the back-end component… here’s the front-end component. We’ll write the former in Python, or perhaps JavaScript, to optimize for prototyping. After all, we have so many ideas, we need the ability to iterate quickly. Sprinkle in a few dependencies, that will speed us up. Oh, and let’s use ChatGPT and Copilot, we’ll be even faster. Oh, and performance, yeah, performance: microservices, Kafka, Redis, Kubernetes… we’re now ready to scale up. Oh, Sentry, Prometheus and Grafana, too, where would we be without ’em? For the front-end, we’ll write a website, and for mobile, Electron. Oh, wait a second, we need to make money and to fidelize our users! Let me see… ads, tracking, and good reasons to revisit our app, perhaps a little NFT here, gamification… alright, we should be good. Three… two… one… and we have shipped v1! Also, the world is burning. Perhaps it’s time we revisited how we do things?

Recent publications by Consumer Reports and the NSA have launched countless conversations in development circles about safety and its benefits. In these conversations, I’ve seen many misunderstandings about what safety means in programming and how programming languages can implement, help or hinder safety. Let’s clarify a few things.

The web is getting darker. It is being weaponized by trolls, bullies and bad actors and, as we’ve witnessed, this can have extremely grave consequences for individuals, groups, sometimes entire countries. So far, most of the counter-measures proposed by either governments or private actors are even scarier. The creators of the Matrix protocol have recently published the most promising plan I have seen. One that I believe stands a chance of making real headway in this fight, while respecting openness, decentralization, open-source and privacy. I have been offered the opportunity to work on this plan. For this reason, after 9 years as an employee at Mozilla, I’ll be moving to Element, where I’ll try and contribute to making the web a better place. My last day at Mozilla will be October 30th.

On this rainy october day (well, at least it rains where I’m writing this) of the great year 2020, let’s take another few minutes to reflect on some great practices that we have at Mozilla and that would deserve to take over the world. Today, let’s talk about what you can do when your work is blocked.

Let’s continue this series on some of the great practices that we have at Mozilla and that your project may wish to adopt, too. This time, let’s talk about Mozilla’s #introduction chatroom.

2020 is a crappy year for pretty much everyone. As you may have seen, this includes organizations such as Mozilla. So I figured it was the best time to actually talk about good stuff! This entry should be the first of a series of short articles dedicated to some great practices we have at Mozilla and that I think many open-source projects could adopt. At its core, Mozilla is a community of open-source enthusiasts. When you’re new to an open-source community and you wish to start contributing somewhere, finding an entry point is often difficult. This is where Mentored Bugs come in.

TL;DR: Firefox used to have a great extension mechanism based on the XUL and XPCOM. This mechanism served us well for a long time. However, it came at an ever-growing cost in terms of maintenance for both Firefox developers and add-on developers. On one side, this growing cost progressively killed any effort to make Firefox secure, fast or to try new things. On the other side, this growing cost progressively killed the community of add-on developers. Eventually, after spending years trying to protect this old add-on mechanism, Mozilla made the hard choice of removing this extension mechanism and replacing this with the less powerful but much more maintainable WebExtensions API. Thanks to this choice, Firefox developers can once again make the necessary changes to improve security, stability or speed. During the past few days, I’ve been chatting with Firefox users, trying to separate fact from rumor regarding the consequences of the August 2020 Mozilla layoffs. One of the topics that came back a few times was the removal of XUL-based add-ons during the move to Firefox Quantum. I was very surprised to see that, years after it happened, some community members still felt hurt by this choice. And then, as someone pointed out on reddit, I realized that we still haven’t taken the time to explain in-depth why we had no choice but to remove XUL-based add-ons. So, if you’re ready for a dive into some of the internals of add-ons and Gecko, I’d like to take this opportunity to try and give you a bit more detail.

A number of programming languages offer a feature called “Named Arguments” or “Labeled Arguments”, which makes some function calls much more readable and safer. Let’s see how hard it would be to add these in Rust.

Years ago, Andrew Kennedy published a foundational paper about a type checker for units of measure, and later implemented it for F#. To this day, F# is the only mainstream programming language which provides first class support to make sure that you will not accidentally confuse meters and feet, euros and dollars, but that you can still convert between watts·hours and joules. I decided to see whether this could be implemented in and for Rust. The answer is not only yes, but it was fun :)