Artigos

Peça a um modelo para responder em JSON e na maioria das vezes json.loads() funciona sem problemas. As falhas são as que custam uma sessão de debug: um comentário de uma linha dentro do objeto, um code fence de markdown envolvendo tudo, uma chave escrita userEmail quando seu código espera user_email. Um prompt mais estrito (“responda APENAS com o objeto JSON, sem nenhum outro texto”) torna esses casos mais raros. Não os torna impossíveis, porque o modelo ainda pode ignorar o pedido. A saída estruturada remove o pedido da equação: você entrega à API um JSON Schema, que restringe a amostragem de tokens do próprio modelo para que a resposta tenha que corresponder a ele. ...

Você escreve .sidebar .card { color: blue; }, carrega a página e o card continua vermelho por causa de uma regra adicionada uma hora antes: .card { color: red; }. A nova regra vem depois no arquivo. Mesmo assim, perde. O navegador compara os dois seletores com um sistema de pontos fixo, e .sidebar .card pontua mais alto que .card, não importa qual você escreveu por último. Esse sistema de pontos é a especificidade. Depois que você aprende a calculá-la de cabeça, “por que meu CSS não se aplica” se torna aritmética pura. Não tem nada a ver com layout: Grid ou Flexbox decide onde um elemento fica, a especificidade decide qual regra define a cor ou o tamanho quando duas regras entram em conflito. ...

Buscar uma chave em um dict Python com dez entradas leva o mesmo tempo que buscar em um com dez milhões. Isso não é acidente de uma linguagem rápida. O dict do Python, o HashMap do Java e o Map do JavaScript são todos tabelas hash, e todo o design existe para que busca, inserção e remoção rodem em O(1) na média. A notação Big O dá a essa busca o rótulo “tempo constante”. Este é o mecanismo que justifica isso. ...

Um programa em C que libera um buffer e continua lendo dele ainda compila. Depois corrompe a memória, às vezes na hora, às vezes três requisições depois, numa parte do código que nunca tocou aquele buffer. O Rust rejeita esse programa já no cargo build, sem nenhum garbage collector envolvido. O compilador rastreia quem é o owner de cada valor e quem pode acessá-lo. Esse rastreamento é ownership e borrowing. ...

Um teste para place_order precisa de um gateway de pagamento, um cliente de SMS e uma calculadora de impostos. Use os de verdade e cada execução do teste cobra um cartão e manda um SMS para um número de telefone real. Um teste unitário tem que rodar em milissegundos e sem rede, então os três precisam ser substituídos por outra coisa. Esse “outra coisa” vem em cinco tipos, cada um resolvendo um problema diferente, e tratá-los como intercambiáveis é por isso que as discussões de “só usa um mock” em code review não terminam nunca. ...

Você salva um arquivo, o Prettier reformata, e o ESLint aponta imediatamente um erro na linha que o Prettier acabou de tocar. As duas ferramentas estão configuradas, as duas estão rodando, e em vez de ajudar, estão brigando uma com a outra. As duas ferramentas fazem trabalhos diferentes. O problema é que as duas têm opinião sobre uma única coisa: a aparência do código na tela. O que o ESLint realmente verifica O ESLint analisa seu código em uma árvore de sintaxe abstrata e executa regras sobre a estrutura dela. A maior parte do seu valor vem de regras que encontram bugs reais: uma variável nunca definida, um return inalcançável depois de outro return, um import que ficou sem uso depois de uma refatoração, uma chave duplicada em um objeto que sobrescreve a primeira em silêncio. São verificações semânticas: o ESLint lê o que o código faz. ...

Por que uma transferência bancária precisa de mais que dois UPDATE Mova R$ 50 de uma conta para outra e a versão naive são duas instruções: subtrair da conta A, somar à conta B. Execute-as separadamente e, se o processo cair ou a conexão cair entre as duas, o dinheiro desaparece de A e nunca chega a B. O banco de dados fez exatamente o que foi pedido, duas vezes. O negócio perdeu os R$ 50 do mesmo jeito. ...

Por que “parece certo” não é um teste para um prompt Você aperta a redação de um prompt que roteia tickets, testa nos três exemplos abertos no seu notebook de rascunho e coloca no ar. Uma semana depois, reclamações de cobrança que antes caíam na fila certa começam a cair em “pergunta”. Não os três casos que você checou: os outros quatrocentos que você não checou. Nada quebra. Não há stack trace. O prompt, lido em voz alta, ainda parece bom. ...

Um componente de chat reconecta o WebSocket toda vez que você digita uma letra em um campo de busca que não tem nada a ver com o chat. Outro componente re-renderiza em loop até a aba congelar. Um terceiro registra seu useEffect duas vezes ao montar, mas só em desenvolvimento. Nenhum desses é um bug do React. Os dois primeiros são o array de dependências fazendo exatamente o que você pediu, e o terceiro é o Strict Mode verificando se o seu efeito sabe se limpar depois de si mesmo. ...

<.+> contra <b>bold</b> and <i>italic</i> não encontra <b>. Encontra a string inteira, do primeiro < ao último >. Nada está quebrado. É exatamente isso que um quantificador greedy deve fazer, e também é o bug mais comum de “o regex está casando demais”. Depois que você entende o que o motor faz enquanto lê o seu padrão, esse bug e a maioria dos parentes dele deixam de ser mistério. Como um Motor de Regex Lê o Seu Padrão Um motor de regex não compara o seu padrão com a string como você compara duas strings por igualdade. Os motores que você usa no dia a dia (re do Python, RegExp do JavaScript, PCRE, .NET, Java) são regex-directed: eles percorrem o padrão da esquerda para a direita, token por token, e para cada token tentam consumir caracteres da string na posição atual. Quando um token casa, o motor avança tanto o ponteiro do padrão quanto o da string. Quando um token falha, o motor faz backtracking: volta ao último ponto em que tinha uma escolha, como um quantificador que poderia ter casado com menos caracteres ou um ramo de alternância ainda não tentado, e tenta a outra opção. ...