As of September 2021, I am leaving Mozilla after 10 years. It hasn't been perfect but it's been a wonderful time with fond memories and an amazing career rocket ship.
In April 2011, I joined as a web developer to work on internal web applications that support the Firefox development engineering. In rough order, I worked on...
Elmo: The web application for managing the state of Firefox localization
Socorro: When Firefox crashes and asks to send a crash dump, this is the storage plus website for analyzing that
Peekaboo: When people come to visit a Mozilla office, they sign in on a tablet at the reception desk
Balrog: For managing what versions are available for Firefox products to query when it's time to self-upgrade
Air Mozilla: For watching live streams and video archive of all recordings within the company
MozTrap: When QA engineers need to track what, and the results, of QA testing Firefox products
Symbol Server
: Where all C++ debug symbols are stored from the build pipeline to be used to source-map crash stack traces
Buildhub: To get a complete database of all and every individual build shipped of Firefox products
Remote Settings: Managing experiments and for Firefox to "phone home" for smaller updates/experiments between releases
MDN Web Docs: Where web developers go to look up all the latest and most detailed details about web APIs
This is an incomplete list because at Mozilla you get to help each other and I shipped a lot of smaller projects too, such as Contribute.json, Whatsdeployed, GitHub PR Triage, Bugzilla GitHub Bug Linker.
Reflecting back, the highlight of any project is when you get to meet or interact with the people you help. Few things are as rewarding as when someone you don't know, in person, finds out what you do and they say: "Are you Peter?! The one who built XYZ? I love that stuff! We use it all the time now in my team. Thank you!" It's not a brag because oftentimes what you build for fellow humans it isn't engineering'ly brilliant in any way. It's just something that someone needed. Perhaps the lesson learned is the importance of not celebrating what you've built but just put you into the same room as who uses what you built. And, in fact, if what you've built for someone else isn't particularly loved, by meeting and fully interactive with the people who use "your stuff" gives you the best of feedback and who doesn't love constructive criticism so you can become empowered to build better stuff.
Mozilla is a great company
. There is no doubt in my mind. We ship high-quality products and we do it with pride. There have definitely been some rough patches over the years but that happens and you just have to carry on and try to focus on delivering value. Firefox Nightly will continue to be my default browser and I'll happily click any Google search ads to help every now and then. THANK YOU everyone I've ever worked with at Mozilla! You are a wonderful bunch of people!
Remember jQuery? Yeah, it was great. But it was also horrible in its own ways but only when compared to the more powerful tools that we have now as of 2021. I still (almost) use it here on my site. Atually, I use "fork" of jQuery called Cash which calls itself: "An absurdly small jQuery alternative for modern browsers." Cash is written in TypeScript, which gives me peace of mind, and as a JS bundle, it's only 19KB minified (5.3KB Brotli compressed) whereas jQuery is 87KB minified (27KB Brotli compressed).
But something that jQuery has, that Cash doesn't, is animations. E.g. $('myselector').fadeIn(). If you need to do this with Cash you can use the following pure JavaScript solution:
// Example implementationconstmsg=$('<div class="message">').text(`Random message: ${Math.random()}`).css("opacity",0).css("transition","opacity 600ms").prependTo($("#root"));setTimeout(()=>msg.css("opacity",1),0);setTimeout(()=>{msg.css("transition","opacity 1000ms").css("opacity",0);setTimeout(()=>msg.remove(),1000);},3000);
What this application demonstrates is the creation of a <div> that's immediately injected into the DOM but slowly fades into view. And 3 seconds later it fades out and is removed. Full demo/sample application here.
Sample application using cash like jQuery's $.fadeIn().
The point of the demo is how you can cause the fade-in effect with just Cash but still relies on CSS for the actual animation. The trick is to, ultimately, create it first like this:
<divclass="message"style="opacity:0; transition: opacity 600ms">
Random message: 0.6517198324628395
</div>
and then, right after it's been added to the DOM, change the style=... to:
What's neat about this is that you use the transition shortcut so it's done entirely with CSS instead of a
requestAnimationFrame and/or while-loop like jQuery's effects.js does it.
Note! This is not a polyfill since jQuery's fadeIn() (etc.) can do a lot more such as callbacks. The example might not be great but I hope this little solution becomes useful for someone else who needs this.
Like any responsible parent, I get heart palpitations when my kids (and especially their friends) rush through the door, in or
out, and just leave the door wide open letting all that sweet sweet air-conditioned coldness rush out like a prison break. My wife gave me these Gibcloser "Safety Door Closer" as a present and we installed them today on all 3 doors (front door, to-basement door, back porch door).
They're ~$18 on Amazon.com and it appears they come in many different colors. Our doors were white so that that's what we used. It took less than 30 minutes to install on all 3 doors. All you need is a screwdriver and, I would suggest, some thin foam command strips.
Door held at 90° and released.
I know it might sound silly but I've wanted this for so long and it never occurred to me that such a simple solution might exist. Clearly, we've all seen door closers like this before, but almost always bigger. Especially on commercial buildings. But they all seem so complicated and expensive-looking and definitely strike fear in you of: "that'd never work on my home doors". What's neat about these is that they are gentle. It's just a gentle (albeit accelerating) push but if someone/something was to get stuck as it closes, it wouldn't chop off a finger or a foot.
Truth be told, they don't close the door all the way. In the above video, it closes nicely because I held the door open at 90° which is a bit unrealistic angle that someone would forget to close the door. But at least it'll close it enough to stop the flow of cold/warm air going through.
Because it was driving me insane, and because I don't want to ever forget...
Playwright is a wonderful alternative to jest-puppeteer for doing automated headless browser end-to-end testing. But one I couldn't find in the documentation, Google search, or Stackoverflow was:
How do you submit a form without clicking a button?. I.e. you have focus in an input field and hit Enter. Here's how you do it:
You, or my future self, might be laughing at me for missing something obvious but this one took me forever to solve so I thought I'd better blog about it in case someone else gets into the same jam.
UPDATE (Sep 2021)
I found a much easier way:
awaitpage.keyboard.press("Enter");
This obviously only works when you've typed something into an input so the focus is on that <input> element. E.g.:
awaitpage.fill('input[aria-label="New shopping list item"]',"Carrots");awaitpage.keyboard.press("Enter");
We use Poetry
in a GitHub project. There's a pyproject.toml file (and a poetry.lock file) which with the help of the executable poetry gets you a very reliable Python environment. The only problem is that adding the poetry executable is slow. Like 10+ seconds slow. It might seem silly but in the project I'm working on, that 10+s delay is the slowest part of a GitHub Action workflow which needs to be fast because it's trying to post a comment on a pull request as soon as it possibly can.
First I tried caching $(pip cache dir) so that the underlying python -v pip install virtualenv -t $tmp_dir that install-poetry.py
does would get a boost from avoiding network. The difference was negligible. I also didn't want to get too weird by overriding how the install-poetry.py works or even make my own hacky copy. I like being able to just rely on the snok/install-poetry GitHub Action to do its thing (and its future thing).
The solution was to cache the whole $HOME/.local directory. It's as simple as this:
The key is important. If you do copy-n-paste this block of YAML to speed up your GitHub Action, please remember to replace .github/workflows/pr-deployer.yml with the name of your.yml
file that uses this. It's important because otherwise, the cache might be overzealously hot when you make a change like:
Now, thankfully install-poetry.py (which is the recommended way to install poetry by the way) can notice that it's already been created and so it can omit a bunch of work. The result of this is as follows:
From 10+ seconds to 2 seconds
. And what's neat is that the optimization is very "unintrusive" because it doesn't mess with how the snok/install-poetry workflow works.
But wait, there's more!
If you dig up our code where we use poetry you might find that it does a bunch of other caching too. In particular, it caches .venv it creates too. That's relevant but ultimately unrelated. It basically caches the generated virtualenv from the poetry install command. It works like this:
In this example, deployer is just the name of the directory, in the repository root, where we have all the Python code and the pyproject.toml etc. If you have yours at the root of the project you can just do: run: poetry install and in the caching step change it to: path: .venv.
Now, you get a really powerful complete caching strategy. When the caches are hot (i.e. no changes to the .yml, poetry.lock, or pyproject.toml files) you get the executable (so you can do poetry run ...) and all its dependencies in roughly 2 seconds. That'll be hard to beat!
