Os Assassinos Silenciosos do System Design

 

Bellacosa Mainframe e os assassinos sileciosos do system design

☕ Um Café no Bellacosa Mainframe

Os Assassinos Silenciosos do System Design

O guia do Programador COBOL Padawan para construir sistemas que não explodem quando chegam à produção

Existe um momento muito perigoso na vida de todo projeto de software.

Não é quando o programa apresenta erro de compilação.

Não é quando o JCL retorna JCL ERROR.

Não é quando o COBOL encerra com um S0C7, um S0C4 ou um S806.

O momento mais perigoso acontece muito antes disso.

Acontece naquela reunião aparentemente inocente em que alguém diz:

“É um sistema simples. Vamos começar a programar e depois ajustamos os detalhes.”

Nesse instante, caro Programador COBOL Padawan, uma perturbação surge na Força.

Ou, para os oficiais da Frota Estelar, os sensores da ponte detectam uma anomalia arquitetural se formando perto do núcleo de dobra.

Muitos sistemas não fracassam porque seus programadores desconhecem sintaxe. Eles fracassam porque começaram sem requisitos claros, cresceram sem planejamento, acumularam complexidade desnecessária, ignoraram segurança, não prepararam mecanismos de recuperação e foram colocados em produção sem monitoramento adequado.

No início, tudo parece funcionar.

O sistema cadastra clientes.

A API responde.

O batch termina.

A tela CICS abre.

O SELECT retorna dados.

Todos comemoram.

Entretanto, meses depois, a quantidade de usuários aumenta, o banco de dados cresce, as integrações se multiplicam e aquela pequena aplicação começa a mostrar rachaduras.

As respostas ficam lentas.

O banco atinge níveis perigosos de utilização.

Ninguém consegue localizar os erros.

A equipe tem medo de alterar o código.

Uma mudança de configuração exige nova compilação.

Um servidor cai e leva todo o sistema junto.

O que parecia ser um pequeno cargueiro espacial agora está tentando operar como a USS Enterprise, mas foi construído sem escudos, sem sensores e sem plano de evacuação.

Este artigo é uma viagem completa pelos principais erros de System Design, explicando como eles surgem, por que são perigosos e como evitá-los. A missão é traduzir os conceitos de arquitetura para quem está começando em COBOL, mainframe e sistemas corporativos.

Prepare seu café, ajuste o comunicador e assuma seu posto na ponte.

Temos uma arquitetura para salvar.

---

1. O que é System Design?

System Design, ou projeto de sistemas, é o processo de decidir como uma solução será estruturada para atender a determinados objetivos.

Não se resume a desenhar caixas e setas em um diagrama.

Também não significa apenas escolher:

• linguagem de programação;

• banco de dados;

• framework;

• servidor;

• provedor de nuvem.

O projeto de sistemas procura responder perguntas muito mais profundas:

• Quem utilizará o sistema?

• Quantos usuários serão atendidos?

• Qual volume de dados será processado?

• O sistema precisa funcionar 24 horas por dia?

• O que acontece quando um componente falha?

• Como os dados serão protegidos?

• Como o ambiente será monitorado?

• Como a solução crescerá?

• Como uma versão será implantada?

• Como recuperar o sistema após um desastre?

• Quanto custará manter tudo funcionando?

Em um ambiente mainframe, essas perguntas aparecem há décadas.

Um sistema COBOL corporativo normalmente não é apenas um programa. Ele pode envolver:

• transações CICS;

• programas batch;

• JCL;

• arquivos VSAM;

• tabelas Db2;

• filas IBM MQ;

• segurança RACF;

• logs SMF;

• gerenciamento de carga pelo WLM;

• rotinas de recuperação;

• interfaces com sistemas externos.

Portanto, System Design é a arte de transformar requisitos de negócio em uma estrutura técnica capaz de funcionar com segurança, desempenho, disponibilidade e possibilidade de evolução.

Um bom projeto não tenta prever o futuro inteiro.

Ele cria uma base suficientemente sólida para que o sistema possa se adaptar sem precisar ser destruído e reconstruído a cada nova necessidade.

---

2. O primeiro assassino silencioso: começar sem requisitos claros

Um dos erros mais graves é iniciar a programação antes de compreender o problema.

A frase normalmente soa assim:

“Vamos codificar logo para ganhar tempo.”

Na prática, esse atalho costuma produzir o efeito contrário.

Quando os requisitos são vagos, cada pessoa imagina um sistema diferente.

O gestor imagina um portal.

O cliente imagina um aplicativo.

O desenvolvedor imagina uma API.

A infraestrutura imagina uma solução em nuvem.

O analista mainframe imagina uma integração com CICS e Db2.

Todos estão trabalhando, mas cada um está construindo uma nave diferente.

Um exemplo simples

O cliente solicita:

“Precisamos modernizar o sistema de pagamentos.”

A palavra “modernizar” pode significar muitas coisas:

• substituir telas 3270 por uma interface web;

• expor transações COBOL como APIs;

• migrar programas para outra plataforma;

• reorganizar o código;

• melhorar desempenho;

• automatizar implantação;

• atualizar a segurança;

• criar acesso por dispositivos móveis;

• simplesmente documentar o legado.

Sem esclarecimento, a equipe pode passar meses resolvendo o problema errado.

Requisitos funcionais e não funcionais

Os requisitos funcionais descrevem o que o sistema deve fazer.

Exemplos:

• cadastrar clientes;

• consultar saldo;

• emitir boleto;

• processar pagamento;

• gerar relatório;

• cancelar uma transação.

Os requisitos não funcionais descrevem como o sistema deve se comportar.

Exemplos:

• responder em menos de dois segundos;

• atender dez mil usuários simultâneos;

• manter disponibilidade de 99,99%;

• criptografar dados sensíveis;

• registrar todas as operações;

• recuperar o serviço em até quinze minutos.

Muitos projetos documentam apenas as funcionalidades e ignoram os requisitos não funcionais.

Depois descobrem, tarde demais, que o sistema funciona — porém é lento, inseguro ou impossível de operar.

Passo a passo antes de programar

Antes de escrever o primeiro IDENTIFICATION DIVISION, procure responder:

1. Qual problema de negócio será resolvido?

2. Quem são os usuários?

3. Qual volume inicial de dados?

4. Qual crescimento esperado?

5. Quais integrações existem?

6. Qual horário de funcionamento?

7. Qual nível de indisponibilidade é aceitável?

8. Quais dados são sensíveis?

9. Como os erros serão tratados?

10. Quem dará suporte em produção?

Clareza no início não elimina mudanças.

Ela apenas impede que a equipe viaje em dobra máxima para o quadrante errado.

---

3. Ignorar escalabilidade desde cedo

Escalabilidade é a capacidade de um sistema continuar funcionando quando sua carga aumenta.

Um projeto pode começar com cem usuários e atingir cem mil.

Uma tabela pode começar com dez mil registros e chegar a bilhões.

Um processo batch que inicialmente trabalha com vinte arquivos pode, anos depois, receber milhares.

O erro está em pensar:

“Quando crescer, nós resolvemos.”

Às vezes isso é possível.

Em outras situações, a solução inicial cria limitações tão profundas que o crescimento exige uma reescrita completa.

Escala vertical e escala horizontal

Escala vertical significa tornar uma máquina mais poderosa:

• mais CPU;

• mais memória;

• mais armazenamento;

• processadores mais rápidos.

Escala horizontal significa adicionar mais máquinas ou instâncias para dividir o trabalho.

Em ambientes distribuídos, a escala horizontal é comum.

No mainframe, há décadas existem mecanismos sofisticados de expansão e gerenciamento de carga, como:

• múltiplas LPARs;

• Parallel Sysplex;

• WLM;

• compartilhamento de dados;

• filas;

• particionamento de workloads;

• recursos especializados.

O importante não é defender uma única estratégia.

É reconhecer que o crescimento precisa ser considerado.

Exemplo de programa COBOL

Imagine um batch que processa um arquivo sequencial inteiro usando apenas uma etapa e um programa.

No começo:

• 50 mil registros;

• execução em três minutos.

Cinco anos depois:

• 500 milhões de registros;

• execução em nove horas;

• janela batch insuficiente.

Talvez o projeto devesse ter considerado:

• particionamento;

• processamento paralelo;

• checkpoints;

• retomada após falha;

• divisão por faixas;

• utilização de banco com índices adequados;

• filas de trabalho.

Escalabilidade não significa construir uma arquitetura gigante no primeiro dia.

Significa evitar escolhas que impossibilitem o crescimento.

---

4. Overengineering: quando a solução é maior que o problema

Overengineering acontece quando criamos uma solução excessivamente complexa para uma necessidade simples.

É o famoso caso de utilizar um torpedo de fótons para abrir uma lata de conservas.

Imagine uma aplicação interna usada por vinte pessoas.

A equipe decide criar:

• quinze microsserviços;

• três bancos de dados;

• um cluster Kubernetes;

• Kafka;

• Redis;

• Elasticsearch;

• Service Mesh;

• Event Sourcing;

• CQRS;

• múltiplos pipelines;

• dezenas de dashboards.

Tudo isso para cadastrar fornecedores.

A arquitetura parece impressionante em uma apresentação.

Mas agora exige:

• mais servidores;

• mais especialistas;

• mais monitoramento;

• mais segurança;

• mais custos;

• mais pontos de falha.

Complexidade não é sinônimo de maturidade.

O princípio KISS

KISS significa:

Keep It Simple.

Ou, em português:

Mantenha a solução simples.

Uma solução simples tende a ser:

• mais fácil de entender;

• mais barata;

• mais testável;

• mais confiável;

• mais rápida de corrigir.

Isso não significa escrever código descuidado.

Significa usar apenas a complexidade necessária.

Monólito não é palavrão

Muitas equipes tratam qualquer monólito como tecnologia ultrapassada.

Entretanto, um monólito modular pode ser excelente para diversos cenários.

O problema não é o monólito.

O problema é um monólito sem organização, com dependências caóticas e responsabilidades misturadas.

Da mesma forma, microsserviços não são automaticamente modernos.

Um ambiente de microsserviços mal projetado pode se tornar um monólito distribuído, mais difícil de depurar e mais caro de operar.

A melhor arquitetura não é a mais elegante no diagrama.

É a que atende aos requisitos com o menor nível razoável de complexidade.

---

5. Negligenciar tolerância a falhas

Todo componente falha.

Discos falham.

Redes falham.

Servidores param.

Programas recebem dados inválidos.

APIs externas ficam indisponíveis.

Filas enchem.

Bancos bloqueiam recursos.

Pessoas cometem erros.

O arquiteto maduro não pergunta:

“Será que vai falhar?”

Ele pergunta:

“Quando falhar, o que acontecerá?”

Falha não pode virar desastre

Uma falha local deveria permanecer local.

Se uma API de consulta de endereço estiver indisponível, isso não deveria necessariamente derrubar todo o sistema de cadastro.

Se um servidor parar, outra instância deveria assumir.

Se um programa batch interromper após processar 80% do arquivo, deveria ser possível retomar do ponto correto.

Padrões importantes

Timeout

Nenhuma chamada deveria esperar eternamente.

Um timeout define quanto tempo o sistema aguardará antes de considerar a operação malsucedida.

Retry

Algumas falhas são temporárias.

Uma nova tentativa pode resolver.

Entretanto, repetir sem controle é perigoso. Mil clientes realizando cinco tentativas podem transformar uma pequena lentidão em colapso completo.

Circuit Breaker

Funciona como um disjuntor.

Quando um serviço começa a falhar repetidamente, o sistema interrompe temporariamente as chamadas para evitar sobrecarga.

Failover

Quando um componente principal falha, outro assume.

Checkpoint

Um processo longo salva pontos de progresso para poder continuar após interrupção.

Dead Letter Queue

Mensagens que não podem ser processadas são desviadas para uma fila de análise, evitando que bloqueiem todo o fluxo.

A tradição do mainframe

A tolerância a falhas está no coração dos ambientes IBM Z.

Conceitos como:

• Parallel Sysplex;

• Coupling Facility;

• GDPS;

• replicação;

• recuperação de logs;

• commit e rollback;

• reinício de jobs;

• journaling;

• gerenciamento de workload;

existem porque sistemas bancários, governamentais e de companhias aéreas não podem simplesmente parar e aguardar alguém reiniciar o computador.

A lição é simples:

Falhar é inevitável. Falhar sem plano é opcional.

---

6. Ignorar estratégias de cache

Cache é uma camada de armazenamento rápido utilizada para evitar processamento ou acesso repetitivo a fontes mais lentas.

Imagine que dez mil usuários consultem a mesma tabela de códigos de países.

Sem cache, cada requisição pode acessar o banco.

Com cache, a informação pode ser lida uma vez e reutilizada.

Isso reduz:

• latência;

• carga no banco;

• consumo de CPU;

• tráfego de rede;

• custos.

Tipos de cache

O cache pode existir:

• no navegador;

• na aplicação;

• em memória;

• em servidores como Redis;

• em proxies;

• em CDNs;

• em estruturas internas do banco;

• em subsistemas mainframe.

O lado difícil

Cache traz um problema delicado:

Como garantir que os dados não fiquem desatualizados?

Se o preço de um produto mudar no banco, quando o cache será atualizado?

Estratégias comuns incluem:

• tempo de expiração;

• invalidação explícita;

• atualização após gravação;

• leitura através do cache;

• atualização antecipada.

Existe uma velha piada entre programadores:

Há duas coisas difíceis em computação: invalidar cache, nomear coisas e erros de contagem.

Sim, a frase diz duas coisas e lista três.

Esse é o easter egg clássico.

Cache não conserta consulta ruim

Adicionar cache sobre uma arquitetura defeituosa pode apenas esconder o problema.

Primeiro, ajuste:

• índices;

• consultas;

• modelo de dados;

• volume retornado.

Depois, utilize cache onde houver benefício real.

---

7. Projeto ruim de banco de dados

O banco de dados frequentemente se torna o coração e o gargalo do sistema.

Um modelo mal projetado pode causar:

• consultas lentas;

• duplicidade;

• inconsistência;

• bloqueios;

• dificuldade de manutenção;

• crescimento descontrolado.

Erros comuns

Falta de índices

Uma consulta por CPF em uma tabela com milhões de registros pode exigir varredura completa se não houver índice adequado.

Índices demais

Índices aceleram leitura, mas também ocupam espaço e aumentam o custo de inserções, atualizações e exclusões.

Uso indiscriminado de SELECT *

Buscar todas as colunas desperdiça:

• I/O;

• memória;

• rede;

• CPU.

Solicite apenas os dados necessários.

Tipos inadequados

Armazenar datas como texto ou valores numéricos como caracteres cria problemas de validação, ordenação e desempenho.

Ausência de integridade

Chaves primárias, estrangeiras, restrições e validações ajudam a impedir dados inválidos.

Transações longas

Uma transação aberta por muito tempo pode manter locks e afetar outros usuários.

No Db2

O programador COBOL precisa conhecer a importância de:

• índices;

• EXPLAIN;

• RUNSTATS;

• REORG;

• planos de acesso;

• cardinalidade;

• commits;

• níveis de isolamento;

• cursores;

• tabelas particionadas.

Um SQL correto do ponto de vista sintático pode ser desastroso do ponto de vista operacional.

A consulta retorna o resultado.

Mas talvez consuma milhões de leituras para localizar vinte linhas.

O banco não deve ser tratado como um depósito onde jogamos dados.

Ele é um motor que precisa ser modelado, observado e ajustado.

---

8. Ignorar segurança

Segurança não deve ser adicionada no final do projeto como um acessório.

Ela precisa acompanhar todo o ciclo de vida.

Cada atalho pode criar uma superfície de ataque.

Autenticação e autorização

Autenticação responde:

Quem é você?

Autorização responde:

O que você pode fazer?

Uma pessoa pode estar corretamente autenticada e ainda assim não possuir permissão para consultar salários, alterar limites ou excluir registros.

Princípio do menor privilégio

Cada usuário, programa ou serviço deve receber apenas as permissões necessárias.

Nada além disso.

Uma aplicação que precisa apenas consultar uma tabela não deveria ter permissão para apagá-la.

Criptografia

Dados precisam ser protegidos:

• em trânsito;

• em repouso;

• durante backups;

• em arquivos temporários;

• em logs.

Segredos não pertencem ao código

Senhas, tokens e chaves não devem aparecer em programas ou repositórios.

Nada de:

01 WS-PASSWORD PIC X(20) VALUE 'ADMIN123'.

Além de inseguro, isso transforma qualquer troca de senha em alteração de código.

Mainframe e segurança

No IBM Z, a proteção pode envolver:

• RACF;

• SAF;

• perfis de recursos;

• MFA;

• TLS;

• ICSF;

• Crypto Express;

• auditoria SMF;

• separação de funções.

Entretanto, possuir ferramentas poderosas não garante segurança.

Configuração incorreta, privilégios excessivos e ausência de revisão continuam sendo riscos.

Segurança é tecnologia, processo e disciplina.

---

9. Não ter monitoramento, logs e observabilidade

Um sistema sem monitoramento é como a Enterprise atravessando uma nebulosa com os sensores desligados.

Talvez a nave esteja bem.

Talvez esteja a segundos de uma colisão.

Sem telemetria, ninguém sabe.

Logs

Logs registram eventos importantes:

• início e fim de processamento;

• erros;

• decisões;

• identificadores;

• mensagens recebidas;

• duração de operações.

Um bom log precisa ser útil.

Mensagens como:

“Erro inesperado.”

ajudam muito pouco.

Melhor seria registrar:

• operação;

• horário;

• módulo;

• código do erro;

• contexto;

• identificador da transação.

Naturalmente, sem expor senhas ou dados sensíveis.

Métricas

Métricas mostram valores ao longo do tempo:

• CPU;

• memória;

• transações por segundo;

• tempo médio de resposta;

• quantidade de erros;

• tamanho de fila;

• uso de conexões;

• duração do batch.

Tracing

Em sistemas distribuídos, uma única operação pode atravessar diversos serviços.

Tracing permite acompanhar a jornada da requisição.

Observabilidade no mainframe

Podemos relacionar esse universo a:

• SMF;

• RMF;

• OMEGAMON;

• SDSF;

• logs do CICS;

• estatísticas do Db2;

• mensagens JES;

• registros de MQ;

• relatórios de WLM.

O objetivo é responder:

• O que aconteceu?

• Quando aconteceu?

• Onde aconteceu?

• Qual componente foi afetado?

• Quantos usuários sofreram impacto?

• Qual foi a causa?

• O problema está piorando?

Se a equipe só descobre uma falha quando o cliente telefona, o sistema não está verdadeiramente monitorado.

---

10. Configurações hardcoded

Hardcoding ocorre quando valores específicos de ambiente são gravados diretamente no código.

Exemplos:

• endereço de servidor;

• senha;

• diretório;

• fila;

• porta;

• nome de banco;

• limite operacional;

• e-mail;

• URL.

Por que isso é ruim?

Porque o código fica preso ao ambiente.

Para mover de desenvolvimento para teste, talvez seja necessário alterar e recompilar.

Para trocar um servidor, nova mudança.

Para ajustar timeout, novo deploy.

Isso aumenta riscos e reduz flexibilidade.

Estratégia correta

Separar:

• código;

• configuração;

• segredo.

Configurações podem ficar em:

• arquivos externos;

• variáveis de ambiente;

• tabelas de parâmetros;

• sistemas de gestão de configuração;

• cofres de segredos;

• propriedades de runtime.

No mundo COBOL e mainframe, essa separação também pode envolver:

• PARM de JCL;

• SYSIN;

• DDs;

• arquivos de controle;

• tabelas Db2;

• variáveis simbólicas;

• parâmetros de transação.

O mesmo programa pode operar em vários ambientes sem alteração do fonte.

Essa é uma característica valiosa de sistemas bem projetados.

---

11. Não testar em escala realista

O notebook do desenvolvedor não é a produção.

No ambiente local:

• há poucos dados;

• apenas um usuário;

• quase nenhuma concorrência;

• rede rápida;

• banco vazio;

• recursos disponíveis.

Em produção:

• milhares de usuários;

• milhões de registros;

• chamadas simultâneas;

• períodos de pico;

• integrações lentas;

• falhas intermitentes.

Um sistema pode funcionar perfeitamente no teste funcional e colapsar sob carga.

Tipos de teste

Teste de carga

Verifica o comportamento sob volume esperado.

Teste de estresse

Aumenta a carga até localizar o limite.

Teste de pico

Simula aumento repentino de uso.

Teste de longa duração

Avalia vazamentos de memória, degradação e acúmulo de recursos.

Teste de concorrência

Identifica condições de corrida, locks e conflitos.

Teste de recuperação

Confirma se o sistema volta corretamente após falha.

Chaos Engineering

Introduz falhas controladas para verificar a resiliência.

Por exemplo:

• derrubar uma instância;

• atrasar uma chamada;

• bloquear uma dependência;

• simular perda de rede;

• encher uma fila.

No mainframe, também é essencial testar:

• grandes massas;

• duração da janela batch;

• contenção Db2;

• transações CICS;

• reinício de jobs;

• checkpoints;

• indisponibilidade de datasets;

• falha de comunicação MQ.

Produção não deveria ser o primeiro teste de escala.

Quando isso acontece, o cliente se torna parte involuntária da equipe de QA.

---

12. O erro invisível: monitorar tecnologia, mas ignorar o negócio

Muitas equipes monitoram CPU, memória e disco.

Mas não sabem responder:

• Quantos pagamentos foram processados?

• Quantas vendas foram perdidas?

• Quantos clientes abandonaram a operação?

• Quantas transações falharam por regra de negócio?

• Qual valor financeiro ficou represado?

O sistema pode estar tecnicamente saudável e ainda assim falhar na missão.

Imagine que todos os servidores estejam verdes no painel, mas uma regra errada esteja rejeitando metade dos pedidos.

A infraestrutura diz:

“Tudo normal.”

O negócio diz:

“Estamos perdendo dinheiro.”

Por isso, métricas técnicas e de negócio precisam caminhar juntas.

A ponte da Enterprise não monitora apenas o motor de dobra.

Ela também monitora destino, tripulação, missão e ameaças.

---

13. O custo também faz parte da arquitetura

Uma arquitetura pode funcionar e ainda assim ser inviável financeiramente.

Recursos ociosos, bancos superdimensionados, tráfego excessivo, logs sem retenção controlada e componentes desnecessários aumentam despesas.

Na nuvem, cada decisão pode gerar custo recorrente:

• processamento;

• armazenamento;

• transferência;

• chamadas;

• serviços gerenciados;

• licenciamento.

No mainframe, também existem questões de:

• consumo de CPU;

• MSU;

• janelas;

• classes de serviço;

• licenças;

• capacidade;

• uso de processadores especializados.

Um bom arquiteto não pensa apenas:

“Funciona?”

Ele também pergunta:

“É sustentável?”

A melhor solução equilibra:

• desempenho;

• confiabilidade;

• segurança;

• simplicidade;

• custo.

---

14. Um roteiro prático para projetar melhor

Aqui está um pequeno plano de missão para o Programador COBOL Padawan.

Etapa 1 — Compreenda o problema

Converse com usuários e responsáveis pelo negócio.

Evite começar pela tecnologia.

Etapa 2 — Levante requisitos funcionais

Liste as operações que o sistema deverá executar.

Etapa 3 — Levante requisitos não funcionais

Defina:

• desempenho;

• volume;

• disponibilidade;

• segurança;

• recuperação;

• auditoria.

Etapa 4 — Identifique dados e integrações

Pergunte:

• De onde os dados vêm?

• Onde serão armazenados?

• Quem poderá acessá-los?

• Quais sistemas dependem deles?

Etapa 5 — Desenhe uma solução simples

Comece com a menor arquitetura capaz de atender aos requisitos.

Etapa 6 — Mapeie pontos de falha

Para cada componente, pergunte:

“O que acontece se ele parar?”

Etapa 7 — Planeje observabilidade

Defina logs, métricas, alertas e painéis antes da produção.

Etapa 8 — Separe configuração do código

Prepare a solução para múltiplos ambientes.

Etapa 9 — Teste com volume realista

Não teste apenas o caminho feliz.

Etapa 10 — Revise segurança

Aplique menor privilégio, criptografia e auditoria.

Etapa 11 — Documente decisões

Registre por que determinada alternativa foi escolhida.

Isso evita que, anos depois, alguém veja uma solução estranha e a substitua sem compreender o contexto.

Etapa 12 — Evolua gradualmente

Arquitetura não é um monumento congelado.

Ela deve ser revisada conforme o negócio e a tecnologia evoluem.

---

15. Curiosidades da sala de máquinas

Curiosidade 1 — Mainframes já faziam “cloud” antes do nome existir

Compartilhamento de recursos, virtualização, isolamento e gerenciamento centralizado são práticas antigas no mainframe.

O termo mudou.

Muitos princípios permaneceram.

Curiosidade 2 — Filas não são novidade

Mensageria assíncrona parece moderna, mas sistemas corporativos utilizam filas e processamento desacoplado há décadas.

IBM MQ é um exemplo clássico dessa filosofia.

Curiosidade 3 — O batch continua vivo

Mesmo com APIs e eventos, processamento batch continua essencial para:

• fechamento financeiro;

• faturamento;

• conciliação;

• geração de relatórios;

• tratamento de grandes volumes.

A diferença é que batch moderno pode ser integrado a pipelines, APIs e eventos.

Curiosidade 4 — Simplicidade exige experiência

Criar algo complicado é relativamente fácil.

Criar uma solução simples que atenda aos requisitos exige entendimento profundo.

É como a ponte da Enterprise: o painel parece organizado porque uma enorme complexidade foi cuidadosamente controlada abaixo do convés.

---

16. Easter egg da Frota Estelar

Em muitos episódios de Star Trek, a Enterprise encontra tecnologias extremamente poderosas construídas por civilizações avançadas.

Entretanto, o perigo raramente está apenas na tecnologia.

O problema aparece quando:

• ninguém compreende os limites;

• não existem controles;

• a tripulação ignora sinais;

• alguém tenta obter poder rapidamente;

• uma falha pequena se propaga.

Isso é System Design.

Uma arquitetura sofisticada sem compreensão pode ser mais perigosa que uma solução simples.

O melhor oficial de engenharia não é aquele que instala mais componentes.

É aquele que mantém a nave funcionando, conhece seus limites e sabe exatamente o que fazer quando uma luz vermelha aparece no painel.

Como diria Montgomery Scott em espírito:

Você não pode mudar as leis da física, capitão.

Na engenharia de software, também não podemos ignorar:

• latência;

• concorrência;

• falhas;

• volume;

• capacidade;

• custo.

Podemos administrá-los.

Nunca eliminá-los por decreto.

---

Conclusão — O sistema não quebra de repente

Os grandes problemas arquiteturais raramente chegam anunciados.

Eles crescem silenciosamente.

Uma consulta sem índice parece inofensiva enquanto a tabela é pequena.

Uma configuração hardcoded parece conveniente enquanto existe apenas um ambiente.

A ausência de cache não incomoda enquanto há poucos usuários.

A falta de logs passa despercebida enquanto nada falha.

A inexistência de failover parece aceitável enquanto o servidor está funcionando.

Depois, um dia, tudo converge.

O tráfego aumenta.

O banco fica lento.

A aplicação gera timeout.

Os retries sobrecarregam ainda mais o sistema.

A fila cresce.

Os logs são insuficientes.

A equipe não consegue identificar a causa.

A direção pede uma previsão.

O cliente reclama.

E alguém diz:

“Precisamos reescrever tudo.”

Na realidade, o desastre começou meses ou anos antes, em pequenas decisões que pareciam não ter importância.

O verdadeiro objetivo de System Design não é criar diagramas bonitos nem utilizar todas as tecnologias da moda.

É construir sistemas capazes de:

• cumprir sua missão;

• resistir a falhas;

• crescer com controle;

• proteger dados;

• ser observados;

• ser mantidos;

• evoluir sem caos.

Para o Programador COBOL Padawan, compreender arquitetura é o passo que transforma alguém que apenas escreve programas em um profissional que entende sistemas.

O COBOL pode processar a regra.

O JCL pode executar o job.

O Db2 pode armazenar os dados.

O CICS pode receber a transação.

O MQ pode transportar a mensagem.

Mas é o projeto de sistemas que faz todas essas partes trabalharem juntas.

Na Frota Estelar, uma nave não é apenas o motor de dobra.

É a combinação de propulsão, sensores, escudos, comunicação, suporte à vida, segurança, comando e uma tripulação treinada.

No mundo corporativo, a arquitetura também depende de integração, observabilidade, resiliência, dados, processos e pessoas.

Antes de liberar a próxima versão, pare diante do painel e faça a pergunta mais importante:

“Estamos construindo apenas algo que funciona hoje, ou um sistema capaz de sobreviver à missão de amanhã?”

Porque o melhor sistema não é aquele que nunca falha.

É aquele que foi projetado para continuar sua jornada quando o inesperado inevitavelmente aparecer no horizonte.

Vida longa e próspera aos seus programas, aos seus jobs e às suas arquiteturas.

⏳ A Filosofia do Desejo em Anime — Parte 6: O Amor e o Fetiche da Eternidade

 

⏳ A Filosofia do Desejo em Anime — Parte 6: O Amor e o Fetiche da Eternidade

Amar é um gesto contra o tempo.
É desafiar o esquecimento, gritar no vazio do relógio:

“Eu ainda me lembro.”

O fetiche final não é o toque, o poder, o caos ou o ideal.
É a memória.
O amor que sobrevive à ausência, o eco que insiste mesmo depois do silêncio.
Os japoneses chamam isso de natsukashii —
uma nostalgia doce, dolorida e irresistível.

---

🌌 1. Your Name (君の名は。)

Ano: 2016 | Direção: Makoto Shinkai

Dois jovens trocam de corpo, de vida e de destino.
Separados por tempo e tragédia, buscam reencontrar-se sem lembrar exatamente o porquê.
O fetiche aqui é a conexão impossível — amar alguém que já se foi, mas ainda está.

🔎 Curiosidade Bellacosa: Shinkai declarou que queria fazer “um filme sobre o destino como código genético do amor”.
A trilha do RADWIMPS é quase uma oração moderna.

---

🌸 2. 5 Centimeters per Second (秒速5センチメートル)

Ano: 2007 | Direção: Makoto Shinkai

Cada episódio é uma estação da vida — e um adeus.
Takaki e Akari se amam, mas a vida os separa, como neve que cai devagar demais.
O fetiche aqui é a saudade, o prazer doloroso de lembrar.

🔎 Curiosidade Bellacosa: O título se refere à velocidade de queda das pétalas de cerejeira —
um símbolo do quanto o amor pode ser lento e rápido ao mesmo tempo.

---

🎶 3. Vivy: Fluorite Eye’s Song (ヴィヴィ)

Ano: 2021 | Estúdio: Wit Studio

Uma androide cantora atravessa cem anos tentando impedir a guerra entre humanos e máquinas.
Mas o que ela descobre é mais humano que qualquer algoritmo:
amar é aprender a falhar.

O fetiche da eternidade aqui é o ciclo, o desejo de corrigir, salvar, e cantar para alguém que já não existe.

🔎 Curiosidade Bellacosa: A música “Sing My Pleasure” virou um hino digital — mistura de IA e emoção em pura harmonia.

---

🌧 4. The Garden of Words (言の葉の庭)

Ano: 2013 | Direção: Makoto Shinkai

Um jovem e uma mulher se encontram nos dias de chuva, em um jardim silencioso.
Nada acontece — e é isso que acontece.
O fetiche é a suspensão do tempo, o instante que se recusa a passar.

🔎 Curiosidade Bellacosa: O som da chuva foi tratado como instrumento musical.
Shinkai disse: “a água é o toque dos que não se tocam”.

---

☕ Epílogo de Balcão: A Eternidade como Fetiche

No fim de tudo, o amor talvez não queira durar —
quer apenas ser lembrado.
Os animes de Shinkai e seus herdeiros nos ensinam que o desejo não é sobre possuir,
mas sobre preservar o instante antes que ele se desfaça.

O verdadeiro fetiche da eternidade é este:
guardar o cheiro de um beijo que o tempo já levou.
Rever um rosto que talvez nunca tenha existido.
Sorrir por dentro e pensar:

“Se eu a encontrasse hoje... ainda reconheceria seu olhar.”

E então, o ciclo se fecha.
Do corpo ao espírito, do toque ao eco, do agora ao sempre —
o amor continua sendo a mais humana das ficções,
e o mais belo dos bugs da alma.

 

Bellacosa Mainframe e a estrutura moderna do fuzoku japones

🏙️ Estrutura Moderna do Fūzoku Japonês

(A indústria do entretenimento adulto no Japão)

---

🌸 1. Conceito de “Fūzoku” (風俗)

No Japão, fūzoku significa literalmente “costumes” ou “hábitos sociais”, mas no contexto moderno se refere a negócios ligados ao prazer e entretenimento adulto.

A lei diferencia dois grandes grupos:

• Fūzoku legal (registrado) → fiscalizado, paga impostos e segue regras locais.

• Fūzoku ilegal → atividades de prostituição direta (sexo pago), tráfico, exploração de menores, etc.

Tudo é regido pela Lei de Controle de Negócios de Entretenimento e Moralidade (Fūeihō, 風営法).

---

🧩 2. Tipos de Estabelecimentos (Fūzoku tenpo)

💦 1. Soaplands (ソープランド)

• Origem: Evoluíram das antigas “Turkish baths” dos anos 60.

• Serviço: O cliente é banhado e massageado por uma atendente nua ou seminudada.
  O ato sexual é “teoricamente” não contratado, mas frequentemente ocorre sob o pretexto de “consentimento pessoal”.

• Localização: Tóquio (Yoshiwara), Kawasaki, Sapporo.

• Legalidade: Registrados como banhos públicos privados, não como prostíbulos.

🧴 Curiosidade: Há uma linguagem codificada nos anúncios — palavras como “relax total”, “VIP course” e “deluxe bath” indicam o nível de intimidade.

---

💋 2. Fashion Health (ファッションヘルス)

• Serviço: Massagens eróticas, masturbação manual e oral.

• Sem sexo completo, portanto legal.

• Nome curioso: “Health” é usado como eufemismo de “prazer”, e “fashion” dá uma aparência moderna e higiênica.

• Preço: Mais acessível que um soapland.

👗 Curiosidade: As atendentes muitas vezes se vestem conforme “temas” — enfermeiras, secretárias, estudantes, etc.

---

🚗 3. Delivery Health (デリヘル / Deriheru)

• Serviço: Acompanhantes enviadas para hotéis ou apartamentos (“delivery”).

• Registro: Legalmente descritos como agências de massagem domiciliar.

• Popularidade: É o tipo de fūzoku mais comum no Japão moderno.

• Regras: Sexo não pode ser oficialmente contratado, mas o “extra” é negociado de forma privada.

💡 Curiosidade: Muitos sites de “deriheru” funcionam com perfis, avaliações e agendamento online, como aplicativos de namoro.

---

🍸 4. Hostess Clubs (キャバクラ / Kyabakura) e Snack Bars

• Serviço: Companhia, conversa, charme e bebida — sem sexo direto.

• As hostess entretêm os clientes, fazem o cliente se sentir desejado, mas mantêm distância física.

• Locais: Áreas como Kabukichō (Shinjuku) ou Ginza.

• Hierarquia: Existem hostesses iniciantes (kyabajō) e veteranas com status de celebridade.

👠 Curiosidade: Muitos clientes gastam fortunas apenas para “fazer parte do mundo dela”, sem relação física alguma.

---

🕴️ 5. Host Clubs

• Versão masculina dos hostess clubs.

• Clientes: Mulheres, frequentemente casadas ou executivas.

• Serviço: Atenção, flerte, bebida, ego e fantasia romântica.

• Cultura: Os hosts cultivam uma imagem de “príncipe moderno” e constroem vínculos emocionais com suas clientes.

💰 Curiosidade: Alguns hosts se tornam celebridades nacionais; um dos mais famosos, Roland, é multimilionário e figura pública.

---

🎭 6. Image Clubs (イメクラ / Imekura)

• Serviço: Encenações de fetiches e fantasias (professora, médica, policial, etc.).

• O foco é o roleplay, não necessariamente o ato sexual.

• Legalidade: 100% legal se não houver penetração.

🎬 Curiosidade: Muitos roteiros são inspirados em mangás e animes — há inclusive “imekura” de estilo cosplay.

---

⚖️ 3. Regras e Fiscalização

A Fūeihō (Lei de Moralidade Pública) impõe:

• Horário limitado: Geralmente até 00h.

• Zonas específicas: Não podem operar perto de escolas ou templos.

• Registro obrigatório: Cada loja deve ter licença e número de operação visível.

• Idade mínima: 18 anos.

• Fiscalização policial periódica.

Mas a aplicação da lei é flexível — as autoridades muitas vezes fecham os olhos desde que não haja escândalo ou crime associado.

---

🏗️ 4. Hierarquia e Economia Interna

• Topo: Donos e gerentes (geralmente ex-funcionários ou ex-proprietários).

• Meio: Mama-san (madames que gerenciam hostesses) e captains (supervisores).

• Base: Atendentes, massagistas, hostesses ou hosts.

💵 Lucros vêm de:

• Taxas por tempo e bebida.

• Presentes e “extra fees”.

• Comissões para intermediários (scouts).

Estima-se que o setor mova mais de 4 trilhões de ienes por ano — maior que a indústria de videogames japonesa.

---

🧠 5. Impacto Cultural e Social

• Ambiguidade moral: O Japão trata o sexo como tabu e negócio ao mesmo tempo.

• Mulheres do fūzoku frequentemente enfrentam preconceito, mas também ganham autonomia financeira.

• Homens e solidão: A clientela é movida tanto por desejo quanto por carência emocional.

• Pop culture: Muitos animes, mangás e filmes abordam o universo fūzoku — como Midnight Diner, Shinjuku Swan e Kabukichō Sherlock.

• Turismo sexual: Estrangeiros são malvistos em muitos desses locais, especialmente onde há regras rígidas de “japoneses apenas”.

---

🌆 Conclusão

O fūzoku japonês é um espelho da sociedade:
sofisticado, discreto, contraditório e altamente regulado.
Apesar da proibição formal da prostituição, o Japão criou um ecossistema onde o prazer é “legalizado” até o limite da lei, transformando tabus em negócio — e negócio em tradição.

 

Bellacosa Mainframe apresenta o Arrow Function e Lambda Functions

☕ Um Café no Bellacosa Mainframe

⚔️ YUUYA TENJOU E A DUNGEON DAS ARROW FUNCTIONS — QUANDO O COBOL ENCONTROU A SETA =>

Lambda, Arrow Functions, programação funcional, callbacks, map, filter, reduce, pipelines, legibilidade, carga cognitiva — e o dia em que um programador COBOL descobriu que x => x * 2 não era uma tentativa de economizar caracteres no teclado.

---

🎬 PRÓLOGO — YUUYA ENCONTROU UMA PORTA ESTRANHA

Todo programador possui uma porta para outro mundo.

Para Yuuya Tenjou, em Isekai de Cheat Skill, foi literalmente uma passagem para outro mundo.

Para um programador COBOL, às vezes basta abrir um programa JavaScript moderno.

Você entra inocentemente esperando encontrar variáveis, condições, loops e funções.

De repente aparece:

clientes
    .filter(c => c.ativo)
    .map(c => c.nome)
    .sort((a, b) => a.localeCompare(b));

O programador COBOL observa aquilo durante alguns segundos.

Depois mais alguns.

Finalmente pergunta:

— Cadê o IF?

Silêncio.

— Cadê o PERFORM?

Nada.

— Cadê o END-IF?

Apenas uma seta olhando para ele:

=>

Bem-vindo à Dungeon das Arrow Functions.

O objetivo deste artigo não é convencer você de que arrow functions são maravilhosas, nem dizer que programação funcional é superior ao COBOL.

Nosso objetivo é muito mais interessante:

entender por que essa maneira de programar existe, que problema ela resolve e, principalmente, como um programador acostumado ao pensamento COBOL pode aprender a lê-la rapidamente.

Pegue o café.

Yuuya abriu a porta.

Nós vamos entrar.

---

🏰 CAPÍTULO 1 — COBOL FOI FEITO PARA SER LIDO

Existe uma razão histórica para um programador COBOL estranhar JavaScript moderno.

Veja:

IF WS-IDADE >= 18
    DISPLAY 'ADULTO'
END-IF

Mesmo alguém com pouco conhecimento de COBOL consegue imaginar o que está acontecendo.

Há uma condição.

Há uma ação.

Há um encerramento explícito.

Compare com:

p => p.idade >= 18

A primeira impressão pode ser:

— Isso não foi construído para humanos.

Na realidade, foi construído para humanos que já dominam determinado vocabulário.

Esse detalhe é importante.

Quando você lê:

PERFORM VARYING IDX FROM 1 BY 1
    UNTIL IDX > WS-TOTAL

um iniciante também pode achar estranho.

Mas depois de anos trabalhando com COBOL, seu cérebro não interpreta individualmente:

PERFORM
VARYING
FROM
BY
UNTIL

Você reconhece um padrão inteiro:

LOOP.

É exatamente isso que precisa acontecer com:

x => x * 2

O objetivo não é interpretar cada símbolo.

O objetivo é reconhecer o padrão.

---

🧙 CAPÍTULO 2 — PRIMEIRA MAGIA DE YUUYA: => SIGNIFICA RECEBE E DEVOLVE

Vamos estabelecer nosso primeiro cheat skill.

Sempre que encontrar:

x => expressão

leia mentalmente:

RECEBE x E DEVOLVE expressão.

Portanto:

x => x * 2

vira:

recebe x e devolve x * 2.

Isso:

idade => idade >= 18

vira:

recebe idade e devolve verdadeiro se idade for maior ou igual a 18.

Isso:

cliente => cliente.ativo

vira:

recebe cliente e devolve o estado de cliente.ativo.

E:

(a, b) => a + b

significa:

recebe a e b e devolve a soma dos dois.

Pronto.

A seta perdeu boa parte da magia.

---

⚔️ CAPÍTULO 3 — LAMBDA NÃO É ARROW FUNCTION

Antes de avançarmos, precisamos separar dois conceitos.

Lambda é uma ideia.

Arrow function é uma sintaxe.

O conceito de funções lambda é muito anterior ao JavaScript moderno e está relacionado ao cálculo lambda desenvolvido por Alonzo Church na década de 1930.

O cálculo lambda tornou-se uma das bases teóricas da ciência da computação e influenciou profundamente linguagens funcionais.

JavaScript apenas oferece uma maneira compacta de escrever determinadas funções.

Compare:

function dobrar(numero) {
    return numero * 2;
}

com:

numero => numero * 2

A segunda forma é uma arrow function.

Conceitualmente ambas representam comportamento:

ENTRADA
   |
   V
numero
   |
   V
numero * 2
   |
   V
SAÍDA

A diferença principal aqui é a quantidade de cerimônia sintática.

---

🧠 CAPÍTULO 4 — POR QUE ALGUÉM QUIS DIMINUIR AS FUNÇÕES?

Imagine que precisamos filtrar clientes adultos.

Poderíamos escrever:

function clienteAdulto(cliente) {
    return cliente.idade >= 18;
}

const adultos = clientes.filter(clienteAdulto);

Isso é perfeitamente válido.

Mas talvez essa função seja usada somente naquele ponto.

Então podemos escrever:

const adultos =
    clientes.filter(cliente => cliente.idade >= 18);

A função foi criada exatamente onde é necessária.

Essa é uma das grandes vantagens das lambdas:

comportamentos pequenos podem ser definidos e passados diretamente para outras operações.

Em outras palavras, funções passam a ser tratadas como valores.

Podemos passar uma função para outra função.

Esse conceito recebe frequentemente o nome de funções de primeira classe.

---

📦 CAPÍTULO 5 — QUANDO O COMPORTAMENTO VIRA DADO

Aqui começa a parte realmente importante.

Um programador COBOL está acostumado com algo semelhante a:

PERFORM VALIDAR-CLIENTE

Existe uma rotina chamada VALIDAR-CLIENTE.

Agora imagine que pudéssemos entregar essa rotina para outra rotina dizendo:

Tome esta regra e execute-a para cada elemento.

É aproximadamente isso que acontece aqui:

clientes.filter(clienteAdulto);

Estamos entregando clienteAdulto para filter.

Mas também podemos criar a regra diretamente:

clientes.filter(
    cliente => cliente.idade >= 18
);

filter recebe comportamento.

Isso permite construir abstrações extremamente poderosas.

---

🏭 CAPÍTULO 6 — O COBOLZEIRO PENSA EM PERFORM

Imagine:

MOVE ZERO TO WS-CONTADOR

PERFORM VARYING IDX FROM 1 BY 1
    UNTIL IDX > WS-TOTAL

    IF CLIENTE-ATIVO(IDX) = 'S'
        ADD 1 TO WS-CONTADOR
    END-IF

END-PERFORM

Aqui estamos descrevendo explicitamente o mecanismo:

1. inicializar;

2. criar índice;

3. incrementar índice;

4. testar limite;

5. acessar elemento;

6. testar condição;

7. executar ação.

Isso é pensamento imperativo.

Estamos dizendo:

computador, faça isso, depois aquilo, depois aquilo.

Agora observe:

clientes.filter(cliente => cliente.ativo);

Aqui estamos mais próximos de:

Dos clientes, quero aqueles que estão ativos.

Não especificamos explicitamente como percorrer a coleção.

filter já sabe fazer isso.

Nós fornecemos apenas a regra.

Essa diferença é fundamental.

---

🔮 CAPÍTULO 7 — IMPERATIVO VERSUS DECLARATIVO

Simplificando bastante:

Imperativo

Descreve como fazer.

PEGUE REGISTRO
TESTE
SE ACEITO
   MOVA
INCREMENTE
VOLTE

Declarativo

Descreve mais diretamente o que queremos.

FILTRAR CLIENTES ATIVOS

Programação funcional frequentemente permite aproximar o código dessa segunda maneira de pensar.

Isso não significa que uma seja universalmente melhor.

Significa que estamos trabalhando em níveis diferentes de abstração.

---

🗺️ CAPÍTULO 8 — O COPYBOOK SECRETO DAS FUNÇÕES FUNCIONAIS

Yuuya encontra agora um pergaminho escondido na dungeon.

Nele estão apenas sete palavras.

Memorize-as:

FILTER = QUEM FICA?

MAP = VIRA O QUÊ?

FIND = QUAL DELES?

SOME = EXISTE ALGUM?

EVERY = TODOS?

REDUCE = ACUMULA COMO?

SORT = COMPARA COMO?

Esse pequeno mapa muda completamente a maneira de ler JavaScript moderno.

---

🧹 CAPÍTULO 9 — FILTER: QUEM PASSA PELO PORTÃO?

Considere:

clientes.filter(
    cliente => cliente.idade >= 18
);

Não comece pela lambda.

Veja primeiro:

filter

Pergunte:

Quem fica?

Agora leia:

cliente => cliente.idade >= 18

Resposta:

clientes cuja idade seja maior ou igual a 18.

filter funciona como uma peneira.

Entrada:

Ana     15
Maria   27
João    17
Carlos  44

Regra:

IDADE >= 18

Saída:

Maria   27
Carlos  44

A lambda usada por filter normalmente produz:

TRUE

ou:

FALSE

TRUE passa.

FALSE fica para trás.

---

🪄 CAPÍTULO 10 — MAP: TRANSFORME UMA COISA EM OUTRA

Agora:

clientes.map(cliente => cliente.nome);

Pergunta:

Vira o quê?

Cada cliente vira seu nome.

Entrada:

[
    { nome: "Ana", idade: 30 },
    { nome: "Maria", idade: 41 }
]

Saída:

[
    "Ana",
    "Maria"
]

Pense:

CLIENTE --------> NOME
CLIENTE --------> NOME
CLIENTE --------> NOME

map é uma transformação.

---

🔎 CAPÍTULO 11 — FIND: ENCONTRE UM REGISTRO

clientes.find(
    cliente => cliente.id === 123
);

Leia:

encontre o cliente cujo ID seja 123.

Mentalmente, isso é muito próximo de procurar um registro por determinada condição.

O interessante é que não precisamos escrever explicitamente toda a lógica de iteração.

---

🧪 CAPÍTULO 12 — SOME E EVERY

Veja:

clientes.some(cliente => cliente.bloqueado);

Pergunta:

Existe algum cliente bloqueado?

Agora:

clientes.every(cliente => cliente.ativo);

Pergunta:

Todos os clientes estão ativos?

Esse vocabulário começa a tornar o código surpreendentemente expressivo depois que você aprende a lê-lo semanticamente.

---

👹 CAPÍTULO 13 — YUUYA ENCONTRA O BOSS: REDUCE

E finalmente chegamos ao monstro que assusta muita gente:

pedidos.reduce(
    (acc, pedido) => acc + pedido.valor,
    0
);

O COBOLzeiro olha:

— Agora vocês passaram dos limites.

Calma.

Vamos desmontar.

O 0 é o valor inicial.

Portanto:

ACC = 0

Depois:

(acc, pedido) => acc + pedido.valor

significa:

recebe acumulador e pedido e devolve acumulador + valor do pedido.

Em COBOL conceitualmente teríamos:

MOVE ZERO TO WS-TOTAL

PERFORM VARYING IDX FROM 1 BY 1
    UNTIL IDX > WS-QTD-PEDIDOS

    ADD PEDIDO-VALOR(IDX)
        TO WS-TOTAL

END-PERFORM

Portanto:

pedidos.reduce(
    (total, pedido) => total + pedido.valor,
    0
);

é essencialmente:

TOTAL = TOTAL + PEDIDO-VALOR

repetido para todos os pedidos.

O dragão morreu.

---

🏗️ CAPÍTULO 14 — O PODER REAL ESTÁ NO PIPELINE

Agora podemos juntar tudo:

const total =
    pedidos
        .filter(pedido => pedido.status === "PAGO")
        .map(pedido => pedido.valor)
        .reduce(
            (total, valor) => total + valor,
            0
        );

Não tente ler cada símbolo.

Primeiro veja:

PEDIDOS
   |
FILTER
   |
MAP
   |
REDUCE

Agora pergunte:

FILTER

Quem fica?

PEDIDOS PAGOS

MAP

Vira o quê?

PEDIDO → VALOR

REDUCE

Acumula como?

SOMA

Então o algoritmo inteiro significa:

Pegue os pedidos pagos, transforme-os em valores e some esses valores.

---

🖥️ CAPÍTULO 15 — ISSO PARECE MAIS MAINFRAME DO QUE VOCÊ IMAGINA

Podemos imaginar:

INPUT DATASET
      |
      V
    FILTER
      |
      V
 TRANSFORMATION
      |
      V
 AGGREGATION
      |
      V
   OUTPUT

Familiar?

Muito.

Um pipeline:

dados
    .filter(...)
    .map(...)
    .reduce(...)

pode ser mentalmente interpretado como uma sequência de etapas de processamento.

É quase como observar um fluxo batch.

Você primeiro identifica:

INPUT
STEP01
STEP02
STEP03
OUTPUT

Depois entra em cada etapa.

Essa é uma excelente estratégia para um programador mainframe.

---

📞 CAPÍTULO 16 — CALLBACK: TOME ESTA ROTINA E CHAME DEPOIS

Arrow functions aparecem muito em callbacks.

Veja:

setTimeout(() => {
    console.log("Olá");
}, 1000);

Primeiro:

() => {
    console.log("Olá");
}

significa:

função que não recebe parâmetros e imprime "Olá".

Agora:

setTimeout(FUNCAO, 1000);

significa aproximadamente:

execute essa função depois de 1000 milissegundos.

Poderíamos escrever:

function dizerOla() {
    console.log("Olá");
}

setTimeout(dizerOla, 1000);

A arrow function evita criar um nome para uma rotina utilizada apenas naquele ponto.

---

⚠️ CAPÍTULO 17 — MENOS CARACTERES NÃO SIGNIFICA MELHOR CÓDIGO

Agora Yuuya encontra uma armadilha.

Veja:

x => x.a > 10

Curto?

Sim.

Legível?

Depende.

O que é x?

O que é a?

Por que 10?

Compare:

cliente =>
    cliente.saldo > LIMITE_CREDITO

Muito melhor.

A arrow function não era o problema.

O problema eram os nomes.

Essa é uma lição extremamente importante.

Código compacto não é necessariamente código simples.

---

🧠 CAPÍTULO 18 — COMPRESSÃO DE CÓDIGO E DESCOMPRESSÃO CEREBRAL

Imagine:

x.filter(a=>a.b).map(c=>c.d).reduce((e,f)=>e+f,0)

Poucos caracteres.

Mas o cérebro precisa descobrir:

x = ?
a = ?
b = ?
c = ?
d = ?
e = ?
f = ?

Economizamos digitação e transferimos o custo para quem lê.

É como compactar o programa.

O desenvolvedor precisa executar mentalmente:

UNZIP ALGORITMO

antes de poder entendê-lo.

Código de produção vive muito mais tempo sendo lido do que sendo digitado.

Isso vale para COBOL.

Vale para JavaScript.

Vale para Java.

Vale para Python.

E valerá para a próxima linguagem da moda.

---

🧱 CAPÍTULO 19 — QUANDO NÃO USAR UMA LAMBDA GIGANTESCA

Isto é aceitável:

pedidos.filter(pedido => pedido.ativo);

Mas considere:

pedidos.filter(pedido =>
    pedido.ativo &&
    pedido.valor > 1000 &&
    pedido.cliente?.status !== "BLOQUEADO" &&
    pedido.itens.some(item => item.quantidade > 0)
);

Ainda funciona.

Mas talvez seja melhor escrever:

function pedidoElegivel(pedido) {
    return (
        pedido.ativo &&
        pedido.valor > 1000 &&
        pedido.cliente?.status !== "BLOQUEADO" &&
        pedido.itens.some(
            item => item.quantidade > 0
        )
    );
}

pedidos.filter(pedidoElegivel);

Agora o algoritmo principal diz:

filtre pedidos elegíveis.

A regra de elegibilidade está isolada.

Isso lembra muito:

PERFORM VALIDAR-PEDIDO

em vez de colocar 47 condições no meio do processamento principal.

---

🧭 CAPÍTULO 20 — O MÉTODO YUUYA PARA LER LAMBDAS

Encontrou:

usuarios
    .filter(u => u.ativo)
    .map(u => ({
        nome: u.nome,
        total: u.pedidos.reduce(
            (a, p) => a + p.valor,
            0
        )
    }))
    .filter(u => u.total > 1000);

Não entre em pânico.

Faça quatro passagens.

PASSO 1 — IDENTIFIQUE A ENTRADA

usuarios

Estamos trabalhando com usuários.

PASSO 2 — IGNORE AS LAMBDAS

Leia somente:

FILTER
MAP
FILTER

Já temos:

USUÁRIOS
   |
 FILTRAR
   |
TRANSFORMAR
   |
 FILTRAR

PASSO 3 — ABRA AS REGRAS EXTERNAS

Primeiro:

u => u.ativo

Somente usuários ativos.

Depois:

u => ({
    nome: u.nome,
    total: ...
})

Transforma usuário em:

NOME + TOTAL

Depois:

u => u.total > 1000

Mantém total superior a 1000.

PASSO 4 — ENTRE NA LAMBDA INTERNA

u.pedidos.reduce(
    (a, p) => a + p.valor,
    0
)

Tradução:

some os valores dos pedidos.

Resultado final:

USUÁRIOS
     |
     V
SOMENTE ATIVOS
     |
     V
CALCULAR NOME + TOTAL DOS PEDIDOS
     |
     V
TOTAL > 1000

Agora o código deixou de ser hieróglifo.

---

⚡ CAPÍTULO 21 — NÃO EXECUTE O PROGRAMA INTEIRO NA CABEÇA

Essa talvez seja a melhor dica deste artigo.

Programadores experientes não necessariamente entendem código complexo porque conseguem simular cinquenta instruções simultaneamente.

Eles reconhecem padrões.

Um operador de mainframe experiente olha:

IEFBR14

e não precisa analisar cada caractere.

Um programador COBOL olha:

PERFORM VARYING

e reconhece imediatamente um padrão.

Queremos construir o mesmo reflexo:

.filter(...)

→ seleção.

.map(...)

→ transformação.

.reduce(...)

→ agregação.

Depois disso, sua velocidade de leitura aumenta enormemente.

---

🎒 CAPÍTULO 22 — A DUNGEON TEM NÍVEIS DE ABSTRAÇÃO

Uma das grandes mudanças da programação moderna é o aumento do nível de abstração.

Antigamente poderíamos escrever:

PEGUE ELEMENTO
COMPARE
INCREMENTE
COPIE
VOLTE

Hoje escrevemos:

filter(...)

Isso não significa que o loop desapareceu.

Ele foi encapsulado.

Esse conceito é importantíssimo.

Abstração não elimina trabalho.

Abstração esconde implementação atrás de uma interface.

Quando fazemos:

SELECT *
FROM CLIENTES
WHERE ATIVO = 'S';

também não especificamos como o banco deve percorrer fisicamente cada página.

O SGBD resolve.

Um COBOLzeiro já trabalha com abstrações há décadas.

Talvez apenas não chamasse dessa maneira.

---

📜 CAPÍTULO 23 — CURIOSIDADE: COBOL TAMBÉM É UMA GRANDE ABSTRAÇÃO

Imagine explicar para um programador Assembly de décadas atrás:

ADD WS-VALOR TO WS-TOTAL

Ele poderia responder:

— Preguiçosos! Cadê os registradores?

😂

Toda geração acha que a próxima está escondendo detalhes demais.

Assembly abstraiu código de máquina.

COBOL abstraiu muitos detalhes da máquina.

SQL abstraiu mecanismos de acesso aos dados.

Bibliotecas abstraíram algoritmos.

Frameworks abstraíram infraestrutura.

filter, map e reduce abstraem padrões de iteração.

A história da programação é, em boa medida, a história da criação de abstrações.

---

🥚 EASTER EGG — 03:17 NA DUNGEON

Às 03:17, Yuuya encontra um programa:

const incidente =
    eventos
        .filter(evento => evento.critico)
        .find(evento => evento.hora === "03:17");

O operador pergunta:

— Encontrou a causa?

Yuuya responde:

— Não. Só encontrei correlação.

O veterano do mainframe sorri.

Finalmente alguém aprendeu troubleshooting.

Porque:

CORRELAÇÃO != CAUSALIDADE

Nem mesmo uma arrow function possui Cheat Skill suficiente para mudar isso.

---

🧰 CAPÍTULO 24 — EXERCÍCIO PARA TREINAR SEU CÉREBRO COBOL

Pegue:

transacoes
    .filter(t => t.aprovada)
    .map(t => t.valor)
    .reduce((total, valor) => total + valor, 0);

Não traduza sintaxe.

Faça:

ENTRADA:
TRANSAÇÕES

FILTER:
QUEM FICA?

APROVADAS

MAP:
VIRA O QUÊ?

VALOR

REDUCE:
ACUMULA COMO?

SOMA

Conclusão:

some o valor de todas as transações aprovadas.

Agora imagine o equivalente COBOL:

MOVE ZERO TO WS-TOTAL

PERFORM VARYING IDX FROM 1 BY 1
    UNTIL IDX > WS-QTD-TRANSACOES

    IF TRANSACAO-APROVADA(IDX) = 'S'
        ADD TRANSACAO-VALOR(IDX)
            TO WS-TOTAL
    END-IF

END-PERFORM

São dois estilos descrevendo essencialmente a mesma intenção.

---

🏆 CAPÍTULO 25 — QUANDO ARROW FUNCTIONS REALMENTE BRILHAM

Elas são especialmente convenientes quando a função é:

• pequena;

• local;

• usada uma única vez;

• semanticamente evidente;

• passada como callback;

• utilizada em transformação de coleções.

Por exemplo:

precos.map(preco => preco * 1.10);

Perfeitamente razoável.

Mas quando a lógica cresce, nomes podem ser superiores.

Em vez de:

clientes.filter(c =>
    c.a &&
    c.b &&
    !c.x &&
    c.y > 500
);

prefira algo como:

clientes.filter(clienteElegivel);

O nome carrega significado.

---

🧙 CAPÍTULO 26 — A REGRA DE OURO DE YUUYA

Depois de atravessar a dungeon, Yuuya escreve na parede:

Não tente entender a seta. Entenda o fluxo dos dados.

Essa é a mudança fundamental.

Diante de:

dados
    .filter(...)
    .map(...)
    .reduce(...)

pergunte:

DE ONDE VÊM OS DADOS?

QUEM SOBREVIVE?

NO QUE SE TRANSFORMAM?

COMO SÃO AGREGADOS?

QUAL É A SAÍDA?

Essas perguntas funcionam quase independentemente da linguagem.

---

☕ EPÍLOGO — O COBOLZEIRO VOLTA DA DUNGEON

Yuuya atravessou a porta para outro mundo e descobriu habilidades que inicialmente pareciam mágicas.

O programador COBOL pode passar por experiência semelhante quando encontra programação funcional moderna.

No começo:

x => x * 2

parece uma linguagem inventada por alguém que cobrava por caractere.

Depois entendemos:

RECEBE X
DEVOLVE X * 2

Então encontramos:

filter

e aprendemos:

QUEM FICA?

Encontramos:

map

e perguntamos:

VIRA O QUÊ?

Encontramos:

reduce

e finalmente percebemos:

ACUMULA COMO?

A dungeon deixa de parecer tão assustadora.

Arrow functions não foram criadas porque funções tradicionais estavam erradas.

Elas surgiram porque determinadas situações envolvem pequenos comportamentos usados localmente, especialmente callbacks e transformações de coleções, e escrever toda a cerimônia de uma função nomeada repetidamente pode tornar o código desnecessariamente verboso.

Mas existe uma lição ainda mais importante.

Concisão não é sinônimo de legibilidade.

Isto:

x.filter(a=>a.b).map(c=>c.d).reduce((e,f)=>e+f,0)

pode impressionar alguém pela quantidade de lógica comprimida em uma linha.

Mas software corporativo não é campeonato de quem digita menos.

O programa que você escreve hoje poderá ser investigado durante um incidente às 03:17 daqui a quinze anos.

Talvez por alguém que ainda nem entrou na empresa.

Talvez por um jovem programador.

Talvez por uma IA.

Talvez por você mesmo, tentando lembrar:

"Quem foi o animal que escreveu isso?"

E então o Git responde:

AUTHOR: VOCÊ
DATE: 2026

Nesse momento você compreenderá definitivamente por que nomes importam.

COBOL possui algo valioso para ensinar às linguagens modernas: software também é comunicação entre seres humanos.

Programação funcional possui algo igualmente valioso para ensinar ao COBOLzeiro: nem sempre precisamos descrever cada passo mecânico de uma transformação quando podemos expressar diretamente sua intenção.

O verdadeiro Cheat Skill não é decorar:

=>

É aprender a reconhecer:

ENTRADA
   |
   V
SELEÇÃO
   |
   V
TRANSFORMAÇÃO
   |
   V
AGREGAÇÃO
   |
   V
SAÍDA

Quando você começa a enxergar isso, deixa de tentar executar cada instrução mentalmente.

Você passa a enxergar a arquitetura do algoritmo.

E então aquela linha:

pedidos
    .filter(pedido => pedido.pago)
    .map(pedido => pedido.valor)
    .reduce((total, valor) => total + valor, 0);

deixa de parecer uma magia de outro mundo.

Você olha para ela e pensa:

PEDIDOS
  ↓
PAGOS
  ↓
VALORES
  ↓
SOMA

Yuuya guarda a espada.

O COBOLzeiro termina o café.

E a misteriosa porta => permanece aberta.

Desta vez, porém, não existe mais monstro do outro lado.

Existe apenas outra maneira de escrever algoritmos.

---

☕ COPYBOOK FINAL DO BELLACOSA MAINFRAME

Se quiser guardar apenas uma página deste artigo, guarde esta:

=>      RECEBE → DEVOLVE

FILTER  QUEM FICA?

MAP     VIRA O QUÊ?

FIND    QUAL DELES?

SOME    EXISTE ALGUM?

EVERY   TODOS?

REDUCE  ACUMULA COMO?

SORT    COMPARA COMO?

E diante de qualquer pipeline funcional:

1. DESCUBRA A ENTRADA.

2. LEIA SOMENTE OS NOMES DAS OPERAÇÕES.

3. IDENTIFIQUE O FLUXO DOS DADOS.

4. ABRA UMA LAMBDA DE CADA VEZ.

5. TROQUE => POR "RECEBE E DEVOLVE".

6. DÊ NOMES HUMANOS ÀS VARIÁVEIS.

7. SE A LAMBDA FICOU GRANDE DEMAIS,
   EXTRAIA UMA FUNÇÃO COM NOME.

8. NÃO EXECUTE O PROGRAMA INTEIRO
   NA CABEÇA.

9. RECONHEÇA PADRÕES.

10. LEMBRE-SE:
    MENOS CARACTERES != MENOS COMPLEXIDADE.

No fim das contas, seja em COBOL, JavaScript, Java, Python ou no próximo isekai tecnológico, continuamos fazendo a mesma coisa:

recebendo dados, tomando decisões, transformando informações e produzindo resultados.

A sintaxe muda.

A dungeon muda.

Os monstros ganham nomes novos.

Mas o algoritmo continua lá.

E um programador que aprende a enxergá-lo por trás da sintaxe já desbloqueou seu verdadeiro Cheat Skill.

Bellacosa Mainframe e 10 animes slice of life

10 animes Slice of Life sobre criação, evolução e desafios

O anime Usagi Drop (também conhecido como Bunny Drop) é um elogiado slice of life que aborda a temática da paternidade/cuidado de uma criança em circunstâncias inesperadas, focando no crescimento emocional dos personagens e no cotidiano da nova família. A ressalva do "limite ético" geralmente se refere ao final do mangá, que diverge drasticamente do anime.

Considerando o foco do anime (relação pura de cuidado, calor humano, cotidiano, amadurecimento e "família não convencional"), aqui está uma lista de 10 animes com temáticas semelhantes, todos dentro do limite ético e do gênero slice of life / drama familiar:

#	Anime	Ano de Lançamento	Autor (Mangaká Original)
1	Amaama to Inazuma (Doçura & Relâmpago)	2016	Gido Amagakure
2	Barakamon	2014	Satsuki Yoshino
3	Kakushigoto	2020	Kōji Kumeta
4	The Yakuza's Guide to Babysitting (Guia do Yakuza para Cuidar de Crianças)	2022	Tsukiya
5	Aishiteruze Baby (Aishiteruze Baby ★★)	2004	Yōko Maki
6	Udon no Kuni no Kiniro Kemari (Poco's Udon World)	2016	Shinomaru Nodoka
7	Somali to Mori no Kamisama (Somali e o Espírito da Floresta)	2020	Yako Gureishi
8	If It's for My Daughter, I'd Even Defeat a Demon Lord (Sewayaki Kitsune no Senko-san)	2019	CHIROLU (Light Novel)
9	Deaimon: Recipe for Happiness	2022	Ren Mochizuki
10	Chichin Puipui! (curta-metragem/ONA)	2013	Takashi Taniguchi

---

1. Amaama to Inazuma (Doçura & Relâmpago)

• Sinopse: Kōhei Inuzuka, um professor viúvo, está lutando para cozinhar refeições nutritivas para sua filha pequena, Tsumugi. Ao se deparar com Kotori Iida, uma de suas alunas, que oferece um jantar em sua casa, ele descobre que cozinhar com outras pessoas e compartilhar as refeições pode ser uma atividade deliciosa e fortalecedora de laços. O anime foca na culinária como meio de união familiar.

• Personagens Principais: Kōhei Inuzuka (Pai, professor), Tsumugi Inuzuka (Filha pequena), Kotori Iida (Colega de escola de Kōhei).

• Dica: Perfeito para quem ama a combinação de comida e conforto (iyashikei). As reações de Tsumugi à comida são um show à parte.

• Curiosidade: O mangaká, Gido Amagakure, costuma incluir receitas detalhadas no final de cada capítulo do mangá.

---

2. Barakamon

• Sinopse: Handa Seishuu, um jovem e talentoso calígrafo, é enviado para uma ilha remota após agredir um crítico de arte. Esperando encontrar paz para se concentrar em sua arte, ele encontra a agitada e caótica Naru Kotoishi, uma garotinha local. O relacionamento inesperado e as interações com os moradores da ilha forçam Handa a crescer como pessoa e como artista.

• Personagens Principais: Seishuu Handa (Calígrafo), Naru Kotoishi (Criança da ilha).

• Dica: É um excelente anime de desenvolvimento de personagem, mostrando como a ingenuidade de uma criança pode ensinar lições valiosas a um adulto.

• Curiosidade: O anime tem um spin-off chamado Handa-kun, que é uma comédia focada na vida de Handa no ensino médio, antes dos eventos de Barakamon.

---

3. Kakushigoto

• Sinopse: Kakushi Gotō é um mangaká de sucesso que desenha mangás com conteúdo adulto e um tanto questionável. Ele faz de tudo para esconder sua profissão da sua filha, Hime, que ele cria sozinho, acreditando que ela seria julgada e envergonhada se descobrisse seu segredo. O anime transita entre o hilário cotidiano de esconder a verdade e flashforwards mais emocionais.

• Personagens Principais: Kakushi Gotō (Pai, mangaká), Hime Gotō (Filha).

• Dica: Ótimo para quem gosta de comédia com um forte toque de drama familiar, semelhante à forma como Usagi Drop mistura fofura e a seriedade da paternidade.

• Curiosidade: O autor, Kōji Kumeta, é conhecido por seu estilo de comédia satírica e seu trabalho mais famoso é Sayonara Zetsubou Sensei.

---

4. The Yakuza's Guide to Babysitting (Guia do Yakuza para Cuidar de Crianças)

• Sinopse: Toru Kirishima é um yakuza temido conhecido por sua violência. Cansado de lidar com sua natureza destrutiva, seu chefe lhe dá a tarefa mais difícil de sua vida: ser o babá de sua filha de sete anos, Yaeka Sakuragi. O anime segue a transformação gradual de Toru e o vínculo crescente entre a dupla.

• Personagens Principais: Toru Kirishima (Yakuza, babá), Yaeka Sakuragi (Filha do chefe).

• Dica: Assim como Usagi Drop, mostra um adulto "durão" ou sem experiência se tornando responsável por uma criança, forçando-o a mudar de vida.

• Curiosidade: O contraste entre a aparência intimidante de Toru e seu jeito desajeitado, mas atencioso, com Yaeka é o motor da comédia e emoção.

---

5. Aishiteruze Baby (Aishiteruze Baby ★★)

• Sinopse: Kippei Katakura, um estudante do ensino médio popular e despreocupado, tem sua vida virada de cabeça para baixo quando sua tia, após um colapso nervoso, abandona sua filha de 5 anos, Yuzuyu Sakashita. Kippei é forçado a assumir a responsabilidade de cuidar da prima, descobrindo o peso e a alegria da paternidade responsável.

• Personagens Principais: Kippei Katakura (Estudante, primo/cuidador), Yuzuyu Sakashita (Prima de 5 anos).

• Dica: É um shoujo clássico com uma abordagem muito honesta sobre a responsabilidade e o amadurecimento através do cuidado. Tem uma forte semelhança temática com Usagi Drop.

• Curiosidade: O mangá aborda o desenvolvimento romântico de Kippei e como ele equilibra a vida escolar, social e a nova responsabilidade.

---

6. Udon no Kuni no Kiniro Kemari (Poco's Udon World)

• Sinopse: Souta Tawara, um web designer de 30 anos que trabalha em Tóquio, volta à sua cidade natal na província de Kagawa após a morte de seu pai. Lá, ele encontra um garoto misterioso (Poco) em seu antigo restaurante de udon. O garoto acaba sendo um tanuki (espécie de guaxinim mágico japonês) que assume a forma humana. Souta decide cuidar de Poco, redescobrindo sua cidade e lidando com memórias do seu pai.

• Personagens Principais: Souta Tawara (Web designer), Poco (Tanuki/Garoto).

• Dica: Mistura o calor humano e a temática familiar de Usagi Drop com elementos de fantasia suave. Focado na paisagem rural e na culinária regional.

• Curiosidade: A província de Kagawa é famosa no Japão pela produção de udon, e o anime faz um belo trabalho em mostrar a cultura e os pontos turísticos da região.

---

7. Somali to Mori no Kamisama (Somali e o Espírito da Floresta)

• Sinopse: Em um mundo habitado por espíritos, goblins e outras criaturas, onde os humanos foram quase extintos, um Golem (ser guardião da floresta com pouco tempo de vida) encontra uma garotinha humana chamada Somali. O Golem assume o papel de pai e embarca em uma jornada com Somali para encontrar outros humanos, tudo isso enquanto seu tempo de vida se esgota.

• Personagens Principais: Golem (Pai adotivo), Somali (Menina humana).

• Dica: Embora seja um anime de fantasia, o cerne da história é a relação paternal e a proteção incondicional, muito parecida com a de Usagi Drop e com uma grande carga emocional.

• Curiosidade: A animação é notável pela sua direção de arte e a beleza dos cenários de fantasia, transportando o espectador para um mundo visualmente rico e melancólico.

---

8. If It's for My Daughter, I'd Even Defeat a Demon Lord

• Sinopse: Dale, um aventureiro talentoso e reservado, encontra Latina, uma jovem garota demônio, abandonada em uma floresta. Sem conseguir deixá-la sozinha, ele a adota e se torna seu pai. A vida de aventureiro de Dale é substituída pelas alegrias e desafios da paternidade, enquanto ele faz tudo para proteger Latina.

• Personagens Principais: Dale (Aventureiro/Pai), Latina (Garota demônio/Filha).

• Dica: É uma série de fantasia que, na verdade, é um slice of life disfarçado. O foco está quase inteiramente nas interações adoráveis de Latina e no instinto superprotetor e carinhoso de Dale.

• Curiosidade: Assim como em Usagi Drop, a história original (light novel/mangá) também possui uma progressão que pode ser polêmica para alguns leitores, mas o anime de TV se concentra apenas na fase de paternidade/infância, mantendo o tom "fofo e ético".

---

9. Deaimon: Recipe for Happiness

• Sinopse: Nagomu Irino, de 30 anos, retorna à sua casa em Kyoto para assumir a tradicional loja de doces japoneses (wagashi) da família, depois que seu pai é hospitalizado. No entanto, ele descobre que a herdeira "escolhida" é Itsuka Yukihira, uma garota de 10 anos que foi acolhida pela família Irino. Nagomu e Itsuka aprendem a conviver, e ele assume um papel de mentor e figura familiar para a garota.

• Personagens Principais: Nagomu Irino (Filho que retorna), Itsuka Yukihira (Garota de 10 anos).

• Dica: Um anime calmante (iyashikei) que usa a culinária tradicional e a atmosfera de Kyoto para explorar as dinâmicas familiares, a responsabilidade e o conceito de lar.

• Curiosidade: O anime dedica bastante tempo a detalhes sobre a criação dos doces wagashi e sua conexão com as estações do ano, sendo também uma celebração da cultura local.

---

10. Chichin Puipui! (Curta-metragem/ONA)

• Sinopse: Um adorável curta-metragem/Original Net Animation que se passa em uma época mais antiga, acompanhando o dia a dia de um homem mais velho que cuida de sua neta pequena em uma casa rural. A história é simples, focada nos pequenos momentos de ternura, nas brincadeiras e no calor do lar, sem diálogo, apenas com música e sons ambientes.

• Personagens Principais: Avô, Neta.

• Dica: Se você gostou da atmosfera tranquila e da pura inocência infantil do anime Usagi Drop, este curta é uma dose concentrada desse sentimento.

• Curiosidade: O estilo de animação e o design de som criam uma atmosfera de conto de fadas, sendo um exemplo perfeito de como os animes podem evocar emoções fortes com uma simplicidade sublime.