What do Google’s DevOps Research and Assessment (DORA) and Rollbar have to do with each other? DORA identified four key metrics to measure DevOps performance and identified four levels of DevOps performance from Low to Elite. One way for a team to become an Elite DevOps performer is by focusing on Continuous Code Improvement.
A memory leak is a situation where unused objects occupy unnecessary space in memory. Unused objects are typically removed by the Java Garbage Collector (GC) but in cases where objects are still being referenced, they are not eligible to be removed. As a result, these unused objects are unnecessarily maintained in memory. Memory leaks block access to resources and cause an application to consume more memory over time, leading to degrading system performance.
Debugging is the process of identifying and fixing any issues in the source code of a program. Modern IDEs like Eclipse provide debugging tools that make it easier for developers to walk through their code interactively and inspect it to spot and resolve any issues.
It can be really exciting when your development team is growing fast! But then you soon realize that managing all the developer tools to constantly create new projects or add users is becoming a full-time job. Well, not anymore. At least, not for Rollbar. We’re releasing our HashiCorp Terraform Verified Provider for Rollbar today, built in partnership with HashiCorp.
We surveyed nearly 1,000 developers across the U.S. to uncover key development trends and insights. Today’s businesses are software businesses. If there was any positive in 2020, it’s the power software has to allow us to continue in some “normal” sense. Learn how this survey uncovers how too many companies and their development teams still have a major blind spot when it comes to errors in their code.
When Cory Virok and I started Rollbar in 2012, we knew something was lacking in how software was being built. Developers continue to get better everyday at building applications — the widespread adoption of microservices architectures and open source are evidence of this. But, we realized something was still holding us back. And that was how we track and fix bugs.
If your experience as a developer is anything like mine, the best moments are those known as the "flow state.” When distractions drift into the background and all your energy is going in the creative direction of solving the problem at hand. Your brain is directly connected to your users through your code. Months of progress happen in hours. Unfortunately, those moments are rare. But it’s not emails or Slack messages that are the biggest distractions.
Imagine you’ve been working on a new feature for weeks. Finally—after exhaustive QA and testing, and more late coding sessions than you care to count—you release with a feeling of both accomplishment and relief. Only to be woken up at 3am that something’s wrong. Or worse, you get flooded with customer complaints that it’s not working properly. Well, it’s probably a scenario you don’t need to imagine. Every developer has a version of this story to tell.
We software engineers like to think ourselves unflappable. Consider that we spend most of our days staring at glowing pages of eldritch horror that no mortal was meant to witness. We whisper and type our otherworldly incantations, all the while feeling the hungry gaze of a lurking cross-site scripting bug, or a shadowy use-after-free, or an accidental summoning of ZALGO. (H̨e̛ ̕c͢om͢es, you know.)
You know the feeling. You’ve just deployed a new version to production and are monitoring the Rollbar dashboard for any new errors or looking out for any Slack notifications. You’re keeping an eye on the number of new or reactivated errors, their severity level, and triaging to see which errors need to be assigned and to whom. Now what if you could automate these tasks?
