☕ Um Café no Bellacosa Mainframe
Gostou do conteúdo? Ajude a manter o café quente, o COBOL compilando e o mainframe acordado. 😄
☕ Pague um café ao Bellacosa

Translate

Mostrar mensagens com a etiqueta Star Trek. Mostrar todas as mensagens
Mostrar mensagens com a etiqueta Star Trek. Mostrar todas as mensagens

terça-feira, 8 de setembro de 2026

Star Trek Acertou o Futuro... Mas Será Que Nós Acertamos a Humanidade?

 

Bellacosa Mainframe e o legado dos 60 anos de Star Trek

☕ Um Café no Bellacosa Mainframe

Star Trek Acertou o Futuro... Mas Será Que Nós Acertamos a Humanidade?

60 Anos Depois, Vivemos Cercados por Inteligência Artificial, Internet, IoT e Guerras. A Pergunta Não É Mais se Conseguimos Construir a Tecnologia. É Se Ainda Conseguiremos Construir a Federação.

"O futuro nunca foi sobre naves estelares. Sempre foi sobre pessoas."

Existe uma cena invisível que acontece todos os dias.

Um programador COBOL em um banco processa milhões de transações que mantêm economias inteiras funcionando.

Um satélite transmite informações para outro continente.

Uma Inteligência Artificial auxilia um médico a identificar um tumor.

Um sensor IoT detecta um incêndio antes que ele destrua uma floresta.

Uma criança conversa naturalmente com uma máquina.

Um astronauta observa a Terra do espaço.

Enquanto isso...

Em outro lugar do planeta, cidades são destruídas por mísseis.

Hospitais ficam sem energia.

Crianças crescem em meio a conflitos.

Governos disputam poder.

Hackers atacam infraestruturas críticas.

Fake news dividem sociedades.

A mesma tecnologia capaz de salvar vidas também pode ampliar destruição.

E então percebemos algo curioso.

Sessenta anos depois da estreia de Star Trek, finalmente conseguimos construir boa parte da tecnologia imaginada por Gene Roddenberry.

Mas ainda estamos tentando aprender a parte mais difícil.

Como sermos dignos dela.

Pegue seu café.

Hoje não vamos revisitar apenas uma série de televisão.

Vamos conversar sobre um espelho.

Porque talvez Star Trek nunca tenha mostrado o futuro.

Talvez tenha mostrado aquilo que ainda estamos tentando alcançar.


Bellacosa Mainframe Star Trek Setembro de 1966

Setembro de 1966

Imagine aquele momento.

O homem ainda não havia chegado à Lua.

A Internet não existia.

A palavra "software" mal era conhecida.

Os computadores ocupavam salas inteiras.

COBOL tinha poucos anos de vida.

Mainframes utilizavam cartões perfurados.

Programar era quase um ritual.

Foi exatamente nesse cenário que apareceu uma pequena série chamada Star Trek.

Pouca audiência.

Baixo orçamento.

Cenários simples.

Uniformes coloridos.

E uma ideia absurdamente ambiciosa.

Mostrar uma humanidade que havia sobrevivido aos próprios erros.


Gene Roddenberry não queria prever tecnologia

Ele queria prever maturidade.

Essa talvez seja a maior confusão que as pessoas fazem.

Quando lembram de Star Trek, pensam imediatamente em:

teletransporte.

phasers.

dobra espacial.

Enterprise.

Mas isso era apenas o cenário.

O verdadeiro roteiro sempre foi outro.

Roddenberry perguntava:

Como seria uma sociedade onde ciência, ética, diversidade e curiosidade finalmente caminhassem juntas?

Sessenta anos depois...

Essa pergunta continua sem resposta.


O futuro chegou...

Só que de uma forma muito diferente.

Olhe ao seu redor.

Você provavelmente possui no bolso um smartphone milhares de vezes mais poderoso que qualquer computador usado pela NASA durante o Projeto Apollo.

Você conversa com uma Inteligência Artificial.

Faz videoconferências.

Traduz idiomas instantaneamente.

Compra produtos sem sair de casa.

Controla lâmpadas por voz.

Recebe informações de relógios inteligentes.

Utiliza GPS.

Streaming.

Computação em nuvem.

Blockchain.

Computação quântica em desenvolvimento.

Carros parcialmente autônomos.

Sensores espalhados por cidades inteiras.

Internet das Coisas.

Modelos generativos capazes de escrever código.

Se alguém mostrasse tudo isso para uma pessoa de 1966...

Ela provavelmente acreditaria estar vendo tecnologia vulcana.


E mesmo assim...

Ainda fazemos guerras.

Essa talvez seja a maior ironia do século XXI.

Nossa inteligência técnica evoluiu numa velocidade impressionante.

Nossa inteligência social...

Nem tanto.

Continuamos discutindo fronteiras.

Continuamos divididos por ideologias.

Continuamos produzindo armas cada vez mais sofisticadas.

Criamos drones inteligentes.

Ataques cibernéticos.

Campanhas de desinformação.

Espionagem digital.

Sabotagem de infraestrutura.

A tecnologia avançou.

Mas o coração humano continua enfrentando velhos desafios.


O computador da Enterprise

Hoje mora no seu bolso.

Lembra do comunicador?

Virou smartphone.

O PADD?

Virou tablet.

O computador de bordo?

Hoje responde perguntas por voz.

O Tradutor Universal?

Está presente em aplicativos que traduzem dezenas de idiomas em tempo real.

A videoconferência?

É rotina.

Os sensores médicos?

Estão em relógios inteligentes.

A Inteligência Artificial?

Finalmente começou a conversar naturalmente.

O curioso é que nenhuma dessas tecnologias surgiu por acaso.

Milhares de engenheiros cresceram assistindo Star Trek.

Primeiro imaginaram.

Depois construíram.


O COBOL também faz parte dessa história

Pode parecer estranho ligar Star Trek ao mainframe.

Mas pense comigo.

Enquanto milhões de pessoas sonhavam com naves espaciais...

Os bancos precisavam continuar funcionando.

As aposentadorias precisavam ser pagas.

As passagens aéreas precisavam ser emitidas.

Os governos precisavam processar impostos.

Hospitais precisavam registrar pacientes.

Empresas precisavam sobreviver.

Tudo isso aconteceu graças a profissionais que construíram sistemas robustos.

Entre eles...

Programadores COBOL.

Talvez nunca apareçam em filmes.

Mas são parte silenciosa da infraestrutura que mantém a sociedade funcionando.

Assim como Scotty.

Quase ninguém lembrava dele quando tudo estava funcionando.

Mas bastava uma pane no motor de dobra para perceber sua importância.


Scotty era um Sysprog

Essa é uma das minhas analogias favoritas.

Imagine a Enterprise.

Kirk lidera.

Spock analisa.

McCoy cuida das pessoas.

Uhura comunica.

Sulu pilota.

Scotty mantém tudo funcionando.

Ele não aparece apenas para apertar botões.

Ele entende profundamente a máquina.

Conhece seus limites.

Improvisa quando necessário.

Resolve problemas sob pressão.

Quem trabalha com IBM Z conhece bem esse sentimento.

Quando um ambiente crítico para.

Não existe espaço para pânico.

Existe diagnóstico.

Existe método.

Existe experiência.

Existe equipe.


Spock e a Inteligência Artificial

Em 2026 falamos muito sobre IA.

Modelos.

LLMs.

Agentes.

Automação.

Mas existe um detalhe curioso.

Spock nunca foi apenas lógico.

Ele também era extremamente ético.

Essa diferença é enorme.

Uma Inteligência Artificial pode responder.

Mas deve responder?

Pode executar uma ação.

Mas deveria executá-la?

Star Trek fazia essas perguntas décadas antes de existir ChatGPT.


O perigo da tecnologia sem ética

Hoje uma IA consegue gerar imagens.

Escrever código.

Criar vídeos.

Produzir vozes.

Descobrir padrões invisíveis.

Mas ela também pode:

enganar.

manipular.

produzir fraudes.

espalhar desinformação.

invadir privacidade.

automatizar ataques.

Não é diferente do motor de dobra.

Toda tecnologia poderosa exige responsabilidade proporcional.

Essa talvez seja a maior lição de Star Trek.


A Federação nunca foi construída por máquinas

Foi construída por pessoas.

Existe uma frase que sempre me impressiona.

A Federação não venceu porque possuía as armas mais fortes.

Venceu porque conseguia cooperar.

Imagine isso no mundo da computação.

Arquitetos.

Programadores.

Segurança.

DevOps.

Banco de Dados.

Mainframe.

Cloud.

IA.

Todos trabalhando juntos.

É praticamente uma ponte da Enterprise moderna.


A Internet nos conectou...

Mas nem sempre nos aproximou.

Quando a Internet surgiu comercialmente, muitos acreditavam que ela acabaria com preconceitos.

Que aproximaria culturas.

Que democratizaria conhecimento.

Em parte...

Isso aconteceu.

Hoje aprendemos praticamente qualquer assunto.

Conversamos com pessoas do outro lado do planeta.

Participamos de comunidades globais.

Mas também descobrimos que algoritmos podem criar bolhas.

Polarizações.

Radicalização.

Fake news.

Star Trek imaginava uma humanidade unificada.

Nós criamos uma rede mundial.

Agora precisamos aprender a usá-la como uma Federação, e não como campos de batalha digitais.


Internet das Coisas

Imagine explicar IoT para alguém de 1966.

Geladeiras conectadas.

Carros conectados.

Semáforos inteligentes.

Sensores agrícolas.

Satélites monitorando florestas.

Casas automatizadas.

Tudo parece ficção científica.

Mas já é cotidiano.

Curiosamente...

Quanto mais dispositivos conectamos...

Mais precisamos de segurança.

A Enterprise também ensinava isso.

Cada sistema adicional aumentava responsabilidade.


O maior legado não foi tecnológico

Foi psicológico.

Star Trek ensinou milhões de jovens a gostar de ciência.

A gostar de engenharia.

A gostar de astronomia.

A gostar de computadores.

A gostar de explorar.

Isso não aparece em estatísticas.

Mas aparece em universidades.

Laboratórios.

Empresas.

Agências espaciais.

Centros de pesquisa.

Muitos cientistas simplesmente decidiram seguir carreira porque um dia assistiram Spock resolver um problema usando lógica.


E você, Padawan?

Talvez esteja aprendendo COBOL em 2026.

Alguns amigos perguntam:

"Por que estudar uma linguagem tão antiga?"

Eu responderia com outra pergunta.

Por que ainda estudamos Shakespeare?

Por que ainda estudamos Aristóteles?

Porque certas obras não envelhecem.

Elas se tornam fundamentos.

COBOL é um fundamento da computação corporativa.

Star Trek é um fundamento da imaginação tecnológica.

Ambos continuam relevantes porque resolveram problemas que permanecem importantes.


A verdadeira fronteira final

Quando ouvimos essa frase...

Pensamos imediatamente no espaço.

Mas talvez a fronteira final nunca tenha sido Marte.

Nem Júpiter.

Nem outra galáxia.

Talvez seja nossa própria capacidade de cooperar.

De construir tecnologias responsáveis.

De equilibrar Inteligência Artificial com ética.

De preservar liberdade.

De compartilhar conhecimento.

De usar ciência para reduzir sofrimento.

Essa continua sendo nossa missão.


Sessenta anos depois...

Ainda precisamos de Kirk.

Precisamos de líderes.

Precisamos de Spock.

Precisamos de pensamento crítico.

Precisamos de McCoy.

Precisamos de empatia.

Precisamos de Scotty.

Precisamos de engenheiros competentes.

Precisamos de Uhura.

Precisamos de comunicação.

Precisamos de Sulu.

Precisamos de disciplina.

Precisamos de Chekov.

Precisamos de jovens trazendo novas ideias.

Mais do que nunca.


Uma carta de um velho programador aos novos Padawans

Se você está começando sua jornada em tecnologia, talvez a velocidade das mudanças assuste.

Hoje existe IA.

Amanhã surgirá outra revolução.

Depois computação quântica.

Depois novas arquiteturas.

Depois algo que ainda nem imaginamos.

Não tente decorar tudo.

Aprenda aquilo que Star Trek ensinou.

Aprenda a pensar.

Aprenda a colaborar.

Aprenda a questionar.

Aprenda a respeitar diferenças.

Aprenda a estudar continuamente.

Tecnologias mudam.

Princípios permanecem.

Foi assim em 1966.

Foi assim em 1980.

Foi assim na era dos mainframes.

Foi assim na Internet.

É assim na Inteligência Artificial.

E continuará sendo.


☕ Considerações finais do Bellacosa Mainframe

Quando Star Trek estreou, ninguém imaginava que, seis décadas depois, conversaríamos com inteligências artificiais, carregaríamos supercomputadores no bolso e conectaríamos bilhões de dispositivos à Internet.

Gene Roddenberry acertou muitas previsões tecnológicas.

Mas sua maior previsão não era sobre máquinas.

Era sobre nós.

Ele acreditava que a humanidade poderia crescer junto com sua tecnologia.

Essa continua sendo a missão mais difícil.

Como programador COBOL da velha guarda, depois de décadas convivendo com mainframes que nunca podem falhar, aprendi uma lição simples: o hardware mais poderoso, o software mais elegante e a IA mais avançada ainda dependem das escolhas humanas.

É por isso que, sessenta anos depois, Star Trek continua sendo mais do que entretenimento.

Ela permanece como um manual de princípios para engenheiros, cientistas, arquitetos de sistemas, desenvolvedores, operadores, pesquisadores e todos aqueles que acreditam que conhecimento deve servir à humanidade.

E talvez esse seja o maior legado da USS Enterprise.

Ela nunca nos convidou apenas para explorar novas galáxias.

Ela nos convidou a construir um futuro em que valha a pena chegar.

Vida longa e próspera, Padawan.

E que sua missão, seja em COBOL, em Inteligência Artificial ou em qualquer tecnologia que ainda será inventada, seja sempre a mesma da Frota Estelar: explorar, aprender, compartilhar e deixar o universo um pouco melhor do que você o encontrou. 🖖☕

quinta-feira, 16 de dezembro de 2021

Da USS Enterprise aos Containers: O Guia Definitivo do Programador COBOL Padawan para Entender Docker, DevOps e Cloud Computing

 

Bellacosa Mainframe e o docker sem misterios

☕ Um Café no Bellacosa Mainframe

🐳 Docker sem Mistérios

Da USS Enterprise aos Containers: O Guia Definitivo do Programador COBOL Padawan para Entender Docker, DevOps e Cloud Computing

"A lógica é o começo da sabedoria, não o fim."

— Sr. Spock


Introdução — Bem-vindo à Sala de Teletransporte

Imagine que você acaba de embarcar na USS Enterprise.

Você é um jovem oficial recém-saído da Academia da Frota Estelar.

Seu trabalho é manter os computadores da nave funcionando.

No entanto...

A Enterprise não possui apenas um computador.

Ela possui centenas.

Existem computadores para:

  • Controle de navegação

  • Motores de Dobra

  • Sensores

  • Transporte

  • Comunicações

  • Holodeck

  • Engenharia

  • Laboratórios científicos

Todos precisam funcionar simultaneamente.

Mas imagine se, para executar um simples software de navegação, fosse necessário construir uma Enterprise inteira.

Foi exatamente assim que a computação funcionou durante décadas.

Cada aplicação precisava praticamente de um servidor inteiro.

Era desperdício.

Foi então que surgiu uma ideia revolucionária.

"E se pudéssemos empacotar apenas a aplicação e tudo aquilo que ela realmente precisa?"

Nasciam os containers.

E alguns anos depois...

O mundo conheceria uma pequena baleia azul chamada Docker.

Hoje, Docker é um dos pilares de DevOps, Cloud Computing, CI/CD, Kubernetes e da computação moderna.

Neste Café no Bellacosa Mainframe vamos entender absolutamente tudo, especialmente para quem vem do universo COBOL, JCL, CICS, Db2 e IBM Z.

Prepare seu café.

O computador da Enterprise já iniciou o boot.


Capítulo 1 — Antes do Docker

Durante muitos anos instalar software era um verdadeiro ritual.

Imagine um servidor Linux.

Você precisava instalar:

  • Java

  • Python

  • NodeJS

  • Apache

  • Bibliotecas

  • Drivers

  • Dependências

Depois disso...

Rezava para tudo funcionar.

Se alguém atualizasse uma biblioteca...

Seu programa quebrava.

Era comum ouvir:

"Na minha máquina funciona."

Essa frase virou praticamente uma piada mundial.

O problema não era o código.

Era o ambiente.


Capítulo 2 — O Grande Problema

Imagine três aplicações.

Sistema A

Java 8

Sistema B

Java 17

Sistema C

Java 21

Todos no mesmo servidor.

Cada uma exige versões diferentes.

Resultado?

Conflitos.

Muito parecidos com programas COBOL compilados com runtimes incompatíveis.

No IBM Z isso sempre foi tratado com enorme cuidado.

No mundo distribuído...

Era um caos.


Capítulo 3 — A Solução Chamada Container

Container significa isolamento.

Cada aplicação leva consigo:

  • bibliotecas

  • dependências

  • configuração

  • runtime

Tudo empacotado.

Sem interferir nas demais.

É como colocar cada programa em sua própria cabine da Enterprise.

Todos dividem a nave.

Mas ninguém invade o espaço do outro.


Capítulo 4 — Máquina Virtual x Container

Durante anos usamos máquinas virtuais.

Servidor

↓

Hypervisor

↓

Windows

↓

Aplicação

Docker mudou completamente.

Servidor

↓

Linux

↓

Docker Engine

↓

Containers

Não existe outro sistema operacional inteiro.

Existe apenas:

  • processo

  • isolamento

  • filesystem

Resultado?

Inicialização em segundos.

Pouca memória.

Baixíssimo consumo.


Curiosidade

O kernel Linux enxerga um container apenas como um processo.

Nada mais.

Esse é um dos maiores segredos do Docker.


Capítulo 5 — O Docker Engine

O Docker Engine é o capitão da nave.

Ele administra:

  • containers

  • imagens

  • volumes

  • redes

  • armazenamento

  • execução

Sem ele...

Nada acontece.


Capítulo 6 — Dockerfile

O Dockerfile é uma receita culinária.

Exemplo:

FROM ubuntu

RUN apt update

RUN apt install python3

COPY app.py .

CMD ["python3","app.py"]

Ele diz exatamente como montar a aplicação.

No mundo Mainframe ele lembra bastante:

  • PROC JCL

  • CLIST

  • REXX

  • Script SMP/E

  • Job de instalação


Capítulo 7 — O Processo Completo

Tudo segue uma sequência lógica.

Dockerfile

↓

docker build

↓

Imagem

↓

docker run

↓

Container

Jamais confunda.

Dockerfile não executa.

Imagem não executa.

Quem executa é o container.


Capítulo 8 — O Mistério das Imagens

Imagem é um template.

Ela é imutável.

Pense em:

  • ISO

  • Backup

  • Snapshot

  • Golden Image

Você cria uma única imagem.

Depois gera cem containers.

Todos iguais.

Essa repetibilidade é um dos grandes segredos do DevOps.


Capítulo 9 — docker build

docker build -t web .

Significa:

Construa uma imagem usando o Dockerfile localizado no diretório atual.

"-t"

significa Tag.

Exemplo:

bellacosa/site:v1

Capítulo 10 — docker images

Lista todas as imagens.

docker images

Saída típica:

REPOSITORY

TAG

IMAGE ID

SIZE

Pense nisso como um catálogo de módulos carregáveis.


Capítulo 11 — docker pull

O Docker Hub funciona como uma biblioteca mundial.

docker pull nginx

Baixa uma imagem pronta.

Sem instalar manualmente.

Sem configurar dependências.

Sem sofrimento.


Curiosidade

O Docker Hub possui milhões de imagens.

Mas...

Nem todas são oficiais.

Sempre prefira imagens verificadas.


Capítulo 12 — docker run

Provavelmente o comando mais famoso.

docker run nginx

Ele cria:

Imagem

↓

Container

Nunca altera a imagem.


Principais parâmetros

-d

Modo background.

docker run -d nginx

Muito parecido com iniciar um Started Task no z/OS.


-p

Mapeamento de portas.

-p 8080:80

Host

↓

8080

Container

↓

80


--name

docker run --name web nginx

Muito melhor que decorar IDs enormes.


-e

Variáveis de ambiente.

-e DB_USER=admin

-v

Volumes.

-v dados:/var/lib/mysql

Sem volumes...

Os dados desaparecem ao remover o container.


Capítulo 13 — docker ps

docker ps

Lista apenas containers ativos.

Muito parecido com observar tarefas em execução no ambiente operacional.


docker ps -a

Mostra também:

  • encerrados

  • falhados

  • pausados

É excelente para troubleshooting.


Capítulo 14 — docker logs

Todo administrador aprende isso rapidamente.

Quando algo falha...

Primeiro comando:

docker logs

É equivalente ao programador COBOL abrir imediatamente:

  • JESMSGLG

  • JESJCL

  • SYSOUT

  • CEEDUMP

  • SDSF

Os logs contam a história do que aconteceu.


Capítulo 15 — docker exec

docker exec -it web bash

Agora você entra literalmente dentro do container.

Como abrir um terminal remoto exclusivo daquele ambiente.

Muito útil para:

  • investigar arquivos

  • executar comandos

  • validar configurações


Capítulo 16 — docker stop

Encerra um container.

Primeiro envia um SIGTERM.

Dá tempo para o programa finalizar corretamente.

Caso ignore...

Recebe SIGKILL.

Muito semelhante a uma finalização controlada antes de um cancelamento forçado.


Capítulo 17 — docker rm

Remove containers.

Mas apenas se estiverem parados.

Fluxo típico:

docker stop web

docker rm web

Capítulo 18 — docker rmi

Remove imagens.

docker rmi nginx

Só funciona se ninguém estiver usando aquela imagem.


Capítulo 19 — docker system prune

O famoso botão vermelho.

docker system prune -a

Remove:

  • cache

  • containers

  • imagens

  • redes não utilizadas

  • artefatos temporários

Libera dezenas de gigabytes.

Mas...

Muito cuidado.


Capítulo 20 — Comandos que Todo Profissional Usa

docker inspect

Mostra praticamente tudo.

IPs.

Volumes.

Redes.

JSON completo.


docker stats

Monitoramento em tempo real.

CPU

RAM

Rede

Disco

É semelhante a consultar métricas de desempenho em ferramentas de monitoramento corporativas.


docker top

Lista processos internos.


docker cp

Copia arquivos.

Host

↓

Container

Container

↓

Host


docker restart

Reinicia.


docker start

Liga novamente um container parado.


docker pause

Congela processos.


docker unpause

Retoma execução.


docker network ls

Lista redes.


docker volume ls

Lista volumes persistentes.


docker history

Mostra todas as camadas da imagem.

Excelente para otimização.


Capítulo 21 — Como Docker Funciona Internamente

Pouca gente sabe...

Mas um container não é uma máquina virtual.

Ele utiliza recursos do próprio kernel Linux, como:

  • Namespaces

  • Control Groups (cgroups)

  • OverlayFS

  • Union File Systems

Essas tecnologias isolam processos, redes, usuários e sistemas de arquivos sem a necessidade de um sistema operacional completo por container.

É por isso que containers iniciam em poucos segundos e consomem muito menos memória que VMs tradicionais.


Capítulo 22 — Docker e DevOps

Docker revolucionou o DevOps porque eliminou um dos maiores problemas da engenharia de software: ambientes inconsistentes.

Hoje é possível:

  • Desenvolver localmente.

  • Testar em homologação.

  • Implantar em produção.

Tudo usando exatamente a mesma imagem.

Isso torna pipelines de CI/CD previsíveis e reproduzíveis.


Capítulo 23 — Docker no Mundo Mainframe

Você pode pensar:

"Mas eu trabalho com COBOL no IBM Z. O que Docker tem a ver comigo?"

A resposta é: muito.

Mesmo que aplicações COBOL rodem diretamente no z/OS, Docker é amplamente utilizado para hospedar ferramentas que fazem parte do ecossistema de desenvolvimento moderno:

  • Jenkins para automação de builds e deploys.

  • SonarQube para análise estática de código.

  • GitLab e Gitea para repositórios Git.

  • Nexus e Artifactory para gerenciamento de artefatos.

  • Bancos PostgreSQL, MariaDB e MongoDB para aplicações satélite.

  • Ambientes de testes para APIs REST que consomem serviços do z/OS Connect EE.

  • Ferramentas como Zowe CLI, Ansible e utilitários DevOps.

Assim, Docker não substitui o mainframe: ele o complementa, oferecendo um ecossistema ágil ao redor do IBM Z.


Boas Práticas

  • Use imagens oficiais sempre que possível.

  • Evite executar containers como usuário root.

  • Versione seus Dockerfiles junto com o código-fonte.

  • Utilize tags específicas (nginx:1.28) em vez de latest para garantir previsibilidade.

  • Mantenha imagens pequenas, removendo dependências temporárias.

  • Faça limpeza periódica de recursos não utilizados com cautela.


Curiosidades

  • O mascote do Docker chama-se Moby Dock, uma baleia carregando contêineres.

  • Docker foi lançado em 2013 pela empresa dotCloud.

  • O formato de imagens e containers inspirou o padrão aberto OCI (Open Container Initiative).

  • Embora muita gente diga que "Kubernetes usa Docker", atualmente o Kubernetes conversa com runtimes compatíveis com OCI, como containerd e CRI-O, mantendo compatibilidade com imagens Docker.

  • Muitas distribuições Linux modernas já trazem ferramentas de containers integradas, mostrando como esse modelo se tornou um padrão da indústria.


Easter Egg Bellacosa Mainframe

No universo de Star Trek, o computador da USS Enterprise isola centenas de subsistemas críticos — navegação, comunicações, sensores, suporte de vida e controle dos motores de dobra — para que uma falha em um deles não comprometa toda a nave.

Os containers seguem exatamente essa filosofia: cada aplicação roda em um ambiente isolado, compartilhando apenas os recursos essenciais do sistema operacional. Se um serviço apresentar problemas, os demais continuam operando normalmente.

Essa ideia também ecoa no IBM Z. Assim como LPARs, z/VM e mecanismos de isolamento permitem executar múltiplas cargas de trabalho com segurança e eficiência, os containers oferecem isolamento leve e portabilidade para aplicações modernas.

Missão do Padawan COBOL: quando você entender que Docker não é apenas um conjunto de comandos, mas uma forma diferente de pensar a infraestrutura, terá dado um importante salto rumo ao universo de DevOps. Afinal, tecnologias mudam, ferramentas evoluem, mas os princípios de isolamento, automação, repetibilidade e confiabilidade permanecem — exatamente como ensinaria o Sr. Spock na ponte da Enterprise. 🚀

quarta-feira, 25 de agosto de 2021

Engenharia de Software sem Mistérios — Parte II

 

 

Bellacosa Mainframe e a engenharia de software sem misterios parte ii


☕ Um Café no Bellacosa Mainframe

Engenharia de Software sem Mistérios — Parte II

Da USS Enterprise ao IBM Z

Como Arquitetos Pensam, Como Projetos Evoluem e Como um Programador COBOL Padawan Enxerga Muito Além do Código

"A lógica constrói programas. A arquitetura constrói civilizações."

— Dr. Spock


Capítulo 1 — Diário de Bordo da USS Enterprise

No artigo anterior o Capitão Kirk apresentou a missão.

Conhecemos:

  • Engenharia de Software

  • SDLC

  • Engenharia de Requisitos

  • HLD

  • LLD

Agora o Dr. Spock chama você para a sala de planejamento.

Ele coloca sobre a mesa dois projetos.

Projeto A

"Precisamos alterar um campo no cadastro."

Projeto B

"Precisamos construir o sistema bancário inteiro de um novo país."

Os dois usam COBOL.

Os dois usam Db2.

Os dois usam CICS.

Mas absolutamente todo o processo de engenharia será diferente.

É exatamente isso que veremos nesta segunda parte.


Capítulo 2

O Modelo Incremental

(aprofundamento enorme)

História

Origem

Por que surgiu

Como funciona

Incrementos

Releases

Versões

Roadmap

Entregas contínuas

Benefícios

Desvantagens

Comparação:

Waterfall

Agile

Scrum

Mainframe


Exemplo Bellacosa

Imagine um Internet Banking.

Incremento 1

Login

Incremento 2

Extrato

Incremento 3

PIX

Incremento 4

Investimentos

Incremento 5

Open Finance

O cliente recebe valor desde a primeira entrega.


Aplicação IBM Z

Como isso aparece num banco?

Release 1

COBOL

Release 2

CICS

Release 3

Db2

Release 4

MQ

Release 5

APIs REST


Easter Egg

Scotty nunca construiu a Enterprise inteira de uma vez.

Ela evoluiu por blocos.

Isso é desenvolvimento incremental.


Capítulo 3

Modelo Espiral

Agora entra Barry Boehm.

Quem foi?

Por que revolucionou engenharia?

Como nasceu o Spiral.


Explicar

Planejamento

↓

Análise de riscos

↓

POC

↓

Protótipo

↓

Avaliação

↓

Nova volta

↓

Produto


Aplicação IBM

Migrar um banco inteiro para IBM Z16.

Não se faz em Waterfall.

É Spiral.

Cada volta reduz riscos.


Comparação com Star Trek

A Federação nunca parte para um planeta desconhecido sem sondas.

Primeiro sonda.

Depois aproximação.

Depois reconhecimento.

Depois pouso.

Depois missão.

Isso é exatamente o Spiral Model.


Capítulo 4

Levantamento de Requisitos Avançado

Além da entrevista.

Explicar

Workshop

JAD

Story Mapping

DDD

Shadowing

Event Storming

Brainstorming

Questionários

Prototipação


Exemplo COBOL

O usuário diz:

"Quero um relatório."

Analista pergunta:

Qual?

Quando?

Em PDF?

CSV?

Ordenado?

Agrupado?

Subtotal?

Auditoria?

Histórico?

Aqui nasce um bom software.


Capítulo 5

O Documento SRS Profissional

Muito além da imagem.

IEEE 830

ISO 29148

Versionamento

Glossário

Escopo

Casos de Uso

Diagramas

Rastreabilidade

Mudanças

Requisitos


Exemplo

Sistema

Cadastro

Regra 001

CPF obrigatório

↓

Caso de teste

↓

Programa COBOL

↓

Tela CICS

↓

Tabela Db2

↓

Teste

↓

Produção

Tudo rastreável.


Capítulo 6

Arquiteturas Modernas

Expandir muito.

Layer

MVC

SOA

Microservices

EDA

Hexagonal

Clean

DDD

Monólitos

Serverless


Como isso aparece no IBM Z?

Layer

3270

↓

CICS

↓

COBOL

↓

Db2


Microservices

z/OS Connect

↓

REST

↓

MQ

↓

COBOL


SOA

CICS

IMS

MQ


Capítulo 7

Qualidade de Software

Expandir muito.

Disponibilidade

Confiabilidade

Escalabilidade

Portabilidade

Eficiência

Segurança

Usabilidade

Observabilidade

Auditabilidade


Comparação

Um caixa eletrônico não pode cair.

Disponibilidade.

Um PIX não pode duplicar.

Confiabilidade.

Uma folha de pagamento precisa rodar para 15 milhões de pessoas.

Escalabilidade.


Capítulo 8

HLD e LLD na Vida Real

Mostrar um projeto real.

HLD

Arquiteto.

↓

LLD

Programador.

↓

Código COBOL.

↓

Compile.

↓

DBRM.

↓

BIND.

↓

JCL.

↓

Execução.


Mostrar exemplo completo.


Capítulo 9

Como nasce um sistema bancário

Passo a passo.

Cliente

↓

Negócio

↓

SRS

↓

Arquitetura

↓

HLD

↓

LLD

↓

COBOL

↓

Compile

↓

Link

↓

Db2

↓

CICS

↓

JCL

↓

Teste

↓

Produção

↓

SMF

↓

RMF

↓

Monitoramento

Esse fluxo conecta todos os conceitos das imagens ao ciclo real de desenvolvimento em um ambiente IBM Z.


Capítulo 10

As Grandes Lições do Dr. Spock

Frases inspiradas na lógica vulcana:

"Um requisito mal compreendido custa centavos para escrever, milhares para corrigir e milhões quando chega à produção."

"Arquitetos constroem possibilidades; programadores constroem realidade."

"O melhor código é aquele cuja arquitetura foi pensada antes da primeira linha."

"A pressa escreve código. A engenharia escreve sistemas."


Curiosidades

  • Como a IBM utilizava documentação de engenharia antes mesmo da popularização da UML.

  • Por que muitos sistemas COBOL de 40 anos ainda funcionam melhor que aplicações modernas.

  • A origem da IEEE 830 e sua influência na documentação de requisitos.

  • O papel da NASA e da indústria aeroespacial na evolução dos modelos Incremental e Espiral.

  • Como CMM, ISO 9001 e Capability Maturity Model mudaram a forma de desenvolver software corporativo.


Dicas do Bellacosa Mainframe

  • Nunca programe antes de entender o negócio.

  • Um bom HLD evita dezenas de retrabalhos.

  • Um LLD bem escrito economiza horas de depuração.

  • Documentação não é burocracia: é memória técnica do projeto.

  • Em Mainframe, uma regra de negócio pode sobreviver décadas; escreva pensando em quem fará manutenção daqui a vinte anos.

  • Conhecer modelos de desenvolvimento torna você um profissional mais completo, mesmo que sua principal linguagem continue sendo COBOL.


 


☕ Um Café no Bellacosa Mainframe

Da Ideia ao Código: Engenharia de Software sem Mistérios

Conheça a jornada completa de um sistema, desde os requisitos, arquitetura e design até a codificação, testes, implantação e manutenção, com exemplos aplicados ao universo COBOL e IBM Z.

quarta-feira, 21 de julho de 2021

Da Ideia ao Código: A Engenharia de Software Sem Mistérios - Parte I

 

Bellacosa Mainframe e a engenharia de software sem misterios parte I

☕ Um Café no Bellacosa Mainframe

Da Ideia ao Código: A Engenharia de Software Sem Mistérios

O Guia Definitivo do Programador COBOL Padawan para Entender Como Nascem os Sistemas que Movem o Mundo — Inspirado no Universo de Star Trek

"A lógica é o começo da sabedoria, não o fim."

— Sr. Spock


Introdução — A Ponte de Comando da USS Enterprise e o IBM Z

Existe uma cena recorrente em praticamente toda série de Star Trek.

O Capitão Kirk recebe uma missão.

Antes de simplesmente sair acelerando rumo ao desconhecido, uma sequência acontece quase sempre da mesma forma:

  • Uhura recebe as comunicações;

  • Sulu calcula a rota;

  • Chekov verifica a navegação;

  • Scotty analisa os motores;

  • Dr. McCoy avalia a tripulação;

  • Spock analisa os riscos.

Somente depois disso...

Warp Factor!

Curiosamente...

É exatamente assim que funciona um projeto de software.

O programador iniciante costuma imaginar que um sistema nasce quando alguém abre o Visual Studio Code, o IDz ou o ISPF e começa a escrever COBOL.

Na realidade...

O código representa apenas a ponta do iceberg.

Antes de existir uma única linha de código, dezenas de profissionais trabalharam durante semanas — ou meses — planejando tudo.

Foi justamente essa percepção que criou uma nova ciência chamada:

Engenharia de Software

E é exatamente essa jornada que faremos hoje.

Pegue sua caneca de café.

Ajuste o brilho do terminal 3270.

Ative os sensores de longo alcance.

Nossa missão começa agora.


Diário de Bordo — Stardate 2026

Imagine que a Federação precisa desenvolver um novo sistema para controlar toda a logística das naves da Frota Estelar.

Esse sistema deverá controlar:

  • combustível (Dilithium)

  • tripulação

  • armamentos

  • manutenção

  • suprimentos

  • teletransporte

  • missões

Parece simples.

Mas...

Como garantir que um erro nunca destrua uma nave inteira?

É exatamente para isso que existe a Engenharia de Software.


Capítulo 1 — A Grande Crise do Software

Nos anos 50 e início dos anos 60, programar era relativamente simples.

Os programas eram pequenos.

Poucas pessoas trabalhavam neles.

Mas os computadores ficaram cada vez maiores.

Surgiram:

  • bancos

  • companhias aéreas

  • governos

  • seguradoras

  • sistemas militares

De repente surgiram programas com:

  • milhões de linhas

  • milhares de tabelas

  • centenas de desenvolvedores

Resultado?

Uma verdadeira catástrofe.

Projetos atrasavam anos.

Custavam dezenas de vezes mais.

Nunca terminavam.

Essa situação ficou conhecida como:

Software Crisis

Foi ela que deu origem à Engenharia de Software.


O verdadeiro significado de Software

As apostilas mostram:

Software = Programas + Dados + Documentação

Na prática moderna...

Software significa muito mais.

Um sistema corporativo normalmente inclui:

  • código COBOL

  • programas Java

  • APIs REST

  • filas MQ

  • banco Db2

  • VSAM

  • IMS

  • documentação

  • monitoramento

  • pipelines CI/CD

  • segurança

  • backups

  • auditoria

  • logs

  • scripts

  • automação

Ou seja...

O código é apenas uma pequena parte.


Easter Egg nº 1 ☕

No universo Star Trek, o computador da Enterprise nunca mostra apenas "o programa".

Ele conhece:

  • estado da nave

  • sensores

  • mapas

  • comunicações

  • banco de dados

  • diagnósticos

Isso é exatamente o conceito moderno de software.


Engenharia de Requisitos

Antes de escrever código existe uma pergunta extremamente difícil.

"O que exatamente devemos construir?"

Curiosamente...

Essa costuma ser a pergunta mais complicada de todo projeto.

Imagine um banco dizendo:

"Queremos um sistema PIX."

Pronto?

Claro que não.

Agora começam centenas de perguntas.

Quem pode transferir?

Existe limite?

Qual horário?

Pessoa física?

Pessoa jurídica?

Existe auditoria?

Existe rollback?

Existe LGPD?

Existe dupla autenticação?

Existe assinatura digital?

Existe timeout?

Existe integração com BACEN?

Perceba.

Nenhuma dessas perguntas envolve COBOL.


O Analista é um Investigador Vulcano

Spock nunca tira conclusões precipitadas.

Ele primeiro coleta evidências.

Depois formula hipóteses.

Depois valida.

Um bom analista faz exatamente isso.

Ele investiga.

Questiona.

Confirma.

Documenta.


Engenharia de Requisitos é Engenharia de Perguntas

Quanto melhor forem as perguntas...

Melhor será o software.

Existe um velho ditado da IBM:

Um requisito mal entendido custa centenas de horas de retrabalho.


Requisitos Funcionais

São aqueles que respondem:

"O sistema faz o quê?"

Exemplos:

Consultar saldo

Transferir PIX

Emitir boleto

Gerar extrato

Cadastrar cliente

Calcular juros

Tudo isso é comportamento.


Requisitos Não Funcionais

Agora entra uma categoria que muitos iniciantes ignoram.

Ela responde:

"Como o sistema deve funcionar?"

Por exemplo.

Consultar saldo.

↓

Em menos de 300 milissegundos.

Transferir dinheiro.

↓

Disponibilidade de 99,999%.

Cadastrar cliente.

↓

Suportar 50 mil usuários simultâneos.

Esses requisitos normalmente definem se o projeto será aprovado ou não.


O Segredo do Mainframe

Por que um IBM Z consegue processar bilhões de transações?

Porque praticamente todos os seus requisitos importantes são...

Não funcionais.

Disponibilidade.

Escalabilidade.

Confiabilidade.

Segurança.

Performance.


Curiosidade ☕

A famosa meta de 99,999% de disponibilidade ("cinco noves") significa apenas alguns minutos de indisponibilidade por ano. Esse nível é perseguido por plataformas de missão crítica como o IBM Z porque uma interrupção pode afetar milhões de clientes e transações.


Como levantar requisitos

Existem diversas técnicas.

As mais usadas são:

Entrevistas

Observação

Questionários

Brainstorming

Protótipos

Workshops


O poder da observação

Imagine automatizar um caixa bancário.

Você pergunta:

"Como você trabalha?"

Ele responde.

Mas...

Quando você o observa...

Descobre atalhos.

Planilhas escondidas.

Papéis.

Post-its.

Macetes.

Fluxos nunca documentados.

Isso acontece diariamente nas empresas.


O Documento Mais Importante do Projeto

Depois de semanas de entrevistas nasce um documento.

O famoso:

SRS

Software Requirement Specification

Ele é praticamente a Constituição do projeto.

Tudo nasce dele.

Tudo termina nele.


O que existe em um SRS?

Escopo.

Objetivos.

Glossário.

Casos de uso.

Regras de negócio.

Integrações.

Restrições.

Mensagens.

Fluxos.

Requisitos funcionais.

Requisitos não funcionais.

Critérios de aceitação.

No mundo IBM Z, muitas organizações utilizam documentos equivalentes, às vezes com outros nomes, mas a função é a mesma: registrar claramente o que será construído.


A Validação

Agora acontece algo extremamente importante.

Antes de programar...

Pergunta-se:

"Está correto?"

É muito mais barato descobrir um erro aqui do que meses depois.


A Regra dos Custos

Existe um princípio amplamente aceito na Engenharia de Software:

Quanto mais tarde um defeito é encontrado, maior tende a ser o custo para corrigi-lo.

Encontrar uma falha durante a análise geralmente é muito mais barato do que descobri-la após a implantação em produção.


Arquitetura

Agora começa outra etapa.

Imagine construir a USS Enterprise.

Você começaria instalando os motores?

Claro que não.

Primeiro existe um projeto.

Com software acontece igual.


Arquitetura responde perguntas gigantes

Será:

Monolito?

Microserviços?

Mainframe?

Cloud?

MQ?

REST?

Kafka?

Db2?

VSAM?

IMS?

CICS?

Nada disso envolve código ainda.


Um exemplo IBM Z

Imagine uma compra pela Internet.

O fluxo pode ser:

Cliente

↓

API

↓

z/OS Connect

↓

CICS

↓

Programa COBOL

↓

Db2

↓

MQ

↓

Sistema de Estoque

Isso é arquitetura.


Arquitetura em Camadas

As apostilas mostram:

Presentation

Business

Data

Database

Curiosamente...

Muitos sistemas COBOL já utilizavam esse conceito décadas antes da popularização dos frameworks modernos.

Tela BMS.

↓

Programa COBOL.

↓

Db2.

É uma separação de responsabilidades.


Microserviços

Hoje muito se fala em Microservices.

A ideia é dividir um sistema enorme em pequenos serviços independentes.

Exemplo:

PIX

Cartões

Empréstimos

Investimentos

Clientes

Cada um evolui de forma independente.

Mas isso não significa que seja sempre a melhor escolha. Em muitos cenários, um monólito bem projetado é mais simples de desenvolver e manter.


HLD — High Level Design

Agora a arquitetura vira documento.

O HLD mostra:

Grandes módulos.

Integrações.

Banco.

Protocolos.

Fluxo de dados.

Não entra nos detalhes.

É o mapa da cidade.


LLD — Low Level Design

Agora sim.

Entramos no nível do desenvolvedor.

O LLD explica:

Algoritmos.

Tabelas.

Campos.

Índices.

Funções.

Pseudocódigo.

Fluxogramas.

Entradas.

Saídas.

Mensagens.

Agora o programador consegue escrever código.


Exemplo COBOL

Imagine um programa chamado:

COBPIX01

O LLD pode dizer:

Entrada:

  • Agência

  • Conta

  • Valor

Processamento:

  • validar conta

  • consultar saldo

  • verificar limite

  • debitar

  • registrar auditoria

  • gravar MQ

  • atualizar Db2

  • executar COMMIT

Saída:

  • código de retorno

  • novo saldo

  • mensagem ao usuário

Perceba.

O código praticamente nasce desse documento.


O Pseudocódigo

Uma das ferramentas mais antigas da Engenharia.

Ele permite pensar antes de programar.

Receber conta

↓

Conta existe?

↓

Não

Erro

↓

Sim

Saldo suficiente?

↓

Não

Saldo insuficiente

↓

Sim

Debitar

↓

Registrar log

↓

Atualizar Db2

↓

Commit

↓

Retornar sucesso

Quando esse fluxo está correto...

Programar fica muito mais simples.


SDLC na prática

Todo projeto percorre algo semelhante a:

Ideia

↓

Requisitos

↓

Validação

↓

Arquitetura

↓

HLD

↓

LLD

↓

Codificação

↓

Testes

↓

Implantação

↓

Manutenção

↓

Nova evolução

Perceba que a programação aparece apenas na metade da jornada.


Modelos de Desenvolvimento

A Engenharia criou diversos modelos para organizar esse fluxo.

Waterfall

Segue uma sequência rígida.

Requisitos.

↓

Projeto.

↓

Código.

↓

Testes.

↓

Produção.

Ainda é muito usado em projetos com requisitos estáveis, como diversos sistemas governamentais e aplicações de missão crítica.


Modelo V

Cada etapa de desenvolvimento possui uma etapa correspondente de teste.

Requisitos

⇔ Testes de Aceitação

Projeto

⇔ Testes de Sistema

Arquitetura

⇔ Testes de Integração

Módulos

⇔ Testes Unitários

É excelente para ambientes onde rastreabilidade e qualidade são fundamentais.


Modelo Incremental

Em vez de entregar tudo de uma vez, o sistema cresce por partes.

Primeiro:

Login.

Depois:

Cadastro.

Depois:

Relatórios.

Depois:

Integrações.

Cada incremento entrega valor ao usuário.


Modelo Espiral

Muito usado em projetos grandes e de alto risco.

Cada volta da espiral passa por:

Planejamento.

↓

Análise de riscos.

↓

Desenvolvimento.

↓

Avaliação do cliente.

↓

Nova volta.

É um modelo que combina evolução contínua com gestão de riscos.


Os Atributos da Qualidade

Um software não é considerado bom apenas porque "funciona".

Ele precisa ser:

✔ Correto

✔ Confiável

✔ Eficiente

✔ Seguro

✔ Escalável

✔ Portável

✔ Fácil de manter

✔ Disponível

✔ Fácil de usar

Esses atributos influenciam diretamente o sucesso de um sistema em produção.


A Engenharia Invisível

Quando um cliente faz um PIX em dois segundos...

Ele nunca imagina que por trás daquela simplicidade existiram:

Meses de análise.

Centenas de reuniões.

Documentos.

Diagramas.

Arquitetura.

Revisões.

Testes.

Validações.

Planejamento.

Essa é a parte invisível da Engenharia de Software.


Easter Egg nº 2 — A Diretriz Principal

Em Star Trek existe a famosa Prime Directive, um conjunto de regras criado para evitar consequências desastrosas.

Na Engenharia de Software existe um princípio parecido:

Nunca comece a codificar antes de compreender completamente o problema que precisa ser resolvido.

Escrever código sem requisitos claros costuma produzir sistemas que funcionam tecnicamente, mas não atendem ao negócio.


Lições do Sr. Spock para o Programador COBOL Padawan

Se Spock fosse um arquiteto de software no IBM Z, provavelmente deixaria estas recomendações:

  • A lógica deve vir antes do código.

  • Requisitos mal definidos geram defeitos bem implementados.

  • Um bom design reduz a complexidade futura.

  • Documentação não substitui conhecimento, mas preserva conhecimento.

  • Teste não cria qualidade; ele revela a qualidade do que foi construído.

  • O programa termina de ser escrito, mas o software continua evoluindo durante anos.


Conclusão — A Verdadeira Missão da Engenharia de Software

Muitos iniciantes acreditam que o objetivo de um desenvolvedor é escrever muitas linhas de código.

Com o tempo, descobrem que acontece justamente o contrário.

Os melhores engenheiros escrevem o código certo, no momento certo, apoiado por requisitos claros, uma arquitetura consistente e um projeto bem elaborado.

É exatamente por isso que sistemas COBOL executados em IBM Z continuam sustentando bancos, seguradoras, governos e bolsas de valores após décadas de evolução. Eles não sobreviveram apenas por causa da linguagem ou do hardware, mas porque foram construídos sobre fundamentos sólidos de Engenharia de Software: análise cuidadosa, documentação, arquitetura, testes e manutenção disciplinada.

Assim como a USS Enterprise não parte para uma missão sem planejamento, análise de riscos e coordenação entre toda a tripulação, um grande sistema corporativo também não nasce de improviso. Cada documento, cada diagrama, cada revisão e cada teste representa um membro da "tripulação" trabalhando para que, quando chegar o momento da implantação, tudo funcione de forma segura, previsível e confiável.

No fim da jornada, o verdadeiro Padawan COBOL percebe que programar é uma habilidade importante, mas compreender a Engenharia de Software é o que transforma um programador em um engenheiro capaz de construir sistemas que resistem ao tempo — exatamente como os grandes sistemas do IBM Z e as lendárias naves da Frota Estelar. Vida longa e próspera! 🖖


☕ Um Café no Bellacosa Mainframe

Engenharia de Software sem Mistérios — Parte 2

Da USS Enterprise ao IBM Z

Descubra como arquitetos pensam, como projetos evoluem e como um programador COBOL pode enxergar além do código, compreendendo SRS, HLD, LLD, modelos Incremental e Espiral, arquitetura, qualidade e desenvolvimento de sistemas no IBM Z.

quinta-feira, 20 de fevereiro de 2020

A Psicologia por Trás do Programador COBOL

 

Bellacosa Mainframe e a psicologia por trás do programador Cobol

☕ Um Café no Bellacosa Mainframe

A Psicologia por Trás do Programador COBOL

Como as Grandes Teorias do Comportamento Explicam a Vida no IBM Z — Um Guia para o Programador COBOL Padawan Inspirado em Star Trek e no Dr. Spock

"A lógica é o começo da sabedoria, não o fim." — Dr. Spock

Existe uma curiosidade fascinante sobre o desenvolvimento de software.

Quando um programa COBOL apresenta um ABEND S0C7 pela terceira vez consecutiva, duas pessoas podem reagir de maneiras completamente diferentes.

Um iniciante pensa:

"Eu nunca vou aprender isso."

Um veterano pensa:

"Interessante... existe um padrão escondido."

O erro é exatamente o mesmo.

A diferença está no cérebro.

Mais especificamente, na forma como aprendemos, criamos hábitos, tomamos decisões, reagimos ao estresse e interpretamos o sucesso e o fracasso.

Curiosamente, quase tudo isso já havia sido estudado muito antes da existência do COBOL.

Muito antes do IBM System/360.

Muito antes da linguagem C.

Muito antes do Agile.

A psicologia comportamental, cognitiva e social explica boa parte do que acontece diariamente dentro de um projeto mainframe.

Hoje vamos visitar a ponte da USS Enterprise.

Nosso guia será o oficial de ciências mais famoso da ficção.

Dr. Spock.

Porque poucos personagens representam tão bem o equilíbrio entre lógica, emoção, aprendizado e disciplina quanto um vulcano.

Prepare seu tricorder.

Vamos explorar a mente do programador.


Capítulo 1 — O cérebro do programador COBOL

Quando um padawan chega ao IBM Z ele acredita que seu maior desafio será aprender:

  • COBOL

  • JCL

  • CICS

  • Db2

  • VSAM

  • IMS

  • RACF

Na verdade não.

Seu maior desafio será aprender...

...como funciona seu próprio cérebro.

Porque programar é uma atividade profundamente psicológica.

Todos os dias você precisa:

  • resolver problemas

  • aprender coisas novas

  • lembrar detalhes

  • controlar ansiedade

  • trabalhar em equipe

  • lidar com críticas

  • aceitar erros

  • persistir

Tudo isso é comportamento humano.


Capítulo 2 — Ivan Pavlov e os condicionamentos

Todo mundo conhece o cachorro de Pavlov.

O experimento era simples.

Campainha.

Comida.

Salivação.

Depois de repetir diversas vezes...

Somente a campainha já fazia o cachorro salivar.

Chamamos isso de:

Condicionamento clássico.


E no mainframe?

Você também foi condicionado.

Exemplos:

Abrir SDSF →

Ansiedade.

Receber e-mail do gerente →

Tensão.

Ver "ABEND" →

Frio na barriga.

Ou...

Ver JOB RC=0000 →

Satisfação.

Seu cérebro aprende associações constantemente.


Dica Bellacosa

Não associe erro à vergonha.

Associe erro ao aprendizado.

Veteranos fazem exatamente isso.


Capítulo 3 — Skinner e o condicionamento operante

B. F. Skinner mostrou que comportamentos recompensados tendem a aumentar.

Exemplo:

Você resolve um problema difícil.

Recebe elogios.

Seu cérebro libera dopamina.

Na próxima vez...

Você terá maior motivação.


No desenvolvimento COBOL

Quando um mentor diz:

"Excelente análise."

Você ganha confiança.

Quando ele apenas critica...

Seu aprendizado diminui.

Por isso grandes líderes ensinam.

Não apenas corrigem.


Easter Egg Star Trek

Capitão Kirk motiva.

Spock orienta.

McCoy apoia emocionalmente.

Uma boa equipe técnica possui exatamente esses três perfis.


Capítulo 4 — Albert Bandura e a aprendizagem observacional

Bandura revolucionou a psicologia.

Ele mostrou que aprendemos observando.

Nem sempre precisamos experimentar.

Podemos aprender vendo alguém fazer.


O veterano na tela 3270

Você observa um analista experiente.

Ele:

  • navega rapidamente

  • usa atalhos

  • identifica erros em segundos

  • conhece comandos escondidos

Você aprende apenas olhando.

Por isso pair programming funciona.

Shadowing funciona.

Mentoria funciona.


Curiosidade

Grande parte do conhecimento do mainframe nunca foi documentada.

Foi transmitida oralmente.

Como os mestres Jedi.


Capítulo 5 — Jean Piaget

Piaget estudou como construímos conhecimento.

Aprender não significa decorar.

Aprender significa reorganizar modelos mentais.


Exemplo

No início:

"JCL executa programa."

Depois:

"JCL conversa com JES."

Mais tarde:

"JES conversa com WLM."

Depois:

"SMS influencia datasets."

Depois:

"Tudo faz parte do sistema operacional."

Seu cérebro cria mapas mentais cada vez maiores.


Capítulo 6 — Lev Vygotsky

Talvez a teoria mais importante para um padawan.

Vygotsky criou a famosa:

Zona de Desenvolvimento Proximal.

Ou simplesmente:

ZDP.

Ela representa aquilo que você ainda não consegue fazer sozinho...

...mas consegue fazer com ajuda.


Exemplo

Você não sabe montar um BIND PACKAGE.

Com um mentor...

Consegue.

Depois de algumas semanas...

Faz sozinho.

É assim que ocorre o crescimento profissional.


Dica

Nunca estude completamente sozinho.

Mentores aceleram décadas de aprendizado.


Capítulo 7 — Carol Dweck e o Growth Mindset

Carol Dweck descobriu duas formas principais de pensar.

Mentalidade fixa

"Sou ruim em COBOL."

Fim.


Mentalidade de crescimento

"Ainda não domino COBOL."

Existe enorme diferença.

A palavra "ainda" muda tudo.


No IBM Z

Veteranos erram diariamente.

A diferença?

Eles sabem que aprenderão com o erro.


Spock diria

"A ausência de conhecimento atual não implica incapacidade futura."


Capítulo 8 — Daniel Kahneman

Prêmio Nobel.

Criador da teoria dos dois sistemas.

Sistema 1:

Rápido.

Automático.

Instintivo.

Sistema 2:

Lento.

Analítico.

Lógico.


Durante um ABEND

Sistema 1:

"Foi o Db2."

Sistema 2:

"Vamos verificar SQLCODE."

Ou:

"Vamos analisar SYSUDUMP."

Ou:

"Verifique o offset."

Grandes analistas usam o Sistema 2.


Capítulo 9 — Heurísticas

Nosso cérebro cria atalhos.

Eles economizam energia.

Mas produzem erros.


Viés da confirmação

"Tenho certeza que o erro está no COBOL."

Horas depois...

Era o JCL.


Ancoragem

"O último problema era VSAM."

Logo:

Todo problema agora parece VSAM.


Disponibilidade

Você lembra do último ABEND.

Então acredita que ele é o mais comum.

Mesmo não sendo.


Capítulo 10 — Maslow

A famosa pirâmide.

No mundo corporativo ela aparece diariamente.

Primeiro:

Segurança.

Depois:

Pertencimento.

Depois:

Reconhecimento.

Depois:

Autorrealização.


Um padawan inseguro

Tem medo de perguntar.

Tem medo de errar.

Tem medo de produzir.

Sem segurança psicológica...

Não existe inovação.


Capítulo 11 — Herzberg

Herzberg descobriu algo curioso.

Salário evita insatisfação.

Mas não gera paixão.

O que realmente motiva?

  • autonomia

  • crescimento

  • reconhecimento

  • propósito


Mainframe

Quem entende que processa milhões de salários, hospitais e bancos...

Encontra propósito.


Capítulo 12 — Csikszentmihalyi e o Flow

Flow.

O estado de concentração absoluta.

Você esquece o relógio.

Horas passam.

Você nem percebe.


Quando acontece?

Desafio equilibrado.

Nem fácil.

Nem impossível.

É exatamente onde um bom líder posiciona seus padawans.


Capítulo 13 — Charles Duhigg e os hábitos

Todo hábito possui:

  • gatilho

  • rotina

  • recompensa


Exemplo

Chegar ao trabalho.

↓

Abrir SDSF.

↓

Verificar jobs.

↓

Sensação de controle.

Em poucos meses...

Isso vira automático.


Dica

Crie hábitos saudáveis:

  • revisar código

  • comentar programas

  • ler manuais

  • testar antes do deploy


Capítulo 14 — Inteligência Emocional (Daniel Goleman)

Conhecimento técnico explica parte do sucesso.

Relacionamento explica o restante.

Grandes profissionais:

  • ouvem

  • perguntam

  • ajudam

  • compartilham

Nunca humilham iniciantes.


Curiosidade

Muitas empresas perderam especialistas...

Não por aposentadoria.

Mas porque ninguém quis aprender com pessoas difíceis.

Conhecimento sem empatia morre.


Capítulo 15 — Reforço Positivo na Revisão de Código

Imagine duas revisões.

Revisor A

"Está tudo errado."

Fim.


Revisor B

"Gostei da organização. Agora podemos melhorar estes três pontos."

Mesmo resultado técnico.

Impacto psicológico completamente diferente.


Capítulo 16 — O efeito Dunning-Kruger

Iniciantes frequentemente acreditam que sabem muito.

Depois descobrem quanto ainda falta aprender.

A confiança cai.

Mais tarde...

O conhecimento cresce.

A confiança volta.

Agora baseada em experiência.

Todo especialista já passou por essa curva.


Capítulo 17 — O poder da curiosidade

A curiosidade é um dos maiores motores do aprendizado.

Perguntas como:

  • Por que existe o SQLCA?

  • Por que o JCL usa DDNAME?

  • Por que o COBOL continua evoluindo?

  • Como o JES agenda milhares de jobs?

  • Como o WLM decide prioridades?

Cada resposta amplia seu mapa mental.

Os melhores profissionais raramente se contentam com "funciona". Eles perguntam "por que funciona?".


Easter Egg — A Ponte da USS Enterprise como um Projeto Mainframe

Imagine um grande sistema bancário.

  • Capitão Kirk é o gerente de projeto: toma decisões sob pressão e assume riscos calculados.

  • Dr. Spock é o arquiteto ou analista sênior: baseia-se em evidências, métricas e lógica.

  • Dr. McCoy representa RH, UX e liderança humana: lembra que sistemas existem para atender pessoas.

  • Scotty é o sysprog: mantém a infraestrutura IBM Z funcionando, faz milagres com CPU, memória e I/O.

  • Uhura é o middleware: garante que CICS, MQ, APIs e sistemas conversem.

  • Sulu é o operador: conduz a operação diária com precisão.

  • Chekov é o padawan curioso: aprende rápido, faz perguntas e cresce a cada missão.

Nenhum deles vence sozinho. A Enterprise funciona porque cada especialidade respeita as demais.


As Grandes Lições para um Padawan COBOL

Depois de conhecer essas teorias, fica claro que evoluir no mainframe depende de muito mais do que decorar comandos.

Os maiores aprendizados são:

  • Erros são dados para aprendizado, não motivos para vergonha.

  • Observe especialistas: modelagem é uma das formas mais rápidas de aprender.

  • Desenvolva uma mentalidade de crescimento e aceite o "ainda não".

  • Questione seus próprios vieses antes de concluir a causa de um problema.

  • Crie hábitos consistentes de estudo, testes e documentação.

  • Valorize mentores e também torne-se mentor quando adquirir experiência.

  • Cultive inteligência emocional: conhecimento compartilhado vale mais do que conhecimento guardado.

  • Busque o estado de flow, equilibrando desafio e capacidade.

  • Nunca pare de fazer perguntas.


Conclusão — O Verdadeiro Vulcano do IBM Z

No universo de Star Trek, muitos acreditam que Spock representa apenas a lógica. Mas essa é uma visão incompleta.

Spock estudou suas emoções para não ser dominado por elas. Ele sabia que lógica sem empatia se torna fria, enquanto emoção sem disciplina leva a decisões impulsivas. Sua força estava no equilíbrio.

O mesmo vale para um excelente profissional de mainframe.

Dominar COBOL, JCL, CICS, Db2, IMS, RACF ou z/OS é essencial, mas insuficiente. Os melhores especialistas também entendem como aprendem, como colaboram, como reagem à pressão, como recebem críticas e como transformam erros em experiência.

Em um datacenter, milhões de linhas de código mantêm bancos, hospitais, governos e empresas funcionando. Mas por trás de cada linha existe um ser humano tomando decisões. É aí que a psicologia encontra a engenharia.

Ao longo da carreira, você perceberá que os maiores desafios raramente serão técnicos. Eles envolverão comunicação, disciplina, curiosidade, paciência, liderança e aprendizado contínuo.

Como diria o Dr. Spock:

"Computadores são excelentes ferramentas para seguir instruções. Pessoas são extraordinárias porque conseguem aprender, adaptar-se e evoluir."

Essa talvez seja a tecnologia mais poderosa de todas.


domingo, 18 de junho de 2017

Grutas de Mira D'aire e seus tesouros

Bellacosa Mainframe visitando as Grutas de Mira D´aire

Uma aventura embaixo da terra

Grutas de Mira D'aire e seus tesouros 

As Grutas de Mira de Aire já seriam espetaculares simplesmente por existirem. Caminhar por aqueles enormes salões subterrâneos, cercado por estalactites, estalagmites, rochas moldadas durante eras e pequenos lagos escondidos nas profundezas da terra já seria aventura suficiente.

Mas eles resolveram ir além.

Existe praticamente um espetáculo dentro do espetáculo.

A infraestrutura impressiona: escadarias, passarelas, caminhos preparados, iluminação e até elevador. Em determinados momentos eu me perguntava como conseguiram instalar tudo aquilo no interior de uma montanha sem destruir justamente aquilo que desejavam mostrar.

Então começam as luzes.

E aí a caverna muda.

As sombras desaparecem em alguns lugares e surgem em outros. Formações que estavam escondidas na escuridão aparecem repentinamente. A água reflete as cores, as paredes parecem ganhar outra dimensão e enormes estruturas de pedra emergem diante dos olhos.

Foi quase um teleporte de Star Trek.

Você está caminhando normalmente por uma caverna e, alguns segundos depois, parece que Scotty acionou os controles da Enterprise:

“Energize!”

Puff!



Estamos em outro planeta.

Talvez seja justamente isso que tenha ficado tão marcado na minha memória. Não foi apenas conhecer uma gruta. Foi participar de uma experiência cuidadosamente construída em torno de algo que a própria natureza levou milhões de anos para preparar.

E quando finalmente encontramos o elevador para retornar à superfície, surge aquela sensação curiosa de estar voltando de algum lugar muito distante.

Só que não viajamos anos-luz.

Viajamos para baixo.

E descobrimos que, às vezes, basta atravessar algumas dezenas de metros de rocha para encontrar um universo completamente diferente escondido debaixo dos nossos pés.

-----------------------------------------------------------------------------------

Entre estalactites e estalagmites.




Estamos passeando pelo distrito de Leiria, na região de Mós tem uma belíssima caverna, totalmente adaptado ao turismo, aqui descendo ao seu interior temos um verdadeiro show de luzes pelos lagos, vemos diversos espeleotemas, um grande lago subterrâneo diversas estalactites e vamos ao seu interior.

Serve para pensarmos que uma cidade bem administrada, explora todos os recursos naturais para trazer turistas e impressionar as pessoas.



quinta-feira, 8 de setembro de 2016

Star Trek 50 Anos: A Série que Ensinou a Humanidade a Construir o Futuro

 

Bellacosa Mainframe comemorando os 50 anos da serie Star Trek

☕ Um Café no Bellacosa Mainframe

Star Trek 50 Anos: A Série que Ensinou a Humanidade a Construir o Futuro

Uma homenagem de um Programador COBOL da Velha Guarda aos novos Padawans que ainda irão explorar a fronteira final

"Espaço... a fronteira final..."

Existem séries que fazem sucesso.

Existem séries que criam uma geração.

E existe Star Trek.

Cinquenta anos depois de sua estreia, em 8 de setembro de 1966, ainda é difícil medir o tamanho de seu legado. Não porque ela tenha sido a série de maior audiência. Não foi. Nem porque possuía os melhores efeitos especiais. Também não tinha.

Seu verdadeiro poder era outro.

Ela fazia uma pergunta que continua atual:

"E se a humanidade pudesse ser melhor do que é hoje?"

Essa pergunta mudou milhões de vidas.

Mudou carreiras.

Mudou universidades.

Mudou empresas.

Mudou a NASA.

Mudou a computação.

Mudou engenheiros.

Mudou cientistas.

Mudou programadores.

E talvez, sem você perceber, tenha mudado até a sua vida.

Pegue uma caneca de café.

Sente-se na ponte da USS Enterprise.

Hoje não vamos falar apenas de uma série de televisão.

Vamos falar de um sonho que já dura seis décadas.


O sonho de Gene Roddenberry

Em 1966, o mundo estava longe de ser um lugar tranquilo.

A Guerra Fria dividia o planeta.

Os Estados Unidos viviam intensos conflitos raciais.

A Guerra do Vietnã ocupava diariamente os jornais.

O homem ainda nem havia pisado na Lua.

Os computadores eram gigantescos mainframes alimentados por cartões perfurados.

A Internet sequer existia.

Nesse cenário nasceu uma ideia completamente fora do padrão.

Gene Roddenberry não queria criar apenas uma aventura espacial.

Queria imaginar como seria uma civilização que tivesse aprendido com seus próprios erros.

Enquanto muitos filmes mostravam futuros dominados por guerras nucleares, ditaduras ou invasões alienígenas, Star Trek ousava dizer algo diferente:

"Nós conseguiremos."

Pode parecer uma mensagem simples.

Mas em 1966 ela era quase revolucionária.


O futuro não era perfeito...

Mas era esperançoso

Esse talvez seja o maior ensinamento de Star Trek.

A Federação dos Planetas Unidos não era um paraíso.

Ainda existiam conflitos.

Ainda havia desafios.

Ainda havia inimigos.

Mas existia algo muito importante:

As pessoas haviam aprendido a cooperar.

Não importava:

  • cor da pele;

  • nacionalidade;

  • religião;

  • idioma;

  • planeta de origem.

Todos trabalhavam pelo mesmo objetivo.

Hoje chamamos isso de diversidade.

Na Enterprise chamava-se apenas...

Tripulação.


A maior nave da série nunca foi a Enterprise

Pode parecer estranho.

Mas a verdadeira protagonista nunca foi a NCC-1701.

Foi a própria humanidade.

Cada episódio era uma pergunta filosófica.

O que significa liberdade?

O que torna alguém humano?

Máquinas podem pensar?

A lógica é suficiente?

Vale tudo para vencer uma guerra?

Até onde devemos interferir em outra cultura?

Quem define o certo?

Quem define o errado?

São perguntas que continuam sendo discutidas hoje na Inteligência Artificial.

Cinquenta anos depois.


Para um Padawan COBOL

Talvez você esteja pensando:

"O que isso tem a ver comigo?"

Muito mais do que parece.

Imagine que a Enterprise seja um enorme ambiente IBM Z.

Scotty administra a infraestrutura.

Spock analisa dados.

Uhura integra sistemas.

McCoy protege as pessoas.

Kirk toma decisões.

Nenhum deles trabalha sozinho.

É exatamente assim que funciona um grande ambiente corporativo.

Um sistema bancário.

Uma companhia aérea.

Uma seguradora.

Um hospital.

Mainframes nunca funcionaram porque existia um único gênio.

Funcionaram porque centenas de especialistas trabalharam como uma tripulação.

Star Trek entendia isso décadas antes da computação moderna falar em colaboração multidisciplinar.


A tecnologia sempre foi consequência

Uma curiosidade interessante.

Quase ninguém assiste Star Trek por causa do phaser.

Ou do teletransporte.

Ou da dobra espacial.

O que prende o espectador são as pessoas.

As conversas.

Os dilemas.

Os valores.

A tecnologia nunca era o objetivo.

Era apenas uma ferramenta.

Curiosamente...

É exatamente o que acontece hoje com Inteligência Artificial.

O modelo não é o produto.

O produto é resolver problemas humanos.


Cinquenta anos de inspiração

Olhe ao seu redor.

Smartphone.

Tablet.

Assistente virtual.

Videoconferência.

Relógio inteligente.

Tradução automática.

Interfaces por voz.

Diagnóstico auxiliado por IA.

Tudo isso apareceu primeiro como ficção.

Muitos engenheiros cresceram assistindo Star Trek.

Eles não copiaram a série.

Eles tentaram construí-la.

Essa talvez seja a maior homenagem que um cientista pode fazer.

Transformar imaginação em engenharia.


A coragem de mostrar um futuro diferente

Em 1966 havia enorme tensão racial nos Estados Unidos.

Mesmo assim, a ponte da Enterprise tinha:

Uma mulher negra.

Um japonês.

Mais tarde, um russo.

Um alienígena.

Todos trabalhando juntos.

Hoje isso parece absolutamente normal.

Naquela época era revolucionário.

Gene Roddenberry não fazia discursos.

Ele simplesmente mostrava um futuro onde isso já havia sido superado.

Essa era sua forma silenciosa de ativismo.


O beijo que entrou para a história

Quando Kirk e Uhura se beijaram na televisão, muita gente ficou escandalizada.

Hoje parece um detalhe.

Naquele momento, porém, milhões de pessoas perceberam que a televisão podia desafiar preconceitos.

Star Trek não queria provocar.

Queria normalizar.

Existe uma enorme diferença entre essas duas coisas.


O verdadeiro motor da Enterprise

Não era matéria-antimatéria.

Era curiosidade.

Cada episódio começava praticamente da mesma forma.

Explorar.

Descobrir.

Aprender.

Entender.

Esse talvez seja o espírito que todo profissional de tecnologia deveria preservar.

Nunca parar de aprender.


O Padawan nunca deixa de estudar

No universo Bellacosa Mainframe, gosto de imaginar que cada profissional de TI recebe um uniforme invisível da Frota Estelar no primeiro dia de carreira.

O desenvolvedor COBOL.

O administrador de banco.

O especialista em RACF.

O arquiteto de APIs.

O engenheiro de IA.

Todos possuem uma missão semelhante.

Explorar novos conhecimentos.

Resolver problemas.

Compartilhar experiências.

Construir sistemas que ajudem pessoas.

É exatamente isso que a Enterprise fazia.


O legado para a Inteligência Artificial

Hoje falamos muito sobre IA.

Agentes.

Robôs.

LLMs.

Governança.

Mas Star Trek já fazia perguntas sobre isso há décadas.

Data, nas séries posteriores, mostrou que inteligência não basta sem ética.

Spock lembrava que lógica sem empatia é insuficiente.

McCoy lembrava que emoção sem razão também falha.

Kirk mostrava que liderança exige equilibrar ambas.

Não é difícil perceber como esses conceitos continuam atuais.


O impacto na ciência

Diversos astronautas declararam que escolheram essa profissão por causa de Star Trek.

Engenheiros da computação contam histórias parecidas.

Pesquisadores da medicina.

Especialistas em robótica.

Até criadores de startups frequentemente mencionam a série como inspiração.

Poucas obras conseguiram influenciar tantas profissões diferentes durante tanto tempo.


Cinquenta anos depois...

Ainda estamos explorando.

Ainda cometemos erros.

Ainda temos guerras.

Ainda existem preconceitos.

Ainda discutimos inteligência artificial.

Ainda buscamos novas fontes de energia.

Ainda sonhamos com Marte.

Ainda queremos conversar com outras civilizações.

Talvez Gene Roddenberry estivesse certo.

O futuro não acontece sozinho.

Ele precisa ser construído.

Todos os dias.


O que Star Trek ensina para um jovem Padawan?

Se eu pudesse resumir cinquenta anos dessa franquia em algumas lições, seriam estas:

  • Nunca pare de aprender.

  • Questione tudo, inclusive suas próprias certezas.

  • Ciência e ética devem caminhar juntas.

  • Diversidade fortalece equipes.

  • Tecnologia existe para servir pessoas, nunca o contrário.

  • A curiosidade é mais poderosa que o medo.

  • Grandes sistemas são construídos por grandes equipes.

  • O conhecimento compartilhado vale mais do que o conhecimento escondido.

  • A exploração começa quando deixamos a zona de conforto.

  • O verdadeiro progresso é medido pela forma como tratamos os outros.

Essas lições valem tanto para uma nave estelar quanto para um datacenter com milhares de aplicações COBOL processando bilhões de transações diariamente.


Uma mensagem para a nova geração

Talvez você tenha conhecido Star Trek através de filmes, séries modernas ou até de memes na internet.

Talvez nunca tenha assistido a um episódio da série clássica.

Se esse for o caso, faça um favor a si mesmo.

Assista.

Não espere efeitos especiais comparáveis aos de hoje.

Olhe além dos cenários de papelão, das miniaturas e dos computadores com luzes piscando.

Ali existe algo muito mais valioso.

Existe uma visão de futuro construída com inteligência, esperança e humanidade.

Em um mundo que frequentemente parece dividido, Star Trek continua lembrando que o maior salto tecnológico nunca será um motor de dobra, um computador quântico ou uma inteligência artificial.

Será aprendermos a cooperar como uma única tripulação.


☕ Considerações finais do Bellacosa Mainframe

Cinquenta anos podem parecer muito tempo para uma série de televisão.

Mas, curiosamente, Star Trek continua jovem.

Porque suas perguntas continuam sem respostas definitivas.

Como construiremos uma Inteligência Artificial ética?

Como exploraremos outros planetas?

Como preservaremos a paz?

Como conciliaremos tecnologia e humanidade?

Como prepararemos a próxima geração de cientistas e programadores?

Talvez essas respostas ainda estejam sendo escritas.

Talvez estejam surgindo neste exato momento em uma universidade, em um laboratório, em um mainframe ou no quarto de algum jovem Padawan que acabou de descobrir COBOL, Python ou Inteligência Artificial.

Se este artigo chegar até uma dessas pessoas, então Gene Roddenberry continuará vencendo sua missão, mesmo seis décadas depois.

Porque Star Trek nunca foi apenas uma série.

Foi um convite permanente para imaginar um futuro melhor — e, principalmente, para ajudar a construí-lo.

Vida longa e próspera. 🖖


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...