Módulo 09 — Inglês técnico

1. Como 15% de inglês aparecem numa prova de programação

Não existe "a prova de inglês" com hora marcada. O inglês da Seletiva é instrumental: ele atravessa os quatro módulos do Projeto-Teste e pontua onde a competidora nem sempre percebe que está sendo avaliada.

• No enunciado e nas orientações. Parte do material da prova pode vir em inglês: um requisito, uma orientação técnica, um texto de apoio. Entender exatamente o que está sendo pedido é a UC5 acontecendo ao vivo. Ler errado um must ou um up to muda o que se constrói, e aí o ponto se perde antes de qualquer linha de código.
• Na documentação. Quando bate a dúvida de sintaxe ou de parâmetro durante a prova, a resposta está na doc que estiver disponível, e doc de tecnologia é em inglês. Quem lê doc rápido destrava sozinha. Quem não lê, trava ou chuta.
• Nas mensagens de erro. Todo erro que o sistema cospe durante as 10h30 de prova está em inglês. Ler o erro e entender a causa em 30 segundos é a diferença entre um bug de 2 minutos e um bug de 40.
• Na fala sobre o sistema. A UC7 é a competência de explicar tecnicamente o que se construiu. A apresentação do Módulo D é em português, mas os termos são em inglês (endpoint, constraint, hash, token), e usar o termo certo com naturalidade é parte da imagem de competência que a banca avalia.

2. A gramática que cai: inglês instrumental de requisito

Esquece conjugação de verbo irregular. O inglês que decide ponto na Seletiva cabe em meia dúzia de estruturas que aparecem em todo enunciado e em toda doc. Dominar essas estruturas é gramática a serviço da leitura de requisito.

2.1 Os modais que definem o que é obrigatório

Especificação técnica em inglês usa os modais com sentido padronizado. Existe até um documento clássico que fixou essa convenção pra internet inteira, a RFC 2119, e as provas seguem a mesma lógica:

Um trecho de enunciado do universo Wedding Pass, do jeito que poderia cair:

Leitura de competidora nota 3: check-in duplo bloqueado é inegociável (must, e é a constraint UNIQUE do módulo 03 mais a verificação atômica do módulo 07); acompanhantes são permitidos com limite de cinco, incluindo o cinco (may + up to); o alerta de 90% é esperado, entra no plano, mas depois dos musts (should).

2.2 O imperativo das instruções

Documentação e orientação técnica falam com verbo no imperativo, sem sujeito: "Create a database named wedding_pass.", "Run the following command.", "Add the dependency to your project.". Imperativo em doc não é grosseria, é instrução: faça isso, nessa ordem. Quando uma orientação vem numerada em imperativo, a sequência importa; pular passo é a receita do erro esquisito dez minutos depois.

2.3 Condicionais de comportamento: if X, then Y

Todo comportamento de sistema se descreve com condicional, e o enunciado usa isso o tempo todo:

• "If the token is missing or expired, the server returns 401." (se acontecer, faça)
• "When a guest confirms the invitation, the system updates the status." (toda vez que acontecer)
• "Guests cannot check in unless the invitation is confirmed." (unless = a menos que; é um "if not" disfarçado)
• "The code must be valid; otherwise, the system displays an error message." (otherwise = caso contrário)

A diferença fina que muda implementação: if descreve uma possibilidade, when descreve uma regra que roda sempre que o evento acontece. Unless engana porque inverte: a frase acima diz que o check-in só passa com convite confirmado. Quem lê unless como "a não ser" solto costuma implementar a condição ao contrário.

2.4 Quantidades e limites

Requisito com número é requisito com pegadinha de fronteira:

2.5 Voz passiva: quem faz o quê

Doc e enunciado adoram voz passiva: "The password is hashed before being stored.", "The request is rejected if the header is missing.". A pergunta de leitura é sempre a mesma: quem faz isso? Se a frase está descrevendo o comportamento esperado do sistema, quem faz é o código da competidora (ela precisa implementar o hash). Se está descrevendo o que a ferramenta já faz sozinha ("the connection is closed automatically"), é só saber que acontece. Confundir os dois gera tanto trabalho faltando quanto trabalho dobrado.

2.6 Falsos amigos e palavras que enganam

3. Ler documentação: método, não tradução

3.1 Skimming e scanning

Duas habilidades diferentes, e a prova usa 90% uma delas:

• Skimming: passar o olho pra entender do que o texto trata. Títulos, primeiro parágrafo, negritos. Serve pra decidir "é essa página que eu preciso?". Dez segundos.
• Scanning: procurar uma informação específica numa página que já se sabe ser a certa. Qual parâmetro, qual valor default, qual o nome da função. É caça, não leitura.

Traduzir a página inteira não é nenhuma das duas. É o hábito que mais queima tempo de prova e o primeiro que o treino desmonta.

3.2 A anatomia das páginas de doc que a gente usa

Cada doc tem um esqueleto fixo. Conhecer o esqueleto transforma a página de parede de texto em mapa:

• MDN (JavaScript, HTML, CSS, HTTP): título → resumo de uma linha → Syntax (a assinatura da função) → Parameters (cada parâmetro explicado) → Return value (o que volta) → Examples (código pronto). A resposta quase sempre está em Syntax + Examples.
• MySQL 8.0 Reference Manual: páginas gigantes por tema, com tabelas de funções e exemplos no meio do texto. Não se lê, se faz Ctrl+F com o nome da função ou da palavra-chave (DATE_FORMAT, FOREIGN KEY, ON DELETE).
• php.net: o manual com a melhor estrutura do mercado: Description (assinatura) → Parameters → Return Values → Examples → User Contributed Notes. As notes são comentários de devs com soluções prontas pra casos reais; garimpo que às vezes economiza meia hora.
• Express (expressjs.com): doc curta, orientada a exemplo. A página da API lista método por método com um bloco de código cada.

3.3 A rota dos 30 segundos

Padrão pra qualquer dúvida de sintaxe durante o treino e a prova:

1. Ctrl+F na página com a palavra exata (nome da função, do parâmetro ou do erro).
2. Exemplo primeiro. Achou um bloco de código que parece com o caso? Lê ele.
3. Syntax/Description depois, só pra confirmar a ordem dos parâmetros.
4. Parágrafo por último, só se ainda restou dúvida (geralmente sobre um caso especial).

Se em 2 minutos a página não respondeu, a página está errada: voltar e escolher outra, em vez de insistir traduzindo.

3.4 Exercício real de scanning (com gabarito)

Fazer cronometrado, 2 minutos por rodada, sem tradutor. É o mesmo formato do Drill 2 (§8).

Rodada 1: MDN, página do fetch(). 1. Qual é o método HTTP default quando não se passa options? 2. O fetch() retorna o quê? 3. Em qual propriedade das options vai o corpo da requisição?

Rodada 2: MySQL Manual, página de Date and Time Functions. 1. Qual specifier do DATE_FORMAT imprime o dia com dois dígitos? 2. Como formatar uma data como 30/11/2026?

Rodada 3: php.net, página de password_hash(). 1. Qual algoritmo o PASSWORD_DEFAULT usa hoje? 2. A função retorna o quê? 3. Qual função faz a verificação na hora do login?

Gabarito: R1: GET · uma Promise que resolve pra um objeto Response · body (string, via JSON.stringify). R2: %d · DATE_FORMAT(data, '%d/%m/%Y'). R3: bcrypt · a string do hash (que já embute salt e custo) · password_verify().

4. Anatomia do erro: ler a mensagem que resolve

O erro em inglês é a orientação técnica escrita (UC5) que mais aparece no dia da prova. E ele sempre tem a mesma estrutura, em qualquer stack:

[TIPO DO ERRO]: [o que aconteceu] [detalhe: qual valor, qual chave, qual arquivo]
    [onde: arquivo, linha, coluna]
    [stack trace: o caminho de chamadas até chegar lá]

4.1 O vocabulário que os erros repetem

4.2 Stack trace no Node: de cima pra baixo, até achar o seu arquivo

TypeError: Cannot read properties of undefined (reading 'nome')
    at listarConvidados (/home/comp/wedding-pass/controllers/convidadoController.js:23:35)
    at Layer.handle [as handle_request] (/home/comp/wedding-pass/node_modules/express/lib/router/layer.js:95:5)
    at next (/home/comp/wedding-pass/node_modules/express/lib/router/route.js:149:13)

Como ler, na ordem:

1. Primeira linha: tipo (TypeError) + o que houve (tentou ler .nome de algo que é undefined).
2. Descer até a primeira linha que é do SEU código: convidadoController.js:23:35 (arquivo, linha 23, coluna 35). Tudo que tem node_modules no caminho é o percurso interno do Express: ignora, não é lá que se mexe.
3. Ir na linha 23 e perguntar: o que aqui pode estar undefined? (O resultado da query? O req.body? Um campo com nome trocado?)

4.3 Erro no PHP: a linha vem no final da mensagem

Fatal error: Uncaught PDOException: SQLSTATE[23000]: Integrity constraint violation:
1062 Duplicate entry '12' for key 'checkin.uq_checkin_convidado'
in /var/www/wedding-pass/api/checkin.php:18
Stack trace:
#0 /var/www/wedding-pass/api/checkin.php(18): PDOStatement->execute(Array)
#1 {main}

Leitura: uma exceção de PDO não tratada, violação de integridade, código MySQL 1062 (entrada duplicada) na chave única uq_checkin_convidado, disparada no checkin.php linha 18. Esse erro específico é um velho conhecido de propósito: é a constraint UNIQUE do check-in fazendo o trabalho dela (módulo 07). O bug não é o banco reclamar; é o código não ter tratado a reclamação pra devolver um 409 educado em vez de estourar na cara do usuário. Além do Fatal error (para tudo), o PHP solta Warning e Notice/Deprecated (avisos que não param a execução, mas apontam problema).

4.4 Os erros de MySQL que mais aparecem no treino

4.5 Os erros do navegador (console do front)

• Failed to fetch / net::ERR_CONNECTION_REFUSED: a API não respondeu. API fora do ar, porta errada na URL, ou o servidor caiu. Primeiro check: o terminal do back.
• blocked by CORS policy: No 'Access-Control-Allow-Origin' header: o navegador bloqueou porque o back não liberou a origem. Falta o middleware de CORS (módulo 04).
• Unexpected token '<', "<!DOCTYPE"... is not valid JSON: o front pediu JSON e recebeu HTML. Quase sempre a API devolveu uma página de erro (404 ou 500) e o response.json() engasgou. O erro aponta pro front, mas a causa está no back ou na URL. 🎯 Esse é o erro que mais engana leitura apressada na prova.
• 401 Unauthorized em toda requisição: token ausente, expirado ou sem o Bearer no header. Olhar a aba Network, não o código, primeiro.
• Cannot read properties of null (reading 'addEventListener'): o getElementById não achou o elemento. Id digitado diferente do HTML, ou o script rodou antes do HTML existir.

4.6 O método dos 30 segundos

Pra qualquer erro, sempre na mesma ordem:

1. Tipo: que categoria de erro é? (sintaxe, conexão, constraint, undefined)
2. Mensagem em português mental: traduzir a linha principal pra si mesma, sem tradutor.
3. Onde: primeira linha do stack que é do meu código (arquivo:linha).
4. Hipótese: o que naquela linha produziria essa mensagem?
5. Teste: confirmar a hipótese (um console.log, um SELECT, um print) antes de sair mexendo.

5. O glossário por domínio

Regra de uso: essa é a base pronta. Na primeira semana de agosto ela vira um arquivo vivo no repositório de cada competidora (docs/glossario.md), e toda sexta-feira ganha os termos novos que apareceram no treino da semana (5 minutos, no fim do drill). Glossário que não cresce é glossário decorativo.

5.1 Palavras de enunciado

5.2 Banco de dados

5.3 Back-end e API

5.4 Front-end

5.5 Git e terminal

5.6 Palavras de erro

A tabela vive na §4.1 (é a mesma lista). No glossário vivo, esses termos entram no domínio "erros", de preferência colados no print do erro real em que apareceram.

6. Falar do sistema em inglês

A apresentação da prova é em português. Mas a competência de comunicação técnica oral (UC7) se treina nas duas línguas, e falar do sistema em inglês tem dois retornos diretos: os termos técnicos saem naturais na apresentação (módulo 10 colhe isso), e a competidora fica pronta pra qualquer material ou interação em inglês que a prova trouxer.

6.1 O banco de frases prontas

Frases de verdade sobre o Wedding Pass, prontas pra adaptar ao sistema de cada uma. A meta não é decorar o banco: é falar cada uma em voz alta até sair sem pausa.

O sistema como um todo: - "Wedding Pass is a web system for wedding management." - "It has three user roles: administrator, organizer and reception." - "The front end consumes a REST API connected to a MySQL database."

Banco de dados: - "The database has six tables, and every table has a primary key." - "Each guest belongs to a wedding and may be assigned to a table." - "I added a UNIQUE constraint to prevent duplicate check-ins."

API e segurança: - "The API uses JWT for authentication." - "Every request must send the token in the Authorization header." - "If the token is missing or expired, the server returns 401." - "Passwords are hashed with bcrypt before being stored." - "I used prepared statements to prevent SQL injection."

Front-end: - "The interface is responsive: the layout adapts from mobile to desktop." - "Every screen handles four states: loading, empty, error and success." - "The form validates the input and shows a clear error message."

Funcionalidades: - "When a guest confirms the invitation, the system updates the status and checks the table capacity." - "The check-in uses an atomic update, so the same guest cannot enter twice." - "The dashboard shows the occupation per table, with an alert at 90% of capacity." - "The guest receives a confirmation receipt in PDF."

6.2 O padrão que sustenta qualquer arguição: I chose X because Y

Toda decisão técnica do sistema cabe numa frase desse formato, e é o mesmo músculo do banco de porquês do módulo 10:

• "I chose bcrypt because it was designed specifically for password hashing."
• "I chose an ENUM for the status column because there are only three possible values."
• "I put the capacity rule in the back end because the front end can be bypassed."
• "I used a UNIQUE constraint because it is the last line of defense against duplicates."

O formato força o hábito certo: nunca dizer só o que fez, sempre o que fez e por quê. Em qualquer língua, isso é o que separa descrição (nota 2) de justificativa (nota 3).

6.3 Narrar enquanto codifica 🛠️

A gambiarra de custo zero: durante o treino normal, explicar em voz baixa, em inglês, o que está fazendo. "Now I'm creating the check-in table, with a unique key on the guest id." Sem plateia, sem nota, sem hora marcada. Três frases por dia já mantêm o vocabulário ativo, e é treino de UC7 acontecendo dentro do treino de banco.

6.4 Pronúncia: as palavras que travam

Meta: clareza, não sotaque. A banca quer entender, não avaliar fonética. Mas algumas palavras técnicas têm pegadinhas que fazem a palavra sair irreconhecível, e essas valem 2 minutos de atenção:

7. Diluir o inglês no treino (pra não virar matéria)

Inglês técnico morre quando vira "estudar inglês na sexta à tarde". Vive quando se dilui em quatro hábitos que não custam hora de cronograma:

• Ambiente em inglês. IDE, navegador e ferramentas configurados em inglês desde o primeiro dia. Cada menu virou flashcard grátis.
• Doc na fonte. Dúvida técnica vai primeiro na doc oficial (inglês), com a rota da §3.3. O vídeo dublado fica pra quando a doc não resolver. Resolve o problema e treina ao mesmo tempo.
• Glossário vivo com rotina. O arquivo da §5 no repositório, atualizado toda sexta no fim do drill. Termo novo que apareceu na semana entra com a frase real em que apareceu.
• O drill diário de 10 minutos. O motor de tudo, catalogado na §8. Nunca falha, nunca estica: 10 minutos, timer, todo dia.

8. O catálogo de drills de 10 minutos

É daqui que sai o aquecimento de inglês que abre toda aula de todas as guias. Regras da rotina:

• 10 minutos cravados, com timer. Estourou, acabou; o drill de amanhã continua de onde parou.
• Material preparado na véspera pelo professor (faz parte da "preparação prévia" de cada guia). Erro real do treino de ontem vale mais que erro inventado.
• Rodízio por fase: a tabela abaixo diz quais drills pagam mais em cada mês. Dentro da fase, variar pra não virar decoreba.
• Sexta tem apêndice: os últimos 5 minutos da sexta são de atualização do glossário vivo (§5).

Drill 1 — Palavra do dia

Como roda. O professor escolhe 5 termos do glossário do domínio da semana e mostra só a coluna da esquerda. Cada competidora explica o sentido; depois, cada uma monta uma frase em voz alta usando 2 dos termos, sobre o próprio sistema. Material. O glossário vivo (§5), aberto. Quando paga mais. O tempo todo; trocar o domínio junto com a fase do cronograma.

Drill 2 — Scanning cronometrado

Como roda. Uma página de doc aberta no telão (MDN, MySQL, php.net, Express) e 3 perguntas objetivas. 2 minutos por pergunta, no cronômetro, sem tradutor. Quem acha, fala onde achou (qual seção da página), porque o método importa mais que a resposta. Material. Uma página de doc ligada ao conteúdo da semana + 3 perguntas preparadas (modelo na §3.4). Quando paga mais. Agosto e setembro, quando cada semana traz ferramenta nova.

Drill 3 — Traduz o erro

Como roda. O professor mostra o print de um erro real que apareceu no treino de ontem (ou um da coleção das §4.4/§4.5). As duas aplicam o método dos 30 segundos em voz alta: tipo, mensagem em português, arquivo:linha, hipótese de causa. Sem abrir o código: o drill é de leitura, não de correção. Material. Prints de erros reais coletados durante a semana (o professor vai guardando). Quando paga mais. Sempre; é o drill mais rentável do catálogo, porque treina exatamente o gesto que recupera tempo na prova.

Drill 4 — Status code relâmpago

Como roda. O professor fala um cenário ("login com senha errada", "convidada criada com sucesso", "token expirado", "rota que não existe", "check-in duplicado"), e elas respondem o código e o nome em inglês (401 Unauthorized, 201 Created, 404 Not Found, 409 Conflict). Depois inverte: o professor fala o código, elas dão um cenário do Wedding Pass. Material. A tabela de status codes do módulo 04. Quando paga mais. Setembro, com a API viva e o front consumindo.

Drill 5 — My system in three sentences

Como roda. Cada uma descreve o sistema (ou o módulo da semana) em exatamente 3 frases, em inglês, de pé. Frase 1: o que é. Frase 2: como está construído. Frase 3: um destaque técnico. A outra escuta e diz qual das três ficou mais clara. Material. Nenhum; o banco de frases da §6.1 é a rampa de partida. Quando paga mais. Outubro, esquentando pro módulo 10.

Drill 6 — I chose X because Y

Como roda. Cada uma pega 2 decisões técnicas que tomou no dia anterior (qualquer tamanho: um tipo de coluna, um endpoint, um componente) e as formula em inglês no padrão da §6.2. Vale repetir decisão antiga com formulação melhor. Material. O trabalho de ontem; depois de outubro, o banco de porquês do módulo 10. Quando paga mais. Outubro e novembro, quando defender escolha vira rotina.

Drill 7 — Read aloud

Como roda. Cada uma lê em voz alta 4 ou 5 linhas de uma doc (parágrafo curto ou lista de passos) e resume em português em uma frase. O professor só corrige pronúncia que compromete a compreensão (tabela da §6.4); fluência vem com a repetição. Material. A doc da semana, qualquer trecho instrutivo. Quando paga mais. Outubro e novembro; bom pra variar quando os outros drills cansarem.

Drill 8 — Enunciado relâmpago

Como roda. O professor lê (ou projeta) um mini-requisito em inglês, no estilo do trecho da §2.1. Elas dizem: o que é must, o que é should, o que é may, e o que implementariam primeiro. 2 minutos por requisito, 2 ou 3 requisitos por drill. Material. Requisitos curtos que o professor escreve na véspera, misturando modais e limites numéricos (§2.4) do universo do sistema. Quando paga mais. Setembro em diante; é ensaio direto da leitura de enunciado da prova.

Drill 9 — Arguição relâmpago

Como roda. O professor faz uma pergunta em inglês sobre o sistema ("How does the system prevent duplicate check-ins?", "Where is the capacity rule enforced?", "What happens when the token expires?"). Nível 1: resposta em português usando os termos técnicos certos em inglês. Nível 2: resposta inteira em inglês, 2 ou 3 frases. Começar todo mundo no nível 1; subir pro 2 quando sair sem travar. Material. 3 perguntas preparadas sobre o que foi construído na semana. Quando paga mais. Outubro e novembro, junto do treino de arguição do módulo 10.

Drill 10 — Must, should ou may?

Como roda. O professor mostra 5 frases de spec (uma por vez) e elas classificam em obrigatório, recomendado ou opcional, justificando pela palavra ("must not: proibido, mais grave que faltar um should"). 30 segundos por frase. Misturar pegadinhas: unless, otherwise, up to, at least. Material. Frases da §2 ou variações que o professor escreve. Quando paga mais. Agosto, pra instalar a leitura de modal antes do primeiro TA.

9. Autoavaliação do módulo

1. Num enunciado, qual a diferença prática entre must, should e may? E por que must not é tão grave quanto um must faltando?
2. "Each guest may bring up to five companions." Cinco acompanhantes passam na validação ou não? Que palavra define isso?
3. O que significa unless numa frase de requisito, e qual o erro clássico de implementação que ele provoca?
4. Qual a diferença entre skimming e scanning, e qual dos dois a prova usa mais?
5. Qual é a rota dos 30 segundos pra achar uma resposta numa página de doc?
6. Num stack trace do Node, como separar o que é do seu código do que é caminho interno do framework?
7. O que diz o erro 1062 Duplicate entry for key 'uq_checkin_convidado', e por que ele pode ser um bom sinal?
8. Qual a diferença entre x is not defined e Cannot read properties of undefined?
9. O erro "Unexpected token '<'... is not valid JSON" aparece no front. Onde costuma estar a causa?
10. Fala, em inglês, três frases sobre o teu sistema: o que é, como é construído, um destaque técnico.
11. Formula em inglês, no padrão "I chose X because Y", duas decisões técnicas do teu sistema.
12. Quais são os quatro hábitos que diluem o inglês no treino sem custar hora de cronograma?

Referências do módulo

• Plano de curso, UC5 (Analisar orientações técnicas em inglês escrito) e UC7 (Elaborar orientações técnicas orais). As duas UCs de 108h que ancoram o módulo; a bibliografia da UC5 usa a série Evolve (Cambridge University Press), base de inglês comunicativo do curso.
• RFC 2119 — Key words for use in RFCs to Indicate Requirement Levels. O documento que padronizou MUST/SHOULD/MAY em especificação técnica; a lógica que a §2.1 aplica ao enunciado da prova.
• MDN Web Docs (developer.mozilla.org). Referência de JavaScript, HTML, CSS e HTTP usada nos exercícios de scanning; a anatomia de página da §3.2.
• MySQL 8.0 Reference Manual (dev.mysql.com). Fonte das funções de data e da referência de mensagens de erro do servidor (os códigos da §4.4).
• Manual do PHP (php.net). Estrutura de página usada no exercício da §3.4; seções de funções e de tratamento de erros.
• Express — documentação oficial (expressjs.com). Doc curta orientada a exemplo, usada nos drills de scanning.