Unless you live under an actual rock and haven’t hauled yourself into modern times, I’m sure you know – and most likely use – JavaScript. You know, the versatile and dynamic programming language that powers the web and beyond. From client-side scripting to server-side computing, and even robotics, JavaScript is everywhere. 

However, like any good craftsperson, a JavaScript developer knows that their work is only done once it’s been tested. That’s where testing frameworks come into play. These tools make it easier to ensure your code is behaving exactly as you’d expect, taking the guesswork out of releasing new versions. 

So let’s get to the point of why you’re here, reading this blog, and dive into the top 6 JavaScript testing frameworks that are making waves in the development world.

#1 – Mocha: The Full-bodied Framework 

Mocha came into existence in 2011 and has matured beautifully, much like a fine wine. Its syntax is simple and straightforward, offering developers an easy-to-use platform for asynchronous testing. Mocha’s flexibility is one of its key strengths. It doesn’t assert any specific style of tests, letting you pair it with assertion libraries like Chai and Sinon. 

Mocha is popular among developers for its detailed error reports, making debugging a breeze. It’s widely adopted, with a large, active community that contributes to its continuous development. IDE support is extensive, and the development speed is rapid, thanks to asynchronous capabilities. Notable projects like Brave Browser and Web3.js have taken advantage of Mocha’s robustness. However, its flexibility can also be a weakness, as it may require additional libraries for assertions and spies (a way of recording function arguments).

#2 – Jest: The Jester of JavaScript Testing

Jest, introduced by Facebook in 2016, is another heavyweight in the testing realm. It’s matured quickly and is now favored for its simplicity and zero-configuration setup. Its syntax is intuitive and user-friendly, which, combined with rich, detailed documentation, makes Jest incredibly easy to use. 

Jest’s main strength is its comprehensive nature. Unlike Mocha, it includes a complete set of testing utilities (such as DOM snapshots and testing), eliminating the need for additional libraries. Parallel test execution is built-in to speed up the development process. The community is vibrant, and IDE support is strong, with projects like React and Airbnb using Jest. However, its large API can be a double-edged sword, potentially overwhelming new users.

#3- Jasmine: BDD for JavaScript

Jasmine has been around since 2010, giving it a long history and a high level of maturity. Its syntax is clear and readable, making it simple to use for both new and experienced developers. 

Jasmine is a behavior-driven development (BDD) framework with features like spies and async support. It’s been adopted by projects like AngularJS and is popular among developers who prefer a comprehensive, out-of-the-box solution. The community is stable and supportive, and the development speed is impressive. However, the lack of an assertion library and manual mocking can be a downside for some.

# 4- QUnit: The Quantum Leap in Testing

QUnit, the oldest in our lineup, was developed by the jQuery team in 2008. Despite its age, it’s maintained a reputation for stability and reliability. Its syntax is straightforward but may seem a bit archaic compared to newer frameworks.

QUnit shines in its simplicity, offering basic functionalities without the frills. It’s ideal for testing jQuery projects and has a dedicated, albeit smaller, community. IDE support is decent, and the development speed is satisfactory. However, there might be better choices for complex applications due to its lack of advanced features.

# 5- Cypress: The Evergreen Testing Framework

Cypress, a newcomer in comparison, was launched in 2014. It’s gaining traction quickly due to its unique end-to-end testing approach. Cypress’s syntax is simple, and it excels in its ease of use. It enables developers to write tests in a real browser environment, making it a great tool for testing complex frontend applications.

Cypress stands out with its automatic waiting feature, which means you don’t have to manually add waits or sleeps to your tests. Its real-time reloading feature boosts development speed, making it a hit among developers. The community is rapidly growing, and IDE support is solid. Despite its relative youth, it’s been adopted by organizations like NASA and DHL. However, it only supports Chrome-based browsers, which may be a hindrance for some.

# 6- Puppeteer: The Master of Web Manipulation

Puppeteer, released by Google in 2017, is a high-level API over Chrome DevTools Protocol. Its syntax is modern and fairly easy to grasp, particularly for those familiar with async/await.

Puppeteer’s primary strength lies in its ability to perform actions that emulate real user interactions, making it excellent for end-to-end testing. With its headless browsing capabilities, it can automate virtually anything in a browser. The community is robust, and Puppeteer enjoys direct support from Google, bolstering its development speed. It’s been adopted by notable projects like Angular and GoogleChromeLabs’ tooling report. However, similar to Cypress, its browser support is limited.

Wrapping Up The Code

JavaScript testing frameworks are the unsung heroes of the development process. They help to catch bugs, reduce errors, and ultimately deliver a better product. Whether you’re drawn to the full-bodied flexibility of Mocha, the jester-like comprehensive nature of Jest, the allure of Jasmine’s BDD style, the quantum simplicity of QUnit, the evergreen automatic waiting feature of Cypress, or the masterful browser manipulation of Puppeteer, there’s a framework for everyone. 

Keep in mind that chooing the right frameworks depends as much on project needs as on personal preferences. When faced with this kind of technical choices, it’s important to note they can be very difficult to reverse down the line. It’s a great idea to try out a few options, even going as far as writing a couple of tests with each framework, to get some hands on experience.
Happy coding, and may your tests always pass! You can learn more about how Rookout intergrates with testing frameworks right here.

A paradigm shift is overdue in the realm of software observability. While Site Reliability Engineers (SREs) have been having fun with metrics, traces, and logs, software developers have been left in the lurch, shackled to the conventional, low-fidelity tool of logs. Why should SREs have all the fun, right?

Welcome to the dawn of a new era. An era where developers, too, can enjoy superior observability engineering. That’s where the fourth pillar of observability comes in: Snapshots.

Logs: Low Fidelity vs. Snapshots: High Fidelity

Traditionally, logs have been the mainstay of debugging for developers. They provide insight into the system’s behavior and serve as the primary source of data during issue investigation. However, their information is often limited, sometimes irrelevant, and quite noisy. This ‘low-fidelity’ nature makes them less efficient in capturing the full picture of a system’s status, hindering quick problem resolution.

Snapshots, on the other hand, are the antithesis of logs in terms of fidelity. A snapshot is a high-fidelity, contextual image of your application’s state at any given moment. It can contain variable values, stack traces, and other metadata, making it a richer and more informative source of data. The high fidelity of snapshots provides an in-depth view of the code execution, facilitating more efficient debugging and reducing the time to resolution.

The Pain of Optimizing Logs

Let’s be honest. Working with logs is a nightmare, isn’t it? They require a great deal of optimization, necessitating constant tinkering with the code to ensure that the logs capture the right data. It’s a time-consuming process, fraught with challenges, and the end result may still not be optimal.

To make it even more difficult, logs are often not ‘developer-friendly’. Developers have to carefully choose what to log, balancing between log verbosity and performance impact. Too little logging and there might not be enough data to diagnose an issue. Too much logging and the system could be bogged down with the performance cost, not to mention the hassle of sifting through mountains of irrelevant log entries. This often leads to an iterative, try-and-fail process of determining the right amount of logging, significantly impeding the development cycle.

Additionally, developers often have to anticipate which data will be required for future debugging sessions, which is inherently problematic. As we have yet to encounter any developers who can see the future, this makes predicting future issues accurately a difficult, if not impossible, task. Thus, developers often find themselves in situations where the logs don’t contain the necessary information to diagnose an issue, thereby leading to more time lost in log augmentation.

Last but not least, making changes to logs, whether adding new ones, removing outdated ones, or updating existing ones, involves modifying the code, testing, and then deploying the updated service. Each of these steps consumes a significant amount of time and resources, slowing down the overall software development process.

From a financial perspective, these inefficiencies translate to real costs. The time and resources consumed in log optimization not only slow down the development cycle, leading to delayed releases, but also represent labor hours that could have been spent on feature development, enhancements, or innovation. Additionally, extensive logging results in high storage costs. As data generation accelerates, managing and storing these logs can be a severe financial burden. 

Snapshots: Contextual Data in Real-time

In contrast, snapshots offer a more seamless, efficient solution. They allow you to see data in the context of the code, eliminating the tedious back-and-forth involved in decoding logs. With snapshots, there’s no need to manually map log data to code, as they are designed to give you the relevant information right where you need it.

Snapshots provide a context-rich view of your application’s state in real-time, offering a more granular and detailed understanding of your code’s behavior. They make it easier to identify and address problems, significantly reducing the time spent on resolving issues. They are not just a stand-alone tool but a piece of a larger observability engineering puzzle, complementing and enhancing the effectiveness of the other three pillars – logs, metrics, and traces.

While logs are the fundamental basis for observability, providing raw data about system events, metrics offer a high-level overview of system health and performance, and traces give insight into request flows across services. However, even with these tools, developers often grapple with the question: “What exactly is happening inside my code at this moment?”

This is where Snapshots truly shine. Snapshots provide a contextual, real-time view of your code’s execution, bridging the gap between these high-level statistics and the granular detail of specific code execution. They complement metrics by providing detailed context for changes in system behavior. They supplement traces by offering a deep dive into specific function calls or service interactions. And they enhance logs by providing a rich, detailed picture of your code’s state at any point in time, eliminating guesswork and assumptions.

Snapshots: Reliability and Relevance

Logs, by nature, are based on a plethora of assumptions and can quickly become outdated. This results in a situation where you might base your analysis and decisions on inaccurate or obsolete information.

Snapshots, however, are highly reliable. They capture the exact state of your application at a specific point in time, ensuring the data’s relevance and accuracy. This allows developers to make informed decisions based on up-to-date, precise information, significantly reducing the chances of errors.

Snapshotting without Redeployments

One of the best things about snapshots is the ability to add them in real-time without requiring code changes or deployments. This is a game-changer for developers as it eliminates the cumbersome, time-consuming process associated with log optimization, enabling a more streamlined approach to observability. By combining snapshots with logs, metrics, and traces, developers can gain a comprehensive view of their software – from macro performance metrics to micro-level code execution details.

Let’s not stop at the three pillars of observability; let’s raise the bar and embrace snapshots and give developers the observability tools they deserve and need to make their jobs easier. Snapshots promise a future where high fidelity, real-time, and context-rich data are not luxuries but norms in software debugging. Get ready to say goodbye to the limitations of logs and welcome the powerful capabilities of snapshots in your developer toolkit.

So, here’s the takeaway: logging sucks. But with snapshots, we’re hoping to change that narrative. Let’s elevate our observability game. Together.

If you’re intrigued by this new way of approaching observability software, be sure to stay tuned. We’ll be diving deeper into the power of snapshots in our next blog post. And if you want to learn more about the fourth pillar of observability, watch Liran Haimovitch’s webinar on SDTimes on this exact topic. Enjoy!

Cloud logging services have long been plagued by limitations and high costs, hindering companies’ ability to achieve true flexibility in their operations. One of the primary obstacles is the lack of flexibility in traditional cloud logging services, which often require companies to make upfront decisions about log levels and storage capacity, locking them into fixed plans for extended periods. This leads to inefficient resource allocation, as companies either overpay for excessive log capacity they don’t fully utilize or face log shortages during critical moments.

However, these limitations go beyond the cost of logging. It impacts the developers themselves, with the sheer volume of logs generated in modern applications overwhelming developers, hampering their ability to troubleshoot and debug effectively. This, when coupled with a developer’s fear of missing out on logging data (or Logging FOMO, as we like to call it), can increase the time and effort required to identify and resolve issues, impacting developer productivity and slowing down the software development lifecycle. Navigating through vast amounts of logs becomes a daunting task, often resulting in critical information being overlooked.

However, a recent breakthrough has introduced a new tool to combat these long-standing challenges: the ability to dynamically access your logs, wherever, whenever. No more storage. No more FOMO. Let’s take a look.

The Need for Flexibility in Cloud Architecture

Companies operating in a cloud architecture – or planning to migrate to one – have a clear expectation: they are looking for the ability to consume technological services on demand, aligning with their actual usage patterns. This flexibility empowers organizations to efficiently scale their utilization of cloud resources during periods of high data loads and promptly reduce it when necessary. 

By leveraging this dynamic approach, businesses can effectively manage costs and gain a competitive edge. Unfortunately, it isn’t that simple or easy, and what you require isn’t always what you receive.

The Inflexibility of Traditional Cloud Logging Services

Unless you’ve been living under a rock, you’re sure to know – and have probably felt yourself – how most traditional cloud logging services fail to provide the desired level of flexibility and instead impose exorbitant prices on organizations.

One of the primary limitations is the rigid structure and predefined schemas imposed by these services. Traditional logging solutions typically require a predefined log format, limiting the types of data that can be logged and the level of customization that organizations can achieve. This inflexibility makes it challenging to capture and store diverse types of logs in a unified manner, such as application logs, system logs, and security logs.

If that isn’t enough, traditional cloud logging services are also limited in scalability. These services often have predefined storage capacities and processing capabilities, which can become a bottleneck as data volumes increase. Scaling these services to accommodate higher log ingestion rates or larger storage requirements typically involves complex configuration changes and may result in downtime or disruptions to the logging infrastructure. This lack of scalability hampers organizations’ ability to effectively handle sudden spikes in log data, such as during periods of increased user activity or when dealing with security incidents.

A Trade-off Between Access and Costs

Oftentimes, to mitigate performance issues and high expenses associated with maintaining and accessing logs at high levels, companies opt for printing only a subset of logs. By selectively choosing log levels that suit their requirements, businesses strike a delicate balance, enabling them to resolve bugs efficiently while keeping costs manageable.

Planning for Future Logging Needs

Immediate log-level expansion is a complex process that necessitates application redeployment. To avoid this challenge, many organizations opt to purchase larger log packages in advance. This proactive approach allows them to have the necessary information readily available, quickly resolve bugs, and restore normal service and product functionality. Yet, it comes with the obvious downside: an increased cost.

Yet, what if there were another option? One in which organizations were not bound by decisions made in advance regarding their production and other environments’ log levels. Fortunately, there is. Specifically, there is the option to use one of the innovative, flexible, and cost-effective solutions that have emerged in the market, enabling dynamic consumption of logs on demand. These solutions empower companies to reevaluate their log management strategies, ultimately reducing fixed costs.

These new solutions enable developers to instantly access the logs and information they need to expedite bug resolution in any runtime environment. Key features to consider when evaluating such solutions include the ability to easily adjust verbosity levels, even in a production environment, and receive logs at the Info, Debug, or Trace levels. These logs play a crucial role in resolving bugs promptly as they occur. Even more so, these solutions optimize log printing costs and enhance application performance, benefiting the organization as a whole.

Rookout, for example, does all of that. With the introduction of Snapshots, Rookout has given developers the ability to unlock peak efficiency and effectiveness. They are now provided with everything they need to know, as Snapshots capture the most relevant application state and give a clear, detailed, high-fidelity image of what’s happening. No longer do developers need to experience Logging FOMO or waste time sifting through logs. Instead, they can get the data they need to understand what’s happening in their application, exactly when they need it, wherever they need it.

Reduce Those Cloud Logging Costs

It’s time to stop complaining over logging costs and jump into the future of logging. We fully understand the importance of investing in tools that enhance developer productivity, and that’s why we advocate for solutions that offer maximum value for your money. Instead of wasting precious time scouring through logs or crafting new log lines, empower your developers with instantaneous insights into their live applications.

Rookout’s Dev-First platform equips R&D teams with the ability to effortlessly access logs and code-level data, enabling them to swiftly pinpoint root causes and resolve issues on the fly, all while minimizing costs throughout the entire software development lifecycle. Thanks to our innovative live Snapshots, you can capture a detailed, context-rich picture of any incident and gain invaluable code-level insights. 

Bid farewell to exorbitant log storage expenses, as the real-time snapshot of your application state is just a click away. Embrace the logging revolution and unlock a world of efficient, cost-effective development.
Sounds good? Talk to us. Let’s make it happen for you.

As digital transformation and the consequent move towards cloud-native continues to accelerate, and customer demands increase, traditional approaches to debugging and troubleshooting are limited and insufficient. Developers must quickly understand the relationships between user sessions, topology, and end-to-end transactions during incidents. This is made all the more difficult when they encounter the complexity of cloud-native environments and makes working in their production environments much more difficult. 

And yet, it’s not just the team that’s impacted. It’s a domino effect. While it might start in the code with an issue or a bug, it could escalate and impact your customers and bottom line. Which, of course, can’t happen. 

That’s why most organizations have already implemented various methods of coping with these challenges, whether it’s the shift-left methodology, ownership, or onboarding of new tools for better visibility. But what happens when you combine all of those? This blog will explore exactly what you should do to ensure your R&D team can fix issues faster.

Common Observability Challenges of Cloud-Native Architectures

Observability in cloud-native architectures is complex due to the distributed nature of microservices and containerized environments. Identifying and isolating the root cause of issues that may arise in the system can be difficult, as numerous moving parts and dependencies are involved. Traditional monitoring solutions are often not enough to capture the full picture. Additional observability tools such as tracing, logging, and metrics must be leveraged for a holistic view of a system’s performance. If that wasn’t enough to deal with, it’s essential to ensure that these tools are designed for cloud-native environments and can keep up with the scale and complexity of the system.

Shift-left practices aim to catch issues early in the development cycle by shifting quality and testing activities left in the software development lifecycle. This allows developers to detect and address issues before they become problems in production environments, which is crucial in cloud-native architectures where fast iteration and continuous deployment are common. 

When developers have access to production environments, they can better understand how their code behaves in the actual environment and make informed decisions that optimize performance and reliability. They can get real-time feedback on code changes by building observability into the development process and proactively addressing potential issues. Observability and shift-left practices go hand-in-hand, as they both contribute to creating more resilient and reliable cloud-native architectures. But without ownership of production environments, they’ll still be limited in what they can do.

So What Does Ownership Look Like?

When developers have ownership, they are responsible for the health and well-being of the code they have written. This means they have a vested interest in the success of their code and take accountability for any issues that arise. But we can all be honest; not every company and management team is comfortable giving developers that level of access. 

But we’re here to tell you that while we understand your fear, it’s wrong. Giving your devs production access will only benefit you. You’ll find that you’ll have better quality code and faster issue resolution. 

Start by providing clear expectations and guidelines. Define what it means to have ownership, what responsibilities come with it, and what metrics are used to measure success. Provide training and support to help your team understand the production environment and the available tools. One common example of ownership is through on-call rotations, a model in which developers are responsible for monitoring and addressing any issues that pop up in production environments during a specific time period. 

The Observability Tools For Success

Unfortunately, ownership on its own isn’t enough. Observability is essential to detect and diagnose problems in modern cloud-native applications. However, the specific observability needs depend on the role. For instance, developers need it to understand the behavior of their code during development and testing, whereas SREs require it to maintain service-level agreements in production environments. And to do so, both of them need the proper tooling. Let’s take a look at classic examples.

Enter Dynatrace (for end-to-end visibility across cloud-native applications) and Rookout (for debugging and troubleshooting production-level code). 

The Dynatrace APM platform is a powerful tool that provides end-to-end visibility across cloud-native application stacks. The APM can detect and diagnose problems across complex microservices, containers, and serverless architectures. Dynatrace automatically maps out all the components of an application and visualizes the dependencies between them. This helps detect anomalies and diagnose problems quickly, minimizing user impact.

Rookout, on the other hand, enables developers to debug and troubleshoot code in production environments. Unlike the APM, Rookout focuses on providing developers with real-time visibility into their code with no code changes required. This is especially helpful when bugs must be fixed quickly, but access to the source code is unavailable, or the problem cannot be reproduced.

But these aren’t stand-alone tools. For maximum effect, Dynatrace and Rookout (or other similar tools) can be used together to provide full observability for both developers and SREs. With both tools, developers can identify and troubleshoot issues faster, as well as proactively identify performance issues and optimize code for better performance. SREs can use APM to identify issues with infrastructure and dependencies and Rookout to identify issues with code.

This is probably the part where you ask yourself, “Okay, these tools sound cool – but so what? Where is my complete view of what’s going on in my code?”. 

That’s where the fourth pillar of observability – snapshots – comes in. Snapshots allow developers to capture a complete view of an issue, including application code, infrastructure, dependencies, and runtime data. This provides a more holistic view of the issue and enables faster troubleshooting. For example, a developer using Dynatrace APM and Rookout might notice that a particular function is taking longer to execute than usual. With Rookout, they can inspect the code in real-time to identify the root cause of the issue. They can then capture a smart snapshot that includes the code, runtime data, and infrastructure data, and share it with the SRE team. The SRE team can use the smart snapshot to identify any infrastructure or dependency issues that might be causing the problem. The developer and SRE team can resolve the issue quickly and minimize user impact. Awesome, right?

Python ∙ Java ∙ Go ∙ .NET ∙ Ruby ∙ Node.js & MORE. Rookout covers it all.

Try Rookout for free!

The TL;DR of Observability and Ownership

As we’ve seen, traditional observability and troubleshooting approaches are no longer sufficient in today’s complex production environments. R&D teams need access to the methodologies and tools that provide end-to-end observability and allow them to identify and resolve issues quickly. Ownership of production environments will give you better-quality code and faster issue resolution. End-to-end visibility across cloud-native application stacks will help your team detect and diagnose problems. By capturing metrics, log lines, and debug snapshots from a running application, they can troubleshoot faster and get instant insight into their app. 

So that’s it. No need to complicate it – we all have enough complicated code as is. For faster issue resolution, give your team the gift of ownership, observability, and the proper tooling to get both.
Talk to us to learn more about how you can level up your observability and ownership! We’ve got you covered.

Logs are the core of the human-machine interface for software developers and operators. Historically, they are very much like caveman paintings. They were our first attempt to express and understand how our software was working.

For several decades, logs were an island of calm in a rapidly changing technological ecosystem. Logs remained the same even as software services became web-based and grew in scale. We added context to make them easier to search through, moved them to a structured format, and over the past decade or two, started to aggregate and index them for ease of use.

And yet, at some point, that wasn’t enough. Thus, the three pillars of Observability were born: Logs, Metrics, and Traces.

Why do we need Metrics?

One of the most common questions we ask ourselves while monitoring the web server is, “how many requests for that URL did we get over the last minute?” To answer this question using logs, we must collect logs from all servers, parse individual lines, filter the relevant URLs, and count the results.

Whether we build a dedicated pipeline for this metric or calculate it by querying a fully indexed logs database, it’s a long and arduous process for both man and machine and unlikely to give us results in real-time.

Think of metrics as a way to efficiently aggregate multiple log lines of the same instance at the source application. By counting (or using other forms of aggregations such as summing) each event, you can efficiently get a real-time value of the behavior of your application as a whole.

A much more efficient way to get high-quality data is to create a counter inside the application and export it to the Observability stack, which will aggregate it and produce the relevant reports.

So where does Distributed Tracing come in?

Modern web applications are running on a much grander scale than ever before. We shifted our engineering paradigms and have adopted new architectural patterns, such as microservices and reactive programming.

Unfortunately, this has fundamentally broken the unwritten promise of logs: that we can tell the story by connecting the dots one log line at a time. One can no longer assume that two consecutive log lines are part of the same request, or even use process and thread IDs to build the timeline.

Distributed Tracing is a way to generate the timeline of individual requests and other processing tasks. This way, we can easily keep track of each step within the flow, even as it crosses service and functional boundaries.

What’s still missing?

By adding Metrics and Distributed Tracing, the three pillars of Observability significantly improved the operational paradigm of modern cloud-native applications.

Metrics allow us to bind log lines vertically and see how the system behaves over many requests. Tracing allows us to bind log lines horizontally and know how the system behaves through the lifespan of a single request. Both tools are super valuable for understanding the system as a whole and excite SREs and architects across the globe.

And yet, for most software organizations, the software developer is the most common engineering role-those poor souls who spend most of their time writing and debugging code.

We shift responsibility left and want engineers to own their code across the whole software development lifecycle, all the way to production. They don’t care about the number of requests or how requests cross service boundaries. What they want to know is how the code behaves.

What does it take to understand the code?

The incredible power of modern code is that the sum is way more than the value of its parts. Each variable is an abstraction, combining code and data to provide superb power with only a few characters of text. The layers stack on top of each other.

The code in question might be your code, or it might be first, second, and third-party packages and services, many of which are open-source. The data comes from various configurations, databases, caches, user settings, user inputs, feature flags, and more. Add to that the current state of the application, which often brings its own set of caveats, especially for long-running processes.

Squeezing that invaluable context into a single log line is no picnic. When stringifying primitive values into a log line, you lose some of the finer points, such as type information. When stringifying complex objects, the challenge is even greater.

Will you take a lean approach and miss out on invaluable information? Or will you take a deeper capture and impact the application’s performance? Chances are, you won’t bother in the first place, and pray that whoever built the library provided a decent stringification flow that won’t do too bad on either front.

Even worse, the current line is only a tiny part of the application state. What about the stack trace, the request context, or other valuable information?

What’s better than logs? Snapshots.

Snapshots as the fourth pillar of Observability that meets that need. By capturing most of the relevant application state, you get a clear, detailed, high-fidelity image of what’s happening. To paraphrase: a Snapshot is worth a thousand log lines.

Snapshots provide everything you need to know. Variables are captured with full fidelity, maintaining type information and exact representation. Objects are captured by individual attributes, and collections are appropriately enumerated. The stack trace and other global variables are readily available.

As is often the case with software engineering, Snapshots are not a new concept. Operating systems such as Linux and Windows had snapshot tools (core dumps) for years, used to analyze kernel and application crashes. Error monitoring tools such as Sentry or Bugsnag utilize (limited) snapshotting capabilities focused on errors. For more recent examples, developer Observability platforms such as Rookout are heavily focused on Snapshots.

How do we use Snapshots?

To meet the needs of modern development, we need to put snapshots at easy reach for every developer.  We need to give them the ability to decide ahead of time which obscure edge cases to snapshot for ease of reproduction and fixing. We must allow them to snapshot unexpected events in real-time to understand and remediate them. Therefore, we should build monitoring tools that intelligently identify and snapshot interesting events for easy analysis. Lastly, we must build automation engines that correlate data from other sources and automatically collect snapshots.

Snapshots are the key to unlocking peak efficiency and effectiveness for engineering organizations in these turbulent times. Even more important is the potential impact on engineering culture. By empowering engineers to witness how their code runs in production, we promote a true shift-left culture and create day-to-day ownership of their code across the software development lifecycle.

After all, developers deserve a pillar too.