Translate

domingo, 16 de agosto de 2020

43 anos sem o rei do Rock. Tributo a Elvis Presley

Incrível Elvis Presley em uma noite bem diferentona na Casa de Portugal




Dia 16 de Agosto o mundo perdia o Rei do Rock, deixava esse mundo terreno, para ir além e surgir no imaginário popular aparecendo em diversos lugares para a loucura dos fans.



Imagine a cena bizarra, mas bem divertida.
Estamos na tradicional festa junina da Casa de Portugal de Campinas, famosa por promover e manter a cultura lusitana junto a família de imigrantes que para cá vieram.
Normalmente promovem animados jantares com atrações ligadas a cultura portugueses, regados ao bom vinho lusitano, bacalhau e sardinha grelhada.
É isso aí galera, a noite foi muito animada com clássicos do rei do Rock, espero que gostem, deixem seu joinha e se inscreva em nosso canal.

Mas para surpresa de todos, a atração musical foi rock in roll com uma banda bem animada e shows especiais de covers da Rita Lee e Elvis Presley.

sábado, 15 de agosto de 2020

O Holocron do Chaos Monkey – Como o Macaco Escolhe suas Vítimas, o Conceito de Blast Radius e as Técnicas Secretas dos Engenheiros da Netflix - Parte II

 

Bellacosa Mainframe e o chaos monkey parte II

☕ Um Café no Bellacosa Mainframe

O Holocron do Chaos Monkey – Parte II

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

"A diferença entre um sistema resiliente e um sistema frágil é que o resiliente já sobreviveu ao desastre em laboratório."


O Café Esfria e o Macaco Aprende Novos Truques

O relógio marcava 01h17.

O Padawan COBOL ainda estava intrigado.

Na noite anterior, havia descoberto que a Netflix possuía um pequeno macaco virtual cuja diversão favorita era assassinar servidores em plena luz do dia.

Algo que parecia absurdo.

Algo que, para um operador acostumado a passar horas analisando mensagens DFHxxxx, DSNxxxx, IEAxxxx e $HASPxxxx, soava quase criminoso.

Ele olhou para o velho Sysprog do Bellacosa Mainframe.

— Mestre...

— Sim?

— O Chaos Monkey simplesmente escolhe qualquer servidor e aperta o botão vermelho?

O velho tomou um gole de café.

Sorriu.

E respondeu.

— Se fosse apenas isso, meu jovem Padawan, chamaríamos de estagiário em produção.

O Chaos Monkey é muito mais sofisticado.

Ele trabalha com hipóteses.

Métricas.

Estatística.

Probabilidade.

E principalmente com um conceito extremamente importante.

Blast Radius.


O Conceito de Blast Radius

Talvez a maior contribuição filosófica do Chaos Engineering seja uma pergunta simples.

Quanto estrago eu posso causar antes de me tornar um problema para a empresa?

Esse conceito recebeu o nome de:

Blast Radius

Em português poderíamos traduzir como:

Raio de Explosão

Ou

Zona de impacto controlado


Imagine uma granada.

A explosão possui um alcance limitado.

Pessoas próximas são afetadas.

Pessoas distantes permanecem seguras.

Chaos Engineering funciona da mesma forma.

Não se derruba tudo.

Derruba-se apenas uma pequena parte.

E observa-se.


Exemplo Netflix

Serviços existentes:

Catalog Service

Authentication Service

Billing Service

Streaming Service

Recommendation Engine

CDN Controller

Número total de instâncias:

300

Chaos Monkey escolhe:

2 instâncias.

Blast Radius.

0,66%

Impacto esperado:

Nenhum cliente deve perceber.


Exemplo IBM Z

Ambiente.


LPAR PROD1

LPAR PROD2

LPAR PROD3

CICSA

CICSB

CICSC

Db2A

Db2B

MQA

MQB


Experimento.

Parar CICSB.

Blast Radius.

16%

Objetivo.

Nenhum terminal 3270 deve perder sessão.

Nenhuma transação deve falhar.

Nenhum SLA deve ser violado.


Quanto Menor o Blast Radius, Melhor

Essa é uma das regras mais importantes.

Nunca comece destruindo metade do ambiente.

Comece pequeno.

Muito pequeno.

Ridiculamente pequeno.

Primeiro.

Mate uma instância.

Depois.

Mate duas.

Depois.

Uma AZ.

Depois.

Uma região.

Depois.

Teste desastre.


No mundo IBM Z.

Primeiro.

Pare uma região AOR.

Depois.

Um TOR.

Depois.

Um MQ Manager.

Depois.

Um membro Db2.

Depois.

Uma LPAR.

Somente depois.

Teste GDPS.


O Conceito de Steady State

Na Parte I falamos rapidamente sobre isso.

Agora vamos aprofundar.

Chaos Engineering não começa derrubando servidores.

Começa respondendo.

O que é comportamento normal?


Exemplo.

Sistema bancário.

TPS

8000

CPU

42%

Latência

120 ms

Erros

0,002%


Esse é o estado estável.

Steady State.


Hipótese.

Posso perder um servidor.

Mantendo.

TPS acima de 7800.

Latência abaixo de 150 ms.

Erro abaixo de 0,01%.


Agora sim.

Executamos o caos.


Como o Chaos Monkey Escolhe suas Vítimas

Muita gente imagina.

Servidor.

Sorteio.

Desliga.

Fim.

Não.

Existem estratégias.


Estratégia 1

Seleção aleatória pura

Número aleatório.

Escolha.

Encerrar.


Vantagem.

Simples.


Desvantagem.

Pode escolher servidores pouco importantes.


Estratégia 2

Weighted Random

Peso.

Criticidade.

Histórico.

Capacidade.


Exemplo.

API01

peso 30

API02

peso 10

API03

peso 60


Maior chance.

API03.


Estratégia 3

Tag Based

AWS Tags.

Kubernetes Labels.


Production

Homolog

ChaosEnabled


Exemplo.

ChaosEnabled=true

Apenas esses.

Serão vítimas.


Estratégia 4

Janela Programada

09h às 11h

Terça-feira

Equipe presente

Observabilidade ativa


Muito usada.

Na Netflix.

Google.

Spotify.


O Segredo dos SREs

Os Site Reliability Engineers possuem um mantra.

Não faça experimentos quando ninguém puder observar.

Parece óbvio.

Mas muitas empresas ignoram.


É necessário.

Logs.

Dashboards.

Tracing.

Alertas.

Equipe disponível.

Rollback.

Runbook.


Sem isso.

Chaos vira apenas.

Caos.


O Conceito de Observabilidade

Chaos Engineering depende totalmente dela.


Logs


Métricas


Tracing


Eventos


Alertas


No IBM Z.

RMF.

SMF.

OMEGAMON.

NetView.

SA z/OS.

CICS Monitoring.

Db2 Monitor.

MQ Statistics.

SDSF.

JES2.

WLM.


Exemplo Completo — Banco Digital

Arquitetura.


Load Balancer

6 APIs

Kafka

Redis

Postgres

IAM

PIX

Open Finance


Estado.

12000 TPS

85ms

Erro 0,001%


Hipótese.

Perder API04.


Chaos.

Kill.

API04.


Resultado.

Latência.

91ms.

TPS.

Erro.

0,003%


Hipótese validada.


Novo teste.

Perder Redis.


Resultado.

Latência.

650 ms.


Fila cresce.


Clientes reclamam.


Descoberta.

Redis era SPOF.


Problema corrigido.


Single Point of Failure

Talvez o maior inimigo.

SPOF.


IBM Z nasceu combatendo isso.


Redundância.


Coupling Facility.


Parallel Sysplex.


FICON redundante.


Db2 Sharing.


MQ QSG.


GDPS.


WLM.


RACF Database Sharing.


ODS.


XCF.


Sysplex Timer.


STP.


Chaos Engineering apenas tornou explícita uma filosofia que ambientes críticos praticam há décadas.


Ferramentas Modernas

Gremlin

Plataforma comercial.

CPU.

Memória.

Rede.

Disco.

DNS.

Processos.


LitmusChaos

Kubernetes.


CRDs.

Experimentos.

GitOps.


Chaos Mesh

Cloud Native.


Latência.

IO.

Kernel.


AWS FIS

Fault Injection Simulator.


Instâncias.

EBS.

Rede.


PowerfulSeal

Clusters Kubernetes.


Chaos Toolkit

Python.

Open Source.


Truques Utilizados por Equipes Experientes

Truque 1

Sempre começar em homologação.


Truque 2

Executar experimentos repetidamente.


Truque 3

Automatizar.


CI/CD.


GitOps.


Ansible.


Terraform.


Truque 4

Documentar tudo.


Hipótese.

Resultado.

Aprendizado.

Correção.


Truque 5

Criar um catálogo.

Chaos Experiments.

Versão.

Data.

Owner.


Um Sysprog Descobre o Chaos Monkey

O Padawan olhou para o mestre.

— Então...

— Sim.

— Chaos Engineering é ensinar o sistema a sofrer.

— Exatamente.

— Até ele parar de sentir dor.

— Não.

O velho sorriu.

— Até ele continuar funcionando mesmo sentindo.

Porque a disponibilidade perfeita não existe.

Hardware quebra.

Fibra rompe.

Discos falham.

Firmware possui bugs.

Aplicações vazam memória.

Operadores cometem erros.

Pessoas esquecem procedimentos.

O objetivo nunca foi impedir falhas.

O objetivo sempre foi algo muito mais ambicioso.

Fazer com que as falhas se tornem acontecimentos comuns, previsíveis e entediantes.

E foi nesse momento que o Padawan percebeu algo curioso.

Talvez o Chaos Monkey nunca tivesse sido realmente uma invenção revolucionária.

Talvez fosse apenas uma nova linguagem para explicar uma velha sabedoria dos Sysprogs do IBM Z:

Não espere o desastre ensinar sua arquitetura. Ensine sua arquitetura a sobreviver ao desastre antes que ele aconteça.


Continua na Parte III

No próximo capítulo do Holocron do Chaos Monkey, entraremos definitivamente no território do IBM Z:

  • Existe um Chaos Monkey para z/OS?

  • Como testar falhas em CICSplex, Db2 Data Sharing e MQ QSG.

  • O papel do WLM, Sysplex, XCF e GDPS.

  • Como construir experimentos de caos seguros para Sysprogs.

  • Técnicas usando SA z/OS, NetView, z/OSMF e Ansible Automation Platform.

  • Laboratórios Bellacosa Mainframe com exemplos práticos para Padawans e Sysprogs Seniores.

domingo, 9 de agosto de 2020

⚔️ Bellacosa Otaku Blog — Parte 20: Expressões de Batalha, Luta e Ação nos Animes ⚔️

 


⚔️ Bellacosa Otaku Blog — Parte 20: Expressões de Batalha, Luta e Ação nos Animes ⚔️


💥 O idioma da força, combate e heroísmo nos animes

(Versão Bellacosa: gritos de poder, golpes espetaculares e energia vibrante que atravessa a tela.)

Nos animes shounen, mecha e de artes marciais, o japonês se transforma em explosão de adrenalina.
Cada palavra, grito ou exclamação carrega energia, desafio e emoção, tornando cada luta memorável.
Vamos explorar as mais icônicas! 🥋


⚡ 1. 必殺技 (hissatsu waza)

Tradução: “Golpe mortal / técnica especial.”
👉 Nome do ataque especial de um personagem, geralmente acompanhado de pose dramática.

📺 Anime vibe: Dragon Ball, Naruto, One Piece.
💬 Exemplo: “Hissatsu Waza — Kamehameha!” 🌊


🗡️ 2. 攻撃! (kougeki!)

Tradução: “Ataque!”
👉 Ordem ou comando para iniciar ofensiva contra o inimigo.

📺 Anime vibe: Naruto, Bleach, My Hero Academia.
💬 Exemplo: “Kougeki! Não deixe ele escapar!” ⚡


🛡️ 3. 防御! (bougyo!)

Tradução: “Defesa!”
👉 Ordem para proteger-se ou criar barreira contra ataques inimigos.

📺 Anime vibe: Naruto, Bleach, Dragon Ball.
💬 Exemplo: “Bougyo! Bloqueie o golpe agora!” 🛡️


💪 4. 力 (chikara)

Tradução: “Força / poder.”
👉 Palavra essencial para gritar energia interior ou concentração máxima.

📺 Anime vibe: Dragon Ball, One Punch Man, Boku no Hero Academia.
💬 Exemplo: “Chikara! Eu não vou desistir!” ⚡


🔥 5. 技 (waza)

Tradução: “Técnica / habilidade.”
👉 Indica um movimento específico, golpe ou estratégia de luta.

📺 Anime vibe: Naruto, Bleach, One Piece.
💬 Exemplo: “Waza secreta ativada — Rasen Shuriken!” 🌀


😱 6. 危ない! (abunai!)

Tradução: “Perigo! / Cuidado!”
👉 Grito usado durante momentos críticos ou ataques inesperados.

📺 Anime vibe: Dragon Ball, Naruto, Bleach.
💬 Exemplo: “Abunai! Desvie agora!” ⚡


🏆 7. 勝利! (shouri!)

Tradução: “Vitória!”
👉 Exclamação clássica ao derrotar o adversário ou vencer uma batalha.

📺 Anime vibe: Dragon Ball, One Piece, Naruto.
💬 Exemplo: “Shouri! Conseguimos vencer a luta!” 🏅


💨 8. 必死! (hisshi!)

Tradução: “Com toda força / até o último esforço.”
👉 Expressa empenho total, coragem extrema e determinação.

📺 Anime vibe: Dragon Ball, Boku no Hero Academia.
💬 Exemplo: “Hisshi! Eu não vou perder para você!” 💥


🌪️ 9. 超 (chou)

Tradução: “Super / ultra.”
👉 Prefixo usado para indicar forma mais poderosa ou ataque elevado.

📺 Anime vibe: Dragon Ball, Naruto, One Piece.
💬 Exemplo: “Chou Saiyan — nível máximo ativado!” ⚡


💥 10. 闘志 (toushi)

Tradução: “Espírito de luta / determinação.”
👉 Palavra que representa coragem, resiliência e vontade de vencer.

📺 Anime vibe: Naruto, Dragon Ball, Bleach.
💬 Exemplo: “Toushi! Não vou recuar nem por um segundo!” 🥋


🏮 Curiosidades Bellacosa:

  • Gritos de ataque (kougeki!, bougyo!) e nomes de técnicas (hissatsu waza, waza) aumentam a tensão e dramatizam cada combate.

  • Expressões de energia e esforço (chikara, hisshi!, toushi) são onipresentes em shounen e refletem persistência e espírito de superação.

  • Exclamações de perigo (abunai!) e vitória (shouri!) tornam as cenas mais imersivas e emocionantes. ⚔️


🌟 Dica Bellacosa:

  • Observe a entonação e intensidade: mesmo uma palavra curta pode transmitir poder extremo.

  • Repare nos efeitos visuais e postura do personagem junto com a fala — aumenta a dramaticidade da batalha.

  • Memorizar essas expressões ajuda a captar tensão, estratégia e emoção de qualquer luta de anime. 💥


🌸 Conclusão Bellacosa:

As expressões de batalha e ação nos animes transmitem força, coragem e emoção máxima.
Cada palavra, grito e comando é uma fagulha de adrenalina, fazendo o espectador sentir-se dentro do combate.
No universo shounen e de artes marciais, o japonês se torna a linguagem do heroísmo e da energia pura. ⚡

“Kougeki! Chikara! Toushi! Hisshi! Shouri é nossa!” 💥🥋

segunda-feira, 3 de agosto de 2020

1️⃣ Diferença visual pode existir mesmo sem mudar o estúdio

 

Bellacosa Mainframe e as assinaturas visuais de studios de anime estilo marca registrada

1️⃣ Diferença visual pode existir mesmo sem mudar o estúdio

Sim, mesmo dentro de um mesmo estúdio, animes diferentes podem ter estilos visuais bem distintos. Isso depende de vários fatores:

  • Diretor de animação / character designer: Cada artista tem um traço próprio, proporções de personagens, expressões faciais e estilo de olhos diferentes.

  • Orçamento do projeto: Mais verba significa mais frames, mais detalhes, fundos mais ricos e cores melhores.

  • Temática e público-alvo: Um shoujo vai ter traços mais delicados, olhos maiores, cores suaves; um shounen de ação terá linhas mais marcantes, cores fortes e dinamismo.

2️⃣ Diferença por estúdio

Cada estúdio tem uma “marca registrada”:

  • Kyoto Animation: Detalhes ricos, animação suave, expressões muito naturais.

  • Madhouse: Estilos variáveis, mas muita atenção à coreografia de ação e composições de cena.

  • Trigger: Traços exagerados, movimento estilizado, cores vibrantes.

Então, se você trocar de estúdio, a diferença tende a ser mais perceptível, mas não é regra absoluta. Um diretor pode mudar o visual drasticamente mesmo no mesmo estúdio.

3️⃣ Diferença percebida pelo público

Visualmente, a gente percebe mais:

  • Expressões faciais e olhos

  • Movimento e fluidez

  • Detalhes de fundo

  • Paleta de cores e iluminação

Se você olhar rápido, às vezes nem percebe se é mudança de estúdio ou só de estilo/tema. Mas se olhar frame a frame, diferenças de “assinatura” artística saltam aos olhos.

💡 Resumo: A diferença pode ser tanto por estúdio quanto por escolha artística do projeto, orçamento e equipe. O estúdio define um “tom”, mas o diretor e o character designer podem mudar completamente o jeito que o anime parece e se sente.

domingo, 2 de agosto de 2020

🪄 Bellacosa Otaku Blog — Parte 19: Expressões Sobrenaturais e de Magia nos Animes 🪄

 


🪄 Bellacosa Otaku Blog — Parte 19: Expressões Sobrenaturais e de Magia nos Animes 🪄


O idioma do misterioso, mágico e sobrenatural nos animes

(Versão Bellacosa: varinhas, feitiços e mundos além da imaginação.)

Nos animes de fantasia, shoujo mágico e sobrenatural, o japonês ganha tons místicos e encantadores.
Cada expressão e palavra pode ser um feitiço, uma maldição ou um ritual, transportando o espectador para outro mundo.
Vamos explorar as mais icônicas! 🔮


🔥 1. 魔法 (mahou)

Tradução: “Magia / feitiço.”
👉 Palavra central em qualquer anime de magia, referindo-se ao poder sobrenatural ou habilidades especiais.

📺 Anime vibe: Cardcaptor Sakura, Little Witch Academia.
💬 Exemplo: “Mahou! Hora de lançar o feitiço!” ✨


🪄 2. 呪文 (jumon)

Tradução: “Encantamento / feitiço.”
👉 Palavra usada para descrever a recitação de feitiços ou fórmulas mágicas.

📺 Anime vibe: Mahou Shoujo Madoka Magica, Little Witch Academia.
💬 Exemplo: “Jumon! Transformação completa!” 🪄


🌌 3. 精霊 (seirei)

Tradução: “Espírito / entidade mágica.”
👉 Representa seres sobrenaturais ou guardiões, muito comuns em aventuras fantásticas.

📺 Anime vibe: Fruits Basket, Natsume Yuujinchou.
💬 Exemplo: “Seirei apareceu diante de mim!” 👻


⚡ 4. 闇 (yami)

Tradução: “Escuridão / trevas.”
👉 Palavra que indica energia sombria ou poderes malignos.

📺 Anime vibe: Bleach, Noragami.
💬 Exemplo: “Yami se aproxima… cuidado!” 🌑


🔮 5. 呪い (noroi)

Tradução: “Maldição.”
👉 Termo usado para feitiços negativos ou situações amaldiçoadas.

📺 Anime vibe: Jigoku Shoujo, Noroi: The Curse.
💬 Exemplo: “Noroi será quebrado apenas pelo ritual sagrado.” 🕯️


✨ 6. 変身 (henshin)

Tradução: “Transformação.”
👉 Expressão clássica de magias de transformação, presente em animes de garotas mágicas e heróis.

📺 Anime vibe: Sailor Moon, Pretty Cure.
💬 Exemplo: “Henshin! Poderes ativados!” 🌟


🔥 7. 精神力 (seishinryoku)

Tradução: “Força espiritual / poder de vontade.”
👉 Representa energia interior que sustenta feitiços ou habilidades sobrenaturais.

📺 Anime vibe: Yu Yu Hakusho, Bleach.
💬 Exemplo: “Seishinryoku é a chave para derrotar o inimigo!” ⚡


🧙 8. 魔術 (majutsu)

Tradução: “Arte mágica / magia ritual.”
👉 Termo para técnicas e rituais complexos de magia.

📺 Anime vibe: Fate/stay night, Mahou Shoujo Madoka Magica.
💬 Exemplo: “Majutsu avançado ativado!” 🪄


🌬️ 9. 幻覚 (genkaku)

Tradução: “Alucinação / ilusão.”
👉 Usada para enganar, confundir ou criar efeitos sobrenaturais visuais.

📺 Anime vibe: Naruto, Monogatari Series.
💬 Exemplo: “Genkaku! Ele não pode ver a realidade!” 🌫️


🕯️ 10. 神秘 (shinpi)

Tradução: “Mistério / místico.”
👉 Palavra que envolve a ideia de algo desconhecido e sobrenatural.

📺 Anime vibe: Mushishi, Natsume Yuujinchou.
💬 Exemplo: “Shinpi envolve esta floresta há séculos…” 🌌


🏮 Curiosidades Bellacosa:

  • Termos como mahou, henshin e jumon são frequentemente acompanhados de gestos, palavras longas e efeitos visuais, tornando a magia mais teatral.

  • Expressões de poder espiritual (seishinryoku) e trevas (yami) são comuns em batalhas sobrenaturais.

  • Palavras de mistério e maldição (noroi, shinpi) criam atmosfera de suspense e fantasia. 🔮


🌟 Dica Bellacosa:

  • Observe a entonação e pausa: feitiços longos ou curtos mudam a sensação de poder e mistério.

  • Aprender essas palavras ajuda a entender rituais, magias e lógicas sobrenaturais japonesas.

  • Onomatopeias e expressões visuais reforçam emoção, suspense e espetáculo mágico. ✨


🌸 Conclusão Bellacosa:

As expressões de magia e sobrenatural nos animes transformam o japonês em uma linguagem de poder, mistério e encantamento.
Cada palavra é um feitiço que ativa emoção, tensão ou fascínio, transportando o espectador para mundos além da imaginação.

“Mahou! Henshin! Shinpi nos guia… prepare-se para o desconhecido!” 🪄✨

sexta-feira, 31 de julho de 2020

DotCom : Capítulo VII — Os Sobreviventes da Seleção Natural Digital: Por Que Amazon, Google e eBay Venceram Quando Quase Todos Perderam

 

Bellacosa Mainframe e o estouro da bolha dotcom capitulo vii

Capítulo VII — Os Sobreviventes da Seleção Natural Digital: Por Que Amazon, Google e eBay Venceram Quando Quase Todos Perderam

Como algumas empresas transformaram a maior crise da Internet em uma oportunidade para construir impérios tecnológicos que mudariam o século XXI

"Uma tempestade não cria um grande navegador. Ela apenas revela quem realmente sabe navegar."

Quando estudamos a bolha da Internet, existe uma tendência natural de focarmos apenas nas empresas que desapareceram.

Pets.com.

Webvan.

Boo.com.

eToys.

Excite.

GeoCities.

Broadcast.com.

Centenas de outras.

É uma lista enorme.

Mas existe uma pergunta muito mais interessante.

Por que algumas empresas sobreviveram?

Afinal...

Todas faziam parte da mesma Internet.

Todas enfrentaram o mesmo colapso.

Todas perderam investidores.

Todas sofreram com a queda do NASDAQ.

O que havia de diferente?

Será que tiveram sorte?

Ou existia algo mais profundo?

A resposta é uma das maiores lições de gestão, tecnologia e engenharia da história moderna.


A Natureza Também Funciona Assim

Charles Darwin jamais estudou empresas de tecnologia.

Mesmo assim, sua teoria da evolução explica muito do que aconteceu entre 2000 e 2003.

Na natureza, sobreviver não significa ser o maior.

Nem o mais forte.

Nem o mais bonito.

Sobrevive quem melhor consegue adaptar-se às mudanças do ambiente.

No mundo corporativo acontece exatamente o mesmo.

Quando o dinheiro era abundante...

Quase todas as empresas pareciam saudáveis.

Quando o dinheiro desapareceu...

Descobriu-se quais realmente possuíam capacidade de adaptação.


Amazon: A Empresa que Quase Morreu

Hoje parece impossível imaginar.

Mas houve um momento em que analistas afirmavam seriamente que a Amazon jamais sobreviveria.

Suas ações perderam aproximadamente 95% do valor após o estouro da bolha.

Jeff Bezos tornou-se alvo de críticas.

Jornais publicavam manchetes questionando:

"A Amazon ainda existirá daqui a alguns anos?"

A empresa acumulava prejuízos.

Investia pesadamente em infraestrutura.

Construía centros de distribuição enormes.

Comprava servidores.

Desenvolvia software.

Naquele momento, muitos acreditavam que tudo aquilo era desperdício.

Hoje sabemos que era exatamente o contrário.

Bezos estava construindo a fundação de um império.


Jeff Bezos Não Pensava em Trimestres

Existe uma característica interessante nos fundadores que sobreviveram.

Eles olhavam para décadas.

Não para o próximo trimestre.

Enquanto investidores exigiam resultados imediatos, Bezos repetia constantemente uma filosofia simples.

"Estamos construindo uma empresa para o longo prazo."

Essa visão permitiu decisões extremamente difíceis.

Redução de despesas.

Demissões.

Cancelamento de projetos.

Renegociação de contratos.

O objetivo não era impressionar Wall Street.

Era sobreviver.

Sem sobrevivência...

Não existiria futuro.


Google Chegou na Hora Certa

Outro caso fascinante é o Google.

Ao contrário da maioria das startups da época, o Google nasceu praticamente no momento em que a bolha começava a mostrar sinais de desgaste.

Larry Page e Sergey Brin tinham um problema muito específico para resolver.

Como encontrar informação relevante na Web.

Naquela época já existiam buscadores.

AltaVista.

Lycos.

Excite.

Infoseek.

Yahoo!.

Entretanto...

Os resultados eram frequentemente ruins.

Google resolveu um problema concreto.

Seu algoritmo PageRank organizava resultados de forma muito superior aos concorrentes.

Perceba a diferença.

Eles não criaram uma empresa porque a Internet estava na moda.

Criaram porque existia um problema real.


Resolver Problemas Vale Mais do que Seguir Tendências

Esse talvez seja o maior ensinamento de Google.

Tecnologia é consequência.

Problemas vêm primeiro.

Quando um produto resolve algo importante...

Os clientes permanecem.

Quando ele existe apenas porque está acompanhando uma tendência...

A sobrevivência torna-se muito mais difícil.

Esse princípio continua válido vinte anos depois.

Na era da Inteligência Artificial, a pergunta permanece exatamente a mesma.

Que problema estamos resolvendo?


eBay Descobriu o Poder da Comunidade

Enquanto muitas startups gastavam fortunas em publicidade, o eBay crescia principalmente através dos próprios usuários.

Compradores atraíam vendedores.

Vendedores atraíam compradores.

Esse fenômeno recebe hoje o nome de efeito de rede.

Quanto maior a comunidade...

Maior o valor da plataforma.

Esse crescimento orgânico reduziu drasticamente a necessidade de investimentos gigantescos em marketing.

Era um modelo muito mais sustentável.


PayPal Sobreviveu Porque Existia um Problema Real

Comprar pela Internet no final dos anos 1990 não era simples.

Cartões de crédito ainda geravam desconfiança.

Fraudes eram frequentes.

Pagamentos internacionais eram complicados.

PayPal apareceu justamente para resolver esse problema.

A empresa enfrentou enormes dificuldades.

Mudou diversas vezes de estratégia.

Lutou contra fraudes diariamente.

Mesmo assim...

Persistiu.

Porque seu serviço atendia uma necessidade concreta do mercado.

Não era uma solução procurando um problema.

Era exatamente o contrário.


Salesforce Mudou o Modelo de Negócio

Outro sobrevivente importante foi a Salesforce.

Marc Benioff defendia uma ideia considerada quase absurda na época.

Software não precisava mais ser instalado.

Poderia funcionar diretamente pela Internet.

Hoje chamamos isso de SaaS.

Software as a Service.

Naquele período parecia uma heresia.

Empresas estavam acostumadas a comprar CDs, instalar programas e manter servidores próprios.

Salesforce mostrou que era possível fazer diferente.

Não venceu porque possuía o software mais bonito.

Venceu porque criou um modelo econômico melhor.


O Que Todas Tinham em Comum?

Quando analisamos essas empresas percebemos padrões bastante claros.

Elas possuíam objetivos diferentes.

Mercados diferentes.

Produtos diferentes.

Mas compartilhavam características fundamentais.

Primeiro.

Resolvendo problemas reais.

Segundo.

Pensando no longo prazo.

Terceiro.

Investindo fortemente em engenharia.

Quarto.

Aceitando adaptar modelos de negócio sempre que necessário.

Quinto.

Controlando cuidadosamente recursos durante a crise.

Nenhuma delas ignorou a realidade financeira.


Enquanto Isso... Milhares Desapareciam

No mesmo período, centenas de startups continuavam apostando que novos investidores resolveriam seus problemas.

Não reduziram custos.

Não mudaram estratégias.

Não adaptaram produtos.

Esperaram que o mercado voltasse ao normal.

Ele nunca voltou.

A crise mostrou uma diferença importante entre esperança e planejamento.

Esperança é importante.

Mas não substitui estratégia.


A Engenharia Tornou-se Diferencial Competitivo

Existe outra característica curiosa.

As empresas sobreviventes investiram pesadamente em infraestrutura.

Google construiu data centers gigantescos.

Amazon desenvolveu plataformas logísticas extremamente sofisticadas.

PayPal criou mecanismos antifraude avançados.

eBay investiu em escalabilidade.

Nenhuma delas acreditava que apenas marketing seria suficiente.

Todas compreenderam que crescimento exige engenharia.

Essa continua sendo uma das maiores diferenças entre demonstrações impressionantes e produtos duradouros.


O Mainframe Sempre Conheceu Esse Princípio

Para um profissional COBOL, essa conclusão parece quase óbvia.

Durante décadas, sistemas bancários sempre foram projetados pensando em:

  • crescimento;

  • disponibilidade;

  • redundância;

  • recuperação;

  • desempenho;

  • segurança.

Ninguém constrói um sistema de pagamentos imaginando apenas a demonstração para um cliente.

Ele precisa continuar funcionando durante anos.

É exatamente essa mentalidade que começou a reaparecer na indústria de software após a bolha.

As empresas voltaram a valorizar arquitetura.

Não apenas velocidade.


A Crise Eliminou Concorrentes

Existe uma consequência pouco comentada sobre grandes crises.

Elas reduzem drasticamente a concorrência.

Quando centenas de startups desapareceram, empresas sobreviventes passaram a disputar um mercado muito menos congestionado.

Amazon encontrou menos competidores.

Google tornou-se rapidamente referência em buscas.

eBay consolidou sua liderança.

Salesforce expandiu-se praticamente sozinha no mercado de CRM em nuvem.

Paradoxalmente...

A crise abriu espaço para gigantes crescerem ainda mais.


A Internet Ficou Mais Forte

Pode parecer contraditório.

Mas a bolha fortaleceu a própria Internet.

Como?

Eliminando modelos insustentáveis.

Concentrando investimentos em empresas mais eficientes.

Incentivando engenharia de melhor qualidade.

Criando consumidores mais confiantes.

Melhorando infraestrutura.

Fortalecendo meios de pagamento.

Quando a década seguinte começou...

A Internet estava muito mais preparada para crescer.

A crise havia funcionado como uma gigantesca poda.

As raízes permaneceram.

Os galhos fracos desapareceram.


O Paralelo com a Inteligência Artificial

Estamos vivendo algo semelhante atualmente.

Existem milhares de startups de IA.

Nem todas sobreviverão.

Isso não significa que a Inteligência Artificial fracassará.

Muito provavelmente ocorrerá o oposto.

Assim como aconteceu após as Dot-Com, algumas poucas empresas construirão infraestrutura sólida, resolverão problemas relevantes e permanecerão durante décadas.

Outras desaparecerão.

A tecnologia continuará evoluindo.

A história mostra que inovação costuma sobreviver às bolhas.

O que normalmente não sobrevive são os modelos econômicos mal planejados.


Lições para o Padawan COBOL

Existe uma razão pela qual programas COBOL escritos há quarenta anos continuam executando milhões de transações diariamente.

Eles foram desenvolvidos para resolver problemas concretos.

Não para impressionar investidores.

Essa talvez seja a maior diferença entre sistemas críticos e muitos produtos criados durante períodos de euforia.

Um sistema duradouro nasce da combinação entre boa engenharia, visão de longo prazo e disciplina operacional.

Empresas também.

No universo da Frota Estelar, durante uma batalha, as naves mais vistosas nem sempre sobrevivem. Muitas possuem armamentos impressionantes, mas pouca resistência estrutural. Já as naves projetadas por engenheiros cuidadosos suportam impactos, adaptam-se aos danos, redistribuem energia e continuam cumprindo sua missão.

Foi exatamente isso que aconteceu após a bolha da Internet.

As empresas que sobreviveram não eram necessariamente as mais rápidas.

Eram as mais resilientes.

No próximo capítulo conheceremos uma das maiores ironias dessa história: como justamente o colapso das Dot-Com abriu caminho para a Web 2.0, as redes sociais, os smartphones e praticamente toda a economia digital que conhecemos hoje. Às vezes, destruir o excesso é exatamente o que permite o verdadeiro crescimento.


YAGNI Rules: Quando um Programador COBOL Descobriu que a Matrix Estava Cheia de Recursos Que Ninguém Jamais Usaria

 

Bellacosa Mainframe e a yagni rules

☕ Um Café no Bellacosa Mainframe

YAGNI Rules sem Mistérios

Quando um Programador COBOL Descobriu que a Matrix Estava Cheia de Recursos Que Ninguém Jamais Usaria

"O código mais caro não é aquele que foi escrito. É aquele que foi escrito para um futuro que nunca chegou."


Prólogo — O Depósito das Funcionalidades Fantasma

Após derrotar mais uma legião de Agentes Smith, Neo recebeu um convite inesperado do Arquiteto.

— Hoje vou lhe mostrar um lugar que nem mesmo o Oráculo costuma visitar.

Os dois atravessaram uma enorme porta metálica escondida atrás do núcleo da Matrix.

Do outro lado havia um gigantesco depósito.

Prateleiras infinitas.

Milhões de linhas de código.

Módulos completos.

APIs.

Menus.

Botões.

Rotinas.

Neo perguntou:

— O que é tudo isso?

O Arquiteto respondeu:

— Funcionalidades.

Neo ficou impressionado.

— Quantas pessoas usam?

Silêncio.

Depois de alguns segundos o Arquiteto respondeu:

— Nenhuma.

Neo caminhou entre corredores intermináveis.

Encontrou módulos chamados:

FUTURO-PROJETO.

CLIENTE-PREMIUM-V3.

IA-EXPERIMENTAL.

RELATORIO-UNIVERSAL.

MODULO-MULTIMOEDA.

SISTEMA-DE-TELETRANSPORTE.

Perguntou:

— Isso tudo está em produção?

O Arquiteto respondeu.

— Está.

— Funciona?

— Sim.

— É usado?

— Nunca foi.

O Oráculo apareceu.

Serviu café para Neo.

Depois disse calmamente:

"O maior desperdício da engenharia não é escrever código ruim. É escrever código que jamais resolverá um problema real."

Naquele momento Neo compreendeu o verdadeiro significado do YAGNI.


O que significa YAGNI?

YAGNI significa:

You Aren't Gonna Need It

Em português:

"Você não vai precisar disso."

É um dos princípios mais conhecidos da metodologia Extreme Programming (XP).

Sua ideia é extremamente simples.

Não implemente hoje funcionalidades que talvez sejam necessárias amanhã.

Implemente apenas aquilo que resolve um problema existente.


A origem do princípio

O YAGNI surgiu no final da década de 1990 dentro do movimento Extreme Programming, criado por Kent Beck.

Na época, muitas equipes gastavam enorme quantidade de tempo construindo recursos para um futuro hipotético.

Esses recursos quase nunca eram utilizados.

Kent Beck propôs uma filosofia radical.

Construa somente aquilo que possui necessidade comprovada.

Quando surgir uma nova necessidade.

Implemente naquele momento.


Matrix explica perfeitamente

Imagine que o Arquiteto resolvesse prever todas as possibilidades da humanidade.

Então incluiria:

  • controle de dragões;

  • módulo para dinossauros;

  • protocolo para viagens no tempo;

  • economia marciana;

  • integração com civilizações alienígenas.

Tudo isso "caso um dia seja necessário".

Resultado?

A Matrix seria gigantesca.

Difícil de manter.

Lenta.

Cheia de código inútil.


Como nasce o excesso?

Sempre começa com boas intenções.

Alguém diz.

"Vai que um dia..."

Depois aparecem frases como:

  • "Já vamos deixar preparado."

  • "Aproveita e cria também..."

  • "É só mais um IF."

  • "No futuro pode servir."

Meses depois.

Ninguém usa.


O COBOL conhece isso muito bem

Imagine um sistema bancário.

O requisito diz:

Calcular IOF.

O desenvolvedor pensa.

"Vai que um dia o banco trabalhe com Bitcoin, Ouro, Marte e Lua."

Então cria:

  • vinte tabelas;

  • quinze tipos de moeda;

  • cinquenta parâmetros.

Quando entra em produção.

Existe apenas:

Real.


Um exemplo COBOL

Requisito.

Calcular juros.

Solução simples.

COMPUTE JUROS = SALDO * TAXA

Solução YAGNI ignorado.

Cria:

  • Framework de cálculo.

  • Plugin.

  • Factory.

  • Reflection.

  • Configuração XML.

  • API REST.

  • Tabela dinâmica.

Tudo para multiplicar dois números.


Matrix Reloaded

O Arquiteto mostra milhares de possibilidades futuras.

Neo pergunta.

— Precisamos construir tudo isso?

O Arquiteto responde.

— Não.

O Oráculo sorri.

— O futuro ainda não decidiu existir.


O efeito psicológico

Existe um medo comum entre desenvolvedores.

"E se amanhã precisarmos?"

Essa pergunta gera enormes desperdícios.

Porque o amanhã raramente acontece exatamente como imaginamos.


O Programador COBOL Padawan

Imagine seu primeiro projeto.

O gerente pede:

— Precisamos gerar um relatório.

Você responde.

— Já vou criar vinte modelos diferentes.

Pergunta.

O cliente pediu vinte?

Não.

Pediu um.


O Agente Smith ama funcionalidades imaginárias

Porque cada funcionalidade extra gera:

  • novos bugs;

  • novos testes;

  • nova documentação;

  • novas dependências;

  • novas exceções.

Quanto mais código.

Maior a superfície para ataques.


Um exemplo inspirado na Matrix

Neo pergunta.

— Quantas portas existem?

O Chaveiro responde.

— Mil.

Neo pergunta.

— Quantas usamos?

— Dez.

As outras novecentas e noventa foram criadas "caso um dia fossem necessárias".


O custo invisível

Toda funcionalidade possui custo.

Mesmo sem uso.

Ela precisa:

  • compilar;

  • ser testada;

  • documentada;

  • protegida;

  • revisada;

  • mantida.

Nada é gratuito.


O impacto no Mainframe

Em ambientes IBM Z aparecem frequentemente:

  • COPYBOOKs preparados para campos inexistentes;

  • layouts gigantes;

  • tabelas nunca utilizadas;

  • JCLs reservados para processos imaginários;

  • programas chamados apenas "no futuro".

Tudo isso aumenta:

  • CPU;

  • armazenamento;

  • manutenção.


Curiosidade

Diversos estudos em desenvolvimento de software mostram que uma parcela significativa das funcionalidades presentes em sistemas corporativos é usada muito raramente ou nunca é utilizada pelos usuários finais.

Isso reforça a importância de validar necessidades reais antes de implementar novas capacidades.


Atenção!

YAGNI não significa:

"Nunca pensar no futuro."

Significa:

"Não implementar antes da hora."

Arquitetura pode prever evolução.

Código desnecessário não.


A diferença

Preparar arquitetura

Permitir crescimento.


Implementar tudo

Criar desperdício.


Matrix e Zion

Imagine construir:

  • cem hangares;

  • mil naves;

  • cinquenta hospitais.

Antes mesmo de saber quantas pessoas viverão em Zion.

Seria desperdício.


Ferramentas ajudam

Hoje podemos medir uso real.

  • Telemetria.

  • Analytics.

  • Logs.

  • Feature Flags.

  • IBM Instana.

  • OMEGAMON.

  • Monitoramento de APIs.

Esses dados mostram o que realmente é utilizado.


O papel da IA

A IA frequentemente sugere funcionalidades extras.

Cabe ao engenheiro perguntar.

"O cliente pediu isso?"

Se a resposta for não.

Talvez seja YAGNI.


Os riscos

Ignorar YAGNI gera:

  • overengineering;

  • manutenção cara;

  • código morto;

  • testes maiores;

  • documentação enorme;

  • mais bugs.


Erros clássicos

  • Programar para cenários imaginários.

  • Criar abstrações prematuras.

  • Implementar requisitos inexistentes.

  • Confundir arquitetura extensível com funcionalidades prontas.

  • Aceitar "vai que um dia".


Boas práticas

  • Desenvolver apenas requisitos atuais.

  • Validar com usuários.

  • Medir utilização.

  • Evoluir incrementalmente.

  • Refatorar quando necessário.

  • Simplificar continuamente.


Aplicabilidade

YAGNI aparece em:

  • COBOL.

  • Java.

  • Python.

  • Cloud.

  • APIs.

  • Microsserviços.

  • Mobile.

  • IA.

  • DevOps.

  • ERP.


Um exemplo COBOL

Cliente pede.

Cadastro de Endereço.

Você cria.

  • Rua.

  • Número.

  • Cidade.

  • Estado.

  • CEP.

Não precisa adicionar:

  • Colônia em Marte.

  • Quadrante Galáctico.

  • Planeta de Origem.

  • Coordenadas Quânticas.

Até que alguém realmente peça.


YAGNI e os outros princípios

YAGNI conversa diretamente com quase todos os princípios estudados nesta série.

Ele reduz:

  • Golden Hammer, porque evita criar soluções grandiosas para problemas pequenos.

  • Lasagna Code, porque impede camadas desnecessárias.

  • Lava Flow, porque evita código que nunca será usado e depois ninguém tem coragem de remover.

  • Boiling Frog, porque impede o crescimento silencioso da complexidade.

  • KISS, porque incentiva soluções simples.

  • Death March, porque reduz trabalho desnecessário.

  • Brooks's Law, porque menos funcionalidades significam menos necessidade de crescimento artificial da equipe.

YAGNI é um excelente antídoto contra o excesso de zelo que acaba produzindo desperdício.


O ensinamento do Oráculo

O Oráculo entrega uma mochila para Neo.

Dentro dela existem:

  • vinte lanternas;

  • quinze bússolas;

  • dez rádios;

  • cinco espadas;

  • três computadores;

  • duas cafeteiras.

Neo tenta levantá-la.

Não consegue.

Ela retira tudo.

Deixa apenas:

uma bússola.

água.

e uma lanterna.

Neo sorri.

— Agora consigo caminhar.

Ela responde.

"Quem leva tudo para uma jornada acaba sem forças para percorrê-la."


Lições para um Programador COBOL Padawan

Ao longo da carreira você ouvirá muitas sugestões começando com:

  • "Já aproveita..."

  • "Vai que..."

  • "Quem sabe no futuro..."

  • "Deixa preparado..."

Antes de aceitar, faça algumas perguntas:

  • Existe um requisito aprovado?

  • Há uma necessidade real?

  • Algum usuário pediu isso?

  • Existe previsão concreta de uso?

  • Estamos aumentando a complexidade sem necessidade?

Se a resposta for "não", provavelmente você está diante de um caso clássico de YAGNI.

Projetar sistemas preparados para evoluir é excelente.

Implementar funcionalidades imaginárias é desperdício.


Curiosidades

O princípio YAGNI influenciou fortemente várias práticas modernas:

  • Agile, priorizando valor entregue a cada iteração.

  • Lean Software Development, eliminando desperdícios.

  • Feature Flags, permitindo ativar funcionalidades apenas quando realmente necessárias.

  • MVP (Minimum Viable Product), que incentiva lançar a menor solução capaz de gerar valor.

  • Continuous Delivery, favorecendo evolução contínua em vez de grandes antecipações.

Todos compartilham a mesma ideia: desenvolva apenas aquilo que gera valor agora.


Conclusão — O Futuro Ainda Não Escreveu Seu Código

Quando Neo percorreu o depósito do Arquiteto, percebeu que milhares de módulos existiam apenas para responder a perguntas que ninguém jamais faria.

Na Engenharia de Software isso acontece com frequência.

O princípio YAGNI nos lembra que o futuro é imprevisível. As funcionalidades imaginadas hoje dificilmente corresponderão exatamente às necessidades reais de amanhã.

Para um Programador COBOL, especialmente em ambientes IBM Z onde estabilidade, desempenho e facilidade de manutenção são essenciais, escrever menos código costuma ser uma decisão mais inteligente do que escrever código "por precaução".

Cada linha adicionada representa mais testes, mais documentação, mais manutenção e mais oportunidades para o Agente Smith encontrar uma brecha.

No universo Bellacosa Mainframe existe uma máxima que certamente estaria gravada na oficina do Chaveiro:

"Não construa hoje a chave de uma porta que talvez nunca exista. Quando essa porta aparecer, você terá conhecimento, ferramentas e experiência para fabricar exatamente a chave de que ela precisa."

Porque o verdadeiro engenheiro não é aquele que tenta prever todos os futuros possíveis.

É aquele que constrói sistemas simples, elegantes e preparados para evoluir quando o futuro finalmente bater à porta.

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