DEV Community: William Queiroz

Drops #05: Meu guia para você aprender Go!

William Queiroz — Tue, 13 Jun 2023 15:37:56 +0000

Introdução

E ae dev, tudo bem com você?

Nesses últimos meses eu passei boa parte do meu tempo aprendendo a linguagem criada pelo Google e queridinha pela comunidade de desenvolvedores (principalmente os apaixonados por CLIs 😅): Go!

Foi um desafio e tanto, dado que eu tinha pouco tempo para isso e precisava entregar um projeto bem massa para outros desenvolvedores poderem utilizar e criar seus próprios projetos escritos em Go. No caminho encontrei barreiras e facilidades para quem busca aprender uma nova linguagem, pensando nisso, resolvi trazer um guia simples e objetivo para você orientar seus estudos e ter em mente alguns pontos para evitar algumas barreiras durante essa jornada de aprendizado! Bom, falei demais, a ideia desse "guia" é que ele seja vivo! A medida que eu for encontrando novos conteúdos vou atualizá-lo por aqui, btw.

Bora pro post?

Sumário

Crie um plano: o que você quer construir com Go?
Aprenda a testar seu código! Não subestime isso, ou ignore logo no início
Cuidado com “a comunidade de Go não faz isso”
Indicações de conteúdos
- Comunidades
- Cursos
- Outros
Links úteis
Finalizando...

Crie um plano: o que você quer construir com Go?

Antes de sair por ai buscando tutoriais pela internet e já sair colocando a mão na massa, pare um pouco, e reflita: o que você quer construir com Go? É muito fácil cairmos em um limbo onde não conseguimos visualizar a evolução do nosso aprendizado muito por conta de que se quer elaboramos um plano para isso! A pergunta é bem simples afinal, e com ela podemos até obter novas como: "O que dá para construirmos com Go?", "Por que raios o Google criou essa linguagem?", "Qual problema eles queriam resolver?".

"Comece do começo": elabore um plano com objetivos que sejam fáceis de atingir, e assim que atingi-lo, adicione mais "requisitos" ainda no mesmo projeto, e.g.:

Quero construir uma API com 1 endpoint hello world com Go;
Quero construir uma API com CRUD de TO-DOs com Go;
Quero construir uma API conectada ao Postgres com Go;
Quero adicionar testes na minha API com Go.

Claro que isso são exemplos simples, não estou entrando no detalhe do que é um fato: de que você precisará entender e aprender as especificidades da linguagem. Mas isso será muito mais fácil se você tiver um objetivo e algo que seja tangível durante esse processo!

Aprenda a testar seu código! Não subestime isso, ou ignore logo no início

Se você estiver vindo de outra linguagem, muito provavelmente (se você tiver o mínimo de preocupação com a qualidade e escalabilidade do seu projeto) você ficará curioso para entender como funcionam os testes no Go. Não caia na armadilha de pensar “ah, isso aqui eu posso ver depois, preciso construir minha API!”: é muito tranquilo aprender Go já com testes, isso irá facilitar a construção do seu projeto (pelo design e refactor), e também fará com que você tenha um código mais idiomático. Inclusive a recomendação desse tópico é pra esse excelente guia do Chris James: Learn Go with Tests (com a versão traduzida em pt-BR aqui: Aprenda Go com Testes). Apesar do guia estar utilizando a versão 1.16 do Go (e no momento em que eu escrevo esse artigo, já estamos na 1.20.5), não tive muitos problemas ao seguí-lo.

Cuidado com “a comunidade de Go não faz isso”

Meu amigo, isso aqui sem dúvida algum foi uma barreira e tanto 🤣 Como se não bastasse a "pressão" que (eu não sei você, mas eu sou expert nisso) colocamos em nós mesmos, sempre haverá alguém para fazer isso ainda melhor! HAHAHA

É óbvio que cada tecnologia/linguagem terá um jeito adequado ou mais correto de lidar com um certo problema, mas pense comigo: isso é algo realmente necessário de nos preocuparmos logo no começo? O que eu mais ouvi sobre a comunidade de Go (isso, sobre, e não diretamente da comunidade) é de que "X coisa não é feita assim", "A comunidade prefere convencionar de Y jeito". O ponto aqui é que será fácil encontrar opiniões nesse sentido, o que você precisa é filtrar bem o conteúdo que encontra por ai... Em alguns momentos você terá uma sensação como se alguém estivesse falando pra uma criança: "Olha, cuidado pra você não tropeçar e cair", sendo que ela nem se quer começou a "engatinhar" 🤣

Indicações de conteúdos

Aqui vou deixar alguns links de comunidades e cursos disponíveis na web que vão te ajudar muito! Nas comunidades é possível sanar dúvidas, buscar opiniões sobre um determinado assunto e acompanhar as novidades da linguagem da galera que está há mais tempo em contato com a linguagem (ou não hehehe).

Comunidades

LinkedIn: Go Developer Community: https://www.linkedin.com/groups/10541552/
Gophers: Slack oficial da comunidade Go: https://join.slack.com/t/gophers/shared_invite/zt-1x4z32nlf-QOO8r9eqA_C4kGa2YPlB2Q

Cursos

Aprenda Go 🇧🇷: Curso completo em português da linguagem Go construído pela Ellen Korbes

Apesar do conteúdo já ter mais de 3 anos, a playlist do curso está gratuita no YouTube e conta com mais de 180 vídeos que explora a linguagem com diversos exercícios.

Aprenda Go 🇧🇷 - YouTube

Curso completo em português da linguagem Go, de zero a ninja! 🇧🇷

youtube.com

Go 101: Curso 100% gratuito do blog Aprenda Golang, construído pelo Tiago Temporin.

GO 101 - YouTube

Curso completo e gratuito para quem está iniciando na linguagem Golang. Aqui você vai aprender tudo o que precisa para dar seus primeiros passos nessa lingua...

youtube.com

Outros

Google I/O: Apesar de não ser um conteúdo específico de Go, vou deixar a recomendação aqui para você acompanhar o Google I/O!

O Google I/O é uma conferência de programadores que é organizada anualmente pela Google em São Francisco, Califórnia, Estados Unidos. O objetivo dessa conferência é orientar os programadores a melhorarem seus programas com técnicas que a Google demonstra (e geralmente tem o Go na jogada!). Aqui estão os links das últimas 3 edições disponíveis no YouTube:

Gopher Academy: Talks!: A Gopher Academy é a força criativa por trás da GopherCon, uma conferência que celebra todas as coisas do Go! Desde sua estreia em 2014, a GopherCon desenvolveu algumas das melhores programações da comunidade Go. A GopherCon até inspirou reuniões em países como Reino Unido, Índia, Brasil, Cingapura, Rússia e China, com novas conferências globais surgindo todos os anos!

No canal do YouTube, você pode encontrar conteúdos mais específicos sobre Go, apresentados durante as edições da GopherCon. Aqui estão os links das últimas 3 edições disponíveis no YouTube:

Vale dizer que também temos a nossa edição BR, você pode encontrar mais detalhes aqui: https://gopherconbr.org.

Links úteis

gobyexample.com - uma introdução prática ao Go com vários exemplos: https://gobyexample.com
gosamples.dev - uma biblioteca de tutoriais e exemplos de Go que ajuda você a resolver problemas de código do dia a dia: https://gosamples.dev
avelino/awesome-go - uma lista com curadoria de incríveis frameworks, bibliotecas e software Go: https://github.com/avelino/awesome-go
Effective Go - um guia construído pelos mantenedores do Go para entendermos a suas propriedades e expressões idiomáticas: https://go.dev/doc/effective_go

💡 O documento "Effective Go" foi escrito para o lançamento do Go em 2009 e não foi atualizado significativamente desde então. Embora seja um bom guia para entender como usar a linguagem em si, graças à estabilidade da linguagem, fala pouco sobre as bibliotecas e nada sobre mudanças significativas no ecossistema Go desde que foi escrito, como o sistema de compilação, testes, módulos e polimorfismo.

A tour of Go - uma espécie de "tour" interativo construído pelos mantenedores do Go que cobre as características mais importantes da linguagem com diferentes lições: https://go.dev/tour/list

Finalizando...

Bem, é isso, por hoje, é só!

Quero te agradecer por chegar até aqui, e queria lhe pedir também para me encaminhar as suas dúvidas, comentários, críticas, correções ou sugestões sobre a publicação.

Deixe seu ❤️ se gostou ou um 🦄 se esse post te ajudou de alguma maneira! Não se esqueça de ver os posts anteriores e me siga para maaaais conteúdos.

Até!

Refresh Tokens: equilibrando segurança e usabilidade em aplicações!

William Queiroz — Fri, 17 Jun 2022 15:46:11 +0000

Photo by FLY:D on Unsplash

Sumário

Introdução
Problema
Solução: refresh tokens!
- O que é um access token?
- O que é um refresh token?
Autenticação com refresh token
Finalizando...

Introdução

E ae dev, tudo bem com você?

Hoje vamos falar especificamente de uma das camadas mais utilizadas num fluxo "moderno" de autenticação. Você já ouviu falar de Refresh Tokens? Em resumo, "tokens de atualização" são credenciais utilizadas para obter credenciais/tokens de acesso. Complicado?

Calma fica comigo, pega um café e garanta sua leitura!

Bora pro post?

Problema

Vamos criar uma cenário hipotético mas muito comum para quem está lidando com autenticação de aplicações. Imagine que um usuário queira acessar uma aplicação. Essa aplicação por sua vez possui uma tela de login onde o usuário precisará se autenticar para então acessar toda a parte interna da aplicação: dashboards, meu perfil, e etc.

Por questões de segurança, no momento em que o usuário se autenticou, foi definido que o tempo de sessão mínimo seja de apenas 5 minutos. O usuário então (sempre que expira a sua sessão) perde o acesso ao sistema, e deve inserir suas credenciais novamente para continuar navegando.

É evidente que o nosso usuário acaba tendo uma péssima experiência ao utilizar o nosso sistema...

Tendo isso em vista, conversamos com o time de segurança sobre aumentarmos o tempo de duração da sessão, mas isso implicaria em deixarmos a nossa aplicação menos segura para o nosso usuário...

Sendo assim, como evitar que os usuários tenham que realizar o login sempre que a sessão expire? Como equilibrar a segurança e a usabilidade na nossa aplicação?

Solução: refresh tokens!

Primeiro, vamos entender um pouco do fluxo de autenticação que temos até então.

O Client envia um usuário e senha para o servidor de autorização, as credenciais estando válidas o servidor devolve um access_token para o Client. O Client pode (e deve) utilizar o access_token nas requisições protegidas para as APIs. As APIs protegidas validam o access_token e devolvem o recurso solicitado pelo Client.

Com o fluxo atual, é inevitável que o usuário tenha a experiência que falamos antes. Isto porque as APIs protegidas verificam sempre se o access_token é válido, para então devolver o recurso pro usuário.

Precisamos melhorar esse fluxo, incluindo o mecanismo de refresh_token!

Vamos primeiro entender qual é a diferença entre um access_token e de um refresh_token.

O que é um access token?

O access token é um JWT (JSON Web Tokens) que é utilizado pelo usuário para acessar as aplicações e os recursos protegidos. Esse token é codificado (não encriptado) e carrega algumas informações presentes no Header, Payload e Signature (seções que compõe a estrutura base de um token JWT).

Geralmente ele possui um tempo de vida útil curto.

💡 jwt.io: JSON Web Tokens are an open, industry standard RFC 7519 method for representing claims securely between two parties.

O que é um refresh token?

O refresh token é um token utilizado para "renovar a sessão" de um usuário. Através dele podemos solicitar ao servidor de autorização para que seja gerado um novo access token sem ter que pedir ao usuário que ele se logue novamente (desde que o token de atualização seja válido e não tenha expirado).

É importante entender que:

Ele possui um tempo de vida útil maior do que o access_token;
É um token apenas para gerar um novo token de acesso. Não pode ser utilizado para acessar a aplicação. Porém, se expirado, o usuário deve realizar o login novamente;
Alguns IdPs (Identity Providers) utilizam o refresh token pra revogar as sessões ativas do usuário.

Estando claras as diferenças, vamos adaptar o nosso fluxo de autenticação!

Autenticação com refresh token

No novo fluxo o Client, toda vez que tiver uma solicitação rejeitada pela API protegida, deve solicitar ao servidor de autorização um novo token de acesso (utilizando o refresh token na solicitação). O servidor de autorização valida a solicitação (verificando se o refresh token está válido e não expirado) e concede ao Client o token de acesso.

Verificando as alterações no novo fluxo de autenticação:

Além de retornar o access_token, também retornamos o refresh_token durante o login do usuário (no POST /auth/login);
Adicionamos um nova rota no Authorization Server para possibilitar que o Client possa renovar a sua sessão (o POST /auth/refresh);

Finalizando...

Bem, é isso, por hoje, é só!

Quero te agradecer por chegar até aqui, e queria lhe pedir também para me encaminhar as suas dúvidas, comentários, críticas, correções ou sugestões sobre a publicação.

Deixe seu ❤️ se gostou ou um 🦄 se esse post te ajudou de alguma maneira! Não se esqueça de ver os posts anteriores e me siga para maaaais conteúdos.

Até!

Testes Unitários: Fundamentos e Qualidade de Software!

William Queiroz — Fri, 11 Mar 2022 12:41:38 +0000

Photo by Ferenc Almasi on Unsplash

Sumário

Introdução
Qualidade de Software
Por que eu devo testar meu código?
Tipos de testes
Testes Unitários
- Dicas para escrever bons testes unitários
O que são Test Doubles
- Dummies, Fakes, Spies, Stubs e Mocks
- Diferenças entre Mocks e Stubs
TDD: Test Driven Development
- TDD vs Escrever o teste depois
Análise de Qualidade de Software
- SonarQube
Finalizando...
Referências e Links

Introdução

E ae dev, tudo bem com você?

Hoje eu vim trazer um tema que eu gosto beeem pouco (sou apaixonado) que é sobre Testes Unitários e Qualidade de Software!

O post dessa vez está mais teórico que o normal por aqui, mas fica comigo, pega um café e garanta sua leitura!

Bora pro post?

Qualidade de Software

Antes de falarmos sobre testes, precisamos entender o que é que define a qualidade de um software. Da perspectiva de produto e negócios, do nosso "cliente", um software de qualidade é aquele que atende os requisitos funcionais, expectativa e necessidades do usuário final. E qual é a perspectiva do desenvolvedor quanto à qualidade?

Em 1977, James A. McCall propôs um modelo que define critérios de qualidade de software dividido em 3 pontos de vista distintos, sendo eles:

Operação: que são características relativas ao uso do produto.
Revisão: que é a capacidade do produto ser modificado e evoluído.
Transição: que remete a adaptabilidade à novos ambientes.

Tais critérios, são elencados a partir de cada ponto de vista:

Operação:

Corretitude: medida na qual o software satisfaz as especificações e objetivos visados pelo cliente.
Confiabilidade: medida que se pode esperar que um programa execute sua função com a precisão exigida.
Eficiência: é a quantidade de recursos computacionais exigidos para que um programa execute sua função, visando realizar a operação de forma 100% segura e performática.
Integridade: medida na qual, controla-se o acesso ao software e aos dados, bloqueando assim o acesso de pessoas não autorizadas, para que não ocorra perda de dados ou de código.
Usabilidade: mede a facilidade para a utilização do software.

Revisão:

Manutenção: mede o esforço exigido para localizar e reparar erros em um programa.
Flexibilidade: analisa o esforço utilizado para realizar uma alteração no software, isto é, qual o grau de facilidade que o software oferece para a sua alteração.
Testabilidade: analisa se é possível testar o funcionamento do software, não só por vias automatizadas.

Transição:

Portabilidade: mede a facilidade com que um produto pode ser movido para outra plataforma ou ambiente.
Reusabilidade: medida na qual o software, ou parte dele, poder ser reusado em outros softwares, em outras palavras, o código do software deve ser reaproveitável.
Interoperabilidade: capacidade do software ser acoplado à outro.

Dito isso, qualidade de software da perspectiva do desenvolvedor é uma área que visa garantir a qualidade do software por meio de normatizações e definições de processos de desenvolvimento. Testar é apenas uma das maneiras que temos para garantir a qualidade do nosso software. Ainda assim, vamos responder a seguinte pergunta.

Por que eu devo testar meu código?

Você em algum momento da sua carreira deve ter se perguntado: "será que se eu alterar isso aqui, isso ainda vai continuar funcionando? 🤔”. Já sentiu aquela insegurança na hora de fazer aquela feature ou refactor? Seu código/projeto não trazia nenhuma confiança quando estava tomando proporções maiores?

Pois é… e como saber se aquilo que você implementou funciona em conjunto com aquilo já foi implementado? A melhor maneira de saber se algo funciona é: testando.

Ao testar o seu projeto, você garante mais:

Confiabilidade;
Integridade, evolução e melhorias no código;
Velocidade nas entregas e demandas (uma vez que um código existente já possui testes, a preocupação nas mudanças e implementações futuras é menor, podendo-se ter mais agilidade e previsão ao decorrer do desenvolvimento); Isso vem em contrapartida de que se eu implementar testes durante a entrega eu vou levar mais tempo. Isso é gradual, à medida em que o software é contemplado com mais testes, mais demandas com qualidade são entregues.
Qualidade no software (fácil manutenção, flexível a alterações, testabilidade e etc, tudo que falamos na introdução);
Redução no tempo ao encontrar bugs;
Implementações mais objetivas e códigos mais limpos.

Agora que você já sabe os motivos pelos quais você deve implementar testes, vamos conhecer alguns dos tipos de testes!

Tipos de testes

Fonte: https://martinfowler.com/articles/practical-test-pyramid.html

A maioria das pessoas conhecem essa pirâmide graças à Mike Cohn que a descreveu no seu livro de 2009, Succeeding with Agile. No livro ele faz referência à "Test Automation Pyramid" (pirâmide de automação de testes) que popularmente ficou conhecida apenas como "Test Pyramid" (pirâmide de testes).

Ela é constituída por 3 camadas:

Testes Unitários
Testes de Serviço
Testes de Interface do Usuário

Pode-se observar que, à medida em que chegamos ao topo da pirâmide, menor é quantidade de testes que teremos e mais "caros" eles serão (pensando em processamento). Quanto menor é o isolamento, mais rápido será a execução dos nossos testes.

💡 Recebi uma excelente recomendação do Paulo Gonçalves, membro do Agile Testers de alternativas e materiais complementares à pirâmide de testes. Um deles é o artigo "Abordagem de testes" e a talk "AT Talks: Triângulos de Teste, Não Mais" da Samanta Cicilia. Os links você encontra na seção Referências e Links.

Testes Unitários

Estando na base da pirâmide, os testes unitários além de ser a fundamentação, eles são responsáveis por testar a menor unidade do nosso software de maneira isolada. "Tá, mas qual é a menor unidade do software?”: podem ser métodos/funções, classes, módulos, etc. Esses testes validam o comportamento esperado de um método/função: dada uma determinada execução espera-se uma saída.

Como testamos as funções do software, podemos ter diversos comportamentos a cada execução com determinadas condições e, consequentemente, vários testes. O teste unitário nos possibilita criar um código mais objetivo, com métodos limpos e com uma única e determinada funcionalidade (daí, associa-se também o conceito de "unidade”), sendo possível ser testado de maneira isolada.

Vamos ver um exemplo de teste unitário com JavaScript! Imagine que temos uma calculadora, e que centralizamos as funções das operações em um arquivo. Precisamos testar o comportamento esperado de cada uma dessas funções. No exemplo, espera-se que a função sum retorne a soma de a e b. Como seria o nosso teste?



// calculator.js
const sum = (a, b) => a + b;

export { sum };

// calculator.spec.js
import { sum } from './calculator.js';

describe('calculator.js', () => {
  it('should return the sum of a and b', () => {
    const a = 1;
    const b = 2;

    const result = sum(a, b);

    expect(result).to.equal(3);
  });
});

Na descrição do nosso teste, montamos o cenário de teste de acordo com a especificidade da função.

Você precisa ter a seguinte reflexão quando for escrever os seus testes unitários: "essa função/método deve fazer isso quando aquilo”. Ou seja, para um determinado comportamento, é necessária uma condição.

Dicas para escrever bons testes unitários

Escolha as melhores asserções para cada momento.
Evite ruídos e dependências entre os testes, garanta o isolamento. Se o seu teste depender de quaisquer fatores externos ele não é mais um teste unitário.
Utilize do teste unitário para definir o design do seu código. Durante a escrita dos testes, é comum identificarmos a necessidade de refatorar o código para melhorar o seu uso (e também isolá-lo). Aproveite desses momentos.
Por último, mas não menos importante: evite "estressar" camadas que excedam a barreira de unidade: banco de dados, 3rd party APIs... Os testes unitários sempre superarão os testes das camadas superiores da pirâmide. Garanta que a execução dos testes unitários seja rápida, use Test Doubles!

Por falar nisso, você sabe o que são Test Doubles?

O que são Test Doubles

Segundo Martin Fowler, "Test Doubles” é um termo genérico para qualquer caso que você queira substituir um objeto de produção para fins de teste. Pense em "dublê", aqueles de cinema mesmo, que "simulam” a aparência e o comportamento dos atores em um filme. Você provavelmente deve conhecer o conceito de maneira generalizada como "mockar" ou pela palavra "Mock". O fato é que Mock é apenas um dos tipos de "dublês" que temos disponíveis.

Além dele temos Dummies, Fakes, Spies e Stubs.

Dummies, Fakes, Spies, Stubs e Mocks

Dummies: são objetos ou dados fictícios que substituem dados reais mas que não utilizados nos testes geralmente. São usados para satisfazer parâmetros. Com o uso deles é possível diminuir a complexidade dos testes, focando no que importa.

Fakes: são objetos reais que implementam um comportamento que os torna inviável para serem utilizados em produção (um In-Memory Database, por exemplo).

Spies: são "espiões” para registrar as informações de uma determinada função. Pode ser usado para dizer se um específico método importante no escopo da função que está sendo testada foi chamado, quantas vezes, com quais argumentos e etc.

Stubs: são semelhantes aos spies porém, ele consegue substituir toda a implementação de um específico método, mudando o seu comportamento. São úteis para simular uma possível exceção, evitar estresse na camada de serviço: persistência de dados (evitando de gravar um registro no banco de dados, por exemplo); chamada à uma API ou integração a outros serviços possibilitando a diminuição no tempo de execução do teste.

Mocks: São similares ao stub porém, é a camada mais alta para tornar um comportamento falso, geralmente, são usados para emular um banco de dados, um output de dados ou até mesmo uma dependência, a diferença é que, com um stub, é possível testar diversas ramificações do seu código, já com o mock, é possível testar diversos comportamentos de uma só vez. Os Mocks tem expectativas sobre o jeito que ele deve ser chamado e, caso não seja chamado da forma correta, o teste deve falhar.

Diferenças entre Mocks e Stubs

Para entender a diferença entre mocks e stubs vamos imaginar que toda vez que um usuário criar uma conta no nosso software, um e-mail é disparado com uma mensagem de boas-vindas e dados referente à sua conta. No nosso cenário de testes não queremos enviar esse e-mail. Podemos usar mocks ou stubs, mas afinal... qual é a diferença?

Observemos a implementação abaixo retirada do artigo "Mocks Aren't Stubs” do Martin Fowler (sim, em Java mesmo hahaha). Criamos um stub que implementa o método send apenas com um contador (adicionando a mensagem para ser enviada na lista messages), ou seja, deixaremos de enviar o e-mail propriamente:



public interface MailService {
    public void send(Message msg);
}

public class MailServiceStub implements MailService {
    private List<Message> messages = new ArrayList<Message>();

    public void send(Message msg) {
        messages.add(msg);
    }

    public int numberSent() {
        return messages.size();
    }
}

Com nosso stub, podemos usar a verificação de estado no teste:



class OrderStateTester {

 public void testOrderSendsMailIfUnfilled() {
    Order order = new Order(TALISKER, 51);
    MailServiceStub mailer = new MailServiceStub();

    order.setMailer(mailer);
    order.fill(warehouse);

    assertEquals(1, mailer.numberSent());
  }
}

A verificação de estado ocorre através da asserção e utilização do método numberSent do nosso stub.

Usando mocks, nosso teste ficará um pouco diferente:



class OrderInteractionTester {
    // ...
    public void testOrderSendsMailIfUnfilled() {
        Order order = new Order(TALISKER, 51);

        Mock warehouse = mock(Warehouse.class);
        Mock mailer = mock(MailService.class);

        order.setMailer((MailService) mailer.proxy());

        mailer.expects(once()).method("send");
        warehouse.expects(once()).method("hasInventory")
            .withAnyArguments()
            .will(returnValue(false));

        order.fill((Warehouse) warehouse.proxy());
    }
}

Lembra que falamos que os mocks tem expectativas sobre o jeito que ele deve ser chamado? Aqui criamos as expectativas (espera-se que o método mailer.send deve ser chamado ao menos 1 vez e o método warehouse.hasInventory seja chamado ao menos uma vez, com qualquer argumento e retornará false quando chamado. Se por ventura alguma dessas expectativas não forem atendidas, nosso teste falhará.

Em ambos os casos usamos Test Doubles ao invés do nosso serviço de e-mail (evitando o estresse externo). A principal diferença é que com stub utilizamos a verificação por estado e com o mock usamos a verificação do comportamento.

TDD: Test Driven Development

Agora que tivemos uma introdução ao universo dos testes unitários, vamos conhecer um método muito comum atualmente para a construção de testes unitários: o TDD!

TDD é uma sigla para "Test Driven Development", em português "Desenvolvimento Orientado à Testes. A técnica foi criada/descoberta em 2003 pelo engenheiro de software americano Kent Beck (um dos pais do eXtreme Programming ou simplesmente, XP) e declara que o TDD é um método que encoraja designs de código simples e inspira confiança.

O método se baseia em ciclos ou etapas de desenvolvimento que visam que uma implementação permita que um teste tenha um resultado positivo. Confuso não?

Calma que eu explico!

Fonte: https://www.rcelebrone.com/2021/03/podcast-teste-unitario-automatizado-tdd.html

Como mencionei, a ideia do TDD é que você trabalhe em ciclos. Iniciando a partir da escrita de um teste para a sua solução. O TDD é composto em 3 ciclos, aplicados na seguinte ordem:

Red: escreva um teste que irá falhar. Isso mesmo! Pense em como você teria um teste caso o seu código estivesse implementado.
Green: a partir disso, implemente o código que satisfaça as condições do seu teste. O intuito nessa fase é que o código implementado, faça com que o teste criado no ciclo anterior passe.
Refactor: na fase anterior, você precisava apenas fazer com que o teste passasse, nesse ciclo você deve focar em melhorar os pontos que não eram uma preocupação: legibilidade, reuso, duplicidade. Deixando-o funcional, e mais limpo. Consequentemente (e é comum), o seu teste criado no primeiro ciclo, pode vir a falhar com a refatoração. No próximo ciclo, você deve fazer com que o teste passe.

O ciclos são iterativos até que os testes e a implementação satisfaça as especificidades solução.

TDD vs Escrever o teste depois

Ressaltando que o TDD é uma metodologia para desenvolvimento e escrita de código, você deve estar se perguntando: "Po, mas o que eu ganho escrevendo o teste antes? Será que vale a pena?”

O que irá manter a qualidade do nosso software será a quantidade de testes produzidos durante a prática do TDD, como qualquer outra metodologia, você só conseguirá ver os reais ganhos colocando-a em prática, é no dia-a-dia que isso acaba ficando mais claro.

Uma das principais vantagens do uso de TDD é que o desenvolvedor acabar tendo mais feedback dos testes, e a quantidades de feedbacks também é maior!

Pense comigo: é melhor implementar testes em um sistema "legado" (onde a quantidade de código é muito maior para ser testado) ou aplicar TDD no inicio do projeto onde a base de código ainda é pequena? Quanto maior é a quantidade de código escrito, maior será o custo da mudança. Ao aplicar o TDD, o desenvolvedor recebe o feedback em um momento onde as mudanças ainda são baratas!

Análise de Qualidade de Software

Falamos muito sobre testes e qualidade de software, mas mais do que garantir, como podemos mensurar e analisar como anda a qualidade do nosso código-fonte?

Existem ferramentas poderosíssimas que podem nos auxiliar à deixar um código mais limpo e mais seguro para ir para produção. É comum as empresas adotarem táticas para evitar que um projeto com pouca qualidade (isso envolve segurança e todos os outros quesitos mencionados na introdução desse artigo) seja implantado no ambiente produtivo. Afinal é muito melhor prevenir do que remediar.

Uma excelente ferramenta utilizada amplamente no mercado é o SonarQube!

SonarQube

O SonarQube é uma ferramenta de revisão automática de código para detectar bugs, vulnerabilidades, falta de cobertura de teste e code smells em seu código. Ele pode ser integrado em esteiras de CI/CD para permitir a inspeção contínua de código em todas as branchs do projeto e pull requests.

O fluxo de análise do projeto é baseado no seguinte:

O desenvolvedor abre um Pull Request com o código novo criado e testado.
Num workflow de CI/CD, a pipeline de CI é acionada a partir do PR criado.
A pipeline de CI executa os comandos do projeto para realizar a execução dos testes e extrair a cobertura do código.
A pipeline de CI envia os metadados coletados para o SonarQube a partir de uma integração.
O SonarQube recebe os metadados e disponibiliza uma dashboard com um overview completo sobre o seu projeto.

Existem diversas outras ferramentas e serviços (como Coveralls e Codecov), cabe você avaliar o que faz mais sentido utilizar no momento.

Finalizando...

Bem, é isso, por hoje, é só!

Quero te agradecer por chegar até aqui, e queria lhe pedir também para me encaminhar as suas dúvidas, comentários, críticas, correções ou sugestões sobre a publicação.

Deixe seu ❤️ se gostou ou um 🦄 se esse post te ajudou de alguma maneira! Não se esqueça de ver os posts anteriores e me siga para maaaais conteúdos.

Até!

Referências e Links

Drops #04: Desmistificando ponteiros no Golang!

William Queiroz — Sun, 04 Jul 2021 21:13:14 +0000

Introdução

E ae dev, tudo bem com você?

Agora que FINALMENTE finalizei o MBA, aproveitei o tempo livre para dedicá-lo aos estudos do Golang.

Confesso que eu estou apaixonado pela linguagem - ainda dando os primeiros passos claro - mas creio que já dá pra compartilhar uma parada muito massa da linguagem (e como ela implementa) que são os ponteiros!

Bora pro post?

Ah! mas antes disso... Esse post faz parte de uma série de artigos "drops" que tenho aqui! Veja a lista:

Afinal, o que é um ponteiro?

Um ponteiro (ou apontador) nada mais é do que uma variável que, ao invés de armazenar um valor (true, "hello world"), ela armazena um endereço que está alocado na memória.

Memória

Vamos entender a imagem a seguir:

Basicamente, bem a grosso modo, a memória é constituída por elementos que armazenam informações.

O endereço é uma posição onde os dados serão colocados (geralmente expressos em números hexadecimais). Eles podem conter apenas uma única informação.

O dado, por sua vez, é a informação presente em cada posição na memória.

Quando criamos uma variável, ela recebe um endereçamento na memória e através dessa variável podemos armazenar valores que serão alocados nesse endereço:

Aqui podemos ler o seguinte:

A variável a que possui o endereço de memória 0xc000192020 está armazenando o dado 10 na posição deste endereço.

Ponteiros no Go

É muito simples definir um ponteiro, basta adicionar o * junto ao tipo do ponteiro que estamos criando:



package main

import "fmt"

func main() {
    var p *int

    fmt.Println(p) // output: <nil>
}

💡 O tipo do ponteiro indica qual é o tipo de dado que esse ponteiro irá manipular. No caso acima, criamos um ponteiro que pode "apontar" para endereços na memória de variáveis que armazenam dados do tipo inteiro.

No Go temos o conceito de zero value que, ao definir uma variável sem atribuir um valor para ela, o Go irá atribuir um valor padrão para essa variável. Cada tipo possui o seu valor padrão (0 para int, false para bool...), no caso do nosso ponteiro, o zero value será nil dado que não atribuímos nenhum valor para ele. Ou melhor dizendo: nenhum endereço!

E como podemos definir um endereço para o ponteiro? 🤔

Primeiro, criaremos outra variável no nosso código, e então, vamos atribuir o endereço dela para o ponteiro dessa forma:



package main

import "fmt"

func main() {
    var p *int

    i := 10

    p = &i // atribuindo o endereço de i para o ponteiro

    fmt.Println(p) // output: algo como 0xc000192020
}

💡 O & usado antes da variável, indica que queremos obter o endereço na memória daquela variável.

A representação gráfica do que fizemos aqui está na imagem a seguir:

💡 Note que o ponteiro que criamos, também possui o seu próprio endereço na memória!

Beleza, entendi! Até aqui o ponteiro já tá "apontando" pra um endereço... mas como eu faço pra saber o que esse endereço aí tá armazenando? 🤔

Basta utilizar o operador * junto ao ponteiro (*p). Esse é o processo de desreferenciar o ponteiro para que, ao invés dele retornar o endereço armazenado, ele ir lá naquele endereço e a partir de lá retornar o valor:



package main

import "fmt"

func main() {
    var p *int

    i := 10

    p = &i

    fmt.Println(p)  // output: 0xc000192020
    fmt.Println(*p) // output: 10
}

Uma vez que desreferenciamos o ponteiro, podemos manipular o dado que está armazenado naquele endereço:



package main

import "fmt"

func main() {
    var p *int

    i := 10

    p = &i

    fmt.Println(p)  // output: 0xc000192020
    fmt.Println(*p) // output: 10

    *p = 20

    fmt.Println(i)  // output: 20
    fmt.Println(*p) // output: 20
}

A representação gráfica do que fizemos aqui está na imagem a seguir:

Quando usar ponteiros?

No Go, por padrão, tudo é Pass By Value. Isso significa que, quando passamos uma variável como parâmetro de uma função, essa variável é "duplicada" na memória e o que fazemos dentro do escopo da função acontece apenas no escopo da função:



package main

import "fmt"

func increment(a int) int {
    a++

    fmt.Println(a) // output: 11

    return a
}

func main() {
    x := 10

    increment(x)

    fmt.Println(x) // output: 10
}

Como é realizada uma "cópia" da variável na memória, isso tem um custo, que pode se tornar problemático quando lidamos com um grande volume de dados nessa variável. Para economizarmos essa operação, é possível trabalhar com Pass By Reference com a ajuda de ponteiros:



package main

import "fmt"

func increment(a *int) {
    *a++

    fmt.Println(*a) // output: 11
    fmt.Println(a)  // output: 0xc0000180b0
}

func main() {
    x := 10

    increment(&x)

    fmt.Println(x)  // output: 11
    fmt.Println(&x) // output: 0xc0000180b0
}

Perceba que a função increment não retorna mais o valor manipulado e que além disso, passou a exigir um ponteiro/endereço de memória como parâmetro (a *int).

Dessa maneira, o parâmetro da função increment não foi duplicado na memória e passamos a trabalhar com a referência da variável x (que está fora do escopo da função increment).

A grosso modo, podemos trabalhar com ponteiros uma vez que lidamos com um volume grande de dados ou simplesmente querer trabalhar com Pass By Reference ao invés de Pass By Value.

É importante entender que existem pontos positivos e negativos ao trabalhar com ponteiros. Nós podemos e devemos usá-los mas precisamos ter certeza do que estamos fazendo.

Ou seja: depende! HAHA Cabe a você avaliar os melhores cenários.

Finalizando...

Bem, é isso, por hoje, é só!

Quero te agradecer por chegar até aqui, e queria lhe pedir também para me encaminhar as suas dúvidas, comentários, críticas, correções ou sugestões sobre a publicação.

Deixe seu ❤️ se gostou ou um 🦄 se esse post te ajudou de alguma maneira! Não se esqueça de ver os posts anteriores e me siga para maaaais conteúdos.

Até!

Configurando e publicando aplicações NodeJS no Nexus Repository Manager 3

William Queiroz — Mon, 01 Feb 2021 20:59:31 +0000

Introdução

E ae dev, tudo bem com você?

Fazia um tempo que não publicava nada por aqui, eis então que surgiu uma oportunidade de falar sobre o Nexus Repository Manager 3.

O Nexus é um gerenciador de repositórios e artefatos! Ele possibilita termos nosso próprio Docker Hub e NPM privados!

Hoje vou mostrar como configurá-lo para publicar suas aplicações NodeJS, e compartilhá-las entre projetos.

Ao final deste artigo, você irá:

Configurar um contêiner Nexus para publicação de projetos NodeJS.
Configurar aplicações para publicação no Nexus.

Bora pro post?

Sumário

Criando um contêiner Docker com o Nexus
- Obtendo a senha do usuário padrão
Configurando o Nexus
- Criando um usuário para publicação de pacotes
- Configurando um armazenamento Blob
- Criando um repositório privado (hosted)
- Criando proxy para NPM público e agrupamento de repositórios
Configurando aplicação para publicação no Nexus
- Habilitando Realm NPM de autenticação no Nexus
- Realizando a publicação da aplicação no Nexus
- Salvando configurações de login no projeto (basic)
Instalando dependências a partir do Nexus
Finalizando...
FAQ
- Devo versionar o arquivo .npmrc contendo as credenciais do Nexus no projeto?

Criando um contêiner Docker com o Nexus

Bom, inicialmente, precisaremos configurar o Nexus localmente para realizarmos as configurações para habilitar o nosso "NPM privado". Felizmente, a Sonatype disponibiliza uma imagem Docker pronta para executarmos!

Vamos começar subindo um contêiner docker com o seguinte comando:



$ docker run -d -p 8081:8081 --name nexus sonatype/nexus3:3.29.2

Em seguida vamos visualizar os logs desse contêiner:



$ docker logs nexus -f

Como o processo de inicialização desse contêiner é demorado, aguarde até visualizar a seguinte saída nos logs:



-------------------------------------------------

Started Sonatype Nexus OSS 3.29.2-02

-------------------------------------------------

Veja mais em: https://help.sonatype.com/repomanager3/installation/installation-methods#InstallationMethods-InstallingwithDocker

Após isso, acesse a URL http://localhost:8081/, você visualizará a tela inicial do Nexus:

Obtendo a senha do usuário padrão

No canto inferior direito, clique em Sign in. Você visualizará essa tela:

Perceba que aqui, temos que obter a senha do usuário padrão (admin), em /nexus-data/admin.password.

Vamos acessar o contêiner e obter a senha com os comandos:



$ docker exec -it nexus /bin/bash

$ echo "$(cat /nexus-data/admin.password)" # d9f3e86b-1a5d-45f8-a851-afcba3d05fdb

Copie a saída do segundo comando e realize o login.

Avance na janela de configuração exibida, e defina uma nova senha. Em seguida, marque a opção Disable anonymous access.

Isso fará com que apenas usuários logados possam navegar no nosso Nexus.

Saia do contêiner digitando exit no terminal.

Configurando o Nexus

Antes de sermos capazes de armazenar nossos projetos no Nexus, é necessário realizar algumas configurações.

Criando um usuário para publicação de pacotes

Vamos no painel, na barra superior e clique no símbolo de engrenagem e navegue em Security / Users. Clique em Create local user e crie o usuário com as seguintes informações:

Campo	Valor
ID	npmuser
First name	NPM
Last name	User
Email	npmuser@company.com
Password	npmuser
Confirm Password	npmuser
Status	Active
Granted	nx-admin

Configurando um armazenamento Blob

Aqui criaremos uma partição lógica que queremos impor para nossos diferentes tipos de projeto, ou seja, queremos segregar nossos binários NPM e binários Maven, por exemplo, para evitar quaisquer conflitos (de nome ou outros).
Internamente, o Nexus apenas cria pastas diferentes para cada armazenamento de Blob que criamos.

Veja mais em: https://help.sonatype.com/repomanager3/high-availability/configuring-blob-stores#ConfiguringBlobStores-WhatisaBlobStore?

Navegue em Repository / Blob Stores, clique em Create blob store e crie o blob store com as seguintes as informações:

Campo	Valor
Type	File
Name	NPM
Path	/nexus-data/blobs/NPM

Qualquer pacote que enviarmos agora (para esse Blob) será persistido no volume sob a pasta associada à ele.

Criando um repositório privado (hosted)

Esse repositório será responsável por manter todos os nossos projetos privados que enviamos ao Nexus.

Navegue em Repository / Repositories, clique em Create repository. O Nexus trará uma lista de recipes disponíveis para configuração. Selecione npm (hosted) e crie o repositório com as seguintes informações:

Campo	Valor
Name	npm-private
Blob store	NPM
Deployment Policy	Allow redeploy

Aqui, em Blob store, selecionamos aquele que criamos anteriormente. É interessante falar que, em Deployment Policy, estamos habilitando o "redeploy" para ser possível sobrescrever a mesma versão do pacote que é enviado.

Note que aqui isso é configurando apenas pro nosso exemplo. Essa estratégia deve ser analisada juntamente com o time responsável que realizará a manutenção dos projetos mantidos no Nexus.

Criando proxy para NPM público e agrupamento de repositórios

O repositório proxy realiza o proxy (duh!) de todas as nossas solicitações de leitura para o registro público do NPM (https://registry.npmjs.org).

Já o repositório group combina o repositório proxy e o hosted para possibilitar a instalação de bibliotecas de terceiros (NPM) quanto as privadas (npm-private).

Ainda em Repository / Repositories, clique em Create repository. Selecione npm (proxy) e crie o repositório com as seguintes as informações:

Campo	Valor
Name	npm-proxy
Remote Storage	https://registry.npmjs.org
Blob store	NPM

Voltando para Repository / Repositories, clique em Create repository. Selecione npm (group) e crie o repositório com as seguintes as informações:

Campo	Valor
Name	npm-group
Blob store	NPM
Members	npm-proxy, npm-private

Configurando aplicação para publicação no Nexus

Afim de agilizar o processo de configuração, eu já deixei um projeto pré-configurado para brincarmos aqui. Baixe o projeto com o comando abaixo:



$ git clone https://github.com/wnqueiroz/nodejs-nexus-repository-setup.git

O nosso objetivo aqui será publicar a application-a no Nexus, e realizar a instalação dela na application-b.

Acesse o projeto application-a, e abra o package.json.

Note que lá temos uma configuração de publicação:



{
  // ...
  "publishConfig": {
    "registry": "http://localhost:8081/repository/npm-private/"
  }
}

Ou seja, toda vez que executarmos o comando npm publish, o NPM irá utilizar o repositório privado (que criamos lá atrás, npm-private) como registry de publicação.

A mesma configuração está disponível na application-b.

Em um terminal, na application-a, vamos tentar realizar a publicação do projeto. Execute o comando:



$ npm publish

Perceba que não foi possível realizar a publicação, pois ainda não estamos logados na CLI do NPM:



npm ERR! code E401
npm ERR! Unable to authenticate, need: BASIC realm="Sonatype Nexus Repository Manager"

Vamos realizar o login no repositório privado, usando o usuário de publicação que criamos em Criando um usuário para publicação de pacotes.

Execute o comando abaixo informando as crendenciais de acesso:



$ npm login --registry=http://localhost:8081/repository/npm-private/

Em seguida, tente realizar a publicação novamente:



$ npm publish

Veja que, mesmo logados, ainda temos o mesmo problema:



npm ERR! code E401
npm ERR! Unable to authenticate, need: BASIC realm="Sonatype Nexus Repository Manager"

Isso acontece por que precisamos dizer ao Nexus, que ele aceite esse tipo de publicação (logados localmente através da CLI). Para fazer isso, vamos habilitar um dos Realms do Nexus, precisamente o npm Bearer Token Realm.

Habilitando Realm NPM de autenticação no Nexus

Os Realms no Nexus, nada mais são de que um mecanismo de segurança para segregar os tipos de autenticação permitidas.

Veja mais em: https://help.sonatype.com/repomanager3/system-configuration/access-control/realms

Voltando à interface do Nexus, na seção de configuração, acesse Security / Realms. Selecione npm Bearer Token Realm em Available, e adicione na guia Active:

Clique em Save para finalizar a configuração.

Realizando a publicação da aplicação no Nexus

Voltando ao terminal na application-a, vamos tentar realizar novamente a publicação do projeto. Execute o comando:



$ npm publish

Veja que agora conseguimos realizar a publicação! 🚀🎉



npm notice
npm notice 📦  application-a@1.0.0
npm notice === Tarball Contents ===
npm notice 39B  src/index.js
npm notice 321B package.json
npm notice === Tarball Details ===
npm notice name:          application-a
npm notice version:       1.0.0
npm notice package size:  368 B
npm notice unpacked size: 360 B
npm notice shasum:        f40f2d6547110507a8d72481be0614eab3e9b659
npm notice integrity:     sha512-Aw1e784PXCFUT[...]BQKZZEnlJ61Yg==
npm notice total files:   2
npm notice
+ application-a@1.0.0

Salvando configurações de login no projeto (basic)

Em alguns casos, não podemos utilizar a CLI do NPM para realizar o login (usando STDIN e STDOUT), como por exemplo, em um ambiente de CI. Podemos configurar o nosso projeto para utilizar uma autenticação básica (um pouco diferente da autenticação através do Realm e Login).

Na raiz do projeto, crie um arquivo .npmrc com o seguinte conteúdo:



email=npmuser@company.com
always-auth=true
_auth=<BASE_64_TOKEN>

Em um terminal, gere o Base64 do usuário e senha que criamos em Criando um usuário para publicação de pacotes:



$ echo -n 'npmuser:npmuser' | openssl base64 # bnBtdXNlcjpucG11c2Vy

Substitua <BASE_64_TOKEN> no .npmrc com o Base64 gerado. Seu arquivo deve estar com o seguinte conteúdo:



email=npmuser@company.com
always-auth=true
_auth=bnBtdXNlcjpucG11c2Vy

Agora vamos validar a configuração realizando o logout da CLI do NPM e publicando o pacote novamente. Em um terminal, na application-a, execute os comandos:



$ npm logout --registry=http://localhost:8081/repository/npm-private/
$ npm publish

Aqui, como habilitamos o "redeploy" em Criando um repositório privado (hosted), é possível sobrescrevermos a versão 1.0.0, publicada anteriormente.

Veja que agora conseguimos realizar a publicação sem realizarmos o login na CLI do NPM! 🚀🎉

Instalando dependências a partir do Nexus

Agora vamos configurar a application-b para instalarmos a application-a no projeto.

Vamos copiar o conteúdo do .npmrc criado na application-a e vamos criar um .npmrc na application-b:



email=npmuser@company.com
always-auth=true
_auth=bnBtdXNlcjpucG11c2Vy

Aqui também vamos adicionar o registry com o npm-group:



registry=http://localhost:8081/repository/npm-group/

Usamos o repositório npm-group para conseguirmos obter tanto as aplicações públicas (direto do NPM registry, através do repositório npm-proxy) tanto quanto as aplicações privadas (através do repositório npm-private). E como dito anteriormente, isso só é possível pois agrupamos esses repositórios no npm-group.

Ao final, seu arquivo deverá conter o seguinte:



email=npmuser@company.com
always-auth=true
_auth=bnBtdXNlcjpucG11c2Vy
registry=http://localhost:8081/repository/npm-group/

Vamos testar a configuração realizando a instalação da application-a na application-b. Em um terminal, na application-b, execute o comando:



$ npm install application-a

Aqui já conseguimos instalar aplicações em outros projetos a partir do Nexus.

Agora, vamos instalar o axios para testar se conseguimos instalar aplicações públicas, direto do registry do NPM:



$ npm install axios

Finalizamos todas as nossa configurações! 🚀🎉

Caso tenha alguma dúvida, ou tenha deixado passar alguma configuração, no projeto base existe uma branch com toda a configuração realizada até aqui:

https://github.com/wnqueiroz/nodejs-nexus-repository-setup/tree/final-setup

Finalizando...

Bem, é isso, por hoje, é só!

Quero te agradecer por chegar até aqui, e queria lhe pedir também para me encaminhar as suas dúvidas, comentários, críticas, correções ou sugestões sobre a publicação.

Deixe seu ❤️ se gostou ou um 🦄 se esse post te ajudou de alguma maneira! Não se esqueça de ver os posts anteriores e me siga para maaaais conteúdos.

Até!

FAQ

Devo versionar o arquivo .npmrc contendo as credenciais do Nexus no projeto?

Bem, idealmente, nenhum arquivo contendo informações sensíveis devem ser "versionados" no SCM. Toda e qualquer informação inerente à ambiente, devem estar disponíveis através de variáveis de ambiente. Entretanto, a CLI do NPM não nos permite realizar o login sem ser através de STDIN e STDOUT (de maneira não interativa). O CircleCI por exemplo, sugere para inserirmos o token _auth no arquivo .npmrc em tempo de execução na própria pipeline (obtendo o token através de uma variável de ambiente), algo como:



$ echo -n "_auth=$NPM_TOKEN" >> .npmrc

A variável $NPM_TOKEN deve conter o token de autenticação.

Alternativamente, existem algumas soluções como a https://www.npmjs.com/package/npm-cli-login, que possibilita realizar o login no NPM através de variáveis de ambiente.

A decisão é dada através de um alinhamento com todo o time para que não só a esteira de CI funcione, mas também a possibilidade do desenvolvedor ter mais flexibilidade quando for atuar nos projetos privados.

Pessoalmente, eu crio um usuário "devops" com específicas permissões e mantenho o arquivo .npmrc com o _auth. O combinado não sai caro! 😏

Drops #03: Usando aliases para importação de módulos em TypeScript!

William Queiroz — Thu, 22 Oct 2020 21:09:45 +0000

Introdução

E ae dev, tudo bem com você?

Você já deve ter trabalhado com projetos onde as importações de arquivos e módulos eram (ou ficaram) cada vez mais aninhadas. Em um determinado momento você se perde a cada "ponto, ponto, barra, ponto, ponto, barra" (e ainda espera um pouquinho pra ver se o editor de texto ajuda a completar o caminho, pra onde você realmente quer ir (profundo, não?).

Seria muito mágico se houvesse uma maneira de alterar isso:



import { MyClass } from "../../../../deep/module";

Pra isso:



import { MyClass } from "@/deep/module";

Pois é, e TEM!

Bora pro post?

Ah! mas antes disso... Esse post faz parte de uma série de artigos "drops" que tenho aqui! Veja a lista:

Iniciando o projeto

Vamos começar criando um projeto e inicializando o nosso package.json:



mkdir ts-module-aliases && cd ts-module-aliases && yarn init -y

Em seguida, vamos adicionar algumas dependências de desenvolvimento, sendo elas:

O TypeScript (duh!);
O ts-node-dev (que será responsável por rodar o nosso código em modo de desenvolvimento);
O Jest (precisaremos configurar algumas coisas no Jest para que ele interprete os caminhos absolutos que usaremos no nosso código);
O tsconfig-paths (esse carinha será responsável por viabilizar o uso dos aliases).
O Babel (ficará encarregado de realizar a construção do nosso projeto, interpretando os aliases e transpilando o código com os caminhos respectivos).

Execute o comando:



yarn add typescript@4.0.3 ts-node-dev@1.0.0 jest@26.6.0 ts-jest@26.4.1 @types/jest@26.0.15 tsconfig-paths@3.9.0 @babel/core@7.12.3 @babel/cli@7.12.1 @babel/node@7.12.1 @babel/preset-env@7.12.1 @babel/preset-typescript@7.12.1 babel-plugin-module-resolver@4.0.0 -D

Note que aqui foram fixadas as versões de cada dependência. Apenas para que a minha configuração e a sua sejam feitas com as mesmas versões dos pacotes.

Depois de instalar as dependências vamos iniciar as configurações!

Configurando o TypeScript

Na raiz do projeto, crie um arquivo tsconfig.json com a seguinte configuração:



{
  "compilerOptions": {
    "target": "es2017",
    "module": "commonjs",
    "lib": ["es6", "dom"],
    "allowJs": true,
    "rootDir": ".",
    "outDir": "./dist/lib",
    "declarationDir": "./dist/@types",
    "declaration": true,
    "removeComments": true,
    "esModuleInterop": true,
    "resolveJsonModule": true,
    "skipLibCheck": true,
    "forceConsistentCasingInFileNames": true
  },
  "include": ["src/**/*", "**/*.spec.ts"]
}

Criando a base do projeto

Depois de configurar o Typescript, vamos criar alguns arquivos partindo da raiz do projeto, dentro da pasta src:

src/services/BarService.ts:



export class BarService {
  bar() {
    console.log(`Hi! I'm bar method from BarService :)`);
  }
}

src/controllers/FooController.ts:



import { BarService } from "../services/BarService";

export class FooController {
  private readonly barService: BarService;

  constructor() {
    this.barService = new BarService();
  }

  foo() {
    this.barService.bar();
  }
}

src/index.ts:



import { FooController } from "./controllers/FooController";

const fooController = new FooController();

fooController.foo();

Para finalizar, vamos adicionar o script no package.json que executa o nosso código em modo de desenvolvimento:



{
  "scripts": {
    "dev": "ts-node-dev --no-notify src/index.ts"
  }
}

Perceba que até aqui, ainda não temos um bom exemplo de arquivos SUPER aninhados. Será possível visualizar isso ao criarmos os nossos arquivos de testes!

Configurando o Jest

Na raiz do projeto, crie um arquivo jest.config.js com a seguinte configuração:



// For a detailed explanation regarding each configuration property, visit:
// https://jestjs.io/docs/en/configuration.html

module.exports = {
  clearMocks: true,
  coverageDirectory: "__tests__/coverage",
  coverageProvider: "v8",
  preset: "ts-jest",
  testEnvironment: "node",
  testMatch: ["**/__tests__/**/*.spec.ts"],
};

NOTA: os testes da nossa aplicação, ficarão na raiz do projeto, dentro da pasta __tests__.

Vamos então criar os nossos arquivos de testes. Partindo da raiz do projeto, dentro da pasta __tests__:

__tests__/unit/controllers/FooController.spec.ts:



import { FooController } from "../../../src/controllers/FooController";
import { BarService } from "../../../src/services/BarService";

describe("Unit: FooController", () => {
  let fooController: FooController;

  beforeEach(() => {
    fooController = new FooController();
  });

  describe("foo", () => {
    it("should call bar method from BarService", () => {
      const spy = jest.spyOn(BarService.prototype, "bar").mockImplementation();

      fooController.foo();

      expect(spy).toBeCalled();
    });
  });
});

__tests__/unit/services/BarService.spec.ts:



import { BarService } from "../../../src/services/BarService";

describe("Unit: BarService", () => {
  let barService: BarService;

  beforeEach(() => {
    barService = new BarService();
  });

  describe("foo", () => {
    it("should call console.log", () => {
      const spy = jest.spyOn(console, "log").mockImplementation();

      barService.bar();

      expect(spy).toBeCalledWith(`Hi! I'm bar method from BarService :)`);
    });
  });
});

Olha ai, os benditos "ponto, ponto, barra, ponto, ponto, barra"!

Configurando os aliases no projeto

Vamos adicionar a configuração abaixo no tsconfig.json:



{
  "compilerOptions": {
    // (...)
    "baseUrl": "./",
    "paths": {
      "@/*": ["./src/*"]
    }
  }
}

Esse mapeamento, fará com que todo @/* seja um alias para ./src/* (com o baseUrl sendo a raiz do nosso projeto).

Vamos agora, fazer com que o ts-node-dev seja capaz de entender os nossos aliases. Adicione no script de dev (no package.json), O trecho -r tsconfig-paths/register:



- "dev": "ts-node-dev --no-notify src/index.ts"
+ "dev": "ts-node-dev -r tsconfig-paths/register --no-notify src/index.ts"

A partir daqui, podemos alterar as importações! Altere isso:



import { FooController } from "../../../src/controllers/FooController";
import { BarService } from "../../../src/services/BarService";

Para isso:



import { FooController } from "@/controllers/FooController";
import { BarService } from "@/services/BarService";

NOTA: Altere todas as importações para usarmos o alias ao invés dos ../ ou ./.

Ao executarmos o comando yarn dev, já podemos utilizar os aliases durante o desenvolvimento, porém, ao executarmos o yarn test, o Jest ainda não é capaz de entender os caminhos que estamos utilizando...

Vamos adicionar a propriedade moduleNameMapper no arquivo jest.config.js e fazer a seguinte configuração:



const { pathsToModuleNameMapper } = require("ts-jest/utils");
const { compilerOptions } = require("./tsconfig.json");

module.exports = {
  // (...)
  moduleNameMapper: pathsToModuleNameMapper(compilerOptions.paths, {
    prefix: "<rootDir>",
  }),
};

Com isso, já é possível utilizarmos os aliases nas nossas importações!

O problema

Até aqui, conseguimos configurar os aliases e utilizá-los tanto nos arquivos de testes quanto no source do projeto. Entretanto, precisamos ainda configurar o comando de construção do nosso projeto, somente assim ele estará pronto para publicarmos e utilizarmos no ambiente produtivo.

Vamos configurar o comando yarn build para construir o nosso projeto, e o comando yarn start para executar a o pacote construído.

Adicione os scripts no package.json.



{
  "scripts": {
    // (...)
    "build": "tsc",
    "start": "node dist/lib/src/index.js"
  }
}

A seguir, execute o comando:



yarn build && yarn start

Você perceberá que o projeto não pode ser executado, por conta do seguinte erro:



❯ yarn start
yarn run v1.22.5
$ node dist/lib/src/index.js
internal/modules/cjs/loader.js:968
  throw err;
  ^

Error: Cannot find module '@/controllers/FooController'
Require stack:

Isso ocorre por que o tsc não é capaz de entender esses aliases, inclusive, para nossa versão de produção, pouco importa se estamos usando aliases ou caminhos relativos, o que importa é que funcione!

Outro problema também, é que se notarmos os arquivos que foram construídos na nossa pasta dist vamos encontrar todos os nossos arquivos de testes! O que não faz sentido algum ir pro ambiente de produção, não é mesmo?

Precisamos então:

Fazer com que o comando de build gere um pacote funcional.
Fazer com que o comando de build empacote apenas o código que irá para produção (e remover os arquivos de testes de lá).

Vamos fazer tudo isso com a substituição do tsc pelo babel!

NOTA: O babel será responsável por alterar os nossos aliases, para os respectivos caminhos no projeto

Configurando o Babel

Como já adicionamos as dependências do Babel no inicio do artigo, vamos começar o arquivo babel.config.js na raiz do projeto, com a seguinte configuração:



module.exports = {
  presets: [
    [
      "@babel/preset-env",
      {
        targets: {
          node: "current",
        },
      },
    ],
    "@babel/preset-typescript",
  ],
  plugins: [
    [
      "module-resolver",
      {
        root: ["."],
        alias: {
          "^@/(.+)": "./src/\\1",
        },
      },
    ],
  ],
  ignore: ["**/*.spec.ts"],
};

Com isso o babel irá alterar todo ^@/(.+) para ./src/\\1, e.g.: @/services/BarService para ../services/BarService.

Vamos agora criar o arquivo tsconfig.build.json que irá herdar todas as configurações do nosso tsconfig.json e será usado apenas para criar os arquivos de declaração de tipos do projeto (dentro da pasta dist/@types). Isso é necessário, pois o Babel não fará esse trabalho. Adicione o seguinte no arquivo:



{
  "extends": "./tsconfig.json",
  "compilerOptions": {
    "rootDir": "./src"
  },
  "exclude": ["node_modules", "dist", "**/*.spec.ts"]
}

Em seguida, altere o script start (não precisaremos mais do src ali) e o de build.

Adicione também o script postbuild no package.json:



{
  "scripts": {
    "start": "node dist/lib/index.js",
    "build": "babel src --extensions \".js,.ts\" --out-dir dist/lib --copy-files --no-copy-ignored",
    "postbuild": "tsc -p tsconfig.build.json --emitDeclarationOnly"
  }
}

Vamos apagar a pasta dist gerada anteriormente, construir o projeto com o Babel, e então rodar o comando de produção:



rm -rf dist && yarn build && yarn start



yarn run v1.22.5
$ babel src --extensions ".js,.ts" --out-dir dist/lib --copy-files --no-copy-ignored
Successfully compiled 3 files with Babel (704ms).
$ tsc -p tsconfig.build.json --emitDeclarationOnly
✨  Done in 3.74s.
yarn run v1.22.5
$ node dist/lib/index.js
Hi! I'm bar method from BarService :)
✨  Done in 0.35s.

E Voilà!

Foi bastante coisa feita aqui! Espero que você tenha conseguido usar essa funcionalidade massa nos seus projetos, e entendido cada detalhe da configuração. No final desse artigo eu deixo o exemplo completo que desenvolvemos juntos!

Finalizando…

Bem, é isso, por hoje é só!

Quero agradecer a você que chegou até aqui, e queria lhe pedir também para encaminhar-me as suas dúvidas, comentários, críticas, correções ou sugestões sobre a postagem.

Deixe seu ❤️ se gostou ou um 🦄 se esse post te ajudou de alguma maneira! Não se esqueça de ver os posts anteriores e me siga para maaaais conteúdos.

Até!

wnqueiroz / typescript-tsconfig-paths

An example project on how to configure tsconfig-paths

Criando e automatizando o versionamento semântico de projetos NodeJS

William Queiroz — Tue, 11 Aug 2020 14:53:07 +0000

Photo by Johnson Wang on Unsplash

Introdução

E ae dev, tudo bem com você?

Desde que eu comecei a trabalhar com JavaScript do lado do servidor, e a utilizar as mais diversas bibliotecas lá do NPM, sempre me questionei como elas eram mantidas... Desde as suas versões publicadas, padrões dos projetos que podem ser seguidos por um ou mais desenvolvedores, ou até mesmo por uma equipe dedicada apenas nisso.

A questão que mais me intrigava era: como saber quais versões DEVEM ser publicadas, quando uma alteração é feita?

Bom, com base nisso, nos últimos dias dediquei os estudos a explorar os mais variados repositórios no GitHub, e as bibliotecas mais populares no momento no NPM. Identifiquei alguns padrões que podem facilitar a manutenção dos projetos com automatização de processos!

Ao final deste artigo, você irá:

Entender a importância de padronizar um projeto, antes de desenvolver.
Entender como funciona um versionamento semântico.
Entender o que são commits semânticos.
Aprender a automatizar a publicação/distribuição do seu projeto com base no versionamento.

Bora pro post?

Sumário

O problema
Entendendo o versionamento semântico
Entendendo o que são commits semânticos
- Especificação Conventional Commits
- Por que usar?
- Como isso se relaciona com o SemVer?
Hands-On
- Iniciando o projeto
- Habilitando a padronização de commits semânticos
- Instalando o husky e integrando-o ao commitlint
- Facilitando a criação de commits padronizados
- Gerando versões semânticas e CHANGELOG
Workflow de desenvolvimento

O problema

Imagine que você esteja trabalhando com o cenário, onde as versões do seu projeto precisam ser coerentes com cada ajuste que você precise fazer, isto é, as versões devem indicar aquilo que foi feito. Seja uma implementação de uma nova funcionalidade, uma correção de um bug, ou até mesmo um breaking change por remover uma feature ou mudar completamente a integração do seu projeto, com os demais projetos que o utilizam.

A coerência com as versões do seu projeto irá auxiliar na manutenção do projeto como um todo!

O SemVer está aqui para nos ajudar!

Entendendo o versionamento semântico

Vamos entender melhor como funciona a especificação SemVer!

Ela aborda um conjunto simples de regras e requisitos que determinam como os números da versão são atribuídos e por sua vez, incrementados.

"Sob esse esquema, os números da versão e a maneira como eles mudam transmitem significado sobre o código subjacente e o que foi modificado de uma versão para a seguinte".

Em resumo, dado o número de versão MAJOR.MINOR.PATCH, deve-se incrementá-las seguindo as seguintes regras:

MAJOR: quando você realizar alterações incompatíveis da API;
MINOR: quando você adicionar funcionalidades compatíveis com versões anteriores;
PATCH: quando você corrigir erros compatíveis com versões anteriores.

Para a nossa configuração, o essencial está nesse resumo. Você pode ler mais sobre a especificação em: https://semver.org/

Recomendo também a leitura da seção FAQ disponível no site, lá você encontrará respostas para dúvidas do tipo: "Como sei quando lançar a 1.0.0?".

A especificação SemVer foi originalmente criada por Tom Preston-Werner, inventor do Gravatar e co-fundador do GitHub.

Entendendo o que são commits semânticos

Você em algum momento já se questionou como deveria escrever uma mensagem de commit (se deveria colocar muitos detalhes, descrever melhor o que fez no corpo do commit, usar algum prefixo, e etc.).

Seria mágico termos algum padrão para usarmos no nosso projeto, que siga uma maneira consistente e coesa de escrever os commits, e que informe exatamente o que foi feito ali, não é mesmo?

Pois é, e TEM!

Especificação Conventional Commits

A especificação Conventional Commits é inspirada e baseada fortemente no guideline de commits do Angular. É uma convenção bem simples para seguir ao escrever commits e que oferece um conjunto fácil de regras para manter um histórico de commits mais explícito e facilmente compreendido.

Em resumo, para seguir a especificação, um commit deve ser estruturado da seguinte maneira:



<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

O commit pode conter alguns elementos estruturais, que comunicam a intenção aos "consumidores" do seu projeto:

fix: um commit "do tipo" fix indica que aquela alteração corrige algum bug no projeto (isso se correlaciona ao PATCH do SemVer);
feat: um commit "do tipo" feat indica que aquela alteração adiciona alguma nova funcionalidade ao projeto (isso se correlaciona ao MINOR do SemVer);
BREAKING CHANGE: um commit que possui um rodapé com BREAKING CHANGE ou está diretamente na mensagem com ! depois do type ou scope, indica que aquela alteração, muda a compatibilidade da sua API com os "consumidores" (isso se correlaciona com o MAJOR do SemVer). Um BREAKING CHANGE pode fazer parte de commits de qualquer type;
Outros tipos além de feat e fix também são permitidos.

Um scope pode ser fornecido ao type do commit, para fornecer informações contextuais adicionais e pode ser encontrado entre parênteses na mensagem, e.g.:



feat(parser): add ability to parse arrays.

Você pode ler a especificação completa em: https://www.conventionalcommits.org/en/v1.0.0/#specification

Por que usar?

Ao adotar os padrões no seu projeto, você poderá:

Determinar automaticamente o bump das versões (de maneira semântica, com base nos tipos dos commits criados);
Comunicar com clareza a natureza das alterações (seja aos colegas de equipe ou ao público);
Automatizar o processo de build e publicação/distribuição do projeto.
Gerar CHANGELOGs automaticamente.

Outro ganho é que os desenvolvedores serão encorajados a granularizar os commits, uma vez que os padrões adotados visam contextualizar melhor a alteração feita (com tipos, escopos, e etc.). Isso é muito bom ao trabalhar com Code Review e Pull Requests.

Como isso se relaciona com o SemVer?

Como vimos, os tipos dos commits se relacionam com cada "acrônimo" da especificação SemVer:

fix: deve ser traduzido em liberações de PATCH;
feat: deve ser traduzido em liberações MINOR;
BREAKING CHANGE: deve ser traduzido, independentemente do tipo, em liberações MAJOR;

Hands-On

Bom, agora que já entendemos como o versionamento e os commits semânticos funcionam, vamos criar um projeto com as configurações ideais para:

Realizar o incremento automático de versões (coesas, através da análise dos commits);
Realizar a geração automática do arquivo CHANGELOG.md.
Realizar a distribuição/publicação da versão gerada (com a ajuda de CI/CD).

TL;DR: O arquivo CHANGELOG.md, na raiz do projeto, contém o descritivo de todas as alterações (pertintentes) feitas naquele específico projeto. A razão para criar e manter um changelog é simples: quando um colaborador ou usuário final deseja verificar se alguma alteração foi feita em um software, ele pode fazer isso com facilidade e precisão lendo o registro de alterações. Tudo o que eles precisam fazer é ir para o changelog e ele mostrará o que e quando as alterações foram feitas entre as diferentes versões ou lançamentos daquele software.

Iniciando o projeto

Vamos criar um novo projeto NodeJS e criar o package.json, com o seguinte comando:



$ mkdir my-project && cd my-project && yarn init -y

Posteriormente, usaremos um hook do Git para que a cada vez que realizarmos um commit, seja feita uma análise do commit em questão para identificar se ele está ou não no padrão especificado pelo Conventional Commits. Então, vamos inicialiazar o git no projeto:



$ git init

Habilitando a padronização de commits semânticos

Para realizar a análise dos commits criados, precisamos de uma ferramenta que fará esse trabalho e nos auxiliará a adotar os padrões que vimos anteriormente. Vamos então instalar e configurar o commitlint.

Comece instalando os pacotes cli e config-conventional do commitlint nas dependências de desenvolvimento:



$ yarn add -D @commitlint/{config-conventional,cli}

Vamos criar o arquivo de configuração commitlint.config.js na raiz do projeto com o trecho abaixo:



module.exports = {
  extends: ["@commitlint/config-conventional"],
};

Valide as configurações com o comando:



echo 'foo: bar' | yarn commitlint

Você deverá visualizar no terminal algo como:



⧗   input: foo: bar
✖   Please add rules to your `commitlint.config.js`
    - Getting started guide: https://git.io/fhHij
    - Example config: https://git.io/fhHip [empty-rules]

✖   found 1 problems, 0 warnings
ⓘ   Get help: https://github.com/conventional-changelog/commitlint/#what-is-commitlint

Instalando o husky e integrando-o ao commitlint

Bom, até aqui, apenas configuramos a ferramenta que realiza análise dos nossos commits. Para que ela seja usada, a cada novo commit, precisaremos instalar o husky e configurá-lo com o commitlint.

Comece instalando o husky como dependência de desenvolvimento:



$ yarn add -D husky

Vamos agora habilitar o hook commit-msg criando um arquivo .huskyrc (na raiz do projeto) com o trecho abaixo:



{
  "hooks": {
    "commit-msg": "commitlint -E HUSKY_GIT_PARAMS"
  }
}

Valide a configuração criando um commit, no seguinte formato:



$ git commit -m "foo: bar" --allow-empty

Você deverá visualizar no terminal algo como:



husky > commit-msg (node v12.16.1)
⧗   input: foo: bar
✖   Please add rules to your `commitlint.config.js`
    - Getting started guide: https://git.io/fhHij
    - Example config: https://git.io/fhHip [empty-rules]

✖   found 1 problems, 0 warnings
ⓘ   Get help: https://github.com/conventional-changelog/commitlint/#what-is-commitlint

husky > commit-msg hook failed (add --no-verify to bypass)

Perceba que o husky habilitou o hook commit-msg, o commitlint, por sua vez, foi executado e fez a análise do que escrevemos. Com isso os nossos commits serão analisados antes de serem criados!

Para que haja sucesso na criação do commit, ele deve estar padronizado seguindo a especificação.

Facilitando a criação de commits padronizados

Imagine que você esteja realizando um commit, e por ventura não se lembre de algum tipo que esteja na especificação, ou até mesmo não lembre do formato específico que comunique um breaking change, por exemplo. O Commitizen disponibiliza uma CLI que nos auxilia na criação de commits padronizados.

Essa configuração, é opcional, mas é bem interessante tê-la aqui para os futuros colaboradores terem mais facilidade e entendimento quanto aos padrões do projeto.

Comece configurando a CLI no repositório com o comando:



$ npx commitizen init cz-conventional-changelog --yarn --dev

Será adicionado ao package.json:



{
  "config": {
    "commitizen": {
      "path": "./node_modules/cz-conventional-changelog"
    }
  }
}

A seguir, vamos adicionar um script ao package.json para iniciar a CLI:



{
  "scripts": {
    "commit": "git-cz"
  }
}

Execute o comando yarn commit --allow-empty. Você verá a ferramenta entrar em ação!

A flag --allow-empty, apesar de intuitiva vale a pena informar que ela possibilita a criação de commits sem ser necessário adicionar uma modificação em staged.

É possível definir o commitizen como padrão ao executar git commit no terminal, veja mais em: https://github.com/commitizen/cz-cli#optional-running-commitizen-on-git-commit

Extra: se o seu projeto for open-source, com essa configuração, é possível adicionar a badge "commitizen friendly" no README.md do repositório:



[![Commitizen friendly](https://img.shields.io/badge/commitizen-friendly-brightgreen.svg)](http://commitizen.github.io/cz-cli/)

Gerando versões semânticas e CHANGELOG

Até aqui, já podemos gerar os commits semânticos. Através deles, utilizaremos uma ferramenta que realiza a análise dos commits novos (adicionados desde a última versão do projeto) e determina qual será essa nova versão para a distribuição. Por padrão, ela também criará o CHANGELOG.md automaticamente de acordo com a análise feita.

Vamos configurar o projeto com o standard-version.

Comece instale o standard-version como dependência de desenvolvimento:



$ yarn add -D standard-version

Em seguida, adicione o script abaixo no package.json:



{
  "scripts": {
    "release": "standard-version"
  }
}

Ao executar o comando yarn release (ou npm rum release):

Será realizada a análise dos commits feitos após o último release.
Será incrementada a versão do projeto no package.json, com base na análise dos commits.
Será gerado o CHANGELOG.md, incluindo os detalhes da nova versão.
Será criada uma tag com base na versão do package.json.

Para remover o prefixo "v" da tag, basta adicionar a flag -t sem nenhum valor no script criado, e.g.: standard-version -t \"\".

Depois de executar o comando, você pode publicar o projeto com o npm publish e enviar a tag gerada para o repositório remoto com git push --follow-tags origin master.

Workflow de desenvolvimento

Com ajuda de uma esteira de CI/CD, é possível automatizar o processo de publicação/distribuição de novas versões, para que a cada nova modificação na branch master, sejam executados os comandos:

Gerando uma nova versão: yarn release (ou nom run release);
Publicando a nova versão: npm publish
Enviando a tag gerada para o repositório: git push --follow-tags origin master

Mas para que isso seja possível, deve-se seguir o seguinte fluxo de desenvolvimento:

Criar uma nova feature branch a partir da branch principal (master);
Realizar as alterações e "commitá-las" nos padrões estabelecidos pelas especificações;
Mesclar as alterações na branch principal via Pull Request;
A esteira de CI/CD deve ser acionada assim que houver uma nova alteração na branch principal, e (além de executar outros passos durante o processo, como testes, coleta de cobertura, lint, e etc.) incluir os comandos mencionados anteriormente.

Finalizando...

Bem, é isso, por hoje, é só!

Quero te agradecer por chegar até aqui, e queria lhe pedir também para me encaminhar as suas dúvidas, comentários, críticas, correções ou sugestões sobre a publicação.

Deixe seu ❤️ se gostou ou um 🦄 se esse post te ajudou de alguma maneira! Não se esqueça de ver os posts anteriores e me siga para maaaais conteúdos.

Até!

Drops #02: Como alterar o autor do commit depois do push

William Queiroz — Mon, 06 Jul 2020 19:07:18 +0000

Photo by Yancy Min on Unsplash

E ae dev, tudo bem com você?

Semana passada eu finalmente comecei a usar o dev.to, inaugurando-o com um post que eu havia escrito originalmente lá no Medium, se você ainda não leu, já salva pra ler mais tarde: Drops #01: Corrigindo vulnerabilidades em dependências com Yarn! (ou quase)

Bom, continuando essa série "drops" com dicas e truques que eu uso no dia-a-dia...

Quem nunca subiu um código para o repositório depois de ter "comitado" com o usuário que você usa na empresa, não é mesmo? HAHAHA

Calma, isso é mais comum do que você imagina. Ainda mais se costuma utilizar uma única máquina tanto para o seu trabalho, quanto para aqueles projetos pessoais que você costuma publicar no Github.

A dica de hoje é de como alterar o autor do commit depois de já tê-lo enviado ao seu repositório remoto.

Bora pro post?

Ah! mas antes disso... Esse post faz parte de uma série de artigos "drops" que tenho aqui! Veja a lista:

Alterando o usuário do repositório

Antes de realizarmos as alterações nos commits, vamos definir o usuário que, daqui pra frente, será o autor dos commits futuros.

Para isso, abra um terminal na pasta do seu repositório, e execute os comandos abaixo:

git config --local user.email "<GIT_EMAIL>" --replace-all
git config --local user.name "<GIT_USER>" --replace-all

NOTA: a flag --replace-all irá substituir todas as configurações anteriores.

Altere <GIT_EMAIL> e <GIT_USER> para os seus respectivos valores.

Opcional:

Eu costumo armazenar as credenciais usando o helper store, essa configuração evita que uma janela de credenciais seja aberta a cada interação com o repositório remoto.

Caso você queira usar a mesma configuração, execute o comando abaixo:

git config --local credential.helper store

Veja mais em: https://git-scm.com/docs/git-credential-store

Note que todos os comandos, servirão apenas para o repositório atual, caso queira essa configuração em outros repositórios, basta repetir o processo nos repositórios desejados.

Selecionando os commits para alteração

O git-rebase é uma ferramenta poderosíssima, que nos permite alterar a linha do tempo sem ser necessário gerar novas ramificações. Com isso é possível juntar commits, reordenar, removê-los, e um bocado de outras coisas.

Vamos utilizá-lo para selecionar os commits!

Se você quer alterar todos os commits, desde o primeiro, basta executar o seguinte comando:

git rebase -i --root

Caso queira alterar apenas os 3 ou N últimos commits, basta utilizar o comando git rebase -i HEAD~3 ou git rebase -i HEAD~n, sendo n o número de commits que deseja alterar.

Isso abrirá um arquivo chamado git-rebase-todo, que é exatamente ali onde informaremos o que queremos fazer com os commits, e.g.:

pick 687f049 foo: bar
pick 25a798a fooz: barz

# Rebase f157872..25a798a onto f157872 (2 commands)
#
# Commands:
# p, pick <commit> = use commit
# r, reword <commit> = use commit, but edit the commit message
# e, edit <commit> = use commit, but stop for amending
# s, squash <commit> = use commit, but meld into previous commit
# f, fixup <commit> = like "squash", but discard this commit's log message
# x, exec <command> = run command (the rest of the line) using shell
# b, break = stop here (continue rebase later with 'git rebase --continue')
# d, drop <commit> = remove commit
# l, label <label> = label current HEAD with a name
# t, reset <label> = reset HEAD to a label
# m, merge [-C <commit> | -c <commit>] <label> [# <oneline>]
# .       create a merge commit using the original merge commit's
# .       message (or the oneline, if no original merge commit was
# .       specified). Use -c <commit> to reword the commit message.
#
# These lines can be re-ordered; they are executed from top to bottom.
#
# If you remove a line here THAT COMMIT WILL BE LOST.
#
# However, if you remove everything, the rebase will be aborted.
#
# Note that empty commits are commented out

No nosso caso, iremos substituir pick por edit:

- pick 687f049 foo: bar
+ edit 687f049 foo: bar
- pick 25a798a fooz: barz
+ edit 25a798a fooz: barz

Podemos então, salvar a edição do arquivo, e fechá-lo.

Alterando o autor

No terminal, veremos a seguinte saída após fechar o arquivo:

You can amend the commit now, with

  git commit --amend 

Once you are satisfied with your changes, run

  git rebase --continue

Beleza! Estamos prontos.

Para cada um dos commits, iremos alterar o autor, com o seguinte comando:

git commit --amend --author="<GIT_USER> <<GIT_EMAIL>>" --no-edit
# e.g.: git commit --amend --author="Lorem Ipsum <lorem@ipsum.com>" --no-edit

Altere <GIT_EMAIL> e <GIT_USER> para os seus respectivos valores.

Após isso, você deve continuar para o próximo commit, que selecionou na edição do git-rebase-todo:

git rebase --continue

Esse processo ocorre para cada commit. Quando finalizado, o rebasing é concluído.

Aqui é importante observar que, você não conseguirá enviar de volta os commits modificados com apenas o comando git push. Isso porque estamos reescrevendo a nossa linha do tempo, isso significa que devemos substituir a branch atual que existe lá no remoto.

Para isso, devemos usar a flag --force:

git push --force

E Voilà!

Alteramos o autor dos commits lá do repositório e ainda garantimos que os próximos commits sejam criados com o usuário correto!

Finalizando…

Bem, é isso, por hoje, é só!

Quero agradecer a você que chegou até aqui, e queria lhe pedir também para encaminhar-me as suas dúvidas, comentários, críticas, correções ou sugestões sobre a postagem.

Deixe seu ❤️ se gostou ou um 🦄 se esse post te ajudou de alguma maneira! Não se esqueça de ver os posts anteriores e me siga para maaaais conteúdos.

Até!

Drops #01: Corrigindo vulnerabilidades em dependências com Yarn! (ou quase)

William Queiroz — Thu, 02 Jul 2020 20:03:20 +0000

Photo by Alexander Sinn on Unsplash

Disclaimer

E ae dev, tudo bem com você?

Esse post foi originado lá no meu Medium, estou migrando-o para cá, pois adotarei o dev.to por diversas vantagens em relação ao Medium (o suporte ao Markdown me venceu heauehau).

Bora pro post?

Ah! mas antes disso... Esse post faz parte de uma série de artigos "drops" que tenho aqui! Veja a lista:

Fala pessoal!! Quanto tempo!

Alguns dias atrás, acessei o repositório de um exemplo que usei no post: Entendendo a Context API do React: criando um componente de loading e me deparei com isso:

Eu precisava então atualizar as dependências desse projeto lá no meu Github. E como tenho utilizado o Yarn como gerenciador de pacotes principal, quis fazer o processo de correção com ele.

Até aí, BELEZA.

Entretanto, notei que o Yarn até possui um script para executar a auditoria das dependências do projeto, porém, não inclui a atualização automática e transparente delas (assim como o NPM faz com o npm audit fix).

Se você executar no seu terminal o script yarn audit --help, verá que de fato não existe um script que corrija automaticamente as dependências com vulnerabilidades…

Você pode ler mais sobre o comando audit do Yarn em: https://classic.yarnpkg.com/en/docs/cli/audit

Existem algumas issues no repositório do Yarn, solicitando o recurso e etc. Não vou entrar tanto em detalhes, mas você pode dar uma olhada começando por aqui: https://github.com/yarnpkg/yarn/issues/5808

Troubleshoot

A ideia aqui é aproveitar o script do NPM, e ainda assim continuar utilizando o Yarn como o gerenciador principal dos seus pacotes.

Inicialmente, vamos obter apenas package-lock.json que o NPM gera ao instalar as dependências (mais à frente explicarei o porque disso):



npm i --package-lock-only

Então utilizaremos o script npm audit fix. Ele utilizará o package-lock.json gerado:



npm audit fix

O comando atualizará a dependências passíveis de atualização.

E o que eu quero dizer com isso? O comando é capaz de identificar possíveis breaking changes que impactam diretamente o seu projeto. Você talvez veja na saída do terminal algo como:

"x" vulnerabilities required manual review and could not be updated

Você pode usar a flag -- force, porém, o NPM irá avisá-lo: I sure hope you know what you are doing HAHA

Veja mais sobre em: https://docs.npmjs.com/cli/audit

Ainda não terminamos! Até então, temos o arquivo package-lock.json criado e, possivelmente, o package.json modificado no projeto. O lock de dependências de um projeto que utiliza o Yarn como gerenciador, é o arquivo yarn.lock.

O que faremos aqui, é gerar esse arquivo a partir do nosso package-lock.json.

Antes de executar o comando a seguir, remova o arquivo yarn.lock para não termos algum problema na criação do novo arquivo com o yarn import:



rm yarn.lock && yarn import

Veja mais sobre em: https://classic.yarnpkg.com/en/docs/cli/import/

E Voilà!

Temos o yarn.lock fresquinho, com as correções feitas pelo NPM, e prontinho para ser versionado!

Ah! Não esqueça de remover o package-lock.json gerado lá no início.

Finalizando…

Bem, é isso, por hoje, é só!

Quero agradecer a você que chegou até aqui, e queria lhe pedir também para encaminhar-me as suas dúvidas, comentários, críticas, correções ou sugestões sobre a postagem.

Deixe seu ❤️ se gostou e me siga para mais conteúdos.

Até!