DEV Community: Mattheus Cassundé

Como automatizar resumos de notícias com IA: Um guia prático usando Jina e Gemini

Mattheus Cassundé — Sun, 17 Aug 2025 18:55:49 +0000

Fala pessoal, tudo certo? Hoje vamos falar sobre como podemos usar a IA para nos ajudar no dia a dia, esse projeto chamado de getContent é um projeto que visa capturar informações de alguns portais de notícia, resumir e mandar direto para seu e-mail

O Problema

Mantermo-nos informados sobre as principais notícias do Brasil e do Mundo sem gastar muito tempo é um desafio constante, entrar nos portais tradicionais, é ser soterrado por propagandas ou incentivos, pensando em melhorar a experiência de ler notícias esse projeto vem para resumir as principais notícias e envia-os por email.

O GetContent

GetContent é um projeto feito em Python que usa duas IA para fazer a parte trabalhosa, usa a IA Jina para capturar o conteúdo e o gemini para fazer os resumos.

Podemos executar esse projeto de algumas forma, via Docker ou diretamente no seu terminal, vamos ver como executar as duas formas, primeiro vamos executar diretamente no terminal.

Fazer clone do projeto

git clone git@github.com:cassunde/getContent.git

Instalar as dependências.

pip3 install requirements.txt

Agora precisamos criar um arquivo .env com as nossas credencias

GOOGLE_API_KEY=...
JINA_API_KEY=...
SENDER_EMAIL=...
SENDER_PASSWORD=...
RECIPIENT_EMAIL=...
SMTP_SERVER=...
SMTP_PORT=587
TYPE_GETCONTENT=daily

Para obter as chaves necessárias, siga estes passos:

Chave Gemini: Acesse o seguinte link para gerar sua chave: https://aistudio.google.com/app/apikey
Chave Jina: Cadastre-se na plataforma Jina através deste link: https://jina.ai/api-dashboard/ Após o cadastro, você receberá uma chave gratuita.

Além disso, você precisará de um endereço de e-mail para ser utilizado como remetente. Se você utiliza o Gmail como seu e-mail principal, considere criar uma conta no Outlook. Para configurar o Outlook como remetente, você pode encontrar as informações de SMTP necessárias neste guia: Link

Executando o GetContent via Terminal

Após clonar o repositório. instalar as dependências e criar o arquivo .env na raiz do projeto com suas credenciais. Execute o script principal do GetContent via terminal usando o comando:

python3 news.py

Isso iniciará o processo de coleta de notícias, resumo usando as APIs Jina e Gemini, e envio do resumo por e-mail para o destinatário especificado. Observe que o sucesso da execução depende da configuração correta do arquivo .env e da disponibilidade das APIs.

Executando a aplicação `getcontent` com Docker

Este sessão explica como executar a aplicação getcontent, disponível no Docker Hub em cassunde/getcontent, utilizando o comando docker run.

Pré-requisitos:

Docker instalado e configurado em seu sistema.

Execução:

O comando

docker run --rm --name getcontent -e TYPE_GETCONTENT=daily --env-file ./.env getcontent:0.0.2

com as seguintes opções:

--rm: Remove o contêiner após a sua execução. Isso limpa o ambiente após o término da aplicação, evitando a acumulação de contêineres desnecessários.
--name getcontent: Atribui o nome getcontent ao contêiner. Isso facilita a identificação e a gestão do contêiner em execução.
-e TYPE_GETCONTENT=daily: Define a variável de ambiente TYPE_GETCONTENT com o valor daily. Esta variável dis quais urls serão capturadas, resumidas e enviadas por e-mail
--env-file ./.env: Lê as variáveis de ambiente a partir do arquivo .env localizado no diretório atual. Este arquivo contém todas as credencias para executar a integrações com as IAs
getcontent:0.0.2: Especifica a imagem Docker a ser executada. A tag 0.0.2 indica a versão da imagem.

Verificando a execução:

Após executar o comando, verifique se a aplicação funcionou corretamente. Você precisa observar os logs que serão exibidos logo no final

Buscando conteúdo de: https://techcrunch.com/
Conteúdo obtido com sucesso.
Gerando resumo...
Resumo gerado com sucesso.
Email sent successfully!
Buscando conteúdo de: https://www.bbc.com/portuguese/topics/cz74k717pw5t
Conteúdo obtido com sucesso.
Gerando resumo...
Resumo gerado com sucesso.
Email sent successfully!
Buscando conteúdo de: https://cearaagora.com.br/ultimas/
Conteúdo obtido com sucesso.
Gerando resumo...
Resumo gerado com sucesso.
Email sent successfully!

Agendamento Automático com Crontab

Para automatizar a execução do getcontent via Docker usando o Crontab, siga estes passos:

Abra o Crontab: Execute o comando crontab -e no seu terminal. Isso abrirá o editor de texto padrão do seu sistema para editar o arquivo Crontab.
Adicione uma nova tarefa: Adicione uma linha com o comando para executar o Docker, seguindo a estrutura abaixo. Substitua * * * * * pela programação desejada (veja exemplos abaixo) e certifique-se de que o caminho para o arquivo .env esteja correto.

* * * * * docker run --rm --name getcontent -e TYPE_GETCONTENT=daily --env-file /caminho/para/.env getcontent:0.0.2

Exemplos de programação:

Diariamente às 8h: 0 8 * * *
A cada hora: 0 * * * *
Diariamente às 8h e 20h: 0 8,20 * * *
Somente aos dias úteis às 8h: 0 8 * * 1-5

Observações:

O caminho /caminho/para/.env deve ser substituído pelo caminho absoluto para o seu arquivo .env. Use o comando pwd no terminal para descobrir o caminho do diretório atual, se necessário.
Certifique-se de que o usuário que executa o Crontab tenha permissão para executar o comando docker. Pode ser necessário adicionar o usuário ao grupo docker.
Após salvar as alterações no Crontab, a tarefa agendada será executada de acordo com a programação definida.
Monitore os logs do Docker para identificar e solucionar quaisquer problemas que possam ocorrer durante a execução automatizada. Você pode usar o comando docker logs getcontent para visualizar os logs do contêiner.

Considerações Adicionais

Este projeto é uma excelente demonstração de como a IA pode simplificar tarefas cotidianas. No entanto, é importante considerar alguns pontos:

Limites das APIs: As APIs Jina e Gemini possuem limites de uso. Monitore o consumo para evitar exceder os limites gratuitos.
Tratamento de Erros: Implemente um mecanismo robusto de tratamento de erros para lidar com falhas nas APIs, problemas de conexão de rede e outras situações inesperadas. Isso garantirá a confiabilidade do sistema.
Escalabilidade: Para um maior volume de notícias ou usuários, considere a escalabilidade da solução, possivelmente utilizando um serviço de agendamento mais robusto e gerenciamento de filas de tarefas.
Segurança: Proteja suas credenciais de API e e-mail adequadamente. Evite armazená-las diretamente no código e utilize variáveis de ambiente como demonstrado.

GetContent - Enviando resumo de notícias por e-mail

Mattheus Cassundé — Sun, 17 Aug 2025 18:55:49 +0000

O Problema

O GetContent

GetContent é um projeto feito em Python que usa duas IA para fazer a parte trabalhosa, usa a IA Jina para capturar o conteúdo e o gemini para fazer os resumos.

Podemos executar esse projeto de algumas forma, via Docker ou diretamente no seu terminal, vamos ver como executar as duas formas, primeiro vamos executar diretamente no terminal.

Fazer clone do projeto

git clone git@github.com:cassunde/getContent.git

Instalar as dependências.

pip3 install requirements.txt

Agora precisamos criar um arquivo .env com as nossas credencias

GOOGLE_API_KEY=...
JINA_API_KEY=...
SENDER_EMAIL=...
SENDER_PASSWORD=...
RECIPIENT_EMAIL=...
SMTP_SERVER=...
SMTP_PORT=587
TYPE_GETCONTENT=daily

Para obter as chaves necessárias, siga estes passos:

Chave Gemini: Acesse o seguinte link para gerar sua chave: https://aistudio.google.com/app/apikey
Chave Jina: Cadastre-se na plataforma Jina através deste link: https://jina.ai/api-dashboard/ Após o cadastro, você receberá uma chave gratuita.

Executando o GetContent via Terminal

Após clonar o repositório. instalar as dependências e criar o arquivo .env na raiz do projeto com suas credenciais. Execute o script principal do GetContent via terminal usando o comando:

python3 news.py

Executando a aplicação `getcontent` com Docker

Este sessão explica como executar a aplicação getcontent, disponível no Docker Hub em cassunde/getcontent, utilizando o comando docker run.

Pré-requisitos:

Docker instalado e configurado em seu sistema.

Execução:

O comando

docker run --rm --name getcontent -e TYPE_GETCONTENT=daily --env-file ./.env getcontent:0.0.2

com as seguintes opções:

--rm: Remove o contêiner após a sua execução. Isso limpa o ambiente após o término da aplicação, evitando a acumulação de contêineres desnecessários.
--name getcontent: Atribui o nome getcontent ao contêiner. Isso facilita a identificação e a gestão do contêiner em execução.
-e TYPE_GETCONTENT=daily: Define a variável de ambiente TYPE_GETCONTENT com o valor daily. Esta variável dis quais urls serão capturadas, resumidas e enviadas por e-mail
--env-file ./.env: Lê as variáveis de ambiente a partir do arquivo .env localizado no diretório atual. Este arquivo contém todas as credencias para executar a integrações com as IAs
getcontent:0.0.2: Especifica a imagem Docker a ser executada. A tag 0.0.2 indica a versão da imagem.

Verificando a execução:

Após executar o comando, verifique se a aplicação funcionou corretamente. Você precisa observar os logs que serão exibidos logo no final

Buscando conteúdo de: https://techcrunch.com/
Conteúdo obtido com sucesso.
Gerando resumo...
Resumo gerado com sucesso.
Email sent successfully!
Buscando conteúdo de: https://www.bbc.com/portuguese/topics/cz74k717pw5t
Conteúdo obtido com sucesso.
Gerando resumo...
Resumo gerado com sucesso.
Email sent successfully!
Buscando conteúdo de: https://cearaagora.com.br/ultimas/
Conteúdo obtido com sucesso.
Gerando resumo...
Resumo gerado com sucesso.
Email sent successfully!

Agendamento Automático com Crontab

Para automatizar a execução do getcontent via Docker usando o Crontab, siga estes passos:

Abra o Crontab: Execute o comando crontab -e no seu terminal. Isso abrirá o editor de texto padrão do seu sistema para editar o arquivo Crontab.
Adicione uma nova tarefa: Adicione uma linha com o comando para executar o Docker, seguindo a estrutura abaixo. Substitua * * * * * pela programação desejada (veja exemplos abaixo) e certifique-se de que o caminho para o arquivo .env esteja correto.

* * * * * docker run --rm --name getcontent -e TYPE_GETCONTENT=daily --env-file /caminho/para/.env getcontent:0.0.2

Exemplos de programação:

Diariamente às 8h: 0 8 * * *
A cada hora: 0 * * * *
Diariamente às 8h e 20h: 0 8,20 * * *
Somente aos dias úteis às 8h: 0 8 * * 1-5

Observações:

O caminho /caminho/para/.env deve ser substituído pelo caminho absoluto para o seu arquivo .env. Use o comando pwd no terminal para descobrir o caminho do diretório atual, se necessário.
Certifique-se de que o usuário que executa o Crontab tenha permissão para executar o comando docker. Pode ser necessário adicionar o usuário ao grupo docker.
Após salvar as alterações no Crontab, a tarefa agendada será executada de acordo com a programação definida.
Monitore os logs do Docker para identificar e solucionar quaisquer problemas que possam ocorrer durante a execução automatizada. Você pode usar o comando docker logs getcontent para visualizar os logs do contêiner.

Considerações Adicionais

Este projeto é uma excelente demonstração de como a IA pode simplificar tarefas cotidianas. No entanto, é importante considerar alguns pontos:

Limites das APIs: As APIs Jina e Gemini possuem limites de uso. Monitore o consumo para evitar exceder os limites gratuitos.
Tratamento de Erros: Implemente um mecanismo robusto de tratamento de erros para lidar com falhas nas APIs, problemas de conexão de rede e outras situações inesperadas. Isso garantirá a confiabilidade do sistema.
Escalabilidade: Para um maior volume de notícias ou usuários, considere a escalabilidade da solução, possivelmente utilizando um serviço de agendamento mais robusto e gerenciamento de filas de tarefas.
Segurança: Proteja suas credenciais de API e e-mail adequadamente. Evite armazená-las diretamente no código e utilize variáveis de ambiente como demonstrado.

Implementando software seguindo problemas de negócio

Mattheus Cassundé — Sat, 31 May 2025 19:52:17 +0000

Nesta imersão sobre Domain-Driven Design (DDD), desvendamos como essa metodologia se estabelece como um pilar fundamental para o desenvolvimento de sistemas complexos, priorizando, de forma inegociável, os problemas de negócio acima de qualquer consideração técnica. O DDD não é meramente um conjunto de padrões arquiteturais; é uma abordagem filosófica que orienta o desenvolvimento de software a partir de uma compreensão contínua do domínio de negócio.

A essência da nossa discussão girou em torno da premissa de que a tecnologia, por mais avançada que seja, deve ser um meio para um fim – e esse fim é resolver os desafios e impulsionar as oportunidades do negócio. Ao invés de começarmos com a pilha tecnológica ou a arquitetura de banco de dados, o DDD nos convida a iniciar a jornada de desenvolvimento com um mergulho no universo do cliente, entendendo suas operações, seus desafios e seus objetivos estratégicos. É essa compreensão que irá, em última instância, moldar a arquitetura e as soluções técnicas que emergem.

Um dos pilares conceituais que exploramos foi o Domínio de Negócio e seus Subdomínios. O domínio de negócio representa a área de expertise e conhecimento sobre a qual o software será construído. No entanto, raramente um domínio é monolítico; ele é, na maioria das vezes, composto por diversos Subdomínios, cada um com suas particularidades, regras e responsabilidades. A importância de identificar e mapear esses subdomínios é crucial, pois eles nos permitem segmentar a complexidade e gerenciar o desenvolvimento de forma mais eficaz.

Dentro dessa estrutura de subdomínios, há uma distinção vital entre subdomínios "core", de suporte e genéricos. Os subdomínios "core" são aqueles que representam o diferencial competitivo da empresa, as funcionalidades que realmente a destacam no mercado. São eles que entregam o maior valor de negócio e, consequentemente, devem ser os mais maleáveis, adaptáveis e fáceis de evoluir. A discussão na call enfatizou que a prioridade de investimento em tempo, recursos e talentos deve ser direcionada para esses subdomínios "core", garantindo que eles permaneçam na vanguarda da inovação e da relevância de mercado. Subdomínios de suporte, embora necessários, não são o cerne da vantagem competitiva, enquanto subdomínios genéricos são aqueles que podem ser adquiridos como soluções prontas (prateleira) ou desenvolvidos com menor investimento, pois não representam um diferencial.

A colaboração e a comunicação foram outros temas centrais abordados, destacando o papel indispensável dos Especialistas de Domínio. Essas são as pessoas que possuem um conhecimento aprofundado do negócio, suas regras, processos e exceções. No DDD, a parceria entre especialistas de domínio e desenvolvedores é fundamental. Não se trata apenas de o especialista de domínio "passar" os requisitos para o desenvolvedor, mas sim de uma colaboração contínua e bidirecional, onde ambos aprendem uns com os outros. Essa interação constante é a base para a construção de uma Linguagem Ubíqua.

A Linguagem Ubíqua é muito mais do que um glossário de termos; é um vocabulário comum e consistente que é usado por todos os membros da equipe – desde os especialistas de negócio até os desenvolvedores, passando por testers, gerentes de produto e qualquer outra pessoa envolvida no projeto. A importância da Linguagem Ubíqua reside em sua capacidade de eliminar ambiguidades e garantir que todos estejam falando a mesma "língua" ao discutir o domínio. Se um especialista de domínio usa um termo com um significado e o desenvolvedor o interpreta de forma diferente, o resultado pode ser um software que não atende às expectativas do negócio. A Linguagem Ubíqua atua como um sistema de verdade único, onde os termos, conceitos e regras do negócio são expressos de forma clara e inequívoca, tanto na comunicação oral quanto no código do software.

A discussão prosseguiu abordando como essa compreensão profunda do domínio e a Linguagem Ubíqua são traduzidas em artefatos de desenvolvimento, como Casos de Uso e Modelos. Os Casos de Uso nos ajudam a descrever as interações dos usuários com o sistema, detalhando as funcionalidades sob a perspectiva do negócio. Eles são uma ponte crucial entre os requisitos de negócio e o design do software. Os Modelos, por sua vez, são as representações abstratas do domínio, que podem se manifestar de diversas formas – desde diagramas de classes e entidades até fluxos de processo e diagramas de estado. A beleza do DDD é que esses modelos não são apenas documentos estáticos; eles são a representação viva da Linguagem Ubíqua e são constantemente refinados e ajustados à medida que a compreensão do domínio evolui. A clareza e a precisão desses modelos são vitais para que o software reflita fielmente as regras e o comportamento do negócio.

A call ressaltou a importância de mapear esses subdomínios cruciais para que os modelos de software reflitam a essência do negócio. Isso significa que as classes, os serviços, os repositórios e todos os outros componentes do sistema devem ser nomeados e estruturados de acordo com a Linguagem Ubíqua e a lógica do domínio, e não com base em convenções técnicas genéricas. Por exemplo, se o negócio tem o conceito de "Pedido", o software deve ter uma entidade Pedido, com métodos e atributos que representem o comportamento e as características de um pedido no mundo real.

A grande vantagem de se focar nos problemas de negócio com o DDD é a capacidade de construir sistemas que são inerentemente mais alinhados aos objetivos estratégicos da empresa. Ao invés de se adaptar a um software inflexível, o negócio pode, com o DDD, guiar a evolução do sistema de forma orgânica e eficiente. Essa abordagem permite que as empresas se mantenham ágeis, adaptáveis e, o mais importante, continuem relevantes no mercado. A arquitetura de software, quando guiada pelo domínio, torna-se uma aliada poderosa na busca por inovação e competitividade, e não um obstáculo. Em suma, o DDD nos oferece um framework robusto para garantir que o desenvolvimento de software seja uma extensão natural e precisa da estratégia de negócio.

Vídeo

Quem quiser assistir o vídeo segue abaixo

Estratégias de Paralelismo e Divisão de Responsabilidades em Sistemas Complexos

Mattheus Cassundé — Sat, 04 Nov 2023 19:18:22 +0000

Paralelismo é extremamente funcional quando temos algumas responsabilidades bem definidas dentro do nosso sistema, a divisão de responsabilidade entendo que é o principal ponto de partida.

Escopo

Vamos imaginar um sistema que fará o fechamento da folha de pagamento dos funcionários.

Nesse fechamento hipotético precisamos identificar quantidade de horas extras dos funcionários, multiplicar o resultado pelo valor da hora do funcionário e adicionar o valor encontrado ao salário para assim chegarmos ao valor final a ser pago.

Quebrando responsabilidades

Como podemos dividir as responsabilidades nesse cenário? existe uma ordem de acontecimento ?

Primeiro vamos pensar, nesse cenário não podemos fazer o fechamento sem as horas extras previamente calculadas, com isso entendido fica claro que o cálculo de horas extras não depende de nada mas o fechamento depende do cálculo das horas extras, agora vamos pensar mais um pouco, vamos iniciar com a rotina de calcular as horas extras, será que conseguimos quebrar essa rotina ? será que a rotina precisa mesmo processar todos os funcionários de uma vez ?

Vamos imaginar que todos os meses esse sistema fará o cálculo de horas extras para 2mil funcionários, nessa nossa primeira implementação faremos um select na base de dados, pegaremos os 2mil funcionários e para cada funcionário encontrado calcularemos o valor de hora extra.

Um dos problemas com a abordagem acima é que caso um único funcionário falhe, faremos o reprocessamento de todos os funcionários pois tudo está acoplado dentro de uma única rotina.

Beleza, para mitigar esse problema, vamos dividir nosso problema em duas partes:

Identificação de cada Funcionário.
Execução do calculo de hora extra dado um funcionário. ## Identificando todos os Funcionários

Abaixo temos um simples diagrama que representa a primeira parte da implementação, vamos identificar todos os funcionários que estão aptos e enfileirá-los.

Em nosso exemplo estamos utilizando o RabbitMQ para controlar nossas mensagens

Podemos implementar controles de status ou outro mecanismo que de alguma forma ajude a identificar se um Funcionário está ou não apito para ter suas horas extras calculas.

Quando lidamos com eventos temos o benefício do desacoplamento mas temos que nos preocupar com outros fatores, como por exemplo, lidar com mensagens duplicadas, caso por qualquer motivo chegue uma mensagem que já foi processada essa mensagem precisa ser descartada para evitar sobrescrita ou desperdício de recursos.

Executando o cálculo de hora extra

Agora vamos implementar um Listener que receberá esse único funcionário e realizará todo o processo de cálculo de hora extra, com o RabbitMQ, conseguimos configurar a quantidade de Consumers que um determinado Listener produzirá, ou seja, podemos fazer com que processemos vários Funcionários ao mesmo tempo.

Vale observar que a nossa rotina de cálculo de hora extra é totalmente isolada entre os funcionários, podemos processar com segurança todos em paralelo, pois nesse momento não existe recurso em concorrência.

Com essa abordagem temos o processo de cálculo de hora extra sendo executado por funcionário e caso algum funcionário falhe conseguiremos reprocessar apenas o funcionário que falhou.

DLQ

Com nosso Listener implementado podemos tirar proveito das DLQs (Dead Letter Queue) que nada mais é do que o local para onde as mensagem que não conseguiram ser processadas vão ser armazenadas, é indicado que sempre que uma mensagem for direcionada para DLQ, seja disparado algum tipo de alarme para que a equipe responsável possa fazer suas análises, isso lembra um post que falo sobre a importância dos logs.

O Processo de fechamento

E sobre o processo de fechamento? será que conseguimos fazer da mesma forma? a resposta é sim, todos os processos serão por funcionário, quando o funcionário sair da fila de cálculo de hora extra ele irá para a fila de fechamento de folha de pagamento.

Nesse fluxo fica explicito que para um funcionário chegar na Fila de Fechamento ele precisará passar na fila de Calculo de Hora Extra.

Conclusão

Para alcançar o paralelizar com segurança e escalabilidade, é crucial isolar adequadamente os processos, só isso já é bem difícil principalmente em sistemas monolíticos onde existe muito acoplamento, tolerância a falhas não é coisa de microservice e sim de qualquer sistemas.

Temos cenários mais complexos, como por exemplo, receber mensagem para descontar valor de um saldo único, isso gera concorrência ou seja, dois processos querendo descontar do mesmo saldo, mas nesse post vou abordar a forma mais simples do paralelismo.

Espero que tenha ajudado a pensar em alternativas antes de tentar paralelizar um processo já existente ou no desenho de um novo processo, qualquer dúvida ou comentário é só chamar ;)

Implementando Paralelismo com Virtual Threads no Java 21

Mattheus Cassundé ・ Oct 30 '23

#java #braziliandevs #virtualthread

Implementando Paralelismo com Virtual Threads no Java 21

Mattheus Cassundé — Mon, 30 Oct 2023 03:30:52 +0000

Neste exemplo, veremos como implementar o paralelismo usando Java 21. Anteriormente, para alcançar paralelismo, utilizávamos e ainda usamos o CompletableFeature, que funciona muito bem, mas ainda é um pouco verboso.

Para começar, criaremos dois métodos que retornam uma String. Dentro de cada método, faremos a Thread esperar por alguns segundos para simbolizar uma operação de I/O.

private static String executeTask1() throws InterruptedException {
    logger.info("task 1");
  Thread.sleep(1000);
    return "task1";
}

O primeiro método espera 1 segundo antes de retornar a String, e o segundo método é semelhante, também aguardando 1 segundo.

private static String executeTask2() throws InterruptedException {
    logger.info("task 2");
  Thread.sleep(1000);
    return "task2";
}

Agora, criaremos um método que chamará esses dois métodos de forma paralela.

private static String startVirtualThreads() throws InterruptedException, ExecutionException {

    try(var executor = Executors.newVirtualThreadPerTaskExecutor()){
        var task1 = executor.submit(AppThreadPerTask::executeTask1);
    var task2 = executor.submit(AppThreadPerTask::executeTask2);
    return task1.get() + task2.get();
    }
}

Ao analisar o código acima, observaremos a criação do executor usando o utilitário Executors. No Java 21, foi adicionado o método que cria um ExecutorService usando VirtualThreads: o newVirtualThreadPerTaskExecutor(). Com esse método, podemos criar uma Virtual Thread para cada tarefa. Observamos a separação das tarefas nas linhas 4 e 5 do exemplo.

O método submit recebe Callable<V>, que é uma interface funcional do Java, e retorna um Future. O Future entrega o retorno do método quando este é finalizado com sucesso, funcionando de forma similar às Promises do JavaScript link.

É importante observar que utilizamos o método .get() para recuperar os valores dos métodos que estão sendo processados de forma paralela. Se algum dos métodos retornar uma exceção, podemos capturá-la facilmente no método principal.

Agora podemos chamar o método principal, que fará tudo funcionar. É recomendável monitorar os tempos de execução para visualização os tempos.

public static void main(String[] args) throws InterruptedException, ExecutionException {

        Instant start = Instant.now();
        logger.info("init");
        String tasksConcatenated = startVirtualThreads();
        logger.info(tasksConcatenated);

        Instant end = Instant.now();
        Duration timeElapsed = Duration.between(start, end);
        logger.info("Time taken: "+ timeElapsed.toMillis() +" milliseconds");
    }

Após a execução, teremos um log mais ou menos como o seguinte:

2023-10-29 23:03:12 INFO  AppThreadPerTask:26 - trace=121212 - init
2023-10-29 23:03:12 INFO  AppThreadPerTask:64 - trace= - task 1
2023-10-29 23:03:12 INFO  AppThreadPerTask:58 - trace= - task 2
2023-10-29 23:03:17 INFO  AppThreadPerTask:29 - trace=121212 - task1task2
2023-10-29 23:03:17 INFO  AppThreadPerTask:33 - trace=121212 - Time taken: 5018 milliseconds

Observamos nos logs que os métodos são registrados imediatamente, ou seja, estão sendo executados em paralelo. Isso significa que o método mais lento determinará o tempo de execução do método principal.

Repositório com código de exemplo: Repositório

Você já utilizou alguma dessas funcionalidades em produção? Se sim, o que achou?

Reduzindo acoplamento no desenvolvimento de software

Mattheus Cassundé ・ Sep 17 '22

#java #architecture #braziliandevs

Proxy Reverso com Apache2

Mattheus Cassundé — Fri, 20 Oct 2023 12:11:26 +0000

O Problema

Muitas vezes quando estamos iniciando uma aplicação web deixamos os usuários acessarem nosso sistema direto do servidor que nossa app está instalada. A imagem abaixo ilustra essa abordagem, agora imagina quantas informações sobre nosso sistema estamos entregando para um atacante?

Aumentando a segurança

Expor detalhes da nossa aplicação como IP e porta não é uma boa alternativa principalmente quando começamos a aumentar o fluxo de acesso, um atacante pode usar essas informações para derrubar nosso serviço.

Pensando em como resolver esse problema uma alternativa é usar um proxy reverso e tentar dificultar a vida do atacante, agora, ele não terá acesso direto ao servidor e sim a um proxy que internamente vai chamar um ou vários outros servidores.

Na imagem a cima nosso usuário não acessa mais servidor da aplicação direto, ele agora acessa um proxy que a partir do subdomínio que chegou ele vai redirecionar para o servidor correto.

Comandos

Vamos rodar o camando abaixo para resincronizar os arquivos que guardam os repositórios disponíveis do SO

sudo apt update

Vamos instalar a aplicação apache2 que será usada como nosso proxy reverso.

sudo apt install apache2

Vamos instalar todos os módulos que o apache precisa para que possamos configurar o proxy reverso

sudo a2enmod proxy proxy_http proxy_connect proxy_html

Após a instalação dos módulo será necessário realizar um reload da aplicação para aplicar todas as instalações acima.

sudo service apache2 restart

Agora vamos criar o arquivo que representa a configuração de um subdomínio que usaremos para fazer o proxy.

sudo nano /etc/apache2/sites-available/subdominio.dominio.com.br.conf

Aqui temos um exemplo do conteúdo desse arquivo onde precisamos apenas alterar algumas configurações.

<VirtualHost *:80>
       ServerName subdominio.dominio.com.br
       DocumentRoot /var/www/html

       ErrorLog ${APACHE_LOG_DIR}/error.log
       CustomLog ${APACHE_LOG_DIR}/access.log combined

       ProxyPass / http://192.121.122.12:8080/
       ProxyPassReverse / http://192.121.122.12:8080/

</VirtualHost>

Sobre esse arquivo podemos fazer sobre alguns pontos como:

ServerName: Tem que ser exatamente o mesmo do subdomínio que configuramos para apontar para IP da máquina que estamos instalando o apache2
ProxyPass: Configuração que diz para o apache2 como ele redirecionará as solicitações que chegarem em um determinado path. Em nosso exemplo a cima nosso primeiro parâmetro é o "/" que diz que redirecionaremos apartir da raiz do domínio e o segundo é para onde essas requisções serão redirecionadas, em nosso exemplo http://192.121.122.12:8080/.
ProxyPassReverse: Configuração para ajustar os cabeçalhos http da resposta do servidor de destino antes de chegar no cliente, assim deixando totalmente oculto o servidor real onde a resposta foi produzida.

Voltando para nossa instalação vamos continuar habilitando o site que acabamos de configurar.

sudo a2ensite subdominio.dominio.com.br

Por fim vamos recarregar o servidor com as novas configurações

sudo systemctl reload apache2

Conclusão

Pronto com as configurações a cima tudo deve está funcionando corretamente.

Apresentação

Outros posts

Jenkins Pipeline com Jenkinsfile

Mattheus Cassundé ・ Mar 13 '23

#ci #jenkins #cd #braziliandevs

Jenkins Pipeline com Jenkinsfile

Mattheus Cassundé — Mon, 13 Mar 2023 13:44:27 +0000

O Problema

O time está gastando muito tempo com implantações e atualizações de sistemas nos ambientes de homologação e produção, esse time faz essas operações de forma manual ou seja acessando o servidor e rodando todos os comandos necessários, vale lembrar que esse processo é repetido diversas vezes durante o mês.

Precisamos de alguma forma melhorar esse processo dando mais agilidade e deixando o time livre para trabalhar em outras tarefas.

Quais práticas existem para ajudar ?

Em uma situação como essa podemos tirar proveito dos conceitos de CI/CD. Antes de entrar no significado dessas siglas, vamos deixar claro que DevOps não é CI/CD, DevOps é sobre pessoas, um desenvolvedor não pode simplesmente avisar que terminou e esperar que o time de Operação faça a implantação, o time de Operação quando se depara com um erro após a implantação não pode simplesmente abrir um card de erro e encerrar sua parte. Em caso de falhas sistêmicas logo após a implantação quem é o profissional mais apto para resolver o problema ? um profissional de Operações ou o desenvolvedor que criou determinada feature ?

Vamos imaginar agora que o time de operação não faz mais implantações, quem vai fazer agora é o próprio time de desenvolvimento. Mas por que isso? “Quem pariu Mateus que o balance” ou "cachorro com muitos donos morre de fome”, essas frases falam de responsabilidade, quando atualizamos uma aplicação no servidor do cliente não estamos apenas trocando o .jar ou exe , estamos entregando uma solução para resolver um problema, o acompanhamento dessa solução desde a implantação até está em uso diário deve ser do time que planejou e desenvolveu essa solução. Estruturas como Servidores, Sistema operacional, versão de libs e etc depois de configurados é muito difícil dar problema, o que está mais propício a dar problema é código desenvolvido, é aplicação.

Ok, como podemos melhorar isso?

Vamos falar sobre como o Jenkins e Jenkinsfile conseguem ajudar na criação de um pipeline, a sintaxe que precisamos usar para conseguir escrever um pipeline é baseada em duas formas uma chamada de Declarativa e outra chamada de Script, nesse nosso papo vamos usar a forma Declarativa.

A Arquitetura ficará mais ou menos assim:

Iniciando com Jenkinsfile

Um jenkinsfile nada mais é do que um arquivo com código que será interpretado pelo Jenkins, esse código é baseado em Groovy uma linguagem de programação bastante usada no mercado e roda na JVM do Java. Um Jenkinsfile é como qualquer outro código do software,precisa ser versionado, pode evoluir e que provavelmente precisará de manutenções.

Vamos rapidamente voltar nos passos básicos para entregar um software em produção ou homologação.

Devemos rodar testes de unidade
Devemos rodar build
Devemos armazenar artefato
Devemos implantar artefato no servidor

pronto, agora que mapeamos os passos básicos que fazemos para entregar um software, podemos começar a pensar em como automatizar e deixar uma máquina fazendo esse trabalho.

Para iniciarmos vamos criar um arquivo na raiz do projeto chamado Jenkinsfile, não precisa de extensão, basta Jenkinsfile, vamos colocar o conteúdo abaixo:

pipeline {
    agent any

    stages {      
        stage('Test') {
            steps {
                echo 'Testando..'
            }
        }
                stage('Build') {
            steps {
                    echo 'Compilando..'
            }
        }
        stage('Store') {
            steps {
                echo 'Armazenando....'
            }
        }
                stage('DeploY') {
            steps {
                echo 'Implantando....'
            }
        }
    }
}

Analisando o conteúdo que colamos, vamos observar algumas palavras reservadas como, pipeline, agent, stages, stage e steps, vamos conhecer um pouco mais sobre eles nos blocos abaixo.

Pipeline

Quando estamos montando um Pipeline de forma Declarativa todo o conteúdo fica dentro desse nó principal que chamamos de pipeline {}

Agent

Define o Executorque será responsável por executar os comando dos pepiline, no formato Declarativo essa definição é obrigatória pois sem não saberá como executar. Podemos definir um agentde forma global como em nosso exemplo, no topo do arquivo, ou dentro de cada stagedando mais possibilidades para nosso pipeline.

Temos alguns tipos de Agent, mas para não alongar muito vamos focar em none, any e Docker.

Tipo none é bem simples, não será executado por nenhum Executor mas obriga a definição nos stage.

Tipo anydiz que será executado por qualquer Executordisponível, em nosso exemplo até o momento estamos usando esse valor.

agent any

Tipo Dockerdiz que o Executorusará uma imagem docker especificada para que ele execute seu trabalho, essa forma é a que usaremos em nossos exemplos, usando esse tipo de agent conseguimos realizar várias operações bastando ter uma imagem docker que contenha o que precisamos e pronto, não precisaremos "encher” nosso Jenkins com Plugins.

Confira mais detalhes aqui.

Stages e Stage

Agrupa um ou vários stagecada stage representa uma etapa do nosso pipeline, como test,build, deploy e etc.

...
    stages {      
        stage('Test') {
            steps {
                echo 'Testando..'
            }
        }
                stage('Build') {
            steps {
                    echo 'Compilando..'
            }
        }
        stage('Store') {
            steps {
                echo 'Armazenando....'
            }
        }
                stage('DeploY') {
            steps {
                echo 'Implantando....'
            }
        }
    }
...

Steps

Define como o stage será executado, em nosso caso estamos apenas executando o comando echomas podemos ter vários outros comando para executar o objetivo do stage.

Evoluindo colunas

Agora vamos evoluir mais ainda nosso Jenkinsfile preenchendo algumas colunas para entender como o Jenkins vai executar os passos que definimos.

Evoluindo coluna de Teste

Vamos ver como podemos evoluir a stagede teste, atualmente está super simples, apenas exibindo um texto no console, veja abaixo:

...
stage('Test') {
      steps {
          echo 'Testando..'
      }
}
...

Nosso projeto foi escrito em java usando maven como gerenciador, para rodarmos os testes unitários executamos o comando:

$ mvn test

Mas a partir de agora quem vai executar esse comando será o Jenkins, nesse nosso papo usaremos um agent do tipo docker com uma imagem contendo o Java já configurado, primeiro vamos mudar o agentglobal que está como agent anypara agent none dessa forma vamos definir o agent apenas dentro do stage como no exemplo abaixo:

...
agent none
    stages {      
        stage('Test') {
          agent { docker 'adoptopenjdk/openjdk11:jdk-11.0.9.1_1' }            
        }
}
...

agora basta implementar o steps passando o comando para rodar os testes, veja como fica:

...
agent none

    stages {      
        stage('Test') {
          agent { docker 'adoptopenjdk/openjdk11:jdk-11.0.9.1_1' }
          sh './mvnw test'
        }
     }
}
...

Se observar usamos o comando sh dentro da chave steps, pronto com isso finalizamos nossa primeira coluna, nosso arquivo está fincando assim:

pipeline {
    agent none

    stages {      
        stage('Test') {
            agent { docker 'adoptopenjdk/openjdk11:jdk-11.0.9.1_1' }
            steps {
                sh './mvnw test'
        }
    } 
    stage('Build') {
        agent any
        steps {
        echo 'Compilando..'
        }
    }
    stage('Store') {
        agent any
        steps {
            echo 'Armazenando....'
        }
    }
    stage('DeploY') {
        agent any
        steps {
            echo 'Implantando....'
        }
    }
}

observe que nos demais stage adicionei um agent do tipo any pois como comentei, se colocarmos no agent global o tipo none seremos obrigados a definir um agent em cada stage.

Evoluindo coluna de Build

Como na coluna de teste, vamos definir um agent do tipo docker, passar uma imagem com java e executar um outro comando para fazer o build da aplicação.

stage('Test') {
    agent { docker 'adoptopenjdk/openjdk11:jdk-11.0.9.1_1'}            
    steps {
        sh './mvnw package'
    }
}

pronto agora o Jenkins saberá empacotar toda nossa aplicação em um arquivo jar que ficará disponível para a próxima etapa que pode ser por exemplo criar uma imagem docker.

Conclusão

Vimos com é simples criar um arquivo Jenkinsfile e começamos a entender como o Jenkins vai usa-lo para automatizar os passos das nossas entregas de Software.

A importância dos logs na sua aplicação

Mattheus Cassundé ・ Oct 1 '22

#log #java #kibana #devops

A importância dos logs na sua aplicação

Mattheus Cassundé — Sat, 01 Oct 2022 18:34:44 +0000

Introdução

As vezes não damos aos logs a importância que eles tem e com isso não conseguimos usar a capacidade que eles tem em ajudar no dia a dia de uma aplicação em produção.

Nada sabe mais sobre a falha do que a própria aplicação que falhou, por tanto podemos usar os logs para saber o que estava se passando na aplicação quando ela falhou.

Quando podemos usar os logs?

Podemos usar o poder dos logs em diversos aspectos vou listar alguns como:

Validação de novas funcionalidades
Análise de erros
Criação de alarmes e visualizações

Validação de novas funcionalidades

É legal sempre que lançarmos alguma funcionalidade nova, sabermos se ela está sendo usada ou se está atendendo o objetivo para qual ela foi implementada, com base nisso podemos lançar os logs sempre que uma rotina for finalizada com sucesso.

Um exemplo, foi lançada uma funcionalidade que cria prontuário de paciente sempre que ele faz seu primeiro atendimento no hospital, até pouco tempo na aplicação não era possível fazer isso de formal automática, que tal lançar um log sempre que essa funcionalidade rodar com sucesso? dessa forma saberemos que funcionalidade entregue em produção funcionou com sucesso.

Análise de erros

Tão importante quanto sabermos quando uma funcionalidade nova roda com sucesso é saber quando essa mesma falha, sempre vai existir a possibilidade de algum cenário não mapeado acontecer e literalmente quebrar sua funcionalidade, é importante que saibamos o mais rápido possível para entender e corrigir esse cenário não mapeado.

O log poderá nos ajudar exibindo o máximo possível de informações sobre o cenário que ocorreu, informações como:

Classe
Método
Variáveis

pois essas informações certamente ajudarão a entender o cenário e agilizar a definição da solução.

Criação de alarmes e visualizações

Existe no mercado diversos centralizadores de logs onde um dos principais objetivos é facilitar a visualização dos mesmos.

Ferramentas como Splunk e Kibana permitem criar alarmes a partir de consultas em logs, por exemplo, sempre que chegar um log de "erro ao salvar paciente" deve ser disparado um alarme para que time de desenvolvimento/sustentação possam agir para corrigir o mais rápido possível o problema em produção.

Existe algum framework para logs?

No mundo java um dos Frameworks mais populares é o Log4J, com ele podemos deixar nossos logs mais eficientes e programáveis, podemos definir também um padrão de log como por exemplo:

"%d{HH:mm:ss.SSS} [%t] %-5level %logger{36} - %msg%n";

com essa configuração nosso log será mais ou menos assim:

17:13:01.540 [main] ERROR com.foo.Bar - Did it again!

Observa que temos a palavra ERROR, com o log4j temos níveis de log que poderemos relacionar com a gravidade do que aconteceu.

Vamos fazer um exemplo, imagine que temos o método abaixo

public void salvar(Paciente paciente {
  paciente.repository(paciente);
}

Para deixar claro que esse método foi executado com sucesso, ele ficaria mais ou menos assim:

Logger logger = Logger.getLogger("br.com.MinhaClasse");
public void salvar(Paciente paciente){
  paciente.repository(paciente);
  logger.INFO("paciente salvo com sucesso");
}

Observe que agora temos uma linha de logger do tipo INFO logo após o passo que salva o paciente, seu log ficaria mais ou menos assim:

17:13:01.540 [main] INFO com.foo.Bar - Paciente salvo com sucesso

Agora que entendemos um pouco de como podemos usar o Log4j vamos ver como podemos lidar com erros:

public void salvar(Paciente paciente){
   try{
     paciente.repository(paciente);    
   }catch(Exception e){
       e.printStackTrace();
   }
}

Nessa classe acima podemos melhora-la deixando-a com logs para ajudar a entender o que aconteceu quando esse método executou.

public void salvar(Paciente paciente){
   try{
     paciente.repository(paciente);
     logger.INFO("paciente salvo com sucesso, paciente={}",paciente.getCodigo())
    }catch(Exception e){
       logger.ERROR("problema para salvar paciente, paciente={}",paciente.getCodigo());
    }
}

Observando o método a cima, agora é possível saber quando um paciente foi salvo com sucesso e quando um paciente teve problema. Para facilitar mais ainda o entendimento quando analisarmos os logs é a possibilidade de saber qual paciente deu erro.

Dados sensíveis

Hoje em nosso país temos a lei LGPD que visa melhorar a segurança dos nossos dados na Internet. primordialmente não devemos logar nenhum dado que possa identificar unicamente uma pessoa como:

CPF
Data de Nascimento
e-mail
Nome completo
etc

Então observe sempre o que estamos logando para não expor dados pessoais.

Conclusão

É fácil começar a usar os logs para ajudar no entendimento do que acontece dentro da sua aplicação, então use e faça proveito dessa vantagens.

Reduzindo acoplamento no desenvolvimento de software

Mattheus Cassundé — Sat, 17 Sep 2022 15:14:11 +0000

Existem vários princípios que ajudam na implementação de códigos mais desacoplados e tudo mais, aqui a ideia e exemplificar como podemos fazer isso.

Exemplo

Imagine que estamos implementando um código que vende jornal, teremos uma entidade que representa a Banca e outra que representa a Carteira de um cliente.

Implementação acoplada

public void pagaJornal(BigDecimal valorJornal, Carteira carteira){

  if(carteira.getSaldo().compareTo(valorJornal) > 0){
    cateira.debitaSaldo(valorJornal);
  }else{
    // exception SaldoInsuficiente
  }

}

Nessa primeira abordagem a Banca pega a carteira do cliente verifica se tem o valor necessário e caso sim tira o valor do jornal de dentro da certeira do cliente, talvez isso não seja tão legal pois a Banca sabe muito sobre a carteira do cliente.

Implementação desacoplada

Agora vamos implementar uma solução de uma forma mais desacoplada.

class Carteira{

  private BigDecimal saldo;

  public void paga(BigDecimal valorADebitar) throws SemSaldoException  {
    if(this.saldo.compareTo(valorADebitar) > 0){
      this.saldo = this.saldo.substract(valorADebitar);
    }else{
      throw new SemSaldoException();
    }
  }
}

class Banca{
  public void pagaJornal(BigDecimal valorJornal, Carteira   carteira){
    try{
      carteira.paga(valorJornal);
    }catch(Exception e){
      // exception SaldoInsuficiente
    }
  }
}

Nessa segunda abordagem a regra de saldo fica dentro da própria carteira, dessa forma a entidade Carteira está mais livre para cuidar da sua responsabilidade, caso seja necessário incluir essa mesma funcionalidade em outra parte do projeto agora será mais simples.

Referência

Principio de Demeter
https://pt.wikipedia.org/wiki/Lei_de_Demeter

Engenharia Moderna
https://www.amazon.com.br/Engenharia-Software-Moderna-Marco-Valente/dp/6500019504

Conheça outros papos

Observer com PropertyChangeListener

Mattheus Cassundé ・ Jun 21 '22

#java #pattern

Subindo imagens para Harbor

Mattheus Cassundé — Mon, 12 Sep 2022 16:57:38 +0000

Introdução

Harbor é uma ferramenta simples para armazenar suas imagens docker.

Em nosso exemplo vamos fazer a entrega de um site simples, onde os arquivos estão dentro da pasta /dist

Pré Requisitos

Sua máquina deve ter o Docker instalado, aqui você pode ver como.
Sua aplicação deve ter um Dockerfile com as configurações necessárias para realizar o build da sua imagem com sucesso.

Por exemplo:

FROM httpd:2.4

ENV IP_API=192.0.0.1

COPY ./dist/ /usr/local/apache2/htdocs/

Criando sua imagem

Dentro a pasta do site digite o seguinte comando

sudo docker build -t {nome-sua-app}:{versao} .

por exemplo:

sudo docker build -t site-sample:0.0.1 .

Criando tag

Precisamos criar tag para cada versão da nossa aplicação, podemos usar o seguinte comando:

sudo docker tag {nome-sua-app}:{versao} {url-registry}/{projeto}/{nome-sua-app}:{versao}

por exemplo:

sudo docker tag site-sample:0.0.1 registry.inlinesoft.com.br/test/site-sample:0.0.1

Push para repositório

Para enviar uma image para o repositório devemos executar o comando push seguindo o seguinte template:

sudo docker push {url-registry}/{projeto}/{nome-sua-app}:{versao}

por exemplo:

sudo docker push site-sample:0.0.1 registry.inlinesoft.com.br/test/site-sample:0.0.1

Se tiver dado tudo certo, ao acessar seu registry você verá sua imagem disponível.

Agora é só colocar para rodar no seu servidor.

Critérios de Aceite + Cenários de Teste + Teste Unitário

Mattheus Cassundé — Fri, 02 Sep 2022 16:00:19 +0000

Gestão de projetos

Para ajudar no entendimento e definição de estimativa, podemos usar um princípio visto em Gestão de projetos chamado de Triângulo do Projeto, que requer que o gerente tente manter um equilíbrio entre três pontos fundamentais, Escopo, Tempo e Custo.

Segundo essa ideia em Gestão de projetos, não é possível Modificar nenhum desses pilares sem afetar ao menos um outro pilar.

Triângulo do Projeto de forma Ágil

Nossa ideia é explorar como podemos aplicar esse princípio, primeira coisa a entender que a responsabilidade de manter o equilíbrio entre os pontos é do time e não exclusivamente de uma pessoa.

Cada ponto pode ser explorado para ajudar na estimativa e refinamento das histórias, vamos ver como podemos explora-los.

Escopo:
O uso de critérios de aceite podem ajudar a deixar claro esses limites.
Tempo:
O uso de técnicas como t-shirt ou Planning Poker para definir o tempo que será necessário para atender os critérios de aceite.
Custo:
Nesse ponto podemos avaliar o custo em "R$", demonstrando a necessidade de usar um recurso da AWS ou a necessidade de levantar mais uma máquina em produção e entre outros.

Resumo sobre BDD

Daniel Terhorst apresentou uma técnica para juntamente com TDD busca melhorar a qualidade dos nossos produtos, priorizando o foco em comportamento e nunca em processos.

Essa técnica auxilia no compartilhamento de informações entre membros do time independentemente se for um membro de negócio ou um membro técnico.

Parte importante da técnica está na escrita nos Cenários de Teste, esses cenários usam a seguinte estrutura base:

Item	Descrição
Dado	Descreve o Contexto em que nosso usuário está
Quando	Descreve o comportamento que nosso usuário irá realizar
Então	Descreve o resultado gerado pelo comportamento do nosso usuário

Estrutura pode chegar a usar outras palavras chaves como:

Step	Descrição	Obrigatório
Feature	Descreve a HST em uma linha	Não
Cenário	Descreve cenário em uma linha	Não
Dado	Descreve o contexto	Sim
E	Detalha o contexto	Não
Quando	Descreva o Comportamento	Sim
Entao	Descreva o resultado	Sim
E	Detalha o resultado	Não

Ideia central

A ideia central e relacionar os critérios de aceite, cenários de teste e testes unitários, dessa forma unindo e ajudando na padronização da comunicação entre os membros do time.

Exemplo

Vamos imaginar que nosso time é composto por um Product Owner (PO), um Analista de Qualidade (QA) e Desenvolvedores, nesse contexto a PO escreverá os critérios de aceite para que o time possa estimar, e o time, juntamente com o QA vão criar os cenários de teste, tentando montar os cenários em cima de cada critério de aceite descrito pela PO.

Quando time começa a pensar nos cenários de teste com um "escopo limitado" isso tende a facilitar no planejamento técnico e definição de esforço.

Em nosso exemplo vamos criar uma história e passaremos pelos seguintes pontos:

Critérios de Aceite
Cenários de Teste
Teste Unitário

Criaremos uma história usando o seguinte modelo, QUEM, O QUE e POR QUÊ

Obs: Sempre criar história com base no PROBLEMA e não da Solução.

História de Usuário

Eu, enquanto Comprador quero utilizar meu cartão de crédito no pagamento dos livros escolhidos para ter praticidade e segurança no pagamento.

Critério de Aceite

Somente podemos aceitar cartões de crédito com bandeiras VISA e MASTERCARD
Somente podemos aceitar cartões de crédito com data de expiração no futuro

Cenários de Teste

A ideia aqui é relacionar os critérios de aceite com os cenários de teste, para deixar nossa entrega mais simples e focada no que realmente foi solicitado pelo negócio.

Vamos criar quantos cenários forem necessários para cada critério de aceite.

Critério de Aceite1

Somente podemos aceitar cartões de crédito com bandeiras VISA e MASTERCARD*

agora vamos montar os cenários de teste focado nesse critério de aceite.

Cenário 1:

Step	Descrição
Dado	Comprador de Livro utilizando cartão de crédito Visa
Quando	Tenta finalizar compra
Então	Recebe mensagem de sucesso

Cenário 2:

Step	Descrição
Dado	Comprador de Livro utilizando cartão de crédito diferente de Visa ou Mastercard
Quando	Tenta finalizar compra
Então	Recebe mensagem de Falha

Cenário 3:

Step	Descrição
Dado	Comprador de Livro utilizando cartão de crédito Mastercard
Quando	Tenta finalizar compra
Então	Recebe mensagem de sucesso

obs:
No critério de aceite não referencia nada de saldo, então devemos nos preocupar apenas com o que está no critério de aceite.

Critério de Aceite2

Somente podemos aceitar cartões de crédito com data de expiração no futuro

Cenário 1:

Step	Descrição
Dado	Comprador de Livro utilizando cartão de crédito com expiração 01/01/2020
Quando	Tenta finalizar compra
Então	Recebe mensagem de falha

Cenário 2:

Step	Descrição
Dado	Comprador de Livro utilizando cartão de crédito com expiração 01/01/2025
Quando	Tenta finalizar compra
Então	Recebe mensagem de sucesso

Teste Unitário

Aqui vamos fazer a última parte do nosso fluxo, escrever os teste unitários, a ideia aqui é escrever um teste unitário para cada cenário de teste definido anteriormente.

Critério de Aceite 1 | Cenário de Teste 1

@Test
public void mustAllowPaymentWithCreditCardVisa(){

    //create the saleMock
    ...

    CreditCard creditCardVisa = saleMock.getCreditCard();
    assertEqual("VISA", creditCardVisa.getFlag());

    Boolean success = saleService.finlizeSale(creditCardVisa);
    assertTrue(success);
}

Critério de Aceite 1 | Cenário de Teste 2

@Test
public void mustNotAllowPaymentWithCreditCardOtherCreditCard(){

    //create the saleMock
    ...

    CreditCard creditCardHiper = saleMock.getCreditCard();

    Boolean success = saleService.finlizeSale(creditCardHiper);
    assertFalse(success);
}

Critério de Aceite 1 | Cenário de Teste 3

@Test
public void mustAllowPaymentWithCreditCardMastercard(){

    //create the saleMock
    ...

    CreditCard creditCardMastercard = saleMock.getCreditCard();

    Boolean success = saleService.finlizeSale(creditCardMastercard);
    assertTrue(success);
}

Aqui vamos começar a fazer os testes para o Critério de aceite 2

Critério de Aceite 2 | Cenário de Teste 1

@Test
public void mustAllowPaymentWithCreditCardValidDate(){

    //create the saleMock
    ...

    CreditCard creditCardMastercard = saleMock.getCreditCard();
    assertTrue(creditCardMastercard.getExpirationDate().isAfter(LocalDate.now()));

    Boolean success = saleService.finlizeSale(creditCardMastercard);
    assertTrue(success);
}

Critério de Aceite 2 | Cenário de Teste 1

@Test
public void mustNotAllowPaymentWithCreditCardInvalidDate(){

    //create the saleMock
    ...

    CreditCard creditCardMastercard = saleMock.getCreditCard();
    assertTrue(creditCardMastercard.getExpirationDate().isBefore(LocalDate.now()));

    Boolean success = saleService.finlizeSale(creditCardMastercard);
    assertFalse(success);
}

Conclusão

Finalizamos nosso fluxo entregando uma tarefa focada na necessidade de negócio, com qualidade pois os teste unitário estão cobrindo todos os cenários de teste e consequentemente cobrindo os Critérios de aceite definidos por negócio.

Reduzindo acoplamento no desenvolvimento de software

Mattheus Cassundé ・ Sep 17 '22

#java #architecture #braziliandevs

[Dica rápida de CDI] - Observando o início

Mattheus Cassundé — Tue, 30 Aug 2022 11:11:00 +0000

As vezes precisamos executar alguns comandos quando nossa aplicação é iniciada, portanto quem usa algum framework moderno consegue saber quando sua app subiu e com o CDI não é diferente.

CDI contém uma funcionalidade de ajuda na implementação do padrão de projeto Observer.

A Própria especificação usa esse padrão em suas rotinas internas, vamos usar umas dessas chamadas para observarmos quando o CDI for carregado ao levantar o servidor de aplicação, com o código abaixo fica fácil:

@ApplicationScoped
public class StartSchedule {

    public void init(@Observes @Initialized(ApplicationScoped.class) Object init) {

        System.out.println("CDI Iniciado");
    }

    public void destroy(@Observes @Destroyed(ApplicationScoped.class) Object init) {

        System.out.println("CDI Finalizado");
    }
}

Pronto agora podemos fazer alguma ação pois o contexto do CDI foi levantado e podemos usar todo o seu poder.

Cuidados

Quando usamos o método acima para observar a inicialização do CDI outros passos da inicialização só iram continuar após a conclusão deste ou seja o uso errado pode atrapalhar a inicialização completa da sua APP.

Podemos diminuir um pouco esse efeito se colocarmos toda a implementação de negócio para ser executada em outra thread, como no exemplo abaixo:

....

public void init(@Observes @Initialized(ApplicationScoped.class) Object init) {

        new Thread(new Runnable() {
            @Override
            public void run(){
                System.out.println("CDI Iniciado");
            }
        }).start();

    }
...

Conclusão

CDI é uma poderosa ferramenta para ajudar na produtividade do desenvolvimento de soluções usando JavaEE/JarkataEE , essa é apenas uma das diversas funcionalidades que o CDI pode oferecer.

DEV Community: Mattheus Cassundé

Como automatizar resumos de notícias com IA: Um guia prático usando Jina e Gemini

O Problema

O GetContent

Executando o GetContent via Terminal

Executando a aplicação getcontent com Docker

Agendamento Automático com Crontab

Considerações Adicionais

GetContent - Enviando resumo de notícias por e-mail

O Problema

O GetContent

Executando o GetContent via Terminal

Executando a aplicação getcontent com Docker

Agendamento Automático com Crontab

Considerações Adicionais

Implementando software seguindo problemas de negócio

Vídeo

Estratégias de Paralelismo e Divisão de Responsabilidades em Sistemas Complexos

Escopo

Quebrando responsabilidades

Executando o cálculo de hora extra

DLQ

O Processo de fechamento

Conclusão

Implementando Paralelismo com Virtual Threads no Java 21

Mattheus Cassundé ・ Oct 30 '23

Implementando Paralelismo com Virtual Threads no Java 21

Reduzindo acoplamento no desenvolvimento de software

Mattheus Cassundé ・ Sep 17 '22

Proxy Reverso com Apache2

O Problema

Aumentando a segurança

Comandos

Conclusão

Apresentação

Outros posts

Jenkins Pipeline com Jenkinsfile

Mattheus Cassundé ・ Mar 13 '23

Jenkins Pipeline com Jenkinsfile

O Problema

Quais práticas existem para ajudar ?

Ok, como podemos melhorar isso?

Iniciando com Jenkinsfile

Evoluindo colunas

Conclusão

A importância dos logs na sua aplicação

Mattheus Cassundé ・ Oct 1 '22

A importância dos logs na sua aplicação

Introdução

Quando podemos usar os logs?

Existe algum framework para logs?

Dados sensíveis

Conclusão

Reduzindo acoplamento no desenvolvimento de software

Exemplo

Referência

Conheça outros papos

Observer com PropertyChangeListener

Mattheus Cassundé ・ Jun 21 '22

Subindo imagens para Harbor

Critérios de Aceite + Cenários de Teste + Teste Unitário

Gestão de projetos

Triângulo do Projeto de forma Ágil

Resumo sobre BDD

Ideia central

Exemplo

História de Usuário

Critério de Aceite

Cenários de Teste

Teste Unitário

Conclusão

Reduzindo acoplamento no desenvolvimento de software

Mattheus Cassundé ・ Sep 17 '22

[Dica rápida de CDI] - Observando o início

Cuidados

Conclusão

Executando a aplicação `getcontent` com Docker

Executando a aplicação `getcontent` com Docker