ZeroCopia Dicas Técnicas

Linux, Redes, Programação Back-end e Front-end, Cloud & BI.

Esta página funciona como consulta rápida do conteúdo publicado em infnet. Cada bloco resume um assunto com foco em operação, diagnóstico, boas práticas e erros recorrentes.

05 macroáreas para percorrer o acervo do site sem sobreposição inútil.
27 assuntos mapeados a partir das páginas já publicadas em infnet.
84 dicas rápidas com comandos e snippets reaproveitáveis para estudo e execução.
01 critério editorial: evidência operacional antes de opinião.

> Linux, Sistemas Operacionais & Automação

Esta macroárea reúne Linux, Sistemas Operacionais e automação. O fluxo recomendado é simples: entender o ambiente, medir o estado e só então alterar.

Terminal, arquivos e documentação

Referência: GNU/Linux e Sistemas Operacionais com Linux e Python. Foco em localizar, ler e interpretar antes de editar.

LNX-01
Pesquise em escopo pequeno e pagine a saída.

Quando precisar achar configuração ou artefato de sistema, limite diretório, profundidade e tipo de arquivo. Isso reduz ruído e melhora a leitura.

Erro comum: rodar find / sem filtro e transformar busca simples em volume inútil.

find /etc -maxdepth 2 -type f -name '*.conf' 2>/dev/null | less
LNX-02
Use a documentação do próprio shell antes de copiar comandos.

type, apropos e man resolvem boa parte das dúvidas sem sair do terminal. Eles mostram se o comando é builtin, o termo certo de busca e a sintaxe real.

Erro comum: decorar flags isoladas e aplicar comando sem entender contexto.

type cd
apropos network | head
man rsync

Recursos, logs, dispositivos e montagem

Foco em ler performance, disco e kernel como cadeia causal, sem conclusões isoladas.

LNX-03
Separe CPU, memória e I/O antes de concluir que a máquina está “lenta”.

Uma mesma sensação de lentidão pode ter causas diferentes. Leia cada família de métrica com ferramenta apropriada antes de trocar serviço ou mexer em hardware.

Erro comum: tratar uso alto de CPU como se todo gargalo fosse processador.

ps -eo pid,comm,%cpu,%mem --sort=-%cpu | head
vmstat 1 5
iostat -xz 1 3
LNX-04
Confirme dispositivo, filesystem, montagem e log do kernel na mesma investigação.

Antes de formatar, montar ou culpar o disco, valide a cadeia completa. Isso reduz risco operacional e evita confundir sintoma com causa.

Erro comum: montar “na mão” sem conferir UUID, tipo de FS e mensagens do boot atual.

lsblk -f
mount | grep '/dev/'
journalctl -k -b | tail -n 30

Shell script, systemd, pacotes e containers

Foco em automação repetível: controle de rotina, rastreabilidade e isolamento.

LNX-05
Todo script recorrente merece fail-fast e log mínimo.

Script que mexe em arquivo, serviço ou backup sem tratamento defensivo produz estado quebrado silencioso. O cabeçalho certo já elimina uma classe inteira de erro.

Erro comum: automatizar sem log e descobrir falha apenas quando o dano já ocorreu.

#!/usr/bin/env bash
set -euo pipefail
log(){ printf '[%s] %s\n' "$(date +%F_%T)" "$*"; }
LNX-06
Agende com evidência e teste dependências em ambiente efêmero.

Timers do systemd e containers descartáveis ajudam a separar operação recorrente de experimento. Isso reduz sujeira no host e aumenta previsibilidade.

Erro comum: criar agendamento e nunca validar se ele realmente rodou ou instalar pacote só para um teste rápido.

systemctl --user enable --now backup.timer
systemctl --user list-timers
docker run --rm python:3.12-slim python --version
LNX-07
Leia o estado global antes de reiniciar serviço no escuro.

Antes de alterar a unidade, confirme o panorama com systemctl status e failed units. Isso evita ação reativa em problema que não é do serviço alvo.

Erro comum: reiniciar daemon automaticamente sem checar se a degradação vem de outra unit.

systemctl status
            systemctl --failed
            systemctl status sshd
LNX-08
Separe isolamento de namespace e consumo de cgroup no diagnóstico.

Namespaces mostram contexto de isolamento; cgroups mostram uso agregado de recurso. Ler os dois juntos melhora a precisão do troubleshooting.

Erro comum: usar só um comando e concluir causa de performance sem cruzar evidências.

lsns
            lsns -p <PID>
            systemd-cgtop

> Redes, Observabilidade & Segurança

Foco operacional de redes: configurar, validar, induzir falha, diagnosticar, corrigir e provar com evidência.

Interfaces, rotas, DNS e sockets no Linux

Referência: Programação Distribuída com Redes. Comece sempre pelo estado local antes de culpar o remoto.

NET-01
Comece por interface, rota e porta local.

Boa parte do troubleshooting termina cedo quando você confere se há IP, rota válida e processo ouvindo. É a triagem mínima antes de tocar em firewall ou DNS externo.

Erro comum: testar ping aleatório sem saber por onde o tráfego sairia.

ip -br addr
ip route
ss -tulpen
NET-02
Resolva nome pelo mesmo caminho que o sistema usa.

getent costuma refletir melhor o resolvedor efetivo do host do que ferramentas isoladas. Ele ajuda a separar problema de nome, cache ou override local.

Erro comum: editar /etc/hosts sem verificar o resolvedor e depois esquecer o desvio.

getent hosts api.exemplo.com
grep -v '^#' /etc/hosts
cat /etc/resolv.conf

Diagnóstico por evidência em redes

Foco em correlação de evidências: cruzar visão de cliente, processo e tráfego.

NET-03
Cruze cliente HTTP e socket local na mesma hipótese.

curl -v mostra a conversa; ss mostra se o serviço está mesmo ouvindo. Juntos, eles reduzem chute e melhoram causalidade.

Erro comum: confiar só no navegador ou só no processo local.

curl -v http://host:8080
ss -ltnp | grep 8080
NET-04
Teste transporte com ferramenta ativa, captura e varredura controlada.

Quando a dúvida é porta, combine teste, captura e confirmação externa. Isso separa recusa, filtro, timeout e serviço indisponível.

Erro comum: chamar tudo de “porta fechada” sem capturar pacote nem validar do lado de fora.

nc -vz host 22
sudo tcpdump -ni any port 22
nmap -Pn -p 22 host

Switching, inter-VLAN, ACL, NAT e redundância

Cada comando show deve existir para provar uma hipótese técnica específica.

CCN-01
Valide camada 2 e endereçamento antes de subir a investigação.

VLAN errada, trunk inconsistente ou interface down derrubam a pilha inteira. Ler a base primeiro economiza tempo em troubleshooting.

Erro comum: ir direto para ping entre redes sem conferir o estado local.

show vlan brief
show interfaces trunk
show ip interface brief
CCN-02
ACL, NAT e redundância só contam quando você lê a evidência operacional.

A configuração pode existir e ainda assim não estar sendo usada como esperado. Os comandos de inspeção devem responder por onde o tráfego passou, traduziu e saiu.

Erro comum: aplicar política e nunca provar o efeito sobre o fluxo real.

show access-lists
show ip nat translations
show standby brief
show ip route

VLAN, STP, EtherChannel e DHCPv4

Foco em operação com método: segmentar, validar, induzir falha e corrigir com prova.

CCN-03
STP precisa de raiz, papel e consequência operacional.

Não basta habilitar Rapid PVST+. Sempre confirme quem virou root bridge e como as portas ficaram posicionadas na topologia.

Erro comum: falar em redundância sem verificar convergência nem porta bloqueada.

show spanning-tree vlan 10
show spanning-tree root
CCN-04
EtherChannel e DHCP falham por inconsistência bem antes de falharem por falta de comando.

Agregação e endereçamento dinâmico exigem coerência de parâmetros nas duas pontas e por VLAN. Os resumos certos mostram isso rápido.

Erro comum: misturar negociação do bundle ou esquecer gateway correto no pool.

show etherchannel summary
show interfaces port-channel 1
show ip dhcp binding

Segurança de redes

Foco em segurança verificável: exposição mensurável, hardening e evidência de resultado.

SEC-01
Hardening começa por inventário, não por slogan.

Portas abertas, pacotes pendentes e política ativa contam mais do que checklist decorado. Segurança operacional se mede primeiro.

Erro comum: falar em superfície de ataque sem saber o que o host realmente expõe.

ss -tulpen
sudo apt list --upgradable
sudo ufw status verbose
SEC-02
Depois da regra, audite o efeito e a configuração efetiva.

Controle de acesso e autenticação precisam deixar rastro. Ler log e arquivo de configuração vale mais do que assumir que a política entrou.

Erro comum: ativar proteção e nunca revisar o que de fato mudou.

sudo journalctl --since -2h | grep -Ei 'auth|fail|deny|drop'
sudo grep -R "PermitRootLogin" /etc/ssh/sshd_config*
SEC-03
Desenhe a matriz de fluxos antes de abrir qualquer policy.

Separar fluxo necessário de fluxo proibido antes da configuração reduz retrabalho e evita permissões amplas por urgência.

Erro comum: começar por comando de ACL/ZBF sem definir origem, destino, serviço e direção de cada fluxo.

Origem | Destino | Serviço | Direção | Ação
            WAN | DMZ | tcp/80 | WAN->DMZ | inspect
            WAN | ADMIN/FIN | any | WAN->LAN | drop
SEC-04
Teste política com par positivo e negativo na mesma evidência.

Um único teste de sucesso não prova segurança. Sempre combine um fluxo que deve passar e outro que deve falhar.

Erro comum: validar só o acesso permitido e não confirmar bloqueio do tráfego não autorizado.

curl http://<ip-dmz-web>
            # esperado: sucesso

            nc -vz <ip-lan-interna> 80
            # esperado: bloqueado
SEC-05
Em ZPF, valide direção do zone-pair antes de ajustar regra

No Cisco ZBF, origem e destino definem a política aplicada. Se a direção estiver invertida, o tráfego falha mesmo com class-map correta.

Erro comum: configurar a policy certa no par errado e concluir que o protocolo não está casando.

show zone-pair security
show policy-map type inspect zone-pair
show class-map type inspect
SEC-06
Use MD5 comparativo para provar efeito avalanche no relatório

Ao alterar um caractere na senha, o hash muda completamente. Mostrar esse contraste fortalece a explicação técnica da questão 7.

Erro comum: citar avalanche de forma teórica sem apresentar os dois hashes gerados no laboratório.

echo -n '%S3nh4S3gur4$' | md5sum
echo -n 'S3nh4S3gur4$' | md5sum

> Programação, Algoritmos & Linguagens

Foco em raciocínio técnico: entender modelo mental, justificar estrutura escolhida e provar execução.

Python fundamental: IPO, tipos e operadores

Foco em modelar entrada, processamento e saída com tipo explícito.

PY-01
Converta a entrada na fronteira do programa.

Trazer o dado para o tipo certo logo na leitura simplifica o resto da lógica e expõe erro mais cedo.

Erro comum: deixar tudo como string e descobrir o problema só quando a conta quebra.

idade = int(input("Idade: ").strip())
altura = float(input("Altura: ").strip())
PY-02
Dê nome às variáveis pelo significado do problema.

No começo, modelagem ruim costuma atrapalhar mais do que sintaxe. Nome claro e saída formatada facilitam validação e leitura.

Erro comum: usar x, y e z para tudo e imprimir resultado sem contexto.

total = preco_unitario * quantidade
print(f"Total: R$ {total:.2f}")
PY-03
Fixe o contrato I/O antes de escrever a primeira linha.

Quando o formato de entrada e saida fica explicito no inicio, o codigo cresce com menos retrabalho e menos bugs de formato.

Erro comum: Comecar por tentativa e erro sem definir ordem das entradas e layout da saida.

entrada = input().strip()
            # processar
            print(saida_final)
PY-04
Teste bordas com casos minimos e compare a saida literal.

Para TP introdutorio, a maior causa de erro e detalhe de formato: espaco, ponto e virgula, caixa ou separador faltando.

Erro comum: Validar apenas um caso feliz e ignorar variacao de maiuscula/minuscula ou string vazia.

casos = ["-", "", "Python", "#pythonchallenge"]
            for c in casos:
                print(c)

Algoritmos e Big O introdutórios

Foco em escolher método pelo estado do dado e custo total, não por preferência.

ALG-01
Dado ordenado pede busca binária, não laço linear por reflexo.

Se a ordenação já existe ou se compensa mantê-la, aproveite a estrutura. Isso muda o custo de consulta de forma relevante.

Erro comum: ordenar a cada busca ou ignorar que o conjunto já está ordenado.

from bisect import bisect_left

pos = bisect_left(valores_ordenados, alvo)
ALG-02
Mesmo algoritmo didático merece parada antecipada quando o trabalho acabou.

O estudo melhora quando você enxerga otimizações seguras dentro do próprio algoritmo, em vez de tratá-lo como ritual imutável.

Erro comum: repetir laços inúteis por não observar estado já ordenado.

for i in range(n - 1):
    trocou = False
    ...
    if not trocou:
        break

Hash, pilha, fila e custo intermediário

Foco em estrutura adequada para reduzir custo e explicar comportamento do algoritmo.

DSA-01
Quando o problema é pertinência ou interseção, teste set primeiro.

Tabela hash costuma eliminar laço duplo em problemas de busca repetida. A diferença de custo aparece cedo.

Erro comum: manter comparação quadrática por costume, não por necessidade.

ids = set(ativos)
intersecao = [item for item in lista_a if item in ids]
DSA-02
Fila e pilha não são “listas com apelido”.

Use a estrutura cuja ordem operacional coincide com a regra do problema. Isso deixa o código mais correto e mais barato.

Erro comum: usar list.pop(0) para fila e pagar custo sem perceber.

from collections import deque

fila = deque()
fila.append(cliente)
proximo = fila.popleft()

Heaps, recursão e programação dinâmica

Foco em justificar corretude, custo e trade-off entre abordagens.

DSA-03
Para top-k e fila de prioridade, heap costuma ganhar de ordenação completa.

Se o problema pede só o topo, ordenar tudo geralmente é desperdício. Heap deixa explícita a prioridade e melhora o custo.

Erro comum: ordenar toda a coleção quando só precisa de poucos elementos.

import heapq

top5 = heapq.nlargest(5, vendas, key=lambda item: item["valor"])
DSA-04
Recursão boa tem caso base claro e corte de recomputação.

A forma recursiva pode ser elegante, mas sem memoização ou invariantes ela explode custo e perde defensabilidade.

Erro comum: escrever função bonita e impraticável para entrada real.

from functools import lru_cache

@lru_cache(maxsize=None)
def fib(n):
    return n if n < 2 else fib(n - 1) + fib(n - 2)
DSA-07
No QuickSelect, interrompa assim que o pivô cair no índice alvo.

Selecionar não é ordenar: descarte a partição irrelevante e mantenha foco no k desejado.

Erro comum: rodar QuickSort completo e só depois pegar a mediana.

k = len(arr) // 2
            mediana = quickselect(arr, k)
DSA-08
Instrumente recursão para provar ganho de memoização.

Contar chamadas antes/depois da cache mostra objetivamente a redução de custo.

Erro comum: afirmar melhoria sem coletar evidência de execução.

calls = 0
            @lru_cache(maxsize=None)
            def fib(n):
                global calls; calls += 1
                return n if n < 2 else fib(n-1) + fib(n-2)

Trie, grafos e invariantes em Python

Foco em separar índice textual e estrutura de relacionamento, mantendo corretude e previsibilidade.

DSA-05
Em Trie, diferencie prefixo existente de palavra concluída.

A raiz do erro em busca lexical é assumir que caminho válido implica palavra válida. O contrato correto exige verificação de is_end.

Erro comum: retornar verdadeiro em search apenas porque o caminho foi encontrado.

assert trie.starts_with("car") is True
assert trie.search("car") is True
assert trie.search("ca") is False
DSA-06
No grafo não direcionado, emita aresta canônica no Mermaid.

Para documentar sem ruído, normalize o par (u, v) e emita cada aresta uma única vez. Isso evita duplicação visual e mantém consistência.

Erro comum: exportar u-v e v-u como se fossem duas arestas diferentes.

key = tuple(sorted([u, v]))
if key not in emitted:
    emitted.add(key)
    lines.append(f"{key[0]} --- {key[1]}")
DSA-09
Em Dijkstra, bloqueie peso negativo antes de iniciar a fila de prioridade.

A prova de corretude do algoritmo depende da não negatividade. Valide no início para evitar resultado enganoso.

Erro comum: Executar normalmente com peso negativo e confiar no resultado porque o código não quebrou.

for u in g.adj:
                for v, w in g.adj[u].items():
                    if w < 0:
                        raise ValueError('peso negativo invalida Dijkstra')
DSA-10
No Floyd-Warshall, inicialize diagonal em zero e registre INF fora da diagonal.

Sem essa base, o relaxamento por vértice intermediário propaga valores incorretos e perde consistência entre pares.

Erro comum: Montar matriz sem diagonal zero e obter distâncias absurdas mesmo com laços corretos.

dist = [[INF] * n for _ in range(n)]
            for i in range(n):
                dist[i][i] = 0.0

Java: ambiente, build e debug

Foco em validar JDK, terminal e debug como base de autonomia.

JVM-01
Prove o ambiente pelo terminal antes de discutir o código.

Se javac e java não funcionam fora da IDE, o problema ainda é de ambiente. Resolver isso primeiro economiza horas.

Erro comum: culpar a linguagem quando o PATH ou a instalação estão errados.

javac Main.java && java Main
java -version
javac -version
JVM-02
Debug começa com hipótese, breakpoint e evidência.

Antes de “mexer até funcionar”, delimite onde a variável perde valor, onde a entrada vem errada e onde a exceção nasce.

Erro comum: usar println aleatório sem estratégia de isolamento.

Scanner scanner = new Scanner(System.in);
int divisor = scanner.nextInt();
int resultado = 10 / divisor;

Java: entrada, faixas e laços de console

Foco em usar Scanner com previsibilidade, tratar bordas com if/else e garantir laços com condição de parada defensável.

JVM-03
Quando houver texto e número, leia como linha e faça parse explicitamente.

Isso elimina o bug da quebra de linha perdida e deixa a entrada mais previsível em programas pequenos de console.

Erro comum: misturar nextInt() com nextLine() e culpar o Scanner pela linha “vazia”.

int idade = Integer.parseInt(sc.nextLine());
double nota = Double.parseDouble(sc.nextLine());
String nome = sc.nextLine();
JVM-04
Faixa e repetição exigem fronteira clara e contrato de parada explícito.

Média, desconto, imposto e sequência numérica só ficam corretos quando os limites são escritos sem ambiguidade e o laço sabe exatamente quando encerrar.

Erro comum: usar > onde precisava de >= ou deixar incremento inválido prender o programa em loop infinito.

if (media >= 7.0) {
    System.out.println("Aprovado");
} else if (media >= 5.0) {
    System.out.println("Recuperação");
}

if (inc <= 0) return;

C# e .NET: SDK, build e execução

Foco em separar linguagem, plataforma e toolchain desde o início.

DOT-01
Verifique SDK e gere um projeto mínimo antes de abrir a IDE.

Isso confirma ambiente, template e execução real. Se o esqueleto básico não sobe, o problema ainda não é do seu código.

Erro comum: confundir runtime instalado com SDK disponível para build.

dotnet --list-sdks
dotnet new console -n Demo
dotnet run --project Demo
DOT-02
Separe restore, build e debug para não misturar camadas de problema.

Quando cada etapa é validada isoladamente, o erro aparece com mais nitidez. Isso é especialmente útil em início de stack.

Erro comum: tentar depurar sem saber se o projeto sequer compila em Debug.

dotnet restore
dotnet build -c Debug
dotnet run --project Demo
DOT-03
Valide entrada antes de converter para numero ou data.

TryParse evita quebra e permite controlar o fluxo de erro sem encerrar o programa.

Erro comum: usar Parse direto em Console.ReadLine() e quebrar a execucao em valores invalidos.

if (!DateOnly.TryParseExact(entrada, "dd/MM/yyyy", out var data))\n{\n    Console.WriteLine("Data invalida.");\n    return;\n}
DOT-04
Quebre o problema em etapas pequenas e nomeadas.

Separar leitura, validacao, calculo e exibicao reduz erro logico e acelera depuracao.

Erro comum: concentrar toda a logica em um bloco unico e perder controle dos casos de borda.

var entrada = Console.ReadLine();\n// 1) validar\n// 2) transformar\n// 3) calcular\n// 4) exibir
DOT-05
Modele classe com estado minimo e metodos que alteram esse estado com previsibilidade.

No TP3, cada metodo precisa deixar claro o que muda no objeto e qual resultado deve aparecer no console.

Erro comum: Criar metodos que so imprimem texto sem atualizar atributo algum, impedindo validacao real do comportamento.

public void Vender(int quantidade) {
                if (quantidade <= 0) return;
                Quantidade -= quantidade;
            }
DOT-06
Teste sempre a classe no Main com caso nominal e caso limite.

Confiar apenas na compilacao nao prova regra de negocio; execute sequencias que mostrem estado antes/depois.

Erro comum: Entregar classe sem instancia-la no Main, sem evidenciar entrada, processamento e saida esperada.

var ingresso = new Ingresso("Show", 100, 50);
            Console.WriteLine(ingresso.QuantidadeDisponivel);
            ingresso.Vender(2);
            Console.WriteLine(ingresso.QuantidadeDisponivel);

> Front-end, React & Mobile

Foco em front-end aplicado: JavaScript, renderização declarativa e layout responsivo com papéis claros.

React: JSX, listas, state e props

Foco em transformar dado em interface e separar componente, estado e propriedades.

REA-01
Lista em React pede chave estável derivada do dado.

key não é detalhe visual; ela afeta reconciliação e comportamento da interface. Use identificador real sempre que existir.

Erro comum: usar índice como chave por comodidade e gerar bug difícil de rastrear.

{tarefas.map((tarefa) => (
  <li key={tarefa.id}>{tarefa.nome}</li>
))}
REA-02
Separe estado mutável de dado recebido por props.

Quando cada componente sabe o que recebe e o que controla, a interface fica mais previsível e mais fácil de depurar.

Erro comum: duplicar estado sem necessidade ou editar prop como se fosse local.

const [count, setCount] = useState(0);

<Contador total={count} />

React: fetch, APIs e primeiros componentes

Foco em fluxo de dados: busca, armazenamento em estado e renderização declarativa.

REA-03
Pense em fluxo: buscar, armazenar, renderizar.

React fica mais simples quando a sequência de dados é clara. Efeito assíncrono fora do JSX, estado dentro do componente, render por consequência.

Erro comum: misturar chamada de API e lógica de render no mesmo raciocínio.

const [itens, setItens] = useState([]);

useEffect(() => {
  async function carregar() {
    const response = await fetch("/api/itens");
    setItens(await response.json());
  }
  carregar();
}, []);
REA-04
Renderize estados de carregamento e erro como parte da interface.

Quem consome API precisa prever ausência de dado, falha e sucesso. Isso melhora UX e força clareza no fluxo da aplicação.

Erro comum: assumir que toda chamada remota sempre retorna dados válidos.

if (loading) return <p>Carregando...</p>;
if (error) return <p>Falha ao carregar.</p>;
return <Lista itens={itens} />;
REA-05
Normalize entrada antes de consultar API pública.

Campos de busca como CEP e década precisam limpeza e padronização para reduzir erro de consulta e resposta inconsistente.

Erro comum: montar URL com valor bruto de input e tratar falha só no fim.

const cepLimpo = cep.replace(/\D/g, "");
const decada = Math.floor(Number(ano) / 10) * 10;
REA-06
Agrupe dados antes da UI e renderize por seções.

Quando o enunciado pede agrupamento por departamento, faça a transformação no dado e só depois monte a interface por bloco.

Erro comum: tentar agrupar direto no JSX com lógica espalhada e difícil de manter.

const grupos = itens.reduce((acc, item) => {
  (acc[item.departamento] ||= []).push(item);
  return acc;
}, {});

Mobile-first com Flexbox e Grid

Foco em escolher a técnica certa: picture vs img, Flexbox vs Grid e media queries por contexto.

UI-01
Use Flexbox quando o problema principal for alinhamento em um eixo.

Flex resolve muito bem distribuição, centralização e quebra controlada em linhas ou colunas. Ele é ótimo para blocos e barras de interface.

Erro comum: forçar uma grade inteira em Flexbox quando o layout pede duas dimensões claras.

.container {
  display: flex;
  flex-wrap: wrap;
  gap: 1rem;
  align-items: center;
}
UI-02
Use Grid quando a interface precisa se organizar em duas dimensões.

auto-fit com minmax ajuda a manter responsividade sem quebrar leitura. É uma base excelente para painéis e cards.

Erro comum: fixar colunas rígidas e estourar a viewport no celular.

.grid {
  display: grid;
  grid-template-columns: repeat(auto-fit, minmax(220px, 1fr));
  gap: 1rem;
}
UI-03
Combine media queries por contexto, não só por largura.

Para TP2, pense em contexto real: orientação, impressão, tipo de ponteiro e esquema de cor. Isso evita CSS inflado e comportamento imprevisível.

Erro comum: resolver tudo com breakpoint de largura e ignorar print, hover e dark mode.

@media (orientation: landscape) { ... }
@media print { ... }
@media (hover: hover) and (pointer: fine) { ... }
@media (prefers-color-scheme: dark) { ... }
UI-04
Feche cada exercício com validação curta no DevTools.

Validação operacional evita regressão silenciosa. Registre qual condição mudou e como o layout respondeu em cada breakpoint.

Erro comum: mudar CSS sem comparar comportamento em mobile, tablet e desktop.

# Matriz minima de teste
320x640, 375x667, 768x1024, 1024x768
portrait/landscape
prefers-color-scheme: light/dark
hover/pointer
UI-05
Desenhe o header mobile primeiro e só depois distribua no desktop.

Com base mobile-first, o topo começa estável em tela pequena e evolui por min-width sem retrabalho de estrutura.

Erro comum: iniciar no desktop e tentar “encolher”, acumulando regras de exceção.

.main-nav { display: none; }
.nav-toggle:checked ~ .main-nav { display: flex; }
@media (min-width: 1024px) {
  .hamburger { display: none; }
  .main-nav { display: flex; }
}
UI-06
Separe full width de conteúdo contido para não quebrar composição.

Banner ocupa toda a largura da tela; cards e rodapé interno ficam no container. Essa separação mantém ritmo visual e leitura.

Erro comum: aplicar container no banner e perder o efeito full width.

.banner { width: 100%; }
.container { width: min(1120px, calc(100% - 2rem)); margin-inline: auto; }
.row { display: grid; grid-template-columns: repeat(12, 1fr); }
UI-07
Troque o arquivo com picture; ajuste o encaixe com img e CSS.

Quando o requisito muda a imagem entregue por faixa de tela, use picture. Quando a mídia é a mesma e só precisa ficar fluida, uma img com CSS resolve melhor.

Erro comum: usar só max-width: 100% quando a questão pede source e troca real de arquivo.

<picture>
  <source media="(max-width: 576px)" srcset="img-small.jpg">
  <img src="img-large.jpg" alt="Imagem responsiva">
</picture>

.hero-img { width: 100vw; max-width: 100%; height: auto; }
UI-08
Carregue CSS por cenário e trate viewport como experimento, não como superstição.

Use <link media> ou @import quando a separação por contexto estiver no enunciado, e valide cada hipótese com Device Toolbar ao alterar a meta viewport.

Erro comum: juntar tudo num único arquivo sem condição e depois tentar explicar comportamento que nunca foi isolado.

<link rel="stylesheet" href="screen-small.css" media="screen and (max-width: 767px)">
<link rel="stylesheet" href="print.css" media="print">

@import url("portrait.css") screen and (orientation: portrait);
<meta name="viewport" content="width=device-width, initial-scale=1.0">

TP3 React: migração, fundamentos e validação por evidência

Checklist do TP3 com foco em componentização, estado, efeitos, consumo de APIs e entrega verificável.

TP-0410062723-A
Migre por camadas: base CSS primeiro, componentes depois.

No TP3, faça em ordem: container/row/grid, depois Menu e Header, depois Banner/Card/Partners/Footer. Isso evita quebra em cascata de layout.

Erro comum: começar por componente isolado sem a base de grid e depois remendar responsividade no fim.

# ordem sugerida
1) styles/grid.css
2) Menu + Header
3) Banner + Card
4) Partners + Footer
5) montagem da Home
TP-0410062723-B
Valide com números do enunciado antes de enviar.

A submissão só está completa quando você prova: 2 banners, 4 notícias, 4 parceiros, menu hamburger funcional e CSS/SCSS por componente.

Erro comum: entregar só o visual sem comprovar os quantitativos e sem fechar o fluxo CodeSandbox + PDF.

# checklist final TP3
- 2 itens no Banner
- 4 notícias na Home
- 4 parceiros acima do Footer
- hamburger abre/fecha
- link no CodeSandbox + PDF nome_sobrenome_DR3_TP3
UI-0410222544-A
Prefira dado derivado antes de criar estado novo.

No fluxo de usuários e posts do TP3, usuarioSelecionado deve ser calculado a partir de usuarios + usuarioId, evitando estado redundante.

Erro comum: Criar useState extra para dado que já pode ser obtido com find, aumentando risco de inconsistência.

const usuarioSelecionado =
  usuarios.find((u) => String(u.id) === usuarioId) || null;
UI-0410222544-B
Em APIs grandes, peça só os campos necessários.

Na questão de país aleatório, use fields= no Rest Countries para reduzir payload e simplificar renderização.

Erro comum: Consumir /all completo sem filtro de campos e depois tratar objeto gigante no componente.

const response = await fetch(
  "https://restcountries.com/v3.1/all?fields=name,capital,region,population,flags,cca3"
);

Pipeline HTML: validação estrutural e página de teste

Foco em manter páginas auxiliares no padrão do acervo: includes, toggle, rodapé e evidência de validação visual.

WEB-01
Valide o contrato mínimo do template antes de publicar qualquer ajuste.

A página de teste só cumpre o papel dela quando prova includes de header/footer, seções expansíveis e scripts corretos no final do documento.

Erro comum: testar só HTML estático e esquecer layout-loader ou toggleSection.

rg -n "data-include|toggleSection|layout-loader.js|script.js" infnet/pagina-teste-pipeline.html
WEB-02
Em página curta, o rodapé deve começar logo após o último box de conteúdo.

Esse teste evita regressão visual comum: sobra de área vazia depois do último bloco. O fechamento precisa respeitar o fluxo natural do conteúdo.

Erro comum: usar altura fixa/min-height inadequada e empurrar o rodapé sem necessidade.

python3 -m http.server 8010
# abra /infnet/pagina-teste-pipeline.html e valide o fim da página em desktop e mobile

> Dados, Cloud, Databricks & BI

Foco em dados e cloud com disciplina técnica: arquitetura, schema, organização de ambiente e validação por evidência.

AWS Lakehouse: zonas, governança e custo

Foco em lakehouse como contrato operacional, não como desenho de apresentação.

AWS-01
Raw, clean e analytics são contratos de uso, não nomes de pasta.

Separar camadas ajuda a manter reprocessamento, qualidade e consumo analítico sob controle. O lake fica mais barato e mais legível.

Erro comum: jogar tudo no mesmo prefixo e tentar “governar depois”.

s3://datalake/raw/
s3://datalake/clean/
s3://datalake/analytics/
AWS-02
IAM mínimo, catálogo e lifecycle entram no projeto desde o começo.

Arquitetura séria já nasce pensando em permissão, retenção e governança. Isso evita lake caro, amplo demais e difícil de sustentar.

Erro comum: abrir acesso amplo e deixar custo e retenção para “quando crescer”.

IAM minimo:
- ingestao -> raw/clean
- leitura -> analytics
- administracao -> Glue/Lake Formation

AWS ingestão, particionamento e catálogo

Foco em conectar schema, formato, partição e evidência de execução.

AWS-03
Parquet só vale a pena quando o schema já está disciplinado.

Converter para formato colunar sem ajustar tipos cria problema caro e silencioso no catálogo e nas consultas.

Erro comum: trocar extensão do arquivo e chamar isso de modelagem.

order_timestamp -> timestamp
amount -> decimal(10,2)
status -> string
saida -> parquet
AWS-04
Particione pelo padrão de consulta e registre isso no catálogo.

Partição boa reduz leitura desnecessária e melhora custo. Ela precisa fazer sentido para o consumo analítico real.

Erro comum: particionar por campo irrelevante e esquecer a tabela do catálogo.

s3://clean-zone/vendas/ano=2026/mes=03/dia=11/
Partition keys: ano, mes, dia

Databricks: compute, workspace e CLI

Foco em escolher compute certo para exploração, job agendado e organização de workspace.

DBX-01
Escolha compute pelo tipo de trabalho, não por conveniência do momento.

Cluster interativo serve para exploração; job compute serve para rotina previsível e custo menor. Misturar os dois encarece operação.

Erro comum: manter cluster all-purpose ligado para pipeline repetitivo.

All-Purpose Compute -> exploracao
Job Compute -> pipeline agendado
DBX-02
Organize o workspace desde o primeiro notebook.

CLI e estrutura de pastas evitam acúmulo de artefato solto. Em dados, desorganização do ambiente vira custo operacional muito rápido.

Erro comum: subir notebook isolado sem pensar em projeto, pasta e reuso.

databricks workspace mkdirs /Shared/projeto
databricks workspace ls /Shared

PySpark Core: schema, transformação e Parquet

Foco em ingestão, transformação sem SQL e persistência com disciplina mínima de projeto.

DBX-03
JSON complexo merece schema explícito.

Confiar em inferência para dado aninhado torna o pipeline frágil e pouco repetível. Schema explícito melhora previsibilidade e depuração.

Erro comum: aceitar a inferência padrão e só descobrir desvio no meio da transformação.

df = spark.read.schema(schema).json("/mnt/raw/events.json")
DBX-04
Persistência em Parquet e módulo mínimo já fazem parte da solução.

Escrever dado tratado e separar lógica em módulo simples ajuda a sair do notebook descartável para algo defensável.

Erro comum: deixar toda a lógica espalhada em célula sem estrutura mínima de projeto.

df.write.mode("overwrite").parquet("/mnt/clean/events")
pyproject.toml
src/projeto/transformacoes.py
DBX-05
Converta Bronze para Delta com tabela registrada no Unity Catalog.

A governança começa no namespace catalog.schema.tabela; só escrever arquivo não garante descoberta nem controle operacional.

Erro comum: Manter Parquet solto no volume e chamar isso de camada Bronze governada.

CREATE OR REPLACE TABLE sensorflow_catalog.iot_bronze.sensor_events_bronze
            USING DELTA
            AS SELECT * FROM parquet.`/Volumes/.../*.parquet`;
DBX-06
Inspecione _delta_log para provar transação e versionamento.

Validação técnica de Delta exige evidência de log transacional, não apenas contagem de linhas na tabela.

Erro comum: Encerrar exercício sem verificar o location físico e sem abrir os JSON de commit.

DESCRIBE EXTENDED sensorflow_catalog.iot_bronze.sensor_events_bronze;
            LIST "<location>/_delta_log";
            SELECT * FROM json.`<location>/_delta_log/*.json`;

Looker Studio, SQL e qualidade da base

Foco em diferenciar dimensão, métrica e tipagem correta antes do gráfico.

BI-01
Separar dimensão de métrica começa na fonte, não no dashboard.

Se a base já entra com tipo errado ou papel ambíguo, o gráfico apenas mascara o problema. A limpeza mínima vem antes da visualização.

Erro comum: tratar identificador como métrica ou soma de texto como insight.

SELECT categoria, SUM(valor) AS total
FROM vendas
GROUP BY categoria;
BI-02
Valide totais do dashboard contra a fonte original.

Scorecard bonito sem conferência com planilha ou consulta de base é convite a erro silencioso. BI sério precisa de reconciliação.

Erro comum: assumir que a visualização está certa porque o gráfico “faz sentido”.

=SUM(F2:F101)
SELECT SUM(valor) AS total_esperado FROM vendas;
BI-05
Valide o filtro no WHERE antes de montar visualização.

Quando o recorte SQL está errado, o dashboard só amplifica o erro. Confirme primeiro quais linhas entram no dataset final.

Erro comum: Aplicar filtro apenas no gráfico e esquecer que a consulta base ainda retorna registros indevidos.

SELECT id_pedido, status, valor_total
            FROM pedidos
            WHERE status IN ('ENVIADO', 'PROCESSANDO')
              AND valor_total > 1000;
BI-06
Teste AND e OR com amostra pequena e casos de borda.

Uma contagem simples por condição evita erro de precedência e mostra rapidamente se o agrupamento lógico está coerente.

Erro comum: Misturar AND e OR sem parênteses e só perceber o problema depois do relatório pronto.

SELECT COUNT(*) AS total_validos
            FROM pedidos
            WHERE valor_total > 1000
              AND (status = 'ENVIADO' OR status = 'PROCESSANDO');

Dashboard final, filtros e auditoria visual

Foco em rastreabilidade do relatório: período, origem e coerência de leitura.

BI-03
Todo dashboard entregue deveria dizer de onde veio e até quando vale.

Período, fonte e atualização tornam o relatório auditável. Sem isso, KPI bonito vira argumento fraco.

Erro comum: entregar visual limpo, mas sem metadado básico para leitura responsável.

Periodo: 2026-03-01 a 2026-03-31
Fonte: Google Sheets
Atualizado em: 2026-03-11 09:00
BI-04
Mostre filtros ativos e limite a interpretação ao que os dados sustentam.

Boa visualização informa contexto, não vende causalidade inventada. Filtro explícito e nota de leitura ajudam nisso.

Erro comum: deixar o leitor sem saber qual recorte está ativo e extrapolar demais a análise.

Filtros ativos:
- Regiao = Sudeste
- Canal = Organic
- Periodo = mes atual