DEV Community: Victor Osório

O que são Sistemas Distribuídos?

Victor Osório — Tue, 26 Nov 2024 12:04:17 +0000

Nos últimos 10 anos a internet se tornou onipresente. Isso nos levou a estarmos sempre conectados ao nosso smartphone que se torna um tela de acesso a todo o mundo. Mas isso não mudou somente as nossas vidas, mas a arquitetura de software como um todo. Quase todos os sistemas hoje são conectados a internet e interagem com outros sistemas como se fossem parte de uma inteligência distribuída. Nessa série vou tentar colocar no "papel" o que são sistemas distribuídos e como podemos avaliar eles.

Procurando uma definição

Antes de começarmos a falar sobre sistemas distribuídos que tal procurar definir o que são sistemas distribuídos? Vou aceitar a definição do livro do Maarten van Steen e Andrew S. Tanenbaum.

Definição
Um Sistema Distribuído é uma coleção de elementos computacionais autônomos que aparecem para seus usuários como um único sistema coerente.

Dessa definição podemos realçar duas características muito importantes para quando analisamos os sistemas distribuídos. A primeira é que estamos falando de elementos computacionais autônomos, ou seja, estamos falando de uma arquitetura de software/hardware que contém elementos distintos e independentes. Mas também estamos falando sobre usuários que veem esses sistemas como um único e coerente sistema, ou seja, estamos falando de vários uma arquitetura de software que conterá vários elementos autônomos que podem ser compreendidos como um só pela colaboração de seus elementos.

— Se fala o tempo inteiro de Microsserviços... Qual seria a diferença entre um Microsserviço e um Sistema Distribuído?!

A discussão sobre microsserviços é uma discussão paralela aos Sistemas Distribuídos. Para termos essa percepção precisamos olhar para a definição que o Sam Newman traz no primeiro capitulo do livro Criando Microsserviços.

Definição
Microsserviços (microservices) são serviços que podem ser lançados (deploy) de forma independentes e são modelados com base em um domínio de negócios. [...] A arquitetura de microsserviços é um tipo de arquitetura orientada a serviços, com uma definição bem clara sobre como as fronteiras dos serviços devem ser traçadas, e para a qual a possibilidade de implantações independentes é fundamental.

Através dessa definição podemos perceber que a discussão de microsserviços é atrelada a implantação e ao deploy. Nós estamos falando de software em produção de um domínio especifico que evolui e não sobre uma arquitetura estática.

Ouso dizer que toda arquitetura de Microsserviço é uma arquitetura de um sistema distribuído, mas nem todo sistema distribuído tem uma arquitetura em microsserviço. Isso porque um sistema composto por microsserviços pode ser visto como um sistema único, mas um sistema distribuído pode não se adequar a uma arquitetura em microsserviço.

— COMO ASSIM?!?!

Deixa eu exemplificar! A análise de um Sistema Distribuído vai focar em qualidades do software que são comuns a uma gama maior que os sistemas que abrangem o foco dos Microsserviços. Por exemplo, se você olhar o The Pirate Bay vai ver o maior catálogo de Torrents que existe. Torrents são baixados em uma arquitetura Peer-to-Peer que é um Sistema Distribuído mas de forma alguma pode ser encarado como um Microsserviço. O The Pirate Bay pode até ter uma arquitetura de microsserviços, mas ele faz parte de um sistema maior que é uma arquitetura mais complexa com protocolos e algoritmos próprios.

Quando falamos de Sistemas Distribuídos estamos preocupados em como os softwares vão interagir, quais algoritmos eles irão usar para alcançar um objetivo e qual é o modelo de falha. Já quando falamos em Microsserviços estamos falando de um subconjunto dessa analise mais focado em como o software vai se manter em produção, qual a fronteira de cada elemento da arquitetura, como será o design do sistema, etc.

REST & HTTP

Victor Osório — Tue, 14 Sep 2021 11:15:55 +0000

Ano passado eu me dediquei a escrever sobre HTTP e REST. Estava com alguns objetivos claro em mente, queria mostrar quando usar e como usar o HTTP. Depois me fiz algumas perguntas e fui pesquisar se existem padrões de projeto em REST. Dessa pesquisa saiu dois POST enormes. O primeiro eu decidi tornar um livreto, mas sem muita revisão e sem muita experiência.

Com esse "livreto" eu acabei conseguindo ser aceito como escritor na Casa do Código, a ideia é escrever um livro sobre desenvolvimento backend, mas focado nos protocolos e não nos frameworks. A parte HTTP já está pronta, e o tal "livreto" é só um capitulo, tem muito mais.

Esse tal livreto está disponível na Amazon, de graça pra quem gosta de sustentar o Jeff Benzos.

Se você quiser pegar no Leanpub, também está lá: leanpub.com/anatomiahttp

Criando um Stream em Java

Victor Osório — Mon, 29 Mar 2021 17:24:43 +0000

Esse é um post muito rápido! Eu tinha estudado isso muito tempo atrás, na época que o Java 8 foi lançado, mas hoje tive uma ideia de usar ele.

Qual é problema a se resolver?

Podemos usar Stream para abstrair um tipo de coleção, com o Stream podemos encapsular o metodo de captura do dado e só expor uma fonte de dados.

Porque eu decidir usar?

Estou implementando uma funcionalidade que consome uma lista de produtos de uma API. Como essa lista é paginada e eu preciso usar em alguns lugares, prefiro criar um Stream, assim toda a lógica de percorrer a lista é encapsulada. Se eu retornasse uma lista, a primeira operação só ocorreria quando toda a lista estivesse carregada na memória. Com o Stream, eu terei pequenas listas na memória e quando ela se esgota vai percorrendo as páginas.

Como implementar?

Vamos abstrair o meu StoreService, certo? Vou apresentar ele como uma interface (na verdade ele é, só que usando MicroProfile RestClient com Quarkus):

@Path("/")
@RegisterRestClient
public interface StoreService { 
    @GET
    @Path("/produtos")
    @Consumes(MediaType.APPLICATION_JSON)
    List<Produto> listarProdutos(@QueryParam("limit") int limit,
                                 @QueryParam("offset") int offset)
}

Configurado e validado que está funcionando corretamente é hora de começar a construir o Stream. O próximo passo e se perguntar qual é as caracteristicas principais desse Stream. Para isso recomendo ler a documentação do Spliterator, interface que é o coração de qualquer Stream. Dado as caracteristicas do meu Stream, vou considerar ele imutável, não nulo e com tamanho fixo.

Agora podemos implementar a classe que irá dar vida ao Stream. Para isso devemos basicamente implementar um método, o tryAdvance, ele deverá consumir um dos itens da lista de produtos e retornar se há ou não mais elementos. Segue abaixo uma tabela com os detalhes da implmentação por método.

Método	Escolhas
`tryAdvance`	Irá consumir elementos da pilha. Se a pilha estiver vazia irá pedir uma nova página, se vier menos elementos que o requisitado, irá setar uma flag dizendo que acabou os elementos.
`trySplit`	Sempre retornará `null`, não será possível fazer processamento paralelo.
`estimateSize`	Será o tamanho da pilha mais uma página, se a última requisição voltar menos itens que uma página, será apenas o tamanho da pilha.
`characteristics`	Irá informar que esse Stream é imutável, com tamanho fixo e não nulo.

Segue a implementação final:

public class RemoteSpliterator implements Spliterator<Produto> {
    private static final Logger logger = LoggerFactory.getLogger(RemoteSpliterator .class);
    private statica final int LIMITE = 10; // tamanho da página

    private Queue<Produto> produtos;
    private boolean temMais;
    private int offsetAtual;
    private StoreService storeService;

    RemoteSpliterator (StoreService storeService) {
        produtos = new LinkedList<>();
        temMais = true;
        offsetAtual = 0;
        this.storeService = storeService; 
    }

    @Override
    public boolean tryAdvance(Consumer<? super Produto> action) {
        if (produtos.isEmpty()) {
            if (!temMais) {
                return false;
            } else {
                var produtosRemotos= storeService.listarProdutos(token, LIMITE, offsetAtual);
                temMais = produtosRemotos.size() == LIMITE;
                offsetAtual += produtosRemotos.size();
                logger.info("Produdos lidos do servidor: {}", produtosRemotos);
                produtos.addAll(produtosRemotos);
            }
        }

        if (produtos.isEmpty()) {
            return false;
        } else {
            action.accept(produtos.poll());
            return true;
        }
    }

    @Override
    public Spliterator<Produto> trySplit() {
        return null;
    }

    @Override
    public long estimateSize() {
        return temMais ? produtos.size() + LIMITE : produtos.size();
    }

    @Override
    public int characteristics() {
        return Spliterator.IMMUTABLE | Spliterator.SIZED | Spliterator.NONNULL;
    }
}

Para finalizar, precisamos apenas criar o Stream, isso pode se feito chamando o método StreamSupport.stream usando o Spliterator criado como primeiro parâmetro e false como segundo parâmetro, já que ele não aceita processamento paralelo.

Porque usei LinkedList?

Porque o acesso não será como em um array, mas em pilha. Apenas adicionarei itens no final a removereis itens do começo. Usar ArrayList tem um custo maior para adicionar e remover, enquanto sua vantagem está no acesso a itens que é em O(1).

Conclusão

Para se criar Streams não precisamos de ter todos os dados em mãos, essa é uma ferramenta poderosa que nos permite transformar qualquer fluxo de dados em uma API poderosa que irá agilizar a execução do seu código.

Você não precisa resolver tudo em uma lista e depois criar o Stream.

Using Bean Validation on Quarkus.io

Victor Osório — Mon, 25 Jan 2021 14:07:08 +0000

Jakarta Bean Validation is a very useful specification. I can't find any reason to do not use it. If you know, please share with me.

The worst way to do it

Validation is a boring feature. It is important, but most of the time it pollutes the code. You have to check function by function if all values are according to the expected.

So, let's imagine the in the code of our Step 02 we need to validate that the username is a String not empty, with a minimum size of 4 and a maximum of 15 and no whitespace. How can we do it?

@POST
@Produces(MediaType.APPLICATION_JSON)
public User create(CreateUserRequest request) {
    Objects.requireNonNull(request.getUsername(), "\"username\" cannot be null!");
    if (request.getUsername().isBlank()) {
        throw new BadRequestException("\"username\" may not be blank");
    } else if (!request.getUsername().matches("^[a-zA-Z][a-zA-Z0-9]+$")) {
        throw new BadRequestException("\"username\" should start with a letter and should only accept letters and numbers");
    } else if (request.getUsername().length() < 4 || request.getUsername().length() > 15) {
        throw new BadRequestException("\"username\" should have size [4,15]");
    }
    return users.create(User.builder()
                            .email(request.getEmail())
                            .username(request.getUsername())
                            .firstName(request.getFirstName())
                            .lastName(request.getLastName()).admin(request.isAdmin())
                            .hashedPassword(request.getHashedPassword())
                            .build());
}

Jakarta Bean Validation allow us to remove all this code and replace with simple annotations.

Configuring JPA in an existent Quarkus Project

To enable Jakarta Bean Validation, you should add it's implementation to Quarkus, that is Hibernate Validator.

<dependency>
    <groupId>io.quarkus</groupId>
    <artifactId>quarkus-hibernate-validator</artifactId>
</dependency>

That is all you need! Now you just need to configure where you will use and what fields you want to validate.

Requiring Valid Parameters

The next step, you should informe Quarkus, where you want to use the validate. From the example above, we can remove all validation lines and just add the annotation javax.validation.Valid.

@POST
@Produces(MediaType.APPLICATION_JSON)
public User create(@Valid CreateUserRequest request) {
    return users.create(User.builder()
                            .email(request.getEmail())
                            .username(request.getUsername())
                            .firstName(request.getFirstName())
                            .lastName(request.getLastName()).admin(request.isAdmin())
                            .hashedPassword(request.getHashedPassword())
                            .build());
}

Then we need inform Quarkus the logic for this validation, it can be done inside CreataUserRequest class. We will use the annotations Email, NotBlank, Pattern and Size.

import javax.validation.constraints.Email;
import javax.validation.constraints.NotBlank;
import javax.validation.constraints.Pattern;
import javax.validation.constraints.Size;

public class CreateUserRequest {

    @Email
    @NotBlank(message = "email may not be blank")
    private String email;

    @Size(min = 4, max = 15, message = "username should have size [{min},{max}]")
    @NotBlank(message = "username may not be blank")
    @Pattern(regexp = "^[a-zA-Z][a-zA-Z0-9]+$", message = "\"username\" should start with a letter and should only accept letters and numbers")
    private String username;

    @NotBlank(message = "firstName may not be blank")
    private String firstName;

    @NotBlank(message = "lastName may not be blank")
    private String lastName;

    private boolean admin;

    @NotBlank(message = "hashedPassword may not be blank")
    private String hashedPassword;

    // [Getters and Setters]
}

This can be used in any Managed Bean inside Quarkus, but if you used on Endpoints it will enable HTTP validation returning a Bad Request response, as we can see in the response bellow. This is not a good way to present errors on a REST API, but at least follow some patterns as returning the correct HTTP Status Code and informing all constraint violations.

{
    "classViolations": [],
    "parameterViolations": [
        {
            "constraintType": "PARAMETER",
            "message": "\"username\" should start with a letter and should only accept letters and numbers",
            "path": "create.request.username",
            "value": "2vepo"
        }
    ],
    "propertyViolations": [],
    "returnValueViolations": []
}

If you need to add validation for a parameter that you do not implement the class, like a String or a primitive type, you can use the annotations directly on the bean paramenter. In this case you can ommit the Valid.

public Optional<User> findByUsername(@Size(min = 4, max = 15) String username) {
    TypedQuery<User> query = em.createNamedQuery("User.findByUsername", User.class);
    query.setParameter("username", username);
    return query.getResultStream().findFirst();
}

Creating Custom Validations

Now that we are able to use the Built-in validations, let's create some custom validators. First we need to define the annotation for it. It should have the following pattern.

@Documented
@Constraint(validatedBy = ReservedWordValidator.class)
@Target({
    METHOD,
    FIELD,
    ANNOTATION_TYPE,
    CONSTRUCTOR,
    PARAMETER,
    TYPE_USE })
@Retention(RUNTIME)
@Repeatable(ReservedWords.class)
@SupportedValidationTarget(ANNOTATED_ELEMENT)
@ReportAsSingleViolation
public @interface ReservedWord {
    String value();

    String message() default "You are using a Reserved Word";

    Class<? extends Payload>[] payload() default {};

    Class<?>[] groups() default {};
}

In our case we are creating a Repeatable just for an example, but you can set any kind of Type for value. Then we need to declare and implement the Validator. As you can see, we are already linking the Validator with the Annotation using @Constraint(validatedBy = ReservedWordValidator.class), now we only need to implement it.

public class ReservedWordValidator implements ConstraintValidator<ReservedWord, String> {

    private String word;

    @Override
    public void initialize(ReservedWord wordAnnotation) {
        this.word = wordAnnotation.value();
    }

    @Override
    public boolean isValid(String value, ConstraintValidatorContext context) {
        return value.compareToIgnoreCase(word) != 0;
    }

}

Now you can use it in your service.

Executing and Testing

With the database running you only need to start the Quarkus using maven.

mvn quarkus:dev

In our example, we have provided 2 endpoints where you can test with valid and invalid parameters.

Create an User: POST /user
Find User by Username: GET /user/{username}

You can find all the code on github.com/vepo/quarkus-tutorial.

vepo / quarkus-tutorial

This is a series of blog posts where I will create a tutorial of Quakus.io.

Quarkus Tutorial

Steps

1. Create a REST API

More information

In the first example, we create a minimal REST API using Quarkus and JAX-RS.

2. Configure JPA Jakarta Persistence

More information

In the second example, we add the persistence layer for our REST API.

3. Configure Jakarta Bean Validation

More information

In the third example, we add the validation to all layers of our REST API.

View on GitHub

Design by Contract

The most important concept on Validating parameters is Design By Contract. A contract defines you rights and responsability, if you define a contract you will not handle values outside that contract. And using Bean Validation enable you to implement Orthogonal Contracts, keeping your code clear. You do not mix validation with business logic. And you don't need to replicated code, only adding an annotation you can spread validation in all your Managed Beans.

Conclusion

Quarkus is easy to configure. You can remove a lot of code, only creating validations.

Foto de Startup Stock Photos no Pexels

Log Cleanup no Kafka

Victor Osório — Fri, 27 Nov 2020 19:07:35 +0000

Ao ler o livro Designing Event-Driven Systems, tive a impressão que o Kafka atua exatamente como uma base de dados. Essa é uma informação falsa. Ele pode atuar como uma base de dados, desde que seja configurado para.

Nesse post vou mostrar algumas configurações de tópicos que deve ser feitas para que o dado seja persistente e não efêmero.

Partições e Segmentos

Espero que você já conheça alguns elementos importantes de um tópico, como Partições e Fator de Replicação. Caso não conheça, leia Anatomia de um Tópico para podermos conhecer basicamente como funciona um tópico.

No post anterior, só entrei até o detalhe do número de partição, pois essa é a parte importante quando falamos de ordenação de mensagens.

Já quando falamos de Cleanup, precisamos introduzir Segmentos. Cada partição, é subdividida em Segmentos. Segmentos contém os dados ordenados sequencialmente (um arquivo de log), assim como a partição. Ao escrever, o Broker escreve apenas ao final do último segmento da partição. Mas os dados são lidos sequencialmente pelos consumers.

Se formos fazer um levantamento nas configurações de um tópico, podemos ver que muitas das propriedades são referentes não somente ao tópico, mas ao segmento.

Propriedade	Descrição	Valor Padrão
`segment.bytes`	Tamanho do arquivo de segmento.	1073741824 (1 GB)
`segment.index.bytes`	Tamanho do arquivo de index do segmento.	10485760 (10 MB)
`segment.jitter.ms`	O jitter aleatório máximo subtraído do tempo de rolagem do segmento programado para evitar sobrecargas.	0
`segment.ms`	Idade máxima do segmento. O Kafka fará a rolagem para garantir sua limpeza	604800000 (7 dias)

Todos esses valores também podem ser configurados por cluster. A configuração de cluster é usando como padrão, caso o valor não seja configurado no Tópico.

Configuração do Tópico	Configuração do Broker
`segment.bytes`	`log.segment.bytes`
`segment.index.bytes`	`log.index.size.max.bytes`
`segment.jitter.ms`	`log.roll.jitter.ms`
`segment.ms`	`log.roll.ms`

Dado os valores de segmento.ms e segment.bytes, o Kafka decidirá quando um segmento será finalizado para que outro seja inicializado.

O arquivo de index, como o nome já diz, é um índice que mapeia em qual posição do arquivo de offset uma mensagem está armazenada, garantindo assim ao Kafka que qualquer mensagem seja lida em tempo constante.

Há também um outro arquivo de index, o timeindex. Este tem como função criar um index baseado no timestamp da mensagem.

Políticas de Limpeza

Mas o que o Kafka faz com mensagens antigas? Isso é configurável por Tópico ou no Cluster.

Essa configuração é muito importante se você usa seu Cluster como Fonte de Verdade ou caso você precise fazer um reset de todo pipeline.

Para configurar é preciso alterar o valor de cleanup.policy (ou log.cleanup.policy para o Cluster). Essa propriedade aceita os valores compact e delete. Por padrão, essas propriedades vêm como delete.

Delete

Quando a política de limpeza selecionada é delete, o Kafka vai remover o segmento baseado na sua idade ou no tamanho da partição.

Propriedade	Descrição	Valor Padrão
`retention.ms`	Idade máxima de um segmento	604800000 (7 dias)
`retention.bytes`	Tamanho máximo da partição	-1 (desabilitado)

Vale lembrar que essas duas propriedades podem também ser configuradas por Cluster.

Configuração do Tópico	Configuração do Broker
`retention.ms`	`log.retention.ms`
`retention.bytes`	`log.retention.bytes`

Compactação

A compactação do Log vai fazer uma limpeza, mas garantindo que você terá ao menos a última mensagem enviada por chave. Assim teremos apenas a última informação de cada chave.

A compactação não irá alterar os offsets das mensagens, uma mensagem é imutável. Irá apenas remover mensagem com offset inferior a última mensagem de cada chave.

Mensagens anda podem ser recebidas, mesmo depois de removidas, isso é feito baseado na propriedade delete.retention.ms. Após esse tempo se esgotar a mensagem não será recebida.

Uma mensagem apagada, significa que novos consumidores não a receberão. Consumidores que já estejam recebendo mensagens não perceberão que o histórico foi alterado, a não ser que este tenha seu offset reiniciado.

A compactação ocorre quando o segmento é finalizado.

Implicações

Ao desenvolvedor e arquiteto, uma pergunta deve ser feita. Quais as implicações da escolha da política de limpeza?

Um Cluster terá suas configurações padrão, mas cada Tópico pode ter sua própria configuração.

Delete

Ao se escolher por remover mensagens de um Tópico, deve-se ter ciência que novos consumers não receberão mensagens antigas. Vamos imaginar que, com os valores padrões, a idade máxima de uma mensagem será 14 dias. Assim, se um tópico é considerado fonte de verdade, deve ter os valores de retention.ms e retention.bytes configurados corretamente.

Para se calcular o volume de dados armazenado por Tópico, é preciso levar em consideração o tamanho médio de uma mensagem, o número de mensagens por dia e o tempo de retenção de uma mensagem. Essa é uma informação que o Arquiteto de Software tem que ter, e mesmo que não tenha, deve estimar baseado nas estatisticas da aplicação.

Compactação

Ao se escolher compactar segmentos de um Tópico, deve-se ter ciência que uma mensagem não deve conter apenas uma atualização de estado, mas a informação completa. Caso haja apenas atualização de estado, haverá perca de dados.

Para se calcular o volume de dados armazenado por Tópico, é necessário ter ciência do número de chaves únicas e o tamanho médio da mensagem, e adicionar o tamanho máximo de um segmento.

Conclusão

Kafka pode ser usado como Fonte de Verdade, mas antes deve-se conhecer a fundo como configurar. As configurações padrão garantem que uma mensagem ficará armazenada por entre 7 e 14 dias, mas isso pode ser alterado de acordo com os requisitos do sistema.

Foto de Azamat E no Pexels.

Configure JPA on Quarkus.io

Victor Osório — Thu, 26 Nov 2020 03:23:42 +0000

JPA is a specification from Jakarta EE that controls the Data Access Layer. The most common implementation for it is Hibernate ORM.

Trade-offs

Choose technology involves a trade-off. I always thought that if I choose JPA, I will lose control of any generated SQL. And that is true!

JPA is an ORM, so most of the SQL is generated from a JPQL. If you do a bad design of your code, you will have SQL been generated at execution time, that is a bad design. In truth, horrible design.

But you will boost your coding speed. You will no more care about writing SQL or modelling the database. You can think in terms of objects, not tables. This does not mean that you will not care about modelling. In the first time is better to create the database model before, than design the objects according to what you want. This will avoid you creating some very commons Anti Patterns from JPA. I, have worked on a project where if you get a user from the database, you can load all objects associated with that user on the memory crashing the application.

It is important to know well the specification to create an optimal service, balancing database performance with development speed.

Advantages	Aisadvantages
Fast Coding	SQL is generated
Easy to change the model	Lack of support for NoSQL ¹
Database agnostic

¹ Use JNoSQL instead of JPA

Configuring JPA in an existent Quarkus Project

Configure dependencies

So the first step is to configure the dependencies. For adding JPA you will have to add the Hibernate Plugin and the Database JDBC plugin.

Why we have two dependencies? This is one of the code ideas of JPA, it is database agnostic. You can change your database with almost no change on your code.

<dependency>
    <groupId>io.quarkus</groupId>
    <artifactId>quarkus-hibernate-orm</artifactId>
</dependency>
<dependency>
    <groupId>io.quarkus</groupId>
    <artifactId>quarkus-jdbc-postgresql</artifactId>
</dependency>

If you want to know which database you can use, just search on mvnrepository.com.

Modeling the database

The next step we need to model the database. You probably have your database model using SQL, but you need to create Java POJOs that will map your data in your Java code.

For this example we will create a backend CRUD for User. That means we will create the Create, Read, Update and Delete endpoints for it.

So, to model we have to add the annotations:

Annotation	Description
`javax.persistence.Entity`	Specifies that the class is an entity.
`javax.persistence.Table`	Specifies the primary table for the annotated entity.
`javax.persistence.Id`	Specifies the primary key of an entity.
`javax.persistence.Column`	Specifies the mapped column for a persistent property or field.

Not even all annotations are required, but you should do a good design of your code.

So I'm defining the User adding all required annotations, and some NamedQuery and a Builder. The builder is just a fancy code to improve the readability and the NamedQuery it will be used later to search for users.

package io.vepo.tutorial.quarkus.user;

import javax.persistence.Column;
import javax.persistence.Entity;
import javax.persistence.GeneratedValue;
import javax.persistence.GenerationType;
import javax.persistence.Id;
import javax.persistence.NamedQuery;
import javax.persistence.Table;
import javax.persistence.UniqueConstraint;

@Entity
@Table(name = "tb_users", uniqueConstraints = {
    @UniqueConstraint(name = "uq_users_username", columnNames = {
        "username" }),
    @UniqueConstraint(name = "uq_users_email", columnNames = {
        "email" })
})
@NamedQuery(name = "User.findByUsernameAndHashedPassword", query = "SELECT usr FROM User usr WHERE usr.username = :username AND usr.hashedPassword = :hashedPassword AND usr.enabled = true")
@NamedQuery(name = "User.findByUsername", query = "SELECT usr FROM User usr WHERE usr.username = :username")
public class User {
    public static final class UserBuilder {
        private String email;
        private String username;
        private String firstName;
        private String lastName;
        private boolean admin;
        private String hashedPassword;

        private UserBuilder() {
        }

        public UserBuilder email(String email) {
            this.email = email;
            return this;
        }

        public UserBuilder username(String username) {
            this.username = username;
            return this;
        }

        public UserBuilder firstName(String firstName) {
            this.firstName = firstName;
            return this;
        }

        public UserBuilder lastName(String lastName) {
            this.lastName = lastName;
            return this;
        }

        public UserBuilder admin(boolean admin) {
            this.admin = admin;
            return this;
        }

        public UserBuilder hashedPassword(String hashedPassword) {
            this.hashedPassword = hashedPassword;
            return this;
        }

        public User build() {
            return new User(this);
        }
    }

    public static final UserBuilder builder() {
        return new UserBuilder();
    }

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Integer id;

    @Column
    private String email;

    @Column
    private String username;

    @Column(name = "first_name")
    private String firstName;

    @Column(name = "last_name")
    private String lastName;

    @Column
    private boolean admin;

    @Column(name = "hashed_password")
    private String hashedPassword;

    @Column(name = "enabled")
    private boolean enabled;

    public User() {
    }

    private User(UserBuilder builder) {
        email = builder.email;
        username = builder.username;
        firstName = builder.firstName;
        lastName = builder.lastName;
        admin = builder.admin;
        hashedPassword = builder.hashedPassword;
        enabled = true;
    }

    public Integer getId() {
        return id;
    }

    public void setId(Integer id) {
        this.id = id;
    }

    public String getEmail() {
        return email;
    }

    public void setEmail(String email) {
        this.email = email;
    }

    public String getUsername() {
        return username;
    }

    public void setUsername(String username) {
        this.username = username;
    }

    public String getFirstName() {
        return firstName;
    }

    public void setFirstName(String firstName) {
        this.firstName = firstName;
    }

    public String getLastName() {
        return lastName;
    }

    public void setLastName(String lastName) {
        this.lastName = lastName;
    }

    public boolean isAdmin() {
        return admin;
    }

    public void setAdmin(boolean admin) {
        this.admin = admin;
    }

    public String getHashedPassword() {
        return hashedPassword;
    }

    public void setHashedPassword(String hashedPassword) {
        this.hashedPassword = hashedPassword;
    }

    public boolean isEnabled() {
        return enabled;
    }

    public void setEnabled(boolean enabled) {
        this.enabled = enabled;
    }

    @Override
    public int hashCode() {
        final int prime = 31;
        int result = 1;
        result = prime * result + ((id == null) ? 0 : id.hashCode());
        return result;
    }

    @Override
    public boolean equals(Object obj) {
        if (this == obj) {
            return true;
        }
        if (obj == null) {
            return false;
        }
        if (getClass() != obj.getClass()) {
            return false;
        }
        User other = (User) obj;
        if (id == null) {
            if (other.id != null) {
                return false;
            }
        } else if (!id.equals(other.id)) {
            return false;
        }
        return true;
    }

    @Override
    public String toString() {
        return "User [id=" + id + ", email=" + email + ", username=" + username + ", firstName=" + firstName
                + ", lastName=" + lastName + ", admin=" + admin + ", hashedPassword=" + hashedPassword + ", enabled="
                + enabled + "]";
    }

}

I want to point out some important things on this code. The @Column annotation is not required, if you omit does not mean that JPA will ignore, it will only read the column with the same name from the field. If you want a not persisted column, you should use create a transient field. If you have a compound name for the field, for example, lastName, if you do not specify the name in @Column, JPA will search for lastName, not last_name. I don't know if you have understood, but naming is important! All applications should follow naming conventions and the SQL Naming Convetions is different from Java Naming Convetions.

With the @Column you have more options, like required and unique. You can see all options on Jakarta Documentation.

For the id column, I have added two important annotations. @Id and @GeneratedValueare required to create a good design, but if you choose a different database probably it will have different values!

I have added the Unique Constraints, this is not required, but as I'm creating the database automatically, I have to do it. In a future tutorial I will teach how to use Flyway to create automatically the database using SQL.

Define the parameters

Hibernate requires few parameters to configure, you can put all in src/main/resources/application.properties. But you can also replace it using environment variables. This will take place later in a tutorial from Microprofile Config.

So we need to define the Database type and credentials and what Hibernate will do with the Schema. For production always use quarkus.hibernate-orm.database.generation=validate, but in our example, we will use drop-and-create recreating the database schema every deploy.

If you need to change more configurations properties, the Quarkus documentation has a list of all available configurations.

quarkus.datasource.db-kind = postgresql
quarkus.datasource.username = postgres
quarkus.datasource.password = password
quarkus.datasource.jdbc.url = jdbc:postgresql://localhost:5432/tutorial

quarkus.hibernate-orm.database.generation=drop-and-create

Creating the database

To create the database, we will use Docker. So just execute the line bellow.

docker run --rm --name postgres-db -e POSTGRES_PASSWORD=password -e POSTGRES_DB=tutorial -p 5432:5432 -d postgres:13-alpine

If you want to use Postgres directly, just download and install it. It will work fine.

Acessing the database

There is a lot of ways to access the database, but you should always use javax.persistence.EntityManager. I have created a service class called Users and added some methods to show the best way to access it.

package io.vepo.tutorial.quarkus.user;

import java.util.List;
import java.util.Objects;
import java.util.Optional;

import javax.enterprise.context.ApplicationScoped;
import javax.persistence.EntityManager;
import javax.persistence.PersistenceContext;
import javax.persistence.TypedQuery;
import javax.persistence.criteria.CriteriaBuilder;
import javax.persistence.criteria.CriteriaQuery;
import javax.transaction.Transactional;

@Transactional
@ApplicationScoped
public class Users {
    @PersistenceContext
    EntityManager em;

    public List<User> list() {
        CriteriaBuilder criteriaBuilder = em.getCriteriaBuilder();
        CriteriaQuery<User> query = criteriaBuilder.createQuery(User.class);
        query.from(User.class);
        return em.createQuery(query).getResultList();
    }

    public User create(User user) {
        if (Objects.nonNull(user.getId())) {
            throw new IllegalStateException("Id should be null!");
        }
        em.persist(user);
        return user;
    }

    public Optional<User> findByUsername(String username) {
        TypedQuery<User> query = em.createNamedQuery("User.findByUsername", User.class);
        query.setParameter("username", username);
        return query.getResultStream().findFirst();
    }

    public User get(int userId) {
        return em.find(User.class, userId);
    }
}

Using Criteria Builder

Using Criteria Builder is a good way when you need to generate dynamically the query. You will create the query programmatically, the API is not so easy to understand because it is very powerful.

Using Named Query

For me, Named Queries is the best way to execute commons queries. You have to write the query on JPQL, not SQL. JPQL is very similar to SQL, but you can use the same query in different databases, Hibernate will translate it for you. It is better to use it than custom JPQL queries because it will compile it once.

Using Query

You can create the query directly. But this is not a good approach! Every time you call createQuery it will compile the query.

public Optional<User> findByUsername(String username) {
    TypedQuery<User> query = em.createQuery("SELECT usr FROM User usr WHERE usr.username = :username", User.class);
    query.setParameter("username", username);
    return query.getResultStream().findFirst();
}

Access the data directly

If you have a Class and an Id, you can access the object directly.

public User get(int userId) {
    return em.find(User.class, userId);
}

Transactional Objects

As we are using a transactional object, all changes we do in the JPA object it will be updated on the database. Each object read from the database is attached to the current session.

Executing and Testing

With the database running you only need to start the Quarkus using maven.

mvn quarkus:dev

In our example, we have provided 3 endpoints:

List all Users: GET /user
Create an User: POST /user
Find User by Username: GET /user/{username}

You can find all code in the repository bellow.

vepo / quarkus-tutorial

This is a series of blog posts where I will create a tutorial of Quakus.io.

Quarkus Tutorial

Steps

1. Create a REST API

More information

In the first example, we create a minimal REST API using Quarkus and JAX-RS.

2. Configure JPA Jakarta Persistence

More information

In the second example, we add the persistence layer for our REST API.

3. Configure Jakarta Bean Validation

More information

In the third example, we add the validation to all layers of our REST API.

View on GitHub

And you can test it using Postman.

Conclusion

If you want to develop fast and use databases, you should use JPA. You will not be worried about queries and knowing the JPA features and implementation, you can optimize the access from your database.

Future Readings

Catálogo de Code Smells ORM

How to set up a REST API using Quarkus.io

Victor Osório — Tue, 10 Nov 2020 12:32:21 +0000

Why Quarkus is a good choice?

Quarkus is one of the best frameworks for Java! First, there was the Wildfly, that as an experiment became a microservices focus project called Wildfly Swarm. Then Wildfly Swarm was renamed to Thorntail. The main purpose of Thorntail was to build a Jakarta EE implementation build for microservices. But there was some pitfall that needed a full rewrite for the code. So this is Quarkus, a light implementation, ready for microservices and it has native support to GraalVM.

So Quarkus is based on lessons learned from previous development. Based on these lessons I believe this will be a better framework, easy to use and fast on execution.

Mangling artifacts is dangerous
When you mangle and repackage a user’s artifacts and dependencies, it can many times go awry.

Don’t replace Maven
Let Maven (or Gradle) handle the entirety of pulling dependencies. We cannot predict the topology of someone’s repository managers, proxies and network.

Don’t get complicated with uberjars
The more complex our uberjar layout is, the harder it is to support Gradle or other non-Maven build systems.

Classpaths are tricky
If different codepaths are required for executing from Maven, an IDE, a unit-test, and during production, you will have a bad time.

Don’t insist on uberjars
For Linux containers, people want layers that cleanly separate application code from runtime support code.

Testability is important
A slow test is a test that is never willingly executed. PRs take forever to validate. Users like to be able to test their own code quickly and iteratively.

Easily extensible means ecosystem
If it’s entirely too difficult to extend the platform, the ecosystem will not grow. New integrations should be simple.

Related: Core things should not be any more first-class than community contributions
For instance, auto-detection in WildFly Swarm only worked with core fractions; user-provided wouldn’t auto-detect.

Ensure the public-vs-private API guarantees are clear.
Intertwingly code (and javadocs) make finding the delineation between public API and private implementations difficult.

Allow BYO components
We don’t want to decide all of the implementations, and certainly not versions, of random components we support.

Be a framework, not a platform
Frameworks are easier to integrate into an existing app; a platform becomes the target with (generally too many) constraints.

Maintain tests & documentation
Ensure the definition of "done" includes both tests and documentation.

Productization complexity
The greater divergence between community and product, the more effort is required for productization. Complicating any process to automate productization from community.

BOM complexity
Related to productization as well, but of itself having a handful of BOMs made life confusing for us and for users. There were often times where fractions would be "Unstable" or "Experimental" for months with no real reason other than we forgot to update it.

Configure Quarkus

The first question we need to answer on a tutorial is: To build a project using Quarkus, what do you need?

For Quarkus we need:

Add the dependencies
Configure the package
Starting coding

1. Configure the dependencies

As Quarkus is a Jakarta EE, we will use the Jakarta EE annotations on the code. But, for the pom.xml we should point to Quarkus dependencies because quarkus has native support for GraalVM.

First we need add all dependencies to Quarkus, this can be done using dependencyManagement:

<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>io.quarkus</groupId>
            <artifactId>quarkus-universe-bom</artifactId>
            <version>1.9.2.Final</version>
            <type>pom</type>
            <scope>import</scope>
        </dependency>
    </dependencies>
</dependencyManagement>

The for that project we will need:

Create REST API
Add JSON Support
Add Reactive Support

For that we will need the following dependencies:

io.quarkus:io.quarkus for creating the REST API
io.quarkus:quarkus-resteasy-jsonb for adding JSON serializer to REST API
io.quarkus:quarkus-resteasy-mutiny for adding reactive support for REST API

2. Configuring the build

The next step we should configure Quarkus build. As we know, Quarkus creates a fat jar with all dependencies.

To enable the Quarkus builder on Maven, just add the following plugin:

<plugin>
    <groupId>io.quarkus</groupId>
    <artifactId>quarkus-maven-plugin</artifactId>
    <version>1.9.2.Final</version>
    <executions>
        <execution>
            <goals>
                <goal>generate-code</goal>
                <goal>generate-code-tests</goal>
                <goal>build</goal>
            </goals>
        </execution>
    </executions>
</plugin>

In this example, I'm compiling as Java 11, but I'm using Java 15 to test. It will work for any version of Java newer than 11. If you need to execute it on Java 8, just change the compiler options.

We can make the build just executing:

mvn clean package

This will create two jars inside the target folder, the one terminating with -runner.jar can be executed with no dependencies.

$ java -jar target\quarkus-tutorial-runner.jar
__  ____  __  _____   ___  __ ____  ______
 --/ __ \/ / / / _ | / _ \/ //_/ / / / __/
 -/ /_/ / /_/ / __ |/ , _/ ,< / /_/ /\ \
--\___\_\____/_/ |_/_/|_/_/|_|\____/___/
2020-11-09 11:16:53,416 INFO  [io.quarkus] (main) quarkus-tutorial 0.0.1-SNAPSHOT on JVM (powered by Quarkus 1.9.2.Final) started in 4.706s. Listening on: http://0.0.0.0:8080
2020-11-09 11:16:53,470 INFO  [io.quarkus] (main) Profile prod activated.
2020-11-09 11:16:53,475 INFO  [io.quarkus] (main) Installed features: [cdi, mutiny, resteasy, resteasy-jsonb, resteasy-mutiny, smallrye-context-propagation]
2020-11-09 11:16:58,790 INFO  [io.quarkus] (Shutdown thread) quarkus-tutorial stopped in 0.024s

This is the way we should execute for production environments, for development we can use Quarkus Maven plugin. It already does the deploy of any change on the running server:

mvn quarkus:dev

3. Adding the REST API Endpoint

The latest step for creating an API is creating the code that will handle the requests. Using JAX-RS is easy, just create a class and add the annotations.

The most simple example is:

@Path("/hello")
@ApplicationScoped
public class HelloEndpoint {
    @GET
    public String sayHello() {
        return "Hello World!";
    }
}

JAX-RS automatically generate a JSON representation for any object returned by this method, you have just to inform the MIME Type.

@Path("/hello")
@ApplicationScoped
public class HelloEndpoint {
    private HelloResponse generateResponse() {
        HelloResponse response = new HelloResponse();
        response.setCode(new Random().nextInt());
        response.setMessage("Hello World!");
        return response;
    }

    @GET
    @Path("/json")
    @Produces(MediaType.APPLICATION_JSON)
    public HelloResponse sayHelloWithJson() {
        return generateResponse();
    }
}

Quarkus also have support for reactive programming. For JAX-RS, you have just to return a Uni or a CompletableFuture.

@Path("/hello")
@ApplicationScoped
public class HelloEndpoint {
    private HelloResponse generateResponse() {
        HelloResponse response = new HelloResponse();
        response.setCode(new Random().nextInt());
        response.setMessage("Hello World!");
        return response;
    }

    @GET
    @Path("/json/reactive")
    @Produces(MediaType.APPLICATION_JSON)
    public Uni<HelloResponse> sayHelloWithJsonReactively() {
        return Uni.createFrom().item(this::generateResponse);
    }
}

Conclusion

With Quarkus you can build quickly a REST API using JAX-RS. As JAX-RS is a Jakarta EE specification, you can migrate your code with few changes to another existing implementation, but Quarkus is the lighter implementation.

Quarkus is a good choice!

You can find all examples on github.com/vepo/quarkus-tutorial

vepo / quarkus-tutorial

This is a series of blog posts where I will create a tutorial of Quakus.io.

Quarkus Tutorial

Steps

1. Create a REST API

More information

In the first example, we create a minimal REST API using Quarkus and JAX-RS.

2. Configure JPA Jakarta Persistence

More information

In the second example, we add the persistence layer for our REST API.

3. Configure Jakarta Bean Validation

More information

In the third example, we add the validation to all layers of our REST API.

View on GitHub

Installing an Old Kubernetes version on Windows

Victor Osório — Tue, 27 Oct 2020 20:55:40 +0000

Yes, sometimes we need to downgrade. So that was my problem I need to maintain an application using Windows and Kubernetes 1.17.

First attempt

I try to install the Kubernetes package inside Docker. But... For now, I only have the version 1.19! I know that I should reproduce the same environment from the deployment.

Second attempt

What if I deploy Rancher v2?

We have one problem. The latest version of Rancher doesn't create a Kubernetes 1.17 cluster, only a 1.19!

So I have to find a version of Rancher that creates the cluster on the required version. I found it on the version 2.3.8.

So to get this Rancher open a CMD running as Administrator and execute:

docker run --name rancher --privileged -d --restart=unless-stopped -p 10080:80 -p 10443:443 rancher/rancher:v2.3.8

Why I'm not using port 80 and 443? Because ETCD will use these ports, let them free!

Troubleshooting

If you tried running more than one Kubernetes Cluster on Windows with WSL, you will have a problem with client certification:

2020-10-27 20:14:53.231000 I | etcdserver: published {Name:etcd-docker-desktop ClientURLs:[https://192.168.65.3:2379 https://192.168.65.3:4001]} to cluster 3c0da32f1ef888fb
2020-10-27 20:14:53.232544 I | embed: serving client requests on [::]:2379
2020-10-27 20:14:53.241806 I | embed: rejected connection from "192.168.65.3:43330" (error "tls: failed to verify client's certificate: x509: certificate signed by unknown authority (possibly because of \"crypto/rsa: verification error\" while trying to verify candidate authority certificate \"kube-ca\")", ServerName "")
2020-10-27 20:14:58.251358 I | embed: rejected connection from "192.168.65.3:43744" (error "tls: failed to verify client's certificate: x509: certificate signed by unknown authority (possibly because of \"crypto/rsa: verification error\" while trying to verify candidate authority certificate \"kube-ca\")", ServerName "")
2020-10-27 20:15:03.258650 I | embed: rejected connection from "192.168.65.3:43908" (error "tls: failed to verify client's certificate: x509: certificate signed by unknown authority (possibly because of \"crypto/rsa: verification error\" while trying to verify candidate authority certificate \"kube-ca\")", ServerName "")
2020-10-27 20:16:22.390547 I | embed: rejected connection from "192.168.65.3:46707" (error "EOF", ServerName "")
2020-10-27 20:16:36.732519 I | embed: rejected connection from "192.168.65.3:47178" (error "tls: failed to verify client's certificate: x509: certificate signed by unknown authority (possibly because of \"crypto/rsa: verification error\" while trying to verify candidate authority certificate \"kube-ca\")", ServerName "")

This happens because Rancher ETCD creates a folder inside the host machine and reuse some data. You can find that information on the log:

2020-10-27 20:14:43.703157 N | etcdmain: the server is already initialized as member before, starting as etcd member...

On the line above, ETCD is informing us that it will use a certificate for an old cluster. This will produce an error.

To resolve this problem, you should remove all data from /var/lib/etcd. I could not find that folder on Windows File System, so I open the Docker Troubleshoot and select Clean / Purge data.

Conclusion

You can run any version of Kubernetes using Windows, WSL and Rancher. You have only to find the correct versions.

Picture by Julius Silver from Pexels

Docker 101 - Tecnologias e Conceitos

Victor Osório — Thu, 22 Oct 2020 13:45:27 +0000

Este material era para ser um curso de Docker. Mas eu não tenho skills para gravação/edição de vídeo. Minha intenção aqui é apresentar alguns conceitos básicos de Docker.

O que é Docker?

Introdução

Antes de iniciar qualquer curso sobre Docker, precisamos primeiro entender o que é Docker? Essa pergunta pode não ter uma resposta muito simples, visto que você pode ouvir esse termo em vários contextos diferentes.

Para responder vamos levantar as seguintes perguntas?

Seria Docker uma empresa?
Seria Docker um software?
Seria Docker uma plataforma?
Seria Docker uma tecnologia?

Seria Docker uma empresa?

SIM!

Sim Docker é a empresa que criou o Docker. A Docker, Inc. provê soluções Enterprise e o Docker Hub.

Seria Docker um Software?

SIM!

Sim, você pode executar um docker --version em qualquer máquina com Docker instalado. Ele é desenvolvido pela Docker, Inc. e pode ser instalado em qualquer dos mais comuns SOs do mercado.

Seria Docker uma Plataforma?

Podemos dizer que SIM!

Não sou tão assertivo nessa resposta porque o termo plataforma é genérico. Mas há uma série de componentes no Docker que nos permite chamar ele de plataforma. Você usa docker para criar imagens, que pode ser armazenadas em um Docker Registry, que serão carregadas por um Gerenciador de Containers. Há inúmeros nós nessa teia.

Seria Docker uma Tecnologia?

Com certeza SIM!

O que a Docker, Inc. criou foi muito além de um software. Ela utilizou vários recursos já existente para criar um conceito a containerização. Com isso se gerou uma Explosão Cambriana na industria. Novos conceitos e padrões surgirão depois dele.

Assim podemos dizer que a maneira de se gerenciar uma infra-estrutura em 2019 é completamente diferente da maneira que se gerenciava em 2005. COMPLETAMENTE DIFERENTE!

Depois do advento do Docker, a Docker, Inc. cedeu sua core engine para Cloud Native Computing Foundation sob o nome de containerd. Você pode ver pela CNCF Landscape que o containerd é uma caixinha em Container Runtime. A evolução da tecnologia não é mais controlada pela Docker, Inc., mas por essa organização que faz parte da Linux Foundation.

A tecnologia Docker

"Na natureza nada se cria, nada se perde, tudo se transforma" Antoine-Laurent de Lavoisier

Essa frase de Lavoisier se adequa perfeitamente a projetos Open Source! Na verdade Docker não criou nada novo e nem utilizou nenhuma tecnologia nova, mas a partir do que existia uma nova tecnologia foi criada.

Tecnologias Bases

Docker se baseia em algumas tecnologias já existentes no Linux.

COW

Copy On Write é uma técnica que permite a criação de uma estrutura de arquivos por camada. Cada camada altera a anterior e camadas podem ser compartilhadas com processos diferentes.

cgroups

cgroups é uma feature do Linux que permite controlar o tanto de recurso (CPU, Memória, I/O) que um processo pode utilizar.

iptables

iptables é um programa Linux que permite criar regras de redirecionamento de portas dentro do Linux.

Linux Namespaces

Linux Namespaces permite o compartilhamento, e o isolamento, de recursos do SO dentro do Linux. Similar ao cgroups, mas se refere a outros tipos de recursos. Por exemplos: PIDs, nomes de arquivos, hostnames, etc...

Infraestrutura Imutável

O termo Immutable Infrastructure vem em contraste ao que tinhamos antes do Docker, que é a Mutable Infraestructure.

Em uma Infraestrutura mutável, para fazer qualquer alteração em ambientes, deve-se alterar as configurações existente. Cada atualização há um risco muito grande que deve ser minimizado por técnicas como rollback, dry-run e backups. Cada update é um risco, pois o novo deploy vem alterar o antigo.

Com a infraestrutura imutável, o novo deploy vem em paralelo ao antigo. É criado uma nova estrutura e o mesmo substitui o antigo. Assim, caso o novo apresente falhas, o antigo pode ser reutilizado.

Antes do Docker

Antes do Docker existir, para fazer a configuração de um serviço era preciso alguns passos:

Configurar um Servidor (Instalar Linux, Unix ou Windows)
Instalar dependências (Apacha httpd, Java, Python, etc...)
Configurar o Servidor de Aplicação (JBoss, IIS)
Fazer deploy da Aplicação
Monitorar o estado da Aplicação (monit)

Configurar um servidor era a tarefa mais fácil, o difícil era fazer atualizações ou gerenciar projetos legados. Muitas vezes duas aplicações precisam de diferentes dependências para rodar. Ou tinha problema com o compartilhamento de recursos, duas aplicações tentando escutar na mesma porta TCP.

Atualizar um servidor de produção, envolvia criar scripts para fazer diversas alterações que nem sempre funcionavam na produção. Quando um erro acontecia na implementação.... ROLLBACK! O que também era uma atividade complexa!

Possível solução

Uma boa e possível solução era a criação de fotos (ou snapshots) do servidor. E se pudéssemos a partir de uma foto rodar um servidor? Ou voltar para uma versão anterior a partir de uma foto? E se esse servidor fosse totalmente isolado? Posso executar duas versões dele em paralelo?

Depois do Docker

Para executar um servidor:

docker pull my-application:1.0.1
docker stop my-app
docker rm my-app
docker run -name my-app -p 8080:80 my-application:1.0.1

Com as 4 linhas acima, podemos atualizar uma aplicação chamada my-application para versão 1.0.1. Deu erro?

docker stop my-app
docker rm my-app
docker run -name my-app -p 8080:80 my-application:1.0.0

Mais 3 linhas para fazer o rollback seguro!

Conceitos Básicos

Um pouco antes do Docker, uma das tecnologias da moda era a virtualização. Mas em que consistia a virtualização e porque a necessidade de containerização

Virtualização

Talvez você já tenha criado uma Máquina Virtual. Se não criou, gaste algum tempo baixando o VirtualBox e rodando algumas versões de SOs diferentes dentro da sua máquina.

Quando falamos de virtualização, estamos dividindo os recursos físicos da máquina com outras máquinas, que são chamadas máquinas virtuais. Assim, podemos alocar 1 CPU, 2GB de memória, etc... Nessa máquina rodará um Sistema Operacional completo que não compartilhará nenhum recurso com nenhum outro. Se esse SO não utilizar todo o recurso alocado, este não poderá ser compartilhado.

Containerização

Com containers todas as aplicações compartilham o mesmo SO. O SO rodará a aplicação isoladamente, criando e alocando qualquer recurso que o container necessitar.

Vantagens

Como a containerização acontece no nível do Sistema Operacional, há uma série de vantagens:

Inicialização imediata. Não é necessário se inicializar o Sistema Operacional
Compartilhamento de Recursos. Caso o container não utilize Memoria ou CPU, esta fica disponível para outro.
É possível criar mais uma instância do mesmo container imediatamente.

Docker Building Blocks

Gosto do conceito de Building Blocks, quando me refiro a ele estou definindo elementos básicos para algo. Assim em Docker podemos definir alguns building blocks.

Para o desenvolvimento de qualquer aplicação Docker, é necessário entender o que são cada um desses elementos.

Imagem
- TAGs
Container
- Volume
- Network
Registry
Dockerfile

Imagem

Uma Imagem é uma foto do Container em seu momento inicial. Se formos comparar com os conceitos de máquinas virtuais, a Imagem seria um SNAPSHOT.

Uma Imagem é usada para gerar um Container. Uma Imagem pode ser gerada a partir de um Container. Uma Imagem tem algumas propriedades que estendem o conceito de Snapshot, podemos definir qual comando a Imagem irá executar assim que ela iniciar.

Uma Imagem é preferencialmente construida a partir de um Dockerfile.

Container

Um Container é uma instância de uma aplicação. Pode haver vários Containers rodando com a partir da mesma Imagem. Ao se executar um Container é preciso uma Imagem e um conjunto de informações:

Volumes
Variáveis de Ambiente
Portas
etc...

Volume

O Sistema de Arquivo de um Container é descartável. Assim, ao se remover o container, todos os arquivos dele são removidos. Um Volume é um mapeamento entre um diretório da máquina hospedeira para o container. Usando COW, o diretório, ou arquivo, dentro container é sobrescrito.

Network

Quando um container é executado, pode pertencer a uma ou várias Networks. Por padrão, ele pertence a Network Default. Para cada Network associada, ele terá um IP NAT associado.

Uma Network serve para criar uma VPC. Dois containers só podem se comunicar se pertencerem a mesma Network. Uma Network contém DNS que resolve o IP através do nome do container. Assim, se um container tentar acessar container-1:8080 estará tentando acessar a porta 8080 do container com nome container-1.

Registry

Um Registry é um servidor web para armazenar uma Imagem. No ciclo de vida de uma Imagem, ela pode ser gerada ou baixada de um Registry.

O padrão é o Docker Hub, sempre que possível procure imagens lá. No Docker Hub há imagens verificadas e não verificadas. Procure usar as imagens verificadas, caso contrário você pode estar correndo o risco de expor seus dados.

Dockerfile

Dockerfile é o script de criação de uma Imagem. Uma Imagem deve ser construida através de um script, e pode ser reconstruida em qualquer máquina.

Conclusão

Docker pode parecer uma mágica, mas é só o uso inteligente de tecnologias há muito tempo já existiam no Sistema Operacional Linux. Com o uso dessas tecnologias, podemos agora criar deploys completamente independentes dentro de um mesmo sistema operacional, usando a mesma infraestrutura.

Com Docker não há o desperdício de recursos que existia com a Virtualização. Agora os recursos podem ser alocados de forma mais inteligente.

Foto de Tom Fisk no Pexels.

Ágil 101 - O que devo saber?

Victor Osório — Sat, 03 Oct 2020 21:25:44 +0000

Ágil é um adjetivo. Ele descreve uma característica de algo. Mas Ágil não pode vir sozinho, pois seu uso se refere a uma comparação. Um ninja é mais ágil que um lutador de sumô.

Quando falamos de Ágil no mundo do Desenvolvimento de Software estamos falando de um movimento que veio em resposta aos modelos gerenciais predominantes até 2001.

Porque 2001? Porque foi em 2001 que Kent Back reuniu um pessoal, que muitos não se gostam publicamente hoje, para discutir os Modelos de Desenvolvimento de Software. De lá saiu um manifesto que se você não o conhece... Bom, ele define o que é Ágil.

Estamos descobrindo maneiras melhores de desenvolver software, fazendo-o nós mesmos e ajudando outros a fazerem o mesmo. Através deste trabalho, passamos a valorizar:

Indivíduos e interações mais que processos e ferramentas
Software em funcionamento mais que documentação abrangente
Colaboração com o cliente mais que negociação de contratos
Responder a mudanças mais que seguir um plano

Ou seja, mesmo havendo valor nos itens à direita, valorizamos mais os itens à esquerda.

Eu vou falar sobre cada item desse manifesto, mas antes precisamos entender como é a gerência de projetos não-ágil e qual a ideia por trás do ágil.

Antes do Ágil havia o PMBOK

A disciplina de Gerência de Projetos é bastante complexa e precisamos ter em mente que não há certo e errado. Há padrões e esses padrões podem ser aplicados em contextos. O PMBOK, Project Management Body of Knowledge, é bastante útil e é largamente utilizado na indústria e governos. Ele consiste em uma série práticas que vão definir como um projeto deve ser gerenciado. Temos os processos, documentos que devem ser gerados, reuniões que deve ser feitas, etc..

Antes do Ágil, o padrão PMBOK era imposto dentro da empresa. Todos os projetos tinha que seguir exatamente o que estava definido lá. E é lá que temos o famoso Cascata, em que entre a definição do que será entregue e a entrega temos meses onde não há comunicação entre Equipe de Desenvolvimento e Cliente.

Vale ressaltar que esse modelo é muito bom e funciona para outros tipos de projetos. Pensa bem, o que pode dar errado no meio do caminha da construção de um prédio? Muito diferente da construção de um software.

Ideias por trás do Ágil

Antes que você pense que o Ágil foi uma revolução, não. Nos anos 90, o que aconteceu foi que ideias que já existiam de administração começaram a ser aplicada em Desenvolvimento de Software.

LEAN

Um das ideias bem óbvias no Ágil e que passa despercebido por quem não conhece é a influencia do livro Toyota Kata: Gerenciando Pessoas para Melhoria, Adaptabilidade e Resultados Excepcionais (nunca li). Observe o que é dito nos apendices do livro O Projeto Fênix:

As liçoes do Sr. Rother foram codificadas no livro Toyota Kata, que estrutura o processo de planejamento e cultura que deve existir para permitir o ciclo PDCA Lean (Planejar, Fazer, Verificar, Agir). Acredito que essa seja uma das contribuições mais extraordinárias para o mundo da melhoria dos processos.
A manifestação mais óbvia do Toyota Kata é o ciclo de melhoria de duas semanas, no qual cada supervisor de centro de trabalho deve melhorar algo (qualquer coisa!) a cada duas semanas. Para citar o Sr. Rother, "A prática do kata é o ato de praticar um padrão para que ele se torne uma segunda natureza. Em sua gestão diária, a Toyota ensina uma maneira de trabalhar - um kata - que tem ajudado a torná-la muito bem-sucedida nas últimas décadas.

Podemos ver claramente dois pontos aqui óbvios:

Ciclo de duas semanas
Para cada letra do LEAN (PDCA em Português), tem uma reunião no SCRUM.

Gestão da Equipe

A Gestão de uma Equipe também é baseada em ideias que vem de livros influentes. O SCRUM vai tentar resolver os problemas levantados no livro Os 5 desafios das equipes (não li também). Observe o que é dito nos apendices do livro O Projeto Fênix:

Em seu modelo, as cincos disfunções são descritas como:

Ausência de confiança - relutância em ser vulnerável dentro do grupo

Medo de conflito - buscando harmonia artificial sobre debate fervoroso construtivo

Falta de comprometimento - fingir comprar as decisões do grupo cria uma ambiguidade na organização

Evitação de responsabilidade - desviar da responsabilidade para chamar a atenção dos colegas sobre comportamento contraprodutivo, que estabelece padrões baixos

Desatenção aos resultados - focar no sucesso pessoal, status e ego antes do sucesso da equipe

Cada ponto desse é direcionado por alguma prática do SCRUM ou XP. Em uma simples descrição da equipe desejada pelo SCRUM, há muita teoria de administração de equipes.

O Manifesto

Para se por em prática o Manifesto Ágil, é preciso ser um gestor e ter poder sobre os processo da empresa. PONTO FINAL. Não é possível uma equipe decidir ser ágil, sem contar com a boa vontade da empresa, mesmo que a empresa ganhe com essa mudança cultura.

O Manifesto Ágil na verdade propõe uma inversão de valores corporativos. Ao invês de seguir os processos da empresa, cada equipe vai decidir o que fazer com a intenção de entregar mais valor mais rapidamente. Isso é uma resposta ao engessado PMBOK. Quando se assina um contrato para um projeto, todos os requisitos propostos DEVEM ser entregues. Isso pode implicar muitas horas extras caso haja algum imprevisto. Ou pode levar a não aceitação do produto pelo cliente, muitas vezes o cliente percebe que o que foi pedido não é o que se realmente deseja. Isso é comum, sem estresses.

Então para se colocar em prática um framework Ágil, deve-se primeiro mudar a forma de se assinar os contratos. Não se pode vender um produto com homens/hora, escopo fechado. Tem que se vender um projeto com iterações e escopo aberto. Vamos começar a desenvolver o projeto X que inicialmente está previsto para 5 Sprints. Todos os documentos assinado entre Empresa e Cliente deve ser completamente diferentes.

Indivíduos e interações mais que processos e ferramentas

Em um ambiente Ágil, a equipe terá mais autonomia que em outros contextos. Os membros dessa equipe decidirão se vão executar o framework proposto (viu que não falei processo?) ou se vão adaptar. O próprio Framework Scrum não se denomina processo por esse motivo, caso a equipe decida que alguma prática deve ser alterada, sem estresse!

Muito das reuniões propostas pelo Scrum são denominadas rituais, porque eles devem ser executados como rotina, serem inseridos na cultura. Eles tem valores inseridos nele. Por exemplo, a Retrospectiva deve ser para reavaliar se o próximo Sprint deve ter melhorias. Lembra do processo de melhoria continua do LEAN?

Obviamente que a equipe deverá seguir alguns padrões da empresa. Não dá pra simplesmente jogar fora a ferramenta de Solicitação de Mudança da empresa e usar uma nova. Mas a maneira de se usar deve ser menos impositiva.

Software em funcionamento mais que documentação abrangente

Em projetos PMBOK havia muito tempo gasto em escrita de documentação. Havia o documento de Requisitos, Arquitetura e Testes. Cada um era escrito e validado antes do desenvolvimento e deviam ser validados de acordo com a entrega.

Em um contexto Ágil, o Software em funcionamento tem mais valor. No SCRUM, uma reunião de Review vale mais do que um documento de Requisito. E provavelmente é mais barato fazer um reunião de Review a cada 2 semanas do que escrever um documento de requisitos gigantesco a cada 3 meses.

Que fique claro uma coisa, o software deve ser documentado, o que pode não ser documentado é os contratos de requisitos com o cliente. Caso seu projeto não use uma Wiki interna (ou coloca no repositório de código mesmo) para documentar arquitetura, vamos começar agora! Abre um README.md e coloca todos os pressupostos arquiteturais agora!

O mais claro desse ponto é dizer: mais vale um teste automático do que um documento de testes em .docx.

Colaboração com o cliente mais que negociação de contratos

O Cliente deve ser envolvido em todo o processo de desenvolvimento. Se não puder participar das reuniões diárias (nem é bom participar... 😳), deve participar das reuniões de Review! Cada requisito tem que ser validado com o cliente, mostrado e discutido. A decisão é dele e as vezes a opinião dele muda muito rapidamente.

O que acontecia com o PMBOK é que todo o projeto estava detalhado na documentação e deveria ser entregue conforme a documentação. Era esse o contrato. A comunicação com o cliente se dava somente para informar se o projeto está em dia ou atrasado, e muitas vezes as horas extras eram escondidas do cliente. Vamos fazer uma banco de horas que próximo mês nós tiramos. Em meu primeiro projeto acumulei 72hs em apenas 2 meses e acabei tirando todas essas horas nos 2 meses seguintes.

No contexto Ágil, o projeto não deve ser encarado como algo fechado que é contratado e deve ser entregue. Isso pode ser válido para construção de um prédio, mas para construção de software não é possível. Há muito mais volatilidade dos requisitos. O cliente deve ser envolvido em todo o processo.

Responder a mudanças mais que seguir um plano

Mudanças vão ocorrer! Toda a disciplina de Engenharia de Software já leva em conta que o Cliente não sabe o que quer, ou se sabe, pode ser que sua necessidade mude.

É comum ver desenvolvedores reclamando que o cliente nunca sabe o que querem. É por isso que são chamado de desenvolvedores e não engenheiros de software! 😏

Por isso que uma equipe ágil deve ter um backlog e deve gerenciar esse backlog muito bem! Ele deve ser repriorizado a cada iteração. Lembre-se o foco deve ser entregar valor ao cliente!

Mas muito cuidado! Deve ser feito um Gerenciamento de Débito Técnico! Não é possível construir um software respondendo a mudanças rapidamente, mas deixando muita sujeira pra trás... O nome disso não é Ágil! É eXtreme Go Horse (XGH)!

Conclusão

Acabei de apresentar quais são os principios do Ágil. Agora cabe a você usar bem esses conceitos. Os Frameworks Ágeis são baseados em Times autogerenciaveis, isso é uma das bases.

Eu nunca tive contato com um agilista, mas caso você tenha veja se ele está aplicando esses conceitos. Caso não esteja, é hora de ter uma conversa séria com o gerente! É muito complicado se criar uma função para garantir o ágil... Parece contraditório.

Há outros temas que o Ágil habilitou, porém são temas completamente diferentes. Você viu que todas as citações usadas foram de um livro de DevOps? Pois é, o Ágil possibilitou o DevOps. E este é nada mais nada menos do que a aplicação de conceitos ágil no suporte. Outro tema foi Microsserviços... Mas é muito tema para pouca letra...

Desejo que você aplique esse conhecimento no seu projeto e que ele seja um sucesso! 😉

Leituras Recomendadas

Foto de Essow Kedelina no Pexels

Soft-Skill 101 - Mentoria. Porque e como?

Victor Osório — Mon, 28 Sep 2020 12:14:48 +0000

Porque?

Porque eu mentoro gratuitamente é a primeira pergunta que respondo quando me procuram. A resposta é simples: eu sei o que a falta de mentoria pode fazer com a carreira de uma pessoa. Passei meus 10 primeiros anos sem a ajuda de ninguém e evolui muito pouco. Não sabia como estudar, não conhecia o mercado, não sabia o que era uma postura profissional, não conhecia os frameworks, etc... As empresas que eu trabalhavam gostavam do perfil do herói. O cara que chega lá e mata o leão. E eu era esse perfil, mas sempre reinventando a roda.

Só temos que contextualizar isso no tempo. Nessa época tinha pouco conteúdo online. E eu não sabia o que procurar. Muitas vezes ia procurar na academia, em artigos.

Como?

A segunda pergunta é o como eu mentoro.

Deixo minha agenda aberta, qualquer um com acesso ao meu LinkedIn pode me encontrar ou encontrar nos sites de mentoria gratuita e marcar 30 minutos.

Marcada a reunião, eu dou uma olhada nas redes sociais da pessoa. O que ela anda postando? Como ela se descreve? O que ela anda curtindo?

Dentro desses 30 minutos vou fazer pedir para a pessoa descrever a sua história. Porque me procurou? Quais são suas queixas? O que você está fazendo hoje?

Normalmente a pessoa vai gastar 10 minutos contando essa história. Nesse tempo é fácil levantar algumas deficiências. Seja um conceito errado, seja uma incompatibilidade com suas redes sociais.

Depois eu explico os conceitos que eu identifiquei como errados. Exemplifico os comportamentos que não são desejáveis. E aponto algumas melhorias nas redes sociais. O exemplo mais claro:

— Estamos desenvolvendo uma API REST...
— Como você me descreve uma API REST?
— Ah, uma API que usa JSON!
Lá vou eu explicar que usar JSON não faz com que uma API seja RESTful.

Depois eu proponho um RoadMap. Vamos iniciar um plano de estudos. Eu vou dar um tema, vou dar uns posts de blog e vou pedir que a pessoa estude. Se possível ela deve:

Produzir um post de blog
Fazer um exemplo do que foi estudado

Áreas Avaliadas

Eu creio que mentoria é uma pratica muito importante. Eu nunca recebi um processo de mentoria formal, apenas algumas avaliações que me foram muito proveitosas.

Para desenvolver meu processo de mentoria, acabei levantando algumas possíveis áreas e o que desejo produzir de resultados nas pessoas que me procuram.

Qualidade de Código

Um desenvolvedor deve produzir um código com qualidade. O que isso significa? Este código deve ser:

Estável
De fácil compreensão
De fácil manutenção
Otimizado

Linguagem de Programação

Um desenvolvedor deve conhecer a fundo a sua linguagem de programação principal. Deve conhecer as APIs, como a sua linguagem está evoluindo, os seus pontos fortes e os seus pontos fracos.

Este deve saber ao iniciar um projeto qual linguagem usar. Se a sua não for a mais recomendada, deve saber o porque e qual ele pode usar.

Arquitetura de Software

Um desenvolvedor não precisa ser apenas um desenvolvedor. Ele pode atuar como arquiteto, compreendendo o que o arquiteto está falando e dialogar com o arquiteto.

Por isso proponho que o desenvolvedor conheça os principais conceitos arquiteturais. Quais são os padrões arquiteturais existentes. Deve saber documentar a sua solução.

Ele deve saber o que aplicar quando um problema surgir. E como raciocinar em cima do problema.

Conceitos Teóricos

O que você aprendeu na faculdade não fica na faculdade. É importante usar ele no seu trabalho.

Cada mentorado deve ter os conceitos corretos e saber usar. E mesmo que seja alguém em migração de carreira, deve aprender alguns conceitos de Computação para desempenhar um bom trabalho.

Negócios

Ninguém cresce em uma empresa se não conhecer a fundo o modelo de negócios dela.

Desejo que meus mentorados saibam como suas empresas funcionem e que eles contribuam para o crescimento delas.

Eles devem conhecer:

Quem são seus superiores?
Como a empresa se mantém?
O que a empresa deseja deles?

Comportamento

O comportamental é essencial. Ninguém cresce se seu comportamento não mudar. Todos iniciam como júnior. Depois vão ganhando independência e param de depender dos Seniores, nesse momento se tornam plenos. Depois passam a apoiar outros durante a realização das atividades, e nesse ponto se tornam Seniores.

Eles devem saber ouvir e perguntar. Como se comportar e o que falar. As vezes um comentário indesejado pode ser fatal para sua carreira.

Conclusão

Eu sempre digo uma fase que reflete a minha própria experiência. O problema quando você não sabe é que você não sabe o que não sabe. Eu passei muitos anos achando que sabia muito, isso porque tinha me treinado ao máximo naquilo que já sabia, mas como não tinha contato com pessoas mais experientes, estava travado.

Só consegui crescer quando mudei de empresas e tive contatos com outras realidades. Isso foi muito enriquecedor!

Se você deseja mentoria, procure alguém que você admira e mande uma mensagem. Não é preciso muito tempo para o mentor, apenas 30 minutos a cada duas semanas.

Se você deseja mentorar e quer conversar, pode me procurar. Sempre respondo no Twitter e LinkedIn.

Atividades em paralelo

Paralelo à mentoria, é urgente produzir material em português. Nós estamos passando por um período de grande crescimento da necessidade de desenvolvedores. Você pode reparar, 10 anos atrás só tinha formados trabalhando em nossa área, agora temo pessoas sem nenhum conhecimento teórico, apenas o conhecimento prático aprendido em Bootcamps que não devem se aprofundar muito.

Tenho feito bastante isso, escrito coisas básicas. O que é básico para um pode ser muito relevante para outros.

Próximos Passos

Agora que eu estabeleci uma rede com algumas pessoas sendo mentoradas, devo me aprofundar no tema. Ler alguns artigos sobre o próprio processo de mentoria e sua aplicação no mundo de desenvolvimento de software.

Para isso escolhi dois artigos iniciais usando o Google Scholar:

KE Kram (2007) - The Landscape of Mentoring in the 21st Century
C Casado-Lumbreras (2011) - Culture dimensions in software development industry: The effects ofmentoring

Espero ler eles em breve...

Foto de nappy no Pexels.

Testes 101 - Testando aplicações Java

Victor Osório — Wed, 02 Sep 2020 00:16:37 +0000

Testes são fundamentais. Se você deseja ser desenvolvedor Java lhe recomendo pelo menos conhecer o que são TDD, Maven e JUnit. E vou te apresentar o porque.

TDD

TDD significa Test-Driven-Development. Se você imagina que é criar o testes e depois o código, você está um pouco enganado. TDD é uma disciplina um pouco diferente.

TDD é uma disciplina, não é algo que pode ser explicado. É uma cultura que você tem que aprender, e treinar. Depois de anos você vai ver já melhorou bastante, mas tem muito mais a aprender.

Ciclos do TDD

Pra explicar o TDD facilmente, temos que falar dos ciclos. Nem todos os testes criados serão usados e eles não devem refletir o requisito final. Você tem que usar Baby Steps, passos de bebê, em cara ciclo. Imagine um ciclo como um rodada de desenvolvimento de 10 a 30 minutos:

[R] Você cria um Test, ele deve falhar.
[G] Você implementa o código para o teste funcionar
[R] Você Refatora o código

Ao final de um tempo de desenvolvimento você terá vários testes. Alguns podem ser descartados, outros vão ficar. Eu recomendo ficar apenas os que representem a funcionalidades do código. E recomendo também que cubram o máximo possível o seu código.

Maven

Se estamos falando de testes, estamos falando de Processo de Build. Se você cria os seus testes e não os colocar para serem executados automaticamente, você não fez praticamente nada.

O Maven abstrai cada build criando um ciclo com fases. Então os testes sempre serão executados se você deseja executar ou empacotar o seu projeto.

Para criar um projeto usando Maven, instale o Maven e execute:

mvn archetype:generate -DgroupId=io.vepo.tests -DartifactId=testsExample -DarchetypeArtifactId=maven-archetype-quickstart -DinteractiveMode=true

Você vai observar duas coisas:

o Maven criou um arquivo pom.xml colocando como dependência o JUnit, e que versão antiga! 🙄
o Maven criou duas pastas de código: src/main/java e src/test/java.

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
  <modelVersion>4.0.0</modelVersion>
  <groupId>io.vepo.tests</groupId>
  <artifactId>testsExample</artifactId>
  <packaging>jar</packaging>
  <version>1.0-SNAPSHOT</version>
  <name>testsExample</name>
  <url>http://maven.apache.org</url>
  <dependencies>
    <dependency>
      <groupId>junit</groupId>
      <artifactId>junit</artifactId>
      <version>3.8.1</version>
      <scope>test</scope>
    </dependency>
  </dependencies>
</project>

Mas onde o Maven configura que os testes devem ser executados durante a build ou como ele descobre os testes? O Maven se baseia na ideia convention-over-configuration, ou seja, Convenção acima de Configuração. Para realizar certas configurações basta apenas usar a convenção apropriada.

O projeto criado já vem com alguns testes JUnit configurado, porém é usado a versão 3.8.1... Alguém por favor atualiza o github.com/apache/maven-archetypes, por favor!

JUnit 5

O JUnit é o framework que irá gerenciar o ciclo de vida de seus testes. Cara classe dentro de src/test/java contendo um método com a annotation org.junit.jupiter.api.Test será executado como testes. Assim para migrarmos o arquivo gerado automaticamente, basta mudar o seguinte conteúdo:

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
  <modelVersion>4.0.0</modelVersion>
  <groupId>io.vepo.tests</groupId>
  <artifactId>testsExample</artifactId>
  <packaging>jar</packaging>
  <version>1.0-SNAPSHOT</version>
  <name>testsExample</name>
  <url>http://maven.apache.org</url>
  <dependencies>
    <dependency>
      <groupId>org.junit.jupiter</groupId>
      <artifactId>junit-jupiter-engine</artifactId>
      <version>5.5.2</version>
      <scope>test</scope>
    </dependency>
  </dependencies>
  <build>
    <plugins>
        <!-- Need at least 2.22.0 to support JUnit 5 -->
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-surefire-plugin</artifactId>
            <version>3.0.0-M3</version>
        </plugin>
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-compiler-plugin</artifactId>
            <version>3.8.1</version>
            <configuration>
                <source>1.8</source>
                <target>1.8</target>
            </configuration>
        </plugin>
    </plugins>
</build>
</project>

package io.vepo.tests;

import static org.junit.jupiter.api.Assertions.assertEquals;

import org.junit.jupiter.api.DisplayName;
import org.junit.jupiter.api.Test;

public class AppTest 
{   
    @Test
    @DisplayName("Test if it works")
    public void simpleTest() {
        assertEquals("OK", "OK");
    }
}

Observe que com o JUnit 5 eu consigo dar nomes aos testes, isso facilita em muito a identificação de um erro. Eu costumo usar frases que definem as features testadas. Isso facilita quando preciso fazer manutenção em código escrito meses, ou anos, antes.

Ciclo de Vida

O ciclo de vida de um teste passa pela execução métodos antes/depois da classe ser criada e métodos antes/depois da execução de cada teste. Dê uma olhada na documentação. Há vários exemplos de como usar @BeforeAll, @BeforeEach, @AfterEach e @AfterAll.

Se eu for detalhar cada feature do JUnit 5, esse post não terá fim. São muitas, conheça elas, assim você pode construir bons testes.

Asserções

O mais importante do JUnit não é apenas a execução dos testes, mas a validação dos resultados.

O JUnit provê uma classe com métodos estáticos para realizar isso. Na documentação oficial há vários exemplos.

@Test
void standardAssertions() {
    assertEquals(2, calculator.add(1, 1));
    assertEquals(4, calculator.multiply(2, 2),
            "The optional failure message is now the last parameter");
    assertTrue('a' < 'b', () -> "Assertion messages can be lazily evaluated -- "
            + "to avoid constructing complex messages unnecessarily.");
}

Tests DSL

DSL significa Domain-Specific Language. Você cria uma DSL seu código pode ser lido como uma linguagem. Em testes é comum se construir uma DSL usando os termos Given-When-Then. Você pode fazer isso em português Dado-Quando-Então:

(Dado) Qual o contexto que o teste é executado?
(Quando) Qual ação vai ser testada?
(Então) O que deve ser validado?

Um bom exemplo pode ser:

dadoNovoUsuário()
    .executaChecking()
        .validaReserva();

Aí fica de você implementar cada método e reutilizar ele quando possível.

AssertJ

Há algumas bibliotecas que auxiliam na construção dessa DSL. Eu gosto muito da AssertJ. Com ela é possível usar uma DSL para validação de resultados complexos.

// extracting multiple values at once grouped in tuples
assertThat(fellowshipOfTheRing).extracting("name", "age", "race.name")
                               .contains(tuple("Boromir", 37, "Man"),
                                         tuple("Sam", 38, "Hobbit"),
                                         tuple("Legolas", 1000, "Elf"));

Mocks

Mock significa Imitação. Imagina no caso de estarmos acessando uma base de dados. Você tem duas opções, ou liga a base de dados e testa diretamente nela, ou você mocka o acesso a base. O problema da primeira abordagem é que ela torna o teste mais abrangente. Não estaremos fazendo um Teste Unitário, mas um Teste de Integração.

Não há problema em fazer Testes de Integração, mas eles serão muito mais lentos. Outro problema é que muitas vezes você não precisa testar uma base de dados. Mas as vezes é bom testar a integração, sempre evita um NullPointerException! ☠️

Há algumas boas bibliotecas para Mock, vou falar um pouco do Mockito e PowerMock

Mockito

Mockito serve para criar classes onde o código original pode ou não ser executado.

Quando você quer executar o código original, estamos falando de um spy. O código é executado e você pode validar o que foi feito.

Um Spy pode ser criado usando Mockito.spy ou usando o Jupiter Extension para o JUnit 5.

@Test
@DisplayName("Testa o exemplo de Mock para UserRepository")
public void addUserInMemoryTest() {

    User userWithoutId = new User();
    userWithoutId.setEmail("vepo@vepo.com");
    userWithoutId.setUsername("vepo");

    assertThat(userRepositoryInMemory.add(userWithoutId)).hasFieldOrPropertyWithValue("id", 1L);

    verify(userRepositoryInMemory).add(userWithoutId);
}

Observe que um Spy serve para verificar se o método foi chamado com um valor especifico. Ou seja, precisamos ter uma implementação concreta da classe.

Agora quando falamos de Mocks não precisamos de implementações concretas. Podemos usar em interfaces. Quando é criado um mock, o código real não é chamado, são sempre retornados valores vazios ou nulls. Então é preciso definir o que será retornado e quando.

@Test
@DisplayName("Testa o exemplo de Mock para UserRepository")
public void addUserTest() {
    User userWithoutId = new User();
    userWithoutId.setEmail("vepo@vepo.com");
    userWithoutId.setUsername("vepo");

    User userWithId = new User();
    userWithId.setId(1L);
    userWithId.setEmail("vepo@vepo.com");
    userWithId.setUsername("vepo");

    when(userRepository.add(userWithoutId)).thenReturn(userWithId);

    assertThat(userRepository.add(userWithoutId)).hasFieldOrPropertyWithValue("id", 1L);
}

Cobertura de Testes

As coisas não andam se não tivermos estatísticas! Então para testes, precisamos saber com exatidão qual é a cobertura de testes do nosso projeto. Se não colocarmos isso em prática, muito rapidamente a cobertura irá cair e nem perceberemos.

Uma ferramenta para gerar um relatório de cobertura é o JaCoCo

Para configurar o JaCoCo no Maven, basta adicionar ele como um plugin e configurar quando será executado.

<plugin>
    <groupId>org.jacoco</groupId>
    <artifactId>jacoco-maven-plugin</artifactId>
    <version>0.8.1</version>
    <executions>
        <execution>
            <id>prepare-agent</id>
            <goals>
                <goal>prepare-agent</goal>
            </goals>
        </execution>
        <execution>
            <id>report</id>
            <phase>test</phase>
            <goals>
                <goal>report</goal>
            </goals>
        </execution>
    </executions>
</plugin>

Depois para executar:

mvn clean test jacoco:report

No caso será gerado um relatório. Esse relatório pode ser armazenado no Jenkins ou mesmo usado pela próxima ferramenta que vamos ver.

Code Smells

Antes de partir para última ferramenta, vamos definir uma coisa.

Code Smells são construções que podem trazer má qualidade ao código. Eliminando eles, você pode melhorar a qualidade do seu código.

Análise Estática de Código

Como última ferramenta, vamos falar de Análise Estática de Código. Imagina se você pudesse analisar o seu código e encontrar bugs ou Code Smells. Seria bom, não?

Mas temos isso e de graça. Você pode usar o SonarQube. Com esse plugin para o Maven você pode criar um servidor para armazenar a qualidade atual do seu código e construir uma timeline dele. Assim você pode desafiar o time a reduzir o número de Code Smells em 50%. Ou em aumentar a covertura de testes até um determinado patamar.

Para integrar no Maven, basta colocar:

<plugin>
    <groupId>org.sonarsource.scanner.maven</groupId>
    <artifactId>sonar-maven-plugin</artifactId>
    <version>3.7.0.1746</version>
    <executions>
        <execution>
            <phase>verify</phase>
            <goals>
                <goal>sonar</goal>
            </goals>
        </execution>
    </executions>
</plugin>

Ao adicionar o plugin, crie o projeto no Github e já inicialize ele no SonarCloud. Ao iniciar um projeto, você pode pegar um Token que deve ser usado na build.

mvn -Dsonar.login=<SONAR_TOKEN> verify sonar:sonar

Caso queira rodar o Sonar em projetos internos da sua empresa, você só precisa de um servidor e uma instalação do Sonar. É simples de configurar.

Tudo Junto

Agora vamos responder a última pergunta. Quem vai rodar tudo isso? Você pode configurar algumas ferramentas. Entre elas podemos citar:

Ferramenta	Contexto
Jenkins	Para rodar projetos internos. Não é um serviço cloud.
Github Actions	Excelentes para projetos Github.
TravisCI	Could e facilmente integrado com o Github.

Conclusão

Testes são fundamentais e você não precisa saber fazer antes de começar a desenvolver. MAS... Se você souber criar testes, seu código terá muita estabilidade.

Treine fazer testes. Treine TDD. Conheça as ferramentas e boa sorte!