O Verao Que Mudou Minha Vida Online

Descobrindo a internet num verão qualquer

Vocês sabem como é aquele período em que você resolve finalmente mexer com alguma coisa na internet e percebe que tinha zero noção do que estava fazendo. Foi assim que o verão que mudou minha vida online começou pra mim. Eu tava em casa, sem muita opção, e resolvi montar meu primeiro site. Não era nada de outro mundo. Um blog simples, hospedagem barata, template básico. O problema é que eu não sabia nem o que era DNS naquela época. Meu primeiro erro foi assumir que registrar um domínio e configurar hospedagem eram a mesma coisa. Fiquei três horas tentando fazer upload dos arquivos pelo painel da locadora e nada. O FTP não conectava, a porta estava bloqueada, e eu nem sabia que existia essa tal de porta 21. No fim, descobri que meu provedor tinha bloqueado portas não padrão na rede residencial. Troquei para uma VPS com acesso SSH e o processo inteiro de subir um site simples que deveria levar trinta minutos demorou quatro dias. Aprendi algo importante aí: infraestrutura básica antes de código.

O verão que mudou minha vida online

Depois desse baque inicial, comecei a estudar de verdade. Não no sentido acadêmico, mas daquele jeito que a gente estuda quando precisa resolver um problema concreto. Apreendi o básico de HTML e CSS, depois entrei num curso grátis de JavaScript. Construí coisas feias, quebradas, que não respondiam direito no mobile. Mas funcionavam. Aos poucos, comecei a entender o que acontecia entre o navegador e o servidor. Uma das coisas que mais me pegaram foi a confusão entre front-end e back-end. Eu achava que criar interfaces bonitas era suficiente. Achei errado quando lancei meu primeiro projeto e vi que ninguém conseguia preencher o formulário de contato porque eu tinha esquecido completamente de configurar o endpoint no servidor. O formulário enviava para lugar nenhum. Passei uma semana inteira analisando logs antes de perceber que simplesmente não havia nenhum route configurado. Isso é algo que a maioria dos iniciantes passa. Você constrói a parte visual e esquece que existe toda uma camada invisível funcionando por trás. O que realmente mudou pra mim foi entender de ferramentas de deploy. No começo eu subia tudo manualmente, arquivo por arquivo, via FTP. Foi então que conheci CI/CD. Configurei um pipeline simples com GitHub Actions e o deploy passou a rodar sozinho toda vez que eu fazia commit. O tempo que eu gastava fazendo upload manual era cerca de duas horas por semana. Com automação, reduzi pra cinco minutos, se é que preciso fazer algo além de dar push. E não precisa ser complicado pra começar. Um workflow básico de dez linhas no YAML resolve a maior parte dos casos.

Também descobri CSS Grid e Flexbox no meio desse processo. Antes disso, eu centralizava divs usando tabelas. Sério. Tabela com cells, vertical-align middle, margem automática. Era 2018 e eu ainda fazia isso. Quando descobri que existia display: flex e justify-content: center, fiquei viciado. A diferença prática é que layouts que antes levavam dois dias pra ficarem decentes passaram a levar duas horas. Sem exagero. Outro ponto que muita gente não leva a sério no começo é versionamento. Eu costumava manter múltiplas cópias dos projetos numa pasta chamada "versao_final", "versao_final_real", "versao_final_de_verdade". Isso não é organização, é falta de git. Quando perdi um projeto inteiro porque sobrescrevi o arquivo local sem saber, entendi que precisava aprender branches. Hoje eu nunca mais trabalho sem branch separado para cada feature. E faço commit fragmentado, sempre. Commit de coisa feia misturado com commit de correção é receita pra dor de cabeça na hora de fazer rollback. Tem um detalhe técnico que poucos explicam direito e que causa bastante problema: a diferença entre dependências de desenvolvimento e dependências de produção. Já perdi horas debuggando um site que funcionava localmente e quebrava no servidor porque eu tinha instalado um pacote apenas como devDependency. O npm remove essas dependências quando você roda npm install --production. Se o seu código depende disso, o deploy falha silenciosamente. A solução é simples: verifique o package.json antes de subir e garanta que tudo que o app usa está listado como dependency normal, não como devDependency. Teste com o flag --production antes de confiar no build.

Um dos maiores aprendizados foi sobre performance. Comecei a medir meu site com Lighthouse e os resultados eram vergonhosos. Imagens pesadas, JavaScript carregando antes do conteúdo, sem cache configurado. Gastei tarde demais entendendo lazy loading, compression e CDN. O ganho foi concreto: o tempo de carregamento caiu de oito segundos pra cerca de dois segundos. Só isso já justificava todo o esforço. E não precisa ser tudo de uma vez. Vá resolvendo um problema de cada vez. Se você tá começando agora, tem algumas coisas que facilitam muito. Use template engines básicos antes de partir pra frameworks pesados. Não precisa de React pra fazer um blog. Um boilerplate com nunjucks ou até HTML puro já chega. Só entre em terreno complexo quando o projeto exigir algo que o básico não consegue entregar. Frameworks adicionam camadas de abstração que parecem necessárias no começo, mas que viram peso morto quando você não domina os fundamentos. Também vale a pena investir em ferramentas de desenvolvimento desde o início. VS Code com as extensões certas economiza tempo que você não imagina. Live Server pra ver alterações em tempo real, Prettier pra formatar automaticamente, e uma extensão de snippets pra economizar digitação. Nada disso é revolucionário, mas o acúmulo de pequenas economias de tempo faz diferença depois de meses de uso.

O que eu diria pra mim mesmo no início seria: documente tudo. Anote os erros que encontrou e como resolveu. Crie um pequeno handbook pessoal. Da primeira vez que configurei SSL num servidor Linux, gastei seis horas. Da terceira vez, levei quinze minutos porque tinha anotações prévias. Isso se aplica pra qualquer coisa: configuração de banco de dados, deploy, integração de API. O conhecimento acumulado em notas técnicas vale mais do que qualquer curso. Se quiser recursos práticos, o MDN Web Docs é a referência mais confiável que existe. Gratuita, atualizada, e com exemplos que você pode testar direto no navegador. Além dele, tem o freeCodeCamp pra exercícios interativos e o The Odin Project que cobre o fullstack do zero. Não precisa pagar nada pra aprender. O mercado tá cheio de curso caro que ensina o mesmo que você encontra grátis. A diferença é disciplina, não acesso à informação. A parte mais difícil não é técnica. É manter consistência. Estudar uma hora por dia é muito mais produtivo do que dez horas num sábado e nada no resto da semana. O cérebro precisa de repetição espaçada pra fixar conceitos. Programação é habilidade, não conhecimento teórico. Você aprende fazendo, errando, corrigindo, e fazendo de novo. Os projetos que parecem pequenos no começo são os que te dão base sólida. Não subestime a experiência de construir algo simples e funcional antes de partir pro próximo.