Let’s get real – as developers, we spend a significant amount of time staring at a screen and trying to figure out why our code isn’t working. According to Coralogix, there are an average of 70 bugs per 1000 lines of code. That’s a solid 7% worth of blimps, bumps, and bugs. In addition to this, fixing a bug can take 30 times longer than writing an actual line of code. But it doesn’t have to be this way.

We’re delighted to announce that Lightrun for Web IDEs is now available for our beta users! Lightrun for the Web is now supported in three different IDEs: If you want to check out the individual plugins, check out the respectable documentation articles: Lightrun’s users are now able to connect to their live applications directly from the browser, without having to download one of our dedicated plugins – and enjoy the full suite of Lightrun features right in the browser.

Debugging is an essential step in software development, as it allows developers to fix errors before releasing the software to the public. Debugging tools can be integrated into code editors, making the debugging process more efficient. This tutorial will show you how to debug node.js in Visual Studio Code.

Let’s look at IllegalArgumentException, which is one of the most common types of exceptions that Java developers deal with. We’ll see when and why IllegalArgumentException usually occurs, whether it’s a checked or unchecked exception, as well as how to catch and when to throw it. We’ll use a few examples based on common Java library methods to describe some of the ways to handle IllegalArgumentException.

The Java Collections Framework was a huge leap forward when it was introduced as part of Java 2 (JDK 1.2). Thanks to the included collection classes we finally moved beyond the limits of Vector and Hashtable to more mature and generic solutions. With the introduction of streams and functional concepts in Java 8 the framework took everything to the next level. One of the core principles underlying the framework is coding to the interface.

Tom Granot and myself have had the privilege of Vlad Mihalcea’s online company for a while now. As a result we decided to do a workshop together talking about a lot of the things we learned in the process. This workshop would be pretty informal ad-hoc, just a bunch of guys chatting and showing off what we can do with tooling.

I spent over a decade as a consultant working for dozens of companies in many fields and pursuits. The diversity of each code base is tremendous. This article will try to define general rules for modernizing legacy code that would hopefully apply to all. But it comes from the angle of a Java developer. When writing this, my primary focus is on updating an old Java 6 era style J2EE code to the more modern Spring Boot/Jakarta EE code.

Getting a good grasp on your application, especially when it is distributed across multiple clouds, kubernetes clusters and serverless functions is not an easy fit.

The Java Message Service API (JMS) was developed by Sun Microsystems in the days of Java EE. The JMS API provides us with simple messaging abstractions including Message Producer, Message Consumer, etc. Messaging APIs let us place a message on a “queue” and consume messages placed into said queue. This is immensely useful for high throughput systems – instead of wasting user time by performing a slow operation in real-time, an enterprise application can send a message.

Spring makes building a reliable application much easier thanks to its declarative transaction management. It also supports programmatic transaction management, but that’s not as common. In this article, I want to focus on the declarative transaction management angle, since it seems much harder to debug compared to the programmatic approach. This is partially true. We can’t put a breakpoint on a transactional annotation. But I’m getting ahead of myself.