Goblin Slayer — Parte XII : Goblin Slayer sem Mistérios O Guia Definitivo da Série Completa

Bellacosa Mainframe apresenta Goblin Slayer parte xii

---

☕ Um Café no Bellacosa Mainframe

Goblin Slayer — Parte XII : Goblin Slayer sem Mistérios

O Guia Definitivo da Série Completa

Quando um Programador COBOL Descobre que Grandes Obras Também Precisam de um Mapa para Não se Perder na Dungeon

---

Introdução

Existem obras que podem ser consumidas em apenas uma tarde.

Goblin Slayer definitivamente não é uma delas.

À primeira vista, parece apenas uma história sobre um aventureiro obcecado em eliminar goblins.

Entretanto, conforme avançamos nesta série do Bellacosa Mainframe, percebemos que Kumo Kagyu construiu muito mais do que uma simples aventura de fantasia medieval.

Existe uma cronologia cuidadosamente planejada.

Existe uma engenharia militar extremamente realista.

Existe psicologia profunda.

Existe estratégia baseada em princípios clássicos de guerra.

Existe ecologia aplicada à construção dos monstros.

Existem dezenas de referências escondidas ao universo dos RPGs de mesa, literatura fantástica e história militar.

Pensando nisso, reunimos aqui todos os capítulos desta série em uma única página.

Ela funciona como um mapa da aventura.

Leia na ordem ou escolha o tema que mais desperta sua curiosidade.

---

📚 Guia da Série

1 — A Evolução Cronológica Completa da Franquia Goblin Slayer

Resumo

Como uma pequena web novel publicada em 2013 transformou-se em uma das maiores franquias modernas de Dark Fantasy, passando por light novels, mangás, filmes, spin-offs e anime.

➡️ Leia o artigo completo:

LINK DO ARTIGO

---

2 — A Biologia dos Goblins

Resumo

Uma análise científica dos goblins como espécie invasora, explorando anatomia, comportamento, adaptação, ecologia, cadeia hierárquica e por que representam uma ameaça muito maior do que simples monstros de RPG.

➡️ Leia o artigo completo:

LINK

---

3 — As Referências Escondidas de Goblin Slayer

Resumo

Conan, Tolkien, Berserk, Dungeons & Dragons, Sword World RPG e dezenas de outras influências que ajudaram Kumo Kagyu a construir um universo incrivelmente rico.

➡️ Leia o artigo completo:

LINK

---

4 — A Psicologia Profunda de Goblin Slayer

Resumo

Trauma, resiliência, memória, silêncio, relações humanas e crescimento emocional explicados sob a ótica da psicologia moderna.

➡️ Leia o artigo completo:

LINK

---

5 — A Engenharia Militar de Goblin Slayer

Resumo

Reconhecimento, logística, redundância, planejamento, economia de recursos e pensamento operacional fazem do protagonista um verdadeiro engenheiro da guerra.

➡️ Leia o artigo completo:

LINK

---

6 — A Estratégia de Goblin Slayer

Resumo

Por que Goblin Slayer vence batalhas muito antes da primeira espada ser desembainhada? Um mergulho nos princípios estratégicos presentes em toda a obra.

➡️ Leia o artigo completo:

LINK

---

7 — Os 100 Segredos de Goblin Slayer que Quase Nenhum Fã Percebeu

Resumo

Uma coletânea de curiosidades, simbolismos, referências, detalhes de narrativa e pequenas decisões de Kumo Kagyu que enriquecem ainda mais a experiência da obra.

➡️ Leia o artigo completo:

LINK

---

Ordem Recomendada de Leitura

🥇 Começando agora?

Siga exatamente esta sequência:

1. Evolução Cronológica

2. Biologia dos Goblins

3. Referências Escondidas

4. Psicologia

5. Engenharia Militar

6. Estratégia

7. Os 100 Segredos

Cada capítulo foi escrito para aprofundar o anterior, criando uma experiência semelhante à progressão de uma campanha clássica de RPG.

---

Para Quem Esta Série Foi Escrita?

Esta coleção foi pensada para leitores que desejam ir além da superfície da obra, incluindo:

• fãs de Goblin Slayer e Dark Fantasy;

• jogadores de RPG de mesa;

• leitores de light novels e mangás;

• interessados em estratégia militar e história;

• estudantes de psicologia narrativa;

• admiradores de worldbuilding;

• programadores, arquitetos de software e profissionais de tecnologia que apreciam analogias entre sistemas complexos e narrativas bem construídas.

Cada artigo busca mostrar que Goblin Slayer não é apenas uma sequência de combates contra monstros, mas uma obra cuidadosamente arquitetada, em que cada elemento exerce uma função específica dentro do conjunto.

---

Conclusão

Assim como um grande sistema COBOL de missão crítica não pode ser compreendido apenas pela leitura de um único programa, Goblin Slayer revela sua verdadeira grandeza quando analisamos todas as suas camadas em conjunto.

Esperamos que esta série funcione como um verdadeiro grimório de referência, capaz de acompanhar tanto o fã que acaba de conhecer a obra quanto aquele que já revisitou a franquia inúmeras vezes.

Afinal, toda grande aventura merece um mapa. E toda dungeon merece um explorador disposto a abrir cada porta, investigar cada corredor e descobrir os segredos escondidos nas sombras.

---

☕ Um Café no Bellacosa Mainframe

ARQUIVOS DA GUILDA • CLASSIFICAÇÃO: DARK FANTASY

Goblin Slayer sem Mistérios

O Guia Definitivo da Série Completa

Uma jornada por cronologia, psicologia, biologia, estratégia, engenharia militar, referências culturais, simbolismos e os segredos escondidos de Goblin Slayer.

“Quando um Programador COBOL Descobre que Grandes Obras Também Precisam de um Mapa para Não se Perder na Dungeon.”

Explorar a série

RELATÓRIO DE MISSÃO

Uma série construída como uma campanha de RPG

Goblin Slayer sem Mistérios é uma coleção especial do Bellacosa Mainframe dedicada à análise profunda da obra criada por Kumo Kagyu. Cada capítulo investiga uma camada diferente da franquia, relacionando fantasia sombria, RPG de mesa, estratégia, trauma, sobrevivência, engenharia militar e arquitetura de sistemas.

A coleção foi organizada em ordem cronológica para facilitar a leitura. Você pode começar pela Parte I, seguir capítulo após capítulo ou utilizar os filtros para selecionar assuntos como psicologia, goblins, táticas, história da franquia e cultura otaku.

Todos os títulos abaixo são links HTML reais e permanecem acessíveis mesmo quando o JavaScript estiver desativado. Isso facilita a navegação dos leitores e a descoberta das páginas por mecanismos de busca.

Pesquisar nos arquivos

⌕

Progresso da campanha 0 de 14 missões visitadas

14 capítulos encontrados

I

Introdução

Goblin Slayer sem Mistérios — Parte I

O ponto de entrada da campanha. Uma análise sobre o herói invisível que não salva o mundo em uma única batalha, mas impede silenciosamente que ele desmorone todos os dias.

Heroísmo Disciplina Mainframe

Ler artigo completo

II

Disciplina

Goblin Slayer sem Mistérios — Parte II

O verdadeiro poder não está na espada, mas na constância de levantar, preparar os equipamentos e executar diariamente o trabalho que quase ninguém deseja assumir.

Rotina Dever Persistência

Ler artigo completo

III

Missão crítica

Goblin Slayer sem Mistérios — Parte III

Nem todo herói enfrenta o Rei Demônio. Alguns garantem que na segunda-feira existirão sistema, salários, luz e uma aldeia inteira ainda de pé.

Disponibilidade Proteção Responsabilidade

Ler artigo completo

IV

Arquitetura

Parte IV — O Arquiteto Invisível de Goblin Slayer

Uma reflexão sobre profissionais que projetam soluções, previnem desastres e permanecem atrás do terminal enquanto o restante do mundo apenas percebe que tudo continua funcionando.

Arquitetura COBOL Prevenção

Ler artigo completo

V

Cronologia

Parte V — A Evolução Cronológica Completa da Franquia

Da publicação original às light novels, mangás, adaptações, spin-offs, filme e temporadas do anime: a evolução de uma história que cresceu release após release.

Web Novel Light Novel Anime

Ler artigo completo

VI

Biologia

Parte VI — A Biologia dos Goblins

Anatomia, comportamento, adaptação, hierarquia e ecologia dos goblins analisados como uma espécie invasora capaz de explorar brechas e evoluir rapidamente.

Ecologia Adaptação Worldbuilding

Ler artigo completo

VII

Referências

Parte VII — As Referências Escondidas de Goblin Slayer

Conan, Berserk, Tolkien, Dungeons & Dragons, Sword World RPG, literatura fantástica, mitologia e cultura pop escondidos entre as linhas da obra de Kumo Kagyu.

RPG Literatura Cultura pop

Ler artigo completo

VIII

Psicologia

Parte VIII — A Psicologia Profunda de Goblin Slayer

Trauma, hipervigilância, isolamento, necessidade de controle, resiliência e reconstrução emocional por meio das relações que lentamente devolvem humanidade ao protagonista.

Trauma Memória Resiliência

Ler artigo completo

IX

Engenharia militar

Parte IX — A Engenharia Militar de Goblin Slayer

Reconhecimento, suprimentos, redundância, controle do terreno, fortificação, retirada e arquitetura operacional transformam batalhas perigosas em vitórias planejadas.

Logística Terreno Contingência

Ler artigo completo

X

Estratégia

Parte X — A Estratégia de Goblin Slayer

Uma análise sobre informação, iniciativa, especialização, probabilidades, redundância e a capacidade de pensar diversos movimentos à frente do adversário.

Planejamento Inteligência Antecipação

Ler artigo completo

XI

100 segredos

Parte XI — Os 100 Segredos de Goblin Slayer

Cem detalhes sobre personagens, mundo, goblins, equipamentos, narrativa, simbolismos, RPG, produção, psicologia e estratégia que podem passar despercebidos até pelos fãs.

Easter eggs Simbolismos Curiosidades

Ler artigo completo

XII

Guia completo

Parte XII — Goblin Slayer sem Mistérios

O mapa da campanha: introdução, sequência recomendada, resumo dos capítulos e orientação para explorar todas as camadas da coleção sem se perder na dungeon.

Índice Mapa Ordem de leitura

Ler artigo completo

FINAL

Síntese definitiva

Por Que Goblin Slayer É uma das Melhores Obras de Dark Fantasy

A conclusão da jornada, reunindo cronologia, psicologia, estratégia, engenharia militar, simbolismos, referências culturais, construção de mundo e impacto na cultura otaku.

Dark Fantasy Síntese Conclusão

Ler artigo completo

BÔNUS

Dossiê militar

A Composição do Exército Goblin em The Fate of an Adventurer

Rei Goblin, estado-maior, Champions, Shamans, arqueiros, infantaria, Riders, logística e cadeia de comando analisados como componentes de uma força militar organizada.

Exército Goblin Hierarquia Ordem de batalha

Ler artigo completo

ROTA RECOMENDADA

Como percorrer esta dungeon

Comece pelas três primeiras partes para compreender a proposta da série. Depois visite o Arquiteto Invisível, conheça a evolução da franquia e aprofunde-se em biologia, referências, psicologia, engenharia militar e estratégia.

1. 01 Fundamentos do herói invisível
2. 02 História e evolução da franquia
3. 03 Biologia e organização dos goblins
4. 04 Psicologia e simbolismos
5. 05 Engenharia militar e estratégia
6. 06 Segredos, guia completo e síntese final

Índice textual dos artigos

Esta relação fornece acesso direto e rastreável a todos os capítulos da coleção:

1. Goblin Slayer sem Mistérios — Parte I
2. Goblin Slayer sem Mistérios — Parte II
3. Goblin Slayer sem Mistérios — Parte III
4. Parte IV — O Arquiteto Invisível de Goblin Slayer
5. Parte V — A Evolução Cronológica da Franquia
6. Parte VI — A Biologia dos Goblins
7. Parte VII — As Referências Escondidas
8. Parte VIII — A Psicologia Profunda
9. Parte IX — A Engenharia Militar
10. Parte X — A Estratégia de Goblin Slayer
11. Parte XI — Os 100 Segredos de Goblin Slayer
12. Parte XII — O Guia Definitivo
13. Parte Final — Por Que Goblin Slayer É uma das Melhores Obras de Dark Fantasy
14. A Composição do Exército Goblin

Bellacosa Mainframe Dark Fantasy • Anime • RPG • COBOL • Estratégia

“A vitória não é improviso. É arquitetura.”

🧪 Um guia para o programador COBOL iniciante entender Unit Test, Component Test, Integration, E2E, APIs, Db2, CICS, IA, Mutation Testing, Chaos Engineering

  

Bellacosa Mainframe e os testes automatizados

☕ Um Café no Bellacosa Mainframe

Dr. Strangelove e a Arte de Parar de se Preocupar e Amar os Testes

🧪 Um guia para o programador COBOL iniciante entender Unit Test, Component Test, Integration, E2E, APIs, Db2, CICS, IA, Mutation Testing, Chaos Engineering e por que um MAXCC=0 não significa que o mundo está salvo

Imagine a cena.

Uma sala subterrânea.

Luzes fracas.

Painéis verdes piscando.

Um enorme mapa operacional ocupa a parede.

Generais discutem nervosamente ao redor de uma mesa enquanto alguém observa um terminal 3270.

De repente, surge a mensagem:

IEF142I PAYROLL STEP030 - STEP WAS EXECUTED - COND CODE 0000

Silêncio.

Um jovem programador COBOL ergue os braços:

— Funcionou!

Do outro lado da mesa, um velho sysprog ajusta os óculos.

— O job terminou com RC=0.

— Exatamente! Funcionou!

— Eu disse que terminou.

— E qual é a diferença?

Nesse momento, uma música imaginária começa a tocar e, em algum lugar entre o JES2, o Db2 e um endpoint REST perdido na nuvem, o Dr. Strangelove levanta lentamente a mão mecânica.

Bem-vindo ao maravilhoso mundo dos testes de software.

Porque existe uma diferença monumental entre:

O PROGRAMA EXECUTOU

e:

O PROGRAMA FEZ A COISA CERTA.

E existe uma diferença ainda maior entre:

O PROGRAMA FEZ A COISA CERTA UMA VEZ.

e:

O SISTEMA CONTINUARÁ FAZENDO A COISA CERTA
QUANDO O BANCO ESTIVER LENTO,
O MQ ESTIVER INDISPONÍVEL,
O USUÁRIO CLICAR DUAS VEZES,
O RACF NEGAR ACESSO
E UM ARQUIVO CHEGAR COM 17 BYTES A MENOS.

Essa diferença se chama engenharia.

---

🦖 Antes de qualquer coisa: o teste não existe para provar que você é inteligente

Essa talvez seja a primeira lição para quem está começando em COBOL.

Testar não é demonstrar que o programa está bonito.

Não é mostrar ao chefe:

100% DE COVERAGE

e sair correndo em direção ao café.

Testar é produzir evidência de que o comportamento esperado existe.

Pense em um programa COBOL simples:

IF WS-IDADE >= 18
    MOVE 'MAIOR' TO WS-STATUS
ELSE
    MOVE 'MENOR' TO WS-STATUS
END-IF.

Parece fácil.

Então alguém testa:

IDADE = 25
RESULTADO = MAIOR

Passou.

Parabéns.

Temos uma evidência.

Mas ainda sabemos pouco.

Teste também:

IDADE = 17
IDADE = 18
IDADE = 19
IDADE = 0
IDADE = 999
IDADE = -1

Nesse ponto começamos a perceber algo fundamental.

O trabalho interessante não é apenas perguntar:

funciona?

A pergunta interessante é:

em quais condições funciona, em quais condições falha e o que significa falhar corretamente?

---

🔬 UNIT TEST — o microscópio do programador

Unit Test é o teste da menor unidade lógica razoável.

Em COBOL isso pode ser:

• um parágrafo;

• uma SECTION;

• uma rotina;

• uma regra de negócio isolada;

• uma transformação;

• um cálculo.

Imagine:

CALCULA-JUROS.

    COMPUTE WS-JUROS =
        WS-VALOR * WS-TAXA / 100.

Podemos testar:

VALOR = 1000
TAXA  = 10
JUROS = 100

Mas um bom programador vai além:

VALOR = 0
TAXA = 10

VALOR = 1000
TAXA = 0

VALOR = 1000
TAXA = -10

VALOR = 999999999
TAXA = 99.99

Aqui aparece uma das primeiras curiosidades importantes para quem entra no mundo COBOL:

💰 Dinheiro é uma criatura traiçoeira

COBOL é historicamente excelente para sistemas financeiros justamente porque possui representação decimal adequada.

Mesmo assim, você precisa pensar em:

PIC 9(9)V99
PIC S9(9)V99 COMP-3
ROUNDED
ON SIZE ERROR

Um cálculo pode estar matematicamente correto e ainda produzir problema de tamanho, arredondamento ou sinal.

O Unit Test serve justamente para transformar essas hipóteses em fatos verificáveis.

---

🧩 COMPONENT TEST — quando várias engrenagens começam a conversar

Um componente é maior que uma função isolada.

Imagine um programa:

PROGRAMA DE CADASTRO

VALIDA CPF
   ↓
VALIDA DATA
   ↓
CALCULA SCORE
   ↓
CLASSIFICA CLIENTE
   ↓
MONTA REGISTRO

Você pode testar cada rotina separadamente.

Depois pode testar o componente completo sem necessariamente acessar Db2, CICS ou MQ.

Por exemplo:

ENTRADA

CPF válido
idade 43
renda 8000

SAÍDA

cliente aceito
score 742
categoria B

Isso começa a testar o comportamento da aplicação como conjunto.

É um pouco como testar o motor inteiro depois de testar pistão, válvula e injeção separadamente.

---

🟩 INTEGRATION TEST — “Vocês dois realmente conseguem conversar?”

Aqui começam algumas das melhores explosões cinematográficas.

Imagine:

PROGRAMA COBOL
     ↓
Db2

Seu programa pode estar perfeito.

Sua tabela também.

Mas a integração pode falhar porque:

coluna mudou
tipo mudou
package não está bindado
plan errado
authorization falhou
SQLCODE inesperado
connection indisponível

Ou:

COBOL
 ↓
MQ
 ↓
JAVA

O programa COBOL envia:

CUSTOMER-ID=00001234

O Java espera:

customerId=1234

Os dois programas podem passar individualmente em todos os testes.

Juntos:

💥

Esse é o território do Integration Testing.

---

🐳 Testcontainers e a revolução do “vamos testar com algo parecido com produção”

No mundo distribuído moderno existe uma ferramenta muito interessante chamada Testcontainers.

Ela permite criar dependências reais durante o teste.

Por exemplo:

TESTE
  ↓
sobe PostgreSQL
  ↓
executa aplicação
  ↓
testa
  ↓
derruba PostgreSQL

Isso evita uma velha armadilha:

Produção = banco A
Teste    = banco B parecido

A palavra perigosa aqui é:

parecido.

Em computação, “parecido” é frequentemente irmão de “incidente”.

No mainframe temos uma filosofia semelhante quando criamos ambientes de teste com Db2, VSAM, MQ, CICS e configurações próximas de produção.

Quanto maior a fidelidade do ambiente, maior tende a ser nossa confiança.

Mas também maior o custo.

E aqui começa a aparecer a famosa pirâmide.

---

🔺 A PIRÂMIDE DOS TESTES

Imagine:

                  /\
                 /  \
                / E2E\
               /------\
              /INTEGR. \
             /----------\
            / COMPONENT  \
           /--------------\
          /      UNIT       \
         /___________________\

A ideia é simples.

Na base:

MUITOS TESTES
RÁPIDOS
BARATOS
ISOLADOS

No topo:

POUCOS TESTES
LENTOS
CAROS
COM MUITAS DEPENDÊNCIAS

Não existe uma porcentagem mágica.

Você encontrará gente repetindo:

70% Unit
20% Integration
10% E2E

Não trate isso como mandamento gravado em pedra por Moisés depois de um IPL.

É apenas uma heurística.

A arquitetura do sistema deve determinar a estratégia.

---

🎭 END-TO-END — agora queremos saber se o usuário consegue sobreviver

End-to-End Test, ou E2E, acompanha uma jornada completa.

Imagine Internet Banking:

cliente abre navegador
        ↓
login
        ↓
consulta conta
        ↓
faz transferência
        ↓
confirma
        ↓
recebe comprovante

Nos bastidores:

Browser
 ↓
Frontend
 ↓
API Gateway
 ↓
OAuth
 ↓
z/OS Connect
 ↓
CICS
 ↓
COBOL
 ↓
Db2
 ↓
MQ
 ↓
outro sistema

Agora temos algo muito próximo da realidade.

Excelente.

Só existe um pequeno problema:

se o teste falhar, quem matou o coronel?

Pode ser:

browser
CSS selector
rede
token
API
DNS
z/OS Connect
CICS
COBOL
Db2
MQ
serviço remoto
ambiente de teste

Um único:

FAILED

pode significar vinte coisas diferentes.

É por isso que E2E é extremamente valioso, mas também caro.

---

👻 O monstro chamado Flaky Test

Agora chegamos a uma criatura verdadeiramente perigosa.

O flaky test.

Hoje:

PASS

Amanhã:

FAIL

Executa novamente:

PASS

O programador aprende:

quando falhar, roda novamente

Essa é uma péssima situação.

Depois de alguns meses:

PIPELINE FAILED

e alguém responde:

— Deve ser aquele teste.

Roda novamente.

Passa.

A partir desse momento, o sistema de testes começou a perder autoridade.

Isso é equivalente a um alarme de incêndio que dispara todos os dias sem incêndio.

No começo todo mundo corre.

Depois de três meses:

— Ah, é aquele alarme.

Até o dia em que o prédio realmente pega fogo.

---

📊 COVERAGE — a estatística favorita para impressionar PowerPoint

Imagine:

IF WS-SALDO >= WS-VALOR
    PERFORM EFETUA-SAQUE
END-IF.

Você cria um teste:

SALDO = 1000
VALOR = 100

A linha foi executada.

Coverage:

100%

Maravilhoso.

Mas você testou:

SALDO = 100
VALOR = 100

?

E:

SALDO = 99
VALOR = 100

?

Coverage mede frequentemente:

o código foi executado?

Não necessariamente:

o comportamento foi corretamente verificado?

É uma diferença monumental.

---

🧬 MUTATION TESTING — quem testa os testes?

Essa técnica é maravilhosa.

Imagine seu código:

IF WS-IDADE >= 18

Uma ferramenta de mutation testing altera deliberadamente para:

IF WS-IDADE > 18

Depois executa seus testes.

Se eles continuarem passando:

🤨

talvez ninguém esteja realmente testando a fronteira:

IDADE = 18

Mutation Testing basicamente pergunta:

se eu introduzir um pequeno defeito proposital, seus testes percebem?

É uma pergunta muito mais poderosa do que apenas coverage.

---

🔐 SECURITY TESTING — “funcionar” não significa “ser seguro”

Imagine:

Administrador consegue consultar salários?

Teste:

PASS

Ótimo.

Agora faça a pergunta de segurança:

Usuário comum consegue consultar salários?

Se a resposta for sim:

Parabéns.
Sua aplicação funciona perfeitamente
e está perfeitamente vulnerável.

Security Testing precisa verificar:

autenticação
autorização
privilégio
validação de entrada
segregação
sessão
tokens
exposição de dados

No mainframe:

RACF
SAF
ACEE
profiles
FACILITY
SURROGAT
dataset access
CICS transactions

Um programa COBOL pode produzir exatamente o resultado esperado e ainda ser um desastre de segurança.

---

⚡ PERFORMANCE TESTING — funciona com um usuário. E com cinquenta mil?

Imagine:

transação demora 50 ms

Excelente.

Então chegam:

10 usuários
100 usuários
1.000 usuários
20.000 usuários

Aí começamos a medir:

CPU
elapsed time
throughput
locks
threads
connections
I/O
queue depth
Db2 contention
CICS MXT
WLM

E essa é uma das grandes vantagens pedagógicas de estudar testes pensando em mainframe.

O mainframe sempre viveu no mundo onde:

funcionalidade e capacidade são problemas diferentes.

---

🐒 CHAOS ENGINEERING — Dr. Strangelove finalmente assume o comando

Chaos Engineering parece uma ideia de alguém que bebeu café demais:

vamos quebrar deliberadamente coisas para ver o que acontece.

Exemplo:

derrube um serviço

ou:

adicione latência

ou:

bloqueie acesso ao banco

ou:

mate uma instância

e observe.

A pergunta não é:

o sistema funciona?

A pergunta é:

o sistema continua se comportando
de maneira aceitável quando algo falha?

No mundo COBOL podemos traduzir a ideia para:

Db2 indisponível
MQ indisponível
arquivo faltando
arquivo cheio
dataset em uso
VSAM file status diferente de 00
transaction timeout
deadlock
CICS region indisponível

Sistemas empresariais não são construídos apenas para o mundo feliz.

Eles precisam sobreviver ao mundo real.

---

🦕 TESTANDO BATCH — o capítulo que os diagramas modernos quase sempre esquecem

Agora chegamos à terra natal do COBOL.

Imagine:

JOB001
  ↓
gera arquivo
  ↓
JOB002
  ↓
atualiza Db2
  ↓
JOB003
  ↓
manda MQ
  ↓
JOB004
  ↓
gera relatório

Você precisa testar:

JCL
PROC
COND
IF/THEN/ELSE
GDG
DISP
datasets
SORT
IDCAMS
restart
checkpoint
commit
rerun

Exemplo:

STEP010 RC=0
STEP020 RC=4

O STEP030 deveria rodar?

Depende.

E se:

STEP020 RC=8

?

E se o arquivo estiver vazio?

E se houver registro duplicado?

E se o job cair depois de atualizar metade da tabela?

Você consegue reiniciar?

O processamento é idempotente?

Esse último termo merece atenção.

🔁 Idempotência

Significa, simplificando:

executar novamente não deve causar destruição adicional.

Imagine pagamento:

PAGA R$100

Job cai.

Operador reinicia.

Se o programa pagar novamente:

R$200 enviados

temos um pequeno incidente.

Se repetirmos 300 mil registros...

temos reunião com vice-presidente.

---

🤖 AGORA A IA ENTRA NA SALA DE GUERRA

Chegamos a GitHub Copilot, ChatGPT, Claude, Cursor, Qodo e outros.

Essas ferramentas conseguem ajudar a:

gerar testes
encontrar edge cases
criar mocks
produzir dados
documentar
explicar erros
analisar cobertura
sugerir cenários

Você pode entregar:

IF WS-SALDO >= WS-SAQUE
   SUBTRACT WS-SAQUE FROM WS-SALDO
END-IF

e perguntar:

Quais casos devo testar?

A IA provavelmente sugerirá:

saldo maior
saldo igual
saldo menor
saque zero
saque negativo
saldo zero
valor máximo

Isso economiza muito tempo.

Mas existe uma pegadinha digna de Stanley Kubrick.

---

☢️ IA gera o código. IA gera o teste. Tudo passa.

Imagine:

IA interpreta requisito errado
      ↓
gera implementação errada
      ↓
IA usa a mesma interpretação
      ↓
gera teste errado
      ↓
PASS

Temos então uma maravilha tecnológica:

um erro perfeitamente documentado, testado, automatizado e aprovado pelo pipeline.

Essa talvez seja uma das grandes questões da engenharia assistida por IA.

Quanto mais fácil fica gerar código, mais importante fica validar intenção.

---

🧠 O programador do futuro precisará responder menos “como?” e mais “o quê?”

Antes:

Como escrevo este teste?

Agora uma IA pode escrever boa parte dele.

A pergunta mais importante passa a ser:

O QUE precisa ser testado?

E principalmente:

O QUE ninguém lembrou de testar?

A experiência começa exatamente aí.

Um programador iniciante testa:

usuário fez tudo certo

Um programador experiente pergunta:

usuário clicou duas vezes?

Depois:

a rede caiu no meio?

Depois:

a mensagem chegou duplicada?

Depois:

o token expirou?

Depois:

Db2 deu deadlock?

Depois:

o job reiniciou após commit parcial?

A maturidade em testes não consiste em escrever mais ASSERT.

Consiste em imaginar mais maneiras pelas quais a realidade pode destruir nossas suposições.

---

🛠️ PASSO A PASSO PARA O COBOLISTA INICIANTE

Vamos transformar tudo em um roteiro prático.

Passo 1 — descubra a regra

Antes de testar:

ENTRADA
PROCESSAMENTO
SAÍDA

Exemplo:

SALDO = 1000
SAQUE = 300
SALDO FINAL = 700

---

Passo 2 — teste o Happy Path

Comece pelo comportamento esperado.

saldo suficiente
valor válido
cliente válido

---

Passo 3 — teste fronteiras

Se a regra diz:

IDADE >= 18

teste:

17
18
19

Essa pequena técnica encontra uma quantidade absurda de erros.

---

Passo 4 — teste entradas ruins

zero
negativo
nulo
branco
máximo
mínimo
duplicado
formato inválido

---

Passo 5 — teste integrações

Pergunte:

e se Db2 falhar?
e se VSAM retornar file status 23?
e se MQ estiver indisponível?
e se CICS devolver erro?

---

Passo 6 — teste restart

Principalmente batch.

Pergunte:

se cair no meio,
consigo continuar?

---

Passo 7 — teste segurança

Pergunte:

quem pode executar?
quem pode ver?
quem pode alterar?

---

Passo 8 — teste carga

Pergunte:

funciona com uma transação?

Depois:

e com 10 mil?

---

Passo 9 — observe produção

Esse ponto é frequentemente esquecido.

Produção ensina.

Logs, abends, SMF, RMF, CICS statistics, Db2 traces e incidentes mostram situações que talvez ninguém tenha imaginado em laboratório.

Cada incidente deveria produzir, quando possível:

novo conhecimento
        ↓
novo teste

---

🎁 EASTER EGGS PARA QUEM CHEGOU ATÉ AQUI

Primeiro:

Dr. Strangelove é uma referência óbvia ao filme de Stanley Kubrick:

Dr. Strangelove or: How I Learned to Stop Worrying and Love the Bomb.

Nossa versão poderia ser:

How I Learned to Stop Worrying and Love the Test Suite.

Segundo:

Se você encontrar um programador COBOL dizendo:

RC=0, então está certo.

não discuta.

Ofereça café.

Depois pergunte delicadamente:

“Mas você conferiu o arquivo de saída?”

Terceiro:

O verdadeiro teste de integração de qualquer sistema corporativo acontece sexta-feira às 17h43 quando alguém diz:

“É só uma alteração pequena.”

Quarto:

Todo programador algum dia conhece este comando psicológico:

RERUN

Passou na segunda vez?

Ótimo.

Agora você ganhou um problema muito pior.

---

☕ REGRA BELLACOSA Nº 1

Nunca confunda:

JOB TERMINOU

com:

PROCESSAMENTO CORRETO

Nunca confunda:

TESTE PASSOU

com:

SISTEMA ESTÁ CORRETO

Nunca confunda:

100% COVERAGE

com:

100% CONFIANÇA

E nunca confunda:

IA GEROU 47 TESTES

com:

ALGUÉM ENTENDEU O RISCO.

---

🧨 A grande conclusão: Testing não é sobre código

No fundo, Testing é engenharia de incerteza.

Estamos tentando responder:

Quanto sabemos sobre o comportamento deste sistema?

Depois:

O que ainda não sabemos?

E finalmente:

Quanto custa descobrir isso somente em produção?

Essa última pergunta muda tudo.

Um bug descoberto durante Unit Test talvez custe minutos.

Durante Integration Test, horas.

Durante homologação, dias.

Depois da implantação, talvez semanas.

Depois de afetar 500 mil clientes...

PowerPoint.

War Room.

Conference Call.

RCA.

Executivos.

Compliance.

Auditoria.

E alguém inevitavelmente perguntará:

Como nossos testes não pegaram isso?

A pergunta quase nunca possui resposta simples.

Porque sistemas reais não são apenas código.

São:

código
+
dados
+
infraestrutura
+
rede
+
configuração
+
segurança
+
operações
+
processos
+
humanos

É por isso que nenhum teste isolado consegue provar que o sistema inteiro é perfeito.

A Pirâmide de Testes, o Testing Trophy, Mutation Testing, Security Testing, Performance Testing e Chaos Engineering são maneiras diferentes de iluminar regiões diferentes da escuridão.

E isso nos leva à talvez mais importante transformação trazida pela inteligência artificial.

Durante décadas, programadores foram valorizados em grande parte por sua capacidade de produzir código.

Agora produzir código está ficando barato.

Muito barato.

Uma IA consegue produzir em segundos aquilo que um desenvolvedor levaria horas para digitar.

Mas produzir confiança continua caro.

Porque alguém precisa entender:

qual é a regra?
qual é o risco?
qual é a exceção?
qual é a fronteira?
qual comportamento seria perigoso?
qual falha é aceitável?
qual falha é catastrófica?

E isso não é simplesmente programação.

Isso é julgamento.

Talvez o programador COBOL de 2030 escreva muito menos código manualmente.

Talvez peça:

“Gere um programa COBOL para esta regra.”

A IA produzirá.

Depois:

“Gere os testes.”

A IA produzirá.

Mas alguém ainda precisará olhar para tudo aquilo e fazer a pergunta que nenhum compilador consegue responder sozinho:

Estamos testando aquilo que realmente importa?

E, quando você chegar a esse ponto, terá deixado de ser apenas alguém que escreve COBOL.

Terá começado a pensar como engenheiro de sistemas.

Em algum lugar distante, o JES2 imprimirá:

MAXCC=0000

Você olhará para a tela.

Não comemorará imediatamente.

Tomará um gole de café.

Abrirá o output.

Conferirá os registros.

Verificará os totais.

Examinará o SQLCODE.

Confirmará os datasets.

E somente então dirá:

— Agora podemos conversar.

Dr. Strangelove sorrirá.

O mainframe continuará funcionando.

E ninguém precisará apertar o botão vermelho.

CHANGE REQUEST CLOSED.

INCIDENT NOT FOUND.

CAFÉ CONSUMIDO COM SUCESSO.

CÂMBIO FINAL.

 

Bellacosa Mainframe e a lista de animes que vão te quebrar

☕💣🧠 OPERADOR, O PROBLEMA NUNCA FOI O APOCALIPSE — O PROBLEMA É QUANDO A REALIDADE COMEÇA A RETORNAR ERROS DE LEITURA!

Se você terminou Gakkougurashi! (School-Live!) e ficou alguns minutos olhando para a tela tentando processar o que acabou de acontecer, saiba que você não está sozinho.

School-Live pertence a uma categoria rara de animes que não atacam o espectador com monstros, explosões ou batalhas gigantescas. Eles atacam algo muito mais sensível: a percepção da realidade.

São obras que apresentam um ambiente aparentemente normal, mas escondem processos obscuros executando em segundo plano. Quando a verdade finalmente aparece, o espectador percebe que passou vários episódios observando o mundo através de um filtro defeituoso.

Esse tipo de anime funciona como uma auditoria psicológica em produção.

Você acredita estar assistindo uma coisa.

Mas está assistindo outra.

A genialidade dessas obras está justamente na manipulação da perspectiva. Muitas vezes o protagonista é um narrador pouco confiável, alguém traumatizado ou simplesmente incapaz de compreender completamente a situação em que vive.

O resultado são histórias que permanecem na memória durante anos.

Não porque possuem os melhores combates.

Não porque possuem os melhores efeitos visuais.

Mas porque alteram a forma como você interpreta os acontecimentos.

Os animes desta lista compartilham exatamente esse DNA.

São séries repletas de mistério, simbolismo, trauma psicológico, dilemas existenciais, realidades distorcidas, segredos devastadores e revelações capazes de provocar um verdadeiro dump de memória no cérebro do espectador.

Prepare o console.

Ative o rastreamento de eventos.

Faça backup da sanidade.

Porque os próximos sistemas possuem alto potencial de gerar ABEND emocional.

---

1. Puella Magi Madoka Magica (2011)

Personagens

• Madoka Kaname

• Homura Akemi

• Sayaka Miki

• Mami Tomoe

• Kyubey

Sinopse

Garotas recebem a oportunidade de se tornarem garotas mágicas e realizar um desejo.

O custo da operação, entretanto, está oculto nos contratos.

Resumo

O anime desmonta completamente o gênero "garotas mágicas" e o reconstrói como horror psicológico existencial.

Dica Bellacosa Mainframe

☕ OPERADOR, LEIA TODAS AS CLÁUSULAS ANTES DE ASSINAR O CHANGE REQUEST DO KYUBEY.

---

2. Higurashi no Naku Koro ni (2006)

Personagens

• Keiichi Maebara

• Rena Ryuuguu

• Mion Sonozaki

• Rika Furude

Sinopse

Uma pequena vila japonesa esconde segredos aterradores.

Resumo

Mistura paranoia, assassinatos, loops temporais e conspirações.

Cada arco revela novas camadas da verdade.

Dica Bellacosa

💣 NÃO CONFIE EM LOGS INCOMPLETOS.

---

3. Shinsekai Yori (2012)

Personagens

• Saki Watanabe

• Satoru

• Maria

• Shun

Sinopse

Mil anos no futuro, a humanidade vive numa sociedade aparentemente perfeita.

Resumo

Uma das maiores obras de ficção científica dos animes.

A verdade por trás da sociedade é perturbadora.

Dica Bellacosa

⚠️ QUANDO A AUDITORIA ESTÁ PROIBIDA, EXISTE ALGO MUITO ERRADO NO SISTEMA.

---

4. Serial Experiments Lain (1998)

Personagens

• Lain Iwakura

Sinopse

Uma garota começa a receber mensagens de alguém que deveria estar morto.

Resumo

Internet, consciência digital e identidade humana se misturam.

Dica Bellacosa

🖥️ O PROBLEMA COMEÇA QUANDO O USUÁRIO SE TORNA PARTE DA REDE.

---

5. Ergo Proxy (2006)

Personagens

• Re-l Mayer

• Vincent Law

• Pino

Sinopse

Uma investigadora descobre falhas na sociedade artificial onde vive.

Resumo

Filosofia, inteligência artificial e existencialismo.

Dica Bellacosa

🤖 QUANDO O ROBÔ COMEÇA A QUESTIONAR O SISTEMA, O INCIDENTE JÁ ESTÁ ABERTO.

---

6. Made in Abyss (2017)

Personagens

• Riko

• Reg

• Nanachi

Sinopse

Uma menina desce ao maior abismo já descoberto.

Resumo

Começa como aventura infantil.

Termina como uma experiência emocional devastadora.

Dica Bellacosa

💀 NUNCA EXECUTE DESCIDA EM PRODUÇÃO SEM PROCEDIMENTO DE RETORNO.

---

7. Another (2012)

Personagens

• Kouichi Sakakibara

• Mei Misaki

Sinopse

Uma turma escolar sofre uma maldição mortal.

Resumo

Mistério e horror sobrenatural.

Mortes memoráveis e atmosfera constante de tensão.

Dica Bellacosa

⚡ EXISTE UM REGISTRO FANTASMA NA BASE DE DADOS.

---

8. Boogiepop wa Warawanai (2019)

Personagens

• Boogiepop

• Touka Miyashita

Sinopse

Eventos sobrenaturais começam a ocorrer entre estudantes.

Resumo

Narrativa fragmentada e extremamente inteligente.

Cada episódio adiciona peças ao quebra-cabeça.

Dica Bellacosa

🧠 O ERRO NÃO ESTÁ NO PROGRAMA. ESTÁ NA FORMA COMO VOCÊ ESTÁ INTERPRETANDO O LOG.

---

9. Steins;Gate (2011)

Personagens

• Rintarou Okabe

• Kurisu Makise

• Mayuri Shiina

Sinopse

Um grupo de amigos descobre acidentalmente como alterar linhas do tempo.

Resumo

Mistério, ficção científica e viagens temporais.

Possui uma das construções narrativas mais famosas dos animes.

Dica Bellacosa

⏳ NÃO EXECUTE UPDATE NA LINHA TEMPORAL SEM BACKUP.

---

10. Heavenly Delusion (Tengoku Daimakyou) (2023)

Personagens

• Maru

• Kiruko

Sinopse

Dois jovens viajam por um Japão pós-apocalíptico.

Resumo

Mistura sobrevivência, mistério e revelações chocantes.

Possui várias semelhanças estruturais com School-Live.

Dica Bellacosa

🚨 O MUNDO EXTERNO ESTÁ CORROMPIDO, MAS O DATACENTER INTERNO PODE SER AINDA MAIS ASSUSTADOR.

---

Ranking Bellacosa de "Explodir a Cabeça"

🥇 Serial Experiments Lain
🥈 Shinsekai Yori
🥉 Madoka Magica
🏅 Higurashi
🏅 School-Live
🏅 Ergo Proxy
🏅 Heavenly Delusion
🏅 Steins;Gate
🏅 Made in Abyss
🏅 Boogiepop

Status Final do Operador

☕ Sanidade: DEGRADANDO

🧠 Processamento Cognitivo: 99%

⚠️ Realidade: NÃO CONFIÁVEL

💣 Revelações Traumáticas: AGENDADAS

🚨 Recomenda-se assistir um anime leve entre cada um destes títulos para evitar sobrecarga do subsistema emocional.

 

Bellacosa Mainframe e o antropomorfismo em anime

🐾✨ Antropomorfismo Moe em Anime & Mangá

Quando objetos… ganham orelhas fofas e sentimentos?

Se você já assistiu a um anime e pensou:

“Por que essa nave espacial tem cara de menininha kawaii?”
…bem-vindo ao maravilhoso mundo do antropomorfismo moe.

---

💖 O que é antropomorfismo moe?

Vamos por partes:

• Antropomorfismo = dar características humanas a algo não humano

• Moe = aquela sensação de fofura que faz o coração dar um mortal carpado

Coloque os dois juntos e temos:

Transformar conceitos, animais, armas, comida, softwares e até ondas sonoras em personagens fofos
(às vezes com orelhas de gato, às vezes com uniforme escolar — porque claro)

---

🧬 De onde veio isso?

Embora personagens humanizados existam há séculos, o moe antropomórfico ganhou força com:

✅ Mascotes japoneses (sim, até prefeitura tem mascote
✅ Games de estratégia com “waifus” baseadas em nações
✅ Fandoms que personificam o que amam
✅ A indústria percebendo: isso vende muito merch

Resultado: o Japão decidiu olhar para qualquer objeto e pensar:

“E se fosse uma garota fofa?”

---

🎮 Exemplos icônicos

Aqui a criatividade não tem limites:

Tema	Anime/Jogo/Conceito	Por que funciona?
Navios de guerra	Kantai Collection	Ironia + estética militar moe
Países	Hetalia	Estereótipos → comédia e fofura
Armas, tanques	Girls und Panzer	Guerra + fofura = caos controlado
Computadores/OS	OS-tan	Meme que virou franquia
Animais	Kemono Friends	Educação + carisma

E quando digo que qualquer coisa pode virar waifu, estou falando sério:
⚡ Eletricidade moe
🌡️ Estações do ano moe
🍞 Pão moe
🦠 Até vírus moe já rolou

O limite é a imaginação (e a loja de figures).

---

😂 Por que isso é tão engraçado e viciante?

• Mistura contraste + absurdo

• Cria empatia por coisas aleatórias

• Gera nichos e fandoms enormes

• É meme-friendly (muito)

• Fofura = dopamina gratuita

Psicologicamente, o moe convida ao cuidado.
Então ver uma fragil girl representando… um encouraçado?

Essa dissonância é justamente o encanto.

---

🧩 Tipos comuns de antropomorfismo moe

1️⃣ Kemonomimi (humanos com traços de animais — orelhinhas 😺)
2️⃣ Mecha-musume (equipamentos militares “garotificados”)
3️⃣ Gijinka (qualquer objeto/conceito transformado em humano)

Se dá para colocar acessório fofo → já é moe suficiente.

---

🔍 Dicas para reconhecer (e aproveitar)

• Preste atenção no design: cores e símbolos do objeto original continuam ali

• Veja como o anime justifica a transformação

• Repare na personalidade:

  • Arma → tsundere 🗡️

  • Animal → energética 🐾

  • Objeto cotidiano → tímida e desastrada 🍞😖

E claro: quanto mais absurdo, mais divertido.

---

🗣️ Comentários finais do narrador

O antropomorfismo moe é um reflexo perfeito do otaku-verso:

A gente vê personalidade e fofura em tudo.
E quando não tem… a gente cria 😌

Anime diz:
“Esse tanque de guerra… poderia ser uma garota fofa.”
E nós respondemos:
“Sim, quero três figures dela na minha estante.”

A Biblioteca da Sociedade Digital

Bellacosa Mainframe e a biblioteca da sociedade digital

☕ Um Café no Bellacosa Mainframe

A Biblioteca da Sociedade Digital

Os Livros Que Todo Programador COBOL Padawan Deveria Ler Para Entender Psicologia, Sociologia, Poder, Algoritmos e a Natureza Humana

"Quem entende apenas computadores programa máquinas. Quem entende pessoas compreende por que as máquinas foram construídas daquela maneira."

---

Introdução

Durante esta série conversamos sobre alguns dos temas mais importantes da sociedade moderna.

• Economia da Atenção

• Redes Sociais

• Algoritmos

• Inteligência Artificial

• Psicologia das Massas

• Poder

• Conformidade

• Beleza

• Censura

• Narrativas

• Liberdade

• Liderança

A pergunta natural é:

Por onde continuar estudando?

A resposta está nos grandes autores que moldaram a Psicologia, a Sociologia, a Filosofia Política e a Economia Comportamental.

Esta é uma biblioteca comentada para quem deseja compreender o século XXI.

---

Psicologia

Daniel Kahneman — Rápido e Devagar: Duas Formas de Pensar

Talvez o livro mais importante para entender por que seres humanos tomam decisões irracionais.

Você aprenderá:

• Sistema 1 e Sistema 2

• vieses cognitivos

• heurísticas

• erros de julgamento

Ideal para entender: algoritmos, redes sociais e comportamento humano.

⭐⭐⭐⭐⭐

---

Robert Cialdini — As Armas da Persuasão

Um clássico absoluto.

Explica como somos influenciados diariamente.

Você descobrirá princípios como:

• reciprocidade

• autoridade

• escassez

• prova social

• compromisso

Ideal para entender marketing, política e influência digital.

⭐⭐⭐⭐⭐

---

Jonathan Haidt — A Mente Moralista

Por que pessoas inteligentes chegam a conclusões completamente diferentes?

Haidt mostra que emoções frequentemente vêm antes da razão.

Fundamental para entender polarização política.

⭐⭐⭐⭐⭐

---

Leon Festinger — A Theory of Cognitive Dissonance

Obra clássica da Psicologia Social.

Explica por que justificamos nossas próprias contradições.

Depois de lê-lo você nunca mais verá discussões da mesma forma.

⭐⭐⭐⭐⭐

---

Philip Zimbardo — O Efeito Lúcifer

Como pessoas comuns podem praticar atos extraordinariamente cruéis?

Uma profunda reflexão sobre contexto, papéis sociais e poder.

---

Viktor Frankl — Em Busca de Sentido

Talvez o maior livro já escrito sobre propósito humano.

Mostra que significado pode ser mais importante do que conforto.

---

Sociologia

Pierre Bourdieu — A Distinção

Livro fundamental para compreender:

• capital cultural

• capital social

• capital simbólico

• reprodução das elites

Depois dele, luxo nunca mais parecerá apenas luxo.

---

Zygmunt Bauman — Modernidade Líquida

Explica por que tudo parece temporário.

Empregos.

Relacionamentos.

Carreiras.

Identidades.

---

Erving Goffman — A Representação do Eu na Vida Cotidiana

As redes sociais parecem uma atualização moderna deste livro.

Goffman descreve a vida como um palco.

Instagram praticamente confirmou sua teoria.

---

Émile Durkheim — As Regras do Método Sociológico

Base da sociologia moderna.

Explica como instituições moldam comportamentos.

---

Max Weber — Economia e Sociedade

Autoridade.

Burocracia.

Legitimidade.

Estado.

Talvez ninguém tenha explicado melhor como organizações funcionam.

---

Filosofia Política

Hannah Arendt — Origens do Totalitarismo

Leitura obrigatória para compreender autoritarismo e fragilidade das instituições.

---

Karl Popper — A Sociedade Aberta e Seus Inimigos

Uma defesa da democracia liberal baseada no pensamento crítico.

Aqui nasce o famoso Paradoxo da Tolerância.

---

Alexis de Tocqueville — A Democracia na América

Mesmo escrito no século XIX continua surpreendentemente atual.

Mostra virtudes e riscos das democracias.

---

John Stuart Mill — Sobre a Liberdade

Um dos maiores clássicos sobre liberdade de expressão.

Continua sendo leitura essencial.

---

Poder

Michel Foucault — Vigiar e Punir

Talvez o livro mais influente sobre poder no século XX.

Você passará a enxergar instituições de maneira diferente.

---

Antonio Gramsci — Cadernos do Cárcere

Explica hegemonia cultural.

Independentemente da posição política do leitor, sua influência intelectual é enorme.

---

Niccolò Maquiavel — O Príncipe

Frequentemente mal interpretado.

Não ensina apenas como conquistar poder.

Ensina como ele funciona.

---

Economia Comportamental

Richard Thaler — Nudge

Como pequenas mudanças alteram grandes decisões.

Leitura fascinante.

---

Dan Ariely — Previsivelmente Irracional

Mostra que nossa irracionalidade segue padrões.

Excelente introdução à economia comportamental.

---

Comunicação

Marshall McLuhan — Os Meios de Comunicação Como Extensões do Homem

A frase "o meio é a mensagem" nasceu aqui.

Hoje faz ainda mais sentido.

---

Neil Postman — Divertindo-nos Até a Morte

Escrito antes da internet.

Mesmo assim parece prever as redes sociais.

Impressionante.

---

Psicologia das Massas

Gustave Le Bon — Psicologia das Massas

Apesar da idade da obra, continua importante para compreender comportamento coletivo.

---

René Girard — A Violência e o Sagrado

Introduz o conceito de desejo mimético.

Depois dele você compreenderá influência de outra maneira.

---

Inteligência Artificial

Stuart Russell & Peter Norvig — Artificial Intelligence: A Modern Approach

A "bíblia" da IA.

Leitura técnica.

---

Max Tegmark — Vida 3.0

Discute os impactos futuros da Inteligência Artificial.

Excelente ponte entre tecnologia e filosofia.

---

Economia da Atenção

Shoshana Zuboff — A Era do Capitalismo de Vigilância

Provavelmente o livro mais importante sobre Big Tech.

Explica como dados se tornaram matéria-prima econômica.

---

Nir Eyal — Hooked

Mostra como aplicativos criam hábitos.

Leitura indispensável para entender o design das plataformas digitais.

---

Redes Sociais

Jaron Lanier — Dez Argumentos Para Você Deletar Agora Suas Redes Sociais

Mesmo que você não concorde com todas as conclusões, é uma leitura provocativa.

---

Jonathan Haidt — A Geração Ansiosa

Analisa possíveis relações entre smartphones, redes sociais e saúde mental de crianças e adolescentes, discutindo evidências e limitações.

---

A Grande Conclusão

Curiosamente, quase nenhum desses livros fala sobre Instagram.

TikTok.

ChatGPT.

YouTube.

Ou Inteligência Artificial Generativa.

Mesmo assim, todos ajudam a explicar o mundo atual.

Porque a tecnologia mudou.

O cérebro humano mudou muito pouco.

Continuamos sendo movidos por:

• pertencimento;

• medo;

• desejo;

• reconhecimento;

• status;

• curiosidade;

• identidade;

• significado.

Os algoritmos apenas encontraram uma forma extraordinariamente eficiente de conversar com essas características.

Talvez a maior descoberta desta série seja perceber que compreender a sociedade digital exige muito mais do que aprender programação.

Exige compreender pessoas.

E talvez exista uma última ironia.

Quanto mais Inteligência Artificial criamos...

Mais importante se torna estudar aquilo que continua exclusivamente humano.

Psicologia.

Sociologia.

Filosofia.

História.

Porque computadores processam dados.

Mainframes processam milhões de transações por segundo.

Mas somente seres humanos atribuem significado ao mundo.

E, no fim, são os significados — e não apenas os algoritmos — que movem as civilizações.

Low-Code: O Que Todo Programador COBOL Precisa Saber Você Não Está Sendo Substituído.

 

Bellacosa Mainframe e o low-code para o mundo mainframe

☕ Um Café no Bellacosa Mainframe

Low-Code: O Que Todo Programador COBOL Precisa Saber

Você Não Está Sendo Substituído. Está Ganhando Mais uma Ferramenta para Construir Soluções.

"Toda geração acredita que encontrou a tecnologia que acabará com o desenvolvimento tradicional. Até descobrir que software continua sendo engenharia."

---

Introdução

Durante décadas ouvimos promessas parecidas.

Primeiro foi o CASE.

Depois vieram os geradores automáticos.

Em seguida os Frameworks.

Logo apareceram os CMS.

Depois os ERPs prometendo eliminar programação.

Mais tarde surgiram as plataformas BPM.

Então veio o No-Code.

Agora o assunto da vez é o Low-Code.

Sempre aparece alguém dizendo:

"Agora ninguém mais precisará programar."

O curioso é que o número de desenvolvedores no mundo nunca foi tão grande.

Por quê?

Porque a demanda por software cresce mais rápido do que qualquer tecnologia consegue simplificar.

Para quem trabalha com IBM Z, COBOL, CICS, DB2 e z/OS, entender Low-Code não significa abandonar décadas de experiência.

Significa entender onde essa tecnologia realmente funciona.

E onde ela não funciona.

---

O que é Low-Code?

Low-Code é uma abordagem de desenvolvimento baseada em componentes visuais.

Em vez de escrever milhares de linhas de código manualmente, o desenvolvedor monta aplicações através de:

• componentes prontos

• fluxos visuais

• formulários

• regras de negócio

• integrações

• conectores

• workflows

A plataforma gera automaticamente boa parte do código.

Isso não significa ausência de programação.

Normalmente existe código.

Muito código.

Só que parte dele é gerado automaticamente.

Por isso o nome:

Low-Code

e não

No-Code.

---

A diferença entre Low-Code e No-Code

Embora muita gente use como sinônimos, são conceitos diferentes.

No-Code

Destinado para usuários de negócio.

Exemplos:

• RH

• Marketing

• Financeiro

• Comercial

O objetivo é permitir criar aplicações sem escrever código.

---

Low-Code

Voltado para desenvolvedores.

Permite:

• escrever código quando necessário

• criar componentes próprios

• consumir APIs

• acessar bancos

• integrar sistemas

• customizar regras

Ou seja:

continua sendo engenharia de software.

---

Como surgiu o Low-Code?

Na verdade, a ideia é muito mais antiga do que parece.

Se voltarmos aos anos 80 veremos ferramentas como:

• PowerBuilder

• Delphi

• Visual Basic

• Oracle Forms

• IBM VisualAge

• Gupta SQLWindows

Todas possuíam:

• drag-and-drop

• componentes visuais

• geração automática de código

Hoje chamaríamos isso de Low-Code.

A diferença é que atualmente as plataformas são orientadas para:

• Cloud

• APIs

• Mobile

• Microsserviços

• Containers

• IA

Ou seja,

o conceito é antigo.

A infraestrutura mudou.

---

Linha do tempo

Década de 1980

Programação visual.

CASE.

Geradores de código.

RAD (Rapid Application Development).

---

Década de 1990

Visual Basic.

Delphi.

PowerBuilder.

Oracle Forms.

Lotus Notes.

---

Década de 2000

SOA.

BPM.

Workflow.

Ferramentas corporativas.

---

Década de 2010

Cloud.

Mobile.

APIs REST.

Low-Code moderno.

---

Década de 2020

IA Generativa.

Copilots.

Modelagem automática.

Assistentes inteligentes.

Low-Code + IA.

---

O objetivo nunca foi eliminar programadores

Essa é talvez a maior confusão.

Imagine um arquiteto.

Hoje existem softwares que desenham plantas automaticamente.

Isso eliminou arquitetos?

Não.

Apenas aumentou sua produtividade.

O mesmo ocorre aqui.

Low-Code automatiza tarefas repetitivas.

Quem continua decidindo arquitetura é o desenvolvedor.

---

Como funciona internamente?

Quase todas as plataformas seguem a mesma arquitetura.

Usuário

↓

Designer Visual

↓

Modelo da Aplicação

↓

Gerador de Código

↓

Compilação

↓

Banco

↓

Servidor

↓

Aplicação Executando

O desenvolvedor manipula um modelo.

A plataforma transforma esse modelo em código.

---

Quais problemas o Low-Code resolve?

Principalmente:

• desenvolvimento lento

• escassez de desenvolvedores

• excesso de sistemas internos

• necessidade de digitalização

• automação de processos

• criação rápida de protótipos

Imagine um departamento de RH precisando aprovar férias.

Não faz sentido iniciar um projeto de 8 meses.

Uma plataforma Low-Code resolve isso em dias.

---

Onde o Low-Code é excelente?

Sistemas internos

• RH

• Compras

• Financeiro

• Aprovação

---

Dashboards

Indicadores.

KPIs.

Relatórios.

---

Formulários

Cadastro.

Pesquisa.

Solicitações.

---

Workflow

Fluxos de aprovação.

---

Aplicativos móveis

Aplicações simples.

---

Portais

Intranet.

Extranet.

Atendimento.

---

Onde ele não é indicado?

Nem tudo deve ser feito em Low-Code.

Exemplos:

• motores bancários

• processamento de cartões

• compensação financeira

• sistemas de bolsa

• processamento em massa

• compiladores

• sistemas operacionais

• bancos de dados

• kernels

Nesses casos,

o controle fino importa.

---

Performance

Uma pergunta comum.

Low-Code é lento?

Resposta:

Depende.

Um formulário simples?

Praticamente igual.

Um workflow?

Excelente.

Mas aplicações extremamente críticas normalmente exigem código especializado.

Por quê?

Porque uma plataforma genérica precisa atender milhares de cenários.

Código manual pode ser otimizado especificamente.

---

O impacto na arquitetura

Antes:

Cliente

↓

Aplicação

↓

Banco

Hoje:

Cliente

↓

Portal Low-Code

↓

API

↓

Microsserviços

↓

Mainframe

↓

DB2

Perceba algo importante.

O Mainframe continua existindo.

Ele apenas deixa de conversar diretamente com o usuário.

---

Low-Code e APIs

Aqui está o ponto de encontro com IBM Z.

O Low-Code praticamente vive de APIs.

Quem fornece essas APIs?

Frequentemente:

• COBOL

• CICS

• IMS

• DB2

• MQ

• z/OS Connect

Ou seja,

o Mainframe passa a ser o motor.

O Low-Code apenas cria a interface.

---

O papel do COBOL muda?

Sim.

Mas não desaparece.

Antes:

COBOL fazia:

• tela

• regra

• banco

Hoje:

COBOL concentra-se em:

• regra de negócio

• segurança

• consistência

• transações

Enquanto o Low-Code faz:

• telas

• formulários

• dashboards

• workflow

É uma separação saudável.

---

Principais vantagens

Desenvolvimento rápido

Dias em vez de meses.

---

Menos código repetitivo

CRUD praticamente automático.

---

Padronização

Todas as aplicações seguem o mesmo modelo.

---

Facilidade de manutenção

Mudanças visuais são simples.

---

Integração

APIs.

SOAP.

REST.

MQ.

SQL.

LDAP.

OAuth.

---

Reutilização

Componentes podem ser usados diversas vezes.

---

Os riscos

Nem tudo são flores.

Vendor Lock-in

Talvez seja o maior problema.

Sua aplicação depende da plataforma.

Trocar depois pode ser caro.

---

Código gerado

Nem sempre é elegante.

Às vezes gera excesso de processamento.

---

Limitações

Quando surge algo muito específico,

a plataforma pode não suportar.

---

Licenciamento

Grandes plataformas costumam ser caras.

---

Performance

Em aplicações extremamente críticas,

código especializado costuma vencer.

---

As boas práticas

Modele antes

Não saia criando telas.

Desenhe processos.

---

Use APIs

Nunca acesse diretamente sistemas legados.

---

Centralize regras

A regra deve permanecer no backend.

Nunca na interface.

---

Versione

Mesmo sendo visual.

Use Git.

---

Automatize testes

Aplicações visuais também precisam de testes.

---

Documente integrações

Principalmente contratos REST.

---

Passo a passo para criar uma aplicação Low-Code

1. Entenda o processo

Mapeie:

• entradas

• saídas

• aprovações

---

2. Modele dados

Clientes.

Pedidos.

Produtos.

Usuários.

---

3. Crie formulários

Cadastro.

Consulta.

Pesquisa.

---

4. Configure regras

Quem pode aprovar?

Quem pode editar?

---

5. Integre APIs

REST.

SOAP.

MQ.

Banco.

---

6. Teste

Validação.

Carga.

Segurança.

---

7. Publique

Cloud.

On-premises.

Containers.

---

8. Monitore

Logs.

Performance.

Auditoria.

---

Principais metodologias utilizadas

Agile

Scrum.

Kanban.

Sprints curtas.

---

DevOps

CI/CD.

Deploy automático.

---

Domain Driven Design

Separação por domínio.

---

BPM

Modelagem de processos.

---

BPMN

Fluxos de negócio.

---

Design Thinking

Descoberta do problema.

---

UX

Experiência do usuário.

---

API First

Tudo começa pela API.

---

As principais plataformas Low-Code

O mercado amadureceu muito nos últimos anos e hoje existem dezenas de plataformas. Algumas são focadas em pequenas empresas; outras suportam ambientes corporativos gigantescos, incluindo integração com IBM Z.

Microsoft Power Apps

Talvez seja a plataforma mais conhecida atualmente.

Pontos fortes:

• integração com Microsoft 365

• SharePoint

• Dynamics

• Azure

• Power Automate

• Dataverse

Muito usada em departamentos internos.

---

Mendix

Uma das líderes mundiais.

Hoje pertence à Siemens.

Muito forte em aplicações corporativas complexas.

Possui excelentes recursos para integração com APIs REST e SOAP.

---

OutSystems

Bastante conhecida entre bancos, seguradoras e grandes empresas.

Possui:

• desenvolvimento web

• mobile

• DevOps integrado

• monitoramento

• escalabilidade

É uma das plataformas mais maduras do mercado.

---

Appian

Extremamente forte em:

• BPM

• Workflow

• Automação

• Processos empresariais

Muito utilizada em governos e instituições financeiras.

---

Salesforce Platform

Voltada para aplicações em torno do ecossistema Salesforce.

Excelente quando toda a empresa já utiliza CRM Salesforce.

---

ServiceNow

Originalmente voltada para ITSM.

Hoje permite desenvolver inúmeras aplicações corporativas.

---

Oracle APEX

Muito respeitada entre desenvolvedores Oracle.

Rápida.

Estável.

Excelente para aplicações baseadas em banco Oracle.

---

IBM Business Automation Workflow

A IBM também investe nesse segmento.

Especialmente para processos corporativos.

Integra naturalmente com:

• IBM MQ

• CICS

• DB2

• IBM Z

---

Low-Code e Inteligência Artificial

A IA acelerou ainda mais esse mercado.

Hoje diversas plataformas conseguem:

• criar formulários automaticamente

• gerar consultas SQL

• sugerir telas

• criar APIs

• escrever validações

• documentar aplicações

Mas existe um detalhe.

A IA produz software.

Quem produz arquitetura continua sendo o engenheiro.

---

O impacto no ambiente Mainframe

Agora chegamos ao ponto mais importante para quem trabalha com COBOL.

Existe um mito recorrente:

"Se a empresa adotar Low-Code, o Mainframe desaparecerá."

Na prática acontece exatamente o contrário.

Quanto mais empresas investem em transformação digital, mais precisam acessar os sistemas que realmente armazenam os dados de negócio. Em bancos, seguradoras, operadoras de saúde, companhias aéreas e órgãos públicos, esses dados continuam majoritariamente em aplicações COBOL executando no IBM Z.

O Low-Code normalmente não substitui esse núcleo. Ele cria uma camada de experiência para o usuário.

Uma arquitetura moderna costuma seguir este fluxo:

Aplicativo Web ou Mobile
        │
        ▼
Plataforma Low-Code
        │
        ▼
API Gateway
        │
        ▼
z/OS Connect / API REST
        │
        ▼
CICS / IMS / MQ
        │
        ▼
Programas COBOL
        │
        ▼
DB2 / VSAM / IMS DB

Nesse cenário, o COBOL deixa de cuidar da interface gráfica e concentra seus esforços onde ele sempre foi excepcional:

• regras de negócio;

• integridade transacional;

• processamento de alto volume;

• consistência de dados;

• disponibilidade contínua.

Enquanto isso, a plataforma Low-Code entrega:

• formulários modernos;

• portais web;

• aplicativos móveis;

• dashboards;

• fluxos de aprovação;

• integrações com serviços externos.

Essa separação de responsabilidades reduz o acoplamento e facilita a evolução dos sistemas.

Novas responsabilidades para o desenvolvedor COBOL

O profissional de Mainframe tende a atuar menos como "programador de telas" e mais como especialista em serviços.

Isso significa dominar conceitos como:

• APIs REST;

• JSON;

• OpenAPI/Swagger;

• OAuth e autenticação;

• mensageria com IBM MQ;

• integração via z/OS Connect;

• versionamento de contratos;

• observabilidade e monitoramento.

O conhecimento do negócio continua sendo o maior diferencial. Uma plataforma Low-Code pode gerar uma interface em minutos, mas não conhece as regras de crédito, tributação, previdência, seguros ou compensação bancária que estão consolidadas em décadas de código COBOL.

Oportunidades profissionais

Para quem trabalha com IBM Z, o crescimento do Low-Code abre novas possibilidades:

• atuar como arquiteto de integração;

• expor aplicações COBOL como APIs;

• modernizar sistemas legados sem reescrevê-los;

• integrar Mainframe com nuvem e aplicações móveis;

• liderar iniciativas de transformação digital.

Em vez de competir com o Low-Code, o desenvolvedor COBOL pode tornar-se a peça central que conecta o legado confiável às novas interfaces de negócio.

Conclusão

Low-Code não é uma moda passageira nem a solução para todos os problemas. É mais uma etapa da evolução da engenharia de software.

Assim como o Delphi acelerou o desenvolvimento desktop, o Visual Basic simplificou aplicações Windows e os frameworks web reduziram código repetitivo, as plataformas Low-Code automatizam tarefas de baixo valor para que os desenvolvedores concentrem seu tempo naquilo que realmente importa: arquitetura, regras de negócio, segurança, integração e desempenho.

Para o profissional de Mainframe, a mensagem é especialmente positiva. O IBM Z continua sendo o ambiente onde executam algumas das aplicações mais críticas do planeta. O que muda é a forma como essas aplicações são consumidas. Em vez de telas verdes acessadas diretamente, elas passam a atender portais, aplicativos móveis e plataformas Low-Code por meio de APIs e serviços.

O futuro não será de COBOL ou Low-Code.

Será de COBOL com Low-Code, APIs, IA, DevOps e integração em nuvem, formando um ecossistema onde cada tecnologia desempenha o papel para o qual foi projetada.

No fim, a tecnologia muda, as interfaces evoluem e as ferramentas se renovam. Mas um princípio permanece inalterado desde os primeiros dias da computação: software crítico continua dependendo de boa engenharia. E essa continua sendo a principal especialidade de quem desenvolve soluções para o IBM Z.

 

Bellacosa Mainframe em um visao do dbb e zbuilder

☕ DBB e zBuilder: Os Jedi Invisíveis da Modernização IBM Z   

Quando a Galáxia Fala de IA, OpenShift e APIs, Mas Esquece Quem Realmente Constrói o Sabre de Luz

Por Vagner Bellacosa – Bellacosa Mainframe

Existe uma cena recorrente no universo da tecnologia corporativa contemporânea.

Um executivo sobe ao palco de um grande evento. Atrás dele aparecem imagens futuristas de nuvens híbridas, containers rodando em OpenShift, dashboards coloridos alimentados por Inteligência Artificial Generativa, modelos LLM analisando código COBOL e APIs REST conectando sistemas legados a aplicativos móveis.

A plateia aplaude.

Os fornecedores sorriem.

Os analistas produzem relatórios.

Os CIOs aprovam investimentos milionários.

E, em algum canto silencioso de um datacenter refrigerado, um desenvolvedor COBOL continua aguardando que alguém compile seu programa utilizando um processo criado quando Ronald Reagan ainda era presidente dos Estados Unidos.

Talvez seja exatamente aí que esteja um dos maiores paradoxos da modernização do Mainframe.

Todos querem modernizar aplicações.

Poucos querem modernizar a engenharia que produz essas aplicações.

E talvez seja por isso que IBM Dependency Based Build (DBB) e zBuilder continuem sendo duas das tecnologias mais importantes, poderosas e menos discutidas do ecossistema IBM Z.

A Modernização que o Mercado Enxerga

Quando falamos em transformação digital associada ao Mainframe, normalmente escutamos frases semelhantes a estas:

"Precisamos expor COBOL como APIs."

"Vamos colocar CICS atrás de um API Gateway."

"Devemos integrar IBM Z ao OpenShift."

"Precisamos utilizar IA Generativa para entender programas legados."

"Vamos migrar workloads para a nuvem híbrida."

Tudo isso possui valor.

Tudo isso representa avanços importantes.

Mas existe uma pergunta quase filosófica que raramente aparece nas apresentações corporativas.

Como essas aplicações são construídas hoje?

A resposta costuma ser desconfortável.

Em muitas organizações ainda encontramos processos semelhantes a este:

Desenvolvedor altera programa COBOL.

↓

Salva em um PDS.

↓

Executa compile manual.

↓

Submete JCL.

↓

Espera aprovação.

↓

Abre chamado.

↓

Aguarda CAB.

↓

Equipe operacional promove.

↓

Produção.

Se substituirmos COBOL por Java, Python ou Go, provavelmente qualquer desenvolvedor moderno consideraria esse fluxo algo retirado de um museu de informática.

No entanto, em centenas de empresas ao redor do mundo, essa ainda é a realidade operacional.

Enquanto equipes cloud utilizam GitHub Actions, GitLab Pipelines, ArgoCD, Tekton e GitOps, muitos ambientes z/OS permanecem dependentes de mecanismos desenvolvidos em uma época em que a palavra DevOps sequer existia.

O Mainframe Não Precisa Ser Modernizado. A Engenharia Sim.

Esta talvez seja a primeira provocação importante deste artigo.

O IBM Z já é extremamente moderno.

Executa Linux.

Possui aceleração para IA.

Executa containers.

Suporta APIs.

Possui criptografia embarcada.

Disponibiliza telemetria avançada.

Integra-se com Kubernetes.

Suporta OpenShift.

Conecta-se com praticamente qualquer ecossistema corporativo.

O problema raramente está na plataforma.

O problema está na forma como produzimos software para essa plataforma.

Em outras palavras:

Não basta transformar programas COBOL em APIs.

Precisamos transformar desenvolvedores Mainframe em engenheiros de software do século XXI.

IBM DBB: O Maven que Nasceu em z/OS

IBM Dependency Based Build surgiu justamente para resolver esse problema.

Muitas pessoas imaginam que DBB seja apenas um mecanismo de compilação.

Na prática, ele é muito mais do que isso.

DBB representa uma mudança conceitual profunda.

Historicamente, ambientes Mainframe trabalhavam com builds completos.

Alterou um copybook?

Compila tudo.

Mudou uma tabela?

Compila tudo.

Atualizou uma rotina compartilhada?

Compila tudo.

Imagine um banco contendo dois mil programas COBOL.

Um único COPY chamado CLIENTE é utilizado em mil e duzentos programas.

Uma alteração de dois bytes nesse copybook pode disparar uma compilação massiva.

Horas de processamento.

Centenas de datasets temporários.

JES2 congestionado.

Fila de builds aumentando.

DBB muda completamente essa lógica.

Ele constrói um grafo de dependências.

Algo semelhante ao que Maven, Gradle ou Bazel fazem há anos no mundo distribuído.

O DBB entende que:

CLIENTE

é utilizado por

COB001

COB017

COB105

COB221

COB998

Logo, apenas esses componentes precisam ser recompilados.

O ganho operacional pode ser gigantesco.

Horas podem transformar-se em minutos.

Dias podem transformar-se em horas.

O Encanamento que Ninguém Mostra no LinkedIn

Existe uma razão interessante para DBB receber relativamente pouca atenção.

Ferramentas de build são invisíveis.

Ninguém publica uma foto dizendo:

"Olhem meu maravilhoso sistema hidráulico."

As pessoas mostram a piscina.

Mostram a fachada.

Mostram o jardim.

DBB é o encanamento.

Sem ele, a casa não funciona.

Mas dificilmente aparece na propaganda.

Executivos não compram compiladores.

Executivos compram redução de risco.

Compram velocidade.

Compram governança.

Compram previsibilidade.

Compram auditoria.

Compram produtividade.

DBB entrega exatamente isso.

O Desafio do Groovy

Historicamente, muitas implementações DBB foram construídas utilizando Groovy.

Algo como:

buildProgram("COB001")

compile()

link()

package()

Para equipes acostumadas ao universo z/OS isso pode ser aceitável.

Mas estamos vivendo uma nova era.

A era do Platform Engineering.

E Platform Engineers respiram YAML.

Respiram GitOps.

Respiram Infrastructure as Code.

Respiram Kubernetes.

Respiram ArgoCD.

Respiram Tekton.

Respiram Ansible.

Respiram pipelines declarativos.

Nesse contexto, surge um novo protagonista.

zBuilder: O YAML Desperta na Força

Talvez zBuilder seja uma das iniciativas mais promissoras do ecossistema IBM Z atual.

Sua proposta é elegantemente simples.

Trocar imperatividade por declaratividade.

Trocar scripts complexos por descrições legíveis.

Ao invés de dezenas de linhas em Groovy, podemos imaginar algo semelhante a:

application:

 name: BANKAPP


languages:

 - COBOL
 - PL1
 - JCL



test:

 zunit



deploy:

 cics

Subitamente, o Mainframe começa a falar o mesmo idioma das equipes cloud.

E isso é muito poderoso.

Porque YAML tornou-se praticamente a língua franca da engenharia moderna.

Kubernetes utiliza YAML.

OpenShift utiliza YAML.

GitHub Actions utiliza YAML.

Ansible utiliza YAML.

ArgoCD utiliza YAML.

Crossplane utiliza YAML.

Tekton utiliza YAML.

Terraform possui sintaxe declarativa semelhante.

Platform Engineering gira em torno desse paradigma.

O Surgimento do GitOps Mainframe

Talvez este seja o próximo estágio evolutivo da engenharia IBM Z.

Durante décadas o repositório oficial era um PDS.

Hoje ele pode ser Git.

Antes:

PDS

↓

Compile

↓

Promotion

Agora:

Git

↓

Pull Request

↓

Review

↓

Pipeline

↓

Testes

↓

Security Scan

↓

Deploy

Exatamente igual ao mundo Java.

Exatamente igual ao mundo Python.

Exatamente igual ao universo Go.

Exatamente igual ao desenvolvimento cloud-native.

Isso reduz uma barreira psicológica importante.

O Mainframe deixa de parecer um ambiente exótico.

Passa a parecer apenas mais uma plataforma suportada pelo pipeline corporativo.

DevSecOps Não É Opcional

Durante muitos anos o Mainframe foi considerado seguro por definição.

E, de certa forma, ele realmente é.

RACF.

Criptografia.

Auditoria.

SMF.

Segurança robusta.

Porém, DevSecOps não trata apenas da segurança da plataforma.

Trata da segurança do ciclo de desenvolvimento.

Podemos imaginar pipelines semelhantes a:

Git

↓

DBB

↓

ZUnit

↓

SonarQube

↓

Checkmarx

↓

SBOM

↓

Artifact Repository

↓

Approval

↓

Deploy

Agora COBOL participa das mesmas políticas utilizadas pelo restante da organização.

Existe rastreabilidade.

Existe compliance.

Existe análise estática.

Existe assinatura digital.

Existe inventário de componentes.

Existe governança corporativa.

O Grande Equívoco da Modernização

Talvez o maior erro cometido por algumas organizações seja acreditar que modernização significa abandonar Mainframe.

Na prática, a maior parte dos projetos bem-sucedidos mostra exatamente o oposto.

Modernizar significa aumentar a capacidade de evolução do Mainframe.

Transformá-lo em uma plataforma capaz de competir pela atenção dos novos desenvolvedores.

Se um profissional de vinte e cinco anos consegue utilizar VS Code, GitHub, Pull Request, pipelines automatizados, Zowe, OpenShift e YAML para desenvolver COBOL, a experiência muda completamente.

Ele deixa de enxergar IBM Z como um fóssil tecnológico.

Passa a enxergá-lo como um backend extremamente robusto conectado a práticas modernas.

A Analogia dos Jedi

Talvez DBB e zBuilder possam ser comparados aos técnicos responsáveis por construir os sabres de luz dos Jedi.

Nos filmes, a atenção está sempre voltada para o duelo.

Para a batalha espacial.

Para os poderes da Força.

Pouco se fala sobre os artesãos que produziram as armas.

Mas sem eles não existiria batalha.

Não existiria Ordem Jedi.

Não existiria legado.

DBB e zBuilder desempenham papel semelhante.

Não aparecem em demonstrações de IA.

Não aparecem em apresentações sobre OpenShift.

Não aparecem em propagandas de APIs.

Mas tornam possível algo muito mais importante.

Permitem que a engenharia IBM Z participe plenamente do movimento DevSecOps corporativo.

Considerações Finais

A pergunta original permanece extremamente pertinente.

DBB e zBuilder ainda são subestimados?

Possivelmente sim.

Mas talvez isso esteja começando a mudar.

Estamos observando o surgimento de uma nova geração de profissionais que não deseja apenas integrar Mainframe à nuvem.

Deseja integrar Mainframe à cultura moderna de engenharia.

Quer Git.

Quer pipelines.

Quer automação.

Quer segurança contínua.

Quer observabilidade.

Quer experiência de desenvolvedor.

Quer Platform Engineering.

Quer GitOps.

Quer tratar COBOL exatamente como trata Java, Python ou Go.

Se esse movimento continuar crescendo, talvez daqui a dez anos olhemos para DBB e zBuilder da mesma forma que hoje observamos Git ou Kubernetes.

Ferramentas que inicialmente pareciam apenas componentes técnicos, mas que acabaram redefinindo completamente a maneira como organizações constroem software.

E talvez essa seja a verdadeira modernização do Mainframe.

Não trocar COBOL por outra linguagem.

Não mover aplicações para outro ambiente.

Mas transformar o IBM Z em algo que ele sempre teve potencial para ser:

Uma plataforma de engenharia contínua, capaz de unir a estabilidade de cinquenta anos de missão crítica com a velocidade, automação e governança exigidas pela próxima geração de sistemas corporativos.

Que a Força do Pipeline esteja com vocês.