terça-feira, 4 de fevereiro de 2014

☁️ O que é Cloud Computing (sem bullshit)

 


☁️ O que é Cloud Computing (sem bullshit)

Segundo o NIST, cloud computing é:

Um modelo que permite acesso sob demanda a um pool compartilhado de recursos computacionais configuráveis, que podem ser rapidamente provisionados e liberados com mínimo esforço humano.

Traduzindo para o dialeto Bellacosa:

  • Recursos não são seus

  • Você não vê o ferro

  • Você sobe e desce capacidade sem pedir benção

  • Você paga pelo que usa

  • E se der ruim… é responsabilidade compartilhada (já chegamos lá)



🧱 Modelos clássicos: IaaS, PaaS e SaaS (a analogia do carro)

A IBM adora analogias. Vamos à mais famosa:

🚗 O carro

IaaS – Comprar o carro

  • Você cuida de tudo

  • SO, patch, firewall, aplicação

  • Liberdade total

  • Dor de cabeça total

👉 Ex: VMs no IBM Cloud, AWS EC2


PaaS – Alugar o carro

  • Você dirige

  • O provedor cuida do motor, manutenção, óleo, troca de peça

  • Foco no código, não no ferro

👉 Ex: Cloud Foundry, OpenShift, runtimes gerenciados


SaaS – Pegar um táxi

  • Só usa

  • Não sabe nem onde fica o motor

  • Só reclama quando atrasa

👉 Ex: Salesforce, O365, ServiceNow


🔐 Segurança na nuvem: não é opcional, é fundação

Se você acha que cloud é insegura, parabéns:
você acabou de repetir uma frase de 2012.

O mantra IBM:

Security by design + Shared Responsibility

📌 Modelo de responsabilidade compartilhada

  • Provedor protege:

    • Data center

    • Hardware

    • Infraestrutura física

  • Cliente protege:

    • Dados

    • Identidade

    • Acesso

    • Configuração

Se você subir um banco aberto na internet…
👉 o problema não é da nuvem


🪪 IAM – Identity & Access Management

No mainframe você tinha:

  • RACF

  • ACF2

  • Top Secret

Na nuvem você tem:

  • IAM

  • Access Groups

  • Policies

  • Least Privilege

A regra é a mesma desde os anos 80:

Nunca dê mais acesso do que o necessário.

E sim…
quem dá *.* em produção continua existindo 😅


🔒 Criptografia: dados inúteis para quem não deveria ver

Criptografia em nuvem protege dados:

  • Em repouso

  • Em trânsito

  • Em uso

Dois elementos fundamentais:

  • 🔑 Algoritmo

  • 🔑 Chave

E aqui vai um easter-egg:

🔥 Criptografia não elimina risco.
Ela só garante que o invasor roube lixo ilegível.


👀 Monitoring: quem não mede, não governa

No mainframe você tinha:

  • SMF

  • RMF

  • Console verde gritando

Na nuvem você tem:

  • Logs

  • Métricas

  • Traces

  • Eventos

  • Flow Logs

  • Dashboards

As 3 áreas do monitoramento em nuvem:

  1. Infraestrutura

  2. Aplicações

  3. Dados

Monitoramento moderno serve para:

  • Detectar falhas antes do usuário

  • Medir custo (sim, a fatura dói)

  • Garantir compliance

  • Reagir a ataques (DDoS, brute force, etc.)

👉 Monitorar não é olhar gráfico bonito.
É tomar decisão rápida.


🌪️ DDoS: o velho ataque com roupa nova

Ataque de negação de serviço distribuída é simples:

  • Milhares de máquinas

  • Um alvo

  • Tráfego até cair

A nuvem ajuda porque:

  • Escala automaticamente

  • Distribui carga

  • Usa redes globais (CDN)

Mas não faz milagre se você:

  • Não configurou

  • Não monitorou

  • Ignorou alertas


🧠 Boas práticas Bellacosa Approved™

✔ Use monitoramento contínuo, não auditoria ocasional
✔ Aplique least privilege sempre
✔ Separe ambientes (dev / test / prod)
✔ Monitore custo (cloud não é barata por padrão)
✔ Automatize tudo (infra as code)
✔ Desconfie de “funciona na minha máquina”
✔ Lembre-se: cloud não perdoa gambiarra


🧩 Curiosidades & Easter-Eggs

🥚 Mainframe é cloud privada ultra resiliente
🥚 LPAR ≈ VM
🥚 WLM ≈ Auto Scaling
🥚 SMF ≈ Observability
🥚 Quem domina mainframe aprende cloud mais rápido
🥚 O problema nunca foi a tecnologia… sempre foi o processo


🧘 Visão final para o Padawan

Cloud Computing não é:
❌ só subir VM
❌ só reduzir custo
❌ só modernizar frontend

Cloud é:
modelo operacional
mudança cultural
automação
segurança embutida
monitoramento contínuo

E se você veio do mainframe…
você não está atrasado.

👉 Você só está lembrando de algo que já sabia.



📊 Infográfico: Modelos de Nuvem no Mainframe

🏗️ 1. IaaS (Infrastructure as a Service) - Mainframe como Infraestrutura

Neste nível, você "aluga" o poder de processamento bruto, mas gerencia quase todo o resto.

  • O que é fornecido: LPARs (Partições Lógicas), Processadores (CPs, zIIPs), Memória e Storage (DASD).

  • O que você gerencia: O Sistema Operacional (z/OS, z/VSE, z/TPF ou Linux on Z), middleware e aplicações.

  • Exemplo: Provedores que oferecem zCloud onde você define o tamanho da sua LPAR e instala seu próprio stack.


🛠️ 2. PaaS (Platform as a Service) - Mainframe como Plataforma

Aqui, a complexidade da infraestrutura é escondida. O foco é no desenvolvimento e execução de código.

  • O que é fornecido: Ambiente de execução pronto, compiladores (COBOL, Java, Python), gerenciadores de banco de dados (DB2, IMS) e monitores de transação (CICS).

  • O que você gerencia: Apenas o seu código (programas) e os dados.

  • Exemplo: Ambientes de DevOps moderno (como z/OSMF ou containers via OpenShift on Z) onde o desenvolvedor faz o deploy do código sem se preocupar com a configuração do sistema operacional.


💻 3. SaaS (Software as a Service) - Mainframe como Serviço

O nível mais alto. O software roda no mainframe, mas o usuário final apenas consome a funcionalidade via web ou API.

  • O que é fornecido: A aplicação completa. Toda a manutenção, segurança e escalabilidade do mainframe são invisíveis para o usuário.

  • O que você gerencia: Apenas as configurações de usuário e o consumo do serviço.

  • Exemplo: Sistemas bancários de core-banking acessados via mobile que rodam transações críticas no mainframe, ou soluções de análise de fraude em tempo real oferecidas como serviço.


📉 Tabela de Responsabilidades (Quem controla o quê?)

CamadaIaaSPaaSSaaS
Hardware (z14, etc)ProvedorProvedorProvedor
Virtualização (z/VM)ProvedorProvedorProvedor
S.O. (z/OS, Linux)VOCÊProvedorProvedor
Middleware (DB2, CICS)VOCÊProvedorProvedor
Aplicações (COBOL)VOCÊVOCÊProvedor
DadosVOCÊVOCÊProvedor

⏱️ O Simbolismo dos Relógios no Anime Japonês

 



⏱️ O Simbolismo dos Relógios no Anime Japonês

(ou: quando o tempo vira sistema operacional)

No anime japonês, relógios nunca estão ali por acaso.
Eles não servem apenas para marcar horas. Servem para marcar limites, falhas, loops e pontos de não retorno.

Se no Ocidente o tempo corre, no Japão o tempo cobra.



🧠 1. Relógio em anime = contrato com o destino

Sempre que um relógio aparece em destaque, algo está acontecendo:

  • um prazo foi imposto

  • uma escolha precisa ser feita

  • o sistema entrou em contagem regressiva

📌 Bellacosa insight: é o SLA do universo sendo exibido na tela.

Exemplo clássico:

  • Death Note – o tempo de vida visível é o uptime humano



⛓️ 2. Relógios quebrados = sistema corrompido

Relógios parados, rachados ou fora de sincronia indicam:

  • trauma

  • tempo psicológico congelado

  • mundo que se recusa a avançar

🎬 Animes:

  • Steins;Gate – o tempo não flui, ele reverte

  • Ergo Proxy – o tempo é um artefato instável

  • Tokyo Ghoul – a identidade para no instante da ruptura

📌 Mainframe rule: quando o relógio quebra, o problema não é o tempo — é o estado.


🔄 3. Relógios e loops temporais

O Japão ama loops porque acredita que:

errar faz parte
repetir é aprendizado
insistir é honra

Relógios circulares, ponteiros voltando ou tiques repetidos sinalizam:

  • reinício de processo

  • tentativa de correção

  • batch reprocessado

🎬 Animes:

  • Re:Zero – checkpoint emocional

  • Higurashi – loop como punição

  • Madoka Magica – tempo como armadilha

📌 Easter egg: o som do tique-tique muitas vezes marca reset invisível.


⌛ 4. Ampulhetas e relógios antigos = peso do passado

Quando o anime usa relógios antigos, mecânicos ou ampulhetas:

  • tradição > modernidade

  • passado > futuro

  • legado > inovação

🎬 Animes:

  • Fullmetal Alchemist – tempo como troca equivalente

  • Violet Evergarden – cartas como relógios emocionais

  • Inuyasha – eras conectadas, mas nunca sincronizadas

📌 Bellacosa truth: sistemas antigos não medem segundos, medem consequências.


🕰️ 5. Personagens ligados a relógios sabem demais

Se um personagem:

  • carrega um relógio

  • conserta relógios

  • para o tempo

  • olha demais para o pulso

…desconfie.

Eles geralmente:

  • conhecem o fim

  • guardam segredos

  • vivem fora da linha temporal comum

🎭 Personagens:

  • Homura (Madoka Magica) – o relógio como prisão

  • Dio (JoJo) – o tempo como poder absoluto

  • Nox (Wakfu) – obsessão pelo tempo perdido

📌 Mainframe analogy: são os administradores do sistema.


🔔 6. Sinos, badaladas e alarmes

No Japão, o som importa tanto quanto a imagem.

  • sino = transição

  • alarme = ruptura

  • badalada = morte ou renascimento

🎬 Exemplos:

  • Evangelion – alertas = colapso iminente

  • Angel Beats – sinos = passagem

  • Bleach – tempo espiritual ≠ tempo humano

📌 Dica: quando o som do relógio fica alto, o diálogo costuma mentir.


🧩 7. Relógios digitais são frios e impessoais

Relógios digitais em anime indicam:

  • controle

  • vigilância

  • sistema desumanizado

🎬 Animes:

  • Psycho-Pass – tempo medido por produtividade

  • Serial Experiments Lain – tempo fragmentado

  • Akira – urgência urbana constante

📌 Easter egg urbano: telas cheias de números = sociedade sem pausa.


🧠 8. O Japão vê o tempo como responsabilidade

Diferente do “tempo é dinheiro”, no Japão:

tempo é dívida
tempo é honra
tempo é promessa

Por isso, nos animes:

  • atrasos custam vidas

  • segundos importam

  • escolhas tardias não têm rollback

📌 Mainframe final rule: o sistema pode até continuar rodando — você não.


☕ Conclusão: Relógios não medem horas, medem consequências

Em anime japonês, o relógio:

  • observa

  • julga

  • cobra

  • e nunca esquece

Se ele aparece em cena, preste atenção.
O sistema já decidiu algo — só não avisou os personagens ainda.

🕛 Midnight Lunch encerrado. O tempo continua.


segunda-feira, 3 de fevereiro de 2014

Do Pós-Hokusai ao Mangá Moderno: quando o rabisco virou sistema crítico

 


Do Pós-Hokusai ao Mangá Moderno: quando o rabisco virou sistema crítico

Introdução – após o reboot de Hokusai, quem assumiu o console?

Se Hokusai foi o IPL da linguagem visual do mangá, o período pós-Hokusai foi aquele momento clássico em que o sistema:

  • sai do laboratório,

  • entra em produção,

  • ganha usuários,

  • sofre incidentes,

  • e vira infraestrutura crítica da cultura japonesa.

A evolução do mangá não foi um salto.
Foi incremental, versionada e cheia de gambiarras geniais — exatamente como todo bom sistema legado.


Pós-Hokusai imediato – o mangá como documentação visual

Após a morte de Hokusai (1849), seus cadernos Hokusai Manga passaram a circular como:

  • material de estudo,

  • referência artística,

  • “apostila técnica” de desenho.

📌 Tradução Bellacosa:

Era o GitHub da época, só que impresso em madeira.

Artistas começaram a:

  • copiar poses,

  • repetir enquadramentos,

  • exagerar expressões.

Aqui nasce o DNA visual do mangá:

  • movimento

  • caricatura

  • narrativa implícita



Biografia essencial – Rakuten Kitazawa, o primeiro “mangaká oficial”

👤 Rakuten Kitazawa (1876–1955)

Se Hokusai foi o arquiteto, Rakuten Kitazawa foi o primeiro gerente de produção do mangá.

  • Trabalhou com caricaturas políticas

  • Publicou em jornais

  • Usou o termo “mangá” de forma consistente

  • Introduziu narrativa sequencial clara

📌 Curiosidade técnica:

Ele se inspirou fortemente em cartoons ocidentais, algo ousado num Japão ainda conservador.

Ou seja:

Foi o primeiro a integrar “sistemas externos” no core japonês.


Comentário crítico – quando o mangá vira mídia, não só arte

Até aqui, mangá era:

  • desenho,

  • exercício,

  • humor gráfico.

Com Kitazawa e seus sucessores, ele vira:

  • comunicação

  • opinião

  • narrativa

É o momento em que o mangá deixa de ser job de teste e passa a rodar como serviço essencial.


O terremoto histórico – guerra, censura e reset forçado

Anos 1930–1945:
O Japão entra em modo DRP não planejado.

  • Guerra

  • Censura

  • Propaganda estatal

  • Controle total do conteúdo

Mangá vira:

  • ferramenta ideológica

  • conteúdo educativo

  • propaganda disfarçada

📌 Easter egg histórico:

Muitos artistas aprenderam a contar histórias mesmo sob censura — habilidade que depois explodiria criativamente.


Biografia que muda tudo – Osamu Tezuka, o z/OS do mangá

👤 Osamu Tezuka (1928–1989)

Se existe um nome que merece ALL CAPS, é esse.

  • Criador de Astro Boy, Kimba, Black Jack

  • Introduziu:

    • enquadramentos cinematográficos

    • narrativa longa

    • personagens emocionalmente complexos

📌 Bellacosa traduz:

Tezuka transformou o mangá de utilitário em sistema operacional.

Ele pegou:

  • o traço livre de Hokusai

  • a narrativa de Kitazawa

  • e adicionou storytelling de Hollywood

Resultado?

Mangá como conhecemos hoje.


Curiosidades técnicas – padrões que ninguém te conta

  • Olhos grandes vêm do cinema, não da “fofura”

  • Quadros sem texto criam tempo narrativo

  • Linhas de movimento simulam processamento paralelo

Easter egg clássico:
👉 Muitos mangás usam silêncio visual como recurso narrativo — coisa raríssima em quadrinhos ocidentais.


Fofoquice de bastidor (porque sim 😄)

  • Tezuka era conhecido por:

    • trabalhar sem dormir

    • redesenhar páginas inteiras na última hora

    • aceitar prazos impossíveis

Basicamente:

O cara que salvava produção às 3 da manhã com café frio.

Alguns editores diziam que ele “estragou o mercado” criando expectativas irreais de produtividade 😅


Inspiração – legado não nasce perfeito

O mangá evoluiu porque:

  • cada geração não apagou a anterior

  • o legado foi estendido, não substituído

📌 Lição Bellacosa:

Não jogue fora o sistema antigo antes de entender por que ele funcionou por 100 anos.


Dicas Bellacosa para leitores (e criadores)

💡 1. Leia mangá como quem lê arquitetura
Observe enquadramento, ritmo, silêncio.

💡 2. Conheça o legado
Antes do hype, existe história.

💡 3. Nem todo traço simples é simples
Minimalismo exige domínio.

💡 4. Cultura também é sistema crítico
Quando cai, o impacto é social.


Fechamento – do rabisco ao império cultural

Do pós-Hokusai até Tezuka, o mangá:

  • virou linguagem

  • virou indústria

  • virou identidade nacional

Hoje ele está em:

  • animes

  • games

  • moda

  • cinema

  • memes

E tudo começou com alguém rabiscando o mundo sem saber que estava definindo um padrão eterno.

No El Jefe Midnight Lunch, a gente segue fazendo o mesmo:

conectando cultura, curiosidade e legado —
sempre com café, ironia e respeito ao sistema.

☕📚🖋️

quinta-feira, 16 de janeiro de 2014

SMP/E na prática – SYSMOD Packaging sem medo

 

Bellacosa Mainframe apresenta smp/e sysmod packaging

SMP/E na prática – SYSMOD Packaging sem medo



🧠 Introdução – SMP/E não é bicho‑papão

Quem trabalha com z/OS cedo ou tarde se depara com ele: SMP/E. Para alguns, um monstro antigo. Para outros, um mal necessário. A verdade é simples:

SMP/E é só método, disciplina e leitura correta das MCS.

Neste post vamos direto ao ponto: SYSMOD Packaging, ou seja, como os produtos, correções e USERMODs são empacotados, entregues e entendidos pelo SMP/E.

Sem marketing. Sem misticismo. Só mainframe raiz.


📦 O que é um SYSMOD de verdade?

Todo SYSMOD é composto por duas partes inseparáveis:

  1. Conteúdo

    • módulos

    • macros

    • source

    • dados

    • HFS / JAR

  2. MCS – Modification Control Statements

    • instruções que dizem ao SMP/E como, onde e quando instalar

👉 Durante o RECEIVE, o SMP/E lê primeiro as MCS, cria as MCS entries e armazena tudo no SMPPTS.

Se as MCS estiverem erradas… não há santo que salve o APPLY.


🧾 Regras de ouro das MCS (decore isso)

  • Todas começam com ++

  • Colunas 1–2 obrigatórias

  • Terminam com ponto final (.)

  • Continuação de linha só se não houver ponto antes da coluna 73

  • Colunas 73–80 são ignoradas

📌 Erro clássico: esquecer o ponto final. Resultado? SMP/E surtando.


🪪 HEADER – identidade do SYSMOD

Toda SYSMOD começa com:

++HEADER

É aqui que o SMP/E descobre:

  • o tipo do SYSMOD

  • o SYSMOD‑ID

Tipos clássicos

  • FUNCTION – produto base

  • PTF – correção testada

  • APAR – correção de problema

  • USERMOD – correção local

Sem HEADER correto, não existe SYSMOD.


🧬 FMID – quem é o dono do código

O FMID (Function Modification ID):

  • tem 7 caracteres

  • identifica qual função é dona do elemento

  • aparece normalmente no ++VER

📌 Em FUNCTION SYSMOD, o FMID é o próprio SYSMOD‑ID.

Erro comum em prova e produção: FMID errado = APPLY recusado.


🔗 ++VER – o cérebro do SMP/E

O ++VER é obrigatório e define:

  • releases suportados

  • pré‑requisitos

  • co‑requisitos

  • supersedes

Principais operandos:

  • SREL – release do sistema

  • FMID – função dona

  • PRE – pré‑requisito

  • REQ – co‑requisito

  • SUP – supersede

👉 Sem ++VER, o SMP/E não confia em você.


🚦 ++HOLD – bloqueios controlados

Existem três HOLDs clássicos:

  • ERROR – correção com problema

  • SYSTEM – ação manual necessária

  • USER – regra local

O HOLD pode vir:

  • dentro do SYSMOD

  • ou separado em HOLDDATA

📌 HOLD não é erro. HOLD é controle.


🏗️ ++JCLIN – a planta da casa

O ++JCLIN descreve:

  • como o load module deve ser montado

  • quais objetos entram

  • qual link‑edit será usado

⚠️ JCLIN não executa JCL.

Ele apenas documenta a estrutura, permitindo RESTORE e rebuild corretos.

Sem JCLIN, o SMP/E fica cego.


🧩 MCS de elementos – o que realmente instala

Alguns exemplos:

  • ++MOD – módulo

  • ++SRC – source

  • ++MAC – macro

  • ++DATA – dados

  • ++HFS – arquivo Unix

  • ++JAR – JAR inteiro

  • ++JARUPD – update parcial

  • ++ZAP – patch binário

📌 ZAP e UPD alteram partes. DATA e HFS sempre substituem tudo.


☕ JAR no SMP/E (onde muita gente erra)

  • ++JAR → substituição total

  • ++JARUPD → update parcial

O SMP/E usa comandos do JDK para manipular o conteúdo.

Sim, Java também é mainframe.


📦 Técnicas de empacotamento SYSMOD

1️⃣ Relative File (tape)

  • clássico IBM

  • MCS em um arquivo

  • elementos em arquivos seguintes

  • usa RELFILE

Muito comum em FUNCTION SYSMOD.


2️⃣ Inline

  • MCS e conteúdo juntos

  • registros fixos de 80 bytes

  • simples e direto

⚠️ Dados variáveis exigem GIMDTS.


3️⃣ Indirect Library

  • MCS no SMPPTS

  • conteúdo fora (PDS indicado no APPLY)

  • comum em USERMOD

Flexível e perigoso se mal documentado.


4️⃣ GIMZIP Archive (Shopz / Internet)

  • entrega moderna

  • tudo compactado

  • inclui MCS, conteúdo e HOLDDATA

Base do RECEIVE FROMNETWORK.


❌ Pegadinhas clássicas (anota aí)

  • ++MOD não é o último MCS

  • Inline com RELFILE

  • FMID inexistente

  • SREL inválido

  • falta de ponto final

👉 Todas já derrubaram produção algum dia.


🧠 Conclusão – SMP/E é método

RECEIVE entende
APPLY constrói
ACCEPT congela

Quando você entende SYSMOD Packaging, o SMP/E deixa de ser mistério e vira aliado.

Mainframe não é velho.
Velho é não saber o que está rodando.


💾 Até o próximo post. Porque mainframe bom é mainframe bem documentado.

quinta-feira, 9 de janeiro de 2014

🔞 Um anime bem fetichista : Kill la Kill (キルラキル)

 


Kill la Kill (キルラキル)

Autor: Kazuki Nakashima (roteiro)
Direção: Hiroyuki Imaishi
Estúdio: Trigger
Ano de lançamento: 2013


Sinopse

Em um colégio onde o uniforme concede poderes sobre-humanos, Ryuko Matoi chega armada com uma tesoura-gigante para descobrir quem assassinou seu pai.
A trama é uma montanha-russa visual e simbólica, misturando ação, sátira, erotismo e crítica social.
Cada uniforme, chamado Goku Uniform, dá força ao usuário, mas exige que ele se exponha — literalmente.

Por trás da estética provocante, há uma metáfora sobre controle, liberdade e vergonha.
Kill la Kill brinca com a ideia do corpo como arma, da roupa como identidade, e do fetiche como símbolo de poder e vulnerabilidade.


Dicas e curiosidades

  • O diretor Hiroyuki Imaishi é o mesmo de Gurren Lagann — outro anime que exagera tudo de propósito.

  • A exposição do corpo não é gratuita: simboliza a libertação das amarras sociais e a aceitação de si mesmo.

  • O anime faz críticas sutis ao consumismo, à padronização e ao uso da sexualização como ferramenta de controle.

  • A trilha sonora é vibrante, cheia de gritos de guerra e hinos épicos — impossível assistir sentado.


Principais personagens

  • Ryuko Matoi: protagonista impulsiva e corajosa, em busca de vingança e autodescoberta.

  • Satsuki Kiryuuin: líder fria e autoritária, representa o poder e o controle, mas também esconde vulnerabilidade.

  • Senktesu: o uniforme falante de Ryuko — uma metáfora viva sobre confiança e simbiose entre corpo e alma.


Comentário para padawans 🥋

“Kill la Kill” é uma aula disfarçada de insanidade.
Se você olhar só o visual, vai achar que é puro fanservice;
mas se assistir com atenção, vai perceber que é um ensaio sobre o fetiche, o poder e a autoaceitação.
É o tipo de anime que desafia o espectador a enxergar além do óbvio —
a entender que o fetichismo pode ser uma linguagem estética, uma provocação social e uma forma de autoconhecimento.


segunda-feira, 6 de janeiro de 2014

Curiosidades sobre o Japão que Todo Otaku Dev Mainframe Deveria Saber

 


🇯🇵 Curiosidades sobre o Japão que Todo Otaku Dev Mainframe Deveria Saber

Se você acha que anime é só cabelo colorido, olhos gigantes e batalhas infinitas… sinto informar: o Japão esconde mais camadas que um JCL bem escrito. Vamos abrir o dump cultural.


🧠 1. O Japão pensa em “sistemas”, não em “personagens”

No Japão, histórias raramente giram só em torno do herói.
O foco está no sistema: vilas, clãs, corporações, regras, contratos e hierarquias.

👉 Naruto não é sobre Naruto.
👉 Ghost in the Shell não é sobre a Major.
👉 Attack on Titan não é sobre Eren.

É tudo sobre como o sistema funciona — e como ele quebra.

📌 Mainframe vibes: primeiro vem a arquitetura, depois a aplicação.



🏯 2. Castelos japoneses explicam 80% dos animes

Os castelos não eram só fortalezas.
Eram data centers feudais: controle de acesso, hierarquia rígida, caminhos confusos para invasores.

Por isso tantos animes têm:

  • corredores infinitos

  • escadas simbólicas

  • salas proibidas

  • “você não tem permissão para estar aqui”

📌 Easter egg: subir uma torre = ascender no sistema. Igual migrar de operador para sysprog.


⏱️ 3. O Japão respeita o tempo como se fosse batch window

No Japão:

  • trem atrasado dá pedido público de desculpas

  • pontualidade é honra

  • repetir o processo até a perfeição é virtude

Isso explica:

  • episódios lentos

  • cenas longas de silêncio

  • treinamentos infinitos

  • arcos de preparação maiores que a batalha

📌 Bellacosa insight: não é filler, é processamento em background.


🧩 4. Anime ama legado, não inovação vazia

Enquanto o Ocidente idolatra o “novo”, o Japão pergunta:

“Isso honra o que veio antes?”

Por isso:

  • reboots são raros

  • remakes são respeitosos

  • mestres velhos sempre sabem algo

  • o passado nunca está morto

📌 Mainframe rule: sistema antigo não é obsoleto — é estável.


👘 5. Uniformes não são estética. São contrato social.

Em animes, todo mundo usa uniforme:

  • escola

  • empresa

  • clã

  • exército

  • café temático

Não é moda.
É papel social visível.

📌 Analogicamente: seu crachá define seu acesso. Seu kimono define sua função.


🌸 6. Flores dizem mais que diálogos

O Japão usa linguagem floral (Hanakotoba).
Animes usam isso o tempo todo:

  • 🌸 Cerejeira: impermanência

  • 🌺 Lírio: pureza ou morte

  • 🌻 Girassol: devoção silenciosa

  • 🌹 Rosa branca: amor impossível

📌 Easter egg: se uma flor aparece numa cena, preste atenção. É um comentário oculto do sistema.


⚙️ 7. Tecnologia japonesa é invisível (como mainframe)

No Japão, a melhor tecnologia:

  • não faz barulho

  • não chama atenção

  • simplesmente funciona

Por isso:

  • animes não explicam tudo

  • interfaces são minimalistas

  • máquinas parecem “vivas”, mas discretas

📌 Bellacosa truth: o melhor sistema é aquele que você esquece que existe.


🐺 8. Personagens solitários = operadores noturnos

O arquétipo do personagem calado, observador, solitário:

  • samurai errante

  • hacker silencioso

  • sensei que surge do nada

Eles não falam muito porque já viram falhas demais.

📌 Midnight Lunch mode: quem segura o sistema não faz discurso — faz backup.


🍱 9. Comer junto é mais importante que lutar

Repare:

  • depois da batalha, vem a refeição

  • times se formam à mesa

  • conflitos se resolvem com comida

No Japão, partilhar alimento cria laço.

📌 El Jefe insight: anime entende que confiança nasce no almoço, não no combate.


🧠 10. Anime não explica tudo de propósito

O Japão respeita o silêncio e a interpretação.
Se algo não foi dito, é porque:

  • você deveria sentir

  • não entender ainda

  • ou aceitar o mistério

📌 Mainframe final rule: nem todo log é para o usuário final.


☕ Conclusão: Anime é Cultura de Sistema

Se você curte anime e trabalha (ou admira) sistemas complexos, saiba:

  • o Japão pensa como arquiteto

  • escreve como sysprog

  • e conta histórias como quem mantém legado

Anime não é fuga da realidade.
É documentação poética de como o mundo funciona.

🍜 Nos vemos no próximo Midnight Lunch.

domingo, 5 de janeiro de 2014

Katsushika Hokusai: o sysprog do traço que rebootou a arte japonesa (e pariu o mangá)

 


Katsushika Hokusai: o sysprog do traço que rebootou a arte japonesa (e pariu o mangá)

Introdução – quando o batch da arte roda por 90 anos

No mainframe, a gente aprende cedo que sistemas legados bem feitos atravessam décadas. Na arte, acontece a mesma coisa.
E se existe um “MVS 3.8j” da cultura japonesa, esse sistema atende pelo nome de Katsushika Hokusai.

Hokusai não foi apenas um artista.
Ele foi um arquitetural designer cultural, um early adopter de estilos, um debugger obsessivo do próprio traço — e, sem exagero nenhum, um dos pais do mangá moderno.

Sim, mangá. Mas calma… já chegamos lá 😉



Biografia – IPL artístico iniciado em Edo (Tóquio antiga)

  • Nome: Katsushika Hokusai

  • Nascimento: 1760, Edo (atual Tóquio)

  • Morte: 1849, aos 88 anos (idade absurda pra época)

Hokusai viveu durante o Período Edo, quando o Japão era praticamente um sistema air-gapped: fechado ao mundo, sem internet, sem importações culturais externas. Mesmo assim, ele conseguiu influenciar o planeta inteiro.

Curiosidade de sysprog:
👉 Hokusai mudou de nome artístico mais de 30 vezes ao longo da vida.

No nosso mundo isso seria:

“Esse programador aqui já foi operador, analista, arquiteto, consultor, evangelista e agora atende como freelancer sênior”.

Cada nome novo representava uma nova versão do sistema, com melhorias, refatorações e até mudanças de paradigma visual.


Ukiyo-e – o VSAM da arte popular japonesa

Hokusai trabalhava com ukiyo-e, xilogravuras feitas em madeira.
Era a arte popular, barata, reproduzível — tipo print spool da cultura japonesa.

Nada de pintura única para elite:

  • Produção em massa

  • Distribuição ampla

  • Consumo cotidiano

📌 Tradução Bellacosa:

Hokusai democratizou a arte do mesmo jeito que o mainframe democratizou o processamento em larga escala.


A Grande Onda – o print que rodou o mundo

Se você já viu uma onda gigante quase engolindo barcos, parabéns: você já “executou” Hokusai sem perceber.

🌊 A Grande Onda de Kanagawa

  • Criada por volta de 1831

  • Parte da série “Trinta e Seis Vistas do Monte Fuji”

  • Influenciou artistas como Van Gogh, Monet e Debussy

Easter egg clássico:
👉 O Monte Fuji está lá… pequeno, estável, imutável.

No meio do caos, ele representa:

  • Permanência

  • Ordem

  • Estabilidade

Ou seja:

Enquanto a onda é o incidente em produção, o Fuji é o mainframe — sempre lá.


Hokusai Manga – quando nasce o “manual técnico” do mangá

Agora o ponto que interessa aos curiosos de plantão 👀

📘 Hokusai Manga

Não era mangá como conhecemos hoje (história sequencial com balões), mas sim:

  • Cadernos de esboços rápidos

  • Pessoas, monstros, cenas do cotidiano

  • Humor, exagero, movimento

“Manga” significava algo como:

desenhos espontâneos / rabiscos livres

📌 Bellacosa explica:

Hokusai criou um “dump visual” do Japão da época.

Esses cadernos:

  • Serviam para estudo

  • Inspiração

  • Ensino

  • Replicação de estilo

Sem querer, ele lançou a base conceitual do mangá moderno.


Curiosidades – o artista que nunca fechava o chamado

  • Hokusai dizia que só começou a desenhar bem depois dos 70 anos

  • Aos 88, pouco antes de morrer, afirmou:

    “Se eu tivesse mais 10 anos, seria um verdadeiro artista”

Isso é praticamente:

“Ainda não fechei esse incidente, mas o fix tá quase pronto”

Ele também:

  • Viveu pobre grande parte da vida

  • Mudava de casa constantemente (quase um nomad computing)

  • Era obcecado por melhorar o traço até o último dia


Inspiração – legado é mais forte que hype

Hokusai nos ensina algo poderoso:

  • Não importa a ferramenta

  • Não importa o contexto

  • Consistência vence moda

Ele não viu o impacto global da sua obra.
Mas hoje:

  • Está em museus do mundo inteiro

  • Influencia quadrinhos, animações, games e cultura pop

  • Está embutido no DNA do mangá e do anime


Dicas Bellacosa (vale pra arte, código e vida)

💡 1. Refatore sempre
Hokusai nunca considerava o trabalho “pronto”.

💡 2. Documente seu processo
Os cadernos Hokusai Manga são ouro puro até hoje.

💡 3. Popular não é sinônimo de raso
Ukiyo-e era “arte barata” — e virou patrimônio mundial.

💡 4. Longa vida ao legado
Faça coisas que sobrevivam à próxima versão.


Fofoquice histórica (porque ninguém é de ferro 😄)

Dizem que Hokusai:

  • Esquecia de pagar aluguel

  • Vivia atolado em dívidas

  • Era caótico no dia a dia

Mas quando sentava pra desenhar…

rodava em modo production sem falha.

Genial, difícil, humano — como todo grande arquiteto de sistemas.


Fechamento – do ukiyo-e ao mangá, do papel ao mundo

Se hoje você lê mangá, assiste anime ou consome cultura japonesa, saiba:
👉 Hokusai está no background, rodando como um serviço essencial.

No El Jefe Midnight Lunch, a gente celebra isso:

  • Cultura

  • Profundidade

  • Curiosidade

  • E aquele prazer nerd de conectar pontos improváveis

Porque no fim…

arte, código e histórias são só diferentes formas de registrar o mundo.

☕🌊📚