Guias praticos e perenes para programadores. Cada um parte de comandos reais e exemplos que funcionam, e diz com clareza quando nao usar a ferramenta que explica.
Abaixo esta tudo, do mais recente ao mais antigo.
Guias praticos e perenes para programadores. Cada um parte de comandos reais e exemplos que funcionam, e diz com clareza quando nao usar a ferramenta que explica.
Abaixo esta tudo, do mais recente ao mais antigo.
A suíte de testes está verde há três semanas. Hoje o npm test falha em uma asserção que não tem nada a ver com o que você acabou de mudar, e git log v1.4.0..HEAD mostra 340 commits de quatro pessoas desde o último release que alguém tinha certeza de que funcionava. Ler cada diff custa um dia inteiro. Fazer checkout de commits ao acaso é mais rápido, mas ainda não é um plano. ...
O que o DNS realmente faz em cada requisição Toda requisição para example.com começa com uma busca que não tem nada a ver com sua aplicação: algo precisa transformar aquele nome em um endereço IP antes que um único pacote TCP saia da máquina. Essa tradução é o DNS, o Domain Name System, e ela acontece em toda requisição, seja o cliente um navegador, o curl, ou um serviço de backend chamando outro pelo hostname. ...
O que o TLS realmente protege em uma conexão HTTPS Carregue uma página por http:// puro em uma rede que você não controla, um aeroporto ou o roteador de uma cafeteria, e tudo o que você envia viaja como texto legível. O caminho da URL, os cookies, os campos do formulário, a senha em um POST de login: qualquer pessoa nessa rede com um sniffer de pacotes lê tudo isso ao passar. TLS, Transport Layer Security, é o protocolo que impede isso. Ele fica entre o TCP e o protocolo de aplicação, então quando o HTTP começa a falar, a conexão já está criptografada e vinculada a uma identidade de servidor verificada. HTTPS é o HTTP rodando sobre essa conexão em vez de uma em texto plano. ...
Cada chamada a uma API de LLM hospedada envia seu prompt para o servidor de outra pessoa e cobra por token. Perdeu a rede, ela para de responder. O Ollama tira os dois problemas do caminho: baixa um modelo de pesos abertos para a sua máquina e o disponibiliza por uma API REST em localhost:11434. Um único binário funciona como gerenciador de modelos, cliente de chat e servidor. O que o Ollama faz de verdade O Ollama usa o llama.cpp e engines de inferência parecidas por baixo dos panos, então você nunca precisa mexer numa flag de compilador ou num caminho de biblioteca CUDA. ollama pull llama3.2 baixa um arquivo de modelo quantizado (formato GGUF) do próprio registro do Ollama em vez do Hugging Face, embora também consiga importar arquivos GGUF de lá. Ao executar o modelo, o Ollama entrega esses pesos a um servidor em segundo plano, que os carrega na RAM (ou VRAM, se encontrar uma GPU compatível), os mantém residentes por alguns minutos após a última requisição para que a próxima seja rápida, e os descarrega assim que você para de fazer perguntas. ...
Um endpoint de checkout que redimensiona a imagem de um produto, envia um email de confirmação e atualiza um mecanismo de recomendação antes de responder com 200 OK é tão rápido quanto sua etapa mais lenta. Se uma delas der timeout, a requisição inteira falha. Uma fila de mensagens permite que o endpoint entregue esse trabalho como mensagens e responda na hora, enquanto workers separados as processam no próprio ritmo. ...
Todo recurso de cloud que você já criou clicando em um console web (uma VM, um load balancer, um registro DNS) também pode ser descrito em um arquivo de texto e criado com um único comando. O arquivo vive no git, passa por uma pull request e reproduz o mesmo setup em uma segunda conta sem que ninguém precise lembrar quais das nove configurações foram alteradas na mão. É isso que o Terraform faz. ...
O que um CDN realmente faz com uma requisição Um usuário em Tóquio que carrega uma página hospedada num servidor na Virgínia paga essa distância duas vezes: uma vez para a requisição chegar, outra para a resposta voltar. A fibra óptica corre numa fração fixa da velocidade da luz, e só essa viagem já custa algo entre 150 e 200ms de round-trip antes de a origem fazer qualquer trabalho. Some uma query no banco de dados e mais um ou dois saltos lentos. Uma página que parece instantânea na porta ao lado fica arrastada do outro lado do planeta. ...
Uma query que leva 200ms no seu banco de dados ainda leva 200ms na milionésima vez que alguém a executa, e cada uma dessas execuções disputa as mesmas conexões, o mesmo I/O de disco e a mesma CPU. O Redis mantém a resposta em memória, num servidor que não faz mais nada, então a milionésima leitura custa uma ida e volta de rede em vez de um plano de query. ...
O que fica entre o navegador e sua app Aponte o navegador para example.com e a requisição nunca toca diretamente no processo que executa seu código. Ela encontra primeiro outra coisa: um servidor que lê a requisição, decide qual backend deve responder, a encaminha para lá e devolve a resposta como se a tivesse produzido ele mesmo. Esse servidor é um reverse proxy. Nginx, Caddy, Traefik e HAProxy fazem esse trabalho, assim como o load balancer que fica na frente de um cluster Kubernetes. O esquema nunca muda: os clientes falam com o proxy e com mais nada. Os servidores reais ficam atrás, em qualquer quantidade e onde quer que rodem. ...
Você dá pull na última versão da main e o Git para com CONFLICT (content): Merge conflict in checkout.js. Você resolve o conflito e o log agora mostra um commit chamado Merge branch 'main' into feature/checkout, acima dos três commits que você realmente escreveu. Quatro commits, uma única mudança real. Um colega que ler esse histórico no mês seguinte não consegue saber qual é qual. git merge e git rebase respondem à mesma pergunta: como eu atualizo meu branch com as mudanças feitas em outro lugar. Eles deixam rastros muito diferentes, e escolher o errado num branch compartilhado causa dano real. ...