标签：#braziliandevs

Eae gente bonita, beleza? Depois de um longo período, resolvi voltar aqui e continuar compartilhando...

Como eu mostro que estou contribuindo? Posso colocar no meu LinkedIn? E no meu currículo, como faço? Foi a partir dessas dúvidas que eu elaborei esse guia pra você que quer contribuir do seu jeito e mostrar às empresas e às pessoas, de forma clara e estratégica, o que você está fazendo. Vamos lá? 👇 Por que eu deveria mostrar no LinkedIn? LinkedIn é a porta de entrada para o mundo corporativo no Brasil e no mundo. É por meio dele que você mostra "trabalho". E tem mais: não é só experiência remunerada que conta como evidência de que você tem conhecimento e prática, mas também tudo o que você constrói de forma voluntária , seja tirando dúvida de alguém, participando de um projeto open-source ou escrevendo sobre o que aprendeu. Recrutador não lê currículo pensando só em carteira assinada. Lê pensando em capacidade . Você contribui com algo para a comunidade e quer colocar isso no seu perfil. Existem 3 formas que você pode usar, e elas podem ser usadas todas juntas ou só uma. Escolha aquela que fizer mais sentido pro seu perfil ou busque por outras pessoas que você admira dentro da comunidade e veja como elas colocaram no próprio perfil. 1. Seção de Experiência Use como experiência sempre que estiver contribuindo de forma profissional pra uma área que você busca. Se você participa de contribuições no GitHub, seja através de código, documentação ou outra forma, use como experiência. Pessoas que também estão ajudando na moderação ou administração (community managers) podem destacar as responsabilidades ou resultados das suas ações por aqui. Exemplo de como preencher no LinkedIn: Cargo: [cargo que você faz] Open Source Empresa: [Nome do projeto/organização] Tipo de emprego: Meio período (ou Voluntário) Local: Remoto, Brasil Descrição: - Contribuí com [X] pull requests na documentação do projeto [Nome], focando em clareza para novos contribuidores. - Revisei issues abertas e sugeri melhorias de acessibilidade em componentes de UI usando [ferramenta/stack]. - Participei de re

Não é novidade para ninguém que estamos passando por uma transformação na área de desenvolvimento de software, em que a IA está assumindo diversas atividades. E isso me faz pensar: o que vamos medir, ou o que teremos como parâmetro para qualidade de software daqui pra frente? É sobre isso que vou falar neste texto. Antes das métricas: entenda o momento do seu time Antes de entrarmos nas métricas em si, precisamos entender o momento em que o nosso time está. É muito fácil eu simplesmente jogar métricas aqui e você aplicá-las ao seu time de maneira automática — mas será que elas fazem sentido para o seu contexto? Uma coisa que eu falo bastante aos meus alunos da mentoria que dou na He4rt Developers é: pra que eu quero isso? Softwares representam necessidades do mundo real, logo, medir o sucesso e a qualidade deles vai depender muito das necessidades que eles buscam suprir. Partindo agora para as métricas, eu gosto de dividi-las em dois grupos: Métricas para stakeholders Métricas para o time Qualidade de software não se resume a número de bugs — ela se aplica tanto em como o software é recebido pelo cliente final, quanto em como ele é desenvolvido. Métricas para stakeholders Uma coisa que eu aprendi neste tempo na empresa em que tenho atuado, principalmente com a transformação digital, é que mostrar número de bugs abertos ou resolvidos não mostra para o público o que realmente importa: como está a qualidade do produto. E, para me ajudar nisso, eu sempre tento me colocar no lugar de um cliente que não tem conhecimento profundo sobre o ciclo de desenvolvimento de software. A primeira coisa que eu gostaria de ver quando um QA, ou o time, vier me mostrar os resultados de uma sprint ou de um quarter é: quantos problemas eu tenho em produção — mas não só isso, quanto tempo tenho levado para resolvê-los. Mean Time to Resolve/Repair (MTTR) Essa é a famosa métrica que vai mostrar o tempo que leva desde que o problema é identificado até ele ser resolvido em produção. Dependendo

A narrativa atual da tecnologia está fortemente inclinada para a automação. Com agentes de IA escrevendo boilerplate , gerando componentes e até estruturando projetos inteiros, é fácil olhar para o futuro do desenvolvimento de software e assumir que o elemento humano está diminuindo. Mas se você mantém ou contribui ativamente para um projeto open source , sabe que a realidade é bem diferente. A IA pode escrever código, mas não consegue validá-lo contextualmente contra décadas de edge cases obscuros. Ela não sabe dizer por que uma regra de negócio específica falha em produção. Mais importante ainda: a IA não constrói comunidade. A evolução de um software robusto ainda depende inteiramente de pessoas colaborando, quebrando código, reportando bugs e validando se o código realmente funciona no mundo real. Para ver isso na prática, precisamos olhar para projetos que tentam fechar lacunas geracionais gigantescas na tecnologia. Um exemplo perfeito disso é o AxonASP . A Filosofia do AxonASP: Modernizando o Legado Por muito tempo, o ASP Clássico e o VBScript foram considerados presos a um modelo de servidor obsoleto — amarrados ao IIS e deixados para trás pelas práticas modernas de deploy . O AxonASP muda esse cenário. É um runtime open source e cross-platform que trata o ASP Clássico como uma Aplicação moderna, em vez de uma relíquia do passado. Ele traz o VBScript, o ASP e, principalmente, o suporte ao JavaScript Síncrono para o futuro. Construir um runtime que lida com código legado enquanto opera em um ecossistema moderno e multiplataforma não é algo que você consegue simplesmente pedindo para um LLM. Exige um ciclo de feedback agressivo. O AxonASP está em franca evolução e apresenta altíssima compatibilidade com o ASP Clássico. Mas essa compatibilidade não é mágica — ela é o resultado direto de usuários pegando seus scripts legados de 15 a 20 anos atrás, rodando no motor, vendo onde falham e reportando exatamente o que aconteceu. Cada issue aberta e cada bug reportado p

Exatamente isso que você leu. Você não precisa ser um "expert" em determinada linguagem, ou ter: 5...

Por muito tempo eu acreditei que programação e desenvolvimento de software como sinônimos. Na...

Um relato honesto de alguém que trabalha com design, vive com TDAH e está cansada de dicas genéricas Tem um tipo de artigo sobre organização que eu já sei de cor. É sempre alguma variação de: “faça uma lista, use Pomodoro, durma 8 horas e beba água”. Só que tem um cenário que quase nunca aparece nessas listas: O momento em que você não é neurotípica, está em burnout, tem duas tarefas importantes com o mesmo prazo e nenhuma técnica milagrosa resolve. É sobre isso que eu quero falar aqui. Sumário: O cenário caótico (e bem real) Por que o Pomodoro não funciona pra todo mundo Burnout em quem tem TDAH O dia em que duas tarefas importantes têm o mesmo prazo Estratégia 1: uma prioridade verdadeira por dia Estratégia 2: subtarefas em vez de cronômetro Estratégia 3: time blocking gentil (agenda que não te esmaga) Estratégia 4: reduzir fricção em vez de exigir mais disciplina Estratégia 5: contratos curtos consigo mesma E quando nada disso parece suficiente? Referências O cenário caótico (e bem real) Imagina o seguinte: Projeto A : entrega do pitch da pós, com prazo na sexta. Projeto B: preparar apresentação do roadmap, também para sexta. Você já está cansada, a cabeça rodando, o corpo em modo economia de energia. Aí você joga no Google “como se organizar” e recebe de volta: “Use a técnica Pomodoro, 25 minutos de foco, 5 de pausa.” E você pensa: “Amiga, eu mal estou levantando da cama. Você quer que eu vire um cronômetro humano?” A real é que muita técnica de produtividade tradicional foi pensada para cérebros neurotípicos. Quando a gente vive com TDAH, burnout ou os dois juntos, essa lógica simplesmente não encaixa tão bem. Por que o Pomodoro não funciona pra todo mundo Pomodoro é ótimo… para algumas pessoas. Mas tem motivos bem específicos para ser um caos para muitos de nós. Por exemplo: A pausa obrigatória, interrompe justo quando o foco finalmente chegou. A sensação do timer contando, aumenta a ansiedade em vez de ajudar. Cada “reinício de ciclo” vira mais uma micro deci

Há alguns meses, pagando $7/mês por um servidor de 512MB no Render pra hospedar uma API de um projeto da escola, decidi entender como esse tipo de infraestrutura funciona por baixo — e construir a minha própria versão. O resultado é o Arctis Deploy : uma plataforma de deploy contínuo via Git, com Docker isolado por projeto. Esse post é sobre como ela funciona por dentro. Arquitetura geral Frontend (Next.js) │ ▼ Backend (Go + Fiber) — Clean Architecture │ ├──► Deploy-Agent (roda em cada servidor) → Docker └──► Database-Agent (provisiona MySQL/Postgres) em desenvolvimento, ainda não disponível para usuários Cada servidor de produção roda um deploy-agent próprio. O backend central envia comandos via HTTPs autenticado e o agent executa o que for necessário — clone, build, container, métricas. O pipeline de deploy Todo deploy passa por 5 etapas sequenciais: clone — git clone --depth 1 , otimizado pra trazer só o necessário analyze — detecta o framework automaticamente lendo package.json , requirements.txt , go.mod , etc. build — gera um Dockerfile multi-stage específico pro framework detectado (timeout: 15min) deploy — sobe o container na porta alocada, com limites de CPU/RAM aplicados health check — faz requisições até o container responder, com rollback automático em caso de falha Cada etapa emite logs estruturados ( info / warn / error ), transmitidos via WebSocket em tempo real pro frontend. Detecção automática de framework Next.js, React, Vue, Node.js, e sites estáticos. A detecção é baseada nos arquivos do repositório — o usuário só conecta o Git e dá push. Outros detalhes Pool de recursos : cada plano define um total de Projetos/CPU/RAM/disco que o usuário distribui livremente entre seus projetos Auto-sleep : no free, containers sem tráfego são pausados ( docker pause ) — não destruídos — e despertam automaticamente na próxima requisição Domínios : subdomínio automático ou domínio próprio, com SSL via Cloudflare Pagamentos : MercadoPago integrado, planos em real V

Tenho aproveitado meu tempo sem trabalhar pra estudar, enfim a vida de quem trabalha com tecnologia né? E um dos meus maiores focos tem sido IA, seus usos, como ela entra e pode ser aplicada em áreas diferentes, e todas as novidades que saem todos os dias. Hoje vim compartilhar uma coisa bem legal que aprendi no curso AI-Native Engineering Foundations do Addy Osmani , o problema dos 70%. Existe um padrão claro que tenho observado na prática ao acompanhar dezenas de equipes de engenharia: a Inteligência Artificial resolve com impressionante eficiência 70% de quase qualquer tarefa técnica. Falo daquela camada previsível, repetitiva e baseada em padrões exaustivamente documentados na internet. Coisas como código boilerplate, arquivos de configuração, implementações de CRUDs simples, conversão de sintaxe entre linguagens e a escrita de testes unitários básicos. A IA já "viu" milhões de exemplos disso em repositórios públicos e consegue reproduzir o padrão em segundos. Para essa fatia do trabalho, ela é uma aceleradora fantástica. O grande problema, e o motivo pelo qual muitos projetos com IA começam bem mas falham no meio, é que os outros 30% são justamente os que sustentam o software. É nesses 30% que entram as decisões que inteligência nenhuma consegue tomar sozinha: Contexto de Negócio: A IA não sabe por que aquela feature está sendo construída ou como ela impacta o usuário final. Arquitetura e Manutenibilidade: Escrever código que funciona hoje é fácil; escrever código que outra pessoa consegue alterar daqui a seis meses sem quebrar o sistema é outra história. Casos de Borda e Segurança: A IA tende a gerar o "caminho feliz". Tratar falhas de concorrência, vazamento de memória e vulnerabilidades específicas do seu ecossistema exige malícia técnica. Essas questões não se resolvem apenas digitando linhas de código, elas exigem contexto, experiência, histórico de dores passadas e, acima de tudo, julgamento humano. E é exatamente aqui que a IA ainda não entrega. O Parado

Fiz um curso de devweb e achei que tinha aprendido JavaScript O problema Fiz um curso de...