 |
| Bellacosa Mainframe uma wiki para usar o obsidian |
☕ Um Café no Bellacosa Mainframe
Do Blogger ao Obsidian: A Jornada para Transformar um Blog Antigo em uma Wiki Pessoal Digna da Frota Estelar
Há um momento na vida de todo programador COBOL em que ele percebe uma verdade desconfortável:
o código pode sobreviver por décadas, mas o conhecimento pode desaparecer em uma tarde.
Um programa COBOL criado em 1987 ainda pode estar processando milhões de transações. Um JCL escrito antes de muita gente nascer pode continuar rodando religiosamente às duas da manhã. Um arquivo VSAM pode carregar a memória operacional de uma empresa inteira.
Mas um blog?
Um blog depende de plataforma, servidor, domínio, política comercial, formato de exportação, links, imagens, bancos de dados, APIs, temas, plugins e, às vezes, de uma boa dose de sorte.
Foi exatamente nesse ponto que começou esta missão.
O objetivo inicial parecia simples:
baixar um blog do Blogspot, abrir o conteúdo em uma ferramenta desktop, editar os artigos, melhorar os textos, incluir novas informações e, mais tarde, converter tudo para WordPress.
Mas, como acontece em qualquer missão da Frota Estelar, a pergunta inicial escondia uma arquitetura muito maior.
O que parecia ser apenas uma migração de blog revelou-se um projeto de preservação de conhecimento.
E assim nasceu a ideia de construir uma verdadeira:
El Jefe Midnight Lunch Wiki
Uma Wikipédia pessoal, offline, pesquisável, versionada, enriquecida com inteligência artificial e construída sobre o Obsidian.
Prepare o café. Ajuste o uniforme. Verifique o estado dos escudos. Esta viagem começa em um arquivo XML e termina em uma galáxia de conhecimento.
1. O problema real não é mover o blog
Quando alguém diz:
“Quero converter meu Blogger para WordPress”
a primeira reação costuma ser procurar um conversor.
Blogger XML para WordPress XML.
Parece lógico.
Mas essa abordagem enxerga apenas o transporte, não o patrimônio.
Imagine um mainframe com milhares de programas COBOL. Você não faria uma migração simplesmente copiando todos os fontes para uma pasta chamada NOVO-SISTEMA.
Seria necessário identificar:
programas ativos;
programas obsoletos;
dependências;
chamadas entre módulos;
arquivos utilizados;
tabelas acessadas;
rotinas duplicadas;
versões antigas;
documentação;
regras de negócio;
riscos operacionais.
Com um blog de milhares de artigos acontece a mesma coisa.
Você não possui apenas postagens.
Você possui:
conhecimento técnico;
memórias;
séries;
tutoriais;
análises;
imagens;
títulos;
categorias;
marcadores;
hyperlinks;
relacionamentos invisíveis;
artigos incompletos;
textos duplicados;
conteúdos atualizados;
conteúdos desatualizados;
material que pode virar curso;
material que pode virar livro;
material que pode virar newsletter;
material que pode virar vídeo.
O verdadeiro projeto, portanto, não é:
Blogger → WordPress
O verdadeiro projeto é:
Blog antigo
↓
Base de conhecimento
↓
Edição
↓
Enriquecimento
↓
Organização
↓
Preservação
↓
Publicação multiplataforma
Essa diferença é gigantesca.
2. Por que o Obsidian entra nesta história?
O Obsidian é uma ferramenta desktop baseada em arquivos Markdown.
Markdown é um formato de texto simples.
Um artigo pode ser armazenado assim:
# COBOL sem Mistérios
COBOL é uma linguagem criada para processamento de negócios.
## Principais características
- Legibilidade
- Estabilidade
- Precisão decimal
- Integração com arquivos e bancos
Esse arquivo é apenas texto.
Não depende de um banco de dados secreto.
Não depende de uma plataforma proprietária.
Não depende do Blogger.
Não depende do WordPress.
Não depende sequer do próprio Obsidian.
Você pode abrir o arquivo com:
Bloco de Notas;
Visual Studio Code;
Notepad++;
GitHub;
qualquer editor de texto;
scripts Python;
ferramentas Linux;
geradores de site estático;
sistemas de inteligência artificial.
Essa é uma diferença fundamental.
No Blogger, seu conteúdo vive dentro da plataforma.
No Obsidian, seu conteúdo vive em seus arquivos.
O Obsidian é a ponte de comando.
Mas os dados continuam sendo seus.
3. O que é um Vault?
No Obsidian, uma coleção de notas é chamada de Vault.
Em português, poderíamos chamar de cofre.
Para o projeto Bellacosa, o nome perfeito seria:
Bellacosa Mainframe Vault
ou:
El Jefe Midnight Lunch Wiki
Esse Vault nada mais é do que uma pasta no computador.
Exemplo:
C:\BellacosaVault
Dentro dela você poderia ter:
00-Inbox
01-Artigos
02-Imagens
03-Templates
04-Cursos
05-Livros
06-Pesquisas
07-Códigos
08-Fontes
09-Publicados
10-Rascunhos
99-Arquivo
Cada artigo seria um arquivo .md.
Exemplo:
01-Artigos\COBOL\Alter-sem-Misterios.md
01-Artigos\CICS\Commarea-sem-Misterios.md
01-Artigos\DB2\SQLCODE-sem-Misterios.md
01-Artigos\IA\Agentes-de-IA.md
01-Artigos\Anime\Log-Horizon.md
É como se cada postagem fosse um membro da tripulação.
Cada uma tem função própria.
Mas todas pertencem à mesma nave.
4. Por que isso se parece com uma Wikipédia?
Porque o Obsidian permite criar links entre notas usando uma sintaxe muito simples:
[[COBOL]]
[[CICS]]
[[Db2]]
[[VSAM]]
[[IBM Z]]
Suponha que você esteja escrevendo um artigo sobre programas COBOL executados no CICS.
Você poderia escrever:
Um programa [[COBOL]] pode ser executado sob o controle do [[CICS]], acessar dados no [[Db2]] e manipular arquivos [[VSAM]].
Cada termo entre colchetes vira um link.
Ao clicar em [[CICS]], você abre a nota CICS.
Ao clicar em [[Db2]], abre a nota Db2.
Ao clicar em [[VSAM]], abre a nota VSAM.
Agora imagine isso em três mil artigos.
Seu blog deixa de ser uma linha cronológica.
Ele vira uma rede.
Um mapa.
Uma enciclopédia.
Uma galáxia.
5. O poder dos backlinks
Os backlinks mostram quem aponta para determinada nota.
Imagine abrir a nota:
CICS.md
E o Obsidian mostrar:
Artigos que mencionam CICS:
- COBOL Online sem Mistérios
- COMMAREA sem Mistérios
- Pseudoconversacional
- BMS
- EIBRESP
- CEDF
- CECI
- CICS Web Services
- z/OS Connect
Isso é extremamente poderoso.
No Blogger, você precisa lembrar manualmente quais artigos estão relacionados.
No Obsidian, o sistema mostra automaticamente.
Backlink é como uma tabela de chamadas de programas.
Se um módulo COBOL é chamado por vinte programas, você quer saber quem são eles.
Se um artigo sobre CICS é citado por vinte outros textos, você também quer saber.
A lógica é parecida.
6. O Graph View: a galáxia do conhecimento
O Graph View é uma visualização gráfica das notas e ligações.
Imagine algo assim:
IBM Z
|
----------------------
| | |
COBOL CICS Db2
| | |
JCL COMMAREA SQL
| | |
JES2 BMS BIND
Cada nota aparece como um ponto.
Cada ligação aparece como uma linha.
Em um acervo pequeno, o grafo é curioso.
Em um acervo de milhares de artigos, ele se torna um mapa intelectual.
Você pode descobrir que:
muitos artigos de COBOL se conectam a CICS;
textos de DevOps se conectam a Git, Jenkins e Ansible;
artigos sobre IA se ligam a segurança, governança e automação;
conteúdos de anime se conectam a cultura japonesa, filosofia e tecnologia;
Star Trek aparece como metáfora em vários temas técnicos.
O Graph View mostra algo que o Blogger nunca mostrou:
como sua mente organiza o conhecimento.
Esse é um dos grandes easter eggs do Obsidian.
Você começa pensando que está organizando arquivos.
Depois percebe que está visualizando sua própria arquitetura mental.
7. O primeiro cuidado: o arquivo XML correto
Durante a missão apareceu um arquivo chamado:
export.xml
Parecia promissor.
Mas ao abrir o conteúdo, surgiu uma surpresa.
O arquivo começava com:
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
E continha estruturas como:
<url>
<loc>https://eljefemidnightlunch.blogspot.com/...</loc>
<lastmod>2026-07-13T21:29:22Z</lastmod>
</url>
Isso significa que o arquivo não era o backup completo do Blogger.
Era um sitemap.
Um sitemap é uma lista de URLs destinada principalmente a mecanismos de busca.
Ele informa:
endereço da página;
data de modificação;
às vezes prioridade;
às vezes frequência de atualização.
Mas não possui necessariamente:
corpo do artigo;
título completo em campo estruturado;
marcadores;
comentários;
autor;
conteúdo HTML;
imagens incorporadas;
configurações da postagem.
O arquivo enviado era, portanto, um mapa de rotas, não a carga da nave.
Essa distinção é importantíssima.
Um sitemap diz:
“Existe uma página neste endereço.”
O backup do Blogger diz:
“Aqui está a página, o título, o conteúdo, a data, as categorias e seus metadados.”
Em linguagem mainframe:
O sitemap é como um catálogo de datasets.
O backup completo é como o conteúdo real dos datasets.
Saber que HLQ.PRODUCAO.CLIENTES existe não significa que você possui os registros dentro dele.
8. Como reconhecer um verdadeiro backup do Blogger
Um backup completo do Blogger normalmente usa o formato Atom.
Ele costuma começar com algo parecido com:
<?xml version='1.0' encoding='UTF-8'?>
<feed xmlns='http://www.w3.org/2005/Atom'>
Dentro dele aparecem várias estruturas <entry>.
Exemplo simplificado:
<entry>
<title>COBOL sem Mistérios</title>
<published>2026-07-10T10:00:00Z</published>
<content type="html">
<![CDATA[
<p>COBOL é uma linguagem...</p>
]]>
</content>
</entry>
Cada <entry> pode representar:
uma postagem;
um comentário;
uma página;
uma configuração;
outro item exportado pelo Blogger.
O conversor precisa analisar o tipo de entrada.
Não basta transformar cada <entry> em artigo.
É necessário filtrar corretamente.
9. Passo a passo para obter o arquivo certo
No Blogger, o caminho normalmente é semelhante a:
Configurações
↓
Gerenciar blog
↓
Fazer backup do conteúdo
↓
Download
Depois do download, guarde o arquivo original em uma pasta segura.
Exemplo:
D:\Backup-Blogger\Original\blog-backup.xml
Faça uma cópia de trabalho:
D:\Backup-Blogger\Trabalho\blog-backup.xml
Nunca altere diretamente o original.
Essa é uma regra clássica de operações.
Um operador experiente jamais testa uma rotina de reorganização usando o único arquivo de produção disponível.
O mesmo vale para seu blog.
10. A estratégia correta de conversão
O melhor projeto não gera apenas um formato.
Gera vários.
Blogger Atom XML
|
|---- WordPress WXR
|
|---- Markdown
|
|---- HTML
|
|---- JSON
|
|---- SQLite
|
|---- CSV de índice
|
|---- Relatório de erros
Por quê?
Porque cada formato atende a uma missão.
WordPress WXR
Serve para importar no WordPress.
Markdown
Serve para Obsidian, GitHub, Hugo, Jekyll, MkDocs e edição offline.
HTML
Preserva melhor o conteúdo visual original.
JSON
Facilita automações e integração com scripts.
SQLite
Permite pesquisas estruturadas.
CSV
Ajuda a criar inventários.
Relatório de erros
Mostra:
títulos ausentes;
datas inválidas;
HTML quebrado;
imagens externas;
links problemáticos;
artigos duplicados;
entradas vazias.
Esse é o equivalente editorial de rodar uma validação antes do deploy.
11. Como deve ficar cada arquivo Markdown
Um artigo convertido não deve conter apenas o texto.
Ele deve carregar metadados.
Exemplo:
---
title: "CICS sem Mistérios"
author: "Vagner Bellacosa"
published: 2026-07-10
updated: 2026-07-15
status: publicado
original_url: "https://eljefemidnightlunch.blogspot.com/..."
categories:
- Mainframe
- IBM Z
tags:
- cics
- cobol
- bms
- mainframe
seo_description: "Guia introdutório sobre CICS para programadores COBOL."
source: blogger
---
Essa área é chamada de frontmatter.
Depois vem o conteúdo:
# CICS sem Mistérios
## Introdução
O CICS é um monitor transacional...
O frontmatter transforma o texto em um registro estruturado.
É como a WORKING-STORAGE SECTION do artigo.
O corpo é a narrativa.
O frontmatter é a estrutura de dados.
12. Organização por pastas ou por tags?
Essa é uma pergunta clássica.
A melhor resposta é:
use os dois, mas não exagere.
Uma estrutura possível:
01-Artigos
Mainframe
IA
DevOps
Anime
Cultura Japonesa
Star Trek
Memórias
Dentro dos artigos, use tags mais específicas:
tags:
- cobol
- cics
- tutorial
- iniciante
- ibm-z
As pastas organizam grandes territórios.
As tags descrevem características.
Pense assim:
pasta é o setor da nave;
tag é a função do tripulante.
Um artigo pode estar na pasta Mainframe, mas ter tags:
cobol, cics, tutorial, performance, iniciante
13. Plugins essenciais do Obsidian
O Obsidian já é poderoso sem plugins.
Mas alguns recursos ampliam muito o sistema.
Dataview
Permite consultar notas como banco de dados.
Exemplo:
TABLE published, tags
FROM "01-Artigos"
WHERE contains(tags, "cobol")
SORT published DESC
Isso gera uma tabela com todos os artigos COBOL.
É quase um SQL para notas.
Para um programador COBOL, isso soa familiar.
Templater
Cria modelos de artigos.
Ao iniciar uma nova nota, ela pode nascer com:
título;
data;
autor;
estrutura;
seções;
campos de SEO;
checklist.
Omnisearch
Melhora a pesquisa em grandes acervos.
Tag Wrangler
Ajuda a renomear e consolidar tags.
QuickAdd
Automatiza criação de notas e fluxos.
Excalidraw
Permite criar diagramas.
Canvas
Ajuda a montar mapas visuais.
Git
Permite versionar o Vault.
14. Git: o SMF do seu conhecimento
O Git registra versões.
Você edita um artigo hoje.
Amanhã altera novamente.
Depois percebe que a versão anterior era melhor.
Com Git, você pode recuperar.
Exemplo:
git init
git add .
git commit -m "Importação inicial do Blogger"
Depois:
git add .
git commit -m "Revisão dos artigos COBOL"
Mais tarde:
git add .
git commit -m "Inclusão de backlinks entre CICS e Db2"
Cada commit é um checkpoint.
É como se seu Vault tivesse um histórico de mudanças semelhante a um log operacional.
O Git não substitui backup.
Mas adiciona rastreabilidade.
Regra de ouro:
Git registra mudanças. Backup protege contra perda física.
O ideal é usar os dois.
15. Como integrar inteligência artificial
A IA pode atuar em três níveis.
Nível 1 — Artigo individual
Você abre um texto e pede:
melhorar a clareza;
corrigir erros;
expandir conceitos;
adicionar exemplos;
criar FAQ;
gerar SEO;
sugerir título;
identificar informações desatualizadas;
criar links internos;
adaptar para iniciante.
Nível 2 — Conjunto de artigos
Você seleciona uma pasta e pergunta:
quais artigos estão duplicados?
quais podem virar uma série?
quais estão incompletos?
quais mencionam IBM z14 e precisam ser atualizados?
quais falam de CICS sem citar COMMAREA?
quais poderiam formar um curso?
Nível 3 — Todo o acervo
Aqui surge a verdadeira inteligência editorial.
Você pode perguntar:
“Mostre todos os textos que relacionam COBOL com DevOps.”
Ou:
“Quais artigos sobre IA mencionam governança, risco e segurança?”
Ou:
“Monte uma trilha de aprendizado para um iniciante usando apenas artigos existentes.”
Nesse momento, seu blog deixa de ser arquivo morto.
Ele se torna um sistema consultável.
16. IA local ou IA na nuvem?
Existem dois caminhos.
IA na nuvem
Exemplos:
ChatGPT;
Claude;
Gemini;
APIs comerciais.
Vantagens:
modelos mais avançados;
excelente qualidade;
pouca configuração.
Cuidados:
custos;
privacidade;
limite de tokens;
envio de conteúdo para serviços externos.
IA local
Exemplos:
Ollama;
Open WebUI;
AnythingLLM;
modelos locais.
Vantagens:
maior controle;
funcionamento offline;
privacidade;
integração local.
Desvantagens:
exige mais memória;
exige configuração;
modelos podem ser menos capazes;
processamento pode ser lento.
Uma estratégia híbrida costuma ser melhor.
Use IA local para:
busca;
classificação;
perguntas simples;
análise de grandes volumes.
Use modelos de nuvem para:
reescrita sofisticada;
criação de artigos;
revisão editorial;
síntese complexa.
17. O perigo das imagens externas
Muitos blogs antigos possuem imagens hospedadas em serviços externos.
O artigo pode conter:
<img src="https://algum-servidor.com/imagem.jpg">
Isso funciona enquanto o servidor existir.
Se o serviço desaparecer, a imagem quebra.
Esse fenômeno é chamado de link rot.
Durante a migração, o ideal é:
localizar todas as URLs de imagens;
baixar as imagens;
renomear os arquivos;
guardar em
02-Imagens;atualizar os links nos artigos;
registrar a URL original;
identificar imagens ausentes.
Exemplo:
02-Imagens
2026
cics-sem-misterios-01.jpg
cics-sem-misterios-02.png
No Markdown:
![[cics-sem-misterios-01.jpg]]
Ou, para compatibilidade externa:
18. Por que não converter diretamente para Xanga?
O WordPress possui diferentes importadores, incluindo formatos históricos.
Na tela mostrada, aparecia o importador Xanga.
Mas isso não significa que o Xanga seja a melhor rota.
Converter Blogger para Xanga apenas para importar no WordPress seria parecido com:
COBOL
↓
Assembler intermediário
↓
Java
↓
Aplicação final
Pode funcionar.
Mas cria etapas desnecessárias.
A rota mais limpa é:
Blogger Atom XML
↓
WordPress WXR
Ou:
Blogger Atom XML
↓
Markdown
↓
WordPress
O formato Xanga só faria sentido se o importador do WordPress aceitasse melhor aquele padrão e não houvesse alternativa.
Em geral, o formato WXR é mais adequado.
19. O WordPress WXR
WXR significa WordPress eXtended RSS.
É um XML com elementos como:
<item>
<title>CICS sem Mistérios</title>
<wp:post_date>2026-07-10 10:00:00</wp:post_date>
<content:encoded><![CDATA[
<p>Conteúdo...</p>
]]></content:encoded>
<wp:post_type>post</wp:post_type>
</item>
Ele pode carregar:
posts;
páginas;
categorias;
tags;
autores;
comentários;
campos personalizados;
datas;
status.
Por isso é o formato natural para migração ao WordPress.
20. Plano de ação prático
Fase 1 — Preservação
localizar o backup Atom correto;
copiar o arquivo original;
calcular hash;
guardar em dois locais;
validar o XML;
contar entradas.
Fase 2 — Inventário
contar posts;
contar páginas;
contar comentários;
listar tags;
listar categorias;
identificar imagens;
identificar URLs.
Fase 3 — Conversão
gerar Markdown;
gerar WordPress WXR;
gerar HTML;
gerar JSON;
gerar relatório de erros.
Fase 4 — Obsidian
criar Vault;
importar Markdown;
configurar anexos;
instalar plugins;
padronizar frontmatter;
criar templates.
Fase 5 — Organização
consolidar tags;
criar MOCs;
criar índices;
adicionar wikilinks;
identificar duplicações.
Fase 6 — IA
revisar artigos;
expandir conteúdo;
atualizar informações;
gerar SEO;
criar FAQ;
sugerir links internos.
Fase 7 — Publicação
testar importação em WordPress local;
revisar mídia;
revisar slugs;
configurar redirecionamentos;
publicar gradualmente.
21. MOCs: os mapas de conteúdo
MOC significa Map of Content.
É uma nota que funciona como índice temático.
Exemplo:
# MOC — COBOL
## Fundamentos
- [[História do COBOL]]
- [[Estrutura de um programa COBOL]]
- [[DIVISION]]
- [[SECTION]]
- [[PARAGRAPH]]
## Controle de fluxo
- [[PERFORM]]
- [[EVALUATE]]
- [[IF]]
- [[GO TO]]
- [[ALTER]]
## Arquivos
- [[QSAM]]
- [[VSAM]]
- [[ESDS]]
- [[KSDS]]
## Online
- [[CICS]]
- [[COMMAREA]]
- [[BMS]]
O MOC é como uma tabela de conteúdo viva.
Ele não precisa listar tudo automaticamente.
Pode ser editorial.
Você decide qual caminho o leitor deve seguir.
22. Curiosidades de bastidores
Curiosidade 1 — Markdown nasceu para ser simples
A ideia do Markdown é que o texto continue legível mesmo sem renderização.
Isso o torna ideal para preservação.
Curiosidade 2 — Wikilinks são antigos
O conceito de ligar documentos por referências existe desde os primeiros sistemas de hipertexto.
O Obsidian apenas tornou isso simples para arquivos locais.
Curiosidade 3 — Blogs envelhecem cronologicamente
Uma postagem excelente de 2013 pode ficar enterrada porque blogs priorizam data.
Uma wiki prioriza assunto.
Curiosidade 4 — Seu sitemap ainda tem valor
Mesmo sem trazer o conteúdo, ele pode ajudar a:
conferir se todas as URLs foram importadas;
descobrir páginas faltantes;
comparar o blog atual com o backup;
gerar mapa de redirecionamentos.
Curiosidade 5 — Seu arquivo mais importante não é o XML
O arquivo mais importante é o plano de preservação.
Um único XML sem cópias e sem validação continua sendo um ponto único de falha.
23. Easter egg da Frota Estelar
Em Star Trek, a nave Enterprise não é poderosa apenas por causa de seus motores.
Ela é poderosa porque possui:
sensores;
mapas;
registros;
redundância;
protocolos;
engenharia;
oficiais;
memória computacional;
capacidade de análise.
Seu blog também não se torna valioso apenas porque tem milhares de artigos.
Ele se torna poderoso quando esses artigos podem ser:
encontrados;
relacionados;
atualizados;
reutilizados;
versionados;
ensinados;
publicados;
preservados.
A Enterprise sem computador seria apenas uma estrutura metálica no espaço.
Um blog sem arquitetura de conhecimento é apenas uma sequência de páginas.
24. O que o programador COBOL pode aprender com tudo isso?
Muito.
Esse projeto ensina princípios clássicos de sistemas.
Separação entre dado e plataforma
O conteúdo não deve depender exclusivamente do Blogger ou WordPress.
Portabilidade
Markdown permite mover o conhecimento entre ferramentas.
Redundância
Backup em mais de um local.
Versionamento
Git registra mudanças.
Metadados
Frontmatter descreve o conteúdo.
Integridade
Validação evita perda silenciosa.
Relacionamentos
Backlinks revelam dependências.
Indexação
Pesquisa full text encontra rapidamente informações.
Automação
Scripts podem converter, classificar e enriquecer dados.
Governança
É necessário saber o que é original, revisado, publicado ou obsoleto.
Perceba: estamos falando de conteúdo, mas os fundamentos são os mesmos usados em sistemas corporativos.
25. A arquitetura final
Ao término da missão, a arquitetura pode ser:
BLOGGER
|
v
BACKUP ATOM XML
|
---------------------------
| | |
v v v
Markdown WXR JSON
|
v
OBSIDIAN KNOWLEDGE VAULT
|
--------------------------
| | | |
v v v v
Busca Backlinks Git IA
| | | |
--------------------------
|
v
CONTEÚDO ENRIQUECIDO
|
--------------------
| | |
v v v
WordPress Blogger Livros
|
v
NOVA PRESENÇA DIGITAL
Essa é a arquitetura da El Jefe Midnight Lunch Wiki.
Conclusão — O blog não foi baixado; foi resgatado
Existe uma enorme diferença entre salvar arquivos e preservar conhecimento.
Salvar arquivos é copiar.
Preservar conhecimento é organizar, validar, relacionar, documentar e garantir que ele continue utilizável.
O Blogger foi o porto original.
O WordPress pode ser o próximo planeta.
Mas o Obsidian será a nave.
O Markdown será o formato universal.
O Git será o registro de bordo.
A IA será o oficial científico.
Os backlinks serão os corredores entre os decks.
O Graph View será o mapa estelar.
E cada artigo será um tripulante carregando uma parte da missão.
Para um programador COBOL iniciante, esta jornada oferece uma lição valiosa:
sistemas duradouros não sobrevivem apenas porque funcionam. Eles sobrevivem porque seus dados, regras, dependências e histórias são preservados.
O seu blog não é somente um conjunto de postagens antigas.
É um sistema de conhecimento acumulado.
É documentação.
É memória.
É história técnica.
É cultura.
É experiência.
É legado.
E legado não deve ficar preso a uma única plataforma.
Na ponte de comando da El Jefe Midnight Lunch Wiki, a ordem final é simples:
CAPITÃO: Estado do acervo?
SPOCK: Conteúdo preservado, indexado e relacionado.
SCOTTY: Backups redundantes e versionamento ativos.
DATA: Metadados normalizados.
WORF: Links quebrados identificados.
COMPUTADOR: Obsidian Vault online.
CAPITÃO: Curso definido.
Computador, iniciar conversão.
E em algum diretório silencioso do Windows, entre arquivos Markdown, backlinks e diagramas, um velho artigo COBOL de 2013 desperta novamente.
Não como relíquia.
Mas como parte viva de uma nova galáxia de conhecimento.
Sem comentários:
Enviar um comentário