It’s remarkable to me how many developers have no idea what their time is worth. I speak with a lot of developers, and when I mention my work on TrackJS, I frequently hear “I could build that”. Yeah, you could. Observability tools aren’t rocket science. But you shouldn’t. Your time is too valuable to build better mousetraps. Your time is valuable and finite. Both to you and to your company.
In our Sentry for Data series, we explain precisely why Sentry is the perfect tool for your data team. The present post focuses on how we used Sentry to make debugging Apache Beam easier (and faster). Since its creation, Sentry has embraced a single vision: help all developer teams build the best software, faster. We want to give developers the information they need to resolve issues quickly, without having to dig through noisy log lines.
There are a lot of things we, at Sentry, love about Rookout, a Sentry Integration Platform early adopter. First of all, Sentry loves purple, and Rookout loves purple. And, Rookout helps fix software in production, and Sentry helps fix software in production. Together, the two tools cut time from error to resolution. Honestly, Rookout and Sentry integrating is just kismet.
If you’re a Rails developer, then you’ve probably used Rails Logger on at least one occasion or another. Or maybe you have used it without even realizing, like when you run ‘rails server’ and it prints information to the terminal window, for example. Rails Logger provides us with a powerful way of debugging our applications and gives us an insight into understanding errors when they occur.
No matter how carefully coded, reviewed, and tested your Ruby code is, odds are good that at some point you’ll cause a catastrophic failure to at least one system you’re responsible for. How do you prepare yourself? You need a Ruby debugger. In this post, I’ll cover the whole Ruby debugger process—from finding the issue to determining the root cause. Use these instructions for debugging a single Ruby file, a Rails app, or a gem.
