DEV Community: Samuel Rodrigues Almeida e Sousa

O que achei do Bootcamp Java com Spring Boot organizado pela Dio e Claro

Samuel Rodrigues Almeida e Sousa — Thu, 21 Nov 2024 19:47:37 +0000

introdução

Descobri por acaso o Bootcamp Java com Spring Boot organizado pela Dio e Claro e resolvi fazer por dois motivos:

Gosto de programar e conhecer uma linguagem nova de programação é tipo um hobby
Java é uma linguagem bastante usada no mercado e historicamente importante.

Após concluir o bootcamp resolvi escrever minhas impressões sobre o curso.

Os desafios que fiz durante o curso estão no github: https://github.com/samuelralmeida/exercises-dio-java

sobre o objetivo do curso

Na página de apresentação do curso aparece qual é o perfil do público destinado o curso e o objetivo dele:

“Profissionais que desejam entrar ou evoluir suas práticas no mercado como desenvolvedor back-end construindo e implementando APIs com Java e Spring, com foco em arquitetura de microsserviços que destacam o portfólio.”

“Se prepare para as oportunidades que estão por vir e tenha sucesso nas entrevistas de recrutamento.”

Pelo texto eu entendi que o público alvo é tanto pessoas que não são desenvolvedores profissionais e querem se tornar, quanto pessoas que já trabalham com desenvolvimento e querem se preparar.

Para quem está tentando entrar na área, o curso deve ser entendido como um complemento de estudos que precisam ser mais amplos. O estudante que começa esse bootcamp achando que vai ser o suficiente para um conhecimento básico para tentar entrevistas de emprego ficará frustrado. Penso que ele vai precisar de outros cursos para estar apto a essa busca.

Para quem já trabalha com programação, meu caso, o curso é bom para conhecer uma nova linguagem e framework. Não acho que um desenvolvedor júnior ou pleno fazendo o curso se sentirá pronto para o próximo nível de carreira, mas com certeza ajuda nessa bagagem.

sobre o curso e minha experiência

Eu não conhecia nada de Java e trabalhei pouco com orientação a objeto até o momento. Então o curso foi ótimo para conhecer a sintaxe da linguagem, framework, pacotes, recursos, etc.

Não me sinto capaz de liderar um sistema de produção em Java com o que eu aprendi, mas, juntando com minhas outras experiências anteriores de outros trabalhos e linguagens, acredito ser capaz de colaborar com um time que trabalha com Java e com o tempo dominar melhor esse conhecimento.

Tenho mais experiência trabalhando com linguagens que não são baseadas em orientação a objetos. O curso me ajudou muito a conhecer mais esse paradigma, que é a base do Java.

O curso mescla alguns vídeos gravados mais recentes com outros mais antigos. Não me parece ter uma grande perda por isso, mas é estranho um bootcamp de Java com Spring Boot ter aulas usando Java 8 sendo que a menor versão do “spring initializr” é 17. Isso gera alguns problemas de compatibilidade ao usar Gradle ou Maven, mas ter que resolvê-los foi de muito aprendizado também.

Os professores são bons e a plataforma de aula também é boa. Sempre cabe espaço para melhorar, mas não senti que me atrapalhou em nada. O bootcamp conta com mentorias que são aulas ou conversas com experts, acontecem ao vivo, mas ficam gravadas também. Não assisti todas, mas ouvir a experiência de gente programando ou liderando times na vida real é sempre legal. Ter esses momentos é sempre positivo para mim.

O curso tem alguns projetos para fazer e colocar no portfólio. Não são projetos complexos e muito elaborados que vão chamar muita atenção se você já atua como desenvolvedor, entretanto, para quem está tentando entrar na área, é sempre importante ter esses projetos para treinar e mostrar.

sobre meu aprendizado

Acredito que o que eu tinha para falar do bootcamp em si eu já falei antes. Então agora é sobre o que eu aprendi.

Para meus objetivos pessoais de aprender uma nova linguagem como hobby e possibilitar oportunidades de trabalho, fiquei satisfeito.

Sobre o quesito hobby, achei uma linguagem chata por ser muito verbosa mesmo com as facilidades do Spring Boot e Stream API. Além disso, o Spring Boot é um framework que usa muito de decoradores e abstrações e isso deixa as coisas meio “mágicas” no código, realmente pode trazer produtividade, mas por vezes eu tinha dificuldade de ler o código e saber exatamente o que estava acontecendo. Pessoalmente, não seria uma linguagem que escolheria para fazer um projeto.

Sobre o quesito profissional, entendo linguagens de programação como uma ferramenta de trabalho, não acho correto me limitar a uma outra linguagem para trabalhar. Então com o conhecimento básico de Java que aprendi no curso acredito que posso me comunicar bem com times que trabalham com Java Spring Boot, talvez tenha uma certa dificuldade inicial de entender completamente o código devido às muita abstrações do framework e com o tempo e prática poderia colaborar melhor com o desenvolvimento de sistemas em Java.

LGPD e falsear dados sensíveis no banco de dados - parte 2

Samuel Rodrigues Almeida e Sousa — Mon, 13 Jun 2022 18:09:15 +0000

Contextualizando

A Lei Geral de Proteção de Dados Pessoais (LGPD) visa regulamentar direitos e deveres no tratamento de dados pessoais. Participando de conversas sobre o tema, o time que trabalho chegou a conclusão que é mais seguro e inteligente que os bancos de dados de desenvolvimento e staging não tivessem dados pessoais reais dos clientes por alguns motivos:

a) como os desenvolvedores trabalham de forma remota o acesso a esses bancos é mais aberto.

b) uma vez que não é necessário aos ambientes de desenvolvimento e staging que existam dados reais, é mais seguro e eficiente não tê-los do que criar estratégias e recursos para protegê-los.

O desafio

Nosso banco de produção possui dois databases importantes que possuem dados sensíveis para serem falseados e disponibilizados em desenvolvimento e staging. O desafio foi gerar um programa que automatize esse processo de gerar um banco com dados falsos a partir do de produção; ainda é necessário que seja possível escolher qual database de origem e qual ambiente de destino.

Um rascunho seria:

Fazer a cópia do banco de produção (parte 1)
Inserir essa cópia em um banco temporário (parte 1)
Falsear os dados sensíveis
Fazer uma nova cópia com os dados falsos (parte 1)
Inserir no bancos de desenvolvimento e/ou staging (parte 1)
Excluir arquivos intermediários gerados

Disclaimer

Por motivos de segurança da informação os databases, tabelas e colunas serão inventados. Além disso, os exemplos usam tabelas menores e mais simples, uma vez que o objetivo é mostrar e explicar o código desenvolvido.

Parte 1

A parte 1 aborda mais a manipulação do banco de dados usando os clientes mysql e mysqldump pode ser lido aqui:

Parte 2

O programa foi feito em Golang e o chamei de fakedb. Essa segunda parte aborda como o fakedb gera dados falsos e atualiza o banco. Além disso, tabelas em banco podem ser cridas, colunas adicionadas ou removidas, então o código precisa permitir essa dinamicidade também.

O código completo pode ser acessado em https://github.com/samuelralmeida/fakedb

Organização do código e interfaces do script

Cada database do banco possui um diretório. No nosso exemplo: coisa e trem.

Dentro desse diretório cada tabela que precisar falsear dados tem um arquivo próprio, além de um arquivo “pai” com o mesmo nome do database que retorna o grupo de scripts por tabela que devem ser executados.

As duas interfaces abaixo definem as regras a serem seguidas.

// arquivo fakedata/interface.go
package fakedata

import "database/sql"

type FakeDataScript interface {
    DB() *sql.DB
    FetchRows() (*sql.Rows, error)
    PrepareStmt(tx *sql.Tx) (*sql.Stmt, error)
    UpdateData(*sql.Rows, *sql.Stmt) error
    TableName() string
}

type IFakeData interface {
    Scripts(db *sql.DB) []FakeDataScript
}

Cada script da tabela atende a interface FakeDataScript e cada database atende a interface IFakeData.

Dessa forma, uma alteração em uma tabela existente só precisa ser corrigida no seu respectivo script. Uma nova tabela que surgir, basta escrever os métodos para ela e devolver no array do database.

A estrutura do script de falsear dados

Como para cada tabela do banco temos os mesmo métodos definidos pela interface, o que o programa faz é os chamar de forma lógica. Vou detalhar o que ocorre no arquivo fake_data.go

A função getDBHandle cria uma conexão com banco a partir das credenciais recebidas.
Para cada tabela do database passado vai: 2.1. Buscar todas as entradas da tabela. (método FetchRows) 2.2. Iniciar uma transaction para garantir que todas as alterações sejam feitas por inteiro ou nada seja feito 2.3. Preparar um statement a partir da transaction com o UPDATE da respectiva tabela. (método PrepareStmt) 2.4. Atualizar os dados falsos. (método UpdateData) 2.5. Fazer o commit da transaction.

É dentro do UpdateData que o principal ocorre:

func (c FakeClientTable) UpdateData(rows *sql.Rows, stmt *sql.Stmt) error {
    for rows.Next() {
        var ID int64
        err := rows.Scan(&ID)
        if err != nil {
            return fmt.Errorf("rows scan error: %w", err)
        }

        name := helper.GenerateName()
        cpf := helper.GenerateCpf()
        address := helper.GenerateAddress()

        _, err = stmt.Exec(name, cpf, address, ID)
        if err != nil {
            return fmt.Errorf("update exec error: %w", err)
        }
    }

    if err := rows.Err(); err != nil {
        return fmt.Errorf("rows error: %w", err)
    }

    return nil
}

O código acima é do exemplo para a tabela de cliente. O método recebe as linhas retornadas do banco e o statement de update; para cada linha um novo nome, CPF e endereço é gerado e a linha é atualizada usando o Exec do statement.

Para gerar os dados falsos usamos o pacote gogakeit. Ele pode ser chamado diretamente como no caso da tabela de lead: email := gofakeit.Email().

Deixei esse caso de exemplo, mas acredito que o melhor é encapsular dentro do nosso pacote helper caso queira ou precise alterar o pacote gofakeit:

// fakedata/helper/generate_data.go
package helper

import (
    "fmt"
    "github.com/brianvoe/gofakeit/v6"
)

func GenerateAddress() string {
    types := []string{"Avenida", "Rua", "Travessa"}
    street := fmt.Sprintf("%s %s %s, %d",
        types[gofakeit.Number(0, 2)],
        gofakeit.StreetPrefix(),
        gofakeit.StreetName(),
        gofakeit.Number(0, 3000),
    )
    return street
}

O caso CPF

O gofakeit não gera CPFs e é importante que eles sejam válidos para que não quebre validações que existam no back ou frontend. Além disso, CPFs costumam ser chave única no banco, portanto, apesar de ser gerado aleatório não pode ser repetidos. Por isso criamos uma função para gerar cpfs falsos cpf.go que controla quais já foram gerados usando um map.

CLI, Dockerfile e Makefile

Usamos o pacote flag nativo do Go para permitir parâmetros na chamada para definir quais databases de origem dos dados, no nosso exemplo permite trem, coisa ou all (default). E também decidir o destino dev, staging ou all (default):

// main.go
// ...
func main() {
    var source string
    var target string

    flag.StringVar(&source, "source", "all", "Specify which database. Options: all, trem, coisa. Default: all")
    flag.StringVar(&target, "target", "all", "Specify which dump destination. Options: all, dev, staging. Default: all")
    flag.Parse()

    sources := map[string]bool{"all": true, "trem": true, "coisa": true}
    targets := map[string]bool{"all": true, "dev": true, "staging": true}

    if _, ok := sources[source]; !ok {
        log.Fatalf("%s is a invalid source. Options: all, farme, indicame.", source)
    }

    if _, ok := targets[target]; !ok {
        log.Fatalf("%s is a invalid target. Options: all, dev, staging.", target)
    }

//...
}

Optamos por usar um container Docker para rodar o script para padronizar o ambiente que é executado e facilita subir a imagem e rodar o container em uma máquina da AWS.

Usamos uma imagem de Go intermediária para compilar o programa e uma imagem definitiva do Mysql que já sobe um banco local automaticamente ao iniciar o container. E copiamos o executável do nosso programa para essa imagem.

// Dockerfile
FROM golang:1.18 AS build

COPY . /app
WORKDIR /app

RUN go build -o fakedb main.go

FROM mysql:8.0.23

RUN mkdir app
COPY --from=build /app/fakedb /app
WORKDIR /app

E para facilitar executar e automatizar o programa preparamos um Makefile que facilita a fazer build da imagem, iniciar o container, acessar e executar o container, etc.

build:
    docker build -t dumpfakedb .

run:
    docker run -d --name dumpfakedb --env-file .env dumpfakedb

bash:
    docker exec -it dumpfakedb bash

remove:
    docker container rm dumpfakedb -f

fakedb-all:
    docker exec -it dumpfakedb ./fakedb

fakedb-all-dev:
    docker exec -it dumpfakedb ./fakedb --target=dev

fakedb-trem-staging:
    docker exec -it dumpfakedb ./fakedb --source=trem --target=staging

Fim

Essa foi a segunda parte que abordou mais o falseamento dos dados e execução do programa. O artigo ficou um pouco grande e denso devido aos detalhes do assunto e do código, mas espero que tenha ajudado você. Até breve.

LGPD e falsear dados sensíveis no banco de dados de dev e staging - parte 1

Samuel Rodrigues Almeida e Sousa — Mon, 30 May 2022 16:09:04 +0000

Contextualizando

a) como os desenvolvedores trabalham de forma remota o acesso a esses bancos é mais aberto.

b) uma vez que não é necessário aos ambientes de desenvolvimento e staging que existam dados reais, é mais seguro e eficiente não tê-los do que criar estratégias e recursos para protegê-los.

O desafio

Um rascunho seria:

Fazer a cópia do banco de produção
Inserir essa cópia em um banco temporário
Falsear os dados sensíveis (parte 2)
Fazer uma nova cópia com os dados falsos
Inserir no bancos de desenvolvimento e/ou staging
Excluir arquivos intermediários gerados (parte 2)

Disclaimer

Por motivos de segurança da informação os databases, tabelas e colunas serão inventados. Além disso, os exemplos usam tabelas menores e mais simples, uma vez que o objetivo é mostrar e explicar o código desenvolvido.

Parte 1

O programa foi feito em Golang e o chamei de fakedb. Essa primeira parte aborda como o fakedb usa os recursos dos clientes CLI mysql) e mysqldump) para resolver os itens 1, 2, 4 e 5 do rascunho apresentado anteriormente.

O código completo pode ser acessado em https://github.com/samuelralmeida/fakedb

A estrutura do banco de produção

O código SQL para gerar o banco de produção com dados para nosso código se encontra no arquivo populate.sql

Go exec, mysql e mysqldump

mysql e mysqldump são clientes CLI para manipular bancos de forma direta, por exemplo, o código abaixo cria o database temp diretamente pelo terminal:

mysql -user=root --password=minha_senha -e "CREATE DATABASE temp"

Golang oferece um pacote nativo os/exec que permite executar pelo código comandos de terminal. O exemplo abaixo faz o mesmo que o código anterior:

// ...
import "os/exec"

func dropDatabase(dbName) error {
    cmd := exec.Command("mysql", "--user=root", "--password=minha_senha", "-e", "CREATE DATABASE temp")
    err := cmd.Run()
    return err
}

O arquivo mysqldb contem as funções que usamos para deletar o database se existir (DropDatabase), criar um database (CreateDatabase), exportar dados (DumpDatabase), importar dados (RestoreData).

Função de exportar dados recebe o nome do arquivo sql que vai ser gerado. No terminal seria similar a:

mysqldump -u root -p client > prod_trem.sql

Já a função para importar os dados recebe o nome do arquivo que possui os dados para serem inseridos, no terminal teriamos algo como:

mysql -u root -p temp < prod_trem.sql

Essa particularidade do arquivo ser um input para o cliente mysql faz com que precisamos abrir o arquivo em buffer e controlar o stdin no Go para usá-lo junto com o mysql:

func RestoreData(filename string, args credentials.ConnectionParams) error {
    bytes, err := ioutil.ReadFile(fmt.Sprintf("./%s", filename))
    if err != nil {
        return fmt.Errorf("restoreData: error to read file: %w", err)
    }

    dropArgs := []string{
        fmt.Sprintf("--host=%s", args.Host),
        fmt.Sprintf("--port=%s", args.Port),
        fmt.Sprintf("--user=%s", args.User),
        fmt.Sprintf("--password=%s", args.Password),
        args.Database,
    }

    cmd := exec.Command("mysql", dropArgs...)

    stdin, err := cmd.StdinPipe()
    if err != nil {
        return fmt.Errorf("restoreData: error to get stdin pipe: %w", err)
    }

    go func() {
        defer stdin.Close()
        stdin.Write(bytes)
    }()

    _, err = cmd.CombinedOutput()
    if err != nil {
        return fmt.Errorf("restoreData: error to run command: %w", err)
    }

    return nil
}

Goroutines para restaurar dados

As etapas mais demoradas são: a) fazer o dump do banco, que por ser de um único banco não tem como fazer em paralelo; e b) restaurar os dados em um novo database, o que podemos melhorar a performance paralelizando essa etapa uma vez que a restauração ocorre para bancos de dev e staging.

O código abaixo mostra como abrimos uma goroutine para cada banco alvo, controlamos os possíveis erros de forma independente e aguardamos que finalizem usando sync.WaitGroup.

// goroutine para alvos
func restoreTargets(filename string, targets []credentials.ConnectionParams) error {
    var (
        wg   sync.WaitGroup
        errs = []string{}
    )

    for _, target := range targets {
        t := target

        wg.Add(1)
        go func(credential credentials.ConnectionParams) {
            defer wg.Done()

            var err error

            log.Printf("drop database if exixts - %s", credential.Database)
            err = mysqldb.DropDatabase(credential)
            if err != nil {
                err = fmt.Errorf("target - %s: %w", credential.Database, err)
                errs = append(errs, err.Error())
                return
            }

            log.Printf("create database - %s", credential.Database)
            err = mysqldb.CreateDatabase(credential)
            if err != nil {
                err = fmt.Errorf("target - %s: %w", credential.Database, err)
                errs = append(errs, err.Error())
                return
            }

            log.Printf("restore database - %s", credential.Database)
            err = mysqldb.RestoreData(filename, credential)
            if err != nil {
                err = fmt.Errorf("target - %s: %w", credential.Database, err)
                errs = append(errs, err.Error())
                return
            }

            log.Printf("DONE: restore database - %s", credential.Database)

        }(t)
    }

    wg.Wait()

    if len(errs) > 0 {
        return errors.New(strings.Join(errs, "&&"))
    }
    return nil
}

Empregamos esse mesmo raciocínio para executar o script em paralelo para bancos diferentes, uma goroutine para o banco trem e outra para o banco coisa, como pode ser visto no arquivo main.go. Nos nossos testes, o uso de goroutines nos fez economizar 30% do tempo gasto sem elas.

Acessando bancos por variáveis de ambiente

Para não deixar como hardcode dados de acesso aos bancos, usamos variáveis de ambiente que são carregadas dentro do container docker que roda todo o script. As variáveis ficam em um arquivo .env, e no arquivo example.env tem um esqueleto dessas variáveis.

A imagem docker criada para executar o script se baseia em uma imagem do Docker do Mysql, que já vem com os clientes mysql e mysldump instalados. Além disso, usando a variável de ambiente MYSQL_ROOT_PASSWORD, já inicia um banco local dentro do container o usado como banco intermediário para receber os dados de produção, falsear e exportar. Por isso a mesma senha dele é usada na variável de ambiente INTERMEDIATE_PASS.

A vantagem de usar esse banco local do container como intermediário, é que finalizando o script e removendo o container, todos os dados intermediários que o script gerou são apagados também.

Continua…

Essa primeira parte abordou mais a manipulação dos bancos, a segunda parte vai ser a respeito da lógica para gerar dados falsos para o banco. O artigo ficou um pouco grande e denso devido aos detalhes do assunto e do código, mas espero que tenha ajudado você. Até breve.