If you’re a developer working on building software these days, it’s more than likely that you’ve considered using the microservice architectural pattern. With individual services that can be run and deployed independently of one other, this architecture is loosely coupled, fault-tolerant, and more easily scalable. Achieving these lofty goals requires a system that can support running microservices at scale and most organizations view Kubernetes as the optimal orchestration system.

.NET Profilers are a developer’s best friend when it comes to optimizing application performance. They are especially critical when doing low level CPU and memory optimizations. But did you know that there are three different types of profilers? All are very valuable but serve relatively different purposes and different types of performance profiling. Let’s explore the different types.

In today’s world of software development, it can often be challenging to get the data and information we need from running applications. While the introduction of container orchestration frameworks such as Kubernetes has brought about new capabilities around scalability and fault tolerance of applications, it has also introduced challenges in understanding exactly what’s happening within those applications when things don’t go as expected.

Debugging performance issues in production can be a pain and, in some cases, impossible without the right tools. Java profilers have been around forever, but the profilers most developers think about are only one type: standard JVM profilers. However, using one type of profiler is not enough. Suppose you’re analyzing your application’s performance. There are multiple profiling activities which you may execute.

Debugging is the art of removing bugs — hopefully quickly, and in this guide, I’ll show you multiple ways to debug React. In terms of React, we can have many different kinds of bugs, including: There are more categories than this, but it’s enough to get started debugging in React. Let’s open by talking about how to create a small application using React and how to debug it.

About a year ago, I was lucky enough to post an article at SCMag about Rookout’s journey to achieve SOC 2 compliance. Since then, I sat down with many engineering managers who had follow-up questions on the article. They wanted more details on the relationship with the auditors, the steps we took to control various risks, and how it affected our R&D processes.

Log aggregation systems are awesome. They truly are. Being able to get any log I want from my servers with just a few clicks is not only fun but a huge productivity boost. I have all my logs in one place. All applications. Each microservice. Every load-balanced instance. The entire infrastructure. Plus, I can search through it with queries. I can extract specific fields from my (structured!) logs and split them into tables. Then, I can graph those data points with a click of a button.

Recently, Michael Bolton wrote this awesome tip on twitter: And it got me thinking, how minor changes in the way we ask questions impact the answers we receive. As a company that offers developer-productivity tools that are often used for debugging, I’m surprised how frequently engineers and their managers underestimate the time and effort, blood and tears they spend on debugging.