Take a look at your application as it runs on your server or the cloud. You’re so proud of it. Admire it as it’s processing data, interacting with the user, and doing magical things. You should be very proud of it- you wrote a lot of code to make it happen. But, honestly, how much of the code in your application is your code?

In a recent blog post, one of my teammates, Josh, shared a few techniques for deploying Java agents in Kubernetes applications. We have been getting a lot of interest in the concepts we have shared and, per popular request, decided to raise the bar. Is it possible to add a Java agent without changing a single line in either the Dockerfile or the Kubernetes Manifest? Well, the answer is most definitely yes (!), and here’s how.

In the world of software development, there’s no such thing as writing perfect code. As such, almost every software developer ends up spending a great deal of their time debugging code. Therefore, one of the best ways to increase your efficiency as a developer is to have the ability to locate errors, identify the root cause, and fix it to resolve problems in your codebase.

As all dev managers, including ourselves, have witnessed, the last few years have been characterized by unprecedented and rapid technological advances. Due to this, there has been a fundamental change in the way applications are being developed. The software world as we knew it shifted from monolithic app development to new methods such as microservices architectures, cloud functions, and distributed systems that are faster and more agile.

Over the last few years, we have seen an avalanche of tools to enable easier software development on Kubernetes (let’s face it, it is quite hard out of the box). As often happens in growing ecosystems, some tools grow and adapt, while others get left behind, or at the very least, merged into new offerings. What’s a better way to open 2021 than with an up-to-date review of the options we have?

I have been managing R&D teams for the past 14 years or so and have learned many lessons along the way. Some of the best lessons have come about in the moment when your software meets the real world and you find that you need to debug remotely. Part of them were learned from my own battle scars and some were taught to me by my peers and employees.

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.