Translate

sábado, 4 de março de 2017

Isekai Shokudou — O Mainframe da Gastronomia Entre Mundos

 

Bellacosa Mainframe apresenta o Isekai Shokudou

☕ O Holocron do Nekoya

Isekai Shokudou — O Mainframe da Gastronomia Entre Mundos

Como um Pequeno Restaurante Japonês Ensinou Mais Sobre Disponibilidade, Experiência do Usuário e Convivência do que Muitos Frameworks Corporativos


Introdução

Existe uma curiosidade interessante sobre os animes isekai.

A maioria começa com alguém morrendo, sendo atropelado pelo Truck-kun, recebendo habilidades absurdamente apelonas e derrotando um Rei Demônio após montar um harém.

Mas em 2017 surgiu uma obra que praticamente respondeu:

"E se ninguém precisasse morrer?"

"E se ninguém precisasse salvar o mundo?"

"E se a verdadeira magia fosse simplesmente preparar uma boa refeição?"

Nascia Isekai Shokudou.

Uma obra singela.

Calma.

Quase terapêutica.

Um anime que troca espadas por panelas, magia destrutiva por curry japonês e guerras épicas por cheesecake recém-saído da cozinha.

E curiosamente, para quem trabalha com IBM Z, o Nekoya lembra bastante um ambiente produtivo de alta disponibilidade.


Ficha Técnica

ItemInformação
Título Original異世界食堂 (Isekai Shokudou)
Título InternacionalRestaurant to Another World
AutorJunpei Inuzuka
Ilustrador OriginalKatsumi Enami
Light NovelHero Bunko
Web Novel2013
Light Novel2015
Anime S1Julho de 2017
Anime S2Outubro de 2021
Estúdio S1Silver Link
Estúdio S2OLM Team Yoshioka
Diretor S1Masato Jinbo
Diretor S2Masato Jinbo
Episódios24
Temporadas2
StatusConcluído
GênerosIsekai, Gourmet, Slice of Life, Fantasia, Seinen
Classificação IndicativaAproximadamente 12 anos

A Sinopse

No distrito comercial de Tóquio existe um pequeno restaurante chamado Youshoku no Nekoya.

Durante seis dias da semana atende clientes comuns.

Mas aos sábados acontece algo extraordinário.

Portas mágicas aparecem espalhadas por outro mundo.

Elfos.

Dragões.

Cavaleiros.

Mercenários.

Magos.

Anões.

Demônios.

Todos atravessam essas portas para experimentar pratos da culinária ocidental japonesa.

E retornam às suas vidas levando consigo algo muito maior que uma refeição.

Memórias.

Conforto.

Esperança.

Conexões humanas.


A História

Diferente da maioria dos animes contemporâneos, Isekai Shokudou não possui uma narrativa linear.

Não existe uma grande missão.

Não há vilão principal.

Não há ameaça global.

Cada episódio funciona quase como um pequeno conto.

Uma antologia gastronômica.

O restaurante é o ponto de convergência.

A cozinha é o coração.

Os clientes são as histórias.

O espectador passa a conhecer o mundo de fantasia através das experiências individuais de quem visita o Nekoya.


O Estúdio Silver Link

A primeira temporada foi produzida pelo Silver Link.

Conhecido por obras como:

  • Bofuri

  • Non Non Biyori

  • Fate/Kaleid

  • Rakudai Kishi

O Silver Link conseguiu algo extremamente difícil.

Transformar comida em espetáculo visual.

Curry fumegante.

Carne brilhando.

Molhos escorrendo.

Cheesecake macio.

Panquecas douradas.

O resultado lembra o conceito japonês chamado:

Meshi Terror

"Food Porn"

A arte faz o espectador sentir fome.

Literalmente.


A Segunda Temporada

Produzida pela OLM.

Mesmo estúdio responsável por:

Pokémon

Komi-san

Odd Taxi (coprodução)

A qualidade visual aumentou.

Animações mais suaves.

Melhor iluminação.

Maior detalhamento dos cenários.

O diretor Masato Jinbo permaneceu.

Isso preservou a identidade da obra.


Personagens

O Mestre

Nunca recebe nome.

Uma decisão inteligente.

Ele não é protagonista.

Ele é o facilitador.

É praticamente um Sysprog.

Mantém o ambiente disponível.

Não julga usuários.

Resolve problemas.

Entrega serviços.

Seu SLA é impecável.


Aletta

Demônio pobre.

Excluída socialmente.

Passava fome.

Encontra no Nekoya um emprego.

Uma família.

Dignidade.

Seu arco é um dos mais emocionantes.

Representa inclusão social.


Kuro

Uma entidade capaz de destruir civilizações.

Mas prefere cheesecake.

E café.

Sua presença é simbólica.

Mesmo seres quase divinos desejam paz.

Rotina.

Conforto.


Clientes Memoráveis

Princesas.

Mercenários.

Dragões.

Elfos.

Sacerdotes.

Piratas.

Reis.

Todos sentam nas mesmas mesas.

Sem distinção.


Temática

Isekai Shokudou fala sobre:

Pertencimento

Todos precisam de um lugar seguro.


Memórias afetivas

A comida conecta pessoas.


Hospitalidade

O restaurante não pergunta quem você é.

Pergunta:

O que deseja comer?


Diversidade

Raças inimigas convivem.

Sem guerras.

Sem preconceito.

Sem disputas.


O que torna diferente dos outros Isekai

Não existe protagonista escolhido.


Não existe sistema RPG.


Não existe fanservice exagerado.


Não existe batalha final.


O foco é emocional.


É praticamente um Slice of Life disfarçado de Isekai.


As Aventuras

As aventuras aqui são pequenas.

Mas significativas.

Encontrar uma porta.

Economizar dinheiro.

Viajar meses.

Experimentar um novo prato.

Parece banal.

Mas para aqueles personagens é um evento anual.

Quase um feriado sagrado.


Mensagens Ocultas

A comida é linguagem universal

Independentemente de espécie.

Todos compreendem prazer.

Conforto.

Afeto.


O Nekoya é um espaço liminar

Na antropologia, locais entre dois mundos representam transformação.

O restaurante funciona como um portal simbólico.

Ao entrar:

Você deixa conflitos externos.

Ao sair:

Retorna renovado.


Crítica à sociedade moderna

O Japão contemporâneo enfrenta:

Solidão

Isolamento social

Excesso de trabalho

O anime oferece uma fantasia diferente.

Não riqueza.

Não poder.

Mas tempo.

Boa comida.

Conversas.


Impacto Cultural

A obra tornou-se bastante querida entre fãs de:

Slice of Life

Gastronomia

Isekai alternativos

Abriu caminho para produções semelhantes.

Entre elas:

  • Isekai Izakaya Nobu

  • Campfire Cooking in Another World

  • Sweet Reincarnation

  • Deaimon

  • Yuru Camp (espiritualmente próximo)

Embora nunca tenha alcançado a popularidade massiva de Re:Zero ou Mushoku Tensei, conquistou uma comunidade extremamente fiel.

Muitos fãs consideram o anime um exemplo de:

Iyashikei

Anime terapêutico.

Curativo.

Reconfortante.


Houve Censura?

Praticamente não.

Isekai Shokudou é uma das obras menos controversas do gênero.

Não possui:

Violência gráfica.

Erotização excessiva.

Conteúdo político.

Temas potencialmente sensíveis.

Algumas emissoras internacionais apenas adaptaram nomes de pratos ou referências culinárias para facilitar a compreensão local, mas não houve registro significativo de cortes ou censura relevante.


A Visão Bellacosa Mainframe

O Nekoya parece um ambiente IBM Z.

NekoyaMainframe
Portas mágicasVPNs
ClientesAplicações
MestreSysprog
CardápioCatálogo de serviços
CheesecakeChange aprovado
CurryJob sem ABEND
Café da KuroBatch encerrado com RC=0000
Sábado especialJanela de manutenção

No fim, Isekai Shokudou transmite uma ideia simples, porém poderosa:

Nem toda infraestrutura precisa suportar milhões de transações por segundo para ser importante.

Às vezes, basta estar disponível no momento certo, receber bem quem chega e entregar uma experiência memorável.

Talvez seja essa a maior magia do Nekoya.

Não transportar pessoas para outro mundo.

Mas lembrá-las de que, em qualquer mundo, todos procuram a mesma coisa: um lugar onde possam sentar, descansar, serem bem recebidos e voltar para casa um pouco mais felizes do que quando chegaram.


sexta-feira, 3 de março de 2017

Knight's & Magic: Como um Programador Obcecado por Mechas Reencarnou em um Datacenter Medieval e Criou o DevOps dos Cavaleiros Gigantes

 

Bellacosa Mainframe apresenta Knights & Magic

☕ O Holocron de Knight's & Magic

Como um Programador Obcecado por Mechas Reencarnou em um Datacenter Medieval e Criou o DevOps dos Cavaleiros Gigantes

Existe um momento na carreira de todo profissional de tecnologia em que ele deixa de apenas usar ferramentas e passa a querer construí-las.

Ele deixa de perguntar:

"Como eu executo isto?"

E começa a perguntar:

"Por que isto foi feito assim?"

Essa pergunta é justamente o motor que move Knight's & Magic.

E talvez seja por isso que este anime tenha conquistado tantos engenheiros, makers, arquitetos de software, desenvolvedores e entusiastas de automação.

Para um profissional IBM Z, Knight's & Magic parece a história de um Sysprog apaixonado por hardware que acordou em um universo medieval e decidiu reinventar a indústria de computação pesada utilizando magia como middleware.


Dados da Obra

Título Original

ナイツ&マジック

Romanização

Naitsu ando Majikku

Título Internacional

Knight's & Magic

Autor da Light Novel

Hisago Amazake-no

Ilustrador

Kurogin

Estúdio de Animação

8bit

Diretor

Yusuke Yamamoto

Composição da Série

Michiko Yokote

Música

Masato Koda

Exibição Original

2 de julho de 2017

Término

24 de setembro de 2017

Episódios

13 episódios

Origem

Web Novel

Publicação inicial

2010

Light Novel

2013

Mangá

2016


Classificação e Gêneros

Classificação indicativa aproximada:

12+

Gêneros:

  • Isekai

  • Fantasia

  • Mecha

  • Aventura

  • Engenharia Fantástica

  • Ficção Científica Soft

  • Slice of Engineering (quase um subgênero não oficial)


A Sinopse

Tsubasa Kurata era um programador japonês.

Um adulto funcional.

Empregado.

Otaku veterano.

Colecionador de modelos mecha.

Apaixonado por Gundam.

Fanático por robôs gigantes.

Morre em um acidente automobilístico.

Reencarna como Ernesti Echevalier.

Num mundo onde existem enormes armaduras mágicas chamadas:

Silhouette Knights.

Para muitas pessoas, isso seria um sonho.

Para Ernesti é um projeto de engenharia.

Seu objetivo não é derrotar o Rei Demônio.

Nem montar um harém.

Nem salvar princesas.

Seu objetivo é muito mais ambicioso.

Construir o melhor robô gigante já criado.


A História

O Reino de Fremmevilla vive relativamente estável.

As tecnologias dos Silhouette Knights evoluem lentamente.

A sociedade aceita os padrões existentes.

Ernesti não.

Ele começa a observar.

Questionar.

Estudar.

Fazer engenharia reversa.

Criar protótipos.

Redesenhar mecanismos.

Melhorar mobilidade.

Aumentar eficiência energética.

Reduzir peso.

Otimizar armas.

É praticamente Lean Manufacturing aplicado em mechas.


Os Personagens

Ernesti Echevalier

O protagonista.

Uma mistura de:

  • engenheiro mecânico;

  • programador;

  • pesquisador;

  • cientista maluco;

  • arquiteto de soluções.

Ele lembra muito:

Um desenvolvedor COBOL que recebeu acesso ao código-fonte do z/OS.


Adeltrud Walter

Nobre.

Corajosa.

Leal.

Representa usuários satisfeitos com sistemas legados.

Até Ernesti aparecer.


Archid Walter

Amigo de infância.

Piloto habilidoso.

Usuário power-user.


Edgar Blanche

Companheiro de equipe.

Especialista operacional.

Equivalente ao operador de produção.


O Que Há de Diferente

A maioria dos isekais segue esta fórmula:

Truck-kun

Reencarnação

Poder apelão

Harém

Rei demônio

Knight's & Magic faz algo raro.

Truck-kun

Reencarnação

CAD mental

Pesquisa

P&D

Indústria

O protagonista não recebe uma espada lendária.

Recebe um problema técnico.

E fica feliz.


As Aventuras

As aventuras são essencialmente projetos de engenharia.

Projeto 1

Aprender teoria mágica.

Projeto 2

Construir miniaturas.

Projeto 3

Pilotar.

Projeto 4

Criar novos mecanismos.

Projeto 5

Desenvolver o Ikaruga.

Projeto 6

Produção em massa.

Projeto 7

Transferência tecnológica.


O Ikaruga

O ápice do anime.

É praticamente um protótipo revolucionário.

Comparando com TI:

Ikaruga = IBM z17

Modelos antigos = zEC12

Magia = Middleware

Cristal demoníaco = Fonte redundante

Cabine = Console HMC


Temáticas

Engenharia

O anime é uma carta de amor para engenheiros.

Curiosidade

O conhecimento nasce da obsessão positiva.

Inovação

Questionar padrões.

Aprendizado contínuo

Ernesti nunca para.

Maker Culture

Construir é divertido.


Mensagens Ocultas

O especialista continua especialista

Mesmo mudando de ambiente.

Conhecimento é transferível.


Inovadores assustam organizações

Toda vez que Ernesti propõe algo novo.

A reação é:

"Isso nunca foi feito."

Exatamente como em empresas tradicionais.


O prazer da criação

Ernesti não quer riqueza.

Quer construir.

É a mentalidade do open source.


Impacto Cultural

Foi muito bem recebido.

Principalmente entre:

Fãs de Gundam;

Makers;

Programadores;

Engenheiros;

Modelistas.

Recebeu elogios pela proposta incomum.

A principal crítica foi:

13 episódios.

Pouco tempo.

Muita compressão narrativa.

Vários volumes foram condensados.


Houve censura?

Não existem registros relevantes de censura oficial.

A adaptação foi considerada bastante fiel.

As alterações ocorreram principalmente por limitações de tempo.

Foram removidas:

Explicações técnicas detalhadas;

Desenvolvimento político;

Interações secundárias;

Momentos de pesquisa mais extensos.

Nada comparável aos cortes vistos em obras mais controversas.


A Análise Bellacosa Mainframe

Se Ascendance of a Bookworm é sobre gestão do conhecimento,

Se Dr. Stone é sobre reconstruir a ciência,

Então Knight's & Magic é sobre algo muito específico:

A alegria quase infantil que um engenheiro sente ao olhar para uma máquina complexa e pensar:

"Eu consigo fazer uma versão melhor."

Ernesti não luta por glória.

Não busca fama.

Não quer governar o mundo.

Ele quer otimizar throughput.

Diminuir latência.

Melhorar arquitetura.

Eliminar gargalos.

Fazer benchmark.

Construir a próxima geração.

E talvez seja justamente por isso que tantos profissionais de infraestrutura, mainframe, DevOps e arquitetura corporativa terminem a série com a sensação de terem encontrado um personagem que, pela primeira vez em muito tempo, pensa exatamente como eles.


⭐ Classificação Bellacosa Mainframe

CritérioNota
Engenharia e Inovação10/10
Universo Fantástico8/10
Desenvolvimento de Personagens7/10
Mechas10/10
Ritmo Narrativo7/10
Valor para Profissionais de TI10/10
Nota Final Bellacosa Mainframe9,0/10 ☕

Veredito: Knight's & Magic talvez seja o anime isekai que melhor representa a mentalidade de um arquiteto de sistemas, de um engenheiro de plataforma IBM Z ou de um desenvolvedor que não se contenta em apenas utilizar tecnologia, mas sente uma necessidade quase irresistível de entendê-la, aprimorá-la e reinventá-la.


quinta-feira, 2 de março de 2017

O Tríplice Alicerce da Informática: Hardware, Software e Peopleware

 

Bellacosa Mainframe e o triplice alicerce da informatica hardware software e peopleware

☕ O Holocron do Padawan COBOL

O Tríplice Alicerce da Informática: Hardware, Software e Peopleware

Existe uma armadilha muito comum para quem está iniciando na área de tecnologia.

O programador júnior costuma acreditar que informática é apenas escrever código.

O administrador de sistemas imagina que tudo se resume a servidores.

O usuário acredita que basta apertar um botão e esperar.

Na prática, a informática moderna é sustentada por três grandes pilares.

São eles:

  • Hardware

  • Software

  • Peopleware

Se um deles falhar, todo o ecossistema entra em desequilíbrio.

Para um Programador COBOL Jr., compreender esses três fundamentos é tão importante quanto aprender PIC X(10), EXEC CICS, SQLCODE ou IDCAMS.

Porque um sistema bancário não é apenas um programa COBOL.

Ele é uma enorme engrenagem composta por pessoas, processos, equipamentos, sistemas operacionais, redes, bancos de dados e conhecimento acumulado durante décadas.

Vamos explorar esse universo.


O Primeiro Alicerce: Hardware

Hardware é tudo aquilo que podemos tocar.

São os componentes físicos de um sistema computacional.

Podemos pensar no hardware como sendo o corpo humano.

Os músculos.

Os ossos.

Os órgãos.

A estrutura material.

Exemplos:

Notebook

Desktop

Servidor

Mainframe

Disco SSD

Fita magnética

Teclado

Monitor

Switch

Roteador

Placa de rede

Processador

Memória

No mundo IBM Z, o hardware possui uma sofisticação enorme.

Exemplos:

IBM z16

IBM z17

Processadores IFL

CP

zIIP

SAP

Canais FICON

DASD

Tape Libraries


O que um COBOL Jr precisa entender sobre hardware?

Muito mais do que parece.

Por exemplo.

Quando escrevemos:

OPEN INPUT CLIENTES

Parece simples.

Mas internamente acontece algo impressionante.

O programa solicita acesso ao dataset.

O z/OS consulta o catálogo.

Descobre em qual volume está.

Envia requisição ao subsistema de I/O.

Os canais FICON processam a leitura.

O controlador do storage recebe.

Os discos entregam os blocos.

A memória recebe.

O COBOL finalmente acessa o registro.

Talvez em menos de um milissegundo.

Mas dezenas de componentes participaram.


CPU

É o cérebro.

Executa instruções.

Soma.

Subtrai.

Compara.

Move dados.

COBOL:

ADD 1 TO CONTADOR

Vira instruções de máquina.

O processador executa.

Bilhões por segundo.


Memória

É onde os programas vivem enquanto estão executando.

WORKING-STORAGE.

Buffers.

Tabelas.

Caches.

Áreas de comunicação.

Exemplo:

01 WS-NOME PIC X(50).

Está em memória.

Não em disco.


Disco

Armazenamento permanente.

Datasets.

VSAM.

DB2.

Logs.

JCL.

Load Modules.

Exemplo:

//ARQ DD DSN=EMPRESA.CLIENTE.MESTRE

Está fisicamente em um disco.


Rede

Liga computadores.

Permite APIs.

MQ.

FTP.

TN3270.

REST.

Web Services.


Hardware é caro?

Sim.

Muito.

Um IBM Z pode custar milhões de dólares.

Mas também pode processar milhares de transações por segundo.

Com disponibilidade próxima de:

99,999%

Cinco noves.

Poucos segundos de indisponibilidade por ano.


O Segundo Alicerce: Software

Se hardware é o corpo...

Software é a mente.

É a inteligência.

As instruções.

Os algoritmos.

As regras.


O que é software?

É um conjunto de programas.

Sequências de comandos.

Dados.

Configurações.

Documentação.

Procedimentos.

Tudo que diz ao hardware o que fazer.


Tipos de software

Podemos dividir em categorias.

Software de Sistema

Controla a máquina.

Exemplos:

Windows

Linux

z/OS

AIX

z/VM

Hypervisor


Software Aplicativo

Resolve problemas do negócio.

Internet Banking.

ERP.

Folha.

CRM.

No Mainframe:

Sistema bancário.

Sistema previdenciário.

Seguros.

Cartões.


Middleware

Fica entre sistemas.

Exemplos:

CICS

IMS

MQ

Kafka

Tomcat

Websphere

z/OS Connect


Ferramentas

Editores.

Compiladores.

IDEs.

Git.

Zowe.

Ansible.

VSCode.

SDSF.

ISPF.


O programa COBOL é software

Imagine:

IF SALDO < VALOR
   DISPLAY "NEGADO"
END-IF

O hardware não entende isso.

Ele entende:

101011100001

Instruções binárias.

Quem converte?

Compilador.


O compilador

Traduz COBOL.

Gera código objeto.

Binder.

Load Module.

Executável.

Fluxo:

COBOL

Objeto

Link Edit

LOADLIB

Execução


Sistemas Operacionais

São maestros.

Coordenam tudo.

CPU.

Memória.

Arquivos.

Impressoras.

Usuários.


No z/OS:

WLM

JES2

RACF

SMS

RMF

SMF

TCPIP

Trabalham juntos.


Exemplo

Você submete:

//STEP01 EXEC PGM=PGM0001

JES2 recebe.

Agenda.

Executa.

Monitora.

Captura mensagens.

Libera saída.


Software envelhece?

Sim.

Muito.

Não fisicamente.

Mas tecnologicamente.

Exemplo:

COBOL 74

COBOL 85

Enterprise COBOL 6.5


Sistemas precisam:

Correções

Patches

Atualizações

Refatoração


O Terceiro Alicerce: Peopleware

Aqui está o componente mais importante.

E também o mais difícil.

Porque computadores não brigam.

Não ficam cansados.

Não pedem demissão.

Não esquecem procedimentos.

Pessoas fazem tudo isso.

Peopleware é o conjunto de seres humanos envolvidos com tecnologia.


Quem faz parte do Peopleware?

Muita gente.

Programadores

Analistas

DBAs

Sysprogs

Arquitetos

Gerentes

Operadores

QA

Scrum Masters

Auditores

Usuários finais

Executivos

Fornecedor

Consultor

Instrutor


Um exemplo bancário

Cliente faz PIX.

Quem participa?

Cliente

Aplicativo

Desenvolvedor COBOL

DBA

Administrador MQ

Equipe de rede

Sysprog

Segurança

Operação

Help Desk

Gestor

Auditoria


Dezenas de pessoas.


O Peopleware é o fator crítico

Podemos comprar:

Servidor.

Storage.

Licenças.

IA.

Cloud.

Mas conhecimento?

Não.

Ele precisa ser desenvolvido.


O problema da perda de conhecimento

Imagine.

Empresa possui:

30 milhões de linhas COBOL.

Programador aposentou.

Documentação inexistente.

Comentários ausentes.

Ninguém entende.

Crise.


Peopleware significa:

Treinar.

Documentar.

Compartilhar.

Mentorar.

Ensinar.


O Programador Sênior

É uma biblioteca viva.

Conhece:

ABENDs

Datasets

JCL

CICS

Negócio

Regras fiscais

Histórico

Decisões antigas


Um júnior aprende muito observando.


Soft Skills

Peopleware não é apenas conhecimento técnico.

É relacionamento.


Comunicação

Empatia

Escuta

Negociação

Organização

Liderança


Exemplo

Junior:

O programa está errado.

Sênior:

Qual cenário reproduz o problema?

Muito melhor.


Trabalho em equipe

Um sistema complexo nunca é feito sozinho.

Exemplo:

Programador faz código.

QA testa.

DBA cria índices.

Sysprog instala.

Operação agenda.

Negócio aprova.

Produção libera.


O equilíbrio entre os três pilares

Podemos imaginar um tripé.

Caso 1

Hardware excelente.

Software ruim.

Peopleware desorganizado.

Resultado:

Fracasso.


Caso 2

Equipe brilhante.

Hardware insuficiente.

Resultado:

Lentidão.


Caso 3

Equipamentos modernos.

Equipe competente.

Software legado mal escrito.

Resultado:

Manutenção cara.


Caso ideal

Hardware adequado.

Software bem projetado.

Peopleware capacitado.

Resultado:

Estabilidade.

Escalabilidade.

Segurança.

Disponibilidade.


Como isso aparece no IBM Z?

Um exemplo bastante próximo da realidade.

Hardware

IBM z17

Storage DS8000

FICON

Criptografia embarcada


Software

z/OS

COBOL 6.5

DB2 13

CICS TS

MQ

RACF


Peopleware

Programadores COBOL

DBA DB2

Sysprog

Administrador CICS

Segurança

Operação

Arquitetos

Negócio


O cliente acessa o aplicativo pelo celular.

Em dois segundos recebe a resposta.

Por trás disso existem milhares de elementos trabalhando em conjunto.


A Informática Moderna Adicionou um Quarto Pilar?

Alguns especialistas defendem que hoje existe um quarto elemento.

Data (Dados)

Porque dados se tornaram ativos estratégicos.

Empresas vivem de dados.

Bancos.

Hospitais.

Varejo.

Streaming.

IA depende de dados.

Machine Learning depende de dados.

Analytics depende de dados.

Mas, tradicionalmente, a maior parte da literatura continua tratando a informática como sustentada principalmente pelo Hardware, Software e Peopleware, sendo os dados considerados um recurso administrado por esses três pilares.


O que um Padawan COBOL deve fazer?

Sugestão de evolução profissional:

1º mês

Aprender COBOL básico.

2º mês

Aprender JCL.

3º mês

Entender datasets.

4º mês

Conhecer DB2.

5º mês

Estudar CICS.

6º mês

Aprender arquitetura IBM Z.

7º mês

Conversar com operadores.

8º mês

Acompanhar um DBA.

9º mês

Entender o trabalho de um Sysprog.

10º mês

Estudar RACF.

11º mês

Praticar documentação.

12º mês

Mentorar outro iniciante.


Considerações Finais

O maior erro de um profissional iniciante é acreditar que informática é apenas programação.

Um programa COBOL não existe isoladamente. Ele depende de processadores, memória, discos, sistemas operacionais, compiladores, redes, bancos de dados, equipes de infraestrutura, analistas de negócio, operadores, administradores e usuários.

O hardware fornece a força física.

O software fornece a lógica e a inteligência.

O peopleware fornece experiência, criatividade, disciplina e conhecimento acumulado.

Quando um Padawan COBOL compreende esse tríplice alicerce, ele deixa de enxergar apenas linhas de código e começa a perceber algo muito maior: um ecossistema vivo, onde tecnologia e pessoas colaboram para manter funcionando bancos, seguradoras, governos, hospitais e empresas que atendem milhões de pessoas todos os dias. Em muitos ambientes corporativos, especialmente no IBM Z, o verdadeiro diferencial não está apenas na potência das máquinas ou na qualidade do software, mas na capacidade das equipes de preservar conhecimento, compartilhar experiência e evoluir continuamente. É isso que transforma um simples programador em um profissional capaz de compreender a alma dos sistemas que sustentam o mundo moderno.


quarta-feira, 1 de março de 2017

☕YAML : Como um Padawan COBOL Pode Aprender a Conversar com DevOps, Kubernetes e IA Sem Precisar Decorar um Novo JCL

 

Bellacosa Mainframe apresenta o YAML

☕ O Holocron do YAML

Como um Padawan COBOL Pode Aprender a Conversar com DevOps, Kubernetes e IA Sem Precisar Decorar um Novo JCL

Existe um momento na jornada de todo Padawan COBOL em que ele percebe uma estranha verdade do universo corporativo.

Durante décadas, aprendemos a falar linguagens sagradas.

COBOL.

JCL.

REXX.

CLIST.

DFSORT.

IDCAMS.

Parmlibs.

PROCs.

SYSIN.

Control Cards.

E então, certo dia, aparece um desenvolvedor de tênis colorido dizendo:

— Só coloca no YAML.

E o Padawan COBOL pergunta:

— No quê?

— YAML.

— É um utilitário da IBM?

— Não.

— É um APF Authorized?

— Não.

— É um membro do PARMLIB?

— Não.

— Então por que todo mundo está usando isso?

A resposta é simples.

Porque YAML se tornou um dos idiomas universais da automação moderna.


O que é YAML?

YAML significa:

YAML Ain't Markup Language

Antigamente significava:

Yet Another Markup Language

Mas os criadores perceberam uma pequena ironia.

YAML não é exatamente uma linguagem de marcação como XML.

Ela é uma linguagem de serialização de dados.

Seu objetivo principal é representar estruturas de dados de forma extremamente legível para humanos.

Imagine um SYSIN bonito.

Ou um membro PARMLIB que alguém resolveu deixar elegante.


Origem do YAML

YAML nasceu em 2001.

Criadores:

Clark Evans

Brian Ingerson

Oren Ben-Kiki

A inspiração veio de várias tecnologias.

XML

SGML

Python

Perl

Configurações INI

A ideia era simples:

Criar algo que fosse:

Menos verboso que XML

Mais organizado que INI

Mais amigável que JSON

Mais legível que arquivos proprietários

Eles conseguiram.


Evolução das versões

YAML 1.0

2001

Primeira implementação.


YAML 1.1

2005

Grande expansão.

Mais tipos de dados.

Booleanos flexíveis.

Exemplo:

yes
no
on
off

Todos eram interpretados como booleanos.

Isso gerou muitos problemas.


YAML 1.2

2009

Versão usada atualmente.

Maior compatibilidade com JSON.

Booleanos ficaram:

true
false

mais previsíveis.


O conceito principal

YAML é apenas dados.

Nada de lógica.

Nada de loops.

Nada de IF.

Ele descreve objetos.

Como um DSECT.

Como um Copybook.

Como um catálogo.

Como um PROC parametrizado.


Estrutura básica

Chave valor

nome: Bellacosa
idade: 52
profissao: Sysprog

Lista

animes:

 - ReZero
 - Konosuba
 - Overlord

Objetos

usuario:

 nome: Vagner

 perfil: Champion

 stack:

   - COBOL
   - CICS
   - DB2

Exemplo equivalente em JSON

JSON:

{
 "nome":"Bellacosa",
 "idade":52
}

YAML

nome: Bellacosa
idade: 52

Muito mais agradável.


A regra mais importante

Espaços importam

Não existe:

BEGIN
END

Não existe:

PERFORM
END-PERFORM

Existe indentação.

Correto:

usuario:

  nome: Bellacosa

  idade:52

Errado

usuario:

nome: Bellacosa

O parser explode.

Padawan aprende isso em cinco minutos.

Veterano aprende isso durante uma madrugada inteira.


Comentários

# Ambiente produção


server:

 host: z17.ibm.com

Strings

nome: COBOL

ou

nome: "COBOL"

Multilinhas

descricao: |

  Curso Mainframe

  COBOL

  CICS

  DB2

Resultado:

Texto preservado.


Dobrando linhas

descricao: >

 Curso COBOL

 Curso CICS

 Curso DB2

Resultado:

Uma única linha.


Exemplo prático passo a passo

Laboratório 1

Criar arquivo.

config.yaml


ambiente: DEV

sistema: COBOLBANK


database:

 tipo: DB2

 versao: 13


cics:

 regiao: CICSPRD


usuarios:


 - nome: Bellacosa

   perfil: SYSADM


 - nome: Padawan

   perfil: DEV

Ler em Python

import yaml


with open("config.yaml") as f:

 dados=yaml.safe_load(f)



print(dados)

Resultado:

Dicionário Python.


Para que serve?

Praticamente tudo.


Kubernetes

Deployment

Pod

Service

Ingress

Secrets


Docker Compose

services:

 cobol:

   image: ibm-z

GitHub Actions

CI/CD

name: Build


jobs:

 compile:

Ansible

Muito usado em IBM Z.

tasks:


 - name: Submit Job


   zos_job_submit:

YAML no Mainframe

Aqui começa a parte divertida.

Hoje YAML está presente em:


Ansible for IBM Z

Coleções IBM.

Automation.

Provisionamento.


Zowe

Perfis.

Plugins.

CLI.


OpenShift

IBM Cloud Pak.


z/OS Connect

Configurações.


Tekton Pipelines

CI/CD Mainframe.


IBM Developer for z/OS

Integrações modernas.


Exemplo Ansible


- hosts: zos


 tasks:


 - name: Copiar membro


   zos_copy:


      src: TESTE


      dest: USER.COBOL(TESTE)

Padawan COBOL olha isso e pensa:

"Parece um PROC misturado com JSON."

Sim.

É exatamente isso.


Vantagens

Legibilidade

Muito melhor que XML.


Menos caracteres

XML:

500 linhas.

YAML:

100 linhas.


Fácil aprendizado

Padawan aprende em poucas horas.


Excelente para automação

DevOps.

IaC.

Pipelines.

Cloud.

Mainframe moderno.


Desvantagens

Espaços

Maior inimigo.

Uma tabulação errada.

Tudo quebra.


Erros difíceis

Parser informa:



Expected block mapping


Obrigado parser.

Não ajudou em nada.


Arquivos gigantes

Pipeline enorme.

5000 linhas.

Fica complicado.


Truques de Jedi

Âncoras


padrao: &base

 memoria: 4GB



server1:


 <<: *base

Reutilização.

Muito elegante.


Variáveis

host: ${HOST}

Referências

perfil: *base

Curiosidades

Muita gente pronuncia:

Yamel

Iamel

Yah-mal

Os criadores aceitam qualquer uma.


Easter Eggs

Booleanos famosos do YAML 1.1

on
off
yes
no

Podiam gerar bugs catastróficos.

Exemplo:

Senha:

password: no

Parser:

False

Administrador:

ABEND S0C4 emocional.


Outro Easter Egg.

YAML é tecnicamente um superconjunto de JSON.

Isto funciona:

{
 "nome":"Bellacosa"
}

É YAML válido.

Pouca gente sabe disso.


Dicas para Padawans COBOL

Pense em YAML como um PARMLIB moderno

PARMLIB → YAML

JCL PROC → YAML

Control Cards → YAML

Copybook → YAML

A curva de aprendizado fica muito menor.


Use validadores

Ferramentas excelentes:

  • yamllint

  • VSCode YAML Extension

  • IntelliJ YAML Plugin

  • Red Hat YAML Support

Evita noites em SDSF procurando um erro que, desta vez, não foi um IEC161I, um JCL ERROR ou um RACF 913, mas simplesmente dois espaços a menos.


O Conselho do Mestre Bellacosa

O Padawan COBOL que aprende YAML não está abandonando o IBM Z.

Está aprendendo uma nova língua diplomática do universo corporativo.

O profissional do futuro provavelmente continuará compilando programas COBOL, analisando SMF, ajustando CICS e executando REORG no Db2.

Mas também abrirá um repositório Git, ajustará um pipeline Tekton, criará um playbook Ansible, configurará um ambiente OpenShift e conversará com agentes de IA que utilizam arquivos YAML para descrever fluxos, ferramentas e automações.

No fim das contas, YAML talvez seja apenas isto:

O SYSIN que decidiu fazer intercâmbio com a nuvem, frequentar reuniões de DevOps e voltar para casa falando Kubernetes com sotaque de Ansible.

E, curiosamente, muitos Sysprogs veteranos descobrem que já entendiam YAML há anos. Apenas o chamavam por outros nomes:

PARMLIB, PROC, SYSIN, COPYBOOK ou simplesmente "aquele membro que ninguém ousa mexer em produção numa sexta-feira à tarde". ☕🚀