☕ 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

terça-feira, 20 de outubro de 2020

Como Criar um Roteiro para Mangá

Bellacosa Mainframe e o guia de como criar um manga


Como Criar um Roteiro para Mangá: Guia Completo para Otakus que Querem Ser Mangaka

Se você é fã de mangás e sempre sonhou em criar suas próprias histórias, este post é para você. Transformar uma ideia em um mangá publicado pode parecer difícil, mas com organização, estudo e criatividade, qualquer otaku apaixonado por quadrinhos japoneses pode dar os primeiros passos rumo à carreira de mangaka. Aqui está o guia completo:


1. Entenda a base do mangá

Antes de pegar lápis e papel, é essencial entender a estrutura do mangá:

  • Gêneros: Shonen, Shoujo, Seinen, Josei, Kodomo… Escolha o que você mais se identifica.

  • Narrativa visual: Mangás contam histórias tanto com palavras quanto com imagens. Cada quadro (ou “panel”) precisa transmitir ação, emoção e ritmo.

  • Personagens memoráveis: O coração de qualquer história são personagens fortes, com objetivos, conflitos e personalidade definida.

Curiosidade: Mangás famosos como Naruto ou Attack on Titan começaram com roteiros simples, mas bem estruturados, antes de se tornarem épicos.


2. O que estudar antes de começar

Para criar um roteiro de mangá, você precisa desenvolver três habilidades principais:

  1. Desenho e anatomia

    • Pratique perspectiva, proporção, movimento e expressões faciais.

    • Estude poses dinâmicas — personagens em ação são essenciais para shonen, por exemplo.

  2. Roteiro e narrativa

    • Estude roteiros de mangás que você ama. Observe como a história flui de quadro em quadro.

    • Leia sobre narrativa visual e storytelling; cada cena precisa conduzir a história.

  3. Diálogos e ritmo

    • Frases curtas funcionam melhor nos balões.

    • Espaço entre balões e quadros controla o ritmo da leitura.


3. Como criar seu primeiro roteiro de mangá: passo a passo

Aqui vai um guia prático, perfeito para iniciantes:

Passo 1: Ideia central

  • Qual é a história que você quer contar?

  • Quem é o protagonista? Qual é o conflito principal?

  • Exemplo: “Um garoto encontra um espírito que concede poderes, mas cada desejo tem um preço.”

Passo 2: Estrutura da história

  • Divida em começo, meio e fim.

  • Crie uma lista de eventos importantes: pontos de virada, revelações, clímax.

Passo 3: Crie personagens

  • Nome, idade, aparência, habilidades, fraquezas e objetivos.

  • Personagens secundários são tão importantes quanto os principais para dar profundidade.

Passo 4: Escreva o “name”

  • O “name” é o storyboard inicial do mangá.

  • Use rabiscos simples para mostrar quadros, balões e posições de personagens.

  • Aqui você foca na narrativa, não nos detalhes do desenho final.

Passo 5: Adicione diálogos

  • Coloque balões nos quadrinhos.

  • Revise se os diálogos fazem sentido e mantêm o ritmo.

Passo 6: Revise e teste

  • Leia seu roteiro como se fosse um leitor.

  • Ajuste quadros confusos, diálogos longos ou cenas que não fluem.

Truque de mangaka profissional: sempre tente ler seu roteiro em voz alta, você vai perceber se o ritmo está natural.


4. Dicas e truques para iniciantes

  • Comece pequeno: uma história curta de 10–15 páginas é suficiente para praticar.

  • Use referências: fotos, poses de outros mangás ou sites de stock.

  • Participe de comunidades online como Pixiv, Reddit ou Discord para receber feedback.

  • Experimente ferramentas digitais como Clip Studio Paint ou Krita, que têm recursos para mangá.


5. Curiosidades do mundo dos roteiros de mangá

  • Alguns mangakas escrevem roteiros totalmente no computador, outros ainda preferem papel e lápis.

  • Assistentes muitas vezes ajudam a finalizar fundos, cenários e detalhes repetitivos.

  • Mangás populares começaram com one-shots (histórias únicas) para testar a aceitação do público.


6. Próximos passos para se tornar mangaka

  1. Faça seu portfólio com histórias curtas e roteiros completos.

  2. Participe de concursos de editoras ou publique online em plataformas como Webtoon, MangaPlus ou Pixiv.

  3. Construa uma presença online mostrando seu trabalho.

  4. Continue estudando, desenhando e testando novas ideias.

Lembre-se: persistência é tudo. Até os grandes mangakas começaram com pequenos projetos e muitos erros.

100-man no Inochi no Ue ni Ore wa Tatteiru : Quando um Programador COBOL Descobre que um Job em Produção Pode Afetar Um Milhão de Usuários...

 

Belllacosa Mainframe apresenta 100-man no inochi no ue ni ore wa tatteiru

☕ Um Café no Bellacosa Mainframe

100-man no Inochi no Ue ni Ore wa Tatteiru (100万の命の上に俺は立っている) sem Mistérios

Quando um Programador COBOL Descobre que um Job em Produção Pode Afetar Um Milhão de Usuários... e Não Existe ROLLBACK para Algumas Decisões


Introdução

Imagine que você recebe um chamado às três da manhã.

O sistema bancário caiu.

Você pode corrigir rapidamente o problema...

...ou gastar mais tempo encontrando uma solução definitiva.

A primeira opção salva o dia.

A segunda pode salvar anos de operação.

Essa é exatamente a filosofia de 100-man no Inochi no Ue ni Ore wa Tatteiru (I'm Standing on a Million Lives).

Embora seja vendido como mais um isekai, ele está muito mais próximo de um RPG estratégico, um simulador de gerenciamento de crises e um estudo sobre ética e responsabilidade do que de uma fantasia tradicional com protagonista overpower.

Enquanto boa parte dos isekais pergunta:

"Como seria viver em outro mundo?"

Esta obra pergunta algo muito mais desconfortável:

"Quantas pessoas você estaria disposto a sacrificar para salvar milhões?"

Para um programador COBOL acostumado a trabalhar em sistemas que movimentam milhões de transações por dia, a analogia é imediata: uma única decisão incorreta pode gerar um ABEND em cadeia.


Dados da Obra

Título original: 100万の命の上に俺は立っている

Romanização: 100-man no Inochi no Ue ni Ore wa Tatteiru

Título internacional: I'm Standing on a Million Lives

Autor da história: Naoki Yamakawa

Ilustrações: Akinari Nao

Publicação do mangá: Junho de 2016

Revista: Bessatsu Shōnen Magazine (Kodansha)

Anime

  • Estúdio: Maho Film

  • Diretor: Kumiko Habara

  • Composição: Takao Yoshioka

  • Música: Kenji Kawai

  • Temporada 1: outubro a dezembro de 2020

  • Temporada 2: julho a setembro de 2021

Quantidade de episódios

  • Temporada 1: 12

  • Temporada 2: 12

Total: 24 episódios


O Estúdio Maho Film

A Maho Film nasceu em 2018 e rapidamente se especializou em adaptações de light novels e mangás de fantasia.

Entre suas produções estão:

  • I'm Standing on a Million Lives

  • By the Grace of the Gods

  • In the Land of Leadale

  • A Playthrough of a Certain Dude's VRMMO Life

Embora não tenha o orçamento de gigantes como MAPPA, Bones, Madhouse ou Ufotable, o estúdio costuma entregar animações consistentes, com foco na narrativa e na construção dos personagens.

Em 100-man, o destaque está muito mais nas escolhas morais do que em cenas espetaculares de combate.


Sinopse

Yuusuke Yotsuya é um estudante extremamente antissocial.

Ao lado de duas colegas de escola, ele é misteriosamente transportado para um mundo de fantasia.

Lá encontra um ser estranho conhecido apenas como Game Master.

Esse ser informa que eles agora são participantes de um jogo.

Recebem:

  • classes aleatórias

  • níveis

  • objetivos

  • limite de tempo

  • vidas limitadas

Ao concluir uma missão retornam ao Japão.

Dias depois...

são convocados novamente.

Pouco a pouco descobrem que aquele mundo pode ser muito mais real do que imaginavam.


Resumo da História

Inicialmente parece apenas mais um RPG.

Os heróis recebem missões simples.

Eliminar monstros.

Salvar aldeias.

Escoltar pessoas.

Mas conforme novas missões surgem, percebe-se que cada decisão altera profundamente a história daquele mundo.

Eles deixam de ser aventureiros.

Passam a interferir diretamente na política, economia, religião, guerras e sobrevivência de civilizações inteiras.

O que parecia um "jogo" transforma-se em uma responsabilidade gigantesca.


O Grande Diferencial

A maioria dos isekais possui esta estrutura:

Invocação

↓

Recebe poderes absurdos

↓

Forma grupo

↓

Derrota Rei Demônio

100-man segue outra lógica:

Missão

↓

Informações incompletas

↓

Tomada de decisão

↓

Consequências

↓

Nova missão

↓

Consequências ainda maiores

O foco nunca é o poder.

O foco é a responsabilidade.


Personagens

Yuusuke Yotsuya

O protagonista.

Talvez um dos personagens mais controversos do gênero.

Não acredita em justiça.

Não acredita em heroísmo.

Não acredita em sacrifícios desnecessários.

Seu cérebro funciona quase como um algoritmo.

Ele sempre calcula:

  • custo

  • benefício

  • risco

  • probabilidade

  • recursos disponíveis

No universo Bellacosa Mainframe:

"Yotsuya parece executar um EXPLAIN PLAN antes de cada decisão."


Iu Shindou

A heroína tradicional.

Otimista.

Empática.

Sempre tenta salvar todos.

Representa a visão emocional do grupo.


Kusue Hakozaki

Inicialmente insegura.

Medrosa.

Mas cresce durante toda a série.

Mostra que coragem não significa ausência de medo.


Yuka Tokitate

Mais impulsiva.

Questiona frequentemente Yotsuya.

Torna o grupo menos previsível.


Game Master

Provavelmente o personagem mais enigmático da obra.

Jamais explica completamente:

  • quem é

  • de onde veio

  • por que escolheu aqueles estudantes

Quanto mais aparece...

mais perguntas surgem.


Sistema de Classes

Aqui existe uma das ideias mais inteligentes do anime.

As classes são distribuídas aleatoriamente.

Podem ser:

  • Farmer

  • Cook

  • Warrior

  • Archer

  • Magician

  • Chef

  • Hunter

No começo parecem inúteis.

Depois tornam-se essenciais.

É uma excelente metáfora para equipes multidisciplinares.

Nem sempre o profissional mais importante é o mais poderoso.

Às vezes o fazendeiro salva mais vidas que o guerreiro.


As Aventuras

Durante as duas temporadas encontramos:

  • guerras entre reinos

  • dragões

  • trolls

  • missões diplomáticas

  • epidemias

  • conflitos religiosos

  • escravidão

  • corrupção política

  • crises alimentares

  • genocídios

  • dilemas morais

Cada arco parece uma campanha independente de RPG.

Mas todos se conectam.


Temáticas

Ética

Nem toda decisão correta parece boa.

Consequências

Salvar alguém hoje pode provocar milhares de mortes amanhã.

Responsabilidade

O título resume toda a obra.

"Estou sobre um milhão de vidas."

Liderança

Yuusuke lidera porque pensa.

Não porque é o mais forte.

Pragmatismo

Nem sempre existe uma solução perfeita.

Existe apenas a menos ruim.


O que tem de diferente?

Praticamente tudo.

Enquanto muitos protagonistas querem ficar famosos...

Yuusuke quer terminar a missão.

Enquanto muitos querem aumentar de nível...

Yuusuke quer entender as regras.

Enquanto muitos querem derrotar monstros...

Yuusuke tenta evitar guerras.

Enquanto muitos seguem o roteiro do herói...

ele constantemente o questiona.


Mensagens Ocultas

O mundo não é preto e branco

Há poucas decisões totalmente certas ou erradas.

Poder exige responsabilidade

Quanto maior sua influência...

maior o impacto dos seus erros.

Informação vale mais que força

Antes de agir...

entenda o problema.

O verdadeiro inimigo pode ser o próprio sistema

Nem sempre derrotar monstros resolve a raiz do conflito.


Uma Analogia Mainframe

Imagine que o Game Master é o JES2.

Cada missão é um JOB.

Cada classe é uma PROC diferente.

Os heróis recebem:

JOB

↓

EXEC

↓

STEP

↓

RETURN CODE

↓

Nova Execução

Só que aqui existe um detalhe.

O RETURN CODE influencia milhares de vidas.

É praticamente um ambiente de produção bancária.


Impacto Cultural

Embora nunca tenha alcançado o sucesso comercial de:

  • Re:Zero

  • Mushoku Tensei

  • Overlord

  • Sword Art Online

  • Slime

A obra conquistou um público fiel por oferecer uma proposta diferente.

É frequentemente recomendada para quem procura:

  • isekais estratégicos

  • dilemas morais

  • protagonistas inteligentes

  • desenvolvimento psicológico

  • aventuras menos convencionais


Censura

O anime suaviza parte da violência gráfica presente no mangá, especialmente algumas cenas de mortes e ferimentos. Ainda assim, preserva o tom sombrio, os dilemas éticos e a carga dramática das missões. O foco permanece nas consequências das escolhas, mais do que no choque visual.


Mangá

O mangá continua além do ponto onde o anime termina e aprofunda vários mistérios:

  • a verdadeira natureza do Game Master;

  • a origem do mundo das missões;

  • novos integrantes da equipe;

  • conflitos políticos ainda mais complexos;

  • revelações sobre a missão maior envolvendo a humanidade.

É considerado por muitos leitores superior ao anime por desenvolver melhor os personagens e os dilemas morais.


Light Novel

Diferentemente da maioria dos isekais modernos, 100-man no Inochi no Ue ni Ore wa Tatteiru não é baseado em uma light novel. A obra nasceu diretamente como um mangá original de Naoki Yamakawa e Akinari Nao, o que contribui para um ritmo narrativo diferente das adaptações tradicionais.


Games

Até o momento, a franquia não recebeu um jogo eletrônico próprio de grande porte para consoles ou PC. Sua estrutura, entretanto, lembra campanhas de RPG tático e jogos de mesa, nos quais cada missão apresenta objetivos, recursos limitados e consequências permanentes.


Curiosidades

  • O protagonista foge completamente do estereótipo do herói altruísta e costuma ser comparado a um estrategista ou gerente de crises.

  • A trilha sonora é composta por Kenji Kawai, conhecido por trabalhos marcantes em Ghost in the Shell, Patlabor, Mob Psycho 100 e diversos filmes e animes de ficção científica.

  • O título "Estou sobre um milhão de vidas" simboliza o peso das decisões individuais sobre uma sociedade inteira.

  • A obra mistura fantasia medieval, política, sobrevivência e filosofia, aproximando-se mais de um experimento social do que de um isekai tradicional.


Classificação Geral Bellacosa Mainframe

CritérioNota
História⭐⭐⭐⭐⭐ (9,5/10)
Construção do Mundo⭐⭐⭐⭐☆ (8,8/10)
Personagens⭐⭐⭐⭐⭐ (9,2/10)
Estratégia⭐⭐⭐⭐⭐ (10/10)
Ação⭐⭐⭐⭐☆ (8,4/10)
Drama⭐⭐⭐⭐⭐ (9,4/10)
Originalidade⭐⭐⭐⭐⭐ (9,6/10)
Fan Service⭐☆☆☆☆ (2/10)
Filosofia⭐⭐⭐⭐⭐ (9,8/10)
Recomendação para fãs de isekai inteligente⭐⭐⭐⭐⭐

Easter Egg Bellacosa Mainframe

Imagine que o Game Master é o operador responsável pelo ambiente de produção de um grande banco.

Cada missão é um JOB submetido ao JES2.

As classes são módulos carregados dinamicamente.

Os níveis representam novas permissões RACF.

Os monstros são incidentes críticos.

Os reinos são sistemas legados integrados.

E Yuusuke?

Ele é aquele analista COBOL veterano que nunca executa um programa sem antes ler toda a documentação, revisar o JCL, conferir o RC anterior e perguntar:

"Qual é o impacto em produção se isso der ABEND?"

No fim, 100-man no Inochi no Ue ni Ore wa Tatteiru ensina uma lição que todo profissional de missão crítica aprende cedo: o verdadeiro poder não está em resolver problemas rapidamente, mas em compreender profundamente as consequências de cada decisão. Em um ambiente onde milhões dependem do sistema, pensar antes de agir vale mais do que qualquer espada lendária ou magia suprema.

domingo, 18 de outubro de 2020

💖🌸 Bellacosa Otaku Blog — Parte 30: Expressões de Amizade, Companheirismo e Vínculo Emocional nos Animes 🌸💖

 


💖🌸 Bellacosa Otaku Blog — Parte 30: Expressões de Amizade, Companheirismo e Vínculo Emocional nos Animes 🌸💖


🤝 O idioma do coração e da conexão nos animes

(Versão Bellacosa: olhares cúmplices, abraços apertados e promessas silenciosas que emocionam.)

Nos animes de slice of life, shounen, romance ou aventura, o japonês se transforma em uma linguagem de laços, confiança e amor fraterno ou romântico.
Cada palavra carrega emoção, cuidado e proximidade, tornando os relacionamentos entre personagens inesquecíveis.
Vamos explorar as mais icônicas! 💫


💕 1. 友達 (tomodachi)

Tradução: “Amigo / amizade.”
👉 Palavra básica, mas poderosa, que representa vínculo e confiança.

📺 Anime vibe: Anohana, Naruto, One Piece.
💬 Exemplo: “Tomodachi para sempre, não importa a distância.” 🤗


🤝 2. 仲間 (nakama)

Tradução: “Companheiro / aliado.”
👉 Muito usada em shounen e aventuras, reforça união e propósito comum.

📺 Anime vibe: One Piece, Haikyuu!!, Fairy Tail.
💬 Exemplo: “Nakama é quem está ao seu lado em todas as batalhas!” ⚡


🌟 3. 信じる (shinjiru)

Tradução: “Acreditar / confiar.”
👉 Expressa fé e confiança em outra pessoa, essencial para vínculos profundos.

📺 Anime vibe: Naruto, Your Lie in April.
💬 Exemplo: “Shinjiru… eu acredito em você, não importa o que aconteça.” 💖


💌 4. 大切 (taisetsu)

Tradução: “Importante / precioso.”
👉 Usada para enfatizar alguém ou algo que merece cuidado especial.

📺 Anime vibe: Clannad, Anohana.
💬 Exemplo: “Taisetsu… você é muito importante para mim.” 🌸


🌈 5. 助け合う (tasukeau)

Tradução: “Ajudar uns aos outros / cooperação.”
👉 Destaca apoio mútuo, essencial em grupos e amizades fortes.

📺 Anime vibe: Haikyuu!!, One Piece.
💬 Exemplo: “Tasukeau é o que nos torna invencíveis como equipe.” 🤝


💖 6. 忘れない (wasurenai)

Tradução: “Não vou esquecer / sempre lembrarei.”
👉 Palavra carregada de memória, saudade e vínculo emocional duradouro.

📺 Anime vibe: Anohana, Clannad.
💬 Exemplo: “Wasurenai… sempre lembrarei de todos vocês.” 😢


🌟 7. 支える (sasaeru)

Tradução: “Apoiar / sustentar.”
👉 Expressa cuidado e suporte emocional, físico ou moral.

📺 Anime vibe: Your Lie in April, Naruto.
💬 Exemplo: “Sasaeru… sempre estarei aqui para você.” 💪


💫 8. 約束 (yakusoku)

Tradução: “Promessa / compromisso.”
👉 Palavra simbólica que reforça confiança, vínculo e esperança.

📺 Anime vibe: Anohana, Clannad.
💬 Exemplo: “Yakusoku… vamos nos encontrar de novo, prometo.” 🌸


🌹 9. 心 (kokoro)

Tradução: “Coração / sentimentos.”
👉 Representa emoções profundas, intenções e conexões afetivas.

📺 Anime vibe: Your Lie in April, Clannad.
💬 Exemplo: “Kokoro fala mais que palavras… eu te entendo.” 💖


✨ 10. 永遠 (eien)

Tradução: “Eternidade / para sempre.”
👉 Palavra usada para enfatizar laços duradouros, amizade ou amor infinito.

📺 Anime vibe: Anohana, Clannad.
💬 Exemplo: “Eien… juntos para sempre, não importa o que aconteça.” 🌟


🏮 Curiosidades Bellacosa:

  • Palavras como tomodachi, nakama e sasaeru destacam apoio, amizade e lealdade, essenciais em qualquer anime com vínculo emocional.

  • Termos de promessa e memória (yakusoku, wasurenai, eien) reforçam a força dos laços afetivos.

  • Conceitos de importância e coração (taisetsu, kokoro) tornam as relações emocionalmente intensas e tocantes. 💖


🌟 Dica Bellacosa:

  • Observe gestos, abraços e olhares: o vínculo se sente tanto nas palavras quanto nas ações.

  • Frases curtas e emocionais (shinjiru, wasurenai, eien) têm impacto profundo nos espectadores.

  • Memorizar essas expressões ajuda a compreender e sentir a força das amizades e relacionamentos nos animes. 🌸


🌸 Conclusão Bellacosa:

As expressões de amizade, companheirismo e vínculo transformam o japonês em uma linguagem de afeto, confiança e emoção pura.
Cada palavra, gesto ou promessa conecta o espectador ao coração dos personagens, suas histórias e relacionamentos.

“Tomodachi, nakama e yakusoku… juntos no coração, eternamente.” 💖🌸

sábado, 17 de outubro de 2020

O Holocron do Chaos Monkey – Os Laboratórios Bellacosa Mainframe: Como um Sysprog Pode Injetar Caos no IBM Z Sem Ser Expulso da Sala de Guerra - Parte IV

 

Bellacosa Mainframe e o chaos monkey parte iv

☕ Um Café no Bellacosa Mainframe

O Holocron do Chaos Monkey – Parte IV

Os Laboratórios Bellacosa Mainframe: Como um Sysprog Pode Injetar Caos no IBM Z Sem Ser Expulso da Sala de Guerra

"Em produção todos são especialistas em alta disponibilidade. Em laboratório descobrimos quem realmente sabe recuperá-la."


O Café das 3 da Manhã e a Última Lição do Mestre

03h11.

A sala estava silenciosa.

O RMF Monitor III permanecia aberto.

OMEGAMON coletava estatísticas.

O SDSF exibia centenas de jobs.

MQ continuava movimentando mensagens.

Db2 processava commits.

CICS atendia milhares de transações.

O Padawan perguntou.

— Mestre...

— Sim?

— Já entendi a teoria.

— Já entendi o Blast Radius.

— Já entendi observabilidade.

— Já entendi o Parallel Sysplex.

— Mas...

— Como fazemos isso de verdade?

O velho Sysprog sorriu.

Abriu um caderno antigo.

Escrito na capa.

Bellacosa Chaos Labs


Filosofia dos Laboratórios

Objetivo:

Não quebrar ambientes.

Objetivo:

Aprender.

Medir.

Observar.

Melhorar.


Princípios.

Pequeno impacto

Rollback rápido

Equipe avisada

Métricas disponíveis

Documentação obrigatória


Laboratório 1

Chaos Monkey para CICS


Ambiente

CICSPLEX01

TOR01

TOR02

AOR01

AOR02

AOR03

FOR01


Hipótese

Posso perder AOR02.

Sem impacto.


Métricas

CPU

Task Rate

Response Time

Storage

SOS

Abends


Execução

Método 1

CEMT PERFORM SHUTDOWN

Método 2

CEMT SET REGION QUIESCED

Método 3

SA z/OS

INGREQ AOR02 STOP

Observar

OMEGAMON

RMF

CICS Explorer

SMF110


Resultado esperado

TOR redireciona.

Usuários continuam.


Hipótese validada

SIM


Laboratório 2

Chaos Monkey para Db2


Ambiente

DB2A

DB2B

DB2C

CF1

CF2


Hipótese

DB2B pode falhar.


Observar

GBP

IRLM

Claims

Commits

Threads


Simulação

-STOP DB2 MODE(QUIESCE)

ou

-STOP DB2

ambiente controlado.


Métricas

SMF 100

SMF101

IFCID

OMEGAMON


Verificar

Aplicações continuam.

Sim.

Não.


Laboratório 3

Chaos Monkey para MQ


Ambiente

MQA

MQB

MQC

QSG


Hipótese

MQB pode desaparecer.


Execução

STOP QMGR

Observar

Queue Depth

Channels

Persistent Messages

Restart


Ferramentas

MQ Explorer

MO71

OMEGAMON MQ

SMF115


Resultado

Mensagens preservadas.


Laboratório 4

Chaos Monkey para WLM

Talvez um dos mais interessantes.


Hipótese

Aplicação suporta degradação.


Situação

Service Class

HIGH

MEDIUM

LOW


Alteração

Política.

Reduzir.

Importance.


Observação

Velocity

Execution Delay

CPU

SRB


Pergunta

Quem sofre primeiro?


Descoberta

Aplicações frágeis.

Aparecem rapidamente.


Laboratório 5

Simulando Perda de LPAR


Ambiente

LPAR1

LPAR2

LPAR3

LPAR4


Hipótese

Perda.

LPAR2.


Observar

XCF

Coupling

Db2

MQ

CICS


Ferramentas

RMF

NetView

SA

OMEGAMON


Resultado

Sysplex redistribui.


Laboratório 6

Coupling Facility

Apenas para ambientes preparados.


Hipótese

CF1 indisponível.


Observação

Lock Structure

Cache Structure

GBP

Latency


Resultado esperado

CF2 assume.


Laboratório 7

z/OS Connect

Ambientes híbridos.


REST

JSON

APIs


Hipótese

API Gateway indisponível.


Monitorar

HTTP 500

Timeout

MQ

Db2


Laboratório 8

Batch Chaos

Pouco discutido.

Muito útil.


Parar JES Initiator.


Perguntas.

Jobs aguardam?

Restart funciona?

Dependências quebram?


O Papel do Ansible

Chaos moderno.

Precisa ser repetível.


Exemplo.

Playbook.

---
- hosts: zos

tasks:


- stop_cics


- collect_rmf


- wait


- validate


- restart


- report

Benefícios.

Auditoria

Versionamento

Git

Rollback


Exemplo Python

if latency < 120:

    print("Hipótese válida")

else:

    print("Ajustar arquitetura")

O Checklist Bellacosa Chaos

Antes

Hipótese

Blast Radius

Equipe

Janela

Backup

Dashboard

Autorização

Rollback


Durante

Coletar métricas

Observar

Documentar

Registrar horário


Depois

Corrigir

Melhorar

Automatizar

Repetir


O Nível de Maturidade Chaos para IBM Z

Nível 1

Sem testes.


Nível 2

DR anual.


Nível 3

Testes trimestrais.


Nível 4

Automação.


Nível 5

Chaos contínuo.


Nível 6

Auto Healing.

IA.

Ansible.

SA z/OS.


O Futuro

IBM Z já possui.

Observabilidade.

Automação.

Resiliência.

Telemetry.

OpenTelemetry.

Ansible.

AIOps.

Watson.

Instana.

Zowe.

z/OSMF.


Talvez o próximo passo seja.

Chaos Engineering Assistido por IA.


IA pergunta.

Posso testar?


Sysprog.

Sim.


IA.

Executa.

Coleta.

Analisa.

Produz relatório.

Abre Change.

Atualiza Wiki.

Agenda próximo teste.


Bibliografia Recomendada

Chaos Engineering

Netflix

Google SRE

Building Secure and Reliable Systems

IBM Redbooks

Parallel Sysplex Handbook

SA z/OS Planning Guide

CICS TS Administration Guide

Db2 Data Sharing Redbook

MQ for z/OS Redbooks

RMF User Guide

SMF Manuals


A Última Conversa do Padawan

O relógio marcava quase quatro horas da manhã.

O café havia acabado.

O mestre fechou o caderno.

O Padawan perguntou.

— Então...

— Sim.

— O Chaos Monkey é apenas um macaco derrubando servidores?

O velho Sysprog sorriu.

— Não.

— O Chaos Monkey é um professor.

Ele ensina humildade.

Ensina observabilidade.

Ensina automação.

Ensina recuperação.

Ensina arquitetura.

Ensina disciplina.

Ensina documentação.

E acima de tudo.

Ensina que sistemas confiáveis não são aqueles que nunca falham.

São aqueles que falharam inúmeras vezes.

Em laboratório.

Sob controle.

Com métricas.

Com aprendizado.

Com engenharia.

Muito antes dos usuários.

Muito antes dos auditores.

Muito antes da manchete do jornal.

E talvez seja exatamente por isso que tantos Sysprogs veteranos olham para o Chaos Monkey e apenas dão um pequeno sorriso.

Porque, no fundo, sabem que o IBM Z passou décadas ensinando a mesma lição.

Disponibilidade não é sorte.

Resiliência não é marketing.

Alta disponibilidade é a arte de transformar falhas inevitáveis em eventos rotineiros, previsíveis e quase entediantes.


☕ Fim do Holocron do Chaos Monkey

Teste. Observe. Aprenda. Evolua. E nunca deixe que o primeiro desastre da sua arquitetura aconteça em uma segunda-feira às 9h da manhã.


sexta-feira, 16 de outubro de 2020

Como Kami-tachi ni Hirowareta Otoko Ensina Mais Sobre Automação, Resiliência e Engenharia de Sistemas do que Muitos Cursos Corporativos

Bellacosa Mainframe se diverte com Kami-tachi ni hirowareta Otoko 


Como Kami-tachi ni Hirowareta Otoko Ensina Mais Sobre Automação, Resiliência e Engenharia de Sistemas do que Muitos Cursos Corporativos

Existe um momento na vida de quase todo profissional de TI em que surge um pensamento silencioso:

"E se eu pudesse simplesmente desaparecer por alguns anos, morar numa floresta, estudar tecnologia em paz, tomar café e catalogar slimes?"

Curiosamente, foi exatamente isso que o autor de Kami-tachi ni Hirowareta Otoko transformou em uma das obras mais peculiares do fenômeno isekai moderno.

E talvez seja justamente por isso que esta série seja uma das produções mais subestimadas da década.


Ficha Técnica

Título Original

神達に拾われた男

Romanização

Kami-tachi ni Hirowareta Otoko

Título Internacional

By the Grace of the Gods

Autor

Roy

Ilustrador

Ririnra

Publicação Inicial

2014

(Web Novel no Shōsetsuka ni Narō)

Light Novel

2017

Editora:

HJ Novels

Mangá

2017

Arte de Ranran


Anime

Estúdio

Maho Film

Direção

Takeyuki Yanase

Primeira temporada

Outubro de 2020

12 episódios

Segunda temporada

Janeiro de 2023

12 episódios

Total:

24 episódios

Duração média:

24 minutos


Gêneros

Isekai

Fantasia

Slice of Life

Iyashikei

Aventura

Comédia leve

Classificação indicativa aproximada:

12 anos

Violência mínima

Pouco fanservice

Ausência de linguagem pesada


Sinopse

Ryoma Takebayashi era um trabalhador japonês de 39 anos.

Sua vida foi marcada por:

Abuso familiar.

Bullying.

Sobrecarga profissional.

Solidão.

Pouco reconhecimento.

Após morrer enquanto dormia, três divindades decidem conceder uma nova existência.

Ryoma renasce em outro mundo como uma criança de oito anos.

Recebe talentos mágicos excepcionais.

Mas decide não se tornar herói.

Não quer derrotar demônios.

Não deseja governar países.

Não sonha em montar um harém.

Ele quer apenas viver em paz.

Estudar.

Experimentar.

Aprender.

Criar slimes.

E é justamente aí que a história se torna interessante.


A História Sob a Ótica Bellacosa Mainframe

Eu costumo dizer que Ryoma é praticamente um Sysprog aposentado.

Imagine um profissional que passou vinte anos cuidando de produção.

Recebia chamados às três da manhã.

Corrigia JCL quebrado.

Fazia RECOVER de DB2.

Investigava ABEND S0C7.

Lutava contra gestores tóxicos.

Morre de exaustão.

E então recebe um novo LPAR vazio.

Pode configurar tudo do zero.

Sem incidente.

Sem SLA.

Sem Change Request.

O que ele faz?

Não instala Kubernetes.

Não sobe uma startup.

Não cria NFTs.

Ele começa a estudar slimes.


Os Slimes São Quase Ferramentas de Automação

Na prática, Ryoma constrói um laboratório.

Cataloga espécies.

Analisa comportamento.

Mede consumo.

Documenta evolução.

Executa testes.

É um trabalho extremamente semelhante ao de:

RMF

SMF

Capacity Planning

WLM

Machine Learning supervisionado

DevOps

Observabilidade

Cada slime possui função específica.

Slime Ácido

Processamento destrutivo.

Slime Limpador

Housekeeping.

Slime Coletor

Garbage Collection.

Slime Curador

Autorreparo.

Slime Metálico

Persistência.

Slime Venenoso

Análise química.

Ryoma praticamente cria um catálogo de serviços.


O Diferencial da Obra

Grande parte dos isekais segue um padrão.

Academia mágica.

Rei demônio.

Harém.

Torneios.

Poder absurdo.

Kami-tachi rompe essa estrutura.

O foco é:

Vida cotidiana;

Empreendedorismo;

Pequenas conquistas;

Curiosidade científica;

Construção de comunidade;

Saúde emocional.

Poucas obras conseguem ser tão tranquilas.


As Aventuras

Apesar da atmosfera calma, Ryoma passa por várias experiências.

Vida na floresta

Sobrevivência.

Domínio da magia.

Pesquisa.


Conhecendo a Família Jamil

Reinhart.

Elise.

Eliaria.

Funcionam quase como uma família adotiva.


Fundação da lavanderia

Talvez o arco mais interessante.

Ryoma automatiza lavagem.

Padroniza processos.

Treina pessoas.

Escala operações.

Monitora qualidade.

É literalmente um projeto Lean Six Sigma em fantasia medieval.


Guildas

Integração social.

Networking.

Gestão de reputação.


Personagens

Ryoma

Introvertido.

Traumatizado.

Observador.

Empático.

Possui uma característica rara.

Nunca busca reconhecimento.


Eliaria

Filha da família Jamil.

Representa amizade genuína.

Normalidade.

Infância saudável.


Reinhart

Figura paterna.

Mentor.

Proteção.


Os Deuses

Gain

Kufo

Lulutia

São diferentes de deuses tradicionais.

Não punem.

Não exigem culto.

Apenas desejam que Ryoma seja feliz.


As Mensagens Ocultas

Aqui está a parte mais interessante.

A obra possui forte subtexto.

1. Burnout corporativo

Ryoma é um adulto destruído.

A reencarnação simboliza uma segunda oportunidade.


2. Ciência aplicada

Não existe talento inato.

Ryoma documenta tudo.

Experimenta.

Falha.

Corrige.

Repete.

Método científico.


3. Trauma

Ryoma frequentemente estranha receber carinho.

Não entende amizades.

Tem dificuldade em confiar.

São traços típicos de pessoas emocionalmente negligenciadas.


4. O valor do trabalho digno

A lavanderia simboliza algo importante.

Trabalho não precisa destruir.

Pode gerar:

renda;

utilidade;

comunidade;

satisfação.


Impacto Cultural

Kami-tachi não se tornou um fenômeno do tamanho de:

Re:Zero

Mushoku Tensei

Konosuba

Overlord

Mas conquistou enorme popularidade entre públicos que procuram animes relaxantes.

Entrou para listas frequentes de:

"Comfort Anime"

"Iyashikei Fantasy"

"Slow Life Isekai"

Influenciou a consolidação do subgênero conhecido como:

Slow Life Isekai

Hoje bastante explorado.


Houve censura?

Praticamente não.

Não existem registros relevantes de:

Cortes internacionais;

proibição em países;

alterações narrativas.

Algumas críticas surgiram porque o anime suavizou aspectos mais sombrios do passado de Ryoma presentes na novel.

Mas isso parece ter sido uma decisão criativa.

O objetivo era reforçar a proposta de obra terapêutica.


A Grande Questão

Kami-tachi ni Hirowareta Otoko talvez seja um dos poucos isekais que perguntam algo profundamente adulto:

"Se você tivesse uma segunda chance, realmente desejaria ser o herói mais forte do mundo... ou apenas gostaria de ter tempo, paz, amigos sinceros, um laboratório organizado, alguns slimes curiosos e uma boa caneca de café?"

Sob a ótica do Bellacosa Mainframe, Ryoma não é exatamente um aventureiro.

Ele é um antigo operador de produção que finalmente recebeu um ambiente limpo, sem incidentes críticos, onde pode estudar, automatizar processos, construir algo útil e descobrir que a verdadeira magia talvez não esteja em derrotar dragões, mas em encontrar uma rotina que permita viver sem medo da próxima chamada de madrugada anunciando que a produção caiu. ☕🟢🖥️🧪

domingo, 11 de outubro de 2020

🏐⚡ Bellacosa Otaku Blog — Parte 29: Expressões de Esportes, Competição e Superação nos Animes ⚡🏀

 


🏐⚡ Bellacosa Otaku Blog — Parte 29: Expressões de Esportes, Competição e Superação nos Animes ⚡🏀


🏟️ O idioma da adrenalina, esforço e vitória nos animes

(Versão Bellacosa: suor, treinos intensos, gritos de incentivo e momentos que aceleram o coração.)

Nos animes esportivos, shounen e de competição, o japonês se transforma em uma linguagem de ação, energia e superação.
Cada palavra carrega paixão, determinação e espírito de equipe, tornando as partidas e desafios emocionantes e inspiradores.
Vamos explorar as mais icônicas! ⚡


💪 1. 頑張れ (ganbare)

Tradução: “Força! / Continue firme!”
👉 Palavra essencial para motivar companheiros e a si mesmo durante treinos ou competições.

📺 Anime vibe: Haikyuu!!, Kuroko no Basket, Yowamushi Pedal.
💬 Exemplo: “Ganbare! Não desista agora!” 🏐


🏆 2. 勝利 (shouri)

Tradução: “Vitória / triunfo.”
👉 Meta de todo atleta e equipe, usada para celebrar conquistas.

📺 Anime vibe: Haikyuu!!, Kuroko no Basket.
💬 Exemplo: “Shouri! Conquistamos a final!” 🏅


⚡ 3. 全力 (zenryoku)

Tradução: “Com toda a força / total empenho.”
👉 Palavra usada para dar tudo de si, sem reservas.

📺 Anime vibe: Yowamushi Pedal, Haikyuu!!, Prince of Tennis.
💬 Exemplo: “Zenryoku! Cada ponto conta!” 💥


🏐 4. チーム (chīmu)

Tradução: “Equipe / time.”
👉 Representa a importância da união e colaboração.

📺 Anime vibe: Haikyuu!!, Kuroko no Basket.
💬 Exemplo: “Chīmu unido, ninguém nos derrota!” 🤝


🥵 5. 練習 (renshū)

Tradução: “Treino / prática.”
👉 Essencial para evolução, melhoria de habilidades e preparação para desafios.

📺 Anime vibe: Haikyuu!!, Prince of Tennis, Yowamushi Pedal.
💬 Exemplo: “Renshū duro todos os dias é a chave da vitória.” 🏋️


🏃 6. 努力 (doryoku)

Tradução: “Esforço / dedicação.”
👉 Expressa a perseverança e o empenho contínuo para alcançar objetivos.

📺 Anime vibe: Haikyuu!!, Yowamushi Pedal.
💬 Exemplo: “Doryoku constante nos leva à excelência.” 💪


⚡ 7. ライバル (raibaru)

Tradução: “Rival / concorrente.”
👉 Palavra usada para quem desafia, estimula e inspira crescimento.

📺 Anime vibe: Haikyuu!!, Kuroko no Basket.
💬 Exemplo: “Raibaru à frente! Hora de mostrar tudo que treinamos!” 🏀


🔥 8. 決勝 (kesshou)

Tradução: “Final / fase decisiva.”
👉 Termo usado para a última e mais importante partida ou desafio.

📺 Anime vibe: Haikyuu!!, Prince of Tennis.
💬 Exemplo: “Kesshou! Tudo depende deste momento!” ⚡


🌟 9. チャンス (chansu)

Tradução: “Oportunidade / chance de vitória.”
👉 Momento crucial em que o esforço pode se concretizar em resultado.

📺 Anime vibe: Haikyuu!!, Kuroko no Basket.
💬 Exemplo: “Chansu! Este ponto pode mudar o jogo!” 🏐


🏅 10. 勝負 (shoubu)

Tradução: “Confronto / disputa.”
👉 Palavra para toda competição ou batalha esportiva intensa.

📺 Anime vibe: Haikyuu!!, Kuroko no Basket, Yowamushi Pedal.
💬 Exemplo: “Shoubu! Vamos mostrar quem é o melhor!” ⚡


🏮 Curiosidades Bellacosa:

  • Palavras como ganbare, zenryoku e doryoku reforçam motivação e esforço, pilares de qualquer anime esportivo.

  • Termos de competição (shouri, kesshou, shoubu) tornam os jogos emocionantes e cheios de tensão.

  • A presença de raibaru e chīmu destaca importância da rivalidade e do trabalho em equipe. 🏐


🌟 Dica Bellacosa:

  • Observe gritos, gestos e expressões faciais: eles transmitem energia e intensidade da competição.

  • Frases curtas e motivacionais (ganbare, zenryoku, shoubu) são essenciais para o clima de superação.

  • Memorizar essas expressões ajuda a sentir a adrenalina, esforço e emoção das partidas e treinos nos animes. ⚡


🌸 Conclusão Bellacosa:

As expressões de esportes e competição transformam o japonês em uma linguagem de coragem, dedicação e adrenalina pura.
Cada palavra, gesto ou grito motiva o espectador a viver junto a desafios, vitórias e superações dos personagens.

“Ganbare, zenryoku e doryoku… juntos com o chīmu, a vitória será nossa!” 🏐⚡

sexta-feira, 9 de outubro de 2020

O Mercado das Linguagens : Quando um Programador Descobre que Wall Street Não Compra Linguagens — Compra Risco, Poder, Escala e Sistemas que Não Podem Parar

 

Bellacosa Mainframe e o mercado das linguagens de programação

☕ Um Café no Bellacosa Mainframe

O Mercado das Linguagens sem Mistérios para Programadores COBOL

Quando um Programador Descobre que Wall Street Não Compra Linguagens — Compra Risco, Poder, Escala e Sistemas que Não Podem Parar

“A linguagem mais valiosa não é necessariamente a mais popular. É aquela que está executando quando alguém aperta o botão ‘transferir’.”

Imagine a manhã começando em Manhattan.

Táxis amarelos brigam por centímetros de asfalto. Executivos atravessam a calçada segurando café, telefone e a certeza temporária de que compreenderam o mercado. Telas verdes e vermelhas piscam nos escritórios. Alguém acaba de ganhar uma fortuna. Outro ainda não descobriu que perdeu a empresa inteira.

No alto de um prédio, um jovem programador observa um gráfico circular sobre linguagens de programação.

De um lado, estão os ativos considerados promissores: Go, Elixir, Swift e TypeScript.

Do outro, aparecem tecnologias classificadas como custo, substituição, obsolescência ou passado industrial: COBOL, PL/I, RPG, Fortran, C e outras sobreviventes de guerras computacionais que já deveriam ter sido encerradas segundo dezenas de consultorias, centenas de palestrantes e aproximadamente quinze mil artigos escritos por pessoas que nunca viram um fechamento bancário.

O jovem aponta para o gráfico e pergunta:

— Então COBOL está morrendo?

O veterano do mainframe olha pela janela, ajeita o paletó e responde:

— Filho, neste mercado há duas maneiras de enriquecer. A primeira é descobrir o futuro. A segunda é cobrar caro para manter funcionando aquilo que todos afirmaram que não teria futuro.

Bem-vindo ao pregão das linguagens.

Aqui, popularidade não é receita.

Quantidade de repositórios não é volume financeiro.

Curtidas não são transações.

E um sistema escrito em uma linguagem considerada “antiga” pode movimentar mais dinheiro antes do almoço do que milhares de aplicativos modernos movimentarão durante toda a existência.


O gráfico original: elegante, sedutor e perigosamente incompleto

O diagrama analisado anteriormente tenta organizar as linguagens em um ciclo de mercado.

Ele apresenta quatro grandes regiões:

  • Advantage, ou vantagem;

  • Choice, ou escolha;

  • Cost, ou custo;

  • Replacement, ou substituição.

Também inclui marcos como:

  • início de mercado;

  • nascimento dos padrões;

  • auge da industrialização;

  • crepúsculo da obsolescência;

  • comoditização.

Como modelo intelectual, é interessante.

Como fotografia absoluta do mercado, é tão confiável quanto um corretor que telefona na sexta-feira à tarde dizendo que determinada ação “não tem como cair”.

O primeiro problema é que o gráfico tenta colocar em uma única circunferência coisas completamente diferentes:

  • idade da linguagem;

  • quantidade de novos projetos;

  • custo de manutenção;

  • popularidade;

  • disponibilidade de profissionais;

  • maturidade de ferramentas;

  • valor econômico;

  • perspectiva de substituição.

Essas dimensões não caminham juntas.

Uma linguagem pode ser antiga e barata.

Outra pode ser moderna e caríssima.

Uma pode ter milhões de programadores e produzir sistemas descartáveis.

Outra pode ter poucos especialistas e sustentar operações que não admitem interrupção.

Portanto, a primeira correção necessária é abandonar a ideia de que todas as linguagens percorrem o mesmo caminho.

Linguagens não são ações negociadas na mesma bolsa.

Rust não compete diretamente com COBOL em processamento de folha salarial.

JavaScript não substitui automaticamente Fortran em simulações científicas.

Python não é obrigatoriamente a melhor escolha para firmware.

COBOL não precisa vencer TypeScript na construção de interfaces web.

Comparar essas tecnologias sem considerar o domínio é como analisar uma companhia ferroviária e uma fabricante de perfumes apenas porque ambas possuem funcionários e pagam impostos.


A verdadeira bolsa de valores das linguagens

O mercado real deveria avaliar uma linguagem em pelo menos seis dimensões:

  1. adoção em novos projetos;

  2. base instalada;

  3. valor dos sistemas existentes;

  4. custo de substituição;

  5. disponibilidade de profissionais;

  6. capacidade de integração com tecnologias modernas.

Uma linguagem pode parecer fraca em uma dimensão e ser praticamente indestrutível nas outras.

É exatamente o caso do COBOL.


1. Adoção em novos projetos

Essa é a métrica preferida dos rankings.

Ela responde:

Quantos sistemas novos estão sendo iniciados nesta linguagem?

Aqui, linguagens como TypeScript, Python, JavaScript, Java, Go, C# e outras tendem a aparecer com força.

No GitHub, por exemplo, TypeScript tornou-se a linguagem mais usada em agosto de 2025, ultrapassando Python e JavaScript. O movimento foi impulsionado pelo crescimento de aplicações web, ferramentas de inteligência artificial e pela preferência crescente por linguagens tipadas em projetos de grande escala. (The GitHub Blog)

Na pesquisa Stack Overflow de 2025, JavaScript apareceu entre as tecnologias mais utilizadas, enquanto Python ganhou participação de forma significativa, associado principalmente a inteligência artificial, ciência de dados, automação e desenvolvimento de backend. (survey.stackoverflow.co)

Se analisarmos somente os novos projetos visíveis na internet, COBOL parecerá pequeno.

Mas esse é apenas o salão da bolsa aberto ao público.

Os cofres estão em outro andar.


Bellacosa Mainframe e a evolução das linguagens de programação

2. Base instalada

A base instalada representa tudo aquilo que já existe, funciona, recebe manutenção e não pode ser desligado por capricho arquitetural.

É aqui que o mapa muda.

Considere dois projetos hipotéticos.

Projeto A

Uma aplicação em TypeScript criada há seis meses:

  • 20 mil linhas de código;

  • 15 microsserviços;

  • 800 usuários;

  • faturamento ainda experimental;

  • possibilidade de substituição relativamente simples.

Projeto B

Um sistema COBOL criado ao longo de quatro décadas:

  • milhões de linhas;

  • centenas de programas;

  • milhares de arquivos e tabelas;

  • integrações com CICS, Db2, IMS e MQ;

  • processamento de milhões de clientes;

  • regras fiscais, contratuais e contábeis acumuladas;

  • funcionamento contínuo há décadas.

O Projeto A é mais novo.

O Projeto B é mais valioso.

A linguagem não recebe valor apenas pelo código que poderá ser escrito amanhã. Recebe valor também pelo patrimônio lógico que representa hoje.

Essa distinção raramente aparece em rankings.


COBOL não é uma ação de crescimento; é infraestrutura soberana

Wall Street adora empresas de crescimento.

Empresas que prometem conquistar novos mercados, multiplicar receitas e transformar o mundo antes da próxima apresentação trimestral.

COBOL não pertence a essa categoria.

COBOL é mais parecido com:

  • uma empresa de energia;

  • uma rede ferroviária;

  • um sistema de compensação;

  • uma usina;

  • um porto;

  • um conjunto de cofres subterrâneos.

Ele não precisa ser excitante.

Precisa estar funcionando.

A própria IBM descreve COBOL como uma linguagem criada especificamente para aplicações empresariais e ainda presente em sistemas essenciais. A modernização desses ambientes não significa simplesmente abandonar COBOL, mas atualizar práticas, ferramentas, integrações, arquitetura e processos em torno das aplicações existentes. (IBM)

Esse é um ponto fundamental para o iniciante:

Modernização não é sinônimo de reescrita.

Muitas empresas modernizam sistemas COBOL por meio de:

  • APIs;

  • integração com Java;

  • serviços REST;

  • mensageria;

  • pipelines de CI/CD;

  • Git;

  • testes automatizados;

  • novos compiladores;

  • análise estática;

  • observabilidade;

  • interfaces web e móveis;

  • inteligência artificial aplicada à compreensão do código.

O programa COBOL permanece no centro porque continua executando a regra de negócio.

O que muda é a forma de acessá-lo, testá-lo, implantá-lo e governá-lo.


O erro da coluna “Cost”

O gráfico coloca COBOL, Java, C++, PHP, JavaScript, Python e outras linguagens próximas da região de custo.

Essa classificação é enganosa porque toda tecnologia possui custo.

A pergunta correta não é:

Quanto custa manter?

A pergunta correta é:

Quanto custa manter em comparação com o valor produzido e com o risco de substituir?

Imagine que um sistema COBOL custe dez milhões por ano para operar.

À primeira vista, parece caro.

Mas suponha que ele processe centenas de bilhões em transações, cobranças, pagamentos, apólices ou benefícios.

O custo representa uma pequena fração do valor protegido.

Agora imagine uma tentativa de reescrever tudo em outra linguagem por 300 milhões, durante cinco anos, sem garantia de equivalência funcional.

O sistema antigo deixa de parecer caro.

Ele passa a parecer o adulto responsável na sala.

O mercado não calcula apenas custo de desenvolvimento.

Calcula:

  • risco operacional;

  • risco regulatório;

  • risco de indisponibilidade;

  • risco de perda de dados;

  • risco reputacional;

  • risco de fraude;

  • risco de interpretação incorreta das regras;

  • risco de migração;

  • risco de dependência de fornecedor;

  • risco de a equipe moderna descobrir tarde demais que o sistema antigo fazia 4.700 coisas que ninguém documentou.

A função do programador COBOL não é apenas escrever código.

É proteger capital operacional.


O programa de 1978 que sabe mais sobre a empresa do que a diretoria

Uma das grandes curiosidades do legado é que o código frequentemente se transforma em documentação executável da organização.

Imagine uma seguradora.

Ao longo de 40 anos, seus programas receberam alterações para:

  • novas leis;

  • novos produtos;

  • decisões judiciais;

  • mudanças de moeda;

  • planos especiais;

  • regras de exceção;

  • fusões empresariais;

  • acordos com clientes;

  • tratamentos para contratos antigos;

  • cálculos atuariais;

  • arredondamentos específicos;

  • datas de corte.

O programa pode conter uma condição como:

IF DATA-ADESAO < 19940701
   COMPUTE TAXA-FINAL = TAXA-ANTIGA * FATOR-TRANSICAO
ELSE
   COMPUTE TAXA-FINAL = TAXA-NOVA
END-IF

O programador iniciante olha e pensa:

— Isso é feio. Vamos simplificar.

O veterano pergunta:

— Você sabe por que julho de 1994 está ali?

Silêncio.

Talvez a data represente:

  • uma mudança monetária;

  • uma norma;

  • um produto encerrado;

  • um contrato coletivo;

  • um ajuste de transição;

  • uma determinação jurídica.

Apagar aquela condição sem compreender o contexto pode gerar milhões em pagamentos incorretos.

Eis a verdadeira mercadoria do programador COBOL:

conhecimento de negócio encapsulado em código.


O que os rankings realmente medem?

Outro erro comum é interpretar índices como se todos medissem a mesma coisa.

Não medem.

TIOBE

O TIOBE mede sinais de popularidade obtidos em mecanismos de busca, cursos, fornecedores e disponibilidade de profissionais. O próprio índice avisa que não mede qual é a melhor linguagem nem quantas linhas de código foram escritas em cada uma. (TIOBE)

Portanto, subir no TIOBE significa ganhar visibilidade relativa naquele método.

Não significa automaticamente:

  • mais vagas;

  • salários maiores;

  • mais sistemas críticos;

  • melhor desempenho;

  • maior faturamento;

  • maior relevância estratégica.

GitHub

O GitHub enxerga principalmente o universo hospedado na plataforma:

  • open source;

  • projetos públicos;

  • empresas que utilizam GitHub;

  • código criado ou espelhado ali.

É uma fonte extremamente importante, mas não enxerga perfeitamente:

  • bibliotecas internas antigas;

  • ambientes isolados;

  • código proprietário;

  • instituições financeiras restritas;

  • sistemas governamentais;

  • aplicações mantidas em ferramentas tradicionais;

  • organizações que ainda não levaram todo o patrimônio para Git.

Se um banco possui dezenas de milhões de linhas COBOL protegidas por controles internos, elas não aparecerão em um ranking público.

Isso não as torna inexistentes.

Torna-as confidenciais.

Stack Overflow

A pesquisa Stack Overflow reflete a comunidade que responde ao levantamento.

Isso ajuda a compreender preferências e práticas contemporâneas, mas profissionais de certos setores podem estar sub-representados.

Um programador de startup provavelmente usa fóruns públicos com frequência.

Um especialista responsável por um sistema financeiro confidencial pode encontrar respostas em:

  • documentação interna;

  • Redbooks;

  • manuais IBM;

  • bases corporativas;

  • colegas;

  • contratos de suporte;

  • comunidades especializadas.

O silêncio público não significa ausência econômica.

Às vezes significa segurança.


A correção realista das principais linguagens do gráfico

COBOL: de “custo” para “ativo crítico de baixa visibilidade”

COBOL deveria ocupar uma categoria própria:

Infraestrutura empresarial consolidada com alto custo de substituição.

Não é a principal escolha para uma nova rede social.

Mas continua excelente para:

  • processamento em lote;

  • transações comerciais;

  • cálculos financeiros;

  • grandes volumes de registros;

  • regras de negócio;

  • integração com bancos de dados empresariais;

  • sistemas que exigem previsibilidade e continuidade.

COBOL não está no “fim da vida”.

Está em um mercado maduro, especializado e menos visível.

A IBM continua promovendo recursos, interoperabilidade, modernização e ferramentas voltadas a aplicações COBOL, inclusive integração com Java e uso de IA para compreender e transformar aplicações. (@ibmdeveloper)


Java: de “custo” para “coluna vertebral empresarial”

Java não é novidade.

Exatamente por isso é valioso.

Ele possui:

  • ecossistema gigantesco;

  • bibliotecas maduras;

  • JVM;

  • frameworks;

  • profissionais;

  • ferramentas;

  • aplicações bancárias;

  • sistemas governamentais;

  • plataformas empresariais;

  • serviços de backend;

  • Android em sua trajetória histórica.

Java talvez não produza a mesma euforia de uma linguagem recém-lançada.

Mas continua sendo uma base fundamental do desenvolvimento corporativo. O próprio GitHub o descreve como uma das fundações de aplicações empresariais escaláveis e seguras. (The GitHub Blog)

No pregão tecnológico, Java não é uma startup exótica.

É uma corporação que possui prédios, clientes, contratos e advogados.


JavaScript e TypeScript: da improvisação ao império

No gráfico antigo, JavaScript aparece em uma posição que já não representa a realidade.

JavaScript deixou de ser apenas uma linguagem de pequenos scripts no navegador.

Hoje está presente em:

  • frontend;

  • backend;

  • aplicações desktop;

  • ferramentas;

  • automação;

  • servidores;

  • plataformas;

  • aplicações móveis;

  • ambientes cloud.

TypeScript adicionou tipagem estática e melhor estrutura para grandes bases de código. Em 2025, ultrapassou JavaScript e Python no GitHub, tornando-se o exemplo perfeito de como um gráfico tecnológico pode envelhecer rapidamente. (The GitHub Blog)

CoffeeScript, que no diagrama aparece perto do “nascimento dos padrões”, perdeu relevância justamente porque TypeScript ocupou seu espaço de maneira mais poderosa.

O mercado não recompensa apenas quem chega primeiro.

Recompensa quem resolve melhor o problema no momento certo.


Python: a moeda preferida da era da IA

Python cresceu porque conseguiu tornar-se simultaneamente:

  • acessível para iniciantes;

  • útil para automação;

  • forte em ciência de dados;

  • dominante em inteligência artificial;

  • presente no backend;

  • adequado para protótipos;

  • cercado por bibliotecas.

A pesquisa Stack Overflow de 2025 registrou aumento expressivo de adoção de Python, associando-o à IA, ciência de dados e backend. (survey.stackoverflow.co)

Isso não significa que Python substituirá todas as linguagens.

Ele é poderoso porque atua como uma espécie de língua franca entre áreas.

Mas não elimina:

  • C em sistemas;

  • COBOL em regras empresariais;

  • Java em plataformas corporativas;

  • JavaScript e TypeScript na web;

  • Fortran em computação científica;

  • Rust em sistemas que exigem segurança de memória.

Wall Street gosta de narrativas absolutas.

A engenharia prefere contexto.


C e C++: petróleo bruto da computação

C e C++ aparecem em muitos discursos como tecnologias antigas.

Entretanto, continuam presentes em:

  • sistemas operacionais;

  • bancos de dados;

  • compiladores;

  • jogos;

  • navegadores;

  • dispositivos;

  • sistemas embarcados;

  • telecomunicações;

  • aplicações de alto desempenho.

Você pode escrever uma interface moderna em uma linguagem recente.

Mas em algum ponto inferior da pilha haverá uma quantidade considerável de C ou C++ fazendo o trabalho pesado.

Eles não desapareceram.

Tornaram-se subterrâneos.

Como cabos, tubulações e cofres.


Fortran: o velho cientista que ainda controla o reator

Fortran não disputa atenção com frameworks web.

Ele disputa precisão, desempenho e décadas de código científico validado.

Permanece relevante em:

  • meteorologia;

  • física;

  • engenharia;

  • modelagem;

  • simulações;

  • supercomputação;

  • pesquisa climática.

Reescrever um modelo científico validado durante décadas não é apenas um projeto de programação.

É uma nova validação científica.

Uma fórmula convertida incorretamente pode continuar compilando e produzindo números aparentemente plausíveis.

Esse é o tipo mais perigoso de erro: o erro elegante.


PL/I e RPG: mercados menores, porém reais

PL/I e RPG não possuem a visibilidade de Python ou JavaScript.

Porém, continuam presentes em ambientes empresariais específicos.

RPG possui forte associação com IBM i.

PL/I continua ligado a sistemas corporativos, inclusive ambientes mainframe.

O número de novos programadores é menor.

Isso cria um paradoxo interessante:

  • menos vagas totais;

  • menos candidatos qualificados;

  • maior dependência de conhecimento especializado;

  • risco de sucessão;

  • oportunidades para quem combina legado e modernização.

Não é um mercado de massa.

É um mercado de nicho com portas pesadas.


Passo a passo para o programador COBOL iniciante ler o mercado

Passo 1 — Não pergunte apenas “qual linguagem está crescendo?”

Pergunte:

  • Em qual setor?

  • Em qual país?

  • Em qual plataforma?

  • Para qual tipo de aplicação?

  • Em empresas de qual tamanho?

  • Em projetos novos ou manutenção?

  • Com qual nível de responsabilidade?

“Python está crescendo” é verdadeiro.

“Python substituirá todo COBOL bancário” é uma aposta muito mais arriscada.


Passo 2 — Aprenda a diferenciar popularidade de valor

Popularidade mede atenção.

Valor mede consequência.

Um aplicativo com milhões de downloads pode falhar por alguns minutos e causar reclamações.

Um sistema de liquidação pode falhar por segundos e gerar impactos financeiros, operacionais e regulatórios.

A criticidade muda o preço da competência.


Passo 3 — Construa uma combinação, não uma prisão

O iniciante não deve aprender apenas COBOL.

Também não deve abandonar COBOL para perseguir toda nova linguagem que aparece no noticiário.

Uma combinação poderosa inclui:

  • COBOL;

  • JCL;

  • Db2;

  • CICS ou IMS;

  • VSAM;

  • Git;

  • APIs;

  • Linux ou Unix;

  • noções de Java ou Python;

  • testes;

  • CI/CD;

  • observabilidade;

  • fundamentos de segurança.

O profissional mais valioso não é aquele que defende uma linguagem como time de futebol.

É aquele que conecta mundos.


Passo 4 — Aprenda negócio

Um programador COBOL que entende apenas sintaxe possui valor limitado.

Um programador que entende:

  • contabilidade;

  • crédito;

  • seguros;

  • pagamentos;

  • previdência;

  • logística;

  • faturamento;

  • tributação;

  • conciliação;

  • processamento batch;

transforma-se em especialista.

No mercado financeiro, código é apenas a camada visível.

A verdadeira riqueza está na compreensão da operação.


Passo 5 — Aprenda a modernizar sem destruir

Modernização responsável começa com perguntas:

  1. O que o sistema faz?

  2. Quais aplicações dependem dele?

  3. Quais dados utiliza?

  4. Qual o volume processado?

  5. Quais regras são críticas?

  6. Quais exceções históricas existem?

  7. Quais interfaces podem ser expostas?

  8. O que pode ser refatorado?

  9. O que deve permanecer?

  10. Como testar equivalência?

Depois vêm as ferramentas.

Nunca o contrário.

Escolher um framework antes de compreender o sistema é como comprar um terno antes de descobrir se você foi convidado para uma reunião ou para um funeral.


Curiosidade: o ativo invisível não aparece no balanço

Empresas costumam registrar servidores, imóveis, licenças e equipamentos como ativos.

Mas raramente conseguem representar adequadamente o valor acumulado de décadas de regras de negócio em código.

Um sistema COBOL pode conter o conhecimento de centenas de:

  • analistas;

  • contadores;

  • especialistas;

  • advogados;

  • operadores;

  • gestores;

  • programadores;

  • auditores.

Muitos já se aposentaram.

Alguns faleceram.

Outros sequer lembram por que determinada regra foi criada.

O código permaneceu.

Nesse sentido, o programa não é apenas software.

É memória institucional compilável.


Easter egg do pregão: GREED IS GOOD, mas integridade referencial é melhor

Em filmes sobre mercados financeiros, a cobiça aparece como motor de ascensão e queda.

Na tecnologia, existe uma versão semelhante:

  • a cobiça pela linguagem nova;

  • a cobiça pelo projeto de migração;

  • a cobiça pelo contrato milionário;

  • a cobiça pela arquitetura com cinquenta produtos;

  • a cobiça por anunciar que “desligamos o legado”.

Mas sistemas empresariais não obedecem ao roteiro de Hollywood.

Quando a música termina, alguém precisa reconciliar os centavos.

Você pode convencer a diretoria a substituir um sistema considerado antigo.

O que não pode fazer é convencer o razão contábil a aceitar uma diferença de três milhões porque a nova arquitetura possui containers elegantes.

No mainframe, o verdadeiro lema não é:

“A cobiça é boa.”

É:

“O fechamento precisa bater.”


O novo mapa realista

Se redesenhássemos o gráfico, não colocaríamos COBOL caminhando simplesmente em direção ao fim.

Criaríamos zonas diferentes.

Zona 1 — Crescimento e experimentação

  • novas linguagens;

  • novos frameworks;

  • alto volume de projetos;

  • mudanças rápidas;

  • risco de desaparecimento.

Zona 2 — Adoção industrial

  • ecossistemas maduros;

  • forte mercado;

  • disponibilidade de profissionais;

  • ampla utilização.

Zona 3 — Infraestrutura consolidada

  • sistemas críticos;

  • grande base instalada;

  • alto custo de substituição;

  • evolução gradual;

  • menor visibilidade pública.

Aqui estariam COBOL, C, Java e outras tecnologias fundamentais, dependendo do domínio.

Zona 4 — Nichos especializados

  • Fortran;

  • PL/I;

  • RPG;

  • Erlang;

  • Haskell;

  • linguagens científicas, funcionais ou empresariais específicas.

Zona 5 — Declínio real

Uma linguagem só deveria entrar aqui quando houvesse combinação de:

  • ausência de manutenção;

  • fim de compiladores;

  • desaparecimento de fornecedores;

  • falta de sistemas relevantes;

  • impossibilidade de integração;

  • abandono completo do ecossistema.

Ser antiga não basta.

Ser pouco comentada também não.


Conclusão: o mercado não é uma enquete de internet

No fim do dia, as telas do pregão se apagam.

Os influenciadores fecham seus rankings.

Os consultores recolhem seus slides.

Os desenvolvedores encerram seus vídeos sobre a “linguagem que acabará com todas as outras”.

Mas, em algum lugar, um job entra no JES.

Um programa COBOL abre arquivos.

Consulta tabelas.

Processa milhões de registros.

Aplica regras criadas durante décadas.

Gera lançamentos.

Atualiza saldos.

Produz relatórios.

Dispara mensagens.

Fecha o movimento.

A empresa acordará no dia seguinte porque esse processamento terminou corretamente.

Essa é a realidade que o gráfico não consegue mostrar.

COBOL não lidera os rankings de entusiasmo.

Não domina os repositórios públicos.

Não produz a maior quantidade de tutoriais coloridos.

Não aparece diariamente nas discussões das startups.

Ainda assim, permanece onde o dinheiro, os contratos, os registros e as obrigações precisam ser processados com consistência.

O iniciante deve abandonar dois medos.

O primeiro é o medo de que COBOL desapareça amanhã.

O segundo é a ilusão de que aprender somente COBOL garantirá o futuro.

A estratégia vencedora está no meio.

Conheça profundamente o legado.

Aprenda os sistemas que o cercam.

Entenda o negócio.

Domine integração.

Use ferramentas modernas.

Estude APIs, Git, automação, testes, cloud, segurança e inteligência artificial.

Transforme-se no profissional capaz de entrar na sala onde o veterano conhece o passado e o arquiteto conhece o futuro — e conversar com ambos.

Porque o mercado não paga apenas por código.

Paga por confiança.

Paga por continuidade.

Paga por alguém que saiba qual programa pode ser alterado, qual regra deve ser preservada e qual processo jamais poderá falhar no último dia útil do mês.

No pregão das linguagens, modas sobem e descem.

Frameworks tornam-se estrelas e desaparecem.

Empresas nascem avaliadas em bilhões e terminam vendendo os móveis.

Enquanto isso, o velho COBOL permanece sentado no fundo da sala, tomando café, processando a folha de pagamento de todos os presentes.

Ele não está preocupado com o gráfico.

Ele é o sistema que imprime o extrato.


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