Welcome fellow developer, I can see you’ve traveled a long road, why don’t you stay a while and listen? I’ve got some fantastic stories to share; Lessons to imbue your debugging skills with power and wisdom, adding at least 1000 XP to take you to the next level and make your future travels much safer. Hmm, now, where should we start? Have you already faced the terrifying Heisenbugs? They are truly fantastic.
Modern software production stops for no one, and everyone is needed to keep it rolling. Every dev is on-call. Great speed and friction produce a lot of heat, and when everything is on fire all the time, even the best devs and engineers struggle to keep the train speeding onwards without getting burned. What makes maintaining modern production so hard? And what is the difference between being good and being bad at dev-on-call? Let’s dive in and see.
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.
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.
Logs. Do we really need them? As developers, we write the code and the tests, and everything seems to be looking great. Why then, do we need to spend even more time writing a bunch of lines nobody is ever going to read? Recently I did a talk on the subject at StatsCraft (check out the slides here). This post, a summary of the talk I gave, will discuss why we need good, informative logs, and how we can write them well enough.
Porting a software project to a new operating system is always interesting and fun, and Alpine Linux with its musl libc brings a unique set of challenges.
Kubernetes is a highly distributed, microservices oriented technology that allows devs to run code at scale. K8S revolutionized cloud infrastructure and made our lives a whole lot easier in many aspects. Developers don’t have to do anything but write code and wrap it in the docker container for K8S to handle. But even its greatest enthusiasts will admit debugging Kubernetes pods is still a pain.
To kick off our series on debugging for software developers, we tell you how to build breakpoints to isolate key information about your app’s performance, and save crucial time during the process.
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.
