DEV Community: Laura Fumagalli

Programação funcional - primeiras impressões com Clojure

Laura Fumagalli — Thu, 25 Sep 2025 01:23:09 +0000

O intuito deste artigo é ser a primeira parte de um material introdutório à Programação Funcional. Usarei Clojure, uma linguagem que usa esse paradigma muito diferente da tradicional Orientação a Objetos amplamente utilizada no mercado de trabalho e ensinada em faculdades tradicionais. Se você tem a mente aberta para uma nova linguagem de programação e acredita que uma sintaxe e paradigma novos te levarão a novos horizontes, este artigo é para você! Vou também fazer algumas comparações com linguagens historicamente consideradas orientadas a objeto (como Java, por exemplo).

Logo de início, já vou trazer que a Programação Funcional tem muito a agregar. Com ela, é possível escrever códigos mais robustos, menos suscetíveis a erros e expandir sua forma de pensar. Por exemplo, a imutabilidade, um conceito comum nesse paradigma, minimiza a possibilidade de encontrarmos defeitos oriundos da manipulação de estado em lugares desconhecidos. Uma grande vantagem de aprender Programação Funcional é utilizar os benefícios do paralelismo, que trarei aqui mais adiante. Escrever código paralalizável em uma linguagem de paradigma funcional é muito mais fácil. A ausência de efeitos colaterais nas funções de um programa permite que essas funções sejam executadas sem uma ordem definida e em paralelo. A programação funcional nos ajuda a pensar sempre em construir funções sem efeitos colaterais.

Por que Clojure?

Essa linguagem possui recursos interessantes para nos ajudar a manter o foco nos aspectos inerentes à linguagem e à Programação ƒuncional: a sintaxe, que é simples e muito diferente das linguagens mais populares, e um sistema dinâmico de tipos, o que vai nos permitir evitar pensar em Orientação a Objetos por um tempo. Clojure é um dialeto Lisp. Enquanto todas as outras linguagens, como Java, Golang, C# etc, derivam do Algol (como C), linguagens de Paradigma Funcional, como Clojure, Scala ou Elixir por exemplo, são da família do Lisp. Lisp é uma linguagem que trouxe a ideia de que é possível utilizar apenas funções matemáticas para reprezentar estruturas de dados básicas, aliado ao conceito de código como dado. Depois do "choque inicial", é possível perceber que a sintaxe é extremamente simples, com poucos símbolos ou palavras-chaves reservadas.

Clojure roda na máquina virtual Java, o que permite que programas escritos nesta linguagem usem bibliotecas escritas em Java! Dito isto, você precisa instalar o kit de desenvolvimento do Java, JDK, antes de instalar o Clojure em si. Basta seguir o passo a passo da própria documentação no site oficial deles.

Primeiro código em Clojure (e o REPL)

Algo que pode parecer estranho no começo é o fato de não depurar o código da forma tradicional em Clojure. REPL é um ambiente imterativo onde escrevemos códigos e eles são interpretados de imediato, gerando resultados muito rápidos. É ideal para trechos pequenos e validação de ideias.

REPL é um acrônimo para read, evaluate, print e loop. Isto quer dizer que ele vai ler nossos comandos, interpretá-los, exibir na tela o resultado e repetir o processo.

Programar no REPL é algo bem comum entre quem tem familiaridade com Clojure. Claro, em algum momento, nossos códigos vão parar em arquivos e serão empacotados. Mas o REPL fornece um ambiente muito prático para experimentação e testes. Algumas pessoas substituem desenvolvimento guiado por testes pelo constante uso do REPL, mas eu não recomendo. É sempre melhor criar casos de testes para garantir a consistência e qualidade do código, independente da linguagem. Se hoje você sente dificuldade com TDD, ou Desenvolvimento Orientado por Testes (Test-Driven Development), aprender a desenvolver em Clojure é uma excelente oportunidade de treinar essa prática.

Para entender esse tal de REPL na prática, vamos usar o Boot "clj". Basta abrir o terminar e digitar clj ou clojure que vai abrir um terminal interativo esperando você fornecer alguma informação, o terminal diz: user=>. Isso significa que já podemos escrever código! É possível sair desse contexto apertando "ctrl + d".

Primeiros contatos com Clojure

Aqui vou fazer uma abordagem um pouco diferente sobre essa linguagem. O código em Clojure me lembrou muito RPN (Reverse Polish Notation / Notação Polonesa Reversa). RPN basicamente é um método para escrever expressões matemáticas onde os operadores (+, -, *) são colocados depois dos números (operandos), eliminando a necessidade de parênteses. Exemplo de uso: "O motor de cálculo converte a fórmula (10 + 5) * 2 para a expressão RPN 10 5 + 2 * para poder processá-la". É normalmente usado em sistemas de back-end, como calculadoras e motores de regras (rule engines), para avaliar de forma rápida e sem ambiguidade fórmulas complexas de juros, tarifas ou limites de crédito.

Entrando no REPL e digitando (+ 1 2) o resultado, como esperado, é 3. Mas a sintaxe parece bem diferente das linguagens com as quais estamos acostumadas. Vamos à explicação:

Acontece que a linha dentro do () é uma lista composta de +, 1 e 2. O primeiro elemento dessa lista é sempre uma função que é executada e os demais elementos desta lista são argumentos para esta função. O mesmo se aplica para as outras operações aritméticas:

(* 2 3)
(/ 2 2)
(- 0 2)

Se for uma operação um pouco mais complexa, fica da seguinte forma:

(* 2 (+ 3 3))
;; isto é um comentário em Clojure e vamos
;; utilizá-lo para demonstrar o retorno das funções
;; 12

Este exemplo é onde Clojure mostra mais um diferencial no sentido de sintaxe, fruto de sua herança de Lisp. Pensando na matemática, é claro que a soma será executada primeiro. O diferencial, porém, é que a linguagem exige os parênteses, o que não deixa margem alguma para dúvidas do que precede o quê. A ordem de execução de código é sempre de dentro para fora.

E para concatenar Strings? Assim: (str "Hello, " "world!")
Podemos também verificar se duas Strings são iguais:

(= "Hello" "Hi")`
;; false
(= "Hi" "Hi")
;; true

Importante observar que, diferente de muitas linguagens, o = é uma função em Clojure que verifica se duas coisas são iguais. O = não é um operador de associação, normalmente utilizado na construção de variáveis.

E como verificamos se um número é par?

(even? 2)
;; true

E se um número é múltiplo de 3?

(= 0 (mod 9 3))
;; true

Neste último exemplo, o que acontece é que verificamos o módulo da divisão entre 9 e 3. O resultado será utilizado como o segundo argumento na função que verifica igualdade, =.

Nossas próprias funções

Começando do básico, vamos criar uma função que recebe um nome e da um "oi". Para criar funções, fazemos o seguinte:

(defn oi [nome]
  (str "Oi, " nome "!"))

Namespaces

Ao criar a função é possível ler a saída: #'user/oi
Isto quer dizer que alguma coisa com o nome oi acabou de ser criada, e encontra-se no namespace padrão, user. Namespaces em Clojure representam a mesma ideia que em outras linguagens, como pacotes em Java, sendo uma forma de agrupar funções. A combinação do namespace e do nome da função forma o identificador de tal função

A função +, por exemplo, é encontrada no namespace clojure.core, sendo o identificador clojure.core/+.
Como o namespace clojure.core é disponibilizado por padrão, a função + está sempre disponível.
Funções em outros namespaces precisam ser incluídas no nosso cófigo antes de serem utilizadas.

Com a função criada, vamos invocar com o nome desejado:

(oi "zé")
;; "Oi, zé!"

O defn nos indica que vamos criar uma função.
Depois, damos um nome a ela (neste caso, oi).
Logo a seguir, vem a lista de argumentos, cercada por [ e ]. Neste caso, temos apenas um argumento, então fica [nome].
Em seguida vem o que realmente é executado: a concatenação de Strings. Note que não precisamos definir o que será retornado. A última instrução é o que será retornado.

O Trecho que concatena Strings tem uma particularidade: é aplicado 3 argumentos. Esta é uma de várias funções que são aplicáveis em uma quantidade indeterminada de argumentos.

E como seria uma função que verifica se um número é múltiplo de 3?

(defn multiplo-de-3? [dividendo]
  (= 0 (mod dividendo 3)))

Então podemos chamar a função assim:

(multiplo-de-3? 9)
;; true

(multiplo-de-3? 20)
;; false

Sobre os condicionais

Para simplificar o exemplo, vamos exibir a palavra sim se um número for par, e, caso contrário, a palavra não. O código fica assim:

(defn par? [numero]
  (if (even? numero)
    "sim"
    "não"))

Dessa forma, temos a saída:

(par? 5)
;; "não"
(par? 4)
;; "sim"

if tem muito cara de uma função também, mas ela é na verdade o que é chamado de forma especial: um recurso base do Clojure.

O if recebe 3 argumentos: O primeiro é uma verificação que retorna verdadeiro ou falso. Os demais argumentos representam algo a ser executado de acordo com o resultado da verificação. Em caso de verdadeiro, o segundo argumento é avaliado e retornado. Caso contrário, o argumento 3 é que é avaliado e retornado.

É importante salientar que apenas nil e false são considerados realmente falsos para verificação de condições. Outros, como 0 e String vazia, que são comuns em outras linguagens, serão avaliados como verdadeiros!

Consultando a documentação

Sempre que você quiser saber mais sobre algum recurso do Clojure, você pode experimentar a documentação dentro do REPL!
Para isso, use a função doc:
(doc if)

Agora, quando houver outra condição além de duas, a macro cond pode ajudar. Ela recebe pares de condicionais e expressões. Segue um exemplo:

(defn saldo [valor]
  (cond (< valor 0) "negativo"
    (> valor 0) "positivo"
    :else "zero"))

Quando testamos:

(saldo 900)
;; "positivo"

(saldo -900)
;; "negativo"

(saldo 0)
;; "zero"

Neste exemplo, quando o valor é menor que zero, o primeiro teste, logo de cara, retorna verdadeiro, e a expressão que o segue, "negativo" , é avaliada (neste caso, não faz nada, apenas retorna a String "negativo"). Quando o valor é maior que zero, o primeiro teste ((< valor 0)) falha, retornando falso, mas o teste seguinte retorna verdadeiro, e a expressão correspondente é avaliada. Agora, quando o valor é exatamente 0, as duas primeiras verificações retornam falso, e a última verificação (:else) é validada e "zero" é retornado.

O que significa este :else? Nada demais, na real. Como qualquer coisa diferente de nil e false é considerada verdadeira, qualquer coisa que colocássemos ali no lugar do :else funcionaria como uma forma de fazer com que "zero" fosse retornado por padrão. Se quiser, teste lá com valores como 1 ou "milhão". Bem, não é realmente qualquer coisa: números (mesmo que 0), Strings (mesmo que vazias), caracteres, coleções... O :else é apenas uma convenção adotada por algumas pessoas as quais eu andei copiando.

Conclusão

Ufa! Acho que agora temos a capacidade de aumentar um pouco mais a complexidade dos problemas que podemos tratar. Aqui aprendemos como interagir com o REPL do Clojure, chamar funções, criar nossas próprias funções e trabalhar com condicionais. No próximo artigo, resolveremos um problema bastante comum no mundo da programação: o Fizz-Buzz. Você verá como a solução para este problema fica bem sucinta em Clojure.

Do zero ao backend: seu plano (com IA e PDI)

Laura Fumagalli — Mon, 08 Sep 2025 20:44:19 +0000

Se você quer ser um desenvolvedor backend junior, mas não sabe por onde começar, ou se já começou e está se sentindo perdido no meio do caminho, esse artigo é pra você. Vamos falar de tudo que você precisa aprender, sem enrolação, sem jargões complicados, e com exemplos práticos do que fazer, como fazer e como medir seu progresso. E sim, vamos falar de como usar a Inteligência Artificial a seu favor, porque ela é sua aliada, não sua concorrente.

Antes de tudo, vamos entender o que é um PDI. PDI significa Plano de Desenvolvimento Individual. É um plano que você mesmo monta para guiar seu crescimento profissional. Ele não é um documento rígido, nem algo que só gestores fazem. É uma ferramenta sua, para você se organizar, saber onde está, onde quer chegar e o que precisa fazer para chegar lá. Vou te ensinar a montar o seu ao longo do texto.

1. Escolha uma linguagem de programação e comece a codar

Você não precisa ser expert em Java, Go, Kotlin, C#, Python, Swift ou qualquer outra. O que você precisa é escolher uma, aprender o básico e começar a construir coisas simples com ela.

O que um junior precisa fazer:

Implementar funcionalidades pequenas seguindo guias técnicos, usando ferramentas e frameworks padrão da linguagem. Resolver problemas técnicos simples, seja com ajuda da IA, seja conversando com alguém mais experiente, se tiver acesso.

Exemplo prático novo:

Você recebe o desafio de criar um endpoint que salva o nome e a idade de um pet num sistema de petshop. Segue um passo a passo que alguém do time preparou, ou então usa a IA para gerar um exemplo inicial. Escreve o código, testa localmente, e quando não funciona direito, refina sua pergunta para a IA ou mostra exatamente onde travou para alguém que entende mais. Por exemplo: “o nome do pet salva, mas a idade some, o que pode ser?”

Como medir seu progresso:

Peça para alguém revisar seu código, ou use ferramentas de análise estática, tipo o Sonarqube. Veja se ele está seguindo as especificações, se está legível, se está dentro das boas práticas. Observe quantas vezes você precisou de ajuda externa. Se for muitas vezes, tudo bem, é normal no começo. O importante é reduzir isso com o tempo.

Atitude que faz diferença:

Não fique com vergonha de perguntar, nem de pedir ajuda à IA. Mas antes de perguntar, tente. Pesquise, leia a documentação, tente resolver sozinho por 15 minutos. Depois, vá com a pergunta pronta, mostrando o que você já tentou, seja com IA ou com outra pessoa.

2. Aprenda algoritmos e estruturas de dados básicos

Não precisa virar um cientista da computação agora. Mas precisa entender o básico para resolver problemas do dia a dia.

O que um junior precisa fazer:

Implementar algoritmos simples como ordenação por seleção, busca linear, cálculo de fatorial. Usar estruturas como arrays, listas encadeadas e pilhas.

Exemplo prático novo:

Você está montando um sistema de fila para um food truck. Usa uma lista encadeada para adicionar pedidos no final e remover do começo. Ou então, precisa calcular quantos combos foram vendidos no dia. E faz isso com um loop simples somando valores de um array. Se travar, pergunta à IA: “como somar todos os valores de um array em Python?” e depois adapta ao seu caso.

Como medir seu progresso:

Faça exercícios em plataformas como HackerRank, LeetCode (na seção easy), Codewars ou até em projetos pessoais. Verifique se seu código funciona, se é eficiente o suficiente para o problema, e se está legível. Compare sua solução com a da IA ou com a de colegas, para ver outras formas de resolver.

Atitude que faz diferença:

Não pule essa parte achando que “não vai usar no trabalho”. Você vai. Mesmo que seja só para entender o que os outros estão falando. E se não tiver com quem discutir, use a IA para simular um debate: “me mostre 3 formas diferentes de resolver isso”.

3. Aprenda Git e comece a colaborar em projetos

Git não é opcional. É obrigatório. E não é só dar commit. É entender fluxo, branches, resolver conflitos, participar de code reviews.

O que um junior precisa fazer:

Clonar repositórios, criar branches, fazer commits com mensagens boas, resolver conflitos simples com ajuda da IA ou de outra pessoa.

Exemplo prático novo:

Você precisa ajustar a regra de cálculo de frete no backend. Cria uma branch chamada “feature/frete-gratis-acima-100”, faz commits com mensagens como “adiciona condição para frete grátis acima de R$100”, e quando alguém pede ajuste, você sabe voltar lá e editar sem quebrar tudo. Se encontrar um conflito, cola o erro na IA e pergunta: “como resolver esse conflito de merge no Git?”.

Como medir seu progresso:

Veja quantos commits você faz por semana, se as mensagens são claras, se você consegue resolver conflitos sem ajuda ou com menos ajuda ao longo do tempo. Use a IA para revisar suas mensagens de commit: “essa mensagem é clara o suficiente?”.

Atitude que faz diferença:

Escreva mensagens de commit que fazem sentido. Não escreva “arrumei bug”. Escreva “corrige cálculo de frete quando valor é exatamente R$100”. Isso mostra profissionalismo. E se não tiver certeza, pergunte à IA ou a um colega.

4. Entenda o básico de CI/CD

CI/CD é integração e entrega contínua. Parece complicado, mas no nível junior, você só precisa saber executar e monitorar.

O que um junior precisa fazer:

Executar pipelines de deploy em ambientes de desenvolvimento ou staging. Monitorar logs para ver se deu certo ou se quebrou.

Exemplo prático novo:

Você termina sua tarefa de adicionar um novo campo “observações” no cadastro de cliente. Executa o pipeline de deploy no ambiente de testes, abre o sistema lá, vê que o campo aparece, mas está cortado. Volta nos logs, descobre que faltou um ajuste no CSS do frontend e avisa o time antes de virar problema em produção. Se os logs estiverem confusos, copia um trecho e pergunta à IA: “o que esse erro no log significa?”.

Como medir seu progresso:

Veja se você consegue executar o pipeline sozinho. Se consegue identificar um erro pelo log. Se consegue avisar o time quando algo quebrou. Use a IA para decifrar mensagens de erro que parecem em outra língua.

Atitude que faz diferença:

Não ignore os logs. Mesmo que pareça chato, leia. É ali que você vai aprender a entender o que acontece depois que seu código sai da sua máquina. E se não entender, transforme o log numa pergunta para a IA.

5. Construa APIs simples

APIs são o coração do backend. Você precisa saber criar, testar e documentar.

O que um junior precisa fazer:

Criar APIs REST simples, com autenticação básica (como JWT), e paginação quando necessário.

Exemplo prático novo:

Você cria um endpoint POST /enviar-cupom que recebe um código e devolve “válido” ou “expirado”. Usa JWT pra garantir que só clientes logados possam enviar, e adiciona paginação porque a loja tem 10 mil cupons e não pode carregar tudo de uma vez. Tudo seguindo um rascunho que o tech lead deixou no Notion, ou então gerado pela IA com base na sua descrição do problema.

Como medir seu progresso:

Peça para alguém testar sua API, ou use a IA para gerar casos de teste. Veja se ela responde como esperado, se a autenticação funciona, se a paginação está certa. Use ferramentas como Postman ou Insomnia para testar você mesmo.

Atitude que faz diferença:

Teste sua API antes de entregar. Não espere os outros encontrarem os erros. Seja o primeiro a quebrar seu próprio código. E se não souber como testar, pergunte à IA: “quais testes devo fazer nesse endpoint?”.

6. Aprenda o básico de segurança

Segurança não é só coisa de especialista. No nível junior, você precisa saber o mínimo para não entregar um sistema cheio de brechas.

O que um junior precisa fazer:

Implementar autenticação e autorização básicas, como JWT e HTTPS, com ajuda da IA ou de alguém mais experiente.

Exemplo prático novo:

Você configura o sistema pra forçar HTTPS em todas as requisições, porque viu que o login estava sendo enviado sem criptografia. Usa um middleware simples com JWT, copia a estrutura de um projeto antigo ou gerado pela IA, mas testa linha por linha pra entender o que cada parte faz e pergunta: “por que a chave secreta não pode ser hardcoded?” seja para a IA ou para um colega.

Como medir seu progresso:

Revise seu próprio código. Veja se o token está sendo validado corretamente, se o HTTPS está forçado. Peça feedback de alguém que entende mais, ou use a IA para fazer uma “revisão de segurança básica”.

Atitude que faz diferença:

Não subestime a segurança. Um sistema funcional que vaza dados é pior do que um sistema quebrado. E se não tiver especialista por perto, use a IA como primeiro filtro: “isso aqui tem risco de segurança?”.

7. Conheça padrões de arquitetura básicos

Você não precisa ser arquiteto, mas precisa saber o que é MVC, Repository, Singleton, e quando usá-los.

O que um junior precisa fazer:

Aplicar esses padrões em projetos pequenos, com apoio da IA ou de alguém mais experiente.

Exemplo prático novo:

Você está fazendo um sistema de agendamento de banho para pets. Separa o código em Controller (recebe a data e o pet), Service (verifica se o horário está disponível) e Repository (salva no banco). Usa Singleton pra garantir que só exista uma conexão com o calendário de horários, evitando conflitos. Se não tiver certeza da implementação, pergunta à IA: “como aplicar Singleton em Java para gerenciar conexão com banco?”.

Como medir seu progresso:

Peça revisão de código, ou use a IA para avaliar se você aplicou o padrão corretamente. Pergunte “por que usamos isso aqui?” para entender o contexto, seja para a IA ou para um colega.

Atitude que faz diferença:

Não aplique padrão só porque viu em algum lugar. Entenda o problema que ele resolve. Se não fizer sentido, não force. E use a IA para te ajudar a entender o “porquê”, não só o “como”.

8. Entenda o básico de Infra como Código (IaC)

Você não precisa escrever scripts de Terraform ainda, mas precisa entender os conceitos.

O que um junior precisa fazer:

Entender o que é IaC, o que é estado, o que é infra declarativa vs imperativa, e os componentes básicos de templates.

Exemplo prático novo:

Você participa de uma reunião onde alguém fala “o state do Terraform tá bagunçado”. Você não entende na hora, mas depois pesquisa e aprende que o state é como um “retrato” da infra atual. Explica pro estagiário: “é tipo um save point do jogo, se apagar, você perde o progresso”. Se ficar confuso, pergunta à IA: “me explique o state do Terraform como se eu tivesse 10 anos”.

Como medir seu progresso:

Responda perguntas técnicas. Participe de discussões. Faça quizzes online. Mostre que você entende os conceitos, mesmo que não saiba codar ainda. Use a IA para simular uma entrevista técnica sobre o tema.

Atitude que faz diferença:

Pergunte sempre “por que usamos isso?”. Entender o motivo é mais importante do que decorar o que faz. E se ninguém puder responder, a IA pode te dar uma base sólida para continuar.

9. Conheça os serviços de computação em nuvem

EC2, Lambda, ECS, EKS, Fargate... você não precisa saber usar todos, mas precisa saber para que servem. Conceitos básicos também são importantes e úteis, como saber o que é VPC, Zonas de Disponibilidade, latência, idempotência etc.

O que um junior precisa fazer:

Explicar a diferença entre eles, e em que cenário cada um é útil.

Exemplo prático novo:

Você precisa escolher onde rodar um script que envia lembretes de vacina por SMS. Pergunta: “Lambda é melhor aqui porque roda só de vez em quando, né?”. E compara com EC2: “EC2 seria como alugar um celular 24h pra mandar 3 SMS por dia. Desnecessário”. Se tiver dúvidas, pergunta à IA: “me dê um exemplo real de quando usar Lambda vs EC2”.

Como medir seu progresso:

Participe de discussões técnicas. Responda perguntas. Faça simulações mentais: “se eu tivesse que escalar uma API que recebe 100 requisições por minuto, qual serviço eu usaria?”. Use a IA para validar seu raciocínio.

Atitude que faz diferença:

Não fique só na teoria. Crie uma conta na AWS, Azure ou GCP, e experimente. Mesmo que seja só para clicar e ver como as coisas funcionam. E se não entender algo, transforme em pergunta para a IA. Não tenha medo de custos inesperados, sempre leia a documentação do serviço, principalmente a parte FinOps, antes de utilizar para ter certeza que não terá gastos inesperados. Reserve de um a cindo dólares para caso aconteça e SEMPRE monitore sua conta, diariamente, até ter segurança de que não esqueceu nada lá rodando e gastando. Sempre desligue os serviços após usá-los, se esquecer de derrubar um serviço por dias, isso pode gerar gastos. Mas não tenha receio, lembre-se: você deve ser a primeira pessoa a investir em você!

10. Saiba usar logs e monitoramento

Seu código vai quebrar. E você precisa saber onde e por que.

O que um junior precisa fazer:

Implementar logs nas suas aplicações, e saber onde procurar quando algo der errado.

Exemplo prático novo:

Você adiciona um log.info("Pedido #123 finalizado com sucesso") e um log.error("Falha ao processar pagamento do pedido #123") no código. Quando o sistema trava, você vai direto nos logs do Kibana, filtra por “erro”, descobre que o problema era um cartão expirado e já sugere uma mensagem amigável pro usuário. Se o log for confuso, copia e cola na IA: “o que esse erro significa?”.

Como medir seu progresso:

Veja se você consegue encontrar o erro sozinho olhando os logs. Se consegue explicar o que aconteceu. Se consegue sugerir uma solução. Use a IA para te ajudar a interpretar padrões ou mensagens estranhas.

Atitude que faz diferença:

Não ignore os logs. Eles são seus melhores amigos quando tudo der errado. E se você não entende o que estão dizendo, a IA pode ser sua tradutora.

11. Aprenda SQL e NoSQL

Banco de dados é essencial. Relacional ou não, você precisa saber mexer.

O que um junior precisa fazer:

Escrever consultas básicas, entender tabelas, chaves, coleções, documentos.

Exemplo prático novo:

Você precisa listar todos os clientes que compraram ração premium nos últimos 30 dias. Escreve:

SELECT nome, email FROM clientes WHERE ultima_compra > '2025-03-01' AND categoria_produto = 'premium';

No MongoDB, faz:

db.clientes.find({ ultimaCompra: { $gt: ISODate("2025-03-01") }, categoria: "premium" })

E cria uma view chamada “clientesPremiumAtivos” pra equipe de marketing usar sem precisar escrever SQL. Se não lembrar a sintaxe, pergunta à IA: “como escrever isso em SQL?”.

Como medir seu progresso:

Teste suas consultas. Veja se elas retornam o que deveriam. Peça revisão. Use ferramentas de migration como Flyway ou Liquibase para versionar suas alterações no banco. Ou use a IA para revisar sua query: “isso aqui está certo? Eu quero listar todos os clientes que compraram ração premiun nos último 30 dias”.

Atitude que faz diferença:

Não trate o banco como um detalhe. Ele é parte fundamental da sua aplicação. Aprenda a pensar em performance e consistência desde o começo. E se não tiver com quem discutir, discuta com a IA.

12. Entenda o básico de cache

Cache é para deixar seu sistema mais rápido. E você precisa saber quando e como usar.

O que um junior precisa fazer:

Entender o que é TTL, cache local vs distribuído, e quando vale a pena usar.

Exemplo prático novo:

Você percebe que toda vez que alguém abre a página inicial, o sistema consulta o banco pra pegar os 5 produtos mais vendidos. Como isso não muda a cada minuto, você sugere: “vamos guardar isso no Redis por 1 hora?”. E explica: “cache local é tipo anotar no seu caderno, cache distribuído é tipo anotar no mural da empresa: todo mundo vê”. Se não tiver certeza, pergunta à IA: “quando usar cache local vs Redis?”.

Como medir seu progresso:

Veja se você consegue identificar cenários de uso. Se consegue explicar os conceitos. Se consegue configurar um cache simples com ajuda. Use a IA para te ajudar a montar um exemplo prático.

Atitude que faz diferença:

Não saia colocando cache em tudo. Cache mal usado pode piorar seu sistema. Pense antes de agir. E use a IA para simular cenários: “se eu colocar cache aqui, o que pode dar errado?”.

13. Use IA a seu favor (e aprenda a fazer bons prompts)

IA não vai te substituir. Mas vai te ajudar muito, se você souber usar.

O que um junior precisa fazer:

Saber estruturar prompts claros para obter respostas úteis de modelos de linguagem.

Exemplo prático novo:

Você pergunta pra IA: “me dê um exemplo de código em Python que valida CPF”. Ela te dá algo genérico. Você refina: “quero em Flask, como decorator, retornando 400 se for inválido”. Aí ela entrega certinho. Você testa, entende, e ainda pergunta: “como eu testo isso com Pytest?”. Usa a IA pra aprender, não pra colar.

Como medir seu progresso:

Veja se suas perguntas estão gerando respostas úteis. Se você consegue iterar e melhorar o prompt quando a resposta não serve. Se você usa a IA para aprender, não só para copiar. Peça para a IA avaliar seu próprio prompt: “como eu poderia melhorar essa pergunta?”.

Atitude que faz diferença:

Nunca copie e cole sem entender. Use a IA como tutor, não como dependência. Sempre pergunte “por que isso funciona?”. E se a resposta não fizer sentido, reformule a pergunta. A IA melhora conforme você melhora suas perguntas.

Como montar seu PDI (Plano de Desenvolvimento Individual)

Agora que você sabe o que precisa aprender, vamos montar seu PDI. Ele tem 4 partes:

Onde você está hoje?

Faça uma autoavaliação honesta. Em cada tópico acima, se pergunte: “eu sei fazer isso sozinho?”, “eu preciso de ajuda da IA ou de alguém?”, “eu nem sei por onde começar?”. Anote.
Onde você quer chegar?

Defina um objetivo claro. Exemplo: “em 3 meses, quero conseguir implementar uma API com autenticação e deploy sozinho, usando IA como apoio quando necessário”.
O que você vai fazer para chegar lá?

Liste ações concretas. Ex: “fazer 2 exercícios de algoritmos por semana com revisão da IA”, “ler a documentação do Express.js e comparar com exemplos da IA”, “assistir 1 vídeo por semana sobre Git e depois simular os comandos com ajuda da IA”, “usar IA para revisar meus prompts e melhorar minhas perguntas”.
Como você vai medir?

Defina indicadores. Exemplo: “conseguir resolver 80% dos exercícios sem ajuda”, “fazer 5 commits por semana com mensagens boas revisadas pela IA ou por colegas”, “entregar 1 API por mês revisada por alguém ou validada pela IA”.

Revise seu PDI a cada 2 semanas. Ajuste. Comemore os progressos. E siga em frente.

Conclusão (e lembrete final)

Ser junior não é sobre saber tudo. É sobre estar disposto a aprender, errar, corrigir e evoluir. O mercado não espera que você seja perfeito. Espera que você seja curioso, organizado e proativo.

Use esse guia como mapa. Monte seu PDI. Use a IA como aliada. Troque com outras pessoas sempre que possível, porque conversa traz insights que a IA ainda não reproduz. Mas se você estiver sozinho, saiba que a IA é um ótimo parceiro de estudos.

Lembre-se: cada linha de código que você escreve, cada erro que você corrige, cada pergunta que você faz, seja para a IA ou para um ser humano, é um passo na direção certa.

Você consegue. E quando duvidar, volte aqui. Acredite em você.

Na era da IA, o maior erro de um Programador é não aprender a programar

Laura Fumagalli — Sun, 10 Aug 2025 13:49:18 +0000

Em uma era de crescente automação e ferramentas de inteligência artificial que geram código, como essa frase do título pode fazer sentido? A resposta está na diferença crucial entre "gerar software" e "saber programar". E essa distinção, que reavalia o papel da faculdade e a forma como aprendemos, é o que definirá o sucesso profissional nos próximos anos.

A Era do "Vibe Coding" e a Oportunidade Escondida

Estamos entrando em um período em que a criação de software se tornará acessível a um número cada vez maior de pessoas, incluindo aquelas sem formação técnica aprofundada. Designers, analistas e outros profissionais poderão usar ferramentas avançadas para "vibe coding", ou seja, materializar suas ideias em código funcional sem escrever cada linha manualmente.

Longe de ser uma ameaça, essa democratização é uma oportunidade. Primeiramente, ela eleva o valor percebido do software e do trabalho de quem o constrói. Em segundo lugar, e mais importante, cria uma nova e crescente demanda por especialistas. Afinal, ferramentas de low-code, no-code ou "vibe-code" têm um elemento em comum: elas produzem código.

E a regra de ouro da engenharia de software permanece intacta: quanto mais código, mais bugs. Quem irá depurar, otimizar e resolver os problemas complexos que essas ferramentas inevitavelmente criarão? Nós, os programadores que entendemos os fundamentos. O futuro não é sobre menos trabalho, mas sobre um trabalho mais especializado e valioso.

Redescobrindo o Valor da Faculdade

Durante anos, ouvi sobre a ideia de que um diploma não era necessário para se tornar um programador de sucesso. E, de fato, não é um pré-requisito para entrar no mercado. No entanto, minha experiência me faz avaliar e reconhecer um valor diferente do que tantos pregam: o poder dos fundamentos adquiridos na educação formal.

Durante a minha pós-graduação, uma disciplina de Inteligência Artificial me desafiou a implementar uma rede neural com backpropagation do zero, em Java, a partir de um livro. Foi um processo árduo, que exigiu interpretar conceitos matemáticos complexos e traduzi-los em lógica de programação. Parecia apenas um trabalho acadêmico. Hoje, percebo que aquela experiência construiu uma base tão sólida que me permite navegar com facilidade pelos "hypes" tecnológicos atuais, seja IA, blockchain ou qualquer outra novidade. A tecnologia de superfície muda, mas os princípios fundamentais permanecem os mesmos há décadas.

A Ilusão do Aprendizado na Internet e a Disciplina da Sala de Aula
"Mas hoje não é mais fácil aprender tudo pela internet?" Essa é uma pergunta legítima, mas que esconde uma armadilha. O problema nunca foi a falta de conteúdo. Desde o início dos anos 2000, tínhamos acesso a mais livros e apostilas do que poderíamos consumir. O verdadeiro desafio é a forma como interagimos com esse conhecimento.

Hoje, corremos o risco de cair na falsa sensação de aprendizado. Assistir a um podcast ou a um vídeo explicando um conceito complexo é uma forma de consumo passivo. É completamente diferente de ler um paper, um livro técnico e lutar para implementar aquele conhecimento. A primeira abordagem informa; a segunda, forma.

É aqui que a faculdade revela seu maior trunfo. Ela oferece um currículo estruturado que nos força a estudar tópicos fundamentais, mesmo aqueles que consideraríamos "chatos" ou distantes da prática imediata, como teoria das redes, compiladores ou arquitetura de computadores. Sem essa obrigatoriedade, muitos de nós, por mais proativos que sejamos, pularíamos de um tópico para outro, acumulando um conhecimento superficial que se desfaz rapidamente. A faculdade nos obriga a construir o alicerce, tijolo por tijolo.

Conclusão: Programe, Não Apenas Gere Código

O objetivo desta reflexão não é defender a universidade como o único caminho, mas sim destacar a importância de um aprendizado ativo e profundo dos fundamentos da computação. O programador do futuro não será aquele que apenas sabe usar a ferramenta mais recente para gerar código, mas aquele que compreende o que acontece por baixo do capô.

Portanto, o convite é para uma mudança de mentalidade. Mergulhe em livros, implemente algoritmos do zero, entenda a teoria por trás da prática. Seja através de uma graduação ou de um estudo autodidata disciplinado, invista na construção de uma base sólida.

Escalabilidade DE ZERO A MILHÕES DE USUÁRIOS

Laura Fumagalli — Sun, 13 Jul 2025 14:39:22 +0000

Esse é a postagem 2 de uma série de postagens sobre arquitetura de sistemas.

Projetar um sistema que ofereça suporte a milhões de usuários é desafiador e uma jornada que exige refinamento contínuo e melhorias contínuas. Neste artigo, construímos um sistema que oferece suporte a um único usuário e o escalamos gradualmente para atender a milhões de usuários. Após essa leitura, você dominará algumas técnicas que vão ajudar a decifrar as perguntas sobre design de sistemas que sempre surgem.

Assim como uma maratona começa com um único passo, a construção de um sistema complexo também começa com etapas simples. Nas imagens a seguir, você encontrará uma série de representações de arquiteturas de sistemas que ilustram essa evolução. Para facilitar o entendimento inicial, começaremos com uma abordagem básica, na qual todo o sistema é executado em um único servidor.

A imagem acima (Figura 1-1) mostra a ilustração de uma configuração de servidor único onde tudo está sendo executado em um servidor: aplicativo web, banco de dados, cache, etc.

A imagem acima (Figura 1-2) é a mesma coisa, porém numerado com a ordem que as coisas acontecem. Para entender essa configuração, é útil investigar o fluxo de solicitações e a origem do tráfego. Vamos analisar primeiro o fluxo de solicitações:

As pessoas usuárias acessam sites por meio de nomes de domínio, como api.mysite.com. Normalmente, o Sistema de Nomes de Domínio (DNS) é um serviço pago fornecido por terceiros e não hospedado por nossos servidores.
O endereço de Protocolo de Internet (IP) é retornado ao navegador ou aplicativo móvel. No exemplo, o endereço IP 15.125.23.214 é retornado.
Assim que o endereço IP for obtido, as solicitações do Protocolo de Transferência de Hipertexto (HTTP) são enviadas diretamente ao seu servidor web.
O servidor web retorna páginas HTML ou respostas JSON para renderização.

Em seguida, vamos examinar a origem do tráfego. O tráfego para o seu servidor web vem de duas fontes: aplicativo web e aplicativo móvel.

Aplicativo web: ele usa uma combinação de linguagens do lado do servidor (Java, Python, etc.) para lidar com lógica de negócios, armazenamento, etc., e linguagens do lado do cliente (HTML e JavaScript) para apresentação.
Aplicativo móvel: o protocolo HTTP é o protocolo de comunicação entre o aplicativo móvel e o servidor web. JavaScript Object Notation (JSON) é o formato de resposta de API normalmente usado para transferir de dadosdevido à sua simplicidade. Um exemplo de resposta da API em formato JSON é mostrado abaixo:

GET /users/12 - Recupera o objeto da pessoa usuária cujo id = 12

Exemplo de retorno:

{
    "id": 12,
    "firstName": "Laura",
    "lastName": "Fumagalli",
    "address": {
        "streetAddress": "rua XPTO, 1800",
        "city": "São Paulo",
        "state": "Brazil",
        "postalCode": "12345-678"
    },
    "phoneNumbers": [
        "1191234-5678",
        "1994321-8765"
    ]
}

Banco de dados

Com o crescimento da base de usuários, um servidor não é suficiente e precisamos de vários servidores: um para o tráfego web/móvel e outro para o banco de dados (Figura 1-3). Separar os servidores de tráfego web/móvel (camada web) e de banco de dados (camada de dados) permite que eles sejam dimensionados de forma independente.

Quais bancos de dados usar?

Você pode escolher entre um banco de dados relacional tradicional e um banco de dados não relacional. Vamos examinar suas diferenças.

Bancos de dados relacionais também são chamados de sistemas de gerenciamento de banco de dados relacional (RDBMS) ou banco de dados SQL. Os mais populares são MySQL, banco de dados Oracle, PostgreSQL, etc.

Bancos de dados relacionais representam e armazenam dados em tabelas e linhas. Você pode realizar operações de junção usando SQL em diferentes tabelas de banco de dados.

Bancos de dados não relacionais também são chamados de bancos de dados NoSQL. Os mais populares são CouchDB, Neo4j, Cassandra, HBase, Amazon DynamoDB, etc. Esses bancos de dados são agrupados em quatro categorias: armazenamentos de chave-valor, armazenamentos de gráficos, armazenamentos de colunas e armazenamentos de documentos. Operações de junção geralmente não são suportadas em bancos de dados não relacionais

Para a maioria dos desenvolvedores, bancos de dados relacionais são a melhor opção, pois existem há mais de 40 anos e, historicamente, têm funcionado bem. No entanto, se os bancos de dados relacionais não forem adequados para seus casos de uso específicos, é fundamental explorar além dos bancos de dados relacionais. Bancos de dados não relacionais podem ser a escolha certa se:

Seu aplicativo requer latência superbaixa.
Seus dados não são estruturados ou você não possui dados que se relacionam de algum forma (relacionais).
Você só precisa serializar e desserializar os dados (JSON, XML, YAML, etc.).
Você precisa armazenar uma grande quantidade de dados.

Escalabilidade vertical vs. escalabilidade horizontal

A escalabilidade vertical, conhecida como "scale-up", significa o processo de adicionar mais potência (CPU, RAM, etc.) aos seus servidores. A escalabilidade horizontal, conhecida como "scale-out", permite que você escale adicionando mais servidores ao seu pool de recursos.

Quando o tráfego é baixo, a escala vertical é uma ótima opção, e a simplicidade dessa escala vertical é sua principal vantagem. Infelizmente, ela vem com sérias limitações.

A escalabilidade vertical tem um limite rígido. É impossível adicionar CPU e memória ilimitadas em um único servidor.

A escalabilidade vertical não possui failover e redundância. Se um servidor cair, o site/aplicativo cai completamente com ele.

A escalabilidade horizontal é mais desejável para aplicações de grande escala devido às limitações do escalonamento vertical.

Na arquitetura anterior, os usuários eram conectados diretamente ao servidor web. Os usuários não conseguiriam acessar o site se o servidor web estivesse offline. Em outro cenário, se muitos usuários acessassem o servidor web simultaneamente e ele atingisse o limite de carga do servidor web, os usuários geralmente experimentariam uma resposta mais lenta ou não conseguiriam se conectar ao servidor. Um balanceador de carga(Load Balancer) é a melhor técnica para resolver esses problemas.

Load Balancer

Um balanceador de carga distribui uniformemente o tráfego de entrada entre servidores web definidos em um conjunto de balanceamento de carga. A imagem a seguir (Figura 1-4) mostra como um balanceador de carga funciona.

Conforme mostrado na imagem acima (Figura 1-4), os usuários se conectam diretamente ao IP público do balanceador de carga. Com essa configuração, os servidores web não podem mais ser acessados diretamente pelos clientes. Para aumentar a segurança, são utilizados IPs privados para a comunicação entre os servidores. Um IP privado é um endereço IP acessível apenas dentro da rede local, ou seja, ele não é alcançável a partir da internet. Dessa forma, o balanceador de carga se comunica com os servidores web utilizando esses IPs privados.

Após a adição de um balanceador de carga e de um segundo servidor web, conseguimos resolver com sucesso o problema de failover e melhorar a disponibilidade da camada web. Abaixo estão os detalhes dessa implementação:

Se o Servidor 1 ficar offline, todo o tráfego será automaticamente redirecionado para o Servidor 2 , garantindo que o site permaneça acessível.
Isso evita que o sistema fique fora do ar. Além disso, podemos adicionar um novo servidor web saudável ao pool de servidores, mantendo o balanceamento de carga e a alta disponibilidade.
Caso o tráfego do site aumente rapidamente e dois servidores não sejam suficientes, o balanceador de carga também consegue lidar com esse cenário. Basta adicionar mais servidores ao pool, e o balanceador começará automaticamente a distribuir as requisições entre todos eles.

Agora que a camada web está mais robusta e resiliente, surge uma nova pergunta: e a camada de dados?

Atualmente, o design utiliza apenas um único banco de dados, o que significa que não há suporte para failover nem redundância nessa camada. Isso representa um ponto único de falha e pode colocar a disponibilidade do sistema em risco.

Uma solução comum e eficaz para esse problema é a replicação de banco de dados , uma técnica amplamente utilizada para garantir redundância, alta disponibilidade e tolerância a falhas. Vamos explorar como implementá-la a seguir.

Replicação de banco de dados

Citado da Wikipédia: "A replicação de banco de dados pode ser usada em muitos sistemas de gerenciamento de banco de dados, geralmente com um relacionamento primário/secundário entre o original (primário) e as cópias (secundárias)" [3].

Um banco de dados primário geralmente é responsável pelas operações de escrita. Já os bancos de dados secundários recebem cópias dos dados do primário e são utilizados apenas para operações de leitura. Todos os comandos que modificam os dados, como INSERT, DELETE ou UPDATE, devem ser enviados ao banco de dados primário. A maioria das aplicações realiza muito mais operações de leitura do que de escrita, por isso o número de bancos de dados secundários em um sistema costuma ser maior do que o de primários. A imagem anterior (Figura 1-5) ilustra essa arquitetura com um banco de dados primário e vários secundários.

Vantagens da replicação de banco de dados:

✅ Melhor desempenho

No modelo primário/secundário, todas as gravações e atualizações ocorrem no nó primário, enquanto as operações de leitura são distribuídas entre os nós secundários. Essa divisão de responsabilidades melhora o desempenho do sistema, pois permite que um maior número de consultas seja processado em paralelo.

✅ Confiabilidade e tolerância a falhas

Se um servidor de banco de dados for afetado por um desastre natural, como um tufão ou terremoto, os dados ainda estarão disponíveis nos outros nós secundários. Isso reduz drasticamente o risco de perda de dados e aumenta a disponibilidade do sistema, mesmo em cenários adversos.

✅ Alta disponibilidade:

Ao replicar dados em diferentes locais, seu site permanece em operação mesmo se um banco de dados estiver offline, pois você pode acessar dados armazenados em outro servidor de banco de dados.

Discutimos anteriormente como o uso de um balanceador de carga contribui significativamente para a melhoria da disponibilidade da camada web. Agora, aplicamos a mesma pergunta à camada de dados: e se um dos bancos de dados ficar offline?

A arquitetura apresentada na imagem acima (Figura 1-5) é capaz de lidar com falhas nos bancos de dados de forma eficiente. Abaixo estão os cenários possíveis:

Se apenas um banco de dados secundário estiver disponível e ele ficar offline , as operações de leitura serão temporariamente direcionadas ao banco de dados principal até que o problema seja resolvido. Assim que a falha for detectada, um novo banco de dados secundário será provisionado para substituir o antigo e retomar a redundância. Caso múltiplos bancos de dados secundários estejam disponíveis, as consultas de leitura são automaticamente redirecionadas para os nós ainda saudáveis. Paralelamente, um novo nó secundário é criado para substituir o que falhou, mantendo o nível desejado de disponibilidade e balanceamento de carga.
Se o banco de dados principal ficar indisponível , um dos bancos de dados secundários será promovido a novo banco de dados principal . Durante esse processo, todas as operações (incluindo escritas) são temporariamente executadas no novo nó principal. Em seguida, um novo banco de dados secundário é adicionado para retomar o processo de replicação.

⚠️ Importante: Em ambientes de produção, a promoção automática de um novo banco de dados principal pode ser um processo complexo. Isso ocorre porque, dependendo do tipo de replicação utilizada (síncrona ou assíncrona), alguns dados podem não estar totalmente atualizados nos bancos de dados secundários. Nesses casos, é necessário realizar uma etapa de recuperação de dados para garantir a consistência antes da promoção oficial do novo nó principal.

Embora existam outros métodos de replicação, como replicação circular por exemplo, que podem trazer vantagens adicionais em certos cenários, essas configurações tendem a ser mais complexas e fogem ao escopo deste artigo. Pessoas leitoras interessadas podem pesquisar sobre para aprofundar seus conhecimentos sobre esses tópicos, é um estudo bem interessante.

A imagem abaixo (Figura 1-6) ilustra o projeto atualizado do sistema após a inclusão do balanceador de carga e da replicação do banco de dados. Essa arquitetura reflete uma evolução importante na disponibilidade e escalabilidade do sistema, garantindo maior resiliência frente a falhas e aumento de tráfego.

Excelente! Agora vamos dar uma olhada no design atual do sistema:

Um usuário consulta o DNS e obtém o endereço IP público do balanceador de carga.
Em seguida, o usuário estabelece a conexão com o balanceador de carga usando esse endereço IP.
A solicitação HTTP é então roteada para um dos servidores web disponíveis (Servidor 1 ou Servidor 2), conforme a política de balanceamento configurada.
Quando uma requisição envolve leitura de dados, o servidor web recupera as informações de um banco de dados secundário.
Já as operações que modificam os dados, como inserções, atualizações ou exclusões, são sempre direcionadas ao banco de dados primário, garantindo consistência nos dados.

Agora que você tem uma compreensão sólida das camadas web e de dados, vamos dar o próximo passo: melhorar o tempo de resposta e carregamento do sistema.

No próximo artigo, vou explorar como isso pode ser alcançado com a adição de uma camada de cache e com a utilização de uma Rede de Distribuição de Conteúdo (CDN) para armazenar e entregar conteúdo estático, como arquivos JavaScript, CSS, imagens e vídeos.

Continue acompanhando para descobrir como otimizar ainda mais o desempenho da sua aplicação.

Entrevistas de design de sistemas

Laura Fumagalli — Thu, 10 Jul 2025 12:52:55 +0000

Esse é a postagem 1 de uma série de postagens sobre arquitetura de sistemas.

As entrevistas de design de sistemas são, sem dúvida, um dos maiores desafios em qualquer processo técnico. Diferente de perguntas diretas sobre algoritmos ou estruturas de dados, aqui não existe “uma resposta certa”. O objetivo é claro: projetar uma arquitetura escalável para alguma coisa, como, por exemplo, um feed de notícias, sistema de mensagens, mecanismo de busca, etc... Mas o escopo é muito amplo, a abordagem é aberta, e a pressão é real.

E se você já se sentiu perdido sobre por onde começar, saiba que você não está sozinho(a).

Meu nome é Laura Fumagalli , trabalho em um dos maiores bancos da América Latina, tenho formação em Engenharia de Software e em Arquitetura de Soluções e Software. E foi justamente essa bagagem prática, aliada à ajuda de uma amiga incrível (super referência em IA, inclusive. Quer conhecer? clique aqui ), que me motivou a compartilhar aqui meu conhecimento acumulado ao longo dos ultimos anos.

Este é o primeiro de uma série de posts que vou compartilhar nos próximos dias. E acredite, vai valer a pena acompanhar.

O objetivo? Ajudar você , seja lá qual for seu papel, a ir além e alcançar o próximo nível em design e arquitetura de sistemas . Porque esse tema não é apenas para desenvolvedoras e desenvolvedores. É para todo mundo que trabalha ou convive com sistemas complexos.

Você é gestora ou gestor de projetos ? Acompanhe para entender melhor a linguagem do seu time e tomar decisões mais assertivas.

É desenvolvedora ou desenvolvedor ? Acompanhe para aprender a projetar soluções mais robustas, escaláveis e alinhadas com o negócio.

Está buscando uma nova oportunidade ? Acompanhe para se preparar com antecedência e mostrar durante a entrevista que você entende do que realmente importa.

Essa jornada é para todos. E eu vou guiar quem se interessar passo a passo.

Arquitetura de Sistemas na Prática: Estratégias Para Quem Quer Entender e Aplicar

Empresas em todo o mundo adotam entrevistas de design de sistemas não por acaso. Elas buscam avaliar habilidades que vão além do código: comunicação, pensamento estruturado, capacidade de resolver problemas complexos e a maneira como você discute soluções com outras pessoas. Sim, comunicação.

Essas entrevistas simulam situações reais: você recebe um problema vago e precisa transformá-lo em uma solução clara e funcional. E isso é exatamente o que fazemos no dia a dia como engenheiros e arquitetos de software.

O objetivo desse artigo (e da série que vem por aí) é te mostrar como pensar como um arquiteto de sistemas, seja para se preparar para uma entrevista técnica, seja para melhorar sua prática no trabalho.

Vou compartilhar estratégias reais, passos estruturados e exemplos práticos de como projetar sistemas escaláveis. Você vai aprender a:

Entender os requisitos e restrições de um sistema;
Escolher as tecnologias certas para cada cenário;
Comunicar suas ideias de forma clara e assertiva;
Pensar em escala, segurança e performance desde o início;
Ajustar sua abordagem conforme o feedback do entrevistador ou do time.

Minha intenção é que você saia dessa leitura mais confiante, mais preparado(a) e, acima de tudo, mais curioso(a) para mergulhar fundo nesse universo.

Entender é o Primeiro Passo Para Projetar Bem

O design de sistemas não começa com tecnologia. Ele começa com comunicação . Uma boa arquitetura nasce do diálogo, da capacidade de ouvir, questionar e entender profundamente o problema que está sendo apresentado. Muitas pessoas entram em uma entrevista técnica já querendo propor soluções complexas sem sequer ter clareza dos requisitos reais. E isso pode ser um ponto crítico.

Lembre-se: o objetivo não é mostrar que você sabe de tudo logo de cara, mas sim demonstrar que consegue pensar de forma estruturada, adaptável e colaborativa. A entrevista é uma conversa, não uma prova fechada. E isso reflete diretamente no mundo real: quanto mais você entender o negócio, os usuários e as restrições envolvidas, mais relevante e eficaz será sua contribuição como engenheiro ou arquiteto. Converse com quem está na chamada, pergunte se aquela abordagem faz sentido antes de continuar, isso com certeza vai fazer toda a diferença no resultado final!

Nos próximos artigos, vamos mergulhar fundo nesses passos, desde a análise inicial até a escolha das tecnologias certas, balanceamento de trade-offs e detalhamento da arquitetura de forma simples. Vamos aprender juntos como projetar sistemas que façam sentido e não "apenas funcionem".

Até breve!

Virtual Threads, Records e Pattern Matching no Java: Simplificando a Vida do Dev

Laura Fumagalli — Sun, 09 Feb 2025 13:34:30 +0000

Fala galera! Faz um tempo que não apareço aqui, mas como hoje estou nostálgica, decidi que vou falar sobre três funcionalidades massas que chegaram (ou foram aprimoradas, como preferir) no Java: Virtual Threads, Records e Pattern Matching. Se já cansou de escrever código verboso ou de ter que lidar com concorrência complexa, esses recursos vão fazer seus trazer luz ao seu código. Bora lá?

1. Virtual Threads: Concorrência sem Dor de Cabeça

Imagina o seguinte: você precisa lidar com milhares de tarefas simultâneas, como processar requisições em um servidor web. Tradicionalmente, no Java, isso significava criar threads do sistema operacional, o que pode ser pesado e limitado. Mas agora, com os Virtual Threads (parte do Project Loom), você pode criar milhões de threads leves e eficientes, gerenciadas pela JVM.

O que muda?
- Menos overhead: threads leves que não sobrecarregam o sistema.
- Código mais simples: sem precisar de frameworks complexos para lidar com concorrência.
Exemplo prático:

Runnable task = () -> {
    System.out.println("Rodando em uma virtual thread!");
};

Thread.startVirtualThread(task); // Simples assim!

Se você já sofreu com CompletableFuture ou frameworks reativos, os Virtual Threads são um respiro de ar fresco, uma brisa no verão. Eles chegaram oficialmente no Java 21, então já dá para começar a testar!

2. Records: Adeus, Boilerplate!

Quantas vezes você já escreveu uma classe só para carregar dados, com getters, setters, equals, hashCode e toString? Com os Records, isso acabou! Introduzidos no Java 16, eles são uma forma super concisa de criar classes imutáveis para armazenar dados.

O que é um Record?
- Uma classe que automaticamente gera métodos como equals(), hashCode() e toString().
- Campos são imutáveis e acessados via métodos gerados automaticamente.
Exemplo prático:

record Person(String name, int age) {}

Person person = new Person("João", 25);
System.out.println(person.name()); // João
System.out.println(person); // Person[name=João, age=25]

Percebeu como o código ficou limpo? Records são perfeitos para DTOs, entidades e qualquer lugar onde você precise carregar dados sem complicação.

3. Pattern Matching: Escreva Menos, Faça Mais

Já precisou verificar o tipo de um objeto e fazer um casting manual? Isso pode ser chato e propenso a erros. Com o Pattern Matching, o Java trouxe uma forma bem mais elegante de lidar com isso.

O que é?
- Uma maneira de verificar o tipo de um objeto e extrair seus dados em uma única operação.
- Funciona com instanceof e, a partir do Java 17, com switch também.
Exemplo com instanceof:

Object obj = "Olá, mundo!";
if (obj instanceof String s) { // Verifica e faz o casting automaticamente
    System.out.println(s.toUpperCase()); // OLÁ, MUNDO!
}

Exemplo com switch:

Object obj = 42;
String result = switch (obj) {
    case Integer i -> "É um inteiro: " + i;
    case String s  -> "É uma string: " + s;
    default        -> "Tipo desconhecido";
};
System.out.println(result); // É um inteiro: 42

Pattern Matching torna o código mais legível e menos repetitivo. É aquela funcionalidade que, depois que você começa a usar, não quer mais largar.

Por Que Isso Importa?

Essas funcionalidades mostram como o Java está evoluindo para ser mais moderno, eficiente e fácil de usar. Resumindo:

Virtual Threads: Para concorrência escalável e simples.
Records: Para classes de dados sem boilerplate.
Pattern Matching: Para código mais limpo e seguro.

Se você ainda não experimentou essas features, recomendo fortemente! Elas estão aí para tornar nossa vida de dev mais produtiva e menos estressante. E aí, o que você achou? Já usou alguma delas? Conta aqui nos comentários!

Abraços e happy coding! 🚀

Java #DevCommunity #Programação #DicasDev

Verificando o status da instalação SQL

Laura Fumagalli — Fri, 25 Feb 2022 18:28:37 +0000

Uma instância de um banco de dados é similar à instalação de um software (mais especificamente um serviço) que roda em segundo plano no seu computador. Existem serviços que rodam tanto localmente em sua máquina quanto em servidores remotos ao redor do mundo.

Abra o terminal e digite o seguinte comando (deve ser exibido o status de active no Linux / started no macOS)

# Linux
sudo systemctl status mysql
# macOS
brew services list

Caso o serviço esteja parado, você pode usar o comando a seguir para iniciá-lo:

# Linux
systemctl start mysql
# macOS
brew services run mysql

Para parar o serviço do MySQL , você pode usar o comando stop

# Linux
systemctl stop mysql
# macOS
brew services stop mysql

Para sair, aperte ctrl+c.

Configurando a inicialização e senha do servidor MYSQL

Por padrão, após a instalação, seu servidor vai estar configurado para iniciar junto ao sistema. Caso não queira que isso aconteça, para poupar memória RAM, você pode desativar o início automático utilizando o comando:

# Linux
sudo systemctl disable mysql

# macOS
brew services stop mysql
# Esse comando remove os serviços não utilizados
brew services cleanup

A primeira vez que for utilizar após iniciar o computador, será necessário iniciar o servidor com o comando:

# Linux
sudo systemctl start mysql

# macOS
brew services run mysql

Se desejar ativar novamente que ele inicie junto ao computador, basta usar o comando:

# Linux
sudo systemctl enable mysql

# macOS
brew services start mysql

você poderá agora acessar seu servidor pela linha de comando. Para visualizar quais bancos de dados estão disponíveis, você deve usar o comando:

mysql -u root -p

Docker Compose

Laura Fumagalli — Wed, 16 Feb 2022 21:03:06 +0000

****É um arquivo pelo qual conseguimos configurar todo um ambiente de containers de maneira muito mais simples.
Usando o Compose , definimos em um arquivo de configuração YAML todos os detalhes para executar nosso ambiente de desenvolvimento local, aproveitando todas as vantagens do Docker , sem se preocupar em subir cada um dos containers que envolvem um app com seus parâmetros específicos no run .

Outros recursos importantes que também precisamos entender são os Volumes . Eles são componentes do Docker responsáveis por prover a preservação de informações.

Networks - Redes no Docker

Por padrão, o Docker possui 3 redes que são criadas junto com ele: bridge , none e host . Cada uma delas tem características específicas quanto a conectividade para seus containers . Podemos consultá-las executando:
docker network ls

Bridge

Ao ser iniciado, todo container é associado a uma rede e, caso uma rede não seja especificada explicitamente por nós, ele será associado a rede Bridge .

Host

Ao associarmos um container a essa rede, ela passa a compartilhar toda stack de rede do host , ou seja, da máquina que roda o ambiente Docker . O uso desta rede é recomendada apenas para alguns serviços específicos, normalmente de infra, em que o container precisa desse compartilhamento. Caso contrário, a recomendação é evitá-la.

None

Essa é uma rede que não possui nenhum driver associado. Dessa maneira, ao atribuir um container a ela, o mesmo ficará isolado. Ela é útil quando temos containers que utilizam arquivos para a execução de comandos ou para se comunicar, por exemplo, um container de backup ou que rode apenas um script localmente.

Docker - YouTube Course

Laura Fumagalli — Wed, 16 Feb 2022 18:01:38 +0000

Container - is an isolated environment for running an application

!==

Virtual Machine - is an abstraction of a machine (physical hardware) - Hypervisors

Installing Docker - the lattest version

docker version

Dockerfile - is a file that include instructions packge a image (contains everything that application needs to run)

Container - Is just a process then use that image.
Docker run inside a container an isolated environment

Docker in action

Back End - Docker Parte 2

Laura Fumagalli — Tue, 15 Feb 2022 21:15:45 +0000

Imagens Docker são arquivos que funcionam como espécies de fotos de programas, bibliotecas, frameworks ou mesmo sistemas operacionais, a partir das quais construimos containers e executamos códigos dentro do Docker .

Para listar todas as imagens que foram baixadas em algum momento no seu computador:
docker images

Dessa forma podemos verificar que a imagem está devidamente instalada localmente como pode ser visto a seguir:

REPOSITORY     TAG       IMAGE ID       CREATED        SIZE
hello-world    latest    bc11b176a293   6 weeks ago    9.14kB

Para sabermos se o container da imagem foi criado a partir da imagem, basta rodar o seguinte comando que retorna a lista de containers ativos e inativos (parâmetro -a ):
docker ps -a

A partir de uma imagem, podemos ter vários containers .

*Podemos ter vários containers reproduzindo uma mesma imagem do Docker .
*

Para remover a imagem (o comando -f serve para forçar a remoção do recurso):
docker rmi -f bc11b176a293

Sem a flag -f , o Docker irá nos alertar que já foram criados containers a partir da imagem que estamos tentando excluir, pois a remoção dessa imagem também removerá a fonte de referência dos containers criados a partir dela. Para excluir a imagem mesmo assim, é preciso acrescentar a flag -f .
Ao excluir uma imagem, os containers gerados a partir dela não serão excluídos, apenas ficaram órfãos das camadas da imagem que a utilizavam para executar suas funções. A partir do momento que excluímos uma imagem que era referência para um container, precisaremos baixar uma nova imagem se quisermos rodar os containers criados novamente

======================================================

Comando que baixa a imagem, mas não cria nenhum container:
docker pull <imagem>

Uma imagem é um arquivo imutável e a partir dele um ou mais containers podem ser gerados. Uma imagem do Docker é criada a partir do processo de build * de um arquivo chamado Dockerfile **.

Frequentemente no contexto de programação, o termo build ('construir' em português) se refere ao trabalho de pegar aquele conjunto de instruções que definimos antes (o nosso "script", "código fonte"), e a partir dele, construir um produto que seja executável de maneira mais simples - que por tanto, é melhor para distribuir.
** O Dockerfile é um arquivo que contém as instruções necessárias (como um "script") para que rodemos uma aplicação: Sistema Operacional (SO) utilizado, bibliotecas que devem ser instaladas, arquivos que devem ser inicializados, etc.

Confirmar a existência daquela imagem:
docker images

Já para sabermos se o container da imagem hello-world foi criado a partir da imagem, basta rodar o seguinte comando:
docker ps -a

Podemos ter vários containers reproduzindo uma mesma imagem do Docker .
Toda imagem possui sua IMAGE ID e todo container possui seu CONTAINER ID . Ambos são identificadores únicos desses elementos dentro do Docker e servem como referência para outras possibilidades de comando.

Depois de obter o IMAGE ID , basta executar o comando docker rmi -f , em que rmi vem de " R e m over I magem" ( remove image(s) ).

É importante ressaltar que ao excluir uma imagem, os containers gerados a partir dela não serão excluídos, apenas ficaram órfãos das camadas da imagem que a utilizavam para executar suas funções. Portanto, para gerar novos containers precisaremos de uma nova imagem.

=========================================

Toda imagem no Docker pode ter uma ou várias camadas e esse sistema é conhecido como Layered File System (Sistema de Arquivos em Camadas) .

Como em praticamente toda instância dentro Docker , cada camada também é representada por um código único (uma hash) . A finalidade dessas camadas é que elas possam ser reaproveitadas por outras imagens .

========================================

docker start -ai meu_container
# Aqui passamos o parâmetro `-ai` ao comando `start`,
# para dizer que queremos acoplar ao container (`a`, de 'attach'),
# de modo interativo (`i`, de 'interactive').

=======================================

um Servidor HTTP (Ou servidor web) é um aplicativo capaz de disponibilizar arquivos (como páginas de internet) através de requisições via protocolo de comunicação HTTP , que é o mais utilizado na navegação via internet.

Existem vários servidores http no mercado. No nosso exemplo, utilizaremos o Servidor HTTP Apache , bastante popular entre pessoas desenvolvedoras da linguagem PHP .

rode o seguinte comando para baixar a imagem do servidor:
docker run -d -P httpd:2.4

É importante ressaltar que a porta 80 é a porta interna que é enxergada somente dentro do container e a porta 55000 é a porta externa, ou seja, aquela que pode ser acessada em nossa máquina.

A forma que temos de identificar os containers é por meio do CONTAINER ID , porém, esses números complexos podem acabar nos confundindo na execução de algum comando.
Para resolver isso, existe a possibilidade de nomear seu container. Dessa forma, não precisamos depender de ids aleatórios que o Docker atribui e assim ficará mais fácil parar ou remover o container.
Para dar um nome ao container, basta utilizar a flag --name :
docker run -d -P --name site-trybe httpd:2.4

A atribuição aleatória das portas é feita pela flag -P e, para especificar a porta, utilizamos a flag -p . Desse modo, devemos seguir a sintaxe -p : .
docker run -d -p 54321:80 httpd:2.4

Nesse exemplo, mapeamos a porta 54321 do nosso computador à porta 80 do container. Agora podemos acessar o site estático mantido pelo servidor Apache acessando o endereço http://localhost:54321 no navegador.

Nesse exemplo, mapeamos a porta 54321 do nosso computador à porta 80 do container. Agora podemos acessar o site estático mantido pelo servidor Apache acessando o endereço http://localhost:54321 no navegador.

o uso do parâmetro -P , ele é utilizado para que o Docker faça um mapeamento de portas automático para acesso ao container.

Um detalhe importante é que a porta do container vai variar dependendo da aplicação que você está rodando . No caso do servidor http , a porta padrão de acesso para páginas web é a 80 .
Em uma aplicação de React por outro lado, a imagem deveria expor a porta 3000 como padrão, então é importante saber qual porta sua aplicação vai usar antes de rodar o parâmetro -p .

======================================

Então, para criarmos containers para nossas aplicações, precisamos iniciar criando a imagem deles! E temos a alternativa de fazê-los a partir dos arquivos Dockerfile *.
também podemos "commitar" (como no git ) alterações que fazemos em nossos containers, salvando eles em novas imagens.
Para isso podemos usar o comando docker commit , que serve literalmente para pegarmos as alterações (que são etapas adicionais) que fizemos no nosso container e salvar elas em uma imagem (nova ou já existente).

Back End - Docker

Laura Fumagalli — Mon, 14 Feb 2022 18:43:43 +0000

Processo de deploy ou implantação - se uma pessoa desenvolve utilizando uma distribuição 'A' de Linux , outra utiliza Windows, outra utiliza Mac e no servidor roda uma distribuição 'B' de Linux, todas elas estão trabalhando no mesmo projeto, e da mesma forma, estão disponibilizando-o para o ambiente de produção, em um servidor remoto comum.

Por meio do Docker , resolvemos o problema de incompatibilidade com outros sistemas

É essencial saber Docker , tanto para se adequar ao mercado como para aproveitar seus benefícios durante o ciclo de vida de nossas aplicações.

=============================================

Fazendo a instalação do Docker Engine

No Linux, o Docker não possui uma interface gráfica de utilização (GUI) oficial, contudo, existem várias opções não-oficiais disponíveis, bem como uma extensão oficial da Microsoft para a plataforma no VSCode , que pode ajudar muito no gerenciamento de seus containers .
(https://marketplace.visualstudio.com/items?itemName=ms-azuretools.vscode-docker)

Desinstalando versões anteriores:

sudo apt-get remove docker* containerd runc

Detalhe, o Docker preserva informações sobre imagens, containers , volumes e redes na pasta /var/lib/docker/ . Nesse processo, esses arquivos não são apagados.
Caso nenhum dos pacotes esteja instalado, esse comando retornará um erro E: Impossível encontrar o , nesse caso, é só prosseguir com a instalação.

(https://docs.docker.com/engine/install/ubuntu/)

*Atualizando os índices dos pacotes do apt:
*
sudo apt-get update

sudo apt-get upgrade

Habilitando HTTPS para o apt:

sudo apt-get install \
    apt-transport-https \
    ca-certificates \
    curl \
    gnupg \
    lsb-release

Adicionando uma chave de acesso ao repositório remoto:

curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg

Se tudo correr bem, você não deve receber nenhum retorno visual.

Adicionando o repositório

echo \ "deb [arch=amd64 signed-by=/usr/share/keyrings/docker-archive-keyring.gpg] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable" \ | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

Perceba que adicionamos o repositório stable (em $(lsb_release -cs) stable ), isso significa que teremos somente o repositório com as versões estáveis do Docker .

Em distribuições baseadas no Ubuntu (como o Linux Mint ), talvez você precise alterar o comando $(lsb_release -cs) para uma versão do ubuntu que seja compatível com aquele sistema. Exemplo: Caso você utilize o Linux Mint Tessa , você deve alterar o valor para bionic .

Instalando Docker Engine

sudo apt-get install docker-ce docker-ce-cli containerd.io

Adicionando um usuário ao grupo de usuários docker

⚠️ Atenção ⚠️: Esse procedimento faz com que seu usuário tenha os mesmos privilégios do usuário root (o superusuário no linux) na execução dos comandos Docker *, então use-o com moderação, apenas em ambiente de desenvolvimento.

sudo groupadd docker

Caso ocorra uma mensagem: groupadd: grupo 'docker' já existe , é só prosseguir.

sudo usermod -aG docker $USER

newgrp docker

Iniciando o Daemon do Docker

sudo systemctl status docker

Esse comando deve retornar algo como um pequeno relatório sobre o serviço, onde consta seu status de funcionamento:

● docker.service - Docker Application Container Engine
     Loaded: loaded (/lib/systemd/system/docker.service; enabled; vendor preset: enabled)
     Active: inactive (dead) since Thu 2021-09-23 11:55:11 -03; 2s ago
TriggeredBy: ● docker.socket
       Docs: https://docs.docker.com
    Process: 2034 ExecStart=/usr/bin/dockerd -H fd:// --containerd=/run/containerd/containerd.sock (code=exited, status=0>
   Main PID: 2034 (code=exited, status=0/SUCCESS

Caso o parâmetro Active esteja como stop/waiting ou no nosso caso, como inactive , rode o comando start para iniciá-lo:

sudo systemctl start docker

Ao consultar o status novamente, o processo deverá estar como start/ running/ active .

Habilite o daemon do Docker para iniciar durante o boot :

sudo systemctl enable docker

Validando a instalação

docker run hello-world

Quando damos o comando docker run hello-world , estamos pedindo para que ele busque em seu repositório oficial, uma imagem chamada hello-world que é um exemplo simples de um container , esse que ao final, nos retorna uma mensagem de texto

============================

Desinstalando o Docker Engine

sudo apt-get purge docker-ce docker-ce-cli containerd.io

sudo rm -rf /var/lib/docker
sudo rm -rf /var/lib/containerd

=========================

Rodando o sistema operacional Ubuntu em um container

Os comandos do Docker funcionam no seguinte formato:

docker <comando> <sub-comando> <parâmetros>

O formato do comando para rodar um container é o seguinte:

docker container run <nome-da-imagem>:<tag>

Em que representa a versão daquela imagem, caso nenhuma seja passada, ele assumira que é a última versão disponível ( latest ).

======================

Listando containers

No Docker , é possível saber quais containers estão ativos com o seguinte comando:

docker container ls

docker container ls -a

E caso você queira saber somente sobre o último container criado (independente do status dele), você pode usar o parâmetro -l

docker container ls -l

Obs: o comando run também cria um novo container para aquela imagem toda vez que é executado.

Significado de cada coluna:

CONTAINER ID: Identificador único*;
IMAGE: O nome da imagem utilizada para a criação do container ;
COMMAND: O comando executado/ em execução dentro do container ;
CREATED: Quando foi criado o container ;
STATUS: O status atual do mesmo, no nosso caso, encerrado;
PORT: A porta que estamos utilizando para nos comunicar com o container*;
**NAMES*: O apelido do container , como não definimos nenhum, foi criado um aleatório.

Quando executamos algum comando relacionado ao container , podemos nos referenciar tanto pelo campo ID (inteiro ou parte dele), quanto pelo campo NAMES . ** Veremos isso mais adiante, mas o docker pode disponibilizar uma porta de acesso para aplicação. Para isso, conseguimos fazer uma atribuição de uma porta do sistema hospedeiro, apontando para uma outra porta, no sistema cliente, no formato : . Exemplo 8080:3000 , em que a porta 8080 do meu sistema representa a porta 3000 do container .

========================

Rodando um comando adicional antes de terminar o container

docker container run <nome-da-imagem>:<tag> <comando> <argumentos-do-comando>

Exemplo: docker container run ubuntu echo 'Hello World!'

================================

Rodando o container de forma interativa

O comando -ti são dois comandos juntos: -t que indica pro docker que estamos requisitando um terminal no container que consiga imprimir o retorno dos nossos comandos; -i que estabelece uma interface de comunicação física com esse terminal, no caso, por meio do teclado.

Exemplo: docker container run -ti ubuntu

O domínio do usuário root no terminal do container é o CONTAINER ID do mesmo, nesse caso 65897a6b07fb ( root@65897a6b07fb ) ;
O comando cat /etc/lsb-release retorna os dados da distribuição, no caso, o Ubuntu 20.04 que é a imagem utilizada;
Para sair desse terminal interno do container e retornar ao seu terminal, é só utilizar o comando exit .

====================

Comandos:

docker é o formato padrão para comandos não-abreviados no CLI;
Utilize o parâmetro --help no ou para ter a relação completa do que pode ser executado a partir deles;
Exemplo: docker container --help , ou docker container run --help .
Os são opcionais na execução dos comandos;
O conteúdo faz referência a documentação oficial dos comandos no Docker Docs .
(https://docs.docker.com/engine/reference/commandline/docker/)

Criar e rodar um container:

Deve criar um novo container e roda-lo logo em seguida:
docker container run <parâmetros> <imagem>:<tag>

O parâmetro --name define um para aquele container (ao invés de um nome aleatório) :
docker container run --name <nome-da-sua-escolha> <imagem>:<tag>

Modo 'Cleanup': O parâmetro --rm deve garantir que o container seja removido ao final da execução (útil para testar imagens sem ficar acumulando containers novos) :
docker container run --rm <imagem>:<tag>

O parâmetro -d (de --detach , desacoplado em português) rodará esse container em segundo plano:
docker container run -d <imagem>:<tag>

Trabalhar em segundo plano significa que a aplicação está rodando, porém de forma assíncrona ao comando, ou seja, embora não esteja visível, o processo está lá, funcionando por de trás dos panos. É possível validar isso com o comando docker ps -a .

O comando -d em outros aplicativos e serviços também pode estar associado ao conceito de daemon , que também é uma forma de se referenciar aplicativos que estão funcionando em segundo plano.
No exemplo da imagem ubuntu, faz sentido passar o parâmetro -d associado ao -it como em:
docker container run -dit ubuntu , o que manterá o container ativo em segundo plano, já com um terminal disponível para acesso;

(Comando antigo) * Abreviação do comando docker container run :
docker run <parâmetros> <imagem>:<tag>

Nas versões mais novas, o Docker vem adotando comandos mais verbosos, nos quais identificamos a entidade ( container , image , etc) que estamos trabalhando, antes de realizar o comando (o que o torna mais semântico).

======================================================

Criar um container sem executá-lo

Cria um container com a imagem de referência, mas não o executa imediatamente:
docker container create <parâmetros> <imagem>:<tag>

O parâmetro -it nesse contexto, deve garantir que ao iniciar o container , ele se mantenha ativo e disponha de um terminal de acesso:
docker container create -it <imagem>:<tag>

=======================================================

Listar containers

Lista ( ls , list em inglês) todos os containers ativos:
docker container ls

Lista todos os containers ativos e inativos :
docker container ls -a

Lista o último container criado (independente do seu estado) :
docker container ls -l

(Comando antigo) Abreviação do comando docker container ls (que também pode ser chamado como docker container ps ):
docker ps <parâmetro>

============================================

Iniciar, reiniciar, pausar, resumir e parar um container

Inicia* um container usando referências de sua identificação única (campo CONTAINER ID , parcialmente ou inteiro) , ou pelo nome (campo NAMES ) que foi definido:
docker container start <CONTAINER ID || NAMES>

Reinicia um container usando as referências citadas anteriormente:
docker container restart <CONTAINER ID || NAMES>

Pausa um container usando as referências citadas anteriormente:
docker container pause <CONTAINER ID || NAMES>

Tira um container do modo de pausa usando as referências citadas anteriormente:
docker container unpause <CONTAINER ID || NAMES>

Encerra um container usando as referências citadas anteriormente:
docker container stop <CONTAINER ID || NAMES>

(Comando antigo) São abreviações para os comandos anteriores:
docker <start || restart || pause || unpause || stop> <CONTAINER ID || NAMES>

====================================================

Retomando o acesso a um container interativo rodando em segundo plano

Caso você tenha iniciado um container em segundo plano utilizando -dit , você pode acessar esse container rodando o comando attach :
docker container attach <CONTAINER ID || NAMES>

Abreviação do comando docker container attach :
docker attach <CONTAINER ID || NAMES>

Excluindo containers específicos

Se o container não estiver ativo, esse comando deve remover o mesmo:
docker container rm <CONTAINER ID || NAMES>

Se o container estiver ativo, você deve passar o parâmetro -f (forçar) para parar sua execução e depois efetuar a remoção:
docker container rm -f <CONTAINER ID || NAMES>

(Comando antigo) Abreviação do comando docker container rm :
docker rm <CONTAINER ID || NAMES>

Limpando containers que não estão sendo utilizados

docker container prune

============================================

Monitorando os processos dentro de um container

O comando top , assim como nos terminais linux, traz as informações sobre os processos que estão sendo rodados, mas dentro daquele container , o que não inclui, por exemplo, serviços que são compartilhados com o sistema hospedeiro. Ele é útil para quando estamos os rodando em segundo plano:
docker container top <CONTAINER ID || NAMES>

GitHub Pages React

Laura Fumagalli — Tue, 25 Jan 2022 01:24:47 +0000

// first the command:
// npm install gh-pages --save-dev

// add on packge.json:

// in the top, in the top of "name":
// "homepage": "http://fumagallilaura.github.io/vetmap",

// in the begin of "scripts" key:
// "predeploy": "npm run build",
// "deploy": "gh-pages -d build",

// after the application is ready, run the command:
// npm run deploy