As organizations place focus on innovation and digital transformation across enterprise IT, we continue to see increased adoption of containers and microservice application development patterns. Containers have brought developers new levels of flexibility and portability, but oftentimes still leave developers with questions about the best way to configure and build those containers.
Our ongoing goal at Rookout, the Live Debugging company, is to turn the debugging of live, remote applications into something that every developer can easily do as part of their daily workflow. Recently, we have taken this challenge one step further. What if we could make it so developers were also able to solve performance issues on a daily basis as well? Some recent additions we made to the Rookout platform are the first step towards turning that vision into a reality.
Learning a new language is always a joyous event. From the first innocent google search, through the first “hello world”, to always being surprised when the classic text is somehow printed to the screen/command line console/browser tab/local text file. The entire time your mind is quickly soaking in new ideas and concepts, new syntax and phrases, and new ways of doing things. Some of them can be compared to the languages you already know. Others are brand new.
Production debugging, as the name suggests, takes place when one must debug the production environment and see the root cause of this problem. This is a form of debugging that can also be done remotely, as during the production phase, it may not be possible to debug within the local environment of the application. These production bugs are trickier to resolve as well, because the development team may not have access to the local environment when the problems do crop up.
There comes a time in every developer’s life (or daily routine, we’re not here to judge) where they have to go and fix a bug. Back in the days when I used to be a developer, I distinctly remember how each time I would go face to face with a bug, my favorite method to fix it was to add log lines. I mean, why not, right?
As engineers, we continuously aim for perfection. The drive to deliver the perfect product sometimes defines how good we are as engineers. We often discuss and fine tune the term and the essence of our product’s perfection. Some claim that a perfect product is one that handles all the edge cases, works flawlessly, and can do everything.
As most developers know, their code doesn’t always behave as they expect it to and they’re not quite sure why. This is most apparent when it comes to debugging their software. In order to figure out what the problem is, developer teams must go through a very long process in order to get the data they need to understand the problem. This can involve unnecessary wait times, unproductive hours, and a lot of wasted resources.
Modern developers are under ever increasing pressure to deliver software applications to the business in record time. This means shorter development cycles and a push to have code production ready as early as possible. In addition, many development teams no longer throw the code over the metaphorical wall to be handled by operations and production support teams, but rather oftentimes own the entire end to end delivery chain.
They say that procrastination is the thief of time. In the world of software development, there are some additional “time thieves” that prevent our teams from developing new features or slow them down as they attempt to fix issues. As software engineers or R&D managers, we take it for granted that our teams spend a lot of their time waiting for compiling, testing, and deploying.
Develop fast, release, learn, repeat. That’s essentially the (not-so-secret) innovation formula, right? Most of us spend our time enhancing the products we have already released. We want to be innovative, releasing new features with the velocity of an unencumbered startup. Yet, we also have customers with quality expectations we need to meet. Guidance on shortening release cycles often centers on adopting agile (or similar) development methodologies. But most companies are already there.
