Console #102 -- Snapdrop, Memray, and Headless Recorder
An Interview With Nacho of Headless Recorder
🤝 Sponsor - Fractal
Become a founding CTO with Fractal
Fractal provides aspiring entrepreneurs with a business idea, a highly capable and complementary co-founder, capital, and ongoing support. There is no better pathway to becoming a successful startup founder than Fractal.
- Fractal de-risks the founding process, accelerating you past the biggest hurdles a new founder faces.
- Fractal’s risk-optimized approach gives first-time founders the best chance at success.
- Fractal is the best platform for a first-time entrepreneur to build a successful startup.
🏗️ Projects
Snapdrop
Snapdrop is a progressive web app for local file sharing in your browser, inspired by Apple's Airdrop.
language: JavaScript, stars: 11,819, forks: 1,065, issues: 162, last commit: March 17, 2022
repo: github.com/RobinLinus/snapdrop
site: snapdrop.net/
Memray
Memray is a memory profiler for Python. It can track memory allocations in Python code, in native extension modules, and in the Python interpreter itself. It can generate several different types of reports to help you analyze the captured memory usage data.
language: Python, stars: 5698, forks: 105, issues: 10, last commit: April 22, 2022
repo: github.com/bloomberg/memray
site: bloomberg.github.io/memray/
Headless Recorder
Chrome extension that records your browser interactions and generates a Playwright or Puppeteer script.
language: JavaScript, stars: 14,057 forks: 648, issues: 21, last commit: April 10, 2022
repo: github.com/checkly/headless-recorder
site: checklyhq.com/docs/headless-recorder/
🎤 Interview With Nacho of Headless Recorder
Hey Nacho! Thanks for joining us! Let’s start with your background. Where have you worked in the past, where are you from, how did you learn how to program, and what languages or frameworks do you like?
I think I have a diverse background, I consider myself a full-stack developer. I love to be involved in the whole development process, not just frontend and backend but also DevOps, database, infrastructure, etc.
I’ve worked in totally different industries (eCommerce, streaming, fintech, blockchain, monitoring) but I always try to contribute and be active in the open-source ecosystem. I mostly love JavaScript and Vue.js but I am always open to learning new things. Right now I started discovering Golang and it’s also a really beautiful language.
Which industry is your favorite so far and why?
I learned a lot from all the different industries and it also allowed me to face different kinds of challenges. That gave me a lot of versatility and of course experience. I don't think I have a favourite industry but what I have is a favourite type of company. I love to work for companies that have a product instead of ones that sell services. When you work on products code quality is better, you really care about what you are doing because every single mistake could make you lose a lot of money/customers/trust. It's also really satisfying to see how the product grows with your contributions and in general, you will be able to create more impact.
I also love the dynamics and the rollercoaster you get from early-stage startups. You need to put on different hats, work with dynamic priorities, and a lot of context switching. I admit that sometimes could be stressful but if you find how to deal with that you will never get bored and you will grow a lot.
Who or what are your biggest influences as a developer?
What's an opinion you have that most people don't agree with?
Vue is way better, scalable, and simple than React.
What’s your most controversial programming opinion?
I have two:
90% of your unit tests are useless.
TypeScript is over-engineering in most JavaScript average web/app/api.
What is your favorite software tool?
The terminal. I love that magic black box.
Do you have a favorite terminal, terminal tool, or terminal hack?
I use iTerm with zsh (oh-my-zsh). Right now I am in discovering VIM (it's hard to learn but it's really great) with tmux, fuzzy finders, yabai, and some other tools to improve my development workflow. I am kinda obsessed to automate as much as possible and make my daily tasks easier to get done.
If you could dictate that everyone in the world should read one book, what would it be?
If you had to suggest 1 person developers should follow, who would it be?
Gonzalo Pozo (AKA @goncy)
If I gave you $10 million to invest in one thing right now, where would you put it?
In Checkly, not only because it is the company I work for, but also because monitoring and testing are two crucial aspects of the software development process and we have been doing that in the wrong way for many years. As a famous software developer, Alejandro Crosa from Argentina says: “the whole of software is broken”, and we need tools to fix that.
If I gave you $100 million to invest in one thing right now, where would you put it?
Can I just keep it? I think if I had that kind of money I would invest in my own football team. I am a huge football fan and it’s a very profitable business, so why not?
What are you currently learning?
I am always learning new things and some of them in parallel but right now I am mostly dedicated to learning Golang, TypeScript and different IaC solutions.
What resources are you using to learn Golang and TypeScript?
The resources which work better for me are books, if I want to learn something seriously I will try to get a good book about that topic. I am also a happy user of Frontend Master (online course platform), I love their content and I found great courses about Golang and TypeScript there.
The books I recently bought:
- Learning Go: An Idiomatic Approach to Real-World Go Programming
- Infrastructure as Code: Dynamic Systems for the Cloud Age
- Programming TypeScript: Making Your JavaScript Applications ScaleCourses:
- https://frontendmasters.com/courses/go-for-js-devs
- https://frontendmasters.com/courses/typescript-v3/
Which Infrastructure as Code (IaC) solutions are you looking into?
Terraform and Pulumi. I really like the Pulumi approach because you can use whatever language you like/know in order to create your infrastructure. The process is simple and smooth!
What have you been listening to lately?
I love to listen to Cumbia, my favorite group is “Los Palmeras” but I could really listen to anything. I also started with some podcasts (Migue Granados, a comedian from Argentina) because I work remotely in my office, and sometimes it is a good way to have company.
What’s the funniest GitHub issue you’ve received?
I didn't get any of them yet, but sometimes people think that you are a robot that should be available 24/7/365 and they get upset if you don’t fix their issues or develop the features they want. There are people that do not understand how OSS works. Fortunately, there are only a few.
Why was The Headless Recorder started?
It’s hard to say because I didn’t start it 😅 (I became the Maintainer some years later) but I would say to speed up the E2E testing process and provide a good UX to record and create tests fast and simple
How did you end up becoming the maintainer?
Tim Nolet (founder and CTO of Checkly), created the headless recorder some years ago. He was always really involved in the monitoring/testing ecosystem. After creating Checkly, he moved the project scope to the organization and after some time the company started having a bunch of new open-source projects. And here is where I came in, they were looking for some with some "experience" (or passion) in open source to lead all the OSS efforts the company has. I was performing that role for more than 1 year, taking full ownership of all the open-source projects we have, pushing open-source initiatives (for instance, we donate 1% of our MRR to open-source maintainers), contributing to events, and of course, crafting a bunch of new things.
How do you decide which maintainers get a donation?
We tried to sponsor developers/projects that are relevant to us. Tools, frameworks, and libraries we use every day and made our work more pleasant. I decide the budget allocation and I try to distribute it within "the hidden maintainers", those people who work really hard making great contributions and don't get the recognition they really deserve. GitHub sponsor was being really helpful on that, you can easily access a list of projects that you depend on, so finding those maintainers was relatively easy. The "hard thing" is deciding how to split the donations, we are an early-stage startup and our budget is limited. All our donations are made through GitHub sponsors and are totally public in our profile.
The good news is that as soon as we start being more successful, the open-source ecosystem will also get a benefit from that. We also support open source projects with free plans of our product, people can find more info on our website and apply for support (https://www.checklyhq.com/open-source).
I encourage companies or whoever has a successful business that relies in some way on open-source software (99% of the internet business), to copy this initiative. Fortunately, we are not the only company doing this but most of the companies are not providing any kind of support (even Fortune 500 companies). It is very important to understand that open source projects need us as much as we need them and we need to start retributing everything they give us!
Where did the name for The Headless Recorder come from?
It used to be the Puppeteer Recorder, because it was a tool to generate code Puppeteer scripts from your UI interactions. But when we added support for Playwright, we had to find a more generic name and we moved to Headless Recorder, because both are tools used (mainly) for headless browser testing.
Who, or what was the biggest inspiration for The Headless Recorder?
The inspiration came from two tools: UI Recorder and Daydream. They are in the credits section of our repo README file.
What is the most challenging problem that’s been solved in The Headless Recorder, so far?
I don’t think we resolved it yet but something we are currently working on is the selector's engine. It’s a really hard and complicated problem to solve, we are looking for new approaches and moving forward with the latest patterns. Currently, we are relying a lot on CSS class names to get HTML unique selectors but that is not reliable at all. Modern web development has dynamic/random class generation, the selectors we generated in some cases are useless and that force our users to manually edit generated code and adapt it after the recording. We are looking for a way to generate these selectors in a fancy way, trying to achieve uniqueness using another kind of HTML attributes and providing a smooth UX for the users.
Playwright made a really good solution for that and this is open-source. I don’t want to re-invent the wheel so I will probably try to find a way to get the benefit of that.
What was the most surprising thing you learned while working on The Headless Recorder?
I learned that a strange, complex, and big code base could become friendly and familiar quite easily (and with some effort). It was a good training for me, it helped me take full ownership of projects that I didn't create but now I can totally manage and understand. I always loved this OSS magic where a user could become a contributor and later a contributor could become a maintainer. With the Headless Recorder I was able to experience that myself.
Yeah, I really want to dig into what that journey looked like. I think it's insanely inspirational, and I hope it inspires others!
In the beginning, is extremely frustrating because you don't understand anything. In my case, I didn't exactly know the real value of the project either, I've never used it before. So I had to make the whole process, like a normal user.
I started to use the tool for my own stuff and learn about the context of the tool as well (playwright, puppeteer, e2e, etc). I didn't read any code at that time and after some days that I got familiarized with the UX, I felt that was ready to start making contributions.
I started with the easy part, looking for small bugs, small design tweaks, and open "good-first issues", like any other person that wanted to contribute.
After a few PRs, I could (mostly) understand the code, the patterns, the tech limitations (it's a chrome app, you have a lot of them), and have a general overview of the project itself. Sometime later I was able to get full ownership of the project and start applying my own ideas.
The project was created some years ago, there were a bunch of tools and libraries that required an upgrade. We also wanted to link it in some way with Checkly's product, apply a redesign, improve the UX, and a bunch of other things We did and others that are still on the bucket list.
I also got a few contributions from users (and teammates). That was the way I experienced all the stages you have in the open-source virtuous circle that I mentioned before.
With open-source people move forward but the project could never end and it keeps evolving. The most important thing I learned is that you always need to keep feeding that circle.
What is your typical approach to debugging issues filed in The Headless Recorder repo?
Debugging is always hard. I first try to reproduce the problem locally, sometimes people do not provide really good information or context about the issues. I am a `console.log` debugger, but I also use proper tools when needed. I try to divide and conquer while I am looking for bugs, identify the parts that could be related to the error, discard what is not related and do a massive process of trial/error.
What are the more "proper" tools?
Some of the tools I often use:
- Chrome dev tools
- Vue.js Dev tools
- Responsively
- CURL
- Charles
- The terminal + UNIX commands
- Papertrail and Sentry
I am probably missing some other one
What is the release process like for The Headless Recorder?
The process is simple but is not really cool right now.
Use `npm version` to create a tag and bump package.json
Use vue-cli to build the extension and generate the zip files
Push changes and manually create the release in GitHub
Upload artifacts and create new version in Chrome Store
Every step here could be automated, I am working on some improvements using GH actions.
Is The Headless Recorder intended to eventually be monetized if it isn’t monetized already?
Never, but we would like to find possible ways to integrate with Checkly. We are not going to change the soul of the product and we are not going to link to them strictly. But, it would be great for us if people from the Headless Recorder could become Checkly users. Basically every script you record with our open-source tool you can easily run and configure on Checkly to monitor your website.
How do you balance your work on open-source with your day job and other responsibilities?
Fortunately right now, I work 90% of my time in open source and my company is paying me to do that. Crazy, right? Jokes aside, I really enjoy this role. Before this, I remember it was really hard to make time to maintain and contribute to OSS, I always found time to do it. But, right now, I do not need to sacrifice work, hobbies or time with my family in order to contribute. Thanks Checkly!
What is the best way for a new developer to contribute to The Headless Recorder?
Start with reading our open issues and checking the Public Roadmap. We try to be transparent on what we are working on and keep it updated. There are some open issues tagged with the “help wanted” label, people can ask us for context and start working on those. Will be really helpful for us!
If you plan to continue developing The Headless Recorder, where do you see the project heading next?
To be honest, I don’t know now. We are now in the phase of trying to look for new features, design changes and find how to make it a core product for Checkly.
There are a bunch of new tools doing similar things, but people are still choosing the Headless Recorder, so that is a good sign! There are some immediate things we need to start tackling now (like better code generation and a new selector’s engine) but besides that, I don’t have a clear map for the future.
What motivates you to continue contributing to The Headless Recorder?
I have the privilege to get paid for working in open-source. My role involves working 80% of my time with OSS projects. That is a beneficial and significant advantage. Most people are contributing in their spare time or as a hobby, so I am aware that they need to take this big opportunity and try to create some impact.
Are there any other projects besides The Headless Recorder that you’re working on?
A few of them, mostly projects related to Checkly (terraform provider, pulumi provider, CLI) but also things not related to a product like jamstackdeploy.com or the Vue.js Workshop.
Do you have any other project ideas that you haven’t started?
I would love to create more open-source workshops about different tech stacks: Vue.js, Nuxt, Git, The Terminal, Dev Workflows, and Deno. I like to share knowledge and I strongly believe that open source is not only about creating/coding software.
Where do you see open-source heading next?
I think we are on the rise, this is probably the decade of open-source and companies start noticing that. This is just the beginning, during the next couple of years companies will create more and more opportunities around open source. Right now we also have tools to allow developers, organizations, and projects to grow without any commercial commitment. Crowdfunding and sponsorship are having a really important role for maintainers. The crazy idea of getting paid for making open source is not that crazy anymore and I am really excited about the new things that this paradigm could bring. But don’t forget: if you rely on an open-source project you need to assume a commitment and find your way to re-contribute. OSS needs you!
Do you have any suggestions for someone trying to make their first contribution to an open-source project?
Dare to take the first step but also take it easy. Big projects are hard to start and large codebases can be overwhelming. Try to start with something small. For instance, instead of directly starting to contribute to the Vue.js repo, you can start with a small library or component related to Vue. There are also other ways to contribute that are friendly. For starters, you could write/translate docs, tooling, examples, and answer issues/questions.
Want to join the conversation about one of the projects featured this week? Drop a comment, or see what others are saying!
Interested in sponsoring the newsletter or know of any cool projects or interesting developers you want us to interview? Reach out at console.substack@gmail.com or mention us @ConsoleWeekly!