DEV Community: Danilo P. De Luca

Master the Basics First: A Key Step Toward Senior Engineer

Danilo P. De Luca — Mon, 22 Sep 2025 13:43:00 +0000

"What should I test? What E2E test should I write?" - These were the questions that I heard from a teammate who was working on a task after a week. It reminded me of a bigger question: until when, or at what role, should you tell developers that they need to “brush their teeth”?

Because there’s a difference between asking someone to do the basics and asking them to do the basics with quality.

Doing the Basics:

These are the hygiene factors — the equivalent of brushing your teeth:

Write tests: unit, integration, maybe even some E2E depending on the context. At the very least, there’s a baseline every project should meet.
Monitor and observe your deploys: it’s 2025 — observability shouldn’t be optional. At a minimum, you need visibility into your system’s behavior after a change.
Deploy beyond your machine: “it works on my machine” isn’t enough. Your code should prove itself in a shared environment.
Follow the pipeline: commits build, tests run, deploy happens. No skipped steps.
Get a code review: not for perfection, but at least for another set of eyes.

These are necessary, but not sufficient.

Doing the Basics with Quality:

This is where the difference shows up. Instead of just asking “did you do it?”, the framing becomes “does this give us confidence?”

Tests

Not just “are there tests?” but “do these tests cover critical paths, edge cases, and failure scenarios?”
“If this service crashes under unexpected input, will our tests catch it?”

Monitoring & Alerts

Not just “did you add metrics?” but “are these metrics tied to user experience and business outcomes, not only system health?”
“Would this alert wake up the right person at 3am with enough context to act?”

Deployments

Not just “did you push to dev?” but “did you test this under conditions that resemble production scale and data shape?”
“Do we have a safe rollback plan if things go wrong?”

Code Quality

Not just “is it working?” but “is it readable, maintainable, and resilient against change?”
“Would another developer, six months from now, understand why this was written this way?”

Documentation & Communication

Not just “do we have docs?” but “would someone new to the project be able to follow the reasoning behind this decision?”
“Did we make tradeoffs explicit so future us won’t repeat old mistakes?”

Reviews & Feedback Loops

Not just “did someone approve?” but “did the review meaningfully improve clarity, correctness, or resilience?”
“Do we have feedback mechanisms in production that confirm we’re solving the right problem?”

From Compliance to Confidence, the real shift is this:

Basics = compliance: check the box, do the thing.

Quality = confidence: the team trusts the change, today and tomorrow.

So the next time you’re tempted to say “write better tests” or “clean up the code”, try reframing it:

“Do these tests give us enough confidence that this won’t break in production?”
“Would you trust this if you were the end user?”
“If another developer picks this up in 6 months, will they understand it?”

That’s when the conversation shifts from brushing teeth… to actually keeping them healthy.

SpringAI + DeepSeek: Faster Than Brewing a Coffee

Danilo P. De Luca — Tue, 28 Jan 2025 03:30:45 +0000

Over the past few days, there’s been plenty of buzz about DeepSeek and OpenAI. If you haven’t come across the news yet, no worries—this post isn’t about the headlines. But if you’re a #Java developer curious about how to use this 'new' AI, which has shown better results, lower costs, and already surpassed OpenAI in downloads and usage or if you’re looking to integrate with any AI for the first time here’s the best part: it’s faster than brewing a cup of coffee!

Spring AI

First, let’s talk about SpringAI. As many of us know, the Spring Framework ecosystem is vast, and every time a new technology or concept gains traction in our field—especially one that interests the software developer and Java communities—efforts are made to integrate it with core frameworks like Spring Boot.

With the rise of AI, it was no different. That’s why SpringAI was created: to simplify the integration of Java applications with any AI domain or platform.

Spring AI is an application framework for AI engineering. Its goal is to apply to the AI domain Spring ecosystem design principles such as portability and modular design and promote using POJOs as the building blocks of an application to the AI domain.

DeepSeek

DeepSeek is a player in the game of AI Platforms, like the famous OpenAI it contains a lot of features and ways to integrate with, as well as a bunch of AI models, here you can take a look at more features, including their chat, additionally its important to share that it's an open-source model.

DeepSeek-V3 achieves a significant breakthrough in inference speed over previous models.
It tops the leaderboard among open-source models and rivals the most advanced closed-source models globally.

Integrating SpringAI with DeepSeek

First, you might have Java installed on your local machine. Once you have it, we will use the Spring Start project to set up our brand-new project, which will integrate with DeepSeek.

Go to Spring Start
Choose your preferences, I suggest Maven + Java + Spring Boot 3.4.2 (latest) and for Project Metadata I filled as below, although you can place anything that you want, also I like jar packaging and I set up Java 21.

Add Dependencies, for this we will need 2 dependencies:
Spring Web
OpenAI

After that, it's ready to generate your project. Click on 'Generate,' and a ZIP file containing the project will be downloaded. Unzip it into your favorite directory (in my case, I just unzipped it in my chaotic Downloads directory—remember to clean up your Downloads folder regularly!)

Open the project in your favorite IDE. I'm using IntelliJ in this example (if you need help with that, check out the article "Using Java 21 with IntelliJ IDEA").

Once you open the project you will find the following structure and classes on it:

Before we start, let's create the DeepSeek keys.

DeepSeek - Creating your API-Key

When integrating with any AI Platform, we need an API-Key and with DeepSeek is the same, so the following are the steps to create it:

Go to the DeepSeek Platform website, and register yourself using your preferred email.
When logged, face the API Keys menu:

Create your new API Key - remember to keep it safe as you do with your passwords and crypto-wallets, also you can delete it whenever you want.

If you would like to know more about the pricing take a look at this documentation

SpringAI + DeepSeek

Now that we have our project and the API Key, Time to bring it to life!

As you may know, once we add the Spring OpenAI dependency to our application (you can check your pom/gradle file for spring-ai-openai-spring-boot-starter) all the setup for integrating with any AI platform is managed through environment variables. If you want to learn more, feel free to check out thedocumentation. To integrate with #DeepSeek, we will need 4 environment variables:

spring.application.name=deepseek
spring.ai.openai.api-key=${API_KEY_DEEPSEEK}
spring.ai.openai.base-url=https://api.deepseek.com
spring.ai.openai.chat.options.model=deepseek-chat

Note: the spring.ai.openai.chat.options.model has two options depending on your need.

The deepseek-chat model has been upgraded to DeepSeek-V3. The API remains unchanged. You can invoke DeepSeek-V3 by specifying model='deepseek-chat'.
The deepseek-reasoner is the latest reasoning model, DeepSeek-R1, released by DeepSeek. You can invoke DeepSeek-R1 by specifying model='deepseek-reasoner'.

Once you add this variables it will be able to integrate with DeepSeek. Now lets create some piece of code to ask something for it.

In your Application.java file add the following line of code:

@Bean
    public CommandLineRunner runner(ChatClient.Builder builder) {
        return args -> {
            ChatClient chatClient = builder.build();
            String response = chatClient.prompt("Tell a brief history of Java programming language.").call().content();
            System.out.println(response);
        };
    }

This code will send the message "Tell a brief history of Java programming language." will send it to DeepSeek and print the response, so to test it run (or use the maven/gradle plugin in IntelliJ to get it running):

./mvnw spring-boot:run

There is it! Now you have one Java Application integrating with DeepSeek - _and opps you couldn't even finish brewing your coffee ☕ _

What I like most about it is the fact that we can integrate with any AI platform by making only 3 to 5 lines of code changes. A big shoutout to Spring AI! And big thanks to Dan Vega for sharing and contributing to Spring Ecosystem!

Some references:

Wondering to know more about the differences between DeepSeek and OpenAI? Deepseek R1 vs OpenAI o1
Spring AI Initializer
DeepSeek Open-Source project

"The Strawberry in the Cake" - Challenges of Libraries and Dependency Management

Danilo P. De Luca — Fri, 24 Jan 2025 17:31:23 +0000

Imagine a beautiful cake topped with a fresh, juicy strawberry. The strawberry adds the perfect touch of sweetness, visual appeal, and flavor to the cake. It's the highlight, the centerpiece of the cake's presentation. However, there's a catch—strawberries have a much shorter shelf life than the cake itself. While the cake might stay fresh and edible for days, the strawberry begins to rot much sooner - have you ever eaten a piece of cake that the strawberry had gone rotten? Uhh, that's horrible!

Now, let's connect this to software development, for this, do you remember any time that you had to update library or a dependency version and got into what we can call "Dependency Hell"? Its pretty similar to this:

The Cake represents your main application or system. It's the core product, which should ideally have a long lifecycle and remain stable and maintainable.
The Strawberry symbolizes a third-party library, a dependency, or a microservice your application relies on. These can bring exceptional value, just like the strawberry enhances the cake - I can remember the first time that the Project Lombok was introduced to me, back in 2016, while I was working on a #java huge application, that was fantastic! Nowadays, it might not be worth it, as much of it was introduced in the latest updates in #Java, turning the cake good enough to not need a strawberry.

But, there is a problem:

Just like a strawberry spoils faster than the cake, libraries, and dependencies often have shorter lifecycles than your application (should it be easier to change a library or your entire application?)
If your application (The Cake) is tightly coupled to a specific version of a library (the strawberry), you might face significant issues when the library's lifecycle ends, for example when it has an ABI Breaking change - this is a common terminology when working with C++ in the past, today we mostly use an API Versioning, Breaking Changes, Contract Breakage, and for me, in particular, its one of the main issues when getting into the famous Dependency Hell 🔥

Thinking about it there are different perspectives on avoiding this issue:

1. When Creating Your Libraries

When you are building a library that others will rely on - your friend will use it, other teams in your company will use it, or you are creating it but don't know yet who will use it (that happens sometimes hehe).

- Backward Compatibility: Ensure new versions of it maintain compatibility with previous versions wherever possible. This is not that easy, and sometimes we do need to release a breaking change, for this it should be carefully planned and communicated.

- Semantic Versioning: Follow semantic versioning principles (MAJOR.MINOR.PATCH) to help consumers understand the impact of updates.

- Independent Upgradability: Design your library so it can be updated independently of the system that depends on it. For example, avoid hard-coded assumptions about the consumer's environment.

- Share what has been done: The famous CHANGELOG.md provides clear documentation and migration guides for new versions.
- Focus on Security: Regularly review and address security vulnerabilities in your libraries. You don't your library to be a "trojan" into other people's applications, do you?

2. When Using a Third-Party Library

- Evaluate the Community and Longevity: before adopting a library, assess its community support, maintenance activity, and long-term viability.

- Regular Updates: Stay proactive in updating libraries to their latest stable versions. Many updates include critical bug fixes and security patches.

- Monitor for Vulnerabilities: Use tools like Dependabot or Seemplicity to automatically detect and report vulnerabilities in tour dependencies.

- Avoid Over-Reliance: Use libraries judiciously. Instead of importing an entire library for one small function, consider writing your own implementation or using lightweight alternatives (yeah! Why not coping and paste it into your project? 🤔)

- Plan for Contingency: Have a fallback strategy in case a library becomes deprecated or unsupported. This could involve forking the library or switching to a maintained alternative.

- Abstract Dependencies: I would say that this is the hardest one and at the same the most important, remembering concepts of Hexagonal Architecture, create an abstraction layer between your application and the library. This decouples your code from the library’s API, making it easier to replace or upgrade the dependency. (A master chef knows that when placing a strawberry on a cake, it should be covered with sugar syrup. This helps delay the strawberry from rotting and also prevents it from damaging the cake).

Note that, both of them work together, so when creating your library you might use a third-part library, then you need to be worried about it.

Some key takeaways from it:

Design systems that can handle library updates or replacements without significant disruption.
Avoid tightly coupling your application to specific versions of dependencies.
Emphasize backward compatibility when creating your own libraries to ensure they don't impose unnecessary constraints on their users.
Keep in mind that even if the strawberry is appealing, it might not be worth jeopardizing the cake (remember the to Avoid over-reliance?)

Don't let the "strawberry" define the lifecycle or quality of the "cake." Build systems that are resilient, adaptable, and not overly reliant on individual components.
Do you know other situation that we could use the concept of "The Strawberry in the Cake"? Share it in the comments, I would love to hear about more examples!

Observability Challenge: Configuring Rules to Scale Your Application

Danilo P. De Luca — Sat, 20 Jan 2024 20:36:21 +0000

Working on a scalable architecture presents numerous challenges, especially when dealing with diverse components within the system. As the architecture expands, it becomes increasingly challenging to identify and address problems.
Several practices can prove helpful in such situations, with Observability standing out as a key strategy.

In this article, you will discover how adopting effective Observability practices can assist in configuring rules for scaling your application. By implementing these practices, you can also reduce infrastructure costs by the end of the month.

Before delving deeper, let's briefly explore some Observability concepts.

What is Observability?

As Cindy Sridharan once mentioned in her book Distributed Systems Observability:

Observability is a spectrum of tooling and practices, with the end goal being the ability to understand the entire system’s state by looking at it from the outside.

Observability allows us to perform a range of tasks, including monitoring metrics, logging, and tracing. The primary goal is to comprehend the activities within our architecture and systems.

Monitoring Metrics: This involves quantitatively measuring various aspects of a system's performance. In simpler terms, it helps us understand the fundamental resources of our infrastructures, such as CPU usage, memory utilization, networking latency, and more. The focus here is on identifying trends, anomalies, and potential bottlenecks.

Logging: Have you ever debugged a feature and used logs to understand what's happening? That's logging! This approach entails capturing and storing data about the activities within a system, which is crucial for troubleshooting issues and bugs.

Tracing: Tracing is about analyzing different components of your system and architecture. It provides the entire flow of a request or transaction, moving through various components and services. Tracing can offer a dependency map of the different parts of your system, aiding in the identification of performance issues or bottlenecks.

Configuring scalable rules for your application

As evident, Observability emphasizes sharing metrics from our systems, enabling us to take informed actions. One of the pivotal advantages of scalable systems and architectures is leveraging metrics to establish rules for auto-scaling during periods of high usage or processing demands. Achieving this involves a systematic analysis of the data provided by observability tools.

Now, let's delve into the steps for analyzing observability tools.

1. Finding Behavioral Patterns

In the following example, you'll observe metrics from a Java application that adhered to a single scaling rule: maintaining an average of 60k requests within a 5-minute timeframe. This application operates within a Kubernetes (K8s) cluster, where each pod is allocated a maximum of 16GB memory and 4 CPU cores.

In the image below, you'll find a snapshot displaying the number of pods/containers running in a Kubernetes application of our system. We are currently using Datadog for monitoring our architecture.

To identify patterns and understand the application's behavior, observe the peaks in the graph. In the following image, you'll notice distinct cycles indicating common scaling patterns of the application.

Some key observations on it:

Days 12, 13, and 14 fall on the weekend (Friday, Saturday, Sunday), marked by heightened access peaks in our application (the purple round).
Consistently, during lunch hours from 11 am to 1 pm every day of the week, we observe a similar pattern (the pink round).
Similarly, during breakfast hours from 8 am to 10 am daily, we notice a consistent behavior (the orange round).
Weekdays 09, 10, and 11 (Tuesday, Wednesday, Thursday) exhibit nearly identical usage peaks (the green round).

2. Merge The Founded Patterns With Other Different Metrics

The importance of this second step lies in avoiding reliance on a single metric as the sole source of truth for our analyses. Therefore, it is advisable to employ a minimum of two metrics to enhance the depth of your application analysis. In this instance, I will utilize one of the most common metrics in applications: Requests Per Minute.

The image below provides a snapshot of the application's Requests Per Minute metrics for the same dates.

Here, you'll observe a continuation of the same behavior as indicated by the colored rounds, providing further justification for the application's scaling of the pod count.

The third metric to consider is the resource utilization of your application. Monitoring resource usage is essential for assessing its health and ensuring efficient resource utilization.

The image below presents a snapshot of our application during the same timeframe, depicting the percentage usage of CPU and Memory resources.

So... what about that? Upon closer examination, do you notice anything peculiar? Why is the application scaling pods when the resource usage is less than 20% for CPU and less than 5% for Memory?

3. Finding Anomalies

As evident from the earlier observations, anomalies may exist in our application, given that we're scaling the number of pods despite the application's resource usage being below 20%.

To address this, our first step is to comprehend the auto-scale algorithms. Kubernetes introduces the concept of HPA (Horizontal Pod Autoscale), utilizing both container metrics (CPU, memory) and external metrics (requests per second or custom metrics exposed by your application) to determine when scaling a new pod is necessary within a namespace.

In the case of this application, only one metric was configured in HPA: the number of requests in the past 5 minutes. While this aligns with the application's need for high availability during peaks of throughput over HTTP requests, relying solely on this metric might not be sufficient for effective scaling.

Having identified an anomaly in our application, it's time to take corrective action! In this scenario, we are going to reconfigure the HPA for the application. The modifications we'll implement are grounded in the observed behavior and metrics gathered during the Observability process. It's crucial to recall that we identified a low usage of infrastructure resources (CPU and Memory).

The adjustment involves shifting the HPA to utilize resource metrics for scaling our app. While retaining the metric for server requests in the past 5 minutes, we've decided to increase its threshold from 20,000m to 60,000m.

  metrics:
    - type: Pods
      pods:
        metric:
          name: http_server_requests_seconds_sum_rate5m
        target:
          type: AverageValue
          averageValue: "60000m"
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 75
    - type: Resource
      resource:
        name: memory
        target:
          type: Utilization
          averageUtilization: 80

After implementing any changes, it's crucial to emphasize the importance of restarting the Observability process. By doing so, you can assess whether the application's behavior has been altered and gather meaningful results from the updated configuration.

4. Restart The Observability Process After The Changes

In the image below, you'll notice the precise moment when we deployed the changes—Wednesday at around 4 PM. On the same day, a distinct scaling pattern emerges during dinner time.

Notice the shift in patterns when examining the period from day 17 to day 20. In the image below, the colored rounds depict the same peaks and patterns as we observed previously.

After a thorough analysis, as depicted in the previous image, we can draw the following conclusions:

During lunchtime - indicated by the pink round - the number of pods decreased significantly, from an average of 49 pods between days 9 and 17 to 31 pods on day 18 and 34 pods on day 19, reflecting an almost 30% reduction in pods!
During dinnertime on weekdays - marked by the green round - the number of pods decreased from an average of 75 pods on days 9 to 11 to 37 pods on days 17 and 18, representing almost a 40% reduction in pods!
During dinnertime on the weekend - characterized by the purple round - the number of pods decreased from an average of 120 pods on days 12 to 14 to 82 pods on day 20, reflecting almost a 42% reduction in pods!

Important Note: On Day 20 (Friday) we ran an advertisement in a TV Show (Big Brother Brasil) that increased the number of access by +20% and as a strategy for it we decided to increase the minimum number of pods to 25 (it was 3 pods before).

In conclusion, Observability is indispensable for maintaining the efficiency of your scalable architecture, and it goes beyond that! Utilizing observability tools can also be instrumental in reducing infrastructure costs. In this straightforward example, we are poised to save almost 40% of the previous month's cost for this application by making a seemingly minimal adjustment: adding only 10 lines of code'!

Looking ahead to this same application, our next steps involve further reducing the infrastructure resources allocated to the application and fine-tuning the request per minute metric (http_server_requests_seconds_sum_rate5m). This adjustment is vital as we've observed the scaling behavior without surpassing 30% of the allocated infrastructure resources.

Do you have any other observability metrics or strategies for configuring an auto-scale tool? Feel free to share your insights!

Using Java 21 with IntelliJ IDEA

Danilo P. De Luca — Sat, 18 Nov 2023 16:55:06 +0000

Java 21 was released last September/23 with a lot of new features, such as Virtual Threads, Structured Concurrency (preview), Record Patterns, Sequenced Collections, and many others (if you are interested you can read more on this article). However, how can you use it? Do you only need to update the JDK version of your project? What else you should do to be ready to start rocking some code?
Following you will learn 3 steps to code with Java 21 using IntelliJ as your IDEA in Linux/Ubuntu.

0) Download IntelliJ.

For that, you can follow this article or go to the download page.

sudo snap install intellij-idea-community --classic

1) Install locally the JDK 21

The usage of SDKMan helps you to manage different Java versions on your machine in a simple way, even the last one.
https://sdkman.io/usage

After installing the SDKMan, you should run:

sdk list java
#choose what java 21 version you want to install, in this example I will use 21.0.1-oracle
sdk install java 21.0.1-oracle
#them you can set the previous version as the default.
sdk default java 21.0.1-oracle
#or only use that on your terminal
sdk use java 21.0.1-oracle

Now you can check the Java version in your environment:

java -version
#java version "21.0.1" 2023-10-17 LTS
#Java(TM) SE Runtime Environment (build 21.0.1+12-LTS-29)
#Java HotSpot(TM) 64-Bit Server VM (build 21.0.1+12-LTS-29, #mixed mode, sharing)

2) Add the JDK to your IntelliJ Project

This step is not that simple and requires some attention!

First, you need to go from the top Menu File->Project Structure or use the shortcut [ctrl+alt+shit+s]

Here you will find a window with your project settings, in this window you need to click on the SDK drop-down, and if everything went well with the SDKMan Installation in the previous step, your $JAVA_HOME will detect a new SDK as shown in the following image.

Choose the Java 21 version that you installed ("21.0.1-oracle"), when choosing a new SDK IntelliJ runs a "Home path validity", don't worry about that, it might take a few minutes to finish!

To make sure that everything is correct, you can check on the same window the "Platform Settings-> SDKs", the chosen version might be there!

Depending on the version of your IntelliJ IDEA you will need to specify the Language Level since not all versions are compatible with the new features of Java 21.
On the same window (Project Structure) choose "X - Experimental Features"

Trick Step) Using Experimental Features in IntelliJ

Since we still need to use the mode of "Experimental Features, IntelliJ has a trick to make it work well: the "--enable-preview"

To do so, go to Settings [ctrl+alt+s] -> Build, Execution, Deployment -> Compiler -> Java Compiler.

In the section "Override compiler parameters per module" include a new configuration!

The configuration might appear like this in the end:

Let's code!

With everything configured, it's time to brave the new features of Java 21 release! So here are some amazing contents that might be helpful for that:

For this, I would recommend the following articles:
The Evolution of Java: Challenging Stereotypes and Embracing Modernity by Bazlur

Exploring Java 21's Intriguing Additions (Part 1) by Bazlur

Unlocking Performance: Exploring Java 21 Virtual Threads by Otavio Santana

Suas maiores dúvidas sobre Java no Backend | Esquenta TDC Business with Gabriel Silva and Elder Moraes

Java 21 is here: Virtual threads, string templates, and more