DEV Community: Eduardo Bueno

Backstage: Facilitando a criação de componentes e melhorando a governança no desenvolvimento de software

Eduardo Bueno — Mon, 19 Jun 2023 01:14:40 +0000

Oi, eu sou o Edu!

Pra mim, uma das coisas mais bacanas de trabalhar com tecnologia é a possibilidade de estar sempre aprendendo e aplicando algo novo, como uma nova linguagem de programação, uma abordagem diferente para lidar com problemas relacionados ao desenvolvimento de software, ou uma nova ferramenta ou metodologia que possa melhorar a experiência do desenvolvedor. Isso me proporciona a oportunidade de descobrir o que são, para que servem e como funcionam coisas como aquela que vou comentar hoje: o Backstage.

Algumas das preocupações que afetam as empresas que possuem equipes de desenvolvimento de software estão relacionadas a como oferecer aos desenvolvedores uma boa experiência de trabalho, reduzindo o overhead com aspectos que não fazem parte de seu dia a dia, permitindo que se concentrem na melhor forma de transformar requisitos de negócios em código.

O Backstage, uma plataforma open-source criada pelo Spotify, pode ser descrito como uma ferramenta focada em aumentar e aprimorar a experiência e agilidade da equipe de desenvolvimento. Ela permite a criação de componentes de software de forma padronizada e facilita a governança dos serviços disponíveis. Isso possibilita uma rápida resposta a perguntas como "Qual equipe desenvolveu ou é responsável por esta API?", "Quais são os serviços desenvolvidos pela equipe X?", "Quais são as dependências deste componente?" e "Para que serve e como consumo esta API?".

Meu objetivo aqui não é apresentar em detalhes o Backstage (muitas pessoas já fizeram isso e de forma muito melhor do que eu poderia fazer), mas sim compartilhar um pouco do que aprendi ao trabalhar em uma PoC com o objetivo de avaliar a ferramenta. Não encontrei muito material relacionado à configuração da ferramenta para aproveitar os principais benefícios que ela oferece. Portanto, o primeiro ponto que abordarei aqui está relacionado à criação de templates de software.

Antes, porém, cabe revisar o passo a passo que utilizei para instalar e configurar o Backstage

O Backstage foi escrito em NodeJS e React, o que quer dizer que você precisa tê-los no seu ambiente antes de seguir com a instalação. Para isso, eu fiz o seguinte:

Instalei o Curl: ```lang-bash

apt install curl


![Instalando o curl no Ubuntu](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/f0dcphibbms4v0amka5t.gif)

- Daí instalei o **NVM**: 
```lang-bash


curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.3/install.sh | bash

E então instalei a versão LTS do NodeJS: ```lang-bash

nvm install --lts


![Instalando a versão LTS do NodeJS](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/xsyelabszmgrk7yov627.gif)

- Pra concluir, também instalei o **Yarn**: 
```lang-bash


npm install --global yarn

E o Git:



apt install git

Em tempo: eu fiz tudo isso no Ubuntu, então dependendo do ambiente que você tiver usando pode haver pequenas variações.

Feito isso, você já tem os requisitos necessários para instalar o Backstage, então o próximo passo é iniciar a instalação, usando o comando abaixo:



npx @backstage/create-app

Após concluir essas etapas, o Backstage estará instalado e pronto para ser executado. Para isso, basta acessar o diretório de instalação do Backstage (se você seguiu a recomendação, o diretório será chamado "backstage") e, em seguida, executar o comando:



yarn dev

Atenção! Talvez você receba algumas mensagens de erro relacionadas ao Git quando subir o Backstage pela primeira vez. Para resolver isso, basta inicializar o Git no diretório do Backstage, e fazer o commit dos arquivos de lá, usando o git init, e depois os comandos git add . e então o git commit -m“Primeiro commit”.

Pronto, o Backstage foi instalado e iniciado, e já pode ser acessado a partir da url http://localhost:3000. Assim que a página carregar, você verá isso:

Com o Backstage devidamente instalado, podemos iniciar a configuração dele

Configurando o banco de dados

Por padrão, o Backstage é iniciado com um banco de dados "in-memory", o que significa que todos os dados manipulados nele são armazenados na memória. No entanto, assim que o Backstage é interrompido, esses dados são perdidos. Então, a primeira coisa que eu recomendo fazer é configurá-lo para utilizar um banco de dados para armazenamento destas informações.

Se você já tiver um banco de dados que possa ser utilizado (eu usei o PostgreSQL), basta alterar o arquivo app-config.local.yaml, que está dentro do diretório do backstage, incluindo as configurações necessárias.

Ao abrir o arquivo em um editor, você verá o seguinte:

As configurações que você deverá incluir nele, para que possa utilizar um banco de dados como repositório são:



backend:
  database:
    connection:
      host: localhost
      port: 5432
      user: postgres
      password: secret

Importante! Não esqueça de alterar as configurações do host, port, user e password de acordo com as do banco que você irá utilizar!

Depois de alterado, o arquivo deverá estar assim:

Para aplicar as novas configurações, é só parar o Backstage (Control+C) e iniciá-lo novamente (yarn dev).

Configurando os repositórios

O Backstage possui um arquivo chamado app-config.yaml. É nele que estão as configurações que iremos alterar.

Configurando o Github como repositório

Ao abrir o arquivo app-config.yaml, localize a seção integrations:

Você verá que o arquivo já está preparado para integrar com o Github - para isto basta apenas criar uma variável de ambiente com o nome GITHUB_TOKEN, e atribuir a ela o seu Personal Access Token.

Se você não quiser ou não puder criar uma variável de ambiente, pode inserir no próprio arquivo o seu token no lugar da variável GITHUB_TOKEN. Dessa forma, ele ficará assim:

Configurando o Azure como repositório

A configuração do Azure é basicamente a mesma que a do Github. A diferença é que como não existe uma seção para o Azure dentro da seção integrations, você terá que criá-la. E, do mesmo jeito que no Github, você poderá utilizar uma variável de ambiente para armazenar seu Personal Acess Token (informando ela no arquivo de configuração), ou inserir o token diretamente no arquivo.

Dica: O host do Azure é o dev.azure.com!

Se fizer usando a variável de ambiente, seu arquivo ficará assim:

Pronto! Com essa configuração já podemos partir para o próximo passo: demonstrar como criar templates de software para o desenvolvimento de novas aplicações. Mas isso é assunto para o próximo post.

Bem, por hora é isso... como sempre, comentários, críticas e sugestões são sempre bem-vindos.

Grande abraço, e até mais!

Sobre Kubernetes e a utilização do K6 para efetuar testes de carga/desempenho em um Pod no Cluster do K8s - Parte 1

Eduardo Bueno — Mon, 12 Dec 2022 03:10:58 +0000

Oi, eu sou o Edu!

Não sou um especialista em Kubernetes (ou K8s, como a comunidade gosta de chamá-lo). Nas palavras do meu amigo Ricardo Tenório, quando se trata de mexer com este orquestrador de contêineres eu "sou apenas um menino".

Mas, para resolver um problema (obter, a partir de testes de desempenho/carga, indicadores importantes sobre a capacidade de carga e transações que uma aplicação pode suportar), veio a oportunidade de entender mais a fundo esta ferramenta cuja finalidade é "facilitar a implantação e o gerenciamento de sistemas distribuídos, enquanto se beneficia do melhor uso de recursos de memória e processamento que os contêineres possibilitam", então resolvi aproveitar esta chance para, quem sabe, passar do nível Aprendiz para o nível Praticante.

Daí comecei a pesquisar sobre o assunto e acabei "caindo" no excelente vídeo do Jeferson Fernando da LINUXTips:

Esse vídeo me ajudou muito, pois apresentou de forma bastante clara os conceitos-chave do K8s, e também seus principais comandos. E isso me deu confiança para configurar o ambiente que eu pudesse utilizar para executar os testes que precisava!

Em relação aos testes, eu já havia utilizado o Postman e o RESTfull Stress para executar este tipo de teste, mas o cenário naquela ocasião era um tanto diferente: lá eu não estava testando uma aplicação hospedada dentro de um cluster no K8s! E, embora o princípio do teste seja o mesmo para este caso, o fato de haver mais camadas entre o cliente que faz a requisição e a aplicação a ser testada pode mascarar seus indicadores - vamos lembrar que, em linhas gerais, uma aplicação hospedada no K8s está rodando dentro de um Container que, por sua vez, encontra-se dentro de um Pod no Cluster.

Então fui pesquisar formas de executar estes testes de dentro do Cluster, e acabei encontrando uma alternativa que envolve o uso do K6 (ferramenta que eu também já conhecia e havia utilizado, e que gosto muito porque entre outras coisas ela permite a criação de scripts de teste em javascript, além da execução dos testes tanto de forma manual - na máquina do desenvolvedor - quanto automaticamente, como um passo dentro de uma pipeline de CI/CD, por exemplo).

No próximo post vou descrever em detalhes tudo o que fiz para resolver meu problema utilizando o K6, porém deixo aqui um gostinho do resultado final da minha PoC pra vocês ficarem curiosos. 😂

Abaixo, o resultado de um teste de carga em uma aplicação, executando o K6 localmente a partir da CLI do VS Code:

E o resultado do mesmo teste, só que executado dentro do Cluster do K8s:

Bem, por hora é isso... como sempre, comentários, críticas e sugestões são sempre bem-vindos.

Grande abraço!

Falando um pouco sobre a experiência exigida e a necessária para atuar com desenvolvimento de sistemas...

Eduardo Bueno — Wed, 10 Aug 2022 01:25:00 +0000

Oi, eu sou o Edu!

O tema deste post surgiu a partir de um comentário que li sobre o conteúdo da publicação de uma vaga de desenvolvedor nível Sênior, onde - ao contrário do que costumamos ver normalmente - não exigia-se nenhum tempo de experiência para os requisitos apresentados.

Ao invés de declarar algo como "Mínimo de 5 anos atuando com a linguagem XPTO", "Pelo menos 3 anos de experiência com banco de dados relacional XYZ", e outras coisas do tipo, a descrição dos requisitos era mais objetiva, apresentando cada um apenas como "Experiência com a linguagem XPTO", "Experiência com banco de dados relacional (XYZ)", etc.

A descrição dos requisitos - uma lista não tão pequena, porém sucinta - gerou o seguinte comentário: "Achei interessante a diferença [em relação ao nível de desenvolvedor] ser nos requisitos técnicos em vez de tempo de experiência".

De fato, o que vemos com frequência (principalmente em vagas que pedem nível de experiência mais avançado, como Sênior, por exemplo), é a especificação de um "tempo mínimo de experiência requerido" - normalmente em anos. Por isso a surpresa do amigo que fez o comentário no nosso grupo do Whats.

O comentário dele, embora não direcionado a mim, acabou chamando minha atenção, e então achei por bem dar minha opinião sobre o tema. E, como algumas pessoas que leram o que escrevi entenderam que aquilo poderia gerar um bom tema para discussão, resolvi trazer aqui a essência do que escrevi lá - não está escrito exatamente da mesma forma porque aqui tive um pouco mais de tempo para revisar o texto, mas ele dizia basicamente o seguinte:

Normalmente quando escrevem sobre "ter experiência com algo", seja uma linguagem, ferramenta ou tecnologia, entende-se "ter vivência em projetos reais" - então fica meio que implícito o "tempo mínimo de experiência", considerando ser bem incomum encontrarmos um dev com 2, 3 anos de experiência que já tenha atuado em projetos que fizeram uso de todos os recursos detalhados na vaga (que apresentava, entre outros, os seguintes itens: experiência com C# e .NET Core, experiência com banco de dados relacional - SQL Server ou PostgreSQL, experiência com banco de dados não relacional - MongoDB, Cosmos ou Atlas, experiência com Git e Git Flow, experiência na construção de testes unitários automatizados, experiência com design patterns - singleton, factory, strategy, etc, experiência em clean code, conhecimentos de arquitetura básica e seus princípios - SOLID, ACID, conhecimentos em CI/CD, metodologias ágeis e estruturas de dados, e por aí vai...).

E, aproveitando o gancho - do assunto em questão, mas também de alguns memes e comentários que havia visto recentemente, sobre a diferença entre o que era exigido em uma entrevista, e o que o dev teria que lidar no dia-a-dia de trabalho, complementei:

Eu mesmo não tive tanta vivência em projetos que exigiam tal nível de conhecimento (considerando o tempo que estou trabalhando na área - quase 30 anos!), porque a maioria dos projetos onde atuei - em empresas dos mais diversos portes e segmentos - não ia muito além de CRUD's, arquiteturas mais básicas, uma ou outra regra de negócio mais complexa, e a preocupação em gerar relatórios e consultas com grande volume de dados de forma a não impactar no I/O das transações no banco relacional.

De vez em quando acaba aparecendo algo mais diferentão - um ETL aqui, uma Máquina de Estado ali, uma integração com API's e Webservices de Terceiros (que normalmente não têm suporte a JSON, só a XML, e com documentação porca), troca de arquivos TXT via FTP, implementação de cache ou messageria... mas, em geral, não passa muito disso não.

Projetos que fazem uso de Arquitetura Hexagonal, CQRS, e outras coisas mais complexas, como Microsserviços, são bem mais difíceis de aparecer... primeiro, porque na maioria das vezes trazer este nível de complexidade vai significar construir um canhão para matar uma mosca - por que construir algo usando a arquitetura da Netflix, por exemplo, se o consumo da aplicação será equivalente ao volume de um Pluto TV da vida (e olhe lá)? Brincadeiras à parte, esse nível de complexidade dentro de um projeto acarreta em custos bastante altos - Infraestrutura, pessoal especializado, recursos para monitoramento, etc. Segundo, porque na imensa maioria dos casos, seremos alocados em projetos existentes (os famigerados legados) e que não nasceram fazendo uso da tecnologia mais atual ou o hype do momento. Como vocês devem saber, em pleno 2022 ainda tem muita empresa com projetos rodando - e atendendo as necessidades delas - em PHP, ASP Clássico, VB, Delphi... até Java! (hahahahaha, tô brincando, mas não podia perder a piada! rsrsrs)

MAS... isso não quer dizer que devemos ficar apenas no feijão-com-arroz - é bom conhecer coisas novas, o que o mercado está usando, outros tipos de linguagem, arquiteturas que vão além do padrão MVC, boas práticas de programação como Clean Code, os principais Design Patterns, etc... porque quando a oportunidade aparecer, poderemos bater no peito e dizer "eu conheço esse assunto aí, embora nunca tenha trabalhado num projeto que demandasse a implementação dele, mas deixa comigo que eu desenrolo", sem medo de ser feliz!

(É por isso também que tô sempre buscando algo novo para aprender - agora, por exemplo, estou estudando para conhecer mais a fundo tudo o que a Cloud da AWS oferece, além de um pouco de Flutter e K8s...)

Bom, o que eu quis passar naquela resposta (e aqui), e para qualquer dev (principalmente aqueles iniciantes que se sentem inseguros, achando que nunca terão capacidade para aprender tanta coisa) é que o único jeito de adquirir experiência é colocando a mão na massa, atuando em projetos reais, lidando com problemas reais, batendo cabeça (não no sentido literal, por favor), aprendendo que nem tudo o que vemos na teoria se aplica na prática, o que o que usamos pra resolver no projeto X não se aplica no projeto Y... e que isso leva tempo - não é algo que seja possível condensar num sprint, num bootcamp de 12 semanas! E, como dizem, tá tudo bem!

É isso... como sempre, comentários, críticas e sugestões são sempre bem-vindos! Escrevam, será bacana discutir esse assunto com vocês.

Grande abraço, e até a próxima!

Você sabia que é possível usar Matemática para detecção de fraude?

Eduardo Bueno — Wed, 14 Oct 2020 01:55:04 +0000

Oi, eu sou o Edu!

Lá no distante mês de fevereiro eu publiquei aqui no DEV um artigo que falava sobre a Lei do Primeiro Dígito, ou Lei de Newcomb-Benford, mas fiquei devendo uma explicação sobre como a tal lei poderia ajudar a identificar possíveis anomalias dentro de uma empresa.

Pois bem, imagine que você trabalha em uma empresa, e que é responsável por analisar e aprovar as solicitações de reembolso (de um almoço, um táxi, uma viagem, etc...) feitas pelos funcionários. Supondo que você receba 2 ou 3 solicitações de reembolso por mês, de 2 ou 3 funcionários, esta parece ser uma tarefa simples, certo? Agora, imagine que você deva analisar todas as solicitações de reembolso enviadas por 100 funcionários, ao longo de um mês, para que os reembolsos sejam efetuados o mais breve possível... parece mais difícil, não?

Mas... e se você usasse a Matemática - ou melhor, a Lei de Newcomb-Benford - para te auxiliar nesse processo, ajudando não só a completar esta atividade de forma mais rápida, mas também fazendo uso de um método que indique quais solicitações dentre tantas devem ser analisadas com mais atenção, devido a um possível erro ou, quem sabe, uma fraude? Seria melhor do que um "hmmmm... acho que tem alguma coisa errada com essa nota aqui...", certo?

E como fazer isso? Uma das formas seria comparar as ocorrências dos primeiros dígitos das Notas Fiscais anexadas às solicitações com as probabilidades de ocorrência segundo o cálculo proposto pela Lei. Vejamos um exemplo:

Imagine que eu tenha um lote de 100 solicitações, cada uma com uma Nota Fiscal. Assumindo que todas elas estão ok, ou seja, são verídicas, após agrupá-las de acordo com seu primeiro dígito, teríamos a seguinte distribuição:

A primeira coisa que nos chama a atenção ao analisar o gráfico é a discrepância entre o percentual esperado de ocorrências onde o primeiro dígito é igual a 1 e o percentual encontrado no lote analisado - é quase o dobro de ocorrências!

Outro ponto a ser observado é na diferença entre os percentuais esperados e encontrados para outros dígitos - atentem para os dígitos 3, 5 e 8, e no fato de o percentual encontrado para a ocorrência destes ser de menos da metade do percentual esperado.

Tais fatos podem sugerir - veja bem, PODEM sugerir - que exista algum problema nas solicitações de reembolso cujo primeiro dígito do valor a ser reembolsado seja igual a 1... mas... e agora?

Será que é possível dizer que algumas solicitações de, por exemplo, 30, 50 e 80 reais tiveram seus valores adulterados para, respectivamente, 130, 150 e 180 reais para beneficiar indevidamente quem as solicitou?

Aqui não há como afirmar isso, pois neste caso a Matemática só está nos ajudando a identificar que, de fato, existem anomalias que podem ou não ter uma explicação razoável para terem ocorrido. De todo modo, sem passarmos uma lupa em cada uma destas solicitações de reembolso também não há como garantir que não haja qualquer problema com elas - ainda mais se considerarmos que os valores utilizados neste post são reais, e correspondem a algumas das solicitações de reembolso de combustível feitas por alguns parlamentares da Câmara dos Deputados de todo o Brasil.

Bem, acho que o exemplo acima já dá pra dar uma ideia de como a Matemática pode nos ajudar a identificar possíveis casos de fraude, além de nos direcionar para a análise destes casos - aqui, sugerindo que olhemos com mais atenção para pouco menos de 60 solicitações, em vez das 100 que compõem o lote todo, fazendo com que nosso trabalho seja mais rápido e assertivo!

Espero que tenham gostado do texto (comentários, críticas e sugestões são sempre bem-vindos), e que voltem aqui outras vezes.

Grande abraço, e até a próxima!

(Em tempo: os valores das solicitações de reembolso foram extraídos do site Jarbas Dashboard e selecionados aleatoriamente - o Jarbas é uma ferramenta de visualização de dados - no caso, dados da Câmara dos Deputados e outras instâncias do Governo - minerados por um robô desenvolvido pelo pessoal do projeto Operação Serenata de Amor, que utiliza Inteligência Artificial para Controle Social da Administração Pública que vale a pena dar uma conferida!)

Sobre a Lei de Newcomb-Benford, e sua relação com a Matemática

Eduardo Bueno — Sun, 09 Feb 2020 02:45:29 +0000

Oi, eu sou o Edu!

Uma das muitas coisas bacanas que aprendi no curso de Big Data de Lousa (lá no Prandiano - Museu da Matemática, em São Paulo/SP) foi a Lei de Newcomb-Benford (ou Lei de Benford, ou ainda, Lei do Primeiro Dígito, como é mais conhecida), e como ela pode ser aplicada para nos ajudar a identificar, por exemplo, possíveis anomalias num processo de auditoria.

Em linhas gerais, a Lei trata de um fenômeno que diz que há uma probabilidade de, num conjunto de números quaisquer não-aleatórios, o número 1 ocorrer um maior número de vezes que o número 2, e este ocorrer mais vezes que o 3, e assim sucessivamente, até o 9.

Neste post não entrarei em detalhes sobre tal fenômeno (e nem sobre as observações do astrônomo Newcomb e do físico Benford relativas a ele), mas deixarei os links para seus respectivos artigos ao final do texto. O fato é que o fenômeno é real, e a probabilidade de cada um dos números de 1 a 9 aparecer como primeiro dígito pode ser demonstrada através do gráfico a seguir, e verificada a partir de um cálculo logarítmico.

Como pode ser observado no gráfico, a probabilidade da ocorrência do número 1 no primeiro dígito é de cerca de 30%, enquanto que a da ocorrência do número 9 é de aproximadamente 4%. Mas... como se calcula isso? E, mais importante, o que podemos fazer com estes dados?

Para calcular a probabilidade de frequência da ocorrência de cada número como primeiro dígito, é possível utilizar a seguinte expressão matemática (onde d corresponde a cada um dos dígitos de 1 a 9):

Aplicando a expressão ao número 1, obtém-se sua sua probabilidade de ocorrência como primeiro dígito em percentual, ou seja, 30,10%. Para o número 2, a probabilidade dele aparecer como primeiro dígito cai para 17,60%. E, para o número 3, pode-se verificar que há somente 12,49% de chance dele aparecer no primeiro dígito!

É muito legal isso, né?

Mas... e como usar toda essa informação para nos ajudar a identificar possíveis anomalias num processo de auditoria, como escrevi lá em cima? Bem, irei escrever sobre isso no próximo post. ;)

Espero que tenham gostado do texto (comentários, críticas e sugestões são sempre bem-vindos), e que voltem aqui outras vezes.

Grande abraço, e até a próxima!

Ah, já ia me esquecendo:

O astrônomo Simon Newcomb foi quem primeiro observou o fenômeno que descrevi no post, e publicou suas observações num artigo chamado "Note on the Frequency of Use of the Different Digits in Natural Numbers" no American Journal of Mathematics (Vol. 4, No. 1, pp. 39-40 ), em 1881.

Em 1938, o físico Frank Benford também percebeu tal fenômeno, publicando suas observações no American Philosophical Society (Vol. 78, No. 4, pp. 551-572), no artigo intitulado "The Law of Anomalous Numbers".

Antes de tudo, um pouco sobre mim...

Eduardo Bueno — Sat, 08 Feb 2020 19:58:09 +0000

Comecei a trabalhar com 14 anos como Atendente de Lanchonete no McDonald’s, e foi lá que aprendi a importância de ser um profissional responsável e comprometido - valores que me acompanham até hoje.

Ingressei na área de TI em 1995, no Banco Bradesco, e de lá pra cá tive a oportunidade de atuar em empresas dos mais diversos segmentos, como O Boticário, Coca-Cola, Fundação Pró-Sangue, Toyota, Adobe, Klabin e Repom, seja como desenvolvedor, consultor, coordenador de desenvolvimento ou agilista.

Como desenvolvedor, consultor e coordenador de desenvolvimento, tive a oportunidade de trabalhar com tecnologias diversas, como Microsoft .NET (VBNET e C#), Ruby, Python, Golang, MongoDB, Amazon Web Services, entre outras.

Como agilista (Scrum Master - PSM I e PSD I), tive o privilégio de participar, facilitar e promover a adoção do Scrum como metodologia ágil na Repom, UniPay, Hotel Urbano (hoje Jurb) e, por último, na Alelo.

Paralelo a estas atividades, em 2013 aceitei o desafio para compartilhar um pouco do meu conhecimento com os alunos da Fundação Bradesco, onde ministrei os módulos de Lógica de Programação, Modelagem de Dados, Banco de Dados, Programação Orientada a Objetos e C# no Curso de Informática desta Instituição.

De 2016 até o final de 2019, fui Especialista de Sistemas na Alelo, atuando principalmente como desenvolvedor/administrador da plataforma Qlik Sense - solução de Business Intelligence que permite a análise e o gerenciamento de dados para conduzir insights e impulsionar as decisões de negócios dos clientes do Alelo Auto utilizando dashboards e KPI's - e também como agilista, auxiliando a fomentar a adoção da cultura ágil nas áreas de TI e Produtos.

No início de 2019 pude voltar às minhas raízes, exercendo o papel de Analista de Sistemas Sênior na PagBem, programando em .NET (C#) e Angular, aprendendo um pouco mais sobre API's, AWS e outras coisas bacanas, mas sem deixar de contribuir como líder técnico e de apoiar a gerência na coordenação dos times de desenvolvimento.

E desde a metade de 2021 faço parte do time Modal, primeiro atuando na Vaivoa (braço de Ed Tech do banco), apoiando o desenho e implantação do Programa de Formação de Desenvolvedores Backend (C# e .NET), e atuando na capacitação, mentoria e liderança técnica de novos profissionais da área de desenvolvimento de sistemas utilizando tecnologias e ferramentas como .NET, C#, Docker, Azure Functions e DevOps, Redis, Swagger, PostgreSQL, Dapper, Entity Framework, SonarQube e Horusec. E atualmente coordenando o time de Arquitetura de Inovação do banco Modal.