✨ Bem-vindo ao meu espaço! ✨ Este blog é o diário de um otaku apaixonado por animes, tecnologia de mainframe e viagens. Cada entrada é uma mistura única: relatos de viagem com fotos, filmes, links, artigos e desenhos, sempre buscando enriquecer a experiência de quem lê. Sou quase um turista profissional: adoro dormir em uma cama diferente, acordar em um lugar novo e registrar tudo com minha câmera sempre à mão. Entre uma viagem e outra, compartilho também reflexões sobre cultura otaku/animes

sábado, 9 de novembro de 2019

Anime Manzai — Quando Igor Virou Boke, o Padawan COBOL Tentou Ser Tsukkomi e o Roteiro Deu ABEND de Tanto Rir

Bellacosa Mainframe apresenta o humor boke niponico

☕ Um Café no Bellacosa Mainframe

Anime Manzai — Quando Igor Virou Boke, o Padawan COBOL Tentou Ser Tsukkomi e o Roteiro Deu ABEND de Tanto Rir

Ou: por que duas pessoas discutindo uma bobagem podem ser mais engraçadas que uma sala inteira de efeitos especiais — e dez animes para entender a engrenagem

Antes de abrir a lista, um ajuste importante no JCL: manzai não é exatamente um gênero de anime. É uma forma tradicional de comédia japonesa, normalmente feita por uma dupla. Ela funciona com duas funções quase tão clássicas quanto READ, IF e PERFORM.

Boke: a pessoa que diz ou faz o absurdo, interpreta tudo errado, quebra a lógica.
Tsukkomi: a pessoa que reage, corrige, aponta a maluquice — muitas vezes com indignação calculada.

O boke diz: “Padawan, para melhorar o SORT, apaguei o arquivo de produção.”

O tsukkomi responde: “IGOR, ISSO NÃO É OTIMIZAÇÃO. ISSO É DELETE SEM BACKUP!”

Pronto: isso é o esqueleto do manzai.

No palco japonês, a dupla costuma conversar em ritmo acelerado, com o erro crescendo até que o tsukkomi puxa a realidade de volta pelo colarinho. No anime, a técnica ganhou novas formas: pode estar numa dupla, num trio, numa classe inteira ou num protagonista sério cercado por malucos. É a alma de muito gag anime, comédia escolar, paródia, isekai cômico e até histórias de ação.

O segredo não é somente “dizer uma piada”. É montar um pequeno programa:

PERFORM GERAR-ABSURDO
PERFORM DEIXAR-ABSURDO-CRESCER
PERFORM TSUKKOMI-REAGE
PERFORM VOLTAR-AO-CAOS

O bom manzai parece espontâneo, mas tem engenharia. O boke abre uma falha de lógica; o tsukkomi confirma que nós também vimos a falha; e o roteiro escala o problema até alguém sugerir colocar uma katana, uma nave alienígena ou uma diretiva ALTER dentro do incidente.

A seguir, não há um “ranking científico de quem é mais famoso” — isso seria pedir para Igor criar um comitê de governança de piadas. São dez portas de entrada muito conhecidas para entender o manzai em ação.

1. Gintama (銀魂) — 2006

Autores: mangá de Hideaki Sorachi.
Personagens-centrais: Gintoki Sakata, Shinpachi Shimura e Kagura.
Como a aventura se desenrola: em um Japão do período Edo ocupado por alienígenas, o ex-samurai Gintoki comanda a Yorozuya, uma agência de “faz-tudo”. Cada serviço idiota pode virar conspiração, luta de espada, crise existencial ou paródia de outra franquia.

Se o manzai tivesse um mainframe, Gintama seria o z/OS que continua funcionando mesmo depois de alguém instalar um aplicativo alienígena em produção. Gintoki é o boke preguiçoso e cínico; Kagura amplia a insanidade; Shinpachi é o pobre tsukkomi encarregado de avisar ao espectador que aquilo não é normal.

Por que funciona: Shinpachi não “explica a piada”; ele representa nossa auditoria interna. Quando Gintoki toma uma decisão sem sentido, ele registra o FILE STATUS emocional da cena.

Curiosidades e easter eggs:

A série é famosa por quebrar a quarta parede e zombar de mangás, animes, videogames e da própria produção.
Alterna arcos de humor absurdo com dramas de samurai surpreendentemente sérios.
A ambientação mistura Bakumatsu, ficção científica e cultura pop; essa gambiarra deliberada é parte do charme.

Para quem quer manzai com ação e grande elenco, esta é a porta principal. O mangá de Sorachi terminou em 2019, e o anime consolidou a mistura de samurai, ficção científica e metapiada. Visão geral de Gintama

2. Azumanga Daioh (あずまんが大王) — 2002

Autor: Kiyohiko Azuma.
Personagens-centrais: Chiyo Mihama, Tomo Takino, Yomi Mizuhara, Sakaki, Ayumu “Osaka” Kasuga e Yukari Tanizaki.
A aventura: acompanhar três anos de ensino médio de um grupo de garotas e professores excêntricos. Não existe “o vilão final”; existe a rotina sendo sabotada por personalidades incompatíveis.

É um ancestral importante da comédia escolar moderna. A obra veio de um mangá de quatro quadros, o yonkoma, formato que parece simples, mas exige precisão de relógio: introdução, desenvolvimento, virada e punchline.

Osaka é uma fábrica ambulante de boke: observa o mundo por uma lógica levemente desalinhada. Tomo também cria caos, enquanto Yomi frequentemente assume o papel de tsukkomi cansada de viver.

Easter egg de roteiro: o nome Azumanga Daioh não descreve a história; junta “Azuma” com “manga” e o nome da revista Dengeki Daioh. É como chamar uma aplicação COBOL de BELLACOSA-PROGRAMA-REVISTA: tecnicamente funciona, poeticamente ninguém sabe o que esperar.

Por que assistir: para entender que manzai não precisa de gritaria. Uma pausa, uma resposta deslocada e uma expressão facial podem fazer mais que dez explosões.

3. Nichijou (日常) — 2011

Autor: Keiichi Arawi.
Personagens-centrais: Yuuko Aioi, Mio Naganohara, Mai Minakami, Nano Shinonome e o Professor Hakase.
A aventura: a vida cotidiana de estudantes, uma robô adolescente, uma cientista-criança e um gato falante em uma cidade onde o ordinário é só uma camada fina sobre o delírio.

O título significa “cotidiano”, mas não confie no PROGRAM-ID. Uma discussão sobre dever de casa pode receber animação de batalha épica; um cervo pode ganhar importância tática; uma diretora pode cair de um dirigível.

Yuuko costuma ser a tsukkomi desesperada. Mai, com expressão quase neutra, é a boke de sabotagem silenciosa. O humor nasce do contraste entre uma reação gigantesca e um motivo minúsculo.

Lição Bellacosa: em Nichijou, a animação é parte da piada. É como gastar toda a capacidade do processador para imprimir “BOM DIA” — desproporcional, mas glorioso.

A adaptação da Kyoto Animation tem 26 episódios e transforma o absurdo cotidiano em espetáculo visual. Dados da obra e da adaptação

4. Danshi Kōkōsei no Nichijō (男子高校生の日常) — 2012

Título internacional: Daily Lives of High School Boys.
Autor: Yasunobu Yamauchi.
Personagens-centrais: Tadakuni, Hidenori Tabata e Yoshitake Tanaka.
A aventura: três estudantes transformam tédio escolar, conversas de corredor e fantasias adolescentes em operações que sempre terminam pior do que começaram.

É manzai na forma mais reconhecível: Hidenori e Yoshitake apresentam uma ideia absurdamente séria; Tadakuni tenta dizer “isso é ridículo”; os dois ignoram; a realidade cobra o preço.

A piada estrutural: Tadakuni é apresentado como protagonista, mas por ser o mais normal, muitas vezes fica de fora das situações “interessantes”. É uma ótima piada sobre roteiro: o homem que tem senso perde tempo de tela.

Para o padawan COBOL: pense nos dois amigos como quem propõe reescrever o sistema inteiro na sexta-feira; Tadakuni é o operador que pergunta se existe plano de retorno. Ninguém responde. O incidente continua.

A série tem 12 episódios e nasceu de mangá publicado na Gangan Online. Ficha da adaptação e premissa

5. Saiki Kusuo no Ψ-nan (斉木楠雄のΨ難) — 2016

Título internacional: The Disastrous Life of Saiki K.
Autor: Shūichi Asō.
Personagens-centrais: Kusuo Saiki, Riki Nendou, Shun Kaidou, Kokomi Teruhashi e Kineshi Hairo.
A aventura: Saiki nasceu com poderes psíquicos absurdos: telepatia, teleporte, visão de raio X, alteração de memória e mais. Seu sonho, ironicamente, é levar uma vida sem chamar atenção.

Saiki é um tsukkomi especial: quase não precisa falar em voz alta. Sua narração interna registra a estupidez coletiva com a frieza de um log de sistema. Nendou, incapaz de perceber qualquer sinal social, é o boke que atravessa todas as proteções.

Por que é brilhante: a premissa do herói superpoderoso é desmontada. A grande ameaça não é um demônio cósmico; é um colega insistente, uma turma barulhenta e a incapacidade de tomar café em paz.

Easter egg linguístico: o símbolo Ψ remete a “psi”, associado a poderes psíquicos. Não é enfeite de capa: o trocadilho está no próprio nome.

A obra de Asō foi adaptada para TV de 2016 a 2018, com continuação em 2019. Histórico da série

6. Kono Subarashii Sekai ni Shukufuku wo! (この素晴らしい世界に祝福を！) — 2016

Título curto: KonoSuba.
Autor original: Natsume Akatsuki; ilustrações das light novels por Kurone Mishima.
Personagens-centrais: Kazuma Satou, Aqua, Megumin e Darkness.
A aventura: Kazuma morre de forma humilhante e renasce num mundo de fantasia. Como vingança burocrática, leva a deusa Aqua consigo. Em vez de formar a equipe perfeita de RPG, reúne uma deusa inútil, uma maga que só lança uma explosão por dia e uma cruzada com preferências muito particulares.

Aqui o manzai é uma equipe inteira. Kazuma tenta ser o tsukkomi pragmático; Aqua prova que divindade não equivale a competência; Megumin resolve tudo com “EXPLOSION!”; Darkness torna qualquer missão mais difícil do que o necessário.

A sacada de roteiro: KonoSuba parodia o isekai. Onde outra série diria “o herói ganhou uma habilidade lendária”, esta pergunta: “ótimo; quem vai pagar a hospedagem, remover os sapos gigantes e corrigir a bagunça que vocês fizeram?”

Igor no grupo: seria contratado como “especialista em Db2”, invocaria EXPLOSION para limpar uma tabela temporária e exigiria aplausos.

A adaptação começou em 2016 e mantém a proposta da light novel: desmontar os clichês de fantasia por dentro. Ficha e origem de KonoSuba

7. Kaguya-sama wa Kokurasetai (かぐや様は告らせたい) — 2019

Título internacional: Kaguya-sama: Love Is War.
Autor: Aka Akasaka.
Personagens-centrais: Kaguya Shinomiya, Miyuki Shirogane, Chika Fujiwara, Yu Ishigami e Ai Hayasaka.
A aventura: dois estudantes brilhantes gostam um do outro, mas acreditam que confessar primeiro seria uma derrota. Então transformam romance escolar em guerra psicológica de escala completamente desnecessária.

Este é manzai como estratégia corporativa. Kaguya e Shirogane montam planos de nível “comitê executivo”; Chika entra como boke imprevisível e quebra o projeto; o narrador anuncia uma conversa banal como se fosse uma batalha de vida ou morte.

Roteiro: cada episódio pega uma situação pequena — uma mensagem, um guarda-chuva, uma ida ao cinema — e a transforma em xadrez emocional. O humor está na distância entre a grandeza do plano e a banalidade da necessidade humana.

Easter egg cultural: o título já declara a regra do jogo: “Kaguya quer que ele se confesse”. Não é romance convencional; é incidente de produção com dois gerentes negando que abriram o chamado.

8. Gekkan Shōjo Nozaki-kun (月刊少女野崎くん) — 2014

Título internacional: Monthly Girls’ Nozaki-kun.
Autora: Izumi Tsubaki.
Personagens-centrais: Chiyo Sakura, Umetarou Nozaki, Mikoto Mikoshiba e Yuzuki Seo.
A aventura: Chiyo tenta se declarar para Nozaki. Ele entende que ela quer ser sua assistente de mangá, porque ele secretamente publica shōjo manga sob o pseudônimo Yumeno Sakiko. A partir daí, romance e processo editorial viram uma máquina de mal-entendidos.

Nozaki é o boke com cara de arquivo fiscal: enorme, sério, metódico — e completamente incapaz de compreender a intenção romântica óbvia. Chiyo é a tsukkomi que tenta sobreviver ao fato de que seu amor virou estágio não remunerado.

Por que é especial: parodia os clichês de shōjo manga sem desprezar o gênero. A autora brinca com o “príncipe romântico”, a heroína tímida, a rival e a cena de confissão, mas dá humanidade aos personagens.

Detalhe técnico: também deriva de estrutura yonkoma. Cada cena é uma pequena transação: entrada, expectativa, erro de interpretação, resposta cômica.

9. Asobi Asobase (あそびあそばせ) — 2018

Autora: Rin Suzukawa.
Personagens-centrais: Hanako Honda, Olivia e Kasumi Nomura.
A aventura: três garotas formam um clube informal de passatempos. A expressão “passatempo” inclui jogos infantis, competições sem sentido, chantagens sociais, invenções questionáveis e decisões que jamais passariam por uma reunião de mudança.

Não se deixe enganar pela abertura leve e fofinha. Asobi Asobase pode mudar de “comédia escolar” para “relatório de incidente psicológico” num corte de câmera.

Olivia finge ser estrangeira e, por isso, fala japonês de forma propositalmente estranha; Hanako inicia boa parte das catástrofes; Kasumi tenta preservar alguma sanidade. Em teoria, Kasumi seria tsukkomi. Na prática, a própria série corrói essa função até ninguém escapar inteiro.

Easter egg de atmosfera: a diferença brutal entre a aparência delicada e os gritos, caretas e situações grotescas é uma piada estrutural. É o equivalente anime de uma tela ISPF bonita que abre um job com 4.000 linhas de JCL herdado.

A adaptação de 2018 tem 12 episódios e vem do mangá de Rin Suzukawa. Premissa e dados principais

10. Hinamatsuri (ヒナまつり) — 2018

Autor: Masao Ohtake.
Personagens-centrais: Hina, Yoshifumi Nitta, Anzu e Hitomi Mishima.
A aventura: uma cápsula cai no apartamento de Nitta, integrante da yakuza. Dentro dela está Hina, garota com poderes telecinéticos e uma expressão de quem acaba de pedir sushi sem dinheiro. Nitta, contra toda a lógica, torna-se sua figura paterna.

O arranjo é perfeito: Nitta é o tsukkomi adulto, disciplinado e constantemente derrotado; Hina é a boke de poderes cósmicos com prioridades simples, como comer e não fazer esforço. Depois chegam outros personagens e a obra alterna comédia absurda, carinho e crescimento pessoal.

O golpe de mestre: embaixo da premissa ridícula existe uma história genuína de família improvisada. Hina não precisa “aprender uma lição” a cada episódio; ela muda devagar, e Nitta muda junto.

Curiosidade: Hinamatsuri também é o nome do festival japonês das bonecas, mas aqui o título conversa diretamente com a protagonista Hina — uma “boneca” que consegue demolir a sala se ficar contrariada.

O mapa mental do padawan: como reconhecer manzai

Elemento	No palco	No anime	No mainframe de Igor
Boke	Faz a afirmação absurda	Personagem-caos	“Rodei em produção para testar”
Tsukkomi	Corrige e reage	Personagem-lúcido	“Você abriu a mudança?”
Escalada	A ideia fica mais errada	A cena ganha camadas	“Também alterei o parâmetro global”
Punchline	A resposta final desmonta tudo	Corte, expressão, silêncio ou grito	`JOB ENDED - CONDITION CODE 4096`

A diferença essencial é esta: o boke não é simplesmente burro, e o tsukkomi não é simplesmente inteligente. Eles são peças de ritmo. Um cria a quebra de expectativa; o outro dá forma à quebra; o público ri porque reconhece a distância entre o que deveria acontecer e o que aconteceu.

É por isso que Gintama pode colocar samurais contra alienígenas, Kaguya-sama pode tratar um convite banal como guerra total e Nichijou pode animar uma conversa comum como se fosse o fim da civilização. O manzai dá permissão para o absurdo existir — mas exige que alguém, mesmo por dois segundos, olhe para Igor e diga:

“Não. Você não pode aplicar COMMIT numa piada antes do punchline.”

E essa é a regra final do Café no Bellacosa Mainframe: em comédia, como em COBOL, a estrutura importa. Mas uma boa estrutura só fica memorável quando alguém entra pela porta errada, carrega uma melancia, chama aquilo de interface de integração e obriga o tsukkomi a salvar o sistema.

sexta-feira, 8 de novembro de 2019

🎩 Mandrake e o Grande Espetáculo dos Testes de Software

Bellacosa Mainframe e o mago dos Testes de Software

☕ Um Café no Bellacosa Mainframe

🎩 Mandrake e o Grande Espetáculo dos Testes de Software

Manual Testing, STLC, Test Cases, Test Data, defeitos, regressão e a arte de descobrir que o sistema nunca fez exatamente aquilo que jurava fazer

“Senhoras e senhores, observem atentamente. O programa funciona. Agora começa o truque.”

Há algo profundamente mágico no desenvolvimento de software.

Um programador recebe requisitos, transforma ideias em código, compila aquilo, executa o programa e, finalmente, a tela responde:

PROCESS COMPLETED SUCCESSFULLY
RETURN CODE = 0000

A plateia aplaude.

O gerente respira aliviado.

O desenvolvedor fecha o notebook.

E, sentado discretamente na primeira fila, Mandrake não aplaude.

Ele observa.

Porque todo mágico conhece uma regra fundamental:

aquilo que você vê não necessariamente corresponde ao que realmente aconteceu.

E talvez essa seja uma das melhores maneiras de compreender Software Testing.

O tester profissional não está tentando provar que o programa funciona.

Está tentando descobrir em quais circunstâncias ele deixa de funcionar.

É aí que começa nosso espetáculo.

🎩 ATO I — O programa que jurava estar funcionando

Imagine um pequeno programa COBOL:

IF SALDO >= VALOR-COMPRA
    SUBTRACT VALOR-COMPRA FROM SALDO
    MOVE 'APROVADA' TO STATUS-COMPRA
ELSE
    MOVE 'NEGADA' TO STATUS-COMPRA
END-IF.

Executamos:

SALDO        = 1000
VALOR-COMPRA = 100

Resultado:

STATUS = APROVADA
SALDO  = 900

Fantástico.

O programa funciona!

Mandrake levanta uma sobrancelha.

— Funciona?

Experimentemos então:

SALDO = 1000
VALOR-COMPRA = 1000

Funciona.

Agora:

SALDO = 1000
VALOR-COMPRA = 1001

Negada.

Muito bem.

Mas Mandrake continua:

VALOR-COMPRA = 0

Depois:

VALOR-COMPRA = -100

Depois:

VALOR-COMPRA = 999999999999999

Depois uma transação duplicada.

Depois duas transações simultâneas.

Depois Db2 indisponível.

Depois MQ demora 30 segundos para responder.

Depois o programa sofre ABEND entre o débito e o COMMIT.

Depois o mesmo arquivo é submetido novamente pelo scheduler.

De repente, aquele simples:

IF SALDO >= VALOR-COMPRA

transformou-se numa investigação.

Bem-vindo ao teste de software.

O próprio currículo atual do ISTQB coloca os fundamentos, testes ao longo do ciclo de desenvolvimento, testes estáticos, técnicas de teste, gerenciamento de riscos, defeitos e ferramentas dentro da formação básica do profissional. Ou seja: testar está muito além de simplesmente executar uma tela e verificar se apareceu a mensagem correta. (ISTQB)

🪄 ATO II — QA, QC e Testing: três truques diferentes

Nas anotações que analisamos aparecem três conceitos importantes:

Quality Assurance, Quality Control e Testing.

Podemos imaginá-los no teatro de Mandrake.

QA — Quality Assurance tenta impedir que o truque seja preparado de maneira errada.

Pergunta:

Nosso processo permite produzir software de qualidade?

QA olha para padrões, processos, revisões, métodos, critérios e prevenção.

QC — Quality Control examina aquilo que foi produzido.

Pergunta:

Este produto possui a qualidade esperada?

E finalmente temos Testing.

O tester coloca o produto diante dele e pergunta:

O que acontece se eu fizer isto?

E então começa a puxar as cortinas.

Mas há uma sutileza importante: testing não significa apenas executar programas. O processo moderno também inclui testes estáticos, como revisão de requisitos, documentação, código e outros artefatos antes mesmo da execução do software. Isso aparece explicitamente no CTFL atual. (ISTQB)

Essa é uma das grandes mágicas econômicas da engenharia de software:

encontrar um problema antes de ele virar código.

🔮 ATO III — Error → Defect → Failure

Mandrake coloca três cartas sobre a mesa:

ERROR
DEFECT
FAILURE

Parecem semelhantes.

Não são.

Imagine que alguém escreve um requisito:

Clientes com saldo >= valor da compra
podem realizar a transação.

O programador interpreta errado e escreve:

IF SALDO > VALOR-COMPRA

em vez de:

IF SALDO >= VALOR-COMPRA

O engano humano está na origem.

Esse engano produz um defeito no software.

Quando alguém possui:

SALDO = 100
COMPRA = 100

e o sistema responde:

TRANSACTION DECLINED

temos a manifestação observável do problema: uma falha.

Portanto, conceitualmente podemos imaginar:

ERRO HUMANO
     ↓
DEFEITO INTRODUZIDO
     ↓
CONDIÇÃO ESPECÍFICA
     ↓
EXECUÇÃO
     ↓
FALHA OBSERVÁVEL

E aqui existe um princípio precioso.

Um defeito pode permanecer escondido durante anos.

Ele somente aparece quando determinadas condições o ativam.

O código pode ter sido executado milhões de vezes sem problema.

Até que chega:

29/02

ou:

31/12 23:59:59

ou um campo com valor máximo.

Ou um registro duplicado.

Ou alguém finalmente passa pelo caminho lógico esquecido.

O coelho sempre esteve dentro da cartola.

Apenas ninguém havia olhado direito.

🎭 ATO IV — SDLC: preparando o palco

Antes do espetáculo existe toda uma produção.

No desenvolvimento clássico temos algo semelhante a:

REQUISITOS
    ↓
DESIGN
    ↓
DESENVOLVIMENTO
    ↓
TESTES
    ↓
DEPLOYMENT
    ↓
MANUTENÇÃO

Isso é uma representação simplificada do Software Development Life Cycle — SDLC.

Mas cuidado com uma ilusão muito comum:

CODING → TESTING

pode sugerir que testing começa depois da programação.

Em engenharia moderna isso é uma simplificação perigosa.

Testes podem começar no requisito.

Mandrake recebe:

“O sistema deverá responder rapidamente.”

Ele imediatamente pergunta:

Quanto é rapidamente?

200 milissegundos?

Dois segundos?

Dez?

Sob qual volume?

Com quantos usuários?

Em qual infraestrutura?

Perceba o truque.

Acabamos de testar um requisito sem executar uma única linha de código.

Essa integração entre testing e diferentes modelos de desenvolvimento é justamente parte da abordagem atual do CTFL, que considera Waterfall, Agile, DevOps e Continuous Delivery. (ISTQB)

🪄 ATO V — Waterfall, V-Model, Iterative, Incremental e Spiral

As anotações apresentam vários modelos.

No Waterfall, as etapas parecem uma escada:

Requirements
      ↓
Design
      ↓
Development
      ↓
Testing
      ↓
Deployment

É fácil de compreender e administrar quando requisitos são relativamente estáveis.

O problema aparece quando descobrimos tarde que o requisito inicial estava errado.

O V-Model melhora a conversa entre desenvolvimento e teste.

De um lado:

Requirements
System Design
Architecture
Coding

Do outro:

Acceptance Testing
System Testing
Integration Testing
Component Testing

A ideia essencial é poderosa:

cada nível de construção deve possuir alguma forma correspondente de verificação ou validação.

Já abordagens iterativas e incrementais quebram a entrega em pedaços menores.

Mandrake prefere pequenos truques verificáveis a esperar dois anos pelo desaparecimento completo do elefante.

E o Spiral Model acrescenta explicitamente algo fundamental:

risco.

Quanto maior o risco, maior deve ser nossa atenção.

Isso nos conduz ao Risk-Based Testing.

Um botão que altera a cor de um avatar e uma rotina que liquida R$ 500 milhões não deveriam receber exatamente a mesma prioridade de testes.

Probabilidade × impacto muda completamente a estratégia.

O gerenciamento de riscos também está explicitamente presente no currículo contemporâneo do ISTQB. (ISTQB)

🎩 ATO VI — STLC: o espetáculo dentro do espetáculo

Se SDLC organiza o desenvolvimento, o Software Testing Life Cycle organiza o trabalho de testing.

Uma representação didática é:

Requirement Analysis
        ↓
Test Planning
        ↓
Test Case Development
        ↓
Environment Setup
        ↓
Test Execution
        ↓
Defect Reporting
        ↓
Test Closure

Mas não devemos imaginar isso obrigatoriamente como uma ferrovia em que o trem nunca volta.

Na prática:

Requirement
     ↓
Test
     ↓
Defect
     ↓
Requirement reconsidered
     ↓
Code changed
     ↓
New test
     ↓
Regression

O próprio ISTQB observa que os níveis de teste podem se sobrepor temporalmente em modelos iterativos. (ISTQB)

Testing é muito mais uma espiral de descoberta do que uma simples linha reta.

🃏 ATO VII — Os níveis do teste

Nas anotações encontramos:

Unit
Integration
System
Acceptance

Excelente modelo mental inicial.

Mas aqui Mandrake tira outra carta da manga.

O CTFL atual descreve formalmente cinco níveis:

Component
Component Integration
System
System Integration
Acceptance

(ISTQB)

Isso é particularmente interessante para quem trabalha com mainframe.

Imagine:

COBOL PROGRAM
     ↓
Db2
     ↓
CICS
     ↓
MQ
     ↓
z/OS Connect
     ↓
API
     ↓
Mobile App

Testar apenas o COBOL não testa o sistema.

Talvez o COBOL esteja perfeito.

Talvez a API esteja perfeita.

Mas:

API JSON
   ↓
z/OS Connect
   ↓
COMMAREA

pode estar convertendo incorretamente:

100.50

para:

Cada componente funciona.

A integração está errada.

Esse é um dos defeitos mais traiçoeiros da computação.

Todos os mágicos fizeram seus truques corretamente.

Mas o espetáculo fracassou.

🪄 ATO VIII — Functional e Non-Functional Testing

Agora Mandrake coloca duas caixas no palco.

Na primeira:

O QUE O SISTEMA FAZ?

Na segunda:

COMO O SISTEMA FAZ?

A primeira nos conduz ao Functional Testing.

Exemplo:

COMPRA = R$ 100
LIMITE = R$ 500

Esperado:

APROVADA

Estamos verificando uma regra funcional.

Mas suponha que a autorização leve:

37 segundos

Funcionalmente está correta.

Operacionalmente talvez seja desastrosa.

Entramos então no Non-Functional Testing:

performance, segurança, usabilidade, confiabilidade, escalabilidade, compatibilidade, acessibilidade e outras características de qualidade.

O CTFL atual trata tipos de teste como grupos de atividades ligados a características específicas e observa que eles podem aparecer em diferentes níveis de teste. (ISTQB)

Ou seja:

nível e tipo são dimensões diferentes.

Essa distinção vale ouro.

🧙 ATO IX — Black Box: Mandrake não quer saber como funciona

Temos uma máquina.

Entrada:

AGE = 30

Saída:

ACCEPTED

Mandrake não vê o código.

Ele conhece apenas a especificação:

18 <= AGE <= 60

Podemos então usar Equivalence Partitioning.

Em vez de testar todos os números possíveis, dividimos o universo:

< 18       INVALID
18..60     VALID
> 60       INVALID

Selecionamos representantes:

10
30
70

Três testes cobrem conceitualmente três classes.

É uma maneira elegante de reduzir uma quantidade praticamente infinita de possibilidades.

🎩 ATO X — Boundary Value Analysis: o mágico encontra um erro nas próprias anotações

E aqui acontece algo maravilhoso.

Temos:

IDADE PERMITIDA = 18 até 60

Uma análise de fronteira típica poderia testar:

Porque bugs adoram morar nas fronteiras:

<
<=
>
>=

Mas uma das imagens das nossas próprias anotações apresenta a sequência:

17  18  19  60  61

e ainda associa incorretamente os rótulos próximos ao máximo.

🎩 ABRACADABRA!

Encontramos um defeito num material que ensina como encontrar defeitos.

Esse será nosso Easter Egg.

🐇 Easter Egg Bellacosa #03:17: o primeiro bug do curso estava escondido justamente no capítulo sobre Boundary Value Analysis.

Não poderia existir demonstração melhor.

O tester precisa testar até mesmo aquilo que lhe ensina a testar.

🃏 ATO XI — Decision Table

Agora imagine autorização de cartão:

Cartão ativo?
Senha correta?
Limite disponível?
Suspeita de fraude?

Temos combinações.

Ativo	Senha	Limite	Fraude	Resultado
S	S	S	N	Aprovar
N	S	S	N	Negar
S	N	S	N	Negar
S	S	N	N	Negar
S	S	S	S	Revisar/Negar

Isso é perfeito para Decision Table Testing.

Em COBOL poderíamos encontrar:

EVALUATE TRUE
    WHEN CARTAO-BLOQUEADO
         PERFORM NEGAR-COMPRA

    WHEN SENHA-INVALIDA
         PERFORM NEGAR-COMPRA

    WHEN SEM-LIMITE
         PERFORM NEGAR-COMPRA

    WHEN SUSPEITA-FRAUDE
         PERFORM ANALISAR-COMPRA

    WHEN OTHER
         PERFORM APROVAR-COMPRA
END-EVALUATE.

Cada WHEN é praticamente Mandrake dizendo:

“Mostre-me sua próxima carta.”

🔮 ATO XII — State Transition

Existem sistemas nos quais o resultado depende não apenas da entrada atual, mas do estado anterior.

Cartão:

ACTIVE
  ↓
3 senhas erradas
  ↓
BLOCKED

Agora tente a senha correta.

O sistema deveria desbloquear automaticamente?

Provavelmente não.

Então temos:

STATE + EVENT → NEW STATE

Isso é State Transition Testing.

Em mainframe isso aparece por toda parte:

NEW
AUTHORIZED
CAPTURED
SETTLED
REVERSED
CANCELLED

Uma transação SETTLED talvez não possa simplesmente voltar para NEW.

O tester procura transições permitidas e, principalmente, transições proibidas.

🪄 ATO XIII — Error Guessing: a experiência entra no palco

Depois de alguns anos trabalhando com sistemas, desenvolvemos algo curioso.

Vemos:

PIC 9(5)

e imediatamente pensamos:

99999?
00000?
SPACE?
-1?
100000?

Vemos:

DIVIDE A BY B

e pensamos:

B = ZERO?

Vemos:

SQL INSERT

e pensamos:

DUPLICATE KEY?

Vemos arquivo batch:

INPUT-FILE

e perguntamos:

arquivo vazio?
registro truncado?
layout errado?
duplicado?
EBCDIC/ASCII?
campo COMP-3 inválido?

Isso é experiência transformada em técnica.

É o velho programador olhando para a cartola e dizendo:

“Eu conheço esse truque.”

🎭 ATO XIV — O Test Case

Um bom test case deveria permitir que outra pessoa reproduzisse nossa experiência.

Por exemplo:

TC-CARD-017

Objetivo:
Validar compra exatamente no limite disponível.

Precondition:
Cartão ACTIVE
Limite disponível = R$ 1.000

Input:
Compra = R$ 1.000

Expected:
Authorization = APPROVED
Available Limit = R$ 0
Transaction recorded once

Actual:
...

Status:
PASS / FAIL

Repare no detalhe:

Não basta escrever:

Expected = SUCCESS

Precisamos saber o que significa sucesso.

Esse é o conceito do test oracle: de onde vem nossa certeza sobre o resultado esperado?

Pode ser uma regra de negócio, requisito, cálculo independente, especificação, sistema anterior ou conhecimento validado do domínio.

Porque existe uma situação deliciosamente cruel:

o software pode produzir exatamente o resultado descrito no test case e ambos estarem errados.

🧪 ATO XV — Test Data: os objetos escondidos na manga

Um teste maravilhoso com dados ruins continua sendo um teste ruim.

Para idade 18–60 podemos preparar:

VALID
25
30
45

INVALID
-5
70
ABC

BOUNDARY
17
18
19
59
60
61

No mainframe a brincadeira fica muito mais interessante.

Imagine:

05 WS-AMOUNT PIC S9(9)V99 COMP-3.

Mandrake começa imediatamente a imaginar:

ZERO
NEGATIVO
MÁXIMO
CENTAVOS
SINAL INVÁLIDO
PACKED DECIMAL CORROMPIDO
CAMPO TRUNCADO

E alguém na plateia grita:

S0C7!

Exatamente.

Agora estamos conversando.

🏰 ATO XVI — Test Environment

Um teste não acontece no vazio.

Temos:

DEV
 ↓
QA
 ↓
STAGING
 ↓
PRODUCTION

Mas “funcionou em QA” não significa necessariamente:

funcionará em PROD

Talvez QA tenha:

1.000 registros

e produção:

800 milhões.

Talvez QA tenha uma LPAR praticamente ociosa.

Produção possui WLM disputando recursos.

Talvez QA utilize outra configuração de Db2.

Outro RACF.

Outra versão de copybook.

Outra configuração MQ.

Outro timeout.

Outra quantidade de initiators.

Outra definição CICS.

Esse fenômeno possui um inimigo conhecido:

environment drift.

Quanto maior a diferença entre os ambientes relevantes, maior a possibilidade de o teste produzir confiança falsa.

🐇 ATO XVII — Defect Management

Finalmente Mandrake captura o coelho.

Agora precisamos documentá-lo.

Um fluxo possível:

NEW
 ↓
ASSIGNED
 ↓
OPEN
 ↓
IN PROGRESS
 ↓
FIXED
 ↓
RETEST
 ↓
VERIFIED
 ↓
CLOSED

Se ainda falhar:

REOPEN

Mas isso não é uma lei universal.

Cada organização pode possuir seu próprio workflow.

O mesmo vale para:

P0
P1
P2
P3

Aliás, as próprias anotações analisadas usam convenções diferentes em páginas distintas: numa delas P1 aparece como crítico; em outra, P0 é crítico.

Outro pequeno coelho escondido.

Isso demonstra algo importante:

Priority é convenção organizacional.

Já a distinção conceitual é mais importante:

SEVERITY
= qual o impacto do defeito?

PRIORITY
= quão urgentemente queremos resolvê-lo?

Um erro ortográfico na página inicial de um grande banco pode ter baixa severidade técnica e prioridade altíssima.

Um defeito grave em funcionalidade raramente utilizada pode possuir severidade alta e prioridade temporariamente menor.

🔁 ATO XVIII — Retest não é Regression

Mandrake quebra uma carta.

O desenvolvedor cola.

Mandrake verifica a carta.

Isso é confirmation/retest:

O defeito específico foi corrigido?

Mas Mandrake pergunta:

E ao colar esta carta você rasgou outra?

Isso é regression testing.

O currículo atual do ISTQB trata confirmation testing e regression testing como conceitos distintos justamente por essa razão. (ISTQB)

Imagine:

BUG:
cálculo de juros incorreto.

Correção realizada.

Retest:

juros agora corretos.

Excelente.

Regression:

parcelamento?
estorno?
fatura?
pagamento mínimo?
limite?
contabilidade?
extrato?

O bug morreu.

Agora precisamos descobrir se ele levou algum vizinho junto.

🖥️ ATO XIX — Mandrake entra numa LPAR

E aqui nosso espetáculo chega ao território Bellacosa Mainframe.

Mandrake encontra:

JCL
 ↓
COBOL
 ↓
VSAM
 ↓
Db2
 ↓
CICS
 ↓
MQ
 ↓
APIs

E percebe imediatamente que o RC=0000 é apenas o começo.

Um tester de mainframe deveria aprender a procurar evidências em coisas como:

RETURN-CODE
SQLCODE
CICS RESP
RESP2
ABEND CODE
JESMSGLG
JESJCL
JESYSMSG
SYSOUT
CEEDUMP

Imagine um JOB:

STEP01 → SORT
STEP02 → COBOL
STEP03 → Db2
STEP04 → REPORT

O JOB termina:

MAXCC=0000

Tudo certo?

Mandrake responde:

Quantos registros entraram?

1.000.000

Quantos foram processados?

999.998

Quantos foram rejeitados?

Então onde estão dois registros?

🎩 Eis o truque.

🧮 ATO XX — Reconciliation: a mágica que salva dinheiro

Em sistemas financeiros existe uma forma particularmente poderosa de testing:

reconciliação.

Podemos estabelecer invariantes:

INPUT =
PROCESSED +
REJECTED

ou:

SALDO ANTERIOR
+ CRÉDITOS
- DÉBITOS
= SALDO FINAL

Agora imagine:

INPUT      = 10.000
PROCESSED  = 9.997
REJECTED   = 2

Temos:

10.000 ≠ 9.997 + 2

Um registro desapareceu.

Não sabemos ainda onde.

Mas sabemos que há alguma coisa atrás da cortina.

Isso é extraordinariamente importante em cartões, pagamentos, bancos, seguros e processamento batch.

O resultado bonito na tela não basta.

Precisamos provar que os números fecham.

💥 ATO XXI — O teste favorito de Mandrake: quebrar no meio

Agora imagine processamento:

READ TRANSACTION
      ↓
UPDATE ACCOUNT
      ↓
WRITE HISTORY
      ↓
SEND MQ
      ↓
COMMIT

Mandrake desliga alguma coisa exatamente aqui:

UPDATE ACCOUNT
      ↓
       💥

E pergunta:

O que acontece agora?

Rollback?

Commit parcial?

Registro inconsistente?

Mensagem perdida?

Duplicação durante restart?

É aqui que testing deixa de ser simplesmente “clicar na tela”.

Em sistemas críticos precisamos testar:

RESTART
RECOVERY
ROLLBACK
REPROCESSING
DUPLICATE DELIVERY
TIMEOUT
DEADLOCK
PARTIAL FAILURE

Porque produção possui um talento extraordinário para criar condições que ninguém imaginou durante a happy path.

🧙‍♂️ ATO XXII — O S0C7 escondido na cartola

Considere:

05 WS-AMOUNT PIC S9(7)V99 COMP-3.

Tudo funciona durante meses.

Até chegar um registro corrompido.

O programa tenta executar uma operação aritmética.

💥

S0C7

O defeito talvez não esteja exatamente na instrução que sofreu o ABEND.

Pode ter começado muito antes:

arquivo
 ↓
layout incorreto
 ↓
campo deslocado
 ↓
dados inválidos
 ↓
operação decimal
 ↓
S0C7

O tester não pode perguntar apenas:

Onde explodiu?

Precisa perguntar:

Onde começou a cadeia causal que permitiu a explosão?

Isso é pensamento investigativo.

🔐 ATO XXIII — Segurança também faz parte do espetáculo

Suponha:

USER = VAGNER
ROLE = VIEWER

Ele deveria consultar relatório.

Mas consegue alterar registros.

Funcionalmente o botão funciona perfeitamente.

O problema é justamente esse.

Ele não deveria funcionar para aquele usuário.

Portanto testamos:

AUTHENTICATION
       ↓
Quem é você?

AUTHORIZATION
       ↓
O que você pode fazer?

No mundo mainframe isso imediatamente lembra RACF e os controles existentes ao redor de datasets, transações, recursos e identidades.

O verdadeiro teste negativo seria:

Mostre que Vagner consegue acessar aquilo que deve acessar.

e também:

Mostre que Vagner não consegue acessar aquilo que não deve acessar.

A segunda parte frequentemente é mais valiosa.

🤖 ATO XXIV — Manual Testing versus Automation

E chegamos à falsa guerra:

MANUAL
   VS
AUTOMATION

Não existe necessidade dessa guerra.

Automação é fantástica para:

regressão repetitiva
grandes massas
execuções frequentes
CI/CD
comparações
APIs
checks determinísticos

O ser humano continua excelente em:

exploração
investigação
ambiguidade
usabilidade
novos comportamentos
descoberta

A automação executa rapidamente aquilo que alguém ensinou a procurar.

O tester humano pode perguntar:

E se fizermos algo que ninguém colocou no script?

Essa pergunta continua perigosíssima.

O próprio CTFL inclui benefícios e riscos da automação como parte da formação fundamental, em vez de tratá-la como substituta universal do testing humano. (ISTQB)

🔍 ATO XXV — Exploratory Testing: Mandrake abandona o roteiro

Existe ainda uma atividade que merece espaço especial.

Mandrake recebe o sistema sem um roteiro de cinquenta páginas.

Ele começa a explorá-lo.

Aprende enquanto testa.

Testa enquanto aprende.

Observa uma resposta estranha.

Segue aquela pista.

Encontra outra.

Isso é a essência do exploratory testing.

Não significa sair clicando aleatoriamente.

Um bom explorador possui objetivo, conhecimento, heurísticas, observação e documentação.

É jazz.

Não ausência de música.

📊 ATO XXVI — “97% dos testes passaram!”

Mandrake olha para o dashboard:

10.000 TEST CASES

PASS = 9.700
FAIL = 300

PASS RATE = 97%

O gerente comemora.

Mandrake pergunta:

Quais foram os 300 que falharam?

Resposta:

Transferência bancária
Autorização
Liquidação
Recovery
Login administrativo

Então os 97% significam quase nada.

Métricas sem contexto também fazem ilusionismo.

Podemos possuir:

99,9% PASS

e ainda assim ter um sistema impossível de colocar em produção.

Por isso testing baseado em risco é tão importante.

Não contamos apenas testes.

Precisamos saber o que eles protegem.

🎩 ATO XXVII — O verdadeiro Testing Pyramid

A famosa pirâmide costuma aparecer assim:

           /\
          /UI\
         /----\
        / API  \
       /--------\
      / UNIT     \
     /____________\

Muitos testes pequenos e baratos próximos aos componentes.

Menos testes grandes e caros no topo.

É uma heurística útil.

Não uma lei da física.

Em mainframe talvez nossa realidade tenha:

UNIT / COMPONENT
       ↓
BATCH PROGRAM
       ↓
DB2 / VSAM
       ↓
CICS / MQ
       ↓
SYSTEM INTEGRATION
       ↓
END-TO-END

A arquitetura deveria orientar a estratégia.

Não um desenho bonito encontrado num PowerPoint.

🕯️ ATO XXVIII — Shift Left e Shift Right

Mandrake agora realiza seu último truque.

Move testing para a esquerda:

REQUIREMENT
DESIGN
CODE
BUILD
TEST
DEPLOY

Shift Left significa encontrar problemas mais cedo.

Revisar requisitos.

Testar regras.

Executar análise estática.

Criar testes junto com desenvolvimento.

Mas Mandrake também olha para a direita.

Depois do deployment podemos aprender com:

monitoring
telemetry
synthetic transactions
canary releases
observability
production feedback

Isso é parte da mentalidade de Shift Right.

Não significa transformar produção num laboratório irresponsável.

Significa reconhecer uma realidade:

nenhum ambiente reproduz completamente o mundo real.

🧠 ATO FINAL — O tester não caça bugs; caça confiança falsa

Depois de tudo isso, podemos resumir o aprendizado das anotações numa transformação mental.

O iniciante olha para:

INPUT → PROGRAM → OUTPUT

O tester começa a enxergar:

                 REQUIREMENT
                     ↓
INPUT → VALIDATION → BUSINESS RULE
                     ↓
                   DATA
                     ↓
                INTEGRATION
                     ↓
                 OUTPUT
                     ↓
              SIDE EFFECTS
                     ↓
              AUDIT / LOG
                     ↓
                RECOVERY

E pergunta:

O requisito está certo?

O dado está certo?

A fronteira está certa?

A regra está certa?

O resultado está certo?

O banco foi atualizado?

A mensagem foi enviada?

A mensagem foi enviada uma vez?

O rollback funciona?

O restart duplica alguma coisa?

O usuário possui autorização?

A evidência é suficiente?

Outro componente foi quebrado?

O que acontece sob carga?

O que acontece quando algo falha?

Esse é o momento em que Manual Testing deixa de ser uma coleção de definições e passa a ser engenharia.

O ISTQB moderno reforça exatamente essa amplitude: testing dentro do ciclo de desenvolvimento, técnicas black-box, white-box e baseadas em experiência, testes estáticos, risco, defeitos e automação fazem parte de um mesmo corpo de conhecimento. (ISTQB)

Mandrake finalmente fecha a cartola.

O gerente pergunta:

— Então conseguimos provar que o sistema não possui bugs?

Mandrake sorri.

Não.

Mas conseguimos algo muito mais útil.

Descobrimos onde procurá-los, quais riscos realmente importam, quais evidências sustentam nossa confiança e, principalmente, aprendemos a nunca confundir:

RC=0000

com:

TUDO ESTÁ CERTO.

Porque no mainframe, como num espetáculo de mágica, o perigo não está necessariamente naquilo que vemos acontecer.

Está também naquilo que aconteceu atrás da cortina enquanto todos estavam olhando para outro lado.

E às 03:17, quando aquele JOB que funcionou perfeitamente durante 4.327 execuções finalmente encontrar o registro que ninguém imaginou testar...

...talvez algum velho tester sorria diante do SYSOUT e diga:

“Eu sabia que havia um coelho nessa cartola.” 🎩🐇

ISTQB Certified Tester Foundation Level 4.0

sexta-feira, 25 de outubro de 2019

Cautious Hero sem Medo e com muita cautela

Bellacosa Mainframe apresenta Kono Yuusha ga Ore Tueee Kuse ni Shinchou Sugiru

☕ Um Café no Bellacosa Mainframe

Cautious Hero sem Medo e com muita cautela

Quando o Programador COBOL Descobre que Paranoia, Testes e Planejamento Podem Salvar Muito Mais que um Mundo Fantástico

"No universo IBM Z existe um velho ditado que nunca foi oficialmente escrito em nenhum manual da IBM: quem testa pouco, reza muito na produção."

Ao assistir Cautious Hero, muitos espectadores enxergam apenas uma comédia isekai cheia de exageros.

Eu enxergo outra coisa.

Vejo um excelente curso sobre engenharia de software, gestão de riscos, qualidade, DevOps, resiliência e arquitetura de sistemas, tudo embrulhado em uma história extremamente divertida.

É curioso perceber como um anime consegue ensinar princípios que um programador COBOL levaria anos para aprender trabalhando em um banco.

Talvez seja justamente por isso que este anime tenha conquistado tantos fãs.

Ficha Técnica

Item	Informação
Título original	慎重勇者～この勇者が俺TUEEEくせに慎重すぎる～ (Shinchou Yuusha: Kono Yuusha ga Ore Tueee Kuse ni Shinchou Sugiru)
Título internacional	Cautious Hero: The Hero Is Overpowered but Overly Cautious
Autor (Light Novel)	Light Tuchihi
Ilustrações	Saori Toyota
Estúdio	White Fox
Diretor	Masayuki Sakoi
Composição da série	Kenta Ihara
Design de personagens	Mai Toda
Trilha sonora	Yoshiaki Fujisawa
Lançamento	2 de outubro de 2019
Exibição	Outubro a dezembro de 2019
Episódios	12
Duração	aproximadamente 23 minutos
Origem	Light Novel
Classificação indicativa	16 anos
Gêneros	Isekai, Fantasia, Aventura, Comédia, Ação

Sinopse

A jovem deusa Ristarte recebe uma missão extremamente complicada: salvar o mundo de Gaeabrande, classificado como dificuldade S, onde inúmeros heróis anteriores fracassaram.

Para isso ela invoca um humano da Terra chamado Seiya Ryuuguuin.

Logo percebe que convocou alguém absurdamente poderoso.

Mas também...

absurdamente cauteloso.

Seiya nunca entra em combate sem estar preparado.

Nunca enfrenta um inimigo sem um plano.

Nunca acredita que venceu.

Nunca confia na sorte.

E é justamente aí que mora toda a genialidade da obra.

A história

A narrativa segue o formato clássico dos isekais.

Existe:

uma deusa
um herói convocado
um Rei Demônio
cidades
monstros
magias
níveis
equipamentos

Até aqui...

nada de novo.

Mas basta assistir ao primeiro episódio para perceber que tudo será diferente.

Enquanto outros protagonistas saem correndo para enfrentar monstros...

Seiya decide treinar.

Depois treinar novamente.

Depois comprar centenas de poções.

Depois verificar seus equipamentos.

Depois fazer mais treinamento.

Depois voltar e treinar outra vez.

É uma inversão completa do clichê do "herói invencível".

O que existe de diferente?

Este anime faz uma pergunta extremamente interessante:

E se o protagonista realmente levasse a missão a sério?

Na maioria dos isekais modernos, os heróis:

improvisam
vencem facilmente
aprendem durante a batalha

Seiya faz exatamente o contrário.

Ele transforma cada luta em um projeto de engenharia.

É praticamente um gerente de qualidade ISO 9001 vestido de cavaleiro.

Os personagens

Seiya Ryuuguuin

O protagonista.

Extremamente poderoso.

Extremamente inteligente.

Extremamente desconfiado.

Sua frase poderia facilmente ser:

"Planejamento é mais importante que coragem."

Ele nunca luta por impulso.

Ristarte

A deusa responsável pela missão.

É praticamente o oposto de Seiya.

Ela representa:

emoção
improviso
entusiasmo
impulsividade

Grande parte da comédia nasce justamente dessa diferença.

Mash

Jovem dragonoide.

Representa coragem.

Também simboliza o crescimento pessoal durante a aventura.

Elulu

Outra dragonoide.

Possui enorme importância em diversos momentos dramáticos da história.

Sua evolução é bastante interessante.

Ariadoa

Uma deusa muito mais experiente.

Ela funciona como uma espécie de mentora.

É uma personagem cercada por mistério desde sua primeira aparição.

As aventuras

Durante os 12 episódios vemos praticamente uma campanha completa de RPG.

Entre elas:

combate contra cavaleiros demoníacos
exploração de cidades
treinamento divino
armas lendárias
dragões
deuses
reis demônios
viagens entre mundos
magias proibidas
sacrifícios
reviravoltas emocionantes

Cada aventura parece inicialmente apenas mais uma piada.

Mas quase todas escondem pistas importantes para o final.

As mensagens ocultas

Aqui está a verdadeira riqueza do anime.

1. Trauma muda pessoas

Sem revelar spoilers.

Descobrimos que Seiya não nasceu cauteloso.

Ele se tornou assim.

O anime mostra que experiências traumáticas podem alterar completamente nossa forma de agir.

2. Preparação salva vidas

Esta talvez seja a maior lição.

Em TI chamamos isso de:

contingência
rollback
plano B
disaster recovery
testes

Seiya simplesmente vive isso.

3. Poder sem disciplina é inútil

Ele poderia confiar apenas na força.

Mas prefere confiar na preparação.

4. Inteligência supera talento

O anime deixa claro que planejamento frequentemente vence força bruta.

5. O excesso também possui custo

Existe um equilíbrio.

Ser cuidadoso é excelente.

Mas viver apenas com medo também pode impedir o progresso.

Essa dualidade aparece diversas vezes ao longo da narrativa.

Temáticas

A obra mistura vários temas:

responsabilidade
culpa
amadurecimento
amizade
sacrifício
estratégia
confiança
liderança
crescimento pessoal
redenção

Por trás das piadas existe uma história surpreendentemente emocional.

A qualidade da animação

O estúdio White Fox já era conhecido por produzir séries visualmente marcantes, como Steins;Gate e Re:Zero. Em Cautious Hero, o estúdio equilibra cenas de ação bem coreografadas com expressões faciais exageradas que reforçam a comédia, especialmente nas reações de Ristarte.

Os destaques técnicos incluem:

excelente direção de timing cômico;
expressões faciais extremamente caricatas;
boas sequências de magia e combate;
trilha sonora que alterna humor e tensão;
ritmo consistente ao longo da temporada.

O humor

O humor funciona porque nasce da lógica.

Seiya não é engraçado porque faz piadas.

Ele é engraçado porque leva absolutamente tudo ao extremo.

Um inimigo caiu?

Ele o destrói novamente.

Depois mais uma vez.

Depois verifica os destroços.

Depois pergunta:

"Tem certeza de que morreu?"

Quem trabalha em produção de sistemas provavelmente sorri, porque já viu "processos mortos" voltarem a executar, jobs reaparecerem ou erros aparentemente resolvidos ressurgirem.

O impacto cultural

Embora não tenha alcançado a popularidade de gigantes como Re:Zero ou Konosuba, Cautious Hero conquistou uma comunidade bastante fiel. Muitos fãs destacam justamente a combinação entre humor e a mudança de tom nos episódios finais, além da personalidade única de Seiya, frequentemente comparado ao "Batman dos isekais" por sempre chegar preparado para qualquer situação.

Diversas expressões do protagonista viraram memes entre fãs de anime, e a série continua sendo lembrada como uma das comédias de fantasia mais criativas da década.

Curiosidades

O episódio 3 sofreu atraso durante a exibição original devido a problemas de produção.
A abertura "TIT FOR TAT", da banda Myth & Roid, tornou-se bastante popular entre fãs do gênero.
O encerramento "be perfect, plz!", interpretado por Riko Azuna, contrasta com a intensidade da história usando um tom mais leve.

Bellacosa Mainframe — O que um Programador COBOL aprende com Seiya?

Agora imagine que Seiya fosse contratado para trabalhar em um grande banco.

Antes de colocar um programa COBOL em produção ele faria:

✔ revisão completa do código

✔ teste unitário

✔ teste integrado

✔ teste de volume

✔ teste de rollback

✔ análise de SQLCODE

✔ análise de ABEND

✔ simulação de indisponibilidade

✔ validação do JCL

✔ conferência de parâmetros

✔ comparação de versões

✔ plano de recuperação

✔ documentação completa

Enquanto todos reclamariam da demora...

Ele apenas responderia:

"E se acontecer alguma coisa?"

No universo IBM Z, onde uma única falha pode afetar milhões de transações financeiras, essa pergunta vale ouro. Seiya pensa como um engenheiro de confiabilidade: elimina riscos antes que eles cheguem à produção. Sua cautela exagerada lembra práticas modernas como testes de regressão, integração contínua, planos de contingência e observabilidade.

No fim das contas, Cautious Hero não é apenas uma paródia dos isekais. É uma história sobre disciplina, responsabilidade e a diferença entre confiar na sorte ou confiar na preparação. Para um Padawan COBOL, a mensagem é clara: heróis não salvam sistemas porque são fortes; eles os salvam porque se prepararam para tudo o que poderia dar errado.

quinta-feira, 24 de outubro de 2019

🍓🥪 Sando Furutsu – O Sanduíche de Frutas que Domina os Animes

🍓🥪 Sando Furutsu – O Sanduíche de Frutas que Domina os Animes
(Um post Bellacosa Mainframe para Otakus e Amantes da Gastronomia do Japão)
Por Vagner Bellacosa — Blog El Jefe Midnight Lunch

Se você assiste anime com atenção de SYSOP vasculhando um SDUMP, já deve ter notado aquele sanduíche fofíssimo, branquinho, com creme brilhando e frutas cortadas em formato geométrico que até parecem feitas com SORT FIELDS.

Esse é o Sando Furutsu (フルーツサンド) — o lendário Fruit Sandwich.
Sim, um sanduíche de frutas.
Sim, doce.
Sim, totalmente japonês.
E sim, aparece tanto em anime que parece que todo protagonista, de isekai a slice-of-life, começa o dia com um.

Hoje vamos abrir o dataset gastronômico, carregar o módulo da nostalgia e explicar esse clássico japonês com a fineza Bellacosa Mainframe.

🍰 1) O que é o Sando Furutsu?

O Sando Furutsu é um sanduíche de frutas com pão de forma japonês (o famoso shokupan), extremamente macio, feito com:

Pão branco ultramacio (que parece ALLOCADO com “BUFNO=INFINITO”)
Chantilly leve e suave
Frutas fatiadas (morango, pêssego, manga, kiwi)
Um corte perfeito mostrando o desenho da fruta — estética é tudo no Japão

É um doce leve, barato e iconicamente kawaii, quase um Hello Kitty em forma de sanduíche.

📜 2) Origem: Japão Pós-Guerra e o Shokupan Overpower

O Sando Furutsu nasce lá pelos anos 1950–60, quando o pão branco ganhou força no Japão. O Japão adorava experimentar misturas “ocidentais”, e surgiu a ideia genial:

“E se fizermos um sanduíche…
só que… bonito?”

O povo japonês tem um talento ancestral para pegar ideias comuns e transformá-las em obras-primas de estética, precisão e suavidade.
É o Z/OS do pão de forma: robusto, eficiente, simples e dominante.

O primeiro registro popular é de lojas de frutas premium de Tóquio, tipo a Senbikiya, famosa por vender melões mais caros que um iPhone.

🎌 3) Por que aparece tanto em animes?

Porque o Sando Furutsu é:

✔ Barato
✔ Kawaii
✔ Fotogênico
✔ Simples
✔ “Vibe japonesa” instantânea
✔ Símbolo de cafeteria, amizade e conforto

Ele representa aquele momento “vida tranquila”, comum em:

Slice of Life
Romance escolar
Comédias fofas
Animes de culinária
Heroínas comendo algo lindo que dá vontade de proteger

É quase um JOBLOG de fofura.

🎬 4) Animes onde o Sando Furutsu aparece

Prepare seu SORT FIELDS e sua nostalgia:

🍓 Fruits Basket

Porque claro: fruta + drama emocional + Japão = sando.

🍞 Shokugeki no Souma

Ele aparece como referência nas cafeterias da série.

🥪 Komi-san wa Komyushou desu

Komi recebe ofertas de comida fofinha o tempo todo.
Sando = socializar sem falar. A matemática bate.

🍵 K-On!

Cafeteria? Chá? Dia ensolarado?
Alguém sempre come algo semelhante.

🧁 Cardcaptor Sakura (em versões mais modernas)

Clamp ama estética.
E o sando é praticamente estética materializada.

🧪 5) Por que ele faz tanto sucesso?

Porque o Sando Furutsu é o “Hello World” do Japão”:

Fácil de fazer
Delicioso
Instagramável
Leve
Elegante
Confortável
“Limpo” visualmente

Ele é culinária sem exceções, igual uma JCL bem escrita: funciona sempre.

🕵️ 6) Easter Eggs e detalhes que pouca gente nota

🥛 O creme NUNCA é muito doce

Japoneses odeiam sobremesa pesada.
É sempre chantilly leve, quase um código limpo.

🍞 O pão é cortado sem casca

O Japão considera casca ruído visual.
E otakus também — é por isso que a imagem sempre está perfeita.

🔪 O corte é calculado

Animadores literalmente fazem o corte do sando como cena de impacto.
Geometria das frutas tem que ficar centralizada.
É quase como alinhar colunas no ISPF.

🍈 Se aparecer melão, é sando de gente rica

Melão japonês é caro.
Caríssimo.
Dezena de milhares de ienes.
Se aparece, é foreshadowing de família endinheirada.

🛠️ 7) Como fazer um Sando Furutsu (modo Bellacosa)

Ingredientes:

Shokupan (pode usar pão de forma bem fofinho)
Chantilly
Frutas grandes e bonitas
Faca afiada
Jeito japonês de montar coisas perfeitas

Passo-a-passo:

Passe chantilly dos dois lados.
Posicione as frutas com lógica de layout de tela ISPF:
centralizadas, simétricas, e com previsão de corte diagonal.
Feche, envolva em plástico filme e pressione levemente.
Deixe na geladeira 1 hora.
Corte com precisão cirúrgica (modo ninja ativado).

Fica lindo.
Lindo mesmo.
É um dataset doce.

🚀 8) Resumo Bellacosa

Sando Furutsu = o sanduíche de frutas japonês que aparece em tudo porque é:

bonito
doce
simples
barato
icônico
estético
com vibe pura de vida tranquila

Perfeito para animes, cafeterias, waifus, lolitas e qualquer cena que precise transmitir doçura e paz.

quarta-feira, 23 de outubro de 2019

🌙 Madrugada Discada — o templo sagrado dos 28.800 bps e dos sonhadores digitais

Ah, padawan… havia um tempo em que a internet não era um direito, era um ritual.
Um culto silencioso celebrado à meia-noite, ao som de um modem cantando sua ópera metálica: “piiiiii... krrrrr... tchhhhhh... biiiiip-biiiip”.
Era o chamado dos deuses da conexão — e só os iniciados sabiam o valor desse som.

💤 O rito do acesso noturno
Lá pelos idos de 1996 a 2003, conectar-se à internet era um ato de engenharia e estratégia familiar.
Os planos de acesso noturno das provedoras — IG, Terra, UOL, Mandic — tinham assinaturas acesso free, porém o custo de um impulso telefônico era assustador, por isso as companhias telefonicas para incentivarem o uso de dados, liberavam conexão grátis a partir da meia-noite pagando apenas 1 impulso.
Então a rotina era sagrada:
dormir umas horinhas depois da novela, jantar qualquer coisa, e às 23h59 já estar de frente pro monitor CRT, dedo no Discador do Windows 98, esperando o relógio virar.

🖥️ O despertar dos 28.800 bps
Quando conectava… ah, que glória!
A sensação de poder abrir o STI, meu primeiro provedor, Altavista, visitar o Cadê?, entrar num chat da UOL, e ver as letras aparecendo linha a linha — isso era magia pura.
O PC 486 ou o Pentium MMX virava uma nave, e a madrugada era o nosso cosmos digital.
A tela iluminava o quarto escuro, o ventilador zumbia, e o tempo simplesmente… parava.

🌀 As epopeias dos downloads
Baixar uma música no Napster ou Kazaa era um ato de fé.
Um MP3 de 4MB levava duas horas — e se alguém tirasse o telefone do gancho, adeus conexão.
Muitos dormiam com o download a 87%, torcendo pra acordar com o “Download Complete”.
Outros passavam a madrugada inteira trocando .jpg, scripts do mIRC, gifs e sonhos.

💬 Os templos da madrugada
Os chats eram nossas ágoras.
#brasil, #amizade, #noturnos, #underground…
Ali nasciam amizades, paixonites, tretas e promessas que se dissolviam com o nascer do sol.
Não existia feed, não existia algoritmo — só curiosidade e paciência.

☕ O nascer do sol digital
E quando o céu começava a clarear, os olhos pesavam, o modem ainda chiava, e o corpo pedia cama.
Um banho rápido, café com pão amanhecido e… direto pro trabalho.
Com olheiras, mas com a alma leve — porque você viveu a madrugada conectada, e ninguém podia tirar isso de você.

💡 Reflexão Bellacosa Mainframe style:
Naquela época, a internet não era sobre velocidade — era sobre descoberta.
Não havia pressa, só fascínio.
Cada clique era uma expedição, cada site, um planeta novo.
A gente esperava, sonhava, desconectava e voltava — porque no fundo, sabíamos que a magia estava no processo, não no download.

E hoje, padawan, quando a fibra óptica carrega o mundo em milissegundos…
às vezes sinto falta de esperar a meia-noite, ouvir o modem, e sentir que o universo inteiro estava ali — no som de um chiado, na solidão de um quarto, e na promessa de um novo link. 🌌

#BellacosaMainframe #ElJefe #NostalgiaDigital #InternetDiscada #Modem56k #MadrugadaRaiz

terça-feira, 22 de outubro de 2019

Como um Sysprog Júnior Pode Aprender a Enxergar a Alma do IBM Z Sem Invocar Magia Negra, RMF Jedi Masters ou Adivinhar Gargalos pelo SDSF

Bellacosa Mainframe e o ibm rmf

☕ O Holocron do RMF

Como um Sysprog Júnior Pode Aprender a Enxergar a Alma do IBM Z Sem Invocar Magia Negra, RMF Jedi Masters ou Adivinhar Gargalos pelo SDSF

Existe um momento na jornada de todo Sysprog Jr. em que ele descobre uma verdade desconfortável.

O mainframe não reclama.

Ele não pisca.

Ele não mostra uma barrinha vermelha dizendo:

"CPU em 98%, boa sorte."

Ele apenas continua trabalhando.

Processando milhões de transações.

Movimentando bilhões de dólares.

Executando CICS.

DB2.

MQ.

IMS.

Batch.

Java.

zCX.

OpenShift.

E fazendo tudo isso em silêncio.

Até o dia em que alguém pergunta:

"Por que o banco ficou lento às 10h37?"

E todos olham para você.

Nesse momento surge um dos maiores artefatos tecnológicos já produzidos pela IBM.

O RMF.

O verdadeiro estetoscópio do IBM Z.

O que é RMF?

RMF significa:

Resource Measurement Facility

Foi criado pela IBM para responder uma pergunta simples:

O que exatamente está acontecendo dentro do z/OS?

Ele é o principal sistema de observabilidade do IBM Z.

Pense nele como:

Ferramenta	Analogia
SDSF	Painel do carro
SMF	Caixa preta
RMF	Exames médicos completos
OMEGAMON	Monitor cardíaco em tempo real
Grafana	Painel bonito
RMF	Raios-X, tomografia e ressonância do z/OS

Origem do RMF

Nas décadas de 70 e 80, os computadores custavam milhões de dólares.

Um upgrade errado de CPU podia custar uma fortuna.

A IBM precisava responder:

CPU está saturada?
Disco é gargalo?
Falta memória?
Canal está congestionado?
O WLM está funcionando?

Nasce então o RMF.

Inicialmente no:

MVS

Depois:

MVS/XA

MVS/ESA

OS/390

z/OS

Hoje continua vivo no:

RMF z/OS 3.1

RMF z/OS 3.2

Praticamente todo grande banco do planeta utiliza RMF.

O grande segredo

Muitos iniciantes pensam:

RMF = Monitor

Errado.

RMF possui três modos.

RMF Monitor I

Produz tendências.

Intervalos de coleta.

Exemplo:

CPU média

Paging

Storage

DASD

Canal

É o favorito do Capacity Planning.

RMF Monitor II

Tempo real.

Parecido com um top do Linux.

Exemplos:

CPU NOW

Address Spaces

Enqueue

Locks

Cache

RMF Monitor III

Quase tempo real.

WLM.

Performance por serviço.

CICS

DB2

Batch

Muito usado por operadores.

Arquitetura

Aplicações
     │
     ▼

SMF Records
     │
     ▼

RMF Collectors
     │
     ▼

ERBRMFPP
ERBRMF00

     │
     ▼

Reports


Monitor I
Monitor II
Monitor III

Principais componentes

ERBRMF00

Started Task.

Motor do RMF.

ERBRMFPP

Post Processor.

Gera relatórios.

ERB3XDR

Data Reporter

Exportação.

ERBSCAN

Analisador.

ERBMFH

Monitor host.

Onde configurar?

Parmlib.

Normalmente:

SYS1.PARMLIB

Membro:

ERBRMFxx

Exemplo:

ERBRMF00

Exemplo simples

CPU

SYSRPTS(CPU)

DASD

SYSRPTS(DASD)

Storage

SYSRPTS(STOR)

Channel

SYSRPTS(CHANNEL)

Exemplo completo

REPORTS(CPU,DASD,CACHE,STOR)


INTERVAL(15)


CYCLE(24)



SYSRPTS(ALL)

Significa:

Coletar a cada 15 minutos.

Durante 24 horas.

Gerar tudo.

Como iniciar

Operador:

S RMF

S ERBRMF00

Parar:

P RMF

Verificando

D A,RMF

Monitor II

Comandos clássicos.

CPU

RMFCPU

Storage

RMFSTOR

Device

RMFDASD

Channel

RMFCHAN

Monitor III

Entrar:

RMFIII

Painéis ISPF.

Passo a passo para um Sysprog Jr.

Etapa 1

Descobrir se RMF está ativo.

D A,RMF

Etapa 2

Abrir ISPF.

Selecionar:

RMF

Etapa 3

Escolher:

Monitor II

Etapa 4

CPU Activity

Verificar:

Busy %

LPAR

Logical CPU

Dispatch

Etapa 5

Storage

Frames

CSA

ECSA

Paging

Etapa 6

DASD

Response Time

IOSQ

Cache Hit

Etapa 7

Salvar relatório.

Exemplo de análise

Você percebe:

CPU = 35%

Tudo bem.

Mas:

DASD Response

28 ms

Muito alto.

IOS Queue

Problema não é CPU.

É disco.

RMF revelou o culpado.

Relatórios mais famosos

CPU Activity

Capacidade.

SMT.

CP.

zIIP.

zAAP.

Paging Activity

Falta memória.

Device Activity

I/O.

Cache Activity

DS8000.

Coupling Facility

Parallel Sysplex.

Workload Activity

WLM.

RMF e WLM

São praticamente irmãos.

WLM decide.

RMF mede.

WLM fala:

Dê mais CPU ao CICS.

RMF responde:

Feito.
Resposta caiu para 0,12 segundos.

Easter Eggs do RMF

Pouca gente sabe.

Os nomes ERB vêm de:

Early Resource Base

Projeto interno IBM.

Os relatórios RMF possuem formato semelhante aos produzidos nos anos 80.

Muitos Sysprogs dizem:

Se você consegue ler um relatório RMF de 1987, consegue ler um de 2026.

A aparência mudou muito pouco.

IBM acredita em compatibilidade quase religiosa.

Curiosidades

O RMF consegue medir:

Cache do processador

HiperDispatch

zIIP

Crypto cards

OSA

FICON

Coupling Facility

Storage Class Memory

zEDC

SMT

É possível alimentar:

Grafana

Splunk

Elastic

Instana

OMEGAMON

IBM Z Performance and Capacity Analytics

Erros comuns dos iniciantes

Olhar apenas CPU

CPU raramente é o problema.

Ignorar IOSQ

Fila de I/O mata aplicações.

Não analisar WLM

Prioridades incorretas distorcem tudo.

Coletar dados demais

RMF também consome recursos.

Planejamento é importante.

O Holocron do Sysprog

Um velho Sysprog costumava dizer:

"O SDSF mostra que a casa está pegando fogo."

"O RMF mostra quem acendeu o fósforo."

E, depois de algum tempo trabalhando em produção, você descobre que ele estava absolutamente certo.

O RMF não é apenas uma ferramenta de monitoramento. Ele é a memória histórica do z/OS, o microscópio do Sysprog, o detector de gargalos do Capacity Planner e, muitas vezes, o único testemunho confiável do que realmente aconteceu em uma LPAR às 10h37 de uma terça-feira em fechamento bancário.

E quando você aprender a ler um relatório RMF com a mesma naturalidade com que lê um JOBLOG, terá dado um dos passos mais importantes para deixar de ser apenas um operador de comandos e começar a pensar como um verdadeiro guardião do IBM Z.

Pegue sua caneca de café. O próximo holocron pode ser o SMF, o WLM ou o OMEGAMON. A jornada de um Sysprog apenas começou. ☕🚀

segunda-feira, 21 de outubro de 2019

🎨 Screentones no mangá e anime — o truque visual dos mestres japoneses

Bellacosa Mainframe e a arte de manga em screentones

🎨 Screentones no mangá e anime — o truque visual dos mestres japoneses

Se você já folheou um mangá preto e branco e pensou: “Como eles conseguem dar tanta profundidade e textura só com tons de cinza?”, bem-vindo ao mundo mágico dos screentones — ou, como são chamados no Japão, “ton” (トーン).

🖋️ O que são screentones?

Screentones são camadas adesivas ou digitais com padrões de pontos, linhas, texturas ou sombreados usados pelos artistas de mangá para criar profundidade, contraste e emoção sem precisar usar cor.
Antes da era digital, o artista cortava folhas finas e transparentes com lâmina — tipo decalque — e aplicava diretamente sobre o papel do desenho. Hoje, softwares como Clip Studio Paint, MediBang Paint e Photoshop já trazem bibliotecas inteiras de screentones digitais.

🧩 Como funciona?

Os screentones simulam tons de cinza através de densidades de pontilhado (halftone).

Pontos mais próximos → área mais escura
Pontos mais espaçados → área mais clara

Essa ilusão ótica cria sombras, gradientes, luz, profundidade e até textura de tecido ou cabelo.

💡 Exemplos de estilos e obras

Osamu Tezuka (Astro Boy, Black Jack) — um dos pioneiros no uso de screentones, especialmente para criar efeitos de brilho metálico e contraste dramático.
Rumiko Takahashi (Inuyasha, Ranma ½) — usa screentones suaves para cabelos, roupas e emoções cômicas.
CLAMP (Cardcaptor Sakura, X/1999) — exploram screentones delicados e ornamentais, criando aquele “brilho etéreo” nos personagens.
Kentaro Miura (Berserk) — exemplo extremo: texturas densas e sobreposição de screentones criam o clima sombrio e brutal da obra.
Naoko Takeuchi (Sailor Moon) — usa tons cintilantes e suaves, com muitos brilhos, dando feminilidade e leveza.

🖌️ Tipos de screentones mais usados

Densidade (Dot tone): Pontilhado para sombras e volumes.
Line tone: Linhas para movimento e tensão.
Pattern tone: Padrões (flores, corações, estrelas) — muito comum em shōjo.
Gradient tone: Transições suaves, imitando degradê de luz.
Effect tone: Raios, brilhos, faíscas e fundos de impacto.

⚙️ Screentones digitais: a nova geração

Hoje, artistas usam screentones digitais arrastando e soltando camadas prontas.
O Clip Studio Paint é o queridinho dos mangakás modernos — ele até converte automaticamente grayscale em screentone para publicação impressa.

💡 Dica: se quiser experimentar, procure o pacote “Manga Materials” no CSP Assets — tem milhares de tons usados por profissionais.

🤓 Curiosidades para otaku

Mangakás tradicionais guardavam pilhas de screentones em pastas numeradas — cada padrão tinha código!
Um erro ao cortar screentone era caríssimo — as folhas eram importadas e vendidas por unidade.
No anime, o screentone é raramente usado diretamente, mas inspirou o “halftone shading” em aberturas e filtros artísticos (como em Mob Psycho 100 ou SPY×FAMILY).
Alguns artistas “assinam” seu estilo pelo tipo de screentone — por exemplo, Takehiko Inoue (Slam Dunk, Vagabond) mistura screentone com nanquim e pincel seco para um realismo sem igual.

☕ Dica Bellacosa para curiosos de plantão:

Quer entender o charme dos screentones?
Pegue um volume de “Death Note” e observe como o contraste entre luz e sombra muda conforme a moral de Light Yagami desce a ladeira.
Isso não é só roteiro — é screentone trabalhando!

📚 Resumo Bellacosa Style:
Screentones são o “Photoshop analógico” do mangá. Criam atmosfera, drama e textura com engenhosidade.
De folhas adesivas cortadas à mão a bibliotecas digitais, eles transformam preto e branco em pura emoção visual.

Translate

sábado, 9 de novembro de 2019