Translate

segunda-feira, 2 de março de 2009

✏️ Capítulo 2 — Giz, Mimiógrafo e Destinos Impressos

 


📚 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 2 — Giz, Mimiógrafo e Destinos Impressos

Vim de um tempo em que mal aluno com fraco desempenho era reprovado mesmo — sem dó, piedade e sem discurso motivacional.

Mas eu era bom aluno, sempre me destaquei em todas as matérias, ops, quase todas, era abaixo da média em Educação Física, odiava os exercícios, ter que jogar bola, realmente era algo que não me dava prazer. O curioso é que fora a escola jogava vôlei e futebol normal, andava quilômetros em bicicleta, capinava quintais para ganhar uns trocos. O problema era a questão da aula mesmo... quero dizer não era preguiçoso, só não gostava mesmo, era um nerd, que vivia na biblioteca municipal fazendo pesquisas, numa era sem IA e Google para recuperar pontos em EF.

Passei pelos quatro anos do primário com sucesso, mantive boas notas no ginásio e alcancei a glória sendo um aluno brilhante e invejado e vi o colegial passar num piscar de olhos, nesta época já trabalhava então não foi o melhor alunos, mas estive no Top.

Foi ali que me formei técnico em Processamento de Dados, colegial-tecnico onde aprendiamos o suficiente para prestar o Vestibular, mas garantia uma profissão com melhor remuneração, que abriria as portas do mundo empresarial e me levaria, anos depois, aos corredores sagrados do mainframe.


Naquele tempo, informática ainda tinha cheiro de papel perfurado e fita magnética.
Falar em computador era falar em futuro — e eu queria estar lá, digitando linhas de destino no teclado verde-fósforo, não era um IBM Mainframe, mas sim um microcomputador de 8 bits da marca CP 500.

Participei do centro acadêmico no ginásio e no colegial — outros nomes, mesma essência: alunos que acreditavam poder melhorar o mundo começando pela escola.




Produzíamos jornalzinhos em mimiógrafo, ajudávamos em festas e eventos, organizávamos campeonatos e saraus.





Eram tempos simples, mas cheios de propósito e camaradagem.


Foram anos gratificantes, cheios de aventura, cheiro de álcool e papel úmido, onde cada professor era um farol e cada colega, um companheiro de travessia.


sábado, 14 de fevereiro de 2009

💣 SCHOOL DAYS NÃO É ROMANCE — É UM ABEND EM PRODUÇÃO COM CORE DUMP EM TEMPO REAL

 

Bellacosa Mainframe mergulha no polemico School Days

💣 SCHOOL DAYS NÃO É ROMANCE — É UM ABEND EM PRODUÇÃO COM CORE DUMP EM TEMPO REAL

Se você entrou em School Days esperando um “romance escolar”, parabéns:
você acabou de subir um job inocente que vai derrubar o ambiente inteiro.

Isso aqui não é anime de namoro.
👉 É falha catastrófica de comportamento humano rodando sem controle de exceção.


🧠 📦 IDENTIFICAÇÃO DO SISTEMA

  • 🎬 Anime: School Days
  • 📅 Lançamento: 2007 (TV japonesa)
  • 🎮 Origem: visual novel da Overflow
  • 📺 Episódios: 12 + final especial (OVA/episódio 12 alternativo)

👉 Tradução técnica:
um “simulador de escolhas” que virou um estudo de colapso humano em cadeia.


⚙️ 🧩 ARQUITETURA (A ARMADILHA)

Setup clássico:

  • 👦 Makoto Itou → protagonista
  • 👧 Kotonoha Katsura → tímida, emocional
  • 👧 Sekai Saionji → impulsiva, manipuladora

👉 Parece um triângulo amoroso simples.

Mas não é.

É um sistema sem validação de input… com usuários instáveis.


🧨 🧬 HISTÓRIA (OU: COMO TUDO SAI DO CONTROLE)

Makoto inicia um relacionamento com Kotonoha.
Sekai entra como “ajuda”… e vira parte do problema.

O que vem depois:

  • traições sucessivas
  • manipulação emocional
  • decisões egoístas
  • ausência total de responsabilidade

👉 O sistema degrada gradualmente.


💀 O PONTO DE FALHA (SEM SPOILER… OU QUASE)

O anime faz algo raro:

  • Começa como romance
  • Evolui para drama
  • Termina como terror psicológico realista

👉 Não tem demônio.
👉 Não tem fantasia.
👉 Só comportamento humano levado ao extremo.


🧠 🔍 O BUG REAL

Makoto não é “vilão clássico”.

Ele é pior:

  • indeciso
  • egoísta
  • passivo
  • incapaz de assumir consequências

👉 Ele é um processo que:

  • consome recursos
  • gera erro
  • não trata exceção

Kotonoha Katsura 

🧨 EFEITO NO ESPECTADOR

Assistir School Days causa:

  • 😐 desconforto crescente
  • 😡 raiva real dos personagens
  • 😬 ansiedade social
  • 💀 choque no final

👉 Você não “curte” o anime.
👉 Você sobrevive a ele.


🧩 EASTER EGGS E DETALHES ESCONDIDOS

🎮 1. Múltiplos finais (origem visual novel)

  • O jogo tem vários endings
  • Alguns piores que o anime 😄

👉 O anime escolheu um dos mais extremos.


📺 2. Direção propositalmente desconfortável

  • Ritmo lento no início
  • Diálogos “estranhos”

👉 Tudo calculado pra parecer normal… antes do colapso.


💀 3. Construção do desastre

Cada episódio:

  • adiciona tensão
  • quebra mais um limite
  • aproxima do ponto irreversível

👉 É literalmente um acúmulo de erro não tratado.


🧨 CURIOSIDADE HISTÓRICA (CLÁSSICA)

O final virou meme mundial:

👉 “Nice boat.”

Por quê?

  • O episódio final foi censurado em algumas transmissões
  • Substituído por imagens de um barco

👉 Resultado: um dos memes mais famosos dos animes.


⚖️ LEITURA FILOSÓFICA (NÍVEL AVANÇADO)

School Days não fala sobre amor.

Fala sobre:

  • responsabilidade
  • consequências
  • imaturidade emocional
  • efeito dominó de decisões ruins

👉 Ninguém ali é totalmente inocente.


💀 SENSAÇÃO FINAL

Quando termina, você não pensa:

  • “que legal” ❌
  • “que triste” ❌

Você pensa:

“isso poderia acontecer na vida real… e isso é assustador.”


🔥 CONCLUSÃO (ESTILO MAINFRAME)

School Days é um sistema onde:

  • não há validação de input
  • não há rollback
  • não há recovery

👉 E quando o erro acontece…

💣 não tem restart — só dump.

 

sexta-feira, 13 de fevereiro de 2009

🍑 COMO PRODUZIR UMEBOSHI EM CASA

Bellacosa Mainframe na seca da ume para produzir umeboshi

🍑 COMO PRODUZIR UMEBOSHI EM CASA


Receita raiz ao estilo Bellacosa Mainframe
(quando você vira operador, storage, JES2 e backup da tradição japonesa)

Vou te dizer logo de cara: fazer umeboshi em casa não é receita, é processo batch.
Não tem atalho, não tem CTRL+C / CTRL+V, não tem pressa.
É job longo, roda por meses, mas quando termina… entrega resiliência em forma de comida.


🏯 PRIMEIRO: O QUE É UME?

A ume é uma ameixa japonesa (na real, um híbrido entre damasco e ameixa).
Sozinha ela é azeda, dura e ingrata.
Mas depois do processamento correto… vira umeboshi, um dos alimentos mais antigos, funcionais e simbólicos do Japão.

👉 Conserva
👉 Probiótico natural
👉 Antibiótico ancestral
👉 Backup alimentar de guerra


📦 PRÉ-REQUISITOS (DATASETS OBRIGATÓRIOS)

Antes de submeter o job:

  • 1 kg de ume verde (não madura, firme)

  • 150 a 200 g de sal grosso marinho (15–20%)

  • Shiso vermelho seco (opcional, mas clássico)

  • Pote de vidro ou cerâmica esterilizado

  • Peso (prato + algo pesado)

  • Sol, paciência e silêncio

⚠️ Erro comum de iniciante: usar ameixa comum.
Não é a mesma coisa. Job abenda.


🧼 STEP 1 — LIMPEZA (ALLOCATE & SORT)

  1. Lave as ume com cuidado.

  2. Retire os cabinhos.

  3. Seque uma a uma.

Aqui é igual preparar dataset crítico:
qualquer sujeira vira corrupção futura.


🧂 STEP 2 — SALGA (EXEC PGM=UMEBOSHI)

  1. Faça camadas no pote:

    • ume

    • sal

    • ume

    • sal

  2. Termine com sal por cima.

  3. Cubra com prato e coloque peso.

📌 Após 2–3 dias, vai surgir líquido: umezu.
Isso é sinal de job rodando com sucesso.


🌿 STEP 3 — SHISO (OPCIONAL, MAS TRADICIONAL)

Se usar shiso vermelho:

  1. Amasse com sal até soltar líquido escuro.

  2. Descarte o líquido.

  3. Coloque o shiso junto das ume no pote.

Resultado:
🔴 cor
🌸 aroma
🧠 memória cultural


☀️ STEP 4 — SECAGEM AO SOL (LONG RUNNING JOB)

Depois de 1 mês em salmoura:

  1. Retire as ume.

  2. Seque ao sol por 3 dias, virando de tempos em tempos.

  3. À noite, recolha (orvalho é corrupção de dados).

Isso é batch noturno + diurno, estilo raiz.


🗄️ STEP 5 — ARMAZENAMENTO (BACKUP OFFSITE)

  • Volte as ume para o pote

  • Cubra com umezu

  • Armazene em local fresco

Tempo de maturação:

  • Mínimo: 6 meses

  • Ideal: 1 a 3 anos

  • Mestres: 10+ anos

Sim, umeboshi envelhece melhor que vinho.


🧠 DICAS DE OPERADOR VETERANO

✔ Quanto mais sal, mais durável
✔ Menos sal = mais cuidado
✔ Mofo branco pode ser removido
✔ Mofo preto = ABEND S0C7 (descarta tudo)


🥢 COMO USAR (APLICAÇÕES)

  • Com arroz branco

  • Dentro do onigiri

  • Em chá quente (remédio)

  • Em molhos

  • Para “acordar o sistema” depois de exageros


🥋 FILOSOFIA EMBUTIDA

Fazer umeboshi ensina:

  • Mottainai – nada se desperdiça

  • Wabi-sabi – o valor do imperfeito

  • Shikata ga nai – o tempo manda

  • Resiliência – algo ácido vira força


🧠 CONCLUSÃO BELLACOSA

Produzir umeboshi em casa é como trabalhar com mainframe:

  • Antigo

  • Lento

  • Preciso

  • Pouco entendido

  • Mas absolutamente confiável

É comida que aguenta crises, guerras, apagões…
e ainda melhora com o tempo.

Se quiser, no próximo post eu te ensino:
👉 Umeboshi low-salt (cloud-native)
👉 Umeboshi com mel (versão ocidental)
👉 Falhas comuns e ABENDs do processo

☕🍑
Aqui a tradição roda em batch…
e não falha.

quinta-feira, 12 de fevereiro de 2009

🧭 Agile na Prática: Planejamento, Pessoas e Kanban

 

Bellacosa Mainframe apresenta Agile Kanban

🧭 Agile na Prática: Planejamento, Pessoas e Kanban

(Guia Navegável – Estilo Bellacosa Mainframe)


1️⃣ Por que o planejamento inicial leva à perda de prazos

“Não decida tudo quando você sabe o mínimo.”

Planejar tudo no início de um projeto quase sempre leva a prazos estourados porque:

  • No começo do projeto, sabemos muito pouco

  • Requisitos mudam

  • Tecnologias são atualizadas

  • Dependências externas se movem

📌 Analogia dos pinguins
Planejar um projeto é como atravessar um campo cheio de pinguins em movimento:

  • No início, você enxerga pouco

  • No meio, sua visão muda

  • Conforme avança, você aprende e ajusta o caminho

👉 Moral da história:
Planejar tudo no começo é decidir no pior momento possível.


2️⃣ Planejamento iterativo: navegar pelo desconhecido

O Agile propõe planejar conforme o conhecimento aumenta.

  • Planeje apenas o que você conhece agora

  • Avance um pouco

  • Aprenda

  • Ajuste o plano

  • Repita 🔁

🎯 Precisão realista

  • Planejamento de 3 meses → ~50% de precisão

  • Planejamento de 2 semanas → ~100% de precisão

📌 Frase Bellacosa-style

Agile não tenta ser onisciente. Agile aceita que aprender faz parte do plano.


3️⃣ Por que trocar cargos sem treinamento leva ao fracasso

❌ Erro comum nas organizações

“Vamos virar Agile, mas sem mudar as pessoas nem o mindset.”

Isso gera falhas graves.


4️⃣ Product Manager ≠ Product Owner

  • Product Manager

    • Cargo

    • Foco em orçamento e operação

  • Product Owner

    • Papel do Scrum

    • Visionário

    • Conecta stakeholders ao time

    • Define experimentos e objetivos do sprint

📌 Nem todo Product Manager é um bom Product Owner.
E está tudo bem — desde que isso seja reconhecido.


5️⃣ Project Manager ≠ Scrum Master

Diferenças fundamentais:

Project ManagerScrum Master
Gerencia tarefasAtua como coach
Controla planoProtege o time
Documenta riscosRemove impedimentos
Cobra prazosFomenta autonomia

📌 Choque cultural clássico
O Project Manager pergunta:

“Como você vai se desbloquear?”

O Scrum Master responde:

“Deixa comigo. Vai trabalhar em algo produtivo.”


6️⃣ Development Team ≠ Scrum Team

  • Development Team

    • Apenas desenvolvedores

  • Scrum Team

    • Desenvolvedores

    • Testers

    • Ops

    • Segurança

    • Analistas de negócio

📌 Scrum Team é cross-functional
Tudo o que é necessário para gerar um incremento de valor.


7️⃣ O papel crítico da gestão no Agile

“Sem apoio da liderança, Agile vira teatro.”

Gestão tradicional pergunta:

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

Gestão ágil pergunta:

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

  • “Como vamos encantar o cliente no próximo sprint?”

📌 Citação-chave

Enquanto líderes insistirem em prazo, escopo e custo fixos, Agile não funciona como foi projetado.


8️⃣ Ferramentas não tornam ninguém ágil

  • Kanban

  • ZenHub

  • Jira

  • GitHub

👉 Nenhuma ferramenta cria mindset ágil sozinha

📌 Primeiro vem o processo
📌 Depois vem a ferramenta


9️⃣ O que é um Kanban Board (sem complicar)

Kanban é apenas:

  • 📝 O que precisa ser feito

  • ⚙️ O que está sendo feito

  • ✅ O que já foi feito

Visual. Simples. Transparente.


🔟 Pipelines do Kanban (ZenHub como exemplo)

🔹 New Issues

  • Caixa de entrada

  • Tudo começa aqui

❄️ Icebox

  • Armazenamento de longo prazo

  • Ideias futuras

📦 Product Backlog

  • Tudo o que queremos fazer algum dia

🏃 Sprint Backlog

  • O que será feito nos próximos 14 dias

⚙️ In Progress

  • Trabalho em execução

  • Dono visível (avatar)

🔍 Review / QA

  • Pull Requests

  • Revisão de código

✅ Done

  • Trabalho concluído pelo desenvolvedor

  • Aceitação ocorre depois, no Sprint Review


🔄 Fluxo do trabalho no Kanban

➡️ Sempre da esquerda para a direita

  • Entrada → Execução → Entrega

  • Visual

  • Atualizado

  • Uma única fonte da verdade

📌 Desenvolvedor não atualiza vários sistemas
📌 Tudo acontece onde ele já trabalha: GitHub


🧠 Conclusão Bellacosa Mainframe

Agile não é sobre prever o futuro.
É sobre aprender mais rápido,
planejar melhor,
e entregar valor continuamente.

📦Resumo para ir mais longe

Implementar Agile na prática vai muito além de adotar cerimônias ou ferramentas. O verdadeiro diferencial das metodologias ágeis está na combinação equilibrada entre planejamento, pessoas e resultados. Embora o Agile valorize a adaptação às mudanças, isso não significa ausência de planejamento. Pelo contrário, o planejamento acontece de forma contínua, permitindo ajustes rápidos conforme surgem novas necessidades do negócio.

Nesse contexto, as pessoas ocupam papel central. Equipes multidisciplinares, comunicação transparente e colaboração constante tornam-se elementos fundamentais para o sucesso dos projetos. Frameworks como Scrum incentivam a participação ativa de todos os envolvidos, promovendo responsabilidade compartilhada e melhoria contínua.

Outro aspecto importante é o foco nos resultados. Em vez de medir sucesso apenas pelo cumprimento de cronogramas, o Agile busca entregar valor real ao cliente por meio de incrementos frequentes e funcionais. Cada sprint representa uma oportunidade de aprendizado, validação e refinamento das prioridades.

A prática ágil também estimula a identificação rápida de riscos, gargalos e oportunidades de melhoria. Reuniões como Daily Scrum, Sprint Review e Retrospective ajudam a manter alinhamento e transparência ao longo do projeto.

Quando bem aplicado, o Agile cria ambientes mais adaptáveis, produtivos e inovadores, permitindo que organizações respondam com maior velocidade às mudanças do mercado sem abrir mão da qualidade e da satisfação dos clientes.

 

quarta-feira, 4 de fevereiro de 2009

Queen's Blade (クイーンズブレイド)

 

Bellacosa Mainframe apresenta queens blade

☕ Um Café no Bellacosa Mainframe

Queen's Blade (クイーンズブレイド)

Quando um Programador COBOL Descobre que Nem Todo Sistema Antigo é Conservador

Durante décadas o universo dos animes produziu centenas de histórias de fantasia medieval. Algumas buscavam profundidade filosófica. Outras queriam criar grandes épicos. E algumas simplesmente resolveram perguntar:

"E se um torneio para decidir a rainha do reino misturasse RPG, ilustrações de artistas famosos, personagens extremamente carismáticas e fanservice levado ao máximo?"

A resposta recebeu um nome:

Queen's Blade.

Muita gente conhece a série apenas por sua enorme quantidade de ecchi.

Entretanto, isso conta apenas metade da história.

Assim como existe quem pense que um IBM Z serve apenas para executar COBOL, existe quem acredita que Queen's Blade é apenas um anime de mulheres lutando enquanto suas armaduras desaparecem durante os combates.

Nos dois casos, existe muito mais acontecendo por baixo da superfície.

Hoje vamos analisar essa franquia como verdadeiros engenheiros de software: observando sua arquitetura, sua evolução, seu impacto cultural e até algumas mensagens escondidas que normalmente passam despercebidas.


Ficha Técnica

Título Original

クイーンズブレイド (Queen's Blade)

Origem

Visual Combat Books publicados pela Hobby Japan.

Inspirados no sistema americano Lost Worlds, criado por Alfred Leonardi.

Primeira publicação:

2005.  


O Estúdio

O anime foi produzido pela ARMS Corporation.

Se você assistiu animes ecchi entre 2000 e 2012, provavelmente já encontrou esse estúdio.

Eles também produziram obras como:

  • Ikki Tousen

  • Elfen Lied

  • Ikkitousen

  • Mezzo

  • Kite

A ARMS ficou famosa por combinar:

  • boa animação

  • personagens extremamente detalhadas

  • cenas de ação

  • muito fanservice

Durante anos praticamente dominou esse nicho.  


Diretor

Kinji Yoshimoto

Um diretor especializado em fantasia e ação.

Seu estilo privilegia:

  • lutas rápidas

  • enquadramentos cinematográficos

  • personagens visualmente marcantes


A Origem da Franquia

Curiosamente...

Queen's Blade não nasceu como anime.

Também não nasceu como mangá.

Nem como light novel.

Ela surgiu como uma coleção de livros-jogo, em que cada personagem possuía seu próprio volume e as batalhas eram resolvidas por regras semelhantes a um RPG de mesa. Esses livros eram baseados na licença do sistema Lost Worlds, adaptado pela Hobby Japan. 


O Conceito

A cada quatro anos acontece um torneio chamado:

Queen's Blade

A vencedora se torna a próxima Rainha do continente.

Não importa:

  • origem

  • raça

  • riqueza

  • idade

  • nacionalidade

Qualquer guerreira pode participar.

Isso já demonstra uma curiosidade interessante.

O torneio funciona quase como uma mistura entre:

  • Copa do Mundo

  • Jogos Olímpicos

  • Campeonato Mundial de Artes Marciais


A História

Nossa protagonista é:

Leina Vance

Filha de uma família nobre.

Ela poderia viver confortavelmente.

Mas decide abandonar tudo.

Quer descobrir quem realmente é.

Quer lutar por mérito próprio.

Seu destino é participar do Queen's Blade.

Durante essa jornada encontra dezenas de guerreiras, aliadas, rivais e inimigas, enquanto o torneio revela conspirações envolvendo a rainha Aldra e forças sobrenaturais. (Wikipédia)


As Personagens

Leina

A heroína clássica.

Idealista.

Corajosa.

Inexperiente.

Representa o arquétipo do "Padawan".


Tomoe

Samurai.

Extremamente disciplinada.

Representa honra.


Risty

Líder de bandidos.

Parece uma vilã.

Mas possui enorme senso de justiça.


Nanael

Um anjo.

Engraçada.

Ingênua.

Quase sempre cria mais problemas do que resolve.


Echidna

Uma assassina élfica.

Fria.

Calculista.

Mas extremamente inteligente.


Cattleya

Talvez a personagem mais famosa da franquia.

Seu design exagerado virou uma marca registrada da série.


Melona

Uma criatura metamórfica.

Talvez seja uma das personagens mais imprevisíveis do anime.


Temporadas

Queen's Blade: Rurou no Senshi

2009

12 episódios


Queen's Blade: Gyokuza wo Tsugu Mono

2009

12 episódios


Queen's Blade: Utsukushiki Toushi-tachi

OVA

6 episódios


Depois veio:

Queen's Blade Rebellion

2012

Nova protagonista:

Annelotte.

Mais tarde a franquia ainda recebeu projetos derivados como Queen's Blade Unlimited. (Wikipedia)


Gênero

Mistura diversos estilos.

  • Fantasia Medieval

  • Aventura

  • Ação

  • Ecchi

  • Torneio

  • Magia

  • Espada e Feitiçaria


Classificação

Apesar da violência moderada...

O principal motivo da classificação elevada é o fanservice intenso, com cenas frequentes de nudez parcial e "armaduras destrutíveis". Em vários países foi exibido com censura na TV aberta, enquanto a AT-X transmitiu versões sem cortes. (Wikipedia)


O Que Tem de Diferente?

Aqui encontramos o verdadeiro diferencial.

Quase toda franquia medieval segue um roteiro.

Herói.

Vilão.

Dragão.

Espada.

Castelo.

Queen's Blade faz diferente.

Cada personagem foi desenhada para possuir:

  • personalidade única

  • estilo de luta exclusivo

  • origem própria

  • ilustrador diferente

Isso tornou cada guerreira quase uma marca independente.


O Fanservice

Aqui precisamos fazer uma distinção importante.

Existe:

Ecchi.

Existe:

Erotismo.

Existe:

Pornografia.

Queen's Blade fica praticamente o tempo inteiro no primeiro grupo.

Seu objetivo não é contar uma história adulta.

Seu objetivo é exagerar visualmente o design das personagens.

Isso explica:

roupas improváveis

armaduras impossíveis

danos "convenientes"

efeitos cômicos

É um exagero consciente.


As Aventuras

Cada encontro funciona quase como uma missão de RPG.

Encontramos:

Florestas.

Ruínas.

Templos.

Desertos.

Castelos.

Monstros.

Magia.

Mercenários.

Cada episódio adiciona uma nova guerreira ao "grupo".


As Mensagens Ocultas

É aqui que muitos espectadores param cedo demais.

Por trás do ecchi aparecem temas como:

Liberdade

Quase todas abandonaram algum tipo de prisão.


Escolha

Nenhuma luta acontece apenas porque "sim".

Cada personagem luta por uma razão.


Identidade

Leina foge do destino imposto pela família.

Tomoe luta pelo dever.

Risty luta pelos pobres.

Cada uma responde à pergunta:

"Quem sou eu?"


Aparência engana

Várias antagonistas demonstram honra.

Diversas heroínas cometem erros.

A série evita dividir o mundo em "bem" e "mal" absolutos.


Bellacosa Mainframe

Aqui existe um paralelo curioso.

Imagine um ambiente IBM Z.

Cada LPAR possui:

  • objetivo

  • recursos

  • prioridade

  • carga

Nenhuma é igual.

Da mesma forma...

Cada guerreira possui:

  • atributos

  • estratégia

  • especialidade

Não existe "a melhor personagem".

Existe a personagem correta para determinado combate.

É exatamente como arquitetar um ambiente de produção.


Easter Eggs

A inspiração em Lost Worlds faz com que muitos golpes e posturas remetam diretamente aos livros-jogo originais.

O visual de Tomoe homenageia a tradição samurai.

Diversas personagens lembram classes clássicas de RPG:

  • Paladina

  • Amazona

  • Clériga

  • Assassina

  • Bruxa

  • Elfa

  • Cavaleira

  • Gladiadora


Impacto Cultural

Mesmo sendo frequentemente lembrada pelo fanservice, Queen's Blade transformou-se em uma franquia multimídia com mangás, light novels, jogos, figures colecionáveis e continuações. Seu sucesso ajudou a consolidar o ecchi de fantasia como um subgênero relevante no fim dos anos 2000. (Wikipédia)


Curiosidades

  • A franquia nasceu antes do anime como uma coleção de livros-jogo.

  • Cada personagem possuía um volume próprio.

  • O anime teve censura significativa em canais convencionais e versão integral na AT-X.

  • O sucesso gerou OVAs, Rebellion, Unlimited, mangás, light novels e videogames. (Wikipedia)


Vale a Pena?

Depende da expectativa.

Se você procura:

  • drama psicológico como Monster;

  • fantasia profunda como Frieren;

  • construção política complexa como The Twelve Kingdoms;

provavelmente esta não é a melhor escolha.

Mas se deseja:

  • fantasia medieval;

  • lutas criativas;

  • personagens memoráveis;

  • humor;

  • um dos maiores expoentes do ecchi dos anos 2000;

então Queen's Blade continua sendo uma obra importante para entender a evolução desse nicho do anime.


Conclusão

No estilo Bellacosa Mainframe, Queen's Blade deixa uma lição curiosa para um Padawan COBOL.

À primeira vista, muita gente olha para um mainframe e enxerga apenas "um computador antigo". Da mesma forma, olha para Queen's Blade e vê apenas fanservice. Em ambos os casos, a aparência esconde uma arquitetura mais rica: um universo organizado, personagens com papéis bem definidos, regras claras e uma franquia que expandiu um conceito simples para livros, mangás, jogos, OVAs e animes.

Como em um grande sistema corporativo, cada componente cumpre uma função específica. Nem sempre é a tecnologia — ou a obra — mais sofisticada, mas compreender por que ela fez sucesso ajuda a entender a evolução do ecossistema que veio depois. Essa talvez seja a maior lição: antes de julgar um sistema pela interface, vale a pena conhecer sua arquitetura.


terça-feira, 3 de fevereiro de 2009

SMP/E: Entendendo o guardião do z/OS - Parte 1

 

Bellacosa Mainframe apresenta o IBM SMP/E

📘 Série SMP/E para Iniciantes

Parte 1 – Entendendo o guardião do z/OS 

“No mainframe, nada entra em produção sem passar pelo crivo do SMP/E.”


🧠 O que é SMP/E (sem enrolação)

SMP/E (System Modification Program / Extended) é o gerenciador oficial de mudanças do z/OS.

Ele garante que:

  • Correções sejam aplicadas na ordem certa

  • Dependências sejam respeitadas

  • Nada seja sobrescrito por acidente

  • O histórico do sistema seja preservado

👉 Em resumo Bellacosa:

SMP/E é o síndico do prédio chamado z/OS.


🕰️ Um pouco de história (porque mainframe tem memória)

Antes do SMP/E:

  • Correções eram copiadas “na mão”

  • Não havia controle de versão

  • Produção quebrava sem explicação

A IBM então criou o SMP, que evoluiu para o SMP/E, acompanhando:

  • OS/360

  • MVS

  • OS/390

  • z/OS

📆 Presente em TODOS os releases modernos do z/OS.


🧩 Conceitos básicos que você precisa gravar

🔹 SYSMOD

É o pacote de mudança que o SMP/E gerencia.

Tipos mais comuns:

  • PTF – correção de defeito

  • APAR – problema reportado

  • USERMOD – modificação do cliente

  • FUNCTION – novo produto ou função

📌 Sem SYSMOD, o SMP/E não trabalha.


🔹 CSI – Consolidated Software Inventory

O CSI é o cérebro do SMP/E.

Ele guarda:

  • O que está instalado

  • O que depende de quê

  • O que foi aplicado

  • O que foi aceito

👉 Quebrou o CSI? Parou o mundo.


🔁 O fluxo básico do SMP/E (decore isso)

1️⃣ RECEIVE

Recebe o SYSMOD e registra no CSI.

“Agora o SMP/E sabe que isso existe.”


2️⃣ APPLY

Aplica o SYSMOD no Target Libraries.

“Agora o sistema pode usar.”


3️⃣ ACCEPT

Atualiza o DLIB (baseline oficial).

“Agora isso virou padrão.”


📌 Regra Bellacosa:

Nunca ACCEPT sem antes validar o APPLY.


📦 Target x DLIB (confusão clássica)

BibliotecaFunção
TARGETExecutável
DLIBReferência / fonte

❌ Erro comum de iniciante:

“Achei que DLIB era produção.”


🚨 O que são MCS?

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

Todas começam com:

++

Exemplos famosos:

  • ++VER

  • ++MOD

  • ++HOLD

  • ++ERROR

👉 MCS dizem ao SMP/E como tratar o código.


🧪 Exemplo simples de MCS

++PTF(UJ12345). ++VER(Z038) FMID(HJES770).

📌 Isso diz:

  • É um PTF

  • Serve para o FMID HJES770

  • Compatível com versão Z038


🎓 Como estudar SMP/E (do jeito certo)

📘 Teoria

  • IBM Docs

  • Redbooks

  • APARs reais

🧪 Prática

  • SMP/E for z/OS Workshop

  • APPLY CHECK

  • Ambientes de teste

💡 Dica Bellacosa:

“SMP/E só entra na cabeça quando você vê um APPLY falhar.”


🧠 Curiosidade Bellacosa

  • SMP/E já resolvia dependência antes do DevOps

  • Já fazia auditoria antes do compliance virar moda

  • Não tem interface bonita, mas nunca falha


🧾 Encerramento – Parte 1

Quem aprende SMP/E não briga com produção.
Quem ignora SMP/E vira refém de outage.

Na Parte 2, vamos falar de:

👉 SYSMOD, PTF, APAR e USERMOD na prática 

segunda-feira, 2 de fevereiro de 2009

🏫 Capítulo 1 — O garoto das cidades trocadas

 

Bellacosa Mainframe e a infância isekai

📚 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 1 — O garoto das cidades trocadas


Foto escolar em 1981


As escolas que frequentei foram tantas que minha infância virou uma colcha de retalhos costurada à pressa.


Sempre fui mais tímido do que expansivo, mas a profissão do meu pai — fotógrafo — nos ensinou a viver em constante movimento.

Lembranças do prézinho no parque 3 marias



Cada mudança era uma nova lente, um novo enquadramento, uma turma inteira tentando entender quem era o aluno recém-chegado.

Memórias do primeiro ano, a professora Cecilia, brava e muito rígida para um pequeno garoto, que terminava muito rápido as lições, para poder desenhar mechs em antigos envelopes fotográficos. O unico amigo que me lembro de 1981, era um asiático chamado Fabio, cujo  o obâchan (

お ば あ ち ゃ ん
), era fotografo profissional e virou mentor do meu pai, evoluindo na amizade de ambos, que incluiu as respectivas familias, cimentando minha amizade com o Fábio, com isso ambos eramos fanáticos por mechs e robôs gigantes vindo da Terra do Sol nascente, 

Caderno de calagrafia



Inclusive um dia, ambos muito inspirados em desenhar Spectreman, fomos apanhados pela professora Cecilia, que apesar de termos terminados nossas atividades escolares, fomos duramente repreendidos e colocados de castigo, em pé atras da porta. Algo que marcou minha memória até os dias atuais... 

Cartilha Caminho Suave


Um ano bem traumático, tantas coisas ruim aconteceram em tão pouco tempo. No terceiro ano do primário, passei por três escolas diferentes em três municípios distintos.
Estudei em São Paulo, Pirassununga, Quiririm,

O terceiro ano começou bem, com muita expectativa com a professora Maria, mas a meio do ano uma catástrofe familiar, me derrubou. Nesse meio tempo retornamos a São Paulo em clima de tragédia. Despenquei nas aulas, notas sofríveis e quase reprovando o ano, porém com nova mudança ao Quiririm. Um recomeço com uma nova professora, Maria, recuperei de tal maneira, que a professora emocionada me presenteou com um troféu.

Professora Maria do 3ºano no Quiririm


Quarto ano, uma professora bem velhinha, que amava ensinar a mitica Ligia, uma senhora que educou gerações de pessoas no Quiririm, que tinha prazer imenso em ensinar, uma excelente professora, que serviu de ritual de passagem entre o primário e ginásio. Deixando grandes e boas lembranças da turma do Quarto Ano B da escola Deputado Cesar Costa.

Outros passos do quinto e sexto ano em Taubaté… e novamente São Paulo para concluir o setimo e oitavo ano, sempre correndo, sempre me adaptando. Criando um novo ser a cada escola nova, novas regras, novos professores e novos amigos.

No Ginásio foram dezenas de professores, a memória perdeu o nome da maioria, mas aqueles especiais ficaram Mirtes e Luis de Matemática, Dinah de história, Edvan de ciências, a doce Regina de Educação Moral e Cívica, Miguel de Inglês, conforme for lembrando atualizarei o poste.

Um reencontro com a melhor professora que tive no primario, a lendaria professora Maria


Na minha época escolar, a evolução era dividida em 3 etapas: primário primeiro ao quarto ano com educação básica, usando lápis e borracha, com caderno normal e no meu caso tarefas adicionais em caderno de caligrafia; ginásio do quinto ao oitavo ano com inúmeros professores, cada qual com sua disciplina usando caderno do ginásio e uso de canetas. Para finalmente o Colegial com a possibilidade de ir pelo científico vocacionado a Vestibulares de elite e o Técnico com profissão, mas acesso a faculdades de segunda linha.

Relembrando do caminho seguido desde a pré-historia


Esqueci de comentar que antes de entrar em tudo isso tinha a pré-escola, onde recebíamos os fundamentos de leitura e escrita, matemática e preparava o aluno a entrar em escola no primário.

Até terminar o ginásio, minha vida escolar parecia uma sessão de slides — clique, nova imagem, novo começo.

O colegial fiz em Ferraz de Vasconcelos, o que me obrigou a ser mais aberto, a sorrir primeiro e esperar a empatia depois.


Aprendi cedo que mudar exige não apenas coragem, mas também leveza.

Sempre senti falta de raízes — daqueles amigos que crescem juntos, colecionam histórias e ficam na mesma rua por anos.
Mas a vida me direcionou para outro roteiro.
Sem perceber, vivi meu próprio isekai: em cada escola, um novo universo, uma chance de provar que eu pertencia àquele mundo.

E assim fui acumulando colegas, experiências e memórias, como quem vive duas vidas — uma em cada recomeço.