Translate

Mostrar mensagens com a etiqueta html. Mostrar todas as mensagens
Mostrar mensagens com a etiqueta html. Mostrar todas as mensagens

segunda-feira, 3 de agosto de 2026

ATS Friendly — O Dia em que Patrick Jane Investigou o Seu Currículo COBOL

Bellacosa Mainframe apresenta o ats friendly

 

☕ Um Café no Bellacosa Mainframe

ATS Friendly — O Dia em que Patrick Jane Investigou o Seu Currículo COBOL

Imagine a seguinte cena.

Uma grande empresa publica uma vaga para programador COBOL iniciante. O anúncio parece ter sido escrito especialmente para você:

  • COBOL;

  • JCL;

  • Db2;

  • CICS;

  • z/OS;

  • Git;

  • noções de DevOps;

  • vontade de aprender;

  • capacidade de trabalhar em equipe.

Você lê tudo, ajeita o currículo, salva o arquivo com um nome elegante e clica em “Enviar candidatura”.

Silêncio.

Nenhuma mensagem.

Nenhum telefonema.

Nenhuma entrevista.

Nada.

Você olha para a tela e pensa:

— Será que o recrutador não gostou de mim?

Mas existe uma possibilidade ainda mais intrigante: talvez o recrutador nunca tenha visto o seu currículo.

Antes que uma pessoa de Recursos Humanos leia sua experiência, seus cursos, seus projetos e suas certificações, existe uma boa chance de que o documento precise passar por uma espécie de porteiro eletrônico.

Esse porteiro atende pelo nome de ATS.

E, ao contrário de Patrick Jane, personagem da série The Mentalist, o ATS não observa seus gestos, não analisa seu tom de voz e não percebe quando você está nervoso.

Ele observa palavras.

Ele procura padrões.

Ele classifica informações.

Ele tenta entender se o seu currículo combina com a vaga.

Em outras palavras, o ATS é uma espécie de programa batch executado antes da entrevista.

Se a entrada estiver organizada, o processamento continua.

Se o layout estiver confuso, as palavras-chave estiverem ausentes e as informações importantes estiverem escondidas em caixas de texto, gráficos ou imagens, o job pode terminar com um elegante e silencioso:

COND CODE 0008
CANDIDATO NÃO LOCALIZADO

Bem-vindo ao mistério do currículo ATS Friendly.



1. O que significa ATS Friendly?

A expressão ATS Friendly significa que um currículo foi preparado para ser facilmente lido, interpretado e classificado por um Applicant Tracking System.

Em português, podemos traduzir ATS como:

Sistema de Rastreamento de Candidatos.

Esses sistemas são utilizados para ajudar empresas e recrutadores a:

  • receber currículos;

  • organizar candidaturas;

  • localizar profissionais;

  • comparar perfis;

  • pesquisar competências;

  • acompanhar etapas do processo seletivo;

  • filtrar candidatos conforme os requisitos de uma vaga.

Para um programador COBOL, a analogia é simples.

O ATS funciona como um processo que recebe um arquivo de entrada, tenta interpretar os campos e grava os resultados em uma base de dados.

Seu currículo é o arquivo de entrada.

O anúncio da vaga é a regra de validação.

As palavras-chave são os campos utilizados na comparação.

O recrutador é o usuário que consulta o resultado final.

Se o ATS consegue identificar corretamente seu nome, cargo, experiência, tecnologias e formação, seu currículo foi processado com sucesso.

Quando isso não acontece, informações importantes podem simplesmente desaparecer durante a leitura automática.


2. O ATS não é um vilão

Existe uma tendência de imaginar o ATS como uma inteligência artificial maligna sentada diante de milhares de currículos, eliminando candidatos por diversão.

Na prática, a ideia é menos dramática.

Imagine que uma empresa receba 1.500 candidaturas para uma única vaga.

Seria difícil para uma equipe pequena ler manualmente todos os documentos em pouco tempo. O ATS ajuda a organizar esse volume.

Ele permite que o recrutador procure, por exemplo:

COBOL AND CICS AND DB2

Ou:

MAINFRAME AND JCL AND Z/OS

Ou ainda:

COBOL AND GIT AND DEVOPS

O ATS também pode estruturar informações como:

  • nome do candidato;

  • cidade;

  • e-mail;

  • telefone;

  • empresas anteriores;

  • cargos ocupados;

  • datas;

  • formação;

  • certificações;

  • competências técnicas.

O problema não está necessariamente no sistema.

O problema aparece quando o currículo foi criado apenas para impressionar visualmente uma pessoa, mas não para ser compreendido por uma máquina.

Patrick Jane diria:

— O sistema não está escondendo a verdade. Ele está apenas interpretando os sinais que você deixou.


3. O currículo como um arquivo de entrada

Para compreender um currículo ATS Friendly, pense em um arquivo sequencial utilizado por um programa COBOL.

Imagine este layout:

01 REGISTRO-CANDIDATO.
   05 NOME-CANDIDATO        PIC X(50).
   05 CARGO-PRETENDIDO      PIC X(40).
   05 EXPERIENCIA           PIC X(500).
   05 COMPETENCIAS          PIC X(300).
   05 FORMACAO              PIC X(200).
   05 CERTIFICACOES         PIC X(300).

Agora imagine que alguém decida colocar o nome dentro de uma imagem, as competências dentro de um gráfico, as datas dentro de um rodapé e o telefone em uma caixa lateral.

Para uma pessoa, o currículo pode parecer bonito.

Para o ATS, o registro pode chegar assim:

NOME-CANDIDATO: EM BRANCO
CARGO-PRETENDIDO: NÃO IDENTIFICADO
COMPETENCIAS: PARCIAL
DATAS: INCONSISTENTES
TELEFONE: NÃO LOCALIZADO

Esse é o coração da questão.

Um currículo ATS Friendly não precisa ser feio.

Ele precisa ser estruturado.

A informação deve estar no lugar certo.

Os títulos devem ser claros.

As palavras devem estar escritas como texto.

O documento deve permitir que o sistema entenda sua história profissional sem depender de interpretação visual.



4. O primeiro princípio: simplicidade operacional

No mainframe, simplicidade não significa falta de poder.

Um JCL limpo, bem indentado e corretamente documentado pode executar uma tarefa crítica durante décadas.

Com o currículo acontece a mesma coisa.

Um currículo simples pode ser extremamente eficiente.

O formato mais seguro costuma utilizar:

  • uma única coluna;

  • títulos tradicionais;

  • texto alinhado;

  • listas simples;

  • datas claras;

  • nomes completos das tecnologias;

  • poucas variações de fonte;

  • espaçamento consistente.

Evite transformar o currículo em um pôster publicitário.

O objetivo não é criar uma propaganda de perfume.

O objetivo é facilitar a leitura técnica e humana.

O recrutador precisa encontrar rapidamente as informações relevantes.

O ATS também.



5. Layout de uma coluna

Currículos com duas ou três colunas podem causar problemas de interpretação.

Imagine que o ATS leia primeiro toda a coluna da esquerda e depois toda a coluna da direita. Informações que visualmente estavam relacionadas podem ser reorganizadas de forma incorreta.

Por exemplo:

IBM                     COBOL
Analista de Sistemas    CICS
2022 – Atual            Db2

Visualmente, isso pode parecer perfeito.

Mas o sistema pode interpretar:

IBM COBOL Analista de Sistemas CICS 2022 Atual Db2

O texto perde a estrutura.

Para evitar isso, prefira:

IBM
Analista de Sistemas
Janeiro de 2022 – Atual

Tecnologias:
COBOL, CICS, Db2, JCL e z/OS.

Simples.

Direto.

Sem mágica.

Patrick Jane observaria a página por alguns segundos e diria:

— A resposta estava diante de você. O excesso de design estava escondendo a informação.


6. Títulos tradicionais são seus aliados

Um ATS procura padrões conhecidos.

Por isso, use títulos como:

  • Resumo Profissional;

  • Objetivo Profissional;

  • Experiência Profissional;

  • Formação Acadêmica;

  • Certificações;

  • Competências Técnicas;

  • Idiomas;

  • Projetos;

  • Cursos Complementares.

Evite títulos criativos demais, como:

  • Minha Jornada;

  • Meus Superpoderes;

  • O Que Eu Faço de Melhor;

  • Minha Caixa de Ferramentas;

  • Aventuras Profissionais;

  • Grandes Batalhas.

Esses títulos podem ser simpáticos em um portfólio, mas não são ideais em um currículo destinado a processos automatizados.

Um sistema procura “Experiência Profissional”.

Ele pode não compreender que “Minhas Grandes Batalhas” significa a mesma coisa.

No Bellacosa Mainframe, criatividade é muito bem-vinda.

Mas até um Jedi precisa preencher corretamente o layout do arquivo.


7. Palavras-chave: o vocabulário secreto da vaga

As palavras-chave são um dos elementos mais importantes do currículo ATS Friendly.

Suponha que a vaga mencione:

  • Enterprise COBOL;

  • CICS Transaction Server;

  • Db2 for z/OS;

  • JCL;

  • VSAM;

  • Git;

  • Jenkins;

  • Agile;

  • APIs REST;

  • z/OS Connect.

Seu currículo deve incluir os termos que realmente fazem parte da sua experiência.

Não basta escrever apenas:

Experiência em tecnologias mainframe.

Essa frase é genérica demais.

É melhor escrever:

Experiência acadêmica e prática com COBOL, JCL, Db2 for z/OS, CICS, VSAM e ambiente z/OS.

Ou:

Desenvolvimento de programas COBOL para processamento batch, utilizando JCL, datasets sequenciais e arquivos VSAM.

Ou:

Projeto de integração entre aplicação COBOL e API REST por meio de conceitos de z/OS Connect.

Perceba que as palavras-chave aparecem dentro de um contexto real.

Isso é importante.

O currículo não deve parecer uma lista aleatória de tecnologias.

Ele deve mostrar como você utilizou ou estudou cada competência.



8. Não pratique keyword stuffing

Existe uma técnica ruim conhecida como keyword stuffing, que consiste em repetir palavras-chave de forma exagerada para tentar enganar sistemas de busca.

No currículo, isso poderia parecer assim:

COBOL COBOL COBOL CICS DB2 COBOL JCL CICS DB2 MAINFRAME MAINFRAME COBOL.

Isso não ajuda.

Além de tornar o texto artificial, pode prejudicar a leitura humana.

O recrutador quer compreender:

  • o que você sabe;

  • onde aprendeu;

  • como utilizou;

  • qual resultado alcançou;

  • qual seu nível de contato com a tecnologia.

A palavra-chave precisa aparecer naturalmente.

Patrick Jane não se impressionaria com repetições.

Ele perguntaria:

— Você realmente conhece CICS ou apenas escreveu CICS sete vezes?

  • O que é keyword stuffing

https://eljefemidnightlunch.blogspot.com/2013/01/csi-new-york-unidade-de-crimes-digitais.html


9. Como adaptar o currículo para uma vaga

Um dos maiores erros é enviar exatamente o mesmo currículo para todas as oportunidades.

Um currículo-base é importante, mas ele deve ser ajustado conforme a vaga.

Considere duas oportunidades.

Vaga A — Programador COBOL Batch

Requisitos:

  • COBOL;

  • JCL;

  • VSAM;

  • datasets;

  • SORT;

  • processamento batch.

Seu currículo deve destacar:

  • programas batch;

  • leitura e gravação de arquivos;

  • JCL;

  • SORT;

  • IDCAMS;

  • VSAM;

  • tratamento de retorno;

  • análise de ABEND.

Vaga B — Programador COBOL CICS

Requisitos:

  • COBOL;

  • CICS;

  • BMS;

  • Db2;

  • transações online;

  • COMMAREA;

  • mapas 3270.

Nesse caso, o currículo deve destacar:

  • CICS;

  • programas online;

  • LINK;

  • XCTL;

  • RETURN;

  • COMMAREA;

  • BMS;

  • Db2;

  • tratamento de erros SQL.

Você continua sendo a mesma pessoa.

Mas muda o foco da apresentação.

Isso não é manipulação.

É relevância.

Em programação, você não envia todos os campos de um banco de dados quando a API precisa apenas de cinco.

No currículo, você também prioriza aquilo que atende à consulta.


10. O resumo profissional

O resumo profissional é uma das primeiras áreas do currículo.

Ele deve apresentar rapidamente:

  • quem você é;

  • qual área busca;

  • quais tecnologias conhece;

  • qual valor oferece;

  • quais objetivos profissionais possui.

Para um programador COBOL iniciante, um exemplo poderia ser:

Profissional em formação na área de desenvolvimento IBM Mainframe, com conhecimentos em COBOL, JCL, Db2, VSAM e ambiente z/OS. Experiência prática em projetos acadêmicos envolvendo processamento batch, manipulação de arquivos e lógica estruturada. Busco oportunidade como programador COBOL júnior para aplicar conhecimentos técnicos, ampliar experiência em sistemas corporativos e contribuir com manutenção e modernização de aplicações críticas.

Observe que o resumo contém palavras-chave, mas também forma uma narrativa.

Não é apenas uma lista.

É uma apresentação.


11. Experiência profissional para quem ainda está começando

Muitos iniciantes dizem:

— Não tenho experiência. Meu currículo ficará vazio.

Isso não é verdade.

Experiência não significa apenas emprego formal.

Você pode incluir:

  • projetos acadêmicos;

  • bootcamps;

  • laboratórios;

  • desafios de código;

  • trabalho voluntário;

  • projetos pessoais;

  • exercícios relevantes;

  • repositórios GitHub;

  • participação em comunidades;

  • cursos com atividades práticas.

Por exemplo:

Projeto Acadêmico — Sistema de Cadastro em COBOL

Desenvolvimento de aplicação batch para inclusão, consulta e atualização de registros. Utilização de COBOL, JCL e arquivo sequencial. Implementação de validação de dados, tratamento de erros e geração de relatório de saída.

Outro exemplo:

Projeto Pessoal — Controle de Clientes com VSAM

Criação de programa COBOL para leitura e atualização de arquivo VSAM KSDS. Definição do cluster por meio de IDCAMS e execução do programa com JCL.

Outro:

Laboratório — Integração COBOL e Db2

Criação de consultas SQL embarcadas em programa COBOL, com tratamento de SQLCODE e exibição de mensagens de retorno.

Esses projetos demonstram aplicação prática.

O importante é ser honesto.

Não transforme um exercício de curso em cinco anos de experiência bancária.

Patrick Jane perceberia o exagero antes mesmo de você terminar a frase.


12. Use verbos de ação

As descrições ficam mais fortes quando começam com verbos objetivos.

Exemplos:

  • desenvolvi;

  • implementei;

  • analisei;

  • documentei;

  • corrigi;

  • automatizei;

  • testei;

  • integrei;

  • configurei;

  • monitorei;

  • otimizei;

  • participei;

  • apoiei;

  • criei;

  • mantive.

Compare:

Conhecimento de COBOL.

Com:

Desenvolvi programas COBOL para leitura, validação e processamento de arquivos sequenciais.

Compare:

Curso de JCL.

Com:

Criei e executei jobs JCL com etapas de compilação, linkedição e execução de programas COBOL.

Compare:

Noções de Db2.

Com:

Implementei consultas SQL em programas COBOL, utilizando SELECT, INSERT, UPDATE e tratamento de SQLCODE.

A segunda versão demonstra ação.


13. Competências técnicas

A seção de competências deve ser clara e organizada.

Exemplo:

Competências Técnicas

Linguagens:
COBOL, SQL e Python básico.

IBM Mainframe:
z/OS, TSO/ISPF, SDSF, JCL, VSAM, CICS e Db2.

Ferramentas:
Git, GitHub, Visual Studio Code e IBM Z Open Editor.

Conceitos:
Processamento batch, arquivos sequenciais, lógica estruturada, APIs REST e DevOps.

Essa estrutura ajuda tanto o ATS quanto o recrutador.

Evite barras gráficas como:

COBOL ████████ 80%
JCL  ██████ 60%
DB2  █████ 50%

Esses percentuais são subjetivos.

O que significa possuir 80% de COBOL?

Você sabe 80% de todas as instruções?

Domina 80% do compilador?

Resolve 80% dos ABENDs?

Conhece 80% do Language Environment?

Melhor indicar o contexto:

COBOL — projetos acadêmicos com processamento batch, arquivos sequenciais e VSAM.

Muito mais informativo.


14. Fontes e formatação

Utilize fontes comuns e fáceis de ler, como:

  • Arial;

  • Calibri;

  • Helvetica;

  • Verdana;

  • Times New Roman.

O tamanho pode variar, mas normalmente:

  • nome: entre 16 e 20 pontos;

  • títulos: entre 12 e 14 pontos;

  • corpo do texto: entre 10 e 12 pontos.

Não utilize cinco fontes diferentes.

Não transforme o currículo em um catálogo de estilos.

Um mainframe não precisa de luzes piscando para provar que processa milhões de transações.

Seu currículo também não.


15. Imagens, ícones e fotografias

Em currículos ATS Friendly, é mais seguro evitar:

  • fotografia;

  • logotipos;

  • ícones;

  • gráficos;

  • infográficos;

  • elementos decorativos;

  • textos dentro de imagens.

O problema não é apenas estético.

Um ícone de telefone pode não ser identificado como telefone.

Um ícone de e-mail pode não ser identificado como e-mail.

Por isso, escreva:

Telefone: +55 11 99999-9999
E-mail: nome@email.com
LinkedIn: linkedin.com/in/nome
GitHub: github.com/nome

Não dependa exclusivamente de símbolos.

Quanto à foto, sua inclusão depende do país, do mercado e da cultura local. Em muitos processos corporativos e internacionais, ela não é necessária.

Quando o objetivo principal é compatibilidade com ATS, a ausência de foto costuma simplificar o documento.


16. Cabeçalho e rodapé

Evite colocar informações críticas apenas no cabeçalho ou rodapé.

Alguns sistemas podem ignorar ou interpretar incorretamente essas áreas.

Não esconda seu telefone no rodapé.

Não coloque o e-mail apenas no cabeçalho.

Não deixe o LinkedIn em uma caixa flutuante.

Mantenha os contatos no corpo principal do documento, logo abaixo do nome.

Exemplo:

Vagner Bellacosa
Analista de Sistemas IBM Mainframe

Itatiba, São Paulo, Brasil
Telefone: +55...
E-mail: ...
LinkedIn: ...
GitHub: ...

17. Datas claras e consistentes

As datas devem seguir um padrão.

Exemplos adequados:

Janeiro de 2022 – Atual
01/2022 – Atual
2022 – 2025

Evite misturar formatos:

Jan 2022
02-23
Verão de 2024
Há três anos

O ATS trabalha melhor com consistência.

Além disso, datas claras facilitam a compreensão da evolução profissional.


18. PDF ou DOCX?

Os formatos mais comuns são:

  • DOCX;

  • PDF.

O DOCX costuma ser bem interpretado por diversos sistemas.

O PDF também pode funcionar muito bem, desde que tenha sido criado a partir de texto real.

Evite PDFs gerados como imagem.

Uma forma simples de testar é tentar selecionar o texto com o mouse.

Se você consegue copiar e colar o conteúdo normalmente, o documento provavelmente contém texto real.

Se toda a página se comporta como uma fotografia, o ATS pode ter dificuldade.

Quando a vaga informa um formato específico, siga exatamente a instrução.

Se ela pede DOCX, envie DOCX.

Se pede PDF, envie PDF.

Ignorar esse detalhe é como submeter um job com o nome errado do dataset e esperar que o sistema adivinhe.


19. Nome do arquivo

Nunca envie:

curriculo_final_novo_agora_vai_versao3.pdf

Use um nome profissional:

Vagner_Bellacosa_Curriculo_COBOL.pdf

Ou:

Vagner_Bellacosa_Mainframe_Developer.docx

O nome do arquivo também comunica organização.

Imagine o recrutador baixando 80 currículos chamados “curriculo.pdf”.

Seu nome precisa estar visível.


20. Ortografia e consistência

Erros de escrita prejudicam a credibilidade.

Revise:

  • nomes de tecnologias;

  • nomes de empresas;

  • datas;

  • cargos;

  • acentuação;

  • pontuação;

  • capitalização.

Escreva corretamente:

  • COBOL;

  • JCL;

  • CICS;

  • Db2;

  • z/OS;

  • VSAM;

  • GitHub;

  • Jenkins;

  • IBM Z.

Evite variações aleatórias como:

Cobol
COBOL
cobol
CÓBOL

Padronização demonstra cuidado.

Em ambientes corporativos, pequenos detalhes importam.

Uma letra errada em um dataset pode parar um job.

Uma letra errada em uma competência pode impedir que uma busca encontre seu perfil.


21. LinkedIn e currículo devem conversar

Seu currículo e seu LinkedIn não precisam ser idênticos, mas devem ser coerentes.

Se o currículo diz que você trabalhou de 2020 a 2024 em determinada empresa, e o LinkedIn informa 2021 a 2023, surge uma inconsistência.

Se o currículo apresenta experiência com COBOL e o LinkedIn não menciona mainframe em nenhum lugar, o recrutador pode ter dúvidas.

Mantenha alinhados:

  • cargos;

  • empresas;

  • períodos;

  • tecnologias;

  • certificações;

  • formação;

  • projetos principais.

O LinkedIn pode ser mais detalhado.

O currículo deve ser mais focado.

Um é o arquivo completo.

O outro é a consulta otimizada.


22. GitHub para o programador COBOL iniciante

Um GitHub organizado pode compensar parcialmente a falta de experiência formal.

Você pode criar repositórios com:

  • programas COBOL;

  • JCLs;

  • exemplos de arquivos;

  • documentação;

  • desafios;

  • diagramas;

  • exercícios de Db2;

  • exemplos de CICS;

  • scripts auxiliares;

  • projetos de bootcamp.

Cada projeto deve possuir um README explicando:

  • objetivo;

  • tecnologias;

  • estrutura;

  • como executar;

  • exemplos de entrada;

  • exemplos de saída;

  • aprendizados.

No currículo, escreva:

GitHub: github.com/seuusuario

E destaque projetos relevantes:

Projeto: Cloud Status Checker em Python
Implementação de validador de status de CPU, memória e rede, com tratamento de entradas inválidas e classificação de operação normal, alerta ou incidente.

Mesmo um projeto simples pode demonstrar:

  • lógica;

  • validação;

  • clareza;

  • tratamento de erros;

  • documentação;

  • disciplina.



23. Passo a passo para criar um currículo ATS Friendly

Passo 1 — Leia a vaga como um investigador

Não envie o currículo imediatamente.

Leia com atenção.

Marque:

  • cargo;

  • tecnologias;

  • nível de experiência;

  • responsabilidades;

  • requisitos obrigatórios;

  • requisitos desejáveis;

  • idioma;

  • localização;

  • modelo de trabalho.

Crie uma lista das palavras mais importantes.

Exemplo:

COBOL
JCL
CICS
DB2
VSAM
GIT
AGILE
PRODUÇÃO
MANUTENÇÃO

Passo 2 — Compare com sua experiência

Separe em três grupos:

Conheço e já usei
Conheço por estudo
Ainda não conheço

Seja honesto.

Para aquilo que você estudou, use expressões como:

  • conhecimento acadêmico;

  • experiência em laboratório;

  • projeto pessoal;

  • treinamento prático;

  • familiaridade;

  • noções.

Passo 3 — Ajuste o resumo profissional

Inclua o cargo desejado e as competências mais relacionadas.

Passo 4 — Reorganize a experiência

Coloque primeiro as atividades mais relevantes para a vaga.

Passo 5 — Inclua palavras-chave naturalmente

Utilize as palavras da vaga quando elas forem verdadeiras em seu perfil.

Passo 6 — Remova elementos arriscados

Elimine:

  • colunas;

  • caixas de texto;

  • gráficos;

  • estrelas;

  • ícones excessivos;

  • fotografias desnecessárias.

Passo 7 — Revise o arquivo

Copie todo o conteúdo e cole em um editor de texto simples.

Observe se a ordem permanece compreensível.

Se o texto ficar embaralhado, o ATS também pode ter dificuldade.

Passo 8 — Salve corretamente

Use o formato solicitado e um nome profissional.

Passo 9 — Compare novamente com a vaga

Pergunte:

  • COBOL aparece?

  • JCL aparece?

  • O cargo está claro?

  • Os projetos estão descritos?

  • O nível de experiência está honesto?

  • O telefone está visível?

  • O GitHub está presente?

  • As datas estão consistentes?

Passo 10 — Envie e registre

Crie uma planilha com:

  • empresa;

  • vaga;

  • data;

  • versão do currículo;

  • link;

  • status;

  • retorno;

  • próxima ação.

Isso evita enviar arquivos diferentes sem controle.

No mainframe, chamamos isso de rastreabilidade.

No mundo da carreira, chamamos de não enlouquecer.



24. Modelo de estrutura ATS Friendly

NOME COMPLETO
Cargo ou área de interesse

Cidade – Estado – País
Telefone
E-mail
LinkedIn
GitHub

RESUMO PROFISSIONAL

Texto de quatro a seis linhas apresentando experiência, conhecimentos, tecnologias e objetivo profissional.

COMPETÊNCIAS TÉCNICAS

Linguagens:
COBOL, SQL, Python.

Mainframe:
z/OS, JCL, CICS, Db2, VSAM, TSO/ISPF, SDSF.

Ferramentas:
Git, GitHub, VS Code, IBM Z Open Editor.

EXPERIÊNCIA PROFISSIONAL

Empresa
Cargo
Mês/Ano – Mês/Ano

- Atividade ou resultado.
- Tecnologia utilizada.
- Problema resolvido.
- Participação no projeto.

PROJETOS

Nome do projeto
Tecnologias

- Objetivo.
- Implementação.
- Resultado.

FORMAÇÃO ACADÊMICA

Curso
Instituição
Ano de conclusão ou previsão.

CERTIFICAÇÕES E CURSOS

Nome da certificação ou curso
Instituição
Ano.

IDIOMAS

Português — Nativo
Inglês — Intermediário

25. O currículo humano e o currículo robô

Um bom currículo precisa agradar a dois públicos.

O primeiro é a máquina.

Ela deseja:

  • estrutura;

  • palavras-chave;

  • títulos conhecidos;

  • dados claros;

  • formatação simples.

O segundo é o ser humano.

Ele deseja:

  • clareza;

  • coerência;

  • resultados;

  • contexto;

  • personalidade profissional;

  • honestidade;

  • facilidade de leitura.

O erro é otimizar apenas para um lado.

Um currículo cheio de palavras-chave, mas sem narrativa, parece artificial.

Um currículo visualmente deslumbrante, mas ilegível por sistemas, pode desaparecer no processo.

O equilíbrio é a resposta.


26. Easter eggs escondidos no recrutamento

Easter egg 1 — O currículo não consegue substituir competência

Nenhuma técnica de ATS transforma alguém em especialista.

O currículo abre a porta.

A entrevista testa o conhecimento.

O trabalho confirma a experiência.

Easter egg 2 — O ATS não é uma máquina de aprovação

Ter um currículo ATS Friendly não garante entrevista.

Ele apenas reduz a chance de ser eliminado por problemas de estrutura.

Easter egg 3 — A palavra “mainframe” pode ser ampla demais

Sempre que possível, detalhe:

  • IBM Z;

  • z/OS;

  • COBOL;

  • CICS;

  • Db2;

  • IMS;

  • JCL;

  • VSAM;

  • RACF.

Easter egg 4 — Recrutadores também fazem buscas internas

Mesmo que você não seja escolhido para uma vaga, seu currículo pode permanecer no banco de talentos.

Palavras-chave corretas ajudam a ser encontrado futuramente.

Easter egg 5 — O nome do cargo importa

Se você procura vaga de “Mainframe Developer”, não esconda isso.

Use o título no resumo, desde que seja compatível com seu objetivo.

Easter egg 6 — Certificação sem contexto vale menos

Em vez de listar vinte cursos sem explicação, priorize os mais relevantes.

Easter egg 7 — Currículo não é autobiografia

Você não precisa contar tudo.

Precisa contar o que é relevante para a oportunidade.

Easter egg 8 — O currículo é uma API

Ele recebe uma requisição:

Precisamos de um programador COBOL júnior.

E deve responder com dados claros:

{
  "cobol": true,
  "jcl": true,
  "db2": "conhecimento acadêmico",
  "cics": "em desenvolvimento",
  "git": true,
  "disponibilidade": true
}

Easter egg 9 — Patrick Jane não confiaria em estrelas

Cinco estrelas em COBOL não significam nada.

Uma descrição concreta significa.

Easter egg 10 — O verdadeiro mentalista é o candidato preparado

Você não lê mentes.

Mas aprende a ler vagas.

Essa habilidade muda tudo.


27. Curiosidades para o Padawan COBOL

A palavra “tracking” em Applicant Tracking System significa acompanhamento.

Ou seja, o sistema não serve apenas para filtrar. Ele também pode acompanhar o candidato durante as etapas:

Inscrição
Triagem
Entrevista RH
Entrevista Técnica
Teste
Proposta
Contratação

Em algumas empresas, o recrutador adiciona comentários, avaliações e histórico de contato.

Outro detalhe interessante é que diferentes ATS podem interpretar o mesmo documento de formas diferentes.

Por isso, não existe um layout mágico universal.

A melhor estratégia continua sendo:

  • estrutura simples;

  • texto real;

  • títulos claros;

  • poucas colunas;

  • palavras-chave relevantes;

  • conteúdo honesto.

Outra curiosidade: alguns recrutadores não pesquisam apenas tecnologias.

Eles procuram também responsabilidades e contextos.

Por exemplo:

production support
incident management
batch processing
application maintenance
legacy modernization
code review
unit testing

Portanto, descrever atividades pode ser tão importante quanto listar ferramentas.



28. Erros comuns de iniciantes

Erro 1 — Currículo com quatro páginas sem necessidade

Para alguém no início da carreira, uma ou duas páginas geralmente são suficientes.

Erro 2 — Objetivo genérico

Busco uma oportunidade para crescer profissionalmente.

Isso serve para quase qualquer pessoa.

Prefira:

Busco oportunidade como programador COBOL júnior, com foco em desenvolvimento e manutenção de aplicações IBM Mainframe.

Erro 3 — Listar tudo que já ouviu falar

Conhecer o nome de uma tecnologia não significa dominá-la.

Erro 4 — Não incluir projetos

Para iniciantes, projetos são fundamentais.

Erro 5 — Usar linguagem passiva demais

Foi realizado um projeto.

Melhor:

Desenvolvi um projeto.

Erro 6 — Currículo sem resultado

Sempre que possível, mostre o que foi entregue.

Erro 7 — Misturar português e inglês sem lógica

Use o idioma solicitado pela vaga.

Erro 8 — Endereço completo

Normalmente cidade, estado e país são suficientes.

Não é necessário informar número da casa.

Erro 9 — Dados pessoais excessivos

Evite informações que não ajudam no processo.

Erro 10 — Mentir

Esse é o maior erro.

Em tecnologia, a verdade aparece rapidamente.


29. Como descrever conhecimentos ainda básicos

Você pode ser iniciante e ainda assim apresentar seu conhecimento de forma profissional.

Exemplos:

COBOL — conhecimento prático em programas batch, estruturas condicionais, arquivos sequenciais e relatórios.
JCL — criação de jobs para compilação, linkedição, execução e manipulação básica de datasets.
Db2 — conhecimentos em SQL, consultas, atualização de dados e tratamento de SQLCODE em COBOL.
CICS — familiaridade com conceitos de transação, COMMAREA, mapas BMS e comandos básicos.
Git — versionamento de código, commits, branches e uso de repositórios GitHub.

Essas descrições são claras e honestas.


30. A investigação final de Patrick Jane

Imagine Patrick Jane entrando na sala.

Sobre a mesa existem dois currículos.

O primeiro possui cores, gráficos, estrelas, três colunas e uma fotografia enorme.

O segundo possui texto simples, seções claras, palavras-chave relevantes e projetos objetivos.

Ele observa os dois.

Toma uma xícara de chá — infelizmente, ainda não descobriu o poder do café Bellacosa — e diz:

— O primeiro deseja ser admirado. O segundo deseja ser compreendido.

Essa é a essência de um currículo ATS Friendly.

Ser compreendido.

Pelo sistema.

Pelo recrutador.

Pelo gerente.

Pelo entrevistador técnico.

Você não precisa eliminar sua personalidade.

Você precisa organizar sua mensagem.

  • Conheça o Lovable

https://eljefemidnightlunch.blogspot.com/2024/11/lovable-o-dia-em-que-patrick-jane.html

Conclusão — O job precisa entrar em execução

Um currículo ATS Friendly é um currículo preparado para atravessar a primeira camada do processo seletivo.

Ele utiliza:

  • layout simples;

  • texto legível;

  • títulos tradicionais;

  • palavras-chave;

  • datas consistentes;

  • informações claras;

  • descrições objetivas;

  • projetos relevantes;

  • formatação compatível.

Para um programador COBOL iniciante, essa preparação é especialmente importante.

Você talvez ainda não tenha dez anos de experiência.

Mas pode demonstrar:

  • disciplina;

  • capacidade de aprender;

  • domínio da lógica;

  • projetos práticos;

  • conhecimento do ambiente IBM Z;

  • interesse em sistemas corporativos;

  • organização;

  • documentação;

  • vontade de evoluir.

O currículo não deve fingir que você é um sênior.

Ele deve provar que você está pronto para dar o próximo passo.

No Bellacosa Mainframe, aprendemos que nenhum job chega à produção sem passar por validação, teste, revisão e controle.

Sua carreira também precisa desse cuidado.

Leia a vaga.

Identifique as palavras-chave.

Ajuste seu currículo.

Revise a estrutura.

Elimine ruídos.

Destaque projetos.

Salve corretamente.

Envie com consciência.

E lembre-se:

O ATS não precisa gostar de você.

Ele precisa entender você.

O recrutador não precisa decifrar um enigma.

Ele precisa encontrar rapidamente aquilo que procura.

E você, jovem Padawan do COBOL, não precisa ler mentes como Patrick Jane.

Precisa apenas aprender a ler pistas.

Porque, no grande datacenter da carreira profissional, a oportunidade pode já estar no spool.

Só falta o seu currículo passar com:

MAXCC = 0000
CANDIDATO SELECIONADO PARA A PRÓXIMA ETAPA

☕ Que o café esteja quente, o currículo esteja legível e o job da sua carreira execute sem ABEND.

sexta-feira, 31 de julho de 2026

Do HTML ao IBM Z — Quando um Programador COBOL Descobre que o Front-end Também Faz Parte do Mainframe Moderno

 

Bellacosa Mainframe do Html ao IBM Z uma jornada classica do Heroi

☕ Um Café no Bellacosa Mainframe

Do HTML ao IBM Z — Quando um Programador COBOL Descobre que o Front-end Também Faz Parte do Mainframe Moderno

"Durante muitos anos acreditamos que existiam dois mundos completamente diferentes. De um lado, o navegador. Do outro, o mainframe. Hoje sabemos que eles nunca estiveram tão próximos."


Existe uma cena curiosa que provavelmente todo programador COBOL já viveu.

Você está trabalhando em um programa CICS há horas. Ajusta um COMMAREA, altera uma consulta DB2, recompila, faz o BIND, libera para homologação e, de repente, alguém da equipe Web aparece com uma pergunta aparentemente inocente:

"Você consegue disponibilizar isso numa API REST?"

Há alguns anos essa pergunta soaria quase como magia.

Hoje ela faz parte do cotidiano.

Foi justamente para reduzir essa distância que nasceu o APPDEV 33 – Introduction to Web Development – Part 2, expandindo os conceitos apresentados na Parte 1 e mostrando que HTML, CSS e JavaScript não competem com COBOL. Eles trabalham juntos.

Na verdade...

Eles dependem um do outro.



A grande mudança silenciosa

Existe uma falsa impressão de que o desenvolvimento Web pertence apenas ao universo JavaScript.

Não pertence.

Da mesma forma que existe a falsa impressão de que o Mainframe termina na tela verde.

Também não termina.

O navegador moderno tornou-se apenas mais um terminal.

Só que muito mais bonito.

Muito mais amigável.

Muito mais inteligente.

E atrás dele continua existindo aquilo que sempre sustentou bancos, seguradoras, governos, companhias aéreas e bolsas de valores:

IBM Z.


O que aprendemos na Parte 1

Na primeira parte aprendemos três pilares fundamentais.

HTML

A estrutura.

Assim como uma BMS MAP define onde cada campo aparecerá na tela 3270, o HTML define onde cada elemento será exibido dentro da página.

É o esqueleto.


CSS

A aparência.

Se na BMS alterávamos atributos como intensidade, cor, proteção e brilho, no navegador fazemos praticamente a mesma coisa utilizando CSS.

Mudam os nomes.

O conceito continua.


JavaScript

O comportamento.

Enquanto COBOL executa regras de negócio no servidor, JavaScript controla a experiência do usuário no navegador.

Ele responde cliques.

Atualiza informações.

Valida formulários.

Move elementos.

Sem precisar recarregar toda a página.


A analogia perfeita

Mundo WebMundo Mainframe
HTMLBMS MAP
CSSAtributos da Tela
JavaScriptInterface
COBOLRegras de Negócio

Quando essa tabela aparece pela primeira vez, muita gente faz exatamente a mesma expressão:

"Ahhh... agora fez sentido."



O navegador é apenas o começo

Quando digitamos:

https://empresa.com

Nossa mente costuma imaginar algo simples.

Mas, nos bastidores, ocorre uma verdadeira corrida de revezamento.

Usuário

↓

Browser

↓

Servidor Web

↓

HTML

↓

CSS

↓

JavaScript

↓

Página pronta

↓

REST API

↓

z/OS Connect

↓

CICS

↓

COBOL

↓

DB2

↓

Resposta

Observe algo interessante.

O navegador praticamente nunca conversa diretamente com o COBOL.

Existe uma camada intermediária.

E isso é excelente.


O guardião entre dois mundos

No ecossistema IBM Z moderno existe um verdadeiro tradutor universal.

z/OS Connect.

Ele recebe chamadas REST.

Converte JSON.

Invoca programas COBOL.

Executa CICS.

Consulta DB2.

Retorna novamente JSON.

Tudo isso escondendo completamente a complexidade do ambiente z/OS.

É quase como um intérprete simultâneo durante uma conferência internacional.

Cada lado continua falando sua própria língua.

Mas todos passam a se entender.


HTML deixou de ser apenas marcação

Quem aprendeu HTML há quinze anos provavelmente conheceu algo parecido com isto.

<div>
<div>
<div>

Funcionava.

Mas era praticamente impossível descobrir o significado daquela estrutura.

Então surgiu o HTML Semântico.

Agora passamos a utilizar elementos como:

<header>

<nav>

<main>

<section>

<article>

<footer>

Essas palavras possuem significado.

E significado muda tudo.

Motores de busca entendem melhor o conteúdo.

Leitores de tela conseguem navegar corretamente.

Ferramentas de Inteligência Artificial interpretam o contexto.

Até os próximos programadores agradecem.

Porque finalmente conseguem entender a organização da página.


CSS cresceu

Durante muito tempo criar layouts era uma atividade quase artesanal.

Tabelas.

Float.

Clear.

Margens.

Gambiarras.

Então surgiu o Flexbox.

De repente bastava escrever poucas linhas.

display:flex;

justify-content:space-between;

align-items:center;

Como mágica.

Tudo se alinhava.

Responsivamente.

Sem sofrimento.

Depois veio o CSS Grid.

E aí o navegador finalmente ganhou um verdadeiro sistema de layout bidimensional.

Header.

Menu.

Conteúdo.

Rodapé.

Tudo organizado como uma planta arquitetônica.

Curiosamente...

É exatamente assim que pensamos quando desenhamos uma aplicação CICS.

Primeiro definimos a arquitetura.

Depois os componentes.

Depois o fluxo.


JavaScript finalmente ganhou vida

No início JavaScript apenas executava comandos.

Hoje ele reage.

Clique.

Teclado.

Mouse.

Touch.

Formulário.

Mudança de valor.

Tudo é evento.

Usuário

↓

Evento

↓

JavaScript

↓

Resposta

Essa simplicidade mudou completamente a experiência da Web.

Não precisamos mais atualizar páginas inteiras.

Alteramos apenas aquilo que realmente mudou.

Essa ideia parece moderna.

Mas, curiosamente, programadores CICS fazem algo parecido há décadas.

Atualizamos apenas determinados campos da tela.

Não a aplicação inteira.



DOM — A página deixa de ser estática

Imagine que exista uma árvore invisível.

Cada botão.

Cada texto.

Cada imagem.

Cada tabela.

Cada formulário.

Tudo faz parte dessa árvore.

Ela recebe um nome.

DOM — Document Object Model.

JavaScript pode caminhar por essa árvore.

Encontrar um elemento.

Alterar seu conteúdo.

Modificar sua aparência.

Inserir novos componentes.

Tudo instantaneamente.

Sem recarregar o navegador.

É isso que transforma páginas estáticas em aplicações.

Parte II : Quando o Navegador Conversa com o Mainframe

Na primeira parte da nossa conversa percebemos algo importante: HTML, CSS e JavaScript não substituem o COBOL. Eles apenas ocupam uma camada diferente da aplicação.

Agora vem a pergunta que todo programador COBOL faz quando termina de aprender os conceitos básicos.

"Tudo bem... mas como exatamente um clique no navegador consegue executar um programa COBOL dentro do IBM Z?"

É justamente aqui que começa a mágica.

Ou melhor...

A engenharia.



A viagem de um clique

Imagine que um cliente acessa o Internet Banking.

Ele vê um botão.

Consultar Saldo

Aparentemente ele apenas clicou.

Mas esse clique inicia uma longa viagem.

Clique

↓

JavaScript

↓

REST API

↓

JSON

↓

z/OS Connect

↓

CICS

↓

Programa COBOL

↓

DB2

↓

Resposta

↓

JSON

↓

JavaScript

↓

Atualização da Tela

Em menos de um segundo tudo isso aconteceu.

Sem o usuário perceber.

Se o sistema estiver rodando em IBM Z, provavelmente essa operação ocorreu em alguns poucos milissegundos.



REST API — A língua franca da Internet

Há vinte anos cada sistema possuía seu próprio protocolo.

Cada fabricante inventava uma maneira diferente de trocar informações.

Era um verdadeiro caos.

REST mudou completamente esse cenário.

Hoje praticamente qualquer sistema consegue conversar com qualquer outro utilizando HTTP.

Isso significa que um navegador, um aplicativo Android, um iPhone, uma Smart TV ou até uma geladeira inteligente podem acessar exatamente a mesma API.

O IBM Z simplesmente tornou-se mais um participante dessa conversa.



JSON — O envelope que viaja pela Internet

Quando um navegador solicita informações, ele normalmente envia algo parecido com isto.

{
   "cliente":12345
}

Poucos milissegundos depois recebe algo semelhante.

{
   "nome":"Maria",
   "saldo":1250.90,
   "limite":5000
}

Isso é JSON.

Leve.

Organizado.

Fácil de interpretar.

Mas existe uma curiosidade.

O JSON praticamente nunca nasce no navegador.

Na maioria das aplicações corporativas ele foi produzido por um programa COBOL.

Ou seja...

Por trás daquele pequeno documento existe toda uma lógica construída durante décadas.



z/OS Connect — O tradutor universal

Imagine um diplomata durante uma reunião internacional.

Um participante fala japonês.

Outro fala português.

Outro inglês.

Outro espanhol.

Todos conseguem conversar porque existe um intérprete.

z/OS Connect faz exatamente esse papel.

Ele entende REST.

Entende HTTP.

Entende JSON.

Depois traduz tudo para o universo do IBM Z.

Do outro lado...

O programa COBOL continua exatamente igual.

Sem precisar conhecer HTML.

Sem conhecer JavaScript.

Sem conhecer navegador.

Ele apenas recebe parâmetros.

Processa.

Responde.

E volta ao trabalho.



CICS continua fazendo o que sempre fez

Muita gente acredita que REST substituiu CICS.

Na verdade aconteceu justamente o contrário.

REST fez ainda mais aplicações dependerem do CICS.

O fluxo normalmente é este.

Browser

↓

REST API

↓

z/OS Connect

↓

CICS

↓

Programa COBOL

Observe que o CICS continua sendo o gerente das transações.

Ele controla segurança.

Sincronismo.

Rollback.

Commit.

Performance.

Disponibilidade.

Nada mudou.

Apenas surgiram novos clientes.

Antes eram terminais 3270.

Hoje são navegadores.



COBOL continua sendo o cérebro

Existe uma frase que gosto muito.

JavaScript encanta. COBOL decide.

É JavaScript quem anima a tela.

É JavaScript quem valida um campo.

É JavaScript quem muda uma cor.

Mas quem realmente decide se um empréstimo será aprovado?

Quem calcula juros?

Quem verifica limite de crédito?

Quem consulta regras fiscais?

Quem processa milhões de transações diariamente?

COBOL.

Sempre ele.

O navegador apenas apresenta o resultado.



DB2 continua guardando o tesouro

Toda aplicação precisa armazenar informações.

Clientes.

Contas.

Contratos.

Apólices.

Empréstimos.

Pedidos.

Cartões.

É aqui que entra o DB2.

O programa COBOL faz consultas.

Atualiza registros.

Executa commits.

Controla integridade.

Depois transforma essas informações em JSON.

E o navegador recebe tudo pronto.

Perceba algo interessante.

O navegador nunca conversa diretamente com o banco.

Isso seria extremamente perigoso.

Existe sempre uma camada intermediária protegendo os dados.



Organização faz diferença

Quando começamos nossos primeiros programas HTML normalmente criamos apenas um arquivo.

index.html

Pouco tempo depois aparecem outros.

style.css

app.js

logo.png

Mais tarde surgem dezenas.

Depois centenas.

É exatamente nesse momento que aprendemos a organizar projetos.

Projeto

│

├── index.html

├── css

├── js

├── images

├── api

Essa organização pode parecer apenas estética.

Não é.

Ela facilita manutenção.

Facilita testes.

Facilita integração contínua.

Facilita Git.

Facilita DevOps.

Curiosamente...

É exatamente o mesmo motivo pelo qual existem COPYBOOKS.



COPYBOOKS nasceram muito antes dos Frameworks

Muitos desenvolvedores Web acreditam que reutilização nasceu com Frameworks modernos.

Na verdade...

Programadores COBOL fazem isso desde os anos 60.

Sempre que escrevemos

COPY CLIENTE.

Estamos reutilizando componentes.

Assim como um projeto Web reutiliza:

componentes

bibliotecas

frameworks

módulos

Mudam os nomes.

O princípio continua exatamente igual.


Git mudou a forma de trabalhar

Durante décadas o controle de versões no Mainframe foi responsabilidade de ferramentas como:

  • Endevor

  • ISPW

  • Librarian

  • Panvalet

Hoje Git tornou-se praticamente obrigatório.

Não importa se o código está em Java.

Python.

COBOL.

REXX.

Assembler.

Todos podem viver no mesmo repositório.

E isso abriu uma porta enorme para DevOps.



DevOps aproximou dois mundos

Antigamente existia uma divisão muito clara.

O desenvolvedor escrevia código.

Outra equipe compilava.

Outra homologava.

Outra implantava.

Hoje pipelines fazem praticamente tudo isso automaticamente.

Commit

↓

Build

↓

Testes

↓

Análise

↓

Deploy

Essa automação não substitui o programador.

Ela elimina tarefas repetitivas.

E permite que ele invista tempo onde realmente faz diferença.

Criando soluções.

Não apertando botões.



O novo profissional IBM Z

Chegamos então ao ponto mais importante de toda esta formação.

O profissional IBM Z moderno não conhece apenas COBOL.

Ele entende a jornada completa.

COBOL

↓

JSON

↓

REST

↓

HTML

↓

CSS

↓

JavaScript

↓

Git

↓

DevOps

↓

Cloud

↓

IBM Z

Isso não significa abandonar o Mainframe.

Significa ampliar horizontes.

Quanto mais camadas você compreende, maior passa a ser seu valor dentro da organização.

Você deixa de ser apenas um programador COBOL.

Passa a ser alguém capaz de conversar com equipes Web, arquitetos de soluções, especialistas em APIs, profissionais DevOps e engenheiros de Cloud.

E isso muda completamente sua carreira.



☕ Um café antes de continuar...

Existe um detalhe curioso que costuma passar despercebido.

Durante décadas ouvimos que "o futuro substituiria o Mainframe".

Mas aconteceu exatamente o contrário.

Foi o Mainframe que aprendeu a conversar com o futuro.

Hoje ele fala REST, entende JSON, integra-se com Cloud, participa de pipelines DevOps, conversa com aplicações móveis e continua executando, silenciosamente, bilhões de transações por dia.

Talvez essa seja a maior lição desta formação.

O IBM Z nunca ficou parado. Nós é que demoramos para perceber o quanto ele evoluiu.

Parte III — O Desenvolvedor IBM Z Moderno e o Futuro que Já Chegou

"O melhor momento para aprender HTML foi quando surgiu. O segundo melhor momento é hoje. Porque o IBM Z já está esperando por você."

Depois de percorrer toda a jornada desta formação, uma pergunta inevitavelmente aparece.

"O que devo aprender agora?"

Essa talvez seja a maior ansiedade de quem vem do mundo COBOL.

São tantas tecnologias...

HTML.

CSS.

JavaScript.

Git.

REST.

JSON.

Cloud.

DevOps.

Containers.

Docker.

Kubernetes.

OpenShift.

Inteligência Artificial.

À primeira vista parece impossível.

Mas existe uma boa notícia.

Você não precisa aprender tudo de uma vez.

Muito menos abandonar o conhecimento acumulado durante anos.

Na verdade, você já possui aquilo que a maioria dos desenvolvedores modernos ainda está tentando adquirir.

Conhecimento de negócio.

E isso vale ouro.


A árvore do conhecimento

Durante a apresentação utilizamos uma imagem bastante simbólica.

Uma árvore.

À primeira vista ela parece apenas um desenho bonito.

Mas existe um significado escondido.

As raízes

São invisíveis.

Pouca gente presta atenção nelas.

Mas sustentam tudo.

No IBM Z elas representam:

  • COBOL

  • JCL

  • CICS

  • DB2

  • VSAM

  • RACF

  • TSO/ISPF

Curiosamente...

São justamente as tecnologias que mais movimentam dinheiro no planeta.

Ninguém faz propaganda delas.

Mas bilhões de transações acontecem todos os dias graças a elas.


O tronco

O tronco representa aquilo que conecta todas as áreas.

Na nossa metáfora...

É o próprio IBM z17.

Não apenas como computador.

Mas como plataforma.

Segura.

Disponível.

Escalável.

Resiliente.

Enquanto centenas de tecnologias aparecem e desaparecem ao longo das décadas...

O IBM Z continua crescendo.


Os galhos

É onde surgem as novidades.

HTML.

CSS.

JavaScript.

REST.

JSON.

Git.

Cloud.

DevOps.

IA.

Todos eles crescem apoiados nas raízes.

Sem elas...

A árvore não existe.


O roadmap de evolução

Ao longo da apresentação surgiu uma estrada colorida.

Ela representa algo muito importante.

Você não aprende tudo ao mesmo tempo.

Você sobe um degrau por vez.

Primeiro passo

HTML.

Aprenda estrutura.

Nada além disso.

Não tente decorar centenas de elementos.

Entenda a lógica.


Segundo passo

CSS.

Faça páginas bonitas.

Aprenda cores.

Espaçamento.

Layouts.

Responsividade.

Não é preciso virar designer.

Apenas tornar a informação agradável.


Terceiro passo

JavaScript.

Agora a página ganha vida.

Botões passam a funcionar.

Campos são validados.

Elementos aparecem.

Desaparecem.

Mudam dinamicamente.

É nesse momento que muitos programadores COBOL começam a sorrir.

Porque finalmente enxergam lógica de programação novamente.


Quarto passo

REST.

Agora você entende que aplicações conversam.

E que praticamente toda integração moderna utiliza APIs.


Quinto passo

JSON.

Descobre que arquivos gigantes de integração deram lugar a pequenos documentos extremamente simples.


Sexto passo

Git.

Talvez seja a ferramenta que mais muda a maneira de trabalhar.

Commits.

Branches.

Merge.

Pull Request.

Code Review.

Tudo passa a fazer parte da rotina.


Sétimo passo

DevOps.

Agora o código não vive mais sozinho.

Ele entra em pipelines.

Executa testes.

É compilado automaticamente.

Implantado.

Monitorado.

Tudo praticamente sem intervenção humana.


Oitavo passo

Cloud.

Você percebe que Cloud não substituiu o Mainframe.

Ela apenas adicionou mais um ambiente de execução.

Na prática...

Os dois trabalham juntos.


Nono passo

Inteligência Artificial.

Chegamos ao presente.

Mas cuidado.

Existe um enorme equívoco acontecendo.

A IA não substitui conhecimento.

Ela acelera conhecimento.

Quanto mais experiência possui o profissional...

Melhores perguntas ele faz.

Melhores respostas recebe.


Um pequeno segredo da IBM

Existe uma curiosidade interessante.

Durante muitos anos, aprender IBM significava decorar comandos.

Hoje não.

A IBM mudou completamente sua estratégia.

Ela deseja profissionais capazes de integrar tecnologias.

É exatamente por isso que vemos cada vez mais cursos envolvendo:

  • Git

  • APIs

  • HTML

  • JavaScript

  • OpenShift

  • Red Hat

  • Linux

  • Python

  • DevOps

  • IA

Tudo convivendo naturalmente com COBOL.


Easter Egg nº 1 — O retorno da BMS

Você provavelmente achou curioso estudar HTML.

Mas observe.

Uma página HTML possui:

Header.

Body.

Campos.

Botões.

Mensagens.

Formulários.

Menus.

Parece familiar?

Porque é.

BMS fazia exatamente isso.

A diferença é que hoje existem milhões de cores.

Animações.

Responsividade.

E um mouse.

No restante...

Os conceitos continuam incrivelmente parecidos.


Easter Egg nº 2 — O navegador virou um terminal 3270

Calma...

Antes de fechar a página dizendo que enlouqueci...

Pense comigo.

O navegador:

Recebe dados.

Envia comandos.

Mostra telas.

Executa transações.

Atualiza informações.

Consulta banco.

Exatamente como um terminal.

A diferença é que o navegador ganhou superpoderes.

Renderiza vídeos.

Executa JavaScript.

Faz chamadas REST.

Mostra gráficos.

Integra mapas.

Mas continua sendo uma interface.

Assim como o 3270 sempre foi.


Easter Egg nº 3 — HTML não substitui COBOL

Esse talvez seja o maior medo de muitos iniciantes.

"Vou precisar abandonar COBOL?"

Não.

Pelo contrário.

Quanto maior a adoção de APIs...

Mais programas COBOL acabam sendo reutilizados.

Muitos sistemas escritos há quarenta anos hoje atendem aplicações Web modernas.

Mudou apenas a porta de entrada.


O maior erro dos iniciantes

Depois de ministrar diversos treinamentos, comecei a perceber um padrão.

O erro raramente é técnico.

É psicológico.

O aluno olha para a quantidade de tecnologias e conclui:

"Jamais vou aprender tudo isso."

Mas ninguém aprende.

Nem mesmo quem trabalha há trinta anos.

Todos continuam estudando.

Inclusive os IBM Fellows.

Inclusive os Distinguished Engineers.

Inclusive quem desenvolveu boa parte dessas tecnologias.

Aprender nunca termina.


O conselho que gostaria de ter ouvido em 1988

Quando comecei minha carreira, imaginava que bastava aprender COBOL.

Depois vieram CICS.

DB2.

JCL.

VSAM.

REXX.

Assembler.

TCP/IP.

MQ.

Java.

Web Services.

XML.

JSON.

REST.

Git.

Cloud.

DevOps.

IA.

No início achei que era um problema.

Hoje percebo que foi um privilégio.

Poucas profissões permitem acompanhar tantas revoluções tecnológicas sem abandonar completamente aquilo que aprendemos décadas atrás.

O programador COBOL continua reconhecendo um IF.

Um PERFORM.

Um MOVE.

Da mesma forma que reconhece hoje um IF em JavaScript.

A lógica continua sendo a mesma.

Mudam apenas as ferramentas.


O verdadeiro objetivo desta formação

Se ao terminar estas aulas você decorar todos os comandos HTML...

O curso terá sido apenas razoável.

Se aprender Flexbox.

Grid.

DOM.

Eventos.

REST.

JSON.

Também será um bom resultado.

Mas existe um objetivo muito maior.

Perder o medo da palavra "Web".

Porque ela deixou de ser um território distante.

Hoje faz parte do ecossistema IBM Z.


Uma última xícara de café...

Quando observo um IBM z17 processando milhares de transações por segundo enquanto um navegador moderno exibe gráficos, animações e respostas instantâneas, lembro-me de como essa história começou.

Lá atrás, um simples terminal verde.

Depois uma tela BMS.

Mais tarde o TCP/IP.

Vieram XML e Web Services.

Depois JSON.

REST.

Cloud.

Git.

DevOps.

Agora Inteligência Artificial.

O curioso é que, em todas essas fases, alguém decretou que o Mainframe estava ficando para trás.

E, em todas elas, o IBM Z respondeu da melhor maneira possível.

Evoluindo.

Sem perder sua essência.

Sem abandonar sua confiabilidade.

Sem deixar de ser o coração silencioso das maiores empresas do planeta.

Talvez essa seja a maior lição desta jornada.

As tecnologias mudam.

As interfaces evoluem.

As linguagens ganham novos recursos.

Mas a lógica, a arquitetura bem construída e a capacidade de resolver problemas reais continuam sendo o verdadeiro diferencial de um grande profissional.

No fim das contas, HTML, CSS, JavaScript, REST, JSON, Git, DevOps e Inteligência Artificial não são o destino.

São apenas novas ferramentas nas mãos de quem já aprendeu, há muito tempo, que um bom programa começa antes mesmo da primeira linha de código.

E enquanto houver desafios para resolver, clientes para atender e sistemas críticos para manter funcionando, sempre haverá espaço para quem estiver disposto a aprender.

Então abasteça a caneca, abra o editor de código e continue estudando.

Porque a próxima grande evolução do IBM Z provavelmente já começou.

E, quem sabe, ela será escrita por você.

Do conceito à prática: os laboratórios da Formação APPDEV

Teoria sem prática é como um programa COBOL que nunca saiu do editor: pode estar elegante, bem comentado e perfeitamente identado, mas ainda não processou uma única transação.

Por isso, a Formação APPDEV não termina quando o último slide desaparece da tela.

Ela continua nos laboratórios.

É nesses ambientes que HTML deixa de ser apenas uma sequência de tags, CSS deixa de ser decoração, JavaScript deixa de ser uma promessa e a integração com o ecossistema IBM Z começa a ganhar forma diante dos nossos olhos.

Prepare a caneca.

Abra o navegador.

E vamos colocar a mão na massa.


IBM Web Development Labs

O primeiro ponto de partida é o laboratório de desenvolvimento Web utilizado durante a formação:

IBM Web Development Labs
https://vagnerbellacosa.github.io/Lab_WebdevelopmentCoursera/

Nesse ambiente, o aluno pode revisar os fundamentos de HTML, CSS e JavaScript, observar a organização de uma aplicação Web e experimentar a construção de páginas diretamente no navegador.

É o lugar ideal para praticar:

  • estruturação de páginas com HTML;

  • aplicação de estilos com CSS;

  • criação de comportamentos com JavaScript;

  • eventos de clique e formulário;

  • manipulação do DOM;

  • organização de componentes;

  • preparação para consumo de APIs.

O objetivo não é apenas copiar códigos.

É alterar.

Quebrar.

Testar.

Corrigir.

Executar novamente.

Programação continua sendo uma ciência experimental, mesmo quando o laboratório cabe dentro de uma aba do navegador.

O endereço desse laboratório aparece diretamente na apresentação APPDEV como recurso para continuidade dos estudos.


LAB IBM IPL Mainframe

Depois de compreender o funcionamento da camada Web, vale retornar ao coração da infraestrutura:

LAB IBM IPL Mainframe
https://vagnerbellacosa.github.io/LAB_IBM_IPLMainframe/

IPL significa Initial Program Load.

É, de maneira simplificada, o processo de inicialização de um sistema IBM Z. Entretanto, compará-lo apenas ao boot de um computador pessoal seria uma simplificação quase ofensiva.

Em um ambiente corporativo, um IPL envolve planejamento, volumes, parâmetros, dispositivos, subsistemas, segurança, disponibilidade e uma sequência cuidadosamente controlada de operações.

O laboratório ajuda o estudante a enxergar o IBM Z não apenas como uma máquina que executa COBOL, mas como uma plataforma completa, composta por diversas camadas trabalhando em conjunto.

Essa visão é fundamental para o Desenvolvedor IBM Z Moderno.

Mesmo que ele não execute um IPL em produção, precisa compreender o ambiente no qual seus programas vivem.

A apresentação disponibiliza esse laboratório como uma etapa complementar da jornada.


Lab IBM Storage Management

Todo programa precisa de dados.

E todo dado precisa morar em algum lugar.

Lab IBM Storage Management
https://vagnerbellacosa.github.io/Lab_IBM_StorageManagement/

Nesse laboratório, o aluno pode ampliar a compreensão sobre armazenamento no ecossistema IBM Z.

Isso inclui conceitos relacionados a:

  • datasets;

  • volumes;

  • DASD;

  • organização de arquivos;

  • gerenciamento de espaço;

  • políticas de armazenamento;

  • disponibilidade;

  • proteção de dados;

  • relacionamento entre aplicação e infraestrutura.

No mundo Web, falamos em arquivos, pastas, objetos, buckets e bancos de dados.

No IBM Z, encontramos datasets sequenciais, PDS, PDSE, VSAM, catálogos, volumes e políticas SMS.

Novamente, mudam as ferramentas e os nomes.

A necessidade permanece a mesma:

guardar a informação correta, no lugar correto, com segurança e disponibilidade.

O link para o laboratório de Storage Management também faz parte dos materiais de continuidade presentes na apresentação.


LAB IBM Capacity

Uma aplicação pode funcionar perfeitamente para dez usuários e entrar em colapso quando o décimo primeiro aparece.

É nesse momento que descobrimos que desenvolver software não significa apenas produzir resultados corretos.

Também significa produzir resultados dentro do tempo esperado.

LAB IBM Capacity
https://vagnerbellacosa.github.io/LAB_IBM_Capacity/

O laboratório de capacidade introduz uma visão essencial para aplicações corporativas:

  • utilização de CPU;

  • consumo de memória;

  • carga de trabalho;

  • crescimento de demanda;

  • gargalos;

  • throughput;

  • tempo de resposta;

  • planejamento de recursos;

  • comportamento do ambiente em períodos de pico.

Imagine uma aplicação Web consultando uma API REST que chama z/OS Connect, entra no CICS, executa COBOL e consulta DB2.

Cada camada consome recursos.

Cada camada pode introduzir espera.

Cada componente precisa ser observado.

O usuário não está preocupado com o número de instruções executadas.

Ele apenas sabe que clicou no botão e está esperando.

Por isso, capacidade e desempenho também fazem parte da experiência do usuário.

O laboratório de Capacity aparece na apresentação como parte da trilha prática recomendada.


Lab War Room Mainframe

Alguns problemas não chegam educadamente durante o horário comercial.

Eles aparecem de madrugada.

No fechamento mensal.

Durante uma grande campanha.

Ou exatamente quando todos acreditavam que a mudança estava sob controle.

Lab War Room Mainframe
https://vagnerbellacosa.github.io/LAB_WarRoom_Mainframe/

O conceito de War Room representa a investigação coordenada de incidentes.

É o lugar — físico ou virtual — onde profissionais de diferentes áreas analisam juntos:

  • sintomas;

  • logs;

  • mensagens;

  • falhas;

  • tempos de resposta;

  • consumo de recursos;

  • dependências;

  • mudanças recentes;

  • comportamento das aplicações;

  • impacto para o negócio.

No ambiente moderno, uma falha aparentemente simples no navegador pode ter começado muito longe dele.

O botão não respondeu.

Mas a causa pode estar em:

JavaScript
    ↓
REST API
    ↓
z/OS Connect
    ↓
CICS
    ↓
COBOL
    ↓
DB2
    ↓
Storage

É por isso que o profissional capaz de compreender toda a cadeia possui enorme valor.

Ele não observa apenas a mensagem de erro.

Ele segue as pegadas.

O laboratório War Room Mainframe também está entre os recursos indicados na apresentação APPDEV.


Para ir mais longe: Bellacosa Mainframe

A formação termina.

O aprendizado, felizmente, não.

Para continuar explorando COBOL, CICS, DB2, JCL, VSAM, APIs, HTML, CSS, JavaScript, DevOps, segurança, arquitetura e cultura Mainframe, visite:

Um Café no Bellacosa Mainframe
https://eljefemidnightlunch.blogspot.com/

O blog funciona como uma grande biblioteca construída ao longo do tempo.

Há artigos para iniciantes.

Conteúdos técnicos aprofundados.

Histórias sobre a evolução da computação.

Analogias com filmes, séries, quadrinhos, ficção científica e cultura popular.

Porque aprender tecnologia também significa construir memórias.

Um conceito técnico pode ser esquecido.

Mas uma boa história costuma permanecer.

A apresentação indica o Bellacosa Mainframe como espaço para aprofundamento e continuidade dos estudos.


Projeto Coursera Web Developer no GitHub

Ler códigos é importante.

Executá-los é melhor.

Modificá-los é onde o aprendizado realmente começa.

Projeto Coursera Web Developer
https://github.com/VagnerBellacosa/Lab_WebdevelopmentCoursera

Nesse repositório, o aluno pode explorar a organização de um projeto real, comparar arquivos, analisar versões e compreender como HTML, CSS e JavaScript convivem dentro de uma estrutura profissional.

Um repositório Git não é apenas um lugar para guardar código.

Ele registra a história do projeto.

Mostra o que mudou.

Quando mudou.

Por que mudou.

E quem realizou a alteração.

Essa rastreabilidade aproxima o desenvolvimento Web das práticas modernas de DevOps utilizadas também no IBM Z.

O projeto e seu endereço no GitHub aparecem entre os materiais finais da apresentação.


Mais repositórios HTML: mão na massa

Para explorar outros exemplos, projetos e experiências relacionadas a HTML, acesse:

Repositórios HTML de Vagner Bellacosa
https://github.com/VagnerBellacosa?tab=repositories&q=html

Aqui vale seguir uma pequena rotina de laboratório:

  1. Escolha um projeto.

  2. Observe a estrutura de diretórios.

  3. Localize o index.html.

  4. Identifique os arquivos CSS.

  5. Encontre os códigos JavaScript.

  6. Execute a aplicação.

  7. Altere um elemento.

  8. Teste novamente.

  9. Quebre alguma coisa propositalmente.

  10. Descubra como corrigir.

O aprendizado verdadeiro começa quando deixamos de ser visitantes do código e passamos a ser seus investigadores.

A apresentação encerra a seção prática justamente apontando para os repositórios HTML disponíveis no GitHub.


Uma trilha prática sugerida

Para aproveitar melhor os materiais, siga esta sequência:

1. IBM Web Development Labs
              ↓
2. Projeto Web Developer no GitHub
              ↓
3. Repositórios HTML
              ↓
4. LAB IBM IPL Mainframe
              ↓
5. Lab IBM Storage Management
              ↓
6. LAB IBM Capacity
              ↓
7. Lab War Room Mainframe
              ↓
8. Bellacosa Mainframe

Começamos pela interface.

Seguimos para o código.

Entramos no controle de versões.

Descemos até a infraestrutura.

Observamos armazenamento e capacidade.

Investigamos incidentes.

E retornamos ao blog para continuar estudando.

Essa é a verdadeira jornada do Desenvolvedor IBM Z Moderno.

Ele não precisa dominar todas as áreas como especialista.

Mas precisa compreender como elas se conectam.


O diploma encerra uma etapa, não a jornada

Ao terminar a Formação APPDEV, o aluno leva muito mais do que alguns comandos HTML, propriedades CSS ou funções JavaScript.

Ele passa a compreender uma cadeia completa:

Usuário
   ↓
Browser
   ↓
HTML + CSS + JavaScript
   ↓
REST API + JSON
   ↓
z/OS Connect
   ↓
CICS
   ↓
COBOL
   ↓
DB2
   ↓
IBM z17

Essa visão integrada é o verdadeiro resultado da formação.

O certificado registra que uma etapa foi concluída.

Os laboratórios demonstram que a prática começou.

O GitHub registra a evolução.

E o conhecimento de negócio transforma tudo isso em valor.

Por isso, quando alguém perguntar o que existe entre um botão HTML e uma transação COBOL, você não precisará mais imaginar dois mundos separados.

Verá uma única arquitetura.

Uma longa linha luminosa atravessando navegador, API, middleware, transação, programa e banco de dados.

De um lado, a experiência do usuário.

Do outro, a confiabilidade do IBM Z.

No meio deles...

O Desenvolvedor IBM Z Moderno.

Com uma caneca de café sobre a mesa e muitos caminhos ainda esperando para serem explorados.


quarta-feira, 6 de dezembro de 2023

Bootcamp DIO Projeto LusoFlix : Programadores FrontEnd em HTML, CSS e JavaScript

Bellacosa Mainframe apresenta o projeto DIO Bootcamp Lusoflix


☕ Um Café no Bellacosa Mainframe

LusoFlix sem Mistérios para Programadores HTML, CSS e JavaScript

Quando um Programador Mainframe Descobre que uma Página Inspirada na Netflix Também Pode Guardar Viagens, Castelos, Histórias e Memórias de Portugal

Há projetos que nascem para ensinar uma propriedade do CSS.

Outros surgem para demonstrar uma biblioteca JavaScript.

Alguns existem apenas para cumprir uma atividade de bootcamp, receber uma avaliação e depois desaparecer em algum diretório chamado:

C:\CURSOS\PROJETOS\FINAL\FINAL_AGORA_VAI\

Mas, ocasionalmente, um exercício acadêmico escapa de sua finalidade original.

Ele ganha personalidade.

Recebe um nome próprio.

Passa a carregar fotografias, lembranças, histórias, viagens e pequenos fragmentos da vida de seu criador.

Foi exatamente isso que aconteceu com o LusoFlixhttps://vagnerbellacosa.github.io/002_WebDeveloper_ReplicaNetflix/

O projeto nasceu como uma recriação da interface inicial da Netflix, desenvolvida com HTML, CSS e JavaScript durante um laboratório de desenvolvimento web. Entretanto, em vez de simplesmente copiar filmes, séries e cartazes fictícios, a solução recebeu uma identidade própria: tornou-se uma homenagem a Portugal e um catálogo visual de vídeos publicados no YouTube sobre cidades, monumentos, castelos, praias, igrejas, gastronomia e experiências vividas em terras lusitanas. (GitHub)

Em outras palavras, o exercício deixou de ser apenas:

CLONE NETFLIX

e passou a funcionar como:

PORTAL AUDIOVISUAL DE MEMÓRIAS SOBRE PORTUGAL

É como se alguém tivesse recebido a missão de copiar uma tela de CICS e decidido transformá-la em um sistema completo de consulta histórica.

O LusoFlix demonstra algo essencial para todo programador iniciante:

Uma tecnologia pode ser aprendida através de exercícios, mas somente se torna realmente nossa quando a usamos para contar alguma coisa que nos pertence.

Nesta investigação do Bellacosa Mainframe, abriremos o código do LusoFlix como se estivéssemos analisando um dump de produção.

Examinaremos:

  • a estrutura HTML;

  • a estilização com CSS;

  • a pequena, mas importante, participação do JavaScript;

  • o uso de bibliotecas externas;

  • os carrosséis inspirados em serviços de streaming;

  • a integração com vídeos do YouTube;

  • o conteúdo sobre Portugal;

  • a hospedagem no GitHub Pages;

  • os recursos de SEO e compartilhamento;

  • os pontos fortes do projeto;

  • as melhorias possíveis;

  • e tudo aquilo que o HTML moderno permite construir atualmente.

Sirva o café.

Abra o navegador.

A investigação começou.


1. A cena inicial: o que é o LusoFlix?

O LusoFlix é uma aplicação web estática inspirada visualmente na página inicial da Netflix.

A página apresenta:

  • um cabeçalho com o logotipo LUSOFLIX;

  • um menu de navegação;

  • uma imagem principal de destaque;

  • botões de ação;

  • diversas categorias de vídeos;

  • carrosséis horizontais;

  • miniaturas clicáveis;

  • links para vídeos e playlists no YouTube;

  • informações adicionais sobre Portugal;

  • elementos de compartilhamento e SEO.

O próprio repositório define o projeto como uma réplica da página inicial da Netflix criada com HTML, CSS e JavaScript, utilizando bibliotecas externas. A adaptação temática substitui o catálogo tradicional por miniaturas de vídeos relacionados a viagens por Portugal. (GitHub)

Essa mudança de tema é mais importante do que pode parecer.

Um clone literal normalmente ensina apenas reprodução visual.

Já uma adaptação exige decisões.

O desenvolvedor precisa perguntar:

  • Qual será o conteúdo principal?

  • Como os itens serão categorizados?

  • Que imagem será usada no destaque?

  • Para onde apontarão os botões?

  • Como transformar vídeos do YouTube em um catálogo?

  • Como organizar dezenas de elementos sem perder coerência visual?

É justamente nessa adaptação que o exercício deixa de ser uma simples cópia.

O programador começa a trabalhar como projetista.


2. O HTML como DATA DIVISION da página

Para um programador COBOL, podemos comparar o HTML com uma mistura entre a DATA DIVISION e a estrutura de telas de um sistema online.

O HTML não determina, sozinho, todas as cores, animações ou comportamentos.

Sua principal responsabilidade é declarar:

  • o que existe;

  • qual é a hierarquia;

  • qual é o significado dos elementos;

  • como as partes da página estão organizadas.

O documento começa corretamente com:

<!DOCTYPE html>
<html lang="pt-br">

O DOCTYPE informa ao navegador que o documento utiliza HTML5.

Já o atributo:

lang="pt-br"

indica que o conteúdo está em português do Brasil.

Isso ajuda:

  • leitores de tela;

  • motores de busca;

  • ferramentas de tradução;

  • corretores ortográficos;

  • sistemas de acessibilidade.

Logo depois, o projeto define:

<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">

O charset="UTF-8" permite representar corretamente acentos, cedilhas e outros caracteres.

Sem isso, uma palavra como:

informações

poderia aparecer como uma pequena cena de crime digital:

informações

A meta tag viewport, por sua vez, é essencial para dispositivos móveis. Ela instrui o navegador a adaptar a largura da página à largura real da tela. Esses elementos aparecem logo no início do documento do LusoFlix.

Pense no viewport como um parâmetro de execução.

Sem ele, o navegador móvel tenta exibir a página como se estivesse simulando uma tela de desktop muito larga.

É praticamente um emulador 3270 tentando adivinhar a resolução de um smartphone.


3. O cabeçalho: identidade e navegação

O cabeçalho apresenta uma estrutura bastante clara:

<header>
    <div class="container">
        <h2 class="logo">LUSOFLIX</h2>

        <nav>
            <a href="...">Inicio</a>
            <a href="...">Lisboa</a>
            <a href="...">Turismo</a>
            <a href="...">Gastronomia</a>
        </nav>
    </div>
</header>

Temos aqui três componentes fundamentais:

header

Representa semanticamente o cabeçalho da página.

h2

Apresenta o nome do serviço.

nav

Agrupa os links principais de navegação.

O uso de elementos semânticos como header, nav, main e footer é uma das grandes evoluções do HTML moderno.

No passado, muitas páginas eram construídas quase exclusivamente com:

<div>

Era comum encontrar algo assim:

<div id="topo">
<div id="menu">
<div id="conteudo">
<div id="rodape">

Funcionava, mas o navegador não compreendia claramente a função de cada bloco.

Com HTML5, podemos informar o significado estrutural:

<header>
<nav>
<main>
<section>
<article>
<footer>

Essa semântica ajuda tanto os mecanismos de busca quanto as tecnologias assistivas.

No LusoFlix, os links do menu direcionam o visitante para vídeos relacionados ao início da jornada, Lisboa, turismo e gastronomia.

O menu não está ali apenas como decoração.

Ele funciona como um pequeno índice temático do acervo audiovisual.


4. O herói da página: a área de destaque

Todo serviço de streaming possui um conteúdo destacado.

É aquele grande painel que tenta capturar a atenção do visitante antes que ele comece a navegar pelo catálogo.

No LusoFlix, essa responsabilidade pertence à classe:

<div class="filme-principal">

Dentro dela encontramos:

<h3 class="titulo">Portugal</h3>

<p class="descricao">
    Venha conhecer uma terra belissima...
</p>

e dois botões principais:

ASSISTIR AGORA
MAIS INFORMAÇÕES

O primeiro direciona para uma playlist do YouTube.

O segundo leva o visitante a um blog com informações adicionais sobre Portugal.

Isso representa um padrão clássico de UX, a experiência do usuário:

  • uma ação principal;

  • uma ação secundária.

A ação principal diz:

Veja o conteúdo.

A ação secundária diz:

Conheça o contexto.

Em termos de sistema, poderíamos representar:

OPÇÃO 1 — EXECUTAR
OPÇÃO 2 — CONSULTAR DETALHES

A interface inspirada na Netflix funciona justamente porque aproveita um modelo mental que o usuário já conhece.

Ele vê um grande banner, encontra um botão de reprodução e imediatamente entende o que deve fazer.

Não é necessário explicar o fluxo.

A própria interface conduz o visitante.


5. O CSS entra na sala de interrogatório

Se o HTML define a estrutura, o CSS define a apresentação.

No arquivo principal de estilos, o LusoFlix começa declarando duas variáveis:

:root {
    --vermelho: #E50914;
    --preta: #141414;
}

Essas são Custom Properties, popularmente chamadas de variáveis CSS.

Em vez de repetir uma cor em vários lugares:

color: #E50914;
background: #141414;

o desenvolvedor pode usar:

color: var(--vermelho);
background: var(--preta);

As variáveis CSS funcionam como constantes de configuração visual.

Para um programador COBOL, a ideia lembra declarar valores centralizados na WORKING-STORAGE:

01 WS-COR-PRINCIPAL PIC X(7) VALUE '#E50914'.

Naturalmente, CSS e COBOL são mundos diferentes, mas a filosofia é semelhante:

Evite espalhar valores mágicos pelo programa.

Se amanhã o LusoFlix quiser trocar o vermelho por verde, basta alterar a variável principal.

Sem variáveis, seria necessário procurar dezenas de ocorrências.

Com variáveis, temos uma espécie de tabela de parâmetros visuais.

As cores escolhidas reproduzem a identidade clássica de uma plataforma de streaming: fundo quase preto, texto branco e destaque vermelho. O arquivo CSS centraliza essas cores e aplica o fundo escuro ao corpo da página.


6. O reset global e o misterioso box-sizing

O projeto utiliza:

* {
    margin: 0;
    padding: 0;
    box-sizing: border-box;
}

O seletor universal * aplica regras a todos os elementos.

Os navegadores incluem margens e espaçamentos padrão em títulos, parágrafos e outros componentes. Ao definir:

margin: 0;
padding: 0;

o desenvolvedor zera esses valores e passa a controlar o layout de forma mais previsível.

Já:

box-sizing: border-box;

resolve um problema histórico do CSS.

Imagine um elemento com:

width: 300px;
padding: 20px;
border: 2px;

No modelo tradicional, a largura total poderia ultrapassar os 300 pixels, pois padding e borda seriam somados à largura declarada.

Com border-box, a largura total permanece dentro dos 300 pixels.

É como reservar um registro de 300 bytes e garantir que os campos internos não ultrapassem o LRECL.

Sem isso, o layout pode sofrer o equivalente visual de um:

IEC141I 013-18

O conteúdo simplesmente não cabe onde deveria.


7. Flexbox: o organizador de filas do HTML moderno

O cabeçalho utiliza Flexbox:

header .container {
    display: flex;
    flex-direction: row;
    align-items: center;
    justify-content: space-between;
}

Essa combinação organiza o logotipo e o menu na mesma linha.

Vamos interpretar cada instrução.

display: flex

Ativa o modelo Flexbox.

flex-direction: row

Organiza os filhos horizontalmente.

align-items: center

Alinha os itens verticalmente ao centro.

justify-content: space-between

Coloca um item no início, outro no final e distribui o espaço entre eles.

Antes do Flexbox, layouts desse tipo frequentemente dependiam de:

  • float;

  • posicionamento absoluto;

  • tabelas;

  • margens negativas;

  • pequenos pactos com forças ocultas.

Com Flexbox, o navegador assume a responsabilidade de calcular os alinhamentos.

O resultado é um código mais legível e adaptável.

O CSS do LusoFlix emprega Flexbox tanto no cabeçalho quanto na organização da área principal.


8. A imagem de fundo e a técnica do gradiente

A área de destaque é construída com:

background:
    linear-gradient(
        rgba(0, 0, 0, .50),
        rgba(0, 0, 0, .50)
    ),
    url('../img/PortugalViagens.png');

Aqui temos duas camadas.

A primeira é um gradiente preto semitransparente.

A segunda é a imagem de Portugal.

O navegador sobrepõe o gradiente à fotografia.

Por que fazer isso?

Porque textos brancos podem perder legibilidade sobre imagens claras.

A camada escura aumenta o contraste e permite que título, descrição e botões continuem visíveis.

Essa técnica é muito comum em:

  • plataformas de streaming;

  • sites de turismo;

  • páginas de jogos;

  • landing pages;

  • portfólios;

  • vitrines de produtos.

O efeito é simples, mas poderoso.

A fotografia continua aparecendo, porém deixa de competir com a informação textual.

É como diminuir o ruído de uma evidência antes de ampliá-la no laboratório.


9. Botões e microinterações

Os botões são estilizados assim:

.botao {
    background-color: rgba(0, 0, 0, .50);
    border: none;
    color: white;
    padding: 15px 30px;
    cursor: pointer;
    transition: .3s ease all;
}

Quando o ponteiro passa sobre o botão:

.botao:hover {
    background-color: white;
    color: black;
}

Temos aqui uma microinteração.

O usuário movimenta o mouse.

O botão reage.

Essa resposta visual confirma:

Este elemento é clicável.

A propriedade:

transition: .3s ease all;

faz a mudança ocorrer suavemente.

Sem transição, a troca de cores seria instantânea.

Com transição, o navegador interpola os valores ao longo de aproximadamente três décimos de segundo.

Parece um detalhe pequeno.

Mas interfaces agradáveis são construídas justamente com pequenos detalhes.

Uma aplicação não precisa executar uma animação cinematográfica a cada clique.

Às vezes basta confirmar elegantemente que o usuário está no caminho certo.


10. O coração visual: os carrosséis

O LusoFlix organiza o acervo em categorias.

Entre elas aparecem:

  • Portugal;

  • Lisboa;

  • Setúbal;

  • Uma Viagem na História;

  • Castelos e vilas medievais;

  • A religiosidade nas igrejas;

  • Praias e rios.

Cada categoria contém miniaturas de vídeos publicadas em um carrossel horizontal. A página pública apresenta dezenas de links do YouTube distribuídos nessas seções temáticas. (Vagner Bellacosa)

A estrutura básica é semelhante a:

<div class="owl-carousel owl-theme">
    <div class="item">
        <a href="VIDEO">
            <img
                class="box-filme"
                src="MINIATURA"
                title="DESCRIÇÃO"
                alt="DESCRIÇÃO">
        </a>
    </div>
</div>

A classe:

owl-carousel

revela o uso da biblioteca Owl Carousel.

Essa biblioteca JavaScript transforma uma lista comum de elementos em um componente deslizável.

Ela pode controlar:

  • quantidade de itens visíveis;

  • navegação;

  • rolagem;

  • responsividade;

  • velocidade;

  • reprodução automática;

  • comportamento em diferentes tamanhos de tela.

O projeto inclui os arquivos CSS do Owl Carousel e seu tema visual no cabeçalho do documento.

Aqui existe uma importante lição arquitetural.

O desenvolvedor não precisa construir tudo do zero.

Usar uma biblioteca consolidada é equivalente a chamar uma rotina confiável em vez de reescrever a mesma lógica em cada programa.

No mainframe, usamos:

  • SORT;

  • IDCAMS;

  • LE routines;

  • APIs de CICS;

  • serviços de Db2;

  • módulos compartilhados.

Na web, utilizamos:

  • bibliotecas;

  • frameworks;

  • componentes;

  • APIs;

  • pacotes.

Reutilização não é preguiça.

É engenharia.

A única condição é compreender o que a dependência faz e quais riscos ela introduz.


11. Onde está o JavaScript?

O visitante pode olhar o HTML do LusoFlix e pensar:

Onde está toda aquela programação JavaScript prometida?

Grande parte do comportamento interativo está relacionada à inicialização do carrossel e às bibliotecas carregadas.

Em projetos desse tipo, o JavaScript costuma conter uma configuração parecida com:

$('.owl-carousel').owlCarousel({
    loop: true,
    margin: 10,
    nav: false,
    responsive: {
        0: {
            items: 1
        },
        600: {
            items: 3
        },
        1000: {
            items: 5
        }
    }
});

A lógica determina quantos cartões serão apresentados conforme a largura da tela.

Em um celular:

1 item por vez

Em uma tela intermediária:

3 itens

Em um desktop:

5 itens

O JavaScript não precisa ser enorme para ser importante.

Nesse projeto, ele atua como um operador de sala de controle.

O HTML fornece os itens.

O CSS fornece a aparência.

O JavaScript coordena a movimentação e a adaptação dinâmica.

Podemos resumir assim:

HTML       = inventário do catálogo
CSS        = cenografia
JavaScript = operador da esteira

12. O YouTube como backend audiovisual

Uma das decisões mais inteligentes do LusoFlix foi não tentar hospedar os vídeos dentro do próprio GitHub Pages.

Os vídeos permanecem no YouTube.

A página funciona como catálogo e ponto de acesso.

Cada miniatura é envolvida por um link:

<a href="https://www.youtube.com/watch?v=...">
    <img src="img/...">
</a>

Quando o usuário clica, o vídeo é aberto no YouTube.

Arquiteturalmente, temos:

LUSOFLIX
   |
   +-- apresenta catálogo
   |
   +-- organiza categorias
   |
   +-- exibe miniaturas
   |
   +-- encaminha reprodução
           |
           +-- YOUTUBE

Isso reduz:

  • consumo de banda;

  • complexidade de infraestrutura;

  • necessidade de servidor próprio;

  • preocupação com codecs;

  • armazenamento de arquivos pesados;

  • desenvolvimento de um player completo.

O YouTube assume responsabilidades como:

  • streaming adaptativo;

  • disponibilidade;

  • armazenamento;

  • player;

  • legendas;

  • compatibilidade;

  • estatísticas;

  • comentários;

  • inscrições;

  • recomendações.

O LusoFlix assume outra missão:

Organizar e contextualizar o acervo.

É uma arquitetura simples, porém coerente.

O portal não tenta substituir o YouTube.

Ele cria uma camada editorial sobre o conteúdo.


13. O canal como arquivo de uma vida em Portugal

Os vídeos não aparecem como elementos aleatórios.

Eles formam um mapa de experiências.

Na seção dedicada a Lisboa, encontramos temas como:

  • Oceanário de Lisboa;

  • Castelo de São Jorge;

  • Campo Pequeno;

  • Terreiro do Paço;

  • chegada aérea à cidade;

  • Sé Catedral;

  • ruas históricas;

  • museus;

  • imigração;

  • memórias pessoais.

Na categoria histórica surgem referências a:

  • Templo de Diana, em Évora;

  • Tavira;

  • Ponte de Prado;

  • Banco de Portugal em Faro;

  • Vila Real de Santo António;

  • Óbidos;

  • Mosteiro de Santa Maria da Vitória;

  • Guimarães.

Também há seções dedicadas a castelos, vilas medievais, igrejas, santuários, praias, rios e localidades da Margem Sul. Esses temas são identificáveis nos títulos e textos alternativos das miniaturas declaradas no HTML.

O canal, portanto, não é apenas um repositório de vídeos turísticos.

Ele mistura:

  • memória familiar;

  • documentação de viagens;

  • história;

  • arquitetura;

  • patrimônio;

  • religiosidade;

  • cotidiano;

  • deslocamentos;

  • imigração;

  • descobertas pessoais.

Isso torna o LusoFlix parecido com uma videoteca temática.

Cada miniatura funciona como uma ficha de catálogo.

Cada categoria funciona como uma coleção.

Cada clique abre um registro audiovisual.

No mainframe, poderíamos imaginar:

ARQUIVO-MESTRE-DE-VIDEOS

com uma chave lógica composta por:

PAÍS + REGIÃO + CATEGORIA + LOCAL + DATA

O que vemos na tela é apenas a camada de apresentação de um acervo muito maior.


14. As miniaturas como registros indexados

Considere este padrão:

<img
    class="box-filme"
    src="img/Historia0007.png"
    title="Encantos medievais em Obidos e suas belas muralhas"
    alt="Encantos medievais em Obidos e suas belas muralhas">

Há três informações fundamentais:

src

Indica o arquivo da imagem.

title

Apresenta uma dica quando o usuário mantém o cursor sobre a miniatura.

alt

Fornece uma descrição alternativa.

O atributo alt é especialmente importante.

Ele pode ser utilizado:

  • por leitores de tela;

  • quando a imagem não carrega;

  • por mecanismos de busca;

  • para contextualização semântica.

Um alt vazio ou genérico desperdiça informação.

Em vez de:

alt="imagem"

é melhor usar:

alt="Vista das muralhas medievais de Óbidos, Portugal"

Isso melhora acessibilidade e SEO.

No LusoFlix, muitas miniaturas já possuem descrições individualizadas, demonstrando a intenção de contextualizar o conteúdo visual.


15. SEO: deixando pistas para os mecanismos de busca

O documento inclui diversas meta tags:

<meta name="Author" content="Vagner Bellacosa">

<meta
    name="Description"
    content="Aplicação dos comandos HTML, CSS e JavaScript...">

Também existem propriedades Open Graph:

<meta property="og:title" content="LusoFlix - Viagens a Portugal">
<meta property="og:site_name" content="LusoFlix">
<meta property="og:description" content="...">
<meta property="og:image" content="...">
<meta property="og:type" content="article">

Essas propriedades ajudam plataformas sociais a gerar uma prévia quando a página é compartilhada.

Sem Open Graph, um link pode aparecer apenas como uma URL seca.

Com os metadados corretos, o compartilhamento pode apresentar:

  • título;

  • descrição;

  • imagem;

  • identificação do site.

É como anexar uma capa, um resumo e uma classificação ao registro antes de enviá-lo para outro sistema.

O projeto também declara autoria, palavras-chave, descrição, imagem social, seção temática e endereço canônico utilizado no compartilhamento.

Atualmente, a meta tag keywords possui pouco peso nos grandes mecanismos de busca, mas a descrição, o título, o conteúdo visível, os cabeçalhos, o texto alternativo e a estrutura semântica continuam importantes.

Uma evolução moderna poderia incluir:

<link
    rel="canonical"
    href="https://vagnerbellacosa.github.io/002_WebDeveloper_ReplicaNetflix/">

E também dados estruturados em JSON-LD:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "CollectionPage",
  "name": "LusoFlix",
  "description": "Catálogo de vídeos sobre Portugal",
  "inLanguage": "pt-BR"
}
</script>

Isso ajudaria os mecanismos de busca a compreenderem que a página representa uma coleção temática.


16. GitHub Pages: o pequeno data center gratuito

O LusoFlix está publicado por meio do GitHub Pages.

Essa solução permite transformar um repositório GitHub em um site estático acessível publicamente.

O fluxo básico é:

ARQUIVOS LOCAIS
      |
      v
GIT COMMIT
      |
      v
GIT PUSH
      |
      v
REPOSITÓRIO GITHUB
      |
      v
GITHUB PAGES
      |
      v
SITE PUBLICADO

Para projetos HTML, CSS e JavaScript que não dependem de processamento no servidor, o GitHub Pages é extremamente útil.

Ele pode hospedar:

  • portfólios;

  • documentação;

  • páginas institucionais;

  • demonstrações;

  • laboratórios;

  • currículos;

  • catálogos;

  • jogos JavaScript;

  • páginas educacionais;

  • protótipos.

O repositório do LusoFlix contém diretórios separados para imagens, JavaScript e estilos, além do index.html, documentação, licença e histórico de commits. (GitHub)

Essa organização já introduz boas práticas:

/index.html
/img
/js
/style

É simples, direta e compreensível para quem está começando.


17. O que o HTML moderno permite fazer?

O LusoFlix demonstra uma parte do poder da web, mas o HTML moderno permite ir muito além.

Hoje, um navegador é quase uma pequena plataforma operacional.

Com tecnologias abertas, podemos criar:

  • players de vídeo;

  • editores;

  • jogos;

  • dashboards;

  • aplicativos offline;

  • mapas;

  • gráficos;

  • sistemas de voz;

  • videoconferência;

  • reconhecimento de dispositivos;

  • armazenamento local;

  • notificações;

  • aplicações instaláveis;

  • experiências tridimensionais.

Vamos examinar algumas possibilidades.


18. Vídeos incorporados diretamente na página

O próprio código possui um comentário indicando uma intenção futura de incorporar vídeos do YouTube ao corpo da página.

Isso poderia ser feito com:

<iframe
    src="https://www.youtube.com/embed/ID_DO_VIDEO"
    title="Vídeo sobre Portugal"
    loading="lazy"
    allowfullscreen>
</iframe>

A vantagem seria permitir a reprodução sem abandonar o LusoFlix.

Uma evolução ainda melhor seria abrir o vídeo em uma janela modal:

CLIQUE NA MINIATURA
        |
        v
ABRE MODAL
        |
        v
CARREGA PLAYER
        |
        v
REPRODUZ VÍDEO

O JavaScript poderia capturar o clique:

const cards = document.querySelectorAll('[data-video]');

cards.forEach(card => {
    card.addEventListener('click', () => {
        abrirVideo(card.dataset.video);
    });
});

Assim, cada cartão receberia:

<button data-video="ylPVYS7Rgyg">
    <img src="img/portugal0001.png" alt="Elvas">
</button>

O uso de button seria semanticamente melhor quando a ação não fosse navegar, mas abrir uma interface interna.


19. Carregamento preguiçoso de imagens

Uma página com dezenas de miniaturas pode consumir muitos recursos.

O HTML moderno oferece:

<img
    src="img/miniatura.png"
    loading="lazy"
    alt="Descrição do vídeo">

Com loading="lazy", o navegador adia o carregamento de imagens que ainda estão fora da área visível.

Isso melhora:

  • tempo inicial de abertura;

  • consumo de banda;

  • experiência em celulares;

  • desempenho;

  • métricas de carregamento.

É semelhante a não carregar um arquivo inteiro quando o programa utilizará apenas alguns registros.

A diferença é que o navegador administra esse acesso sob demanda.


20. Imagens responsivas

O atributo srcset, presente em várias imagens do projeto, pode ser explorado de forma mais completa.

Por exemplo:

<img
    src="img/lisboa-800.jpg"
    srcset="
        img/lisboa-400.jpg 400w,
        img/lisboa-800.jpg 800w,
        img/lisboa-1200.jpg 1200w
    "
    sizes="
        (max-width: 600px) 90vw,
        300px
    "
    alt="Vista histórica de Lisboa">

O navegador escolhe automaticamente a imagem mais apropriada.

Um celular não precisa baixar uma imagem de 3.000 pixels se ela será exibida em um cartão de 300 pixels.

Isso é otimização orientada pelo cliente.


21. CSS Grid: organizando catálogos complexos

O Flexbox é excelente para linhas e alinhamentos.

O CSS Grid é especialmente poderoso para layouts bidimensionais.

Uma futura página de pesquisa do LusoFlix poderia utilizar:

.catalogo {
    display: grid;
    grid-template-columns:
        repeat(auto-fit, minmax(220px, 1fr));
    gap: 1rem;
}

Essa única regra cria uma grade adaptável.

Os cartões se reorganizam conforme a largura disponível.

Em desktop:

[1] [2] [3] [4] [5]

Em tablet:

[1] [2] [3]
[4] [5]

Em celular:

[1]
[2]
[3]

Sem calcular manualmente cada posição.

É uma revolução quando comparada às antigas tabelas HTML utilizadas para diagramar páginas.


22. Busca dinâmica com JavaScript

Imagine um campo:

<input
    type="search"
    id="busca"
    placeholder="Pesquisar Lisboa, castelos, praias...">

O JavaScript poderia filtrar os cartões:

const busca = document.querySelector('#busca');
const videos = document.querySelectorAll('.video-card');

busca.addEventListener('input', evento => {
    const termo = evento.target.value.toLowerCase();

    videos.forEach(video => {
        const texto = video.textContent.toLowerCase();
        video.hidden = !texto.includes(termo);
    });
});

O usuário poderia digitar:

castelo

e visualizar apenas os vídeos relacionados.

Isso transformaria o catálogo estático em uma interface de consulta.

O equivalente mainframe seria sair de uma listagem sequencial e criar uma pesquisa indexada.


23. Catálogo alimentado por JSON

No código atual, cada vídeo é declarado manualmente no HTML.

Funciona, mas gera repetição.

Uma arquitetura moderna poderia armazenar o catálogo em JSON:

[
  {
    "titulo": "Castelo de São Jorge",
    "categoria": "Lisboa",
    "videoId": "rjypUMC2RxI",
    "imagem": "img/lisboa0002.png"
  },
  {
    "titulo": "Templo de Diana em Évora",
    "categoria": "História",
    "videoId": "gLpjM3Xn2Rk",
    "imagem": "img/Historia0001.png"
  }
]

O JavaScript carregaria esses dados:

fetch('./data/videos.json')
    .then(resposta => resposta.json())
    .then(videos => montarCatalogo(videos))
    .catch(erro => console.error(
        'Falha ao carregar catálogo:',
        erro
    ));

A página seria criada dinamicamente.

As vantagens seriam:

  • menos repetição;

  • manutenção facilitada;

  • filtros;

  • ordenação;

  • busca;

  • geração automática de categorias;

  • possibilidade de integrar APIs.

Em termos de arquitetura:

ANTES
HTML = estrutura + dados + catálogo

DEPOIS
HTML = estrutura
CSS  = apresentação
JSON = dados
JS   = montagem e comportamento

Essa separação lembra a divisão entre programa, arquivo e camada de apresentação.


24. Progressive Web App: um LusoFlix instalável

Com um arquivo de manifesto e um Service Worker, o LusoFlix poderia se tornar uma Progressive Web App, ou PWA.

Isso permitiria:

  • instalação na tela inicial;

  • ícone próprio;

  • abertura semelhante a aplicativo;

  • cache de arquivos;

  • funcionamento parcial offline;

  • carregamento mais rápido em visitas futuras.

Um manifesto básico poderia declarar:

{
  "name": "LusoFlix",
  "short_name": "LusoFlix",
  "start_url": "/",
  "display": "standalone",
  "background_color": "#141414",
  "theme_color": "#E50914"
}

O Service Worker poderia armazenar:

  • HTML;

  • CSS;

  • JavaScript;

  • logotipo;

  • imagens principais.

Naturalmente, os vídeos do YouTube ainda dependeriam de conexão.

Mas a estrutura do catálogo poderia continuar acessível.


25. Acessibilidade: o usuário que não vemos

Uma interface moderna deve ser utilizável por pessoas com diferentes necessidades.

Algumas melhorias possíveis seriam:

Navegação por teclado

Todos os cartões e controles precisam ser alcançáveis com Tab.

Foco visível

a:focus-visible,
button:focus-visible {
    outline: 3px solid white;
    outline-offset: 3px;
}

Botões semanticamente corretos

Evitar colocar <button> dentro de <a> quando uma única ação pode ser representada por um link estilizado.

Por exemplo:

<a class="botao" href="PLAYLIST">
    Assistir agora
</a>

Rótulos descritivos

<a
    href="VIDEO"
    aria-label="Assistir ao vídeo sobre o Castelo de São Jorge">

Contraste

Garantir que textos cinza possuam contraste suficiente sobre o fundo escuro.

Movimento reduzido

@media (prefers-reduced-motion: reduce) {
    * {
        scroll-behavior: auto;
        transition: none;
        animation: none;
    }
}

Uma interface acessível não é uma versão especial do sistema.

É o sistema construído corretamente.


26. Pequenas evidências encontradas no código

Toda investigação encontra detalhes curiosos.

No LusoFlix, alguns pontos merecem atenção.

Há links em determinadas seções nos quais as aspas do endereço parecem não estar encerradas antes de target="_blank".

Um exemplo conceitual do problema seria:

<a href="https://www.youtube.com/watch?v=ABC target="_blank">

O correto é:

<a
    href="https://www.youtube.com/watch?v=ABC"
    target="_blank"
    rel="noopener noreferrer">

Quando usamos target="_blank", também é recomendável adicionar:

rel="noopener noreferrer"

Isso reduz riscos associados à página aberta acessar o contexto da página original.

Também aparecem casos de atributos alt duplicados em algumas imagens.

O navegador normalmente tentará tolerar o erro, mas o HTML deveria manter apenas um atributo:

<img
    src="imagem.png"
    alt="Descrição correta">

Esses problemas não diminuem o mérito do projeto.

Ao contrário.

Eles são parte natural do aprendizado.

Todo código antigo funciona como uma fotografia do conhecimento que tínhamos quando o escrevemos.

Revisitar um projeto anos depois é semelhante a abrir um programa COBOL da década de 1990.

Você encontra:

  • decisões corretas;

  • soluções criativas;

  • limitações da época;

  • convenções antigas;

  • oportunidades de modernização;

  • e comentários que parecem mensagens deixadas por uma versão anterior de nós mesmos.


27. Modernizar sem destruir a personalidade

Uma atualização do LusoFlix não deveria apagar sua origem.

Seria um erro transformá-lo em mais um template genérico, tecnicamente perfeito e emocionalmente vazio.

A modernização ideal preservaria:

  • o nome;

  • o tema português;

  • o vermelho característico;

  • as miniaturas;

  • a divisão por localidades;

  • a conexão com o canal;

  • o caráter de diário audiovisual;

  • a simplicidade do projeto original.

Ao mesmo tempo, poderia adicionar:

  • modal de reprodução;

  • busca;

  • filtros;

  • carregamento dinâmico;

  • catálogo JSON;

  • melhor responsividade;

  • acessibilidade;

  • lazy loading;

  • dados estruturados;

  • página individual para cada vídeo;

  • favoritos em localStorage;

  • compartilhamento pela Web Share API;

  • modo claro e escuro;

  • mapa interativo de Portugal.

A modernização correta não pergunta:

Como substituímos tudo?

Ela pergunta:

O que merece permanecer e o que precisa evoluir?

Essa é a mesma pergunta feita em qualquer projeto sério de modernização de legado.


28. Um mapa interativo para as viagens

Uma expansão fascinante seria relacionar vídeos a localidades geográficas.

Cada registro poderia possuir:

{
  "titulo": "Castelo de São Jorge",
  "cidade": "Lisboa",
  "latitude": 38.7139,
  "longitude": -9.1335,
  "videoId": "..."
}

Uma biblioteca de mapas poderia apresentar marcadores em:

  • Lisboa;

  • Setúbal;

  • Évora;

  • Tavira;

  • Faro;

  • Óbidos;

  • Guimarães;

  • Fátima;

  • Sintra;

  • Tomar;

  • Leiria;

  • Elvas.

O visitante poderia clicar em um ponto do mapa e abrir o vídeo correspondente.

A experiência deixaria de ser apenas um catálogo linear.

Tornar-se-ia uma viagem digital.

MAPA
 |
 +-- LISBOA
 |     +-- CASTELO
 |     +-- OCEANÁRIO
 |     +-- BELÉM
 |
 +-- ÉVORA
 |     +-- TEMPLO DE DIANA
 |
 +-- SINTRA
       +-- CASTELO DOS MOUROS

Seria praticamente um KSDS turístico, no qual a chave de acesso seria a localização geográfica.


29. Favoritos com localStorage

O navegador permite armazenar pequenas informações localmente.

Um visitante poderia marcar vídeos favoritos:

const favoritos =
    JSON.parse(localStorage.getItem('favoritos')) || [];

function salvarFavorito(videoId) {
    if (!favoritos.includes(videoId)) {
        favoritos.push(videoId);

        localStorage.setItem(
            'favoritos',
            JSON.stringify(favoritos)
        );
    }
}

Na próxima visita, os favoritos continuariam disponíveis.

Isso não exige banco de dados nem autenticação.

É armazenamento local no navegador.

Naturalmente, possui limitações:

  • os dados ficam naquele dispositivo;

  • podem ser apagados;

  • não são sincronizados;

  • não servem para informações sensíveis.

Mas, para um catálogo pessoal, é uma solução simples e eficiente.


30. Web Share API: compartilhar uma descoberta

Em celulares compatíveis, a Web Share API permite abrir o menu nativo de compartilhamento:

async function compartilhar(video) {
    if (!navigator.share) {
        return;
    }

    await navigator.share({
        title: video.titulo,
        text: 'Conheça este lugar em Portugal',
        url: video.url
    });
}

O visitante poderia compartilhar o vídeo por:

  • WhatsApp;

  • e-mail;

  • redes sociais;

  • aplicativos instalados.

O navegador torna-se uma ponte entre a página e o sistema operacional.


31. O HTML como plataforma, não apenas marcação

Durante muitos anos, ensinar HTML significava apresentar:

<h1>
<p>
<a>
<img>
<table>

Tudo isso continua importante.

Mas a plataforma web moderna inclui muito mais.

O navegador atual oferece recursos para:

  • áudio e vídeo;

  • desenho com Canvas;

  • gráficos vetoriais SVG;

  • comunicação em tempo real;

  • armazenamento;

  • criptografia;

  • localização, mediante autorização;

  • câmera e microfone, mediante autorização;

  • arrastar e soltar;

  • arquivos locais;

  • notificações;

  • execução offline;

  • acessibilidade;

  • animações;

  • componentes personalizados;

  • integração com dispositivos.

O HTML não substitui sozinho Java, C#, COBOL ou Python.

Mas, combinado com CSS e JavaScript, ele se transforma na interface universal de inúmeros sistemas.

O navegador é hoje o terminal de acesso do mundo.

O 3270 conectava o usuário ao mainframe.

O browser conecta o usuário a:

  • nuvens;

  • APIs;

  • bancos;

  • vídeos;

  • aplicações corporativas;

  • inteligência artificial;

  • sistemas governamentais;

  • comércio eletrônico;

  • plataformas educacionais.

Mudou a tela.

A necessidade de arquitetura permaneceu.


32. Um exercício que ensina mais do que parece

À primeira vista, o LusoFlix pode parecer apenas um clone visual criado em um bootcamp.

Mas, ao investigarmos o projeto, encontramos várias disciplinas:

HTML

Estrutura, links, imagens, metadados e semântica.

CSS

Cores, Flexbox, fundos, gradientes, botões, hover e responsividade.

JavaScript

Inicialização de componentes e comportamento do carrossel.

Bibliotecas

Owl Carousel, ícones e dependências externas.

UX

Organização por categorias e ações claramente identificadas.

Arquitetura de conteúdo

Classificação dos vídeos por região e tema.

SEO

Descrição, título, Open Graph e textos alternativos.

DevOps básico

Versionamento com Git e publicação no GitHub Pages.

Produção audiovisual

Integração com vídeos e playlists do YouTube.

Identidade

Transformação de um exercício genérico em uma homenagem pessoal a Portugal.

Isso é desenvolvimento de software.

Não se trata apenas de escrever comandos.

Trata-se de combinar tecnologias para comunicar uma ideia.


33. Passo a passo para um padawan criar seu próprio catálogo

Um desenvolvedor iniciante poderia usar o LusoFlix como referência e seguir esta sequência.

Passo 1 — Escolher um tema

Pode ser:

  • viagens;

  • mainframe;

  • animes;

  • filmes clássicos;

  • cursos;

  • músicas;

  • jogos;

  • patrimônio histórico;

  • receitas;

  • vídeos familiares.

Passo 2 — Criar a estrutura

/projeto
    index.html
    /css
    /js
    /img
    /data

Passo 3 — Montar o HTML sem estilo

Primeiro, crie:

  • cabeçalho;

  • menu;

  • destaque;

  • categorias;

  • cartões;

  • rodapé.

Passo 4 — Aplicar o CSS

Defina:

  • paleta;

  • tipografia;

  • espaçamento;

  • Flexbox;

  • Grid;

  • estados de hover;

  • responsividade.

Passo 5 — Adicionar JavaScript

Implemente:

  • carrossel;

  • busca;

  • filtros;

  • modal;

  • favoritos.

Passo 6 — Trabalhar acessibilidade

Revise:

  • alt;

  • foco;

  • teclado;

  • contraste;

  • títulos;

  • rótulos.

Passo 7 — Melhorar SEO

Inclua:

  • título;

  • descrição;

  • Open Graph;

  • canonical;

  • JSON-LD;

  • conteúdo textual útil.

Passo 8 — Publicar

Use:

  • Git;

  • GitHub;

  • GitHub Pages.

Passo 9 — Testar

Teste em:

  • desktop;

  • celular;

  • tablet;

  • teclado;

  • conexão lenta;

  • imagens desativadas.

Passo 10 — Evoluir

Não tente terminar tudo na primeira versão.

Publique.

Observe.

Melhore.


34. Easter egg localizado

Entre os textos das miniaturas existe uma referência curiosa a:

42 e a resposta

Para os viajantes intergalácticos que carregam uma toalha, o número 42 é a resposta para a pergunta fundamental sobre a vida, o universo e tudo mais.

No LusoFlix, ele aparece associado a uma memória de aniversário.

É um pequeno detalhe, mas combina perfeitamente com a tradição Bellacosa:

  • tecnologia;

  • memória;

  • cultura pop;

  • viagens;

  • uma referência escondida esperando ser descoberta.

Todo bom sistema possui documentação.

Todo grande sistema possui lendas.


35. Conclusão: o clone que deixou de ser clone

O LusoFlix começou como um exercício inspirado na Netflix.

Mas chamar o projeto apenas de clone seria reduzir sua importância.

Tecnicamente, ele demonstra fundamentos essenciais:

  • HTML5;

  • CSS3;

  • Flexbox;

  • variáveis CSS;

  • gradientes;

  • responsividade;

  • bibliotecas JavaScript;

  • carrosséis;

  • integração com conteúdo externo;

  • SEO;

  • GitHub Pages.

Culturalmente, ele faz algo mais valioso.

Organiza lembranças sobre Portugal.

Transforma vídeos dispersos em coleções.

Apresenta Lisboa, Setúbal, castelos, igrejas, praias e cidades históricas como se fossem temporadas de uma grande série documental.

O visitante não encontra apenas cartões clicáveis.

Encontra registros de uma jornada.

E talvez essa seja a principal lição para quem começa a programar para a web.

Você pode aprender HTML criando uma página de exercícios.

Pode aprender CSS copiando um layout.

Pode aprender JavaScript movimentando um carrossel.

Mas o verdadeiro salto acontece quando o projeto deixa de ser uma reprodução e passa a carregar sua identidade.

O LusoFlix usa a linguagem visual de uma plataforma mundial para contar uma história pessoal sobre Portugal.

O código é simples.

A arquitetura é estática.

A infraestrutura é leve.

Mas a ideia é poderosa.

Porque software não é apenas aquilo que o computador executa.

Software também é aquilo que o desenvolvedor decide preservar.

No Bellacosa Mainframe, um registro somente existe enquanto permanece gravado.

Na web, uma memória somente atravessa o tempo quando alguém decide transformá-la em:

<article>
    <h1>Uma história que merece continuar acessível</h1>
</article>

E assim encerramos esta investigação.

O HTML estruturou a cena.

O CSS acendeu as luzes.

O JavaScript colocou o catálogo em movimento.

O YouTube armazenou as imagens do passado.

E o LusoFlix provou que um simples exercício de bootcamp pode se transformar em uma pequena cápsula digital de viagens, afetos e histórias portuguesas.

RETURN-CODE = 0000
CATÁLOGO CARREGADO
MEMÓRIA PRESERVADA
CAFÉ AINDA QUENTE

O texto já está estruturado para publicação no Blogspot, com introdução, análise técnica, exemplos, curiosidades, melhorias e conclusão no estilo Bellacosa Mainframe.

Produção original Bellacosa

LusoFlix: HTML, CSS e JavaScript

Uma coleção sobre desenvolvimento web, estudos em JavaScript, desafios de programação e o projeto LusoFlix, uma experiência visual inspirada nas plataformas de streaming e dedicada às viagens, histórias, castelos e paisagens de Portugal.

  • HTML5
  • CSS3
  • JavaScript
  • GitHub Pages
  • DIO
  • Portugal

Central de exibição

Explore o projeto e os artigos sem sair desta página. Caso o site de origem impeça a exibição em iframe, utilize o botão “Abrir original” abaixo de cada quadro.

Desenvolvimento web, JavaScript e aprendizagem contínua

O LusoFlix é um projeto front-end inspirado na experiência visual de uma plataforma de streaming. Desenvolvido com HTML, CSS e JavaScript, apresenta um catálogo de vídeos sobre Portugal organizado por temas como Lisboa, Setúbal, turismo, gastronomia, castelos, localidades históricas, igrejas, praias e rios.

O projeto demonstra como o HTML estrutura o conteúdo, como o CSS cria a identidade visual e como o JavaScript adiciona comportamento e interatividade. A publicação no GitHub Pages transforma o repositório em uma aplicação acessível diretamente pelo navegador.

JavaScript e plano de estudos

O artigo Dia 7: JavaScript e Plano de Estudos apresenta uma estratégia de aprendizagem baseada em aulas, exercícios, anotações, pesquisas, documentação oficial, repositórios GitHub, depuração no navegador e prática constante.

Bootcamps, desafios e comunidade

O artigo Dia 21: Minha incrível aventura nos desafios da DIO registra experiências com cursos, bootcamps, laboratórios, desafios de programação, VS Code, Node.js, fóruns, mentorias e produção de conhecimento para a comunidade de desenvolvedores.

Juntos, os três conteúdos formam uma pequena trilogia sobre criação, estudo e evolução profissional: primeiro o programador organiza sua aprendizagem, depois enfrenta os desafios e, finalmente, transforma conhecimento em um projeto web publicado.

Bellacosa Mainframe Developer Collection
HTML, CSS, JavaScript, GitHub Pages, educação tecnológica e compartilhamento de conhecimento.
Vagner Renato Bellacosa, IBM Champion e especialista em IBM Mainframe
IBM Z17 SYSTEM ONLINE
Sobre o autor

Vagner Renato Bellacosa

IBM Champion 2026 • Especialista em IBM Mainframe

Vagner Renato Bellacosa trabalha com IBM Mainframe desde 1988 , é IBM Champion e especialista em COBOL, CICS, Db2, z/OS e IBM Z. Compartilha experiências profissionais, conhecimento técnico, história da computação e práticas do universo mainframe para aproximar novas gerações das tecnologias que sustentam empresas, bancos e governos ao redor do mundo.

IBM Champion IBM Z COBOL CICS Db2 z/OS Mainframe desde 1988
GitHub LinkedIn
Inicializando conteúdo...