Translate

sexta-feira, 24 de janeiro de 2020

Viagem rumo a São Tomé das Letras - MG

Dirigindo pelo sul de Minas Gerais,


Seguindo os passos de antigos bandeirantes, estamos circulando pela Rodovia Fernão Dias, rumo a mistica cidade dos gnomos, duendes e ovnis.

Neste primeiro vídeo de nossa jornada, apresento algumas estradas que circulamos passamos por inúmeras localidades, estamos na pequena estrada de 3 Corações, posteriormente iremos subir rumo a São Tomé das Letras.

Passando pelo Portal Magico adentramos na cidade e chegamos ao Camping do CID, onde iremos passar a virada de ano e aproveitar para explorar um pouquinho de São Tome.

#MinasGerais #SaoTomeDasLetras #Estrada #TresCoracoes #Viagem #Rodovia #camping #Cid #Aventura #direcao #passeio #viagem #serramantiqueira


#SaoTomeDasLetras #Piramide #tocaFurada #mirante #cruzeiro #IGrejaAssombrada #Castelo #Trilha #Ecoturismo #ViagemAstral #Ufo #et #duende #fada #weed #hippie #bichogrilo #cachoeira #cascata #corredeira #Caverna #pedradabruxa #panorama #ChicoTaquara #Gruta #saoTome #igrejarosario #sobradinho #eubioese #shangrila #poçoazul #poçodasesmeraldas #paraiso #veudanoiva #valedasborboletas #lua #gruta



quinta-feira, 23 de janeiro de 2020

📖 Honzuki no Gekokujou 2ª Temporada : Quando Myne Sai do Ambiente de Desenvolvimento e Entra em Produção — O Deploy Mais Delicado da História dos Isekais

 

Bellacosa Mainframe e a segunda temporada de honzuki no gekokujou

☕ Um Café no Bellacosa Mainframe

📖 Honzuki no Gekokujou 2ª Temporada (本好きの下剋上 第二部): Quando Myne Sai do Ambiente de Desenvolvimento e Entra em Produção — O Deploy Mais Delicado da História dos Isekais

"Criar papel foi apenas o protótipo. Agora Myne precisa integrar seu projeto ao sistema mais complexo daquele mundo: o Templo, a nobreza e uma burocracia que faz o RACF parecer amigável."


Introdução

A primeira temporada de Honzuki no Gekokujou mostrou como uma garota apaixonada por livros conseguiu reinventar tecnologias esquecidas em um mundo medieval. Era uma história sobre invenção, empreendedorismo e sobrevivência.

A segunda temporada muda completamente o foco.

Agora, o desafio não é mais fabricar papel ou tinta. O verdadeiro obstáculo é inserir conhecimento em uma estrutura de poder consolidada há séculos.

Sob a ótica do Bellacosa Mainframe, é como desenvolver uma solução inovadora em um ambiente de testes e, depois, tentar implantá-la em um gigantesco datacenter bancário cheio de normas, auditorias, segurança e interesses políticos.

É nesse momento que Honzuki no Gekokujou deixa de ser apenas um excelente isekai e se transforma em uma obra sobre governança, gestão de mudanças e transformação organizacional.


Ficha Técnica

Título original

本好きの下剋上 司書になるためには手段を選んでいられません 第二部

(Honzuki no Gekokujou: Shisho ni Naru Tame ni wa Shudan wo Erandeiraremasen – Part 2)

Título internacional

Ascendance of a Bookworm – Season 2


Autor Original

Miya Kazuki


Ilustrações

You Shiina


Estúdio

Ajia-do Animation Works

O estúdio mantém sua principal característica:

Priorizar narrativa.

Não existe espetáculo visual constante.

Existe direção cuidadosa.

Existe desenvolvimento gradual.

Existe respeito pelo material original.

A qualidade está muito mais na escrita do que na quantidade de quadros por segundo.


Direção

Mitsuru Hongo

A direção demonstra enorme maturidade.

Os conflitos deixam de ser físicos.

Agora são:

  • políticos

  • econômicos

  • religiosos

  • sociais

Cada episódio acrescenta uma nova camada ao universo.


Data de lançamento

4 de abril de 2020

Exibição encerrada em:

20 de junho de 2020


Episódios

12 episódios

Cada episódio adapta parte do arco conhecido como Part 2 – Apprentice Shrine Maiden.


Classificação

Fantasia

Isekai

Drama

Slice of Life

Política

Religião

Economia

Construção de Mundo


Faixa indicativa

Aproximadamente 12 anos.

Embora seja um anime tranquilo visualmente, trata temas bastante maduros:

  • exploração infantil

  • corrupção

  • fome

  • abuso de autoridade

  • desigualdade social

  • luta por poder

  • manipulação política


Sinopse

Após conseguir produzir papel e iniciar uma pequena revolução comercial, Myne descobre que sua enorme quantidade de mana ameaça sua própria vida.

A única maneira de sobreviver é ingressar no Templo como aprendiz de sacerdotisa (Blue Shrine Maiden), onde poderá utilizar sua mana de forma controlada.

Mas o Templo está longe de ser um local sagrado e pacífico.

Por trás dos rituais existem interesses políticos, corrupção, disputa por influência e uma rígida divisão entre plebeus e nobres.

Enquanto tenta manter seu sonho de criar livros, Myne precisará aprender a navegar por uma estrutura de poder muito mais perigosa do que qualquer monstro.


Resumo da História

Na primeira temporada, Myne enfrentava limitações tecnológicas.

Na segunda, enfrenta limitações institucionais.

Ela deixa de lutar contra a falta de papel e passa a enfrentar:

  • burocracia

  • preconceito

  • interesses econômicos

  • aristocracia

  • religião

  • poder político

É uma mudança radical de escala.


O Grande Tema da Segunda Temporada

Se a primeira temporada fala sobre inovação tecnológica, a segunda fala sobre governança.

Toda inovação, cedo ou tarde, encontra um sistema estabelecido.

É aí que começam os verdadeiros conflitos.


Bellacosa Mainframe

O Templo é o Datacenter Central

Imagine um enorme ambiente IBM Z.

Tudo passa por ele.

Segurança.

Autorização.

Processamento.

Controle.

Documentação.

Auditoria.

O Templo funciona exatamente assim.

Quem controla o Templo controla informação, recursos e influência.


Ferdinand: o Sysprog Supremo

Nesta temporada Ferdinand ganha enorme profundidade.

Ele lembra um Sysprog veterano.

Conhece todas as regras.

Conhece todas as exceções.

Conhece todos os riscos.

Seu papel é impedir que Myne destrua o ambiente sem perceber.

Ao mesmo tempo, reconhece que apenas ela pode modernizar aquele sistema.


Myne torna-se uma Arquiteta Corporativa

Ela deixa de ser apenas inventora.

Agora precisa:

negociar

liderar

ensinar

administrar

planejar

controlar riscos

formar equipes

gerenciar recursos

Ela amadurece enormemente.


Os novos personagens

Delia

Inicialmente parece antagonista.

Na verdade representa pessoas que cresceram dentro de sistemas injustos.

Ela age conforme foi ensinada.

Não por maldade.


Fran

Extremamente disciplinado.

Competente.

É praticamente um operador experiente de produção.

Sempre segue procedimentos.

Sempre executa corretamente.


Gil

Começa rebelde.

Pouco a pouco descobre propósito.

Talvez represente o maior crescimento pessoal da temporada.


Rosina

Sua sensibilidade artística lembra que cultura também faz parte da construção de uma sociedade.


Ferdinand e Myne

A relação entre ambos evolui bastante.

Não existe romance.

Existe confiança.

Mentoria.

Aprendizado.

Respeito intelectual.

É uma parceria semelhante à de um arquiteto experiente treinando uma futura líder técnica.


As aventuras

Embora pareça um anime "parado", praticamente todo episódio apresenta desafios.

Criar biblioteca.

Organizar funcionários.

Ensinar leitura.

Negociar recursos.

Produzir novos materiais.

Lidar com nobres.

Resolver conflitos internos.

Descobrir conspirações.

Sobreviver politicamente.

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


O verdadeiro antagonista

Não existe um vilão clássico.

O inimigo é:

o sistema.

Estruturas antigas.

Preconceitos.

Interesses.

Corrupção.

Isso torna a obra extremamente realista.


As mensagens ocultas

Conhecimento ameaça quem controla informação

Toda vez que Myne democratiza conhecimento, alguém perde poder.

A série demonstra que informação nunca é neutra.


Mudança exige aliados

Nenhuma revolução acontece sozinha.

Myne depende de:

Lutz.

Benno.

Fran.

Ferdinand.

Gil.

Rosina.

Cada pessoa representa uma competência diferente.


Liderança é servir

Ao contrário de muitos protagonistas.

Myne não manda.

Ela inspira.

As pessoas começam a trabalhar melhor porque acreditam em seu propósito.


Educação modifica gerações

Os livros que Myne cria talvez não mudem sua própria vida.

Mudam a vida das próximas gerações.


Instituições podem proteger ou aprisionar

O Templo é simultaneamente:

abrigo

prisão

escola

centro político

centro econômico

centro religioso

Essa dualidade é brilhantemente construída.


O que diferencia esta temporada?

Enquanto quase todos os isekais aceleram para batalhas cada vez maiores, Honzuki desacelera.

Troca ação por construção de personagens.

Troca magia por administração.

Troca guerras por diplomacia.

Troca espadas por livros.

E surpreendentemente funciona.


Qualidade da adaptação

A adaptação continua bastante fiel às light novels, mas a limitação de episódios exigiu condensar muitos acontecimentos.

Diversos detalhes sobre o funcionamento interno do Templo, as motivações dos sacerdotes, a política da nobreza e o desenvolvimento psicológico de personagens secundários aparecem de forma mais rica nos livros. Ainda assim, o anime preserva os principais eventos e o tom da obra.


Houve censura?

Não houve registros de censura significativa na segunda temporada. A adaptação manteve temas como desigualdade social, exploração de crianças, manipulação política e corrupção religiosa sem grandes alterações. O que ocorreu foi uma simplificação de alguns conflitos e diálogos para adequação ao tempo disponível em cada episódio, evitando excesso de exposição e mantendo um ritmo acessível para a televisão.


Impacto Cultural

A segunda temporada consolidou Ascendance of a Bookworm como um dos isekais mais diferentes da década. Muitos espectadores que inicialmente buscavam fantasia tradicional descobriram uma narrativa voltada para administração, economia e construção de instituições.

A obra passou a ser frequentemente utilizada como exemplo de worldbuilding consistente, mostrando que um universo bem planejado pode ser mais envolvente do que batalhas espetaculares. Também reforçou o interesse internacional pelas light novels de Miya Kazuki, impulsionando traduções e ampliando a comunidade de fãs.


Bellacosa Mainframe Score

ItemNota
Construção de Mundo⭐⭐⭐⭐⭐ (10/10)
Desenvolvimento dos Personagens⭐⭐⭐⭐⭐ (10/10)
Política e Intriga⭐⭐⭐⭐⭐ (9,8/10)
Emoção⭐⭐⭐⭐⭐ (9,7/10)
Trilha Sonora⭐⭐⭐⭐☆ (9,0/10)
Animação⭐⭐⭐⭐☆ (8,8/10)
Fidelidade às Novels⭐⭐⭐⭐⭐ (9,5/10)
Originalidade⭐⭐⭐⭐⭐ (10/10)
Valor Educacional⭐⭐⭐⭐⭐ (10/10)

Conclusão

A segunda temporada de Honzuki no Gekokujou demonstra que inovar é apenas a primeira etapa; o verdadeiro desafio é integrar essa inovação a organizações complexas, onde tradição, burocracia e interesses estabelecidos resistem à mudança. Myne deixa de ser apenas uma inventora brilhante para se tornar uma líder capaz de negociar, formar equipes e transformar instituições sem destruir suas bases.

Na linguagem do Bellacosa Mainframe, essa temporada é o equivalente a implantar uma nova arquitetura em um ambiente IBM Z crítico: não basta escrever um excelente programa COBOL. É preciso entender governança, segurança, processos, gestão de mudanças e, acima de tudo, conquistar a confiança das pessoas que mantêm o sistema funcionando.

É essa combinação de inteligência, sensibilidade e realismo institucional que faz da segunda temporada uma das mais ricas do gênero isekai. Ela prova que a maior aventura não é derrotar um rei demônio, mas convencer uma sociedade inteira de que o conhecimento deve deixar de ser um privilégio para se tornar um patrimônio coletivo.

DT NÃO É Data Type! O Dia em que um Programador COBOL Descobriu que os Otakus Estavam Falando de Outra Coisa o Tempo Todo!

 

Bellacosa Mainframe e o significado oculto de DT

☕ Um Café no Bellacosa Mainframe

DT NÃO É Data Type! O Dia em que um Programador COBOL Descobriu que os Otakus Estavam Falando de Outra Coisa o Tempo Todo!

Imagine a cena.

Você, veterano de COBOL, quarenta anos de mainframe nas costas.

Alguém no grupo do WhatsApp escreve:

"Esse anime tem muito DT."

Imediatamente você pensa:

"Ah... deve ser um novo tipo de dado...

DISPLAY TYPE?

DECIMAL TYPE?

DATA TRANSFER?

DOUBLE TEST?

DATABASE TRIGGER?"

Não.

Nada disso.

Você abre o anime.

Cinco minutos depois...

Uma garota tropeça.

A câmera faz um mergulho cinematográfico.

A gravidade tira férias.

E você finalmente entende.


O que significa DT?

No universo dos mangás e animes, DT normalmente significa:

Doutei (童貞)

Que em japonês significa literalmente:

Virgem (homem).

Mas...

Como tudo no Japão...

...não é tão simples.


Não é apenas "virgem"

Nos animes, chamar alguém de DT virou praticamente um meme.

É quase uma classe de personagem.

Algo como:

  • nunca namorou

  • não sabe conversar com garotas

  • entra em pânico ao ouvir "bom dia"

  • morre por combustão espontânea quando uma menina segura sua mão.

É praticamente um ABEND social.


Traduzindo para COBOL

Imagine um programa assim:

01 EXPERIENCIA-AMOROSA.
   05 STATUS PIC X VALUE "N".

Durante vinte temporadas...

Nunca muda.

Continua:

STATUS = N

Nem um UPDATE.

Nem um COMMIT.

Nem um INSERT.

Só SELECT.


O COBOL Padawan DT

É aquele programador que:

  • conhece CICS

  • conhece Db2

  • conhece VSAM

  • conhece IMS

  • conhece RACF

Mas...

Quando uma garota pergunta:

"Você programa?"

Ele responde:

S0C7

O verdadeiro significado nos animes

DT quase sempre representa o protagonista clássico.

Ele é:

✔ gentil

✔ trabalhador

✔ tímido

✔ azarado

✔ absurdamente poderoso

✔ completamente incapaz de perceber que CINCO garotas gostam dele.


O algoritmo emocional dele

IF GAROTA-SORRI
   MOVE "ELA ESTÁ SENDO EDUCADA"
      TO INTERPRETACAO.

IF GAROTA-ABRACA
   MOVE "DEVE ESTAR COM FRIO"
      TO INTERPRETACAO.

IF GAROTA-BEIJA
   MOVE "FOI UM ACIDENTE"
      TO INTERPRETACAO.

Resultado?

END-IF.

Nada acontece.


O poder oculto do DT

Curiosamente...

Quanto mais DT...

Mais poderoso costuma ser o protagonista.

É uma regra não escrita.

Veja alguns exemplos.

O herói derrota:

✔ dragões

✔ demônios

✔ reis

✔ deuses

✔ entidades cósmicas

✔ conceitos abstratos da existência

Mas...

Não consegue dizer:

"Você gostaria de tomar um café?"


O compilador emocional

Imagine o compilador.

COMPILANDO...

LOVE.DAT

Erro:

Linha 45

Unexpected Female Interaction.

Expected:

Sword

Shield

Magic

Dragon

Guild

Adventure

Found:

Girl

Compilation failed.


O famoso Buff da Pureza™

Em muitos mangás antigos existia até a piada:

Quanto mais DT...

Maior o poder mágico.

Era quase uma estatística RPG.

MAGIA = DT x 100

Perdeu o status?

MAGIA = 0

Não faz sentido.

Mas anime nunca prometeu fazer sentido.


O Agente Smith entra no anime

Imagine Matrix.

Neo enfrenta centenas de Agentes Smith.

Tudo tranquilo.

Mas...

A Trinity segura sua mão.

Neo:

ABEND U9999

Reason:

Emotional Overflow.

O Padawan COBOL encontra uma elfa

A elfa diz:

— Você é incrível.

O programador responde:

— Obrigado.

Silêncio.

Ela continua olhando.

Ele abre o ISPF.


O Debug

DISPLAY "ELA GOSTA DE MIM?"

Resultado:

FALSE.

DISPLAY "TEM CERTEZA?"

TRUE.

DISPLAY "ABSOLUTA?"

TRUE.

DISPLAY "VOCÊ É BURRO?"

TRUE.

O Scheduler do Romance

JES2:

JOB LOVE001 SUBMITTED

Cinco anos depois...

JOB STILL WAITING...

Motivo?

CLASS=A

Priority=LOW

User forgot to talk.

O Banco de Dados Amoroso

SELECT *

FROM GAROTAS

WHERE INTERESSE='SIM';

Resultado:

5 linhas encontradas.

Programa:

DISPLAY

"NÃO EXISTEM RESULTADOS."

O Plot Twist

O curioso é que muitos autores usam o DT justamente para representar o crescimento do personagem.

No início ele é inseguro.

Tem medo.

Não acredita em si mesmo.

Não entende as pessoas.

Com o tempo...

Aprende amizade.

Responsabilidade.

Empatia.

Confiança.

Ou seja...

O DT nunca foi realmente sobre romance.

Era apenas um símbolo da falta de maturidade.


O Bellacosa Mainframe explica

No mundo do mainframe existe algo parecido.

Todo Padawan começa assim.

Tem medo de:

  • SDSF

  • JCL

  • CICS

  • Db2

  • VSAM

  • RACF

  • produção

  • IPL

Até que um belo dia...

Depois do centésimo ABEND...

Depois da milésima compilação...

Depois de sobreviver ao primeiro incidente em produção...

Ele percebe:

"Talvez eu saiba alguma coisa."

É exatamente a evolução de muitos protagonistas de anime.


Moral da História

Ser DT em um anime não significa apenas "ser virgem".

Virou um arquétipo cômico que representa a timidez extrema, a inexperiência social e a clássica incapacidade de perceber o óbvio, rendendo incontáveis cenas engraçadas. Muitos protagonistas começam assim justamente para terem espaço para amadurecer ao longo da história.

E lembre-se, Padawan COBOL...

Você pode não entender as indiretas da elfa da guilda...

Pode demorar três temporadas para perceber que a sacerdotisa gosta de você...

Pode até levar um S0C7 emocional ao receber um elogio...

Mas, se conseguir decifrar um JCL de 4 mil linhas, um dump de CICS às três da manhã e uma query Db2 escrita em 1989, talvez exista esperança. Afinal, entre um ABEND e outro, até o protagonista mais distraído acaba aprendendo que alguns bugs não estão no código... estão na interpretação dos sinais da vida. 😄

quarta-feira, 22 de janeiro de 2020

Murphy's Law Rules : Quando um Programador COBOL Descobriu que a Matrix Não Era Derrotada Pelos Grandes Bugs… Mas Pelos Pequenos Erros que Ninguém Testou

 

Bellacosa Mainframe e a lei de murphy rules

☕ Um Café no Bellacosa Mainframe

Murphy's Law Rules sem Mistérios

Quando um Programador COBOL Descobriu que a Matrix Não Era Derrotada Pelos Grandes Bugs… Mas Pelos Pequenos Erros que Ninguém Testou

"Tudo o que pode dar errado, dará errado... principalmente às 2h17 da madrugada, durante o fechamento mensal, quando o especialista está de férias e o gerente pergunta: 'Mas vocês não testaram isso?'"


Prólogo — O Bug Impossível da Matrix

Era o último minuto antes da implantação da nova versão da Matrix.

Toda a equipe estava reunida.

Neo revisava cuidadosamente o último programa COBOL.

Trinity conferia as APIs.

Tank monitorava o CICS.

Link acompanhava as filas MQ.

O Arquiteto perguntou:

— Todos os testes passaram?

Neo respondeu confiante.

— Sim.

O Arquiteto sorriu.

— Todos?

Neo hesitou.

— Bem...

todos os que imaginamos.

O sistema entrou em produção.

Cinco segundos depois.

O telefone tocou.

Era Zion.

O saldo de todos os habitantes havia desaparecido.

Neo olhou para Morpheus.

— Como isso aconteceu?

O Oráculo apareceu.

Pegou um pequeno parafuso metálico.

Colocou sobre a mesa.

E disse:

"Vocês testaram tudo... menos aquilo que realmente iria acontecer."

Neo respirou fundo.

Naquele instante compreendeu a Lei de Murphy.


O que é a Lei de Murphy?

A Lei de Murphy é um princípio informal que afirma:

"Anything that can go wrong, will go wrong."

Ou, em português:

"Tudo o que pode dar errado, dará errado."

Na Engenharia de Software, essa frase não significa pessimismo.

Ela significa preparação.

Projetamos sistemas assumindo que falhas acontecerão.

Porque elas realmente acontecem.


A verdadeira origem da Lei de Murphy

Ao contrário do que muita gente imagina, a Lei de Murphy não nasceu da computação.

Ela surgiu em 1949, durante experimentos da Força Aérea dos Estados Unidos.

O engenheiro Edward A. Murphy Jr. trabalhava em testes de aceleração com foguetes.

Em um dos experimentos, sensores foram instalados de maneira incorreta.

Todos.

O teste inteiro falhou.

Murphy comentou algo equivalente a:

"Se existir uma maneira de alguém montar isso errado, alguém vai montar."

Com o tempo a frase evoluiu para a forma conhecida mundialmente.


Matrix explica perfeitamente

Imagine Neo.

Existe apenas uma porta errada.

Qual porta o Agente Smith escolhe?

Exatamente aquela.

Existe um cabo conectado invertido.

Qual cabo será usado na produção?

Esse mesmo.

Existe um único usuário que digita um caractere inesperado.

Quem aparece primeiro?

Ele.

Murphy nunca dorme.


O COBOL conhece Murphy há décadas

Imagine um programa.

Você testou:

  • CPF válido.

  • Saldo positivo.

  • Cliente ativo.

Tudo funciona.

Primeiro dia em produção.

Chega um cliente com:

  • CPF estrangeiro.

  • Conta conjunta.

  • Limite especial.

  • Saldo negativo.

  • Produto encerrado.

  • Agência incorporada.

  • Dados vindos via Open Finance.

ABEND.

Murphy sorri.


Murphy não cria problemas

Essa é uma confusão comum.

Murphy não "faz" algo dar errado.

Ele apenas lembra que:

seres humanos erram.

Hardware falha.

Redes caem.

Discos quebram.

Usuários digitam errado.

APIs ficam indisponíveis.

Sistemas distribuídos apresentam atrasos.

Falhas fazem parte da realidade.


Matrix Reloaded

Neo finalmente aprende a enxergar o código verde.

Mesmo assim.

Ele nunca assume que a Matrix será perfeita.

Sempre existe:

um agente escondido.

um programa exilado.

uma porta secreta.

uma variável inesperada.

Essa postura é exatamente o espírito da Engenharia de Software.


O efeito psicológico

Existe um viés chamado:

Excesso de confiança.

Pensamos:

"Comigo não acontece."

Até acontecer.

Murphy combate exatamente esse comportamento.


O Programador COBOL Padawan

Imagine seu primeiro programa.

Você testa:

10

20

30

Tudo funciona.

Produção recebe:

-999999999999

Ou:

ZERO

SPACES

NULL

UTF-8

EBCDIC inesperado

Você nunca imaginou.

Murphy imaginou.


O Agente Smith adora pressupostos

Smith sabe que basta uma hipótese falsa.

"Esse campo nunca vem vazio."

"Esse arquivo sempre chega."

"Essa API nunca cai."

"Esse usuário nunca faz isso."

É exatamente aí que ele ataca.


Um exemplo COBOL

Programa.

DIVIDE WS-VALOR
   BY WS-QUANTIDADE

Pergunta.

Quem garantiu que:

WS-QUANTIDADE

nunca será zero?

Se ninguém garantiu.

Murphy garantirá o contrário.


Outro exemplo clássico

READ CLIENTE

E se o registro não existir?

Foi testado?


Como Murphy aparece?

Pequenos detalhes.

  • Arquivo cheio.

  • Disco indisponível.

  • Dataset bloqueado.

  • Job cancelado.

  • Db2 indisponível.

  • MQ congestionado.

  • Timeout REST.

  • Token expirado.

  • Data inválida.

  • Leap Year.

  • Horário de verão.

Nenhum parece impossível.

Todos acontecem.


O custo invisível

A maior parte do desenvolvimento testa:

caminhos felizes.

Pouca gente testa:

fracassos.

Mas é justamente neles que sistemas críticos demonstram qualidade.


O impacto no Mainframe

Mainframes executam bilhões de transações.

Logo.

Mesmo eventos raríssimos acabam acontecendo.

Se uma falha possui probabilidade de:

1 em 100 milhões.

Um banco processando bilhões de operações provavelmente a encontrará.


Curiosidade

Existe uma frase muito conhecida entre engenheiros:

"Hope is not a strategy."

Esperança não substitui testes.


Matrix e os Sentinelas

Imagine construir Zion assumindo que:

"Os Sentinelas nunca encontrarão este túnel."

Essa não é uma estratégia.

É um desejo.


Ferramentas ajudam

Hoje possuímos recursos incríveis.

No universo IBM.

  • ZUnit.

  • IBM Test Accelerator.

  • Galasa.

  • Debug Tool.

  • Fault Analyzer.

  • File Manager.

  • Application Performance Analyzer.

  • OMEGAMON.

  • Instana.

Eles ajudam a descobrir falhas antes da produção.


O papel dos testes

Murphy explica exatamente por que existem:

Testes Unitários

Cada módulo.


Testes Integrados

Comunicação.


Testes de Performance

Carga.


Testes de Segurança

Ataques.


Chaos Engineering

Falhas controladas.


Disaster Recovery

Pior cenário.


Matrix e Chaos Engineering

Imagine Morpheus desligando propositalmente parte da Matrix.

Por quê?

Para descobrir.

Antes de Smith.

Essa é exatamente a ideia do Chaos Engineering.


O papel da IA

A IA pode:

  • gerar casos de teste;

  • encontrar caminhos pouco explorados;

  • sugerir cenários extremos;

  • revisar código;

  • detectar riscos.

Mas continua dependendo da criatividade humana para imaginar situações improváveis.


Atenção!

Murphy não significa paranoia.

Significa preparação.

Existe enorme diferença.


A diferença

Pessimismo

"Nada funciona."


Engenharia

"Se falhar, estaremos preparados."


Os riscos

Quando Murphy é ignorado.

Surgem.

  • ABENDs.

  • Incidentes.

  • Perda financeira.

  • Vazamento de dados.

  • Retrabalho.

  • Imagem comprometida.


Erros clássicos

  • Testar apenas cenário feliz.

  • Ignorar exceções.

  • Não validar entrada.

  • Assumir infraestrutura perfeita.

  • Não testar recuperação.


Boas práticas

  • Teste entradas inválidas.

  • Faça testes negativos.

  • Automatize regressão.

  • Valide limites.

  • Simule falhas.

  • Faça rollback.

  • Monitore produção.


Aplicabilidade

Murphy aparece em:

  • COBOL.

  • CICS.

  • Db2.

  • MQ.

  • Cloud.

  • Java.

  • Python.

  • Kubernetes.

  • APIs.

  • IA.

Nenhuma tecnologia escapa.


O ensinamento do Oráculo

O Oráculo entrega duas xícaras para Neo.

Uma perfeita.

Outra com uma pequena rachadura.

Pergunta.

— Qual você levaria para atravessar o deserto?

Neo escolhe a perfeita.

Ela sorri.

Depois derruba as duas.

A perfeita quebra.

A rachada continua inteira porque era mais espessa.

Ela olha para Neo.

"Você testou apenas a aparência. Nunca testou a queda."


Murphy e o Mainframe Moderno

No universo IBM Z existe um princípio silencioso que acompanha décadas de engenharia: construa sistemas assumindo que componentes falharão.

Por isso existem:

  • Parallel Sysplex para alta disponibilidade.

  • GDPS para recuperação de desastres.

  • RACF para minimizar erros de acesso.

  • CICS Transaction Server com recuperação automática.

  • Db2 com logs e rollback.

  • MQ garantindo entrega confiável de mensagens.

Nada disso existe porque os engenheiros acreditavam que tudo funcionaria para sempre.

Existe porque eles sabiam que Murphy apareceria.


Lições para um Programador COBOL Padawan

Durante sua carreira você escreverá programas que movimentarão dinheiro, impostos, aposentadorias, seguros e milhões de transações críticas.

Nunca pergunte apenas:

"O programa funciona?"

Pergunte também:

  • O que acontece se o arquivo não existir?

  • E se o banco estiver indisponível?

  • E se o usuário informar dados inválidos?

  • E se houver timeout?

  • E se a conexão cair durante o COMMIT?

  • E se o disco ficar cheio?

  • E se o horário mudar por causa do fuso?

Essas perguntas transformam um programador em um engenheiro.


Curiosidades

A Lei de Murphy inspirou diversos conceitos modernos:

  • Defensive Programming

  • Fail Fast

  • Circuit Breaker

  • Retry Pattern

  • Bulkhead Pattern

  • Chaos Engineering

  • Site Reliability Engineering (SRE)

Todos partem da mesma premissa:

falhas acontecerão.

A diferença está em como o sistema reage a elas.


Conclusão — A Matrix Não Era Forte Porque Nunca Falhava

No final da trilogia percebemos algo importante.

A Matrix nunca foi perfeita.

Ela possuía mecanismos para detectar falhas, adaptar-se e continuar funcionando.

Essa é exatamente a essência da Engenharia de Software.

A Lei de Murphy não é um convite ao pessimismo.

É um convite à humildade.

Ela nos lembra que usuários surpreendem, infraestrutura falha, requisitos mudam e eventos improváveis acabam acontecendo — especialmente em sistemas que executam milhões ou bilhões de operações.

Para um Programador COBOL, especialmente no ambiente IBM Z, isso significa projetar aplicações resilientes, validar entradas, tratar exceções, automatizar testes e preparar planos de recuperação antes que a produção cobre essa preparação.

No universo Bellacosa Mainframe existe uma máxima que Morpheus certamente diria aos novos Padawans antes do primeiro deploy:

"Não escreva código esperando que nada falhe. Escreva código sabendo que um dia tudo poderá falhar — e que, mesmo assim, o sistema continuará de pé."

Porque o verdadeiro Escolhido não é aquele que nunca encontra um bug.

É aquele que já havia imaginado esse bug muito antes de ele aparecer na tela verde do terminal.

quarta-feira, 8 de janeiro de 2020

☕💥 Algoritmos no Mainframe: Da Matemática de Al-Khwarizmi ao COBOL no z/OS

 

Bellacosa Mainframe apresenta algoritmos na programação

☕💥 Algoritmos no Mainframe: Da Matemática de Al-Khwarizmi ao COBOL no z/OS

Ou como um programador COBOL Padawan descobre que, antes de existir código, existia lógica

"Um bom algoritmo faz um bom programa. Um excelente algoritmo faz o programador parecer um mago. Um algoritmo ruim faz o operador do turno da madrugada querer abrir um chamado para exorcismo."

— Bellacosa Mainframe

Introdução

Existe uma frase que gosto de repetir aos meus alunos padawans:

"COBOL não é difícil. Difícil é pensar."

E isso pode soar estranho.

Muitos acreditam que programar significa decorar comandos, aprender sintaxe, conhecer verbos COBOL ou dominar JCL.

Não.

Programar é, essencialmente, aprender a pensar de forma estruturada.

E isso possui um nome.

Algoritmo.

Antes do COBOL.

Antes do Assembler.

Antes do FORTRAN.

Antes do System/360.

Antes do z16.

Antes do ChatGPT.

Já existiam algoritmos.

E a história deles é simplesmente fantástica.


O nascimento dos algoritmos

A palavra algoritmo deriva do nome do matemático persa:

Muhammad ibn Musa al-Khwarizmi

(cerca de 780–850 d.C.)

Ele escreveu um tratado chamado:

"Kitab al-Jabr wa-l-Muqabala"

Livro que deu origem à palavra:

Algebra

E seu nome latinizado tornou-se:

Algorismus

Posteriormente:

Algorithm

Ou seja...

Cada vez que fazemos:

ADD A TO B GIVING TOTAL

estamos usando ideias desenvolvidas há mais de mil anos.


Algoritmos antes dos computadores

Curiosamente, algoritmos são muito mais antigos que computadores.

Exemplos:

Receitas culinárias

Procedimentos militares

Construção de pirâmides

Cálculos astronômicos

Navegação marítima

Tributação romana

Tudo era algoritmo.

Apenas não era chamado assim.


O primeiro algoritmo famoso

O algoritmo de Euclides.

300 a.C.

Encontrar o MDC.

Exemplo:

MDC(48,18)

Passo 1

48 mod 18 = 12

Passo 2

18 mod 12 = 6

Passo 3

12 mod 6 =0

Resposta

6

Dois mil anos depois...

Continuamos utilizando a mesma lógica.


A chegada dos computadores

Década de 1940.

ENIAC

UNIVAC

EDSAC

LEO I

IBM 650

IBM 7070

A grande dificuldade não era processador.

Era ensinar uma máquina a pensar.

E pensar significava:

Transformar problemas em algoritmos.


O nascimento do mainframe

1952

IBM 701

1954

IBM 704

1964

System/360

Um dos projetos mais revolucionários da história.

Pela primeira vez:

Uma arquitetura única.

Diversos equipamentos.

Compatibilidade.

E o software começava a ganhar importância.


O problema dos programas gigantes

Década de 50.

Empresas começavam a automatizar:

Folha de pagamento

Seguros

Bancos

Governo

Previdência

Surgiu um problema.

Como ensinar milhares de pessoas a desenvolver sistemas?

Resposta:

Criando linguagens de alto nível.


COBOL nasce em 1959

CODASYL.

Grace Hopper.

Departamento de Defesa Americano.

Objetivo:

Criar uma linguagem próxima do inglês.

Exemplo:

READ CLIENTE

IF SALDO > 1000

   PERFORM LIBERA-CREDITO

END-IF

Mas existe um detalhe importante.

COBOL não pensa.

Quem pensa é o desenvolvedor.

COBOL apenas executa.

O algoritmo continua sendo o verdadeiro cérebro.


O algoritmo escondido dentro do COBOL

Muitos iniciantes acreditam:

"Aprendi COBOL."

Não.

Aprendeu comandos.

Programar é construir algoritmos.

Exemplo.

Problema:

Calcular média.

Padawan inexperiente:

ADD A TO B
ADD C TO TOTAL
DIVIDE 3 INTO TOTAL

Padawan treinado:

Entrada

3 notas

Processamento

Somar

Dividir

Saída

Média

Ele pensa primeiro.

Codifica depois.


Características de um algoritmo

Entrada

Pode possuir dados.

Exemplo:

Arquivo VSAM

DB2

MQ

GDG

SYSIN


Saída

Relatório

Arquivo

Mensagem

Tela CICS

API JSON


Finitude

Todo algoritmo precisa terminar.

Exemplo ruim:

PERFORM FOREVER

Exemplo bom:

PERFORM UNTIL EOF='S'

Clareza

Evitar ambiguidades.

Ruim:

"Processar cliente"

Bom:

Ler registro

Validar CPF

Consultar saldo

Atualizar DB2

Gravar auditoria


Algoritmos nos Batchs Mainframe

Imagine.

Banco processando PIX.

2 bilhões de registros.

A lógica continua igual.

Entrada

SORTIN

Processamento

JOINKEYS

ICETOOL

COBOL

Saída

SORTOUT

Relatórios

DB2

MQ


O algoritmo do fechamento bancário

Leitura

Validação

Consolidação

Apuração

Tributação

Geração de extrato

Backup

Auditoria

Tudo algoritmo.


Algoritmos no CICS

O novato vê:

EXEC CICS RECEIVE

EXEC CICS SEND

EXEC CICS LINK

Mas por trás existe:

Receber dados

Validar

Consultar

Persistir

Retornar

Fluxo decisório.


Algoritmos no Natural

Mesmo conceito.

MAP

READ

FIND

END-FIND

ESCAPE TOP

DECIDE ON

São apenas ferramentas.

O raciocínio continua sendo algoritmo.


Pseudocódigo

Excelente ferramenta para padawans.

Exemplo.

Transferência bancária.



Inicio


Ler conta origem


Ler conta destino


Ler valor


Saldo suficiente ?


SIM


Debitar


Creditar


Gerar log


Nao


Retornar erro



Fim



Só depois escrevemos COBOL.


Fluxogramas

Muito utilizados nos anos 70.

Analistas desenhavam:

Retângulos

Losangos

Setas

Pastas físicas.

Canetas.

Régua.

Pranchetas.

Sim.

Mainframe já existia antes do Visio.


Algoritmos de busca

Busca sequencial.

Busca binária.

Hash.

Índices VSAM.

DB2 Index.

B-tree.

LSM Trees.

Todos são algoritmos.


Algoritmos de ordenação

Mainframe ama ordenação.

DFSORT.

SYNCSORT.

ICETOOL.

Métodos famosos:

Bubble Sort

Merge Sort

QuickSort

HeapSort

No universo IBM, o Merge Sort praticamente reina.


Complexidade computacional

Nem todo algoritmo é igual.

O(1)

Constante

O(log n)

Busca binária

O(n)

Linear

O(n²)

Bubble

O(2ⁿ)

Exponencial


O dia em que um COBOL virou um monstro

Já vi programa COBOL com:

70 mil linhas.

350 PERFORM.

1200 IF.

85 GO TO.

Documentação inexistente.

Autor aposentado em 1998.

Chamado aberto em produção.

Ninguém sabe mexer.

Por quê?

Ausência de algoritmo.

Código cresceu.

Pensamento não.


Design de algoritmos

Força Bruta

Dividir e conquistar

Backtracking

Greedy

Programação dinâmica

Mesmo em bancos.

Mesmo em seguradoras.

Mesmo em governo.


Algoritmos modernos no IBM Z

Hoje temos:

z16

z17

LinuxONE

OpenShift

zCX

API Connect

z/OS Connect

Kafka

Python

Java

Node.js

AI

Machine Learning

Mas adivinhe.

O algoritmo continua sendo rei.


Inteligência Artificial também vive de algoritmos

Redes neurais.

Transformers.

LLMs.

Árvores.

Regressão.

Clustering.

Tudo algoritmo.

A IA não substituiu algoritmos.

Ela apenas os sofisticou.


O maior erro dos novos programadores

Querer aprender linguagem.

Antes de aprender lógica.

É equivalente a comprar um sabre de luz sem saber usar a Força.


Conselhos para um Padawan COBOL

Primeiro pense.

Depois desenhe.

Depois escreva.

Depois teste.

Depois otimize.

Nunca faça o inverso.

Pergunte sempre:

Quais entradas?

Qual processamento?

Qual saída?

Existem exceções?

Qual volume?

Como recuperar falhas?

Como auditar?

Como escalar?


O algoritmo invisível que move o mundo

Quando um cliente faz PIX.

Existe algoritmo.

Quando um avião decola.

Existe algoritmo.

Quando uma seguradora calcula prêmio.

Existe algoritmo.

Quando um cartão aprova compra.

Existe algoritmo.

Quando o INSS paga benefícios.

Existe algoritmo.

Quando um CICS responde em menos de um segundo.

Existe algoritmo.

E quando um velho programa COBOL criado em 1987 continua funcionando perfeitamente em um IBM Z moderno...

Existe um bom algoritmo escondido ali.


Considerações finais

Muitos dizem que COBOL é uma linguagem antiga.

Discordo.

COBOL é apenas um meio de expressão.

A verdadeira tecnologia imortal chama-se algoritmo.

Ela nasceu com matemáticos árabes, sobreviveu aos impérios, atravessou a Revolução Industrial, alimentou os primeiros computadores, ajudou a criar o System/360, sustentou bancos por décadas, acompanhou a internet, chegou ao z/OS, conversa hoje com APIs REST e provavelmente continuará existindo quando estivermos programando computadores quânticos.

Portanto, jovem Padawan, lembre-se:

Você não é pago para escrever DISPLAY, MOVE, ADD ou EXEC CICS.

Você é pago para transformar problemas caóticos em sequências ordenadas de decisões capazes de gerar valor para empresas, governos e pessoas.

E esse poder, desde Al-Khwarizmi até o IBM z17, continua tendo exatamente o mesmo nome:

Algoritmo.

☕🚀 E como diria um velho mestre do Bellacosa Mainframe:

"Código envelhece. Linguagens mudam. Frameworks desaparecem. Mas um algoritmo elegante continua sendo reconhecido por qualquer programador, em qualquer época, em qualquer plataforma."

 

terça-feira, 7 de janeiro de 2020

☕👓🖥️ OS ÓCULOS QUE ESCONDEM OS OLHOS — O MISTÉRIO VISUAL DOS ANIMES JAPONESES E O SEGREDO QUE O OCIDENTE QUASE NUNCA PERCEBE

Bellacosa Mainframe e o significado dos oculos que escondem olhos em anime


☕👓🖥️ OS ÓCULOS QUE ESCONDEM OS OLHOS — O MISTÉRIO VISUAL DOS ANIMES JAPONESES E O SEGREDO QUE O OCIDENTE QUASE NUNCA PERCEBE

Existe uma pergunta aparentemente simples que muitos espectadores fazem ao assistir animes pela primeira vez:

"Por que alguns personagens de óculos não mostram os olhos?"

À primeira vista parece apenas uma escolha estética.

Um brilho branco cobre as lentes.

Os olhos desaparecem.

O personagem fala normalmente.

A cena continua.

Mas, para quem estuda narrativa visual japonesa, psicologia comportamental, semiótica e construção de personagens, aquilo está longe de ser um detalhe.

Na verdade, estamos diante de uma das linguagens visuais mais antigas, sofisticadas e eficientes dos animes e mangás.

E como acontece com muitas coisas no Japão, por trás de uma imagem aparentemente simples existe uma camada enorme de significado cultural.

Hoje vamos tomar um café e mergulhar nesse assunto.


Quando o rosto para de falar

O ser humano nasceu programado para interpretar rostos.

Muito antes da escrita.

Muito antes da linguagem.

Muito antes da tecnologia.

Nosso cérebro aprendeu a sobreviver observando expressões faciais.

Raiva.

Medo.

Tristeza.

Alegria.

Mentira.

Confiança.

Tudo isso é lido principalmente pelos olhos.

Não é por acaso que existe o ditado:

Os olhos são a janela da alma.

Diversos estudos de psicologia mostram que quando conversamos com alguém nossa atenção se concentra principalmente na região dos olhos.

É ali que buscamos sinais emocionais.

É ali que tentamos descobrir intenções.

É ali que avaliamos riscos.

Agora imagine que alguém retire justamente essa informação.

O cérebro continua tentando interpretar a pessoa.

Mas perde seu principal instrumento.

Surge então uma sensação curiosa.

Desconforto.

Mistério.

Incerteza.

E é exatamente isso que os autores japoneses exploram.


O personagem que se torna impossível de ler

Quando um personagem tem os olhos ocultos, ele se torna imprevisível.

Você não sabe se está feliz.

Não sabe se está irritado.

Não sabe se está mentindo.

Não sabe se está planejando algo.

Seu cérebro entra em modo de observação.

É como um operador de mainframe observando um job que continua rodando sem emitir mensagens no console.

Você sabe que algo está acontecendo.

Mas não sabe exatamente o quê.

A ausência de informação gera tensão.

Essa é uma das regras mais antigas da narrativa.

O desconhecido sempre produz mais curiosidade do que o conhecido.


O brilho nos óculos

Existe até um trope famoso dos animes.

Os japoneses chamam informalmente de "megane flash".

O famoso brilho nos óculos.

A cena normalmente acontece assim:

O personagem está ouvindo uma conversa.

Permanece calado.

De repente:

BRILHO.

Os olhos desaparecem.

E ele diz algo decisivo.

Instantaneamente o espectador entende que alguma coisa mudou.

Não porque ouviu.

Mas porque viu.

É uma linguagem visual.

Uma comunicação silenciosa.

O diretor não precisa explicar nada.

O cérebro do espectador completa sozinho.


O equivalente corporativo

Imagine uma reunião de crise.

Todos discutindo.

Todos nervosos.

Todos emitindo opiniões.

No canto da sala existe um analista experiente.

Quieto.

Observando.

Anotando.

Sem demonstrar emoção.

Então ele ajusta os óculos e diz:

— Acho que encontrei o problema.

Pronto.

A sala inteira congela.

Por quê?

Porque durante todo o tempo ele estava processando informações.

Nos animes, o brilho nos óculos comunica exatamente isso.

O personagem acabou de concluir uma análise.


O Japão e a cultura das emoções ocultas

Aqui chegamos em um ponto extremamente interessante.

Para entender esse recurso visual precisamos compreender um aspecto importante da cultura japonesa.

Existe um conceito chamado:

Honne

e

Tatemae

Honne representa os sentimentos verdadeiros.

Aquilo que a pessoa realmente pensa.

Tatemae representa a máscara social.

Aquilo que ela mostra ao mundo.

A sociedade japonesa historicamente valoriza harmonia social.

Conflitos diretos costumam ser evitados.

Expressões emocionais intensas nem sempre são incentivadas.

Consequentemente surgiu uma cultura altamente especializada em comunicação indireta.

Nem tudo é dito.

Nem tudo é mostrado.

Nem tudo é revelado.

O personagem de óculos com olhos ocultos se encaixa perfeitamente nessa lógica.

Ele possui uma camada invisível.

Algo que ainda não foi revelado.


O caso clássico dos vilões

Observe quantos vilões memoráveis utilizam esse recurso.

Eles raramente mostram tudo o que sentem.

Aizen.

Kabuto.

Gendo Ikari.

Vários personagens de Death Note.

Diversos antagonistas de Gundam.

Muitos executivos corruptos de animes corporativos.

O motivo é simples.

O vilão precisa parecer difícil de interpretar.

Se enxergarmos claramente suas emoções, ele perde parte do mistério.

Ao esconder os olhos, o autor esconde também suas intenções.


O poder do olhar humano

Curiosamente, isso não surgiu apenas nos animes.

O cinema faz a mesma coisa há décadas.

Pense em quantos personagens usam:

  • óculos escuros;

  • sombras;

  • chapéus;

  • máscaras;

  • fumaça;

  • iluminação parcial.

Todos esses elementos possuem o mesmo objetivo.

Reduzir o acesso emocional do público.

Quanto menos vemos os olhos, menos compreendemos a pessoa.


Mob Psycho 100 e o vazio emocional

Na imagem que motivou este artigo vemos um exemplo fascinante.

Shigeo Kageyama.

O famoso Mob.

À primeira vista ele parece apenas um garoto comum.

Mas o design do personagem é extremamente inteligente.

Mob possui emoções reprimidas.

Tem dificuldades de expressão.

Passa boa parte da história vivendo quase em piloto automático.

Seus olhos frequentemente parecem vazios.

Neutros.

Distantes.

Quando o brilho dos óculos surge, essa sensação aumenta.

É como se estivéssemos olhando para alguém cujo mundo interior permanece inacessível.

E isso é proposital.

O autor está usando linguagem visual para contar a história sem precisar explicá-la.


O cabelo sobre os olhos

Existe um recurso semelhante.

Talvez você já tenha notado.

Muitos personagens possuem franjas cobrindo parcialmente os olhos.

Especialmente em:

  • terror;

  • horror psicológico;

  • dramas;

  • romances melancólicos.

O simbolismo é parecido.

O personagem está escondendo algo.

Pode ser:

  • trauma;

  • tristeza;

  • culpa;

  • insegurança;

  • isolamento.

O espectador percebe isso mesmo sem receber nenhuma explicação.


Por que isso funciona tão bem?

Porque o cérebro humano odeia lacunas.

Quando falta informação, tentamos preenchê-la.

É exatamente o mesmo princípio que faz funcionar:

  • histórias de mistério;

  • thrillers;

  • investigações;

  • conspirações.

O cérebro se torna participante da narrativa.

Ele começa a fazer hipóteses.

E quando o cérebro participa, o envolvimento emocional aumenta.


O operador de produção que não mostra os logs

Agora vamos trazer a discussão para nosso mundo.

Imagine um sistema crítico.

O job executa normalmente.

Nenhum erro aparece.

Nenhuma mensagem surge.

Nenhum alerta dispara.

Mas o processamento está mais lento.

Algo parece errado.

Você sabe que existe um problema.

Mas não consegue vê-lo.

Essa sensação é muito semelhante ao que sentimos diante de um personagem cujos olhos permanecem ocultos.

A informação existe.

Mas não está disponível.

O mistério gera atenção.


A evolução dos personagens

Outro detalhe interessante.

Muitos autores utilizam esse recurso apenas no início da história.

Conforme o personagem amadurece, seus olhos passam a ser mostrados com mais frequência.

É uma representação visual de crescimento emocional.

O personagem deixa de esconder quem é.

O público passa a enxergar seu interior.

Sem perceber, estamos assistindo uma transformação psicológica traduzida em elementos gráficos.


O terror japonês entende isso melhor do que ninguém

Os mestres do horror japonês exploram essa técnica há décadas.

Sadako.

Kayako.

Tomie.

Inúmeros fantasmas e espíritos.

Muitas vezes seus olhos estão:

  • escondidos;

  • cobertos;

  • sombreados;

  • distorcidos.

O motivo é profundamente psicológico.

O cérebro humano precisa dos olhos para classificar intenções.

Quando eles desaparecem, surge uma sensação ancestral de perigo.

Não sabemos o que aquela entidade quer.

Não sabemos o que está pensando.

Não sabemos se vai atacar.

A incerteza gera medo.


O oposto dos heróis clássicos

Agora observe os protagonistas tradicionais.

Dragon Ball.

Naruto.

One Piece.

My Hero Academia.

Eles geralmente possuem olhos enormes e expressivos.

O objetivo é exatamente o contrário.

O espectador deve compreender instantaneamente seus sentimentos.

Tudo é transparente.

Tudo é visível.

Tudo é emocionalmente acessível.

Por isso são personagens fáceis de gostar.

Você entende quem eles são.

Você entende o que sentem.

Você entende o que desejam.


A genialidade da linguagem visual japonesa

O que mais me impressiona nesse tema é perceber como o Japão transformou detalhes aparentemente simples em ferramentas narrativas sofisticadas.

Um brilho numa lente.

Uma sombra.

Uma franja.

Um reflexo.

Nada disso está ali por acaso.

São mensagens.

São códigos.

São informações transmitidas visualmente.

O espectador não precisa estudar psicologia para compreendê-las.

Seu cérebro interpreta tudo automaticamente.

E talvez seja exatamente por isso que os animes conseguem transmitir tantas emoções mesmo em cenas silenciosas.


Considerações finais

Quando assistimos um anime e vemos um personagem cujos olhos desaparecem atrás dos óculos, estamos observando muito mais do que um simples efeito gráfico.

Estamos vendo um recurso narrativo construído ao longo de décadas.

Uma ferramenta que mistura:

  • psicologia humana;

  • semiótica;

  • cultura japonesa;

  • linguagem cinematográfica;

  • design de personagens.

Os olhos representam acesso.

Quando aparecem, conhecemos a pessoa.

Quando desaparecem, surge o mistério.

E talvez essa seja a verdadeira magia dos animes.

Eles entendem algo que a tecnologia, os sistemas e até os ambientes corporativos nos ensinam diariamente:

Nem sempre o que mais importa está visível.

Às vezes os dados mais importantes estão escondidos atrás da interface.

Atrás da tela.

Atrás do log.

Ou, como gostam os mestres da animação japonesa...

Atrás de um simples par de óculos.


🥃 Cachaça, Uísque e Vodka – a Guerra Fria dos Copos Paulistanos

 



🥃 Cachaça, Uísque e Vodka – a Guerra Fria dos Copos Paulistanos
por El Jefe – Bellacosa Mainframe / Filosofia de Balcão Edition

Em São Paulo, o mundo se divide em três castas invisíveis, mais antigas que o DDD 011:
os que bebem cachaça, os que juram por uísque, e os que se acham modernos com vodka.
Três destilados, três ideologias, três maneiras de encarar a vida — e a ressaca.
É a luta de classes em estado líquido.

💥 CENA 1: O BOTECÃO DO PROLETARIADO
Num balcão de zinco em São Miguel, o proletário chega de macacão azul, suando dignidade.
Pede sua caninha sem olhar o rótulo.
Cachaça é cachaça — e conversa encerrada.
Bebe num copo 7, puro, sem frescura, com aquele golpe seco que parece bronca de pai.
É a bebida da honra operária, do salário suado, da marmita de alumínio e da conversa direta:

“Aqui é pinga, não é perfuminho de russo.”

A cachaça nasceu com o Brasil.
É o log do país: destilada da cana, ignorada pela elite, mas mantida viva pelo povo.
Aguardente, caninha, marvada — chame como quiser.
Ela atravessou impérios, repúblicas, planos econômicos e amores de bar.
É o firmware etílico nacional, o código-fonte da brasilidade.

📈 CENA 2: O BURGUÊS DE BLAZER E GELO IMPORTADO
Corta para o Jardins.
A taça de cristal, o terno alinhado, o “me vê um uísque com duas pedras de gelo, por favor”.
O uísque é o login do status.
É o jeito de dizer “trabalho com importação e exportação” sem precisar provar nada.
É a bebida de quem acha que “boteco” é conceito gourmet e não sobrevivência.

Mas há que se reconhecer: o uísque tem sua história.
Chegou aos bares paulistanos nos anos 50, quando os diplomatas e os publicitários começaram a sonhar em inglês.
No fim dos 70, virou febre entre os executivos da Paulista, os mesmos que usavam terno no calor e falavam “weekend” em vez de fim de semana.
Foi a era do Teacher’s, do Old Eight, do Red Label — e da pretensão líquida.

Mas até ele tem seu lado humano.
Porque depois da terceira dose, o executivo também chora, também fala da ex, e também termina a noite no pastel da esquina com os proletários.
No fim, o uísque só disfarça o mesmo bug: a solidão bem servida.

❄️ CENA 3: O FRESCO URBANO DE COPINHO TRANSPARENTE
E então veio ela: a vodka.
Filha da era pós-moderna, sem cheiro, sem cor, sem culpa.
A preferida da geração que troca “boteco” por “bar descolado” e pinga por “shot gelado”.
Nos anos 90, quando os DJs tomaram o lugar dos sanfoneiros e a Balalaika invadiu os supermercados, nasceu o beber cosmopolita.

A vodka era o símbolo da modernidade líquida de Bauman, só que servida com groselha.
Foi a bebida dos jovens da Augusta, das raves em galpão, das baladas onde a autenticidade era medida pelo teor alcoólico.
E convenhamos: vodka é uma delícia travestida de neutralidade.
Ela combina com tudo — suco, energético, drama, carência — e não fede a nada.
É o sistema operacional multiplataforma da bebedeira.

⚙️ O CHOQUE DE SISTEMAS
Cachaça é mainframe: sólida, confiável, roda há séculos.
Uísque é middleware: precisa de status, licenciamento e manual de uso.
Vodka é nuvem: leve, translúcida e cheia de bug emocional.

Mas no boteco da Sé, todos rodam no mesmo servidor.
Porque ali, a filosofia de balcão é simples:

“O copo é o mesmo. O que muda é o código-fonte da vergonha.”

🔮 ADAPTAÇÕES, GOURMETIZAÇÕES E HERESIAS
Nos anos 2000, inventaram a cachaça premium — envelhecida em barril francês e vendida em shopping.
O uísque ganhou versão com energético, pra parecer jovem.
E a vodka virou base de drink “fit” com água de coco.
A guerra virou comédia.
A elite bebe o que o povo inventou, o povo sonha com o que a elite bebe, e o fresco fotografa tudo pro Instagram.

🗣️ LENDAS DE BALCÃO
Dizem que a cachaça foi quem derrubou mais presidentes que qualquer golpe.
O uísque inspirou mais demissões que o FMI.
E a vodka... bem, a vodka é responsável por mais mensagens indevidas às 3h da manhã do que qualquer outro software emocional.

💬 REFLEXÃO FINAL – A DEMOCRACIA DO GOLÉ
No fundo, toda bebida é igual.
Todas queimam, todas consolam, todas mentem.
O que muda é a interface social.
O proletário brinda à sobrevivência.
O burguês, à aparência.
E o fresco, à estética do gole perfeito.

Mas o Bellacosa te lembra:

“No fim da noite, o copo é um espelho. E o que você bebe é o reflexo do que não quer admitir.”

🥂 Moral do balcão:
A cachaça fala a verdade.
O uísque disfarça a dor.
E a vodka finge que nada aconteceu.
Mas, no fundo, todos os três rodam sob o mesmo sistema operacional: o coração humano em modo debug.


🕶️ Bellacosa Mainframe – onde filosofia e pinga rodam na mesma partição.

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