- Software Development
- The Time Travel Method of Debugging Software – InApps 2022
The Time Travel Method of Debugging Software – InApps is an article under the topic Software Development Many of you are most interested in today !! Today, let’s InApps.net learn The Time Travel Method of Debugging Software – InApps in today’s post !
Read more about The Time Travel Method of Debugging Software – InApps at Wikipedia
You can find content about The Time Travel Method of Debugging Software – InApps from the Wikipedia website
Developing programs that run seamlessly isn’t a linear task. The more intricate and complex the code, the more bugs that engineers potentially have to deal with. Studies have shown that software developers spend 35-50% of their time debugging.
Jason Laster, software engineer and founder of a startup called Replay, noticed the struggles developers were facing when debugging. “I joined Firefox to work on the Firefox Dev Tools debugger back in 2016. I wanted to make debugging easier and I kept running into issues where developers found breakpoints,” Laster said in an interview with InApps. “The way to make debugging easier is to make it feel more like adding a print statement in your code and then viewing the console logs.”
So the question that Laster tried to address was, how to make debugging more intuitive? The way to do this, he concluded, was to give developers “the ability to add print statements while debugging.” He compared this to time travel, noting that “it’s the daily record — something happening once and then be able to replay it and then add those print statements and see them in a console.”
Replay began as a pet project for Laster but soon turned into a viable product. Replay now allows its users to record and play back web applications, with developer tools that most programmers are acquainted with. Replay also allows users to share, comment, and inspect software with their team members. Making communication between engineers and the rest of the team is a part of “removing the friction between debugging and developers,” according to Laster.
GTM Lead Oliver de Albuquerque added, “You’ll actually never have to reproduce a bug ever again. You can just send the URL link to a replay.”
The Appeal of Time Travel
Reverse debugging, or time travel debugging, is a concept most developers are already familiar with. Though there are different tools with varying names and features, it all boils down to the same purpose: recording the execution of a program at runtime so that it can be replayed and shared with team members.
Traditional debugging is typically a mix of educated guesswork plus applying logic. Even though it works, moving forward through code, line by line while watching for bugs, isn’t always efficient. But according to de Albuquerque, there are instances where time travel debugging can be very useful.
A demo of Replay
“There are studies where [up to] two-thirds of a developer’s time is just spent trying to understand the application,” said de Albuquerque. “You can imagine Replay being used for developer teams to understand the state of their application when they have a new hire being brought on, or when they’re ramping up and scaling engineering teams.”
“The debugging problem is really the first tangible use case that people tend to lock onto,” he continued, “because it’s a real pain [that] many developers are dealing with on a daily basis.”
Programming with Less Difficulty
By removing the preconceived notions about how challenging programming is, Jason Laster became more confident in building a developer-friendly debug tool. “We want to make software more approachable,” he said. “We want more people to feel like they can program and do things that don’t require a math degree.”
He went on to say, “Imagine being a Project Manager and asking your engineer why something broke and receiving a long explanation that still leaves your question unanswered. Using Replay, they can share the URL with the engineers who can just go in and leave a comment. Now, the PM can recognize the function and identify what went wrong on their own. If anybody along the way can record the issue with Replay, then everyone downstream can look at the replay, debug it and see exactly what went wrong.”
Acknowledging that it’s easy to mistake Replay as another browser recorder tool, Laster explained how Replay differs. “On one end of the spectrum, you have something like a video recorder, then go along that spectrum a little bit further and you have something like a session replay tool and observability tool. Those kinds of tools give you some data about how the application is running, but you can’t debug in an observability tool. You can’t get your application from Rocket, right? If you go further, you have something like Chrome Dev tools and Firefox tools where you could actually debug an element in the Elements panel or the network, the network monitor, or the console.log set of breakpoints. With Replay, you can record your site, replay it down to lines of code, and then share it with others.”
Browsers for Developers
Replay’s developer tools are built with React. Its backend is compatible with a multitude of runtimes, which was a goal from the start of the project.
In a blog post, Laster wrote “Our goal is for runtimes to be replayable: we should be able to thoroughly understand our software no matter where it is running or what language it is written in. It would have been simpler to focus on one browser, but we designed Replay’s recorder to work across a range of runtimes and platforms from the start.”
According to Laster, their recorder is actually a browser.
“So when somebody makes a recording,” he continued, “they’re running our version of Firefox, our version of Chrome, our version of the Node. If you want to record your tests like your Cyprus test or playwright tests, you can record that in CI because there’s a browser. At the end of the day, it’s our version of these browsers.”
Laster then went into detail about the programming that was involved to create Replay. “I wrote at least a hundred lines of in-line assembly code that intercepts the low-level system calls that the browser makes. Allocate memory, open a socket, read and write to a file — those kinds of things. We record that, and then when you’re viewing a replay, we take that browser that was used to make the recording, download the recording, give it the recording, and it thinks it’s running on a normal computer, but it’s just running in the simulation. Almost like The Matrix.”
Photo by Fatih Turan from Pexels.
Let’s create the next big thing together!
Coming together is a beginning. Keeping together is progress. Working together is success.