DEV Community: Jean Jacques Barros

Descomplicando a Configuração de Producers e Consumers com Kafka

Jean Jacques Barros — Wed, 08 May 2024 11:00:00 +0000

Entendendo como configurar Producers e Consumers com Kafka de forma simples e descomplicada visando o que faz sentido para os seus projetos.

Em algum momento pode ser que apareça uma tarefa em seu trabalho onde precise criar uma integração com o Kafka, quando você começa a desenvolver sua aplicação, criar sua lógica de negócio e então se de para com o arquivo cheio de parâmetros surgindo a pergunta: "Quais configurações devo fazer aqui que fazem sentido para o meu cenário?".

É comum esse tiopo de questionamento, kafka como uma ferramenta robusta nos oferece diversos recursos e configurações, e é importante entender como cada uma delas pode ser utilizada para atender as necessidades do seu projeto. Vamos entender um pouco mais sobre o Kafka e trazer exemplos práticos de como você pode preencher esses parâmetros da melhor forma sem precisar "chutar" o que pode ou não ser o melhor para o seu cenário.

O que é o Kafka

Kafka é uma plataforma de streaming distribuída desenvolvida pelo LinkedIn em 2011 e posteriormente, foi doada para a Apache Software Foundation, que hoje cuida da ferramenta. Nasceu da necessidade de lidar com fluxos de dados em tempo real de forma escalável, durável e tolerante a falhas, tornando-se uma peça fundamental em arquiteturas modernas de processamento de dados com a capacidade de processar trilhões de mensagens por dia. Em exemplos reais, Kafka pode ser utilizado para:

Streaming de Dados em tempo real
Monitoramento e Alertas
Processamento de Big Data
Integração entre Microsserviços

Tópicos

Tópicos são utilizados para organizar o fluxo de dados no Kafka, onde os registros são armazenados na sequência em que foram gerados, vamos entrar em detalhes mais a frente de como isso funciona. Por exemplo, uma aplicação de processamento de pagamentos pode ter tópicos como "transacoes-cartao", "transacoes-boletos" e "transacoes-pix", cada um representando um tipo diferente de transação financeira.

Tópicos vs Filas: Ao discutir tópicos no Kafka, muitas vezes surge a dúvida sobre a diferença entre eles e as filas. Em uma fila, as mensagens são consumidas sequencialmente por um único consumidor, garantindo o processamento FIFO (First In, First Out). Por outro lado, em um tópico, segue-se o modelo publish/subscribe, onde cada mensagem publicada é consumida por todos os consumidores registrados no tópico. Além disso, são utilizadas técnicas de particionamento para garantir a escalabilidade na leitura das mensagens pelos grupos de consumidores.

Brokers

Os brokers no Kafka são os servidores encarregados de armazenar e gerenciar os dados dos tópicos. Cada broker é parte de um cluster Kafka e mantém uma cópia dos dados dos tópicos aos quais está atribuído. Eles são escaláveis e podem ser adicionados ou removidos do cluster conforme necessário para aumentar a capacidade ou a disponibilidade do sistema.

Partições (Partitions)

Partições são segmentações que permitem dividir o tópico em frações menores; novas mensagens são adicionadas a uma partition.

Cada partição possui offsets, que são a identificação da mensagem dentro de uma partição específica, o que ajuda a saber a ordem em que foram recebidas e que devem ser processadas. Serem separadas por offsets facilita na hora de processar as mensagens, pois é possível configurar para que sejam lidas a partir de um offset específico, como em casos de reprocessamento, regras de negócio que precisem "voltar no tempo" para processar mensagens antigas ou onde queremos apenas ler mensagens de um determinado ponto.

Utilizar várias partições garante desempenho com grandes cargas de trabalho, aproveitando a replicação e a distribuição de carga entre os brokers. Por exemplo, se um tópico tiver 3 partições e 3 consumidores, cada consumidor lerá de uma partição diferente, garantindo que as mensagens sejam processadas de forma paralela.

Avro

O Kafka transfere bytes de um local para outro, Avro é uma solução para garantir o contrato nessa comunicação. Ele é uma ferramenta de serialização/deserialização de dados que define o formato das mensagens que serão enviadas e recebidas. Além disso, ele permite definir esquemas para os dados transferidos, o que auxilia na garantia de que os dados sejam interpretados corretamente pelos consumidores, mesmo quando os esquemas evoluem ao longo do tempo.

Aqui está um exemplo de um esquema Avro que define um objeto chamado TransactionItem:


 avro
{
  "type": "record",
  "name": "TransactionItem",
  "namespace": "com.payment",
  "fields": [
    {
      "name": "value",
      "type": "string"
    },
    {
      "name": "origin",
      "type": {
        "type": "record",
        "name": "Origin",
        "fields": [
          {
            "name": "account",
            "type": "string"
          }
        ]
      }
    },
    {
      "name": "createdAt",
      "type": {
        "type": "string"
      }
    }
  ]
}

Importante lembrar que o Avro não é obrigatório, mas é uma boa prática utilizá-lo para garantir a compatibilidade entre as mensagens enviadas e recebidas.

Além dos exemplos mencionados anteriormente, existem muitas outras aplicações para essa ferramenta. Neste artigo, vamos nos concentrar na comunicação entre microsserviços. Nosso exemplo será um sistema de pagamentos que processa transações PIX e notifica os clientes quando tudo ocorrer com sucesso!

Todos os exemplos apresentados neste artigo podem ser encontrados no seguinte repositório no GitHub: jjeanjacques10/payment-async-kafka: This is a payment system that utilizes Kafka technology for asynchronous integration

Producer

O producer Kafka é responsável por gerar as mensagens e publicá-las nos tópicos. É possível ter diversos producers publicando mensagens em um mesmo tópico, e também é possível ter diversos producers publicando mensagens em tópicos diferentes. Para evitar de perder mensagens, lembre-se de configurar o "acks", que define o número de replicas que devem confirmar o recebimento da mensagem, e também o "retries", que define o número de tentativas que o producer deve realizar para enviar a mensagem.

Aqui está um exemplo de configuração para um produtor em Spring, onde as principais configurações estão relacionadas à forma como queremos enviar as mensagens.


 yml
spring:
  application.name: pix-processor
  kafka:
    producer:
      bootstrap-servers: localhost:9092
      key-serializer: org.apache.kafka.common.serialization.StringSerializer
      value-serializer: io.confluent.kafka.serializers.KafkaAvroSerializer
      compression-type: snappy # Configura o tipo de compressão que deve ser aplicado às mensagens
      acks: all # Configura o acks para "all" para garantir que todas as réplicas confirmem o recebimento da mensagem
      retries: 3 # Configura o número de tentativas que o producer deve realizar para enviar a mensagem
    template:
      default-topic: payment-topic

Configuração	Descrição	Exemplo
`bootstrap-servers`	Define os endpoints utilizados para se conectar com o cluster Kafka.	`bootstrap-servers=kafka1:9092,kafka2:9092`
`key-serializer`	Classe responsável pela serialização das chaves das mensagens produzidas.	`key-serializer=org.apache.kafka.common.serialization.StringSerializer`
`value-serializer`	Classe responsável pela serialização dos valores das mensagens produzidas, define o formato que os consumidores devem seguir.	`value-serializer=io.confluent.kafka.serializers.KafkaAvroSerializer`
`properties.schema.registry.url`	URL do registro de esquemas utilizado para registrar e recuperar esquemas.	`schema.registry.url=<http://localhost:8082>` (exemplo para configuração local)
`auto.register.schemas`	Indica se os esquemas que ainda não existem devem ser registrados automaticamente no schema registry.	`auto.register.schemas=false`
`retries`	Número de tentativas que o produtor deve realizar para enviar a mensagem.	`retries=3`

acks

O "acks" é uma propriedade que define o número de réplicas que devem confirmar o recebimento da mensagem. Existem três valores possíveis para essa propriedade:

0: O produtor não aguarda nenhuma confirmação.
1: O produtor aguarda a confirmação do líder da partição.
all: O produtor aguarda a confirmação de todas as réplicas da partição.

value-serializer

Um dos pontos principais a serem configurados no produtor é o "value-serializer", que define como os valores das mensagens serão serializados. No exemplo acima, o "value-serializer" está configurado como "io.confluent.kafka.serializers.KafkaAvroSerializer", que é um serializador Avro.

io.confluent.kafka.serializers.KafkaAvroDeserializer
org.apache.kafka.common.serialization.StringSerializer
org.apache.kafka.common.serialization.ByteArraySerializer

compression-type

O "compression-type" é uma propriedade que define o tipo de compressão que deve ser aplicado às mensagens. Existem alguns tipos de compressão disponíveis, como:

none: Sem compressão.
gzip: Compressão GZIP.
snappy: Compressão Snappy.
lz4: Compressão LZ4.

Consumer

Os consumidores são aqueles que se conectam aos nossos tópicos para ler as mensagens publicadas pelos produtores. É possível ter diversos consumers conectados a um tópico. Para evitar a leitura de mensagens repetidas, lembre-se de configurar o "group-id", definindo que o novo consumidor faz parte de um grupo único e que realiza o mesmo processo e também realiza o "acknowledging" que remove a mensagem da fila para o grupo definido. É utilizado o offset para controlar a leitura das mensagens, garantindo que as mensagens sejam lidas apenas uma vez por aquele grupo consumidor (group-id).

Aqui está um exemplo de configuração para um consumidor em Spring, onde as principais configurações estão relacionadas à forma como queremos receber as mensagens e como elas devem ser tratadas.


 yml
spring:
  application.name: notification
  kafka:
    consumer:
      bootstrap-servers: localhost:9092
      key-deserializer: org.apache.kafka.common.serialization.StringDeserializer
      value-deserializer: io.confluent.kafka.serializers.KafkaAvroDeserializer
      group-id: notification-payment-group
      properties:
        auto.offset.reset: earliest # ou 'latest'
    listener:
      ack-mode: MANUAL_IMMEDIATE
    template:
      default-topic: payment-topic
    properties:
      spring.deserializer.key.delegate.class: org.apache.kafka.common.serialization.StringDeserializer
      spring.deserializer.value.delegate.class: io.confluent.kafka.serializers.KafkaAvroDeserializer
      spring.deserializer.value.fail-on-unknown-type: false
      spring.deserializer.value.type: io.confluent.kafka.serializers.subject.RecordNameStrategy
      schema.registry.url: http://localhost:8082
      specific.avro.reader: true # Deserialize to the generated Avro class rather than a GenericRecord type
      auto.register.schemas: false # Whether schemas that do not yet exist should be registered

Existem tantas configurações que seria difícil descrevê-las todas neste artigo, então vou focar em algumas das propriedades que costumo adicionar em minhas configurações, busque entender o que faz mais sentido para o seu cenário.

Configuração	Descrição	Exemplo
`key-deserializer`	Classe responsável pela desserialização das chaves das mensagens consumidas.	`key-deserializer=org.apache.kafka.common.serialization.StringDeserializer`
`value-deserializer`	Classe responsável pela desserialização dos valores das mensagens consumidas.	`value-deserializer=io.confluent.kafka.serializers.KafkaAvroDeserializer`
`group-id`	Identificador do grupo de consumidores ao qual este consumidor pertence.	`group-id=pix-consumer-group`
`properties.spring.deserializer.key.delegate.class`	Classe delegada responsável pela desserialização das chaves das mensagens, utilizada para configurações específicas do Spring.	`spring.deserializer.key.delegate.class=org.apache.kafka.common.serialization.StringDeserializer`
`properties.spring.deserializer.value.delegate.class`	Classe delegada responsável pela desserialização dos valores das mensagens, utilizada para configurações específicas do Spring.	`spring.deserializer.value.delegate.class=io.confluent.kafka.serializers.KafkaAvroDeserializer`
`properties.spring.deserializer.value.fail-on-unknown-type`	Indica se deve falhar ao desserializar um tipo desconhecido. Pode auxiliar em cenários onde o esquema é desconhecido.	`spring.deserializer.value.fail-on-unknown-type=false`
`properties.spring.deserializer.value.type`	Estratégia para obter o nome do registro do esquema para um determinado valor, usado em conjunto com o Schema Registry.	`spring.deserializer.value.type=io.confluent.kafka.serializers.subject.RecordNameStrategy`
`specific.avro.reader`	Indica se a desserialização deve ser feita para a classe Avro gerada específica ou para o tipo GenericRecord.	`specific.avro.reader=true`

ack-mode

O "ack-mode" é uma propriedade que define como o consumidor deve confirmar o recebimento da mensagem. Existem três modos de confirmação:

RECORD: Confirmação de registro por registro.
BATCH: Confirmação de registros em lote.
MANUAL: Confirmação manual.
MANUAL_IMMEDIATE: Confirmação manual imediata.

No exemplo abaixo, o "ack-mode" está configurado para MANUAL_IMMEDIATE, ou seja, a confirmação é feita manualmente e imediatamente após o processamento da mensagem.


 java
 try {
    log.info("Consume Kafka message - topic: {}, offset: {}, partition: {}", topic, offset, partition)
    notificationService.process(transactionItem.toTransaction())
} catch  ex: Exception) {
    log.error("Error processing message: {}", ex.message, ex)
} finally {
    ack.acknowledge() // Confirmação manual sendo realizada
}

consumer.properties.auto.offset.reset

No Kafka, as configurações "earliest" e "latest" são usadas para determinar onde o consumidor deve começar a consumir mensagens.

earliest: Quando o deslocamento da partição não está presente (por exemplo, quando o grupo de consumidores está consumindo a partição pela primeira vez), o consumidor começará a consumir a partir do início da partição.
latest: Quando o deslocamento da partição não está presente, o consumidor começará a consumir a partir do final da partição, ou seja, ele não consumirá nenhuma mensagem que já esteja na partição no momento em que começou a consumir.

Boas práticas

É uma boa prática adiciona o log do offset e também a partition que está lendo, isso pode auxiliar na análise futura do problema de ambos os lados, tanto no consumer quanto no producer.


 kotlin
@KafkaListener(topics = ["payment-topic"], containerFactory = "kafkaListenerContainerFactory")
fun consumePayment(
    @Payload transaction: TransactionItem,
    @Header(KafkaHeaders.OFFSET) offset: Long,
    @Header(KafkaHeaders.RECEIVED_PARTITION) partition: Int?,
    @Header(KafkaHeaders.RECEIVED_TOPIC) topic: String?,
    ack: Acknowledgment
) {
    try {
        log.info("Consume Kafka message - topic: {}, offset: {}, partition: {}", topic, offset, partition)
    } catch (
   ex: Exception) {
        log.error("Error processing message: {}", ex.message, ex)
    } finally {
        ack.acknowledge()
    }
}

Outro ponto importante é a segurança, em ambientes produtivos é essencial proteger o cluster Kafka. Isso pode incluir autenticação, autorização, SSL/TLS, entre outros. Aqui está um exemplo de configuração para habilitar SSL/TLS:


 yml
spring.kafka.properties.security.protocol: SSL
spring.kafka.properties.ssl.truststore.location: /path/to/truststore
spring.kafka.properties.ssl.truststore.password: truststorePassword
spring.kafka.properties.ssl.keystore.location: /path/to/keystore
spring.kafka.properties.ssl.keystore.password: keystorePassword

Essas configurações devem ser ajustadas de acordo com as necessidades específicas do ambiente e da política de segurança da organização.

Conclusão

Desde que comecei a aprender sobre mensageria e todas as possíveis aplicações percebi como é um tema vasto. Até focando apenas no Kafka já vemos como não é algo simples, sendo ele uma ferramenta robusta que pode ser utilizada para diversos cenários, desde streaming de dados até integração entre microsserviços. Neste artigo, vimos algumas das principais configurações que pode ser feitas em nossas aplicações, para ir mais além vá mais a fundo na documentação e realize testes dentro de casa.

A forma que mais aprendi sobre Kafka foi passando por problemas durante o desenvolvimento, e o que mais me auxiliou a resolver esses problemas foi entender melhor como a ferramenta funciona, por isso a introdução de conceitos básicos é essencial para quem está começando.

Espero que este artigo tenha sido último em sua jornada e que seja um ponto de partida para você começar a explorar cada vez mais o Kafka em seus projetos.

Fique a vontade para compartilhar tópicos que ache interessantes nos comentários!

Gostaria de agradecer ao Gustavo Santos Madeira por ter me apresentado estes conceitos sobre o Kafka me incentivado a ir mais a fundo nos estudos.

Caso tenha alguma crítica, sugestão ou dúvida fique a vontade para me enviar uma mensagem:

Linkedin: https://www.linkedin.com/in/jjean-jacques10/

Até a próxima!

Referências

A habilidade mais importante para um desenvolvedor é a comunicação

Jean Jacques Barros — Tue, 08 Aug 2023 01:21:08 +0000

Nem sempre escrever código vai resolver os maiores desafios na carreira de um desenvolvedor

Podemos dizer que 90% dos problemas de uma empresa são causados pela falta de comunicação. Isso em nível de colegas de equipe e até entre áreas inteiras. Então, como podemos melhorar a forma como nos comunicamos e evitar dores de cabeça com problemas simples que acabam crescendo com o tempo? Neste artigo, proponho-me a trazer algumas dicas de como se expressar melhor, transmitir ideias de forma escrita e verbal.

Muito além das habilidades técnicas, um bom desenvolvedor precisa entender como compartilhar suas soluções e problemas com outras pessoas.

O poder de um bom texto…

Você já deve ter participado de uma reunião que poderia ter sido substituída por um e-mail… Frequentemente, ela ocorreu apenas porque acreditavam que seria “impossível” transmitir a ideia por escrito. Posso afirmar que a maioria delas realmente deveria ter sido um texto objetivo. No entanto, para alcançar esse patamar, é necessário compreender previamente como redigir textos de qualidade.

Cuidado com erros de digitação
Conheça seu público algo
Faça as perguntas certas

Cuidado com erros de digitação

O primeiro é o mais simples de todos: Evite equívocos de digitação ou de português, você não precisa redigir a redação do ENEM, nem ser formal constantemente. O dilema ocorre quando tais equívocos podem prejudicar a compreensão do leitor, portanto revise sempre que possível antes de clicar em “ENVIAR”. Alguns segundos adicionais não comprometerão sua oportunidade de compartilhar algo, mas substituir “significado” por “sinificado” pode gerar confusão para o leitor.

Conheça seu público

O segundo aspecto está intimamente relacionado à elaboração de palestras; um palestrante competente sempre pesquisa o público-alvo de seu conteúdo, a fim de aprimorar a forma como é apresentado. No texto, devemos ter a mesma preocupação; não é adequado chegar a uma reunião com profissionais de negócios discorrendo sobre conceitos altamente técnicos. Vejamos um exemplo:

A melhor forma de expressar isso seria abstraindo essas informações e focando no que é importante para esse público:

Faça as perguntas certas

O último ponto é importante independente da senioridade, ele se baseia no “saber perguntar”, um dos sites mais famosos para desenvolvedores é o stackoverflow, nele é crucial descrever de maneira precisa o problema a fim de buscar auxílio de programadores de todo o mundo. Essa prática também ocorre dentro das empresas, quando surge uma dúvida, é necessário enviar uma mensagem no Teams ou no Slack para alguém com maior experiência ou algum profissional de negócios.

Muitas vezes partimos do pressuposta que as outras pessoas tem o mesmo contexto que nós, que sabem todo o caminho que passamos para chegar até aquele ponto, mas nem sempre (grande parte das vezes) não é este o caso. Quando entrei na área, esse foi um dos melhores conselhos que recebi: “Mostre como você chegou a essa conclusão”. Segue mais um exemplo:

Costumo incluir também imagens, pois isso evita que a pessoa precise navegar por vários links para me auxiliar em algo simples. Caso seu colega possua alguma deficiência visual, adicione o texto, se possível, ou descreva o que anteriormente seria uma imagem. Quanto mais detalhes forem acrescentados, mais valor você está dando ao tempo de seus colegas de equipe.

Don’t ask to ask, just ask

Um site que encontrei por acaso e enfatiza bastante esse aspecto é o Don’t ask to ask, just ask. Ele concentra-se nas interações que ocorrem principalmente em fóruns da internet, onde alguém chega com a seguinte pergunta:

Como mencionado no tópico sobre formular as perguntas adequadas, é necessário sempre trazer o contexto do problema, preferencialmente descrevendo as medidas já tomadas para tentar solucioná-lo.

Ao adotar esse método, você obterá uma resposta mais rápida, pois a pessoa não precisará enviar uma nova mensagem perguntando sobre qual tipo de ajuda você precisa. Além de ajudar quem for pesquisar sobre este assunto futuramente, muitas vezes será você mesmo.

Aqui tem alguns exemplos do próprio stackoverflow de como escrever bons questionamentos (tradução livre feita por mim):

Bad: C# Problema de matemática
Good: Por que usar float em vez de int me dá resultados diferentes quando todas as minhas entradas são números inteiros?

Bad: [php] dúvida sobre sessões
Good: Como posso redirecionar usuários para páginas diferentes com base em dados de sessão em PHP?

Bad: problemas com if-else no Android
Good: Por que str == “valor” retorna falso quando str é definido como “valor”?

Iniciando uma conversa

Outra questão bastante comum é como iniciar uma conversa. Provavelmente, você já recebeu uma mensagem no chat com um simples “Oi, tudo bem?” que permaneceu ali até que você respondesse com um “Oi” de volta. No entanto, essa troca pode levar tempo, enquanto novas prioridades surgem e você não tem ideia da urgência daquela saudação sem contexto. Não devemos deixar as pessoas em “espera” como em uma ligação telefônica. Seja direto, fornecendo todas as informações necessárias de forma objetiva junto à saudação.

Não faça isso:

Prefira uma abordagem direta:

TechWriter

Em nossa área temos diversas vertentes, uma delas é a de TechWriters, que são profissionais especializados em escrever e comunicar informações técnicas de maneira clara e compreensível. Eles criam documentação, manuais de usuário e guias de instruções, ajudando a traduzir conceitos complexos em linguagem acessível. Embora os desenvolvedores não precisem ser TechWriters, é importante que aprendam com esses profissionais a compartilhar informações, garantindo o sucesso e a usabilidade de produtos e de software.

Se você tiver a oportunidade de trabalhar com estes profissionais peça algumas dicas, com certeza eles lhe ensinarão algo novo, assim como você ensinará a eles.

Inteligência artificial

Uma ótima ferramenta para lhe ajudar a escrever textos melhores é a Inteligência artificial (IA). Essa tecnologia tem se mostrado cada vez mais promissora na hora de revisar textos. Através de algoritmos avançados, as ferramentas de IA podem identificar erros gramaticais, sugerir correções e até mesmo oferecer alternativas de palavras e frases para melhorar a clareza e a fluidez do texto.

Algumas das opções mais utilizadas atualmente incluem o ChatGPT, Clarice.ai, copy.ai e várias outras.

Se você pretende utilizar essas ferramentas em ambientes corporativos, certifique-se de não violar nenhuma política interna relacionada ao compartilhamento de informações.

Timidez, uma barreira para se expressar

Aqui está outra vantagem de se expressar por texto. Sempre fui uma pessoa muito tímida e busquei por muito tempo não dar minha opinião em conversas no trabalho. Por isso, comecei a escrever. Na escrita, você se expõe menos e tem a chance de revisar mais de uma vez o que será enviado. Apenas tome cuidado para não ficar lapidando um texto até chegar na versão “perfeita”, porque ela não existe. É mais importante você ter uma versão direta com as informações mais importantes do que cobrir todos os cenários.

Além disso, a comunicação escrita também proporciona uma forma de registro e referência para futuras consultas. Ao expressar ideias por meio de textos, você cria um histórico que pode ser utilizado como base para tomadas de decisão, análises retrospectivas e aprendizados.

Algumas dicas extras

Leia bastante, quem escreve bem é aquele que lê muito
Pegue feedback com seus colegas de trabalho
Não tenha medo de expor suas ideias

Conclusão

Escrevi esse artigo para compartilhar com vocês ações que me auxiliaram muito em minha carreira, ainda estou aprendendo a me expressar melhor a transmitir minha ideias para as pessoas, isso tudo é um processo que só vai melhorar com muita prática, assim como programar!

Pratique realizando anotações sobre a tarefa que está fazendo, se possível documente seu projeto, vai ajudar você e será uma forma fácil de compartilhar com novas pessoas que entrarem em sua equipe (sem passar horas em reuniões de overview).

Espero que tenha gostado e sempre que ver alguém fazendo uma pergunta sem muito contexto compartilhe esse artigo com essa pessoa! Vamos melhorar a forma que nos comunicamos e criar um mundo com menos desentendimentos!

Caso tenha alguma crítica, dúvida ou sugestão, fique à vontade para comentar abaixo ou nos envie uma mensagem:

Jean Jacques, Backend Software Engineer — https://www.linkedin.com/in/jjean-jacques10/

Até a próxima!

Referências

Como buscar posts no TabNews - Google Hacking

Jean Jacques Barros — Sun, 04 Dec 2022 22:32:51 +0000

Certeza que para quem utiliza a plataforma do TabNews a feature mais desejada é a barra de buscas. Enquanto não temos ela implementada podemos utilizar alguns recursos do Google para encontrar o que desejamos!

Google Hacking

Google Hacking é uma coleção de comandos que podem ser utilizados para encontrar o que você deseja. É um termo usado para descrever a arte de explorar técnicas de pesquisa avançada, operadores e algoritmos para localizar brechas de segurança em aplicativos, redes e sistemas da web, mas pode ser utilizado para encontrar qualquer coisa na internet.

Utilizamos alguns termos e characteres especiais para realizar essas buscas, seguem os principais:

intext: Útil para localizar páginas que contêm certos caracteres ou strings dentro de seu texto. Exemplo: intext:“TabNews”.
filetype: Este operador é usado para procurar por arquivos específicos. Exemplo: pdf, txt e etc...
site: Este operador é usado para procurar em sites específicos. Exemplo: site:tabnews.com.br
inurl: Este operador é usado para procurar por palavras específicas dentro de uma URL. Exemplo: inurl:“tabnews”
allintext: Este operador é usado para procurar por palavras específicas dentro de um documento. Exemplo: allintext:“TabNews”
allinurl: Pode ser usado para obter resultados cuja URL contém todos os caracteres especificados. Exemplo: allinurl:“tabnews”

Realizando buscas no TabNews

1# Exemplo de busca:

JavaScript site:tabnews.com.br

Resultado:

Como resultado da busca no Google temos diversos Links da TabNews com o assunto JavaScript.

2# Exemplo de busca:

Java intext:Spring Boot site:tabnews.com.br

Resultado:

Quando adicionamos o termo

intext:Spring Boot

estamos dizendo para o Google que queremos encontrar o termo Spring Boot dentro do texto do site. Como resultado temos os posts do TabNews que contém o termo "Spring Boot".

Viu como é simples? E essa técnica funciona para qualquer site!

Se gostou do conteúdo, compartilhe com seus amigos e deixe seu comentário!

GitHub: https://github.com/jjeanjacques10/
Medium: https://medium.com/@jjeanjacques10

Até a próxima!

Hospedando uma aplicação Flask no Heroku

Jean Jacques Barros — Tue, 26 Jul 2022 19:43:00 +0000

Sempre que preciso criar um projetinho para realizar algum teste ou uma prova de conceito minha stack costuma ser essa:

Linguagem: Python
Framework: Flask
Plataforma de Hospedagem: Heroku

Essas três ferramentas facilitam muito o dia a dia e abstraem aquela complexidade de ter que subir uma máquina em provedores como AWS ou Azure, e chega a ser mais simples do que abrir um túnel para acesso externo (outra coisa que já fiz muito e quem sabe um dia mostro como fazer aqui ✌🏼)

Antes de tudo, segue o repositório de exemplo que criei: https://github.com/jjeanjacques10/example_heroku_flask

E agora vamos por a mão na massa!

Criando nosso App

Vamos iniciar criando uma aplicação bem simples para utilizarmos como base:

app = Flask(__name__)

@app.route("/", methods=["GET"])
def index():
    return "<h1>Hello World!</h1>"

Configurando o Projeto

Requirements

É preciso especificar quais dependências serão necessárias para executar o projeto, pois serão baixadas dentro da plataforma do Heroku. Para isso adicionamos o arquivo requirements.txt na raiz do repositório.

Flask
Flask-Cors
requests # Exemplo de lib externa que pode usar

Procfile

Um ponto mega importante é adicionar o arquivo Procfile o qual é imprescindível para o Heroku saber qual comando executar quando for subir a aplicação. No nosso caso o comando é o seguinte:

web: python app.py

Que basicamente é o mesmo que costumamos rodar local para testar. As vezes pode ser necessário adicionar uma configuração ou outra, mas via de regra apenas chamar o python e o arquivo principal vai funcionar.

Porta

Um detalhe que pode passar despercebido é a necessidade de pegar o valor da porta que o Flask irá utilizar nas variáveis de ambiente. A plataforma irá gerar uma aleatório e mapear para a 80, por isso você consegue acessar o link sem passar o ":5000". Segue exemplo de como fazer isso de forma fácil e ainda sim definir um padrão para rodar local (port 5000):

def main():
    port = int(os.environ.get("PORT", 5000))
    app.run(host="0.0.0.0", port=port)

Realizando o Deploy

Agora que nossa aplicação está configurada criamos nosso projeto na cloud do Heroku e conectamos com o GitHub, você também pode utilizar a opção CLI, a única diferença é que ao conectar com a plataforma da Microsoft temos a opção de habilitar o deploy automático.

Após fazer a conexão será iniciado o processo da esteira de deploy, baixando as dependências e preparando o ambiente.

-----> Building on the Heroku-20 stack
-----> Determining which buildpack to use for this app
-----> Python app detected
-----> No Python version was specified. Using the buildpack default: python-3.10.5
       To use a different version, see: https://devcenter.heroku.com/articles/python-runtimes
-----> Installing python-3.10.5
-----> Installing pip 22.1.2, setuptools 60.10.0 and wheel 0.37.1
-----> Installing SQLite3
-----> Installing requirements with pip
       Collecting chardet
         Downloading chardet-5.0.0-py3-none-any.whl (193 kB)
       Collecting click
         Downloading click-8.1.3-py3-none-any.whl (96 kB)
       Collecting cryptography
         Downloading cryptography-37.0.4-cp36-abi3-manylinux_2_24_x86_64.whl (4.1 MB)
       Collecting distlib
         Downloading distlib-0.3.5-py2.py3-none-any.whl (466 kB)
       Collecting et-xmlfile
         Downloading et_xmlfile-1.1.0-py3-none-any.whl (4.7 kB)
       Collecting filelock
-----> Discovering process types
       Procfile declares types -> web
-----> Compressing...
       Done: 28.7M
-----> Launching...
       Released v3
       https://example-heroku-flask.herokuapp.com/ deployed to Heroku

Pronto, agora temos uma aplicação, de forma simples, hospedada em uma cloud e de fácil acesso para qualquer pessoa que deseje consumir esse App.

Link para testar: https://example-heroku-flask.herokuapp.com/

Caso tenha alguma crítica, sugestão ou dúvida fique a vontade para me enviar uma mensagem:

Linkedin: https://www.linkedin.com/in/jjean-jacques10/

Até a próxima!

Utilizando AWS Fargate Spot para economizar até 70% em aplicações ECS

Jean Jacques Barros — Tue, 26 Jul 2022 16:45:19 +0000

Um forma simples de configurar instâncias Fargate Spot para containers ECS, sendo pelo console ou CloudFormation

Escrevi este artigo após identificar uma necessidade na empresa em que trabalho, acredito que possa ser útil para quem utiliza o Elastic Container Service (ECS) no dia a dia e deseja diminuir custos, principalmente em ambiente de desenvolvimento e homologação, assim como foi o meu caso!

Antes de tudo, o ECS é um orquestrador de containers que permite provisionar aplicações de uma forma simples e rápida, possibilitando escalabilidade e um rápido deploy. Com ele é possível utilizar instâncias EC2, onde a infraestrutura fica por nossa conta, ou por meio do AWS Fargate onde não há necessidade por parte do cliente de gerenciar máquinas (Essa segunda opção é a que vamos utilizar).

Em 2019 foi lançado o Fargate Spot que segue o mesmo conceito das instâncias Spot para Amazon EC2, ele busca oferecer uma forma de econômica para os usuários da cloud fornecendo capacidade não utilizada pela AWS. Então quando solicitadas tarefas Spot será desta capacidade ociosa que elas sairão. Clientes que adquirem instâncias dedicadas tem preferência para tais recursos, por conta disso essa capacidade pode ser retirada a qualquer momento para que estes clientes, que optaram pela opção mais cara, possam utilizar. Você receberá uma notificação dois minutos antes da AWS precisar destes recursos de volta. Contudo, o principal motivo para utilizar Instâncias Spot é cortar custos, o preço (por hora de CPU e GB) de uma Task Spot é variável, com um desconto de 50% a 70% sobre o preço de uma tarefa sob demanda. Então, não se preocupe, definindo a estratégia certa seu sistema não ficará indisponível. Contudo, antes de utilizar em ambiente produtivo pense bem na estratégia que irá implantar, para assim evitar problemas de indisponibilidade ocasionais (📝#dica do Jean ).

Como sempre busco em meus artigos, para exemplificar de forma prática vamos subir uma aplicação Spring Boot com a infra sendo provisionada por um CloudFormation.

Então, com os conceitos básicos explicados, vamos começar criando os recursos necessários em nosso Console AWS, e caso queira pular para o template CloudFormation acesse aqui.

Existem dois tipos de configuração, uma sendo no Cluster, a qual será replicada para todos os serviços dentro dele e a feita para um serviço específico. Caso seu Cluster possua mais de um Service e você apenas queira implementar essa estratégia em um único, neste cenário não é necessário configurar o Cluster, apenas o Service.

Criando um Cluster

E é aqui que faremos a configuração para aceitar a estratégia de Fargate Spot. Na aba do serviço Elastic Container Service selecione a opção “Networking only”

Após provisionar o Cluster podemos verificar que por padrão nosso Capacity Providers já está configurado para aceitar ambos: FARGATE ** e **FARGATE_SPOT.

Para definir quais estratégias queremos utilizar devemos clicar no botão de “Update” no canto superior direito.

Nesta tela de configuração selecionamos a estratégia que nosso cluster irá utilizar, nesse caso selecionei ambos os provedores de capacidade. Defini o peso (weight) de 1 para FARGATE e 5 para FARGATE_SPOT. Com esses valores definidos para cada seis tarefas, cinco são iniciadas no FARGATE_SPOT e uma no FARGATE. Claro que você deverá escolher a estratégia que melhor se encaixa com sua necessidade, o que dependerá também de qual ambiente está realizando essas modificações. Por exemplo, o ambiente de desenvolvimento tem menos necessidade de instâncias apenas FARGATE e quanto mais Spots menor a conta no final do mês.

CloudFormation: Cluster

Para realizar configuração do Fargate Spot por meio do Cloudformation devemos adicionar ao nosso Cluster os atributos de CapacityProvider, neles definimos o peso que cada estratégia deve ter como fizemos pelo Console AWS.

EcsCluster:
  Type: 'AWS::ECS::Cluster'
  Properties:
    ClusterName: !Sub '${EcsClusterName}'
    CapacityProviders:
      - FARGATE
      - FARGATE_SPOT
    DefaultCapacityProviderStrategy:
      - CapacityProvider: FARGATE
        Weight: 1
      - CapacityProvider: FARGATE_SPOT
        Weight: 1

Criando uma Task Definition

No lado esquerdo clique em “Task Definitions”, vamos criar uma nova task do tipo “FARGATE”, no caso é a primeira opção:

Faça as configurações básicas de Role, network e sistema operacional e configuração do container que será utilizado. Para simular criei uma imagem no Amazon Elastic Container Registry (ECR) com a aplicação SpringBoot dentro dela, pode utiliza-la ou fazer com uma imagem própria.

ECR Public Gallery — digimonapi

Nesta etapa não precisamos configurar nada relacionado a instância Fargate Spot, apenas nos certificarmos que a opção selecionada foi “Fargate”.

CloudFormation: Task Definition

No Cloudformation um ponto de atenção é adicionar o atributo “RequiresCompatibilities” sendo igual a FARGATE.

TaskDefinition:
  Type: 'AWS::ECS::TaskDefinition'
  Properties:
    ContainerDefinitions:
      - Name: !Sub '${ContainerName}'
        Image: !Ref ImageDocker
        PortMappings:
          - ContainerPort: !Ref ListenerContainerPort
            HostPort: !Ref ListenerContainerPort
        Cpu: !Ref ContainerCpu
        Memory: !Ref ContainerMemory
        MemoryReservation: !Ref ContainerMemoryReservation
        Essential: true
    Family: !Sub 'family-${FeatureName}-${MicroServiceName}'
    NetworkMode: awsvpc
    Memory: !Ref ContainerMemoryReservation
    Cpu: !Ref ContainerCpu
    ExecutionRoleArn: !GetAtt TaskExecutionRole.Arn
    TaskRoleArn: !Ref TaskExecutionRole
    RequiresCompatibilities:
      - FARGATE

Criando um Service

Agora vamos criar um serviço para gerenciar melhor as Tasks que ficarão rodando. Vá até seu Cluster entre na aba de “Services” e clique em “Create”. Podemos fazer a mesma configuração de estratégia que fizemos para o Cluster ao nível de Service.

CloudFormation: Service

A configuração aqui também é bem semelhante, iremos passar o “CapacityProvider” criando uma estratégia personalizada para este serviço.

Service:
  Type: "AWS::ECS::Service"
  Properties:
    ServiceName: !Sub service-${FeatureName}-${MicroServiceName}
    Cluster: !Ref EcsClusterName
    DeploymentConfiguration:
      MinimumHealthyPercent: 100
      MaximumPercent: 200
    DesiredCount: 2
    HealthCheckGracePeriodSeconds: 40
    CapacityProviderStrategy:
      - CapacityProvider: FARGATE_SPOT
        Weight: 5
      - CapacityProvider: FARGATE
        Weight: 1
    PlatformVersion: '1.4.0'
    LoadBalancers:
      - ContainerName: !Sub ${ContainerName}
        ContainerPort: !Ref ListenerContainerPort
        TargetGroupArn: !Ref TargetGroup
    SchedulingStrategy: REPLICA
    TaskDefinition: !Ref TaskDefinition
    NetworkConfiguration:
      AwsvpcConfiguration:
        AssignPublicIp: ENABLED
        SecurityGroups:
          - !Ref SecurityGroup
        Subnets: !Ref PrivateSubnets

Rodando as aplicações

Com tudo configurado vamos ativar nosso service para provisionar novas instâncias e observar o comportamento delas.

Acessando as tasks para ter uma visão mais detalhada podemos verificar quais delas foram provisionadas como FARGATE_SPOT. A primeira está como FARGATE e a partir da segunda task já temos o desconto de 50% à 70% por tarefa rodando.

Os exemplos descritos neste artigo estão melhor detalhados no seguinte repositório (qualquer dúvida abra uma Issue ou comente):

Repositório GitHub
https://github.com/jjeanjacques10/springboot-ecs-fargate

Conclusão

Seguindo esse passo a passo podemos provisionar tarefas em nossos ECS’s com desconto na Cloud AWS, nos testes que realizei consegui ver a diferença de custos em média de 72%. Claro que em alguns casos essa abordagem não é a melhor, principalmente porquê estes recursos podem ser solicitados pela AWS quando necessário. Então analise o que faz mais sentido para o seu cenário atual e suas necessidades.

Agora é buscar aplicar estes conceitos em suas aplicações, sugiro como novamente que façam testes em ambiente não produtivo, que na minha opinião é o ideal, não queremos ter instâncias não dedicadas sendo utilizadas diretamente pelo cliente final.

Gostaria de agradecer a Kamila Peres por ter me apresentado esse conceito e me incentivado a ir mais a fundo nos estudos.

Caso tenha alguma crítica, sugestão ou dúvida fique a vontade para me enviar uma mensagem:

Linkedin: https://www.linkedin.com/in/jjean-jacques10/

Até a próxima!

Referências

AWS Fargate Spot Now Generally Available | AWS News Blog (amazon.com) https://aws.amazon.com/blogs/aws/aws-fargate-spot-now-generally-available/
AWS Fargate Spot vs. Fargate price comparison https://tomgregory.com/aws-fargate-spot-vs-fargate-price-comparison/
Fully Managed Container Solution — Amazon Elastic Container Service (Amazon ECS) — Amazon Web Serviceshttps://aws.amazon.com/ecs/
Provision Infrastructure As Code — AWS CloudFormation — Amazon Web Services https://aws.amazon.com/cloudformation/
The trouble with Fargate Spot — The Scale Factory https://www.scalefactory.com/blog/2020/07/27/the-trouble-with-fargate-spot/

Tornando seu código mais SOLID!

Jean Jacques Barros — Sat, 09 Jul 2022 03:32:20 +0000

Respondendo a primeira e mais importante pergunta, o que é SOLID? O SOLID são os 5 princípios de design de código voltados para orientação a objetos que auxiliam os desenvolvedores a escreverem um código para “serem humanos” não apenas para máquinas. O que significa que tornam o sistema criado mais fácil de se manter e também mais adaptável, facilitando alterações de escopo que podem surgir durante a evolução do projeto.

Estes princípios se mantiveram importantes desde que foram definidos por Robert C. Martin (Uncle Bob) e a necessidade de implementa-los começa a surgir quando se sente um “cheirinho estranho” no código, ou melhor dizendo, um code smells, pode ser definido como qualquer ponto no código que não pareça muito bem e possa indicar algum problema mais profundo. Neste artigo vou lhe mostrar como identificar alguns destes pontos de atenção.

Os exemplos utilizados neste artigo foram escritos em Java, mas podem ser replicados em qualquer linguagem! ☕

Princípios do SOLID

Vamos começar dizendo o que cada letra significa:

S — Single-responsibility Principle
O — Open-closed Principle
L — Liskov Substitution Principle
I — Interface Segregation Principle
D — Dependency Inversion Principle

Vamos começar pelo primeiro princípio e também, em minha opinião, o mais importante de todos eles, o princípio de:

Single-Responsibility Principle

No princípio da responsabilidade única, uma classe não deve ter mais do que um objetivo ou finalidade. Com cada parte do seu código responsável por um escopo bem definido, quando isso é feito da maneira certa é possível encontrar de forma fácil o que deseja modificar e também identificar qual o melhor local para implementar uma nova funcionalidade.

Outra vantagem é que o SRP evita de você ter que guardar todo o programa em sua cabeça, sendo que pequenos “módulos” do código são mais fáceis de lembrarmos no dia a dia. Em projetos grandes é comum criar confusão na hora de lembrar onde fica uma certa função ou qual método deve ser chamado para realizar uma ação.

Exemplo de uma classe que tem mais responsabilidades do que o necessário:

@Service public class PokedexService {

    public void calculateTotalSum() {/*<code>*/}
    public void getAllPokemon() {/*<code>*/}
    public void getPokemon() {/*<code>*/}
    public void addPokemon(String item) {/*<code>*/}
    public void deletePokemon(String item) {/*<code>*/}

    public void printReport() {/*<code>*/}
    public void showCatch() {/*<code>*/}

    public List<Pokemon> load() {/*<code>*/}
    public Pokemon save() {/*<code>*/}
    public Pokemon update() {/*<code>*/}
    public void delete(Long id) {/*<code>*/}

}

Este é um exemplo de uma God Class (Classe Deus), em POO damos esse nome quando uma classe “sabe demais”, ou seja, que implementa vários métodos e não tem um objetivo bem definido. Com o tempo a tendência é ela aumentar cada vez mais de tamanho. Um dos caminhos para evitar essa bola de neve que irá se formar é utilizar o princípio da responsabilidade única criando classes que são responsáveis por uma única tarefa:

@Service public class PokedexService {
    public void calculateTotalSum() {/*<code>*/}
    public List<Pokemon> getAllPokemon() {/*<code>*/}
    public Pokemon getPokemon() {/*<code>*/}
    public void addPokemon(String item) {/*<code>*/}
    public void deletePokemon(String item) {/*<code>*/}    
}

@Service public class ReportService {
    public void printReport() {/*<code>*/}
    public void showCatch() {/*<code>*/}
}

@Repository public interface PokemonRepository extends JpaRepository<Pokemon, Long> {
    List<Pokemon> load();
    Pokemon save();
    Pokemon update();
    void delete(Long id);
}

Neste novo exemplo fiz a separação das responsabilidades, agora temos o ReportService que cuida dos métodos de relatório e o PokedexService que é responsável pelo CRUD de Pokemon. O acesso ao banco de dados é feito por meio de um Repository. Agora ficou mais fácil para crescer a aplicação, com cada item com responsabiliades bem divididas.

Principais problemas quando não implementado:

Dificuldade em escrever testes, principalmente de unidade;
Falta de coesão no código;
Alto acoplamento, a dependência entre as partes de sua aplicação irá aumentar.

Open-closed Principle

“Entidades de software (classes, módulos, funções e etc.) devem estar abertas para extensão, porém fechadas para modificação”

Este princípio determina que uma classe deve ser “fechada para alteração e aberta para extensão”. Okay, mas o que isso significa? 😕

Isso quer dizer que sempre que uma regra de negócio nova é adicionada não será necessário alterar um código já existente e sim adicionar uma nova implementação dele. Isso ficará muito mais claro depois de alguns exemplos:

@Service public class TrainingService {

    public PokemonDTO trainPokemon(PokemonDTO pokemon, TrainingDTO training) {
        if (pokemon.getLastWorkout() != null) {
            var hoursBetweenDates = ChronoUnit.HOURS.between(pokemon.getLastWorkout(), LocalDateTime.now());
            if (hoursBetweenDates < 8) {
                throw new InvalidTraining("Your pokemon is tired, wait 8 hours");
            }
        }

        if (pokemon.getAttack() > 1000) {
            throw new InvalidTraining("Pokemon attack cannot be greater than 1000");
        }

        int newAttack = Math.round(pokemon.getAttack() + (pokemon.getAttack() * (training.getIntension() / 100)));
        int newDefense = Math.round(pokemon.getDefense() + (pokemon.getDefense() * (training.getIntension() / 100)));
        pokemon.setAttack(newAttack);
        pokemon.setDefense(newDefense);
        pokemon.setLastWorkout(LocalDateTime.now());
        return pokemon;
    }

}

Aqui temos diversas validações sendo realizadas ao tentar treinar um Pokémon, sempre que uma nova validação precisar ser adicionada precisaremos modificar esse código adicionando uma condicional. Como solução podemos fazer a seguinte modificação:

@Service public class TrainingServiceImpl implements TrainingService {

    public List<TrainingValidation> validations;

    public TrainingServiceImpl(List<TrainingValidation> validations) {
        this.validations = validations;
    }

    public PokemonDTO trainPokemon(PokemonDTO pokemon, TrainingDTO training) {
        validations.forEach(v -> v.valid(pokemon, training));
        setNewAttributes(pokemon, training);
        return pokemon;
    }

    private void setNewAttributes(PokemonDTO pokemon, TrainingDTO training) { /*code*/ }

}

Agora nosso Service recebe uma lista de validações (linha 5) que implementa a interface TrainingValidation. Desta forma sempre que uma nova validação precisar ser adicionada ao nosso treinamento basta criar uma nova classe que implemente está interface.

public interface TrainingValidation {
    void valid(PokemonDTO pokemon, TrainingDTO training);
}

public class ValidatePokemonPowerLimit implements TrainingValidation {
    @Override
    public void valid(PokemonDTO pokemon, TrainingDTO training) {
        if (pokemon.getAttack() > 1000)
            throw new InvalidTraining("Pokemon attack cannot be greater than 1000");
    }
}

public class ValidateDateLastWorkout implements TrainingValidation {
    @Override
    public void valid(PokemonDTO pokemon, TrainingDTO training) {
        if (pokemon.getLastWorkout() != null) {
            var hoursBetweenDates = ChronoUnit.HOURS.between(pokemon.getLastWorkout(), training.getDate());
            if (hoursBetweenDates < 8)
                throw new InvalidTraining("Your pokemon is tired, wait 8 hours");
        }
    }
}

Obs: O OCP pode lembrar bastante o Design Pattern Strategy, é um tópico interessante para se aprofundar.

Principais problemas quando não implementado:

Métodos com várias condicionais
Modificações constantes em entidades de software que já existem
Aumento no número de bugs ocasionais ao alterar regras de negócio

Liskov Substitution Principle

“Se S é um subtipo de T, então os objetos do tipo T, em um programa, podem ser substituídos pelos objetos de tipo S sem que seja necessário alterar as propriedades deste programa” — Wikipedia

Vamos combinar que essa definição pode deixar nossa mente mais confusa do que explicar algo 😅, mas vamos por partes… Em outras palavras: Um novo objeto criado a partir de uma classe que possuí herança não pode quebrar o comportamento da classe ancestral.

Como exemplo estou utilizando a classe Item que é estendida para as classes filho PokeBall, MasterBall e UltraBall. Mas quando vemos a implementação podemos perceber que MasterBall não implementa o método “buy” porquê não é possível comprar esse tipo de item, apenas adquiri-lo em um lugar específico durante a sua jornada.

public abstract class Item {
    private BigDecimal value;

    public String buyItem() { /*code*/ }
    public String sellItem() { /*code*/ }
}

public class MasterBall extends Item {
    @Override
    public String buyItem() {
        throw new InvalidBusinessTransaction("It's impossible buy this item");
    }
    @Override
    public String sellItem() { /*code*/ }
    public String getLocation() { /*code*/ }
}

public class Pokeball extends Item {
    @Override
    public String buyItem() { /*code*/ }
    @Override
    public String sellItem() { /*code*/ }
}

Por conta disso temos esse efeito inesperado quando tentamos vender um item MasterBall.

Para seguirmos o princípio LSP a nossa MasterBall não deve herdar da classe “Item” e sim da nova Classe “ItemRare” que tem os métodos que se encaixam melhor no escopo desejado.

public abstract class ItemRare {
    private BigDecimal value;
    private String location;

    public String getLocation() { /*code*/ }
    public String sellItem() { /*code*/ }
}

public class MasterBall extends ItemRare {
    @Override
    public String buyItem() { /*code*/ }
    @Override
    public String sellItem() { /*code*/ }
    @Override
    public String getLocation() { /*code*/ }
}

Com essa nova implementação as classes filho podem substituir facilmente a classe ancestral.

Principais problemas quando não implementado:

Métodos que lançam exceções inesperadas
Valores de tipos diferentes da classe base
Implementar um método que não faz nada
Muita lógica condicional espalhada pela aplicação

Interface Segregation Principle

Uma classe não deve implementar métodos que não irá utilizar. Por conta disso uma segmentação maior acaba sendo melhor para a organização do código. Ao desenvolver um software devemos preferir ter mais interfaces específicas, em vez de uma única interface grande e de uso geral, o que tem relação com o princípio de responsabilidade única (SRP), de acordo com essa ideia vejamos a seguinte implementação. Essa é a interface de Payment onde temos os métodos relacionados a um processo de transação dentro da aplicação:

public interface Payment {
    void initiatePayments(List<Pokeball> items);
    boolean status();
    List<Pokeball> getItems();
    void intiateLoanSettlement(List<Pokeball> items);
    List<Pokeball> initiateRePayment();
}

Agora vamos ver a implementação desta interfacenas Classes WalletService e LoanService.

//Service Wallet implementando a interface de Pagamento
public class WalletService implements Payment {
    private List<Pokeball> items;

    @Override
    public void initiatePayments(List<Pokeball> items) { /* code */ }
    @Override
    public boolean status() { /* code */ }
    @Override
    public List<Pokeball> getItems() { /* code */ }

    @Override
    public void initiateLoanSettlement(List<Pokeball> items) {
        throw new UnsupportedOperation("This is not a loan payment");
    }

    @Override
    public List<Pokeball> initiateRePayment() {
        throw new UnsupportedOperation("This is not a loan payment");
    }

}

O service de Wallet precisa implementar todos os métodos da interface, o que acaba causando comportamentos inesperados quando métodos relacionados a empréstimo como o initiateLoanSettlement são chamados, nesse exemplo a classe Wallet não tem como iniciar um empréstimo assim como a classe de LoanService não tem como iniciar um pagamento.

// Service Loan implementando a interface e Pagamento
public class LoanService implements Payment {
    private List<Pokeball> items;

    @Override
    public void initiatePayments(List<Pokeball> items) {
        throw new UnsupportedOperation("This is not a wallet payment");
    }

    @Override
    public boolean status() { /* code */ }
    @Override
    public List<Pokeball> getItems() { /* code */ }
    @Override
    public void initiateLoanSettlement(List<Pokeball> items) { /* code */ }
    @Override
    public List<Pokeball> initiateRePayment() { /* code */ }
}

Como solução para este problema segue um exemplo de implementação de interfaces mais específicas que atendem melhor a necessidade de nossa aplicação:

Neste novo desenho cada Service implementa de uma interface com os métodos que pertence ao seu domínio. Como dá para perceber o número de arquivos aumentou, mas isso não é um problema porquê o foco é manter as classes implementando apenas os métodos necessários.

Resumindo este princípio, caso uma interface comece a ganhar muitas responsabilidades ela deve ser dividida em interfaces menores, as quais serão implementadas pelos clientes (entidades de software). Lembrando que os clientes não devem implementar métodos que não utilizam.

Principais problemas quando não implementado:

Comportamentos inesperados quando chamar uma função
Utilização dos conceitos de herança de forma errada
Ferir o primeiro princípio da responsabilidade única

Dependency Inversion Principle

O princípio de inversão de dependência é sobre como classes devem depender de abstrações, não de implementações específicas dessas abstrações. Quando fazemos isso evitamos que detalhes ditem como devemos implementar uma solução. Se você realiza a chamada de uma classe dentro de outra está classe irá depender da que foi chamada. Isso resulta em um grande acoplamento e dificulta na alteração de módulos externos e também na escrita de testes. Busque então incorporar essa noção em seu código caso queira torna-lo mais flexível, ágil e reutilizável.

Neste exemplo a classe PokedexService está instanciando o modelMapper e também a Conexão do banco de dados dentro de seu construtor, da forma que está implementada temos uma dependência destes dois atributos. No caso temos acesso até as informações de URL, USER e PASSWORD referentes a conexão ao banco de dados, o que sai totalmente do escopo original da Pokedex.

@Service
public class PokedexService {

    private ModelMapper modelMapper;
    Connection connection;

    public PokedexService() {
        modelMapper = new ModelMapper();
        connection = DriverManager.getConnection(DATABASE_URL, USER, PASSWORD);
    }
}

Para resolver esses problemas transformamos a conexão em uma interface de Repository, que é a abstração que comentei a cima, onde ela pode ser trocada facilmente por outros clientes de banco de dados. Além disso ambos Repository e ModelMapper são trazidos para classe de Service por meio da passagem da informação pelo construtor (Dependency Injection) sendo possível uma maior flexibilidade.

@Service
public class PokedexServiceImpl implements PokedexService {

    private PokemonRepository pokemonRepository;
    private ModelMapper modelMapper;

    public PokedexServiceImpl(PokemonRepository pokemonRepository,
                              ModelMapper modelMapper) {
        this.pokemonRepository = pokemonRepository;
        this.modelMapper = modelMapper;
    }
}

Podemos utilizar este conceito também para estruturar melhor nossa aplicação, como exemplo no projeto criei uma interface por serviço, desta forma tenho uma visão melhor de quais são os métodos realmente necessários e também tenho uma facilidade maior para trocar uma implementação caso necessário.

Principais problemas quando não implementado:

Alto acoplamento entre classes
Aumento da complexidade para trocar um sistema externo (adapter)
Aumento da complexidade na escrita de testes

Recomendações

Conheci os princípios do SOLID por meio do livro Clean Code. É uma leitura que recomendo para aqueles que buscam melhorar a forma que escrevem código. Poderia recomendar também diversos vídeos e artigos como este, contudo, o mais importante é implementar o que viu aqui em seus projetos, só assim estes conceitos ficaram mais enraizados em sua mente.

Para ajudar você a por a mão na massa segue um link que pode ser bem útil:

Repositório GitHub
Aqui está o link para o repositório no GitHub onde coloquei os exemplos de código escritos em Java: https://github.com/jjeanjacques10/solid

Conclusão

Quando implementamos estes conceitos em nossos projetos temos um código melhor organizado, mais robusto e de fácil manutenção. Que é basicamente o sonho de todo desenvolvedor. O SOLID sozinho não vai fazer milagres, mas ajuda aqueles que trabalham com programação orientada a objetos a terem uma visão mais voltada para o reaproveitamento e boas práticas.

No começo pode ser um pouco complicado entender todos estes princípios, mas o que me ajuda a compreender cada dia mais o SOLID é buscar implementa-los todos os dias nos códigos que desenvolvo. Se quer aprender então coloque a mão na massa!

Caso tenha alguma crítica, sugestão ou dúvida fique a vontade para me enviar uma mensagem. Até a próxima!

LinkedIn: https://www.linkedin.com/in/jjean-jacques10/

Referências

Spring Boot Microservices — Monorepo Heroku

Jean Jacques Barros — Fri, 08 Jul 2022 22:47:44 +0000

Como hospedar Microservices desenvolvidos com Spring Boot no Heroku utilizando a estratégia de Monorepo

Diversas empresas utilizam Monorepo, que consiste na estratégia de adicionar diversos projetos em apenas um repositório, gerando assim uma única base de código. Essa abordagem facilita no reaproveitamento de código e também na padronização entre projetos. Contudo, este tipo de abordagem trás consigo alguns desafios quando queremos utilizar um sistema de Continuous Deploy (CD) como o Heroku.

Neste artigo vou apresentar o caminho que utilizei para realizar o deploy de diversos microservices desenvolvidos com Spring Boot que se encontram em apenas um repositório no GitHub.

Para isso vamos precisar alterar os arquivos de configuração de nossos projetos e também configurar o processo dentro da plataforma de hospedagem, no caso o Heroku, então vamos por a mão na massa!

Configurando o repositório

Precisaremos adicionar 2 arquivos na raiz de cada projeto, no caso, como vamos trabalhar com Java o primeiro arquivo deverá ser o “system.properties”, nele informamos qual a versão que desejamos trabalhar, neste caso estou utilizando o Java 17.

java.runtime.version=17

Agora iremos criar o arquivo “Procfile”, que devemos prestar muita atenção na hora de escrever. Nele adicionamos o comando que irá ser executado quando o Heroku for realizar o deploy.

web: java $JAVA_OPTS -cp target/classes:target/dependency/* -Dserver.port=$PORT -jar target/user-service-0.0.1-SNAPSHOT.jar

Neste caso estou dizendo para ele executar o arquivo jar (user-service-0.0.1-SNAPSHOT.jar), para cada projeto você deve informar o arquivo de saída esperado. Como parâmetro neste comando passamos a porta que a aplicação deverá rodar “-Dserver.port=$PORT”, o valor da variável de ambiente $PORT será fornecido pelo Heroku. É possível adicionar mais parâmetros de acordo com a necessidade do seu projeto, então fique atento e realize alguns testes locais tentando rodar o comando em sua máquina antes de subir para o repositório e testa-lo na esteira.

Configurando o Heroku

Acessando o site do Heroku: https://dashboard.heroku.com/ devemos clicar em “new” para criar um novo App, selecione um nome único para o aplicativo, ele será o Host de sua aplicação. Após ter criado o App vá até a opção de “settings” (configurações) e localize a sessão de “Buildpacks”, nele que adicionaremos a opção de trabalhar com monorepos utilizando o pacote heroku-buildpack-monorepo criado por Lincoln Stoll.

Primeiro clique em adicionar um buildpack novo, coloque o link do repositório: https://github.com/lstoll/heroku-buildpack-monorepo

Não se esqueça de adicionar o buildpack para o Java também, como no exemplo acima. Os dois devem estar selecionados para que possamos prosseguir:

Para especificar em qual pasta estará o projeto correspondente ao App devemos alterar as variáveis de ambiente adicionando o:

APP_BASE=/nome-pasta-projeto

Neste exemplo passamos /user-service para o meu serviço que controla os usuários do Twitter.

Não se esqueça de adicionar as demais variáveis de ambiente que o seu microservice precisa para ser executado. Ambiente configurado, vamos conectar o nosso repositório GitHub. Na aba de “Deploy” selecione o método GitHub e escolha a conta desejada, pode ser a sua pessoal ou da organização que trabalha.

Após realizar liberação temos a opção de escolher o projeto que queremos trabalhar, pesquise pelo nome dele e conecte. A seguir escolha a branch que deseja utilizar, no meu caso selecionei a main, também deixei ativa a opção para realizar o deploy quando algum novo commit for feito.

Pronto! Agora com tudo configurado basta testar seus Apps. Segue o exemplo dos diversos serviços rodando na aplicação do Twitter que usei como base!

Repositório projeto de exemplo:

https://github.com/jjeanjacques10/twitter-microservices

Conclusão

Seguindo este passo a passo é possível de forma fácil e rápida disponibilizar diversos serviços na plataforma do Heroku sem criar um repositório para cada um deles. O exemplo que dei foi utilizando Spring Boot, mas é possível fazer esta mesma configuração em projetos NodeJS, Python ou demais linguagens.

Caso tenha alguma crítica, sugestão ou dúvida fique a vontade para me enviar uma mensagem:

Linkedin: https://www.linkedin.com/in/jjean-jacques10/

Até a próxima!

Referências

Análise de sentimentos | Twitter com Azure Cognitive Services

Jean Jacques Barros — Wed, 15 Apr 2020 01:21:16 +0000

Com Python + Azure temos uma forma fácil de usar inteligência artificial em nossas aplicações

O objetivo desse artigo não é apresentar uma aplicação complexa, tenho como foco destrinchar o uso de API’s com inteligência artificial integrando com uma das maiores redes sociais do mundo.

O Twitter se tornou bem mais que apenas uma rede social, políticos o utilizam para se comunicarem diretamente com seu público, ameaçar outros governantes entre outras coisas possíveis no meio de muitos MEME’s e gifs engraçados. Para nós da área de tecnologia é um cenário repleto de dados que podemos analisar e foi isso que fiz, utilizado o Azure e a API do Twitter fiz uma análise de sentimentos de alguns Tweets de personalidades importantes atualmente.

Twitter

O Twitter oferece acesso as suas APIs por meio do site deles, elas são os segmentadas em

Standard API
Premium API
Enterprise API
Ads API

Irei utilizar a Padrão (Standard API) que não é preciso pagar e também é a mais fácil de se ter acesso, como única exigência é preciso ter uma conta de desenvolvedor, ação bem simples de ser concluída, assim que fizer a inscrição basta esperar o e-mail de confirmação.

Já logado você vai entrar no site e criar o seu APP, assim que finalizado, vai ter acesso a sua API key e a API secret key (CUIDADO, apenas você de ter acesso a elas).

Com essas duas chaves você agora poderá integrar ao seu código

O que é Azure Cognitive services?

A Microsoft oferece um meio de desenvolvedores que não tem conhecimentos avançados em inteligência artificial a implementarem em suas soluções tecnologias “Cognitivas”, ou seja, que emulam os serem humanos com funcionalidades como ver, ouvir, falar, pesquisar, entender e auxiliar na tomada de decisão.

Vamos utilizar a Análise de texto para identificar o sentimento em uma frase, um dos pontos fortes é que essa análise funciona tanto em português quanto em outros idiomas. É possível testar o recurso no próprio site deles:

Assim que fizer o cadastro no Azure e criar um novo cognitive service vai receber o seu subscription_key e o endpoint no qual poderá consumir o serviço.

Com as keys do Twitter(4 primeiros campos) e da API do Azure(2 últimos campos) vamos criar o env.json, nele teremos tudo que nosso projeto precisa para funcionar, ele vai ter esse formato:

Agora que temos tudo que precisamos,

Vamos por a mão na massa!

Para criar uma aplicação simples primeiro vamos coletar os tweets da rede social, o módulo que vamos precisar importar primeiro é o tweepy, ele que vai nos ajudar a coletar as publicações de uma determinada conta, como exemplo estou coletando da minha pessoal @jeanjacques1999, defini para coletar até 500 tweets, você pode alterar essas variáveis.

# -*- coding: utf-8 -*-
import tweepy, json, os

def get_tweets():
    try:
        #Acessando o arquivo com as keys
        with open('env.json', 'r') as f:
            content = json.loads(f.read())
        f.close()

        chave_consumidor = content['chave_consumidor']
        segredo_consumidor = content['segredo_consumidor']
        token_acesso = content['token_acesso']
        token_acesso_segredo = content['token_acesso_segredo']

        #Fazendo a autenticão
        autenticacao = tweepy.OAuthHandler(chave_consumidor, segredo_consumidor)
        autenticacao.set_access_token(token_acesso, token_acesso_segredo)

        twitter = tweepy.API(autenticacao)

        #Fazendo as pesquisa (Você pode alterar o language)
        result = twitter.search(q='jeanjacques1999', count=1000, tweet_mode="extended")

        data = []
        for tweet in result:
            data.append({'id':str(tweet._json['id']), 'language':'pt', 'text':tweet._json['full_text']})

        return data
    except Exception as e:
        erro = "Encountered exception. {}".format(e)
        return erro

A Função get_tweets() vai se conectar ao Twitter e retornar um JSON com o seguinte formato:

ID, language e text, a linguagem pode ser alterada no código para uma das seguintes suportadas:

Português (pt)
Inglês (en)
Espanhol (es)
Francês (fr)
Russo (ru)

O campo text é o corpo que será analisado pela nossa inteligência artificial, assim que retornamos todos os tweets vamos passa-los para outro método, que está em nosso main(), nossa função principal ficou assim:

from get_tweets import get_tweets
from cognitiveService import sentiment
import os, json

def main():
    #Coletandos os tweets
    tweet = get_tweets()
    insert_data(tweet)

    if(tweet):
        #Passando em nossa IA para identificar sentimento
        tweet_score = sentiment()
        insert_data(tweet_score)
    else:
        print(tweet)

def insert_data(data):
    #Apagando o arquivo caso ele exista
    dir = os.listdir()
    for file in dir:
        if file == "twitters.json":
            os.remove(file)

    #Inserindo os dados entro do arquivo twitters.json
    with open('twitters.json', 'a', encoding='utf-8') as f:
        json.dump(data, f)
    f.close()

if __name__ == "__main__":
    main()

No main() chamamos a função get_tweets() que mostrei anteriormente e então inserimos dentro do arquivo twitters.json, a análise de sentimento será feita na função sentiment() que vou mostrar a seguir. Para que ela funciona antes instale o pacote:

pip install azure.cognitiveservices.language.textanalytics

# -*- coding: utf-8 -*-
import os, json
from azure.cognitiveservices.language.textanalytics import TextAnalyticsClient
from msrest.authentication import CognitiveServicesCredentials

#Acessando o arquivo com as keys
with open('env.json', 'r') as f:
    content = json.loads(f.read())
f.close()

subscription_key = content['subscription_key']
endpoint = content['endpoint']

def authenticateClient():
    credentials = CognitiveServicesCredentials(subscription_key)
    text_analytics_client = TextAnalyticsClient(
        endpoint=endpoint, credentials=credentials)
    return text_analytics_client

def sentiment():
    #Criando um client já autenticado
    client = authenticateClient()
    try:
        #Lendo os tweets que foram salvos anteriormente
        with open('twitters.json', 'r') as f:
            tweets = json.loads(f.read())

        #Fazendo a análise dos sentimentos
        response = client.sentiment(documents=tweets)
        sum_total = 0

        for index, document in enumerate(response.documents):
            tweets[index]["score"] = document.score
            sum_total += document.score

        #Calculo e mostro a média de Scores
        average = (sum_total/len(response.documents)) * 100
        print("Média dos Scores: {0:.2f}%".format(average))

        #Retornando os tweets com o score
        return tweets
    except Exception as err:
        print("Encountered exception. {}".format(err))

Chegamos na parte em que a mágica acontece, faço a leitura do arquivo que foi salvo anteriormente e passo para o meu client, o client autenticado é a nossa API do cognitive service que estamos consumindo diretamente do Azure. Quando o processo for finalizados vamos ter no mesmo JSON o seguinte resultado:

O Score foi adicionado ao nosso objeto e ele é a porcentagem do sentimento, quanto maior mais positivo/feliz o texto.

Também optei por mostrar na tela uma média a qual diz se o twitter analisado é mais positivo ou negativo. O meu resultado ficou assim: “Média dos Scores: 46.20%”, poderia ter sido melhor claro 😅

Analisando outros perfis

Vamos rodar o algoritmo em alguns perfis de pessoas influentes no Twitter

Trump (@realDonaldTrump)

Média dos Scores: 53.41%

Globo News (@GloboNews)

Média dos Scores: 36.32%

Bolsonaro (@jairbolsonaro)

Média dos Scores: 52.24%

Tabata Amaral (@tabataamaralsp)

Média dos Scores: 43.10%

A Solução

Ao final de tudo vamos ter as seguintes informações

Porcentual de felicidade em um tweet
Média de felicidade de um perfil na rede social

Não tive como objetivo criar o melhor e mais completo programa para análise de sentimento aqui, só quis lhe mostrar como é possível iniciar algo que pode ter várias aplicações de uma forma bem rápida e com pouca enrolação.

Agora você pode baixar o código no GitHub e brincar a vontade. Veja quem é uma pessoa mais positiva na rede social, você ou seu amigo.

Repositório Github

Análise de sentimentos com Python e Azure - https://github.com/jjeanjacques10/analise-de-sentimento-python-azure

Caso tenha alguma crítica, sugestão ou dúvida fique a vontade para me enviar uma mensagem:

Linkedin: https://www.linkedin.com/in/jjean-jacques10/

Até a próxima!

Referências

Azure Cognitive Services Acesso em: 22 janeiro. 2020.

API do Twitter https://developer.twitter.com/en/dashboard Acesso em: 22 janeiro. 2020.