NOTAS DO PROFESSOR 📖 O caminho do pedido até à entrega do site Este é o modelo mental base de toda a unidade: convém que os formandos percebam que "publicar" não é magia, mas sim ficheiros num servidor que alguém consegue alcançar. Reforçar que o domínio e o servidor são coisas distintas que se ligam através do DNS. Quando este percurso fica claro, tudo o resto (deploy, HTTPS, DNS) encaixa. 🗣️ Pontos a desenvolver oralmente • Comparar com uma morada física: domínio é o nome, DNS é a lista telefónica, servidor é a casa. • Distinguir entre alojar os ficheiros e registar o nome — são serviços e custos separados. • Mostrar ao vivo o que acontece ao escrever um endereço no browser.

NOTAS DO PROFESSOR 📖 Escolher o tipo de alojamento certo para o projecto Não existe o "melhor" hosting — existe o mais adequado ao tipo de site e ao orçamento. Vale a pena travar a tendência de ir logo para soluções caras ou complexas: a maioria dos projectos de portfólio e PME vive bem em shared ou estático. O critério de escolha deve ser sempre tráfego, tipo de site (estático vs dinâmico) e controlo necessário. 🗣️ Pontos a desenvolver oralmente • Dar exemplos concretos: um portfólio (estático) vs uma loja com milhares de produtos (VPS/cloud). • Explicar o que significa "recursos partilhados" e porque é mais barato mas mais limitado. • Ligar ao bloco seguinte: porque é que o estático mudou a forma de publicar.

NOTAS DO PROFESSOR 📖 O domínio é um aluguer, não uma compra definitiva Importa desmistificar que o domínio não é "comprado para sempre": é registado e pago anualmente, e se não for renovado fica disponível para outros. Convém também esclarecer a diferença entre registrar, alojamento e email, que muitas vezes vêm de fornecedores distintos. A escolha do TLD (.pt, .com) tem implicações de credibilidade e de público-alvo. 🗣️ Pontos a desenvolver oralmente • Falar do risco de perder um domínio por esquecimento de renovação. • Explicar requisitos do .pt (entidade portuguesa) face ao .com aberto. • Mostrar uma pesquisa de disponibilidade num registrar real.

NOTAS DO PROFESSOR 📖 Os registos DNS na prática do dia-a-dia Os registos DNS são onde os formandos mais erram na vida real, por isso vale a pena tempo nesta tabela. O registo A e o CNAME são os que vão usar para apontar um domínio a um servidor ou a uma plataforma; o MX e o TXT surgem quando configuram email. Reforçar que a propagação demorar horas explica muita da frustração de "mudei e não funciona logo". 🗣️ Pontos a desenvolver oralmente • Dar o exemplo prático de apontar um domínio para a Netlify (CNAME/A). • Explicar porque o TXT serve verificações de propriedade e SPF de email. • Aconselhar paciência e ferramentas de verificação de propagação (ex: dnschecker).

NOTAS DO PROFESSOR 📖 Porque o estático voltou a dominar O site estático parece "antigo", mas é precisamente a base do desenvolvimento web moderno (Jamstack). Como não há código a correr no servidor a cada pedido, há menos superfície de ataque e menos coisas para falhar. Convém ligar isto ao que os formandos já produzem: HTML, CSS e JS exportados de um build são exactamente o que se publica. 🗣️ Pontos a desenvolver oralmente • Distinguir "estático" de "simples": um site estático pode ser muito sofisticado. • Explicar porque é mais seguro (não há base de dados nem servidor a explorar). • Antecipar a limitação: para conteúdo dinâmico recorre-se a APIs/serviços externos.

NOTAS DO PROFESSOR 📖 As plataformas que tornam o deploy trivial Estas plataformas mudaram radicalmente a barreira de entrada: publicar deixou de exigir gerir servidores. Para o nível do curso, qualquer uma serve, e todas têm planos gratuitos generosos suficientes para projectos de portfólio. O destaque de cada uma ajuda a escolher: Vercel para Next.js, Pages para quem já vive no GitHub. 🗣️ Pontos a desenvolver oralmente • Sublinhar que HTTPS e CDN vêm de borla — antes era trabalho e custo. • Recomendar começar pela plataforma mais próxima do stack do aluno. • Mostrar, se possível, um deploy real do início ao fim em poucos minutos.

NOTAS DO PROFESSOR 📖 Ligar Git ao deploy: o fluxo profissional Este slide fecha o ciclo entre a unidade de versionamento e a de publicação: o mesmo `git push` que guarda o trabalho também o coloca no ar. Os previews por branch são um conceito poderoso que muitos juniores desconhecem — permitem mostrar uma versão a um cliente antes de a tornar oficial. O rollback fácil tira o medo de publicar. 🗣️ Pontos a desenvolver oralmente • Reforçar que automatizar o deploy elimina passos manuais propensos a erro. • Explicar o valor do preview por PR no trabalho em equipa e com clientes. • Dar segurança: se algo correr mal, reverter é um clique.

NOTAS DO PROFESSOR 📖 A sequência concreta de um primeiro deploy Esta é a checklist que os formandos vão seguir no exercício prático. Os dois pontos onde mais tropeçam são o comando de build e a pasta de output — vale a pena insistir que estes dependem da ferramenta usada (ex: `dist`, `build`, `public`). Quando a ligação ao repositório está feita, o resto é quase automático. 🗣️ Pontos a desenvolver oralmente • Demonstrar onde se encontram o comando de build e a pasta de output de cada projecto. • Avisar para o erro comum de apontar para a pasta errada (página em branco/404). • Mostrar a ligação do domínio personalizado e a activação automática do HTTPS.

NOTAS DO PROFESSOR 📖 O método clássico que ainda vão encontrar Mesmo na era do deploy contínuo, muitos clientes de PME têm alojamento partilhado com cPanel, por isso saber subir por FTP é uma competência ainda relevante. O ponto fulcral é a distinção entre FTP e SFTP: o primeiro envia tudo em texto simples, incluindo a password. A pasta pública (`public_html`) é onde o conteúdo se torna visível. 🗣️ Pontos a desenvolver oralmente • Insistir em usar sempre SFTP por segurança das credenciais. • Mostrar o FileZilla a ligar e a arrastar ficheiros para `public_html`. • Comparar este método manual com o deploy contínuo do bloco anterior.

NOTAS DO PROFESSOR 📖 O painel que centraliza a gestão do alojamento O cPanel é o "canivete suíço" do alojamento partilhado e os formandos vão encontrá-lo em quase qualquer fornecedor português. Não é preciso decorar tudo — basta saber que ali se gere ficheiros, bases de dados, email e SSL num só sítio. Saber navegar este painel dá autonomia para resolver problemas de clientes sem depender de terceiros. 🗣️ Pontos a desenvolver oralmente • Fazer um passeio guiado pelas secções mais usadas (ficheiros, BD, SSL). • Ligar à instalação de WordPress, muito comum neste tipo de alojamento. • Reforçar a importância da secção de backups.

NOTAS DO PROFESSOR 📖 Quando o site deixa de ser só ficheiros Aqui contrasta-se o site estático com o dinâmico: assim que há uma base de dados, há credenciais a guardar e um novo ponto a fazer backup. O WordPress é o exemplo perfeito porque junta ficheiros e BD, e perder a base de dados significa perder todo o conteúdo. O phpMyAdmin é a ferramenta que vão usar para criar e gerir essas bases. 🗣️ Pontos a desenvolver oralmente • Explicar que o backup do site dinâmico tem duas partes: ficheiros e base de dados. • Avisar sobre a segurança das credenciais da BD (nunca em repositórios públicos). • Demonstrar a criação de uma BD e utilizador no cPanel/phpMyAdmin.

NOTAS DO PROFESSOR 📖 HTTPS deixou de ser opcional Convém transmitir que HTTPS não é um "extra de segurança" mas um requisito mínimo: os browsers avisam o utilizador quando um site não o tem, e o Google penaliza no ranking. O cadeado é o sinal visível que os clientes reconhecem. Sem HTTPS, qualquer dado de formulário viaja exposto na rede. 🗣️ Pontos a desenvolver oralmente • Mostrar o aviso "não seguro" do browser num site sem HTTPS. • Ligar à confiança do utilizador e à conversão (ninguém compra num site inseguro). • Antecipar que, nas plataformas estáticas, isto é automático e gratuito.

NOTAS DO PROFESSOR 📖 O certificado que tornou o HTTPS universal O Let's Encrypt foi a peça que democratizou o HTTPS: antes, os certificados eram pagos e renovados à mão, agora são gratuitos e automáticos. Isto explica porque deixou de haver desculpa para não ter HTTPS. Nas plataformas estáticas, os formandos nem precisam de pensar nisto — vem resolvido de origem. 🗣️ Pontos a desenvolver oralmente • Explicar a diferença entre SSL/TLS na prática (o protocolo que encripta). • Sublinhar a renovação automática como vantagem face ao modelo antigo manual. • Mencionar quando ainda se justificam certificados pagos (validação alargada).

NOTAS DO PROFESSOR 📖 Ter certificado não basta — é preciso forçar Um erro comum é instalar o certificado mas deixar o site acessível por HTTP na mesma. O redireccionamento garante que ninguém fica numa ligação insegura, e o HSTS reforça isso ao nível do browser. O "mixed content" é a armadilha clássica: uma imagem ou script carregado por HTTP quebra o cadeado de uma página segura. 🗣️ Pontos a desenvolver oralmente • Mostrar o aviso de "mixed content" e como detectá-lo na consola do browser. • Explicar o HSTS e a sua implicação (depois de activo, não há volta a HTTP). • Verificar que todos os links e recursos internos usam HTTPS ou caminhos relativos.

NOTAS DO PROFESSOR 📖 Camadas extra de defesa via cabeçalhos HTTP Estes cabeçalhos são uma camada de segurança que muitos sites ignoram, mas que protege contra ataques reais como XSS e clickjacking. Não é preciso que os formandos memorizem a sintaxe — basta saber que existem e para que servem, e que se configuram no servidor ou na plataforma de alojamento. Ferramentas como o securityheaders.com dão uma nota ao site. 🗣️ Pontos a desenvolver oralmente • Explicar de forma simples cada ameaça (XSS, clickjacking, MIME sniffing). • Mostrar como avaliar um site real numa ferramenta de auditoria de cabeçalhos. • Referir que nas plataformas estáticas isto se define num ficheiro de configuração.

NOTAS DO PROFESSOR 📖 Velocidade como factor de negócio A CDN e a cache são os dois mecanismos que mais influenciam a velocidade percebida do site. A ideia-chave a transmitir é que a velocidade não é vaidade técnica: afecta diretamente a taxa de abandono e o ranking no Google. Um utilizador a 5 segundos de espera já desistiu; a CDN aproxima fisicamente o conteúdo de quem o pede. 🗣️ Pontos a desenvolver oralmente • Explicar a CDN com o exemplo de servir o site a partir do servidor mais próximo. • Distinguir cache do browser de cache da CDN. • Ligar a velocidade a dados de negócio (abandono, conversão, SEO).

NOTAS DO PROFESSOR 📖 Optimizar com critério e com medição Estas optimizações dão ganhos reais, mas devem ser guiadas por medição e não por intuição. As imagens são quase sempre o maior culpado do peso de uma página, por isso WebP/AVIF e lazy load são as melhores apostas iniciais. O Lighthouse, integrado no DevTools, transforma "o site está lento" numa lista concreta de acções. 🗣️ Pontos a desenvolver oralmente • Demonstrar uma auditoria Lighthouse e ler o relatório com os formandos. • Mostrar a diferença de peso entre um JPEG pesado e a versão WebP. • Explicar o lazy load (carregar imagens só quando entram no ecrã).

NOTAS DO PROFESSOR 📖 Ajudar os motores a perceber o site O SEO técnico é a parte do SEO que está nas mãos de quem constrói o site, ao contrário do conteúdo ou dos backlinks. A mensagem central é que os motores de busca precisam de ajuda para encontrar e interpretar as páginas — o sitemap diz-lhes o que existe, o robots.txt o que podem ver. URLs limpas beneficiam tanto o motor como o humano que lê o endereço. 🗣️ Pontos a desenvolver oralmente • Mostrar um sitemap.xml e um robots.txt reais e explicá-los linha a linha. • Contrastar uma URL limpa com uma cheia de parâmetros. • Distinguir SEO técnico de SEO de conteúdo (fora do âmbito desta unidade).

NOTAS DO PROFESSOR 📖 As meta tags que controlam a primeira impressão O title e a description são o que aparece nos resultados de pesquisa, logo influenciam se alguém clica. O Open Graph é frequentemente esquecido, mas é o que define a imagem e o texto que surgem quando o link é partilhado no Facebook, WhatsApp ou LinkedIn. Um site sem og:image partilha-se com um cartão feio e pouco apelativo. 🗣️ Pontos a desenvolver oralmente • Mostrar como um mesmo link aparece com e sem Open Graph configurado. • Usar um validador de Open Graph para pré-visualizar a partilha. • Reforçar que cada página deve ter title e description próprios, não repetidos.

NOTAS DO PROFESSOR 📖 Um backup só vale se restaurar A frase-chave deste slide é que um backup que não se consegue restaurar não vale nada — muitos só descobrem que o backup estava partido no dia em que precisam dele. A regra de guardar offsite protege contra a falha do próprio servidor. O Git cobre o código, mas não os dados gerados em produção (base de dados, uploads de utilizadores). 🗣️ Pontos a desenvolver oralmente • Insistir no hábito de testar o restauro, não só de fazer o backup. • Explicar porque guardar o backup no mesmo servidor é arriscado. • Distinguir o que o Git cobre (código) do que não cobre (dados de produção).

NOTAS DO PROFESSOR 📖 Detectar problemas antes do cliente A monitorização de uptime é uma daquelas coisas que parece pequena mas faz toda a diferença na relação com o cliente: ser avisado de que o site caiu permite agir antes que o cliente ligue zangado. Estes serviços testam o site de minuto a minuto e alertam por email ou SMS. A percentagem de uptime é também um argumento comercial. 🗣️ Pontos a desenvolver oralmente • Mostrar a configuração de um monitor gratuito (ex: UptimeRobot). • Explicar o que significa "99,9% de uptime" em horas de paragem por ano. • Reforçar o valor reputacional de reagir antes do cliente reparar.

NOTAS DO PROFESSOR 📖 Medir para decidir, respeitando a privacidade O analytics fecha o ciclo: depois de publicar, medir como as pessoas usam o site permite melhorá-lo com base em dados e não em opiniões. Vale a pena introduzir alternativas focadas na privacidade (Plausible, Matomo) face ao Google Analytics. O ponto não-negociável é o RGPD: rastrear utilizadores exige consentimento de cookies. 🗣️ Pontos a desenvolver oralmente • Explicar métricas básicas: visitas, origem do tráfego, páginas mais vistas, conversões. • Comparar Google Analytics com alternativas mais respeitadoras da privacidade. • Ligar ao RGPD e à obrigatoriedade do banner de consentimento.

NOTAS DO PROFESSOR 📖 Um site é um organismo vivo A ideia a deixar é que publicar não é o fim do trabalho — é o início de um ciclo de manutenção. Plugins e dependências desactualizados são a principal porta de entrada de ataques, sobretudo em WordPress. Links partidos e conteúdo velho corroem a credibilidade lentamente, por isso convém ter uma rotina de revisão. 🗣️ Pontos a desenvolver oralmente • Relacionar actualizações com segurança (vulnerabilidades conhecidas em versões antigas). • Lembrar a renovação de domínio e certificados quando não são automáticos. • Propor uma rotina simples de manutenção mensal/trimestral ao cliente.