The page you are looking for does not exist.

Page not found

Articles about software development, architecture, best practices, and experiences shared throughout my journey as a developer.

Open-source projects and personal experiments I build in my spare time.

Projects

Willians Tavares


Have you ever found yourself in a situation where the database is slow and you need to figure out which query is causing the problem? Or needed to cancel a query that got stuck and is consuming server resources?

If you work with PostgreSQL, knowing the query monitoring tools is essential. In this article, I'll share some techniques I use daily to identify and manage running queries.

## The pg_stat_activity view

PostgreSQL has a view called `pg_stat_activity` that is a real lifesaver for anyone who needs to monitor what's happening in the database. It provides information about all active connections and the queries being executed.

### Viewing all running queries

To see all queries currently running, you can use:

```sql
SELECT pid, usename, query_start, state, query 
FROM pg_stat_activity 
WHERE state = 'active' 
  AND pid <> pg_backend_pid();
```

The `pid <> pg_backend_pid()` filter is used to exclude the query we're executing from the results.

### Identifying slow queries

One of the most common situations is needing to find that query that's taking longer than it should. For this, we can sort by execution time:

```sql
SELECT 
    pid, 
    usename, 
    query_start, 
    now() - query_start AS duration, 
    state, 
    query 
FROM pg_stat_activity 
WHERE state = 'active' 
  AND pid <> pg_backend_pid() 
ORDER BY duration DESC;
```

### Filtering queries by execution time

If you want to see only queries that have been running for more than a minute (usually a warning sign), use:

```sql
SELECT 
    pid, 
    usename, 
    query_start, 
    now() - query_start AS duration, 
    state, 
    query 
FROM pg_stat_activity 
WHERE state = 'active' 
  AND now() - query_start > interval '1 minute' 
ORDER BY duration DESC;
```

## Managing problematic queries

Found the problematic query? Now you have two options to deal with it:

### Cancel a query

The most "gentle" way to interrupt a query is using `pg_cancel_backend`:

```sql
SELECT pg_cancel_backend(12345);
```

Replace `12345` with the PID of the query you identified earlier. This function sends a cancellation signal to the query, allowing it to finish in a controlled manner.

### Forcefully terminate a connection

If cancellation doesn't work (sometimes the query is in a state that doesn't respond to the signal), you can force the connection to terminate:

```sql
SELECT pg_terminate_backend(12345);
```

⚠️ **Warning:** Use this option carefully, as it terminates the entire connection, not just the query. Any ongoing transaction will be rolled back.

## Bonus tip: Identifying queries by comment

A practice I adopted in projects is adding identifier comments in the application's queries. This greatly helps when tracing which part of the system is generating a particular query:

```sql
SELECT pid, usename, query_start, state, query 
FROM pg_stat_activity 
WHERE query ILIKE '%/* OrdersModule */%' 
  AND state = 'active';
```

This way, you can quickly filter all queries from a specific module.

## Final thoughts

Monitoring queries is fundamental to maintaining the health of your database. These techniques are simple but extremely useful in daily work. Remember that you need appropriate permissions to view other users' queries and to cancel them.

I hope these tips are useful to you! If you have any questions or want to share other techniques, feel free to get in touch.


Learn how to identify, monitor, and manage running queries in PostgreSQL. Essential techniques for maintaining the health of your database.

Monitoring Queries in PostgreSQL

# Hexagonal Architecture

Hexagonal Architecture consists of dividing a system's classes into layers, where business rules and entities reside in the main layer — the Domain. This way, it's possible to ensure the application's integrity, reuse business rules across multiple platforms such as web and mobile, and easily replace external technologies like databases due to the lack of framework dependencies.

![Hexagonal Architecture](/images/hexagonal.svg)

## Adapters and Ports

With the Domain layer being the main layer of the architecture, it's important that it remains isolated and is accessed in a restricted way by external tools. Therefore, communication between other layers and the Domain layer occurs through Adapters.

![Adapters](/images/hexagonal-adapters1.svg)

Adapters work by communicating with ports, enabling internal and external communication within the application. A port (interface) is a specification of how the domain can be used, meaning for input or output of the application:

- Input Ports are interfaces used for communication from outside to inside the Hexagon.
- Output Ports handle communication from inside to outside the domain, such as databases, API responses, etc.

It's important to note that Ports belong to the business logic — they are technology-independent. Adapters, on the other hand, belong to the external part of the layer and typically use some technology, whether for communication (like REST APIs), databases (like SQL Server), or user interactions.

![Adapters and Ports](/images/hexagonal-adapters.svg)

Adapters can receive method requests both from outside the system and from within the system. It's possible for the same adapter that sends a request to the domain to also receive a response from that domain, thus being able to display an HTTP response message, for example.

Due to this architecture's focus on ports and adapters for accessing the domain, there was an attempt to rename it to Ports and Adapters Architecture.

![Complete Architecture](/images/hexagonal-complete.svg)

The main advantage is that hexagonal architecture manages to maintain the application's integrity by building a project with **technology independence**, favoring **code reusability**, low coupling, **high cohesion, and easy testability**.


Discover how Hexagonal Architecture transforms software design, bringing practical benefits to your project. Explore its effectiveness and application in this in-depth study.

Hexagonal Architecture


# Integration Architecture

Integration architecture refers to the structure and design of systems that facilitate communication and interaction between different software components, systems, or applications. It's important to keep in mind that a large-scale system does not exist in isolation — a system will always communicate with other different systems. This communication can occur in various ways, such as synchronizing data with other systems and ensuring that all information is consistent across all sides, **whether it's a local system, cloud-based, or third-party systems.**

This is where integration architecture comes in, as a way to establish formats and mechanisms that minimize the latency with which data is made available between systems, as well as ensuring the independence of each service in this network of connections. In some cases, integration requires an API call; in others, the technologies need asynchronous communication, requiring something like messages or events.

All processes need proper orchestration — regardless of the technologies involved in the integration, planning is necessary to ensure a simple way to guarantee the flows and execution of the business model.

Technical elements that make up the architecture:

- Communication patterns, such as HTTP, HTTPS, SOAP, REST;
- ESB (Enterprise Service Bus);
- Security protocols SSL/TLS;
- APIs;
- Messaging systems, such as Apache Kafka or RabbitMQ;
- Databases or data storage;
- Monitoring and analysis tools;

The greatest benefit of this architecture is that it becomes possible to view all integrations from a macro perspective. Being a container-based architecture where each service fulfills its function, this makes it possible to achieve:

- **Greater agility**: with the integration architecture perspective, it becomes viable to work with microservices, as it's beneficial for each software to have its own isolated functions, maintaining code that's easy to maintain and read.
- **Scalability**: resources can be adjusted according to the business model, providing greater flexibility to handle increases or decreases in workloads with minimal impact.
- **Resilience**: since each software has its own independence in the overall integration architecture view, it's possible to ensure quick decoupling, and any change doesn't affect other services that are already running.

In addition to being able to relate to other architectures with interdependence, it requires the organization to have prior knowledge of the needs and requirements of its own business and all possible integrations.

Companies that apply integration architecture cases in their solutions:

**Amazon**: The company uses integration architecture to integrate its various services and platforms, such as Amazon Web Services (AWS) and Amazon Marketplace.

**Uber**: Uber uses integration architecture to integrate its applications and services, allowing users to request and pay for rides through various channels, such as the Uber app, virtual assistants, and other third-party applications.

**Airbnb**: Airbnb uses integration architecture to integrate its applications and services, allowing users to book accommodations through different channels, such as the Airbnb website, third-party apps, and virtual assistants.

**Walmart**: Walmart implemented an API-based integration architecture to connect its online and physical store shopping systems. The integration architecture allowed Walmart to offer customers a more integrated and personalized shopping experience.

**American Airlines**: American Airlines implemented a service bus-based integration architecture to integrate its reservation, check-in, and baggage systems. The integration architecture allowed American Airlines to improve the efficiency of its business processes and offer a more integrated and personalized travel experience for its customers.

These are just a few examples of successful integration architecture cases. The choice of the most suitable integration architecture should take into account the specific needs of each company and the systems involved.


Integration architecture refers to the structure and design of systems that facilitate communication and interaction between different software components, systems, or applications.

Integration Architecture


Live chat session aimed at answering your questions about starting a career as a Developer.

<Bleed>
<iframe width="560" height="315" src="https://www.youtube.com/embed/_roQviwNh9M?si=RqaJe1bouWptDMNC&amp;controls=0" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen></iframe>
</Bleed>


Live chat session aimed at answering your questions about starting a career as a Developer.

📺 Live - Answering Questions About Starting a Career as a Developer!


In this live session we presented the main features of the most widely used language for Android app development.

<Bleed>
<iframe width="560" height="315" src="https://www.youtube-nocookie.com/embed/4TnoeXqTClE?si=Wg_7GG-AnS6o4Vco&amp;controls=0" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen></iframe>
</Bleed>


In this live session we presented the main features of the most widely used language for Android app development.

📺 Live - Hello Kotlin | Learn Development on the Android Platform using Kotlin and Android Studio


# S.O.L.I.D
<hr>

**SOLID** is an acronym created by Michael Feathers for the five principles he deemed the most widely used in Object-Oriented Programming and code design. These principles were initially addressed by Robert C. Martin — the famous Uncle Bob — in his article "The Principles of Object-Oriented Design."

Each principle brings an approach and way of developing cleaner and more cohesive code, and can be used and applied in any object-oriented programming language. In the topics below, each principle and its function will be exemplified.


**S** – Single Responsibility Principle
**O** – Open-Closed Principle
**L** – Liskov Substitution Principle
**I** – Interface Segregation Principle
**D** – Dependency Inversion Principle



## Single Responsibility Principle (SRP)
<hr>


**Single Responsibility Principle** — A class should have one, and only one, reason to change.

The single responsibility principle makes it clear that a class should be specialized in only one task — that is, only one responsibility within the system. This way, the class will only have one reason for any changes to be made.

The term used for classes with many responsibilities is God Class, and it should be avoided due to difficult maintenance, the dangers of modifications potentially compromising other tasks executed by the same class, and the complexity of code reuse.

When creating classes for the system, we ideally imagine what possibilities and functions they could perform. In erroneous cases, this class will have various responsibilities to worry about.

Let's say there's a class that represents a rectangle, with properties of its area. The rectangle will worry about maintaining its area, but also about drawing it, as in the image below:


![image.png](/.attachments/image-e6716a03-677e-4d30-be79-015bc6b492a9.png)

If one day we need to change the way we draw the rectangle's area, we'll need to modify the class. Any new change will require handling and modifying the Rectangle class, and consequently all other modules that use it will need to be reviewed and tested.

Following the SRP principle, the Rectangle class should only worry about its area. Therefore, the drawing function should be externalized to another class, as in the image below:


![image.png](/.attachments/image-0905a6b9-e77e-4005-929c-7d943ff721ff.png)


With this, the use of the Rectangle class is freed from modifications, only generating changes in the single, and only one, functionality.

Possible problems from violating the SRP principle:

- Lack of cohesion;
- High coupling;
- Difficulties with automated testing;
- Code reuse issues.


## Open-Closed Principle (OCP)
<hr>

**Open-Closed Principle** — Objects or entities should be open for extension, but closed for modification.

The Open-Closed principle states that you should be able to extend an object or entity, but they should be closed for modifications. In other words, for adding new functionalities or system behaviors, the entity should be extended rather than directly altered.

The idea of **separating extensible behavior behind an interface and inverting dependencies** was conceived by Uncle Bob, with the intention of concentrating everything that could possibly be modified and has a tendency to grow into interfaces, thus making it possible to invert the dependency in the code.

Imagine there's a Payroll class that handles closing, receiving employees for payment calculation. For the logic to work, it must validate the contract type and execute the method that calculates the amount to be paid. As in the image below:

![image.png](/.attachments/image-ba243273-3744-4c58-917f-62e2e37cc129.png)

Following this approach, when the company needs to add a new type of contract, for example a contractor, the Payroll class will need to be modified for a new validation and search for the correct method with the value summation. This approach violates OCP, as the class is open for modifications.

One of the best scenarios to mitigate this problem is creating an interface for compensation, where there will be only one method that will be called and implemented by the contract classes. As in the example below:

![image.png](/.attachments/image-dc4185fd-3569-418b-b398-501f47752eb4.png)


## Liskov Substitution Principle (LSP)
<hr>

The Liskov Substitution Principle states that a derived class can be substituted by its base class without affecting the correct execution of the program.
With this principle, we can apply Polymorphism to always use derived classes while making the proper reference to the base class, ensuring the system's solidity.


## Interface Segregation Principle (ISP)
<hr>

The Interface Segregation Principle states that a class should not have methods and interfaces that won't be used — that is, it's better to have more specific interfaces for their functionality than generic interfaces. This way, the class is not forced to implement methods that won't be used by it.

## Dependency Inversion Principle (DIP)
<hr>

The Dependency Inversion Principle states that we should depend more on abstractions than implementations. This way, we minimize coupling as much as possible, being able to reuse code in other systems without the need to bring dependencies along with the class. The correct way is to use Dependency Injection via method.


In conclusion, the S.O.L.I.D principles offer a robust, object-oriented approach to software development, promoting the creation of flexible, scalable, and easily maintainable code. By adhering to these principles — Single Responsibility, Open/Closed, Liskov Substitution, Interface Segregation, and Dependency Inversion — developers can create systems that are more resilient to change, less prone to errors, and easier to understand and expand.


This article explores in an accessible way the fundamentals of this approach to software design. Learn and apply these principles for more robust and flexible code.

What is S.O.L.I.D?


Requirements gathering serves to identify the needs and possible problems of users — therefore, every business rule can also be called a requirement.

This stage is essential for mapping the user's reality, so the **clarity** and **objectivity** of each requirement is extremely important. Keep in mind that once the requirements are gathered, all subsequent stages of the system development process will be based on this document.

Requirements can be classified in two ways:

**Functional Requirements:** address the system's behavior the way the user desires, describing how the application should behave in certain situations.

For example:
* "The system must have a search input"
* "The app must have a registration form"
* "The user should be able to change registration information"

**Non-Functional Requirements:** describe how the application will be developed — the resources needed to put functional requirements into practice, being linked to application characteristics or constraints.

For example:
   - "The app will use an Azure SQL Database for storing user data"
   - "The registration form will be built with HTML and JavaScript"

It's essential in this first part that some interviews are conducted with the client for a general understanding of the project, understanding of the user's current scenario, the client's main expectations, all possible project constraints, and what is truly necessary for the application.

**Keep in mind that a single meeting may not be enough to gather all the necessary requirements for the system.**

Some tips on how to proceed during interviews so that requirements can emerge coherently:

* Always keep an open mind;
* Let the user have space to bring their vision of the project;
* Be prepared for changes during this gathering phase;
* Bring your questions or prepare an interview script;
* Take note of as much information as possible;

Documentation
---------------------
---

Separate the requirements into two tables: one for functional requirements (FR) and another for non-functional requirements (NFR).

It's important to note that each requirement must be validated by meeting certain criteria:

* Be necessary for the application;
* Be clear, leaving no room for double interpretation;
* Be achievable — the development team must be capable of executing it;
* Have connections with other requirements;

Below is an example of how to organize functional and non-functional requirements for a simple login and registration screen:

**Functional Requirements**

* FR01: The app must allow the user to access the application with Username and Password.
* FR02: The app must allow the user to register in the application with the following fields on the registration screen:
        Email;
        Username;
        National ID;
        Password;
        Password confirmation;
* FR03: The app must allow the user to change their registration information, created in FR02, except for the National ID field.

**Non-Functional Requirements**

* NFR01: User data must be stored in a SQL database.

After writing the requirements, there are several ways to group them according to their importance to the system.

One of these ways is to separate requirements by Criteria — requirements can be classified in three ways:

**Essential Requirements:** Extremely important for the system, directly related to the user's needs or problems. If not implemented, the application cannot be completed.

**Important Requirements:** Although not the most critical and doesn't prevent the application from going to production, if not implemented it will cause losses to the business.

**Desirable Requirements:** Won't cause any loss to the business, but it's something the client would like to have implemented, so attention should be given as well.

Another way to group requirements is by priority, defining high, medium, or low priority for each requirement with the following question: "What is considered most important for the user in the system?"

Validation
---------------------
---
User validation is the last part of requirements gathering — this is where the user reviews all documented requirements, and each requirement is clarified and verified. This verification is useful for validating whether the requirements are truly necessary, whether there are any conflicts between them, whether they meet all constraints, and whether they can actually be implemented by the team.

Be aware that at this stage, some requirements may be changed or new requirements may also arise during the discussion with the user.

Finally, after all corrections if necessary, the client's approval that the gathered requirements truly meet their needs and expectations.

After the documentation is finalized and approved, we can move on to a Prototype following all our gathered requirements. But that's a topic for another article. 😁

Thank you for reading this far!


In this article I'll share some tips and methods for gathering the necessary requirements for system development. This document will accompany all adjacent stages of development, so it's crucial to understand the user's needs.

About Requirements Gathering


In this episode we'll discuss how the increase of information has made revolutionary ideas more and more frequent.

Topics

* Introduction;
* Communication and Information in the past, Connection Between PEOPLE;
* How technological revolutionary ideas came about and their impacts;
* How ideas are today and how they may become in the future in society.

Participants

- Willians Tavares
- Jefferson Almeida
- Eduardo Bolize
- Pablo Luiz

<iframe class="podcast" src="https://open.spotify.com/embed/episode/5MDoucC7IDIvZUoFDog6gr?utm_source=generator" width="100%" height="152" frameborder="0" allowfullscreen allow="autoplay; clipboard-write; encrypted-media; fullscreen; picture-in-picture" loading="lazy"></iframe>


In this episode we'll discuss how the increase of information has made revolutionary ideas more and more frequent.

🎙️ Podcast - Revolutionary Ideas with the Increase of Information


Let's discuss each programming language and where it fits in the rankings we created, then we'll create another Tier List based on chat opinions.

<Bleed>
<iframe width="560" height="315" src="https://www.youtube.com/embed/2LWGWKLLfKg?si=Cv83fVssQR39niIU&amp;controls=0" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen></iframe>
</Bleed>


Live about programming languages in general.

📺 Live - Programming Languages (Tier List)


In this episode we'll talk about Clean Code, its importance and relevance in the market. We'll have a chat about real experiences from our technical team on the subject.

Topics

* Introduction;
* Importance in day-to-day work;
* Real experiences;
* Relevance of clean code;
* Clean code references;

Participants

- Euripedes de Souza
- Willians Tavares
- Jefferson Almeida
- Eduardo Brandão


<iframe class="podcast" src="https://open.spotify.com/embed/episode/180zifPzCFpdwBVSQxDCnu?utm_source=generator&theme=0" width="100%" height="152" frameborder="0" allowfullscreen allow="autoplay; clipboard-write; encrypted-media; fullscreen; picture-in-picture" loading="lazy"></iframe>


In this episode we'll talk about Clean Code, its importance and relevance in the market. We'll have a chat about real experiences from our technical team on the subject.

🎙️ Podcast - Clean Code


In this episode we'll talk about the development world and how to set up or organize yourself to plan a career study, check out the conversation and share your experience with us.

Topics:

* Developer profiles
    * Front-end
    * Back-end
    * Mobile
    * QA
* Developer profile — how to find yours?
* Courses, certifications, degrees...
* The importance of being self-taught while working from home
* Conclusion / Final thoughts.

<iframe class="podcast" src="https://open.spotify.com/embed/episode/6cxPria847HOOLo5aTr6zG?utm_source=generator" width="100%" height="352" frameborder="0" allowfullscreen allow="autoplay; clipboard-write; encrypted-media; fullscreen; picture-in-picture" loading="lazy"></iframe>


In this episode we'll talk about the development world and how to set up or organize yourself to plan a career study, check out the conversation and share your experience with us.