☕ 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

sábado, 25 de setembro de 2021

Yak Shaving Rules: Quando um Programador COBOL Entrou na Matrix para Corrigir um Bug... e Quase Reinventou Todo o Sistema

 

Bellacosa Mainframe e a yak shaving rules

☕ Um Café no Bellacosa Mainframe

Yak Shaving Rules sem Mistérios

Quando um Programador COBOL Entrou na Matrix para Corrigir um Bug... e Quase Reinventou Todo o Sistema

"Você entrou na Matrix para resolver um problema. Mas antes decidiu atualizar o compilador, reorganizar os COPYBOOKs, trocar o editor, renomear variáveis, revisar o JCL... e esqueceu qual era o problema."


Introdução — Bem-vindo ao Labirinto da Matrix

A chuva verde de caracteres desce lentamente pelas telas.

Neo observa uma pequena mensagem piscando em vermelho.

ABEND S0C7

— Morpheus, encontramos o problema?

Morpheus responde calmamente:

— Ainda não.

Neo estranha.

— Mas acabamos de passar oito horas trabalhando.

Morpheus sorri.

— Sim.

Você atualizou o ambiente.

Padronizou os comentários.

Organizou as bibliotecas.

Criou um novo padrão de nomenclatura.

Instalou uma versão mais nova do editor.

Revisou o JCL.

Atualizou o Git.

Refatorou um programa que nem estava relacionado.

Criou documentação.

Mudou o tema do ISPF.

...

Mas o ABEND continua acontecendo.

Neo olha assustado.

— Então o que aconteceu?

O Oráculo responde:

"Você começou a aparar um iaque."

Assim nasce um dos conceitos mais curiosos da Engenharia de Software.

O famoso Yak Shaving.

Ele parece engraçado.

Mas custa milhões de dólares por ano em produtividade desperdiçada.


O que é Yak Shaving?

Yak Shaving significa:

Executar uma longa sequência de tarefas secundárias antes de finalmente resolver o problema original.

Você começa tentando resolver um problema simples.

No caminho encontra outro.

Depois outro.

Depois outro.

Quando percebe...

esqueceu completamente o motivo inicial.


Uma definição divertida

Imagine que alguém diga:

"Preciso cortar o cabelo."

Mas para cortar o cabelo precisa:

  • pegar o carro

  • abastecer

  • trocar o óleo

  • lavar o carro

  • calibrar pneus

  • renovar o seguro

  • comprar um GPS novo

  • instalar aplicativo

  • atualizar o celular

No final do dia...

o cabelo continua igual.

Isso é Yak Shaving.


A origem do termo

O nome surgiu na década de 1990.

Foi popularizado por Carlin Vieri e posteriormente difundido por MIT AI Lab e por programadores da comunidade Unix.

A inspiração veio de uma piada do humorista Ren & Stimpy.

A ideia era mostrar uma sequência absurda de tarefas onde uma ação aparentemente simples leva a dezenas de outras completamente inesperadas.

Desde então, Yak Shaving virou um termo clássico na Engenharia de Software.


Por que "Yak"?

Porque um iaque é um enorme bovino peludo do Himalaia.

A piada consiste justamente em imaginar alguém que precisa raspar um iaque antes de conseguir fazer outra tarefa completamente diferente.

É uma imagem absurda.

E exatamente por isso funciona tão bem.


Matrix explica perfeitamente

Imagine que Neo recebe uma missão.

Corrigir um programa COBOL responsável pelo cálculo do imposto.

Parece simples.

Mas então...


Missão 1

"Vou abrir o programa."

Antes...

precisa atualizar o editor.


Missão 2

Editor atualizado.

Agora percebe que o compilador está antigo.


Missão 3

Atualiza o compilador.

Agora alguns COPYBOOKs ficaram incompatíveis.


Missão 4

Atualiza COPYBOOKs.

Agora resolve reorganizar toda a biblioteca.


Missão 5

Aproveita para mudar o padrão dos nomes.


Missão 6

Já que mudou nomes...

resolve atualizar a documentação.


Missão 7

Agora cria diagramas.


Missão 8

Descobre que seria interessante migrar para GitFlow.


Missão 9

Aproveita para atualizar Jenkins.


Missão 10

O dia termina.

O bug original?

Continua lá.

O Agente Smith agradece.


Como nasce o Yak Shaving?

Geralmente começa assim.

"Já que estou aqui..."

Essa talvez seja a frase mais perigosa da Engenharia de Software.


"Já que estou neste programa..."

"Já que estou nesta rotina..."

"Já que estou compilando..."

"Já que estou mexendo..."

...

Horas depois...

o objetivo inicial desapareceu.


Exemplo COBOL

O usuário informou:

Cliente não consegue emitir boleto.

Problema simples.

Mas o desenvolvedor pensa:

"Vou aproveitar."

Então decide:

  • reorganizar WORKING-STORAGE

  • padronizar comentários

  • alinhar colunas

  • renomear variáveis

  • trocar GO TO por PERFORM

  • atualizar COPYBOOK

  • reorganizar PROCEDURE DIVISION

  • alterar indentação

Resultado?

O boleto continua sem funcionar.


O cérebro gosta disso

Curiosamente...

Yak Shaving é confortável.

Resolver tarefas pequenas produz sensação de progresso.

É muito mais agradável organizar nomes de variáveis do que investigar um erro complexo.

Nosso cérebro adora pequenas vitórias.

Por isso caímos nessa armadilha.


O problema real continua esperando

Enquanto você reorganiza detalhes...

o cliente continua parado.

O banco continua sem processar pagamentos.

O lote continua falhando.

O incidente continua aberto.


A diferença entre Yak Shaving e Refatoração

Muita gente confunde.

Não são iguais.

Refatoração

Melhora código relacionado ao problema.

Tem objetivo claro.

Entrega valor.


Yak Shaving

Executa dezenas de tarefas paralelas sem necessidade imediata.

Aumenta tempo.

Não resolve o problema principal.


Existe Yak Shaving bom?

Sim.

Às vezes.

Imagine.

Você precisa alterar um programa.

Antes percebe:

  • biblioteca corrompida

  • ambiente quebrado

  • compilador incompatível

Corrigir isso não é Yak Shaving.

É pré-requisito.

O segredo está na pergunta:

Essa atividade aproxima ou afasta da solução?


Matrix Reloaded

Na Matrix existe um personagem fascinante.

O Arquiteto.

Ele entende toda a estrutura.

Um bom arquiteto de software também evita Yak Shaving.

Porque consegue separar:

necessário

de

interessante.

Nem tudo que é interessante precisa ser feito agora.


Como identificar Yak Shaving?

Faça uma pergunta simples.

"Estou fazendo isso porque resolve o problema ou porque surgiu oportunidade?"

Se a resposta for:

"Já que estou aqui..."

acenda um alerta.


O Programador Padawan

Todo iniciante passa por isso.

Recebe um pequeno chamado.

Vai investigar.

Três horas depois está lendo documentação sobre VSAM RLS.

Cinco horas depois aprende DFSORT.

Sete horas depois instala uma nova fonte no VS Code.

No dia seguinte...

descobre que o problema era:

IF CPF = SPACES

O efeito dominó

Yak Shaving possui um comportamento interessante.

Cada nova tarefa gera outra.

Por exemplo.

Corrigir documentação.

↓

Descobre padrão antigo.

↓

Atualiza modelo.

↓

Percebe que Wiki está desorganizada.

↓

Resolve reorganizar Wiki.

↓

Atualiza links.

↓

Cria templates.

↓

Muda identidade visual.

↓

...

O problema inicial desapareceu.


Os Agentes Smith adoram Yak Shaving

Na Matrix, Smith cresce distraindo Neo.

No desenvolvimento acontece igual.

Quanto mais tarefas paralelas surgem...

menos energia sobra para o problema verdadeiro.

Smith não precisa impedir você.

Basta manter você ocupado.


Gestão de Projetos

Em projetos grandes isso custa caro.

Imagine uma Sprint de duas semanas.

Uma tarefa estimada em:

8 horas.

Após Yak Shaving.

Consome:

32 horas.

Ninguém entende por quê.

Na verdade...

o desenvolvedor trabalhou bastante.

Só trabalhou nas coisas erradas.


Como gestores combatem isso?

Scrum Masters fazem perguntas importantes.

Qual é o objetivo?

Essa atividade agrega valor?

Está no escopo?

Quem pediu?

É prioridade?

Pode esperar?

Essas perguntas quebram o ciclo.


Técnicas para evitar Yak Shaving

Defina objetivo claro

Antes de abrir o editor escreva:

"Hoje vou corrigir o cálculo do IOF."

Nada além disso.


Use lista de estacionamento

Encontrou outra melhoria?

Anote.

Não faça agora.


Time Boxing

Reserve tempo.

Exemplo:

90 minutos.

Depois reavalie.


Trabalhe por prioridade

Cliente primeiro.

Curiosidade depois.


Faça pequenas entregas

Entregas frequentes diminuem distrações.


Atenção!

Existe uma diferença enorme entre:

Melhorar

e

Perfeccionismo.

Perfeccionismo muitas vezes é Yak Shaving disfarçado.


Os perigos

Atrasos

Cronograma explode.


Retrabalho

Mudanças desnecessárias geram novos bugs.


Escopo infinito

Projeto nunca termina.


Burnout

Equipe trabalha muito.

Entrega pouco.


Perda de foco

Objetivo desaparece.


Um exemplo clássico no Mainframe

Chamado:

Alterar mensagem do CICS.

Durante a alteração:

Atualiza BMS.

↓

Atualiza mapa.

↓

Padroniza cores.

↓

Renomeia campos.

↓

Refatora tratamento.

↓

Atualiza transações.

↓

Altera HELP.

↓

Reorganiza COPYBOOK.

↓

Atualiza manual.

↓

Muda nomenclatura.

↓

Novo teste.

↓

Novo Build.

↓

Nova homologação.

↓

Duas semanas depois...

A mensagem ainda não mudou.


Como o Oráculo resolveria?

Ela perguntaria apenas:

"O que realmente precisa acontecer?"

Essa pergunta elimina metade do Yak Shaving.


Aplicabilidade

Conhecer Yak Shaving ajuda em:

  • COBOL

  • CICS

  • Db2

  • DevOps

  • Cloud

  • IA

  • Engenharia de Dados

  • Projetos Ágeis

  • Infraestrutura

  • Segurança

Na verdade...

qualquer área técnica sofre com isso.


Curiosidades

Grandes empresas treinam desenvolvedores para reconhecer Yak Shaving.

Google possui diversas palestras internas sobre foco.

Microsoft fala sobre "Task Switching".

IBM enfatiza planejamento incremental.

Todas estão combatendo exatamente o mesmo problema.


O Checklist Anti-Yak

Antes de começar pergunte:

✅ Isso resolve o problema principal?

✅ O cliente percebe valor?

✅ Está dentro da Sprint?

✅ É realmente necessário agora?

✅ Posso anotar para depois?

Se respondeu "não" para a maioria...

provavelmente um iaque está esperando por você.


O Ensinamento de Morpheus

Morpheus entrega a Neo uma última mensagem.

"A Matrix não vence apenas pela força.
Ela vence pela distração."

Na Engenharia de Software acontece exatamente igual.

Poucos projetos fracassam porque seus desenvolvedores são incompetentes.

Muitos fracassam porque perderam o foco.


Lições para um Programador COBOL Padawan

Ao trabalhar em um sistema legado, é comum encontrar dezenas de oportunidades de melhoria. Um COPYBOOK poderia ser reorganizado, uma variável poderia ter um nome melhor, um programa poderia ser dividido em módulos menores, um JCL poderia ser simplificado. Tudo isso tem valor — mas nem tudo tem prioridade.

O verdadeiro profissional aprende a distinguir entre o trabalho importante e o trabalho interessante. Resolver o incidente que impede milhares de clientes de realizar uma transação é mais importante do que reorganizar comentários em um programa que funciona perfeitamente. As melhorias devem ser registradas, planejadas e executadas no momento adequado, não durante uma correção crítica.


Conclusão — Saindo da Matrix

No final de sua jornada, Neo compreende que a Matrix não era apenas um sistema de controle, mas também um sistema de distrações. Na Engenharia de Software, o Yak Shaving desempenha exatamente esse papel: cria uma sequência aparentemente lógica de tarefas secundárias que afastam a equipe do objetivo principal.

Para um Programador COBOL, especialmente em ambientes IBM Z onde cada alteração pode impactar processos críticos de bancos, seguradoras ou governos, manter o foco é uma habilidade tão importante quanto dominar a linguagem. Antes de iniciar qualquer atividade, pergunte a si mesmo:

  • Isso resolve o problema do cliente?

  • Isso agrega valor agora?

  • Estou caminhando em direção à solução ou apenas aparando um iaque?

Se a resposta indicar que você está entrando em um labirinto de tarefas paralelas, faça como Neo ao enxergar o código da Matrix: pare, respire, volte ao objetivo original e siga pelo caminho mais direto. Afinal, os melhores engenheiros não são aqueles que fazem mais coisas, mas aqueles que resolvem as coisas certas, no momento certo, com a menor complexidade possível. Esse é o verdadeiro caminho para escapar da Matrix do Yak Shaving e construir software que realmente faz diferença.

sexta-feira, 24 de setembro de 2021

ABEND sem Mistérios — Parte VII

 

Bellacosa Mainframe em abend sem misterio parte vii

☕ Um Café no Bellacosa Mainframe

ABEND sem Mistérios — Parte VII

Os 100 Erros Mais Comuns dos Programadores COBOL que Acabam Gerando ABENDs (e Como os Grandes Bancos Evitam Cada Um Deles)

"Quase nenhum ABEND nasce de um único erro. Ele costuma ser o resultado de pequenas decisões aparentemente inocentes que foram se acumulando até encontrar o momento perfeito para falhar."


Introdução

Depois de entender:

  • o que é um ABEND;

  • como investigá-lo;

  • como analisar dumps;

  • como funciona a arquitetura do IBM Z;

  • como utilizar observabilidade;

  • como criar laboratórios de treinamento;

chegamos a uma pergunta extremamente importante.

Por que tantos ABENDs continuam acontecendo?

A resposta surpreende muita gente.

Na maioria das vezes, não é por causa do compilador.

Nem do JCL.

Nem do z/OS.

Nem do CICS.

Muito menos do hardware IBM Z.

Na prática, a maior parte dos incidentes nasce de pequenos erros de desenvolvimento que poderiam ter sido evitados.

É exatamente por isso que grandes bancos investem tanto em padrões de programação, revisões técnicas, testes automatizados e engenharia preventiva.

Neste artigo reunimos os erros mais frequentes encontrados em projetos COBOL corporativos e as práticas utilizadas para evitá-los.


O verdadeiro custo de um pequeno erro

Imagine uma variável.

01 WS-SALDO PIC 9(09)V99.

Agora imagine que um arquivo carregue:

12A4500

Nenhum cliente percebe.

Nenhum operador percebe.

Nenhum batch falha imediatamente.

Horas depois...

COMPUTE

↓

S0C7

↓

Rollback

↓

Fila parada

↓

Chamado de Produção

O problema começou muito antes do ABEND.


Os cinco grupos de erros

Praticamente todos os incidentes podem ser classificados em cinco categorias.

Dados

↓

Lógica

↓

Integração

↓

Infraestrutura

↓

Processos

Vamos explorar cada uma delas.


Grupo 1 — Erros de Dados

São disparadamente os mais comuns.


Erro 1

Não validar campos numéricos.

Resultado.

S0C7.

Boa prática.

Sempre utilizar:

IF campo NUMERIC

Erro 2

Assumir que um arquivo sempre virá correto.

Arquivos mudam.

Layouts evoluem.

Campos chegam em branco.

Sistemas fornecedores falham.

Nunca confie cegamente na entrada.


Erro 3

Ignorar FILE STATUS.

Uma simples instrução OPEN pode falhar.

Sem tratamento adequado,

o programa continua executando até produzir consequências mais graves.


Erro 4

Ignorar SQLCODE.

O SELECT pode não encontrar registros.

O UPDATE pode falhar.

O COMMIT pode ser rejeitado.

Sempre teste SQLCODE.


Erro 5

Ignorar RESP e RESP2 no CICS.

Esses códigos são equivalentes ao SQLCODE do ambiente transacional.

Não tratá-los significa dirigir sem painel de instrumentos.


Grupo 2 — Erros de Lógica


Erro 6

PERFORM infinito.

Resultado.

S322

Boa prática.

Toda repetição deve possuir condição clara de encerramento.


Erro 7

Índices fora do OCCURS.

Principal causa de inúmeros S0C4.

Sempre valide limites.


Erro 8

Variáveis não inicializadas.

Nunca suponha que memória contém zeros.

Use INITIALIZE quando fizer sentido e inicialize explicitamente áreas críticas.


Erro 9

REDEFINES utilizado sem documentação.

REDEFINES é poderoso.

Mas também é uma das maiores fontes de confusão em sistemas antigos.


Erro 10

Uso excessivo de GO TO.

Quanto maior o número de desvios,

mais difícil torna-se reproduzir problemas.


Grupo 3 — Integração


Erro 11

Copybooks incompatíveis.

Programa A espera:

100 bytes

Programa B envia:

120 bytes

Resultado.

S0C4.


Erro 12

CALL USING incompatível.

Mudança em parâmetros sem recompilar todos os módulos.

Problema extremamente comum em aplicações legadas.


Erro 13

Layouts de arquivos desatualizados.

Uma alteração aparentemente simples pode afetar dezenas de programas.


Erro 14

Interfaces sem versionamento.

Grandes bancos tratam contratos de interface como código-fonte.


Grupo 4 — Infraestrutura


Erro 15

STEPLIB incorreta.

Resultado.

S806

Erro 16

DCB incompatível.

Resultado.

S013

Erro 17

Datasets pequenos.

Resultado.

SB37

SD37

SE37

Erro 18

TIME insuficiente.

Resultado.

S322

Erro 19

Catálogo inconsistente.

Nem sempre o problema está na aplicação.


Grupo 5 — Engenharia de Software

Aqui aparecem os erros mais caros.


Erro 20

Falta de logs.

Sem informações,

investigar torna-se muito mais difícil.


Erro 21

Ausência de documentação.

Quando apenas uma pessoa entende um programa,

o risco operacional aumenta significativamente.


Erro 22

Não reproduzir o incidente.

Corrigir "no escuro" costuma gerar novos problemas.


Erro 23

Não escrever testes.

A correção resolve o incidente atual,

mas ninguém garante que outro desenvolvedor não reintroduzirá o mesmo defeito.


Erro 24

Não documentar a causa raiz.

Todo incidente importante deveria gerar conhecimento.


Os erros que quase nunca aparecem nos livros

Alguns problemas são extremamente frequentes na vida real.

Por exemplo.

Alteração de layout sem avisar outras equipes.

↓

Mudança de copybook.

↓

Programa recompilado parcialmente.

↓

Ambiente inconsistente.

↓

Produção.

↓

ABEND.

Tecnicamente,

ninguém escreveu código errado.

O problema foi comunicação.


O perigo das suposições

Um excelente programador desconfia de tudo.

Pergunta:

O arquivo realmente existe?

O retorno foi validado?

A variável foi inicializada?

O parâmetro chegou corretamente?

A transação ainda está instalada?

Essa postura reduz enormemente os incidentes.


Como pensam os grandes bancos

Muitas empresas utilizam listas de verificação antes do deploy.

Exemplo.

  • SQLCODE tratado?

  • FILE STATUS tratado?

  • RESP tratado?

  • Índices validados?

  • Logs suficientes?

  • Testes executados?

  • Revisão realizada?

  • Plano de rollback pronto?

Esse checklist evita inúmeros problemas.


O princípio da programação defensiva

Programação defensiva significa assumir que algo pode dar errado.

Em vez de escrever:

ADD WS-VALOR TO TOTAL

O profissional escreve:

IF WS-VALOR NUMERIC
    ADD WS-VALOR TO TOTAL
ELSE
    PERFORM TRATAR-ERRO
END-IF

O objetivo não é tornar o código maior.

É torná-lo mais confiável.


A importância da revisão de código

Um desenvolvedor acostuma-se com seu próprio código.

Por isso revisões entre colegas são tão valiosas.

Muitas falhas simples são descobertas antes mesmo dos testes.

Revisar código não é fiscalizar pessoas.

É proteger o sistema.


Testes automatizados no Mainframe

Cada vez mais equipes utilizam:

  • IBM Developer for z/OS;

  • IBM Test Accelerator;

  • ZUnit;

  • Jenkins;

  • GitHub Actions;

  • UrbanCode Deploy;

  • Ansible.

A ideia é simples.

Sempre que uma alteração ocorrer,

os principais cenários são executados automaticamente.

Assim, regressões são identificadas antes da produção.


Os dez mandamentos do Programador COBOL

  1. Nunca confie nos dados de entrada.

  2. Sempre trate retornos do sistema.

  3. Valide limites de tabelas.

  4. Documente alterações importantes.

  5. Escreva logs úteis.

  6. Faça revisões de código.

  7. Teste cenários de erro, não apenas os de sucesso.

  8. Automatize sempre que possível.

  9. Investigue antes de corrigir.

  10. Compartilhe conhecimento com a equipe.


O ciclo dos incidentes

Os sistemas mais maduros seguem um ciclo contínuo.

Erro

↓

ABEND

↓

Investigação

↓

Root Cause

↓

Correção

↓

Teste

↓

Documentação

↓

Automação

↓

Novo Padrão

↓

Menos ABENDs

Cada incidente fortalece a organização.


O Programador Padawan e o Especialista

O Padawan pergunta:

"Como elimino este S0C7?"

O especialista pergunta:

"Como impedir que qualquer programa desta empresa gere esse mesmo S0C7 novamente?"

Essa diferença de perspectiva muda completamente a qualidade do software.


Construindo uma cultura de qualidade

As organizações mais bem-sucedidas não dependem de heróis que resolvem incidentes às três da manhã.

Elas constroem processos que tornam esses incidentes cada vez mais raros.

Isso inclui:

  • padrões de codificação;

  • revisão por pares;

  • integração contínua;

  • testes automatizados;

  • observabilidade;

  • documentação;

  • treinamento constante.

Quando essas práticas amadurecem, o número de ABENDs em produção tende a cair de forma consistente.


Conclusão

Os ABENDs não surgem do nada. Eles são o reflexo da qualidade das decisões tomadas ao longo do ciclo de desenvolvimento.

Cada variável validada, cada SQLCODE tratado, cada FILE STATUS verificado, cada revisão de código e cada teste automatizado representam pequenas barreiras que impedem que um erro simples evolua para um incidente crítico.

Os grandes bancos sabem disso há décadas. Por essa razão, investem muito mais em prevenção do que em correção. A investigação continua sendo importante, mas seu verdadeiro objetivo é produzir aprendizado, melhorar processos e reduzir a probabilidade de novos incidentes.

O Programador Padawan que compreender essa filosofia deixará de ver o ABEND como um inimigo. Passará a enxergá-lo como um indicador da saúde do sistema e uma oportunidade de tornar suas aplicações mais seguras, previsíveis e resilientes.

Porque, no fim das contas, a melhor investigação é aquela que um dia deixa de ser necessária.


quinta-feira, 23 de setembro de 2021

☕🔥 OS MELHORES ANIMES/MANGÁS PÓS-APOCALÍPTICOS — UMA ANÁLISE NO ESTILO BELLACOSA MAINFRAME

 

Bellacosa Mainframe e os animes pós-apocalipticos

☕🔥 OS MELHORES ANIMES/MANGÁS PÓS-APOCALÍPTICOS — UMA ANÁLISE NO ESTILO BELLACOSA MAINFRAME

☕🔥 Os melhores animes e mangás pós-apocalípticos exploram profundamente a psicologia humana porque colocam seus personagens em cenários onde a civilização entrou em colapso. Quando o mundo acaba, desaparecem também as leis, a segurança, o conforto e até a identidade social das pessoas. O resultado é um ambiente perfeito para revelar os medos, traumas e instintos mais primitivos do ser humano.

Em obras como Neon Genesis Evangelion, o apocalipse funciona como metáfora da depressão, da solidão e do vazio emocional. Shinji Ikari não luta apenas contra monstros gigantes; ele luta contra rejeição, medo de abandono e incapacidade de se conectar com outras pessoas. Já em Attack on Titan, o horror psicológico nasce da descoberta de que o verdadeiro inimigo muitas vezes não são os monstros, mas o ódio, o nacionalismo e os ciclos de violência humana.

Outro ponto central nesses animes é a desumanização. Em 86, soldados discriminados são tratados como máquinas descartáveis, refletindo temas como racismo, guerra e perda da individualidade. O mesmo ocorre em Shinsekai Yori, que aborda controle social, medo coletivo e manipulação psicológica em uma sociedade aparentemente perfeita.

O pós-apocalipse japonês também trabalha fortemente o existencialismo. Em mundos destruídos, os personagens precisam encontrar razões para continuar vivendo. Obras como Made in Abyss mostram a curiosidade humana enfrentando sofrimento extremo, enquanto 7Seeds explora o trauma de sobreviver em um planeta irreconhecível.

Diferente de muitos cenários ocidentais focados apenas em ação, os animes pós-apocalípticos japoneses usam a destruição do mundo como ferramenta para investigar a mente humana. O verdadeiro tema raramente é “como salvar o planeta”, mas sim:
quem somos quando tudo aquilo que conhecemos desaparece.

É justamente essa profundidade psicológica que torna essas obras tão marcantes e inesquecíveis.

☕🔥 OS MELHORES ANIMES/MANGÁS PÓS-APOCALÍPTICOS — UMA ANÁLISE NO ESTILO BELLACOSA MAINFRAME

O pós-apocalipse nos animes japoneses raramente é apenas “o fim do mundo”.
No Japão, destruição normalmente significa:

  • colapso social,

  • culpa coletiva,

  • trauma tecnológico,

  • guerra,

  • isolamento humano,

  • e principalmente a pergunta:

“O que sobra da humanidade quando a civilização desaparece?”

E isso faz MUITO sentido historicamente para um país marcado por Hiroshima, Nagasaki, terremotos, crises econômicas e medo nuclear.

Os títulos da imagem representam praticamente TODAS as vertentes do pós-apocalipse japonês:
cyberpunk, psicológico, existencialista, militar, filosófico, biológico, social e até espiritual.


01 — NEON GENESIS EVANGELION

Título original

新世紀エヴァンゲリオン
(Shinseiki Evangelion)

Autor

  • Hideaki Anno

  • Studio Gainax

Lançamento

  • Anime: 1995

  • Filme End of Evangelion: 1997

  • Mangá: 1994–2013


Sinopse

Após uma catástrofe global chamada “Second Impact”, monstros chamados Angels atacam a Terra.
A organização NERV utiliza biomechas gigantes chamados EVAs pilotados por adolescentes traumatizados.


O que Evangelion REALMENTE é?

Muita gente acha que Evangelion é anime de robô.

Não é.

Evangelion é:

  • depressão,

  • ansiedade,

  • solidão,

  • medo de rejeição,

  • trauma emocional,

  • colapso psicológico.

Os EVAs são praticamente metáforas ambulantes da mente humana.


História e contexto

Hideaki Anno criou Evangelion durante uma profunda depressão.

Por isso:

  • os personagens são quebrados emocionalmente,

  • o mundo parece vazio,

  • as relações humanas são dolorosas,

  • a narrativa vira quase terapia psicológica.

O “fim do mundo” aqui é interno.


Personagens principais

Shinji Ikari

Talvez o protagonista mais humano dos animes.
Fraco, inseguro, traumatizado.

Rei Ayanami

Símbolo da identidade vazia e da desconexão emocional.

Asuka Langley

Orgulho mascarando desespero psicológico.

Gendo Ikari

Pai ausente transformado em entidade quase monstruosa.


Temática principal

  • Existencialismo

  • Freud/Jung

  • Solidão

  • Relacionamentos tóxicos

  • Instrumentalização humana

  • Trauma pós-guerra


O diferencial

Evangelion destruiu o gênero mecha tradicional.

Antes:

  • heróis fortes,

  • batalhas épicas.

Depois:

  • pilotos traumatizados,

  • colapso mental,

  • filosofia pesada,

  • simbolismo religioso.

É praticamente o “COBOL legado psicológico” dos animes modernos:
todo mundo herdou algo dele.


02 — 86: EIGHTY-SIX

Título original

86―エイティシックス―

Autor

  • Asato Asato

  • Ilustrações: Shirabii

Lançamento

  • Light Novel: 2017

  • Anime: 2021


Sinopse

A República de San Magnolia afirma lutar uma guerra automatizada sem baixas humanas.

Mentira.

Os “drones” são pessoas discriminadas chamadas Eighty-Six.


O que torna 86 tão poderoso?

Esse anime é brutal porque fala de:

  • racismo,

  • segregação,

  • guerra desumanizada,

  • propaganda estatal,

  • soldados descartáveis.


Influências históricas

É impossível assistir sem lembrar:

  • nazismo,

  • campos de segregação,

  • guerras modernas,

  • drones militares reais,

  • imperialismo.


Personagens

Shinei Nouzen

Um dos protagonistas mais melancólicos da ficção recente.

Vladilena Milizé

A idealista que tenta manter humanidade dentro do sistema.


Temática

  • Desumanização

  • PTSD

  • Guerra automatizada

  • Culpa social

  • Xenofobia


Diferencial

86 moderniza o conceito de guerra pós-apocalíptica.

Aqui o horror não é o monstro.

É o próprio sistema.


03 — SHINSEKAI YORI

Título original

新世界より
(From the New World)

Autor

  • Yusuke Kishi

Lançamento

  • Novel: 2008

  • Anime: 2012


A OBRA MAIS SUBESTIMADA DESSA LISTA


Sinopse

Mil anos no futuro, humanos desenvolveram poderes psíquicos.

A sociedade parece utópica.

Mas existe algo profundamente errado escondido nela.


O que esse anime faz?

Ele desmonta lentamente:

  • moralidade,

  • controle social,

  • manipulação genética,

  • medo coletivo.


Atmosfera

O anime inteiro parece:

  • silencioso,

  • estranho,

  • desconfortável,

  • quase “amaldiçoado”.

Você sente que existe um segredo horrível desde o episódio 1.


Temática

  • Eugenia

  • Controle populacional

  • Totalitarismo

  • Evolução humana

  • Medo da diferença


O diferencial

É um dos raros animes que mistura:

  • horror psicológico,

  • ficção científica,

  • sociologia,

  • filosofia política.

Parece uma mistura de:

  • Orwell,

  • Brave New World,

  • Akira,

  • Evangelion.


04 — SHINGEKI NO KYOJIN

Attack on Titan

Autor

  • Hajime Isayama

Lançamento

  • Mangá: 2009

  • Anime: 2013


Sinopse

Humanidade vive cercada por muralhas gigantes para sobreviver aos Titãs.

Mas a verdade sobre o mundo muda completamente a narrativa.


O MAIOR “PLOT TWIST” DA DÉCADA

O anime começa como:

  • sobrevivência contra monstros.

Depois vira:

  • geopolítica,

  • guerra racial,

  • nacionalismo,

  • fascismo,

  • ciclos de ódio.


Personagens

Eren Yeager

Talvez o protagonista mais controverso dos animes modernos.

Levi Ackerman

Frieza emocional absoluta.

Erwin Smith

Liderança sacrificando humanidade.


Temas

  • Liberdade

  • Determinismo

  • Ódio histórico

  • Militarismo

  • Genocídio

  • Manipulação política


O diferencial

Poucos animes evoluem tanto de escala narrativa.

O mundo cresce de:
“Titan gigante”
para:
“civilização em guerra ideológica”.


05 — AKIRA

Autor

  • Katsuhiro Otomo

Lançamento

  • Mangá: 1982

  • Filme: 1988


O ANIME QUE OCIDENTALIZOU O ANIME

Sem Akira:

  • Matrix talvez não existisse,

  • cyberpunk moderno mudaria,

  • anime não teria explodido no Ocidente.


Sinopse

Neo Tokyo foi reconstruída após uma explosão misteriosa.

Gangues, corrupção, governo militar e experimentos psíquicos dominam a cidade.


Temática

  • medo nuclear,

  • militarização,

  • juventude perdida,

  • explosão tecnológica,

  • caos urbano.


O diferencial

Akira foi revolucionário tecnicamente:

  • animação absurda,

  • iluminação cinematográfica,

  • direção de câmera quase hollywoodiana.

Ainda parece moderno hoje.


06 — SHUUMATSU NANI SHITEMASU KA?

SukaSuka

Título gigante

終末なにしてますか?忙しいですか?救ってもらっていいですか?


Lançamento

  • Light Novel: 2014

  • Anime: 2017


Sinopse

Após o fim da humanidade, criaturas não humanas vivem em ilhas flutuantes enquanto jovens garotas usam armas mágicas para lutar contra monstros.


O diferencial

Ao contrário dos outros:

  • não é ação pesada,

  • é melancolia emocional.

É uma obra sobre:

  • despedida,

  • amor inevitavelmente trágico,

  • aceitar o fim.


Atmosfera

Parece:

  • bonita,

  • triste,

  • silenciosa,

  • poética.


07 — SIDONIA NO KISHI

Knights of Sidonia

Autor

  • Tsutomu Nihei

Lançamento

  • Mangá: 2009

  • Anime: 2014


Sinopse

Humanidade vaga pelo espaço após a destruição da Terra.

Criaturas alienígenas chamadas Gauna perseguem os últimos humanos.


Temática

  • transumanismo,

  • clonagem,

  • sobrevivência espacial,

  • evolução humana.


O diferencial

Tsutomu Nihei cria mundos:

  • frios,

  • industriais,

  • gigantescos,

  • silenciosos.

A arquitetura parece um “mainframe espacial brutalista”.


08 — 7SEEDS

Autor

  • Yumi Tamura

Lançamento

  • Mangá: 2001

  • Anime Netflix: 2019


Sinopse

Jovens são congelados criogenicamente para sobreviver ao colapso da humanidade.


Temática

  • sobrevivência extrema,

  • adaptação,

  • natureza hostil,

  • trauma psicológico.


O diferencial

O foco é sobrevivência REAL.

Sem glamour.
Sem heroísmo exagerado.

É quase um documentário psicológico de desastre.


09 — MADE IN ABYSS

Autor

  • Akihito Tsukushi

Lançamento

  • Mangá: 2012

  • Anime: 2017


O ANIME MAIS ENGANOSO DA LISTA

Parece infantil.

NÃO É.


Sinopse

Uma garota e um robô descem um gigantesco abismo cheio de criaturas e mistérios.


O que torna perturbador?

O Abyss funciona como:

  • inferno biológico,

  • exploração científica,

  • obsessão humana,

  • jornada sem retorno.


Temas

  • perda da inocência,

  • exploração,

  • sofrimento,

  • curiosidade humana.


O diferencial

A obra mistura:

  • visual fofo,

  • horror grotesco,

  • sofrimento extremo.

O contraste emocional é devastador.


10 — APOCALYPSE NO TORIDE

Autor

  • Yuu Kuraishi

  • Kazu Inabe

Lançamento

  • Mangá: 2011


Sinopse

Um presídio juvenil se torna zona de sobrevivência após um surto apocalíptico.


Temática

  • colapso social,

  • violência,

  • sobrevivência urbana,

  • paranoia.


Diferencial

É praticamente:
“Battle Royale encontra The Walking Dead”.

Muito mais brutal e claustrofóbico que outros títulos da lista.


☕ CONCLUSÃO — O QUE O PÓS-APOCALIPSE JAPONÊS TEM DE DIFERENTE?

No Ocidente:

  • o pós-apocalipse costuma focar ação.

No Japão:

  • o foco é trauma,

  • culpa coletiva,

  • perda da identidade,

  • falha da sociedade,

  • medo tecnológico,

  • desumanização.

O monstro quase nunca é o verdadeiro inimigo.

O inimigo geralmente é:

  • o sistema,

  • o Estado,

  • a guerra,

  • a solidão,

  • ou o próprio ser humano.

E talvez seja exatamente por isso que essas obras permanecem tão marcantes.

Porque elas não falam sobre o fim do mundo.

Elas falam sobre:

o que sobra da alma humana depois dele.


quarta-feira, 22 de setembro de 2021

📘 Visão Geral do Curso – IBM Z Resiliency

 


📘 Visão Geral do Curso – IBM Z Resiliency

Objetivo do curso

Compreender os conceitos de resiliência no IBM Z e o valor da recuperação rápida, mostrando por que o mainframe é a espinha dorsal de negócios digitais que não podem parar.

Público-alvo

  • Profissionais novos em resiliência no IBM Z

  • Analistas, operadores, sysprogs iniciantes

  • Profissionais de TI vindos de ambientes distribuídos que precisam entender por que o mainframe é diferente

👉 É um curso conceitual, não técnico profundo, focado em mentalidade, fundamentos e arquitetura.



🧠 Resumo Executivo (em uma frase)

O curso ensina por que o IBM Z foi projetado para não parar, como medir disponibilidade, quais mecanismos de hardware e software garantem isso, quais modelos de resiliência existem e como planejar sistemas realmente resilientes.


🔹 TÓPICO 1 – Resiliency: The key to the survival of a digital business

🎯 Objetivo do tópico

  • Entender como o downtime afeta clientes e usuários

  • Conhecer formas de medir disponibilidade

📌 Explicação prática

O que é Resiliência

Resiliência não é apenas alta disponibilidade.
É a capacidade de um sistema:

  • Continuar operando mesmo com falhas

  • Recuperar rapidamente

  • Minimizar impacto ao negócio e ao cliente

📢 Sistema resiliente não é o que nunca falha — é o que falha sem ser percebido.


💥 Impacto do downtime

Downtime afeta diretamente:

  • 💰 Receita (transações não realizadas)

  • 📉 Reputação da empresa

  • ⚖️ Compliance (bancos, seguradoras, governo)

  • 😡 Experiência do cliente

No mundo digital:

  • Milissegundos importam

  • Minutos custam milhões

  • Horas podem matar um negócio


📊 Como medir disponibilidade

Disponibilidade normalmente é medida como:

Disponibilidade (%) = (Tempo total – Tempo de indisponibilidade) / Tempo total

Exemplo clássico:

  • 99,9% (three nines) → ~8,7 horas de downtime por ano

  • 99,999% (five nines) → ~5 minutos por ano

👉 O IBM Z foi projetado para five nines ou mais, algo extremamente difícil em ambientes distribuídos.


🔹 TÓPICO 2 – IBM Reliability, Availability, Serviceability (RAS)

🎯 Objetivo

Descrever como hardware e software suportam a resiliência do IBM Z.

📌 O que é RAS

RAS é um princípio de engenharia, não um produto.

🔧 Reliability (Confiabilidade)

  • Componentes projetados para falhar menos

  • Detecção proativa de erros

  • Redundância física e lógica

Exemplos no IBM Z:

  • CPUs redundantes

  • Memória com ECC avançado

  • Detecção e correção automática de falhas


⏱ Availability (Disponibilidade)

  • Capacidade de continuar operando mesmo com falhas

  • Substituição de componentes sem desligar o sistema

Exemplos:

  • Hot swap de componentes

  • Workload sendo redistribuído automaticamente

  • Sysplex mascarando falhas de um nó


🛠 Serviceability (Manutenibilidade)

  • Diagnóstico rápido

  • Reparos sem impacto ao negócio

Exemplos:

  • Call Home automático para IBM

  • Logs detalhados de falha

  • Manutenção com sistema online

📢 No IBM Z, muitas falhas são corrigidas antes mesmo do cliente perceber.


🧠 Importante

RAS não é só hardware:

  • z/OS

  • CICS

  • DB2

  • JES

  • Sysplex

  • WLM

Tudo foi desenhado com a filosofia de nunca parar.


🔹 TÓPICO 3 – IBM Z Resiliency Models

🎯 Objetivo

Descrever as características dos quatro modelos de resiliência

📌 Os quatro modelos (visão conceitual)

1️⃣ Single system resiliency

  • Um único IBM Z

  • Usa RAS para evitar falhas

  • Recuperação rápida, mas sem site alternativo

✔️ Bom para ambientes menores
❌ Vulnerável a desastres físicos


2️⃣ Local high availability

  • Uso de Sysplex

  • Múltiplos LPARs ou CPCs no mesmo site

  • Failover quase transparente

✔️ Altíssima disponibilidade
❌ Ainda dependente de um único local físico


3️⃣ Geographically Dispersed Parallel Sysplex (GDPS)

  • Sites geograficamente separados

  • Replicação de dados

  • Failover automatizado

✔️ Proteção contra desastre
✔️ Recovery Time Objective (RTO) muito baixo
💰 Custo mais elevado


4️⃣ Continuous availability / Business resilience

  • Zero downtime percebido

  • Planejamento extremo

  • Automação total

✔️ Missão crítica absoluta
✔️ Bancos, bolsas, governos
📢 Aqui o negócio não pode parar nunca.


🔹 TÓPICO 4 – Planning for Resiliency

🎯 Objetivo

Definir princípios que contribuem para a resiliência.

📌 Planejar resiliência não é comprar hardware

Princípios fundamentais:

🧩 1. Pensar em falhas como algo normal

  • Tudo falha

  • O plano deve assumir isso


📋 2. Definir RTO e RPO

  • RTO: quanto tempo posso ficar fora?

  • RPO: quanto dado posso perder?

Sem isso, não existe resiliência — só achismo.


🔁 3. Automação

  • Failover manual não escala

  • IBM Z foi feito para automação


🧪 4. Testar, testar e testar

  • Plano não testado = plano inexistente

  • DR sem teste falha quando é mais necessário


🧠 5. Pessoas e processos

  • Tecnologia sem pessoas treinadas não funciona

  • Documentação clara

  • Papéis definidos

📢 Resiliência é 50% tecnologia e 50% processo.


🧾 Conclusão Geral do Curso

Este curso:

  • Não ensina comandos

  • Não ensina instalação

  • Ensina mentalidade de resiliência no IBM Z

É ideal para:

  • Quem vem de cloud/distribuído

  • Quem acha que “mainframe é caro”

  • Quem nunca viu um sistema rodar anos sem downtime

terça-feira, 21 de setembro de 2021

Kōtetsujō no Kabaneri : Quando um Datacenter IBM Z Virou uma Fortaleza Sobre Trilhos e o ABEND da Humanidade Começou

 

Bellacosa Maiframe e a fortaleza sobre trilhos dos kabaneri

☕ Um Café no Bellacosa Mainframe

Kōtetsujō no Kabaneri (甲鉄城のカバネリ): Quando um Datacenter IBM Z Virou uma Fortaleza Sobre Trilhos e o ABEND da Humanidade Começou

O anime steampunk que ensina mais sobre Resiliência, Continuidade de Negócios e Engenharia de Sistemas do que muitos cursos corporativos


Introdução

Imagine que, em vez de servidores Linux espalhados pela nuvem, toda a humanidade dependesse de alguns poucos datacenters isolados, ligados apenas por uma infraestrutura ferroviária altamente protegida. Agora imagine que um malware biológico extremamente agressivo invadisse esses ambientes, transformando qualquer usuário infectado em um processo impossível de encerrar.

Esse é o universo de Kōtetsujō no Kabaneri, conhecido internacionalmente como Kabaneri of the Iron Fortress. Embora muitos o tenham chamado de "Attack on Titan com zumbis", essa comparação é simplista. A obra possui identidade própria, combinando horror, steampunk, drama, ação e uma interessante reflexão sobre tecnologia, isolamento, medo coletivo e sobrevivência.

Para quem trabalha com IBM Z, COBOL, Sysplex e Resiliência Operacional, assistir a esse anime é como observar um gigantesco exercício de Disaster Recovery em escala nacional.


Ficha Técnica

Título original: 甲鉄城のカバネリ (Kōtetsujō no Kabaneri)

Título internacional: Kabaneri of the Iron Fortress

Autor (conceito original): Ichirō Ōkouchi

Diretor: Tetsurō Araki

Estúdio: Wit Studio

Character Design: Haruhiko Mikimoto

Música: Hiroyuki Sawano

Lançamento: 8 de abril de 2016

Exibição: abril a junho de 2016

Episódios: 12

Continuação: Filme The Battle of Unato (2019)


Classificação

  • Ação

  • Horror

  • Pós-apocalíptico

  • Steampunk

  • Fantasia Sombria

  • Drama

  • Suspense

  • Sobrevivência

Classificação indicativa: aproximadamente 17+ devido à violência intensa, sangue e cenas de horror.


Sinopse

Durante uma Revolução Industrial alternativa no Japão, um vírus transforma seres humanos em criaturas chamadas Kabane. Diferentemente dos zumbis tradicionais, eles possuem um coração protegido por uma camada de aço, tornando-os extremamente difíceis de eliminar.

As cidades sobreviventes tornam-se fortalezas muradas, conectadas apenas por trens blindados. Quando uma dessas fortalezas cai, o jovem engenheiro Ikoma consegue sobreviver parcialmente à infecção, tornando-se um Kabaneri: um híbrido entre humano e Kabane.

A bordo da locomotiva Kotetsujō (Fortaleza de Ferro), Ikoma inicia uma jornada para salvar a humanidade enquanto luta contra os monstros externos e os preconceitos internos.


Resumo da História

A narrativa acompanha uma sociedade em colapso permanente. Não existe governo central forte, nem comunicação ampla entre as cidades. Cada estação ferroviária tornou-se praticamente um pequeno país.

O trem blindado Kotetsujō representa a última esperança de conexão entre esses enclaves. Durante a viagem, os personagens enfrentam ataques constantes dos Kabane, disputas políticas, traições, escassez de recursos e conflitos morais.

A história evolui de um simples combate contra monstros para uma reflexão sobre poder, manipulação e os limites da humanidade.


Os Personagens

Ikoma

O protagonista foge completamente do arquétipo clássico do herói musculoso.

É um engenheiro.

Um inventor.

Um solucionador de problemas.

Sua primeira reação diante da crise não é fugir, mas construir uma arma melhor.

No universo Bellacosa Mainframe, Ikoma seria aquele desenvolvedor COBOL que passa a madrugada inteira analisando um dump S0C7 até encontrar a verdadeira causa do problema.


Mumei

Talvez a personagem mais popular da série.

Ela é uma Kabaneri extremamente poderosa, treinada desde a infância para combater Kabane.

Por trás da aparência inocente existe uma guerreira marcada por manipulação psicológica, perda da infância e uma busca constante por identidade.


Ayame Yomogawa

Filha do governante da estação Aragane.

Representa liderança baseada em responsabilidade e empatia, contrastando com líderes que governam pelo medo.


Kurusu

Samurai encarregado da proteção de Ayame.

Inicialmente rígido e desconfiado, aprende que disciplina sem adaptação pode levar ao fracasso.


Biba Amatori

O antagonista principal.

Carismático, inteligente e estrategista, acredita que apenas o caos pode destruir uma sociedade considerada fraca.

Sua visão lembra administradores que preferem derrubar todo o ambiente para reconstruí-lo do zero, ignorando o custo humano dessa decisão.


O que torna Kabaneri diferente?

Embora muitos o comparem com Attack on Titan, existem diferenças importantes:

O cenário

Em vez de muralhas medievais, o mundo mistura:

  • locomotivas a vapor;

  • tecnologia industrial;

  • armamentos improvisados;

  • arquitetura inspirada no Japão do período Meiji.

O resultado é um dos cenários steampunk mais belos dos animes modernos.

Os zumbis

Os Kabane não são mortos-vivos lentos.

São rápidos, agressivos e possuem um coração protegido por ferro. Para derrotá-los é necessário precisão, estratégia e armas especializadas.

O protagonista

Ikoma vence pela inteligência e pela engenharia, não apenas pela força física.

A infraestrutura

O trem Kotetsujō não é apenas transporte: é uma cidade móvel, um centro logístico e uma linha de sobrevivência.


A análise Bellacosa Mainframe

Os Kabane são um malware impossível de erradicar

Pense nos Kabane como um ransomware de última geração.

Uma máquina comprometida infecta outra.

A propagação é exponencial.

Não existe antivírus.

Somente isolamento e contenção.


As fortalezas são Data Centers

Cada estação funciona como um grande ambiente IBM Z.

Possui:

  • energia;

  • armazenamento;

  • produção;

  • segurança;

  • usuários;

  • operações.

Quando uma estação cai, perde-se um centro inteiro de processamento.


O trem é um Parallel Sysplex

O Kotetsujō conecta ambientes isolados.

Transporta pessoas, recursos, conhecimento e esperança.

Se o trem parar, toda a infraestrutura nacional entra em colapso.

É praticamente um Parallel Sysplex sobre trilhos, garantindo continuidade operacional mesmo diante de falhas catastróficas.


Ikoma é um engenheiro DevOps

Enquanto outros apenas combatem sintomas, Ikoma busca entender a causa raiz.

Ele observa, testa, falha, ajusta e melhora continuamente.

É a mentalidade de um engenheiro que automatiza processos, otimiza pipelines e cria soluções resilientes em vez de depender apenas de esforço manual.


Biba representa o risco interno

Nem toda ameaça vem de fora.

No universo da segurança da informação, um atacante interno com privilégios elevados pode causar danos muito maiores do que qualquer invasor externo.

Biba simboliza exatamente essa ameaça: alguém que conhece o sistema profundamente e usa esse conhecimento para explorá-lo.


Mensagens ocultas

O medo destrói mais que o vírus

Grande parte das mortes ocorre porque pessoas entram em pânico ou passam a desconfiar umas das outras.

A obra mostra como sociedades podem ruir quando o medo substitui a cooperação.


Engenharia salva vidas

Sem manutenção, sem inovação e sem pessoas capazes de criar novas soluções, nenhuma fortaleza sobrevive.

O anime valoriza engenheiros, mecânicos e inventores tanto quanto guerreiros.


A tecnologia é neutra

O mesmo conhecimento capaz de salvar também pode ser usado para destruir.

Tudo depende da ética de quem o utiliza.


Humanidade é uma escolha

Os Kabaneri vivem entre dois mundos.

São vistos como monstros, mas continuam tentando agir com compaixão.

A pergunta central é: o que realmente define um ser humano? A aparência, a biologia ou as escolhas?


Aventuras marcantes

  • A queda da estação Aragane.

  • A fuga desesperada no Kotetsujō.

  • A adaptação de Ikoma à condição de Kabaneri.

  • Os combates contra Kabane gigantes.

  • A chegada à estação Kongōkaku.

  • O confronto ideológico com Biba.

  • A batalha final pela sobrevivência.

Cada arco amplia o universo e revela que o verdadeiro desafio não é apenas vencer os Kabane, mas impedir que o medo transforme os sobreviventes em algo igualmente perigoso.


Impacto cultural

Embora não tenha alcançado o fenômeno global de Attack on Titan, Kabaneri of the Iron Fortress conquistou reconhecimento por sua qualidade técnica. A animação da Wit Studio, a direção dinâmica de Tetsurō Araki e a trilha sonora de Hiroyuki Sawano são frequentemente apontadas como seus maiores destaques.

A série também ajudou a consolidar o estúdio como referência em animações de ação de alto nível, além de reforçar a popularidade do subgênero steampunk em um período dominado por isekais.


Houve censura?

Não houve censura significativa à obra em si, mas alguns canais de televisão japoneses exibiram versões com ajustes de iluminação e redução da intensidade visual em determinadas cenas muito violentas, prática comum em transmissões de TV. As versões lançadas em Blu-ray restauraram integralmente essas cenas.

Em alguns países, a classificação indicativa elevada limitou horários de exibição ou exigiu avisos de conteúdo devido à violência gráfica e ao horror.


Vale a pena assistir?

Sem dúvida.

Mesmo com críticas ao ritmo da segunda metade e ao desenvolvimento do antagonista, Kabaneri of the Iron Fortress permanece como uma das produções visualmente mais impressionantes da década de 2010. Sua combinação de ação frenética, estética steampunk, trilha sonora marcante e reflexões sobre sobrevivência, liderança e inovação faz dele uma experiência única.


Veredito Bellacosa Mainframe

Se The Walking Dead mostra como grupos sobrevivem ao colapso da sociedade e Attack on Titan explora o medo do desconhecido, Kabaneri of the Iron Fortress ensina que a continuidade de uma civilização depende de infraestrutura, engenharia, logística e pessoas capazes de inovar sob pressão.

Para um profissional de IBM Z, a maior lição do anime é clara:

Um datacenter resiliente não é aquele que nunca sofre ataques. É aquele que continua operando mesmo quando o impossível acontece.

E é exatamente isso que o Kotetsujō representa: uma fortaleza móvel onde tecnologia, disciplina, colaboração e coragem mantêm a humanidade "online", mesmo quando todo o restante do mundo entrou em ABEND.

segunda-feira, 20 de setembro de 2021

O Isekai Não Vende Magia. Ele Vende Demissão da Vida Real.

Bellacosa Mainframe e o isekai como um pedido de ajuda demissao da vida real



☕ Um Café no Bellacosa Mainframe

O Isekai Não Vende Magia. Ele Vende Demissão da Vida Real.

Quando um Programador COBOL Descobre que o Mundo Paralelo Talvez Seja Apenas um Pedido de HELP Nunca Respondido

Existem dias em que o despertador toca às 5h30 da manhã e você já acorda cansado.

Não porque dormiu pouco.

Mas porque sabe exatamente como será o resto do dia.

Ônibus lotado.

Metrô cheio.

Trânsito.

Oito, nove ou dez horas de trabalho.

Reuniões que poderiam ser e-mails.

Metas.

Pressão.

Planilhas.

Chamados.

Produção.

ABEND.

Correção.

Mais produção.

Depois de tudo isso...

Você volta para casa exausto.

Liga a televisão.

Abre um anime.

E o protagonista... morre atropelado por um caminhão.

Cinco minutos depois ele acorda em outro mundo.

Curiosamente...

Você sente inveja.


O Caminhão-kun Nunca Foi Sobre Caminhões

Durante anos fizemos piadas com o famoso Truck-kun.

Mas talvez ele nunca tenha sido o verdadeiro protagonista.

O caminhão não representa a morte.

Representa o fim.

O fim das cobranças.

O fim do relógio de ponto.

O fim da reunião marcada para sexta-feira às 17h.

O fim daquele gerente que responde "vamos alinhar" sempre que aparece um problema.

O protagonista não comemora porque morreu.

Ele comemora porque não precisa voltar ao escritório na segunda-feira.

Parece cruel escrever isso.

Mas talvez seja exatamente por isso que tanta gente entende a cena sem que nenhuma palavra precise ser dita.


O Grande Sonho Não é a Magia

Repare numa curiosidade.

Quase ninguém assiste um isekai pensando:

"Nossa... queria aprender magia."

O pensamento costuma ser outro.

"Queria começar de novo."

Essa pequena diferença muda completamente a interpretação do gênero.

O sucesso do isekai talvez nunca tenha sido sobre dragões.

Foi sobre recomeços.


A Vida Virou um Batch Infinito

Programadores COBOL entendem isso melhor do que ninguém.

Imagine que sua rotina fosse descrita em JCL.

//VIDA     JOB (0001),'TRABALHADOR'
//STEP01   EXEC PGM=ACORDAR
//STEP02   EXEC PGM=ONIBUS
//STEP03   EXEC PGM=METRO
//STEP04   EXEC PGM=TRABALHO
//STEP05   EXEC PGM=PRESSAO
//STEP06   EXEC PGM=REUNIAO
//STEP07   EXEC PGM=HORAEXTRA
//STEP08   EXEC PGM=VOLTAR
//STEP09   EXEC PGM=DORMIR

No dia seguinte...

O scheduler executa tudo novamente.

Sem perguntar.

Sem pausa.

Sem CTRL+C.


O Trabalhador Moderno Também Entrou em Loop

Décadas atrás existia uma promessa.

Estude.

Trabalhe.

Construa uma carreira.

Compre sua casa.

Tenha estabilidade.

Aposente-se.

Esse roteiro funcionou para milhões de pessoas.

Mas algo começou a mudar.

Os empregos ficaram mais instáveis.

Os salários cresceram menos do que o custo de vida.

As casas ficaram mais caras.

O transporte passou a consumir horas preciosas do dia.

A tecnologia, que deveria libertar, começou a manter todos conectados vinte e quatro horas por dia.

O celular virou uma extensão do escritório.


O Bug Nunca Foi o Computador

Curiosamente...

Nunca produzimos tanta tecnologia.

Nunca tivemos tanta automação.

Nunca tivemos tantos sistemas inteligentes.

E mesmo assim...

Muita gente trabalha mais do que trabalhava vinte anos atrás.

É quase um paradoxo.

Criamos máquinas para economizar tempo.

Depois usamos o tempo economizado para trabalhar ainda mais.

Como diria um velho operador de mainframe:

"A CPU ficou mais rápida... mas aumentaram a fila do JES."


O Isekai Resolve um Problema que o Mundo Real Não Resolve

Observe a estrutura da maioria das histórias.

Primeiro episódio.

Você chega.

Segundo.

Descobre um talento extraordinário.

Terceiro.

Alguém acredita em você.

Quarto.

Você encontra amigos.

Quinto.

Recebe reconhecimento.

Sexto.

Sua existência faz diferença.

Compare isso com o mercado de trabalho moderno.

Muitas pessoas passam anos sem ouvir um simples:

"Obrigado."


O Salário Emocional Está em Falta

Nem todo pagamento acontece na conta bancária.

Existe também o pagamento invisível.

Respeito.

Reconhecimento.

Pertencimento.

Sentimento de utilidade.

Orgulho do próprio trabalho.

Quando essas coisas desaparecem...

Até um bom salário parece insuficiente.

Talvez seja justamente isso que tantos isekais oferecem.

Um lugar onde alguém finalmente diz:

"Precisávamos de você."


O Verdadeiro Poder Não é a Magia

Nos animes parece que o protagonista ganha força infinita.

Mas olhando com calma...

O maior poder recebido não é lançar Fireball.

É recuperar o controle da própria vida.

No escritório...

O gerente escolhe.

O cliente escolhe.

O mercado escolhe.

No isekai...

Pela primeira vez...

O protagonista escolhe.


O Reino que Sempre Diz Obrigado

Existe um detalhe curioso.

No mundo paralelo...

Salvar uma vila muda vidas.

Salvar crianças muda vidas.

Construir uma ponte muda vidas.

Curar uma doença muda vidas.

Tudo possui consequência imediata.

No mundo corporativo...

Você entrega um projeto gigantesco.

Na segunda-feira aparece outro.

Como se nada tivesse acontecido.


O Isekai é uma Carta de Demissão

Talvez o verdadeiro sonho nunca tenha sido lutar contra o Rei Demônio.

Talvez o sonho fosse apenas entregar uma carta dizendo:

"Não volto mais na segunda-feira."

É uma fantasia dura.

Mas profundamente humana.


Bellacosa Mainframe

Quanto mais assisto isekais...

Menos acho que eles falam sobre magia.

Eles falam sobre exaustão.

Sobre pessoas que deixaram de acreditar que conseguirão construir uma vida digna dentro do sistema em que vivem.

O círculo mágico talvez nunca tenha sido um portal.

Talvez fosse um pedido silencioso de socorro.

Aqueles sacerdotes não estavam invocando apenas um herói.

Estavam oferecendo ao espectador aquilo que ele secretamente deseja depois de uma semana de reuniões, trânsito, boletos e horas extras:

A chance de apertar o botão IPL da própria existência.

E talvez esteja aí a maior crítica escondida do gênero.

Quando milhões de pessoas sonham em abandonar completamente o próprio mundo para viver em outro, o problema provavelmente não está apenas na fantasia.

Talvez o maior "Rei Demônio" nunca tenha sido derrotado porque ele não mora em um castelo medieval. Ele mora na rotina que transformou viver em apenas sobreviver.


domingo, 12 de setembro de 2021

🖐️ A MÃO que fala no Japão — Entre o gesto, o espírito e o silêncio

 

Bellacosa Mainframe e a mão que fala entenda a linguagem secreta dos animes com habitos do Japão

🖐️ A MÃO no Japão — Entre o gesto, o espírito e o silêncio
📓 Um mergulho sensorial e simbólico ao estilo Bellacosa Mainframe, direto do blog El Jefe Midnight Lunch


Na madrugada, quando a luz azul do monitor é a única companhia e o café já perdeu a vergonha, eu me pego pensando nessas pequenas coisas do cotidiano — como uma simples mão.
Aqui no Ocidente, a mão é ferramenta. No Japão, é linguagem.
E como tudo na cultura nipônica, há camadas, códigos, e uma etiqueta invisível que dita o que pode (ou não) ser feito com ela.

Afinal, no Japão, a mão fala — mesmo quando o japonês não diz uma palavra.



🏯 Um pouco de história — da espada à cerimônia do chá

Na antiga cultura samurai, as mãos eram símbolo de domínio e honra.
Com elas se empunhava a katana, se firmava o pacto, e também se tirava a própria vida em caso de desonra (seppuku).
A mão não era só um instrumento físico, mas um elo entre a ação e o espírito.

Nos templos, monges zen enxergavam nas mãos a ponte entre o corpo e o vazio — o gesto de unir as palmas (合掌 – gasshō) é até hoje uma forma de reverência espiritual e respeito.
Quem visita o Japão logo percebe: antes de entrar em um templo, junta-se as mãos — não como pedido, mas como reconhecimento da presença.


🤲 A linguagem silenciosa das mãos

Os japoneses falam pouco com gestos amplos, mas a mão japonesa é precisa.
Existem gestos com significados claros:

  • 🙏 Juntar as mãos = desculpa, gratidão, oração.

  • ✋ Levantar a palma = recusa polida.

  • 👌 Mão em círculo = dinheiro.

  • 🫳 Palma para baixo balançando = “não, não é bem assim…”

  • 🤚 Mão erguida com leve sorriso = um discreto “olá” socialmente calibrado.

Mas o verdadeiro código está no que não se faz:

  • Tocar alguém é raríssimo — nem apertos de mão são comuns.

  • Apontar com o dedo é considerado rude; usa-se a mão toda.

  • Passar algo diretamente com uma só mão é descortês; deve-se usar as duas mãos, sinal de respeito e cuidado.


🌸 Curiosidades e fofoquices culturais

💅 Namoro japonês: andar de mãos dadas em público já é um sinal forte de intimidade. No Japão, o “dar as mãos” é o equivalente emocional do “te amo” — algo reservado, simbólico e cheio de doçura.

🍱 Etiqueta no trabalho: ao entregar um cartão de visita (meishi), deve-se usar ambas as mãos — é como se entregasse um pedaço da própria identidade.

🎎 Na arte tradicional: a posição das mãos em danças como o Nihon Buyō ou no teatro Noh carrega significados espirituais. Cada gesto é palavra.

🪷 Na meditação: o posicionamento das mãos (mudra) define o tipo de energia invocada. O Dhyana mudra, com as mãos sobrepostas no colo, representa equilíbrio e sabedoria.



📚 Quem já falou sobre isso

  • Okakura Kakuzō, em “O Livro do Chá” (1906), descreve as mãos do anfitrião na cerimônia do chá como “a expressão física da harmonia”.

  • Daisetsu Teitaro Suzuki, mestre zen, falava que “a mente iluminada começa na ponta dos dedos”.

  • Haruki Murakami, em entrevistas, comenta como os gestos sutis das mãos japonesas o inspiram a construir o silêncio entre os personagens.

  • Hayao Miyazaki desenha mãos como espelhos da alma — repare em Totoro, Chihiro, Mononoke: cada toque é emocionalmente programado.


💡 Dicas Bellacosa de etiqueta manual japonesa

  1. Use as duas mãos para entregar ou receber algo — mostra respeito e intenção.

  2. Evite tocar — no Japão, o contato físico é reservado a quem tem permissão emocional.

  3. Não aponte com o dedo. Mostre com a palma — o gesto é mais bonito e neutro.

  4. Junte as mãos para agradecer. O clássico itadakimasu antes da refeição é um ato de reverência, não apenas um “bom apetite”.

  5. Cuidado com o tchau! O aceno de mão japonês é suave, com o pulso virado para baixo, e parece mais um “até logo” do que um “adeus”.


🪶 Conclusão Bellacosa

No Japão, as mãos não apenas fazem — elas significam.
São como terminais de um sistema ancestral que compila emoções, intenções e respeito em gestos silenciosos.
Enquanto no Ocidente falamos com a boca, o japonês conversa com as mãos — discretamente, com elegância, com economia.

E talvez aí esteja a lição:
a verdadeira comunicação não é barulhenta. É sutil. É feita de pausas, gestos, e intenções bem formatadas.

Na madrugada do El Jefe Midnight Lunch, entre um café e outro, penso que a mão é o mouse da alma —
com ela navegamos pelo mundo, clicamos em vidas, arrastamos afetos e, às vezes, erramos o botão.
Mas é nela que mora a beleza do humano — o toque que não precisa ser físico para ser sentido.


🖐️☕
#ElJefeMidnightLunch #BellacosaMainframe #CulturaJaponesa #GestosJaponeses #Etiqueta #MainframeDaAlma


https://eljefemidnightlunch.blogspot.com/2025/10/linguagem-secreta-da-comida-nos-animes.html

https://eljefemidnightlunch.blogspot.com/2025/04/como-ser-um-otaku-educado-no-japao-sem.html



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