DEV Community: Aleatório

Como usar Mockito no Quarkus (feat. jUnit)

Aleatório — Tue, 25 Jan 2022 22:55:40 +0000

Nos últimos tempos fiz dois posts topzeira, um falando sobre o que são testes e outro sobre como utilizar a lib do testcontainers para fazer testes de integração. No artigo de hoje, vamos utilizar a biblioteca Mockito para fazer os testes mockeados.

Esse tutorial será dividido em três partes, no primeiro vamos trabalhar com a criação de mocks e controlar o comportamento deles; no segundo vamos utilizar a biblioteca para fazer o retorno dos objetos de forma condicional; e, por fim, vamos conseguir analisar bem o objeto que estamos recebendo para ver se está tudo correto.

Para conseguir esse feito, vamos trazer o mestre do universo, o único que fica lindo de cabelo chanel e tanguinha, aquele que dá os melhores conselhos: He-man.

O que faremos?

Nesse artigo vamos criar um o castelo de GraySkull onde as pessoas querem entrar. Esse castelo tem um porteiro que vai dizer se você entra na entrada VIP ou entrada normal.

O castelo ficará com a seguinte cara.

import javax.enterprise.context.ApplicationScoped;
import javax.inject.Inject;

@ApplicationScoped
public class CasteloDeGraySkull {
  @Inject
  PortaoNormal portaoNormal;

  @Inject
  PortaoVip portaoVip;

  @Inject
  Porteiro porteiro;

  public void entrarNoCastelo(String nome) {
    System.out.println(nome + " está entrando no castelo");
    if(porteiro.identificarSeÉVip(nome)) {
      portaoVip.entrar(nome);
    } else {
      portaoNormal.entrar(nome);
    }
  }
}

E cada portão tem a seguinte forma:

import javax.enterprise.context.ApplicationScoped;

@ApplicationScoped
public class PortaoNormal {
  public void entrar(String nome) {
    System.out.println(nome + " entrou pelo portão normal");
  }
}

import javax.enterprise.context.ApplicationScoped;

@ApplicationScoped
public class PortaoVip {
  public void entrar(String nome) {
    System.out.println(nome + " entrou pelo portão VIP");
  }
}

Agora vem os problemas. Olha só o que aconteceu com o nosso porteiro.


import javax.enterprise.context.ApplicationScoped;


@ApplicationScoped
public class Porteiro {
  public boolean identificarSeÉVip(String nome) {
    throw new RuntimeException("O porteiro faltou!");
  }
}

Isso mesmo, nós não temos a classe do porteiro. Isso pode acontecer por vários motivos. Seja por nós não sabermos as regras ainda ou por não termos implementado. Ou mesmo porque o porteiro depende de alguma aplicação externa que nem sempre vamos poder usar nos nossos testes.

E é nesse ponto que a beleza do Quarkus e dos mocks entram. Nós não precisamos ter o objeto de verdade para seguirmos nossas implementações. Primeiro vamos adicionar a dependência para o Mockito. Fazemos isso adicionando o trecho abaixo entre as tags <dependencies>do arquivo pom.xml.

    <dependency>
      <groupId>io.quarkus</groupId>
      <artifactId>quarkus-junit5</artifactId>
      <scope>test</scope>
    </dependency>

Agora, vamos para a nossa classe de teste que será chamada de CasteloDeGraySkullTest.

import javax.inject.Inject;

import org.junit.jupiter.api.Test;
import org.mockito.Mockito;

import io.quarkus.test.junit.QuarkusTest;
import io.quarkus.test.junit.mockito.InjectMock;

@QuarkusTest //0
public class CasteloDeGraySkullTest {
  @Inject
  CasteloDeGraySkull castelo;

  @InjectMock //1
  Porteiro porteiroMock;

  @Test
  public void testeEntrarNoNormal() {
    castelo.entrarNoCastelo("He-man"); //2
  }

  @Test
  public void testeEntrarNoVip() {
    Mockito.when(porteiroMock.identificarSeÉVip(Mockito.anyString())).thenReturn(true); //3
    castelo.entrarNoCastelo("She-ha");//4
  }
}

Agora vamos analisar o nosso código.

0. A anotação @QuarkusTest indica que os testes usarão a injeção de dependência do Quarkus.
1. Quando usamos a anotação @InjectMock, estamos dizendo que não é para injetarmos a classe verdadeira, porém uma versão mockada dela.
2. Estamos fazendo o teste tendo o comportamento padrão do tipo boolean que é retornar false. Usando o comando mvn test, veremos a seguinte saída:

He-man está entrando no castelo
He-man entrou pelo portão normal

3. Estamos mudando o comportamento do nosso mock. Estamos dizendo que para qualquer string que for passada (Mockito.anyString()) para o método porteiroMock.identificarSeÉVip() deve ser retornado o valor true.
4. Temos o teste com o valor alterado, rodando o teste, teremos a seguinte saída:

She-ha está entrando no castelo
She-ha entrou pelo portão VIP

Considerações

Tentei dividir ao máximo o conteúdo para que todo mundo possa acompanhar sem maiores problemas e entender bem o que houve.
Mockito é uma biblioteca extremamente poderosa e auxilia bastante no desenvolvimento de testes rápidos e eficientes. Espero que todos gostem.

Ah, e o código de hoje pode ser encontrado no github.

E no próximo post, teremos uma participação especial:

Aprendendo sobre testes em Java com as princesas da Disney

Aleatório — Mon, 25 Oct 2021 23:34:16 +0000

"Era uma vez, um jovem Aleatório que achou que existia muitos conteúdos legais sobre testes, mas resolveu adicionar seus dois centavos. O resto da história, vocês verão a seguir..."

O post de hoje será um dos mais legais e mais densos que eu já tive o prazer de fazer. Falaremos sobre um dos assuntos que eu mais gosto que são a̶s̶ ̶p̶r̶i̶n̶c̶e̶s̶a̶s̶ ̶d̶a̶ ̶D̶i̶s̶n̶e̶y̶ os testes. Juro que vou tentar ser o mais sucinto possível, mas conteúdo é tão legal que é capaz que eu me empolgue. Para conseguir me ajudar nessa tarefa, eu trouxe a minha princesa da Disney favorita:

O que é um teste?

No contexto de desenvolvimento, um teste de software consiste em um conjunto de ações que garantem que o software fará o que está se propondo a fazer. As ações realizadas variam de acordo com o projeto, a importância, o tempo disponível, complexidade, etc...

Nesse ponto, trago um revelação: colocar o código em produção para ser utilizado pelos clientes já é um teste. Não é o melhor teste, tem vários riscos, mas acaba acontecendo ;/
Num mundo ideal, nosso sistema tem boa cobertura e conseguimos garantir que a nossa aplicação funcione e encontramos os casos de erro antes dos clientes.

O que testar?

Esse ponto é polêmico e existem pessoas que defendem as mais diferentes opiniões. Alguns vão dizer que é para testar todos os casos possíveis, outros dirão que só precisa pegar os casos representativos, outros dirão que é necessário testar as interfaces, outros dirão que é preciso testar as aplicações usando sistemas reais outros dirão que os sistemas não precisam ser reais e por aí vai...

Como tudo na vida do dev, a resposta é: depende. Depende do tempo, recursos, tamanho do time, conhecimento e importância do seu projeto. No meu caso, eu prefiro testar o fluxo básico (também chamado de caminho feliz) com testes automatizados e alguns fluxos que eu acho que podem ocorrer erros.

Conforme a aplicação é utilizada e os bugs vão sendo encontrados, então adiciono mais e mais testes automatizados que simulem esses erros e essa parte esteja coberta. Afinal, errar é umano, mas tem limites.

Sempre achei que essa abordagem é bom ponto de começo para os testes, trazendo o equilíbrio bom entre o que deve ser testado e os recursos disponíveis.

O que não testar

Existe uma linha muito tênue entre você testar a sua aplicação e testar os frameworks que você está utilizando. O ideal é testar apenas o nosso código. E c̶o̶n̶f̶i̶a̶r̶ assumir que os frameworks estão bem testados e cobertos.

Para exemplificar isso, vamos imaginar um método que recebe uma princesa, verifica se o nome está nulo e salva no banco.

public void salvarPrincesa(Princesa princesa) {
  if(princesa.getNome() == null) {
      throw new RuntimeException("Princesa com nome nulo");
  }
  princesaDao.salvar(princesa);
}

Olhando esse método, você diria que um teste deve verificar se a princesa foi salva no banco?

A resposta é NÃO. Esse método não tem nenhuma relação com banco de dados. Ele lida com uma abstração (o DAO). Logo, um teste deve verificar se o DAO foi chamado. Se o DAO vai realmente salvar no banco, vai colocar em memória ou vai dar uma maçã envenenada para que a princesa durma para todo o sempre, não é problema da nossa regra e negócio. Nossa regra testa apenas nome nulo e passa adiante.

Caso seja necessário fazer um teste que verifica se o método salvar realmente salva no banco ou não, então esse teste deve ser feito em cima da classe PrincesaDao.

Tipos de testes

Da mesma forma que existem vários tipos de princesas, existem vários tipos de testes. E podemos classificar eles de diferentes formas. A lista abaixo traz algumas classificações possíveis.

Automatizados

Nesses testes, todo o processo de análise, execução dos testes e geração de relatórios é feito por um ou mais scripts diferentes. Isso permite que o mesmo teste possa ser repetido várias e várias vezes.

Manuais

Por outro lado, os testes manuais são testes realizados com a interação humana. Nem tudo pode ser validado através de scripts ou o custo de automatizar pode não valer a pena.

Testes funcionais

Esses testes buscam garantir que o sistema faz o que ele se propõe a fazer. Existem várias formas de fazermos esses testes e por isso os testes funcionais são divididos de acordo com a granularidade. A divisão que eu apresento é um pouco diferente do que é visto na litaratura. Normalmente, os testes mockeados ficam em algum limbo entre os testes unitários e os de integração.

Teste unitário

Esses testes são muito legais de fazer porque eles são rápidos, leves e permitem que você consiga cobrir um monte de situação diferente.
Porém, eles duas pegadinhas. A) Muito código que você faz não pode ser testado de forma unitária. Pois ele acaba tendo dependências com objetos externos. B) Existem coisas que você não consegue testar com teste unitário.

Teste mockeado

Uma saída para lidar com os objetos externos é criar um mock. Um objeto de mentirinha que vai reagir da forma que nós queremos e dando os retornos que nós esperamos. As duas principais bibliotecas de mock que nós temos é a Mockito e a Powermock.

Teste de integração

Ao invés de usar um mock para simular os objetos e ambientes externos, por que não usar algo de verdade?
Seguindo a linha dos 12 fatores para desenvolvimento de software, os ambientes de devsenvolvimento e produção devem ser semelhantes. Logo, se a aplicação funcionará usando um banco de dados de verdade, vamos testar usando um banco de dados de verdade.

Teste ponta-à-ponta

Esse é o suprassumo dos testes. Muitas pessoas são contra fazê-los porque eles são caros ou difíceis de serem realizados. Mas esses testes são os mais próximos da realidade.
Nesse tipo de teste levantamentos todos os sistemas e dependências de verdade. Buscando chegar o mais próximo do que é feito no mundo real.

Teste caixa preta

Essa nomenclatura serve mais para dizer que o teste é criado/planejado/executado sem saber as estruturas internas da aplicação.

Teste caixa branca

Ao contrário dos testes caixa-preta, nos testes caixa-branca, os testes são criados já tendo em mente as estruturas internas da aplicação.

Teste de performance

Esses testes buscam descobrir como é o desempenho do sistema em diferentes cenários.

Teste de carga

Visa medir os tempos de resposta e vazões do sistema em diferentes cargas.

Teste de stress

Semelhante a teste anterior em termos de execução, mas totalmente em sua filosofia. Esse teste busca tanto descobrir quais são os limites da aplicação bem como o comportamento do sistema atuando no limite.

Teste de regressão

Consiste em executar todos testes funcionais criados (ou demais testes quando relevante) para garantir que novas mudanças e alterações não introduzam novos erros.

Teste de segurança

Também conhecido com teste de penetração. Geralmente é feito por alguma empresa externa e visa encontrar falhas de segurança tanto no código quanto nos processos executados pela aplicação/empresa.

Teste de usabilidade

Mais focado para aplicações que tem telas, esse tipo de teste consiste em navegar pelas telas feitas (ou por ideias de telas) para verificar se elas atenderão o usuário.

Teste de aceitação

O sonho de consumo de todo o software. Os testes de aceitação vão dizer se o software está pronto ou não para receber o aceite do cliente.

Por que testar?

Qualidade. Fazer testes é o que permite dizer que nossa aplicação funciona ou não. Como vocês viram no outro tópico, existem várias formas de fazer isso.

Dicas gerais de como testar

Caso você seja a Aurora ou Cinderella, você tem uma fada madrinha que te dará uma mão para resolver os problemas. Caso você não seja, você precisa se ajudar.

Separei algumas dicas para trabalhar tanto em ferramentas que podem te ajudar a fazerem bonito nesse baile dos testes.

Faça que os testes rodem de forma rápida

Desenvolver é algo estressante então as coisas precisam ser rápidas. Se cada vez que você precisar rodar os testes, você levar 10 minutos esperando, a tendência é que você pare de testar.
Parando de testar, as coisas começam a dar ruim. Dando ruim, os prazos vão se apertar. Apertando os prazos, você vai tirar o que for menos necessárias para o sistema ir pra produção. Tirando o menos necessário, você tirará os testes e as coisas vão ficando pior. Então é MUITO importante que você consiga fazer com que os testes rodem rápido.

Escreva um código que facilite os testes

Se o seu código não for pensado para testes, quando você for escrevê-los você provavelmente terá dificuldades. Tendo dificuldade para testar, você vai parar de testar. Parando de testar, as coisas começam a dar ruim...

Evite o uso de static

Métodos estáticos como LocalDate.now() ou Objects.isNull() não podem ser mockeados facilmente. Então, se você precisa testar com algum comportamento específico, fica complicado.

Sempre que aparecer um método estático, pense se isso pode afetar os testes. Caso afete, utilize um objeto para encapsular esse método.

Saiba o porque do teste estar ali

Muitas vezes nós fazemos as coisas sem saber bem o que estamos fazendo ou o porquê das coisas. Com isso, nós podemos testar umas 10 vezes a mesma lógica e deixar de testar algo importante. Então, antes de escrever qualquer coisa crie algum tipo de "plano" onde você define o que você quer testar e o motivo desse teste.

Utilize ferramentas para verificar a cobertura de testes

Se nós não conseguimos medir, nós nem podemos dizer se estamos fazendo um bom trabalho (provavelmente, nosso trabalho está ruim).
O JaCoCo é uma ferramenta ótima para dizer como está nossa cobertura. O que estamos esquecendo e o que precisamos melhorar.

Mas não se prenda muito a isso

É importante ter uma boa cobertura de teste. Particularmente, eu acho que 80% para um projeto maduro é um bom número. Existem coisas que simplesmente são caras demais para serem testadas, ou que só não tem motivo para testar.
Além disso, buscar os 100% pode dar a falsa sensação de que você tem todos os casos possíveis mapeados e que nunca vai acontecer um erro. Spoiler: a menos que o seu nome seja Mulan e você esteja lutando contra os Hunos, você vai errar.

Considerações

Esse post foi mais teórico. Nos próximos, vamos ver como fazer testes unitários, mockeados e de integração. Tudo isso trabalhando com Quarkus. Aguardem a continuação /o/

Usando o fault tolerance no Quarkus, porque errar é umano, mas tem limites!

Aleatório — Tue, 18 May 2021 23:46:58 +0000

Encare os fatos, em algum momento a sua aplicação vai falhar.

Porém, não é porque erramos que vamos precisamos chorando em posição fetal por termos falhando. Nós podemos nos recuperar facilmente e o Quarkus nos auxilia nesse processo.

Então, se você souber como errar ou como se recuperar desse erro, a sua aplicação ficará bem. O Quarkus traz uma extensão batuta para lidar com essas situações: a fault tolerance. No post de hoje, vamos conhecer essa extensão.

O que faremos

Vamos construir um microsserviço com alguns endpoints REST. Esses endpoints vão falhar de diferentes formas. Após isso, vamos implementar soluções simples e elegantes para contornar essas falhas.

É hora da ação

Vamos começar indo no code.quarkus.io, selecionar a extensão SmallRye Fault Tolerance, mandar baixar com código de exemplo. Isso criará um serviço rest bem simples que retornará uma String de hello. Vamos mudar um pouco a classe criada e criando alguns endpoints que simularão diferentes situações de erro e que nós iremos tratar. O código com essas situações ficará assim:

package org.acme;

import javax.ws.rs.GET;
import javax.ws.rs.Path;

import java.time.LocalDateTime;

@Path("/")
public class ExampleResource {
  int contador = 0;

  @GET
  @Path("/timeout")
  public String helloComTimeout() throws Exception {
      return tentativaComSleep();
  }

  String tentativaComSleep() throws Exception {
    Thread.sleep(5_000);
    return "hello com timeout";
  }

  @GET
  @Path("/retries")
  public String helloComRetry() throws Exception {
    tentativaComRetentativas();
    return "hello com retry";
  }

  private void tentativaComRetentativas() {
    contador++;
    System.out.println("Tentativa número: " + contador + " às " + LocalDateTime.now());
    throw new RuntimeException();
  }

  @GET
  @Path("/fallback")
  public String helloComFallback() throws Exception {
    return tentativaComFallback();
  }

  String tentativaComFallback() {
    throw new RuntimeException();
  }  
}

Criamos 3 endpoints. O primeiro responde, porém demora algum tempo para isso, o segundo e o terceiro não conseguem responder por causa de alguma exceção. Agora nós vamos contornar essas situações com o suporte da nossa biblioteca de tolerância a falhas.

Timeout

A condição de timeout é ativada quando o sistema demora tempo demais para responder.
O contorno dela se baseia em criar uma thread para ficar monitorando o tempo de início de execução e estourar uma exception caso esse tempo seja excedido.

Porém, não precisamos escrever muito para ter tudo isso.
Basta adicionar a anotação @Timeout com o tempo limite que nós queremos. Caso o método não complete a operação a tempo, será lançada uma exceção do tipo TimeoutException.

Depois disso é só será tratar essa exceção com o comportamento que desejado. Dessa forma, o Quarkus controla toda essa parte de controle de tempo, threads, etc...

Alterando o código da requisição, ficará assim:


  @GET
  @Path("/timeout")
  public String helloComTimeout() throws Exception {
    try {
      return tentativaComSleep();
    } catch (TimeoutException e) {
      return "Tentativa com timeout tratado, seu serviço responderá rápido";
    }
  }

  @Timeout(value = 2000)
  private String tentativaComSleep() throws Exception {
    Thread.sleep(5_000);
    return "hello com timeout";
  }

Nosso código passará a responder mais rápido (ainda que seja com um comportamento diferente), fazendo com que a experiência do usuário seja mais suave.

Retentativas

Às vezes, o problema pode não ser que o serviço demore demais para responder, talvez o problema pode ser resolvido se nós tentarmos novamente algum tempo depois.

Com a anotação @Retry, caso ocorra alguma exceção, a aplicação tentará executar o mesmo código várias vezes (até um limite estabelecido). Caso não consiga executar, daí então é que ela vai realmente estourar a exceção. O código com a retentativa fica assim:


  @Retry(maxRetries = 5)
  void tentativaComException() {
    contador++;
    System.out.println("Tentativa número: " + contador + " às " + LocalDateTime.now());
    throw new RuntimeException();
  }

O nosso código ainda retornará exceção, porém, se formos no log veremos as vezes que o sistema tentou executar o método.

Tentativa número: 1 às 2021-05-18T10:24:37.996164
Tentativa número: 2 às 2021-05-18T10:24:38.000239
Tentativa número: 3 às 2021-05-18T10:24:38.101461
Tentativa número: 4 às 2021-05-18T10:24:38.292833
Tentativa número: 5 às 2021-05-18T10:24:38.338367
Tentativa número: 6 às 2021-05-18T10:24:38.338657

Notem que só por ter essa anotação, nós ganhamos o comportamento das retentativas e também temos vários tipos de controle como o tempo entre retentativas, o tempo máximo para fazer toda a operação, para quais exceções terá rentativa, etc...

Fallback

O método de fallback é o método que é chamado no caso de uma exceção. Se na retentativa o sistema executava várias vezes o mesmo método, com o fallback será executado alguma outra lógica. Podemos pensar nele como uma forma mais limpa de fazer um try/catch. O código com alterado fica assim:

  @Fallback(fallbackMethod = "tratamentoComFallback")
  String tentativaComFallback() {
    throw new RuntimeException();
  }

  String tratamentoComFallback() {
    return "Hello com fallback tratado";
  }

Executando o código, o retorno será:

É importante que o método de fallback tenha a mesma assinatura do método inicial ou dará ruim.

Outra coisa bem parte legal do método de fallback é que ele trabalha muito bem com as outras anotações. Dessa forma você pode retentar fazer uma operação e, caso não consiga ou demore muito tempo, o método de fallback é executado. Fica topzeira.

Por fim, existe um ponto de enorme atenção a todos. Os métodos com essas anotações não serão processados se o escopo do método for privado. Então muita atenção nesse ponto.

Considerações finais

Fiquei bem feliz em conseguir voltar a escrever sobre Quarkus, principalmente por falar sobre essa extensão que tem sido uma mão na roda nas últimas semanas. Num post futuro, quero falar sobre circuit breaker.

Espero que cada vez mais as pessoas possam usar e se apaixonar por essa tecnologia incrível.
Ah, e o código de hoje pode ser encontrado no github.

Configurando tratamento de erros no kafka com Quarkus

Aleatório — Fri, 05 Mar 2021 00:13:48 +0000

Java é lindo. Quarkus é lindo. [Franz] Kafka é lindo. Porém, nem tudo são flores no desenvolvimento. Acidentes acontecem e é importante conseguirmos nos preparar para eles. Hoje, nós vamos ver sobre os diferentes tipos de tratamento de exceção durante o consumo de uma mensagem Kafka pelo Quarkus.

Já vou assumir que você sabe o que é o Kafka, já manja um pouco de Quarkus e tem tudo configurado. Caso não seja o seu caso, tenho um artigo infinitop para ajudar.

O Quarkus possui 3 formas diferentes para tratar uma exceção quando no método com a anotação @Incoming: Parar de consumir mensagens, ignorar e DLQ (dead-letter queue).

Parar de consumir mensagens

Esse é o tratamento padrão. O serviço continuará funcionando normalmente. Porém, as mensagens não serão mais consumidas até que alguém intervenha na mensagem, resolva o que precisar ser resolvido e então reinicie o serviço.

Caso nada tenha sido configurado, será utilizado essa opção.

Ignorar

Nesse modo, caso ocorra alguma exceção, o Quarkus diz pro Kafka que conseguiu consumir corretamente a mensagem e finge que o erro nunca existiu.

Para configurar é muito simples. Basta adicionar o seguinte trecho no application.properties:

mp.messaging.incoming.<nome do canal>.failure-strategy=ignore

Dead-letter queue

Nesse modo, quando ocorre uma exceção, o Quarkus ainda irá informar ao Kafka que a mensagem foi consumida, porém, irá enviar a mensagem para uma fila especial onde essas mensagens poderão ser consumidas num momento oportuno.

Essa é a configuração que tem mais opções, mas é bem simples de entender:

mp.messaging.incoming.<nome do canal>.failure-strategy=dead-letter-queue
mp.messaging.incoming.<nome do canal>.dead-letter-queue.topic=<nome do tópico de DLQ>
mp.messaging.incoming.<nome do canal>.dead-letter-queue.key.serializer=<caminho para o serializador da chave>
mp.messaging.incoming.<nome do canal>.dead-letter-queue.value.serializer=<caminho para o serializador do valor da mensagem>

Por padrão, o nome do tópico será o "dead-letter-topic-" + nome do canal. Além disso, o Quarkus tentará supor o caminho para o serializador. É possível seguir o palpite dele, ou configurar manualmente. O destino está nas suas mãos.

Uma outra observação importante é que, se o tópico de DLQ não existe, então o Quarkus irá criar um novo tópico com as configurações padrões do Kafka (o que pode não ser a melhor abordagem possível).

Considerações finais

Esse é um assunto bem interessante e que eu queria ter colocado lá no outro post. Porém, achei que ficaria muita coisa.

Foi estranho fazer um post sem código, mas espero que tenham gostado!

Quarkus e TestContainers o Pikachu dos ambientes de testes

Aleatório — Mon, 08 Feb 2021 15:15:13 +0000

Me considero uma pessoa que pensa no bem comum e em ajudar o próximo. Por exemplo, caso eu encontrasse um gênio que me desse direito a um único desejo, eu escolheria que os pokémons existissem no mundo real. Porém, se ele me desse direito a um segundo desejo, eu escolheria que todos os desenvolvedores soubessem usar os test containers.

O que é?

O Testcontainers é uma biblioteca Java que permite subir instâncias docker durantes o ciclo de testes. Com essas instâncias, é possível ter acesso ao banco de dados, sistema de mensageria, cache, etc...

Mas é importante ter atenção pra algo muito importante:
É NECESSÁRIO TER O DOCKER INSTALADO NA MÁQUINA QUE FOR RODAR OS TESTES.

O que faremos?

O teste de hoje será um pouco mais elaborado. Vamos usar o que nós já aprendemos sobre banco de dados e mensageria. Vamos criar uma classe que cria um Pokémon e armazena ele no c̶i̶n̶t̶o̶ ̶d̶e̶ ̶p̶o̶k̶e̶b̶ó̶l̶a̶s̶ banco de dados.
Após isso, será disparado um evento ao kafka onde um treinador rival irá batalhar e nós recuperaremos o nosso pokémon para a batalha.

Hora da ação

Primeiramente vamos configurar nosso ambiente com as dependências necessárias. Por isso, é necessário adicionar a seguinte configuração no nosso pom.xml. Essas extensões configuram o conector de mensagens Kafka, a comunicação com banco de dados (via Panache) e o Test Containers.

    <dependency>
      <groupId>io.quarkus</groupId>
      <artifactId>quarkus-smallrye-reactive-messaging-kafka</artifactId>
    </dependency>
    <dependency>
      <groupId>io.quarkus</groupId>
      <artifactId>quarkus-jdbc-postgresql</artifactId>
    </dependency>
    <dependency>
      <groupId>io.quarkus</groupId>
      <artifactId>quarkus-hibernate-orm-panache</artifactId>
    </dependency>
    <dependency>
      <groupId>org.testcontainers</groupId>
      <artifactId>testcontainers</artifactId>
      <version>1.15.1</version>
      <scope>test</scope>
    </dependency>
    <dependency>
      <groupId>org.testcontainers</groupId>
      <artifactId>kafka</artifactId>
      <version>1.15.1</version>
      <scope>test</scope>
    </dependency>

Segundamente, vamos criar nossa classe de Pokémon. Ela é bem simples, tem o nome e o número dele. Isso é feito através da classe abaixo:

package org.acme;

import javax.persistence.Entity;

import io.quarkus.hibernate.orm.panache.PanacheEntity;

@Entity
public class Pokemon extends PanacheEntity{
  private int codigo;
  private String nome;

  public Pokemon() {
  }

  public Pokemon(int codigo, String nome) {
    this.codigo = codigo;
    this.nome = nome;
  }

  public int getCodigo() {
    return codigo;
  }

  public String getNome() {
    return nome;
  }

}

Agora vamos fazer nosso gerador de batalhas. Ao receber uma mensagem de que um treinador rival quer entrar em batalha (recebendo o nome do treinador), ele gravará no log o nome do treinador, pegará o primeiro pokémon disponível no banco de dados e gravará no log o nome desse pokémon. O código da batalha está baixo.

package org.acme;

import javax.enterprise.context.ApplicationScoped;
import javax.transaction.Transactional;

import org.eclipse.microprofile.reactive.messaging.Incoming;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

import io.smallrye.reactive.messaging.annotations.Blocking;

@ApplicationScoped
public class GeradorDeBatalha {
  private static final int PRIMEIRO_ELEMENTO = 0;
  Logger logger = LoggerFactory.getLogger(getClass());

  @Incoming("novo-combate")
  @Blocking
  @Transactional
  public void iniciarCombate(String nomeDoTreinador) {
    logger.info("O treinador [{}] quer iniciar um combate", nomeDoTreinador);
    Pokemon pokemon = (Pokemon) Pokemon.listAll().get(PRIMEIRO_ELEMENTO);
    logger.info("[{}], eu escolho você!", pokemon.getNome());
  }
}

Vamos fazer o nosso teste. Por fins didáticos, não fazemos nenhum tipo de asserção sobre ele, apenas olhando
o logo impresso. Como são threads diferentes que irão fazer o processamento (uma thread vai emitir a mensagem de batalha e a outra vai consumir), nós precisamos dar um tempo na nossa thread de teste para que a outra faça o seu trabalho.

O código para testes é esse aqui:

package org.acme;

import javax.inject.Inject;
import javax.transaction.Transactional;

import org.eclipse.microprofile.reactive.messaging.Channel;
import org.eclipse.microprofile.reactive.messaging.Emitter;
import org.junit.jupiter.api.BeforeEach;
import org.junit.jupiter.api.Test;

import io.quarkus.test.common.QuarkusTestResource;
import io.quarkus.test.junit.QuarkusTest;

@QuarkusTest
@QuarkusTestResource(Dependencias.class)
public class BatalhaTest {
  @Channel("iniciar-combate")
  @Inject
  Emitter<String> emissor;

  @BeforeEach
  @Transactional
  public void cadastrarPokemon() {
    Pokemon pokemon = new Pokemon(25, "Pikachu");
    pokemon.persist();
  }

  @Test
  public void combateSimples() throws Exception {
    emissor.send("Gary Carvalho");
    Thread.sleep(1_000);
  }
}

Feito isso, vamos configurar o application.properties com o banco de dados, um consumidor e um emissor de mensagens de combate (esse emissor será usado só para os testes).

quarkus.datasource.db-kind = postgresql
quarkus.datasource.username = ash
quarkus.datasource.password = pallet
quarkus.datasource.jdbc.url = jdbc:postgresql://localhost:5432/pokemon

quarkus.hibernate-orm.database.generation = update


mp.messaging.incoming.novo-combate.connector=smallrye-kafka
mp.messaging.incoming.novo-combate.topic=novo-combate
mp.messaging.incoming.novo-combate.value.deserializer=org.apache.kafka.common.serialization.StringDeserializer

%test.mp.messaging.outgoing.iniciar-combate.connector=smallrye-kafka
%test.mp.messaging.outgoing.iniciar-combate.topic=novo-combate
%test.mp.messaging.outgoing.iniciar-combate.value.serializer=org.apache.kafka.common.serialization.StringSerializer

Caso tenha ficado alguma dúvida sobre o funcionamento da parte de configuração, tem dois posts topzeiras aqui e aqui.

Tudo certo né? Agora é só mandar o maven testar e podemos ser felizes. Certo? Errado!

Como não existe nem o banco de dados rodando e nem o kafka, a aplicação nem subirá direito.

Para que a aplicação suba corretamente, é necessário fazer as dependências rodarem e é aqui que os tests containers entram.

Nós já configuramos eles, agora basta criarmos os containers para testes. Isso pode ser feito através da classe abaixo.

package org.acme;

import java.util.HashMap;
import java.util.Map;

import org.testcontainers.containers.GenericContainer;
import org.testcontainers.containers.KafkaContainer;
import org.testcontainers.utility.DockerImageName;

import io.quarkus.test.common.QuarkusTestResourceLifecycleManager;

public class Dependencias implements QuarkusTestResourceLifecycleManager {
  private final KafkaContainer kafka = new KafkaContainer(DockerImageName.parse("confluentinc/cp-kafka")); //0

  private static final DockerImageName POSTGRES_IMAGE = DockerImageName.parse("postgres:12-alpine"); // 1
  private GenericContainer<?> postgresContainer = new GenericContainer<>(POSTGRES_IMAGE); //2

  public Map<String, String> start() {
    postgresContainer.withEnv("POSTGRES_USER", "usuario")// 3
        .withEnv("POSTGRES_PASSWORD", "senha")
        .withExposedPorts(5432)// 4
        .withEnv("POSTGRES_DB", "bancoDeDados"); // 5
    postgresContainer.start();//6

    kafka.start();//7

    Map<String, String> properties = new HashMap<>();
    properties.put("quarkus.datasource.username", "usuario"); //8
    properties.put("quarkus.datasource.password", "senha");
    properties.put("quarkus.datasource.jdbc.url",//
        "jdbc:postgresql://"+ postgresContainer.getHost() +":" + postgresContainer.getFirstMappedPort() + "/bancoDeDados");//9
    properties.put("kafka.bootstrap.servers", kafka.getBootstrapServers());//10

    return properties;
  }

  public void stop() {
  }
}

Essa é a classe que cria os containers. Vamos entender o que ela faz?

0 - Container kafka que já tem tudo pré-configurado (ter um container desses é muito útil)
1 - Imagem docker para a utilização de um container genérico
2 - Container genérico, onde vamos configurar os valores para fazer nossos testes
3 - Configuração do usuário
4 - Configuração da senha
5 - Configuração do banco (notem que é uma boa prática usar valores diferentes dos que estão no application.properties)
6 - Expondo a porta interna 5432 (o testContainers poderá mapear essa porta interna para alguma outra porta externa)
7 - Iniciando o container postgres
8 - Iniciando o container kafka
9 - Atualizando as configurações que serão utilizadas durante o teste
10 - Na falta de um container específico, as configurações ficam assim e isso pode gerar erros
11 - Utilização de propriedade com container específico
12 - Retornando as propriedades

E nós só precisamos de mais um passo que é informar para a nossa classe de teste de que é para ele utilizar o nosso recurso de teste. Isso é feito colocando a anotação de classe
@QuarkusTestResource(Dependencias.class).

Agora sim é só rodar a nossa aplicação com o mvn test e correr pro abraço.

2021-02-08 12:08:14,720 INFO  [org.acm.GeradorDeBatalha_Subclass] (vert.x-worker-thread-1) O treinador [Gary Carvalho] quer iniciar um combate
2021-02-08 12:08:14,811 INFO  [org.acm.GeradorDeBatalha_Subclass] (vert.x-worker-thread-1) [Pikachu], eu escolho você!

Considerações

Fiz um resumão super resumido sobre os tests containers e Quarkus. Tem bastante coisa pra falar e espero fazer mais posts sobre isso. Outra coisa interessante é que notei que boa parte dos meus textos são sobre testes e estou feliz com isso. Um mundo com mais testes, é um mundo mais feliz.

Ah, e o código de hoje pode ser encontrado no github.

Alterando o perfil de configuração do Quarkus

Aleatório — Wed, 03 Feb 2021 01:06:48 +0000

Num post passado, nós já vimos bastante sobre como injetar configurações no Quarkus. Mas a parte de configuração do Quarkus é tão linda que deveria ser exposto num museu como o Louvre e dá vontade de falar bastante sobre ela. No post de hoje, nós vamos ver como alterar o Perfil de configuração.

O que é esse tal de perfil de configuração?

Se você já leu o outro post e entendeu o que são os perfis de configuração, pode passar pro próximo tópico. Se você não leu e não vai ler, não se preocupe vou explicar de novo porque o̶ ̶e̶d̶i̶t̶o̶r̶ ̶m̶e̶ ̶o̶b̶r̶i̶g̶o̶u̶ ̶a̶ ̶t̶e̶r̶ ̶u̶m̶ ̶n̶ú̶m̶e̶r̶o̶ ̶m̶í̶n̶i̶m̶o̶ ̶d̶e̶ ̶p̶a̶l̶a̶v̶r̶a̶s̶ ̶n̶o̶ ̶p̶o̶s̶t̶ eu gosto muito de você <3

O que faremos

Vamos reutilizar a classe ConfigResource do post sobre @ConfigProperty (é sério, vai lá, é um post bem legal), mas vamos adicionar configurações para serem utilizadas no ambiente de QA (que é um perfil diferente de test, prod ou dev). Depois disso, vamos chamar a nossa aplicação com o perfil de QA e vamos ver a magia acontecer.

Hora da ação

Após pegar o de exemplo de configuração lá no github, nós vamos rodá-lo através do comando

mvn quarkus:dev

e acessar a página de configuração /config para ver as configurações salvas.

Nisso, vamos ter o seguinte resultado:

Agora, vamos alterar o arquivo application.properties e adicionar o seguinte trecho:

%test.config=Configuração simples de teste
%qa.config=Configuração simples de QA
%dev.config=Configuração simples em dev

Com isso, nós mudamos o valor da configuração para diferentes perfis. Quando estamos usando o quarkus:dev, nós estamos com o perfil de dev. Se nós atualizarmos a nossa página, nós já vamos ver uma mensagem diferente:

Se fosse em produção (ou em teste, o resultado seria diferente). Aproveite para testar e ver a magia acontecer.

Usando um perfil não padrão

Além de termos adicionado opções para perfis de teste e de desenvolvimento, nós também adicionamos um perfil de QA. Mas fica a dúvida, como fazer para ativar esse perfil?

Para fazer isso, basta passar a configuração -Dquarkus.profile.

Para rodar com o perfil de QA, basta usar o seguinte código

mvn quarkus:dev -Dprofile=QA

Com isso, o restultado final será:

Considerações

Cada vez mais, gosto desse processo de compartilhar conhecimento e esse foi o meu primeiro post para adicionar algo que eu já falei num post passado. Estou todo bobo :3

Também aproveitei pra fazer algo mais simples e direto. Espero que tenham gostado.

Ah, e o código de hoje pode ser encontrado no github.

Boas práticas para usar o git

Aleatório — Tue, 05 Jan 2021 13:44:10 +0000

Seja bem vindo a mais uma ~gentil~ introdução ao git. Chegamos ao nosso último post e vamos ver sobre algumas boas práticas para utilizar o git.
Caso você queira saber sobre tudo o que nós falamos até agora, basta olhar esse mapa maroto:

O que é o GIT e como usar
Principais comandos do git
Como fazer um rebase de presença
Como escrever um README.md
Boas práticas para utilizar o git ⟵ você está aqui

Dicas Gerais

Conhecer bem o git

O git é uma ferramenta ótima. Porém, como já vimos, ele tem comando pra caramba. Não tô dizendo para vocês virarem especialistas no git, mas é importante conhecer bem os comandos, entender como funciona a árvore de commits, saber fazer bem um rebase, saber ler um reflog, entender os diferentes tipos de merge, etc...

Saber usar a linha de comando

As ferramentas gráficas para git são bem interessantes e ajudam bastante. Mas tem muitas coisas que só dá para fazer corretamente pela linha de comando. O quanto antes aprender a mexer no git pela linha de comando, melhor.

Siga padrões

É extremanete importante que todos os colaboradores falem a mesma língua, escrevam commits da mesma forma e sigam o mesmo fluxo de trabalho. Se não, fica praticamente impossível restrear qualquer coisa no git.

Usar sempre o mesmo idioma

Ainda na linha de padrões, é necessário usar o mesmo idioma.

Configurar corretamente a autoria

A autoria permite saber quem exatamente fez cada commit (o famoso git blame). É bem simples, basta usar os seguintes comandos:

git config --global user.name "Seu nome"
git config --global user.email seu_email@exemplo.com

Usar um repositório por projeto

A menos que tenham pessoas que sabem o que estão fazendo para trabalhar como um projeto mono repo, utilize um repositório por projeto. Várias aplicações por projeto é a receita para o caos e confusão.

Ter um workflow (e fazer as pessoas seguirem)

Adicionar um pipeline de CD

Use boas ferramentas

O git sozinho já é ótimo e existem algumas ferramentas que podem ajudar bastante em atividades específicas (visualizar a árvore de commits, fazer o blame automático enquanto você escreve o código, ajudar a ver os conflito, etc...).

Particularmente, eu uso o VSCode para resolver conflitos (com o plugin do gitlens) e o tig para ver a árvore. Vejo muita gente usando o git kraken, mas nunca usei.

Usar repositórios de template

O Github tem uma ferramenta ótima q̶u̶e̶ ̶d̶e̶v̶e̶r̶i̶a̶ ̶s̶e̶r̶ ̶c̶o̶p̶i̶a̶d̶a̶ ̶p̶e̶l̶o̶ ̶b̶i̶t̶b̶u̶c̶k̶e̶t̶ para quem trabalha com vários projetos que é criar um template de repositório com todas as coisas corretamente configuradas. Isso acelera muito o processo de desenvolvimento

Dicas para bons commits

Anotar a issue

Via de regra, você trabalhará com algum sistema de gestão de atividades/issues/tickets integrado com o seu git. No footer de cada commit, basta indicar a commit issue o commit se refere. Isso adiciona mais rastreabilidade no que foi feito e permite indica o caminho de documentações que não cabem dentro de uma mensagem de commit

Considerar os commits como documentação

Para muitas empresas, os commits não representam nada em relação ao código. Porém, ele é uma boa fonte de documentação histórica do código.

Escrever o que foi feito, o que não foi feito e porque

No uma boa mensagem de commit tem o que foi feito, o porque foi feito e o que tentou fazer mas não deu certo (claro que dentro do bom senso, afinal, nem todos os commits carregam esse peso).

Usar título

A primeira linha de um commit serve como título. É ela quem aparecerá dentro das ferramentas e na hora de ler o log. Por isso é importante uma descrição simples do que aquele commit representa (de preferência com menos de 80 caracteres)

Dicas para bons Pull Requests

Fazer vários commits, porém fazer o rebase

Uma das funções do git é servir de backup remoto. Você pode fazer commits diretos com as tentativas de arrumar um problema, ou mesmo fazer commits todos os dias. Na hora do PR, é só juntar as alterações feitas, descartar o lixo e fazer um ou mais commits relevantes.
O mesmo serve para a revisão de código de um PR. Basta ir fazendo as alterações necessárias e depois fazer um rebase para unir tudo com o commit principal. Isso gera uma árvore limpa e fácil de navegar.

Quando fazer o PR, já adicionar os testes

Sempre que possível, já adicione os testes dentro do PR. Além de ajudar a entender melhor o que foi feito, garante que a cobertura de testes do sistema permanecerá alta.

Fazer PR apenas de coisas relacionadas

Se você adicionou uma funcionalidade, abre um PR para isso e só isso. Não é para colocar formatação de arquivo ou outras coisas nesse PR.

Não integrar código comentado

O git já consegue manter o histórico de tudo o que foi feito. Se você seguir boas práticas, não há necessidade para fazer PR com código comentado

Dicas para ter uma boa árvore

Evitar de reescrever a história da Master

Aqui estou falando de qualquer branch que mais de uma pessoa utiliza. Quando rola rebases, é possível que o trabalho de um acabe prejudicando o de outro.

Manter o repositório local atualizado (de preferência com rebase)

É só ficar fazendo git fetch --all e git rebase origin/<nome da branch principal> que você vai manter a sua árvore sempre atualizada e isso evita maiores dores de cabeça na hora de criar o PR.

Abrir branchs

Se você trabalha com outras pessoas, não é bom trabalhar diretamente na branch principal. É p̶r̶o̶v̶á̶v̶e̶l̶ possível que alguém acabe fazendo um rebase que não deve ou algo assim. Por isso é bom sempre abrir uma branch, fazer suas alterações e então mergear via pull request.

Proteger a master

Acidentes acontecem, por isso é importante impedir as pessoas de fazerem pushs direto na master ou develop. Isso é feito através da configuração do repositório.

Não comitar grandes arquivos binários

O git funciona muito bem para arquivos de textos e pequenos binários (coisa de alguns KB). No momento que você começa a colocar arquivos maiores, começa o diretório .git começa a dar ruim (principalmente se você mexer muito nesse arquivo)

Usar um bom .gitignore

Um bom .gitiginore ajuda a evitar o envio de arquivos binários. Eu Eu gosto bastante o do gitiginore.io.

Como escrever um bom README.md

Aleatório — Mon, 28 Dec 2020 00:50:46 +0000

Fala galerinha do barulho, prontos para se meterem em um monte de confusão enquanto seguimos desbravando como funciona o git?

Pra você não se perder, segue o nossa mapa maroto:

O que é o GIT e como usar
Principais comandos do git
Como fazer um rebase de presença
Como escrever um README.md ⟵ você está aqui
Boas práticas para utilizar o git

Já aprendemos o que é o git, já aprendemos quais são os principais comandos e até aprendemos conquistar pessoas nas baladas da vida usando o rebase.
No episódio de hoje, nós vamos dar um passo além na nossa jornada e aprender a fazer um documento README topzeira.

O que é o README?

É um documento do tipo markdown (que é tipo um html simplificado) que descreve informações importantes sobre o seu projeto. Esse artigo explica bem como faz para escrever um markdown. Nós vamos nos focar mais no conteúdo e menos nesses detalhes de tags.

Logo abaixo, nós teremos quais sessões devem ter nesse documento de descrição (incluindo quais sessões são opcionais) para você colocar no seu projeto do git.

Nome do projeto

A primeira parte do projeto é para ser o nome do projeto. Com uma tag de título (#). Eu sei que quem for ler consegue ler o nome na URL, mas a ideia é simplificar a vida de quem está lendo tudo.

Opcional: Logo, Badges

Sem tags de título, aqui nós colocamos qualquer badge que possa ser interessante para o projeto (status do jenkins, número de vezes que o projeto foi clonado, estrelas no github, etc...). Também vamos colocar logo e as coisas que identifiquem graficamente o projeto.

Opcional: Status do projeto caso ele já esteja morto

Ninguém é obrigado a dar manuntenção num projeto para sempre. Caso você tenha decidido deixar o projeto de lado ou não consiga mais contribuir mais com ele é importante deixar claro aos demais que não haverá mais atualizações.
Isso evita bastante frustração para as partes envolvidas.

Descrição do projeto (em um parágrafo)

Também sem tag, aqui é o momento de explicar sucintamente o que o projeto faz. O ideal é que não passe de um parágrafo.

Como rodar

Todo o sistema tem pré requisitos para rodar (o menor deles é você ter um computador). Essa sessão serve para explicar o que o usuário precisa para baixar/instalar/rodar o sistema.
Caso o sistema tenha as dependências em docker, é importante colocar o docker-compose.yml e linká-lo aqui.

Como testar

Tão importante quanto rodar a aplicação é fazer a rotina de testes. Aqui é explicado como a aplicação é testada, se é necessário levantar alguma dependência para os testes ou mesmo se existe a̶l̶g̶u̶m̶a̶ ̶m̶a̶g̶i̶a̶ algum comando especial para executar os testes.

Propriedades/variáveis de ambiente

Como falei lá no post sobre configuração. "Não tem jeito. Inevitavelmente um software precisa de algum tipo de configuração. Seja as credenciais de acesso ao banco de dados, o endereço de algum serviço externo, regras de log, etc..."
Essa sessão, serve para explicar quais são as principais propriedades do sistema, para o que elas servem e como/onde alterar.

Opcional: como contribuir/como ajudar

Se o projeto é um software livre, então é muito importante explicar para as pessoas como elas podem ajudar.
Esse espaço também serve para você deixar links de doação.

Opcional: Acknowledgements ou Agradecimentos

Esse espaço serve exclusivamente para os desenvolvedores se promoverem. Caso alguém esteja realmente interessado em saber quem trabalhou no projeto, a pessoa consegue ir no histórico de commits.
Particularmente, considero um desperdício de espaço.

Dicas gerais

Essas dicas foram testadas no github, mas os demais serviços devem ter soluções parecidas.

Não usar changelog/releases no README.md

É possível usar a aba releases do github para colocar o histórico de alterações. Fica mais limpo.
Também é possível criar um arquivo chamado CHANGELOG.md para as alterações sem a necessidade de ficar poluindo o README.md.

Não usar link para licença

Você pode colocar o conteúdo da licença num arquivo LICENSE.txt que o github vai entender qual licença é.

Usar template de repositório

Caso você precise fazer vários projetos. Você pode criar um template para servir de modelo e ir seguindo ele.

Como fazer um rebase de presença

Aleatório — Sun, 20 Dec 2020 15:59:17 +0000

Seja bem vindo a mais uma ~gentil~ introdução ao git. Hoje, nós vamos aprender a como fazer um rebase de presença e deixar a nossa árvora de commits um pitelzinho.

Antes de começar, vamos lembrar do nosso planejamento de posts:

O que é o GIT e como usar
Principais comandos do git
Como fazer um rebase de presença ⟵ você está aqui
Como escrever um README.md
Boas práticas para utilizar o git

Porque essa é uma introdução bem gentil, vamos dividir o conteúdo sobre nosso rebase em algumas partes. O que é uma branch? O que é um rebase e como ele funciona? Quais são as opções de um rebase interativo? Um pequeno exemplo de como fazer um rebase para conquistar o coração daquele pichadão/tchutchuca que tá te filmando e quer ser seu namorado.

O que é uma branch?

Quando nós fazemos um commit, git cria um objeto que indica quais mudanças foram feitas. Esse objeto tem um monte de informação interessante como autor, horário, hash e os pais do commit.

Uma branch é, apenas, um ponteiro para algum desses commits. Ao fazer um commit, é adicionado um novo nó nessa árvore e o ponteiro é deslocado para esse novo nó. E quandos nós criamos uma nova branch, nós estamos apenas criando um novo ponteiro apontando para aquele commit. A imagem abaixo mostra isso.

Temos três commits, 98ca9, 34ac2 e f30ab. Inicialmente, tínhamos uma única branch (master) apontando para o commit f360ab. Após o comando git checkout -b testing criamos a branch testing que também aponta para o mesmo local.

Se nós estivermos na branch testing e fizemos um commit (vamos chamar de 87ab2), a testing irá apontar para esse novo commit, enquanto a branch master continuará apontando para o f30ab.

Além disso, existe ponteiro especial chamado HEAD que aponta para a branch que nós estamos trabalhando. O movimento desse ponteiro poderá alterar os arquivos nós estamos vendo no nosso diretório de trabalho. E nós movimentamos o HEAD através do comando git checkout <hash do commit ou nome da branch>

Na imagem abaixo, reunimos tudo o que vimos até agora. As branchs master e testing (com seus commits) e o ponteiro HEAD.

Num outro post nós vimos o funcionamento do checkout. Agora nós conseguimos entender melhor o que ele faz. Ao usar o checkout, nós estamos movimentando a HEAD. É possível movimentar tanto entre branchs quanto entre commits. Quando fazemos essa movimentação, o git pode alterar, adicionar ou remover arquivos. E o git sabe sempre como se achar porque dentro do objeto dos commits tem todas as informações importantes para ele trabalhar fazer o que precisa ser feito.

Na imagem abaixo, nós fizemos um git checkout master e fomos para a branch master. Depois disso, criamos um novo commit (c2b9e). Desse ponto em diante, as duas branchs começam a divergir e terão um ancestral comum (f30ab).

Agora vem a parte mágica.

O que é um rebase e como ele funciona?

A operação de rebase reaplica os commits já feitos em um árvore à partir de um determinado commit ou de uma determinada branch.

Na sua versão mais básica um rebase pode ser utilizado para sincronizar duas branchs (como o git merge) com a diferença que, enquanto o git merge gera um novo commit unindo as duas branchs. O rebase aplica todos os commits novos em cima dos commits já existentes de uma branch.

Vamos deixar os exemplos acima de lado e vamos trabalhar com um exemplo mais simplificado ainda (que tem uma pequena mentirinha explicada melhor no fim desse post). Aqui temos duas branchs (master e testing) e elas tem um ansestral e comum (commit E).

          A---B---C testing
         /
    D---E---F---G master

Se nós estivermos na branch testing e fizermos o comando

git rebase master

A árvore da branch testing ficará*:

D---E---F---G---A---B---C

Isso é, o git pegou todo o conteúdo branch master e, depois dele, colocou o conteúdo da branch testing.

Um detalhe importante é que se passarmos uma branch ao invés de um commit como parâmetro para o git rebase, então o commit considerado será o commit do topo daquele rebase.

Na sua forma super-ultra-plus-master-advanced, o rebase vira o rebase interativo. Nessa forma, podemos fazer alterações nos commits antes de aplicarmos eles. Vamos ver algo essas alterações.

Quais são as opções de um rebase interativo?

Para fazermos um rebase interativo, nós precisamos apenas adicionar o parâmetro -i no nosso rebase. Quando fazemos isso, o git irá abrir o editor de texto padrão com um arquivo especial chamado git-rebase-todo. Esse arquivo contém todos os commits que serão utilizados para o rebase (sendo referenciados pelo seus hashs e suas mensagens de commit) e qual operação que será feita com ele (na parte de exemplos, vamos dar uma olhada na cara desse arquivo).

Nesse arquivo, nós podemos reordenar os commits, remover os commits ou escolher qual operação aplicar. As operações são:

p, pick = utilizar o commit
r, reword = utilizar o commit, mas alterando a mensagem de commit
e, edit = utilizar o commit, mas parando para fazer alguma alteração (como adicionar ou remover algum elemento do commit)
s, squash = utilizar o commit, mas juntar as alterações com o commit anterior (se dois commits alterarem o mesmo arquivo, a alteração mais recente será utilizada)
f, fixup = semelhante ao squash, mas ignorando a mensagem de commit
x, exec = executar algum comando shell
d, drop = remover o commit

Um pequeno exemplo de como fazer um rebase para conquistar o coração daquele pichadão/tchutchuca que tá te filmando e quer ser seu namorado

Se você não é a musa do verão, então você precisa ralar para conseguir um bom cobertor de orelhas. E a melhor forma de fazer isso é falar sobre as operações de rebase do git para aquela pessoa que você está de olho.

E pra te dar uma mão nesse plano, vou apresentar aqui um pequeno exemplo de um rebase interativo.

Imagine a situação, você abriu um pull request e o revisor pediu um monte de alterações. Você comita as alterações e ele pede outras. Por fim, ele diz "faz um squash e um push aí das alterações para ter um histórico limpo".

O que ele quer é que todos os commits do tipo "ajustes do PR" sejam colocados como um único commit e, se for o caso, alterar a mensagem para representar as alterações feitas.

Após todas as revisões, o histórico de commits antes do rebase era algo mais ou menos assim:

Como foram feito 6 commits, nós precisamos fazer um rebase interativo à partir de 6 commits anteriores ao ponteiro da HEAD. Fazemos isso com o comando git rebase -i HEAD~6.
Isso vai abrir a tela de alteração dos commits. Daí nós só precisamos marcar os commits que não são o primeiro como squash.

Após salvar e fechar, o git vai abrir a tela para nós editarmos a mensagem de commit. Nessa tela, todas as mensagens de commit que sofreram o squash estarão presentes. Com isso é só colocar a mensagem de commit que você quer e voilá. No final, a árvore de commits ficará mais ou menos assim:

Por fim, na hora de devolver as alterações para a branch remota (aka. fazer um push), será necessário usar o parâmetro -f para reescrever o histórico. Ficará assim git push -f

Mais informações legais podem ser encontrados lá na documentação oficial do git (e foi da documentação dos branchs que eu peguei as imagens usadas)

Nota: Sendo bem preciosista, os novos *commits não serão A,B,C mas commits com mesmas alterações e mensagens de commit. Porém, o hash será diferente já que o pai do commit é diferente.

Como usar Kafka num projeto Quarkus

Aleatório — Thu, 03 Dec 2020 16:43:43 +0000

Kafka é uma ferramenta muito boa para troca de mensagens entre diferentes aplicações, porém, ele é bem intimidador e com um de detalhes para começar a consumir as mensagens.

E agora, quem poderá nos defender?

O Que faremos?

Vamos alterar a nossa gloriosa fábrica de bolo que já está persistindo os dados. Após fazer a operação será enviado uma mensagem para o broker Kafka com a entidade transformada em JSON.

Depois disso, por fim de simplicidade, vamos criar um consumidor para essas mensagens no mesmo projeto. Como vamos enviar as mensagens ao broker Kafka é possível consumir essas mensagens em algum outro projeto.

Para esse artigo é necessário saber um pouco sobre Kafka e ter o feito projeto da fábrica de bolo com banco de dados.

É hora da ação

Caso você não tenha o projeto da fábrica, você pode pegar lá no meu git. Tendo o código em mãos, vamos adicionar as dependências do Kafka e do Jackson (para mandar a mensagem em JSON). Isso é feito colocando o código abaixo na parte de dependências do arquivo pom.xml:

    <dependency>
      <groupId>io.quarkus</groupId>
      <artifactId>quarkus-smallrye-reactive-messaging-kafka</artifactId>
    </dependency>
    <dependency>
      <groupId>io.quarkus</groupId>
      <artifactId>quarkus-jackson</artifactId>
    </dependency>

Escrevendo a mensagem

Vamos começar escrevendo a mensagem. Lá no nosso arquivo BoloResource, vamos adicionar os emitters. O código para isso é:

  @Inject //1
  @Channel("add-bolo") //2
  Emitter<Bolo> addEmitter; //3

  @Inject
  @Channel("delete-bolo")
  Emitter<String> deleteEmitter;

@Inject é utilizado para fazer a inejção do nosso emitter
O @Channel vem do import org.eclipse.microprofile.reactive.messaging.Channel ele é responsável por identificar para onde vamos enviar as mensagens e configurar tudo corretamente (vamos ver mais sobre a configuração lá pra frente)
A classe Emitter vem do import org.eclipse.microprofile.reactive.messaging.Emitter e é ele quem envia a mensagem para o Kafka*

O Envio de mensagem é feito através do método Emitter#send. Vamos alterar BoloResource adicionando esse método logo antes do return. O código vai ficar assim:

  @POST
  @Transactional
  public List<Bolo> add(Bolo bolo) {
    bolo.id = null; //coisa feia, não façam isso em casa
    bolo.persist();
    addEmitter.send(bolo); //1
    return list();
  }

  @DELETE
  @Path("/{nome}")
  @Transactional
  public List<Bolo> delete(String nome) {
    Bolo.delete("nome", nome);
    deleteEmitter.send(nome); //2
    return Bolo.listAll();
  }

Estamos enviando para o kafka todo o bolo
Estamos enviando para o kafka apenas o nome do bolo

Além disso, é necessário descrever e envio de mensagens no arquivo application.properties. Para tanto, basta adicionar as seguintes linhas nele.

mp.messaging.outgoing.add-bolo.connector=smallrye-kafka
mp.messaging.outgoing.add-bolo.topic=add-bolo
mp.messaging.outgoing.add-bolo.value.serializer=io.quarkus.kafka.client.serialization.ObjectMapperSerializer

mp.messaging.outgoing.delete-bolo.connector=smallrye-kafka
mp.messaging.outgoing.delete-bolo.topic=delete-bolo
mp.messaging.outgoing.delete-bolo.value.serializer=org.apache.kafka.common.serialization.StringSerializer

Todas as configurações tem o mesmo formato mp.messaging.outgoing.<nome do canal>.<nome da propriedade>. As propriedades que nós definimos servem para dizer que vamos nos comunicar com Kafka e que vamos serializar a mensagem mensagem como JSON usando o Jackson ou enviando uma String normal.
Qualquer propriedade dos produtores do kafka podem ser utilizados.

Lendo a mensagem

A classe abaixo pode estar tanto no mesmo projeto quanto em um outro projeto (desde que tenha as dependências corretas).

import javax.enterprise.context.ApplicationScoped;

import org.eclipse.microprofile.reactive.messaging.Incoming;

@ApplicationScoped
public class BoloKafkaConsumer {

  @Incoming("add-bolo-consumer")
  public void consumeAdd(String bolo) {
    System.out.println("Bolo adicionado: " + bolo);
  }

  @Incoming("delete-bolo-consumer")
  public void consumeDelete(String nome) {
    System.out.println("Nome do bolo deletado: " + nome);
  }
}

Os dois métodos recebem o JSON do Bolo e escrevem na saída padrão. Notem que, apesar de termos enviado o bolo como objeto, estamos lendo como String. É possível configurar para receber um Bolo ou fazer qualquer transformação que seja interessante para nós.

Assim como no envio, também temos que configurar a leitura no application.properties. Isso pode ser feito através do código:

mp.messaging.incoming.add-bolo-consumer.connector=smallrye-kafka
mp.messaging.incoming.add-bolo-consumer.topic=add-bolo
mp.messaging.incoming.add-bolo-consumer.value.deserializer=org.apache.kafka.common.serialization.StringDeserializer

mp.messaging.incoming.delete-bolo-consumer.connector=smallrye-kafka
mp.messaging.incoming.delete-bolo-consumer.topic=delete-bolo
mp.messaging.incoming.delete-bolo-consumer.value.deserializer=org.apache.kafka.common.serialization.StringDeserializer

Semelhante ao produtor, no consumidor as propriedades tem o formato mp.messaging.outgoing.<nome do canal>.<nome da propriedade> e todas as propriedades podem ser encontradas no site da confluent.

Preparar para rodar

Para rodar essa aplicação, nós vamos precisar do docker-compose. Para isso, basta usar o seguinte arquivo docker-compose.yml:

version: '2'
services:
  postgres:
    image: postgres:12-alpine
    ports: 
      - "5432:5432"
    environment:
      POSTGRES_USER: Sarah
      POSTGRES_PASSWORD: Connor
      POSTGRES_DB: skynet
  zookeeper:
    image: strimzi/kafka:0.19.0-kafka-2.5.0
    command: [
      "sh", "-c",
      "bin/zookeeper-server-start.sh config/zookeeper.properties"
    ]
    ports:
      - "2181:2181"
    environment:
      LOG_DIR: /tmp/logs

  kafka:
    image: strimzi/kafka:0.19.0-kafka-2.5.0
    command: [
      "sh", "-c",
      "bin/kafka-server-start.sh config/server.properties --override listeners=$${KAFKA_LISTENERS} --override advertised.listeners=$${KAFKA_ADVERTISED_LISTENERS} --override zookeeper.connect=$${KAFKA_ZOOKEEPER_CONNECT}"
    ]
    depends_on:
      - zookeeper
    ports:
      - "9092:9092"
    environment:
      LOG_DIR: "/tmp/logs"
      KAFKA_ADVERTISED_LISTENERS: PLAINTEXT://localhost:9092
      KAFKA_LISTENERS: PLAINTEXT://0.0.0.0:9092
      KAFKA_ZOOKEEPER_CONNECT: zookeeper:2181

Esse docker-compose.yml instância e configura um banco de dados, o kafka e o zookeeper (que é um requisito para o Kafka funcionar).

Hora do teste

Depois de levantar o docker-compose (docker-compose up no mesmo diretório que está o arquivo docker-compose.yml), levantar o projeto (mvn quarkus:dev no diretório base do projeto), entrar na url http://localhost:8080/swagger-ui e fazer a cadastro de um bolo.

Depois de apertar o botão do execute. É só olhar no terminal e vamos ver a saída da aplicação:

E é isso, agora é possível brincar enviando novos bolos, excluíndo, etc...

Considerações

Nossa fábrica de bolo que já salva as coisas no banco de dados está evoluindo e está se comunicando via mensagens <3

Nos próximos episódios, vamos garantir a atualização de banco de dados com flyway, adicionar rastreabilidade, resiliência e mais um monte de coisa massa =D

Outra coisa muito massa é que conseguimos enviar mensagens para o MQTT, AMQP ou JMS sem mexer no código. Só ajustando o pom.xml e o application.properties. Isso é mesmo é algo supimpa.

Ah, e o código desse post pode ser encontrado no github.

*Na realidade, ele a função do emitter é colocar a mensagem dentro de um fluxo reativo do Smallrye. O Smallrye possui um conector que acaba fazendo o processo de enviar a mensagem para o kafka. Porém, é possível utilizar esses fluxos sem enviar para o kafka ou para qualquer outro broker de mensageria.

Alguns dos principais comandos do git

Aleatório — Fri, 09 Oct 2020 02:24:59 +0000

Seja bem vindo a mais uma ~gentil~ introdução ao git e hoje nós vamos conhecer alguns dos principais comandos que nós usamos.
Antes de começar, vamos lembrar do nosso planejamento de posts:

O que é o GIT e como usar
Principais comandos do git ⟵ você está aqui
Como fazer um rebase de presença
Como escrever um README.md
Boas práticas para utilizar o git

Quais comandos vamos estudar?

Atualmente, o git possui 137 comandos e uma quantidade infinita de parâmetros, configurações, etc...
Infelizmente, não dá para falar tudo em menos de mil palavras, então selecionei os mais comuns para falar sobre.

Caso você queira se aprofundar mais, é só dar uma olhada na documentação oficial.

Os comandos que vamos estudar são: clone, add, reset, commit, checkout, push e pull.

Então, vocês estão prontas crianças?

Clone

O primeiro comando que nós temos é o clone. Ele tem a função de copiar o repositório remoto (que geralmente está armazenado no github, bitbucket ou gitlab) para a sua máquina. A forma mais comum desse comando é:

git clone <URL>

E o conteúdo da URL é o caminho para o repositório remoto.

Por exemplo:

git clone https://github.com/lucasscharf/blog-posts-code

Fazendo isso, o git vai criar um diretório com o nome igual ao do repositório (no caso do exemplo será blog-posts-code) e copiar todo o conteúdo do repositório remoto para o local.

Add

Você se lembra lá do outro post que nós falamos sobre as áreas do git? Se não lembra, corre lá que eu te espero.

O comando add tem a seguinte cara:

git add <caminho para o diretório ou arquivo>

Ele faz com que os arquivos que não estavam na área de estagiamento passem a fazer parte da área da estagiamento*.

O git é extremamente versátil na hora de indicar o caminho para o add.
Abaixo temos alguns exemplos:

#Adiciona um arquivo
git add AlgumaClasse.java

#Adiciona um diretório*
git add AlgumDiretório

#Adiciona um diretório* com uma barra
git add AlgumDiretório/

#Adiciona todos os arquivos e diretórios* que estão abaixo do diretório local
git add .

#Adiciona o conteúdo interno de um diretório (e por consequência o diretório)
git add AlgumDiretório/Algum_conteúdo_interno

#Adiciona vários arquivos e diretórios* num mesmo comando
git add Classe1.java Classe2.java Diretório3

#Adiciona arquivos com os caracteres coringa
git add *.java

Reset

O reset é o irmão gêmeo do mal do add. Enquanto o add adiciona um diretório na área de estagiamento, o reset tira.

Além disso, o reset tem uma versão anabolizada que é o reset --hard. Que não somente retira os arquivos da área de estagiamento como também excluí os mesmos.

A sintaxe do comando de reset é:

git reset [--hard] [commit]

O no commit, você coloca o hash do commit. Você também pode utilizar atalhos commit HEAD~1 para pegar o último commit.

Commit

Após usarmos o git add para levar as mudanças do diretório de trabalho para a área de estagiamento, nós usamos o comando commit para levar os arquivos para o repositório local. A sintaxe do commit é mais fácil do que andar pra frente:

git commit

E é só isso. Após o enter, o git abrirá o seu editor de texto favorito para você escrever a mensagem de commit.
É EXTREMAMENTE importante escrever uma mensagem ou o commit não será realizado.

Branch

O comando git branch permite criar, listar ou deletar as branchs**. Suas três principais formas são:

git branch
git branch <nome_da_branch>
git branch -D <nome_da_branch>

O primeiro comando lista todas as branchs existentes no repositório local.
O segundo vai criar uma branch com o nome que nós passamos por parâmetro.
E o terceiro vai deletar a branch com o nome passado por parâmetro.

É importante notar que os nomes de branch não podem ter espaços.

Checkout

O checkout serve para movimentar entre diferentes branchs de desenvolvimento. A sintaxe é:

git checkout <nome_da_branch>

Supondo que tenhamos uma branch chamada meu_exemplo, então, nós podemos usar o comando:

git checkout meu_exemplo

Todos os commits que estavam salvos na branch anterior sumirão e, no lugar, vão surgir os commits da branch meu_exemplo. E o nosso diretório de trabalho vai se referência à branch meu_exemplo.

Push

O push é a última parte do processo. Ele envia as alterações do repositório local para o repositório remoto.*

A sintaxe é:

git push

Pull

O pull é um comando* bem simples que atualiza o diretório local com o conteúdo do repositório remoto.
Esse é outro comando tão fácil quanto andar pra frente. A sintaxe é:

git pull

Considerações

Foi uma tarefa difícil escolher apenas alguns comandos para listar. É bem provável que eu faça uma parte 2 e uma parte 3 para esses comandos, mas isso é algo para o futuro.
Foi ainda mais difícil tentar não falar todas as coisas legais que o git faz para executar esses comandos. Mas é isso. No próximo post, vamos falar sobre um assunto que eu gosto muito que é como fazer um rebase de presença.

*Isso é uma meia verdade. Nos comentários eu explico um pouco mais detalhado sobre o que acontece. É possível seguir uma vida tranquila sem olhar para os comentários.

** Pensem numa branch como uma linha de desenvolvimento que tem todos os commits feitos.

Uma gentil introdução ao git e seus comandos

Aleatório — Sat, 03 Oct 2020 09:49:59 +0000

10 em cada 10 desenvolvedores recomendam a utilização do git como ferramenta de controle de versão.

Ao longo de todos esses anos, o git tem ajudado desenvolvedores ao redor do mundo a organizarem seus projetos, fazerem backups, trocarem informações, escreverem livros, montarem blogs, etc... Porém, apesar de ser uma ferramenta tão incrível muita gente acaba usando sem saber exatamente o que tá fazendo, dependendo da IDE e passando por algumas dificuldades sem necessidade.

E é por isso que eu resolvi fazer uma sequência de posts falando sobre o git e como usar. Esses posts serão divididos nas seguintes partes:

O que é o GIT e como usar ⟵ você está aqui
Principais comandos do git
Como fazer um rebase de presença
Como escrever um README.md
Boas práticas para utilizar o git

O que é esse tal git?

Também conhecido como melhor invenção desde aquela paradinha para coçar as costas. O git é uma ferramenta livre, de código aberto para controle de versão distribuído.

Com ele o código e suas alterações ficam nas máquinas de todos os usuários. Através da utilização de snapshots dos arquivos, é possível ter acesso rápido a tudo o que foi feito pelo resto do time.

Como funciona?

Antes de entrar nos detalhes de como o git funciona, é necessário entender que o git trabalha com 4 áreas diferentes. O diretório de trabalho (working directory), a área de estagiamento (staging area), o repositório local (local repo) e o repositório remoto (remote repo). Essas áreas vão se relacionando entre si, mais ou menos como na imagem abaixo.

Diretório de trabalho é o diretório que você está utilizando para trabalhar (duh!). Não vou entrar muito nos detalhes (já que essa é uma introdução gentil), mas pense no diretório de trabalho como um sandbox para todas as alterações que você está fazendo. Ele permite que você faça/desfaça alterações sem compromisso ou afetar qualquer outra coisa.
Área de estagiamento essa área é o meio termo entre o seu diretório de trabalho e o repositório local. Nesse momento, as alterações estão indicadas para serem salvas no repostório local, porém ainda não foram salvas.
Repositório local é onde as coisas ficam salvas. Todos arquivos que você cria e as alterações desses arquivos ficam salvas de forma compactada dentro do diretório .git.
Repositório remoto é um local que centraliza os repositórios seus e de todas as pessoas envolvidas no projeto. Os repositórios mais remotos que nós temos são o github, o bitbucket e o gitlab.

Entendendo esses conceitos, fica mais fácil de entender como funcionam alguns comandos do git.

Nós criamos um repositório através do comando git init (esse comando cria o repostório local, a área de estagiamento e o diretório de trabalho);
Quando nós alteramos um arquivo, nós estamos alterando o diretório de trabalho;
Para persistir essa alteração, nós usamos o comando git add;
Para levar essa alteração da área de estagiamento para o repositório local, é utilizado o comando git commit;
o processo de levar o conteúdo do repositório local para o repositório remoto, é feito com o comando git push.

E nós temos o caminho de volta, onde o git clone copia o repositório remoto e inicializa esse repositório (com a área de estagiamento e diretório de trabalho) num diretório específico;
O git fetch atualiza o repositório local com as informações do repositório remoto;
O git merge atualiza o diretório local com as mudanças feitas no diretório remoto. (nos próximos posts vou falar melhor sobre o pull e checkout).

Imagino que já deva ter ficado claro nesse momento, mas é bom frisar:

O GIT É A FERRAMENTA DE CONTROLE DE VERSÃO, GITHUB/GITLAB/BITBUCKET PERMITEM O ARMAZENAMENTO DE REPOSITÓRIO REMOTOS.

Considerações

Espero do fundo do coração ter conseguido explicar de forma simples como as coisas funcionam. Inicialmente, eu iria fazer um único post, mas é tanta coisa legal para falar que fica complicado :/
Se tem algum tema legal sobre desenvolvimento que você queira que eu fale sobre, deixe um comentário. Você fará um aleatório muito feliz.