☕ 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

domingo, 11 de outubro de 2020

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

 


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


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

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

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


💪 1. 頑張れ (ganbare)

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

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


🏆 2. 勝利 (shouri)

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

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


⚡ 3. 全力 (zenryoku)

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

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


🏐 4. チーム (chīmu)

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

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


🥵 5. 練習 (renshū)

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

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


🏃 6. 努力 (doryoku)

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

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


⚡ 7. ライバル (raibaru)

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

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


🔥 8. 決勝 (kesshou)

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

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


🌟 9. チャンス (chansu)

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

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


🏅 10. 勝負 (shoubu)

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

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


🏮 Curiosidades Bellacosa:

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

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

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


🌟 Dica Bellacosa:

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

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

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


🌸 Conclusão Bellacosa:

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

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

sexta-feira, 9 de outubro de 2020

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

 

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

☕ Um Café no Bellacosa Mainframe

O Mercado das Linguagens sem Mistérios para Programadores COBOL

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

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

Imagine a manhã começando em Manhattan.

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

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

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

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

O jovem aponta para o gráfico e pergunta:

— Então COBOL está morrendo?

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

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

Bem-vindo ao pregão das linguagens.

Aqui, popularidade não é receita.

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

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

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


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

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

Ele apresenta quatro grandes regiões:

  • Advantage, ou vantagem;

  • Choice, ou escolha;

  • Cost, ou custo;

  • Replacement, ou substituição.

Também inclui marcos como:

  • início de mercado;

  • nascimento dos padrões;

  • auge da industrialização;

  • crepúsculo da obsolescência;

  • comoditização.

Como modelo intelectual, é interessante.

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

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

  • idade da linguagem;

  • quantidade de novos projetos;

  • custo de manutenção;

  • popularidade;

  • disponibilidade de profissionais;

  • maturidade de ferramentas;

  • valor econômico;

  • perspectiva de substituição.

Essas dimensões não caminham juntas.

Uma linguagem pode ser antiga e barata.

Outra pode ser moderna e caríssima.

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

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

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

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

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

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

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

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

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


A verdadeira bolsa de valores das linguagens

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

  1. adoção em novos projetos;

  2. base instalada;

  3. valor dos sistemas existentes;

  4. custo de substituição;

  5. disponibilidade de profissionais;

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

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

É exatamente o caso do COBOL.


1. Adoção em novos projetos

Essa é a métrica preferida dos rankings.

Ela responde:

Quantos sistemas novos estão sendo iniciados nesta linguagem?

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

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

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

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

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

Os cofres estão em outro andar.


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

2. Base instalada

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

É aqui que o mapa muda.

Considere dois projetos hipotéticos.

Projeto A

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

  • 20 mil linhas de código;

  • 15 microsserviços;

  • 800 usuários;

  • faturamento ainda experimental;

  • possibilidade de substituição relativamente simples.

Projeto B

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

  • milhões de linhas;

  • centenas de programas;

  • milhares de arquivos e tabelas;

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

  • processamento de milhões de clientes;

  • regras fiscais, contratuais e contábeis acumuladas;

  • funcionamento contínuo há décadas.

O Projeto A é mais novo.

O Projeto B é mais valioso.

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

Essa distinção raramente aparece em rankings.


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

Wall Street adora empresas de crescimento.

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

COBOL não pertence a essa categoria.

COBOL é mais parecido com:

  • uma empresa de energia;

  • uma rede ferroviária;

  • um sistema de compensação;

  • uma usina;

  • um porto;

  • um conjunto de cofres subterrâneos.

Ele não precisa ser excitante.

Precisa estar funcionando.

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

Esse é um ponto fundamental para o iniciante:

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

Muitas empresas modernizam sistemas COBOL por meio de:

  • APIs;

  • integração com Java;

  • serviços REST;

  • mensageria;

  • pipelines de CI/CD;

  • Git;

  • testes automatizados;

  • novos compiladores;

  • análise estática;

  • observabilidade;

  • interfaces web e móveis;

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

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

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


O erro da coluna “Cost”

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

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

A pergunta correta não é:

Quanto custa manter?

A pergunta correta é:

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

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

À primeira vista, parece caro.

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

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

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

O sistema antigo deixa de parecer caro.

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

O mercado não calcula apenas custo de desenvolvimento.

Calcula:

  • risco operacional;

  • risco regulatório;

  • risco de indisponibilidade;

  • risco de perda de dados;

  • risco reputacional;

  • risco de fraude;

  • risco de interpretação incorreta das regras;

  • risco de migração;

  • risco de dependência de fornecedor;

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

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

É proteger capital operacional.


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

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

Imagine uma seguradora.

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

  • novas leis;

  • novos produtos;

  • decisões judiciais;

  • mudanças de moeda;

  • planos especiais;

  • regras de exceção;

  • fusões empresariais;

  • acordos com clientes;

  • tratamentos para contratos antigos;

  • cálculos atuariais;

  • arredondamentos específicos;

  • datas de corte.

O programa pode conter uma condição como:

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

O programador iniciante olha e pensa:

— Isso é feio. Vamos simplificar.

O veterano pergunta:

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

Silêncio.

Talvez a data represente:

  • uma mudança monetária;

  • uma norma;

  • um produto encerrado;

  • um contrato coletivo;

  • um ajuste de transição;

  • uma determinação jurídica.

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

Eis a verdadeira mercadoria do programador COBOL:

conhecimento de negócio encapsulado em código.


O que os rankings realmente medem?

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

Não medem.

TIOBE

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

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

Não significa automaticamente:

  • mais vagas;

  • salários maiores;

  • mais sistemas críticos;

  • melhor desempenho;

  • maior faturamento;

  • maior relevância estratégica.

GitHub

O GitHub enxerga principalmente o universo hospedado na plataforma:

  • open source;

  • projetos públicos;

  • empresas que utilizam GitHub;

  • código criado ou espelhado ali.

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

  • bibliotecas internas antigas;

  • ambientes isolados;

  • código proprietário;

  • instituições financeiras restritas;

  • sistemas governamentais;

  • aplicações mantidas em ferramentas tradicionais;

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

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

Isso não as torna inexistentes.

Torna-as confidenciais.

Stack Overflow

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

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

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

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

  • documentação interna;

  • Redbooks;

  • manuais IBM;

  • bases corporativas;

  • colegas;

  • contratos de suporte;

  • comunidades especializadas.

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

Às vezes significa segurança.


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

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

COBOL deveria ocupar uma categoria própria:

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

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

Mas continua excelente para:

  • processamento em lote;

  • transações comerciais;

  • cálculos financeiros;

  • grandes volumes de registros;

  • regras de negócio;

  • integração com bancos de dados empresariais;

  • sistemas que exigem previsibilidade e continuidade.

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

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

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


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

Java não é novidade.

Exatamente por isso é valioso.

Ele possui:

  • ecossistema gigantesco;

  • bibliotecas maduras;

  • JVM;

  • frameworks;

  • profissionais;

  • ferramentas;

  • aplicações bancárias;

  • sistemas governamentais;

  • plataformas empresariais;

  • serviços de backend;

  • Android em sua trajetória histórica.

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

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

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

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


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

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

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

Hoje está presente em:

  • frontend;

  • backend;

  • aplicações desktop;

  • ferramentas;

  • automação;

  • servidores;

  • plataformas;

  • aplicações móveis;

  • ambientes cloud.

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

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

O mercado não recompensa apenas quem chega primeiro.

Recompensa quem resolve melhor o problema no momento certo.


Python: a moeda preferida da era da IA

Python cresceu porque conseguiu tornar-se simultaneamente:

  • acessível para iniciantes;

  • útil para automação;

  • forte em ciência de dados;

  • dominante em inteligência artificial;

  • presente no backend;

  • adequado para protótipos;

  • cercado por bibliotecas.

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

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

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

Mas não elimina:

  • C em sistemas;

  • COBOL em regras empresariais;

  • Java em plataformas corporativas;

  • JavaScript e TypeScript na web;

  • Fortran em computação científica;

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

Wall Street gosta de narrativas absolutas.

A engenharia prefere contexto.


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

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

Entretanto, continuam presentes em:

  • sistemas operacionais;

  • bancos de dados;

  • compiladores;

  • jogos;

  • navegadores;

  • dispositivos;

  • sistemas embarcados;

  • telecomunicações;

  • aplicações de alto desempenho.

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

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

Eles não desapareceram.

Tornaram-se subterrâneos.

Como cabos, tubulações e cofres.


Fortran: o velho cientista que ainda controla o reator

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

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

Permanece relevante em:

  • meteorologia;

  • física;

  • engenharia;

  • modelagem;

  • simulações;

  • supercomputação;

  • pesquisa climática.

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

É uma nova validação científica.

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

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


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

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

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

RPG possui forte associação com IBM i.

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

O número de novos programadores é menor.

Isso cria um paradoxo interessante:

  • menos vagas totais;

  • menos candidatos qualificados;

  • maior dependência de conhecimento especializado;

  • risco de sucessão;

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

Não é um mercado de massa.

É um mercado de nicho com portas pesadas.


Passo a passo para o programador COBOL iniciante ler o mercado

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

Pergunte:

  • Em qual setor?

  • Em qual país?

  • Em qual plataforma?

  • Para qual tipo de aplicação?

  • Em empresas de qual tamanho?

  • Em projetos novos ou manutenção?

  • Com qual nível de responsabilidade?

“Python está crescendo” é verdadeiro.

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


Passo 2 — Aprenda a diferenciar popularidade de valor

Popularidade mede atenção.

Valor mede consequência.

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

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

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


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

O iniciante não deve aprender apenas COBOL.

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

Uma combinação poderosa inclui:

  • COBOL;

  • JCL;

  • Db2;

  • CICS ou IMS;

  • VSAM;

  • Git;

  • APIs;

  • Linux ou Unix;

  • noções de Java ou Python;

  • testes;

  • CI/CD;

  • observabilidade;

  • fundamentos de segurança.

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

É aquele que conecta mundos.


Passo 4 — Aprenda negócio

Um programador COBOL que entende apenas sintaxe possui valor limitado.

Um programador que entende:

  • contabilidade;

  • crédito;

  • seguros;

  • pagamentos;

  • previdência;

  • logística;

  • faturamento;

  • tributação;

  • conciliação;

  • processamento batch;

transforma-se em especialista.

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

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


Passo 5 — Aprenda a modernizar sem destruir

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

  1. O que o sistema faz?

  2. Quais aplicações dependem dele?

  3. Quais dados utiliza?

  4. Qual o volume processado?

  5. Quais regras são críticas?

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

  7. Quais interfaces podem ser expostas?

  8. O que pode ser refatorado?

  9. O que deve permanecer?

  10. Como testar equivalência?

Depois vêm as ferramentas.

Nunca o contrário.

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


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

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

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

Um sistema COBOL pode conter o conhecimento de centenas de:

  • analistas;

  • contadores;

  • especialistas;

  • advogados;

  • operadores;

  • gestores;

  • programadores;

  • auditores.

Muitos já se aposentaram.

Alguns faleceram.

Outros sequer lembram por que determinada regra foi criada.

O código permaneceu.

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

É memória institucional compilável.


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

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

Na tecnologia, existe uma versão semelhante:

  • a cobiça pela linguagem nova;

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

  • a cobiça pelo contrato milionário;

  • a cobiça pela arquitetura com cinquenta produtos;

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

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

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

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

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

No mainframe, o verdadeiro lema não é:

“A cobiça é boa.”

É:

“O fechamento precisa bater.”


O novo mapa realista

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

Criaríamos zonas diferentes.

Zona 1 — Crescimento e experimentação

  • novas linguagens;

  • novos frameworks;

  • alto volume de projetos;

  • mudanças rápidas;

  • risco de desaparecimento.

Zona 2 — Adoção industrial

  • ecossistemas maduros;

  • forte mercado;

  • disponibilidade de profissionais;

  • ampla utilização.

Zona 3 — Infraestrutura consolidada

  • sistemas críticos;

  • grande base instalada;

  • alto custo de substituição;

  • evolução gradual;

  • menor visibilidade pública.

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

Zona 4 — Nichos especializados

  • Fortran;

  • PL/I;

  • RPG;

  • Erlang;

  • Haskell;

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

Zona 5 — Declínio real

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

  • ausência de manutenção;

  • fim de compiladores;

  • desaparecimento de fornecedores;

  • falta de sistemas relevantes;

  • impossibilidade de integração;

  • abandono completo do ecossistema.

Ser antiga não basta.

Ser pouco comentada também não.


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

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

Os influenciadores fecham seus rankings.

Os consultores recolhem seus slides.

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

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

Um programa COBOL abre arquivos.

Consulta tabelas.

Processa milhões de registros.

Aplica regras criadas durante décadas.

Gera lançamentos.

Atualiza saldos.

Produz relatórios.

Dispara mensagens.

Fecha o movimento.

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

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

COBOL não lidera os rankings de entusiasmo.

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

Não produz a maior quantidade de tutoriais coloridos.

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

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

O iniciante deve abandonar dois medos.

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

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

A estratégia vencedora está no meio.

Conheça profundamente o legado.

Aprenda os sistemas que o cercam.

Entenda o negócio.

Domine integração.

Use ferramentas modernas.

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

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

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

Paga por confiança.

Paga por continuidade.

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

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

Frameworks tornam-se estrelas e desaparecem.

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

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

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

Ele é o sistema que imprime o extrato.


quarta-feira, 7 de outubro de 2020

O EFEITO ZEIGARNIK EXPLICADO PARA OPERADORES DE MAINFRAME, OTAKUS E SOBREVIVENTES DE ANOTHER

 

Bellacosa Mainframe e o efeito zeigarnik em animes

☕💣👁️ OPERADOR, POR QUE VOCÊ AINDA ESTÁ PENSANDO NISSO?

O EFEITO ZEIGARNIK EXPLICADO PARA OPERADORES DE MAINFRAME, OTAKUS E SOBREVIVENTES DE ANOTHER

Existe uma pergunta que parece simples.

Mas ela esconde um dos fenômenos psicológicos mais fascinantes já descobertos.

A pergunta é:

Por que algumas histórias saem da nossa cabeça imediatamente, enquanto outras permanecem rodando durante dias, semanas ou até anos?

Você termina um anime.

Fecha o player.

Desliga o computador.

Vai dormir.

Mas alguma coisa continua executando em background.

Você pensa em Reiko.

Pensa no guarda-chuva.

Pensa naquela cena específica.

Pensa em um detalhe que parecia irrelevante.

Pensa novamente no final.

E de repente percebe que o anime acabou.

Mas você não terminou de assistir.

Pelo menos não dentro da sua cabeça.

Bem-vindo ao universo do Efeito Zeigarnik.

Ou, em linguagem Bellacosa Mainframe:

JOB FINALIZADO

RC=00

MAS O PROCESSAMENTO CONTINUA

QUEM FOI BLUMA ZEIGARNIK?

Antes de tudo precisamos voltar para a década de 1920.

Uma psicóloga soviética chamada Bluma Zeigarnik observou algo curioso.

Ela frequentava restaurantes em Berlim.

E percebeu que os garçons tinham uma memória extraordinária.

Eles lembravam:

  • pedidos

  • mesas

  • clientes

  • valores

Sem anotar quase nada.

Mas havia um detalhe estranho.

Quando a conta era paga, os garçons pareciam esquecer rapidamente aquelas informações.

Como se os dados fossem apagados.

Aquilo chamou sua atenção.


O EXPERIMENTO

Zeigarnik resolveu testar a hipótese.

Ela criou uma série de tarefas para participantes.

Algumas pessoas conseguiam concluir as tarefas.

Outras eram interrompidas no meio do processo.

O resultado foi surpreendente.

As pessoas lembravam muito mais das tarefas interrompidas do que das tarefas concluídas.


Em termos simples:

O cérebro esquece o que terminou.

Mas continua pensando no que ficou incompleto.


O NASCIMENTO DO EFEITO ZEIGARNIK

A conclusão foi revolucionária.

Quando uma atividade permanece incompleta, ela cria uma espécie de tensão psicológica.

Essa tensão permanece ativa.

O cérebro continua tentando resolver o problema.

Mesmo quando você não está conscientemente pensando nele.


EM LINGUAGEM MAINFRAME

Imagine um batch.

Tudo corre normalmente.

JOB START
PROCESSAMENTO
VALIDAÇÃO
RELATÓRIO
JOB END

O sistema encerra.

Pronto.

Agora imagine:

JOB START
PROCESSAMENTO
VALIDAÇÃO
ABEND S0C7

Fim.

Agora o operador não consegue esquecer.

Ele pensa:

  • O que aconteceu?

  • Onde falhou?

  • Qual dataset causou o erro?

  • Existe impacto financeiro?

O job ocupa espaço mental.


O CÉREBRO ODEIA PONTAS SOLTAS

Essa talvez seja a melhor forma de entender o fenômeno.

O cérebro humano ama padrões.

Ama conclusões.

Ama fechamento.

Quando algo fica aberto:

STATUS = INCOMPLETO

A mente continua tentando finalizar o processamento.


POR QUE ANOTHER FICOU NA SUA CABEÇA?

Agora chegamos ao ponto.

Você comentou anteriormente que terminou Another e ficou com um vazio.

Isso é praticamente um estudo de caso do Efeito Zeigarnik.

Porque o anime não entrega apenas respostas.

Ele entrega perguntas.


Você termina pensando:

  • Reiko...

  • As memórias...

  • O guarda-chuva...

  • Os alunos...

  • O destino...

  • O acaso...

Mesmo após os créditos.

O sistema não recebeu comando END.


O EFEITO ZEIGARNIK NOS ANIMES

Os roteiristas japoneses conhecem isso intuitivamente.

Mesmo sem citar a teoria.


Evangelion

O anime termina.

Mas sua mente continua trabalhando.

Décadas depois.


Serial Experiments Lain

Você termina.

Mas continua tentando entender.


Monster

Você fecha o último episódio.

Mas continua analisando Johan.


Steins;Gate

Você continua revisitando linhas temporais mentalmente.


Another

Você continua revisitando cenas.


O SEGREDO DAS GRANDES OBRAS

Muitos acreditam que uma boa história responde tudo.

Na verdade não.

As maiores obras deixam espaço.


Elas criam:

  • ambiguidades

  • interpretações

  • lacunas

Porque lacunas geram processamento.


O CÉREBRO COMO OPERADOR

Imagine seu cérebro como um operador de produção.

Ele recebe um incidente.


Caso Resolvido

INCIDENTE FECHADO
TICKET ENCERRADO

Esquecido.


Caso Aberto

INCIDENTE EM INVESTIGAÇÃO

Não esquecido.


O EFEITO NAS RELAÇÕES HUMANAS

Aqui a coisa fica assustadora.

O fenômeno não acontece apenas com animes.


Relacionamentos

Pessoas frequentemente lembram mais:

  • relacionamentos interrompidos

  • despedidas incompletas

  • conversas não encerradas

do que relacionamentos encerrados adequadamente.


Luto

Muitas vezes o sofrimento aumenta quando existem questões não resolvidas.


Trabalho

Projetos inacabados permanecem ocupando espaço mental.


POR QUE CLIFFHANGERS FUNCIONAM?

Todo roteirista ama cliffhangers.

Porque eles exploram diretamente o Efeito Zeigarnik.


Imagine:

PERSONAGEM ABRE A PORTA
FIM DO EPISÓDIO

Pronto.

Seu cérebro foi sequestrado.


O DOPAMINE LOOP

Existe ainda um componente neurológico.

A expectativa ativa circuitos de recompensa.


Você acredita que uma resposta está próxima.

Então continua assistindo.

Continua lendo.

Continua investigando.


O GUARDA-CHUVA DE ANOTHER

Curiosamente o guarda-chuva é um excelente exemplo.

Não apenas pela cena.

Mas porque ele permanece.


Você começa a associar:

GUARDA-CHUVA
=
PERIGO

Mesmo sabendo racionalmente que não existe perigo.

O símbolo continua ativo.


O EFEITO REIKO

Algo semelhante ocorre com Reiko.

Após a revelação, o cérebro inicia um processo automático:

REPROCESSANDO MEMÓRIAS...

Você revisita:

  • diálogos

  • olhares

  • situações

Tudo ganha novo significado.


A MEMÓRIA NÃO É UM ARQUIVO

Aqui está outra descoberta fascinante.

Muitas pessoas imaginam memória como uma gravação.

Não é.


Cada lembrança é reconstruída.

Toda vez.


Quando surge uma nova informação, o cérebro reorganiza o passado.


POR QUE ALGUNS ANIMES SÃO ESQUECIDOS?

Porque fecham tudo.


Início.

Meio.

Fim.


Sem mistério.

Sem ambiguidades.

Sem lacunas.


Resultado:

JOB END

POR QUE OUTROS VIRAM CLÁSSICOS?

Porque continuam executando.


Décadas depois.


Evangelion.

Lain.

Monster.

Berserk.

Another.


Cada um deixa algo aberto.


O MAIOR EFEITO ZEIGARNIK DE TODOS

Agora vamos extrapolar.


Talvez o maior mistério não seja um anime.

Nem um romance.

Nem um filme.


Talvez seja a própria vida.


Pense nisso.

Quantas perguntas permanecem abertas?


  • O que poderia ter acontecido?

  • E se eu tivesse escolhido outro caminho?

  • E se aquela decisão fosse diferente?


O cérebro odeia essas perguntas.

Mas nunca consegue respondê-las completamente.


BELLACOSA MAINFRAME: A TEORIA DEFINITIVA

Se eu tivesse que explicar o Efeito Zeigarnik para uma turma de operadores de z/OS:

Diria o seguinte.


Existem dois tipos de jobs.


Job Tipo A

START
PROCESSA
FINALIZA

RC=00

Esquecido.


Job Tipo B

START
PROCESSA

ABEND

MOTIVO DESCONHECIDO

Imortal.


Você vai pensar nele:

  • no almoço

  • no banho

  • no trânsito

  • na madrugada


Porque o cérebro foi projetado para resolver problemas inacabados.


VEREDITO FINAL DO OPERADOR

O Efeito Zeigarnik explica por que você ainda pensa em Another.

Não porque seja o anime mais complexo.

Não porque seja o anime mais profundo.

Mas porque ele deixou processos abertos.

E processos abertos continuam consumindo CPU emocional.

Na linguagem Bellacosa Mainframe:

ANOTHER.EXE

STATUS:
FINALIZADO

PROCESSOS RESIDENTES:
REIKO.DLL
UMBRELLA.SYS
MORTALIDADE.MOD
MELANCOLIA.EXE

CPU:
ATIVA

MEMÓRIA:
OCUPADA

PREVISÃO DE ENCERRAMENTO:
DESCONHECIDA

☕💣👁️

LOG FINAL

Algumas histórias terminam quando os créditos aparecem.

Outras continuam executando silenciosamente dentro do operador.

O Efeito Zeigarnik é o nome que a psicologia deu para esse processo.

Os otakus chamam apenas de:

"Não consigo parar de pensar nesse anime."

 

segunda-feira, 5 de outubro de 2020

🧙‍♂️ SHIROE E A DUNGEON DOS DADOS — QUANDO O COBOL DESCOBRIU QUE DATA LAKE NÃO ERA UM LAGO, DATA MART NÃO ERA SUPERMERCADO E O WAREHOUSE NÃO TINHA EMPILHADEIRA

 

Bellacosa Mainframe e os daods e seus repositorios

☕ Um Café no Bellacosa Mainframe

🧙‍♂️ SHIROE E A DUNGEON DOS DADOS — QUANDO O COBOL DESCOBRIU QUE DATA LAKE NÃO ERA UM LAGO, DATA MART NÃO ERA SUPERMERCADO E O WAREHOUSE NÃO TINHA EMPILHADEIRA



Data Warehouse, Data Lake, Data Mart, Lakehouse, ETL, ELT, Schema-on-Write, Schema-on-Read, Star Schema, governança, CICS, Db2, IMS, VSAM, MQ, SMF — e o dia em que Shiroe percebeu que armazenar 8 petabytes de dados não significava absolutamente nada se ninguém soubesse onde estava o cadastro correto do cliente.



🎬 PRÓLOGO — BEM-VINDO A ELDER TALE, PROGRAMADOR COBOL

O jovem programador COBOL acordou assustado.

Olhou em volta.

Não havia ISPF.

Não havia SDSF.

Não havia nem aquela reconfortante tela preta com letras verdes capaz de avisar:

READY

Em seu lugar havia uma enorme cidade medieval.

Guerreiros caminhavam pelas ruas. Magos discutiam estratégias. Mercadores anunciavam poções. Aventureiros corriam atrás de monstros.

— Onde estou?

Uma voz respondeu atrás dele:

— Akiba.

Ele se virou.

Óculos redondos. Capa. Cajado. Expressão de quem provavelmente havia acabado de analisar quinze diagramas de arquitetura antes do café da manhã.

Era Shiroe, de Log Horizon.

— Você é um aventureiro?

— Programador COBOL.

Shiroe ajeitou os óculos.

— Quase a mesma coisa.

— Preciso voltar ao mainframe.

— Primeiro você precisa compreender uma dungeon.

— Qual?

Shiroe apontou para três enormes construções no horizonte.

Na primeira estava escrito:

DATA WAREHOUSE

Na segunda:

DATA LAKE

E na terceira:

DATA MART

Mais distante havia uma quarta construção misteriosa:

LAKEHOUSE

O programador respirou fundo.

— Posso dar CANCEL?

— Não.

— ROLLBACK?

— Também não.

— Então ferrou.

Shiroe sorriu.

— Agora você está aprendendo Data Engineering.



🏰 CAPÍTULO 1 — TRÊS CONSTRUÇÕES, TRÊS MISSÕES DIFERENTES

Existe uma simplificação excelente para começar:

WAREHOUSE = dados confiáveis para a empresa

LAKE      = dados diversos e flexíveis em escala

MART      = dados preparados para uma área específica

O erro começa quando interpretamos isso como:

"Preciso escolher apenas um deles."

Não necessariamente.

Data Warehouse, Data Lake e Data Mart não são três produtos disputando uma vaga.

Eles representam padrões arquiteturais com objetivos diferentes e podem coexistir.

Uma empresa pode possuir simultaneamente:

Sistemas Operacionais
        |
        v
    Data Lake
        |
        v
 Data Warehouse
        |
   +----+----+
   |    |    |
   v    v    v
 Mart  Mart  Mart

E arquiteturas mais recentes podem substituir ou reorganizar partes desse desenho com Lakehouse, streaming, produtos de dados e outras abordagens.

Shiroe escreveria no quadro:

"Não comece escolhendo a tecnologia. Comece descobrindo o problema."

É uma excelente regra de arquitetura.



🏭 CAPÍTULO 2 — DATA WAREHOUSE: O GRANDE ARMAZÉM DA GUILDA

A tradução literal de warehouse é armazém.

Mas não imagine um galpão onde alguém joga caixas pela janela.

Um bom armazém possui:

  • organização;

  • classificação;

  • endereçamento;

  • controle;

  • inventário;

  • procedimentos;

  • segurança;

  • rastreabilidade.

Um Data Warehouse segue filosofia semelhante.

Ele procura disponibilizar dados preparados para análise empresarial.

Imagine uma corporação contendo:

ERP
CRM
Folha de pagamento
E-commerce
Mainframe
Aplicativos
Sistemas financeiros
Logística

Cada sistema pode representar uma entidade de maneira diferente.

Um sistema registra:

CLIENTE = 00012345

Outro:

CUSTOMER_ID = 12345

Outro trabalha principalmente com:

CPF = 123.456.789-00

O Data Warehouse não deveria simplesmente copiar tudo e desejar boa sorte ao analista.

Existe um trabalho de integração, transformação, padronização e governança.

Um fluxo tradicional poderia ser:

FONTES
  |
  v
EXTRAÇÃO
  |
  v
TRANSFORMAÇÃO
  |
  v
VALIDAÇÃO
  |
  v
DATA WAREHOUSE
  |
  +------> BI
  +------> Dashboards
  +------> KPIs
  +------> Relatórios
  +------> Analytics

Essa organização permite responder perguntas corporativas.



⚔️ CAPÍTULO 3 — OLTP NÃO É ANALYTICS

Nosso programador COBOL pergunta:

— Mas se os dados já estão no Db2, para que copiar?

Shiroe desenha duas missões.

Primeira:

Qual é o saldo da conta 12345?

Segunda:

Qual foi a evolução do comportamento
de compra dos clientes paulistas
nos últimos cinco anos,
separada por faixa etária,
canal, produto e mês?

São problemas diferentes.

O primeiro pertence tipicamente ao universo OLTP — Online Transaction Processing.

Precisamos processar rapidamente operações individuais.

No mainframe poderíamos ter:

Cliente
   |
   v
API
   |
   v
CICS
   |
   v
COBOL
   |
   v
Db2

Uma transação chega, é processada e recebe resposta.

Já a segunda pergunta pode envolver milhões ou bilhões de registros, agregações, cruzamentos e histórico.

Não queremos transformar cada consulta de BI numa invasão bárbara ao sistema transacional.

É uma separação importantíssima:

OPERACIONAL
"O que está acontecendo?"

ANALÍTICO
"O que aconteceu e o que podemos aprender?"


📜 CAPÍTULO 4 — SCHEMA-ON-WRITE: PREENCHA A FICHA ANTES DE ENTRAR NA GUILDA

Uma característica historicamente associada aos Data Warehouses é Schema-on-Write.

Antes de armazenar o dado na estrutura analítica definitiva, sabemos como queremos representá-lo.

Imagine:

CREATE TABLE VENDAS (
    ID_VENDA       BIGINT,
    ID_CLIENTE     BIGINT,
    DATA_VENDA     DATE,
    VALOR          DECIMAL(15,2),
    ID_PRODUTO     INTEGER
);

Chega um evento:

{
  "cliente": 12345,
  "produto": 991,
  "valor": 199.90
}

Precisamos interpretar e transformar aquilo para a estrutura desejada.

Há disciplina.

E disciplina tem custo.

Precisamos definir:

tipos
chaves
regras
relacionamentos
qualidade
significado

Mas recebemos algo importantíssimo em troca:

confiança.

Quando duas áreas perguntam quanto a companhia faturou em agosto, o ideal não é receber:

Financeiro: R$ 97 milhões
Vendas:     R$ 103 milhões
Marketing:  R$ 112 milhões
Igor:       depende

🤣

Se cada área possui sua própria definição de "faturamento", temos um problema semântico, não simplesmente tecnológico.


🌊 CAPÍTULO 5 — DATA LAKE: SHIROE MANDA GUARDAR O LOOT

Agora imagine outra necessidade.

Temos:

CSV
JSON
XML
Parquet
logs
documentos
imagens
eventos
telemetria
streams
dados de IoT

Nem sempre sabemos antecipadamente todas as análises que faremos.

Entra o Data Lake.

A filosofia é muito mais flexível.

        FONTES
          |
 +--------+--------+
 |        |        |
JSON     CSV      LOG
 |        |        |
 +--------+--------+
          |
          v
      DATA LAKE

O Lake pode armazenar enormes quantidades de dados estruturados, semiestruturados e não estruturados.

Isso o torna muito atraente para:

Data Science
Machine Learning
Big Data
Experimentação
Streaming
Exploração
Histórico massivo

Mas existe uma diferença importante.

O Lake não deve ser confundido com:

"HD gigantesco onde jogamos qualquer coisa."

Esse caminho leva diretamente para outra criatura.


🐊 CAPÍTULO 6 — O DATA SWAMP: O BOSS QUE NINGUÉM QUER ENFRENTAR

Shiroe leva o programador até uma região pantanosa.

Existem oito petabytes de dados.

— Impressionante! — diz o COBOLzeiro.

— Encontre o cadastro correto dos clientes.

Silêncio.

— Qual diretório?

— Ninguém sabe.

— Quem criou os arquivos?

— Não sabemos.

— Quando?

— Também não.

— Qual é o formato?

— Depende.

— São dados de produção?

— Talvez.

— Posso confiar?

— Boa pergunta.

Parabéns.

Seu Data Lake evoluiu para:

DATA SWAMP.

Um pântano de dados.

Esse é um dos maiores riscos de uma arquitetura de Lake mal governada.

Guardar é fácil.

Descobrir, compreender, proteger e confiar é difícil.

Por isso entram conceitos como:

Metadata
Data Catalog
Data Lineage
Data Quality
IAM
Classificação
Criptografia
Retenção
Auditoria
Governança

Um Lake sem metadados pode ser como encontrar um dataset chamado:

CLIENTES_FINAL_V3_NOVO_FINAL2_OK.csv

e descobrir que existem outros 83 arquivos parecidos.

Qual é o correto?

Bem-vindo à dungeon.


🔮 CAPÍTULO 7 — SCHEMA-ON-READ: PRIMEIRO GUARDE, DEPOIS INTERPRETE

Data Lakes são tradicionalmente associados ao conceito de Schema-on-Read.

Simplificando:

No Warehouse:

definimos estrutura
        |
        v
carregamos os dados

No Lake:

armazenamos os dados
        |
        v
interpretamos conforme consumo

Imagine bilhões de eventos:

{
  "timestamp": "2026-09-22T03:17:00",
  "transaction": "ABC991",
  "response_time": 824,
  "region": "SP"
}

Um cientista de dados talvez queira:

timestamp
response_time
region

Um engenheiro de segurança pode querer outros atributos.

A flexibilidade é enorme.

Mas não transforme a distinção entre Schema-on-Write e Schema-on-Read numa religião.

Plataformas modernas misturam estratégias.

Arquitetura de dados evoluiu.


🛒 CAPÍTULO 8 — DATA MART: A LOJA ESPECIALIZADA DE AKIBA

Imagine agora que o Data Warehouse possui informações de:

RH
Financeiro
Marketing
Vendas
Logística
Clientes
Produtos
Fraudes
Fornecedores

A equipe de Marketing precisa realmente navegar por tudo?

Provavelmente não.

Criamos então uma visão especializada.

             DATA WAREHOUSE
                   |
       +-----------+-----------+
       |           |           |
       v           v           v
     MART        MART        MART
   FINANCEIRO    VENDAS     MARKETING

O Data Mart entrega dados preparados para determinado domínio, departamento ou caso de uso.

O Mart de Marketing poderia conter:

Cliente
Campanha
Canal
Segmentação
Conversão
Lifetime Value

O Financeiro:

Receita
Despesa
Margem
Impostos
Fluxo de Caixa

E Vendas:

Produto
Vendedor
Região
Meta
Receita
Comissão

Isso reduz a complexidade para o usuário.


⭐ CAPÍTULO 9 — O STAR SCHEMA E A PARTY DE CINCO PERSONAGENS

Shiroe desenha uma estrela.

No centro:

               DIM_CLIENTE
                    |
                    |
DIM_PRODUTO --- FATO_VENDA --- DIM_TEMPO
                    |
                    |
                 DIM_LOJA

Temos um Star Schema.

No centro fica normalmente a tabela fato, contendo eventos e medidas.

Por exemplo:

FATO_VENDA

ID_CLIENTE
ID_PRODUTO
ID_TEMPO
ID_LOJA
QUANTIDADE
VALOR
DESCONTO
CUSTO

Ao redor ficam dimensões.

Elas respondem perguntas como:

Quem?
O quê?
Quando?
Onde?
Como?

Assim conseguimos perguntar:

Quanto vendemos do produto X no interior de São Paulo em agosto?

A tabela fato fornece as medidas.

As dimensões fornecem contexto.

É uma ideia extremamente poderosa para BI.


🔄 CAPÍTULO 10 — ETL vs ELT: A ORDEM DOS FEITIÇOS IMPORTA

Outro conceito que o jovem COBOLzeiro precisa dominar:

ETL

EXTRACT
   |
   v
TRANSFORM
   |
   v
LOAD

Primeiro extraímos.

Depois transformamos.

Finalmente carregamos no destino.

Mas existe:

ELT

EXTRACT
   |
   v
LOAD
   |
   v
TRANSFORM

Primeiro extraímos e carregamos.

Depois usamos a capacidade da plataforma para realizar transformações.

Portanto:

Warehouse = ETL

não é uma regra universal.

Ambientes modernos utilizam muito ELT.

E frequentemente encontramos combinações.

Shiroe diria:

"A sequência depende da estratégia da raid."


🏠 CAPÍTULO 11 — SURGE O LAKEHOUSE

Nos limites de Akiba existe a quarta construção.

Lakehouse.

A ideia tenta combinar características historicamente associadas aos dois mundos.

Do Lake:

escala
flexibilidade
múltiplos formatos
armazenamento econômico

Do Warehouse:

governança
SQL
estrutura
qualidade
BI
gerenciamento de tabelas

Em forma de feitiço:

DATA LAKE
    +
capacidades de DATA WAREHOUSE
    =
LAKEHOUSE

Isso tornou a velha discussão:

"Lake ou Warehouse?"

muito menos binária.

As fronteiras ficaram borradas.

E continuam evoluindo.


🖥️ CAPÍTULO 12 — SHIROE ENCONTRA UM IBM Z NO MEIO DA DUNGEON

Agora chegamos à parte divertida.

No subsolo de Akiba existe uma máquina.

Na placa:

IBM Z

Shiroe encontra:

COBOL
CICS
IMS
Db2
VSAM
MQ
JES

O programador pergunta:

— Precisamos transformar o mainframe num Data Lake?

— Não!

Eis um ponto fundamental.

O IBM Z pode continuar desempenhando brilhantemente sua função de System of Record e plataforma transacional.

Imagine:

              IBM Z
                |
      +---------+---------+
      |         |         |
     Db2       IMS       VSAM
      |         |         |
      +---------+---------+
                |
        CDC / ETL / APIs
         MQ / Streaming
                |
                v
        Plataforma de Dados

CDC significa Change Data Capture.

Em vez de executar cargas gigantescas indiscriminadamente, podemos capturar mudanças relevantes e propagá-las para outros ambientes.

Também podemos utilizar:

MQ
APIs
Batch
Streaming
ETL/ELT

dependendo do caso.


💳 CAPÍTULO 13 — A COMPRA DE R$ 3.499

Imagine uma compra.

Valor: R$ 3.499
Horário: 03:17
Local: São Paulo
Canal: Internet

No sistema transacional, queremos algo como:

TRANSACTION_ID
ACCOUNT
VALUE
STATUS

Precisamos autorizar ou recusar rapidamente.

Mas no Warehouse aquela mesma realidade pode virar:

FATO_VENDA
DIM_CLIENTE
DIM_TEMPO
DIM_CANAL
DIM_PRODUTO

No Lake podemos preservar:

evento JSON
logs
clickstream
telemetria
informações antifraude

E no Data Mart de fraude:

cliente
valor
device
localização
risco
score

Veja a mágica.

Não estamos falando necessariamente de quatro eventos diferentes.

Estamos falando de diferentes representações e usos dos dados relacionados ao mesmo evento de negócio.


🔐 CAPÍTULO 14 — RAW NÃO SIGNIFICA "PODE TUDO"

Um aventureiro aparece correndo.

— Shiroe! Criei nosso Lake!

— Excelente.

— Coloquei CPF, cartões, tokens, credenciais, documentos e tudo mais!

Shiroe congela.

🤣

Dados brutos não significam dados sem controle.

Um Data Lake corporativo continua precisando de:

IAM
RBAC/ABAC
Encryption
Masking
Tokenization
Auditing
Retention
Classification
Lineage
LGPD

A flexibilidade aumenta a importância da governança.

Se você centraliza enormes quantidades de informação sensível, está também criando um ativo extremamente interessante para um atacante.


🧭 CAPÍTULO 15 — PASSO A PASSO PARA NÃO CONSTRUIR A ARQUITETURA AO CONTRÁRIO

Antes de escolher tecnologia, faça perguntas.

Passo 1 — Identifique as fontes

Db2?
IMS?
VSAM?
Oracle?
SAP?
APIs?
Kafka?
Arquivos?
Logs?

Passo 2 — Descubra os consumidores

Quem utilizará?

Executivos?
BI?
Data Scientists?
Marketing?
Financeiro?
Fraude?
IA?

Passo 3 — Descubra a latência necessária

O dado precisa chegar:

em 20 ms?
em 1 segundo?
em 5 minutos?
uma vez por hora?
durante o batch noturno?

Isso muda completamente a arquitetura.

Passo 4 — Determine qualidade e governança

Pergunte:

Quem é o dono?
Qual é a fonte oficial?
Quem pode acessar?
Quanto tempo guardar?
É informação pessoal?
Pode sair do mainframe?

Passo 5 — Escolha o padrão apropriado

Precisa de analytics corporativo confiável?

Warehouse pode fazer sentido.

Precisa preservar enormes volumes heterogêneos para exploração?

Lake pode fazer sentido.

Uma área específica precisa de dados curados?

Mart pode fazer sentido.

Precisa combinar capacidades?

Lakehouse pode entrar na conversa.


🥚 EASTER EGG — 03:17 E O INCIDENTE DO DATA LAKE

Às exatamente:

03:17:00

um alerta dispara.

JOB DLK0317 ABEND

O operador chama Shiroe.

— Perdemos o Data Lake!

Shiroe pergunta:

— Backup?

— Temos.

— Catálogo?

— Não.

— Lineage?

— Não.

— Metadata?

— Não.

— Documentação?

— O Igor estava fazendo.

Shiroe tira os óculos.

Silêncio.

O programador COBOL sussurra:

— Então não perdemos o Lake.

Shiroe olha para ele.

— Exatamente.

— Perdemos o mapa.

E essa talvez seja a melhor lição deste artigo.


🗺️ CAPÍTULO 16 — DATA LINEAGE: O MAPA DA DUNGEON

Data Lineage responde:

De onde veio este dado e o que aconteceu com ele?

Imagine:

VSAM CLIENTES
      |
      v
    CDC
      |
      v
RAW CUSTOMER
      |
      v
TRANSFORMAÇÃO
      |
      v
CURATED CUSTOMER
      |
      v
DATA MART
      |
      v
DASHBOARD CFO

Se o CFO encontra um número estranho no dashboard, precisamos conseguir voltar pela trilha.

Dashboard
   ^
   |
Mart
   ^
   |
Transformação
   ^
   |
Origem

Para um veterano de mainframe, essa filosofia deveria soar familiar.

Rastreabilidade sempre foi assunto sério em ambientes críticos.


🧠 CAPÍTULO 17 — A PERGUNTA QUE VALE MAIS QUE PETABYTES

No final da aventura, Shiroe coloca quatro placas sobre a mesa:

DATA LAKE
DATA WAREHOUSE
DATA MART
LAKEHOUSE

E pergunta:

— Qual é a melhor?

O jovem programador já aprendeu a armadilha.

— Depende do problema.

Shiroe sorri.

Exatamente.

Porque a pergunta madura não é:

"Onde vamos guardar os dados?"

É:

"Qual jornada esse dado precisa percorrer desde sua origem até produzir uma decisão?"

Podemos desenhar:

         SISTEMA OPERACIONAL
                |
                v
       CAPTURA / INTEGRAÇÃO
                |
       +--------+--------+
       |                 |
       v                 v
   DATA LAKE        DATA WAREHOUSE
       |                 |
       +--------+--------+
                |
                v
          CAMADA CURADA
                |
       +--------+--------+
       |        |        |
       v        v        v
      MART     MART     MART
       |        |        |
       +--------+--------+
                |
                v
          BI / ML / IA

Ou arquiteturas diferentes podem ser mais apropriadas.

A tecnologia muda.

A pergunta permanece.


🎓 EPÍLOGO — SHIROE ENTREGA O CAJADO AO PROGRAMADOR COBOL

Ao final da dungeon, nosso aventureiro finalmente encontra o terminal.

Na tela:

READY

Ele sorri.

Agora compreende que COBOL, CICS, Db2, IMS e VSAM não estão isolados do mundo moderno dos dados.

Muito pelo contrário.

Imagine o fluxo:

COBOL
  |
CICS
  |
Db2 / IMS / VSAM
  |
CDC / MQ / APIs / Batch / Streaming
  |
  v
PLATAFORMA DE DADOS
  |
  +----> Lake
  |
  +----> Warehouse
  |
  +----> Lakehouse
  |
  +----> Marts
  |
  v
BI / Analytics / ML / IA

O programa COBOL que processa uma transação às 03:17 pode estar produzindo o evento que amanhã será usado por um dashboard, um modelo antifraude ou um algoritmo de Machine Learning.

É a mesma empresa.

É o mesmo negócio.

São diferentes etapas da vida do dado.

E existe algo ainda mais importante.

Um Data Warehouse de última geração com dados ruins continua produzindo respostas ruins.

Um Data Lake de 50 petabytes sem catálogo continua sendo um pântano de 50 petabytes.

Um Data Mart rápido com definições incorretas continuará entregando rapidamente a resposta errada.

E colocar IA sobre tudo isso não resolve magicamente o problema.

Só permite errar em uma velocidade extraordinária.

Shiroe ajeita novamente os óculos:

Dados precisam de estratégia antes de precisarem de tecnologia.

O programador COBOL finalmente digita:

LOGOFF

Antes de desaparecer de Elder Tale, olha uma última vez para o mapa:

       TRANSAÇÃO
           |
           v
          DADO
           |
           v
       CONTEXTO
           |
           v
      INFORMAÇÃO
           |
           v
      CONHECIMENTO
           |
           v
        DECISÃO

Agora ele entende.

O Data Lake preserva.

O Data Warehouse organiza, integra e prepara para confiança analítica.

O Data Mart aproxima o dado de um domínio ou grupo de consumidores.

O Lakehouse procura combinar características antes separadas.

ETL e ELT determinam diferentes estratégias para movimentação e transformação.

Schema-on-Write e Schema-on-Read representam filosofias distintas de estruturação.

Star Schema ajuda a transformar eventos em perguntas de negócio.

Catálogo diz o que existe.

Lineage conta de onde veio.

Governança determina como aquilo pode ser utilizado.

E o mainframe?

O mainframe continua lá.

Processando milhões de transações enquanto todo mundo discute nomes novos para problemas que ele conhece há décadas.

Na saída da dungeon existe uma pequena inscrição.

Quase ninguém percebe.

O programador aproxima a lanterna e lê:

//SHIROE  JOB ...

//* --------------------------------------------
//* TODO DADO TEM UMA ORIGEM.
//* TODO NUMERO PRECISA DE CONTEXTO.
//* TODO DASHBOARD PRECISA DE CONFIANCA.
//*
//* E TODO PROGRAMADOR QUE ENCONTRAR
//* CLIENTES_FINAL_V7_FINAL_OK_AGORA_VAI.CSV
//* DEVE ABRIR UM INCIDENTE IMEDIATAMENTE.
//*
//* 03:17
//* --------------------------------------------

Ele ri.

Em algum lugar de Akiba, Shiroe também.

Fim da raid.

☕ Bellacosa Mainframe — porque modernizar não significa abandonar aquilo que funciona; significa compreender onde cada peça da arquitetura pertence.

domingo, 4 de outubro de 2020

✨🔮 Bellacosa Otaku Blog — Parte 28: Expressões de Magia, Feitiços e Poderes Fantásticos nos Animes 🔮✨

Bellacosa Mainframe e as expressoes de magia e feitiço em animes


✨🔮 Bellacosa Otaku Blog — Parte 28: Expressões de Magia, Feitiços e Poderes Fantásticos nos Animes 🔮✨


🪄 O idioma do impossível e do encantamento nos animes

(Versão Bellacosa: varinhas, grimórios, feitiços e a energia mágica que transforma mundos.)

Nos animes de fantasia, magia e poderes sobrenaturais, o japonês se torna uma linguagem mística, capaz de transmitir encantamentos, poderes e forças invisíveis.
Cada expressão cria atmosfera de fascínio, perigo e poder sobrenatural, tornando cada cena mágica inesquecível.
Vamos explorar as mais icônicas! ✨


🧙 1. 魔法 (mahō)

Tradução: “Magia / feitiço.”
👉 Palavra essencial em universos fantásticos para descrever poderes sobrenaturais.

📺 Anime vibe: Fairy Tail, Little Witch Academia, Mahou Shoujo Madoka Magica.
💬 Exemplo: “Mahō ativada! Prepare-se para o feitiço!” ✨


🔥 2. 呪文 (jumon)

Tradução: “Encantamento / feitiço verbal.”
👉 Usado para conjurar magias ou lançar ataques mágicos.

📺 Anime vibe: Little Witch Academia, Black Clover.
💬 Exemplo: “Jumon pronunciado! Fogo celestial, ataque!” 🔥


🌟 3. 精霊 (seirei)

Tradução: “Espírito / entidade mágica.”
👉 Criaturas mágicas ou forças sobrenaturais que auxiliam ou desafiam personagens.

📺 Anime vibe: Fairy Tail, Magi: The Labyrinth of Magic.
💬 Exemplo: “Seirei despertou! Nossa batalha começa!” 🌌


💫 4. 魔力 (maryoku)

Tradução: “Poder mágico / energia sobrenatural.”
👉 Representa a força que alimenta feitiços, encantamentos e habilidades.

📺 Anime vibe: Black Clover, Fairy Tail.
💬 Exemplo: “Maryoku máximo liberado! Nada poderá nos deter!” ⚡


🪄 5. 魔導書 (madousho)

Tradução: “Grimório / livro de magia.”
👉 Fonte de conhecimento mágico ou manual de feitiços.

📺 Anime vibe: Little Witch Academia, Black Clover.
💬 Exemplo: “Madousho aberto… hora de aprender um novo feitiço!” 📖


🧝 6. 召喚 (shoukan)

Tradução: “Invocação / convocação.”
👉 Chamar criaturas, espíritos ou entidades para auxílio mágico.

📺 Anime vibe: Fairy Tail, Fate/Stay Night.
💬 Exemplo: “Shoukan realizado! Venha, dragão guardião!” 🐉


✨ 7. 魔法陣 (mahōjin)

Tradução: “Círculo mágico / círculo de feitiço.”
👉 Símbolo usado para ativar encantamentos poderosos.

📺 Anime vibe: Black Clover, Little Witch Academia.
💬 Exemplo: “Mahōjin traçado! Feitiço final ativado!” 🔺


🔮 8. 呪い (noroi)

Tradução: “Maldição / feitiço maligno.”
👉 Palavra para magia negra ou efeitos sobrenaturais perigosos.

📺 Anime vibe: Jujutsu Kaisen, Fate/Stay Night.
💬 Exemplo: “Noroi lançado… cuidado com o efeito!” ☠️


🌈 9. 変身 (henshin)

Tradução: “Transformação / metamorfose.”
👉 Transformações mágicas ou físicas para ganhar poderes ou novas formas.

📺 Anime vibe: Mahou Shoujo Madoka Magica, Cardcaptor Sakura.
💬 Exemplo: “Henshin! O poder da heroína desperta!” ✨


🌌 10. 魔界 (makai)

Tradução: “Mundo demoníaco / reino mágico.”
👉 Referência a universos mágicos, infernais ou sobrenaturais.

📺 Anime vibe: Black Clover, Overlord.
💬 Exemplo: “Makai revelado… a batalha final está próxima!” 🌑


🏮 Curiosidades Bellacosa:

  • Palavras como mahō, maryoku e jumon são centrais em qualquer universo mágico e aparecem constantemente em combates e feitiços.

  • Termos de invocação e círculo mágico (shoukan, mahōjin) adicionam ritual e estética às cenas.

  • Conceitos de maldição, transformação e mundo sobrenatural (noroi, henshin, makai) criam tensão e fascínio, mantendo o espectador imerso. 🔮


🌟 Dica Bellacosa:

  • Observe gestos, efeitos visuais e incantamentos: eles amplificam o impacto da magia na cena.

  • Frases curtas e expressões mágicas (jumon, shoukan, henshin) carregam energia dramática e suspense.

  • Memorizar essas expressões ajuda a sentir a grandiosidade e o encanto dos mundos mágicos nos animes. ✨


🌸 Conclusão Bellacosa:

As expressões de magia e poderes fantásticos transformam o japonês em uma linguagem de feitiço, energia e imaginação sem limites.
Cada palavra, gesto ou símbolo transporta o espectador para mundos onde a fantasia se torna real e o impossível se materializa.

“Mahō, maryoku e shoukan… que a magia nos guie até o fim!” ✨🔮

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