Translate

domingo, 18 de dezembro de 2022

🔑🔑🔑 Level 37 e +1k de certificados 🔑🔑🔑 Vencendo a procrastinação e sendo resiliente

  

🔑🔑🔑 Level 37 e +1k de certificados 🔑🔑🔑 Vencendo a procrastinação e sendo resiliente

Bellacosa Mainframe e a evolução na DIO



Resiliência Grau Máximo

Salve jovem padawan, estamos na reta final de 2022 um ano cheio de glórias, onde o Sol voltou a brilhar e temos um lindo arco-íris sob o céu azul.

No alt text provided for this image


O artigo de hoje é mais um agradecimento, um momento de pura felicidade. Gratidão imensa as pessoas lendárias que trabalham na Digital Innovation One. Que dando um duro danado, liberam conteúdos fabulosos, cursos únicos e um apoio em nossa Comunidade, juntos estamos indo mais longe e somos bem fortes.

No ano em que nossa Comunidade ultrapassou um milhão de DEVs, também tive minhas vitórias, momentos únicos em nossa DIO, após os tenebrosos anos de 2020 e 2021, onde tantas coisas ruins aconteceram, em meio a pior pandemia de nossa existência, uma grande crise a muito não vista.

Momentos a esquecer.

Sendo sincero, jovem padawan, 2020 foi um péssimo ano, onde tive grandes perdas financeiras e fiquei sem rumo, numa nau a deriva quase indo a pique, perdido e entristecido, apenas vendo os dias passarem, esperando uma luz ao final do túnel, que não veio.

Chegamos a 2021, sem muitas perspectivas, no auge da Covid-19, mas da minha nau, vislumbrava lá longe, um belo horizonte, um porto seguro, onde poderia reparar minha nau e preparar novas aventuras, justamente foi isso que aconteceu, conheci a Digital Innovation One, onde me inscrevi e comecei modestamente a participar da plataforma, conhecendo a comunidade, fazendo amigos, descobrindo a mecânica e como ranquear em nossos desafios.

Com a nau reparada e com suprimentos, voltei a mar aberto, ainda em 2021 comecei a colher os frutos dos momentos investidos em nossa plataforma, recebi glórias e reconhecimentos, o Tiozão do Mainframe aprendeu muito e contribui ativamente com a nossa comunidade.

Porém o mar continuava turbulento e com alguma noticias ruins a caminho, ante de virarmos o ano, perdi meu pai, vitima de complicações do COVID-19, em luto dei adeus ao meu velho, lembrando lá trás no tempo, quando juntos íamos aos Fliperamas e peguei gosto pela computação e computadores, onde jurei que aprenderia a codificar para saber como eram feitos esses jogos irados.

Notícias boas, nau reparada e esquadra armada.

Rumo a novas aventuras com a chegada de 2022, um ano que a fênix renascida entrou a grande e a francesa, um ano único cheio de bons momentos, momentos a recordar e muitas alegrias e algumas dores e perdas.

Muitos e muitos cursos concluídos, novas metas, retorno ao mundo mainframe. Em Dezembro de 2022 conclui uma das minhas metas mais antigas na hashtagDIO. Conclui mais de 1000, atualmente estou em quase 1200 certificados na plataforma.

Publiquei inúmeros artigos e no primeiro semestre estive muito ativo na plataforma, onde conclui mais de meia centenas de bootcamps, após alguns meses de hiato, voltei no segundo semestre no mesmo pique.

Masterclass DIO Global

Um momento de muita alegria foi apresentar minha própria Masterclass, quebrando a quarta parede, inverti os papéis e pela primeira vez compartilhei com nossa comunidade minha experiencia profissional em videoaula.

Nesta masterclass falei sobre os anos áureos, quando expatriado vive na Europa e trabalhei em Portugal, Espanha e Itália, focado nos anos que passei em Portugal falei sobre os desafios, riscos e oportunidade de trabalhar fora e receber salario em moeda forte.

Community Week Game Press Start

Ainda no primeiro semestre fui convidado para um talk, aproveitei a oportunidade para falar de artigos, comunidade e evolução em nossa rede, foi uma tarde divertida, onde pude mais uma vez retribuir uma vez mais o conhecimento adquirido.

Community Week Talk

No segundo semestre novo convite e nova oportunidade, uma nova participação na CW22, onde pude falar um pouco sobre Desafios de Código, dando algumas dicas e truques para vencer os desafios e concluir mais rápido os bootcamps.

Conclusão

E com isso 2022 vai serrando as cortinas, nosso show está quase terminando e com 2023 as portas, temos muitas surpresas e momentos únicos se aproximando. A nossa comunidade com mais de um milhão de pessoas, unidas por um sonho comum, evoluindo com conteúdo de primeira qualidade, conhecimentos únicos, preparando-nos para os desafios do mercado de trabalho.

Gratidão sempre, muito obrigado a você pela amizade e carinho em todos os momentos. Obrigado a todos os profissionais da DIO que trabalham duro para nos ajudar no crescimento profissional, plantando sementinhas para o futuro, compartilhando o conhecimento e ajudando o próximo, ensino a pescar e dando o melhor em cada curso.

Não me canso de agradecer, muito, mas muito obrigado mesmo, Feliz Natal a Todos, Bom 2023, excelentes festas e que venham mais Bootcamps, Acelerações, Desafios e outras surpresas.

Forte abraço a todos.

hashtagDIO hashtagDIOnitos em Ação


CHAVE DE OURO

No alt text provided for this image

PS: Quem sabe consigo emplacar a ideia de um Bootcamp de IBM Mainframe


No alt text provided for this image


Indice com todos os 175 artigos publicados em nossa comunidade.

https://github.com/VagnerBellacosa/DIO_Bootcamps/blob/main/BootCamps/ArtigosDIO/

hashtagcommunityweekchallenge

hashtagCommunityWeek

hashtagDIO


Referência Bibliográfica

WIKIPEDIA - A Enciclopédia Livre, faça parte, ajude actualizando ou criando verbetes http://www.wikipedia.org

Google Books um repositório com milhões de livros digitalizados https://books.google.com/

Internet Archive, tudo aquilo que um dia foi publicado veio parar aqui. https://archive.org/

Biblioteca de ícones https://www.flaticon.com/

Um momento jaba, divulgando um video e o canal das aventuras do Tiozão, visite El Jefe Midnight Lunch. Memórias de minha estada na Itália, aproveitando o dia de Reis, um fabuloso cortejo dos Reis Magos visitando igrejas centenárias e conhecendo a história da religião cristã/católica. Um passeio único e cheio de momentos históricos, momento magico com o encontro dos Reis Magos rumo a manjedoura para entrega ouro, incenso e mirra ao bebê Jesus, numa das mais belas historias bíblicas. Um video para distrair na jornada: https://www.youtube.com/watch?v=G8ME9W2qxSs

https://www.linkedin.com/in/vagnerbellacosa/

https://github.com/VagnerBellacosa/

Pode me dar uma ajudinha no YouTube?

https://www.youtube.com/user/vagnerbellacosa


sexta-feira, 16 de dezembro de 2022

DIO AWARDS 2022 - Indicação Best Community Influencer

Fechando 2022, fui indicado para o DIO Awards 2022 Tech : Community Influencer, conto com sua ajuda, poderia votar em meu perfil. https://www.linkedin.com/posts/vagnerbellacosa_dionito-activity-7008882870224076800-hhTE Boas Festas!!!! Muito obrigado pela companhia, desejo um bom Natal e que 2023 seja o Ano, cheio de realizações e muito sucesso a nós todos. #Dionitos em ação

quinta-feira, 15 de dezembro de 2022

Dinkum : Quando um Programador COBOL Descobre que Administrar uma Ilha na Austrália Não É Muito Diferente de Administrar um Mainframe.

 

Bellacosa Mainframe apresenta dinkum

☕ Um Café no Bellacosa Mainframe

Dinkum sem Mistérios

Quando um Programador COBOL Descobre que Administrar uma Ilha na Austrália Não É Muito Diferente de Administrar um Mainframe... Tudo Funciona Melhor Quando Você Planeja, Automatiza e Faz Amigos

Existe uma curiosa tendência na indústria dos jogos.

Sempre que pensamos em simuladores de fazenda, imaginamos pequenas vilas europeias.

Campos verdes.

Celeiros vermelhos.

Florestas.

Montanhas.

Mas Dinkum resolveu perguntar algo diferente.

"E se toda essa experiência acontecesse no interior selvagem da Austrália?"

O resultado é um dos jogos mais carismáticos dos últimos anos.

Misturando Animal Crossing, Stardew Valley, Minecraft, Harvest Moon e um pouco de sobrevivência, Dinkum cria um mundo onde a maior aventura não é derrotar um dragão.

É construir uma comunidade inteira.

Para um programador COBOL isso lembra aqueles projetos que começam com apenas um terminal 3270.

Poucos usuários.

Poucos programas.

Poucos arquivos.

Anos depois...

O pequeno sistema tornou-se um ambiente corporativo completo.

É exatamente essa sensação que Dinkum proporciona.

Pegue sua caneca de café.

Hoje vamos conhecer uma das maiores surpresas dos jogos independentes.


A origem

Dinkum foi criado praticamente por uma única pessoa.

O desenvolvedor australiano James Bendon passou anos desenvolvendo o projeto sozinho, inspirado pelo estilo relaxante de jogos como Animal Crossing, mas desejando criar uma experiência mais aberta, com liberdade para construir cidades, explorar e sobreviver. O jogo entrou em Acesso Antecipado (Early Access) para PC em 14 de julho de 2022, sendo publicado pela KRAFTON. Desde então, recebe atualizações frequentes com novos conteúdos, animais, eventos e melhorias. (store.steampowered.com, )


O estúdio

Na verdade...

Não existia um grande estúdio.

Inicialmente era apenas James Bendon.

Isso torna o projeto ainda mais impressionante.

Criar sozinho:

  • programação;

  • design;

  • mecânicas;

  • economia;

  • exploração;

  • IA;

  • agricultura;

  • pesca.

É praticamente construir um ERP inteiro sem equipe.


O cenário

Ao contrário da maioria dos simuladores.

Dinkum acontece inspirado na natureza australiana.

Você encontra:

  • eucaliptos;

  • desertos;

  • rios;

  • praias;

  • manguezais;

  • savanas.

Tudo inspirado no Outback australiano.


A história

Você chega em uma ilha praticamente desabitada.

Poucas construções.

Poucos moradores.

Quase nenhuma infraestrutura.

Seu objetivo?

Transformar aquele lugar em uma cidade vibrante.

Sem pressão.

Sem cronômetros.

Sem urgência.


O verdadeiro objetivo

Curiosamente...

Também não existe.

Você decide.

Pode passar semanas:

  • pescando;

  • minerando;

  • caçando;

  • construindo;

  • decorando;

  • explorando.

É você quem define o ritmo.


A jogabilidade

O ciclo lembra um projeto DevOps muito bem organizado.

Explorar

↓

Coletar Recursos

↓

Construir

↓

Atrair Novos Moradores

↓

Expandir Cidade

↓

Automatizar Produção

↓

Melhorar Equipamentos

↓

Explorar Novamente

É simples.

Mas extremamente viciante.


Construção da cidade

Aqui mora uma das maiores diferenças.

Você não administra apenas uma fazenda.

Você administra uma cidade inteira.

Decide:

  • localização das casas;

  • comércio;

  • ruas;

  • jardins;

  • pontes;

  • iluminação.

É quase um SimCity relaxante.


Agricultura

Existe um excelente sistema agrícola.

Você cultiva:

  • frutas;

  • legumes;

  • árvores;

  • flores.

Tudo ajuda na economia.


Criação de animais

Você cria:

  • galinhas;

  • vombates;

  • animais típicos inspirados na fauna australiana.

Cada um produz recursos diferentes.


Exploração

O mapa é enorme.

Você encontra:

  • cavernas;

  • desertos;

  • ilhas;

  • rios;

  • minas;

  • praias.

Sempre existe algo novo.


Mineração

Assim como Minecraft.

Você procura:

  • cobre;

  • ferro;

  • estanho;

  • ouro;

  • opalas.

Quanto melhores os minérios...

Melhores as ferramentas.


Pesca

A pesca é extremamente divertida.

Existem dezenas de espécies.

Algumas aparecem apenas:

  • em determinadas estações;

  • durante chuva;

  • em horários específicos.


Caça

Diferentemente de Stardew Valley.

Aqui existem animais perigosos.

Você enfrenta:

  • crocodilos;

  • tubarões;

  • cassowaries;

  • morcegos gigantes;

  • outros animais inspirados na fauna australiana.

Isso adiciona bastante aventura.


O combate

Não é o foco principal.

Mas existe.

Você utiliza:

  • lanças;

  • espadas;

  • martelos;

  • bastões;

  • armas de longo alcance.

É suficiente para tornar a exploração emocionante.


Craft

Grande parte do progresso depende da fabricação.

Você produz:

  • móveis;

  • ferramentas;

  • veículos;

  • cercas;

  • pontes;

  • máquinas.

Sempre existe algo novo para construir.


Veículos

Uma das partes mais legais.

Você pode utilizar:

  • barcos;

  • motocicletas;

  • tratores;

  • jet skis;

  • helicópteros (em estágios avançados).

A mobilidade cresce conforme a cidade evolui.


Economia

Você vende praticamente tudo.

Peixes.

Insetos.

Frutas.

Minérios.

Madeira.

Com o dinheiro compra novos projetos para expandir a cidade.


Multiplayer

Até quatro jogadores podem compartilhar a mesma ilha.

Cada pessoa ajuda:

  • construir;

  • cultivar;

  • explorar;

  • minerar;

  • decorar.

A cooperação funciona muito bem.


Curiosidades

  • A inspiração na Austrália vai muito além da estética: animais, vegetação, clima e até algumas expressões refletem a cultura local.

  • O jogo conquistou uma comunidade bastante ativa durante o Early Access, influenciando várias atualizações.

  • Apesar das comparações com Animal Crossing, Dinkum incorpora exploração e sobrevivência de forma muito mais intensa.


Easter Eggs

A ilha está repleta de pequenos segredos.

Você encontra:

  • ilhas escondidas;

  • baús;

  • objetos raros;

  • eventos sazonais;

  • NPCs especiais;

  • referências discretas à cultura australiana.

Grande parte deles depende apenas da exploração.


Os riscos

O maior risco...

É pensar:

"Vou só reorganizar minha cidade."

Três horas depois...

Você está redesenhando todas as ruas.

Outro risco.

Sair sem comida.

Ou enfrentar crocodilos despreparado.

Eles não costumam negociar.


As vantagens

Dinkum oferece praticamente tudo.

✔ agricultura

✔ cidade

✔ exploração

✔ mineração

✔ pesca

✔ construção

✔ multiplayer

✔ combate leve

Sem:

❌ gacha

❌ loot boxes

❌ energia limitada

❌ microtransações invasivas

Você compra.

Instala.

Joga.

No seu ritmo.


A diversão

Cada dia parece diferente.

Hoje você:

Constrói uma ponte.

Amanhã.

Captura um inseto raro.

Depois.

Compra uma motocicleta.

Na semana seguinte.

Recebe um novo morador.

É impossível ficar parado.


O Caminho do Padawan

Se está começando...

Faça assim.

✔ construa ferramentas melhores;

✔ colete madeira diariamente;

✔ plante cedo;

✔ pesque sempre;

✔ economize dinheiro;

✔ organize sua cidade;

✔ visite minas regularmente;

✔ não enfrente crocodilos cedo demais.

No Bellacosa Mainframe existe uma regra parecida.

"Nunca reorganize toda a biblioteca PROD antes de entender quem usa cada programa."


Requisitos para PC

Mínimos:

  • Windows 10 (64 bits)

  • Intel Core i3 ou equivalente

  • 8 GB de RAM

  • NVIDIA GTX 760 / AMD Radeon equivalente

  • Cerca de 2 GB de espaço livre

Recomendados:

  • Intel Core i5 ou AMD Ryzen equivalente

  • 16 GB de RAM

  • NVIDIA GTX 1060 ou superior

Mesmo em máquinas intermediárias, Dinkum costuma apresentar excelente desempenho devido ao estilo gráfico estilizado e à boa otimização. (store.steampowered.com)


Tipo de instalação

É um jogo premium.

Compra única.

Instalação digital.

Atualmente está disponível para Windows (desktop) através da Steam, permanecendo em desenvolvimento contínuo durante o período de Early Access. (store.steampowered.com)


Custo

O preço oficial gira em torno de US$ 19,99, variando conforme promoções e a região da Steam. Em grandes liquidações, costuma receber descontos significativos.


Classificação

  • Gênero: Simulação de vida, construção de cidade, agricultura, exploração, sobrevivência leve e RPG.

  • Modo: Um jogador e cooperativo online (até quatro jogadores).

  • Classificação indicativa: geralmente E10+ / Livre para maiores de 10 anos, dependendo da região, por conter violência leve e temas de fantasia.


Site oficial

Para acompanhar novidades e atualizações:


Curiosidade para Programadores COBOL

Se Stardew Valley lembra um sistema administrativo...

Outward parece um ambiente crítico de produção...

Core Keeper é um enorme banco de dados subterrâneo...

Então Dinkum representa perfeitamente a evolução de uma empresa.

Primeiro existe apenas uma pequena instalação.

Depois chegam os usuários.

Depois os serviços.

As integrações.

As estradas.

Os processos.

Os novos departamentos.

Quando você percebe...

A pequena vila tornou-se uma cidade inteira.

Assim também evoluem muitos ambientes IBM Z.

Um módulo por vez.

Um usuário por vez.

Uma melhoria por vez.


Conclusão

Dinkum mostra que grandes aventuras não precisam acontecer em reinos medievais ou galáxias distantes. Às vezes, basta uma ilha inspirada na Austrália, um punhado de ferramentas e liberdade para construir algo único.

Sob a perspectiva do Bellacosa Mainframe, ele lembra a implantação de um ambiente corporativo sólido: começa pequeno, cresce com planejamento, ganha novos serviços, novos usuários e novas possibilidades sem perder a estabilidade.

Sua maior mensagem é inspiradora.

Toda grande cidade começou como um pequeno terreno vazio.

Todo grande sistema começou como um único programa.

E toda grande aventura começa quando alguém decide dar o primeiro passo... mesmo sem saber exatamente onde a estrada termina.

sábado, 3 de dezembro de 2022

IBM MQ vs Kafka : Quando um Programador Descobre que Voltar no Tempo é Fácil no DeLorean..

 

Bellacosa Mainframe e uma comparação ibm mq versus kafka

☕ Um Café no Bellacosa Mainframe

IBM MQ vs Kafka sem Mistérios para Programadores COBOL

Quando um Programador Descobre que Voltar no Tempo é Fácil no DeLorean... Difícil Mesmo é Dar Rollback em uma Transação Bancária

"Estradas? Para onde vamos, não precisamos de estradas." — Doc Brown

No universo Bellacosa Mainframe, porém, Doc Brown provavelmente corrigiria sua famosa frase:

"Mensagens? Para onde vamos, não precisamos apenas de mensagens. Precisamos de COMMIT."

Porque existe uma enorme diferença entre viajar pelo tempo e viajar com dados corporativos.

Um erro temporal pode fazer Marty McFly apagar sua própria existência.

Um erro numa transação bancária pode fazer desaparecer milhões de reais.

E é justamente aqui que entram dois dos maiores protagonistas da arquitetura moderna:

IBM MQ e Apache Kafka.

Embora muita gente os coloque no mesmo ringue, como se fossem dois boxeadores disputando o cinturão mundial da mensageria, a verdade é outra.

Eles nasceram para resolver problemas completamente diferentes.

Hoje vamos embarcar no DeLorean do Bellacosa Mainframe para visitar quarenta anos de evolução dos sistemas distribuídos e descobrir por que o IBM MQ continua sendo uma das tecnologias mais importantes do planeta para sistemas críticos.

Aperte o cinto.

Configure o Flux Capacitor para 88 mph.

E cuidado para não provocar um ABEND em 1955.


1985: O primeiro salto temporal

Imagine Marty chegando em Hill Valley.

Ele altera um pequeno evento.

Resultado?

Toda a linha do tempo muda.

Nos computadores acontece exatamente a mesma coisa.

Imagine um banco executando uma transferência.

  1. Debita R$ 10.000 da conta A.

  2. Cai a energia.

  3. Nunca credita a conta B.

Parabéns.

Você acabou de criar uma linha temporal alternativa.

No universo do COBOL isso recebe outro nome:

Estado inconsistente.

É exatamente para impedir esse tipo de paradoxo que existem as transações.


O verdadeiro Flux Capacitor chama-se COMMIT

No filme, o Flux Capacitor garante que Marty chegue inteiro ao passado.

Nos sistemas corporativos existe um equivalente.

Ele chama-se:

COMMIT.

Enquanto o COMMIT não acontece...

Nada realmente existe.

É como se todo o processamento estivesse preso num universo paralelo.

Somente quando o commit é confirmado, aquela realidade passa oficialmente a existir.


Se o COMMIT nunca acontecer...

Imagine Doc Brown ligando o DeLorean.

A viagem começa.

Mas o capacitor falha.

Resultado?

A viagem inteira é cancelada.

É exatamente isso que um rollback faz.

Tudo volta ao estado anterior.

Como se nada tivesse acontecido.


IBM MQ nasceu para impedir paradoxos temporais

Quando a IBM criou o MQSeries (hoje IBM MQ), o objetivo nunca foi ser o software mais rápido do planeta.

O objetivo era outro.

Nunca perder uma mensagem.

Existe uma enorme diferença.

Velocidade é importante.

Confiabilidade é indispensável.


Kafka nasceu em outro universo

Apache Kafka surgiu décadas depois.

O problema era completamente diferente.

LinkedIn precisava registrar:

Bilhões de cliques.

Bilhões de visualizações.

Logs.

Eventos.

Métricas.

Streaming.

Analytics.

Machine Learning.

Não importava se um clique perdido acontecesse ocasionalmente.

O importante era processar milhões por segundo.


A analogia do DeLorean

Imagine dois veículos.

O DeLorean

Transporta uma única missão extremamente importante.

Não pode falhar.

É o IBM MQ.


Um trem-bala japonês

Transporta milhares de passageiros continuamente.

É o Kafka.


Os dois são excelentes.

Mas para objetivos completamente diferentes.


O problema da viagem temporal distribuída

Agora imagine uma viagem muito mais complicada.

Marty precisa alterar cinco épocas diferentes simultaneamente.

1985 Alternativo.

Todas precisam terminar corretamente.

Ou nenhuma pode acontecer.

É exatamente isso que faz uma transação distribuída.


XA Transaction

XA é uma especificação criada para coordenar vários recursos diferentes.

Imagine uma orquestra.

Cada músico representa um sistema.

Db2.

Oracle.

IBM MQ.

IMS.

JMS.

Todos precisam tocar exatamente a mesma música.

No mesmo instante.

Se um violinista errar...

Toda a apresentação para.


Two Phase Commit

Aqui aparece o verdadeiro maestro.

O Transaction Manager.

Ele faz duas perguntas.


Primeira fase

"Todos estão preparados?"

Db2

— Sim.

MQ

— Sim.

Oracle

— Sim.

Ninguém grava nada ainda.

Todos apenas levantam a mão.


Segunda fase

O maestro pergunta novamente.

"Posso executar?"

Agora todos respondem.

Sim.

Somente agora tudo é gravado.

Ou...

Caso alguém responda NÃO...

Todos desfazem absolutamente tudo.


Easter Egg nº 1

No filme, Doc Brown nunca aperta o acelerador antes de conferir o Flux Capacitor.

No mundo corporativo, um arquiteto nunca faz COMMIT antes de verificar se todos os recursos responderam "Prepare".


Porque isso importa?

Imagine pagar um boleto.

A aplicação faz:

Atualiza Db2

Envia mensagem MQ

Atualiza saldo

Gera comprovante

Envia SMS

Atualiza limite

Agora imagine que o servidor reinicie exatamente entre o passo três e quatro.

Sem XA...

Você pode ter:

Dinheiro debitado.

Sem comprovante.

Sem mensagem.

Sem auditoria.

Um pesadelo.


IBM MQ resolve isso elegantemente

Quando o MQ participa de uma transação XA, ele espera o Transaction Manager.

Nada é entregue definitivamente.

Nada desaparece.

Tudo permanece consistente.


Persistent Message

Uma das maiores forças do IBM MQ.

Existem dois tipos de mensagens.

Persistent.

Non Persistent.


Persistent

Antes de responder:

"Mensagem recebida."

O Queue Manager grava tudo em disco.

Mesmo que falte energia.

Mesmo que o servidor exploda.

Mesmo que haja reboot.

A mensagem continua lá.


Curiosidade

Essa característica fez do MQ um dos pilares dos bancos durante décadas.

Enquanto aplicações inteiras eram reiniciadas...

As filas permaneciam intactas.


Rollback

Agora vem uma das maiores mágicas do processamento transacional.

Imagine escrever um cheque.

Assinar.

Carimbar.

Guardar.

Depois descobrir que o saldo é insuficiente.

Rollback significa destruir completamente aquela operação.

Como se ela jamais tivesse existido.


Marty McFly e o Rollback

No primeiro filme, Marty começa a desaparecer da fotografia.

Felizmente consegue corrigir a linha temporal.

No mundo do IBM MQ isso acontece automaticamente.

Rollback restaura a fotografia original.


Kafka pensa diferente

Kafka trabalha com outro paradigma.

Eventos.

Streaming.

Replay.

Histórico.

Retenção.

Consumidores independentes.

É quase uma máquina do tempo.

Os eventos ficam armazenados por dias, semanas ou meses.

Você pode voltar e "reassistir" os acontecimentos.

Essa é uma diferença fascinante.

MQ normalmente preocupa-se com entregar a mensagem.

Kafka preocupa-se também em preservar o histórico de eventos para que consumidores possam relê-los.


Throughput

Throughput significa capacidade de processamento.

Imagine duas rodovias.

Rodovia A.

Passam cem caminhões por minuto.

Rodovia B.

Passam cem mil carros por minuto.

Kafka foi projetado para a segunda situação.


IBM MQ prefere outra pergunta

Não pergunta:

"Quantas mensagens?"

Pergunta:

"Quantas mensagens chegaram corretamente?"

Essa diferença muda completamente a arquitetura.


Exactly Once

Esse termo gera muita confusão.

Existem três possibilidades.

At Most Once

Pode perder.

Nunca duplica.


At Least Once

Nunca perde.

Pode duplicar.


Exactly Once

Nem perde.

Nem duplica.

No IBM MQ isso é obtido por sessões transacionais e commit/rollback.

No Kafka, há recursos de exatamente uma vez dentro do ecossistema Kafka (produtores idempotentes, transações e Kafka Streams), mas quando entram bancos de dados e outros sistemas externos, normalmente usam-se padrões como Transactional Outbox, CDC e Saga, em vez de XA distribuído.


MongoDB

Existe uma observação muito interessante.

MongoDB suporta transações internas.

Mas não participa do padrão XA tradicional.

Por isso arquiteturas modernas normalmente utilizam:

Transactional Outbox.

CDC.

Saga Pattern.

Compensating Transactions.

Tudo isso substitui o velho Two Phase Commit quando múltiplos recursos heterogêneos estão envolvidos.


Alta Disponibilidade

Imagine Hill Valley sendo atingida por um raio.

Mesmo assim.

O sistema continua funcionando.

IBM MQ possui recursos empresariais como:

Multi Instance Queue Manager.

HA.

Disaster Recovery.

Logs.

Journal.

Replicação.

Failover.

No z/OS pode integrar-se ao Parallel Sysplex para disponibilidade extraordinária.


Disaster Recovery

Imagine perder um Data Center inteiro.

Mesmo assim.

As mensagens continuam existindo.

É exatamente isso que faz o Journal do MQ.


Easter Egg nº 2

No filme existe uma torre do relógio.

Ela registra um instante histórico.

No IBM MQ existe o Journal.

Ele registra cada passo importante da vida das mensagens.


JMS

Muitos iniciantes confundem.

JMS NÃO é um broker.

JMS é uma API.

Ela permite que aplicações Java conversem com IBM MQ, ActiveMQ, Artemis e outros provedores de mensageria sem ficarem presas a uma implementação específica.


Spring Boot

Hoje é extremamente comum encontrar:

Spring Boot

IBM MQ

Db2

@Transactional

JTA

Tudo trabalhando junto.

Uma única anotação Java coordena diversos recursos corporativos.

É como Doc Brown sincronizando todos os relógios de Hill Valley.


Onde cada tecnologia vence?

Imagine um banco digital.

Cliente faz PIX.

COBOL no CICS processa.

Db2 grava.

IBM MQ garante entrega.

Kafka distribui eventos.

Machine Learning detecta fraude.

Dashboard atualiza em tempo real.

Percebe?

Nenhuma tecnologia substitui completamente a outra.

Elas cooperam.


Curiosidade histórica

O IBM MQ surgiu como MQSeries, em 1993, para facilitar a comunicação confiável entre aplicações distribuídas em diferentes plataformas. Ao longo das décadas evoluiu para integrar z/OS, AIX, Linux, Windows e ambientes em nuvem, mantendo como principal característica a confiabilidade.

O Apache Kafka nasceu no LinkedIn e foi aberto como projeto da Apache Foundation em 2011. Sua proposta revolucionou o processamento de eventos em larga escala, tornando-se um dos pilares das arquiteturas orientadas a eventos modernas.

São tecnologias de épocas diferentes, criadas para resolver dores diferentes.


Dicas para o Padawan COBOL

Se você está começando no mundo mainframe, siga esta ordem de estudos:

  1. Entenda primeiro o conceito de transação e por que ela existe.

  2. Aprenda os fundamentos de COMMIT e ROLLBACK em Db2 e CICS.

  3. Estude o funcionamento de uma Queue, incluindo mensagens persistentes e não persistentes.

  4. Pratique o envio e recebimento de mensagens com IBM MQ em programas COBOL ou Java.

  5. Compreenda como JMS abstrai o acesso ao MQ em aplicações Java.

  6. Só depois mergulhe em Kafka, Event Streaming, CDC, Outbox e Saga. Você entenderá muito melhor quando conhecer primeiro a base transacional.


O que um arquiteto experiente realmente pergunta?

O iniciante pergunta:

"Qual tecnologia é melhor?"

O arquiteto pergunta:

"Qual problema estou tentando resolver?"

Se o problema é transmitir milhões de eventos para dezenas de consumidores independentes, Kafka provavelmente será a escolha natural.

Se o problema é garantir que uma transferência financeira de R$ 500.000,00 nunca fique pela metade, IBM MQ é uma das respostas mais sólidas já criadas.

Essa mudança de perspectiva separa quem conhece ferramentas de quem entende arquitetura.


O Grande Ensinamento do Dr. Emmett Brown

No final de De Volta para o Futuro, Doc Brown aprende que pequenas mudanças podem alterar completamente a história.

Nos sistemas corporativos acontece exatamente o mesmo.

Uma única mensagem perdida pode gerar:

  • um pagamento duplicado;

  • uma conta inconsistente;

  • um pedido entregue duas vezes;

  • uma reserva aérea inexistente;

  • um prejuízo milionário.

É por isso que bancos, seguradoras, bolsas de valores e governos continuam investindo em tecnologias como IBM MQ mesmo décadas após sua criação.

No Bellacosa Mainframe, existe uma máxima que todo Padawan COBOL deveria gravar como se fosse escrita na lateral do próprio DeLorean:

"Velocidade impressiona. Escalabilidade encanta. Mas é a consistência que mantém a máquina do tempo da empresa funcionando sem criar paradoxos financeiros."

E talvez esse seja o maior segredo da computação corporativa.

No cinema, Doc Brown precisava de 1,21 gigawatts para viajar no tempo.

No mundo dos mainframes, um arquiteto experiente precisa apenas de quatro palavras para evitar um desastre que poderia alterar a história inteira de uma empresa:

COMMIT. ROLLBACK. MQ. CONSISTÊNCIA.


sexta-feira, 2 de dezembro de 2022

KAWAII DAKE JA NAI SHIKIMORI-SAN — O ANIME ONDE O FIREWALL MAIS PODEROSO DO MUNDO USA SAIA ESCOLAR E PROTEGE UM USUÁRIO COM AZAR CRÔNICO

 

Bellacosa Mainframe e kawaii dake ja nai shikimori san

☕💣💕 OPERADOR, O SISTEMA DE PROTEÇÃO AUTOMÁTICA ENTROU EM PRODUÇÃO!

KAWAII DAKE JA NAI SHIKIMORI-SAN — O ANIME ONDE O FIREWALL MAIS PODEROSO DO MUNDO USA SAIA ESCOLAR E PROTEGE UM USUÁRIO COM AZAR CRÔNICO


📋 Ficha Técnica

Título Original: 可愛いだけじゃない式守さん
Romanização: Kawaii dake ja Nai Shikimori-san
Título Internacional: Shikimori's Not Just a Cutie

Autor: Keigo Maki

Mangá:

  • Início: Fevereiro de 2019

  • Fim: Fevereiro de 2023

  • Total: 20 volumes

Anime:

  • Estreia: 10 de abril de 2022

  • Episódios: 12

  • Estúdio: Doga Kobo

Gêneros:

  • Romance

  • Comédia Romântica

  • Slice of Life

  • Escolar

Classificação Indicativa:

  • Aproximadamente 12 anos


☕ O QUE ACONTECE NESTA HISTÓRIA?

Imagine um ambiente corporativo onde existe um usuário tão azarado que qualquer operação simples gera incidentes.

Ele atravessa a rua.

Quase é atropelado.

Abre uma porta.

Algo cai na cabeça dele.

Vai passear.

Uma sequência de eventos improváveis transforma um simples domingo em um desastre operacional.

Esse usuário é:

🍀 Yuuki Izumi

O homem mais azarado da sua geração.

Mas existe um sistema de contingência.

Uma solução de alta disponibilidade.

Uma proteção em tempo real.

💕 Miyako Shikimori

Sua namorada.

Quando necessário, ela abandona instantaneamente o modo "fofa" e ativa o modo:

😎 ABSOLUTE CHAD MODE

Ela protege Izumi de acidentes, perigos, situações constrangedoras e praticamente das leis da probabilidade.

Daí nasce o título:

Ela não é apenas fofa.


🏢 O ESTÚDIO DOGA KOBO

Se existe um estúdio especializado em produzir conforto emocional, é o Doga Kobo.

Eles também produziram:

  • New Game!

  • Plastic Memories

  • Oshi no Ko

  • Yuru Yuri

O estúdio ficou famoso por transformar histórias simples em experiências extremamente agradáveis de assistir.

Em Shikimori-san isso aparece claramente:

  • cores suaves;

  • animação limpa;

  • excelente direção facial;

  • foco em expressões;

  • atmosfera acolhedora.

A produção não tenta impressionar pela ação.

Ela tenta criar conexão emocional.


🎭 O QUE TORNA SHIKIMORI DIFERENTE?

Aqui está a grande inovação.


1️⃣ O ROMANCE JÁ COMEÇOU

Grande parte dos romances japoneses segue a fórmula:

  • garoto conhece garota;

  • confusão;

  • mal-entendidos;

  • 3 temporadas;

  • confissão final.

Shikimori pula tudo isso.

O casal já está junto desde o início.

O anime responde uma pergunta raramente explorada:

"O que acontece depois que o casal finalmente começa a namorar?"


2️⃣ INVERSÃO DOS PAPÉIS CLÁSSICOS

Normalmente:

  • garoto protege garota.

Aqui:

  • garota protege garoto.

Mas sem humilhar Izumi.

Esse detalhe é importante.

O anime evita transformar o protagonista em piada.

Ele continua sendo gentil, corajoso e emocionalmente maduro.


3️⃣ O VERDADEIRO PODER É A EMPATIA

Não existe:

  • magia;

  • superpoderes;

  • mechas;

  • isekai;

  • torneios.

O poder da história é:

cuidado genuíno.

Algo cada vez mais raro na ficção moderna.


👥 PERSONAGENS PRINCIPAIS

💕 Miyako Shikimori

A protagonista.

Mistura:

  • delicadeza;

  • confiança;

  • força emocional;

  • carisma.

Ela alterna entre:

Modo Cute

😊

e

Modo Cool

😎

em questão de segundos.

Essa dualidade virou um dos maiores atrativos da obra.


🍀 Yuuki Izumi

O azar ambulante.

Mas existe algo interessante.

Seu azar não o tornou amargo.

Ele continua otimista.

É uma mensagem poderosa:

circunstâncias ruins não precisam definir quem você é.


🐱 Nekozaki

Energia pura.

Representa a amizade espontânea.


🍯 Hachimitsu

Especialista em comentários secos.

Rouba cenas constantemente.


🐶 Inuzuka

Melhor amigo de Izumi.

Leal e confiável.


🔍 AS MENSAGENS OCULTAS

Aqui a obra fica mais interessante do que parece.

Muita gente vê apenas uma romcom.

Mas existem várias camadas escondidas.


A MALDIÇÃO DO AZAR

O azar de Izumi funciona quase como metáfora.

Ele representa pessoas que cresceram acreditando:

  • "sou problemático"

  • "só dou trabalho"

  • "as coisas dão errado comigo"

Shikimori simboliza alguém que enxerga valor mesmo quando a pessoa não enxerga em si mesma.


O AMOR COMO SUPORTE E NÃO COMO SALVAÇÃO

Um detalhe muito saudável.

Shikimori não "conserta" Izumi.

Ela o apoia.

Isso é muito diferente.

O anime evita a ideia tóxica de que um relacionamento resolve todos os problemas.


A FORÇA FEMININA SEM AGRESSIVIDADE

Muitas obras mostram personagens femininas fortes através da violência.

Shikimori mostra outra abordagem.

Ela é forte porque:

  • é confiante;

  • toma iniciativa;

  • cuida dos outros;

  • assume responsabilidades.


🎒 AS AVENTURAS

Não existem grandes guerras.

As aventuras são cotidianas:

  • festivais escolares;

  • encontros;

  • passeios;

  • atividades esportivas;

  • viagens;

  • eventos de classe.

Mas é justamente isso que cria identificação.

Todos já viveram algo parecido.

O anime transforma momentos comuns em memórias especiais.


🌸 O CONCEITO JAPONÊS ESCONDIDO

Existe uma forte influência do conceito japonês:

"Iyashi"

癒し

Significa:

  • cura emocional;

  • tranquilidade;

  • conforto psicológico.

Shikimori pertence parcialmente à categoria dos chamados:

Iyashikei Romances

Obras feitas para relaxar o espectador.

Não para deixá-lo ansioso.


🌎 IMPACTO CULTURAL

Quando estreou, a recepção foi curiosa.

Muitos espectadores esperavam:

  • outra Nagatoro;

  • outra Marin Kitagawa;

  • outra Komi.

Receberam algo completamente diferente.

Isso gerou críticas iniciais.

Mas com o tempo o anime ganhou reconhecimento por sua proposta única.

Hoje é frequentemente lembrado como um dos romances mais confortáveis da década de 2020.


🚫 HOUVE CENSURA?

Não houve censura relevante.

A obra sempre foi considerada extremamente leve.

Não possui:

  • violência gráfica;

  • fanservice pesado;

  • conteúdo controverso.

Seu foco sempre esteve nos relacionamentos.


🧠 A LEITURA BELLACOSA MAINFRAME

Agora vem a interpretação de operador.


Izumi = JOB COM ERROS INTERMITENTES

Nada parece funcionar.

Toda execução produz um incidente novo.


Shikimori = SISTEMA DE RECOVERY AUTOMÁTICO

Detecta problemas.

Corrige falhas.

Evita abends.

Restaura estabilidade.


Amigos = EQUIPE DE SUPORTE

Monitoram o ambiente.

Prestam assistência.

Mantêm a operação saudável.


O Romance = ALTA DISPONIBILIDADE

Não é sobre evitar falhas.

É sobre continuar funcionando apesar delas.


🎯 CONCLUSÃO

Kawaii dake ja Nai Shikimori-san parece uma simples comédia romântica escolar.

Mas por trás da aparência existe uma história sobre:

  • apoio emocional;

  • aceitação;

  • amadurecimento;

  • amizade;

  • relacionamentos saudáveis.

Enquanto muitos animes tentam impressionar com explosões, poderes e reviravoltas, Shikimori faz algo muito mais difícil:

transforma gentileza em entretenimento.

E talvez essa seja a verdadeira mensagem da obra.

No fim, todos nós somos um pouco como Izumi.

Sistemas cheios de falhas inesperadas.

E todos gostaríamos de encontrar uma Shikimori na vida:

alguém que conheça nossos bugs, nossos logs de erro e nossos abends... e mesmo assim escolha continuar ao nosso lado em produção. ☕💣💕


quinta-feira, 1 de dezembro de 2022

NANORI — O SUBSISTEMA SECRETO DOS KANJIS QUE FAZ ATÉ JAPONESES NATIVOS CONSULTAREM O MANUAL DE OPERAÇÃO

 

Bellacosa Mainframe e a nanori a dificil questão dos sobrenomes japoneses

☕💣📛 OPERADOR, O CATÁLOGO DE NOMES DO JAPÃO ACABA DE EXECUTAR UM JOB COM LEITURAS NÃO DOCUMENTADAS!

NANORI — O SUBSISTEMA SECRETO DOS KANJIS QUE FAZ ATÉ JAPONESES NATIVOS CONSULTAREM O MANUAL DE OPERAÇÃO

Quando alguém começa a estudar japonês, acredita que o sistema é relativamente simples. Aprende hiragana, katakana, depois descobre os kanjis e finalmente encontra as famosas leituras on'yomi e kun'yomi.

Nesse momento o operador acredita que já entendeu a arquitetura do sistema.

Mas então surge um personagem de anime, um político, um samurai histórico ou uma idol japonesa cujo nome é escrito com kanjis aparentemente comuns...

...e pronunciado de uma forma que parece não ter qualquer relação lógica com eles.

É nesse instante que o sistema emite:

IEF451I UNKNOWN READING DETECTED

Bem-vindo ao mundo do Nanori (名乗り).

O nanori é provavelmente uma das partes mais fascinantes, misteriosas e culturalmente profundas da língua japonesa.

E também uma das que mais confundem estudantes estrangeiros.


O QUE É NANORI?

De forma simples, nanori são leituras especiais de kanji utilizadas em nomes próprios.

A palavra vem de:

名 (na)
Nome

乗り (nori)
Declarar ou apresentar

Originalmente, nanori significava algo semelhante a:

"o nome pelo qual alguém se apresenta".

Com o passar dos séculos, passou a designar as leituras específicas usadas em nomes pessoais.

Em linguagem de mainframe:

Se o kanji fosse um programa COBOL, as leituras normais seriam as APIs oficialmente documentadas.

O nanori seria uma rotina interna herdada de uma versão de 800 anos atrás que ainda funciona em produção porque ninguém tem coragem de removê-la.


O PROBLEMA QUE O NANORI RESOLVE

Imagine que você tem o kanji:

Normalmente:

  • yama

  • san

Tudo certo.

Mas quando ele aparece em um sobrenome, pode assumir comportamentos diferentes.

Por exemplo:

山田

A maioria dos estudantes aprende:

Yama + ta

Mas o nome é:

Yamada

Até aí tudo bem.

Porém o Japão acumulou mais de mil anos de tradição familiar.

Cada clã, região e linhagem começou a usar leituras próprias.

O resultado foi um gigantesco banco de dados de exceções.


O MAINFRAME CULTURAL DO JAPÃO

Para entender o nanori, precisamos compreender algo importante.

O Japão valoriza profundamente:

  • ancestralidade

  • linhagem familiar

  • tradição regional

  • herança histórica

Durante séculos, famílias nobres mantiveram determinadas leituras exclusivas.

Essas leituras eram transmitidas como verdadeiros ativos culturais.

Em termos de TI:

O nome era uma espécie de certificado digital familiar.

Trocar a leitura seria quase como alterar a chave mestra do RACF de um sistema centenário.


ON'YOMI, KUN'YOMI E NANORI

Pense nos kanjis como programas.

Eles possuem múltiplas interfaces.

ON'YOMI

Leitura de origem chinesa.

Exemplo:

gaku


KUN'YOMI

Leitura japonesa.

Exemplo:

学ぶ

manabu


NANORI

Leitura usada em nomes.

Exemplo:

mana

satoru

gaku

ou outras variantes dependendo do nome.

Ou seja:

O mesmo caractere pode executar rotinas completamente diferentes dependendo do ambiente.

É praticamente um JCL com múltiplos PROC herdados.


QUANDO O SISTEMA COMEÇA A FICAR MALUCO

Vamos pegar um exemplo famoso.

Kanji:

Normalmente:

ichi
itsu
hito

Mas em nomes pode virar:

kazu

hajime

makoto

issei

e várias outras leituras.

O estudante olha para isso e pensa:

"Existe alguma regra?"

A resposta histórica é:

"Mais ou menos."

A resposta prática é:

"Não."


POR QUE EXISTEM TANTAS LEITURAS?

Porque nomes japoneses evoluíram durante mais de mil anos.

Imagine uma empresa que nunca aposentou sistemas legados.

Cada geração adicionou novas convenções.

Nenhuma foi removida.

O resultado é um ambiente onde:

  • regras modernas coexistem

  • regras medievais coexistem

  • exceções regionais coexistem

Tudo funcionando simultaneamente.

Parece familiar para quem administra mainframe.


O TERROR DOS ESTUDANTES DE JAPONÊS

Existe uma piada famosa entre estudantes.

Você consegue ler um jornal inteiro.

Consegue entender um romance.

Consegue interpretar documentos técnicos.

Mas não consegue ler o nome das pessoas.

Isso acontece justamente por causa do nanori.

Os nomes japoneses frequentemente utilizam leituras exclusivas.


EXEMPLOS REAIS

大輔

Pode ser:

Daisuke


Pode ser:

Sho

Kakeru

Tsubasa


翔太

Shota


大和

Yamato

Hirokazu

Yamatoo

dependendo do contexto.

Cada família pode carregar uma tradição diferente.


O EASTER EGG DOS NOMES DE ANIME

Autores de anime adoram brincar com nanori.

Porque isso permite esconder significados.

O nome parece comum.

Mas os kanjis revelam uma mensagem.

É praticamente um comentário oculto no código-fonte.


NARUTO

O universo Naruto possui vários exemplos.

Minato

Significa porto.

Um ponto de encontro.

Algo que combina perfeitamente com o papel do personagem.


Itachi

Doninha.

Uma referência simbólica ao comportamento furtivo do personagem.


Sasuke

Um nome histórico associado a lendas ninja.

Os kanjis carregam múltiplas interpretações.


DEATH NOTE

Light Yagami

O caso é tão extremo que virou clássico.

Seu nome é escrito:

Que normalmente seria:

tsuki

(lua)

Mas é lido:

Light

Uma leitura totalmente não convencional.

É quase um nanori moderno criado para transmitir significado simbólico.


BLEACH

Tite Kubo adora nomes carregados de simbolismo.

Ichigo

一護

O nome pode ser interpretado como:

"aquele que protege"

embora também remeta ao número um.

Múltiplas camadas semânticas coexistem.


DEMON SLAYER

Tanjiro

炭治郎

Cada kanji contribui para a identidade histórica e cultural do personagem.

Os autores frequentemente escolhem nomes considerando:

  • som

  • significado

  • simbolismo

  • tradição

Tudo ao mesmo tempo.


O FENÔMENO DOS KIRA KIRA NAMES

Aqui entramos numa área curiosa.

Nas últimas décadas surgiu o fenômeno dos:

Kirakira Names

"nomes brilhantes".

Pais começaram a usar kanjis tradicionais com leituras extremamente criativas.

Por exemplo:

Kanji que significam "lua".

Mas pronunciados como:

Runa

Luna

Moon

ou até palavras inspiradas em inglês.

É como se alguém cadastrasse um dataset chamado:

PROD001

e declarasse que ele deve ser lido como:

SUPERSYSTEMX


O GOVERNO PRECISOU INTERVIR

O problema ficou tão grande que autoridades japonesas começaram a discutir limites para leituras excessivamente criativas.

Algumas eram tão incomuns que:

  • escolas não conseguiam registrar alunos

  • hospitais erravam nomes

  • sistemas administrativos apresentavam inconsistências

Ou seja:

O Japão começou a enfrentar problemas de integridade referencial no banco de dados nacional de nomes.


NANORI E SAMURAIS

Historicamente, samurais utilizavam nomes que mudavam durante a vida.

Era comum alguém possuir:

  • nome infantil

  • nome adulto

  • título honorífico

  • nome militar

Cada um podia envolver leituras diferentes.

Em termos modernos:

Uma pessoa podia possuir múltiplos aliases operacionais.


O SEGREDO DOS NOMES IMPERIAIS

A família imperial japonesa também influenciou fortemente o desenvolvimento dos nanori.

Certos caracteres tornaram-se associados à nobreza.

Outros passaram a simbolizar:

  • sabedoria

  • prosperidade

  • longevidade

  • força

O uso desses caracteres espalhou-se pela sociedade.


O IMPACTO NA CULTURA POP

Quando um autor escolhe um nome em anime, raramente faz isso aleatoriamente.

Existe um enorme trabalho simbólico.

Um único kanji pode transmitir:

  • destino

  • personalidade

  • papel narrativo

  • referência histórica

  • trocadilho cultural

O espectador japonês muitas vezes percebe detalhes que passam despercebidos para o público ocidental.


O EASTER EGG QUE ESTRANGEIROS QUASE NUNCA NOTAM

Muitos protagonistas possuem nomes cujo significado antecipa a história.

O autor está praticamente inserindo um comentário no código.

Mas o leitor só percebe depois de dezenas de episódios.

É equivalente a encontrar um comentário COBOL escrito em 1978 prevendo exatamente o comportamento do sistema em 2025.


O DESAFIO DOS DICIONÁRIOS

Existem dicionários inteiros dedicados apenas a nomes japoneses.

Isso porque conhecer 2.000 kanjis não é suficiente.

Você também precisa conhecer:

  • leituras históricas

  • leituras regionais

  • leituras familiares

  • leituras nanori

É um universo paralelo dentro da própria língua.


CURIOSIDADES IMPRESSIONANTES

Curiosidade 1

Alguns kanjis possuem dezenas de leituras possíveis em nomes.


Curiosidade 2

Muitos japoneses perguntam a pronúncia do nome mesmo vendo os kanjis.


Curiosidade 3

Formulários japoneses frequentemente possuem espaço específico para indicar a leitura correta do nome.


Curiosidade 4

Muitos animes incluem furigana justamente para evitar ambiguidades.


Curiosidade 5

Existem nomes que até especialistas erram ao tentar ler pela primeira vez.


O MAINFRAME DOS NOMES JAPONESES

Se tivéssemos que resumir o nanori para um profissional de tecnologia, seria algo assim:

O idioma japonês é o sistema operacional.

Os kanjis são os programas.

As leituras on'yomi e kun'yomi são a documentação oficial.

E o nanori?

O nanori é aquele módulo crítico escrito séculos atrás, cheio de exceções, compatibilidades históricas e regras herdadas que continua executando perfeitamente porque está ligado à identidade cultural de milhões de pessoas.

Você pode estudar japonês por anos.

Pode dominar gramática.

Pode ler mangás.

Pode assistir centenas de animes.

Mas inevitavelmente chegará o dia em que encontrará um nome aparentemente simples e descobrirá que sua leitura não segue nenhuma lógica que você conheça.

Nesse momento, o console cultural do Japão exibirá a mensagem definitiva:

$HASP999 NANORI PROCESSING ACTIVE

IEF233A OPERATOR ACTION REQUIRED

E você finalmente entenderá que os nomes japoneses são, na verdade, um dos maiores sistemas legados ainda em produção no planeta. 📛☕💣🖥️


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