Welcome, and thanks for joining us! Today on Exception Perceptions, we’re inviting Sentry Product Manager Sara Gilford to give us all the dirt on collaboration and ownership. That’s right; we’re uncovering the juicy details of who and how folks on teams within Sentry should be notified when issues pop up in their application.
Ziv Levy, Software Engineer at Wix (a Sentry customer), recently faced two challenges: simulating a bug in Wix code and testing report data. His recent blog post, Meet Raven TestKit: Wix Engineering’s Open Source Tool to Test Sentry Reports, dices into how a plugin for Sentry’s Raven SDK helped him tackle those challenges, with specific documentation detailing what made the choice so simple. Read the post below, and then go try Raven TestKit for yourself (please, and thank you).
One month after launch Sentry 9 may feel as though it descended from heaven, but it didn’t simply fall out of the sky. It’s a release that was long in the making, touched by virtually every member of our application engineering team. We made 1979 commits to our getsentry/sentry repo alone, with 2698 files changed, 458546 insertions, and 166290 deletions.
Antoni Orfin, Chief Architect at Droplr, has years of hands-on experience building scalable web applications that serve traffic for millions of users across the globe. His journey started with bare-metal infrastructures. Then, he dove deep into cloud. Today, he’s responsible for making things run smoothly on state-of-the-art serverless architecture at Droplr.
In A Comedy of Errors, we talk to engineers about the weirdest, worst, and most interesting application and infrastructure issues they’ve encountered (and resolved) over the years. This week, we hear from Or Weis, co-founder and CEO of Rookout. Rookout’s focus is on collecting data in a seamless, immediate way that maximizes a developer’s insight into live code.
We’re back! That’s right, we have a new episode of Exception Perceptions to share with y’all. This is part 2 of of our Star Wars series, and this time we’re talking all about using errors to better understand user behavior.
I recently spoke to Nick Rockwell, CTO at The New York Times (a Sentry customer), and Yonas Beshawred of Stackshare about simple solutions, React, and going serverless. Take a listen or read on for the highlights. Because why would we even bother with the lowlights?
With Sentry 9, our goal is to increase the relevance of the information you see in Sentry in order to speed up your time to resolution, while also making the process of fixing application issues less annoying for everyone involved. How are we accomplishing this? We’ve increased our focus on Ownership of issues: expanding your ability to control who owns what in your Projects, while expanding the power of teams and individuals to take action with that ownership.
We recently raised an additional $16 million in funding from our partners at NEA and Accel. What are we going to do with these additional funds? Great question! For a long time Sentry has had a rigid, singular focus: given an application error, discover everything a developer needs to know about it and inform the team as quickly as possible.
Errors. We all cause them all the time, which can make it difficult to figure out the person or team who should be responsible for fixing individual issues. Time that could be spent resolving an issue is instead spent tracking down who should be handling it and what it’s even about. This is a waste. It balloons time to resolution, often from minutes to hours or sometimes even days.
