Posts on Dev On Track!

E era um escritor que não sabia escrever

Sun, 11 May 2025 22:00:00 +0000

O conto que você lê abaixo foi escrito por mim em 2014, para um concurso da faculdade. Infelizmente eu não ganhei nada, só a lembrança de me divertir muito escrevendo hahaah

E era um escritor que não sabia escrever.

Simplesmente, um belo dia, acordou, como sempre fazia, lavou o rosto e se olhou no espelho, contemplando as persistentes olheiras que estavam entalhadas feito mármore em seu rosto.

Era um homem relativamente jovem. Seus olhos acompanharam sua fisionomia, passando pelos seus cabelos desgrenhados, seus olhos escuros e seu nariz reto. Parou em seu queixo quadrado.

É, até que tenho um queixinho bonitinho, pensou.

Isso lhe deu motivos suficientes para acreditar que o dia seria ótimo. Afinal, não são muitas pessoas que tem o queixo charmoso, ou ao menos era isso que ele pensava. Deu um sorriso forçoso para si mesmo refletido no espelho, como que para reafirmar o pensamento mentalmente. Enxugou o rosto e foi se vestir. Abriu o guarda roupa e se arrependeu logo em seguida, pelo monte de roupas que caiu a seus pés. Pegou a primeira camiseta que estava menos amassada em sua frente.

Foi até a cafeteira, colocou água, o pó do café, ligou e esperou ansiosamente, tamborilando os dedos na bancada. Tentou assoviar, mas soou estupidamente deprimente. Realmente não estava se sentindo tão contente assim. Cruzou os braços e pensou no que faria naquele dia. Não haveria nada de novo, provavelmente. A busca por algo em sua agenda mental demorou tempo suficiente para o café preencher a pequena garrafa. E ainda assim, nenhuma ideia.

Suspirou e pegou a garrafa. Procurou sua xícara favorita, aquela que tinha desenhos de pequenos pássaros pretos que voavam sobre uma grama preta e branca, em direção a um por do sol, porém como não estava em seu armário de costume, se dirigiu até a bagunça de louças na pia e procurou até encontrá-la. Lavou rapidamente e serviu seu café. Sentou-se a mesa olhando a xícara. Olhando a fumaça quente sair do café, produzindo aquele efeito de imagem tão bonito que ele tanto gostava.

Observou a xícara até o café esfriar. E depois, sem perceber, continuou pelo menos quinze minutos ali, estático, com os pensamentos girando em espiral, tal como o vapor do café, como fazia todos os dias. Pensou sobre os pássaros, será que eles possuíam algum objetivo ao voar? Será que eles voavam com algum destino pré-definido, ou simplesmente aproveitavam a sorte de planar nos ares para fazê-lo sem pensar muito, apenas pelo prazer do ato?

Ele, por breve instantes, desejou ser um daqueles pássaros. Sorveu o café ainda pensando em tudo aquilo. Estava terrível, sem açúcar. Mas o autor se sentia desanimado demais para se levantar e pegar, de modo que tomou daquela maneira mesmo. Passou as mãos pelo rosto pesarosamente e se levantou, passando pelo calendário pregado ao lado da janela. Voltou de costas e parou de frente ao papel que denotava seus febris e escassos compromissos.

Havia um post it, de berrante tom alaranjado, fixado na data que ele demorou a reconhecer como sendo o dia seguinte. Nele estava escrito palavras que fizeram seu estômago revirar. “Entrega do tema do livro”. Ele encostou-se à bancada para não cair. Um dia? Como havia deixado aquilo acontecer?

Correu de encontro ao seu computador. Havia cabos enrolados se esgueirando para fora da mesa por todo o chão, tal como cipós na floresta tropical, fazendo-o usar toda sua agilidade e perspicácia para não se enroscar e levar ele mesmo e o pobre computador para o chão.

Sentou na cadeira, estafado pela ansiedade, e pressionou o botão “Power” do computador. A luz de LED acendeu, e ele encarou ansiosamente como se isso ajudasse o computador a se ligar mais rápido. A tela se acendeu e ele desviou o olhar rapidamente, como se estivesse acompanhando um interessantíssimo jogo de ping pong, ou talvez de tênis, entre o monitor e o gabinete. Seu computador, que era uma relíquia dos anos 2000, gemeu em protesto – e como que para testar a paciência do autor, ele demorou mais do que o de costume a ligar. O homem se pegou tamborilando os dedos novamente na mesa, dessa vez com maior velocidade.

A tela apresentou sua área de trabalho. Ele gemeu de alivio. Pegou o mouse e abriu seus documentos. Ali estava, o arquivo escrito “Sem título”. Clicou duas vezes com uma impaciência feroz e o arquivo demorou quase trinta segundos para se abrir. Isso o fez passar as mãos no rosto quase como que para arrancar os olhos, tamanha impaciência. Quando a página finalmente se abriu, ele apertou os olhos ao contemplar a página brilhante, que continha vitoriosamente em seu topo os seguintes dizeres: “E era uma vez…”. No resto da página, havia um branco de uma pureza que ao entrar na retina do homem estranhamente se transformou em terror puro. A gota de suor que escorreu em sua têmpora parecia rir de sua cara naquele momento.

Ele fechou a página. Não era possível. Ele se lembrava de ter escrito vinte ou doze páginas, no mínimo. Era algo com o número dois, tinha certeza absoluta. Talvez fosse seu computador que estava com problemas, talvez se ele atualizasse a pasta e abrisse de novo…

E abriu. E durante os trinta segundos de espera, fechou seus olhos com força. Respirou fundo. Contou até trinta. Abriu de novo para encarar o inocente “E era uma vez” ali, acenando para sua burrice. Mas, como aquilo acontecera? A resposta veio como um estalo. O autor recordou-se de estar escrevendo um conto de terror. Havia realmente duas páginas, somente duas. E ele estava discutindo com seu íntimo sobre a chatice de contos de terror e como são fáceis de serem feitos. Basta colocar um fantasma pulando na cara do protagonista e gritando “Buuu” e pronto, estrago feito. Pessoas assustadas com sucesso. Mas detestava esses clichês que, ao escrever, o encaravam e zombavam de seu talento, que, aliás, era impressivo. Mas e aquelas palavras naquela página? Um conto infantil, sério? E onde estava a genialidade que despertaria sentimentos de espanto e profunda admiração nos críticos? Mal podia acreditar. Ele devia estar fora de si quando fez aquilo. Um dia apenas. Ele conseguiria fazer isso. Só precisava entregar no máximo cinco páginas para a editora dar sinal verde para ele continuar escrevendo.

Estalou os dedos e pegou a garrafa de café, servindo mais da bebida já fria na xícara de pássaros. Os pássaros pareciam acenar pra ele, que resistiu ao impulso de perder tempo observando a xícara novamente, tomando o café quase todo de uma vez ainda sem o açúcar. Em compensação, ficou olhando a página em branco por quase três horas.

Ok, a situação estava ficando preocupante.

Respirou fundo novamente e resolveu ir lá fora, tomar um ar. Era assim que as ideias interessantes surgiam, não é? Tentou abrir a porta, mas o bocado de papeis embaixo do carpete dificultou a tarefa. Uma rápida olhada o fez empurrar o monte embolorado, que identificou brevemente como sendo contas, para longe. Quando abriu a porta, a claridade do dia quase o cegou. Se o mundo lá fora costumava ser tão claro assim ele não saberia, com as horas do dia dedicadas em ficar em casa e sair somente à noite.

Resolveu dar uma volta pelo quarteirão e buscar elementos simples para compor sua narrativa. Olhou um cachorro correndo pela calçada. História sobre um cachorro? Um cachorro falante que discutia política na TV. Ele poderia até ter bigode. Ah não, péssima ideia. Viu um menino correndo e brincando com uma imaginária espada de aço, na realidade feita de madeira. Uma história de heróis, onde eles lutavam na Era Medieval e eram fortes e musculosos. Não, isso é muito raso e fácil. Ele amava um desafio. Ou ao menos quando conseguia fazê-lo.

E então, subitamente, o autor começou a correr. Não sabia definir o motivo, talvez fosse o desespero falando mais alto. Ele desejou fugir das responsabilidades de ser adulto, ter bagunça no guarda roupa e contas sob o carpete. Correu e correu, até ficar ofegante. Isso aconteceu no fim do quarteirão. Olhou para trás e viu sua casa a quase 30 metros de distância. Arfando, quase se arrastou de volta para dentro. Iria escrever sobre os pássaros, estava decidido.

Sentou na frente do computador e começou a digitar, digitou furiosamente, conectando as frases como peças de um incrível quebra cabeça, e continuou digitando até se dar por conta que aquilo estava terrível, e segurando o botão de apagar jogou fora mais quatro horas de trabalho.

Ele ficou ainda mais desesperado. Olhou para o relógio, sentindo a pressão surda e esmagadora do prazo se esgotando esgueirando-se sobre seus ombros. Levantou-se, lavou o rosto e ao se olhar no espelho não achou seu queixo tão bonitinho assim. Tomou um banho que mal demorou cinco minutos, e praticamente correu até o guarda-roupa. Jogou todas as roupas no chão e começou a dobrá-las, procurando sua camiseta da sorte que possuía a foto de um golfinho. Passou na cozinha e lavou as louças em uma velocidade absurda, refletindo o nervosismo que o atormentava. A aquela altura, a fome também o atormentava. Esquentou coisas indefinidas que moravam em sua geladeira e mastigou impetuosamente, pensando no infortúnio de ser um terrível escritor, com um talento incrível.

Soou como um tiro. Um estalo em sua mente. Foi como se aparecesse um arco-íris em um céu nublado, como se fosse a luz no fim do túnel, como se ele fosse cego e visse a mais bela flor em sua frente, apenas esperando para ser cheirada. Tropeçou até a mesa novamente, porém, dessa vez sentou-se com a maior calma desse mundo. Agora, ele tinha absoluta certeza que daria certo. Abriu uma nova página, fechou os olhos por trinta segundos, pensando na salvação que sua ideia carregava. Ao abrir os olhos, lá estava a página: branca, imaculada, esperando que ele a preenchesse com todo o seu inenarrável talento.

Digitou a frase no topo da página, lentamente, letra por letra, apreciando o sabor da vitória:

“E era um escritor que não sabia escrever.”

Migrando blog estático do Jekyll para o Hugo

Tue, 06 May 2025 22:00:00 +0000

Quando pensei em criar esse blog, um dos pré-requisitos era ter agilidade e facilidade com o setup. Eu queria focar no que realmente importava: escrever. E nada melhor do que escrever em markdown, que é minha linguagem de markup favorita! Adoro a facilidade em ler, a simplicidade em formatar o texto e a leveza do formato. Com isso em mente, procurei algumas alternativas para colocar meu blog no ar.

Jekyll vem para o resgate!

Em minhas pesquisas notei que o pessoal gostava muito de usar Jekyll. O Jekyll, que é escrito em Ruby, inclusive é a engine por trás do Github Pages - que inclusive era um dos caminhos iniciais que eu estava buscando para publicar meu conteúdo. No geral, Jekyll pareceu bem popular e encontrei diversos exemplos e templates já criados para criar meu próprio blog. Ao configurar a primeira versão do blog, não tive grandes dificuldades. Confesso que a parte mais complicada foi me adaptar com liquid, que é a engine de templates usada pelo Jekyll. Liquid usa uma combinação de objetos, tags e filtros para controlar o conteúdo que será mostrado. Então, por exemplo, a minha página padrão do blog era um arquivo chamado default.htmlcom o seguinte conteúdo:

---
layout: default
permalink: /404.html
---
<!DOCTYPE html>
<html>
 {% include head.html %}
 <body>
 {% include header.html %}
 <div class="page-content">
 {{ content }}
 </div>
 {% include footer.html %}
 </body>
</html>

Na prática, é aquele tipo de configuração que não é feita múltiplas vezes: configurou uma vez, o dinamismo da ferramenta te possibilita não precisar realizar mais ajustes no template. Com isso, o restante da configuração geral do blog foi bem tranquila, e a medida que eu ia escrevendo novos posts me preocupava somente com o texto em si - ainda mais considerando a engenhosidade de buildar e fazer deploy utilizando o github actions ⚡️

Algum tempo depois…

Com o passar do tempo, percebi algumas peculiaridades do Jekyll. Uma delas foi a incompatibilidade que enfrentei com o Ruby: Lembro que atualizei a versão do Ruby na minha máquina para outro projeto e acabei quebrando o funcionamento do Jekyll local. Depois de muita pesquisa vi que ocorreu um certo drama com o fato que a principal gem que sincroniza com o Github Pages não tinha planos de dar suporte para o Jekyll 4. 👀 Outro ponto que não me agradou foi o quão custoso era instalar o ambiente em Ruby, além do estilo de gerenciamento de dependências que o Jekyll fazia - algo que me soava desnecessariamente complicado.

Fiquei um bom tempo sem postar - life happens! 🥸 - mas recebi um lindo incentivo em formato de conta bem salgada para pagar com o valor desse domínio. Fiquei com preguiça em voltar pro Jekyll considerando todos os pontos anteriores, então…

Hora de fazer a reforma!

Pesquisei sobre novos frameworks e encontrei o Hugo - que afirma ser o “framework mais rápido do mundo para construção de sites”. Li a documentação e me pareceu bem simples, e ao mesmo tempo, bem similar com o que eu já havia me acostumado com o Jekyll. O Hugo é open source e escrito em Go (que eu até aprendi recentemente), e promete bastante flexibilidade na criação de conteúdo.

Então, com muita coragem no coração, decidi encarar a migração. Usei a estratégia de criar uma nova pasta e configurar o novo projeto Hugo do zero, adicionando as funcionalidades que eu mais queria uma por uma. Escolhi um novo tema, configurei e fiz pequenos ajustes até ficar do meu agrado, depois fui adicionando minhas páginas com os posts quase que uma a uma. Como elas já estavam em markdown, foi bem tranquilo - tive que fazer pequenos ajustes convertendo algumas tags liquid para o novo formato correto.

Uma das partes mais difíceis desse processo de migração foi configurar as linguagens múltiplas do blog, já que eu escrevo os posts em ambos inglês e português. Mas para resolver esse problema foi até simples: Organizar meu conteúdo e fazer a seguinte configuração no arquivo hugo.toml:

[languages]
 [languages.en]
 contentDir = 'content/en/'
 languageName = '🇬🇧 English'
 weight = 1
 [languages.pt-BR]
 contentDir = 'content/pt_BR/'
 languageName = '🇧🇷 Português'
 weight = 2

Com isso e mais alguns ajustes no arquivo de deploy, o meu blog estava on - e realmente mais rápido do que nunca! 🚀

Aplicando Método Cientifico no Desenvolvimento de Software

Thu, 23 May 2024 08:00:00 +0000

Às vezes (na verdade, com muita frequência) é fácil ficar preso em um enigma de programação durante a codificação, depuração ou solução mental de um problema. Especialmente nos estágios iniciais de senioridade, as pessoas tendem a encarar um problema de programação (como corrigir bugs ou executar testes…) de frente, pensando uma solução provável, experimentando-a e verificando se o problema foi resolvido ou não repetidamente. Nesse sentido, a aplicação de métodos científicos a esse processo de solução de problemas pode ser benéfica na engenharia de software.

O que é método científico?

O Método Científico é uma técnica empírica usada para construir uma hipótese científica. Essas palavras bonitas significam simplesmente: usando a lógica, construímos uma hipótese para explicar um ocorrido. Este método envolve observação baseada no ceticismo (uma vez que suposições cognitivas podem distorcer a interpretação das observações). Após a observação, questões são levantadas e as respostas são coletadas por meio de testes e experimentos. Esta metodologia é útil em vários campos, incluindo investigação científica, ciências naturais e, como veremos a seguir, até engenharia!

Esta técnica consiste nas seguintes etapas:

Observação/Pergunta: O método científico começa com uma pergunta ou questionamento sobre algo.
Pesquisa sobre o tópico: Antes de começar e buscar uma solução em potencial, são realizadas pesquisas para aprender mais sobre o assunto e coletar referências.
Hipótese: Crie um palpite fundamentado sobre a resposta esperada da sua observação/questionamento proposto.
Testar a hipótese com um experimento: Verifique se sua hipótese é válida realizando um teste justo, alterando um fator de cada vez e mantendo as mesmas condições de teste para verificar o resultado final.
Analisar dados: Analise os dados coletados para determinar se eles apoiam ou refutam a hipótese.
Tirar uma conclusão: Determine se a hipótese é aceitável com base na análise dos dados.

Essas etapas são realizadas em ambiente controlado e monitorado, o que significa que somos capazes de observar possíveis variáveis que podem interferir no resultado. Essas variáveis podem ser:

Variáveis de controle: Também conhecidas como “variáveis constantes”, são variáveis que são mantidas iguais durante o experimento.
Variáveis independentes: Variáveis ou condições que podem ser ajustadas para afetar o resultado do experimento.
Variáveis dependentes: Essas variáveis são medidas ou observadas em como respondem com base nas alterações feitas nas variáveis independentes.

OK, mas o que isso tem a ver com desenvolvimento de software?

Você deve estar se perguntando o que o método científico tem a ver com o desenvolvimento de software. À primeira vista, pode parecer uma incompatibilidade - afinal, pode-se argumentar que a ciência trata do estudo do mundo natural, enquanto a codificação trata de ficar encurvado na frente de um computador escrevendo… código. Mas pensa bem! Os princípios do método científico são surpreendentemente relevantes para o trabalho diário dos desenvolvedores de software. Vamos ver como.

Análise de erros

Usar técnicas do método científico para identificar e resolver bugs em um código é bastante útil. Aplicando as etapas acima:

Identifique um problema ou bug a ser investigado. Isso representa a hipótese. Por exemplo, “O programa trava e fecha inesperadamente”.
Se necessário, faça pesquisas adicionais sobre as ferramentas, linguagens, configurações e/ou estruturas utilizadas no programa em questão. Isso lhe dará mais experiências e conhecimento para o próximo passo.
Projete um experimento controlado para testar sua hipótese. Pensando na hipótese acima, você pode escrever testes unitários ou criar um reprodutor para o bug. O objetivo é coletar mais informações sobre o assunto e descartar possíveis variáveis que possam interferir no resultado.
Execute o experimento (por exemplo, execute o programa para observar a falha). Colete os resultados, possíveis comportamentos inesperados, variáveis…
Analise os dados, tentando correlacionar o resultado com as variáveis.
Se necessário, repita o experimento, alterando variáveis e/ou ambiente. Quando o potencial culpado for encontrado, a hipótese pode ser considerada resolvida.

As vezes, realizamos algo semelhante ao processo acima intuitivamente ao resolver um problema e isso é ótimo! A aplicação explícita (e consciente) dessas etapas pode melhorar a precisão da resolução do problema.

Desenvolvimento baseado em hipóteses

E se tratássemos cada recurso ou correção de bug como uma hipótese e, em seguida, projetássemos nosso processo de desenvolvimento em torno de testes e verificação dessa hipótese?

Este é o conceito conhecido como Desenvolvimento Orientado a Hipóteses (Hypothesis-Driven Development - HDD).

Semelhante às etapas do método científico apontadas acima, começamos definindo uma hipótese clara, como “A implementação deste recurso aumentará o uso do programa pelos dos usuários em 30%”. Depois disso, é criado um plano para testar a hipótese, como:

Implementar e implantar x, y e z como pontos-chave do recurso;
Realizar testes A/B para comparar a nova funcionalidade com o comportamento anterior;
Coletar dados sobre interação do usuário, métricas de desempenho, métricas de negócios… Com o plano criado, as mudanças são implementadas e o experimento é executado. Em alguns casos, uma simulação pode ser executada para conduzir o experimento, ou o novo recurso pode ser usado por uma pequena parcela de usuários por um período específico de tempo. Depois disso, os resultados são analisados e a hipótese é validada: se os resultados foram alcançados a hipótese foi confirmada e pode ser adotada, caso contrário, novas rodadas de experimento podem ser conduzidas com novas hipóteses.

Esta jeito de desenvolver pode parecer bem semelhante ao Test Driven Development (TDD). No entanto, tenha em mente que o HDD se concentra no desenvolvimento de recursos ou correções de bugs com base em hipóteses específicas e em como eles irão melhorar o sistema ou a experiência do usuário, enquanto o TDD enfatiza a escrita de testes unitários para alterações de código individuais para garantir correção e confiabilidade em menor escala.

Experimentação com diferentes algoritmos

Também podemos usar o método científico para comparar diferentes algoritmos para resolver um problema específico – e também determinar qual deles é o mais eficaz. Com uma hipótese como “O algoritmo A superará o algoritmo B em termos de precisão quando usado para prever o risco de crédito”, podemos projetar um experimento comparando ambas as opções de algoritmo usando dados de entrada, métricas de avaliação e usuários como dados de controle. Também é importante utilizar um ambiente controlado, para evitar que fatores externos influenciem os resultados.

Após a execução do experimento, o desempenho de cada algoritmo é coletado e analisado para determinar qual algoritmo é o melhor conforme sugerido pela hipótese. Também podemos expandir e refinar a hipótese, identificando limitações ou vieses no experimento e propondo explicações alternativas para os resultados (por exemplo, “O algoritmo A pode ter um desempenho melhor devido à sua capacidade avançada de lidar com dados não agrupados").

…e muitos mais!

Existem muitos outras propostas interessantes que podem se beneficiar do uso do método científico, como:

Revisão de código, ao avaliar a eficácia de diferentes soluções para resolver um problema específico
Priorização de recursos, ao determinar qual recurso tem maior importância e impacto dadas certas restrições
Análise de débito técnico, utilizando métricas para determinar qual débito técnico terá maior impacto positivo no projeto quando resolvido

Os benefícios de usar essas técnicas para resolver problemas é poder abordar problemas - e, como mostrado, não apenas preposições científicas! - com uma abordagem sistemática baseada em dados, isolando questões subjacentes e tendo um conhecimento mais completo do problema em questão. Experimente!

Leitura Adicional

Scientific Method - Wikipedia

Steps of the Scientific Method - Science Buddies

The scientific method and programming - Josh Peterson

Aprendendo GO com TDD

Sun, 25 Feb 2024 08:00:00 +0000

Nos últimos anos, o uso do Desenvolvimento Orientado a Testes (TDD) tornou-se cada vez mais popular no desenvolvimento de software. TDD é um estilo de desenvolvimento que enfatiza a escrita de testes automatizados do seu código antes mesmo de você escrever o código em si. Neste post, vou contar minha jornada aprendendo GO com TDD e como foi aprender uma nova linguagem de programação como uma desenvolvedora experiente.

Aprendendo GO com TDD: Uma Jornada de Descoberta

Como uma desenvolvedora experiente, dá pra perceber a importância de escrever testes automatizados para meu código antes mesmo de colocar a mão na massa. Por mais que eu ainda sinta alguma resistência nesse processo de inverter o fluxo “normal” de desenvolvimento (mais sobre isso depois), é inegável como escrever testes antes do código melhora o fluxo geral de escrita da lógica em si. Eu também estava ansiosa para aprender um novo linguagem de programação, a fim de manter meu cérebro fresquinho sobre tecnologias além daquelas usadas no meu local de trabalho. Para conseguir isso, decidi aprender GO com Test-Driven Development (TDD). Nesta postagem do blog, compartilharei minha jornada e os insights que obtive ao longo do caminho.

Contexto: Entendendo rapidamente o que é GO

Antes de mergulhar nos detalhes do aprendizado de GO com TDD, irei fazer uma breve introdução à linguagem de programação: GO é uma linguagem de programação de código aberto desenvolvida pelo Google em 2009. Ela foi projetada para ser eficiente, simples e fácil de usar, tornando-o uma escolha popular para o desenvolvimento de aplicações web e backend.

Por que aprender GO com TDD?

Existem dois principais motivos pelos quais decidi aprender GO com TDD:

Melhor qualidade do código: O TDD me ajuda a escrever um código melhor, forçando-me a pensar sobre os testes antes de escrever o código real. Isso garante que meu código seja testável e passível de manutenção, o que é especialmente importante ao trabalhar com uma linguagem como GO, que possui muitas funcionalidades integradas.
Compreensão mais profunda do GO: Aprender GO com TDD me ajudou a entender melhor a linguagem de programação. GO tem uma sintaxe bem diferentes ao se comparar com outras linguagens de programação, e o uso do TDD me ajudou a obter uma compreensão mais profunda de como esses recursos funcionam juntos.

Um guia muito bem-vindo

Para colocar a mão na massa de forma rápida, segui o incrível Leaning GO with Tests, que é um excelente recurso para aprender GO com TDD. O site fornece guias com passo-a-passo que te orienta no processo de aprendizagem, desde o básico até tópicos mais avançados. Foi muito útil seguir um tutorial tão bem descrito.

Desafios e percepções

Mesmo com um caminho claro pela frente, aprender GO com TDD teve seus desafios. Aqui estão alguns dos insights que tive ao longo da minha jornada:

A sintaxe do Go: Um dos maiores desafios que enfrentei foi me acostumar com a sintaxe do Go. Mesmo tendo experiência com sintaxes tipo Java e Python (essa última poderíamos argumentar que é bastante semelhante em certo sentido ao GO), ainda foi um pouco desafiador desligar o conhecimento prévio e se acostumar com a forma como o GO está estruturado. GO tem uma sintaxe única e um conjunto de recursos com os quais pode levar algum tempo para se acostumar. Por exemplo, a linguagem utiliza um estilo de programação funcional, que requer uma forma diferente de pensar sobre o código.
TDD te força a pensar em testes antes de escrever código: Um dos benefícios mais significativos de aprender GO com TDD é que ele me forçou a pensar em testes antes de escrever código. Isso me ajudou a escrever código mais robusto, modular e fácil de manter.
Escrever testes primeiro ajuda a identificar possíveis problemas antecipadamente: Ao escrever testes antes de escrever o código real, consegui ficar de olho e identificar possíveis problemas antecipadamente e corrigi-los antes que se tornassem problemas maiores. Isso me economizou uma quantidade significativa de tempo e esforço a longo prazo. Escrever testes antes do código também ajuda a garantir que meu código era sempre simples e fácil de entender.
O modelo de concorrência do GO é único: GO possui um modelo de concorrência integrado que permite processamentos paralelos. No entanto, isso também pode levar a race conditions (que é quando múltiplos processos concorrentes ou threads acessam e modificam dados compartilhados ao mesmo tempo, gerando comportamento inesperado) se não for tratado adequadamente. Ao escrever testes primeiro, é possível identificar esses casos antecipadamente e escrever um código mais robusto e tolerante a falhas.
Testando padrões de design: Escrever testes antes de escrever o código real me ajudou a escrever um código melhor, forçando-me a pensar primeiro nos testes. Isso também me permitiu aplicar padrões de design, como Injeção de Dependência (DI), para tornar meu código mais flexível e mais robusto.
Testes primeiro podem ser difíceis!: Uma limitação pessoal que senti nesta jornada foi o ato de pensar em testar primeiro em vez de codificar a solução inteiramente de uma vez. Foi um esforço muito consciente para combater a vontade de criar a lógica inteira antes dos testes. Parecia errado no começo, mas acho que no final peguei o jeito e ficou mais fácil.
Aprendendo novos conceitos: Esta foi a primeira vez que aprendi TDD com GO, por isso foi importante para mim aprender a linguagem à medida que avançava. Aprender uma nova linguagem de programação pode ser um desafio no início, mas definitivamente vale a pena o esforço. Os benefícios de aprender uma nova linguagem são muitos, incluindo aumento da produtividade e melhoria da qualidade do código.

Conclusão

Aprender GO com TDD foi uma experiência animadora e gratificante. Se você é um desenvolvedor que deseja melhorar seus conhecimentos, recomendo que experimente usar TDD ao aprender GO ou qualquer outra linguagem de programação.

Espero que esse post tenha fornecido alguns insights sobre como aprender GO com TDD. Se você tiver alguma dúvida ou comentário, sinta-se à vontade para entrar em contato comigo pelos comentários abaixo ou pelo LinkedIn. Happy coding! 🥳

Referências:

Leitura Complementar

Se você estiver interessado em aprender mais sobre TDD e GO, aqui estão alguns recursos adicionais:

Schematics Python: Visão Geral e Tutorial

Sat, 24 Jun 2023 08:00:00 +0000

O que é schematics?

Schematics é uma lib que auxilia no design, conversão e validação de estruturas de dados em python. Essa biblioteca elimina a necessidade de criar e manipular diretamente dados de payload para o contexto da aplicação.

Para começar, usamos um pip install assim:

pip install schematics

Neste exemplo, vamos ingerir um esquema de dados complexo usando Schematics. Os dados chegam em um formato json, conforme exemplificado abaixo:

{
 "_id": "641505586f0763093fe5de82",
 "index": 0,
 "guid": "3e591c0d-5812-4c1e-9062-91d67db36326",
 "isActive": True,
 "balance": "$3,657.06",
 "picture": "https://picsum.photos/200",
 "age": 22,
 "eyeColor": "brown",
 "name": "Whitehead Navarro",
 "gender": "male",
 "company": "ROUGHIES",
 "email": "whiteheadnavarro@roughies.com",
 "phone": "(843) 429-2875",
 "address": "934 River Street, Sparkill, New Mexico, 4866",
 "about": "Mollit enim aute sint enim ut eiusmod dolore dolore veniam. Esse ad consequat pariatur "
 "cupidatat qui deserunt proident minim irure. Proident labore minim ex voluptate ea ut excepteur "
 "duis ad minim quis incididunt labore. Laborum sit aliqua aliqua et ad qui qui quis ullamco. "
 "Voluptate voluptate consectetur nostrud amet enim. In Lorem voluptate fugiat duis. Ut proident "
 "ipsum minim do fugiat sunt laboris voluptate tempor aliqua aliquip deserunt sit.\r\n",
 "registered": "2018-08-26T04:14:49",
 "coordinates": [
 -0.642558,
 -154.849655
 ],
 "tags": [
 "pariatur",
 "consequat",
 "et",
 "amet",
 "fugiat",
 "non",
 "deserunt"
 ],
 "friends": [
 {
 "id": 0,
 "name": "Alejandra Kinney"
 },
 {
 "id": 1,
 "name": "Holmes Graves"
 },
 {
 "id": 2,
 "name": "Barbra Dominguez"
 }
 ],
 "greeting": "Hello, Whitehead Navarro! You have 7 unread messages.",
 "favoriteFruit": "strawberry",
 "favoriteMedia": {
 "name": "Better Call Saul",
 "year": "2022",
 "network": "AMC"
 }
}

1. Recebendo e Convertendo Dados

Para converter os dados usando schematics, a primeira coisa a fazer é criar um modelo que represente uma pessoa:

import datetime
from schematics import Model
from schematics.transforms import blacklist, whitelist
from schematics.types import ModelType, StringType, IntType, UUIDType, BooleanType, URLType, EmailType, DateTimeType, \
 GeoPointType, ListType, serializable, PolyModelType

from model.friend import Friend
from model.game import Game
from model.movie import Movie
from model.schematics_types.currency_type import CurrencyType
from model.tv_show import TVShow
from model.validators import is_uppercase, is_email_valid, is_over_18


class Person(Model):
 id = StringType(deserialize_from='_id')
 index = IntType()
 guid = UUIDType()
 is_active = BooleanType(deserialize_from='isActive')
 balance = CurrencyType()
 picture = URLType()
 age = IntType(validators=[is_over_18])
 eye_color = StringType(deserialize_from='eyeColor')
 name = StringType(required=True)
 gender = StringType()
 company = StringType(validators=[is_uppercase])
 email = EmailType(validators=[is_email_valid], required=True)
 phone = StringType(required=True)
 address = StringType()
 about = StringType()
 registered = DateTimeType()
 coordinates = GeoPointType()
 tags = ListType(StringType)
 friends = ListType(ModelType(Friend))
 greeting = StringType()
 favorite_fruit = StringType(deserialize_from='favoriteFruit')
 favorite_media = PolyModelType([
 Movie,
 TVShow,
 Game
 ], deserialize_from='favoriteMedia')
 created_at = DateTimeType(default=datetime.datetime.now)

 @serializable
 def external_id(self):
 return u'%s-%s' % (self.index, self.id)

 class Options:
 serialize_when_none = False
 roles = {
 'public_person': blacklist('id', 'index', 'guid', 'is_active', 'balance'),
 'profile_info': whitelist('name', 'greeting', 'gender', 'picture', 'about', 'age')
 }

Muita informação aqui! Vamos entender passo a passo.

Atribuindo tipos a campos

Criamos uma classe Person que estende a classe Model do Schematics. Nesta classe, todas as variáveis são declaradas com um tipo específico já existente no Schematics ou um tipo customizado criados por nós mesmos. O Schematics fornece tipos prontos para uso (como StringType, UUIDType, IntType; verifique todos os tipos disponíveis usando o as documentações do Schematics).

Esses tipos são muito úteis para coagir e converter dados para corresponder ao nosso esquema de classe desejado. Além disso, com um tipo, a validação de campo se torna muito fácil (falaremos mais sobre isso já já). Como visto acima, é possível criar tipos personalizados para atender às nossas necessidades específicas, como a classe CurrencyType:

from schematics.types import FloatType


class CurrencyType(FloatType):
 def convert(self, value, context=None):
 if not isinstance(value, str):
 return value
 number = value.replace('$', '')
 return float(number.replace(',', ''))

Neste exemplo, CurrencyType estende a classe FloatType do Schematics, o método de conversão recebe um valor - e se tratando de uma string, remove o cifrão e a vírgula para aderir ao formato de moeda desejado.

Lista de Modelos

Para representar uma lista/array de itens de um modelo, usamos ListType(ModelType()) e o nome do modelo que compõem essa lista - como no exemplo acima: ListType(ModelType(Friend)). A classe Friend representa um modelo da seguinte forma:

from schematics import Model
from schematics.transforms import wholelist
from schematics.types import IntType, StringType


class Friend(Model):
 id = IntType()
 name = StringType()

Se a lista consistir em um tipo simples, como o parâmetro tags (uma lista composta apenas de strings), declaramos um ListType() com o tipo desejado, como ListType(StringType).

Renomeando Campos

Schematics faz atribuições automáticas para atribuir as variáveis baseadas no nome do campo recebido com o campo do nosso modelo; quando ambos compartilham o mesmo nome, esse processo acontece por baixo dos panos. Mas o que acontece quando recebemos campos que em nosso contexto possuem nomes diferentes?

Para resolver isso, é bastante fácil: basta adicionar deserialize_from= seguido do nome do campo original recebido para realizar a correspondência. No exemplo acima, os campos id, eye_color e favorite_fruit são desserializados usando este atributo:

favorite_fruit = StringType(deserialize_from='favoriteFruit')

Esta é uma ótima maneira de normalizar facilmente payloads com nomenclatura diferente do snake_case, que é usado pelo python.

Campos Padrão

Para definir um valor padrão para um campo, use o atributo default= dentro do tipo de campo desejado. No exemplo acima, o campo created_at terá como padrão a data/hora em que o modelo foi instanciado.

 created_at = DateTimeType(default=datetime.datetime.now)

Campos Compostos

Para criar um campo composto de campos existentes na classe, crie uma função com o nome do campo desejado anotado com @serializable como no campo external_id do model acima, que é criado concatenando os campos index e id. Isso permite que o valor seja acessado como qualquer outro campo da classe.

 @serializable
 def external_id(self):
 return u'%s-%s' % (self.index, self.id)

Definindo validadores Personalizados

Podemos criar um validador personalizado para verificar se os dados recebidos respeitam regras de negócio. Para isso, crie uma função com a validação desejada que receba um atributo value como parâmetro e gere uma exceção ValidationError em um cenário negativo, como este:

import re

from schematics.exceptions import ValidationError


def is_uppercase(value):
 if value.upper() != value:
 raise ValidationError('Field should be uppercase.')
 return value


def is_email_valid(value):
 regex = r'\b[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Z|a-z]{2,7}\b'
 if not re.fullmatch(regex, value):
 raise ValidationError('E-mail address invalid.')
 return value


def is_over_18(value):
 if value < 18:
 raise ValidationError('User cannot be underage.')
 return value

Para validar os elementos do modelo, use validators=[] e o nome da função entre colchetes, assim: validators=[is_email_valid].

 email = EmailType(validators=[is_email_valid], required=True)

Campos Obrigatórios

Para definir um campo como obrigatório, use required=True na declaração do tipo. Se o valor não estiver presente no momento da validação, a aplicação lançará uma exceção.

2. Acessando e Manipulando Dados

Com nosso modelo criado, é hora de gerar alguns dados carregando o json recebido como um dict e passando como parâmetro ao instanciar classe Person:

person = Person(json_input)

Validando Dados

Para validar se os dados recebidos estão em corretos, usamos o seguinte método:

person.validate()

Em nosso modelo, criamos um validador que especifica que o valor do campo empresa deve ser maiúsculo. Deixar de informar uma string em letras maiúsculas resulta na seguinte saída quando validado:

schematics.exceptions.DataError: {"company": ["Field should be uppercase."]}
Process finished with exit code 1

Ignorando Campos Não Mapeados

Para ignorar campos não declarados no modelo e presentes na entrada, usamos o seguinte atributo de validação:

person.validate(strict=False)

Se este parâmetro não for especificado, passar um campo na entrada que não está contido no modelo resulta na seguinte saída ao validar:

schematics.exceptions.DataError: {"newField": "Rogue field"}
Process finished with exit code 1

Omitindo Campos Sem Valor

Para omitir campos sem valor (atribuídos com None) ao exportar um modelo, use serialize_when_none = False dentro da classe interna Options:

 class Options:
 serialize_when_none = False

Acessando Campos

Com o objeto modelo criado, fica fácil acessar os campos:

print(person.name, 'is', person.age, 'old.')

que gera como resposta:

Whitehead Navarro is 22 old.
Process finished with exit code 0

Exportando para Json

Para exportar o objeto para json, utilizamos o seguinte método:

json.dumps(person.to_primitive())

que gera como resposta o json:

{"id": "641505586f0763093fe5de82", "index": 0, "guid": "3e591c0d-5812-4c1e-9062-91d67db36326", "is_active": true, "balance": 3657.06, "picture": "https://picsum.photos/200", "age": 22, "eye_color": "brown", "name": "Whitehead Navarro", "gender": "male", "company": "ROUGHIES", "email": "whiteheadnavarro@roughies.com", "phone": "(843) 429-2875", "address": "934 River Street, Sparkill, New Mexico, 4866", "about": "Mollit enim aute sint enim ut eiusmod dolore dolore veniam. Esse ad consequat pariatur cupidatat qui deserunt proident minim irure. Proident labore minim ex voluptate ea ut excepteur duis ad minim quis incididunt labore. Laborum sit aliqua aliqua et ad qui qui quis ullamco. Voluptate voluptate consectetur nostrud amet enim. In Lorem voluptate fugiat duis. Ut proident ipsum minim do fugiat sunt laboris voluptate tempor aliqua aliquip deserunt sit.\r\n", "registered": "2018-08-26T04:14:49.000000", "coordinates": [-0.642558, -154.849655], "tags": ["pariatur", "consequat", "et", "amet", "fugiat", "non", "deserunt"], "friends": [{"id": 0, "name": "Alejandra Kinney"}, {"id": 1, "name": "Holmes Graves"}, {"id": 2, "name": "Barbra Dominguez"}], "greeting": "Hello, Whitehead Navarro! You have 7 unread messages.", "favorite_fruit": "strawberry", "created_at": "2023-06-22T22:09:15.939875", "external_id": "0-641505586f0763093fe5de82"}
Process finished with exit code 0

Roles e Opções de Classe

Uma role funciona como um filtro ao exportar dados usando as opções whitelist e blacklist. Como no modelo Person acima, declaramos uma role dentro da subclasse Option e listamos os valores da whitelist (valores para exportar) ou uma blacklist (valores para omitir).

 class Options:
 roles = {
 'public_person': blacklist('id', 'index', 'guid', 'is_active', 'balance'),
 'profile_info': whitelist('name', 'greeting', 'gender', 'picture', 'about', 'age')
 }

Este é o comando para imprimir apenas os valores da whitelist:

print(person.to_primitive(role='profile_info'))

que imprime os valores de pictures, age, name, gender, about e greeting:

{'picture': 'https://picsum.photos/200', 'age': 22, 'name': 'Whitehead Navarro', 'gender': 'male', 'about': 'Mollit enim aute sint enim ut eiusmod dolore dolore veniam. Esse ad consequat pariatur cupidatat qui deserunt proident minim irure. Proident labore minim ex voluptate ea ut excepteur duis ad minim quis incididunt labore. Laborum sit aliqua aliqua et ad qui qui quis ullamco. Voluptate voluptate consectetur nostrud amet enim. In Lorem voluptate fugiat duis. Ut proident ipsum minim do fugiat sunt laboris voluptate tempor aliqua aliquip deserunt sit.\r\n', 'greeting': 'Hello, Whitehead Navarro! You have 7 unread messages.'}
Process finished with exit code 0

Ao imprimir todos os valores exceto os que estão na blacklist, usamos:

print(person.to_primitive(role='public_person'))

que omite os campos id, index, guid, is_active e balance:

{'picture': 'https://picsum.photos/200', 'age': 22, 'eye_color': 'brown', 'name': 'Whitehead Navarro', 'gender': 'male', 'company': 'ROUGHIES', 'email': 'whiteheadnavarro@roughies.com', 'phone': '(843) 429-2875', 'address': '934 River Street, Sparkill, New Mexico, 4866', 'about': 'Mollit enim aute sint enim ut eiusmod dolore dolore veniam. Esse ad consequat pariatur cupidatat qui deserunt proident minim irure. Proident labore minim ex voluptate ea ut excepteur duis ad minim quis incididunt labore. Laborum sit aliqua aliqua et ad qui qui quis ullamco. Voluptate voluptate consectetur nostrud amet enim. In Lorem voluptate fugiat duis. Ut proident ipsum minim do fugiat sunt laboris voluptate tempor aliqua aliquip deserunt sit.\r\n', 'registered': '2018-08-26T04:14:49.000000', 'coordinates': [-0.642558, -154.849655], 'tags': ['pariatur', 'consequat', 'et', 'amet', 'fugiat', 'non', 'deserunt'], 'friends': [{'id': 0, 'name': 'Alejandra Kinney'}, {'id': 1, 'name': 'Holmes Graves'}, {'id': 2, 'name': 'Barbra Dominguez'}], 'greeting': 'Hello, Whitehead Navarro! You have 7 unread messages.', 'favorite_fruit': 'strawberry', 'created_at': '2023-06-22T22:17:12.004692', 'external_id': '0-641505586f0763093fe5de82'}
Process finished with exit code 0

Mockando a Resposta

Para testar nosso código, podemos usar Schematics para mockar os valores do modelo:

print(Person.get_mock_object().to_primitive())

O mock tem valores aleatórios baseados nos tipos das variáveis:

{'index': 14, 'picture': 'http://aiV9Q.ZZ', 'age': 12, 'eye_color': 'N', 'name': 'hgqn8YPvDqLbf', 'company': 'JQ', 'email': 'ER@example.com', 'phone': 'DQVbv9q', 'address': '61sOKCSGGOkV', 'coordinates': (-83, 53), 'greeting': 'fsxF', 'created_at': '2127-03-09T03:39:51.357227+1130', 'external_id': '14-None'}
Process finished with exit code 0

3. Modelagem Avançada: Polimorfismo

Também é possível realizar polimorfismo de tipos usando Schematics! Quando temos um campo que pode ter vários tipos, podemos declará-lo assim:

favorite_media = PolyModelType([
 Movie,
 TVShow,
 Game
], deserialize_from='favoriteMedia')

As classes Movie, TVShow e Game representam os tipos aceitos do campo favorite_media:

from schematics import Model
from schematics.types import StringType, IntType


class Movie(Model):
 name = StringType()
 year = IntType()

from schematics import Model
from schematics.types import StringType, IntType


class TVShow(Model):
 name = StringType()
 year = IntType()
 network = StringType()

 @classmethod
 def _claim_polymorphic(cls, data):
 return data.get('network')

from schematics import Model
from schematics.types import StringType, IntType


class Game(Model):
 name = StringType()
 year = IntType()
 console = StringType()

 @classmethod
 def _claim_polymorphic(cls, data):
 return data.get('console')

Nossos modelos são muito parecidos. Neste caso, devemos implementar o método _claim_polymorphic que ajuda o Schematics a diferenciar entre os modelos com base no payload recebido. Neste caso, retornamos um data.get com um atributo que seja único entre todas as classes.

Para verificar o tipo de mídia favorito escolhido pelos Schematics após a ingestão dos dados recebidos, usamos:

print(person.favorite_media)

que gera como resposta:

<TVShow instance>
Process finished with exit code 0

A saída é definida como uma instância de TvShow porque informamos um atributo network em nosso esquema recebido.

Para acessar o nome da mídia, podemos acessar diretamente o campo de nome:

print(person.favorite_media.name)

que gera como resposta:

Better Call Saul
Process finished with exit code 0

Se alterarmos a entrada para representar um filme, por exemplo, com uma entrada como esta:

 "favoriteMedia": {
"name": "Everything Everywhere All At Once",
"year": "2022"
}

Ao enviar o tipo de mídia favorito, vamos ter:

<Movie instance>
Process finished with exit code 0

É isso! Para acessar esta implementação, confira o código-fonte no meu Github.

Referências

Documentação Schematics Python

AWS Certifications: An Unexpected Journey

Mon, 12 Jun 2023 08:00:00 +0000

Recentemente, tive a grande conquista de obter duas certificações AWS (Practitioner e Solutions Architect Associate) no intervalo de uma semana. Nesse post irei contar como foi a experiência de estudar para as duas provas ao mesmo tempo.

O Início da Jornada

Atualmente eu tenho 5 anos de experiência de desenvolvimento de software e trabalhando diretamente com a AWS, eu tenho pouco mais de dois anos. Nesse período, o escopo do meu conhecimento em AWS se resumia a serviços usados no dia-a-dia como dev (tais como EC2, Dynamo, SQS, Lambdas…)

Quando decidi tirar a certificação AWS, pensei em começar a estudar para a Practitioner que é o primeiro nível de certificações, porém, não estava me sentindo muito feliz com os estudos; por eu já ter um conhecimento mais na prática, não gostei muito do fato do conteúdo que eu iria aprender para essa certificação ser raso.

Com isso me veio a ideia de realizar a SAA, que se alinha melhor no meu planejamento de carreira e tem o conteúdo mais alinhado com o que eu queria aprender. Como bônus, poderia reaproveitar o conhecimento adquirido nesse processo e tirar a Practitioner!

Practitioner vs Solutions Architect Associate

É interessante comparar o conteúdo das duas provas para descobrir o quanto o conteúdo é similar. Comparando os guias das provas, deu pra perceber que mais ou menos 70% do conteúdo delas é similar. Os conteúdos da Practitioner que não são abordados na Solutions Architect Associate são alguns serviços, pilares do AWS Well-Architected, melhores práticas e vantagens de usar a cloud, AWS Support e os modelos de responsabilidade compartilhadas, dentre outros.

Mãos a Obra!

Com o objetivo traçado, chegou a hora de traçar as fontes de estudos. A AWS possui muitos serviços e cada um deles tem suas particularidades, por isso, foi bem importante encontrar um curso que se mantenha no escopo da prova e que entregue um nível interessante de profundidade no conteúdo.

Baseado nisso, utilizei os cursos do Sthephane Maarek no Udemy. Esses cursos são bem focados em explicar o conteúdo coberto pelas certificações de forma sucinta e didática. Além disso, o Sthephane disponibiliza os slides utilizados no curso, que ajudam bastante para uma revisão rápida do conteúdo ou para relembrar alguns conceitos. Eu assisti todos os vídeos do SAA, fazendo os quizes no final de cada um dos capítulos. Ao final, quando fui fazer o meu primeiro simulado, me veio o choque: eu fui muito mal! 🫠

Aprendendo a Aprender

Como fazia um tempinho que eu não estudava no modo sério, digamos que eu estava enferrujada. Nesse processo de estudos percebi uma coisa curiosa sobre mim mesma que não havia notado antes: eu tenho dificuldades em aprender assistindo vídeos, ou absorver conteúdo de forma oral. Foi um choque pra mim perceber que eu não consegui reter muito do conteúdo - que sim, é extenso por si só, mas tive esse choque de realidade ao perceber que eu tenho essa dificuldade a mais e que teria que mudar minha estratégia de combate.

Eu utilizei a técnica que os antigos dinossauros usavam: Fiz uma revisão anotando conceitos em um caderninho, que me ajudou a realizar uma síntese de cada um dos tópicos. Outro truque que me ajudou foi formular cenários mentais: Por exemplo, o que eu usaria pra conectar minha infraestrutura on-premises com a AWS? Ter esse lado crítico e fazer associações do conteúdo com a minha realidade diária me ajudou bastante a assimilar os conteúdos. Finalmente, além dos cursos, usei também os Whitepapers e FAQs da AWS, que me ajudaram a sanar dúvidas que eu nem sabia que tinha!

Com isso, fiz no total 7 simulados. As notas começaram baixas (estava tirando cerca de 50-60% nos primeiros simulados), mas depois foram gradualmente aumentando, até atingir 70-80% nas últimas tentativas. Outro detalhe interessante que me ajudou foi revisar bem os simulados e entender o motivo da resposta certa ser certa e o motivo das incorretas não funcionarem para o contexto da pergunta. No total, creio ter estudado 1 mês, estudando mais ou menos uma a duas horas diárias. Foi essencial também tirar pausas e revisar conteúdo já visto no intervalo de cada semana para fixação.

Preparar, Apontar, Fogo!

E num piscar de olhos chegou o dia do teste! Eu fiz a SAA primeiro e a Practitioner na semana seguinte como round bônus. Optei por fazer a prova em casa e achei o processo bem tranquilo, contando que eu tinha disponível um espaço tranquilo pra fazer a prova, que marquei para 7h da manhã justamente para não ser distraída por barulhos externos. A prova foi mais fácil do que os simulados, o que é excelente - melhor estar super-bem preparado do que mais-ou-menos preparado. Acho que a pior parte foi o nervosismo pela prova e a espera pelo resultado depois do teste.

Então, depois de 24h chegou o e-mail com a minha badge e o resultado de aprovação. 🥳🎉

Com a primeira certificação tirada, tomei o intervalo de 6 dias para estudar o conteúdo da Practitioner. Eu não havia focado nos tópicos antes dessa semana pois achei o conteúdo “estudável” durante o período de uma semana. Foi tranquilo decorar o conteúdo, mas confesso que estava cansada de estudar 🥲

Depois da SAA, a Practitioner foi mamão com açúcar! O resultado saiu na hora - sem suspense. E desse jeito eu consegui as minhas duas primeiras certificações AWS!

Padrões de Projeto - Bridge

Fri, 03 Mar 2023 08:00:00 +0000

Bridge é um padrão de projeto estrutural que visa desacoplar uma abstração de sua implementação, de forma que permita que ambos evoluam de forma independente.

O uso desse padrão é recomendado ao lidar com classes que possuem muitas implementações diferentes e usam herança para implementar a abstração. Nesses casos, a herança conecta uma implementação à abstração permanentemente, de forma que é difícil modificar, aumentar e reutilizar as abstrações de forma independente.

Para dar um exemplo ilustrado, vamos fingir que temos um cenário onde queremos criar diferentes tipos de contas bancárias: CheckingAccount e SavingsAccount. Queremos que nosso sistema seja flexível para a criação de novos tipos de contas, então criamos uma classe abstrata chamada BankAccount e estendemos esta classe com as classes CheckingAccount e SavingsAccount.

Ótimo! Mais tarde, queremos dar aos nossos tipos de conta seu próprio tipo de cartão de crédito personalizado. Criamos as classes BasicCreditCard, SilverCreditCard e GoldCreditCard. Ao vincular esses cartões de crédito a cada tipo de conta bancária, o problema fica claro:

A abordagem ingênua seria criar uma combinação para cada tipo de conta, uma solução que é cara e cresce exponencialmente (imagine o tanto de trabalho se adicionarmos um novo tipo de conta!). O código também é altamente acoplado, pois estados e comportamentos diferentes estariam contidos em uma única classe.

O padrão Bridge resolve esse problema mudando de herança para composição e realocando todas as classes CreditCard para sua própria hierarquia. Ao fazer isso, permitimos que ambos os contextos evoluam e mudem independentemente.

Com esse design em mente, vamos então criar nossa interface CreditCard:

Agora, vamos criar nossos tipos: Basic, Silver e Gold, todos implementando os métodos especificados pela interface CreditCard.

Vamos criar a abstração BankAccount, a classe base para nossos tipos de conta. Esta classe terá um objeto CreditCard, bem como um método para obter as informações do cartão.

Com tudo criado, podemos escrever nossos tipos de conta CheckingAccount e SavingsAccount:

Para testar nosso projeto, criaremos uma classe principal inicializando cada conta com seus respectivos tipos de cartão de crédito.

…que gera o seguinte conteúdo:

No fim das contas, o padrão Bridge é uma ótima ferramenta para ser utilizada quando queremos dividir e refatorar classes com muitas variantes, e também quando precisamos estender uma classe em dimensões independentes. Um grande benefício em usar esse padrão é que ele segue o princípio aberto/fechado (já que podemos adicionar abstrações e implementações sem afetar as existentes) e o princípio de responsabilidade única.

Você pode verificar a implementação completa deste exemplo aqui no meu Github: GracieleDamasceno/design-patterns!

Referências:

Bridge Pattern - Refactoring Guru

Design Patterns (2005), By Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides, Craig Larman

Padrões de Projeto - Adapter

Sat, 18 Feb 2023 08:00:00 +0000

Adapter é um padrão de projeto com a finalidade de - como o próprio nome sugere - adaptar um contexto à outro, permitindo que duas interfaces incompatíveis sejam conectadas. O principal benefício de aplicar esse padrão é permitir trocar de uma interface existente para outra sem alterar o comportamento original da interface existente. o Adapter também é usado quando há a necessidade de criar uma classe reutilizável que interaja com interfaces incompatíveis. Vamos ver esse padrão em ação!

Adaptando a saída existente para uma nova

Em nosso cenário, temos uma POJO de pessoa que contém alguns atributos.

Existe também uma interface que dita qual será o contrato de negócio do objeto Pessoa. Em nosso caso, o contrato existente estabelece que a resposta da classe Person deve ser uma string formatada em XML.

E a classe LegacyPersonService implementa esse contrato, construindo um objeto da classe Person e retornando-o em string, formatada em XML.

Essa arquitetura funciona bem por um bom tempo, até que seja necessário redesenhar nosso sistema. Como nesse cenário temos muitas dependências externas e cruciais, a resposta em XML tem que coexistir com a nova solução, que tem como objetivo ter a resposta em string no formato JSON.

É exatamente aí que o padrão do adaptador é muito útil!

Vamos adaptar nossa solução anterior para gerar um JSON, seguindo os novos requisitos. Primeiro, vamos implementar uma interface que dite esse novo contrato.

Agora, criamos o adapter: implementando a interface criada anteriormente, instanciamos a classe LegacyPersonService que contém a lógica do contrato antigo e implementamos a nova lógica para transformar a resposta em uma string em JSON.

Com a lógica criada, podemos criar tranquilamente uma nova versão do nosso endpoint que atenda à nova especificação, sem alterar a que já existia.

Então, para resumir:

O padrão de Adapter segue o princípio aberto-fechado. Podemos adicionar novos adaptadores sem alterar o código existente.
O padrão de Adapter também segue o princípio da responsabilidade única, pois separamos a interface/contrato da lógica de negócios existente.
No nosso caso, foi utilizada composição na classe ModernizedPersonAdapter para encapsular o alvo do adaptador (LegacyPersonService). Esta forma de lidar com a classe adaptada é chamada de Object Adapter.
- A outra forma de implementar um adaptador seria usando o estilo Class Adapter, onde ao invés de criar um objeto LegacyPersonService em ModernizedPersonAdapter, estenderíamos LegacyPersonService e implementaríamos PersonOutputAdapter simultaneamente. Ambas são abordagens válidas, no entanto, é melhor favorecer a composição em detrimento da herança, pois permite que o sistema seja mais fácil de testar, menos complexo e desacoplado.
A principal desvantagem que esse padrão oferece é o aumento da complexidade ao adicionar novos componentes à aplicação. Dependendo da situação e das restrições externas, é melhor apenas refatorar o código existente para corresponder ao novo contrato.

Você pode dar uma olhada no código aqui no meu Github: GracieleDamasceno/design-patterns! Até a próxima!

Referências:

Composition over inheritance - Wikipedia

Adapter Pattern - Refactoring Guru

Padrões de Projeto - Prototype

Fri, 04 Nov 2022 08:00:00 +0000

Continuando nossa série de padrões de projeto, o segundo que iremos revisitar é o Prototype!

Este padrão visa ter um “planta” para gerar instâncias. Isso é muito útil em situações onde existem vários objetos com propriedades diferentes, onde seja custoso criar novos recursos e quando queremos especificar a instanciação da classe em tempo de execução.

Basicamente, para implementar um Prototype, temos que adicionar à classe original desejada um método que clona uma instância baseada na original. O próximo passo é criar uma espécie de “registro” que mantenha um cache dos objetos prototipados; seguido por uma classe de fábrica que clona o original e retorna o resultado.

O processo de clonagem é um dos aspecto mais importantes do Prototype, então, para entender melhor as nuances escondidas na clonagem de um objeto, vamos falar sobre Deep Cloning e Shallow Cloning.

Deep Cloning versus Shallow Cloning

Deep Cloning significa que, ao clonar, cada cópia terá sua própria referência. Se alterarmos um atributo da cópia, o original permanecerá intacto.

O mesmo não acontece com o Shallow Cloning: tanto a cópia quanto o original compartilham a mesma referência. Isso significa que as alterações feitas nos atributos de cópia também serão refletidas nos atributos do objeto original.

Implementando o Padrão Prototype em Java

Existem algumas “pegadinhas” ao implementar o Prototype em Java: A escolha óbvia, a interface Cloneable do Java, é comumente conhecida por ser defeituosa. Simplesmente não existe um mecanismo construído em Java para criar “deep clones” nativamente, o que significa que implementar Cloneable e chamar super.clone() sempre criará uma cópia superficial. Pior ainda, a interface Cloneable é uma classe marker que apenas marca a classe que a implementa como adequada para clonagem, e não possui um método clone() próprio (este método existe na classe Object).

Esses fatores argumentam por ser uma escolha melhor usar cópia via construtores para criar clones ao invés do Cloneable do Java.

Com isso em mente, vamos tentar usar o Prototype para resolver um problema. O conceito é o seguinte: Queremos acompanhar algumas Criptomoedas que foram compradas em 1º de janeiro de 2022. Os valores nesse período preenchem a instância original quando o aplicativo é iniciado. O usuário envia sua escolha de criptomoeda e o aplicativo chama um endpoint para obter informações em tempo real sobre essa criptomoeda específica, calcula a diferença entre o antes e o depois e envia de volta em um relatório.

Esse é o diagrama de arquitetura do aplicativo:

A classe de controller da aplicação é a seguinte:

@RestController
@AllArgsConstructor
public class CryprocurrencyController {
 private final CryptocurrencyService cryptocurrencyService;

 @GetMapping(value = "/crypto/{cryptocurrencyType}")
 public CryptocurrencyReport cryptocurrencyController(@PathVariable CryptocurrencyTypeEnum cryptocurrencyType) {
 return cryptocurrencyService.getCryptocurrencyReport(cryptocurrencyType);
 }
}

Então, o controller invoca a service:

@Service
@AllArgsConstructor
public class CryptocurrencyService {

 private final CryptocurrencyClient cryptocurrencyClient;
 private final CryptocurrencyLoader cryptocurrencyLoader;

 public CryptocurrencyReport getCryptocurrencyReport(CryptocurrencyTypeEnum cryptocurrencyTypeEnum){

 //Get original Cryptocurrency instance
 Cryptocurrency cryptocurrencyAtPurchase = cryptocurrencyLoader.getCryptocurrencyLoaded(cryptocurrencyTypeEnum);

 //Get Cryptocurrency cloned with updated values
 Cryptocurrency cryptocurrencyNow = getUpdatedCryptocurrencyValues(cryptocurrencyTypeEnum);

 //Returns the report calculating variation between purshased value and current value
 return CryptocurrencyReport.builder()
 .cryptocurrencyCurrentValues(cryptocurrencyNow)
 .cryptocurrencyPurchaseValues(cryptocurrencyAtPurchase)
 .rankVariation(calculateVariation(cryptocurrencyAtPurchase.getRank(), cryptocurrencyNow.getRank()))
 .priceUSDVariation(calculateVariation(cryptocurrencyAtPurchase.getPriceUSD(), cryptocurrencyNow.getPriceUSD()))
 .volume24Variation(calculateVariation(cryptocurrencyAtPurchase.getVolume24(), cryptocurrencyNow.getVolume24()))
 .marketCapUSDVariation(calculateVariation(cryptocurrencyAtPurchase.getMarketCapUSD(), cryptocurrencyNow.getMarketCapUSD()))
 .build();
 }

 private Cryptocurrency getUpdatedCryptocurrencyValues(CryptocurrencyTypeEnum cryptocurrencyTypeEnum){
 //Requests current Crypto's data 
 final CryptocurrencyDTO cryptocurrencyDTO =
 cryptocurrencyClient.getCryptocurrency(cryptocurrencyTypeEnum.getId()).iterator().next();
 //Loads original cripto values
 Cryptocurrency cryptocurrencyLoaded = cryptocurrencyLoader.getCryptocurrencyLoaded(cryptocurrencyTypeEnum);
 //Maps the current values to the original Criptocurrency object
 return updateLoadedPrototypeWithCurrentValues(cryptocurrencyDTO, cryptocurrencyLoaded);
 }

 private BigDecimal calculateVariation(BigDecimal valueBefore, BigDecimal valueNow){
 return valueNow.subtract(valueBefore);
 }

 private Integer calculateVariation(Integer valueBefore, Integer valueNow){
 return valueNow - valueBefore;
 }
}

Essa é a classe que realiza o mapeamento do objeto recebido para o clone:

@NoArgsConstructor
public class CryptocurrencyDTOMapper {

 public static Cryptocurrency updateLoadedPrototypeWithCurrentValues(CryptocurrencyDTO cryptocurrencyDTO, Cryptocurrency cryptocurrencyLoaded){
 cryptocurrencyLoaded.setRank(cryptocurrencyDTO.getRank());
 cryptocurrencyLoaded.setPriceUSD(cryptocurrencyDTO.getPriceUSD());
 cryptocurrencyLoaded.setVolume24(cryptocurrencyDTO.getVolume24());
 cryptocurrencyLoaded.setMarketCapUSD(cryptocurrencyDTO.getMarketCapUSD());
 return cryptocurrencyLoaded;
 }
}

A classe que carrega a instância de Cryptocurrency:

@Component
public class CryptocurrencyLoader {

 HashMap<String, Cryptocurrency> cryptocurrencyTable = new HashMap<>();
 //Returns crypto object based on the enum requested by the user
 public Cryptocurrency getCryptocurrencyLoaded(CryptocurrencyTypeEnum crypto){
 Cryptocurrency loadedCryptocurrency = cryptocurrencyTable.get(crypto.getId());
 //Here the cloning happens!
 return new Cryptocurrency(loadedCryptocurrency);
 }

 //Loads the crypto information on application startup
 @PostConstruct
 private void loadCryptoInfo1stJanuary2022(){
 Cryptocurrency bitcoin = Cryptocurrency.builder()
 .id(CryptocurrencyTypeEnum.BTC.getId())
 .name("BITCOIN")
 .symbol(CryptocurrencyTypeEnum.BTC)
 .rank(1)
 .volume24(new BigDecimal("24582667004"))
 .priceUSD(new BigDecimal("47686.81"))
 .marketCapUSD(new BigDecimal("902104193385"))
 .build();

 Cryptocurrency ethereum = Cryptocurrency.builder()
 .id(CryptocurrencyTypeEnum.ETH.getId())
 .name("ETHEREUM")
 .symbol(CryptocurrencyTypeEnum.ETH)
 .rank(1)
 .volume24(new BigDecimal("9776191466"))
 .priceUSD(new BigDecimal("3769.70"))
 .marketCapUSD(new BigDecimal("448537615143"))
 .build();

 cryptocurrencyTable.put(CryptocurrencyTypeEnum.BTC.getId(), bitcoin);
 cryptocurrencyTable.put(CryptocurrencyTypeEnum.ETH.getId(), ethereum);
 }
}

Finalmente, a classe de Cryptocurrency que realiza a clonagem através do construtor com um parâmetro:

@Getter
@Setter
@Builder
@NoArgsConstructor
@AllArgsConstructor
public class Cryptocurrency {

 private String id;

 private CryptocurrencyTypeEnum symbol;

 private String name;

 private Integer rank;

 @JsonProperty("price_usd")
 private BigDecimal priceUSD;

 @JsonProperty("volume_24")
 private BigDecimal volume24;

 @JsonProperty("market_cap_usd")
 private BigDecimal marketCapUSD;

 /*
 * Since the clone method from Cloneable class is broken, we use a copy constructor.
 * */
 public Cryptocurrency(Cryptocurrency cryptocurrency) {
 this(cryptocurrency.getId(),
 cryptocurrency.getSymbol(),
 cryptocurrency.getName(),
 cryptocurrency.getRank(),
 cryptocurrency.getPriceUSD(),
 cryptocurrency.getVolume24(),
 cryptocurrency.getMarketCapUSD());
 }
}

Você pode checar a implementação completa do projeto clicando aqui.

Referências

Discussões interessantes sobre o Cloneable do Java:

Java: Clone and Cloneable > Programming.Guide

Java Cloning Problems > Vojtech Ruzicka’s Programming Blog

Copy constructors > Java Practices

Melhorando a comunicação assíncrona no ambiente de trabalho

Sun, 11 Sep 2022 08:00:00 +0000

Trabalhar remotamente pode resultar em alguns desafios inesperados. Quando precisamos de ajuda em um ambiente onde todos estão fisicamente compartilhando o mesmo espaço, podemos simplesmente nos chegar em um colega no intervalo do café e pedir ajuda, apontando freneticamente para a tela enquanto explicamos o que estávamos fazendo antes que não funciona mais agora.

No entanto, em um ambiente remoto, às vezes pedir ajuda ou tirar dúvidas pode ser um grande desafio. Primeiro, eu iria analisar minuciosamente o chat, procurando alguém que esteja disponível que possa com sorte saber a resposta para o meu problema, secretamente esperando que a pessoa não mude seu status para “ocupado” ou “não perturbe” nos próximos cinco segundos. Ótimo, a pessoa está disponível! Eu vou ligar… Não, é muito abrupto; melhor enviar uma mensagem.

Eu: Bom dia Joe, tudo bem?

E… nada. Joe não me responde imediatamente. Talvez ele não tenha visto minha mensagem, isso pode acontecer de vez em quando. Vamos tentar chamar a atenção dele novamente:

Eu: Você está ocupado?

Nada. Estou travada! Joe precisa me responder para que eu consiga seguir em frente. Ele é o único que pode. Cada segundo que ele leva para me responder é um tempo perdido que não posso recuperar.

Joe: Oi Gracie. Eu estou bem. E você?

AÍ SIM! Demorou um pouco para me responder, só que ele só respondeu a minha primeira pergunta. Vamos tentar de novo:

Eu: Estou bem, obrigado. Pode me ajudar com uma coisinha?

…

Joe sumiu de novo. Ele não me respondeu.

E ainda estou travada.

Qual é o problema aqui?

Talvez Joe esteja super ocupado e não tenha atualizado seu status. Talvez ele esteja tentando resolver um problema próprio. Talvez ele esteja ajudando outra pessoa. Talvez ele esteja fazendo uma pausa para o café. Talvez sua conexão com a internet não esteja tão boa agora. Talvez ele se distraiu e esqueceu de responder. Talvez…

Nunca dá pra saber o que a outra pessoa está fazendo enquanto trabalhando remoto. Não dá pra dar aquela olhadinha de canto e ver a expressão super concentrada do colega, aquela cara de nem-nem-tente-me-incomodar-que-o-bagulho-ta-feio. Portanto, justamente por estarmos remoto, uma coisa que devemos ter em mente é que devemos aprender a trabalhar de forma assíncrona.

Nem sempre o outro estará disponível o tempo todo para você, e está tudo bem (o problema é quando eles nunca estão disponíveis para ninguém, mas isso é discussão para outro tópico…). Do mesmo jeito como nem você não está disponível para ajudar o tempo todo. Com isso em mente, podemos usar algumas técnicas para aproveitar ao máximo o tempo disponível de todos.

Voltando ao nosso cenário: Joe me responde três horas depois com:

Joe: Sim, desculpe a demora. O que está acontecendo?

Aí eu nem sei nem mais por onde começar minha pergunta. Então eu mando:

Eu: Posso te ligar para mostrar meu problema?

Aqui vêm algumas ramificações deste cenário:

Joe está disponível para conversar agora. Vou ligar para ele e explicar o que estava tentando fazer e o que não está funcionando. Depois de cinco minutos ouvindo, ele vai me perguntar se eu tentei fazer isso ou aquilo, eu vou dizer que não, ainda não tentei, e ele vai esperar na ligação enquanto eu tento aplicar sua sugestão. Funcionou! Excelente.
Joe está disponível para conversar agora. Vou ligar para ele e explicar o que estava tentando fazer, e enquanto explico, percebo que… Algo não parece certo. Eu me escuto explicando e percebo que agora posso chegar à raiz do meu problema. Percebo algum ponto de falha na minha lógica, ou que eu tinha entendido superficialmente o que estava fazendo. Enquanto falo, minha voz desaparece lentamente e exclamo com orgulho que entendi! Eu rapidamente resolvo o problema, agradeço a Joe por seu tempo e sigo em frente.
Joe não está disponível para conversar agora. Procuro outra pessoa para me ajudar.

Vamos examinar algumas técnicas para melhorar esses cenários.

1. Como escrever perguntas de forma eficaz para obter se comunicar de forma assíncrona e precisa

No primeiro cenário, liguei para Joe e expliquei desde o início o que eu estava tentando fazer. Dá pra notar que muito tempo foi gasto esperando Joe me responder antes de conseguir falar com ele. Existe uma maneira melhorar essas situações?

Eu poderia tentar explicar meu problema via texto para Joe, para que quando ele veja minha mensagem, ele possa passar algum tempo pensando e me dar a melhor resposta possível. Existem algumas técnicas que podem ser usadas para melhorar a qualidade de nossa comunicação escrita; vamos dar uma olhada no método Pirâmide Minto (você pode ler mais sobre esse método de escrita visitando o site untools.)

A Pirâmide Minto é uma técnica para escrever melhor e comunicar de forma mais eficiente e clara. Ela se concentra principalmente em compartilhar a essência do problema imediatamente, elaborando os detalhes posteriormente seguindo três etapas:

Para começar, capture a atenção do espectador imediatamente, contando-lhe a essência do problema logo no início. É um começo bastante eficiente, pois pode envolver o leitor a pensar e realmente focar no problema principal.
Em seguida, apoie sua pergunta fornecendo argumentos e pontos-chave breves, explicando os principais detalhes sobre o problema.
Agora é a hora de dar todos os pequenos detalhes que você tiver: o que você tentou, os detalhes mais finos do problema, coisas que podem estar interferindo no seu resultado final, alguns palpites da sua parte… Se a pessoa está muito ocupada e já sabem a resposta, podem pular essa parte inconscientemente, mas às vezes ainda é necessário enriquecer o contexto.

Vamos reescrever nossa primeira mensagem para Joe com tudo isso em mente:

Eu: Oi Joe! Estou tentando acessar nosso banco de dados, porém, a conexão está sendo recusada.

Preciso me conectar ao banco de dados para poder verificar os atributos da nossa tabela para finalizar outra tarefa.

Tentei verificar se meu username e senha estão corretos e também minhas configurações de proxy, e tudo parece estar funcionando bem. Também troquei entre a linha de comando e uma ferramenta GUI, mas ainda não tive sorte. Isso pode ser um problema de acesso? Talvez eu não esteja autorizada a acessar o banco?

Depois de um tempo, Joe responde minha mensagem:

Joe: Olá! Acabei de dar uma olhadinha no sistema principal e sim, foi devido a um problema de autorização. Você não tinha uma permissão válida para acessar o banco de dados, mas acabei de corrigir. Agora vai dar bom!

Dá pra ver como nossa interação foi bem mais rápida? Com apenas duas trocas de mensagens meu problema foi resolvido. Escrevi todas as partes importantes em apenas uma mensagem, como se fosse enviar um e-mail, onde a outra pessoa poderia demorar um pouco para receber, ler e me responder.

Essa técnica de escrita também nos leva a…

2. A arte de obter respostas sem ao menos precisar perguntar para alguém, também conhecida como: a teoria do pato de borracha

Na maioria das vezes, apenas o simples ato de organizar nossos pensamentos pode ser muito benéfico para a resolução de problemas. Como um experimento escrevendo a pergunta do cenário acima em um bloco de notas, sem nem ao menos enviar para ninguém, eu poderia facilmente chegar à mesma conclusão que Joe.

Isso tem correlação direta com o fato de alguém explicar algo complexo para outra pessoa pode aumentar bastante o seu conhecimento próprio sobre a questão em si, as vezes levando diretamente para perceber a solução.

Tentar analisar o problema com os olhos de outra pessoa também pode melhorar a qualidade de nossas perguntas, eliminando redundância e indo direto ao ponto com maior facilidade.

No entanto, às vezes, só analisar o nosso problema não é suficiente. Às vezes, não conseguimos encontrar uma resposta nós mesmos e nosso primeiro instinto pode ser perguntar a outra pessoa, mas por que não perguntar a nós mesmos:

3. Você sabe Google-Fu?

O último recurso antes de pedir ajuda pode ser pesquisar no Google. A esse ponto, já isolamos o problema e pensamos um pouco sobre ele e o contexto, então por que não procurá-lo na internet? Pode esclarecer ou solidificar alguns pontos de nossa compreensão da situação.

A experiência de pesquisar no Google pode ser melhorada por:

Usando operadores de pesquisa avançada do Google, como aspas duplas;
Estar atento às palavras-chave escolhidas para pesquisar, procurando focar no objetivo principal da pesquisa;
Se for algo muito específico, tentar pesquisar em vários idiomas, se possível;
Não tenha medo de olhar para vários links e fontes em sua pesquisa! A resposta pode estar em um deles;
Tentando outros motores de busca.

Com tudo isso dito, há também mais uma habilidade a desenvolver - essa sendo mais difícil de equilibrar: em qual ocasião devemos conversar pessoalmente. Às vezes, é melhor ligar para outra pessoa para compartilhar notícias, pedir conselhos ou apenas conversar; isso aumenta o vínculo na equipe, o que é muito importante para melhorar a sinergia geral do time. Outro ponto é que nem todos se sentem confortáveis em se espressar por texto. Nesse caso, a dica de tentar comunicar mais por mensagens no dia a dia pode ser um excelente modo de melhorar as habilidades de comunicação escrita e até falada.

Padrões de Projeto - Factory

Mon, 29 Aug 2022 08:00:00 +0000

Hoje vamos dar uma olhada no Padrão de Projeto “Factory”.

Imagine que você tenha que construir uma applicação que envie uma mensagem especificada pelo usuário usando diferentes métodos de entrega. Por exemplo, o usuário poderia enviar sua mensagem usando SMS, uma notificação push para um celular, e-mail…

Seria um incômodo construir muitas classes diferentes para receber a mensagem do usuário e entregá-la! Quero dizer, imagine se o usuário tiver que utilizar diferentes endpoints/argumentos para enviar cada tipo de mensagem. Pensando em código, teríamos que criar um método que chamasse cada uma das classes que enviariam uma mensagem de cada maneira específica. Mas e se eu quiser desenvolver outro tipo de método de entrega? Eu teria que alterar a lógica que envia cada mensagem para seu respectivo tipo e, se não tomar cuidado, poderia excluir ou modificar partes importantes dessa lógica. Meu código teria muitas condições e poderia ser altamente acoplado.

Os Padrões de Projeto sugerem uma maneira bem legal de resolver esse problema. Vamos ver como!

Mãos a obra!

Primeiro, vamos dar uma olhadinha no nosso diagrama de arquitetura.

A ideia principal é criar uma interface de notificação que terá um método de entrega definido, para que cada uma das classes implemente suas próprias especificidades da entrega. Há cinco métodos de entrega definidos, e esses métodos serão chamados com base em um parâmetro enviado pelo usuário por meio de uma classe de service. Daqui a pouco vamos ver mais detalhes sobre isso.

Esse projeto usa Java com Spring, e uma chamada REST para receber a mensagem desejada. Vamos começar criando um controller REST onde o usuário pode postar sua mensagem e o tipo de entrega selecionado.

@Slf4j
@RestController
@AllArgsConstructor
public class NotificationController {

 private NotificationService notificationService;

 @PostMapping(value = "/message")
 public DeliveryResponseDTO sendMessage(@RequestBody MessageRequestDTO message, @RequestParam NotificationTypeEnum delivery) {
 log.info("Message received. Method of delivery: " + delivery + ". Payload: " + message);

 return notificationService.redirectMessage(message, delivery);
 }
}

Criamos uma classe MessageRequestDTO que encapsula uma mensagem de tipo String e uma classe enum chamada NotificationTypeEnum com todas as nossas opções de entrega.

A interface que especifica nosso método de entrega padrão para todas as opções de entrega é a seguinte:

public interface Notification {

 DeliveryResponseDTO deliverMessage(MessageRequestDTO message);
}

E este é um exemplo de nossa classe de entrega implementando a interface Notification:

@Slf4j
public class CarrierPigeonNotification implements Notification {

 @Override
 public DeliveryResponseDTO deliverMessage(MessageRequestDTO message) {
 log.info("Carrier Pigeon is the selected choice of delivery! The message to send is: " + message);

 return DeliveryResponseDTO.builder()
 .delivered(false)
 .deliveryStatus("Delivery method not yet supported!")
 .build();
 }
}

Maravilha, agora vamos criar a classe NotificationService que tratará o envio da nossa requisição de mensagem vinda do controller.

@NoArgsConstructor
@Service
public class NotificationService {

 public DeliveryResponseDTO redirectMessage(MessageRequestDTO message, NotificationTypeEnum methodOfDelivery){
 Notification notification = methodOfDelivery.getInstance();
 return notification.deliverMessage(message);
 }
}

Pera aí… Não tem muita coisa acontecendo aqui. Criamos um método para redirecionar a mensagem recebendo o próprio DTO de mensagem e o método de entrega, que é um enum. Aparentemente, existe um método dentro do nosso enum para obter a instância do NotificationType… Vamos dar uma olhada em como a classe enum foi criada.

public enum NotificationTypeEnum {
 CARRIER_PIGEON {
 public CarrierPigeonNotification getInstance(){
 return new CarrierPigeonNotification();
 }
 },
 EMAIL {
 public EmailNotification getInstance(){
 return new EmailNotification();
 }
 },
 MAIL_LETTER {
 public MailLetterNotification getInstance(){
 return new MailLetterNotification();
 }
 },
 MOBILE_PUSH {
 public MobilePushNotification getInstance(){
 return new MobilePushNotification();
 }
 },
 SMS{
 public SMSNotification getInstance(){
 return new SMSNotification();
 }
 };

 public abstract Notification getInstance();
}

Essa é a classe mais interessante de todo o projeto, na minha opinião. Estamos aplicando um conceito bem legal aqui - criando um método getInstance que retorna a classe correta de entrega com base no enum enviado pelo usuário. Dessa forma, evitamos blocos if e nosso código se torna mais limpo e eficiente.

É possível notar que não tivemos que chamar nenhuma de nossas classes de entrega - nem as classes de service nem de controller precisaram chamar. Se quiséssemos adicionar um novo tipo de entrega, não teríamos que mexer em nenhuma das outras classes de tipo de entrega, elas nem “perceberiam” a adição ou remoção de tal método de entrega. Isso acontece porque nossa lógica de construção das instancias das classes é mantida por apenas uma classe usada como “fábrica”, neste caso, a NotificationTypeEnum.

Então, para simplificar, o Factory funciona criando uma interface que é responsável por criar famílias de objetos que possuem a mesma “função”, mas com comportamento diferente, sem a necessidade de especificar qual é a classe concreta desses objetos. A parte de ser uma fábrica está na criação de mecanismos que tratam de selecionar a implementação correta para cada caso necessário.

É isso! Você pode conferir a implementação completa desse exemplo de factory clicando aqui.

Opengram - Um gerenciador de albums web e open-source

Wed, 10 Aug 2022 22:00:00 +0000

O Dilema

Nesses últimos anos tenho tentado fazer um “desintoxicação das redes sociais”. Mesmo antes da pandemia, estava numa fase de tentar me distanciar das redes sociais simplesmente porque não era mais divertido. Os algoritmos que vieram prometendo melhorar o tempo de qualidade das redes sociais criam bolhas impossíveis de estourar. Desinformação, más notícias, negatividade, pessoas compartilhando demais online… Tudo isso me afastou de sentir vontade de fazer login.

No entanto, há um lado das redes sociais que sinto muita falta: compartilhar notícias pessoais com meus amigos mais próximos. Sinto falta de não me preocupar com curtidas, compartilhamentos ou minha timeline sendo inundada por conteúdo que não pedi; sinto falta daqueles bons tempos em que eu logava apenas para conversar e focar em conversas reais com amigos e familiares. Sinto falta de compartilhar minhas fotos de momentos especiais e ter conversas significativas sobre elas.

Falando em fotos, eu adoraria ter uma ferramenta que me permitisse criar álbuns e escrever descrições com contexto sobre elas, mesmo que fosse apenas uma forma de manter um diário local. Tentei encontrar soluções de código aberto que atendesse minhas necessidades, mas nada realmente se encaixava no que eu estava procurando. Até que…

Se você não consegue encontrar, por que não construir do zero?

A essa altura, já tinha um tempo não tinha nenhum projeto grande em Node.js. Então eu tive a “ótima” ideia de combinar o útil com o agradável e construir meu próprio gerenciador de álbuns/fotos usando Node.js e React. Só para deixar claro, eu não sou um grande especialista em tecnologias web/front-end (sofri bastante nesse projeto haha), então essa foi uma maneira de me empurrar para fora da minha zona de experiência também. A ideia era simples: construir um projeto se inspirando no Instagram onde eu pudesse fazer “upload” de imagens e agrupá-las em álbuns, com descrições.

Mãos à obra!

Opengram foi criado com isso em mente. É um projeto muito simples com escopo limitado. Aqui estão alguns prints de alguns recursos:

Algumas dependências foram usadas para construir este projeto, como bcrypt, express, multer, bootstrap, axios, entre muitas outras, juntamente com o MongoDB como banco de dados. O front-end e o back-end foram divididos em dois repositórios, ambos dockerizados. No começo, tentei emular um aplicativo local do tipo Instagram, com login e vários usuários, mas… pensando no uso no mundo real, parece meio bobo ter vários usuários em um aplicativo da web local, não é? Ainda assim mantive o sistema de login que já havia implementado. Essa também foi minha primeira experiência com funções assíncronas em Node.js, foi interessante aprender mais sobre Promises.

Para saber mais sobre o código-fonte, clique aqui para conferir o repositório Opengram e aqui para acessar o Opengram Front.

Arquivo de Exoplanetas da Nasa

Sat, 23 Jul 2022 05:00:00 +0000

Este é um projetinho desenvolvido para aprender mais sobre APIs e gráficos em Python. O principal objetivo aqui foi coletar informações usando um endpoint que oferece dados de exoplanetas (que são planetas fora do nosso sistema solar). Os dados usados na aplicação são provenientes do site do Nasa Exoplanet Science Institute, por meio de uma chamada de API.

O Nasa Exoplanet Archive é um catálogo de estrelas e exoplanetas que reúne e correlaciona dados e informações sobre exoplanetas. Você pode conferir mais sobre o site e a iniciativa aqui.

Detalhes do Projeto

O projeto usa as seguintes bibliotecas externas:

FastApi para criar endpoints e expôr dados,
Requests para buscar informações do banco de dados do Nasa Exoplanet Archive,
MongoClient para salvar tais dados localmente,
Pandas + MatPlotLib para criar gráficos bacanas com os dados coletados.

Endpoints da API

/sync-database: endpoint que chama o site do Exoplanets’ Archive e coleta a resposta, salvando ou atualizando os dados existentes em um banco de dados local.

Curl:

curl -X 'GET' \
 'http://localhost:8000/sync-database' \
 -H 'accept: application/json'

Resposta:

{
 "code": 200,
 "message": "Database successfully updated 32606 elements",
 "data": "",
 "total_elements": 32606
}

Observações pessoais: este endpoint pode demorar um pouco para carregar. Tentei pegar leve ao construir a solicitação da API para o site da Nasa, selecionando apenas mais alguns parâmetros mais “interessantes” para construir meu banco de dados local:

file_url = "https://exoplanetarchive.ipac.caltech.edu/TAP/sync?" \
 "query=select+pl_name,sy_snum,sy_pnum,disc_year," \
 "discoverymethod,disc_facility,disc_locale," \
 "disc_telescope,pl_orbper,pl_rade,pl_bmasse+" \
 "from+ps&format=json"

Tomei a decisão de salvar tudo em um banco de dados Mongo apenas para testar a integração do MongoClient com o Pyhton, sem nenhum outro motivo especial além disso. E olha, no momento que fiz essa requisição arquivo da Nasa possui 32606 elementos! Isso é bem legal!

/planets: Retorna todos os exoplanetas paginados com o uso de filtros (nome do exoplaneta, método de descoberta, onde foi descoberto, ano de descoberta).

Curl:

curl -X 'GET' \
 'http://localhost:8000/planets?size=3&page_num=1&ordered=desc' \
 -H 'accept: application/json'

Resposta:

{
 "code": 200,
 "message": "Planets successfully retrieved",
 "data": [
 {
 "id": "62ddfacf34ec799ba78a342f",
 "planet_name": "TOI-1272 c",
 "number_of_stars": 1,
 "number_of_planets": 2,
 "discovery_year": 2022,
 "discovery_method": "Radial Velocity",
 "discovery_facility": "W. M. Keck Observatory",
 "discovery_locale": "Ground",
 "discovery_telescope": "10 m Keck I Telescope",
 "orbital_period": 8.689,
 "planet_earth_radius": null,
 "planet_earth_mass": 26.7,
 "link": "https://exoplanetarchive.ipac.caltech.edu/overview/TOI-1272 c"
 },
 {
 "id": "62ddfacf34ec799ba78a348b",
 "planet_name": "TOI-500 d",
 "number_of_stars": 1,
 "number_of_planets": 4,
 "discovery_year": 2022,
 "discovery_method": "Radial Velocity",
 "discovery_facility": "La Silla Observatory",
 "discovery_locale": "Ground",
 "discovery_telescope": "3.6 m ESO Telescope",
 "orbital_period": 26.233,
 "planet_earth_radius": null,
 "planet_earth_mass": 33.12,
 "link": "https://exoplanetarchive.ipac.caltech.edu/overview/TOI-500 d"
 },
 {
 "id": "62ddfacf34ec799ba78a348c",
 "planet_name": "TOI-500 e",
 "number_of_stars": 1,
 "number_of_planets": 4,
 "discovery_year": 2022,
 "discovery_method": "Radial Velocity",
 "discovery_facility": "La Silla Observatory",
 "discovery_locale": "Ground",
 "discovery_telescope": "3.6 m ESO Telescope",
 "orbital_period": 61.3,
 "planet_earth_radius": null,
 "planet_earth_mass": 15.05,
 "link": "https://exoplanetarchive.ipac.caltech.edu/overview/TOI-500 e"
 }
 ],
 "total_elements": 32606
}

Notas Pessoais: A resposta vem paginada e ordenada por ano de descoberta. Na resposta, todos os elementos possuem um link que leva ao site do Arquivo, para verificar mais informações sobre o exoplaneta em questão.

/plot/planet/discovery-year: Produz um gráfico com todos os planetas agrupados por ano de descoberta.

Curl:

curl -X 'GET' \
 'http://localhost:8000/plot/planet/discovery-year' \
 -H 'accept: application/json'

Resposta:

Notas pessoais: É muito louco concluir que o número de planetas descobertos foi expressivamente maior em 2014 e 2016. Tive que ajustar o gráfico para exibir o número de planetas usando a notação científica, já que a discrepância era tão grande que os valores dos outros anos quase não apareceram!

/plot/planet/discovery-method: Produz um gráfico com todos os planetas agrupados por método de descoberta.

Curl:

curl -X 'GET' \
 'http://localhost:8000/plot/planet/discovery-method' \
 -H 'accept: application/json'

Resposta:

Notas pessoais: Mais uma vez, descobrir planetas por trânsito (confira a explicação desse método de descoberta) parece ser a maneira mais popular de se descobrir exoplanetas. A visualização também foi ajustada à notação científica.

/plot/planet/discovery-facility: Produz um gráfico com todos os planetas agrupados por estação de descoberta.

Curl:

curl -X 'GET' \
 'http://localhost:8000/plot/planet/discovery-facility' \
 -H 'accept: application/json'

Resposta:

Notas Pessoais: Kepler ganha o prêmio como “estação” que mais descobriu exoplanetas!

/plot/planet/discovery-locale: Produz um gráfico com todos os planetas agrupados por local de descoberta.

Curl:

curl -X 'GET' \
 'http://localhost:8000/plot/planet/discovery-locale' \
 -H 'accept: application/json'

Resposta:

Notas Pessoais: O espaço é um ponto de vista bem privilegiado (Kepler que o diga!) para ver outros planetas. Há duas instâncias de “Multiple Locale” que poderiam ter sido mescladas, no entanto, achei divertido que uma possui S e a outra não e acabei deixando assim.

/plot/planet/discovery-telescope: Produz um gráfico com todos os planetas agrupados por telescópio usado na descoberta.

Curl:

curl -X 'GET' \
 'http://localhost:8000/plot/planet/discovery-telescope' \
 -H 'accept: application/json'

Resposta:

Notas pessoais: Foi um choque descobrir que em segundo lugar atrás do Kepler em número de exoplanetas descobertos estava a Canon 200mm f1.8, uma câmera com mais de 30 anos de idade!

Conclusão

Esta foi uma das minhas primeiras oportunidades de trabalhar com pandas e construir gráficos em Python e eu não poderia estar mais feliz! Eu gostei bastante de construir uma API e me diverti muito descobrindo mais sobre exoplanetas, que é um dos meus interesses pessoais. Você pode verificar o repositório com todo o código fonte aqui.

Criando uma skill de audio local na Alexa

Wed, 20 Jul 2022 22:00:00 +0000

Tutorial que mostra como criar uma Alexa Skill facilmente, chamando um arquivo de áudio externo para impressionar seus amigos e família.

Primeiros passos

Para começar, você precisa de uma conta de desenvolvedor da Amazon. Você pode criar clicando aqui e fazendo login com sua conta Amazon já existente, se já tiver uma, ou criando uma nova conta. No entanto, é importante observar que para “testar” sua habilidade em seu dispositivo, você deve usar a mesma conta do seu dispositivo Alexa.

Após o login, você deve acessar o Alexa Development Console, onde criaremos a primeira skill.

Criando uma skill

Para criar uma nova habilidade, basta clicar no botão Create Skill. Crie um nome para sua habilidade e selecione seu idioma padrão. Nas primeiras configurações Choose a model to add to your skill, deixe marcado no padrão como está (Custom) e selecione “Alexa-hosted (Node.js)” como opção na configuração Choose a method to host your skill's backend resources, se já não estiver selecionado. Quando tudo estiver pronto, clique em Create Skill. A próxima página pedirá que você escolher um novo template (Choose a template to add to your skill), e devemos selecionar a opção de começar do zero"Start from Scratch" e clicar em Continue with template. Voilà! Temos nossa habilidade criada e pronta para ser personalizada.

Adicionando um nome de invocação e interface de áudio

Com a habilidade criada, a primeira etapa é criar um nome de invocação. Esta é a frase/duas palavras que o Alexa usará para invocar nosso código. Para configurar isso, precisamos clicar em Invocation Name digitar a invocação desejada no campo abaixo de Skill Invocation Name e clicar em Save Model. Com isso configurado e pronto, há mais uma configuração que precisa ser feita: ativar nossa interface de áudio. Para fazer isso, clique na opção Interfaces que está localizada no menu à esquerda. Depois disso, marque o botão chamado Audio Player e salve a interface e o modelo de construção. A mensagem Quick build in progress será exibida. Aguarde até que a compilação esteja pronta e vamos para a próxima etapa!

Editando o código

O próximo passo é editar o código adicionando nosso arquivo de áudio! Precisamos especificar um URL que contém um áudio que se reproduz. Você pode auto-hospedar o áudio na AWS ou em qualquer host de sua escolha, ou pesquisar na web para encontrar um. No meu exemplo, usarei um áudio do My Instants.

Para editar o código, clique em Code no menu. Um editor de código no navegador aparecerá com vários arquivos. O que vamos editar é o index.js, e já deve estar aberto.

A próxima parte é fácil: substitua o seguinte código:

const speakOutput = 'Welcome, you can say Hello or Help. Which would you like to try?';
 return handlerInput.responseBuilder
 .speak(speakOutput)
 .reprompt(speakOutput)
 .getResponse();

por esse aqui:

const speakOutput = 'Its me, Mario!';
 return handlerInput.responseBuilder
 .speak(speakOutput)
 .addAudioPlayerPlayDirective('REPLACE_ALL', '*', 1, 0, null, null)
 .getResponse();

Explicando brevemente, o speakOutput corresponde à linha que o Alexa dirá para você quando nosso código for invocado. Você pode mudar o It's me, Mario! para o que você quiser, apenas certifique-se de escrever entre aspas simples. A mágica acontece assim: na linha .addAudioPlayerPlayDirective('REPLACE_ALL', '*', 1, 0, null, null), o '*' é o espaço reservado para nosso link de áudio. Troquei para ficar assim:

const speakOutput = 'Its me, Mario!';
 return handlerInput.responseBuilder
 .speak(speakOutput)
 .addAudioPlayerPlayDirective('REPLACE_ALL',
 'https://www.myinstants.com/media/sounds/its-me-mario.mp3', 1, 0, null, null)
 .getResponse();

Depois de adicionar seu arquivo de áudio ao código, você precisa Save e Deploy seu código, espere até que a implantação seja feita e pronto! Pera, falta testar 🤔

Ativando o modo de teste

Para finalmente chamar a habilidade em sua Alexa pessoal, há uma última etapa: ativar o modo de teste de habilidade. Para isso, basta clicar em Test localizado no menu acima do seu código, e alterar a opção Test is disabled for this skill. para Development. Agora você pode chamar sua Alexa e dizer seu nome de invocação para testar sua habilidade!

Notas finais

Esta é apenas uma opção para criar facilmente uma habilidade de uso pessoal, para ser usada localmente sempre no estágio de desenvolvimento. Não vamos aprofundar na publicação da habilidade para todo mundo neste tutorial.