☕ 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

sexta-feira, 27 de novembro de 2020

Desvendando o Labirinto dos "Fetiches Japoneses": Percepção, Realidade e a Complexidade da Cultura Pop

 


Desvendando o Labirinto dos "Fetiches Japoneses": Percepção, Realidade e a Complexidade da Cultura Pop

Alerta de Spoiler Cultural: Se você esperava uma resposta simples sobre o Japão ser a Terra dos Fetiches™ e seguir em frente, prepare-se. O buraco do coelho é mais profundo, e o que parece um "fetiche japonês" à primeira vista, muitas vezes é um entrelaçamento complexo de história, cultura, mídias e, sim, a universalidade da psique humana. Como bons investigadores da Mainframe, vamos mergulhar de cabeça.

Fofoquice Inicial: A Percepção Ocidental e o Efeito Anime

É uma pergunta comum, quase um meme cultural no ocidente: "Por que o Japão é tão... peculiar com seus fetiches?". E, vamos ser sinceros, para quem consome anime e mangá regularmente, a impressão de que "qualquer coisa pode ser um fetiche" ou que existem nichos inimagináveis é quase palpável. Uniformes de colegial, maids, tentáculos, "garotas-gato", meias até a coxa, óculos, tsunderes... a lista é vasta e, para um olhar externo, pode parecer que o Japão é um paraíso de especializações eróticas.

Dica Bellacosa Mainframe: Antes de julgar, lembre-se que nossa percepção é filtrada por nossa própria cultura e pelas mídias que consumimos. O que vemos nos animes é uma fração, muitas vezes exagerada e estilizada, da realidade japonesa.

O Contexto Histórico e a Expressão Artística

Para entender o "porquê", precisamos de um flash de história e comportamento.

Curiosidade Histórica: Ukiyo-e e a Liberdade Erótica do Passado Muito antes de animes e mangás, o Japão já tinha uma rica tradição de arte erótica conhecida como shunga (parte do movimento Ukiyo-e, "pinturas do mundo flutuante"). Essas gravuras e pinturas, do período Edo (séculos XVII ao XIX), eram explícitas, inovadoras e muitas vezes humorísticas. A sexualidade era abordada de forma mais aberta e menos "pecaminosa" do que em muitas culturas ocidentais da época. Isso sugere uma base cultural de aceitação da expressão erótica que não é puramente um fenômeno moderno. A pornografia não era um tabu tão grande na sociedade japonesa pré-moderna quanto em outras culturas que sofriam forte influência religiosa.

Comportamento: A Separação entre Esfera Pública e Privada No Japão, existe uma forte distin separação entre o honne (sentimentos e opiniões verdadeiras) e o tatemae (o que se mostra publicamente). Isso se reflete também na sexualidade e nos interesses pessoais. A sociedade japonesa tende a ser mais conservadora na esfera pública, mas permite uma grande liberdade (e privacidade) para o que acontece na esfera privada e nos hobbies. A indústria de animes e mangás, incluindo os gêneros mais voltados para adultos (hentai, ecchi), prospera nesse espaço.

Easter-Egg: A "Kawaii" e a Dessexualização (e re-sexualização) A cultura Kawaii (fofo) é onipresente no Japão. Muitos elementos que ocidentais poderiam considerar fetiches (como a infantilização de personagens, roupas "fofas", etc.) podem, inicialmente, ter uma raiz na busca pela "fofura" e na cultura juvenil. No entanto, é inegável que, no contexto de certas mídias, esses elementos podem ser ressexualizados ou adotar um tom erótico. A dualidade do "fofo" e do "sexy" é uma característica marcante.

A Indústria de Conteúdo e a "Caça ao Nicho"

Aqui entramos no cerne da questão da "percepção seletiva" e do "fundamento".

Reflexão: A Economia do Nicho A indústria japonesa de entretenimento (anime, mangá, jogos) é gigantesca e extremamente competitiva. Para se destacar e encontrar seu público, os criadores buscam nichos cada vez mais específicos. Se um tipo de personagem, roupa, comportamento ou interação gera interesse (e lucro), ele é explorado, desenvolvido e refinado. Isso cria uma espiral onde o que começa como uma preferência modesta pode se solidificar em um "gênero" ou "fetiche" reconhecível.

Exemplos Notórios (sem juízo de valor):

  • Maids: Originárias do conceito de serviço de luxo, foram popularizadas em animes e games, tornando-se um ícone de "fofura e submissão" com inúmeras variações.

  • Óculos (Megane): Personagens usando óculos são um "moe point" (ponto de atração) para muitos, simbolizando inteligência, seriedade ou um charme particular.

  • Meias Over-the-Knee (Zettai Ryouiki): A área de pele exposta entre uma minissaia/short e meias que cobrem a coxa. É um dos "fetiches" mais conhecidos e estudados, com regras estéticas sobre a proporção ideal entre coxa, meia e saia.

  • Tentáculos: Enquanto no Ocidente podem ser vistos como puramente monstruosos, no Japão têm uma longa história em shunga e na ficção, muitas vezes com conotações eróticas e de poder.

A Universalidade vs. A Especificidade Cultural É importante notar que muitos "fetiches japoneses" têm análogos em outras culturas. A atração por uniformes, certas vestimentas, ou dinâmicas de poder não é exclusiva do Japão. O que difere é a forma como são apresentados, explorados e normalizados dentro da mídia mainstream e, consequentemente, a visibilidade que ganham. O Ocidente tende a ter mais restrições na exposição de certos temas na mídia de massa, enquanto no Japão a separação público/privado permite uma maior liberdade criativa nesses nichos, desde que não violem certas leis de representação.

Comportamento e Sociedade Moderna

Reflexão: A Pressão Social e os Hobbies A sociedade japonesa é conhecida por suas altas expectativas e pressões sociais, seja na escola ou no trabalho. Para muitos, hobbies e mídias de entretenimento (incluindo as de nicho) servem como uma válvula de escape, um espaço seguro para explorar interesses e identidades que talvez não sejam bem-vindas no dia a dia. A internet e as comunidades online amplificaram isso, permitindo que indivíduos com interesses muito específicos se encontrem e se apoiem.

Curiosidade: O "Homem Herbívoro" (Sōshoku Danshi) Este termo se popularizou para descrever jovens japoneses que demonstram pouco interesse em romance, sexo ou relacionamentos tradicionais, preferindo hobbies e amizades. Isso pode, em parte, levar a uma maior imersão em fantasias e conteúdos de nicho, onde as expectativas sociais são suspensas.

Veredito Mainframe: É Percepção, Mas com Fundamento Cultural

Sua impressão não é totalmente "percepção seletiva" e não é sem fundamento.

  • Sim, há um fundamento cultural e histórico para uma maior abertura à expressão erótica e à exploração de nichos.

  • Sim, a indústria de entretenimento japonesa é extraordinariamente eficaz em identificar, cultivar e capitalizar esses nichos, tornando-os visíveis (especialmente para o público externo).

  • Sim, a separação entre a esfera pública e privada na sociedade japonesa permite que esses interesses floresçam sem necessariamente confrontar as normas sociais mais amplas.

No final das contas, o Japão não é apenas uma fábrica de fetiches, mas um ecossistema cultural complexo onde a criatividade, a busca por nichos de mercado e uma certa liberdade de expressão (especialmente no consumo privado de mídia) se encontram. O que o ocidental vê como "fetiche" é, para o japonês, parte de um vasto e diversificado leque de preferências e formas de entretenimento que coexistem em uma sociedade que, à sua maneira, encontrou formas de acomodá-las.

Então, da próxima vez que você se deparar com um "moe point" inusitado em um anime, lembre-se: há uma rica tapeçaria de história, sociologia e economia cultural por trás daquela meia até a coxa. E isso, caro investigador, é que torna tudo ainda mais fascinante.


God Object Rules: Quando um Programador COBOL Descobriu que Nem Mesmo o Arquiteto da Matrix Deveria Controlar Tudo Sozinho

 

Bellacosa Mainframe e a god object rules

☕ Um Café no Bellacosa Mainframe

God Object Rules sem Mistérios

Quando um Programador COBOL Descobriu que Nem Mesmo o Arquiteto da Matrix Deveria Controlar Tudo Sozinho

"Todo sistema precisa de liderança. Nenhum sistema sobrevive quando uma única entidade tenta fazer absolutamente tudo."


Prólogo — O Programa que Governava Toda a Matrix

Neo caminhava pelos corredores infinitos da Matrix.

Depois de atravessar dezenas de portas, finalmente chegou até a sala do Arquiteto.

Mas desta vez havia algo diferente.

No centro da sala existia apenas um gigantesco programa.

Seu nome era:

SYSTEM-CORE-MASTER-PROCESSOR-UNIVERSAL

Neo perguntou:

— O que esse programa faz?

O Arquiteto respondeu calmamente.

— Tudo.

Neo estranhou.

— Tudo?

— Sim.

Ele:

  • autentica usuários;

  • calcula empréstimos;

  • processa PIX;

  • envia e-mails;

  • controla cartões;

  • consulta saldo;

  • gera boletos;

  • grava auditoria;

  • imprime relatórios;

  • conversa com APIs;

  • envia mensagens MQ;

  • acessa o Db2;

  • manipula VSAM;

  • chama CICS;

  • controla segurança;

  • gera logs;

  • cria arquivos;

  • calcula impostos;

  • fecha o mês;

  • abre o dia.

Neo ficou em silêncio.

Olhou para o tamanho do programa.

412.873 linhas

Morpheus respirou profundamente.

— Neo...

você acaba de encontrar um God Object.


O que é God Object?

God Object (Objeto Deus) é um antipadrão onde um único componente concentra responsabilidades demais.

Ele conhece tudo.

Controla tudo.

Decide tudo.

Depende de todos.

E todos dependem dele.

Em Programação Orientada a Objetos normalmente é uma classe gigantesca.

No universo COBOL, normalmente aparece como:

  • um programa enorme;

  • um módulo central;

  • um "programa mestre";

  • um controlador universal.


A origem do termo

O conceito surgiu durante a popularização da Programação Orientada a Objetos nos anos 80 e 90.

Quando OO começou a crescer, percebeu-se que muitos desenvolvedores criavam classes responsáveis por praticamente todo o sistema.

Essas classes violavam praticamente todos os princípios de bom projeto.

Receberam então o apelido de:

God Object

Porque pareciam onipresentes.


Matrix explica isso perfeitamente

Durante boa parte da trilogia acreditamos que:

O Arquiteto controla tudo.

Depois descobrimos que não.

Existe também:

  • Oráculo

  • Merovíngio

  • Chaveiro

  • Agentes

  • Programas independentes

  • Sentinelas

Cada um possui responsabilidades diferentes.

Imagine se apenas o Arquiteto tentasse executar tudo sozinho.

A Matrix entraria em colapso.


O nascimento do God Object

Curiosamente...

ele costuma nascer de uma boa intenção.

Primeira versão.

Programa de Clientes

Depois.

"Vamos colocar autenticação."

Depois.

"Aproveita e grava log."

Depois.

"Já calcula limite."

Depois.

"Também envia e-mail."

Depois.

"Também atualiza cartão."

Depois.

"Também consulta PIX."

Cinco anos depois.

O programa virou um universo inteiro.


O COBOL conhece isso muito bem

Imagine um programa chamado:

CLIENTE01

Originalmente fazia apenas cadastro.

Anos depois passou a:

  • consultar saldo;

  • emitir extratos;

  • calcular tarifas;

  • atualizar endereço;

  • validar CPF;

  • gerar auditoria;

  • integrar Open Finance;

  • enviar SMS;

  • gerar arquivos CNAB.

O nome permaneceu.

A responsabilidade desapareceu.


Um exemplo simples

Arquitetura saudável.

CLIENTE

↓

Cadastro

↓

Consulta

↓

Atualização

Agora.

God Object.

CLIENTE

↓

Tudo.

O efeito psicológico

Existe uma razão interessante.

Nosso cérebro gosta de centralizar.

Quando surge uma nova funcionalidade pensamos.

"Vou colocar aqui mesmo."

É mais rápido.

Mais fácil.

Mais conveniente.

Até deixar de ser.


Matrix Reloaded

Imagine Neo.

Cada novo poder descoberto.

Voar.

Parar balas.

Ler código.

Controlar máquinas.

Agora imagine.

Além disso.

Ele também:

pilota a nave.

Conserta motores.

Programa a Matrix.

Opera comunicações.

Faz medicina.

Cozinha.

Conserta o Db2.

Absurdo.

Mas exatamente isso acontece com um God Object.


Como reconhecer?

Existem sinais clássicos.

Programa enorme

Dezenas de milhares de linhas.


Muitas responsabilidades

Faz tudo.


Muitas dependências

Conhece dezenas de módulos.


Muitas chamadas

Todo mundo depende dele.


Alterações frequentes

Sempre muda.

Porque tudo passa por ele.


O Agente Smith adora isso

Porque basta derrubar um único componente.

Todo o sistema sofre.

É um enorme ponto único de falha.


Um exemplo COBOL

Programa:

PGMCORE

Ele:

  • acessa Db2;

  • grava VSAM;

  • chama MQ;

  • consulta REST;

  • gera XML;

  • gera JSON;

  • controla autenticação;

  • calcula impostos;

  • imprime relatórios.

Pergunta.

Qual é sua responsabilidade?

Resposta.

Todas.


O custo invisível

Nova regra.

Antes.

Alterava um programa.

Agora.

Precisa entender:

80 mil linhas.


O impacto no Mainframe

Quanto maior o God Object.

Maior:

  • CPU;

  • tempo de compilação;

  • tempo de testes;

  • risco;

  • dependência.


Existe God Object em arquitetura?

Sim.

Às vezes não é um programa.

É um microsserviço.

Chamado:

CoreService.

Ele atende:

todos.

Isso também é um God Object.


A diferença

Módulo central.

Coordena.


God Object.

Executa tudo.


O papel do Arquiteto

O verdadeiro arquiteto distribui responsabilidades.

Nunca concentra.


O princípio SOLID

God Object viola vários princípios.

Principalmente.

SRP

Single Responsibility Principle.

Um módulo.

Uma responsabilidade.


Matrix e o Oráculo

O Oráculo não tenta controlar toda a Matrix.

Ela aconselha.

O Chaveiro cuida das chaves.

O Merovíngio controla informações.

Cada programa possui função específica.

Essa divisão torna o sistema resiliente.


Como evitar?

Modularização

Divida funções.


CALL

Extraia responsabilidades.


APIs

Separe serviços.


COPYBOOK

Compartilhe estruturas.

Não comportamento.


Refatoração

Remova responsabilidades pouco a pouco.


Revisões

Questione sempre.

"Esse módulo realmente deveria fazer isso?"


Atenção!

Existe uma diferença importante.

Um programa pode ser grande.

Sem ser God Object.

O problema não é o tamanho.

É a quantidade de responsabilidades.


Curiosidade

Muitos sistemas bancários antigos possuem programas chamados:

MASTER

CORE

MAIN

CONTROL

MANAGER

Nem todos são God Objects.

Mas muitos acabaram se tornando.


O perigo

Acoplamento

Tudo depende dele.


Baixa reutilização

Funções ficam escondidas.


Testes difíceis

Cenários infinitos.


Deploy arriscado

Qualquer alteração afeta tudo.


Conhecimento concentrado

Poucas pessoas entendem.


Um exemplo inspirado na Matrix

Imagine.

Existe apenas um personagem.

Ele é:

Arquiteto.

Oráculo.

Neo.

Trinity.

Smith.

Merovíngio.

Chaveiro.

Todos ao mesmo tempo.

A história seria impossível.

Software também.


Ferramentas ajudam

Hoje conseguimos identificar God Objects usando:

  • SonarQube

  • IBM ADDI

  • IBM Application Discovery

  • Enterprise Analyzer

  • IBM COBOL Check

Elas medem:

  • acoplamento;

  • complexidade;

  • dependências;

  • tamanho;

  • responsabilidades.


O papel da IA

IA consegue identificar:

métodos enormes.

Dependências.

Objetos excessivos.

Mas ainda depende da análise humana para decidir como dividir responsabilidades.


Aplicabilidade

God Object aparece em:

  • COBOL

  • Java

  • C#

  • Python

  • PHP

  • JavaScript

  • Microsserviços

  • APIs

  • Cloud

Nenhuma tecnologia escapa.


Erros clássicos

  • Colocar tudo no mesmo programa.

  • Misturar negócio com infraestrutura.

  • Misturar interface com persistência.

  • Acrescentar funcionalidades indefinidamente.

  • Evitar modularização.


Boas práticas

  • Alta coesão.

  • Baixo acoplamento.

  • Uma responsabilidade.

  • Pequenas funções.

  • Interfaces claras.

  • Código reutilizável.

  • Documentação.


O ensinamento do Oráculo

O Oráculo entrega um espelho para Neo.

Ele olha.

Vê apenas um rosto.

Depois o espelho se quebra.

Agora aparecem centenas de pequenos espelhos.

Ela pergunta.

"Qual deles é mais resistente?"

Neo responde.

"Os pequenos."

Ela sorri.

"Quando um quebra, os outros continuam refletindo."

Essa é exatamente a ideia da arquitetura modular.


Lições para um Programador COBOL Padawan

Ao longo da carreira, você encontrará programas que parecem controlar o universo inteiro. A tentação será continuar acrescentando funcionalidades porque "já existe muita coisa ali".

Resista.

Sempre que possível:

  • identifique responsabilidades distintas;

  • extraia regras para módulos especializados;

  • separe acesso a dados das regras de negócio;

  • utilize programas chamados (CALL) para funcionalidades reutilizáveis;

  • mantenha interfaces simples e bem definidas.

Cada responsabilidade removida de um God Object reduz riscos, facilita testes e torna o sistema mais compreensível.


Curiosidades

O antipadrão God Object possui "parentes" famosos:

  • Blob – um objeto gigante rodeado de objetos quase vazios.

  • God Class – termo usado em Java e C# para classes com centenas de métodos.

  • Swiss Army Knife Class – classe que tenta oferecer uma ferramenta para qualquer situação.

  • Manager Mania – classes chamadas Manager, Helper ou Util que acabam concentrando comportamento demais.

Todos compartilham a mesma característica: excesso de responsabilidades.


Conclusão — Nem Mesmo o Arquiteto Controlava Tudo

No universo Matrix existe uma lição fascinante.

Embora o Arquiteto parecesse controlar toda a simulação, ele não fazia tudo sozinho. A estabilidade do sistema dependia da colaboração entre diversas entidades, cada uma especializada em uma função.

A Engenharia de Software segue exatamente esse princípio.

Quando um único programa COBOL, uma classe Java ou um microsserviço tenta assumir todas as responsabilidades, ele se transforma em um God Object. No início parece eficiente. Depois torna-se pesado, difícil de testar, arriscado de modificar e praticamente impossível de compreender.

Para um Programador COBOL, especialmente em ambientes IBM Z que processam milhões de transações críticas, a maior virtude não é escrever o maior programa da empresa.

É construir componentes pequenos, coesos, bem definidos e capazes de cooperar entre si.

No universo Bellacosa Mainframe existe uma máxima digna do Oráculo:

"Um sistema forte não nasce de um único programa poderoso. Nasce de muitos módulos simples que sabem exatamente qual é sua missão."

Porque até a Matrix precisou aprender que nenhum programa deveria tentar ser um deus.

domingo, 22 de novembro de 2020

🎒🌸 Bellacosa Otaku Blog — Parte 35: Expressões do Cotidiano e da Vida Escolar nos Animes 🌸🎒

 

Bellacosa Mainframe e expressoes do cotidiano japones


🎒🌸 Bellacosa Otaku Blog — Parte 35: Expressões do Cotidiano e da Vida Escolar nos Animes 🌸🎒


🌸 Bellacosa Otaku Blog — Parte 35

Expressões do Cotidiano e da Vida Escolar nos Animes

Existe um motivo pelo qual os animes do gênero slice of life conseguem transmitir uma sensação tão acolhedora. Mesmo quando quase nada extraordinário acontece na história, somos envolvidos por pequenos gestos, conversas simples e palavras que fazem parte da rotina dos personagens. Um "bom dia" na entrada da escola, um "boa sorte" antes de uma prova, um "obrigado pela refeição" na hora do almoço ou um "bom trabalho" ao final do dia transformam momentos comuns em lembranças inesquecíveis.

Grande parte desse encanto está na língua japonesa. Diferentemente de muitos idiomas ocidentais, diversas expressões do cotidiano carregam significados culturais profundos. Elas não servem apenas para comunicar uma informação, mas para demonstrar respeito, gratidão, empatia, incentivo e pertencimento ao grupo. Por isso, mesmo quem nunca estudou japonês acaba reconhecendo palavras como ohayō, itadakimasu, ganbatte ou daijōbu depois de assistir a alguns animes.

Nesta trigésima quinta edição do Bellacosa Otaku Blog, vamos conhecer algumas das expressões mais presentes na vida escolar japonesa e descobrir por que elas aparecem tantas vezes em séries como K-On!, Horimiya, Clannad, Toradora!, Your Name, Your Lie in April e tantas outras obras que transformam a simplicidade do cotidiano em algo emocionante.

Você perceberá que aprender essas palavras vai muito além de decorar vocabulário. É uma maneira de compreender melhor os sentimentos dos personagens, captar nuances das legendas que muitas vezes se perdem na tradução e enxergar o Japão sob a perspectiva de quem realmente vive aquele dia a dia. Afinal, às vezes um simples "ganbatte" vale muito mais do que um longo discurso, e um sincero "itadakimasu" revela toda uma filosofia de respeito pela comida, pelas pessoas e pela vida.

Então prepare seu bentō, coloque a mochila nas costas, atravesse o portão da escola e venha caminhar pelos corredores dos animes conosco. Entre salas de aula, clubes escolares, festivais culturais e reencontros de amigos, descobriremos como algumas das palavras mais simples do idioma japonês são capazes de aquecer o coração e tornar inesquecíveis os momentos mais comuns da vida. Afinal, são justamente essas pequenas expressões que dão alma às histórias que tanto amamos. 🌸🎒🍱


☀️ O idioma dos dias simples e das pequenas alegrias

(Versão Bellacosa: risadas no corredor, lanches no intervalo e o charme dos dias comuns.)

Nos animes slice of life, colegiais e de comédia leve, o japonês ganha um tom doce, cotidiano e realista, revelando o encanto da rotina.
Cada palavra expressa proximidade, amizade e momentos comuns — que se tornam mágicos quando vistos pelos olhos de um personagem de anime. ✨


🍱 1. おはよう (ohayō)

Tradução: “Bom dia!”
👉 Expressão básica e calorosa usada entre amigos e colegas logo cedo.

📺 Anime vibe: K-On!, Horimiya, Clannad.
💬 Exemplo: “Ohayō! Dormiu bem?” ☀️


📚 2. 行ってきます (ittekimasu)

Tradução: “Estou saindo / até logo.”
👉 Usada ao sair de casa, com a resposta tradicional itterasshai (“volte logo”).

📺 Anime vibe: Your Name, Clannad.
💬 Exemplo: “Ittekimasu! Hoje tem prova!” 🚲


🍡 3. いただきます (itadakimasu)

Tradução: “Agradeço pela comida.”
👉 Ritual dito antes de comer, mostrando gratidão e respeito.

📺 Anime vibe: My Neighbor Totoro, K-On!
💬 Exemplo: “Itadakimasu! Esse bentō está incrível!” 🍱


🏫 4. 頑張って (ganbatte)

Tradução: “Boa sorte / dê o seu melhor!”
👉 Expressão de incentivo e motivação entre amigos e colegas.

📺 Anime vibe: My Hero Academia, Clannad.
💬 Exemplo: “Ganbatte no teste, você consegue!” 💪


💬 5. どうしたの (dō shita no)

Tradução: “O que aconteceu?”
👉 Mostra preocupação e cuidado, comum em amizades próximas.

📺 Anime vibe: Horimiya, Your Lie in April.
💬 Exemplo: “Dō shita no? Está com cara de sono…” ☕


🌧️ 6. 大丈夫 (daijōbu)

Tradução: “Tudo bem / está tudo certo.”
👉 Expressão versátil de conforto, usada em várias situações.

📺 Anime vibe: Clannad, Toradora!
💬 Exemplo: “Daijōbu, só tropecei um pouco!” 😅


🌸 7. 久しぶり (hisashiburi)

Tradução: “Quanto tempo!”
👉 Usada para reencontros entre amigos.

📺 Anime vibe: Your Name, Orange.
💬 Exemplo: “Hisashiburi! Você mudou o cabelo!” ✨


📖 8. 授業 (jugyō)

Tradução: “Aula.”
👉 Palavra comum do ambiente escolar.

📺 Anime vibe: K-On!, Horimiya.
💬 Exemplo: “Jugyō começa em cinco minutos! Corre!” 📚


🧃 9. 放課後 (hōkago)

Tradução: “Depois das aulas.”
👉 Momento de liberdade e aventuras, típico de histórias colegiais.

📺 Anime vibe: K-On!, Toradora!
💬 Exemplo: “Hōkago é a hora perfeita pro clube!” 🎶


🌆 10. お疲れ様 (otsukaresama)

Tradução: “Bom trabalho / você se esforçou.”
👉 Expressão de reconhecimento após esforço ou fim do dia.

📺 Anime vibe: Clannad, K-On!
💬 Exemplo: “Otsukaresama! Hoje foi um dia cheio.” 🌇


🏮 Curiosidades Bellacosa:

  • Palavras como ohayō, itadakimasu e otsukaresama criam ritual e harmonia no dia a dia japonês.

  • Expressões de encorajamento (ganbatte, daijōbu) reforçam amizade e empatia natural entre personagens.

  • Termos escolares (jugyō, hōkago) evocam nostalgia e leveza, típicas de histórias colegiais. 🎒


🌟 Dica Bellacosa:

  • Repare nos tons e contextos: daijōbu pode significar tanto “tudo bem” quanto “deixa comigo!”.

  • Palavras curtas e repetidas no cotidiano mostram a importância da cortesia e das pequenas gentilezas.

  • Memorizar essas expressões ajuda a captar a atmosfera leve e afetiva dos animes de vida escolar. 🌸


🌸 Conclusão Bellacosa:

As expressões da vida cotidiana japonesa transformam o idioma em um retrato poético da simplicidade e dos laços diários.
Cada “ohayō” e cada “ganbatte” carrega calor, respeito e um toque de ternura — o coração dos slice of life.

“Itadakimasu, ganbatte, otsukaresama… as palavras do dia que aquecem o coração.” ☀️🍱

quarta-feira, 18 de novembro de 2020

🧠☕ Bellacosa Mainframe apresenta: El Jefe e o mito do Johnny Castaway — o náufrago digital que vive em nossos corações CRT

 

Bellacosa Mainframe apresenta o mitologico Johnny Castaway

🧠☕ Bellacosa Mainframe apresenta: El Jefe e o mito do Johnny Castaway — o náufrago digital que vive em nossos corações CRT



Nos idos dos anos 1990, quando o som de um modem 56k ainda fazia o coração bater mais rápido e o Windows 95 era sinônimo de modernidade, surgiu uma figura solitária que povoou milhões de telas e imaginários: Johnny Castaway, o homem preso numa ilha pixelada, sobrevivendo ao tédio... e ao screensaver.

Sim, padawan — antes do TikTok, do YouTube e até do MSN Messenger, nós tínhamos salvadores de tela com alma. E nenhum foi mais emblemático do que o “Johnny Castaway”, o protetor de tela lançado pela Sierra On-Line em 1992, dentro da linha Screen Antics.




🌴 A História

John Castaway era um náufrago de camisa rasgada, barba por fazer e o eterno olhar de quem já tinha aceitado o caos da vida.
Preso numa minúscula ilha com um coqueiro e uma gaivota, ele fazia de tudo para não enlouquecer: pescava, construía, sonhava, e — às vezes — enviava mensagens dentro de garrafas.
O detalhe genial: suas animações mudavam conforme o tempo. Havia dezenas de pequenas cenas, algumas raríssimas, que apareciam de forma aleatória, como um easter egg para quem deixava o computador ocioso por horas.




🧩 Origem e bastidores

Criado pela Dynamix, subsidiária da Sierra, o screensaver era quase um experimento artístico. Ele rodava sobre o sistema Windows 3.1, e sua lógica interna funcionava como um mini game engine — cada animação era um “evento” programado.
O design lembrava os jogos King’s Quest e Leisure Suit Larry, com aquele mesmo humor sarcástico e a estética VGA 256 cores que era pura poesia em 640x480.

Reza a lenda (e aqui entra o lado fofoquinha da Bellacosa Mainframe 🕵️‍♂️):
um dos animadores, ex-programador de Space Quest, teria usado o próprio rosto como referência para o John. E o nome “Castaway”? Veio de uma piada interna no estúdio sobre um funcionário que “sumia” da baía de Monterey nos fins de semana para surfar e não voltava na segunda.




💾 Impacto cultural

Johnny Castaway foi o primeiro protetor de tela com narrativa, um pequeno storytelling que rodava escondido enquanto você tomava café.

Ele virou ícone de nostalgia digital, símbolo de uma época em que o computador era quase um companheiro de jornada.
E se você perguntar a qualquer veterano da era 486DX2, ele vai sorrir e dizer: “Ah, o náufrago! Aquele que nunca foi resgatado…”



John foi o primeiro “personagem digital persistente” de muita gente. Num tempo em que não existia The Sims nem Animal Crossing, o Castaway era a nossa janela pra um mundinho animado, com humor, rotina e um toque melancólico. Ele virou assunto em fóruns, revistas de tecnologia e até em lan houses — o pessoal deixava o PC ocioso só pra ver o que ele ia aprontar.


Nos fóruns e subreddits de retrocomputing, até hoje há pedidos de remakes ou versões em HTML5. Alguns heróis anônimos já recriaram o Johnny em emuladores, outros até o portaram para Android. É o espírito da ilha sobrevivendo no tempo.




🔍 Curiosidades dignas de café forte:

  • Ele tinha mais de 35 animações diferentes — uma mini-série escondida no seu PC.

  • O programa usava o relógio do sistema, então ele vivia em “tempo real” — o pôr do sol acontecia quando era pôr do sol de verdade.

  • O arquivo original tinha menos de 1 MB. Hoje, um sticker de WhatsApp ocupa mais espaço.

  • Nos bastidores da Sierra, o projeto era chamado de The Deserted Developer.

  • Em 2020, fãs recriaram a experiência em HTML5, batizando o site de “Johnny Recastaway”.




💡 Dica de El Jefe

Quer reviver a ilha? Há versões rodando via emulador de Windows 3.1 online. Procure “Johnny Castaway em DOSBox” — é pura arqueologia digital, mas vale cada frame.
E, claro, cuidado: assistir por muito tempo pode causar um súbito desejo de jogar Leisure Suit Larry e ouvir MIDI Jazz.


    

☕ Conclusão Bellacosa

Johnny Castaway não era apenas um protetor de tela. Era um espelho da alma do programador dos anos 90: isolado, criativo, meio perdido e sempre tentando mandar uma mensagem dentro de uma garrafa digital.

Ele é o primeiro filósofo do idle time, o estoico dos CRTs, o Sêneca da areia pixelada.
E, no fundo, cada um de nós, entre commits, deadlines e janelas travadas, é um pequeno Johnny olhando o horizonte, esperando o resgate… ou o próximo frame de animação.


🪶 Assinado: El Jefe do Bellacosa Mainframe – porque até um screensaver pode ensinar mais sobre a solidão humana do que muita reunião de sprint.

Simuilador javascript Johnny Castaway

https://eljefemidnightlunch.blogspot.com/1991/01/johnny-castaway-uma-homenagem-ao.html

domingo, 15 de novembro de 2020

⚔️🔥 Bellacosa Otaku Blog — Parte 34: Expressões de Amizade e Rivalidade em Batalhas Shounen 🔥⚔️



 ⚔️🔥 Bellacosa Otaku Blog — Parte 34: Expressões de Amizade e Rivalidade em Batalhas Shounen 🔥⚔️


💥 O idioma do desafio, força e companheirismo nos animes shounen

(Versão Bellacosa: golpes épicos, gritos de batalha e laços que se fortalecem na luta.)

Nos animes shounen, a rivalidade e a amizade se entrelaçam, criando uma linguagem de superação, respeito e intensidade.
Cada expressão transmite emoção, competição e espírito de equipe, fazendo as batalhas memoráveis e os laços inquebráveis.
Vamos explorar as mais icônicas! ⚡


💪 1. 修行 (shugyō)

Tradução: “Treinamento / disciplina.”
👉 Palavra para esforço constante visando crescimento e força.

📺 Anime vibe: Naruto, Dragon Ball, My Hero Academia.
💬 Exemplo: “Shugyō diário é essencial para superar limites!” 🏋️


⚡ 2. 強さ (tsuyosa)

Tradução: “Força / poder.”
👉 Representa habilidade física, mental ou espiritual.

📺 Anime vibe: Dragon Ball, Naruto, One Piece.
💬 Exemplo: “Tsuyosa não vem sem esforço!” 💥


🤝 3. 友情 (yūjō)

Tradução: “Amizade / companheirismo.”
👉 Reflete laços fortes que motivam personagens a lutar e proteger uns aos outros.

📺 Anime vibe: Naruto, One Piece, Fairy Tail.
💬 Exemplo: “Yūjō nos dá coragem para enfrentar qualquer inimigo!” 💖


🏆 4. ライバル (raibaru)

Tradução: “Rival / concorrente.”
👉 Estimula crescimento e competição saudável entre personagens.

📺 Anime vibe: Naruto, My Hero Academia, Dragon Ball.
💬 Exemplo: “Raibaru sempre me empurra a superar meus limites!” ⚡


🔥 5. 必殺技 (hissatsu waza)

Tradução: “Golpe mortal / técnica especial.”
👉 Termo para ataques poderosos ou movimentos decisivos em combate.

📺 Anime vibe: Dragon Ball, Naruto, One Piece.
💬 Exemplo: “Hissatsu waza ativado… é agora ou nunca!” 💥


🏹 6. 限界 (genkai)

Tradução: “Limite / fronteira.”
👉 Representa a linha entre capacidade atual e força máxima, desafiando o personagem.

📺 Anime vibe: Naruto, Dragon Ball, One Piece.
💬 Exemplo: “Genkai superado… não há mais nada que me detenha!” ⚡


💫 7. 必死 (hisshi)

Tradução: “Desespero / esforço total.”
👉 Expressa dedicação absoluta, geralmente em situações críticas.

📺 Anime vibe: Naruto, Fairy Tail, Dragon Ball.
💬 Exemplo: “Hisshi… vou dar tudo de mim nesta batalha!” 💪


🌟 8. 仲間 (nakama)

Tradução: “Companheiro / aliado.”
👉 Representa amizade profunda e confiança mútua, fundamental para apoio em combate.

📺 Anime vibe: One Piece, Naruto, Fairy Tail.
💬 Exemplo: “Nakama ao meu lado… juntos somos invencíveis!” 🤝


⚔️ 9. 決闘 (kettō)

Tradução: “Duelo / confronto.”
👉 Palavra para batalhas diretas, muitas vezes cheias de estratégia e emoção.

📺 Anime vibe: Naruto, Dragon Ball, My Hero Academia.
💬 Exemplo: “Kettō começa… que vença o melhor!” ⚡


🌪️ 10. 挑戦 (chōsen)

Tradução: “Desafio / tentativa.”
👉 Usada para encarar adversários ou superar obstáculos difíceis.

📺 Anime vibe: Naruto, Dragon Ball, One Piece.
💬 Exemplo: “Chōsen aceito… vou superar meus limites!” 💥


🏮 Curiosidades Bellacosa:

  • Palavras como shugyō, tsuyosa e genkai destacam crescimento pessoal e superação de limites.

  • Termos de amizade e parceria (yūjō, nakama) reforçam valores de companheirismo e confiança.

  • Rivais e confrontos (raibaru, kettō, chōsen) criam tensão e motivação contínua para os protagonistas. ⚔️


🌟 Dica Bellacosa:

  • Observe gritos de batalha, expressões de esforço e impacto visual dos golpes: eles tornam cada duelo emocionante.

  • Frases curtas e motivacionais (hisshi, chōsen, tsuyosa) transmitem intensidade imediata.

  • Memorizar essas expressões ajuda a sentir a energia, rivalidade e vínculo nos animes shounen. 💥


🌸 Conclusão Bellacosa:

As expressões de amizade e rivalidade em batalhas shounen transformam o japonês em uma linguagem de coragem, competição e superação constante.
Cada palavra, ataque ou laço aproxima o espectador do espírito de luta e da força dos personagens.

“Raibaru, nakama e chōsen… juntos, a batalha nunca acaba!” ⚔️🔥

sábado, 14 de novembro de 2020

☕ O Holocron do Chaos Monkey

 

Bellacosa Mainframe e o Chaos Monkey

☕ O Holocron do Chaos Monkey

Como um Pequeno Macaco da Netflix Ensinou ao Mundo Algo que os Sysprogs do IBM Z Já Praticavam Há Décadas

Existe um momento curioso na jornada de todo Padawan COBOL, Sysprog, arquiteto ou profissional de infraestrutura em que ele descobre uma verdade desconfortável.

Nenhum sistema é indestrutível.

Nenhuma arquitetura é perfeita.

Nenhum diagrama bonito no PowerPoint é capaz de impedir que um disco falhe, uma fibra seja rompida, uma aplicação entre em loop, uma região CICS desapareça ou uma LPAR resolva tirar férias em plena Black Friday.

Foi exatamente dessa constatação que nasceu, em 2011, uma das ideias mais influentes da engenharia moderna de software.

Um pequeno macaco digital.

Travesso.

Imprevisível.

Sem qualquer respeito pelo conforto psicológico dos administradores de sistemas.

Seu nome era Chaos Monkey.

Criado pela Netflix como parte do projeto Simian Army, o Chaos Monkey possuía uma missão aparentemente absurda:

Derrubar servidores deliberadamente.

Mas havia uma razão bastante séria por trás dessa atitude quase sociopata.

A Netflix havia aprendido uma lição dolorosa em 2008, após sofrer problemas importantes de indisponibilidade em sua infraestrutura. A empresa percebeu que esperar que a primeira falha ocorresse naturalmente era uma péssima estratégia.

Era melhor provocar pequenos desastres controlados.

Observar.

Medir.

Aprender.

Corrigir.

Repetir.

Nascia assim o movimento conhecido como Chaos Engineering.

No entanto, enquanto boa parte do mercado enxergava aquilo como uma revolução tecnológica, muitos profissionais do IBM Z apenas levantaram uma sobrancelha, tomaram um gole de café e pensaram:

Interessante...

Nós fazemos algo parecido há décadas.

Sysprogs veteranos conhecem bem essa filosofia.

Testar GDPS.

Executar Disaster Recovery.

Parar uma região CICS.

Desligar um membro Db2 Data Sharing.

Simular perda de um Queue Manager.

Trocar caminhos FICON.

Validar políticas do WLM.

Testar SA z/OS.

Mover workloads.

Executar IPLs programadas.

No fundo, a grande diferença talvez seja apenas de nomenclatura.

A Netflix colocou um macaco sorridente em apresentações corporativas.

O Mainframe chamou isso de plano de contingência, teste de disponibilidade, procedimento operacional ou simplesmente terça-feira à tarde.

Ao longo desta série do ☕ Um Café no Bellacosa Mainframe, acompanhamos a jornada de um Padawan COBOL descobrindo que resiliência não significa impedir falhas.

Significa aprender a conviver com elas.

Automatizá-las.

Medi-las.

Compreendê-las.

E principalmente garantir que o usuário continue tomando seu café tranquilamente enquanto os engenheiros observam gráficos, métricas e dashboards piscando em uma sala de guerra.


📖 Índice do Holocron do Chaos Monkey

Parte I

O Dia em que a Netflix Soltou um Macaco no Datacenter e Descobriu Algo que os Sysprogs do IBM Z Já Sabiam Há Décadas

Nesta primeira jornada, exploramos a origem do Chaos Monkey, a crise enfrentada pela Netflix em 2008, o nascimento do Simian Army, a filosofia de Adrian Cockcroft e os princípios fundamentais do Chaos Engineering, incluindo o conceito de Steady State, hipóteses de falha e a importância de provocar pequenos desastres antes que eles ocorram naturalmente.

https://eljefemidnightlunch.blogspot.com/2020/07/o-holocron-do-chaos-monkey-o-dia-em-que.html


Parte II

Como o Macaco Escolhe suas Vítimas, o Conceito de Blast Radius e as Técnicas Secretas dos Engenheiros da Netflix

No segundo capítulo, estudamos o funcionamento interno dos experimentos de caos, aprendendo conceitos essenciais como:

  • Blast Radius;

  • Observabilidade;

  • Seleção controlada de componentes;

  • Métricas de disponibilidade;

  • Técnicas empregadas por SREs;

  • Ferramentas modernas como Gremlin, LitmusChaos, Chaos Mesh e AWS Fault Injection Simulator.

Também acompanhamos estudos de caso inspirados em arquiteturas bancárias e serviços digitais.

https://eljefemidnightlunch.blogspot.com/2020/08/o-holocron-do-chaos-monkey-como-o.html

Parte III

Quando o Macaco Entra no IBM Z: Será que o Mainframe Precisava Mesmo de um Chaos Monkey?

Na terceira etapa, levamos o Chaos Engineering para dentro do universo IBM Z.

Analisamos como os conceitos de caos podem ser aplicados em:

  • CICSplex;

  • Db2 Data Sharing;

  • MQ Queue Sharing Groups;

  • WLM;

  • Parallel Sysplex;

  • Coupling Facilities;

  • GDPS;

  • SA z/OS;

  • NetView;

  • z/OSMF;

  • Ansible for IBM Z.

Descobrimos que muitos princípios defendidos pela Netflix já eram praticados há décadas pelos Sysprogs mais experientes.

https://eljefemidnightlunch.blogspot.com/2020/09/o-holocron-do-chaos-monkey-quando-o.html


Parte IV

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

Encerrando o Holocron, construímos uma coleção de laboratórios práticos voltados para ambientes IBM Z.

Entre os exercícios apresentados estão:

  • Derrubar uma região CICS secundária;

  • Simular a perda de um membro Db2 Data Sharing;

  • Testar um MQ Queue Sharing Group;

  • Alterar políticas do WLM;

  • Simular indisponibilidade de uma LPAR;

  • Testar Coupling Facilities;

  • Automatizar experimentos utilizando SA z/OS, Ansible e z/OSMF.

Também apresentamos checklists, exemplos de playbooks, métricas recomendadas e um modelo de maturidade em Chaos Engineering para equipes de Sysprog.

https://eljefemidnightlunch.blogspot.com/2020/10/o-holocron-do-chaos-monkey-os.html


☕ A Última Reflexão do Bellacosa Mainframe

Talvez a maior contribuição do Chaos Monkey não tenha sido derrubar servidores.

Talvez tenha sido lembrar aos arquitetos modernos uma lição antiga que os profissionais do IBM Z conhecem há muito tempo:

Disponibilidade não é sorte.

Resiliência não é marketing.

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

E se um pequeno macaco travesso puder nos ensinar isso, talvez ele mereça uma cadeira na próxima reunião de arquitetura... desde que fique longe do botão vermelho da produção. ☕🐵💻🚀

sexta-feira, 13 de novembro de 2020

DotCom : Capítulo XI — Das Cinzas Nasceu um Novo Jeito de Construir Software: Como a Bolha da Internet Criou as Startups Modernas, o Agile e a Cultura Lean

 

Bellacosa Mainframe e o estouro da bolha dotcom capitulo xi

Capítulo XI — Das Cinzas Nasceu um Novo Jeito de Construir Software: Como a Bolha da Internet Criou as Startups Modernas, o Agile e a Cultura Lean

Por que o maior fracasso da primeira geração da Internet tornou-se a fundação da segunda geração da inovação tecnológica

"Os pioneiros constroem o caminho. Os sobreviventes aprendem onde estavam os buracos."

Existe uma frase muito conhecida na engenharia.

"Os sistemas mais robustos normalmente são construídos sobre os erros das versões anteriores."

Isso vale para software.

Vale para hardware.

Vale para aviões.

Vale para automóveis.

E vale perfeitamente para a Internet.

Quando a bolha das Dot-Com estourou, muita gente acreditou que o empreendedorismo tecnológico havia chegado ao fim.

Os investidores desapareceram.

As startups quebraram.

Os escritórios foram fechados.

Os jornais passaram a tratar a Internet com enorme desconfiança.

Mas algo curioso aconteceu.

Enquanto Wall Street enterrava a primeira geração das empresas digitais, engenheiros e empreendedores estavam estudando cuidadosamente tudo o que havia dado errado.

Essa talvez tenha sido a maior herança da bolha.

Ela ensinou.

E ensinou muito.

Foi justamente desse aprendizado que nasceu praticamente toda a cultura de desenvolvimento moderno que conhecemos hoje.


O Fim da Filosofia "Construa Primeiro, Pense Depois"

Durante os anos da bolha existia uma mentalidade bastante comum.

Lançar rapidamente.

Ganhar usuários.

Corrigir problemas depois.

Essa estratégia parecia funcionar enquanto existia dinheiro abundante.

Mas quando o capital desapareceu...

Muitos descobriram que haviam construído sistemas enormes sobre fundações frágeis.

Projetos difíceis de manter.

Infraestruturas caras.

Código praticamente impossível de evoluir.

A indústria compreendeu que velocidade sem direção produz apenas acidentes mais rápidos.


Surge uma Nova Pergunta

Antes da bolha, muitos empreendedores perguntavam:

"Como posso crescer mais rápido?"

Depois da crise, a pergunta mudou completamente.

"Como descubro rapidamente se minha ideia realmente faz sentido?"

Pode parecer apenas uma mudança de palavras.

Na realidade...

Mudou toda a filosofia de desenvolvimento de produtos.

Em vez de investir milhões antes de validar uma hipótese...

Passou-se a testar primeiro.

Aprender rapidamente.

Corrigir.

Evoluir.


O Nascimento da Cultura Lean

Embora suas origens estejam na indústria automobilística japonesa, especialmente no Sistema Toyota de Produção, foi após a bolha da Internet que muitos desses princípios começaram a ser adaptados para startups de tecnologia.

Eliminar desperdícios.

Construir apenas o necessário.

Aprender continuamente.

Melhorar processos.

Entregar valor.

Esses conceitos tornaram-se extremamente populares.

Anos depois surgiria o movimento conhecido como Lean Startup, consolidado por Eric Ries.

Seu princípio central parecia quase revolucionário.

Não construa um produto completo antes de descobrir se alguém realmente precisa dele.

Hoje isso parece óbvio.

Em 1999 não era.


MVP: O Produto Mínimo Viável

Outro conceito que ganhou enorme importância foi o famoso Minimum Viable Product, ou MVP.

A ideia é simples.

Em vez de gastar anos desenvolvendo uma solução perfeita...

Crie uma versão pequena.

Teste com clientes reais.

Aprenda.

Corrija.

Repita.

Essa filosofia reduziu drasticamente o desperdício de tempo e dinheiro.

Empresas passaram a descobrir problemas muito antes de investir milhões em projetos inviáveis.

Em certo sentido...

O MVP tornou-se uma vacina contra muitas das doenças que destruíram as Dot-Com.


O Cliente Tornou-se Parte do Desenvolvimento

Durante a bolha era relativamente comum desenvolver produtos imaginando aquilo que os clientes desejariam.

Após a crise...

As empresas passaram a perguntar diretamente aos usuários.

Entrevistas.

Testes.

Protótipos.

Versões beta.

Feedback contínuo.

O cliente deixou de aparecer apenas no final do projeto.

Passou a participar desde o início.

Essa mudança alterou completamente a engenharia de produtos digitais.


Agile: Responder às Mudanças

Em 2001, praticamente no auge das consequências da bolha, um grupo de desenvolvedores reuniu-se em Snowbird, Utah.

Dessa reunião nasceu o famoso Manifesto Ágil.

Embora suas ideias não tenham surgido exclusivamente por causa da bolha, o contexto histórico teve enorme influência.

Os profissionais estavam cansados de projetos gigantescos que demoravam anos para entregar resultados.

O mercado precisava de adaptação.

Flexibilidade.

Entrega contínua.

Colaboração.

Assim surgiram princípios que hoje fazem parte do cotidiano de praticamente toda empresa de software.


O Manifesto Ágil Não Era Contra Planejamento

Existe um equívoco bastante comum.

Muitas pessoas acreditam que Agile significa ausência de planejamento.

Não significa.

O Manifesto Ágil nunca afirmou isso.

Ele apenas reconheceu que planos precisam evoluir conforme aprendemos mais sobre o problema.

É uma diferença enorme.

Planejar continua sendo essencial.

Mas o plano deixa de ser um documento imutável.

Passa a ser uma ferramenta viva.


Scrum, Kanban e a Nova Organização das Equipes

Poucos anos depois começaram a popularizar-se metodologias como:

Scrum.

Kanban.

Extreme Programming.

Crystal.

Feature Driven Development.

Cada uma com características próprias.

Todas compartilhando uma mesma filosofia.

Aprender continuamente.

Entregar valor frequentemente.

Corrigir rapidamente.

Evitar desperdícios.

Essas ideias transformaram completamente a maneira como software passou a ser desenvolvido.


DevOps: Derrubando Muros

Outro aprendizado importante surgiu da dificuldade de colocar sistemas em produção.

Durante muitos anos existia uma separação rígida.

Os desenvolvedores criavam o software.

A equipe de operações mantinha os servidores.

Quando algo dava errado...

Cada grupo culpava o outro.

A partir da década seguinte ganhou força o conceito de DevOps.

Desenvolvimento e Operações trabalhando juntos.

Automação.

Monitoramento.

Entrega contínua.

Responsabilidade compartilhada.

Foi mais uma consequência indireta da necessidade de construir sistemas mais confiáveis.


A Cultura da Medição

Outra transformação importante ocorreu na maneira como empresas passaram a tomar decisões.

Antes da bolha muitas estratégias eram baseadas principalmente em expectativas.

Depois dela...

Começou a crescer a cultura dos indicadores.

Métricas.

Dashboards.

KPIs.

Testes A/B.

Análises estatísticas.

As empresas passaram a medir praticamente tudo.

Tempo de resposta.

Conversão.

Retenção.

Disponibilidade.

Latência.

Uso de memória.

Custos.

A intuição continuava importante.

Mas agora caminhava ao lado dos dados.


Enquanto Isso... O Mainframe Apenas Chamava Isso de Rotina

Para um profissional de mainframe, muitos desses conceitos parecem familiares.

Medição?

Sempre existiu.

SMF.

RMF.

Relatórios de desempenho.

Planejamento de capacidade.

Disponibilidade.

Auditoria.

Mudanças controladas.

Recuperação.

Observabilidade.

Muito antes de existirem dashboards coloridos em aplicações web, administradores de sistemas IBM Z já acompanhavam detalhadamente o comportamento de seus ambientes.

Talvez por isso muitos veteranos olhem para DevOps não como uma revolução absoluta.

Mas como uma evolução natural de princípios antigos aplicados a novos ambientes.


O Fracasso Tornou-se Professor

Existe outra mudança cultural extremamente interessante.

Antes da bolha, fracassar era visto como vergonha.

Depois dela...

Começou a surgir uma visão diferente.

Fracassar rapidamente pode ser melhor do que insistir durante anos em uma ideia inviável.

É importante compreender corretamente essa filosofia.

Ela nunca significou:

"Fracasse por qualquer motivo."

Significava:

"Aprenda rapidamente quando algo não funciona."

Essa diferença é enorme.


A Engenharia Voltou a Liderar

Após anos de excesso de marketing, o mercado voltou a valorizar profundamente engenheiros.

Arquitetos.

Especialistas em banco de dados.

Profissionais de infraestrutura.

Especialistas em segurança.

SREs.

DBAs.

Administradores de sistemas.

Todos passaram a ocupar posição estratégica.

As empresas perceberam algo fundamental.

Não basta convencer investidores.

É preciso construir sistemas capazes de sobreviver.


O Paralelo com a Inteligência Artificial

Estamos vivendo novamente um momento de enorme experimentação.

Modelos surgem diariamente.

Frameworks aparecem toda semana.

Ferramentas mudam rapidamente.

Nesse cenário, conceitos como MVP, Agile e Lean tornam-se ainda mais importantes.

Não faz sentido investir milhões em uma solução de IA sem validar primeiro se ela realmente resolve o problema do cliente.

A velocidade continua importante.

Mas o aprendizado tornou-se ainda mais importante.


A Evolução Nunca Para

Curiosamente, muitas ideias consideradas revolucionárias hoje provavelmente parecerão comuns daqui a vinte anos.

Assim como Agile evoluiu.

Assim como DevOps evoluiu.

Assim como Cloud evoluiu.

Também veremos novas formas de desenvolver software impulsionadas pela Inteligência Artificial.

Entretanto...

Os princípios continuarão praticamente os mesmos.

Aprender.

Adaptar.

Melhorar continuamente.


Lições para o Padawan COBOL

Existe uma sabedoria silenciosa presente nos grandes sistemas corporativos.

Eles raramente são reconstruídos do zero.

Eles evoluem.

Recebem novos módulos.

Novas interfaces.

Novos bancos de dados.

Novas APIs.

Novas integrações.

Essa mentalidade é muito próxima da filosofia Lean.

Melhoria contínua.

Evolução incremental.

Valor entregue constantemente.

No universo da Frota Estelar, os engenheiros da Enterprise não desmontam completamente a nave a cada nova missão. Eles atualizam sensores, substituem componentes, aprimoram motores e instalam novos sistemas, preservando aquilo que já demonstrou ser confiável.

A indústria de software aprendeu exatamente essa lição depois da bolha da Internet.

Não é preciso destruir tudo para inovar.

É preciso construir sobre bases sólidas.

Foi essa mudança de mentalidade que preparou o terreno para a computação em nuvem, os smartphones, os microsserviços, o DevOps moderno e, décadas mais tarde, a Inteligência Artificial.

No próximo capítulo veremos como todas essas transformações acabaram aproximando dois mundos que durante muito tempo pareciam opostos: o universo das startups e o universo do mainframe. Descobriremos que, apesar das diferenças aparentes, ambos passaram a compartilhar exatamente os mesmos objetivos: escalabilidade, disponibilidade, segurança, automação e evolução contínua.


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