sábado, 2 de maio de 2009

SMP/E: RECEIVE, APPLY e ACCEPT na vida real - Parte 4

 

Bellacosa Mainframe apresenta IBM SMP/E

📘 Série SMP/E para Iniciantes

Parte 4 – RECEIVE, APPLY e ACCEPT na vida real

“SMP/E não é teoria.
É JCL rodando às 3 da manhã… e tem que dar RC=0.”


🧠 O fluxo sagrado do SMP/E

No mundo real, todo SYSMOD passa obrigatoriamente por três fases:

RECEIVE → APPLY → ACCEPT

👉 Pular etapa não é atalho.
É atalho para incidente.


📥 RECEIVE — trazendo o SYSMOD para casa

O que o RECEIVE faz?

  • Lê o PTF/APAR/FUNCTION

  • Registra no CSI

  • Torna o SYSMOD conhecido pelo SMP/E

📌 RECEIVE não muda o sistema.


Exemplo de JCL (simplificado)

SET BDY(GLOBAL). RECEIVE SYSMODS.

👉 Fontes comuns:

  • IBM Shopz

  • FTP

  • Portable datasets


Erros comuns no RECEIVE

  • SYSMOD duplicado

  • FMID inexistente

  • CSI incorreto

💡 Dica Bellacosa:

“RECEIVE falhou? Nem pense em APPLY.”


🧪 APPLY — onde o risco começa

O que o APPLY faz?

  • Copia módulos para TARGET libraries

  • Atualiza o sistema executável

  • Respeita VER, HOLD e ERROR

👉 Aqui o código passa a existir de verdade.


APPLY CHECK (obrigatório!)

SET BDY(TARGET). APPLY CHECK.

Ele mostra:

  • Conflitos

  • Dependências

  • HOLDs

  • ERRORs

📌 Nunca pule o CHECK.


APPLY real

SET BDY(TARGET). APPLY.

📌 Pode exigir:

  • IPL

  • Parada de subsistema

  • Ação manual


Erros comuns no APPLY

  • Ignorar ++HOLD

  • APPLY direto em produção

  • Não validar impacto

👉 Aqui nascem as histórias de guerra.


📦 ACCEPT — consolidando a verdade

O que o ACCEPT faz?

  • Atualiza o DLIB

  • Define o baseline oficial

  • Prepara futuras manutenções

📌 ACCEPT não muda o sistema executável.


Exemplo de JCL

SET BDY(DLIB). ACCEPT.

Erros comuns no ACCEPT

  • ACCEPT sem teste

  • ACCEPT em ambiente errado

  • DLIB desatualizado

💡 Dica Bellacosa:

“ACCEPT é compromisso. Não faça de cabeça quente.”


🧩 Quem mexe em quê?

ComandoAfetaExecutável?
RECEIVECSI
APPLYTARGET
ACCEPTDLIB

🔄 Rollback existe (mas dói)

RESTORE

  • Reverte APPLY

  • Não é trivial

  • Depende do histórico

👉 Rollback não é Ctrl+Z.


🧠 Caso real (estilo Bellacosa)

Um PTF aplicado sem APPLY CHECK
ignorou um ++HOLD de IPL
Resultado: JES instável pós-manutenção

📌 Moral:

O SMP/E avisou. Alguém não leu.


🎓 Boas práticas de produção

  • Sempre APPLY CHECK

  • Leia HOLDS

  • Separe ambientes

  • Documente ACCEPTs

  • Nunca automatize cegamente


🧠 Curiosidades Bellacosa

  • RECEIVE é burocracia

  • APPLY é tensão

  • ACCEPT é responsabilidade


🧾 Comentário final – Parte 4

RECEIVE informa.
APPLY muda.
ACCEPT oficializa.

Quem entende isso domina o SMP/E.


📌 Próxima Parte da Série

👉 Parte 5 – Laboratório SMP/E: Workshop prático passo a passo


quinta-feira, 9 de abril de 2009

🧔‍♂️💈 Seus REORGs do Db2 estão criando barba?

 

Bellacosa Mainframe apresenta o reorg do db2 

🧔‍♂️💈 Seus REORGs do Db2 estão criando barba?

Ou: quando o REORG vira o primo cabeludo do ambiente z/OS

Se você trabalha com IBM Mainframe + Db2 z/OS há mais de cinco minutos, já sabe:
👉 REORG não é luxo, é higiene básica do banco.
O problema é como ele costuma ser tratado no mundo real.

Em ambientes médios e grandes, o cenário é quase sempre o mesmo:

  • Centenas (às vezes milhares) de jobs de REORG

  • Criados por times de aplicação diferentes

  • Cada um com seu “jeitinho especial”

  • Scripts frágeis

  • Dependências implícitas

  • CHECK DATA aqui, DISCARD ali

  • E quando um passo falha… 🔥 incêndio operacional 🔥

É aí que surge a pergunta filosófica do DBA moderno:

“Será que meus REORGs estão criando barbas?”

Porque quando o REORG cresce sem controle, ele fica:

  • desalinhado

  • imprevisível

  • difícil de reiniciar

  • impossível de auditar

  • e um pesadelo para compliance 😈


🧠 Um pouco de história (porque Bellacosa sempre conta)

Lá atrás, no “Velho Testamento do Db2”, REORG era quase um ritual sagrado:

  • Janela batch gigante

  • Tudo parado

  • DBA com café forte

  • E muito JCL artesanal

Com o tempo:

  • Vieram REORG SHRLEVEL CHANGE

  • Depois ONLINE

  • Depois automação

  • Depois… bagunça organizada (ou nem isso)

O problema não é o REORG.
O problema é a falta de controle centralizado sobre quando, como e por quê ele roda.


🎯 O ponto crítico: falta de controle central

Vamos ser honestos (fofoquinha de corredor):

  • Times de aplicação sabem criar REORG

  • Mas não querem (nem devem) cuidar de padrão corporativo

  • DBA vira o “bombeiro de utilitário”

  • Restart vira arqueologia

  • Auditor pergunta:

    “Quem rodou esse REORG? Quando? Por quê? Com qual critério?”

  • E o DBA responde:

    “Então… veja bem…” 😬

Script-driven process é frágil.
Um COND CODE mal interpretado e todo o castelo cai.


⚡ Power Up Your Db2 REORGs (sem quebrar nada)

É aqui que se separa as crianças dos adultos.

E já vou adiantar o diferencial que faz o DBA sorrir:

🧙‍♂️ Sem mudar JCL

Sim. Você leu certo.
Nada de refatorar centenas de jobs legados.

🧩 Sem impactar os fluxos de aplicação

Os times continuam criando seus REORGs como sempre.

🏛️ Separação clara de papéis

  • Aplicação: o que precisa

  • DBA: como, quando e sob quais regras

Esse detalhe é ouro em ambientes corporativos.


🧰 O que muda na prática?

O Mestre dos Magos do DB2 deve agir como um orquestrador invisível:

  • Centraliza a execução

  • Aplica padrões

  • Controla paralelismo

  • Registra tudo

  • E mantém compliance feliz (raridade!)

Tudo isso transparente, sem “quebrar” o legado.


📚 O que você aprende (e ganha) com essa abordagem

🔍 Seleção inteligente de REORGs

Nada de “REORG por feeling”:

  • Regras

  • Thresholds

  • Estatísticas reais

  • Prioridades de negócio

📏 Ajuste automático de espaço

  • Tablespace cresceu? Ajusta.

  • Encolheu? Otimiza.
    Sem DBA das organizações Tabajara ficar refazendo cálculo no guardanapo.

🧭 Impacto em access path? Sim, senhor!

  • Análise pós-REORG

  • REBIND opcional e controlado

  • Nada de surpresa em produção segunda-feira cedo ☕😱

⚙️ Paralelismo com limites

  • Executa múltiplos objetos

  • Respeitando cotas

  • Sem matar o LPAR

  • Sem “storm” de utilitários

📊 Relatórios e auditoria

  • Quem rodou

  • Quando

  • Por quê

  • Com quais critérios

Auditor pergunta → você mostra relatório → fim da conversa.


🥚 Easter Eggs para DBAs atentos

  • REORG sem governança é dívida técnica disfarçada

  • “Sempre rodamos assim” não é estratégia

  • REORG automático não substitui DBA — ele liberta o DBA

  • O maior inimigo da performance não é fragmentação… é improviso


🗣️ Comentário de bastidor (aquele sincero)

Se você:

  • Vive apagando incêndio de REORG

  • Já perdeu noite com restart quebrado

  • Já ouviu “foi só um REORGzinho”

  • Ou já explicou access path estranho depois de maintenance…

Então você não precisa rodar mais REORG.
Você precisa rodar REORG com controle.


🎓 Conclusão estilo Bellacosa

REORG não pode ser selvagem.
REORG precisa de coleira, guia e pedigree.

Automatizar sem padronizar é só acelerar o caos.
Centralizar sem mudar o legado é maturidade operacional.

Se seus REORGs estão “esta crescendo as barbas ”, talvez não seja hora de cortar…
👉 é hora de pentear com inteligência.

☕💙
Um café, um REORG bem governado e um DBA feliz.


quarta-feira, 8 de abril de 2009

🜂 Folclore Brasileiro em Modo Nativo

 

Bellacosa Mainframe apresenta o Folclore brasileiro para padawans

🜂 Folclore Brasileiro em Modo Nativo

 para mainframers, otakus e curiosos que sabem que todo sistema tem alma


Introdução — quando o batch encontra o mito

Se você é mainframer, você entende uma coisa que muita gente não entende mais: sistemas antigos não são ultrapassados — são estáveis porque funcionam. Se você gosta de anime, você já percebeu outra coisa: toda boa história tem mitologia, regras internas, entidades, ciclos e consequências. Agora junta isso tudo e olha com atenção para o folclore brasileiro.

Spoiler: ele é um sistema distribuído milenar, documentado oralmente, resiliente, cheio de regras implícitas, processos em background, guardiões, exceções, erros fatais e lições que atravessam gerações.

O problema é que a gente cresceu achando que folclore era coisa de criança. Não é. Folclore é arquitetura cultural.

E hoje eu quero te mostrar isso em modo production ready.


1. Folclore não é lenda — é documentação viva

No mundo mainframe, documentação não nasce em PDF bonito. Ela nasce na prática, na falha, no incidente, no “não faz isso que dá problema”. O folclore funciona exatamente assim.

Antes de existir escrita formal, os povos originários do Brasil — Tupi, Guarani, Macro-Jê, Aruak e tantos outros — mantinham o conhecimento via transmissão oral, em ciclos repetidos, reforçados por histórias fortes, simbólicas e fáceis de lembrar.

Não é diferente de um JCL comentado passado de operador para operador.

“Não entra na mata sem pedir licença.”
“Não pesca mais do que precisa.”
“Não ri da noite.”

Isso não é superstição. Isso é controle de acesso ambiental.


2. Arquitetura do sistema: o mundo como ambiente de produção

No folclore brasileiro, o mundo não é um sandbox descartável. Ele é ambiente produtivo. E produção não perdoa.

A floresta, o rio, o céu, a noite e os animais não são cenários — são componentes do sistema.

  • A floresta é o storage

  • O rio é o data stream

  • O vento é o scheduler

  • O fogo é o commit irreversível

Se você faz algo fora das regras, não aparece um deus te punindo. O que acontece é pior: o sistema entra em estado inconsistente.

E aí surgem os processos de correção.


3. Curupira — o anti-debugger da mata 🌿

Vamos começar pelo mais famoso entre os mainframers do mato.

Curupira não é “monstrinho”. Ele é um mecanismo de proteção contra exploração predatória.

  • Pés virados para trás?
    → Rastreamento confuso, logs invertidos.

  • Aparece para quem caça por ganância?
    → Detecção baseada em comportamento, não identidade.

  • Some quando respeitado?
    → Sistema entra em estado estável.

No mundo anime, o Curupira seria um guardião de dungeon que não ataca jogadores conscientes, só os que tentam farmar além do permitido.

Easter egg: pés invertidos são um truque narrativo genial. Quem tenta seguir o rastro se perde. É engenharia social aplicada à sobrevivência da floresta.


4. Boitatá — firewall de fogo 🔥

Boitatá é descrito como uma serpente de fogo, olhos brilhantes, presença silenciosa.

Tradução técnica:
➡️ Firewall ambiental contra destruição deliberada.

Ele aparece onde há:

  • incêndio criminoso

  • destruição gratuita

  • invasão sem propósito

No anime, seria aquele espírito elemental que surge quando o equilíbrio é quebrado. Pense em Princess Mononoke. Isso é Boitatá rodando em background.

Curiosidade: o fogo do Boitatá não é caos — é limpeza corretiva. Ele protege, não consome.


5. Iara — engenharia social aquática 🌊

Ah, a Iara… mal interpretada por séculos.

Não é “sereia malvada”. É teste de atenção.

Ela aparece:

  • para quem navega distraído

  • para quem subestima o rio

  • para quem confunde beleza com segurança

No mundo técnico: Iara é phishing emocional. Se você não entende o ambiente, cai.

Anime check: quantos personagens caem porque ignoram alertas óbvios? Iara é isso, só que com canto bonito e consequências fatais.


6. Saci — o hacker caótico 🌀

O Saci é o personagem mais subestimado do folclore.

Ele:

  • altera pequenos detalhes

  • esconde objetos

  • muda resultados sem causar desastre total

  • aparece rindo

Saci é chaos engineering.

Ele não destrói o sistema. Ele testa sua paciência, sua atenção e sua humildade.

Se você tenta capturá-lo à força, perde.
Se negocia, aprende.

Mainframer entende isso: nem todo erro é falha crítica. Alguns são teste de resiliência.


7. Noite, Lua e Sol — clock e scheduler 🌙☀️

No folclore indígena:

  • Jaci (Lua) controla ciclos, fertilidade, descanso.

  • Guaraci (Sol) regula crescimento, tempo, esforço.

Isso não é poesia. Isso é sincronização de processos.

Trabalhar contra o ciclo gera falha.
Descansar na hora errada gera erro.
Ignorar o tempo gera desgaste.

É o cron job mais antigo da humanidade.


8. Folclore x Anime — por que isso combina tanto?

Se você gosta de anime, já percebeu:

  • Espíritos não são bons nem maus — são função.

  • Poder tem custo.

  • O mundo responde às ações.

  • Exagero gera punição indireta.

Tudo isso já estava no folclore brasileiro.

O problema é que a gente cresceu olhando para fora e esquecendo o que estava rodando localmente.

Curiosidade amarga: o Brasil tem um folclore tão rico quanto o japonês, mas nunca fez world building consistente com ele. Falta coragem cultural.


9. Easter eggs culturais escondidos no dia a dia 🥚

Você já ouviu:

  • “Não aponta pra lua.”

  • “Respeita a mata.”

  • “Não ri da noite.”

  • “A noite escuta.”

Isso é folclore operacional, rodando sem manual.

São avisos comprimidos em frases simples, transmitidos sem precisar explicar o motivo técnico.


10. O que o folclore ensina para quem trabalha com tecnologia

Se você é mainframer, arquiteto, dev ou operador, o folclore brasileiro ensina coisas valiosas:

  • Sistemas vivos exigem respeito.

  • Nem tudo precisa ser explorado ao máximo.

  • Equilíbrio é mais importante que performance.

  • Nem todo erro é bug — às vezes é feedback.

  • O ambiente responde ao abuso.

Isso é DevOps espiritual, muito antes do termo existir.


11. Por que resgatar o folclore agora?

Vivemos num mundo de:

  • cloud sem dono

  • consumo sem limite

  • IA sem ética

  • sistemas opacos

O folclore brasileiro lembra algo essencial:

Todo sistema tem consequências.

Não existe ação isolada.
Não existe impacto zero.
Não existe exploração infinita.


12. Comentário Bellacosa Mainframe ☕💾

Talvez o maior erro da nossa geração tenha sido achar que modernidade significa esquecer o passado.

O folclore brasileiro não é atraso.
Ele é base de dados histórica, validada por séculos de execução contínua.

Se o Japão transformou seus mitos em anime, games e filosofia pop, a gente também pode — sem copiar, sem diluir, sem pedir licença.

O Curupira não precisa de CGI.
O Saci não precisa virar piada.
O Boitatá não precisa ser esquecido.

Eles só precisam voltar a rodar em produção.

E quem sabe, assim como no mainframe, a gente aprenda que o sistema mais antigo ainda é o mais confiável.

🜂 FIM DO JOB — RC=0000

terça-feira, 7 de abril de 2009

SMP/E: MCS na prática: ++VER, ++HOLD, ++ERROR sem medo - Parte 3

 

Bellacosa Mainframe apresenta IBM SMP/E

📘 Série SMP/E para Iniciantes

Parte 3 – MCS na prática: ++VER, ++HOLD, ++ERROR sem medo

“Quem domina MCS manda no SMP/E.
Quem ignora MCS vira refém do APPLY.”


🧠 Relembrando: o que são MCS?

MCS (Modification Control Statements) são as instruções formais que acompanham um SYSMOD.

Elas dizem ao SMP/E:

  • O que é o SYSMOD

  • Onde ele se aplica

  • De que depende

  • Quais são os riscos

  • Quando parar e pedir atenção humana

📌 Regra de ouro:
Toda MCS começa com:

++

🧩 As três MCS que mais derrubam iniciantes

Nesta parte, vamos direto às três mais importantes do dia a dia:

  • ++VER

  • ++HOLD

  • ++ERROR


🔎 ++VER — o filtro de compatibilidade

O que é?

O ++VER garante que o SYSMOD só seja aplicado na versão correta do produto.

👉 Tradução Bellacosa:

“Isso só entra se o ambiente for compatível.”


Exemplo:

++VER(Z038) FMID(HJES770).

Isso significa:

  • z/OS versão Z038

  • Produto JES2 (HJES770)

❌ Sem ++VER, o risco de aplicar PTF errado aumenta muito.


Dica Bellacosa

Se o ++VER não bate, o APPLY trava.
E isso é proteção, não problema.


🚨 ++HOLD — o aviso que você nunca deve ignorar

O que é?

O ++HOLD não é erro, é alerta.

Ele indica:

  • Passos manuais necessários

  • Impacto operacional

  • Dependências externas

  • Necessidade de IPL


Tipos comuns de HOLD

  • SYSTEM → impacto no sistema

  • ACTION → ação manual requerida

  • ERROR → problema conhecido

  • SECURITY → impacto de segurança


Exemplo:

++HOLD(SYSTEM) REASON(REQUIRES IPL).

📌 Tradução:

“Isso funciona, mas só depois de um IPL.”


Dica Bellacosa

HOLD não bloqueia, mas cobra atenção.
Ignorou, o sistema cobra depois.


🔥 ++ERROR — o alerta máximo

O que é?

O ++ERROR marca um PTF com defeito conhecido.

📌 Ele diz:

“Essa correção tem problema. Use por sua conta e risco.”


Exemplo:

++ERROR.

Isso indica:

  • APAR ainda não resolvido

  • Correção parcial

  • Risco conhecido


Regra Bellacosa

Nunca aplique um ++ERROR sem ler a APAR.

Em ambientes críticos, muitas vezes:

  • Aguarda-se o superseding PTF

  • Ou aplica-se com mitigação


🧪 APPLY CHECK: seu melhor amigo

Antes de qualquer APPLY real:

APPLY CHECK

Ele mostra:

  • Impacto do SYSMOD

  • Dependências

  • Conflitos

  • HOLDs e ERRORs

💡 Dica Bellacosa:

“Quem usa APPLY CHECK dorme melhor.”


🧬 Relação entre ++VER, ++HOLD e ++ERROR

StatementBloqueia APPLY?Função
++VERSimCompatibilidade
++HOLDNãoAlerta
++ERRORNãoErro conhecido

👉 SMP/E confia no sysprog, não no automático.


🧠 Curiosidades Bellacosa

  • Um único ++HOLD ignorado já causou outages históricos

  • ++ERROR existe para proteger a IBM e o cliente

  • ++VER é o “cinto de segurança” do SMP/E


🧾 Comentário final – Parte 3

MCS não são opcionais.
São contratos técnicos.
E contrato mal lido dá problema.


📌 Próxima Parte da Série

👉 Parte 4 – RECEIVE, APPLY e ACCEPT na vida real


segunda-feira, 6 de abril de 2009

💾 Capítulo 3 — Boot inicial: o mundo além da escola

 

📚 SÉRIE “Sempre um Isekai”

Por Bellacosa Mainframe
(Memórias de um garoto que aprendeu a trocar de mundo sem sair da sala de aula)


💾 Capítulo 3 — Boot inicial: o mundo além da escola

O fim do colegial chegou rápido — como o ponto final de um livro que a gente queria que tivesse mais capítulos.
Mas o próximo volume já estava sendo escrito: o mundo do trabalho.

Com o diploma técnico em mãos e a curiosidade de quem sempre foi estrangeiro de si mesmo, entrei no universo do Processamento de Dados — ainda não se falava em “TI”.
Era um tempo em que o computador ocupava salas inteiras, e a palavra “mainframe” soava como magia industrial.
Aquele mundo lógico e silencioso me acolheu como nenhum outro.
Ali, finalmente, eu não era o aluno novo — eu era o programador que aprendia a dialogar com máquinas, e cada compile successful era uma nova forma de pertencer.

Percebi que, afinal, viver em trânsito não era desvantagem — era um sistema operacional de alma.
Ser o “novo” sempre me ensinou a observar, adaptar e reconstruir — exatamente o que um bom analista faz.
Minha vida inteira foi um boot contínuo: cada cidade, uma reinicialização; cada escola, uma nova rotina; cada linha de código, uma lembrança em hexadecimal.

Trabalhando como office-boy foi conquistando meu espaço, crescendo, fiz a faculdade, pós-graduação e mestrado, cresci academicamente, mas não abandonei os meus, protegi o quanto pode e ajudei a todos a trilharem o bom caminho. Não imagina que seria apenas o começo e que este isekai iria ainda mais longe, desta vez atravessando o oceano, mas isso já é outra história.

E talvez seja isso o que nos torna humanos no mundo das máquinas: a capacidade de recomeçar sem perder a memória.


☕ Epílogo — O Isekai Real

No fim das contas, percebo que nunca precisei ser transplantado para outro mundo.
Meu isekai sempre foi aqui mesmo — entre escolas, cidades e sistemas que me forjaram.
E, como todo bom personagem de jornada, aprendi que mudar é só outra forma de continuar.


Série “Sempre um Isekai”
Um relato sobre educação, adaptação e vocação — onde cada reboot é também um renascimento.
Assinado: Bellacosa Mainframe


quarta-feira, 18 de março de 2009

🌿 SHISO VERMELHO – A ERVA JAPONESA QUE PINTA A MEMÓRIA

 

Bellacosa Mainframe apresenta shiso vermelho

🌿 SHISO VERMELHO – A ERVA JAPONESA QUE PINTA A MEMÓRIA

 

Se você já assistiu anime, leu mangá ou se aventurou numa receita japonesa mais raiz, uma hora esbarrou nele: shiso vermelho. Às vezes discreto, às vezes protagonista, mas sempre ali, rodando em background como um daemon cultural do Japão.

Hoje vou te contar a história dessa erva que parece simples, mas carrega cor, aroma, superstição, medicina, comida e memória.


shiso

🌱 O QUE É SHISO?

Shiso (紫蘇) é uma erva da família da hortelã.
Existem dois tipos principais:

  • 🟢 Shiso verde (aojiso) – fresco, herbal, muito usado como folha

  • 🔴 Shiso vermelho (akajiso) – mais intenso, levemente amargo, usado para cor, conserva e fermentação

O shiso vermelho é o sysprog da cozinha japonesa: não aparece sempre, mas quando entra… muda tudo.


🏯 ORIGEM & HISTÓRIA

O shiso veio da China há mais de 2.000 anos, mas foi no Japão que ele ganhou identidade própria.

Originalmente usado como:

  • Planta medicinal

  • Conservante natural

  • Antídoto contra intoxicações alimentares

📜 Textos antigos diziam que shiso “acalma o espírito e limpa o sangue”.
Ou seja: debug emocional e físico.


🍙 USO CLÁSSICO NA CULINÁRIA

O shiso vermelho aparece em:

  • Umeboshi (ameixa japonesa)

  • Umezu (líquido da conserva)

  • Furikake

  • Conservas de legumes

  • Bebidas fermentadas

  • Doces tradicionais

👉 Ele é responsável pela cor vermelha icônica da umeboshi.
Sem shiso, a ameixa fica bege, triste, sem alma.
É tipo CICS sem terminal: funciona, mas não encanta.


🧪 CURIOSIDADE TÉCNICA (EASTER EGG BOTÂNICO)

A cor vermelha do shiso vem da antocianina, que:

  • Muda de cor conforme o pH

  • Fica vermelho intenso em meio ácido

  • Era usada como indicador natural antes da química moderna

📌 Sim, o shiso era um pH meter ancestral.


🥋 SHISO EM ANIMES & CULTURA POP

Você já viu shiso em:

  • 🍙 Animes slice of life – preparo de onigiri e umeboshi

  • 🏯 Animes históricos – conservas caseiras

  • 👘 Cenários rurais – quintais e hortas tradicionais

  • 🧘 Obras contemplativas – símbolo de cuidado e tempo

Ele quase nunca é explicado.
Porque no Japão, todo mundo sabe o que é shiso.


🧠 DICAS DE VETERANO

✔ Não confundir com manjericão
✔ Shiso vermelho é mais forte que o verde
✔ Seco dura meses
✔ Fresco estraga rápido (volatile dataset)
✔ Aroma lembra hortelã + canela + terra molhada


👀 FOFOQUICES DE COZINHA

🍃 Criança japonesa que ajuda a fazer umeboshi fica com as mãos roxas
🍃 Casas antigas tinham shiso no quintal como “erva de proteção”
🍃 Era usado para “neutralizar” peixe suspeito antes da refrigeração


🧠 FILOSOFIA ESCONDIDA

Shiso vermelho ensina:

  • Mottainai – nada se desperdiça

  • Tempo – não se apressa fermentação

  • Wabi-sabi – beleza na imperfeição da cor

  • Memória – sabor que atravessa gerações


🏁 CONCLUSÃO BELLACOSA

O shiso vermelho não grita.
Não aparece em propaganda.
Não pede holofote.

Mas sem ele, a cozinha japonesa perde alma, cor e história.

É a erva que roda silenciosa no background…
igual mainframe.

🌿Aqui, até a erva tem memória.

terça-feira, 17 de março de 2009

🧠 Agile de Verdade: Por que Planejar Tudo no Início Falha (e o que Fazer em Vez Disso)

 

Bellacosa Mainframe agile kanbam estouro de prazo

🧠 Agile de Verdade: Por que Planejar Tudo no Início Falha (e o que Fazer em Vez Disso)

Por El Jefe — Estilo Bellacosa Mainframe


Introdução: o som dos prazos passando voando

Douglas Adams resumiu melhor do que qualquer framework:

“Eu amo prazos. Adoro o som que eles fazem quando passam voando. Whoosh!”

Se você trabalha com projetos — especialmente em TI, mainframe, DevOps ou software corporativo — já ouviu esse som.
Planejamos tudo no início, cravamos uma data… e erramos.

A pergunta não é se isso vai acontecer.
A pergunta é: por que insistimos em fazer isso?


O erro clássico: decidir tudo quando você sabe o mínimo

No início de um projeto, sabemos quase nada:

  • Requisitos ainda são hipóteses

  • Sistemas dependentes mudam

  • Patches surgem

  • Prioridades do negócio se ajustam

Mesmo assim, é exatamente nesse momento que:

  • Criamos cronogramas longos

  • Estimamos prazos fixos

  • Prometemos entregas distantes

📌 Bellacosa rule #1

Não decida tudo no ponto em que você sabe menos sobre o problema.


A analogia dos pinguins (e por que ela funciona)

Imagine atravessar um campo cheio de pinguins em movimento.

  • No início, você escolhe os primeiros passos

  • No meio do caminho, o cenário já mudou

  • Quanto mais avança, melhor é sua visão

Agora troque:

  • Pinguins por dependências

  • Campo por projeto

  • Movimento por mudança constante

Isso é desenvolvimento de software.
Isso é modernização de sistemas.
Isso é Agile.


Planejamento iterativo: navegar, não adivinhar

Agile não elimina planejamento.
Ele elimina planejamento ilusório.

A ideia é simples:

  • Planeje o que você conhece agora

  • Avance um pouco

  • Aprenda

  • Ajuste

  • Repita

🎯 Precisão real:

  • Planejar 3 meses à frente → ~50% de acurácia

  • Planejar 2 semanas → quase 100%

📌 Bellacosa rule #2

Agile não tenta ser onisciente. Agile aprende rápido.


O segundo grande erro: trocar cargos sem mudar mentalidade

Quando empresas “viram Agile”, algo perigoso costuma acontecer:

  • Product Manager vira Product Owner

  • Project Manager vira Scrum Master

  • Time de desenvolvimento vira “Scrum Team”

Tudo isso sem treinamento.

Resultado? Fracasso previsível.


Product Manager ≠ Product Owner

  • Product Manager

    • Cargo

    • Foco em orçamento e operação

  • Product Owner

    • Papel do Scrum

    • Visionário

    • Conecta negócio e tecnologia

    • Define valor e experimentos

📌 Podem ser a mesma pessoa? Sim.
📌 Devem ser automaticamente? Não.


Project Manager ≠ Scrum Master

Aqui mora o choque cultural.

Project Manager

  • Controla tarefas

  • Cobra plano

  • Documenta riscos

Scrum Master

  • Atua como coach

  • Remove impedimentos

  • Protege o time

  • Incentiva auto-organização

📌 Diferença brutal
O Project Manager pergunta:

“Como você vai se destravar?”

O Scrum Master diz:

“Deixa comigo. Vai produzir.”


Development Team ≠ Scrum Team

  • Development Team: só desenvolvedores

  • Scrum Team: time cross-functional

Inclui:

  • Dev

  • Teste

  • Ops

  • Segurança

  • Negócio

📌 Agile sem time multidisciplinar é teatro corporativo.


Sem apoio da gestão, Agile não escala

Essa é a verdade que dói.

Gestão tradicional pergunta:

  • “O que você entrega até o fim do ano?”

Gestão ágil pergunta:

  • “O que você entrega nas próximas duas semanas?”

  • “Qual valor chega ao cliente neste sprint?”

📌 Bellacosa rule #3

Agile só funciona quando a liderança muda as perguntas.


Ferramentas não tornam ninguém ágil

Kanban, Jira, ZenHub, GitHub…
Ferramentas não criam mindset.

Elas apenas:

  • Dão visibilidade

  • Sustentam o processo

  • Reduzem ruído

Se o processo é Waterfall, o Kanban vira um Gantt disfarçado.


Kanban sem frescura: simples, visual e honesto

Kanban é só isso:

  • O que preciso fazer

  • O que estou fazendo

  • O que já fiz

Trabalho flui da esquerda para a direita.
Sem mágica. Sem burocracia.


Pipelines: uma visão clara do fluxo

Um Kanban típico tem:

  • New Issues – entrada

  • Icebox – longo prazo

  • Product Backlog – tudo que queremos

  • Sprint Backlog – próximas duas semanas

  • In Progress – trabalho ativo

  • Review / QA – validação

  • Done – concluído

📌 Uma única fonte da verdade.
📌 Atualizada automaticamente onde o dev já trabalha.


Conclusão: Agile não é moda, é sobrevivência

Agile não é sobre:

  • Framework

  • Cerimônia

  • Ferramenta

Agile é sobre:

  • Aprender rápido

  • Planejar melhor

  • Entregar valor continuamente

  • Aceitar que o desconhecido faz parte do jogo

📌 Bellacosa final rule

Quem tenta controlar o futuro perde o presente.
Quem aprende continuamente constrói o futuro.