Forem: Moprius

Cursor SDK, Composer 2 e a nova economia dos agentes de código

Moprius — Fri, 15 May 2026 15:56:34 +0000

A maneira como desenvolvedores trabalham com IA mudou radicalmente nos últimos meses, e quem está dentro dessa rotina sente a evolução semana após semana. Toda nova ferramenta exige uma adaptação do fluxo de trabalho, e logo aparece outra propondo um modelo melhor. O lançamento do SDK do Cursor em TypeScript, somado ao novo Composer 2, parece ser mais um daqueles momentos em que a fundação inteira é repensada — não apenas a ponta da interface.

Do CLI ao multi-agente: por que o fluxo antigo quebrou

Por muito tempo, o fluxo "sério" de quem trabalha com agentes de código foi via CLI: várias sessões de terminal abertas, cada uma rodando um agente em um worktree distinto, às vezes em repositórios diferentes. Funciona — até um certo ponto. O ponto em questão costuma ser quatro sessões em paralelo. A partir daí, a janela de contexto da pessoa que pilota tudo aquilo passa a ser o gargalo. Não a do modelo, mas a humana.

A consequência prática é familiar: você pergunta a um agente algo que estava sendo discutido com outro; manda uma instrução no terminal errado; perde o fio do que cada sessão estava fazendo; confunde o estado de um pull request aberto aguardando review com uma feature ainda em implementação local. Acrescente a isso mensagens do time chegando em paralelo — alguém de produto querendo saber como funciona uma feature flag, um bug report, um comentário de code review — e o cérebro humano simplesmente não escala.

A solução não é parar de paralelizar. É parar de gerenciar o paralelismo manualmente. É exatamente esse o problema que o Cursor 3 e, mais recentemente, o SDK do Cursor se propõem a resolver.

O que é, de verdade, um "AI harness"

A palavra mais importante que entrou no vocabulário do desenvolvedor de IA neste ano é harness. Antes do harness, há o que muita gente assume ser o trabalho todo: o modelo. Treinar um bom modelo de código exige quantidades absurdas de dados, compute e dinheiro. Mas o modelo, sozinho, é apenas 20% do produto final. Os outros 80% — os que fazem a diferença entre uma demo bonita e um agente realmente útil — vivem no harness.

O harness é a infraestrutura que cerca o modelo e transforma uma sequência de tokens em algo capaz de operar em um repositório real. Os componentes essenciais são:

Context management. Antes de gerar qualquer resposta, o agente precisa encontrar o pedaço certo do código no qual atuar. Em um repositório com cem mil arquivos, isso não é trivial. As ferramentas modernas combinam várias técnicas: indexação completa do codebase, busca semântica (embeddings que encontram trechos por significado, não só por correspondência textual), busca por grep clássico (rápido e exato para nomes de função, símbolos, strings literais) e mapas de dependências para entender o que se conecta a quê. Sem isso, o LLM gasta tokens preciosos "adivinhando" onde mexer, e geralmente erra.

Sandboxing. Cada agente roda em uma VM dedicada, com um clone do repositório, ambiente de desenvolvimento pré-configurado e isolamento de credenciais. Esse é um detalhe que muitos subestimam. Rodar um agente diretamente na própria máquina, com acesso a chaves de produção, tokens de cloud e variáveis de ambiente sensíveis, é uma receita pronta para desastres. O sandbox transforma cada sessão em algo descartável e seguro: se o agente fizer besteira, o blast radius está contido.

Session management. O agente precisa sobreviver às intempéries do mundo real. Laptop entra em modo de espera, conexão de rede cai, o computador é reiniciado. Quando o desenvolvedor volta, a sessão tem que estar lá, exatamente onde parou. Isso exige persistência de estado, checkpoints, sincronização entre cliente e backend, e tratamento robusto de falhas de rede. É o tipo de problema clássico de sistemas distribuídos que, paradoxalmente, virou central em uma ferramenta de codificação.

Ferramental: MCP, hooks, skills, subagents. O agente precisa de ferramentas para ler arquivos, rodar comandos, consultar APIs externas. O padrão emergente é o MCP (Model Context Protocol), que define uma forma uniforme de servir tools a qualquer modelo. Por cima disso vêm os hooks (pontos de extensão que executam código do usuário em momentos específicos do ciclo do agente — antes da edição, depois do commit, antes de chamar o modelo), as skills (pacotes de instruções e arquivos auxiliares que o agente carrega quando o contexto pede) e os subagents (capacidade de o agente principal delegar uma subtarefa a outro agente especializado, com contexto isolado).

Cada um desses componentes é, por si só, um produto. Construir um harness completo do zero, com qualidade de produção, é trabalho para um time inteiro durante muitos meses. É exatamente esse o ponto: até agora, quem queria ter um agente próprio precisava reimplementar tudo isso. O Cursor SDK muda essa equação.

O Cursor SDK em TypeScript

Em três linhas de código em TypeScript, o SDK permite instanciar um agente com o mesmo runtime, o mesmo harness, o mesmo sandbox e o mesmo sistema de context management que rodam dentro do Cursor 3. O modelo padrão é o Composer 2, mas qualquer modelo suportado pode ser escolhido. A execução pode acontecer localmente para iteração rápida, na cloud do Cursor para cargas pesadas ou em ambiente self-hosted para empresas com restrições de rede e compliance.

A implicação prática é grande. Quem tem um produto que poderia se beneficiar de um agente embarcado — uma ferramenta interna de DevOps, um assistente customizado para um stack específico, um automator de tarefas repetitivas em um SaaS — agora consegue colocar isso de pé em horas, não meses. O SDK assume todo o trabalho de infraestrutura, e o desenvolvedor se concentra na lógica do produto, nas tools específicas do domínio e na experiência do usuário.

Outra mudança importante é filosófica. Até pouco tempo, as ferramentas de IA para código se dividiam em duas categorias estanques: produtos de prateleira (Cursor, Copilot, Windsurf) e frameworks para construir seu próprio agente (LangChain, LangGraph, frameworks customizados). Quem escolhia o primeiro caminho ficava preso à interface; quem escolhia o segundo reimplementava o mundo todo. O SDK borra essa fronteira: a mesma fundação que serve o produto de prateleira está agora disponível como biblioteca para quem quer construir algo próprio.

Composer 2: o caso dos modelos especializados em código

Ao lado do SDK, há outra peça que merece atenção: o Composer 2. Ao contrário dos modelos generalistas das grandes fornecedoras, o Composer 2 foi treinado especificamente para tarefas de código. A diferença não está apenas no fine-tuning de superfície — é uma decisão de arquitetura e de pipeline de treinamento. O reinforcement learning é direcionado a tarefas de programação reais: passar testes, resolver issues de repositórios open source, executar refactorings corretos, operar em terminais.

Os benchmarks específicos do domínio (SWE-bench Pro, Terminal-Bench 2.0, Cursor Bench) mostram resultados de nível "frontier" — comparáveis aos melhores modelos generalistas em tarefas de código. Mas a métrica que muda tudo é a econômica: o custo de inferência fica em uma fração do que se paga por um modelo generalista equivalente em capacidade.

Esse ponto merece um momento. A indústria está percebendo que treinar um modelo gigantesco para "fazer tudo" tem retorno decrescente. Um modelo de 200 ou 300 bilhões de parâmetros que sabe escrever poesia, traduzir, programar, raciocinar sobre física e debater filosofia é caro de servir e, em qualquer uma dessas tarefas, perde para um modelo menor e bem treinado naquele domínio específico. Para tarefas de código, em que o universo de respostas válidas tem estrutura forte (sintaxe, tipos, semântica) e em que existem sinais de recompensa claros (compila? passa nos testes?), modelos especializados podem ser drasticamente mais eficientes.

A consequência para o desenvolvedor é direta: o custo por tarefa cai. Um agente que antes consumia o equivalente a alguns dólares para resolver um bug agora consome centavos. Isso muda completamente o cálculo de quando vale a pena usar um agente. Tarefas que antes pareciam pequenas demais para "queimar" um modelo caro agora cabem confortavelmente no orçamento.

A economia do token: a nova métrica de eficiência

Em equipes de desenvolvimento que adotam essas ferramentas em escala, uma métrica vem ganhando espaço nos dashboards: tokens consumidos por desenvolvedor por período. Não é incomum encontrar engenheiros queimando 25 milhões de tokens por semana, ou mais de 50 milhões em vinte dias. Esses números traduzidos em dólar, dependendo do modelo, podem chegar a milhares de dólares por mês por pessoa.

Isso não é necessariamente um problema — se o retorno em produtividade compensa, é dinheiro bem gasto. Mas exige uma disciplina nova: a de escolher o modelo certo para cada tarefa. Usar o modelo mais caro disponível para todas as interações é o equivalente a usar um bisturi de cirurgia para cortar pão. Funciona, mas é desperdício.

A regra emergente é simples na intenção e complexa na execução: tarefas de exploração e geração de código de média complexidade vão para o modelo especializado (Composer 2 ou equivalente); tarefas que exigem raciocínio profundo, decisões arquiteturais ou síntese de muitos artefatos diferentes vão para o modelo generalista de topo (Claude Opus, GPT da geração mais recente, Gemini Ultra). Tarefas pequenas — formatação, renomeação, refactorings simples — podem ir para modelos menores e mais baratos.

A métrica de "eficiência por mil tokens" (custo dividido por valor entregue) está se tornando central. Reduzir essa métrica de uma fração de centavo para uma fração menor ainda, vezes dezenas de milhões de tokens por mês, vira economia real.

Multitarefa com agentes: o novo workflow

Com o harness pronto e a economia equacionada, o workflow muda de forma. A interface visual de múltiplas sessões — cada uma representando uma tarefa em andamento, com seu próprio estado, repositório, branch e histórico de conversação — passa a ser o centro de operações.

Algumas práticas se firmam:

Pinar sessões ativas. Sessões que têm um pull request aberto aguardando review, ou que envolvem uma tarefa que precisa ser retomada na manhã seguinte, ficam fixadas. Ao abrir a ferramenta, é a primeira coisa que aparece. É o equivalente moderno do "post-it na tela".

Ordenar por última atualização. Tarefas dormentes saem do campo de visão; tarefas que receberam input recente (um comentário de review, uma resposta de CI) sobem.

Indicadores visuais de estado. Saber de relance se um PR foi mergeado, fechado, ou ainda está aberto reduz drasticamente o custo cognitivo de gerenciar dezenas de tarefas simultâneas. É a diferença entre vasculhar abas de terminal e olhar para um kanban.

Separação por VM. Como cada agente roda em sandbox próprio, alternar entre tarefas não tem custo de "trocar de contexto" no nível do ambiente. A branch certa está checada, as dependências instaladas, o estado do banco de testes preservado. O desenvolvedor só precisa trocar de contexto mentalmente — e mesmo isso fica mais fácil quando a interface ajuda.

O resultado prático é que o limite de quatro tarefas em paralelo (típico de quem trabalha via CLI) sobe consideravelmente. Não é incomum manter dez, quinze sessões ativas, com diferentes graus de envolvimento humano em cada uma. Algumas exigem atenção constante; outras estão no modo "agente trabalha sozinho até concluir ou pedir ajuda".

Para onde isso aponta

A combinação de SDK aberto, modelo especializado eficiente e infraestrutura de execução robusta indica uma transição importante. Ferramentas de IA para código deixam de ser apenas "lugares onde você programa" e passam a ser plataformas sobre as quais outras ferramentas são construídas. A linha entre "usuário do produto" e "desenvolvedor que constrói com a plataforma" começa a se dissolver.

Para quem desenvolve software como atividade principal, isso significa mais alavancagem. O limite do que uma pessoa consegue produzir em um dia deixou de ser a velocidade de digitação ou o número de janelas que cabem na tela. Passa a ser a capacidade de orquestrar agentes, definir bem cada tarefa, revisar com critério o que volta e manter a visão de produto no comando das decisões importantes.

Para empresas que dependem de software como meio (a maioria, hoje), o impacto é estratégico. Construir agentes próprios para fluxos internos, com a mesma qualidade técnica das ferramentas comerciais de ponta, agora cabe no orçamento e no calendário. Quem entender isso primeiro vai ter uma vantagem competitiva que não vinha da escolha de stack — vinha da escolha de quando, e em quê, aplicar agentes.

E para o ecossistema como um todo, vale registrar: estamos saindo de uma fase em que o gargalo era o modelo, e entrando em uma fase em que o gargalo é a infraestrutura ao redor dele. Os próximos avanços relevantes em produtividade de desenvolvedores provavelmente não virão de modelos significativamente maiores. Virão de harnesses mais inteligentes, melhor integração com ferramentas existentes e workflows que respeitem como humanos realmente trabalham — em paralelo, de forma fragmentada, com interrupções, e precisando preservar contexto entre sessões longas.

O Cursor SDK, com tudo que ele encapsula, é um marco nesse caminho. Vale prestar atenção.

Hunyuan Preview: o gigante chinês entra de vez na corrida dos modelos abertos

Moprius — Fri, 15 May 2026 14:18:51 +0000

Quando se fala em IA chinesa open source, os nomes que costumam vir à cabeça são DeepSeek, Qwen, GLM, MiniMax, Kimi — modelos saídos de laboratórios e empresas relativamente pequenas em comparação aos colossos do setor. Falta, nessa lista, um peso pesado óbvio: a Tencent. Maior empresa da China, dona do WeChat (uma espécie de WhatsApp, banco, marketplace e rede social fundidos em um único aplicativo), a Tencent até agora aparecia pouco nas conversas sobre modelos abertos competitivos. O Hunyuan Preview muda esse cenário.

O que é o Hunyuan Preview

O Hunyuan-A13B Preview (também referido como HY3 Preview) é um modelo open source da Tencent, disponibilizado no Hugging Face com pesos abertos. A pronúncia do nome, para quem se aventura no mandarim, fica algo próximo de "ruan-san", e não "hai-san" — uma confusão comum entre falantes ocidentais, já que o "H" do pinyin tem som diferente do esperado.

A ficha técnica chama atenção:

295 bilhões de parâmetros totais
21 bilhões de parâmetros ativos por token
Arquitetura Mixture of Experts (MoE)
Janela de contexto de 256 mil tokens
Suporte a MTP (Multi-Token Prediction)
Modos de "thinking" configuráveis (low e high)

Para efeito de comparação, o Kimi K2 opera na faixa de 1 trilhão de parâmetros, enquanto modelos como GLM 4.5 e DeepSeek V3 ficam em patamares semelhantes ao Hunyuan. O ponto interessante é justamente esse: com cerca de 30% do tamanho do Kimi, o Hunyuan se propõe a chegar perto em capacidade prática.

Mixture of Experts: por que importa

A arquitetura MoE é o que torna o modelo viável fora de data centers gigantes. Em um modelo "denso" tradicional, cada token gerado precisa passar por todos os parâmetros da rede — se o modelo tem 295 bilhões de parâmetros, todos eles trabalham em cada palavra produzida. Isso é caro em memória e devastador em velocidade.

No MoE, o modelo é dividido em "especialistas" — sub-redes que se ativam seletivamente. Para cada token, um roteador escolhe um pequeno subconjunto de especialistas para fazer o trabalho. No caso do Hunyuan, são 21 bilhões de parâmetros ativos por vez, de um total de 295 bilhões. O efeito prático é que a inferência tem o custo de um modelo de 21B, mas o conhecimento e a capacidade de um modelo várias vezes maior.

A contrapartida é o consumo de memória: o modelo inteiro precisa estar carregado na RAM ou na VRAM, mesmo que só uma fração esteja em uso a cada passo. Por isso o MoE é especialmente amigável para arquiteturas com muita memória unificada (como os Macs da linha Studio com chips M3/M4 Ultra) e menos prático em GPUs tradicionais, onde 24 ou 32 GB de VRAM são o teto comum.

MTP: a moda do "Multi-Token Prediction"

O MTP é uma das técnicas que mais ganharam tração no último ano e está presente em quase todos os modelos chineses recentes de ponta. A ideia básica é simples: em vez de gerar um token de cada vez, o modelo tenta prever vários tokens à frente de uma só vez.

Na prática, funciona como uma espécie de "decodificação especulativa interna". Um modelo menor (ou cabeças auxiliares acopladas ao modelo principal) palpita vários tokens à frente, e o modelo grande apenas valida se aquela sequência faz sentido. Se faz, todos os tokens são aceitos de uma vez; se não, descarta-se a partir do ponto em que a divergência aparece, e o processo recomeça.

O ganho é significativo, especialmente em hardware com largura de banda limitada de memória — o gargalo real da inferência local não costuma ser o poder de cálculo da GPU, e sim a velocidade com que os pesos do modelo são lidos da memória. Quando uma única passagem produz dois, três ou quatro tokens em vez de um, a velocidade efetiva pode dobrar ou triplicar sem grandes alterações na receita do modelo.

Janela de contexto e modo de raciocínio

Os 256 mil tokens de contexto colocam o Hunyuan no mesmo patamar dos modelos comerciais de fronteira. Para fins práticos, isso significa caber confortavelmente bases de código médias, livros inteiros ou históricos longos de conversa sem precisar recorrer a estratégias de compressão ou recuperação.

O sistema de "thinking" com níveis configuráveis (low/high) segue a tendência inaugurada pelos modelos de raciocínio. No nível low, o modelo pensa pouco antes de responder — útil para tarefas diretas. No high, a cadeia de raciocínio se estende, com o modelo elaborando planos, esboçando estruturas e revisando o próprio raciocínio antes de produzir a resposta final. Em tarefas como programação de jogos completos em um único arquivo, o modo high pode consumir vários milhares de tokens só na fase de pensamento — mas o resultado tende a ser drasticamente melhor.

Como ele se compara

Nos benchmarks divulgados, o Hunyuan Preview se posiciona ombro a ombro com Gemini 3.1 Pro, GLM 5, Qwen 2.5 e GPT-5.4 — modelos da geração anterior, vale dizer, já que GLM 5.1, Qwen 2.6 e GPT-5.5 já existem. Em SWE-bench, benchmark que mede capacidade real de resolver issues em repositórios de código, o salto da geração HY2 para HY3 é considerável, maior do que os saltos vistos entre versões consecutivas de Qwen ou GLM.

A advertência usual sobre benchmarks vale aqui: os números refletem desempenho em tarefas padronizadas, e a experiência no uso diário pode ser bem diferente. Mas o quadro geral indica um modelo competitivo, ainda que não líder absoluto.

Comportamento na prática

Em testes de geração de aplicações web completas — uma página HTML usando as APIs nativas de Text-to-Speech e Speech-to-Text do navegador para apoio ao estudo de mandarim, por exemplo — o modelo entrega código funcional, com um design razoável (embora não excepcional) e implementação correta das integrações com a Web Speech API. Pequenos detalhes de usabilidade, como o posicionamento dos elementos, ficam abaixo do esperado, mas nada que exija intervenção pesada.

Para jogos mais complexos, o resultado é misto. Um clone de jogo de sinuca em HTML/Canvas saiu praticamente funcional, com física razoável de colisão entre bolas, controle de taco por mouse e visual em 2D. Apenas um erro de digitação no código (uma variável duplicando uma letra) impediu a execução de primeira — correção trivial.

Um clone de Doom usando Three.js também funcionou na primeira tentativa, sem erros de sintaxe. O resultado é simples: uma arena aberta, alguns inimigos com movimentos básicos, uma pistola e uma shotgun. Falta munição reabastecível, sistema de fases, variedade real de inimigos. Mas para um único prompt e um único arquivo, o esqueleto está lá.

Já em tarefas mais ambiciosas, como um clone de Zelda em estilo voxel com mapa, inimigos, sistema de chaves e boss — descritas em prompts longos e detalhados —, o modelo tropeça. O código gerado precisou de várias rodadas de correção, e mesmo após ajustes, parte das mecânicas especificadas no prompt acabou não sendo implementada. É o tipo de tarefa em que modelos no topo absoluto da curva (como Qwen 3.6 Max) ainda têm vantagem clara.

Performance local: o caso do Mac Studio

Aqui aparece uma das discussões mais interessantes sobre o ecossistema de modelos abertos: onde rodar.

Em um Mac Studio M3 Ultra com 256 GB de memória unificada, o Hunyuan Preview em quantização Q4 (aproximadamente 166 GB de pesos) roda confortavelmente entre 20 e 24 tokens por segundo no início de uma geração, caindo para 15 a 20 tokens por segundo conforme o contexto cresce e atinge 10–15 mil tokens. Não é uma experiência fulminante, mas é perfeitamente utilizável.

A comparação relevante é com modelos densos rodando em GPUs Nvidia. Uma RTX 5090 com 32 GB de VRAM consegue rodar um Qwen 3.6 de 27 bilhões de parâmetros denso em Q4 a 50–60 tokens por segundo — o dobro da velocidade. O problema é que não cabe nada muito maior do que isso na VRAM. Para rodar um modelo de 295B/21B-ativos como o Hunyuan em GPUs Nvidia tradicionais, é preciso um cluster ou hardware especializado.

A largura de banda explica boa parte da diferença: a 5090 tem cerca de 1,7 TB/s de banda de memória, contra ~800 GB/s do M3 Ultra. Em modelos densos, em que toda a memória precisa ser percorrida a cada token, a GPU vence com folga. Em modelos MoE como o Hunyuan, em que apenas 21B dos 295B parâmetros são tocados por token, o Mac compensa parte da desvantagem de banda com a possibilidade de carregar o modelo inteiro.

A pergunta de fundo — vale mais rodar um modelo denso de 27B ou um MoE de 295B/21B-ativos? — não tem resposta única. Modelos MoE bem treinados costumam ser, em capacidade absoluta, equivalentes a modelos densos várias vezes maiores que sua contagem de parâmetros ativos. Em teoria, 21B ativos em um MoE bem feito rivalizam com um denso de 50–80B. Na prática, depende do treinamento, dos dados, da arquitetura específica e da tarefa.

Quantização: o detalhe que muda tudo

Vale uma nota sobre quantização. O modelo nativo, em precisão de 16 bits, ocuparia perto de 600 GB — fora do alcance de qualquer hardware de consumo. As versões Q4 reduzem cada peso a quatro bits, com perda mínima de qualidade na maior parte das tarefas. Versões Q8 ficam no meio do caminho: mais fiéis ao modelo original, mas com o dobro do tamanho em memória.

Plataformas como o OpenRouter geralmente servem os modelos em quantização não documentada, o que torna difícil comparar diretamente o desempenho local com o desempenho via API. Para usuários que rodam o modelo no próprio hardware, a escolha da quantização é uma decisão de compromisso entre velocidade, memória e qualidade final.

O que isso significa para o ecossistema

O Hunyuan Preview consolida algo que vinha se desenhando ao longo de 2025: o open source chinês não é mais uma curiosidade ou uma alternativa de segunda linha. É a frente real de inovação em modelos abertos. Empresas que antes pareciam alheias a essa corrida — como a própria Tencent — estão entrando com modelos de qualidade competitiva e licenças permissivas.

Para desenvolvedores e empresas que querem soluções de IA sem depender de APIs fechadas, o cardápio nunca foi tão amplo. Modelos densos de 20–30B para hardware modesto, MoEs gigantes para quem tem memória sobrando, modelos especializados em raciocínio, em geração de código, em multimodalidade. A "comoditização" da inferência avançada está, dia a dia, deixando de ser uma promessa.

A próxima geração de hardware — Macs com chips M5 e M6, GPUs com mais VRAM, aceleradores dedicados — promete tornar essa experiência ainda mais fluida. O tempo de processamento de prefill (a fase em que o modelo "lê" o contexto antes de começar a responder), hoje um dos pontos fracos dos chips Apple comparados às GPUs Nvidia, deve melhorar substancialmente. Quando isso acontecer, rodar um modelo de 300 bilhões de parâmetros em casa será tão trivial quanto rodar um modelo de 7B é hoje.

E o Hunyuan Preview, com seus 21 bilhões de parâmetros ativos e sua licença aberta, é um dos pilares dessa transição.

Entendendo o Linux por dentro: uma viagem pelas camadas que fazem o sistema funcionar

Moprius — Fri, 15 May 2026 12:58:06 +0000

Introdução: por que o Linux parece tão complicado (e por que ele não é, quando você sabe olhar)

Quando você abre um navegador no Linux, digita o endereço de um site e aperta Enter, uma quantidade impressionante de engrenagens invisíveis começa a girar. Um processo conversa com outro processo. Esse outro processo pede ajuda a uma biblioteca compartilhada. Essa biblioteca, por sua vez, faz uma chamada ao núcleo do sistema operacional, que finalmente pede ao hardware que envie sinais elétricos por uma placa de rede. Tudo isso acontece em frações de segundo, sem que você precise pensar em nada disso.

Para quem está começando, esse cenário parece intimidador. Existem dezenas de componentes rodando ao mesmo tempo, trocando mensagens entre si o tempo todo. E a pergunta que fica é: como compreender esse emaranhado sem se perder?

A boa notícia é que existe um método. E ele tem nome: abstração. É justamente com esse conceito que precisamos começar — e é a partir dele que conseguimos enxergar o sistema operacional não como um amontoado confuso, mas como um conjunto bem organizado de camadas com responsabilidades específicas.

Esta postagem é um passeio pelos fundamentos do funcionamento do Linux, indo desde a ideia de níveis e camadas de abstração até os conceitos de usuário e permissões. A ideia é traduzir esses conceitos para uma linguagem clara, com exemplos do dia a dia, para que mesmo quem nunca abriu um terminal consiga sair daqui com uma noção sólida de como o Linux funciona por baixo do capô.

1. Abstração: o segredo para entender qualquer sistema complexo

Antes de mergulhar em qualquer detalhe técnico, precisamos parar e entender o que é abstração. Uma analogia simples com um carro ajuda muito a fixar a ideia.

Imagine que você é apenas um passageiro em um carro. O que você precisa saber para usufruir dessa viagem? Praticamente nada além de como abrir a porta, como afivelar o cinto e talvez como ajustar o banco. Não importa para você quais são os parafusos que prendem o motor, que tipo de óleo lubrifica os pistões, ou como foi pavimentada a estrada. Você está em um nível alto de abstração: usa o produto final sem se preocupar com o que está por baixo.

Agora suponha que você precise dirigir o carro. Subitamente, seu nível de abstração precisa diminuir um pouco. Você ainda não precisa saber montar um motor, mas precisa entender pelo menos três coisas: o próprio carro (tamanho, capacidade, particularidades), os controles (volante, acelerador, embreagem, freio) e as características da estrada (curvas, faixas, sinais de trânsito).

E quando a viagem fica desconfortável, com vibrações estranhas? A abstração ajuda você a diagnosticar o problema de forma estruturada. Pode ser problema no carro? No seu modo de dirigir? Na estrada? Eliminando uma hipótese por vez, você chega à raiz do problema. Se a estrada está esburacada, talvez você queira ir ainda mais fundo: por que a estrada está assim? Houve falta de manutenção? Os operários fizeram um trabalho mal feito?

Esse é exatamente o jeito como engenheiros e desenvolvedores de software pensam quando constroem sistemas operacionais. Em vez de tentar entender tudo de uma vez, eles dividem o sistema em pedaços menores e mais gerenciáveis. Cada pedaço é chamado de subsistema, módulo, pacote ou, de modo mais genérico, componente.

A grande sacada da abstração é que, ao desenvolver um componente, o programador não precisa saber em detalhe como os outros componentes funcionam por dentro — basta saber o que cada um faz e como pedir os serviços que ele oferece. É como ligar para o serviço de entrega: você não precisa saber qual rota o entregador vai fazer ou como ele monta o veículo. Você só precisa saber o número do telefone e o que pedir.

Essa lógica vai guiar todo o resto deste texto. Cada peça do Linux será apresentada não pelos detalhes internos, mas pelo papel que desempenha no funcionamento geral do sistema.

2. Os níveis e camadas de abstração no Linux

A abstração ajuda a dividir o sistema em pedaços, mas, por si só, ela não basta. Precisamos de organização. Os pedaços precisam ser arrumados em camadas, e cada camada se diferencia das outras pela sua proximidade com o hardware ou com o usuário.

No topo dessa pilha, estão as coisas com as quais você interage diretamente: o navegador, o jogo, o editor de texto, o reprodutor de música. Na base, no nível mais fundamental, está o hardware puro — a memória física, os bits, os zeros e uns que circulam pelos circuitos. No meio dessa enorme distância entre o usuário e o hardware, fica o sistema operacional, ocupando várias camadas intermediárias.

No Linux, podemos resumir essa organização em três grandes níveis:

Hardware — a base de tudo. Inclui a memória principal (RAM), uma ou mais unidades centrais de processamento (CPUs), discos, interfaces de rede e quaisquer outros dispositivos físicos.
Kernel — o núcleo do sistema operacional. É um software que reside na memória e atua como intermediário entre o hardware e tudo o que roda acima dele. Ele controla o acesso à memória, decide qual processo usa a CPU, conversa com os dispositivos e fornece serviços essenciais para os programas.
Processos do usuário (espaço do usuário) — todos os programas em execução que o kernel gerencia. Isso inclui a interface gráfica, os servidores, o shell (terminal), os navegadores, enfim, tudo o que executa "por cima" do kernel.

Vale notar que mesmo o termo "processo do usuário" é uma generalização. Quando falamos em "processo do usuário", não estamos nos referindo apenas a programas com os quais um ser humano interage diretamente. Um servidor web, por exemplo, é um processo do usuário, mesmo que nenhum ser humano esteja olhando para a tela enquanto ele atende requisições.

A diferença crítica entre modo kernel e modo usuário

Aqui chegamos a um dos pontos mais importantes do assunto, e que precisa ficar bem claro: o kernel e os processos do usuário rodam em modos diferentes da CPU.

O modo kernel dá acesso irrestrito ao processador e à memória principal. É um poder enorme, mas também perigoso: um erro em código rodando em modo kernel pode corromper ou derrubar o sistema inteiro. A região da memória que só o kernel pode acessar é chamada de kernel space (espaço do kernel).
O modo usuário, por outro lado, restringe o acesso a um subconjunto bem menor da memória e a operações seguras da CPU. A área da memória onde os processos do usuário rodam é chamada de user space (espaço do usuário). Se um processo do usuário falhar — por exemplo, se o navegador travar —, o estrago fica contido: o kernel limpa a bagunça e o resto do sistema continua funcionando.

Esse isolamento é o que permite que seu navegador trave sem que o cálculo científico que está rodando em segundo plano há três dias seja perdido. Cada processo está numa caixinha protegida, e essa caixinha só pode ser aberta pelo kernel.

Em teoria, um processo do usuário não consegue causar danos sérios ao sistema. Na prática, depende: se ele tiver as permissões certas, pode sim, por exemplo, apagar dados de um disco. Existem salvaguardas para evitar esse tipo de problema, mas o ponto é que o conceito de "modo" cria uma barreira clara entre o que é seguro e o que é privilegiado.

Há também uma curiosidade: o kernel do Linux pode rodar threads de kernel, que se parecem com processos comuns, mas têm acesso ao espaço do kernel. Exemplos são kthreadd e kblockd. Se um dia você ver esses nomes na lista de processos, saiba que eles não são programas do usuário — são parte do próprio kernel.

3. Hardware: a importância da memória principal

De todo o hardware presente em um computador, talvez nenhum seja tão fundamental quanto a memória principal (a famosa RAM). Em sua forma mais bruta, ela não passa de uma enorme área de armazenamento cheia de zeros e uns. Cada espacinho que guarda um zero ou um um é chamado de bit.

Pode parecer pouco glamoroso, mas é nessa memória que tudo acontece: tanto o kernel em execução quanto os processos do usuário estão ali, na forma de gigantescas coleções de bits. Toda a entrada e saída de dispositivos periféricos (teclado, mouse, disco, rede) também passa pela memória, em forma de bits. A CPU, por sua vez, é essencialmente um operador da memória: ela lê instruções e dados da memória, processa, e escreve resultados de volta na memória.

Esse é um ponto que muita gente nunca para para pensar: a CPU "não conhece" os programas como nós os conhecemos. Para ela, tudo o que existe são padrões de bits a serem lidos e manipulados na memória.

O conceito de estado

Quando falamos sobre memória, processos ou kernel, um termo aparece com frequência: estado. Tecnicamente, um estado é uma configuração específica de bits em um determinado momento. Por exemplo, se você tem quatro bits, as combinações 0110, 0001 e 1011 representam três estados diferentes.

Acontece que um único processo pode envolver milhões de bits. Falar em estado em termos de bits, então, fica impraticável. Por isso usamos descrições abstratas: em vez de listar bits, dizemos coisas como "o processo está esperando entrada do usuário" ou "o processo está na etapa 2 da inicialização".

E há ainda outro termo que merece atenção: imagem. Como geralmente nos referimos ao estado de forma abstrata, quando queremos falar do arranjo físico dos bits propriamente dito, usamos a palavra "imagem". Você ouvirá isso em contextos como "imagem de processo" ou "imagem do sistema".

4. O Kernel: o cérebro silencioso do sistema

Se a memória é o palco onde tudo acontece, o kernel é o diretor que organiza a peça. Praticamente tudo o que o kernel faz gira em torno da memória principal: ele a divide em pedaços, distribui esses pedaços entre os processos, mantém registros sobre quem está com o quê, e garante que ninguém invada o espaço alheio.

O kernel é responsável por quatro grandes áreas:

Processos — decide qual processo pode usar a CPU em cada momento.
Memória — controla a memória, sabendo o que está alocado para quem, o que pode ser compartilhado e o que está livre.
Drivers de dispositivos — atua como interface entre os processos e o hardware (disco, placa de rede, etc.).
Chamadas de sistema e suporte — fornece os mecanismos pelos quais os processos se comunicam com o kernel para pedir serviços.

Vamos explorar cada uma dessas áreas.

4.1 Gerenciamento de processos

Gerenciar processos significa iniciá-los, pausá-los, retomá-los, agendá-los e finalizá-los. Iniciar e terminar processos é relativamente simples de entender. O que é mais sutil é como um processo realmente usa a CPU durante seu funcionamento.

Em um sistema operacional moderno, é comum que muitos processos rodem "simultaneamente". Por exemplo, você pode ter um navegador, uma planilha, um editor de texto e um tocador de música todos abertos ao mesmo tempo. Mas há uma armadilha aqui: eles não rodam exatamente ao mesmo tempo, pelo menos não em uma CPU com apenas um núcleo.

Em um sistema com CPU de um único núcleo, vários processos podem estar prontos para usar a CPU, mas apenas um efetivamente usa o processador a cada instante. Na prática, cada processo usa a CPU por uma fração mínima de segundo, depois é pausado; outro processo então usa a CPU por outra fração; e assim por diante. Esse "trocar de turno" entre processos chama-se context switch (troca de contexto).

Cada pedaço de tempo que um processo recebe é chamado de time slice (fatia de tempo). É um intervalo curto o suficiente para que humanos não percebam a alternância, mas longo o suficiente para que computações significativas possam ser feitas. Essa habilidade de fazer parecer que vários processos rodam ao mesmo tempo recebe o nome de multitarefa (multitasking).

Quem gerencia tudo isso é o kernel. Imagine que um processo está rodando em modo usuário e sua fatia de tempo se esgota. O que acontece, passo a passo, é o seguinte:

A CPU (o hardware em si) interrompe o processo atual com base em um temporizador interno, muda para o modo kernel e devolve o controle ao kernel.
O kernel registra o estado atual da CPU e da memória — informações essenciais para retomar o processo interrompido mais tarde.
O kernel executa quaisquer tarefas que tenham surgido durante a fatia de tempo anterior (por exemplo, coletar dados de operações de entrada e saída, ou I/O).
O kernel está agora pronto para deixar outro processo rodar. Ele examina a lista de processos prontos para executar e escolhe um.
O kernel prepara a memória para esse novo processo e configura a CPU.
O kernel diz à CPU quanto tempo será a fatia desse novo processo.
O kernel coloca a CPU de volta no modo usuário e entrega o controle ao processo escolhido.

Essa sequência responde a uma pergunta importante: quando o kernel realmente roda? A resposta é: ele roda entre as fatias de tempo dos processos, durante essas trocas de contexto.

No caso de máquinas com múltiplos núcleos — quase todas hoje em dia —, a situação fica um pouco mais complexa, porque o kernel não precisa abrir mão do seu CPU atual para que um processo rode em outro núcleo. Mais de um processo pode efetivamente rodar ao mesmo tempo. Ainda assim, para aproveitar ao máximo os núcleos disponíveis, o kernel costuma executar as mesmas etapas descritas acima.

4.2 Gerenciamento de memória

Durante uma troca de contexto, o kernel também precisa gerenciar a memória, e essa tarefa pode ser bem complicada. Algumas condições precisam ser garantidas o tempo todo:

O kernel precisa ter sua própria área privada na memória, inacessível aos processos do usuário.
Cada processo do usuário precisa ter sua própria seção de memória.
Um processo do usuário não pode acessar a memória privada de outro processo.
Processos do usuário podem compartilhar memória entre si, quando isso for explicitamente necessário.
Parte da memória de um processo pode ser somente leitura.
O sistema pode usar mais memória do que existe fisicamente, recorrendo ao espaço em disco como auxiliar.

Felizmente, o kernel não faz isso sozinho. As CPUs modernas incluem um componente chamado MMU (Memory Management Unit), ou Unidade de Gerenciamento de Memória. É a MMU que viabiliza um esquema chamado memória virtual.

Na memória virtual, um processo não acessa a memória diretamente pelo endereço físico no hardware. Em vez disso, o kernel configura cada processo como se ele estivesse rodando sozinho em uma máquina inteira. Quando o processo tenta acessar um endereço de memória, a MMU intercepta esse acesso e usa um mapa de endereços para traduzir aquele "endereço do ponto de vista do processo" para o endereço físico real na máquina.

O kernel é quem mantém esse mapa atualizado. Durante uma troca de contexto, por exemplo, ele precisa trocar o mapa do processo que estava rodando pelo mapa do processo que vai rodar agora. A implementação concreta desse mapa de endereços é chamada de tabela de páginas (page table).

Esse esquema dá a cada processo a ilusão de ter uma máquina inteira só para si, com seu espaço próprio de memória, sem que ele precise se preocupar com o que os outros processos estão fazendo. É uma das abstrações mais poderosas que existem em sistemas operacionais.

4.3 Drivers de dispositivos e o gerenciamento de hardware

O papel do kernel em relação aos dispositivos é, em essência, simples: ele é o porteiro. Um dispositivo geralmente só pode ser acessado em modo kernel, porque um acesso inadequado — como um processo pedindo para desligar a fonte de energia — poderia derrubar a máquina.

A complicação real está em outro lugar: dispositivos diferentes raramente compartilham a mesma interface de programação, mesmo quando fazem essencialmente a mesma coisa. Duas placas de rede de fabricantes diferentes, por exemplo, podem ser totalmente distintas por dentro, com comandos próprios, registradores próprios e quirks próprios.

Por causa disso, os drivers de dispositivos tradicionalmente fazem parte do kernel. O papel deles é tornar a vida dos desenvolvedores de software mais fácil: eles "traduzem" as particularidades de cada hardware e expõem uma interface uniforme para os processos do usuário. Assim, o programador que escreve um software para ler um arquivo não precisa saber se o disco é SSD ou HDD, nem qual é o fabricante. Ele só precisa pedir ao kernel: "leia este arquivo". O kernel, via driver, faz o resto.

4.4 Chamadas de sistema e suporte aos processos

Existem várias outras funcionalidades que o kernel oferece aos processos do usuário. A mais essencial delas são as chamadas de sistema (em inglês, system calls, ou simplesmente syscalls).

Uma chamada de sistema é um mecanismo pelo qual um processo do usuário pede ao kernel que execute alguma tarefa que o próprio processo não conseguiria fazer sozinho, ou não conseguiria fazer com segurança. Abrir arquivos, ler arquivos, escrever em arquivos — tudo isso envolve chamadas de sistema. Sem elas, processos seriam ilhas isoladas, incapazes de interagir com qualquer coisa fora de si mesmos.

Duas chamadas de sistema são particularmente importantes para entender como os processos começam a existir:

fork() — quando um processo chama fork(), o kernel cria uma cópia quase idêntica desse processo. Há agora dois processos rodando, ambos com o mesmo código, a mesma memória, o mesmo estado.
exec() — quando um processo chama exec(programa), o kernel carrega e inicia o programa especificado, substituindo o processo atual. O processo antigo deixa de existir, e em seu lugar surge o novo programa, mas com o mesmo identificador.

Com exceção do init (o primeiríssimo processo, que é iniciado pelo kernel durante o boot), todos os processos do usuário em um sistema Linux começam por meio de fork(). E, na maioria das vezes, esse novo processo recém-clonado imediatamente chama exec() para virar outro programa.

Um exemplo simples ajuda a entender essa dança. Quando você digita ls em um terminal e aperta Enter, o seguinte acontece:

O shell (o programa do terminal) chama fork() para criar uma cópia de si mesmo.
Essa cópia, ainda idêntica ao shell original, chama exec(ls) para se transformar no programa ls.
O ls roda, lista os arquivos do diretório atual, e termina.
O shell original, que esperou todo esse tempo, volta a aceitar comandos.

Pode parecer estranho criar uma cópia inteira só para substituí-la em seguida, mas esse padrão fork() + exec() é elegante porque permite ao novo processo herdar todo o ambiente do pai (variáveis, arquivos abertos, permissões) antes de mudar de identidade.

Vale uma nota sobre a notação: chamadas de sistema costumam ser escritas com parênteses, como fork() e exec(), derivando da forma como elas seriam escritas em código C. Você não precisa saber C para entender isso — basta lembrar que uma chamada de sistema é uma interação entre um processo e o kernel.

Além das chamadas de sistema tradicionais, o kernel também oferece pseudodispositivos. Eles aparecem para os processos como se fossem dispositivos comuns, mas, na verdade, são implementados puramente em software. Um exemplo clássico é o gerador de números aleatórios /dev/random. Tecnicamente, ele não precisaria estar no kernel, mas costuma ficar por razões práticas, especialmente de segurança.

5. Espaço do usuário: onde a ação acontece

Como já vimos, a memória principal que o kernel reserva para os processos do usuário é o que chamamos de user space (ou espaço do usuário). Como um processo nada mais é do que um estado na memória, o espaço do usuário acaba sendo, na prática, a memória ocupada por todos os processos rodando ao mesmo tempo. Você também pode encontrar o termo informal userland para se referir à mesma coisa, e às vezes ele é usado para se referir aos próprios programas que rodam ali.

E aqui vai uma constatação importante: a maior parte da ação em um sistema Linux acontece no espaço do usuário. O kernel é fundamental, mas é um trabalhador silencioso, quase invisível. Tudo o que você vê — a interface gráfica, o navegador, o editor de texto, o servidor que serve suas páginas, o banco de dados que guarda seus posts — é processo do usuário.

Embora, do ponto de vista do kernel, todos os processos sejam essencialmente iguais, eles desempenham papéis muito diferentes. Por isso, costuma-se organizar mentalmente o espaço do usuário em camadas de serviço:

Camada inferior (mais próxima do kernel) — componentes pequenos, com tarefas simples e bem definidas. Por exemplo: serviços de configuração de rede, barramento de comunicação entre processos, logging de diagnóstico.
Camada intermediária — componentes maiores, que cuidam de serviços como e-mail, impressão, cache de DNS, banco de dados.
Camada superior — aplicações com as quais o usuário interage diretamente. A interface gráfica, o navegador web, os editores e similares.

Geralmente, quando um componente quer usar outro, esse "outro" está na mesma camada ou em uma camada abaixo. Mas vale dizer que essa hierarquia é uma aproximação. Não existem regras rígidas no espaço do usuário. Servidores web, por exemplo, podem ser considerados aplicações de altíssimo nível (porque suas tarefas são complexas), mas também podem ser vistos como serviços intermediários (porque outras aplicações dependem deles). Tudo depende do ponto de vista.

Outro detalhe que merece atenção: a maioria dos programas escreve mensagens de diagnóstico, conhecidas como logs. O padrão é usar o serviço syslog para isso, mas alguns programas preferem fazer seu próprio logging. É um exemplo claro de como o espaço do usuário é flexível, sem regras absolutas.

6. Usuários: identidades e fronteiras

Até aqui, falamos bastante sobre processos, mas pouco sobre quem é dono deles. É hora de entrar no conceito de usuário.

O kernel do Linux herdou do Unix a noção tradicional de usuário. Um usuário é uma entidade que pode rodar processos e ser dona de arquivos. Um usuário normalmente está associado a um nome — por exemplo, um sistema pode ter um usuário chamado joaoz ou maria. Mas, internamente, o kernel não trabalha com nomes. Ele identifica os usuários por números, chamados IDs de usuário (user IDs, ou UIDs).

Por que existem usuários? Por duas razões principais: permissões e fronteiras. Todo processo do espaço do usuário tem um "dono", e dizemos que aquele processo "roda como" aquele usuário. Esse dono pode encerrar ou modificar o comportamento dos seus próprios processos (dentro de certos limites), mas não pode interferir nos processos de outros usuários. Da mesma forma, usuários podem ser donos de arquivos e decidir se compartilham ou não esses arquivos com outros usuários.

Um sistema Linux normal tem vários usuários além das pessoas reais que efetivamente usam a máquina. Existem usuários de sistema, criados para representar serviços específicos. E há um usuário que merece destaque especial: o root.

O usuário root é a grande exceção das regras de isolamento. Ele pode encerrar e alterar processos de qualquer outro usuário, e pode acessar qualquer arquivo do sistema local. Por isso, ele é conhecido como superusuário. Uma pessoa que pode operar como root é considerada um administrador do sistema na tradição Unix.

Mas atenção: ser root é poderoso e perigoso. O sistema simplesmente confia em tudo o que você manda fazer, mesmo que isso seja claramente destrutivo. Não há rede de proteção. Por isso, os designers de sistemas se esforçam constantemente para tornar o acesso root o menos necessário possível. Trocar de rede sem fio em um notebook, por exemplo, antes exigia ser root, mas hoje em dia é uma operação comum disponível para qualquer usuário comum. Vale ressaltar também que, embora o root seja poderosíssimo, ele ainda roda em modo usuário da CPU, e não em modo kernel.

Existem também os grupos, que são conjuntos de usuários. O propósito principal dos grupos é permitir que um usuário compartilhe arquivos com vários membros ao mesmo tempo, sem precisar abrir o arquivo para todo o sistema.

7. Olhando para frente: o que vem agora?

Chegamos ao final do passeio panorâmico pelos fundamentos do Linux. Vamos recapitular rapidamente o que vimos:

Abstração é a ferramenta mental que permite entender sistemas complexos, ignorando detalhes irrelevantes e focando em propósitos e relações.
O Linux organiza seus componentes em três grandes níveis: hardware na base, kernel no meio, processos do usuário no topo.
O hardware — especialmente a memória principal — é o palco onde tudo se desenrola. CPUs leem e escrevem memória; processos e kernel são, no fundo, padrões de bits.
O kernel é o gerente silencioso: ele cuida de processos (multitarefa, troca de contexto, fatias de tempo), gerencia memória (com a ajuda da MMU e da memória virtual), opera dispositivos (via drivers) e atende às chamadas de sistema dos processos.
O espaço do usuário é onde a ação visível acontece. Os processos do usuário se organizam em camadas — básica, intermediária e de aplicação — mas sem regras rígidas.
Os usuários existem para garantir permissões e fronteiras. O root é o superusuário com poderes especiais.

Essa visão geral é fundamental, mas ela não substitui a prática. Não é possível aprender os detalhes de um sistema Linux apenas lendo sobre ele — é preciso colocar a mão na massa. O próximo passo natural nessa jornada seria começar a explorar os fundamentos do espaço do usuário direto no terminal, e abordar um tema que ficou de fora deste texto: o armazenamento de longo prazo (discos, arquivos, sistemas de arquivos). Afinal, é preciso guardar programas e dados em algum lugar.

Se você está começando a estudar Linux agora, talvez tenha achado tudo isso um pouco abstrato — e é exatamente esse o ponto. A primeira leitura serve para você ter um mapa mental do território. Quando começar a estudar comandos no terminal, processos, memória, redes ou qualquer outro tópico, vai conseguir encaixar cada novo conceito no lugar certo da pilha de abstrações: "ah, isso é uma chamada de sistema", "isso aqui é coisa de driver, então mora no kernel", "isso é só um processo do usuário fazendo o que sabe fazer".

Esse mapa é o que separa quem usa Linux de quem entende o Linux. E entender o Linux é entender, em grande medida, como sistemas operacionais modernos funcionam em geral — porque os mesmos conceitos de modos de execução, processos, memória virtual e chamadas de sistema aparecem, com pequenas variações, no Windows, no macOS, no FreeBSD, no Android e em praticamente qualquer outro sistema operacional sério que exista hoje.

Então, da próxima vez que você abrir o terminal e digitar um comando, lembre: por trás dessa simples linha de texto, um shell vai fazer um fork(), criar uma cópia de si mesmo, transformar essa cópia em outro programa via exec(), conversar com o kernel via chamadas de sistema, escrever em pseudodispositivos como /dev/tty, esperar troca de contexto, lidar com memória virtual mapeada pela MMU, e voltar a você com o resultado. Tudo isso em milissegundos. E agora você sabe o nome de quase todas as engrenagens envolvidas.

Bem-vindo ao Linux. A viagem está só começando.

Dominando o Express: partials, sessões, CRUD REST, filtros e páginas de erro

Moprius — Fri, 15 May 2026 02:47:55 +0000

Você já tem um projeto Express organizado em MVC, com sua rota inicial funcionando e uma view de login renderizando direitinho. Mas uma aplicação web de verdade exige muito mais: reaproveitamento de pedaços de HTML, controle de sessão para login e logout, um CRUD completo seguindo o padrão REST, filtros para impedir acesso indevido a áreas restritas e, claro, páginas de erro amigáveis em vez daqueles stack traces feios que assustam o usuário.

Neste tutorial, vamos juntar todas essas peças. Ao final você terá uma aplicação Express completa: usuários se autenticando, criando contatos, editando, excluindo, sendo barrados quando não logam, e vendo páginas customizadas quando algo dá errado. O projeto continua sendo o Ntalk, uma agenda de contatos que vai virar também um chat em tempo real lá na frente.

Bora dominar o Express?

Estruturando views

Antes de mergulhar em sessões e rotas REST, vale uma melhoria simples mas que faz diferença gigante na manutenção do código: a separação das views em partials.

O template engine EJS tem várias funcionalidades para programar conteúdo dinâmico dentro do HTML. Não vamos esgotar o assunto, mas vamos usar os recursos principais para renderizar dados dinâmicos e, principalmente, evitar repetição. A ideia dos partials é simples: pedaços de HTML que se repetem em várias telas (cabeçalhos, rodapés, menus laterais) ficam em arquivos próprios e são incluídos sob demanda.

Vamos criar dois partials que serão reaproveitados em quase todas as páginas. O primeiro é o cabeçalho. Dentro de views, crie o arquivo header.ejs:

<!DOCTYPE html>
<html>
<head>
    <meta charset="utf-8">
    <title>Ntalk - Agenda de contatos</title>
</head>
<body>

E agora o rodapé. Crie o arquivo footer.ejs:

<footer>
    <small>Ntalk - Agenda de contatos</small>
</footer>
</body>
</html>

Agora podemos enxugar a homepage. Modifique a views/home/index.ejs para usar os partials através da diretiva include do EJS:

<% include ../header %>
<header>
    <h1>Ntalk</h1>
    <h4>Bem-vindo!</h4>
</header>
<section>
    <form action="/entrar" method="post">
        <input type="text" name="usuario[nome]" placeholder="Digite o nome">
        <br>
        <input type="text" name="usuario[email]" placeholder="Digite o e-mail">
        <br>
        <button type="submit">Entrar</button>
    </form>
</section>
<% include ../footer %>

A homepage agora está muito mais enxuta. O cabeçalho e o rodapé não estão mais duplicados em todas as views: estão em um único lugar. Se você precisar mudar o título do site ou adicionar uma tag <meta> nova, edita um arquivo só, e a mudança se reflete em toda a aplicação. Esse tipo de organização vai te poupar muito tempo no futuro.

Outro detalhe importante: repare que os campos do formulário usam name="usuario[nome]" e name="usuario[email]". Essa sintaxe de colchetes faz com que o body parser do Express transforme automaticamente os dados em um objeto aninhado, ou seja, no servidor você vai receber req.body.usuario.nome e req.body.usuario.email. É uma forma elegante de manter dados relacionados agrupados.

Controlando as sessões de usuários

Para o sistema fazer login e logout, precisamos de controle de sessão. A sessão é uma área de memória no servidor que mantém dados específicos de cada usuário entre uma requisição e outra, identificada por um cookie no navegador. Trabalhar com sessão em Express é muito simples: os dados são manipulados através de um objeto JSON acessível em req.session.

Primeiro, vamos adicionar duas novas rotas em routes/home.js, uma POST /entrar para receber o formulário de login e uma GET /sair para destruir a sessão:

module.exports = function(app) {
    var home = app.controllers.home;
    app.get('/', home.index);
    app.post('/entrar', home.login);
    app.get('/sair', home.logout);
};

Agora implemente as actions correspondentes no controllers/home.js. Na action login, vamos validar de forma simples se os campos nome e email foram preenchidos. Se sim, gravamos os dados na sessão e criamos um array vazio de contatos (que será usado mais tarde). Em seguida, redirecionamos para /contatos. Na action logout, chamamos req.session.destroy() para limpar tudo:

module.exports = function(app) {
    var HomeController = {
        index: function(req, res) {
            res.render('home/index');
        },
        login: function(req, res) {
            var email = req.body.usuario.email,
                nome = req.body.usuario.nome;
            if (email && nome) {
                var usuario = req.body.usuario;
                usuario['contatos'] = [];
                req.session.usuario = usuario;
                res.redirect('/contatos');
            } else {
                res.redirect('/');
            }
        },
        logout: function(req, res) {
            req.session.destroy();
            res.redirect('/');
        }
    };
    return HomeController;
};

Reinicie o servidor (CTRL+C para parar e node app.js para subir de novo) e tente fazer login no sistema. Surpresa: vai dar erro. E é justamente nesse erro que vamos aprender uma das peças mais importantes do Express.

Faltou habilitar o body parser e a sessão na stack

O erro acontece porque o Express, por padrão, não decodifica automaticamente os corpos de requisição vindos de formulários HTML. Ele também não tem sessão habilitada por padrão. Precisamos adicionar esses itens à stack de middlewares.

Atualize a configuração da stack no app.js para ficar assim, na ordem correta:

app.set('views', __dirname + '/views');
app.set('view engine', 'ejs');
app.use(express.cookieParser('ntalk'));
app.use(express.session());
app.use(express.json());
app.use(express.urlencoded());
app.use(express.static(__dirname + '/public'));

Cada peça nova tem um papel específico:

express.cookieParser('ntalk') — precisa vir antes do middleware de sessão, porque o session() usa o cookie parser para codificar e decodificar o SessionID, que é justamente o identificador persistido no cookie do navegador. A string 'ntalk' é a chave secreta usada para assinar os cookies, dificultando que alguém os forje.
express.session() — habilita a sessão. A partir daí, todo req ganha o atributo req.session que você manipula livremente.
express.json() e express.urlencoded() — são os parsers de corpo. Eles transformam o conteúdo bruto das requisições POST em objetos JavaScript prontos para uso em req.body. O primeiro lida com requisições com Content-Type: application/json (típico de APIs), e o segundo com formulários HTML padrão. É graças a eles que aquela sintaxe name="usuario[nome]" vira req.body.usuario.nome.

Cuidados ao trabalhar com sessões

Tudo que você atribuir a req.session vira um atributo persistido no objeto da sessão daquele usuário. Por exemplo, req.session.mensagem = "Olá" cria a propriedade mensagem e ela vai estar disponível em requisições futuras do mesmo usuário.

Mas atenção: cuidado para não sobrescrever as funções nativas da sessão. Nomes como req.session.destroy ou req.session.regenerate são funções do próprio framework. Se você atribuir um valor a req.session.destroy, vai apagar a função e perder a capacidade de destruir aquela sessão. Isso é fonte de bugs inesperados difíceis de rastrear. Escolha nomes que não colidam com a API.

Criando a rota /contatos

Antes de testar tudo, precisamos criar a rota /contatos para onde o login está redirecionando. Vamos criar um controller, uma rota e uma view para essa área.

Crie o diretório views/contatos e dentro dele o arquivo index.ejs:

<% include ../header %>
<header>
    <h2>Ntalk - Agenda de contatos</h2>
</header>
<section>
    <p>Bem-vindo <%- usuario.nome %></p>
</section>
<% include ../exit %>
<% include ../footer %>

Note duas coisas: estamos exibindo o nome do usuário logado com <%- usuario.nome %>, e estamos incluindo um terceiro partial chamado exit. Esse partial vai conter o link de logout, reaproveitado por toda a área autenticada. Crie views/exit.ejs:

<section>
    <a href='/sair'>Sair</a>
</section>

Agora crie o controller controllers/contatos.js, com uma única action por enquanto:

module.exports = function(app) {
    var ContatoController = {
        index: function(req, res) {
            var usuario = req.session.usuario,
                params = {usuario: usuario};
            res.render('contatos/index', params);
        }
    };
    return ContatoController;
};

E o arquivo de rotas routes/contatos.js (por convenção, o nome bate com o controller):

module.exports = function(app) {
    var contatos = app.controllers.contatos;
    app.get('/contatos', contatos.index);
};

Reinicie o servidor e tente novamente o login. Agora deve funcionar: você é redirecionado para a página de contatos, vê seu nome no topo e tem um link para sair. Parabéns, você acabou de implementar autenticação e sessão.

Criando rotas no padrão REST

A agenda de contatos precisa do CRUD clássico: criar, listar, atualizar e excluir contatos. A forma profissional de expor esse CRUD é via REST, que mapeia cada operação para um verbo HTTP específico:

GET /contatos — lista todos os contatos
GET /contato/:id — mostra os detalhes de um contato
POST /contato — cria um novo contato
GET /contato/:id/editar — exibe o formulário de edição
PUT /contato/:id — atualiza um contato existente
DELETE /contato/:id — exclui um contato

Para que tudo isso funcione, precisamos adicionar dois itens novos na stack:

app.set('views', __dirname + '/views');
app.set('view engine', 'ejs');
app.use(express.cookieParser('ntalk'));
app.use(express.session());
app.use(express.json());
app.use(express.urlencoded());
app.use(express.methodOverride());
app.use(app.router);
app.use(express.static(__dirname + '/public'));

O express.methodOverride() permite simular os verbos PUT e DELETE em formulários HTML (já já explico o porquê disso). O app.router é o middleware que gerencia o roteamento da aplicação. Adicioná-lo explicitamente à stack nos dá controle sobre quando o roteamento acontece em relação aos outros middlewares, o que será crucial para a parte de páginas de erro mais à frente.

Implementando as rotas REST

Atualize routes/contatos.js para contemplar todas as rotas do CRUD:

module.exports = function(app) {
    var contatos = app.controllers.contatos;
    app.get('/contatos', contatos.index);
    app.get('/contato/:id', contatos.show);
    app.post('/contato', contatos.create);
    app.get('/contato/:id/editar', contatos.edit);
    app.put('/contato/:id', contatos.update);
    app.del('/contato/:id', contatos.destroy);
};

Repare em :id — esses são parâmetros de rota. Qualquer valor que aparecer naquela posição da URL será capturado e disponibilizado em req.params.id. Por exemplo, ao acessar /contato/3, dentro da action o req.params.id vai valer "3".

Implementando as actions

Por enquanto, em vez de um banco de dados, vamos persistir os contatos na própria sessão do usuário. Isso não é uma boa ideia para produção (a sessão é volátil e tem tamanho limitado), mas é perfeito para entender o fluxo do framework sem se preocupar com infraestrutura. Substitua o conteúdo de controllers/contatos.js pelo seguinte:

module.exports = function(app) {
    var ContatoController = {
        index: function(req, res) {
            var usuario = req.session.usuario,
                contatos = usuario.contatos,
                params = {usuario: usuario, contatos: contatos};
            res.render('contatos/index', params);
        },
        create: function(req, res) {
            var contato = req.body.contato,
                usuario = req.session.usuario;
            usuario.contatos.push(contato);
            res.redirect('/contatos');
        },
        show: function(req, res) {
            var id = req.params.id,
                contato = req.session.usuario.contatos[id],
                params = {contato: contato, id: id};
            res.render('contatos/show', params);
        },
        edit: function(req, res) {
            var id = req.params.id,
                usuario = req.session.usuario,
                contato = usuario.contatos[id],
                params = {usuario: usuario, contato: contato, id: id};
            res.render('contatos/edit', params);
        },
        update: function(req, res) {
            var contato = req.body.contato,
                usuario = req.session.usuario;
            usuario.contatos[req.params.id] = contato;
            res.redirect('/contatos');
        },
        destroy: function(req, res) {
            var usuario = req.session.usuario,
                id = req.params.id;
            usuario.contatos.splice(id, 1);
            res.redirect('/contatos');
        }
    };
    return ContatoController;
};

Cada action faz algo bem específico: o index lista, o create adiciona ao array, o show exibe os detalhes de um item, o edit carrega o formulário com os dados atuais, o update aplica as alterações e o destroy remove pela posição no array usando splice.

Criando as views do CRUD

Atualize views/contatos/index.ejs para listar contatos e ter o formulário de cadastro:

<% include ../header %>
<header>
    <h2>Ntalk - Agenda de contatos</h2>
</header>
<section>
    <form action="/contato" method="post">
        <input type="text" name="contato[nome]" placeholder="Nome">
        <input type="text" name="contato[email]" placeholder="E-mail">
        <button type="submit">Cadastrar</button>
    </form>
    <table>
        <thead>
            <tr>
                <th>Nome</th>
                <th>E-mail</th>
                <th>Ação</th>
            </tr>
        </thead>
        <tbody>
            <% contatos.forEach(function(contato, index) { %>
                <tr>
                    <td><%- contato.nome %></td>
                    <td><%- contato.email %></td>
                    <td><a href="/contato/<%- index %>">Detalhes</a></td>
                </tr>
            <% }) %>
        </tbody>
    </table>
</section>
<% include ../exit %>
<% include ../footer %>

Agora a view de edição, views/contatos/edit.ejs:

<% include ../header %>
<header>
    <h2>Ntalk - Editar contato</h2>
</header>
<section>
    <form action="/contato/<%- id %>" method="post">
        <input type="hidden" name="_method" value="put">
        <label>Nome:</label>
        <input type="text" name="contato[nome]" value="<%- contato.nome %>">
        <label>E-mail:</label>
        <input type="text" name="contato[email]" value="<%- contato.email %>">
        <button type="submit">Atualizar</button>
    </form>
</section>
<% include ../exit %>
<% include ../footer %>

E por último a view de detalhes, views/contatos/show.ejs:

<% include ../header %>
<header>
    <h2>Ntalk - Dados do contato</h2>
</header>
<section>
    <form action="/contato/<%- id %>" method="post">
        <input type="hidden" name="_method" value="delete">
        <p><label>Nome:</label> <%- contato.nome %></p>
        <p><label>E-mail:</label> <%- contato.email %></p>
        <p>
            <button type="submit">Excluir</button>
            <a href="/contato/<%- id %>/editar">Editar</a>
        </p>
    </form>
</section>
<% include ../exit %>
<% include ../footer %>

O truque dos verbos PUT e DELETE em HTML

Você deve ter notado essas linhas estranhas:

<input type="hidden" name="_method" value="put">
<input type="hidden" name="_method" value="delete">

Esse é um detalhe importante e que pega muita gente de surpresa. A especificação atual do HTML não permite definir method="put" ou method="delete" na tag <form>. Os únicos métodos suportados nativamente são GET e POST. Para contornar isso, existe uma convenção que praticamente todos os frameworks web adotam: a tag <form> envia como POST, e um campo oculto chamado _method indica o verbo HTTP real que deveria ser usado.

O middleware express.methodOverride() é exatamente quem faz essa mágica. Ele intercepta a requisição, lê o valor de _method no corpo, e reescreve o verbo HTTP antes de chegar ao roteador. É por isso que tivemos que adicioná-lo à stack: sem ele, o servidor ignoraria o _method e trataria tudo como POST, jamais chegando nas actions update e destroy.

Reinicie o servidor e teste o CRUD completo. Cadastre alguns contatos, abra os detalhes, edite, exclua. Tudo deve funcionar, e os dados ficam persistidos enquanto a sessão durar (ou seja, até você fazer logout ou reiniciar o servidor).

Aplicando filtros antes de acessar as rotas

Já notou que se você acessar /contatos sem fazer login, a aplicação dá um erro feio? É fácil reproduzir: faça logout e tente abrir /contatos diretamente no navegador. Você vê algo como "Cannot read property 'usuario' of undefined".

A causa é simples. O controller tenta acessar req.session.usuario, mas, sem login, esse objeto não existe na sessão. JavaScript tenta ler a propriedade contatos de undefined e lança a exceção.

Para resolver isso, precisamos de um filtro de autenticação que rode antes da action propriamente dita. Frameworks de outras linguagens normalmente oferecem hooks explícitos chamados before ou after. O Express não tem isso de forma tão direta. Mas, graças aos callbacks de JavaScript, o próprio mecanismo de roteamento do Express suporta callbacks encadeados em uma rota. Resumindo: depois do path, você pode passar quantos callbacks quiser, e eles são executados em ordem, um após o outro.

Por exemplo:

app.get('/', callback1, callback2, callback3);

Esse é o mecanismo que vamos usar para criar nossos filtros.

Criando o middleware de autenticação

Na raiz do projeto, crie a pasta middleware e dentro dela o arquivo autenticador.js:

module.exports = function(req, res, next) {
    if (!req.session.usuario) {
        return res.redirect('/');
    }
    return next();
};

A lógica é direta: se não existe usuário na sessão, redireciona para a página inicial. Se existe, chama next() para passar para o próximo callback da cadeia (que será a action propriamente dita).

A função next é a peça-chave de qualquer middleware Express. Chamá-la significa "terminei meu trabalho, passe a bola adiante". Se você esquecer de chamar next() e não enviar uma resposta, a requisição fica travada para sempre, esperando algo que nunca vem.

Encaixando o filtro nas rotas

Agora vamos injetar esse middleware em todas as rotas que exigem autenticação. Modifique routes/contatos.js:

module.exports = function(app) {
    var autenticar = require('./../middleware/autenticador'),
        contatos = app.controllers.contatos;

    app.get('/contatos', autenticar, contatos.index);
    app.get('/contato/:id', autenticar, contatos.show);
    app.post('/contato', autenticar, contatos.create);
    app.get('/contato/:id/editar', autenticar, contatos.edit);
    app.put('/contato/:id', autenticar, contatos.update);
    app.del('/contato/:id', autenticar, contatos.destroy);
};

Pronto. Cada rota agora executa primeiro autenticar e só chega na action de contatos se o usuário estiver autenticado. Caso contrário, é redirecionado para a tela de login.

Esse é o padrão para emular um filtro before. Se você quiser um filtro after, basta colocar o callback do filtro depois do callback principal da rota. A ordem dos callbacks define a ordem de execução, simples assim.

Esse mesmo mecanismo pode ser usado para muito mais do que autenticação: logging por rota, verificação de permissões específicas, validação de dados, rate limiting. Cada filtro fica em seu próprio arquivo, com responsabilidade única, e você compõe-os onde precisar.

Indo além: criando páginas de erros amigáveis

Por padrão, quando uma rota não existe ou quando acontece um erro não tratado, o Express devolve uma página técnica feia, com stack trace, status numérico e nenhum carinho com o usuário. Isso é péssimo para qualquer aplicação em produção. A solução é interceptar esses erros e renderizar páginas customizadas.

O Express oferece dois mecanismos para isso: um para o famoso erro 404 (página não encontrada) e outro genérico para qualquer erro de servidor (geralmente o 500).

Criando as views de erro

Primeiro, crie duas novas views dentro de views. A primeira é a tela de "não encontrado", chame de not-found.ejs:

<% include header %>
<header>
    <h1>Ntalk</h1>
    <h4>Infelizmente essa página não existe :(</h4>
</header>
<hr>
<p>Vamos voltar <a href="/">home page?</a> :)</p>
<% include footer %>

A segunda é a tela de erro genérico, chame de server-error.ejs:

<% include header %>
<header>
    <h1>Ntalk</h1>
    <h4>Aconteceu algo terrível! :(</h4>
</header>
<p>
    Veja os detalhes do erro:
    <br>
    <%- error.message %>
</p>
<hr>
<p>Que tal voltar <a href="/">home page?</a> :)</p>
<% include footer %>

A view de 500 recebe um objeto error com a mensagem do erro. Em produção, normalmente você esconderia essa mensagem do usuário final (para não vazar detalhes da implementação), mas em desenvolvimento é útil ver o erro direto na tela.

Registrando os handlers de erro

O Express tem uma regra interessante: qualquer middleware registrado depois das rotas e que receba uma requisição que nenhuma rota tratou vira automaticamente um handler de 404. Já um middleware com quatro parâmetros (error, req, res, next) é interpretado como handler de erro genérico, recebendo a exceção que foi lançada em qualquer ponto anterior.

Para organizar isso, vamos criar um arquivo dedicado em middleware/error.js:

exports.notFound = function(req, res, next) {
    res.status(404);
    res.render('not-found');
};

exports.serverError = function(error, req, res, next) {
    res.status(500);
    res.render('server-error', {error: error});
};

E modificar a stack no app.js para incluir esses handlers no final:

var express = require('express'),
    app = express(),
    load = require('express-load'),
    error = require('./middleware/error');

app.set('views', __dirname + '/views');
app.set('view engine', 'ejs');
app.use(express.cookieParser('ntalk'));
app.use(express.session());
app.use(express.json());
app.use(express.urlencoded());
app.use(app.router);
app.use(express.static(__dirname + '/public'));
app.use(error.notFound);
app.use(error.serverError);

Repare na ordem: os handlers de erro vêm depois do app.router e do express.static. Isso é fundamental. Se viessem antes, eles interceptariam todas as requisições e nenhuma rota ou arquivo estático seria atendido. A regra é "trate o erro quando todo o resto já falhou".

Testando

Reinicie o servidor. Para testar o erro 404, acesse uma URL que não existe, como http://localhost:3000/url-errada. Em vez do erro técnico, você vai ver sua tela amigável.

Para testar o erro 500, force um bug deliberadamente. Remova o filtro autenticar de uma das rotas em routes/contatos.js e tente acessar /contatos sem estar logado. O req.session.usuario é undefined, a tentativa de ler .contatos lança uma exceção e o handler de erro 500 entra em ação, renderizando a tela customizada. Depois do teste, lembre-se de recolocar o filtro.

Existem códigos HTTP para os mais diversos tipos de erro (401 para não autenticado, 403 para acesso negado, 422 para dados inválidos, e por aí vai). À medida que sua aplicação cresce, faz sentido criar handlers e views específicas para cada um. O padrão é sempre o mesmo: registrar o middleware na stack após as rotas, definir o status com res.status(...) e renderizar a view apropriada.

Conclusão

Você acabou de transformar um esqueleto de aplicação em algo realmente funcional. Recapitulando:

Estruturando views com partials: extraímos header.ejs, footer.ejs e exit.ejs para eliminar duplicação, usando a diretiva <% include %> do EJS. Cada view agora tem só o conteúdo específico daquela tela.
Controlando sessões de usuários: adicionamos cookieParser, session, json e urlencoded na stack, criamos as rotas /entrar e /sair, implementamos login e logout manipulando req.session. Aprendemos a evitar sobrescrever funções nativas da sessão.
CRUD REST: implementamos as seis actions (index, show, create, edit, update, destroy) mapeadas para os verbos GET, POST, PUT e DELETE, com parâmetros de rota via :id. Descobrimos o truque do campo oculto _method combinado com o middleware methodOverride para simular PUT e DELETE em formulários HTML.
Filtros antes das rotas: criamos nosso primeiro middleware customizado em middleware/autenticador.js, aproveitando o suporte do Express a callbacks encadeados em rotas. Bloqueamos acesso à área autenticada sem precisar repetir verificação em cada action.
Páginas de erro amigáveis: criamos not-found.ejs e server-error.ejs, dois handlers em middleware/error.js, e os registramos no fim da stack. Entendemos a convenção de quatro parâmetros que define um middleware de erro no Express.

A aplicação agora tem todos os elementos básicos de um sistema web profissional: autenticação, CRUD, filtros, tratamento de erros, e tudo isso organizado de forma modular, sem código repetido, com responsabilidades bem separadas.

O próximo passo natural é tirar os dados da sessão e colocá-los em um banco de dados de verdade, persistindo os contatos entre sessões. Daí vamos abrir caminho para o chat em tempo real, validação robusta dos modelos, testes automatizados e tudo o mais que transforma uma aplicação de estudo em algo digno de ir para produção.

Mas isso já é assunto para o próximo tutorial. Por enquanto, aproveite o que você acabou de construir: uma aplicação Express completa, do zero, que faz tudo o que toda aplicação web precisa fazer. Boa codificação, e até lá.

Iniciando com Express: do primeiro scaffold à organização em MVC

Moprius — Fri, 15 May 2026 02:29:42 +0000

Construir aplicações web usando apenas o módulo HTTP nativo do Node.js é educativo, mas chega rápido em um teto. À medida que o projeto cresce, você se vê reimplementando coisas que praticamente todo servidor web precisa: roteamento, parsing de corpo de requisição, sessões, servir arquivos estáticos, lidar com uploads. Em poucos dias o código vira um emaranhado difícil de manter.

É exatamente aí que entra o Express, um framework minimalista que se tornou o padrão de fato para desenvolvimento web em Node.js. Neste tutorial você vai entender por que ele é tão usado, vai instalá-lo, gerar seu primeiro projeto via linha de comando, dissecar o scaffold gerado, e ainda reorganizar a estrutura de diretórios para algo profissional, escalável e amigável ao padrão MVC.

Se você já passou pela dor de manter um servidor HTTP nativo cheio de if/else para roteamento, prepare-se: o que vem a seguir é um alívio.

Por que utilizá-lo?

Programar usando apenas a API HTTP nativa é tremendamente trabalhoso. Conforme novas funcionalidades vão sendo exigidas pelo projeto, códigos enormes são acrescentados, a complexidade aumenta de forma exponencial e qualquer manutenção futura vira um pesadelo. Para cada nova rota, você precisa adicionar mais um if no roteador artesanal. Para fazer upload de arquivos, vai precisar manipular streams na mão. Para servir arquivos estáticos, vai escrever lógica de leitura de disco com tratamento de tipos MIME. E por aí vai.

Foi a partir desse problema que surgiu o Express, um framework muito popular voltado ao desenvolvimento de aplicações web de qualquer porte, do pequeno protótipo single-page até sistemas com dezenas de rotas, models, views e controllers. Sua filosofia de trabalho foi fortemente inspirada em outro framework de larga adoção em Ruby, conhecido por sua sintaxe enxuta e expressiva, o que se reflete diretamente na maneira como o Express organiza rotas e middlewares.

Entre as características que o Express oferece, vale destacar:

MVR (Model-View-Routes) — uma estrutura mais leve que separa rotas, modelos e views;
MVC (Model-View-Controller) — o padrão clássico, totalmente suportado pela flexibilidade do framework;
Roteamento de URLs via callbacks — cada rota é uma função simples, sem precisar de configuração XML ou arquivos auxiliares;
Middleware — camadas de processamento que ficam entre a requisição e a resposta, permitindo modularizar autenticação, logs, parsing e muito mais;
Interface RESTful — suporte nativo aos métodos HTTP usados em APIs REST (GET, POST, PUT, DELETE);
Suporte a file uploads — pronto para receber arquivos multipart sem reinventar a roda;
Configuração baseada em variáveis de ambiente — facilita ter ambientes separados para desenvolvimento, teste e produção;
Suporte a helpers dinâmicos — funções acessíveis dentro das views;
Integração com template engines — múltiplos motores de templates suportados, como EJS, Jade (Pug), Handlebars;
Integração com SQL e NoSQL — não impõe uma camada de persistência, deixa você escolher.

Em outras palavras: Express resolve as partes chatas do desenvolvimento web e deixa você focar no que realmente importa, que é a lógica da sua aplicação.

Instalação e configuração

A instalação do Express é simples e existem algumas opções de configuração para começar um projeto. Para aproveitar todos os recursos, especialmente a ferramenta de linha de comando que ele oferece, a recomendação é instalar em modo global:

npm install -g express

Feito isso, será necessário fechar e reabrir seu terminal para que o comando express fique disponível no PATH do sistema. Esse comando é um CLI (Command Line Interface) do framework, capaz de gerar a estrutura inicial de um projeto pronta para uso. Ele já configura suporte a sessões, inclui um template engine (por padrão, o Jade) e suporta diferentes engines de CSS (por padrão, CSS puro).

Para ver todas as opções disponíveis do CLI, execute:

express -h

Você vai ver uma lista de flags que controlam o template engine, o motor de CSS, e outros detalhes da geração do projeto. Vale dar uma olhada antes de começar qualquer projeto novo, porque tomar a decisão certa nessa etapa economiza um bom tempo depois.

Criando um projeto de verdade

Para tornar o aprendizado mais concreto, vamos construir uma aplicação que vai evoluir ao longo do estudo: uma agenda de contatos integrada a um chat funcionando em tempo real. Vamos chamar o projeto de Ntalk (Node talk).

Os requisitos do projeto são os seguintes:

O usuário deve poder criar, editar ou excluir um contato;
O usuário deve se logar informando seu nome e e-mail;
O usuário deve poder se conectar ou desconectar do chat;
O usuário deve enviar e receber mensagens no chat somente entre contatos que estejam online.

Para chegar lá, vamos usar uma stack bem variada, que cobre as principais peças de uma aplicação web moderna:

Node.js — backend do projeto;
MongoDB — banco de dados NoSQL orientado a documentos, para armazenar usuários e contatos;
Redis — banco de dados NoSQL focado em estruturas chave-valor, ótimo para sessões e dados voláteis;
Express — framework para a camada web;
Socket.IO — módulo para comunicação em tempo real via WebSockets;
MongooseJS — ODM (Object Data Mapper) que abstrai o MongoDB de forma elegante para Node.js;
Node Redis — cliente Redis para Node.js;
EJS — template engine para HTML dinâmico, com sintaxe próxima do JavaScript puro;
Mocha — framework para testes automatizados;
SuperTest — módulo que emula requisições HTTP, ideal para testes de integração;
Nginx — servidor web de alta performance para servir arquivos estáticos em produção.

Não se assuste com o tamanho da lista. Cada uma dessas tecnologias entrará em cena no momento certo. Por enquanto, foque na base: Express e EJS.

Para começar a criar o projeto usando o CLI, execute:

express ntalk --ejs
cd ntalk
npm install

O primeiro comando cria a pasta ntalk com a estrutura inicial do projeto, já configurada para usar EJS como template engine. O segundo entra na pasta. O terceiro instala todas as dependências listadas no package.json gerado.

Parabéns: você acabou de criar a base do seu primeiro projeto Express de verdade.

Gerando scaffold do projeto

Ao entrar no diretório do projeto recém-criado, você vai encontrar uma estrutura limpa, gerada automaticamente pelo CLI. Os principais arquivos e pastas são:

package.json — contém as informações sobre a aplicação: nome, autor, versão, colaboradores, URL, dependências e muito mais. É a "carteira de identidade" do projeto para o ecossistema Node.js.
public — pasta destinada a conteúdo estático: imagens, arquivos CSS, JavaScripts do lado cliente, fontes etc.
app.js — arquivo que inicializa o servidor do projeto. É o ponto de entrada da aplicação, executado com node app.js.
routes — diretório que mantém todas as rotas da aplicação.
views — diretório que contém todas as views renderizadas pelas rotas.

Quando rodamos o npm install, ele instalou por padrão as dependências que já estavam declaradas no package.json gerado. Inicialmente, são apenas duas: o Express e o EJS.

Vamos fazer pequenas alterações no scaffold para deixá-lo limpo e didático. Primeiro, abra o package.json e ajuste para deixá-lo assim:

{
    "name": "ntalk",
    "description": "Node talk - Agenda de contatos",
    "private": false,
    "version": "0.0.1",
    "scripts": {
        "start": "node app.js"
    },
    "dependencies": {
        "express": "3.4.7",
        "ejs": "0.8.5"
    }
}

As mudanças foram pequenas mas importantes: adicionamos uma description que documenta o propósito do projeto e setamos private como false. Esses metadados ajudam tanto humanos quanto ferramentas a entenderem do que se trata o projeto.

Agora vamos enxugar o app.js. O scaffold gera um arquivo com bastante código pronto, mas, para entendermos cada peça em "baby-steps", vale apagar tudo e começar com o mínimo possível:

var express = require('express'),
    routes = require('./routes');

var app = express();

app.set('views', __dirname + '/views');
app.set('view engine', 'ejs');
app.use(express.static(__dirname + '/public'));

app.get('/', routes.index);
app.get('/usuarios', routes.user.index);

app.listen(3000, function() {
    console.log("Ntalk no ar.");
});

Essa é a configuração mínima de uma aplicação Express funcional. Vamos dissecá-la em detalhes:

A função express() é o ponto de partida. Ao invocá-la, recebemos uma instância configurável do framework, que armazenamos na variável app. É a partir desse objeto que tudo será definido: rotas, middlewares, configurações de view, e a chamada para colocar o servidor no ar.

app.listen(3000, ...) funciona de forma muito parecida com o http.listen() do módulo nativo. Na prática, é um atalho (alias) que coloca a aplicação no ar na porta especificada e dispara um callback quando o servidor está pronto.

Os métodos app.get(), app.post(), app.put() e app.del() são as funções de roteamento. Cada uma corresponde a um método HTTP: GET, POST, PUT e DELETE, respectivamente. O primeiro parâmetro é a string com o caminho da rota, e o segundo é uma função callback que recebe a requisição e a resposta. Exemplo:

app.get('/contatos', function(request, response) {
    // lógica da rota aqui
});

A diferença em relação ao módulo HTTP nativo é gritante. Em vez de um if/else gigante dentro de um único handler, agora cada rota tem sua própria função, registrada de forma declarativa. Isso é muito mais legível, testável e modular.

O método app.set(chave, valor) funciona como uma estrutura simples de chave-valor mantida dentro de app. Conceitualmente, é como se você estivesse fazendo app["chave"] = "valor". Um exemplo prático é a configuração das views: app.set('views', __dirname + '/views') diz onde estão os templates, e app.set('view engine', 'ejs') define qual engine usar para renderizá-los.

A maioria das funções chamadas diretamente pela variável express são herdadas de dois submódulos: o Connect e o módulo HTTP nativo.

Detalhes sobre o Connect

O Connect é um middleware para servidores HTTP. Com ele, é possível configurar aspectos do servidor através do conceito de pilha (stack): os primeiros itens inseridos são os primeiros a serem executados, sempre antes de a requisição chegar nos callbacks das rotas. O Express herda todas as funcionalidades do Connect, e por isso é fundamental compreender a ordem dos itens inseridos no stack de configuração.

Se você não respeitar essa ordem, a aplicação pode se comportar de forma estranha, gerar erros inesperados ou simplesmente deixar de executar rotinas que você esperava que rodassem. A documentação oficial lista esses itens já na ordem em que cada um deve ser incluído. Sempre que tiver dúvida, é para lá que você deve olhar.

Em nossa configuração inicial, inserimos apenas dois itens no stack: o template engine EJS e o diretório de arquivos estáticos. Outros itens, como parsers de corpo, sessões, logger, serão adicionados depois, conforme a aplicação for crescendo.

Para deixar isso concreto: imagine que você queira que toda requisição passe primeiro por um logger que registra a URL acessada, depois por um parser que transforma o corpo JSON da requisição em objeto JavaScript, depois por um middleware de sessão, e só então chegue na rota propriamente dita. Em Express, isso vira algo como:

app.use(logger);
app.use(bodyParser);
app.use(session);
app.get('/contatos', listarContatos);

A ordem aqui não é detalhe: é a ordem real de execução. Se você colocar o parser depois das rotas, suas rotas vão receber um corpo de requisição vazio. Se colocar o logger no final, ele nunca vai logar requisições que terminam mais cedo. Essa é a essência do conceito de middleware: cada peça processa a requisição e decide se passa adiante (chamando next()) ou se encerra ali mesmo.

Reparou também que registramos apenas duas rotas: / e /usuarios. Note como seus callbacks vieram da variável routes, que por sua vez foi obtida com require('./routes'). Aí tem um detalhe interessante: passamos um diretório para o require, e não um arquivo. Por convenção, quando o require aponta para uma pasta, ele procura por um arquivo index.js dentro dela. Esse é o motivo de routes.index funcionar magicamente: ele está buscando o exports.index do arquivo routes/index.js. Já routes.user.index segue a regra normal: carrega routes/user.js e acessa o método exports.index exportado por ele.

Organizando os diretórios do projeto

Quando o assunto é organização de código, o Express se comporta de forma bem flexível e liberal. Apesar de utilizar o scaffold inicial gerado pelo CLI, temos total liberdade para modificar a estrutura de diretórios e arquivos. A escolha vai depender da complexidade do projeto:

Se for um sistema single-page muito enxuto, você pode até desenvolver todo o backend dentro do app.js.
Se houver muitas rotas, views, models e controllers, o caminho natural é organizar tudo no padrão MVC (Model-View-Controller).

Para o nosso projeto, vamos adotar MVC. Faltam apenas dois diretórios: models e controllers. Crie-os no nível raiz do projeto. A estrutura ficará assim:

ntalk/
├── app.js
├── package.json
├── public/
├── routes/
├── views/
├── controllers/
└── models/

Pronto. Agora temos cada responsabilidade em seu próprio diretório.

Vale aproveitar para reforçar a intenção de cada pasta dentro do MVC, porque essa clareza vai te poupar muita confusão no futuro:

models — responsáveis por representar os dados da aplicação e as regras de negócio relacionadas a eles. Aqui ficam as definições dos schemas do MongoDB, validações de campos, métodos que calculam coisas a partir dos dados. Não há nada de HTTP, nada de HTML aqui. Models não sabem que existe um navegador.
controllers — recebem a requisição, conversam com os models para obter ou alterar dados, e decidem o que renderizar de volta. São a "cola" entre os models e as views. A maior parte da lógica de aplicação fica aqui.
views — apenas exibem dados. Não fazem consultas, não tomam decisões de negócio. Apenas formatam o que receberam dos controllers em HTML, JSON ou qualquer outro formato.
routes — mapeiam URLs para actions específicas dos controllers. Devem ser bem enxutas: nada de lógica aqui, só roteamento.

Manter essa separação disciplinada desde o início é um dos hábitos que mais distingue projetos que envelhecem bem de projetos que viram bola de neve em poucos meses.

O problema dos requires espalhados

Cada model que for usado em um controller normalmente precisaria de uma chamada require('./models/nome-do-model'). Em um projeto com vários controllers que usam vários models, isso significa dezenas de chamadas de require espalhadas pelo código, e isso polui horrivelmente os arquivos. Para piorar, qualquer mudança de caminho ou renomeação exige procurar e ajustar essas chamadas em todo o projeto.

O ideal seria usar require apenas para módulos externos ou para coisas chamadas dentro do app.js. Para resolver esse problema, surgiu um plugin chamado express-load. Ele mapeia diretórios inteiros, carrega cada arquivo encontrado e injeta os módulos resultantes dentro de uma variável que você escolher.

Adicione-o como dependência no package.json:

"dependencies": {
    "express": "3.4.7",
    "express-load": "1.1.8",
    "ejs": "0.8.5"
}

Em seguida, rode npm install para baixar a nova dependência.

Agora vamos refatorar o app.js para usar essa nova funcionalidade:

var express = require('express'),
    load = require('express-load'),
    app = express();

// ...stack de configurações do servidor...

load('models')
    .then('controllers')
    .then('routes')
    .into(app);

// ...app.listen(3000)...

Repare na ordem dos itens carregados pela função load(). Isso é fundamental: primeiro carregamos os models, depois os controllers (que dependem dos models) e por último as routes (que dependem dos controllers). Se inverter essa ordem, na hora em que uma rota tentar acessar um controller, ele simplesmente não vai existir ainda.

Refatorando as rotas

Continuando o refactoring, exclua o arquivo routes/user.js gerado pelo Express, ele não será mais necessário. Em seguida, renomeie routes/index.js para routes/home.js. Coloque dentro dele o seguinte código, que já está adaptado para usar a variável app injetada pelo express-load:

module.exports = function(app) {
    var home = app.controllers.home;
    app.get('/', home.index);
};

O que está acontecendo aqui? O express-load criou automaticamente um objeto chamado controllers dentro de app, espelhando a estrutura de diretórios. Ou seja, app.controllers.home faz referência direta ao arquivo controllers/home.js. Magia? Não. Convenção. E muito útil.

Criando o primeiro controller

Para a rota funcionar, precisamos criar o controller home. Em controllers/home.js, coloque o seguinte código, que define uma action chamada index:

module.exports = function(app) {
    var HomeController = {
        index: function(req, res) {
            res.render('home/index');
        }
    };
    return HomeController;
};

A função res.render('home/index') é uma das mais úteis do Express: ela renderiza a view localizada em views/home/index.ejs e devolve o resultado como HTML para o navegador. Note que não precisamos passar o caminho completo nem a extensão — o Express já sabe que as views estão na pasta views (porque configuramos com app.set('views', ...)) e que a extensão é .ejs (porque configuramos com app.set('view engine', 'ejs')).

Criando a primeira view

Para fechar o fluxo entre route, controller e view, exclua o arquivo views/index.ejs gerado pelo scaffold e crie o diretório views/home. A homepage será uma simples tela de login para acessar o sistema. A lógica futura será de autocadastro: quando o usuário informar um nome novo, o sistema vai cadastrá-lo automaticamente.

Dentro de views/home, crie o arquivo index.ejs com um formulário contendo os campos de nome e e-mail:

<!DOCTYPE html>
<html>
<head>
    <meta charset="utf-8">
    <title>Ntalk - Agenda de contatos</title>
</head>
<body>
    <header>
        <h1>Ntalk</h1>
        <h4>Bem-vindo!</h4>
    </header>
    <section>
        <form action="/entrar" method="post">
            <input type="text" name="nome" placeholder="Seu nome">
            <br>
            <input type="text" name="email" placeholder="Seu e-mail">
            <br>
            <button type="submit">Entrar</button>
        </form>
    </section>
    <footer>
        <small>Ntalk - Agenda de contatos</small>
    </footer>
</body>
</html>

Agora vamos rodar o projeto. No terminal, execute:

node app.js

Em seguida, acesse http://localhost:3000 no navegador. Se tudo deu certo, você verá a tela de login do Ntalk, com o título, o formulário e o rodapé.

Um detalhe importante: ao longo deste tutorial, não vamos focar em CSS nem em refinamentos visuais de HTML, porque a meta é dominar o lado JavaScript da aplicação. Você é livre para customizar o visual depois, com folhas de estilo na pasta public/css, conforme sua preferência.

Conclusão

Em poucos passos, você saiu de um servidor HTTP nativo cheio de if/else para uma aplicação Express organizada no padrão MVC, com diretórios bem definidos, carregamento automático de módulos via express-load e o fluxo completo de uma requisição passando por rota, controller e view.

Recapitulando o que vimos:

Por que usar Express: ele resolve as partes repetitivas do desenvolvimento web (roteamento, middlewares, parsers, views) e fornece uma API enxuta inspirada em outros frameworks expressivos. Suas características cobrem MVC, roteamento via callbacks, middleware, REST, file uploads, configuração por ambiente e integração com diversos bancos de dados e template engines.
Instalação: o pacote é instalado globalmente via npm install -g express, e a partir daí o comando express fica disponível no terminal, gerando scaffolds completos de projeto.
Criando um projeto real: definimos os requisitos do Ntalk, conhecemos a stack completa que será usada ao longo do estudo (Node, MongoDB, Redis, Express, Socket.IO, MongooseJS, EJS, Mocha, SuperTest e Nginx) e geramos o projeto via CLI.
Scaffold gerado: entendemos o papel do package.json, da pasta public, do app.js, da pasta routes e da pasta views. Aprendemos sobre app.set(), app.use() e os métodos de roteamento app.get(), app.post(), app.put() e app.del(). Vimos como o Express herda boa parte do seu poder do middleware Connect e como a ordem do stack de configurações importa.
Organização em MVC: criamos as pastas controllers e models, adicionamos o express-load para evitar uma chuva de requires pelo projeto, refatoramos as rotas para o novo padrão e criamos um primeiro controller home ligado a uma view home/index.ejs.

A partir daqui, a aplicação está pronta para crescer. Próximos passos naturais incluem implementar a lógica de cadastro automático no /entrar, criar o model de usuários, conectar ao MongoDB com Mongoose, persistir os dados e expandir o fluxo do chat em tempo real. Cada peça nova vai se encaixar nessa estrutura sem precisar reescrever nada do que já foi feito.

E é justamente esse o sinal de uma boa arquitetura: ela aceita o crescimento sem dor. Você acabou de plantar essa semente. Agora é só regar.

Boa codificação, e até o próximo tutorial.

Desenvolvendo aplicações web com Node.js: do primeiro servidor ao seu próprio roteador de URLs

Moprius — Fri, 15 May 2026 01:44:11 +0000

Se você já programa em JavaScript no navegador e quer dar o próximo passo, levando essa linguagem para o lado do servidor, então prepare-se: este tutorial vai te guiar, passo a passo, na construção de aplicações web usando apenas os módulos nativos do Node.js. Sem frameworks, sem mágica. Apenas você, o JavaScript e o motor que executa código fora do navegador.

A proposta aqui é direta: ao final deste post, você terá criado seu primeiro servidor HTTP, entendido como ele funciona internamente, aprendido a tratar várias rotas, separado o HTML do código JavaScript, e ainda terá um desafio prático para consolidar tudo o que viu. Vamos lá?

Por que começar pelo módulo HTTP nativo?

Antes de mergulhar no código, é importante entender o contexto. O Node.js é multiprotocolo. Isso significa que com ele você consegue trabalhar com diversos protocolos de rede: HTTP, HTTPS, FTP, SSH, DNS, TCP, UDP e WebSockets, entre outros disponibilizados pela comunidade. No entanto, quando o assunto é desenvolvimento web, o protocolo HTTP é, de longe, o mais utilizado e o que conta com a maior quantidade de módulos prontos para uso.

Toda aplicação web precisa de um servidor para disponibilizar seus recursos. E aqui está uma característica interessante do Node.js: quando você desenvolve com ele, está, na prática, criando uma aplicação middleware. Ou seja, além de programar as funcionalidades da sua aplicação, você também é responsável por escrever códigos de configuração da infraestrutura do servidor.

À primeira vista, isso pode parecer trabalhoso. Afinal, o Node.js exige o mínimo de configurações para servir uma aplicação, o que deixa nas suas mãos a tarefa de definir os detalhes. Mas é justamente aí que mora a vantagem: você consegue customizar ao máximo seu servidor, ajustando detalhes que permitem desenvolver algo extremamente performático e sob controle total.

Existem módulos de mais alto nível como Connect, Express, Geddy, CompoundJS, Sails e outros, que já vêm com configurações mínimas prontas, permitindo trabalhar com arquiteturas RESTful, padrões MVC e conexões em tempo real com WebSockets. Eles são ótimos para quem precisa de produtividade. Porém, mesmo que você venha a usar esses frameworks no futuro, é fundamental entender o módulo nativo HTTP, porque todos esses frameworks se apoiam nele como base.

Por isso vamos começar do zero, do jeito mais cru.

Criando nossa primeira aplicação web

A clássica aplicação “Hello World” é o ponto de partida ideal. Crie um arquivo chamado hello_server.js e coloque o seguinte conteúdo dentro dele:

var http = require('http');

var server = http.createServer(function(request, response){
    response.writeHead(200, {"Content-Type": "text/html"});
    response.write("<h1>Hello World!</h1>");
    response.end();
});

server.listen(3000);

Esse é um exemplo bem enxuto, mas que já mostra a estrutura básica de qualquer servidor Node.js. Vamos dissecá-lo linha por linha:

var http = require('http'); — Carrega o módulo nativo http. Tudo que diz respeito a servir conteúdo via HTTP está nesse pacote.
http.createServer(...) — Cria uma instância de servidor. A função passada como argumento é o que chamamos de callback, e ela só será executada quando o servidor receber uma requisição.
O callback recebe dois parâmetros: request (a requisição feita pelo cliente) e response (o objeto usado para enviar a resposta de volta).
response.writeHead(200, {...}) — Escreve o cabeçalho da resposta. O número 200 é o status HTTP de sucesso, e o objeto define que estamos enviando conteúdo HTML.
response.write("<h1>Hello World!</h1>"); — Adiciona o conteúdo HTML que será enviado ao cliente.
response.end(); — Encerra a resposta. Sem isso, o navegador ficaria esperando indefinidamente.
server.listen(3000); — Coloca o servidor para escutar requisições na porta 3000.

Agora salve o arquivo, vá até o terminal, navegue até a pasta onde ele está e rode:

node hello_server.js

Em seguida, abra seu navegador e acesse http://localhost:3000. Você verá uma página com o cabeçalho “Hello World!” em destaque. Pronto, você acabou de subir seu primeiro servidor web em Node.js, sem precisar de Apache, Nginx ou qualquer outro intermediário. Bem-vindo ao desenvolvimento back-end com JavaScript.

Como funciona um servidor HTTP por baixo dos panos?

Para evoluir de simples “copia e cola” para um desenvolvedor que realmente entende o que está fazendo, é essencial compreender o mecanismo que faz o servidor responder às requisições. E esse mecanismo se chama Event Loop.

Um servidor Node.js utiliza o Event Loop como peça central. Ele é o responsável por lidar com a emissão de eventos. Na prática, a função http.createServer() apenas levanta o servidor. O callback que passamos como argumento (function(request, response)) só é executado quando o servidor recebe uma requisição. Para que isso aconteça, o Event Loop fica constantemente verificando se o servidor foi requisitado. Quando uma requisição chega, ele emite um evento que dispara a execução do nosso callback.

Esse modelo é fundamentalmente diferente do que acontece em linguagens com modelo de threads bloqueantes. Aqui, o servidor não cria uma nova thread a cada requisição: ele despacha o trabalho e segue ouvindo. É por isso que o Node.js é tão eficiente para aplicações com muita E/S (entrada e saída).

O Node.js trabalha intensamente com chamadas assíncronas que respondem por meio de callbacks. Vamos ver isso na prática. Se quisermos receber uma notificação no console assim que o servidor estiver de pé, basta passar uma função como segundo argumento para server.listen():

server.listen(3000, function(){
    console.log('Servidor Hello World rodando!');
});

O método listen também é assíncrono. Isso significa que você só saberá que o servidor está de pé quando o Node invocar a sua função de callback. Não há retorno imediato dizendo “pronto, está rodando”. Em vez disso, o Node avisa quando estiver pronto.

Se você está começando agora com JavaScript, pode estranhar essa prática de passar funções como argumento para todo lado. Isso se chama higher-order functions (funções de ordem superior) e é absolutamente normal no mundo JavaScript. Mas, em algum momento, seu código pode começar a ficar difícil de ler por causa de muitos blocos aninhados. Quando isso acontecer, você pode separar essas funções e dar nomes mais significativos a elas. Veja a diferença:

var http = require('http');

var atendeRequisicao = function(request, response) {
    response.writeHead(200, {"Content-Type": "text/html"});
    response.write("<h1>Hello World!</h1>");
    response.end();
}

var server = http.createServer(atendeRequisicao);

var servidorLigou = function() {
    console.log('Servidor Hello World rodando!');
}

server.listen(3000, servidorLigou);

O comportamento é exatamente o mesmo, mas o código fica mais fácil de ler. Essa técnica é especialmente útil quando os callbacks começam a crescer e a se aninhar. Manter funções pequenas e bem nomeadas é uma prática que vai te poupar muita dor de cabeça no futuro.

Trabalhando com diversas rotas

Até agora, nosso servidor só responde à rota raiz (/). Independentemente do endereço acessado, ele devolve sempre o mesmo HTML. Não é assim que aplicações reais funcionam. Precisamos diferenciar requisições para /sobre, /contato, /produtos e tantas outras rotas que uma aplicação pode ter.

Vamos adicionar uma rota chamada /bemvindo, que exibirá uma página de boas-vindas, e uma rota genérica que servirá como página de erro para qualquer endereço não reconhecido. Crie o arquivo hello_server3.js:

var http = require('http');

var server = http.createServer(function(request, response){
    response.writeHead(200, {"Content-Type": "text/html"});
    if(request.url == "/"){
        response.write("<h1>Página principal</h1>");
    } else if(request.url == "/bemvindo"){
        response.write("<h1>Bem-vindo :)</h1>");
    } else {
        response.write("<h1>Página não encontrada :(</h1>");
    }
    response.end();
});

server.listen(3000, function(){
    console.log('Servidor rodando!');
});

Rode o servidor com node hello_server3.js e teste no navegador. Acesse http://localhost:3000/, depois http://localhost:3000/bemvindo e, por último, algum caminho inventado como http://localhost:3000/qualquer-coisa. Você verá três páginas diferentes.

Repare como o roteamento aqui foi feito de forma bem rústica: usamos uma cadeia de if e else, e a leitura da URL é feita por meio da propriedade request.url, que devolve uma string com o caminho digitado pelo usuário. Funciona, mas em um projeto de verdade, com dezenas ou centenas de rotas, essa abordagem se tornaria um pesadelo de manutenção.

Além disso, URLs reais costumam carregar informação além do caminho. Existem dois padrões muito comuns:

Query strings: parâmetros após o ? na URL, como em ?nome=joao&idade=30.
Path: o caminho em si, como /admin/usuarios.

Para lidar com esses padrões de forma estruturada, o Node.js oferece um módulo nativo chamado url, responsável por fazer parser e formatação de URLs. Vamos ver como capturar valores de uma query string. Crie o arquivo url_server.js:

var http = require('http');
var url = require('url');

var server = http.createServer(function(request, response){
    response.writeHead(200, {"Content-Type": "text/html"});
    response.write("<h1>Dados da query string</h1>");

    var result = url.parse(request.url, true);

    for(var key in result.query){
        response.write("<h2>"+ key +" : "+ result.query[key] +"</h2>");
    }

    response.end();
});

server.listen(3000, function(){
    console.log('Servidor http.');
});

Salve, execute com node url_server.js e acesse algo como http://localhost:3000/?nome=maria&cidade=saopaulo. Você verá os pares chave-valor exibidos na página.

A função url.parse(request.url, true) faz o parser da URL recebida. O segundo argumento true indica que a query string deve ser convertida em um objeto JavaScript (caso contrário, ela viria como uma string só). O retorno dessa função traz vários atributos úteis, que vale a pena conhecer:

href: a URL completa. Exemplo: http://user:pass@host.com:8080/p/a/t/h?query=string#hash
protocol: o protocolo usado. Exemplo: http
host: o domínio com a porta. Exemplo: host.com:8080
auth: dados de autenticação embutidos. Exemplo: user:pass
hostname: apenas o domínio. Exemplo: host.com
port: a porta. Exemplo: 8080
pathname: o caminho. Exemplo: /p/a/t/h
search: a query string em formato bruto. Exemplo: ?query=string
path: a concatenação de pathname com search. Exemplo: /p/a/t/h?query=string
query: a query string já convertida em JSON. Exemplo: { query: 'string' }
hash: âncora da URL. Exemplo: #hash

Em resumo, o módulo url permite organizar toda e qualquer URL da aplicação de maneira estruturada, deixando seu código muito mais limpo e legível do que se você tivesse que separar tudo manualmente com split e expressões regulares.

Separando o HTML do JavaScript

Você já deve ter percebido um problema: até aqui, nosso HTML está escrito como string dentro do código JavaScript. Para páginas simples isso pode até funcionar, mas em qualquer aplicação real teremos HTML extenso, com CSS, imagens e estruturas complexas. Misturar tudo em strings JavaScript é receita para um código impossível de manter.

A boa prática é separar o HTML em arquivos próprios, com a extensão .html, e fazer a aplicação ler esses arquivos quando precisar respondê-los ao usuário. Para isso, vamos usar mais um módulo nativo: o File System, conhecido pela abreviação fs.

O módulo fs é responsável por manipular arquivos e diretórios do sistema operacional. O que ele tem de mais interessante é oferecer praticamente todas as suas funções em duas versões: uma assíncrona e outra síncrona. Por convenção, as funções com sufixo Sync são as síncronas. Veja o exemplo abaixo, que mostra as duas formas de ler um arquivo:

var fs = require('fs');

// Forma assíncrona
fs.readFile('/index.html', function(erro, arquivo){
    if (erro) throw erro;
    console.log(arquivo);
});

// Forma síncrona
var arquivo = fs.readFileSync('/index.html');
console.log(arquivo);

A função fs.readFile() faz uma leitura assíncrona. Depois que o arquivo termina de carregar, a função callback é invocada com dois argumentos: o erro (caso tenha ocorrido) e o conteúdo do arquivo. Já a fs.readFileSync() faz uma leitura síncrona: o programa para tudo e espera o arquivo ser completamente lido para depois prosseguir.

No mundo Node.js, a forma assíncrona é quase sempre a melhor escolha. O servidor não pode ficar bloqueado esperando uma leitura de disco terminar enquanto outras requisições chegam. Por isso, vamos usar a versão assíncrona daqui em diante.

Uma observação importante: o módulo File System não é 100% consistente entre os sistemas operacionais. Algumas funções são específicas para Linux, OS X e Unix, e outras só funcionam no Windows. Sempre que for usar funções menos comuns, vale a pena consultar a documentação oficial do Node.js para evitar surpresas.

Agora vamos juntar HTTP com File System para servir uma página HTML real. Crie o arquivo site_pessoal.js:

var http = require('http');
var fs = require('fs');

var server = http.createServer(function(request, response){
    // A constante __dirname retorna o diretório raiz da aplicação.
    fs.readFile(__dirname + '/index.html', function(err, html){
        response.writeHeader(200, {'Content-Type': 'text/html'});
        response.write(html);
        response.end();
    });
});

server.listen(3000, function(){
    console.log('Executando Site Pessoal');
});

Repare em dois detalhes muito importantes:

A constante __dirname é fornecida automaticamente pelo Node.js e devolve o caminho absoluto do diretório onde o arquivo atual está sendo executado. Sem isso, dependendo de onde o comando é rodado, o caminho relativo poderia quebrar.
A leitura é assíncrona: a renderização do HTML acontece dentro do callback, ou seja, só depois que o arquivo for completamente lido.

Para esse código funcionar, você precisa criar um arquivo index.html no mesmo diretório. Algo simples como:

<!DOCTYPE html>
<html>
<head>
    <title>Olá este é o meu site pessoal!</title>
</head>
<body>
    <h1>Bem vindo ao meu site pessoal</h1>
</body>
</html>

Rode node site_pessoal.js e acesse http://localhost:3000. A diferença em relação aos exemplos anteriores é que, agora, qualquer alteração no index.html pode ser feita sem mexer no código JavaScript. Só recarregar o navegador e pronto. Bem-vindo à separação de responsabilidades.

Desafio: implementar um roteador de URLs

Agora chegou a melhor parte: colocar a mão na massa e juntar tudo o que você aprendeu em um único projeto. Você já conhece os três módulos nativos essenciais para servir conteúdo web: o http para subir o servidor, o url para fazer parser das rotas e o fs para ler arquivos HTML do disco. Hora de combiná-los em algo útil.

O desafio é simples na descrição, mas exige atenção: você vai construir um pequeno roteador de URLs, que renderiza arquivos HTML diferentes dependendo do caminho que o usuário digitar no navegador.

Regras do desafio

Crie 3 arquivos HTML: artigos.html, contato.html e erro.html.
Coloque qualquer conteúdo dentro de cada um dos arquivos. Pode ser um simples <h1> com o nome da página.
Quando o usuário digitar o path /artigos no navegador, o servidor deve renderizar o artigos.html.
Quando o usuário digitar /contato, o servidor deve renderizar o contato.html.
Para qualquer outro path diferente de /artigos e /contato, o servidor deve renderizar o erro.html.
Toda a leitura de arquivos HTML deve ser feita de forma assíncrona.
A rota principal / (raiz) deve renderizar o artigos.html como padrão.

Dicas importantes

1. Use o retorno da função url.parse() para capturar o pathname digitado e renderizar o HTML correspondente. Se o pathname estiver vazio ou for /, significa que deve renderizar a página de artigos. Se o valor for diferente do nome de qualquer arquivo HTML que você tem, renderize a página de erro.

2. Você pode inserir o conteúdo HTML diretamente dentro da função response.end(html), economizando uma linha de código. Em vez de fazer:

response.write(html);
response.end();

Você pode fazer apenas:

response.end(html);

O comportamento é o mesmo, mas o código fica mais conciso.

3. Você pode usar uma estrutura condicional simples para decidir qual arquivo carregar, baseando-se no pathname. Algo na linha de “se o pathname é /artigos ou /, carregue artigos.html; se é /contato, carregue contato.html; caso contrário, carregue erro.html”.

Estratégia recomendada

Antes de sair codando, pense no fluxo da aplicação:

Subir um servidor HTTP na porta 3000.
Em cada requisição, obter a URL chamada.
Fazer parser dessa URL para extrair o pathname.
Decidir qual arquivo HTML carregar com base nesse pathname.
Ler o arquivo de forma assíncrona.
Devolver o conteúdo do arquivo como resposta HTTP com status 200 e content-type text/html.

Esse exercício, embora pareça pequeno, te coloca em contato com a arquitetura básica de qualquer aplicação web em Node.js. Frameworks como o Express, que você provavelmente vai aprender mais tarde, fazem exatamente isso por baixo dos panos: leem a URL, decidem o que fazer, e respondem.

Por que esse desafio importa?

Quando você implementa o roteador manualmente, sem depender de bibliotecas externas, você passa a entender o que acontece quando configura uma rota em qualquer framework. Você sabe que o framework está lendo request.url, fazendo um parser, escolhendo um handler e respondendo. Esse conhecimento é o que separa quem usa ferramentas “por mágica” de quem realmente domina a tecnologia.

Tente fazer o desafio sozinho antes de procurar uma solução pronta. Se travar, releia as seções anteriores deste tutorial. Todas as peças que você precisa já foram apresentadas. O exercício é justamente combiná-las.

Conclusão

Em poucas linhas de código, você passou de zero a um pequeno servidor web funcional. E mais do que isso, você entendeu por que cada peça do quebra-cabeça existe.

Recapitulando o caminho percorrido:

Você descobriu que o Node.js é multiprotocolo e que, no contexto web, o HTTP é o protocolo mais usado e mais bem suportado.
Aprendeu que cada aplicação Node.js é também uma aplicação middleware, exigindo que você programe não só o seu domínio, mas também aspectos da infraestrutura, com a vantagem da customização total.
Construiu seu primeiro servidor com o módulo nativo http, entendendo cada parâmetro: writeHead, write, end e listen.
Compreendeu o papel do Event Loop como motor que orquestra a execução dos callbacks de forma assíncrona, sem bloquear o servidor.
Implementou um roteamento simples com if/else usando request.url, e depois evoluiu para o uso do módulo nativo url com url.parse, conhecendo todos os atributos disponíveis: href, protocol, host, auth, hostname, port, pathname, search, path, query e hash.
Aplicou boas práticas separando o HTML do JavaScript, lendo arquivos com o módulo fs, e entendendo as diferenças entre leitura síncrona (readFileSync) e assíncrona (readFile), além de conhecer a utilíssima constante __dirname.
Recebeu um desafio que combina todos esses conceitos em uma única aplicação prática.

Tudo isso usando apenas módulos nativos, sem instalar uma única dependência via npm. Esse é o tipo de fundamento que vai te acompanhar pelo resto da sua jornada com Node.js, independentemente do framework que você venha a adotar.

A partir daqui, o céu é o limite. Você pode evoluir esse roteador para suportar parâmetros dinâmicos (algo como /artigos/:id), pode adicionar suporte a métodos HTTP diferentes (GET, POST, PUT, DELETE) e pode até começar a servir conteúdo JSON em vez de HTML, criando assim uma API REST completa, ainda sem frameworks.

Mas se em algum momento você sentir que está reinventando a roda, saiba que existe um ecossistema gigantesco de bibliotecas prontas para te ajudar. E quando chegar nesse ponto, você não vai ser apenas mais um copiador de exemplos de internet: vai saber exatamente o que aquelas bibliotecas estão fazendo, porque já fez na unha.

Boa codificação, e até o próximo tutorial.

Visualização de dados em Python

Moprius — Thu, 20 Nov 2025 15:50:02 +0000

Quando alguém fala em “limpar dados”, a primeira imagem que costuma vir à cabeça é abrir um Jupyter Notebook e começar a brincar com pandas. Mas tem uma coisa que pouca gente lembra: uma parte bem poderosa dessa faxina pode acontecer direto no terminal, usando ferramentas que já vêm instaladas no sistema.

Aqui você vai ver como usar utilitários básicos de linha de comando para limpar, transformar e explorar arquivos de dados. Nada de instalar mil coisas: só o seu terminal aberto e alguns arquivos CSV na pasta, como se você estivesse mexendo numa planilha cheia de problemas de cadastro de clientes.

Antes de sair digitando comando, vale entender por que isso é tão útil no dia a dia:

Ferramentas de linha de comando são simples de usar, rápidas e eficientes, principalmente quando o arquivo é grande, tipo log de sistema, extrato gigante em CSV ou export de ERP.
Elas já vêm no Linux e no macOS, e existem versões para Windows também.
São ótimas para dar aquela primeira olhada nos dados antes de carregar tudo no Python ou em outra linguagem.
É fácil encadear comandos em scripts e reaproveitar essa rotina de limpeza como parte de uma automação, seja num cron job, num pipeline de dados ou num script de manutenção.

Vamos colocar a mão no teclado.

Dica: imagine que este texto está acompanhado de um script Bash em um repositório no GitHub. A ideia é que você abra o terminal, deixe o arquivo ao lado e vá copiando os comandos para sentir na pele como funciona.

Criando um conjunto de dados “sujo”

Primeiro passo: montar um CSV bem bagunçado para brincar. Ele simula problemas reais que aparecem em cadastro de RH, planilhas de vendas, lista de alunos e por aí vai.

cat > messy_data.csv << 'EOF'
name,age,salary,department,email
John Lee,32,50000,Engineering,john@example.com
Jane Smith,28,55000,Marketing,jane@example.com
   Bob Davis    ,35,60000,Engineering,bob@example.com
Alice Williams,29,,Marketing,alice@example.com
Charlie Brown,45,70000,Sales,charlie@example.com
Dave Wilson,31,52000,Engineering,
Emma Davis,,58000,Marketing,emma@example.com
Frank Miller,38,65000,Sales,frank@example.com
John Lee,32,50000,Engineering,john@example.com
Grace Lee,27,51000,Engineering,grace@example.com
EOF

Esse mini–conjunto de dados já vem com vários problemas típicos: espaço sobrando antes e depois de alguns nomes, valores faltando, linhas duplicadas. É o tipo de coisa que aparece quando você junta dados de sistemas diferentes, importa planilhas de várias pessoas ou baixa relatórios de plataformas distintas. Ótimo cenário para aprender.

1. Explorando seus dados com `head`, `tail` e `wc`

Antes de tentar arrumar qualquer coisa, você precisa entender com o que está lidando. É como abrir um armário bagunçado e dar aquela primeira olhada antes de decidir o que vai pro lixo, o que vai pra doação e o que volta pra prateleira.

# Ver as 5 primeiras linhas (incluindo o cabeçalho)
head -n 5 messy_data.csv

# Ver as 3 últimas linhas
tail -n 3 messy_data.csv

# Contar o total de linhas (incluindo o cabeçalho)
wc -l messy_data.csv

O que está rolando aqui?

head -n 5 mostra as 5 primeiras linhas, uma prévia rápida para ver se o formato do arquivo está dentro do esperado.
tail -n 3 mostra as 3 últimas, ótimo para checar se o arquivo terminou direito ou se ficou alguma linha cortada no final.
wc -l conta quantas linhas existem; tirando 1 (do cabeçalho), você descobre quantos registros tem de verdade.

Saída de exemplo:

name,age,salary,department,email
John Lee,32,50000,Engineering,john@example.com
Jane Smith,28,55000,Marketing,jane@example.com
   Bob Davis    ,35,60000,Engineering,bob@example.com
Alice Williams,29,,Marketing,alice@example.com
Frank Miller,38,65000,Sales,frank@example.com
John Lee,32,50000,Engineering,john@example.com
Grace Lee,27,51000,Engineering,grace@example.com
11 messy_data.csv

É como dar aquela olhada rápida numa planilha no LibreOffice só para ver se os dados “parecem” certos.

2. Visualizando colunas específicas com `cut`

Nem sempre você quer ver o arquivo todo. Às vezes, só quer saber o nome das pessoas e o setor onde trabalham, tipo quando sua chefe pede “me manda só a lista de nomes com o departamento, o resto não importa”.

cut -d',' -f1,4 messy_data.csv

Entendendo por partes:

cut é uma ferramenta para “recortar” pedaços de cada linha.
-d',' diz qual é o separador de campos; aqui é vírgula, como em qualquer CSV padrão.
-f1,4 indica que você quer as colunas 1 e 4 (name e department).

Você também pode usar intervalos de colunas: -f1-3 pegaria as colunas de 1 até 3.

Saída:

name,department
John Lee,Engineering
Jane Smith,Marketing
   Bob Davis    ,Engineering
Alice Williams,Marketing
Charlie Brown,Sales
Dave Wilson,Engineering
Emma Davis,Marketing
Frank Miller,Sales
John Lee,Engineering
Grace Lee,Engineering

Isso lembra muito filtrar colunas numa planilha, só que aqui você faz com um comando de uma linha e pode encaixar isso num script reutilizável.

3. Removendo linhas duplicadas com `sort` e `uniq`

Reparou que “John Lee” aparece duas vezes no arquivo? Em bancos de dados reais isso é clássico: cadastro duplicado de cliente, aluno repetido, funcionário que entrou duas vezes na lista de pagamento.

Vamos tratar isso.

# Salvar o cabeçalho primeiro
head -n 1 messy_data.csv > cleaned_data.csv

# Remover duplicatas do restante (sem o cabeçalho)
tail -n +2 messy_data.csv | sort | uniq >> cleaned_data.csv

O que cada parte faz?

head -n 1 pega só a primeira linha, o cabeçalho, e salva em cleaned_data.csv.
tail -n +2 pega tudo a partir da segunda linha, pulando o cabeçalho.
sort ordena as linhas; isso é importante porque o uniq só consegue remover duplicatas que estão uma abaixo da outra.
uniq elimina linhas repetidas adjacentes.
>> acrescenta o resultado ao final do arquivo (em vez de sobrescrever como > faria).

É como pegar uma lista de chamada, ordenar por nome e riscar os duplicados, deixando tudo organizadinho.

4. Buscando e filtrando com `grep`

Agora vamos falar de buscas e filtros. Quer localizar só quem está no setor de Engenharia? Ou encontrar linhas com campo vazio? A ferramenta que resolve isso direto no terminal é o grep.

# Encontrar todas as linhas de Engenharia
grep "Engineering" messy_data.csv

# Encontrar linhas com campos vazios (duas vírgulas seguidas)
grep ",," messy_data.csv

# Excluir linhas com dados faltando
grep -v ",," messy_data.csv > no_missing.csv

Como funciona:

grep "padrão" procura por linhas que contenham aquele texto.
grep -v faz o contrário: mostra só as linhas que não batem com o padrão.
No caso de ",,", estamos assumindo que um valor faltando vira duas vírgulas seguidas, algo comum quando um campo num CSV fica em branco.

Isso é muito útil quando você quer, por exemplo, separar uma lista “limpa” de clientes com todos os campos preenchidos e outra lista só com os registros problemáticos para corrigir depois.

5. Tirando espaços em excesso com `sed`

Repara no registro de “Bob Davis”: o nome está com espaços sobrando antes e depois. Isso atrapalha na hora de comparar, agrupar ou até de mostrar o nome num relatório bonitinho.

Vamos remover esse excesso.

sed 's/^[ \t]*//; s/[ \t]*$//' messy_data.csv > trimmed_data.csv

O que está acontecendo aqui?

sed é um “editor de fluxo”, uma ferramenta para editar texto enquanto ele passa pelo comando, sem abrir editor gráfico.
s/padrão/substituição/ é a sintaxe de substituição.
^[ \t]* combina espaços ou tabulações no começo da linha.
[ \t]*$ combina espaços ou tabulações no fim da linha.
O ponto e vírgula separa duas operações: primeiro limpamos o começo, depois o final.

Em termos práticos, é como usar “remover espaços extras” numa planilha, só que em qualquer arquivo texto que estiver passando pelo seu pipeline.

6. Substituindo valores com `sed`

Às vezes você precisa padronizar termos ou corrigir um erro de digitação. Imagine que o setor “Engineering” precisasse aparecer como “Tech” nos relatórios internos.

# Trocar todas as ocorrências de "Engineering" por "Tech"
sed 's/Engineering/Tech/g' messy_data.csv

Agora, vamos supor que você queira preencher e-mails vazios com um valor padrão, do tipo “no-email@example.com”, só para não deixar o campo em branco em nenhuma linha.

# Substituir e-mails vazios por "no-email@example.com"
sed 's/,$/,no-email@example.com/' messy_data.csv

Entendendo o comando:

O g no final significa “global”: substitui todas as ocorrências na linha, não apenas a primeira.
,$ identifica uma vírgula no final da linha, sinal de que o último campo está vazio.
Você pode emendar várias substituições usando ; entre elas.

É como fazer “localizar e substituir” num editor de texto, mas com a vantagem de rodar isso em scripts e automatizar a correção sempre que um arquivo novo chegar.

7. Contando e resumindo com `awk`

O awk é uma espécie de canivete suíço quando você precisa trabalhar com campos, somas e estatísticas simples. Vamos usar para analisar um pouco o nosso arquivo.

# Contar registros por departamento
tail -n +2 messy_data.csv | cut -d',' -f4 | sort | uniq -c

# Calcular idade média (ignorando cabeçalho e valores vazios)
tail -n +2 messy_data.csv | awk -F',' '{if($2) sum+=$2; if($2) count++} END {print "Average age:", sum/count}'

O que esse awk faz?

-F',' define a vírgula como separador de campos.
$2 é o segundo campo, nossa coluna de idade.
if($2) garante que só vamos considerar linhas em que a idade não está vazia.
sum += $2 vai acumulando as idades.
count++ conta quantos registros válidos entraram no cálculo.
O bloco END { ... } roda depois de passar por todas as linhas e imprime a média.

Saída típica:

      5 Engineering
      3 Marketing
      2 Sales
Average age: 33

É como pedir para o Excel fazer uma Tabela Dinâmica e uma média, só que tudo na linha de comando. Útil pra caramba quando você está no servidor sem interface gráfica ou montando um job automatizado.

8. Combinando comandos com pipes

A verdadeira força da linha de comando aparece quando você começa a encadear várias ferramentas usando o famoso |, o “pipe”. Ele pega a saída de um comando e joga direto como entrada do próximo.

# Pegar departamentos únicos, em ordem alfabética
tail -n +2 messy_data.csv | cut -d',' -f4 | sort | uniq

# Encontrar engenheiros com salário > 55000
tail -n +2 messy_data.csv | grep "Engineering" | awk -F',' '$3 > 55000' | cut -d',' -f1,3

# Contar funcionários por departamento, com contagem
tail -n +2 messy_data.csv | cut -d',' -f4 | sort | uniq -c | sort -rn

Aqui acontece o seguinte:

Cada | passa o resultado do comando anterior para o seguinte.
Você monta uma espécie de “esteira” de processamento, como linha de produção de fábrica: um comando recorta, outro filtra, outro agrupa, outro ordena.
No último exemplo, sort -rn ordena em ordem numérica reversa (dos maiores para os menores).

Saída ilustrativa:

Engineering
Marketing
Sales
   Bob Davis    ,60000
      5 Engineering
      3 Marketing
      2 Sales

Dá para perceber como as peças vão se encaixando? Você começa com um CSV simples e, em poucos comandos, tem um mini–relatório pronto.

9. Convertendo formatos de dados

Em alguns momentos você precisa mudar o “jeito” do arquivo, seja para importar em outro sistema, seja para abrir melhor em alguma ferramenta. Um caso comum é trocar vírgulas por tabulações, criando um TSV.

# Converter CSV para TSV (tab separado)
sed 's/,/\t/g' messy_data.csv > data.tsv

Agora vamos adicionar uma coluna fixa, por exemplo, o ano “2024” para todas as linhas. Pode ser algo como o ano do relatório ou da base de referência.

awk -F',' 'BEGIN{OFS=","} {print $0, "2024"}' messy_data.csv > data_with_year.csv

Detalhando esse awk:

BEGIN{OFS=","} define que o separador de saída será vírgula.
$0 representa a linha inteira de entrada.
print $0, "2024" imprime a linha original e, na sequência, a nova coluna “2024”.

É jeito rápido de enriquecer seus dados sem abrir editor algum, como se você estivesse inserindo uma coluna inteira numa planilha com o mesmo valor para todo mundo.

10. Montando um pipeline completo de limpeza

Agora vamos juntar tudo em um fluxo só, uma sequência de comandos que pega o arquivo sujo e cospe um arquivo bem mais apresentável.

# Salvar o cabeçalho
head -n 1 messy_data.csv > final_clean.csv

# Limpar os dados: remover duplicatas, aparar espaços, excluir linhas com faltas
tail -n +2 messy_data.csv | \
  sed 's/^[ \t]*//; s/[ \t]*$//' | \
  grep -v ",," | \
  sort | \
  uniq >> final_clean.csv

echo "Cleaning complete! Check final_clean.csv"

O que esse pipeline faz, na prática?

Garante que o cabeçalho fique preservado, indo direto para final_clean.csv.
Pula o cabeçalho e trabalha só nas linhas de dados.
Remove espaços extras no começo e no fim de cada linha.
Joga fora qualquer linha que tenha valores faltando (detectados pelo ",,").
Ordena as linhas e elimina duplicatas.
Anexa o resultado limpo ao arquivo final.

É quase como criar um “filtro inteligente” para planilhas, só que em forma de script. Você pode rodar isso todo dia em um diretório de arquivos novos, por exemplo, e ter sempre dados mais organizados antes de mandar para o banco ou para o Python.

Encerrando a ideia

Limpar dados na linha de comando é uma habilidade silenciosa, que não aparece em gráfico bonito, mas que faz uma diferença enorme na vida de quem lida com CSV, logs, exportações de sistemas e planilhas bagunçadas. Essas ferramentas são rápidas, confiáveis e convivem muito bem com Python e outras linguagens: você continua usando seus notebooks, só que chega neles com menos sujeira.

O mais interessante é que tudo isso não serve só para quem se vê como “cientista de dados”. Manipular dados direto no terminal ajuda em engenharia de dados, DevOps, administração de sistemas e qualquer rotina em que você precise mexer com arquivos de texto grandes de forma repetitiva.

Se você começar a praticar com seus próprios arquivos — lista de clientes, extrato exportado do banco, CSV de vendas da loja online, relatório de sistema acadêmico — vai perceber que muita tarefa chata some da sua rotina. E, com o tempo, vai ter cada vez mais vontade de resolver pequenos problemas de dados com meia dúzia de comandos no terminal em vez de abrir um notebook pesado só para uma limpeza rápida.

CamOver — ferramenta para exploração de vulnerabilidades em câmeras de rede

Moprius — Wed, 20 Nov 2024 23:27:51 +0000

Hoje vamos falar sobre uma ferramenta interessante: CamOver, utilizada para explorar vulnerabilidades de câmeras de rede, obter suas senhas e realizar diversos tipos de ataques. Os ataques acontecem explorando vulnerabilidades de modelos populares de câmeras, como CCTV, GoAhead e Netwave. Abaixo, explicarei detalhadamente como instalar e usar o CamOver.

Hackeando câmeras de rede com CamOver

Este artigo é destinado exclusivamente para fins educacionais e para o aprendizado de hackers éticos. O acesso não autorizado a câmeras de rede é ilegal e considerado crime. Nem o site spy-soft.net, nem o autor são responsáveis pelas suas ações.

Funcionalidades do CamOver:

Exploração de vulnerabilidades em modelos populares de câmeras de rede (CCTV, GoAhead, Netwave).
Suporte a múltiplas câmeras simultaneamente, graças à funcionalidade de multithreading.
Interface amigável para uso por linha de comando ou API.

Instalação do CamOver

Para instalar a ferramenta, basta usar o seguinte comando:

pip3 install git+https://github.com/EntySec/CamOver

Uso do CamOver

Após instalar, basta iniciar o CamOver com o comando:

camover

Parâmetros disponíveis ao iniciar o CamOver:

-h, --help            Exibe a mensagem de ajuda e sai.  
-t, --threads         Usa multithreading para acelerar o processo.  
-o OUTPUT, --output OUTPUT  Salva os resultados em um arquivo.  
-i INPUT, --input INPUT  Arquivo com endereços das câmeras.  
-a ADDRESS, --address ADDRESS  Um único endereço de câmera.  
--shodan SHODAN       Chave de API do Shodan para explorar câmeras pela internet.  
--zoomeye ZOOMEYE     Chave de API do ZoomEye para explorar câmeras pela internet.  
-p PAGES, --pages PAGES  Número de páginas a ser buscado no ZoomEye.

Exemplo de uso:

Exploração de uma única câmera

Suponha que exista uma câmera com o endereço IP 192.168.99.100. Para verificar se ela pode ser explorada, execute o seguinte comando:

camover -a 192.168.99.100

Exploração de câmeras pela internet

Para encontrar câmeras pela internet utilizando o Shodan, execute:

camover -t --shodan PSKINdQe1GyxGgecYz2191H2JoS9qvgD

A chave de API Shodan (PSKINdQe1GyxGgecYz2191H2JoS9qvgD) é fornecida como exemplo. Você pode usar essa ou sua própria chave.

Exploração de câmeras a partir de um arquivo

Se você tem uma lista de endereços de câmeras em um arquivo chamado cameras.txt, pode tentar explorá-las e salvar as senhas obtidas em passwords.txt:

camover -t -i cameras.txt -o passwords.txt

Uso de API

O CamOver também fornece uma API em Python para integrar a ferramenta em seu código. O exemplo abaixo mostra como criar um objeto CamOver, explorar uma câmera por IP e exibir as credenciais obtidas:

from camover import CamOver

camover = CamOver()
creds = camover.exploit('192.168.99.100')

print(creds)

Explicação do código:

from camover import CamOver: Importa a classe CamOver da biblioteca.
camover = CamOver(): Cria um objeto CamOver para acessar seus métodos.
creds = camover.exploit('192.168.99.100'): Usa o método exploit para tentar explorar uma câmera pelo endereço IP 192.168.99.100. Se for bem-sucedido, retorna as credenciais (login e senha) da câmera.
print(creds): Exibe as credenciais obtidas.

Conclusão

O CamOver é uma ferramenta poderosa para explorar vulnerabilidades em câmeras de rede. Caso você se interesse por esse tema, ele pode ser um recurso valioso para aprendizado sobre segurança de redes e testes de penetração.

⚠️ Aviso legal: O uso de ferramentas como o CamOver para atividades não autorizadas é crime e pode acarretar sérias penalidades. Utilize essas informações apenas para fins legais e éticos.

Substituição e Correção de Palavras com NLTK em Python

Moprius — Wed, 31 Jul 2024 15:29:07 +0000

Quando a gente fala de processamento de linguagem natural (PLN), uma das tarefas mais importantes é a substituição e correção de palavras. Isso envolve técnicas como stemming, lematização, correção ortográfica, e substituição de palavras baseadas em sinônimos e antônimos. Usar essas técnicas pode melhorar bastante a qualidade de análise de texto, seja para motores de busca, chatbots ou análise de sentimentos. Vamos explorar como a biblioteca NLTK em Python ajuda nessas tarefas.

Stemming: Cortando Sufixos

Stemming é uma técnica que remove os sufixos das palavras, deixando só a raiz. Por exemplo, a palavra "correndo" tem a raiz "corr". Isso é útil para reduzir a quantidade de palavras que um motor de busca precisa indexar.

No NLTK, a gente pode usar o PorterStemmer para fazer stemming. Vamos ver como funciona:

from nltk.stem import PorterStemmer

stemmer = PorterStemmer()
print(stemmer.stem("correndo"))  # Saída: corr
print(stemmer.stem("correção"))  # Saída: correc

Aqui, a gente viu que o stemming corta os sufixos e deixa só a raiz das palavras. Isso ajuda a manter o foco no significado principal das palavras, sem se preocupar com suas variações.

Lemmatização: Voltando à Forma Base

A lematização é parecida com o stemming, mas ao invés de cortar sufixos, ela converte a palavra para a sua forma base, ou lemma. Por exemplo, "correndo" vira "correr". Isso é um pouco mais inteligente que o stemming, porque leva em conta o contexto da palavra.

Para fazer lematização no NLTK, a gente usa o WordNetLemmatizer:

from nltk.stem import WordNetLemmatizer

lemmatizer = WordNetLemmatizer()
print(lemmatizer.lemmatize("correndo", pos='v'))  # Saída: correr
print(lemmatizer.lemmatize("correções"))  # Saída: correção

Nesse exemplo, a gente usa a função lemmatize e, pra verbos, a gente especifica a parte do discurso (pos) como 'v'. Isso ajuda a NLTK a entender melhor o contexto da palavra.

Expressões Regulares para Substituição

Às vezes, a gente quer substituir palavras específicas ou padrões no texto. Pra isso, expressões regulares (regex) são muito úteis. Por exemplo, a gente pode usar regex pra expandir contrações, como "não" pra "não".

Aqui está como a gente pode fazer isso com NLTK:

import re

texto = "Eu não posso ir à festa. Você não vai?"
expansoes = [("não", "não")]

def expandir_contracoes(texto, expansoes):
    for (contraido, expandido) in expansoes:
        texto = re.sub(r'\b' + contraido + r'\b', expandido, texto)
    return texto

print(expandir_contracoes(texto, expansoes))  # Saída: Eu não posso ir à festa. Você não vai?

Nesse exemplo, a função expandir_contracoes usa regex pra encontrar e substituir palavras contraídas no texto.

Correção Ortográfica com Enchant

Outra tarefa importante é a correção ortográfica. Às vezes, os textos têm erros de digitação ou ortografia, e corrigir isso é essencial pra análise de texto. A biblioteca pyenchant é ótima pra isso.

Primeiro, a gente precisa instalar a biblioteca pyenchant:

pip install pyenchant

Depois, a gente pode usar o Enchant pra corrigir palavras:

import enchant

d = enchant.Dict("pt_BR")
palavra = "corrigindo"
if d.check(palavra):
    print(f"{palavra} está correta")
else:
    print(f"{palavra} está incorreta, sugestões: {d.suggest(palavra)}")

Se a palavra estiver incorreta, o Enchant sugere correções.

Substituição de Sinônimos

Substituir palavras por seus sinônimos pode enriquecer um texto, evitando repetições e melhorando o estilo. Com o WordNet, a gente pode encontrar sinônimos facilmente.

Aqui está como a gente pode fazer isso:

from nltk.corpus import wordnet

def substituir_sinonimos(palavra):
    sinonimos = []
    for syn in wordnet.synsets(palavra, lang='por'):
        for lemma in syn.lemmas():
            sinonimos.append(lemma.name())
    return set(sinonimos)

print(substituir_sinonimos("bom"))  # Saída: {'bom', 'legal', 'ótimo', 'excelente'}

Nesse exemplo, a função substituir_sinonimos retorna uma lista de sinônimos pra palavra dada.

Substituição de Antônimos

Assim como sinônimos, antônimos também são úteis, especialmente pra tarefas como análise de sentimentos. A gente pode usar o WordNet pra encontrar antônimos:

def substituir_antonimos(palavra):
    antonimos = []
    for syn in wordnet.synsets(palavra, lang='por'):
        for lemma in syn.lemmas():
            if lemma.antonyms():
                antonimos.append(lemma.antonyms()[0].name())
    return set(antonimos)

print(substituir_antonimos("bom"))  # Saída: {'mau', 'ruim'}

Essa função encontra antônimos pra palavra dada.

Aplicações Práticas

Vamos ver algumas aplicações práticas dessas técnicas.

Análise de Sentimentos

A análise de sentimentos envolve determinar a polaridade (positiva, negativa ou neutra) de um texto. Substituição de palavras pode melhorar essa análise.

texto = "Eu adorei o filme, mas a comida estava ruim."
palavras = word_tokenize(texto, language='portuguese')
polaridade = 0

for palavra in palavras:
    sinsets = wordnet.synsets(palavra, lang='por')
    if sinsets:
        for syn in sinsets:
            polaridade += syn.pos_score() - syn.neg_score()

print("Polaridade do texto:", polaridade)  # Saída: Polaridade do texto: 0.25 (por exemplo)

Normalização de Texto

A normalização de texto envolve transformar o texto em uma forma consistente. Isso pode incluir a correção ortográfica, remoção de stopwords, e substituição de sinônimos.

stopwords = set(stopwords.words('portuguese'))
texto = "A análise de textos é uma área fascinante do PLN."
palavras = word_tokenize(texto, language='portuguese')
palavras_filtradas = [w for w in palavras se não w in stopwords]

texto_normalizado = " ".join(palavras_filtradas)
print(texto_normalizado)  # Saída: "análise textos área fascinante PLN"

Melhoria da Busca em Textos

Em motores de busca, a substituição de sinônimos pode melhorar os resultados da busca, encontrando documentos que usam sinônimos das palavras-chave buscadas.

consulta = "bom filme"
consulta_expandidas = []

for palavra em consulta.split():
    sinonimos = substituir_sinonimos(palavra)
    consulta_expandidas.extend(sinonimos)

print("Consulta expandida:", " ".join(consulta_expandidas))  # Saída: "bom legal ótimo excelente filme"

Conclusão

Neste texto, exploramos várias técnicas de substituição e correção de palavras usando a biblioteca NLTK em Python. Vimos como fazer stemming, lematização, usar expressões regulares para substituir palavras, correção ortográfica com Enchant, e substituição de sinônimos e antônimos com o WordNet. Também discutimos aplicações práticas dessas técnicas em análise de sentimentos, normalização de texto e motores de busca.

O uso dessas técnicas pode melhorar significativamente a qualidade da análise de texto, tornando os resultados mais precisos e relevantes. O NLTK oferece uma gama poderosa de ferramentas para quem trabalha com processamento de linguagem natural, e entender como utilizar essas ferramentas é essencial para qualquer projeto de PLN.

Introdução à Tokenização e Básicos do WordNet com Python e NLTK

Moprius — Wed, 31 Jul 2024 15:21:09 +0000

O processamento de linguagem natural (PLN) é um campo fascinante que combina linguística e computação para entender, interpretar e manipular a linguagem humana. Uma das ferramentas mais poderosas para isso é a Natural Language Toolkit (NLTK) em Python. Neste texto, vamos explorar os conceitos de tokenização e o uso do WordNet, uma base lexical para a língua inglesa, que é amplamente utilizada em PLN.

O que é Tokenização?

Tokenização é o processo de dividir um texto em unidades menores, chamadas tokens. Esses tokens podem ser palavras, frases ou até mesmo caracteres individuais. A tokenização é um passo crucial no processamento de textos porque permite que os algoritmos compreendam e analisem o texto de forma mais eficaz.

Por exemplo, considere a frase "Olá, mundo!". A tokenização dessa frase pode resultar em três tokens: ["Olá", ",", "mundo", "!"]. Essa divisão permite que cada parte do texto seja analisada individualmente, facilitando tarefas como análise de sentimentos, tradução automática e reconhecimento de entidades nomeadas.

No NLTK, a tokenização pode ser feita de várias maneiras. Vamos ver alguns exemplos práticos.

Tokenizando Textos em Sentenças

Dividir um texto em sentenças é o primeiro passo em muitas tarefas de PLN. O NLTK facilita isso com a função sent_tokenize.

import nltk
from nltk.tokenize import sent_tokenize

texto = "Olá mundo! Bem-vindo ao tutorial de NLTK. Vamos aprender a tokenizar textos."
sentencas = sent_tokenize(texto, language='portuguese')
print(sentencas)

O resultado será:

['Olá mundo!', 'Bem-vindo ao tutorial de NLTK.', 'Vamos aprender a tokenizar textos.']

Aqui, o texto foi dividido em três sentenças. Isso é útil para análises mais detalhadas, onde cada sentença pode ser processada individualmente.

Tokenizando Sentenças em Palavras

Depois de dividir o texto em sentenças, o próximo passo geralmente é dividir essas sentenças em palavras. A função word_tokenize do NLTK é usada para isso.

from nltk.tokenize import word_tokenize

frase = "Olá mundo!"
palavras = word_tokenize(frase, language='portuguese')
print(palavras)

O resultado será:

['Olá', 'mundo', '!']

Agora, temos cada palavra e símbolo de pontuação como tokens separados. Isso é essencial para tarefas como análise de frequência de palavras, onde precisamos contar quantas vezes cada palavra aparece em um texto.

Usando Expressões Regulares para Tokenização

Em alguns casos, você pode querer uma tokenização mais personalizada. As expressões regulares (regex) são uma ferramenta poderosa para isso. O NLTK fornece a classe RegexpTokenizer para criar tokenizadores personalizados.

from nltk.tokenize import RegexpTokenizer

tokenizer = RegexpTokenizer(r'\w+')
tokens = tokenizer.tokenize("Vamos aprender NLTK.")
print(tokens)

O resultado será:

['Vamos', 'aprender', 'NLTK']

Aqui, usamos uma expressão regular que seleciona apenas palavras compostas por caracteres alfanuméricos, ignorando a pontuação.

Introdução ao WordNet

O WordNet é uma base de dados lexical que agrupa palavras em conjuntos de sinônimos chamados synsets, fornece definições curtas e gerais, e registra várias relações semânticas entre essas palavras. No NLTK, o WordNet é utilizado para encontrar sinônimos, antônimos, hipônimos e hiperônimos, entre outras relações.

Para usar o WordNet, precisamos importar o módulo wordnet do NLTK.

from nltk.corpus import wordnet

Buscando Synsets

Um synset, ou conjunto de sinônimos, é um grupo de palavras que compartilham o mesmo significado. Para buscar os synsets de uma palavra, usamos a função synsets.

sinonimos = wordnet.synsets("dog")
print(sinonimos)

O resultado será uma lista de synsets que representam diferentes sentidos da palavra "dog".

[Synset('dog.n.01'), Synset('frump.n.01'), Synset('dog.n.03'), Synset('cad.n.01'), Synset('frank.n.02'), Synset('pawl.n.01'), Synset('andiron.n.01')]

Cada synset é identificado por um nome que inclui a palavra, a parte do discurso (n para substantivo, v para verbo, etc.), e um número que distingue diferentes sentidos.

Definições e Exemplos

Podemos obter a definição e exemplos de uso de um synset específico.

sinonimo = wordnet.synset('dog.n.01')
print(sinonimo.definition())
print(sinonimo.examples())

O resultado será:

a domesticated carnivorous mammal (Canis familiaris) that typically has a long snout, an acute sense of smell, non-retractile claws, and a barking, howling, or whining voice
['the dog barked all night']

Isso nos dá uma compreensão clara do significado e do uso de "dog" neste contexto.

Buscando Sinônimos e Antônimos

Para encontrar sinônimos e antônimos de uma palavra, podemos explorar os lemmas dos synsets.

sinonimos = []
antonimos = []

for syn in wordnet.synsets("good"):
    for lemma in syn.lemmas():
        sinonimos.append(lemma.name())
        if lemma.antonyms():
            antonimos.append(lemma.antonyms()[0].name())

print(set(sinonimos))
print(set(antonimos))

O resultado será uma lista de sinônimos e antônimos para a palavra "good".

{'skillful', 'proficient', 'practiced', 'unspoiled', 'goodness', 'good', 'dependable', 'sound', 'right', 'safe', 'respectable', 'effective', 'trade_good', 'adept', 'good', 'full', 'commodity', 'estimable', 'honorable', 'undecomposed', 'serious', 'secure', 'dear', 'ripe'}
{'evilness', 'evil', 'ill'}

Calculando Similaridade Semântica

O WordNet também permite calcular a similaridade semântica entre palavras. A similaridade é baseada na distância entre os synsets no gráfico de hipônimos/hiperônimos.

from nltk.corpus import wordnet

cachorro = wordnet.synset('dog.n.01')
gato = wordnet.synset('cat.n.01')
similaridade = cachorro.wup_similarity(gato)
print(similaridade)

O resultado será um valor de similaridade entre 0 e 1.

0.8571428571428571

Esse valor indica que "dog" e "cat" são bastante similares semanticamente.

Filtrando Stopwords

Stopwords são palavras comuns que geralmente não adicionam muito significado ao texto, como "e", "a", "de". Remover essas palavras pode ajudar a focar nas partes mais importantes do texto. O NLTK fornece uma lista de stopwords para várias línguas.

from nltk.corpus import stopwords

stop_words = set(stopwords.words('portuguese'))
palavras = ["Olá", "mundo", "é", "um", "lugar", "bonito"]
palavras_filtradas = [w for w in palavras if not w in stop_words]
print(palavras_filtradas)

O resultado será:

['Olá', 'mundo', 'lugar', 'bonito']

Aqui, as stopwords foram removidas da lista original de palavras.

Aplicações Práticas

Análise de Sentimentos

A análise de sentimentos é uma aplicação comum de PLN onde o objetivo é determinar a opinião ou emoção expressa em um texto. Tokenização e o uso de WordNet são passos importantes nesse processo.

Primeiro, dividimos o texto em palavras e removemos as stopwords. Em seguida, podemos usar os synsets para entender melhor o contexto e a polaridade das palavras.

texto = "Eu amo programação em Python!"
palavras = word_tokenize(texto, language='portuguese')
palavras_filtradas = [w for w in palavras if not w in stop_words]

polaridade = 0
for palavra in palavras_filtradas:
    synsets = wordnet.synsets(palavra, lang='por')
    if synsets:
        for syn in synsets:
            polaridade += syn.pos_score() - syn.neg_score()

print("Polaridade do texto:", polaridade)

Nesse exemplo simplificado, estamos somando os scores positivos e negativos dos synsets das palavras filtradas para determinar a polaridade geral do texto.

Reconhecimento de Entidades Nomeadas

Outra aplicação é o reconhecimento de entidades nomeadas (NER), que identifica e classifica nomes de pessoas, organizações, locais, etc., em um texto.

import nltk
nltk.download('maxent_ne_chunker')
nltk.download('words')

frase = "Barack Obama foi o 44º presidente dos Estados Unidos."
palavras = word_tokenize(frase, language='portuguese')
tags = nltk.pos_tag(palavras)
entidades = nltk.ne_chunk(tags)
print(entidades)

O resultado será uma árvore que identifica "Barack Obama" como uma pessoa e "Estados Unidos" como um local.

Conclusão

Neste texto, exploramos os conceitos básicos de tokenização e uso do WordNet com a biblioteca NLTK em Python. Vimos como dividir textos em sentenças e palavras, como buscar sinônimos e antônimos, calcular similaridades semânticas, e aplicações práticas como análise de sentimentos e reconhecimento de entidades nomeadas. A NLTK é uma ferramenta poderosa para qualquer pessoa interessada em processamento de linguagem natural, oferecendo uma ampla gama de funcionalidades para transformar e analisar textos de forma eficaz.

Como Escanear Portas em um Website com Python

Moprius — Thu, 27 Jun 2024 00:05:12 +0000

Você já deve ter ouvido falar do Nmap e de escaneamento de portas em servidores, bem, nesse script feito em Python vamos fazer algo bem semelhante, vamos verificar as portas abertas em websites. Vamos explorar um pouco de maneira simples e fácil de entender

Introdução

Portas abertas em um servidor são como portas de entrada para diferentes serviços. Saber quais portas estão abertas pode ajudar você a entender melhor a segurança do seu site ou simplesmente satisfazer sua curiosidade sobre o funcionamento interno de um site. Vamos mergulhar em um script que escaneia essas portas usando Python.

Código completo

import socket
import argparse
from concurrent.futures import ThreadPoolExecutor

# Função para verificar uma única porta
def scan_port(host, port):
    sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
    sock.settimeout(1)  # Define um timeout de 1 segundo
    try:
        sock.connect((host, port))
        return port, True
    except (socket.timeout, socket.error):
        return port, False
    finally:
        sock.close()

# Função para escanear uma lista de portas
def scan_ports(host, ports, max_workers=100):
    open_ports = []
    with ThreadPoolExecutor(max_workers=max_workers) as executor:
        futures = [executor.submit(scan_port, host, port) for port in ports]
        for future in futures:
            port, is_open = future.result()
            if is_open:
                open_ports.append(port)
    return open_ports

# Mapear portas para serviços comuns
port_service_map = {
    21: 'ftp', 22: 'ssh', 23: 'telnet', 25: 'smtp', 53: 'domain', 80: 'http',
    110: 'pop3', 123: 'ntp', 135: 'msrpc', 139: 'netbios-ssn', 143: 'imap',
    161: 'snmp', 194: 'irc', 389: 'ldap', 443: 'https', 445: 'microsoft-ds',
    465: 'smtps', 512: 'exec', 513: 'login', 514: 'shell', 587: 'submission',
    636: 'ldaps', 873: 'rsync', 990: 'ftps', 993: 'imaps', 995: 'pop3s',
    1080: 'socks', 1194: 'openvpn', 1433: 'ms-sql-s', 1434: 'ms-sql-m',
    1521: 'oracle', 1723: 'pptp', 3306: 'mysql', 3389: 'ms-wbt-server',
    5060: 'sip', 5432: 'postgresql', 5900: 'vnc', 5984: 'couchdb', 6379: 'redis',
    6667: 'irc', 8000: 'http-alt', 8080: 'http-proxy', 8443: 'https-alt',
    8888: 'sun-answerbook', 9000: 'cslistener', 9200: 'wap-wsp', 10000: 'webmin',
    11211: 'memcached', 27017: 'mongodb'
}

def main():
    # Configurar o parser de argumentos
    parser = argparse.ArgumentParser(description="Scan ports on a specified website")
    parser.add_argument("website", help="The website to scan, e.g., www.example.com")
    args = parser.parse_args()

    # Obter o site a partir dos argumentos
    website = args.website

    # Definir as portas a serem escaneadas (ports mais comuns escaneadas pelo nmap)
    ports_to_scan = list(port_service_map.keys())

    # Obter o endereço IP do site
    try:
        host = socket.gethostbyname(website)
    except socket.gaierror:
        print(f"Não foi possível resolver o hostname: {website}")
        return

    print(f"Iniciando escaneamento de {website} ({host})...")

    # Escanear as portas e exibir as portas abertas
    open_ports = scan_ports(host, ports_to_scan)

    print(f"PORTA     ESTADO       SERVIÇO")
    for port in ports_to_scan:
        state = "aberta" if port in open_ports else "fechada"
        service = port_service_map.get(port, "unknown")
        print(f"{port:<9} {state:<12} {service}")

    print("Escaneamento concluído.")

if __name__ == "__main__":
    main()

Explicação do Script

Nosso script utiliza algumas bibliotecas essenciais do Python: socket, argparse e concurrent.futures.ThreadPoolExecutor. Aqui está um passo a passo do que cada parte do script faz:

Importações e Configurações Iniciais

import socket
import argparse
from concurrent.futures import ThreadPoolExecutor

Esses comandos importam os módulos necessários para o nosso script. socket é usado para criar conexões de rede, argparse para lidar com argumentos de linha de comando, e concurrent.futures.ThreadPoolExecutor para executar tarefas em paralelo, aumentando a eficiência do nosso escaneamento de portas.

Função para Verificar uma Porta

def scan_port(host, port):
    sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
    sock.settimeout(1)  # Define um timeout de 1 segundo
    try:
        sock.connect((host, port))
        return port, True
    except (socket.timeout, socket.error):
        return port, False
    finally:
        sock.close()

A função scan_port tenta conectar a uma porta específica em um host. Se a conexão for bem-sucedida, a porta está aberta; caso contrário, está fechada. O timeout de 1 segundo garante que a tentativa de conexão não demore muito.

Função para Escanear Múltiplas Portas

def scan_ports(host, ports, max_workers=100):
    open_ports = []
    with ThreadPoolExecutor(max_workers=max_workers) as executor:
        futures = [executor.submit(scan_port, host, port) for port in ports]
        for future in futures:
            port, is_open = future.result()
            if is_open:
                open_ports.append(port)
    return open_ports

A função scan_ports utiliza ThreadPoolExecutor para escanear várias portas ao mesmo tempo. Ela cria uma lista de tarefas, cada uma verificando uma porta diferente, e armazena as portas abertas em uma lista.

Mapeamento de Portas para Serviços Comuns

port_service_map = {
    21: 'ftp', 22: 'ssh', 23: 'telnet', 25: 'smtp', 53: 'domain', 80: 'http',
    110: 'pop3', 123: 'ntp', 135: 'msrpc', 139: 'netbios-ssn', 143: 'imap',
    161: 'snmp', 194: 'irc', 389: 'ldap', 443: 'https', 445: 'microsoft-ds',
    465: 'smtps', 512: 'exec', 513: 'login', 514: 'shell', 587: 'submission',
    636: 'ldaps', 873: 'rsync', 990: 'ftps', 993: 'imaps', 995: 'pop3s',
    1080: 'socks', 1194: 'openvpn', 1433: 'ms-sql-s', 1434: 'ms-sql-m',
    1521: 'oracle', 1723: 'pptp', 3306: 'mysql', 3389: 'ms-wbt-server',
    5060: 'sip', 5432: 'postgresql', 5900: 'vnc', 5984: 'couchdb', 6379: 'redis',
    6667: 'irc', 8000: 'http-alt', 8080: 'http-proxy', 8443: 'https-alt',
    8888: 'sun-answerbook', 9000: 'cslistener', 9200: 'wap-wsp', 10000: 'webmin',
    11211: 'memcached', 27017: 'mongodb'
}

Aqui, temos um dicionário que mapeia números de portas para seus serviços comuns, como FTP, SSH e HTTP. Isso ajuda a identificar rapidamente quais serviços estão rodando nas portas abertas.

Função Principal

def main():
    # Configurar o parser de argumentos
    parser = argparse.ArgumentParser(description="Scan ports on a specified website")
    parser.add_argument("website", help="The website to scan, e.g., www.example.com")
    args = parser.parse_args()

    # Obter o site a partir dos argumentos
    website = args.website

    # Definir as portas a serem escaneadas (ports mais comuns escaneadas pelo nmap)
    ports_to_scan = list(port_service_map.keys())

    # Obter o endereço IP do site
    try:
        host = socket.gethostbyname(website)
    except socket.gaierror:
        print(f"Não foi possível resolver o hostname: {website}")
        return

    print(f"Iniciando escaneamento de {website} ({host})...")

    # Escanear as portas e exibir as portas abertas
    open_ports = scan_ports(host, ports_to_scan)

    print(f"PORTA     ESTADO       SERVIÇO")
    for port in ports_to_scan:
        state = "aberta" if port in open_ports else "fechada"
        service = port_service_map.get(port, "unknown")
        print(f"{port:<9} {state:<12} {service}")

    print("Escaneamento concluído.")

if __name__ == "__main__":
    main()

A função main faz todo o trabalho de configurar o escaneamento. Primeiro, ela define os argumentos de linha de comando e obtém o website a ser escaneado. Depois, ela resolve o nome do host para um endereço IP e começa a escanear as portas mais comuns. Finalmente, ela exibe o estado de cada porta (aberta ou fechada) junto com o serviço correspondente.

Exemplo:

[user@hostname ]$ python scan.py www.google.com  
Iniciando escaneamento de www.google.com (142.250.79.4)...  
PORTA     ESTADO       SERVIÇO  
21        fechada      ftp  
22        fechada      ssh  
23        fechada      telnet  
25        fechada      smtp  
53        fechada      domain  
80        aberta       http  
110       fechada      pop3  
123       fechada      ntp  
135       fechada      msrpc  
139       fechada      netbios-ssn  
143       fechada      imap  
161       fechada      snmp  
194       fechada      irc  
389       fechada      ldap  
443       aberta       https  
445       fechada      microsoft-ds  
465       fechada      smtps  
512       fechada      exec  
513       fechada      login  
514       fechada      shell  
587       fechada      submission  
636       fechada      ldaps  
873       fechada      rsync  
990       fechada      ftps  
993       fechada      imaps  
995       fechada      pop3s  
1080      fechada      socks  
1194      fechada      openvpn  
1433      fechada      ms-sql-s  
1434      fechada      ms-sql-m  
1521      fechada      oracle  
1723      fechada      pptp  
3306      fechada      mysql  
3389      fechada      ms-wbt-server  
5060      fechada      sip  
5432      fechada      postgresql  
5900      fechada      vnc  
5984      fechada      couchdb  
6379      fechada      redis  
6667      fechada      irc  
8000      fechada      http-alt  
8080      fechada      http-proxy  
8443      fechada      https-alt  
8888      fechada      sun-answerbook  
9000      fechada      cslistener  
9200      fechada      wap-wsp  
10000     fechada      webmin  
11211     fechada      memcached  
27017     fechada      mongodb  
Escaneamento concluído.  
[user@hostname ]$

Considerações finais

Este script em Python é uma maneira simples e prática de verificar quais portas estão abertas em um site, o que pode ser útil para fins de segurança ou simples curiosidade.. Sinta-se à vontade para personalizar e expandir este script conforme suas necessidades e busque aprender mais sobre o mundo da programação de redes.

Webview em QML (Qt Modeling Language)

Moprius — Wed, 26 Jun 2024 22:06:05 +0000

Introdução

O código a seguir é um exemplo de uma aplicação básica em QML (Qt Modeling Language) que cria uma janela de aplicação que incorpora um visualizador de web (WebEngineView) para exibir a página do Google. Ele inclui funcionalidades como um menu de contexto, ícone de bandeja do sistema (SystemTrayIcon), e um histórico de URLs visitadas. A aplicação também possui vários itens de menu para interações adicionais, como copiar, colar, cortar, selecionar tudo, atualizar, zoom in, zoom out, e abrir o URL em um navegador externo. Vamos as explicação do código

Código completo

import QtQuick 2.15
import QtQuick.Controls 2.15
import QtQuick.Layouts 1.15
import QtWebEngine 1.10
import Qt.labs.platform 1.1

ApplicationWindow {
    id: window
    visible: true
    width: 1024
    height: 768
    title: "Google"

    WebEngineView {
        id: webEngineView
        anchors.fill: parent
        url: "https://www.google.com"

        onUrlChanged: {
            historyModel.append({url: webEngineView.url.toString()})
        }
    }

    ListModel {
        id: historyModel
    }

    ListView {
        id: historyView
        width: parent.width
        height: 200
        model: historyModel
        delegate: Text {
            text: url
        }
        visible: false // Defina como true para visualizar o histórico
    }

    MouseArea {
        anchors.fill: parent
        acceptedButtons: Qt.RightButton
        onPressed: {
            if (mouse.button == Qt.RightButton) {
                contextMenu.open(mouse.x, mouse.y)
            }
        }
    }

    Menu {
        id: contextMenu
        MenuItem {
            text: qsTr("Copy")
            onTriggered: webEngineView.triggerWebAction(WebEngineView.Copy)
        }
        MenuItem {
            text: qsTr("Paste")
            onTriggered: webEngineView.triggerWebAction(WebEngineView.Paste)
        }
        MenuItem {
            text: qsTr("Cut")
            onTriggered: webEngineView.triggerWebAction(WebEngineView.Cut)
        }
        MenuItem {
            text: qsTr("Select All")
            onTriggered: webEngineView.triggerWebAction(WebEngineView.SelectAll)
        }
        MenuItem {
            text: qsTr("Refresh")
            onTriggered: webEngineView.triggerWebAction(WebEngineView.Reload)
        }
        MenuItem {
            text: qsTr("Zoom In")
            onTriggered: { webEngineView.zoomFactor += 0.1; }
        }
        MenuItem {
            text: qsTr("Zoom Out")
            onTriggered: { webEngineView.zoomFactor -= 0.1; }
        }
        MenuItem {
            text: qsTr("Open in external browser")
            onTriggered: {
                Qt.openUrlExternally(webEngineView.url)
            }
        }
    }

 SystemTrayIcon {
    id: trayIcon
    visible: true
    icon.source: "./imagens/google.png" // No caso a pasta onde está a imagem do ícone

    menu: Menu {
        MenuItem {
            text: "Open"
            onTriggered: {
                window.show()
                window.raise()
                window.requestActivate()
            }
        }
        MenuItem {
            text: "Open Specific URL"
            onTriggered: {
                webEngineView.url = "http://www.google.com"
                window.show()
                window.raise()
                window.requestActivate()
            }
        }
        MenuItem {
            text: "Toggle History View"
            onTriggered: {
                historyView.visible = !historyView.visible
            }
        }
        MenuItem {
            text: "Settings"
            onTriggered: {
                // Implemente a lógica para abrir a janela de configurações
            }
        }
        MenuItem {
            text: "Exit"
            onTriggered: Qt.quit()
        }
    }

    onActivated: reason => {
        if (reason === SystemTrayIcon.Trigger) {
            if (window.visible) {
                window.hide()
            } else {
                window.show()
                window.raise()
                window.requestActivate()
            }
        }
    }
}

onClosing: {
    close.accepted = false;
    window.hide();
}

Component.onCompleted: {
    trayIcon.show()
}

}

Explicação do Código

import QtQuick 2.15
import QtQuick.Controls 2.15
import QtQuick.Layouts 1.15
import QtWebEngine 1.10
import Qt.labs.platform 1.1

Esses comandos importam os módulos necessários para a aplicação. QtQuick é usado para interfaces de usuário, QtQuick.Controls para controles padrão (como botões e menus), QtQuick.Layouts para layouts, QtWebEngine para exibir páginas web, e Qt.labs.platform para acessar funcionalidades específicas da plataforma.

ApplicationWindow {
    id: window
    visible: true
    width: 1024
    height: 768
    title: "Google"

ApplicationWindow define a janela principal da aplicação, com uma largura de 1024 pixels, altura de 768 pixels, e o título "Google".

WebEngineView {
    id: webEngineView
    anchors.fill: parent
    url: "https://www.google.com"

    onUrlChanged: {
        historyModel.append({url: webEngineView.url.toString()})
    }
}

WebEngineView é o componente que carrega e exibe a página web. Quando o URL muda, a nova URL é adicionada ao modelo de histórico (historyModel).

ListModel {
    id: historyModel
}

ListView {
    id: historyView
    width: parent.width
    height: 200
    model: historyModel
    delegate: Text {
        text: url
    }
    visible: false // Defina como true para visualizar o histórico
}

ListModel armazena as URLs visitadas. ListView exibe esse histórico, mas está inicialmente invisível (visible: false).

MouseArea {
    anchors.fill: parent
    acceptedButtons: Qt.RightButton
    onPressed: {
        if (mouse.button == Qt.RightButton) {
            contextMenu.open(mouse.x, mouse.y)
        }
    }
}

MouseArea detecta cliques do mouse. Se o botão direito do mouse for pressionado, o menu de contexto (contextMenu) é aberto na posição do clique.

Menu {
    id: contextMenu
    MenuItem {
        text: qsTr("Copy")
        onTriggered: webEngineView.triggerWebAction(WebEngineView.Copy)
    }
    MenuItem {
        text: qsTr("Paste")
        onTriggered: webEngineView.triggerWebAction(WebEngineView.Paste)
    }
    MenuItem {
        text: qsTr("Cut")
        onTriggered: webEngineView.triggerWebAction(WebEngineView.Cut)
    }
    MenuItem {
        text: qsTr("Select All")
        onTriggered: webEngineView.triggerWebAction(WebEngineView.SelectAll)
    }
    MenuItem {
        text: qsTr("Refresh")
        onTriggered: webEngineView.triggerWebAction(WebEngineView.Reload)
    }
    MenuItem {
        text: qsTr("Zoom In")
        onTriggered: { webEngineView.zoomFactor += 0.1; }
    }
    MenuItem {
        text: qsTr("Zoom Out")
        onTriggered: { webEngineView.zoomFactor -= 0.1; }
    }
    MenuItem {
        text: qsTr("Open in external browser")
        onTriggered: {
            Qt.openUrlExternally(webEngineView.url)
        }
    }
}

Menu define um menu de contexto com várias opções, como copiar, colar, cortar, selecionar tudo, atualizar, zoom in, zoom out, e abrir o URL em um navegador externo.

SystemTrayIcon {
    id: trayIcon
    visible: true
    icon.source: "./imagens/google.png" // No caso a pasta onde está a imagem do ícone

    menu: Menu {
        MenuItem {
            text: "Open"
            onTriggered: {
                window.show()
                window.raise()
                window.requestActivate()
            }
        }
        MenuItem {
            text: "Open Specific URL"
            onTriggered: {
                webEngineView.url = "http://www.google.com"
                window.show()
                window.raise()
                window.requestActivate()
            }
        }
        MenuItem {
            text: "Toggle History View"
            onTriggered: {
                historyView.visible = !historyView.visible
            }
        }
        MenuItem {
            text: "Settings"
            onTriggered: {
                // Implemente a lógica para abrir a janela de configurações
            }
        }
        MenuItem {
            text: "Exit"
            onTriggered: Qt.quit()
        }
    }

    onActivated: reason => {
        if (reason === SystemTrayIcon.Trigger) {
            if (window.visible) {
                window.hide()
            } else {
                window.show()
                window.raise()
                window.requestActivate()
            }
        }
    }
}

SystemTrayIcon cria um ícone na bandeja do sistema com um menu. As opções do menu permitem abrir a aplicação, abrir um URL específico, alternar a visualização do histórico, abrir configurações e sair da aplicação. A aplicação pode ser minimizada para a bandeja do sistema e restaurada a partir dela.

onClosing: {
    close.accepted = false;
    window.hide();
}

Component.onCompleted: {
    trayIcon.show()
}

Esses manipuladores de evento garantem que a aplicação não seja completamente fechada ao clicar em fechar, mas sim escondida. Component.onCompleted exibe o ícone na bandeja quando a aplicação é iniciada.

Conclusão

O código exemplifica uma aplicação QML que utiliza WebEngineView para carregar o Google, inclui um menu de contexto para várias operações, e um ícone de bandeja do sistema para facilitar o acesso e controle da aplicação. Os elementos chave como MouseArea e SystemTrayIcon melhoram a usabilidade, permitindo que os usuários interajam com a aplicação de maneira intuitiva e eficiente. Este exemplo é uma boa base para criar aplicativos web integrados com funcionalidades de interface de usuário ricas e interativas.

Forem: Moprius

Cursor SDK, Composer 2 e a nova economia dos agentes de código

Do CLI ao multi-agente: por que o fluxo antigo quebrou

O que é, de verdade, um "AI harness"

O Cursor SDK em TypeScript

Composer 2: o caso dos modelos especializados em código

A economia do token: a nova métrica de eficiência

Multitarefa com agentes: o novo workflow

Para onde isso aponta

Hunyuan Preview: o gigante chinês entra de vez na corrida dos modelos abertos

O que é o Hunyuan Preview

Mixture of Experts: por que importa

MTP: a moda do "Multi-Token Prediction"

Janela de contexto e modo de raciocínio

Como ele se compara

Comportamento na prática

Performance local: o caso do Mac Studio

Quantização: o detalhe que muda tudo

O que isso significa para o ecossistema

Entendendo o Linux por dentro: uma viagem pelas camadas que fazem o sistema funcionar

Introdução: por que o Linux parece tão complicado (e por que ele não é, quando você sabe olhar)

1. Abstração: o segredo para entender qualquer sistema complexo

2. Os níveis e camadas de abstração no Linux

A diferença crítica entre modo kernel e modo usuário

3. Hardware: a importância da memória principal

O conceito de estado

4. O Kernel: o cérebro silencioso do sistema

4.1 Gerenciamento de processos

4.2 Gerenciamento de memória

4.3 Drivers de dispositivos e o gerenciamento de hardware

4.4 Chamadas de sistema e suporte aos processos

5. Espaço do usuário: onde a ação acontece

6. Usuários: identidades e fronteiras

7. Olhando para frente: o que vem agora?

Dominando o Express: partials, sessões, CRUD REST, filtros e páginas de erro

Estruturando views

Controlando as sessões de usuários

Faltou habilitar o body parser e a sessão na stack

Cuidados ao trabalhar com sessões

Criando a rota /contatos

Criando rotas no padrão REST

Implementando as rotas REST

Implementando as actions

Criando as views do CRUD

O truque dos verbos PUT e DELETE em HTML

Aplicando filtros antes de acessar as rotas

Criando o middleware de autenticação

Encaixando o filtro nas rotas

Indo além: criando páginas de erros amigáveis

Criando as views de erro

Registrando os handlers de erro

Testando

Conclusão

Iniciando com Express: do primeiro scaffold à organização em MVC

Por que utilizá-lo?

Instalação e configuração

Criando um projeto de verdade

Gerando scaffold do projeto

Detalhes sobre o Connect

Organizando os diretórios do projeto

O problema dos requires espalhados

Refatorando as rotas

Criando o primeiro controller

Criando a primeira view

Conclusão

Desenvolvendo aplicações web com Node.js: do primeiro servidor ao seu próprio roteador de URLs

Por que começar pelo módulo HTTP nativo?

Criando nossa primeira aplicação web

Como funciona um servidor HTTP por baixo dos panos?

Trabalhando com diversas rotas

Separando o HTML do JavaScript

Desafio: implementar um roteador de URLs

Regras do desafio

Dicas importantes

Estratégia recomendada

Por que esse desafio importa?

Conclusão

Visualização de dados em Python

Criando um conjunto de dados “sujo”

1. Explorando seus dados com head, tail e wc

1. Explorando seus dados com `head`, `tail` e `wc`

2. Visualizando colunas específicas com `cut`

3. Removendo linhas duplicadas com `sort` e `uniq`

4. Buscando e filtrando com `grep`

5. Tirando espaços em excesso com `sed`

6. Substituindo valores com `sed`

7. Contando e resumindo com `awk`