 |
| Bellacosa Mainframe e a crise dos skills no mundo ibm z |
☕ Um Café no Bellacosa Mainframe
O Guia do Mochileiro das Galáxias para a Crise de Skills no IBM Z
🚀 Como um programador COBOL iniciante pode sobreviver a badges, cursos de 15 semanas, veteranos de 40 anos, abends inexplicáveis e à perturbadora descoberta de que MAXCC=0 não significa que você entendeu alguma coisa
NÃO ENTRE EM PÂNICO.
Especialmente se alguém disser que você virou especialista em mainframe depois de quinze semanas.
Existe, em algum lugar do universo corporativo, provavelmente em uma sala com carpete cinza, café requentado e uma televisão exibindo dashboards coloridos, uma pessoa extremamente satisfeita porque um gráfico ficou verde.
O gráfico provavelmente se chama:
IBM Z SKILLS PIPELINE — STATUS: HEALTHY
Ao lado dele há números impressionantes:
2.437 estudantes treinados
1.982 badges emitidos
784 laboratórios concluídos
97% satisfaction score
42 parceiros
15 semanas
Todos aplaudem.
Alguém tira uma fotografia.
Um executivo diz:
— Excelente! Resolvemos o problema de skills.
Nesse exato momento, a aproximadamente 37 metros dali, um especialista de Db2 com 31 anos de experiência está preenchendo sua documentação de aposentadoria.
Ninguém percebe.
Ele sabe por que determinada subsystem parameter foi alterada em 2004.
Ninguém mais sabe.
Ele lembra por que um batch aparentemente absurdo precisa executar antes das 04:17.
Ninguém documentou.
Ele sabe que existe um programa COBOL compilado em uma determinada opção porque, sem ela, um arquivo produzido por um sistema comprado em 1998 gera um problema extremamente específico que só aparece em fevereiro, em anos bissextos, quando o processamento acontece depois de uma determinada janela.
O programa chama-se:
XPTO047B
Naturalmente.
E assim começa a nossa aventura.
Porque a crise de habilidades do mainframe não é simplesmente uma crise de gente.
É uma crise de continuidade de conhecimento.
E se você é um programador COBOL iniciante entrando agora nesse universo, tenho duas notícias.
A primeira é ótima:
Nunca houve tanto material para aprender mainframe.
A segunda é ligeiramente perturbadora:
Aprender material não significa aprender mainframe.
Pegue sua toalha.
Vamos conversar sobre isso.
🧭 Capítulo 1 — Você não precisa saber IBM Z para começar IBM Z
Comecemos eliminando uma bobagem imediatamente.
Existem pessoas que ficam indignadas quando aparece um curso anunciando:
No previous IBM Z experience required.
Isso, por si só, não é um problema.
Na realidade, é excelente.
Se para aprender mainframe fosse necessário já conhecer mainframe, teríamos criado um paradoxo digno de um departamento burocrático intergaláctico:
Para conseguir experiência:
você precisa trabalhar com mainframe.
Para trabalhar com mainframe:
você precisa ter experiência com mainframe.
Resultado:
RC=12
REASON=HUMAN_RESOURCE_NOT_FOUND
Todo ecossistema precisa de portas de entrada.
Precisamos de universidades.
Precisamos de cursos.
Precisamos de bootcamps.
Precisamos de laboratórios.
Precisamos de vídeos.
Precisamos de badges.
Precisamos de ambientes educacionais.
Precisamos até daquele sujeito no YouTube que grava um tutorial às três da manhã explicando JCL enquanto um gato atravessa o teclado.
Tudo isso é valioso.
O problema surge quando confundimos:
porta de entrada
com
linha de chegada.
Um curso de 15 semanas pode apresentar você ao IBM Z.
Ele pode ensinar conceitos fundamentais.
Pode fazer você executar JCL.
Pode mostrar COBOL.
Pode apresentar Db2.
Pode colocar você diante de CICS.
Pode ensinar conceitos de RACF.
Pode fazer você entender datasets, JES, TSO, ISPF e talvez z/OSMF.
Fantástico.
Mas quinze semanas não transformam automaticamente alguém em especialista.
Da mesma forma que quinze semanas de aulas de medicina não transformam alguém em neurocirurgião.
Você pode aprender onde fica o cérebro.
Isso já ajuda bastante.
Mas eu não entregaria imediatamente uma furadeira.
🪪 Capítulo 2 — O Badge não é seu inimigo
Existe uma tendência divertida em tecnologia de atacar badges como se pequenos arquivos PNG fossem responsáveis pela decadência da civilização ocidental.
Eles não são.
Um badge é simplesmente um marcador.
Ele pode dizer:
Esta pessoa concluiu determinada formação.
Perfeito.
O problema aparece quando alguém interpreta:
Esta pessoa concluiu determinada formação.
como:
Esta pessoa domina profundamente a tecnologia.
A diferença é gigantesca.
Para um programador COBOL iniciante, eu gosto de imaginar cinco níveis.
Nível 1 — Exposure
Você já ouviu falar das coisas.
Sabe que:
JCL não é COBOL.
Db2 não é VSAM.
CICS não é um banco de dados.
RACF não é antivírus.
JES2 não é Jesus 2.0.
O último esclarecimento evita algumas reuniões constrangedoras.
Nível 2 — Literacy
Agora você consegue explicar aproximadamente como as coisas se relacionam.
Você entende que um programa COBOL batch pode:
receber arquivos;
acessar Db2;
executar dentro de um JOB;
produzir datasets;
ser controlado por JCL;
retornar códigos;
gerar dumps;
participar de uma cadeia de processamento.
Você começa a montar o mapa mental.
Nível 3 — Competence
Agora consegue fazer trabalho real.
Você recebe um programa COBOL.
Identifica um problema.
Compila.
Executa.
Interpreta resultados.
Corrige erros.
Entende alguns abends.
Analisa JCL.
Usa ferramentas.
Sabe que mexer em produção sem compreender impacto pode resultar em pessoas pronunciando seu nome em reuniões onde você não foi convidado.
Nível 4 — Proficiency
Você começa a trabalhar independentemente.
Recebe problemas menos estruturados.
Não existe tutorial dizendo exatamente o que fazer.
Você encontra caminhos.
Começa a correlacionar sintomas.
Nível 5 — Mastery
Aqui a brincadeira muda.
Você consegue lidar com problemas que não estavam no treinamento.
Essa é uma definição extremamente importante.
Um especialista não é simplesmente quem sabe responder perguntas conhecidas.
É quem consegue raciocinar quando a pergunta é nova.
🧠 Capítulo 3 — O verdadeiro patrimônio do mainframe não está no DASD
Está dentro da cabeça das pessoas.
Chamamos isso de:
conhecimento tácito.
Conhecimento explícito é relativamente fácil de registrar:
Comando X faz Y.
Parâmetro Z controla W.
Arquivo possui LRECL 100.
Conhecimento tácito é diferente.
É quando o especialista olha para determinada situação e diz:
— Isso está estranho.
Você pergunta:
— Por quê?
Ele responde:
— Não sei ainda.
Isso parece pouco científico.
Mas geralmente significa:
Meu cérebro comparou essa situação com aproximadamente 27 anos de incidentes, padrões, falhas, mudanças, madrugadas, dumps e decisões e encontrou alguma discrepância ainda não verbalizada.
Esse tipo de percepção não aparece instantaneamente.
É acumulada.
Considere dois programadores.
Programador A terminou um curso sobre CICS.
Programador B trabalha com CICS há vinte anos.
Ambos sabem que existe:
EXEC CICS LINK
Mas o segundo talvez tenha vivenciado:
problemas de storage;
loops;
short-on-storage;
runaway tasks;
deadlocks;
transaction dumps;
problemas de terminal;
mudanças de region;
falhas em integração;
incidentes envolvendo Db2;
problemas de performance;
erros provocados por parâmetros aparentemente inocentes.
O conhecimento não é apenas:
“Como funciona CICS?”
É também:
“Como CICS costuma falhar de maneiras que parecem ser outra coisa?”
Essa segunda categoria vale ouro.
🏺 Capítulo 4 — Arqueologia orientada a produção
Em sistemas antigos existe uma disciplina raramente ensinada nas universidades.
Ela se chama:
Arqueologia de Software
Você encontra:
IF WS-FLAG = 'Y'
MOVE 'N' TO WS-FLAG
PERFORM 9000-TRATAMENTO-ESPECIAL.
Você pergunta:
— Por que isso existe?
Ninguém sabe.
O Git não possui histórico porque o programa nasceu antes do Git.
Talvez antes do Linux.
Talvez antes de alguns membros da equipe.
O comentário diz:
* ALTERACAO 12/08/1996 - JORGE
Jorge desapareceu da empresa em 2003.
Ninguém sabe onde Jorge está.
Talvez Jorge esteja pescando.
Talvez Jorge esteja em Portugal.
Talvez Jorge tenha transcendido e virado uma entidade puramente energética.
Mas aquele IF continua executando três milhões de vezes por dia.
O desenvolvedor moderno então pensa:
Código morto.
Remove.
Compila.
Teste passa.
Produção recebe.
Às 03:11 ocorre algo que não acontecia desde 1997.
Parabéns.
Você acabou de descobrir por que Jorge escreveu aquilo.
Esse é um dos motivos pelos quais veteranos são tão valiosos.
Eles frequentemente carregam o contexto histórico do código.
💳 Capítulo 5 — Technical Debt ganhou um primo: Knowledge Debt
Você provavelmente já ouviu falar de Technical Debt.
É quando fazemos escolhas que criam custo futuro.
Existe outra dívida silenciosa:
Knowledge Debt
Ela acontece quando uma organização depende de conhecimento que não está sendo transferido.
Exemplo.
Maria trabalha com Db2 há 28 anos.
Ela conhece profundamente:
performance
utilities
locking
bind
packages
statistics
reorg
recovery
SQL
Todos sabem que Maria sabe.
Então ninguém se preocupa.
Maria resolve problemas.
Maria responde mensagens.
Maria entra nas bridges.
Maria salva a madrugada.
Excelente.
Até o dia em que Maria anuncia:
Vou me aposentar.
Repentinamente surge um PowerPoint:
KNOWLEDGE TRANSFER PLAN
Slide 1:
Duration: 3 weeks
Naturalmente.
Porque obviamente 28 anos podem ser compactados em três semanas através da misteriosa tecnologia conhecida como Microsoft Teams.
Isso é Knowledge Debt vencendo.
🧑🏫 Capítulo 6 — Apprenticeship: a tecnologia revolucionária inventada há milhares de anos
Existe uma abordagem surpreendentemente eficiente para formar pessoas.
Coloque alguém menos experiente próximo de alguém experiente.
Deixe trabalhar juntos.
Parece radical.
Antigamente chamávamos isso de:
aprendizagem.
No mundo moderno poderíamos chamar:
Human Knowledge Replication Framework 2.0
e cobrar consultoria.
O processo saudável costuma parecer assim:
OBSERVAR
↓
EXECUTAR COM AJUDA
↓
EXECUTAR SOZINHO
↓
RESOLVER PROBLEMAS
↓
TOMAR DECISÕES
↓
ENSINAR OUTROS
Observe a última etapa.
Ensinar é importantíssimo.
Quando você consegue ensinar alguém, precisa organizar mentalmente aquilo que sabe.
É por isso que recomendo que programadores iniciantes criem pequenos registros.
Pode ser:
blog;
notas;
Markdown;
Git;
wiki;
caderno;
Obsidian;
arquivos pessoais.
Depois de resolver um problema, escreva:
O que aconteceu?
O que pensei inicialmente?
O que estava errado?
Como diagnostiquei?
Qual era a causa?
O que faria diferente?
Depois de alguns anos isso vira seu próprio Knowledge Vault.
🧪 Capítulo 7 — O laboratório perfeito não deve funcionar
Isso mesmo.
Se você está aprendendo mainframe, laboratórios onde tudo funciona são úteis apenas até certo ponto.
O verdadeiro aprendizado começa quando alguma coisa quebra.
Um ótimo laboratório deveria dizer:
Aqui está o JOB.
Ele não funciona.
Descubra por quê.
Talvez exista:
DISP incorreto
Talvez:
LRECL incompatível
Talvez:
dataset inexistente
Talvez:
SQLCODE -805
Talvez:
S0C7
Talvez:
AEI9
Talvez seja apenas uma vírgula.
Essa última opção costuma causar mais sofrimento.
O objetivo é criar musculatura diagnóstica.
🩺 Capítulo 8 — House M.D. entra no CPD
Imagine o Dr. House analisando um incidente COBOL.
Operações diz:
— O batch falhou.
House:
— Isso é um sintoma.
Desenvolvimento:
— O programa deu S0C7.
House:
— Outro sintoma.
Gerente:
— Ontem funcionava.
House:
— Impressionante. Ontem também não é hoje.
Então começa o diagnóstico.
A pergunta errada é:
Como elimino o S0C7?
A pergunta correta é:
O que fez o programa interpretar esses bytes como número?
Pode ser:
PIC incorreta
Pode ser arquivo errado.
Pode ser layout diferente.
Pode ser REDEFINES.
Pode ser campo não inicializado.
Pode ser alteração upstream.
Pode ser dados corrompidos.
Pode ser compilação diferente.
O especialista pensa em cadeia causal.
Essa é a diferença entre aprender mensagens e aprender sistemas.
🌌 Capítulo 9 — Systems Thinking: a habilidade secreta
Mainframe ensina uma coisa muito importante:
Nada acontece sozinho.
Programa COBOL pode depender de:
JCL
↓
PROC
↓
dataset
↓
catalog
↓
SMS
↓
Db2
↓
CICS
↓
MQ
↓
RACF
↓
network
↓
WLM
↓
storage
Um erro aparece no COBOL.
A causa pode estar cinco camadas atrás.
Essa capacidade de pensar em relações é o que chamamos de systems thinking.
Comece a praticar isso imediatamente.
Sempre pergunte:
O que chama isso?
O que isso chama?
Quais dados entram?
Quem produz esses dados?
Quem consome a saída?
Quais configurações externas influenciam?
O que mudou recentemente?
Essas perguntas valem mais do que decorar cem mensagens de erro.
🪜 Capítulo 10 — O caminho real para quem está começando
Se eu estivesse começando COBOL hoje, montaria esta progressão.
Etapa 1 — COBOL puro
Aprenda muito bem:
DIVISION
SECTION
PARAGRAPH
PIC
MOVE
COMPUTE
IF
EVALUATE
PERFORM
OCCURS
REDEFINES
COMP
COMP-3
Entenda dados.
COBOL é profundamente orientado a dados.
Não trate PIC como decoração.
Etapa 2 — Arquivos
Aprenda:
SEQUENTIAL
INDEXED
VSAM
KSDS
ESDS
Entenda:
RECFM
LRECL
BLKSIZE
Arquivo errado é fonte inesgotável de aventuras.
Etapa 3 — JCL
Não diga:
“Sou desenvolvedor, JCL não é comigo.”
Isso é aproximadamente equivalente a ser piloto dizendo:
“Combustível é coisa da equipe de solo.”
Aprenda:
JOB
EXEC
DD
DISP
SPACE
DSN
SYSOUT
COND
IF
PROC
GDG
Etapa 4 — Db2
Entenda:
SELECT
INSERT
UPDATE
DELETE
COMMIT
ROLLBACK
CURSOR
HOST VARIABLES
NULL INDICATOR
SQLCODE
Depois vá mais fundo.
Etapa 5 — CICS
Aprenda pelo menos os conceitos.
COMMAREA
CHANNEL
CONTAINER
LINK
XCTL
RETURN
READ
WRITE
REWRITE
START
E sobretudo entenda transação.
Etapa 6 — Debugging
Comece a amar mensagens de erro.
Não porque seja saudável.
Mas porque é inevitável.
Leia:
compile listing
runtime messages
joblog
sysout
dump
O dump é o romance policial do mainframe.
O assassino está lá.
Você só precisa descobrir quem é.
🧯 Capítulo 11 — MAXCC=0 não significa que o mundo está salvo
Esse merece moldura.
Você executou:
MAXCC=0
Excelente.
Isso significa aproximadamente:
O utilitário não detectou determinados tipos de problema segundo seus critérios.
Não significa:
Sua solução está correta.
Exemplo.
Você pode executar um SORT perfeitamente.
MAXCC=0
Mas ordenar pelo campo errado.
O computador fez exatamente aquilo que você pediu.
A tragédia é que você pediu uma coisa absurda.
Computadores possuem esse hábito desagradável.
🪐 Easter Egg 42
Em O Guia do Mochileiro das Galáxias, a resposta para a grande pergunta sobre a vida, o universo e tudo mais é:
42.
No mainframe também existe uma grande pergunta.
Quantos anos são necessários para dominar completamente IBM Z?
Resposta:
42.
A diferença é que, no ano 42, provavelmente alguém instalará uma atualização e você terá que estudar novamente.
📊 Capítulo 12 — O Grande Deus Dashboard
Organizações adoram métricas.
Não há nada errado nisso.
O problema é medir aquilo que é fácil em vez daquilo que importa.
É fácil medir:
NUMBER_OF_BADGES
NUMBER_OF_STUDENTS
COURSES_COMPLETED
LABS_FINISHED
Muito mais difícil medir:
CAN_HANDLE_PRODUCTION_INCIDENT
CAN_EXPLAIN_ARCHITECTURE
CAN_RECOVER_SERVICE
CAN_MENTOR_JUNIOR
CAN_REPLACE_RETIRING_SME
Imagine dois programas.
Programa A:
1.000 certificados
Programa B:
20 pessoas
18 meses
shadowing
incidentes
laboratórios
mentoria
responsabilidade progressiva
O primeiro produz slide bonito.
O segundo talvez salve seu banco às três da manhã.
👴 Capítulo 13 — Não transforme veteranos em sacerdotes secretos
Agora uma advertência importante.
Também não devemos romantizar demais o passado.
Existia — e ainda existe — o profissional conhecido como:
“Só o Carlos sabe.”
Pergunta:
— Como funciona esse processo?
Resposta:
— Pergunta pro Carlos.
— Onde está documentado?
— Carlos sabe.
— O que acontece se Carlos sair?
Silêncio.
Carlos não é arquitetura.
Carlos é um risco operacional humano.
O conhecimento precisa circular.
Um bom especialista não apenas resolve.
Ele deixa rastros.
Documenta.
Ensina.
Explica contexto.
Forma sucessores.
🗺️ Capítulo 14 — Como aprender com um veterano sem sequestrá-lo
Quando encontrar alguém experiente, não faça apenas perguntas genéricas.
Pergunte histórias.
Em vez de:
Como funciona Db2?
Pergunte:
Qual foi o pior incidente Db2 que você já viu?
Depois:
Como vocês perceberam?
Qual foi a hipótese inicial?
O que enganou vocês?
Qual era a verdadeira causa?
O que mudou depois?
Isso extrai conhecimento tácito.
Profissionais veteranos frequentemente possuem centenas dessas histórias.
Cada história contém:
contexto
hipótese
erro
diagnóstico
causa
solução
prevenção
Isso vale ouro.
⚠️ Capítulo 15 — Não tenha pressa de parecer sênior
Esse talvez seja o conselho mais importante para um iniciante.
Não tenha vergonha de dizer:
Não sei.
Em sistemas complexos, fingir conhecimento é muito mais perigoso do que admitir desconhecimento.
O bom iniciante pergunta.
O iniciante perigoso inventa.
Você encontrará pessoas exibindo uma coleção impressionante de badges.
Ótimo.
Você também encontrará pessoas com trinta anos de experiência e nenhum badge.
Não trate nenhuma das duas coisas isoladamente como prova definitiva.
Observe capacidade.
Observe raciocínio.
Observe comportamento diante de problemas.
🛠️ Capítulo 16 — Seu plano pessoal de apprenticeship
Mesmo que sua empresa não tenha um programa formal, crie um informal.
Faça isso:
1. Escolha um domínio
Por exemplo:
COBOL batch
2. Encontre alguém mais experiente
Não precisa ser o maior guru do planeta.
Só precisa estar alguns quilômetros à sua frente.
3. Observe problemas reais
Sempre respeitando segurança e acesso.
4. Reproduza em laboratório
Transforme incidentes em exercícios.
5. Documente
Crie notas.
6. Explique para outra pessoa
Se você não consegue explicar, talvez ainda não tenha entendido.
7. Volte seis meses depois
Você ficará horrorizado com suas primeiras anotações.
Isso é bom.
Significa evolução.
🧬 Capítulo 17 — Expertise não é uma coleção de comandos
Esse é o ponto central de toda esta conversa.
Expertise não é:
quantidade de sintaxe memorizada
É uma mistura de:
conhecimento
+
experiência
+
contexto
+
julgamento
+
memória de falhas
+
capacidade de investigação
+
capacidade de ensinar
É por isso que ela demora.
E talvez seja bom que demore.
Porque sistemas que movimentam bancos, governos, seguradoras, companhias aéreas, indústrias e redes gigantescas não deveriam depender de uma cultura onde qualquer pessoa é declarada especialista depois de algumas semanas.
🚨 Capítulo 18 — Production Disaster Nobody Predicted
Todo treinamento deveria possuir um módulo final chamado:
“Algo aconteceu e ninguém sabe o quê.”
Descrição:
03:07
Produção degradada.
Nenhuma mudança aparente.
Aplicação parcialmente funcionando.
Usuários reclamando.
Batch atrasado.
CICS estranho.
Db2 aparentemente saudável.
Uma alteração ocorreu 14 horas atrás.
Ninguém lembra qual.
Objetivo:
sobreviva.
Sem múltipla escolha.
Sem botão “Hint”.
Sem resposta imediatamente disponível.
Esse tipo de exercício aproxima treinamento de realidade.
🧙 Capítulo 19 — O verdadeiro mestre Jedi do mainframe
Você reconhece um grande profissional porque ele não precisa fingir onisciência.
Ele diz:
Não sei ainda.
Depois começa a investigar.
Ele sabe onde procurar.
Sabe formular hipótese.
Sabe descartar hipótese.
Sabe evitar mudanças destrutivas.
Sabe pedir ajuda.
Sabe interpretar evidência.
Sabe documentar descoberta.
E depois ensina alguém.
Essa última parte transforma especialista em legado.
🛰️ Capítulo 20 — Então o que fazemos com os programas de 15 semanas?
Usamos.
Melhoramos.
Expandimos.
Mas chamamos as coisas pelo nome correto.
Um programa curto pode ser:
Foundation Program
Excelente.
Depois crie:
FOUNDATION
↓
LAB
↓
APPRENTICESHIP
↓
PRODUCTION SHADOWING
↓
RESPONSIBILITY
↓
SPECIALIZATION
↓
MENTORSHIP
Agora temos um pipeline.
Não um evento.
A crise de skills não será resolvida através de um único curso.
Será resolvida construindo gerações sobre gerações de profissionais.
Exatamente como o próprio mainframe foi construído.
☕ Epílogo — NÃO ENTRE EM PÂNICO
Se você é iniciante e chegou até aqui preocupado porque aparentemente precisa de trinta anos para aprender IBM Z, relaxe.
Você não precisa aprender tudo.
Ninguém sabe tudo.
IBM Z é grande demais.
Escolha uma trilha.
Aprenda profundamente.
Construa conexões com outras áreas.
Pergunte.
Quebre coisas em laboratório.
Leia mensagens.
Leia listings.
Leia dumps.
Leia documentação.
Converse com veteranos.
Ensine iniciantes.
E principalmente:
não confunda velocidade de formação com profundidade de conhecimento.
Badge é ótimo.
Curso é ótimo.
Certificação é ótima.
Laboratório é ótimo.
Mas todos são partes de algo maior.
A verdadeira formação acontece quando conhecimento encontra experiência.
Quando teoria encontra produção.
Quando documentação encontra memória.
Quando o iniciante pergunta:
Por que fazemos isso assim?
E, em vez de receber:
Porque sempre foi assim.
recebe uma história.
Talvez uma história envolvendo um abend.
Talvez um IPL.
Talvez um banco.
Talvez alguém chamado Jorge.
Talvez 1996.
Talvez um PROC.
Talvez uma madrugada particularmente infeliz.
Essas histórias são o DNA invisível do mainframe.
Preservá-las é tão importante quanto preservar código.
Porque máquinas podem executar programas durante cinquenta anos.
Mas somente pessoas conseguem explicar por que aquele programa ainda deveria existir.
E se algum dashboard corporativo disser que resolvemos tudo depois de quinze semanas, faça aquilo que todo bom programador COBOL aprende cedo ou tarde.
Leia o detalhe.
Procure a mensagem.
Questione a condição.
E desconfie profundamente de qualquer universo onde:
SKILLS-CRISIS = 'SOLVED'
foi definido simplesmente porque:
BADGE-COUNT > 1000
Afinal, como diria um guia extremamente confiável de viagens intergalácticas:
NÃO ENTRE EM PÂNICO.
Mas mantenha o dump por perto.
https://eljefemidnightlunch.blogspot.com/2026/08/o-caso-tsb-bank-como-uma-migracao-de.html
https://eljefemidnightlunch.blogspot.com/2026/08/quanto-custa-um-programador-salario.htm
