-
Notifications
You must be signed in to change notification settings - Fork 0
FAQ
Perguntas que se repetem. Se a sua não está aqui, abra uma issue com o template "Dúvida de módulo" — e, se for recorrente, ela vira FAQ.
Não. O pré-requisito é programar em uma das duas. O curso ensina a
leitura cruzada — cada módulo implementa o mesmo conceito nas duas
linguagens, e o COMPARISON.md registra os trade-offs. Você termina
confortável nas duas.
Não tem prazo fixo. Referências do ROADMAP.md:
- ~10-15h/semana → 1 módulo a cada 1-2 semanas, ~4-5 meses.
- ~5h/semana → 1 módulo a cada 3-4 semanas, ~8-10 meses.
- Workshop intensivo, time numa sala → 1 módulo por dia, 13 dias úteis.
Módulo dura o que precisar. Travar é absorção em curso, não falha.
Não. A ordem é deliberada — cada módulo depende dos anteriores
(concorrência antes de resilience, observability antes de persistência).
O ROADMAP.md explica o porquê de cada posição. Pular vira castelo de
cartas no módulo seguinte.
Não durante a implementação. O curso existe porque digitar o código é o
que internaliza o conceito. IA fica fora do editor no "modo digitar".
Pode usar IA pra estudar conceito numa sessão de estudo — não pra produzir
o código de referência. Veja a seção 7 do METHODOLOGY.md (anti-padrões).
O Copilot Code Review é exceção: ele revisa o PR depois de pronto. Revisar não é gerar.
Não. O entregável é concreto e melhor que certificado: o fork completo (13 módulos, gitflow limpo, releases, board fechado), o relatório de load test do deploy, e 1+ PR mergeado em projeto OSS real. Isso é defensável numa entrevista — certificado não é.
Pra ver o trade-off, não só receber a resposta certa. O nível jr mostra
o que evitar; o diff entre jr → mid → sr é a aula. Pular direto
pro sr é decorar, não entender. Detalhe na seção 2 do METHODOLOGY.md.
Chicago testa com colaboradores reais (Testcontainers), não mocks. É mais
realista — mock não é produção — e mais difícil, porque força entender o
sistema inteiro. Mock só é permitido quando o recurso externo não pode
ser containerizado (ex: sandbox de provedor de pagamento). Tabela
comparativa na seção 1 do METHODOLOGY.md.
Quando todos os gates do ROADMAP.md estão verdes: Go e Node verdes,
README do módulo escrito com suas palavras, COMPARISON.md preenchido,
assessment respondido honestamente, e a apresentação dada sem consultar
notas. Se você não explica sem notas, o módulo não fechou.
Não. O METHODOLOGY.md é explícito: "travado é melhor que avançar sem
absorver". Travar é sinal de absorção em curso. Pode revisitar o módulo
anterior — não é regressão, é integração.
No seu fork. Você não abre PR no upstream — o fork é o seu portfolio
e o seu ambiente de trabalho completo. O CONTRIBUTING.md detalha o setup.
Porque no GitHub o autor não pode aprovar o próprio PR — e cada aluno
trabalha sozinho no próprio fork. Os rulesets usam
required_approving_review_count: 0. A revisão não some: vem dos checks
do CI, do Copilot Code Review (threads obrigatoriamente resolvidas) e da
auto-revisão consciente do próprio diff. Num time real, a aprovação humana
volta. Veja "Revisão de PR — o modelo solo" no CONTRIBUTING.md.
Depende do tempo parado (regra do ROADMAP.md):
- < 1 semana: retoma de onde parou.
- 1-4 semanas: revisa o último módulo fechado (lê o README, refaz as perguntas de calibração). Passou, segue; travou, repete o módulo.
- > 1 mês: refaz o último módulo do zero. O que foi absorvido volta rápido; o que não foi, você descobre agora.
Abra uma issue com o template "Erro no material". Se for no seu fork e você quer corrigir, abra um PR seguindo o gitflow — corrigir o material é um exercício válido de colaboração.
cloudnative-course · Wiki operacional — o material didático vive versionado no repositório.
README · SYLLABUS · METHODOLOGY · ROADMAP · CONTRIBUTING
Conteúdo sob CC BY-SA 4.0.
No repositório