Blog do Dunossauro

Meu ambiente/setup de programação em 2026

mail@dunossauro.com (dunossauro) — Mon, 19 Jan 2026 19:26:17 -0300

Thumbnail usada para a live no youtube!

O objetivo desse post (que também é um roteiro de uma live de Python) é contar um pouco sobre o setup que tenho usado atualmente. Tanto para trabalhar quanto para codar no meu tempo livre. A única intenção é mostrar ferramentas que talvez ainda não façam parte do seu dia a dia.

Nesse momento ele é um material de apoio em tópicos pra live. Em alguns dias vou ajustando a fluidez do texto e ele vira um post de verdade :)

Quero dividir o conteúdo em frentes distintas, para ficar mais fácil de encontrar e enumerar.

Ah… só mais uma coisa… Quando falo em setup, estou falando da parte lógica: sistema, ferramentas, automações e fluxo de trabalho, não de hardware.

# Tópicos

Ambiente geral: coisas relacionadas às minhas configurações do ambiente e ferramentas que me auxiliam
Ambiente Python: coisas que instalo globalmente com Python e também uso para gerenciar o python
Ferramental de projetos: coisas que uso e não necessariamente são dos códigos de produção (linters, task runners, …)
Escolhas para programar: minhas ferramentas de escolha no código, bibliotecas, frameworks, etc.

# 1. Ambiente geral

Bom, não é tão difícil ver que tenho usado GNU/Linux em todos os vídeos desse canal. Atualmente, uso EndeavourOS variando entre dois ambientes gráficos. I3WM e Qtile e meu tema para todas as coisas é o Catppuccin Mocha.

captura de tela de todo o tema convergindo no sistema

Bom… vamos às coisas importantes para programar:

Ferramenta	Qual?	Pra quê?
Editor de texto	GNU/Emacs	Programar, escrever, organizar a vida e basicamente viver dentro dele
Editor de texto (2)	Kate	Quando, por algum motivo, quero escrever em outro lugar ou no win
Shell	GNU/Bash	Shell padrão do sistema e scripts mais portáveis
Shell (2)	Xonsh	Shell interativo usando Python como linguagem principal
Terminal	Terminator	Emulador de terminal com splits, profiles e workflows complexos
Ambiente limpo	LiMa	Criar VMs leves para testar ambientes sem poluir o sistema
Containers	Podman	Gerenciar containers sem daemon e compatível com Docker
dotfiles	dotdrop	Gerenciar e versionar dotfiles de forma reproduzível
Provisionamento	Ansible	Automatizar setup de máquinas e ambientes
Documentação offline	Zeal	Consultar a documentação sem a necessidade de abrir o browser

## Coisas interessantes no editor de texto

É onde acontecem as partes mais importantes do meu fluxo de trabalho. Onde basicamente escrevo código, as aulas, slides e as postagens no blog. Talvez, uma das coisas mais importantes para o nosso contexto, seja um pouco do que uso para programar aqui.

### Servidores de linguagem

Para me acompanhar durante a escrita de texto e de código, tenho usado alguns servidores de linguagem. Uma forma de ter autocomplete + correções durante a escrita.

Para gerenciar os servidores de linguagem, uso o mason-registry via mason.el¹ e coloco o diretório de downloads dele no PATH para poder usar nos dois editores.

Não tenho conectado diretamente nos servidores, pois em alguns casos gosto de usar mais de um LSP para uma mesma linguagem, o que nem sempre é possível em um mesmo editor. Por isso uso o rassumfrassum.

flowchart LR
Eglot <--> rassumfrassum
rassumfrassum <--> python
rassumfrassum <--> markdown
subgraph python
lsp-A
lsp-B
lsp-C
end
subgraph markdown
lsp-D
lsp-E
end

Ele funciona como um servidor de “proxy”, repassando as requisições para os servidores configurados e concatenando as respostas, que são devolvidas de forma síncrona ao editor.

# .config/rassumfrassum/markdown.py
def servers():
 return [
 ['marksman'],
 ['ltex-ls-plus']
 ]

Isso me permite tratar LSPs como ferramentas especializadas, em vez de depender de um único servidor “generalista” por linguagem.

Para Python tenho usado:

zuban: faz checagem de tipos, goto, referências e rename
ruff: busca por erros de estilo de código
typos: levanta erros gramaticais (inglês) [uso ele em todos os modos de programação]

Captura de tela do Emacs mostrando erros de código via LSPs

Para Markdown (o que uso para os slides, blog e textos em geral):

marksman: cria referências entre arquivos e goto
ltex-ls-plus: checagem gramatical via languagetool

Captura de tela do Emacs mostrando erros de grafia no modo markdown

Esse assunto por ele mesmo é tão complexo que merecia um blog post só pra ele. Será?

### Documentação

Geralmente, quando estou programando, abrir o browser, digitar na busca, ir até a página, buscar pelo que quero é trabalhoso. Aqui entra o Zeal em conjunto com meu editor.

M+x zeal-at-point, se eu tiver a documentação, ele vai até o ponto e me mostra do que tem lá. O LSP me mostra a docstring, mas às vezes preciso de mais do que isso. Preciso realmente acessar a documentação.

Captura de tela do Emacs direcionando a documentação ao Zeal

Isso reduz bastante a troca de contexto (context-switching) durante a programação, o que, para mim, faz muita diferença no fluxo. Essas trocas fazem meu foco ir na lua e voltar. hahaha (mesmo ainda estando fora do tema…)

### Extra: Citações

Outra coisa que me ajuda muito no editor, nessa de ficar mudando de lá pra cá, é o Citar, um pacote do Emacs, para citações da minha coleção bibliográfica no Zotero. Quando preciso referenciar algo, com um pequeno comando, insiro a referência lá.

PS: não pense em algo como ABNT ou formatação acadêmica. A ideia aqui é simplesmente não precisar lembrar nomes de papers, subtítulos de livros, PEPs por nome ou número, ou qualquer outro detalhe que quebra o fluxo de escrita.

## Reprodução do ambiente

Umas das coisas que tenho em mente e que faz parte integral do meu ambiente e a “reprodutibilidade” dele. Deixo essas dicas aqui, pois quem está começando pode não ter esse domínio em construir e manter o próprio ambiente.

### Dotfiles

Dotfiles são arquivos de configuração, que guardam preferências e ajustes das ferramentas que você usa no dia a dia, como terminal, editor de código e Git. Para quem está começando, eles costumam passar despercebidos, mas fazem muita diferença na produtividade e na consistência do ambiente como um todo, não somente de desenvolvimento.

Uma “barra” pesada que a gente enfrenta de tempos em tempos é ter de transferir nossas configurações de um “computador” para outro. Veja que coloquei entre aspas, porque às vezes o computador é o mesmo, mas tivemos que formatar por algum motivo. Ou vamos mudar de pc, ou temos que usar um pc nosso e um do trabalho… São inúmeras possibilidades aqui.

Por exemplo, eu uso GNU/Bash como shell. E ele tem um arquivo base de configuração, o .bashrc. Nesse arquivo, posso colocar variáveis de ambiente, alias para comandos, setar algumas configurações, etc. Se eu perder esse arquivo por qualquer motivo que seja, eu vou ter que reconfigurar tudo de novo. Correndo o risco de esquecer algo ou até mesmo não conseguir reproduzir a configuração anterior. Vezes porque procurei uma coisa na internet, “copiei e colei” e nunca mais vou achar o link, ou porque alguém me ajudou com uma configuração e vou ter que aporrinhar essa pessoa de novo.

Uma das técnicas para fugir disso é versionar todos esses arquivos de configuração em um repositório (por exemplo, no Git) para que você possa recriar seu ambiente facilmente em outra máquina, evitar perder configurações importantes e acompanhar mudanças ao longo do tempo.

Um dos problemas de fazer isso é ter que manter os arquivos sempre sincronizados com o repositório. Eu fui futricando na configuração e esqueci de adicionar ao repositório e fazer isso muitas vezes, o tempo todo, é chato. Aí entra uma ferramenta que uso sempre, feita em Python, o dotdrop. Com um simples comando como dotdrop compare ele me diz se meus arquivos estão diferentes do repositório e com dotdrop update ele copia suas configurações atuais para o repositório. Se estiver em outro ambiente, pode rodar um dotdrop install e ele vai colocar todos os seus arquivos de configuração do repositório na máquina.

Caso queira ver meus dotfiles, eles estão aqui: https://dunossauro.com/dotfiles.

### Provisionamento

Além de manter as configurações, claro, precisamos instalar os softwares que usamos nessa nova instalação. É aí que entra o provisionamento.

Provisionamento é o processo de preparar automaticamente um ambiente, instalando pacotes, ferramentas e configurações necessárias para trabalhar ou executar uma aplicação. Para quem está começando, isso ajuda a evitar configurações manuais repetitivas e erros difíceis de reproduzir. Ao versionar esse processo, você registra como o ambiente deve ser montado, possibilitando recriá-lo em outra máquina com poucos comandos.

Tenho usado o Ansible para essa função. Escrevemos arquivos declarativos (em yaml) descrevendo todos os softwares que queremos instalar e comandos que queremos executar:

---
- name: Exemplo de configuração
 hosts: localhost

 tasks:
 - name: Instalação GNU/Emacs
 become: yes
 package:
 name: emacs
 state: present

 - name: Instalação terminator
 become: yes
 package:
 name: terminator
 state: present

 - name: Cópia dotfiles
 git:
 repo: https://codeberg.org/dunossauro/dotfiles.git
 dest: ~/git/dotfiles

 - name: configura dotfiles
 shell: dotdrop --cfg=~/git/dotfiles/config.yaml install -f
 # ...

Fizemos uma live de ansible no passado https://ansible.dunossauro.com pode ser que ela te ajude a montar sua configuração.

### Extra: Ambiente limpo

Uma das coisas que me fazia passar um perrengue antigamente era ter um “ambiente limpo” para testar as coisas. Seja porque eu precisava reproduzir um erro de alguém em um sistema que é diferente do meu. Outra distro linux, outro sistema operacional, outro shell. Ou então, porque eu queria usar algo que claramente mudaria minhas configurações do ambiente. Coisas como trocar o sistema de notificação ou trocar toda uma configuração do meu editor… Coisas desse gênero. Ou ainda, testar como meu código performaria em produção, que geralmente tem uma máquina limpa.

Nesse caso, algumas ferramentas me ajudam muito:

QEMU + KVM: virtualização completa quando preciso testar sistemas operacionais ou comportamentos mais próximos do hardware real.
LiMa: máquinas Linux leves e rápidas para testes pontuais de ambiente e reprodução de problemas (usa QEMU como base)
Vagrant + libvirt: ambientes completos e reproduzíveis a partir de imagens prontas, úteis para testar outras distros ou sistemas.
Podman: containers para isolar serviços e dependências durante o desenvolvimento, sem necessidade de uma VM inteira.

Quando uso cada coisa? Se preciso de uma máquina simples, mas completa, geralmente uso o LiMa (que usa como base o QEMU). Se preciso rodar outro sistema, como Windows, costumo baixar essas imagens com Vagrant via libvirt, que baixa uma imagem completa do sistema pronta para ser executada.

Agora, durante o desenvolvimento, se preciso subir um banco de dados, um cache, ou mesmo isolar a minha aplicação, uso containers via podman.

No fim das contas, cada ferramenta resolve um tipo de problema diferente. O importante, para mim, não é escolher “a melhor”, mas saber quando usar cada uma.

Sobre o LiMa, já conversei sobre esse tópico nesse blog post

# 2. Ambiente Python

Bom, como somos a live de Python, nada mais óbvio que programamos Python… Então, vamos ao meu ambiente global de Python. Por global aqui, entenda que o Python é como parte do meu ambiente e ferramentas que uso no sistema, não em projetos.

## Trabalhando com versões diferentes do Python

Um dos pontos principais de usar GNU/Linux e programar Python é entender a máxima primordial do universo Não, em hipótese alguma, use o Python do sistema. Existem várias formas de lidar com isso. A forma que prefiro gerenciar é via Pyenv.

Embora eu tenha no sistema gerenciadores de projeto que também fazem isso, como Poetry, PDM e UV, pensando no meu sistema, gosto de testar flags de compilação do python em diferentes versões e mantê-las no meu sistema. Por exemplo, uma com o JIT habilitado, outra com o JIT em modo interpreter, uma free thread, … Embora os gerenciadores de projeto possam manipular versões, eles usam pre-compilações e eu gosto de futricar exatamente nesse lugar.

## Ferramentas em Python

Para evitar instalar coisas globalmente, ou no meu shim do pyenv, eu uso o pipx. O Pipx é basicamente uma ferramenta para instalar/executar aplicações em python que são disponibilizadas via pypi em um ambiente virtual isolado e que pode ser acessado via PATH. Ele faz esse trabalho sozinho. Além de também ter comandos interessantes como pipx upgrade-all. Que atualiza toda a sua base de aplicações.

Algumas coisas que tenho instaladas por lá:

Gerenciadores de projeto: Poetry, PDM, Hatch, UV, Briefcase … Cada projeto por onde a gente passa acaba deixando sua marca no sistema
Ferramentas TUI:
- Harlequin: um cliente para banco de dados SQL
- Posting: um cliente de APIs
- toolong: uma forma de ler, buscar e organizar arquivos. (uso para ler logs)
Foxdot e Sardine: porque fazer música com programação é incrível!
Ferramentas de CLI:
- pepotron: ferramenta que abre as peps pelo número
- segno: gerador de QR codes
- doc2dash: conversor de mkdocs/sphinx para o formato do zeal
- httpie: alternativa para curl
- rembg: removedor de fundo de images

Muitas dessas ferramentas eu poderia instalar pelo próprio gerenciador de pacotes da minha distribuição. Mas acho que a proximidade com a linguagem me faz instalar as coisas por aqui. hahaha

# 3. Ferramental de projetos

Agora falamos um pouco sobre meu ambiente em geral. Chegou a hora de falar sobre os projetos em si. Como tenho organizado e criado os ambientes dos meus projetos.

Vale a pena dizer que, talvez, somente talvez, essa gere mais controvérsias por aqui. Como projetos costumam envolver mais pessoas do que somente eu. Umas coisas gosto, outras nem tanto. Mas… vamos lá.

PS: Muitas dessas configurações em ação podem ser vistas em conjunto no curso de FastAPI.

## Além do código

Muitas decisões sobre um projeto são tomadas fora do código. Como a escolha do ferramental que vai gerir esse código. Atualmente, uso o poetry como gerenciador de projeto e de versões do Python nos projetos. E junto da flexibilidade do pyproject tenho combinado algumas ferramentas:

ruff: analisador estático de código. Para procurar por “erros”, em geral. Também formata o código.
taskipy: um executor de tasks complementar. Para coisas como task test, task lint
poethepoet: o mesmo que o taskipy, mas uso quando as coisas precisam ser mais bem “azeitadas”
zuban: checador de tipos, uma alternativa ao mypy, mas com mais funcionalidades e mais rápido.
darker: Ferramenta para formatação de código que aplica as coisas somente aos diffs do git. Ou seja, somente no que alterei, sem formatar lugares que não têm relação nenhuma com o código atual.

Também temos aquelas coisas que fazem parte do projeto, mas não estão alinhadas com o pyproject:

prek: Uma ferramenta que gerencia hooks de pre-commits no git. Ajuda a validar formatação de arquivos, linhas em branco, ver se não tem um teste quebrando etc.
pre-commit: A ferramenta na qual o prek foi baseada, em alguns projetos ela ainda está lá.
invoke: Invoke também é um task runner, como o taskipy e o poethepoet, mas ele é programável. Escrevo em python as devs e ele cria automaticamente as tasks em um cli.
typos: analisador estático que busca por erros de digitação em inglês.
tox: ferramenta para executar testes (um test runner) que permite executar os testes em N versões do python e de bibliotecas.

Nem todos os projetos usam todas essas ferramentas, inclusive algumas fazem o mesmo ou beiram as responsabilidades de outras. Mas, é o que uso em projetos diversos. Algumas delas são repetidas com o que uso no editor, mas executar no pre-commit ou em CI é muito importante também.

O editor ajuda enquanto escrevo, o pre-commit quando esqueço xD

## Containers

Para criar e gerir meus containers durante o desenvolvimento, tenho usado podman e podman-compose.

Para gerir as dependências dos containers em testes de aplicações, uso o testcontainers

Por que não docker? Às vezes subo ele no LiMa, mas as licenças do docker e o fato de não ser mais “igual em todos os sistemas”, eu tenho evitado.

Outra coisa relacionada a isso é que ando testando as imagens da chainguard nos meus projetinhos de casa e que aprendi recentemente no trabalho² :). São imagens menores, pensadas para produção e com foco em segurança (menos problemas relacionados a CVEs).

# 4. Escolhas para programar

Até aqui, falei bastante de ambiente, ferramentas e processos. Agora chegamos ao ponto onde tudo isso se encontra: o código em si. Aqui estão algumas das escolhas que tenho feito quando estou programando projetos em Python hoje.

Vale reforçar: não são escolhas universais, nem definitivas. São ferramentas que têm funcionado bem no meu fluxo atual e que resolvem problemas que aparecem no meu dia a dia.

## Aplicações de terminal

Para CLIs, tenho usado Cyclopts com Rich. O cyclopts me dá parsing de argumentos simples, bem tipado e com pouco “boilerplate”. O Rich entra para melhorar a experiência no terminal. Cores, tabelas, blocos, texto rico, barras de progresso.

Outra coisa que uso menos do que gostaria, mas tenho usado, é o inquirerpy. Uma biblioteca que fornece inputs dinâmicos. Se a ferramenta vive no terminal, ela precisa ser agradável de usar.

Mais uma coisa que uso menos do que deveria é o textual, uma biblioteca para construir TUIs. Proporcionando uma experiência completamente diferente, suporte a mouse, imagens, async, … (pra quem usa ferramentas beeware para GUIs, quase tudo é suportado via Toga).

## Aplicações web

Para aplicações web, tenho gostado bastante de usar o FastAPI, principalmente pela simplicidade. Ele me deixa focar no que importa sem brigar com o framework. Apesar disso, confesso que de tempos em tempos acabo namorando o Quart, o flask-style, vive dentro de mim xD

Para ORM, falem o que falarem, o SQLAlchemy continua sendo minha escolha. Como já disse o criador do Peewee, ele é o estado da arte dos ORMs em Python. Não é o mais simples, mas é extremamente flexível e me permite crescer o projeto sem precisar trocar tudo depois.

Quando preciso renderizar HTML, costumo usar o Jinja. Não é algo que aparece em todo projeto, mas quando aparece, ele resolve bem o problema sem adicionar complexidade desnecessária.

Do outro lado da web, como cliente HTTP, tenho usado o HTTPX, principalmente pela API consistente e pelo suporte a async quando faz sentido.

## Testes

Para testes, uso principalmente o pytest, que combina simplicidade e versatilidade. Gosto especialmente da parametrização e dos markers, que tornam os testes mais expressivos e fáceis de organizar. Além disso, ele suporta testes escritos com o estilo clássico do unittest, facilitando migrar ou integrar código antigo.

Quando preciso de paralelismo ou mocks, adiciono pytest-xdist e pytest-mock. Para gerar dados falsos e cenários de teste realistas, uso Faker e factory_boy.

Para testes baseados em propriedades, uso Hypothesis, que explora automaticamente combinações de entradas para encontrar casos extremos, e, quando estou testando APIs, uso Schemathesis em conjunto com ele, garantindo que minhas rotas e esquemas OpenAPI se comportem como esperado. Ambos em conjunto com seus plugins do pytest.

Quando preciso mockar requisições HTTP de forma controlada, recorro ao respx, já que quase sempre uso o HTTPX.

Essa combinação cobre bem desde testes unitários simples até cenários de integração e APIs mais complexas, mantendo tudo previsível e fácil de manter.

## Outras ferramentas

Algumas ferramentas acabam aparecendo em praticamente todo projeto:

loguru: para logging com menos atrito inicial
ipdb: para debug interativo quando preciso parar e entender o estado do programa
mkdocs: para documentação
towncrier: para manter changelogs organizados ao longo do tempo

São ferramentas pequenas, mas que ajudam bastante a manter o projeto saudável no médio e longo prazo.

# Pequena conclusão

Ao longo desse post, mostrei meu setup em 2026: desde o sistema operacional, passando por editores, shell, ferramentas globais de Python, até o ferramental que uso nos projetos e minhas escolhas de bibliotecas. Para ser bem sincero, dizer que esse setup é o de “2026” é muito estranho. Por que, provavelmente em algumas semanas, algumas coisas vão acabar mudando por aqui.

Construir um ambiente é uma coisa que leva a vida toda, é praticamente um passatempo. A gente experimenta coisas novas sempre e vai trocando, às vezes volta pra antigas e tá tudo bem.

Meu ponto aqui está longe de ser uma “verdade” como “o que é certo”, não tem FOMO. O objetivo é apresentar como as coisas estão agora, como eu me sinto confortável com meu ambiente e apresentar um monte de coisas que você já poderia conhecer, ou até descobrir coisas novas e testar no seu fluxo de trabalho.

Cada ferramenta tem um propósito: algumas para facilitar a escrita, outras para reduzir context-switching, algumas para garantir consistência e qualidade, e outras só para se divertir um pouco (sim, tocar música com Python é válido).

No fim das contas, o setup ideal é aquele que some do caminho, que deixa você focar no que você quer construir, sem se perder em configurações e ferramentas. Embora isso pareça impossível, com esse tanto de coisas. hahaha

Espero que isso ajude você a pensar com mais carinho em tudo que usa por aí. Um abraço!

Ah… Antes de ir, me conta. O que tem usado por aí?

Dica incrível do Krisque ↩︎
Dica do Luiz e do Abreu ↩︎

Forward de E-mail

mail@dunossauro.com (dunossauro) — Sun, 11 Jan 2026 13:27:40 -0300

No meu pequeno degoogle de cada dia, tenho feito alguns testes em diferentes empresas de e-mail. Testei coisas como o tuta, o proton, o zoho, o fast.¹

O grande problema disso é que testar significa que vou usar essa conta de e-mail por algum tempo. Mas é praticamente impossível migrar de contas de e-mail quando as pessoas têm a porcaria da minha conta de e-mail vinculada a uma empresa. Como faço pra quem tem meu endereço na empresa x “atualizar” a lista dele para me mandar na empresa Y?

Tudo bem… alguém vai dizer que eu poderia enviar meus e-mails automaticamente de uma conta pra outra. E de fato eu poderia. Mas, no final das contas, tudo fica inviável. Principalmente se eu cometer o erro de cadastrar meu e-mail em algum serviço e tiver que lembrar em qual porcaria de e-mail criei a conta lá.

Bom… eu já tenho um domínio, esse que vos fala, o dunossauro.com. Por que não me aproveitar disso? E, de fato, eu posso. Assim, sempre que alguém precisar falar comigo, eu poderia enviar meu e-mail pessoal, usando meu domínio. Uma coisa que provavelmente não vai mudar².

Comecei a procurar algumas alternativas para fazer o redirecionamento do meu domínio para qualquer e-mail X que eu esteja usando. Nisso acabei encontrando o forwardemail. Uma solução gratuita para encaminhamento, de código aberto. E que, se quiser, pagar também pode³!

Que me permite, via DNS, onde quer que se encontre o meu domínio, redirecionar o tráfego para onde quer que eu esteja usando o e-mail. Com uma belíssima solução:

Name	Type	Priority	Answer / Value
@	MX	10	mx1.forwardemail.net
@	MX	10	mx2.forwardemail.net
@	TXT		forward-email=seuemail@onde.quiser.com

Pronto! Agora, posso usar qualquer serviço de e-mail sem me preocupar em passar meu endereço de e-mail nesse serviço.

Uma das coisas legais nisso é que posso ter uma quantidade infinita alias de e-mails malucos e redirecionar todos para o mesmo.

span@dunossauro.com
aplicaoxpto@dunossauro.com
email@dunossauro.com

Mas é isso… problema resolvido. Se você também tiver um domínio, pode ser bastante interessante. Por alguns motivos:

Ninguém precisa saber onde você hospeda seu e-mail
Você pode mudar de provedor quando quiser
Pode criar alias malucos para qualquer e-mail maluco que tiver na cabeça
É muito mais legal passar o e-mail do seu domínio do que fazer propaganda pra uma empresa qualquer :)

Sim… eu não me odeio o suficiente, ainda, pra fazer hosting do meu próprio e-mail. ↩︎
Claro, eu poderia parar de pagar o domínio e tudo isso vir por água abaixo. Mas até então, qualquer domínio de empresa poderia cair também. ↩︎
O que pode acontecer no futuro se eu quiser também responder com emails do dunossauro.com ↩︎

Entre o sagrado e o profano!

mail@dunossauro.com (dunossauro) — Sun, 14 Dec 2025 12:52:54 -0300

Dei uma sumida, eu sei… Esse mês foi foda. Em diversos aspectos. Escrever esse texto é uma forma de tentar organizar os meus pensamentos da forma mais aberta possível…

Estamos há um mês sem Lives de Python, ao mesmo tempo em que essa semana fez um mês que voltei a trabalhar formalmente. Essas coisas estão relacionadas? Obviamente sim, mas não da forma em que parece mais evidente.

# O balde furado

Qualquer pessoa que se envolva com algo relacionado a “““educação”””, sabe que esse é um assunto delicado. E esperar qualquer tipo de retorno financeiro sobre isso não é uma coisa sã. Claro, você pode esperar… Mas quando você alinha isso à ética, só se você for um professor universitário com anos de estrada. Caso contrário… tá… você entendeu… Não estou dizendo que não existem pessoas éticas vendendo conteúdo, elas existem. Mas… na grande parte do tempo, você sabe…

Tenho um ideal de que as coisas devem ser gratuitas ao consumo, você pode discordar e entendo vários pontos sobre isso. Mas, pra mim, quando eu olho o dunossauro do passado, se algo custasse 20 conto, ele não poderia pagar. E tudo que eu faço tem isso por trás. Você colabora se quiser e, claro, se puder. Por isso temos a campanha de financiamento coletivo.

Mas isso tem dois lados que não combinam entre si. De um lado, o belo ideal sagrado que me move, do outro, as contas a pagar. O que me coloca sempre no limite de continuar fazendo, mas quando acontece qualquer imprevisto… Bom, os boletos não param, o aluguel não para, a saúde não é a mesma todo mês.

Ano passado, mais ou menos nessa época, tive o maior imprevisto de todos os tempos. Ele me cortou de muitas formas. A financeira foi grande, mas acredito que tenha sido a menor. Seguido disso, tive o devastador de qualquer encomia que ainda me restava, um canal… Como dentistas são caros… E ainda me sobraram os sisos!

# Uma jornada pela live de python em 2025

Dito tudo isso, sou um escravo do youtube. Sim… Se você é uma pessoa minimamente informada, vivendo no mundo real, sabe que depender de plataformas é o PIOR negócio que você pode fazer na vida. Nesse último ano, as coisas foram caindo, caindo, caindo…

Views diárias entre 24 e 25

Nesse gráfico, você pode ver no eixo X todo o ano de 2024 e o de 2025 (até a data de hoje). Por mais incrível que pareça, o ano de 2024 tinha sido o pior ano de todos, desde que comecei a me dedicar exclusivamente a isso. Mas, perto de 2025 ele parece incrivelmente bom.

É tão óbvio quanto parece, as pessoas não assistiram às lives de 2025.

Views semanais sobrepostas de 24 e 25

O pico da semana mais vista em 2025 (azul) é menor que a média de 2024 (roxo). E sim… isso é assustador, partindo do ponto da dependência exclusiva de renda vindo disso. Isso contando com o fato de eu não ter feito lives em nov e dezembro de 2024, mas… já falei sobre isso…

Com isso, precisei parar para pensar sobre esses dados. Alguma ação minha resultou nesses dados? Foram os temas? Será que fiz algo deplorável na internet? Todo mundo agora só quer IA?

## Analisando os temas de 2025

Testes: falamos sobre randomização. Faker, factory-boy e hypotesis.
Arquitetura: padrões de projeto (prototype), arquitetura de eventos, arquitetura de microkernel, SGI, módulos
Python puro: desempacotamento, gerenciadores de contexto, ifs, módulos, 3.14
Ferramentas: changelogs com towncrier
Tradução: duas lives sobre i18n
Segunda edição do curso de FastAPI

As lives com pessoas que vieram como convidadas no canal não contam nessa análise.

Acredito que nada esteja muito fora da realidade aqui. São temáticas “normais” no canal. Mas, alguma coisa errada aconteceu e não consigo entender. A única live de 2025 entre as 10 mais vistas do meu canal é a live do 3.14 e é uma live de outubro. Logo… Algo de errado não está certo. Caso você esteja se perguntando qual a segunda live mais vista desse ano, a de arquitetura de eventos com FastStream, na décima oitava posição. Seguida pela de módulos na décima nona.

Embora os temas não estejam fora do normal, a interação das pessoas caiu vertiginosamente esse ano. De forma geral, só uma live deu errado. A segunda parte de i18n é a live que tem menos views de toda a história do canal.

Acredito que a segunda apresentação do curso de FastAPI, por mais coisas que tenham sido adicionadas e melhoradas, também não tenha sido uma boa jogada, ao nível de youtube. Claro, eu me cobrei intensamente por isso e foi importante ter acontecido de fato.

## Sobre a campanha de financiamento coletivo

Junto a isso, a campanha no apoia-se, o qual é o único dinheiro “fixo” que posso contar. É a certeza de que eu vou conseguir pagar o aluguel e as contas básicas caiu 723 reais mensais entre janeiro e dezembro. Começamos o ano com 2.669 e atualmente temos 1.937. Mesmo sem saber o quanto eu pago de aluguel, você deve imaginar que a coisa ficou complicada…

## Mas por que essa pausa?

Por mais incrível que pareça, a pausa nem tem muita relação com os números assustadores. Claro, eles me deixam MEGA ansioso? Sim… Mas, o meu problema real foram duas lives quase que consecutivas que deram errado. Quem acompanha as coisas mais de perto, tipo diariamente na twitch, onde faço stream preparando material, acompanhou a saga do “Object storage” ou a “live de minio”

O tema simplesmente não aconteceu. Fui andando, escrevi sobre, os slides estavam andando, as referências. Mas, quando pegamos o minio, ele está tão capado que decidi de última hora fazer outro tema, pra dar tempo de estudar outros storages. No meio disso, eu me apressei pra fazer outra live na mesma semana.

Nas semanas seguintes, eu sentei a bunda pra fazer um “tacadão” sobre NoSQL e a live não deu certo também. Nessa semana, eu não consegui preparar outra live às pressas. A ansiedade bateu forte, fiquei em “posição fetal” por uns dois dias. Acho que minha cabeça estava juntando tudo que contei aqui e o gatilho foi o tema não ter dado certo.

Resolvi que precisava dar uma repensada nas coisas. Conversamos sobre isso no grupo da live no telegram.

# Algo tinha (ou tem) que ser feito

Bom… no meio dessa confusão, era extremamente necessário pagar as contas. As dores de dente intermináveis, a minha reserva de emergência tinha menos de 2.000 reais. Me vi com duas opções: voltar para um emprego formal ou fazer outra grande campanha de financiamento, como a do curso de FastAPI.

Pensei muito sobre isso. Mas, MUITO MESMO. A campanha anterior não tinha sido muito boa pra minha saúde mental. Mas… o que é saúde mental perto de não conseguir pagar as contas?

Eu até pensei no tema do curso novo, na verdade, foi uma sugestão do Renan Santos. Um “pytest do zero”. Nos mesmos moldes do curso de FastAPI, mas com foco em ensinar testes. Acredito que no futuro isso possa rolar ainda. Até porque aprendi TANTA coisa do que não fazer no material de FastAPI, que acredito que tudo seria mais fácil. Mas, acho que ainda não é a hora de passar por isso de novo. Embora eu tenha esboçado isso aqui, talvez no futuro a gente toque isso.

No meio disso, acabei recebendo uma proposta legal de emprego. Montar um time de engenharia de qualidade em uma empresa brasileira, com produtos para o público brasileiro. O desafio era tão interessante que provavelmente eu teria aceitado mesmo que não estivesse nessa “pindaíba”. Um salário legal, formar um time legal… Por que não? (isso parece que tem tudo pra virar outro post)

## A volta das lives

Agora que posso me dar ao luxo de não tentar acertar todas as semanas, quero fazer alguns testes em 2026. Na realidade, quero fazer exatamente 3 teses durante os 4/5 primeiros meses do ano. Voltar inicialmente quinzenalmente e depois retomar o ritmo.

Pelo meu conhecimento limitado no analytics do youtube, parece que o maior impacto que temos atualmente é a “falta de pessoas ao vivo”. Isso tem impactado diretamente no desempenho dos VODs¹. O vídeo chega com uma performance comprometida do ao vivo e tende a ser menos recomendado (taxa de impressões menor, por consequência, taxa de cliques menor).

Com isso, quero fazer uma coisa que me pedem há anos, fazer mais cedo. As lives ficaram às 22:00 porque eu chegava das aulas do mestrado às 20:00 e precisava comer algo correndo. Isso não acontece mais há anos, mas o horário continuou. Então, meu primeiro teste vai ser fazer às 21:00. Sei que ainda pode parecer tarde. Mas algo me diz que acabar às 23 é melhor que às 00.

Como um segundo teste, depois do primeiro, quero diminuir um pouco o tempo das lives. Normalmente elas duram duas horas, quero tentar fazer uma hora e meia. Tentar correr um pouco mais na abertura (os slides padrões de todas as lives) e aproveitar melhor o tempo. O que fariam as lives acabarem às 22:30. Bom… quem precisa dormir cedo, consegue acompanhar melhor do que acabar às 00.

E no terceiro teste, quero elencar melhor os temas. Acho que vou montar um formulário para ter uma base do que as pessoas inscritas no canal gostariam de me ver falando (já sei que vão pedir toneladas de IA, mas não vou ceder xD). E com essas sugestões, montar planejamentos que tenham somente uma live mensal escolhida por mim, até porque não sou de ferro.

Com isso, pretendo voltar com as lives no dia 05/01 com uma live de pergunte o que quiser, às 21 e soltar o formulário. Elencar os temas das próximas lives na semana seguinte e voltar no dia 19/01 com o primeiro tema.

Espero que as coisas sejam melhores que em 2025. Se você leu até aqui, espero que tenha boas festas e espero te ver por aqui, e obviamente lá no youtube em 2026 <3

Video On Demand. Como o vídeo é apresentado após o final da live. ↩︎

Curso de FastAPI, post-mortem: como foi a minha experiência criando material financiado coletivamente

mail@dunossauro.com (dunossauro) — Tue, 23 Sep 2025 00:04:14 -0300

Faz uns poucos meses que o curso de FastAPI acabou. Meu objetivo com esse texto é repensar um pouco sobre tudo que aconteceu. Os pontos positivos, negativos, os aprendizados e claro… sobre a dor que foi passar por um período de 3 anos de cobranças internas excessivas.

Um frame da animação de abertura dos vídeos que nunca foram lançados

O resultado foi muito positivo, o curso foi um sucesso, o material virou meu xodó e motivo de orgulho. Mas… foram tempos sombrios!

# Um pouco de história

No segundo semestre de 2021, pensei: “que tal fazer um curso de FastAPI?” e mais do que isso, “por que não ensinar de uma forma que englobe o python mais moderno e os ‘agregados’ como banco de dados, testes, CI, deploy…?”.

Lembro de ter dito algo parecido com isso para minha parceira:

“Acho que se eu trabalhar umas 10 horas por semana, eu devo conseguir preparar todo esse material em uns 3 meses… Aí eu tiro uma semana e gravo todos os vídeos e vou editando por demanda…”

ps: a resposta dela paira mais perto da realidade do que aconteceu.

Spoiler, estou escrevendo esse texto no dia 21 de setembro de 2025. Bom… o objetivo desse texto é desbravar essa jornada que teve um final feliz, tanto quanto traumático.

## Linha do tempo dos acontecimentos

Uma das coisas que mais me ajudou a escrever esse texto e entender meus sentimentos mistos, talvez, quem sabe, fazer com que não seja tão duro comigo mesmo, foi escrever uma linha do tempo. Por esse motivo, vou deixar ela aqui:

13 de dezembro de 2021: começo a escrever a estrutura do curso
14 de janeiro de 2022: início dos trabalhos de assets 3d para usar na campanha
9 de fevereiro de 2022: foi lançada a campanha de financiamento coletivo
11 de fevereiro de 2022: a meta de 12k foi batida
9 de março de 2022: A campanha se encerra com quase 200% do valor inicial
31 de março de 2022: Definida a estrutura inicial do curso em vídeo (link)
29 de abril de 2022: início da escrita do material de apoio (typing + async)
4 de junho de 2022: início da gravação da primeira aula
06 de julho de 2022: faço upload das primeiras quatro aulas gravadas de forma privada
10 de julho de 2022: anuncio da versão 2.0 do pydantic com quebra de retrocompatibilidade, planejada para outubro
11 de julho de 2022: choro no banho a primeira vez
12 de setembro de 2022: a mensagem maldita foi pinada no grupo do telegram
13 de outubro de 2022: iniciado o processo de lançamento do sqlalchemy 2.0
26 de janeiro de 2023: lançada a versão 2.0 do sqlalchemy
30 de junho de 2023: lançada a versão 2.0 do pydantic (planejada para 2022)
1 de julho de 2023: o caos foi instaurado na minha mente
7 de julho de 2023: fastapi adiciona suporte ao pydantic v2 (v0.100)
13 de julho de 2023: commit inicial do material de texto
17 de julho de 2024: Apresento publicamente a página do curso em texto
23 de novembro de 2023: “Desisto” de escrever o material de apoio (typing + async)
8 de junho de 2024: Lançada a v1 do material de texto
11 de junho de 2024: Foi feita a live da aula de abertura
6 de outubro de 2024: v2 do material de texto. Com merge das ideias principais sobre async do material de apoio
29 de janeiro de 2025: Foi iniciado o changelog no texto
2 de fevereiro de 2025: v3 do material de texto
6 de maio de 2025: Foi feita a live da aula de abertura
12 de março de 2025: Lançamento da v4 do material de texto

# A campanha

A forma que encontrei para viabilizar a criação desse material foi por meio da campanha de financiamento coletivo. Uma campanha tudo ou nada, ou seja, se a meta fosse atingida, eu focaria energias para produzir o material, caso contrário, nada aconteceria.

Embora eu mantenha há anos a campanha da live de python, para ser bem sincero, eu não acreditei que em um mês a meta de 12k fosse atingida. Pra minha surpresa, não só foi atingida, como isso aconteceu em 26 horas!

## O dinheiro

Meu trabalho em tempo integral é produzir o material semanal da live de python. O que me toma cerca de 40/50 horas por semana. Entre o levantamento do tema, referências, testes, o estudo, a criação do material, a parte gráfica e a apresentação da live na segunda-feira.

Parar de produzir as lives por um período, ou diminuir o ritmo, faria meu canal ser penalizado pelo youtube, o que diminuiria significativamente a minha renda durante a produção do material. Pensei que esse valor seria o suficiente para cobrir a não entrada de grana do youtube num período máximo de 7 meses¹.

## A receptividade

O quanto as pessoas engajaram na causa e ficaram felizes pela produção desse material mexeu tanto comigo, de uma forma positiva. Me mostrou que as pessoas confiam na qualidade do meu trabalho e também confiaram que eu entregaria algo de valor.

Foi espetacular e um prazer inenarrável ver o quanto sou bem quisto pela nossa comunidade! De verdade, isso foi tão lindo. Durante as partes difíceis do processo, reli algumas mensagens que as pessoas me mandaram, alguns comentários que foram deixados e isso me ajudou MUITO.

## A responsabilidade

O diabo mora nos detalhes…

Bom, com a excelente receptividade, logo veio um senso de cobrança insano. Onde tudo deveria estar perfeito, calculado, nos mínimos detalhes, absurdamente correto, com direito a APIs internas sendo debruçadas.

Com isso, comecei a escrever um material de apoio profundo, aquele tipo de coisa que quem conhece meu trabalho mais de perto sabe como funciona. Eu estava debatendo comigo e escrevendo sobre o fato do interpretado reconhecer uma chamada na pilha e fazer o processo de quickening…

Onde estava o FastAPI? Não sei… eu me perdi na escrita do material de apoio logo no início. Acho que isso vem de uma frustração anterior, como o curso de selenium, que não teve o aprofundamento teórico necessário².

Depois de escrever algumas semanas em que dormi quase nada, um material que não teve nenhum aproveitamento…

## A cobrança interna

Bateu na minha cabeça uma pira de que eu deveria entregar isso de outra forma, como prometido na campanha. Um curso em vídeo, não um material extenso de texto com noias perfectionistas que só dizem respeito a minha ansiedade.

Montei e desmontei toda a fotografia/iluminação. Montei da forma mais “perfeita” que consegui. Anotei todos os parâmetros, fiz os slides com alguns roteiros anteriores e fui gravar. Durante algumas semanas, fui fazendo isso. Gravando, editando e postando de forma privada.

Por que isso não virou público? Não é óbvio? A sabotagem de não ser o incrível perfeito aprofundado e bitolado pomposo e cheio de referências podia me fazer deletar tudo sem ninguém saber que isso tinha começado a ser feito.

# A maldição das majors

Quando achei que tudo tinha começado a andar rumo ao que foi prometido…

## Pydantic 2

Em 10 de julho de 2022 o Pydantic, componente central no curso e no FastAPI anuncia a 2.0 com quebra de retrocompatibilidade, reescrita em Rust.

Eu, como um bom leitor de feeds, li isso no mesmo dia em que sentei para iniciar a gravação da aula 05. O que me fez repensar sobre tudo que tinha sido feito até ali. A previsão inicial de lançamento era para outubro, no mais tardar ao fim do ano.

Isso inviabilizaria o produto final do curso. Sendo bem positivo³ com as datas, se eu continuasse gravando e postasse tudo, provavelmente os lançamentos das últimas aulas combariam com o lançamento do pydantic, o que, exclusivamente na minha cabeça, faria todo o projeto estar desatualizado no momento em que estava sendo lançado.

Com esse turbilhão na cabeça, postei a mensagem mais estranha do mundo no grupo do telegram do curso:

“Galera, o curso ainda não tem data. Estou trabalhando nele diariamente. Quando tiver alguma evolução significativa. Vou avisar aqui no grupo. No momento estou trabalhando nisso em tempo integral. Fiquem em paz, que logo menos as coisas acontecem.

Estou trabalhando nos módulos iniciais ainda. O FastAPI está passando por algumas manutenções. Estou acompanhando de perto as novas mudanças do pydantic.

Sei que as pessoas aqui já estão cansadas de ouvir isso. Mas estou trabalhando. Estou mandando de novo essa mensagem pois toda hora entra alguém no grupo e pergunta de novo e a minha mensagem se perde. Então vou fixar essa mensagem.

Tô trabalhando bastante, tô ficando bastante feliz com o que está rolando. Em breve novidades, sem datas. Afinal, não temos datas nem para release do pydantic, que foi planejada de maneira otimista para dezembro. Estou aproveitando para trabalhar melhor e mais profundamente nos módulos iniciais. Prefiro postergar um pouco mais, do que deixar o curso com aulas desatualizadas.

Isso me fez retomar a escrita do material teórico, aquele aprofundado em nuances, … Sim, aquele delírio insano da minha mente.

Ah… e sobre a versão 2, ela foi lançada em 30 de junho de 2023. Esperar por ela foi complicado.

## SQLAlchemy 2

Nesse material “““incrível””” que estava escrevendo, fugindo totalmente do escopo inicial, passei grande parte trabalhando na interação do AsyncIO com o SQLAlchemy. Recém saído na versão 1.4.

No dia 13 de outubro de 2022, outro tombo. É anunciada a nova major do SQLAlchemy, a 2.0 (que acabou saindo em janeiro do ano seguinte). O que fez com que grande parte do material que trabalhei durante os meses estivesse obsoleta. Novas coisas foram inseridas, o suporte ao async melhorou, a integração com o typing estava incrível. Mas isso não me fez ter menos retrabalho…

O que me fez entrar em pânico novamente!

Embora tenha sido trabalhoso, acabou não sendo em vão, estar “acompanhando” cada commit e modificação originou uma das lives de python que eu mais gosto e considero uma das mais importantes que fiz no canal: “SQLAlchemy: conceitos básicos, uma introdução a versão 2” e parte integral da v2 do texto do curso, quando o AsyncIO foi incluído.

## FastAPI 0.100

Em julho de 2023, o FastAPI adiciona o suporte ao pydantic v2. O que não demorou muito em relação ao lançamento da v2.

# Saúde mental

Com toda a demora, “futurologia” e trabalhando na “diagonal” do conteúdo. É claro que eu não estava feliz. As pessoas me cobravam? Claro que sim…

Mas o meu MAIOR inimigo fui eu mesmo. Eu não soube lidar com a pressão dos atrasos, começava e parava de fazer várias coisas que estavam “entorno” desse projeto, mas eu nunca encarava ele de frente. Eu estava com vergonha de conversar com as pessoas, eu estava com vergonha de “não ser suficiente”. Enquanto as lives python aconteciam, eu me sentia MUITO mal. Isso não foi bom pra mim de maneira geral.

Foi péssimo!

E essa vergonha e culpa me fizeram eu me comunicar muito mal, mais que o normal. Com quem apoiou o projeto, com quem queria saber como estava o andamento, com quem confiou que eu tinha capacidade de fazer esse curso!

## O estopim da fúria

As pessoas sempre viviam me perguntando sobre o curso. Vendo agora em retrospecto, eu entendo que elas estavam curiosas sobre o que estava acontecendo, sobre o andamento. Nunca ninguém* me disse nada em tom de cobrança. Até porque eu andava fazendo lives na twitch quase que diariamente, trabalhando no “material perfeito”, aquele mesmo… a diagonal da diagonal.

No dia 1 de julho de 2023, recebi a mensagem de milhões no privado do telegram:

“Já faz mais de um ano que a campanha acabou e você ainda não entregou o material e nem fala mais sobre isso. Você enganou todas as pessoas e eu investi 50 reais nesse material. Você me roubou!”

Reescrevi essa mensagem em um tom parecido com o que a pessoa usou, claro, além de ter sido chamado de ladrão. Vamos dizer que a pessoa me mandou tomar no *, me chamou de filho de você sabe quem, etc.

## A resposta a incidentes

Quando recebi essa mensagem, eu realmente entendi que eu “era um merda mesmo!”. Chorei bastante nesse dia. Eu realmente era incapaz de lidar com essa situação.

Depois de horas de choro, que foram longas, eu cheguei a uma conclusão: “Quer saber… FODA-SE, eu vou fazer tudo de uma forma nova. Uma que eu consiga entregar o que as pessoas querem. Sem masturbação mental, sem caçar detalhes em APIs, em coisas estupidamente complexas que ninguém quer nem saber”.

# O material em texto

Esse sentimento amargo na boca, a raiva e a cobrança forte me fizeram ir por outro caminho. Vendo em retrospecto, talvez esse caminho seja o que deveria ter sido tomado desde quando comecei a escrever o “maravilhoso profundo”.

As coisas mudaram um pouco de rumo quando entendi que o material deveria ser diferente das rotineiras lives de python. No sentido de tentar destrinchar tudo, todo o tempo, com a complexidade que o tempo permitia. Esse projeto poderia se apoiar nas duzentas e algumas lives que já existiam. O curso poderia apontar tangentes que as lives tradicionais preencheriam.

No sentido de que ele deveria ser um projeto feito de ponta a ponta. Com todos os entornos colocados na ideia inicial. Banco de dados, Async, testes, CI, deploy, etc.

Nessa virada de chave, eu sentei e, em alguns poucos dias, esbocei as primeiras cinco aulas em formato de texto.

## Mas texto? Não eram vídeos?

Trabalhar com texto é extremamente mais exaustivo e complexo do que gravar os vídeos com um roteiro básico e ir no flow e editar tudo depois. Sendo bem sincero, acho que poder me esconder atrás de um monte de palavras parecia mais atraente no primeiro momento.

Não podia ter tomado uma decisão mais certeira do que essa! Embora o custo de escrever seja mais alto, corrigir o texto e fazer o deploy de páginas é extremamente mais fácil do que regravar uma aula e editar.

O interessante, no final das contas, é que acredito que o que gerou mais valor em tudo que foi produzido desse curso, o texto é de cara a coisa mais importante. Textos são acessíveis, nem todas as pessoas gostam de vídeos e claro, sim… dá pra pesquisar no texto.

### O texto me permitiu mais do que isso

Mas do que as aulas, o texto me permitiu usar recursos interativos como os quizzes ao final das aulas. Essa foi uma das coisas mais elogiadas e que, durante as lives que assisti com as pessoas fazendo o curso pelo material de texto, elas sempre diziam que o carinho com o material era tão bom que até em “fixação do material” eu tinha pensado.

Claro, outras coisas incríveis puderam ser feitas. Muitas delas, graças ao markdown-exec, que me permitiu fazer coisas interativas que mantinham sempre tudo atualizado, datas, versões, execução de código…

As contribuições das pessoas foram incríveis. Corrigindo texto, legibilidade, erros de gramática, exercícios, fazendo sugestões. Isso fez o senso de comunidade em torno do material ser mais “ativa” no lugar da receptividade “depositária” dos vídeos.

### Comunicação do material

Divulguei isso para os apoiadores no grupo do telegram no dia 17 de julho de 2023.

Galera, só atualizando vocês dessa sprint maluca que eu disse que ia fazer nessa semana. Consegui roteirizar as aulas: https://fastapidozero.dunossauro.com/

Ainda tem bastante coisa pra ajustar isso pra ser um texto “claro” para referências, mas a progressão está toda aí.

O repo para quem quiser furtricar, se quiser mandar alguma coisa. Tá tudo aqui:

https://github.com/dunossauro/fastapi-do-zero

Meu objetivo é começar a gravar tudo isso na quarta, vou tirar hoje e amanhã pra trabalhar nessa parte da composição visual (tipografia cores e etc…)

Sim… em um pouco mais de um ano, essa foi toda a comunicação “oficial” que fiz do material.

Não exatamente só essa, fomos bastante ativos no telegram durante esse ano. Papeando e conversando sobre todo o processo (nunca explicitamente como nesse texto), mas as pessoas sabiam do andamento das coisas. Mas eram conversas que se perdiam com facilidade no grupo.

### Olhando pra trás

Olhando em retrospecto, fica claro pra mim que isso estava acontecendo desde que comecei a escrever o material de apoio. Mas a utilidade do material de apoio não fazia sentido na minha cabeça. Todo o tempo achei que estava “me enganando”, fugindo do tópico central. Na verdade, era a melhor forma de expressar o que eu estava querendo, mas eu não estava com o caminho bem definido do que o curso tinha que ser em relação ao que eu achava que deveria ser.

## A volta dos vídeos que também não foram

Embora os textos estivessem no formato “perfeito” para acompanhar os vídeos e ser a base deles, no momento eu estava me sentindo um merda. Um ladrão…

Fui gravar de novo, como prometi no grupo de apoiadores. Dessa vez, já com a ideia do “projeto”.

Os vídeos nunca lançados...

Outro grupo de quatro aulas que nunca viram a luz do sol. Só que dessa vez, gravar não foi fácil. Eu tinha o roteiro do que eu queria, eu sabia como fazer, mas eu não conseguia.

Um dos episódios dessas gravações é muito claro na minha mente. Eu pedi pra minha parceira ficar no quarto comigo enquanto eu gravava. Eu estava perdendo o fôlego durante as falas, irritadiço. Eu não conseguia falar, eu estava me sentindo culpado o tempo todo.

Decidi tirar alguns dias sem gravar, pra tentar acalmar as ideias. Lembro que vomitei de nervoso duas vezes tentando gravar a quinta aula.

## Erros de comunicação

Sofri e me culpei em silêncio por bastante tempo, mas decidi, com a comunicação pífia, que eu iria escrever TUDO antes de tentar voltar a gravar. E fui fazendo o texto e postando os updates. A galera foi curtindo, foi dando os feedbacks, foi contribuindo com melhorias. Tudo isso foi ótimo, na minha cabeça confusa da época, e evitou que eu tivesse que falar abertamente dos motivos pelos quais os vídeos nunca saíram.

### Acompanhamentos periódicos?

De todos os tópicos, esse é o que me dói mais. É um combo de vergonha e atraso sem fim. Na minha cabeça pairava que avisar “estou atrasado, mas estou fazendo X…” era péssimo.

Isso virava uma bola de neve na minha cabeça: “Pô, pq avisar? Eu ainda estou travado fazendo coisas que não devia enquanto espero as majors…”

Essa foi a pior escolha possível! Manter as pessoas informadas teria me tirado um peso tão grande das costas.

# Além do texto, as lives

Acho que nunca me recuperei do silêncio antes da primeira palma seguida por “Olá, boas-vindas ao curso de FastAPI” sem me sentir um bandido. Se eu não conseguiria fazer isso dessa forma, decidi que pelo menos a primeira apresentação do curso deveria ser síncrona. No sentido de que faríamos em lives, conversando e sem a pressão do silêncio, “você me roubou…”

Com isso, o material de texto foi andando durante quase um ano. Quando de fato anunciei, em 17 de abril de 2024, a data das lives e algum tempinho depois fechamos a v1.0 do material.

As lives foram divertidas, a galera super acompanhou, gostou do material, da forma final de como tudo ficou. Bastante gente fez os projetos.

# Final feliz, não?

Sabe aquele incômodo de não estar “perfeito”? Ele continuava a me massacrar. Eu “roubei” mesmo as pessoas… Eu disse que teriam coisas, e no final, elas não estavam no conteúdo.

Mas, afinal, o que estava faltando? O asyncio!

Eu dormia pensando nisso, acordava pensando nisso, tomava banho pensando nisso. Como pude fazer um curso todo sem falar sobre programação assíncrona? Passei meses escrevendo sobre isso, fizemos lives sobre o sqlalchemy assíncrono. Mas, no final, na correria de tentar entregar tudo o mais rápido possível⁴, eu me pressionei a não colocar mais aulas no texto.

Foi nessa espiral da desgraça que decidi que iria incluir uma nova aula no texto sobre programação assíncrona e que, depois dessa aula, que iria ser inserida no meio do material, todo o código deveria seguir de forma assíncrona.

Resultado? Mais retrabalho! Mas pensa NO retrabalho em revisar metade do curso, pensando em refazer explicações e alterando códigos…

Nessa hora, eu agradeci por ter feito tudo em texto… Isso pode me guiar pra fazer as coisas sem errar. Embora, talvez, eu nem precisasse ter feito nada disso, eu me sentia na obrigação.

Esse processo durou mais alguns meses, com isso foram marcadas outra saga de aulas síncronas. Que ficaram conhecidas como o “Curso de 2025”.

Adicionei somente o asyncio? Você leu o texto até aqui… Você sabe que não. Eu revisei o material todo e aulas que tinham 15/20 minutos de leitura média se tornaram monstros de 40 minutos de leitura. Testes foram revisados, toda a interação com o banco de dados foi revisada, eventos, apêndices, novas questões nos quizzes… Bom… Foi um retrabalho danado.

Foi lançada a v2 do texto com todas essas alterações. Que foram levadas mais adiante e depois de mais reescrita, viraram a v3.

Finalmente, eu achei que estávamos perto do que eu queria, reescrevi mais um bocado e a v4 foi lançada e marcadas as datas das “reapresentações”.

## Um acontecimento tardio, mas especial

Como me disse meu pai uma vez:

“É só pegar o que sabe fazer de melhor. Se você for fazer pra você, pode ter certeza que vai sair mal feito”

Em 29 de janeiro de 2025, eu me dei conta do que poderia ter resolvido meses de angústia. Por que raios eu não fiz “logs” de trabalho? No que estava trabalhando, o como e com as datas. Isso poderia ter me poupado de tanto sofrimento. Uma página que fosse.

Nesse dia, eu introduzi o Towncrier no material de texto. O que acabou se tornando uma live de python “Entendendo Changelogs: O que são, seus padrões e como gerá-los com Towncrier “.

Olhando agora, não é como se eu nunca tivesse assistido/lido devlogs, principalmente de jogos. E também não tivesse escrito release notes e feito changelogs em projetos de código. É engraçado ver que eu deveria ter pensado nisso. Talvez esse tenha sido o meu maior aprendizado durante esse processo. Isso ajudaria a informar as pessoas, ter uma fonte única dos eventos e também ter aliviado MUITO estresse e ansiedade.

# Final feliz, não? [2]

Não… Algumas questões foram levantadas durante as apresentações, ccomo o fato de que dessa vez tinha menos gente do que da primeira vez ao vivo e as lives tinham a duração 1/4 maior, mais perguntas, mais formas de uso foram levantadas…

Resumo, o texto ganhou a v4.1.

# Depois disso tudo…

Bom… Demorou muito mais do que eu previa, eu acabei entrando em parafuso algumas vezes. Tento ver isso de dois pontos diferentes.

É que no final deu tudo certo, o material tem a qualidade que eu gostaria que tivesse, embora o “produto final” tenha se desenrolado completamente diferente do que eu imaginei no início.
Foi estupidamente desgastante e angustiante. O processo não foi bom.

## Erros

Se puder elencar os pontos onde mais errei, eu destacaria alguns.

### Comunicação da campanha

Esse foi um erro cometido durante todo o processo. Desde a abertura da campanha. Não ficou claro pra muitas pessoas que se tratava de uma campanha “tudo ou nada”. Que eu só começaria a trabalhar no material caso a campanha fosse bem sucedida.

Acredito que essa parte de “campanhas” seja meio que novidade para algumas pessoas e a “cultura” de comprar cursos também não ajuda muito. Grande parte achou que o material seria liberado ao final da campanha de um mês. Se tivesse deixado isso mais claro, talvez o início do trabalho teria sido menos frustrante pra mim.

### Comunicação do processo

Como já mencionei algumas vezes ao longo desse texto, talvez se eu tivesse feito um “devlog” ou simplesmente uma página mantendo o processo, o que estava sendo feito, explicitamente claro, isso poderia ter sido evitado.

Ter “uma única fonte de verdade” foi o que mais faltou aqui. Lembro que, quando comecei os changelogs, isso me aliviou de uma forma absurda.

Se isso fosse pensado no início, eu poderia já ter deixado claro na divulgação da campanha.

### Desespero

Acho que perdi a sanidade quando as coisas foram anunciando versões e eu não soube lidar com essas coisas. O que acabou me deixando extremamente frustrado e sem norte. Eu queria fazer, mas queria fazer “perfeito”. Essa busca pelo inalcançável me machucou bastante.

Embora no final essa subsequência de acontecimentos e espera tenham me feito escrever, esse foi o maior trunfo de todo o material, na minha opinião.

### Prazo

Bom… aqui eu errei rude. Eu não previ a complexidade das coisas porque eu pensei em algo e, na hora de executar, quis fazer de outra forma totalmente diferente. O fato de não ter uma data pra tudo estar “pronto” fez com que eu fosse me arrastando em projetos diagonais.

Eu colocaria um prazo, olhando de fora? Acredito que não, mas pontuar “checkpoints” de metas possíveis poderia ter me ajudado.

### A entrega

No final, o que entreguei foi muito diferente do que foi prometido. As pessoas esperavam um curso em vídeo. Eu entreguei um mega material em texto e aulas síncronas.

Eu acho que a entrega final foi 200x melhor do que o que foi proposto, mas ainda assim não foi o que foi prometido.

### timing

Convenhamos… Eu escolhi literalmente o PIOR momento pra fazer esse curso. É aquela coisa de estar no lugar errado e na hora errada.

Se eu tivesse começado antes ou alguns meses depois, o desenrolar das releases que foi o que mais me deixou maluco, tudo teria acontecido de outra forma.

## Acertos

Bom… Nem tudo deu errado. Talvez eu valorize mais essas coisas por terem sido duras demais pra mim durante o processo. Mas eu aprendi muito do que não fazer e de como fazer coisas melhores do que pensei que seria capaz de entregar.

### A campanha

Claro, a campanha foi um grande acerto. Ver que as pessoas acreditam e confiam no material que eu desenvolvo, não tem preço. Saber que tem alguém que conta com você, que te incentiva… Isso faz toda a diferença.

Muitas das pessoas que contribuíram para o material, assim como na live de Python, de maneira geral, não esperavam pelo resultado. Contribuíram por saber que esse material contribuiria com o conhecimento de outras pessoas.

Pensar nisso agora me arrancou uma lágrima. A nossa comunidade, que é um subconjunto da comunidade de Python em geral, tem essa coisa incrível de sempre estar disposta, se permitir, contribuir com o crescimento das outras pessoas.

### O texto

Você já deve ter cansado de me ouvir falar disso. Mas, de verdade, o material em texto é literalmente A MELHOR coisa que foi produzida por esse material.

Ele é um guia, um tutorial, um livro. É buscável, permitiu os quizzes, atualizações periódicas, o versionamento.

Olhando em retrospecto, eu não imagino como esse material seria sem o material de texto. Ele literalmente é a coisa mais rica que já produzi na vida. Sem brincadeira.

Eu já tinha me arriscado a escrever no passo, com o material de funcional (nunca terminado) e o material de ansible (usado para uma live apenas). Eu não consigo imaginar por que não pensei nisso antes.

Outro ponto aqui foi que ter o texto ativou o modo “pê errers” das pessoas. Elas pegaram o material para si e contribuíram MUITO. Grafia, sugestões de aula, fontes acessíveis, sugestões de ferramentas. Tudo que um projeto aberto é capaz de proporcionar.

### Os changelogs

Ter uma fonte de verdade, do que está sendo feito, das pequenas entregas. Além de mostrar pras pessoas o progresso do que está acontecendo, me deram uma sensação de “olha, eu fiz alguma coisa essa semana”. Que era um sentimento que me massacrava. Trabalhava às vezes por dias sem pausa e a sensação de não ter “feito nada” era sempre grande, o que me desmotivava muito.

## O presente com fatos!

Tanto o Pydantic quanto o SQLAlchemy ainda mantêm ativas, recebendo bugfixes, as versões 1 em setembro de 2025. Mesmo após anos da mudança de major… Ah, claro, o FastAPI ainda hoje 0.117.1 (2025) também suporta o pydantic v1 :)

Ou seja… eu estava desesperado tentando prever um futuro que hoje, três anos depois, não se concretizou.

Em algum momento, a mudança do poetry v1 -> v2 também foi alvo da minha preocupação, pois era a base do projeto. Olhando agora com menos desespero, é retrocompatível com pyproject antigo.

Coisas que pareciam o fim do mundo, que me deixam sentado no escuro sozinho.

# Eu faria isso de novo?

Responder isso é bem complicado.

Mesmo que tenha sido péssimo passar por esse processo, eu cresci muito como pessoa. Eu encontrei falhas nos meus processos, entendi como expor melhor as minhas ideias, ser mais transparente com os processos.

Talvez eu faça de novo, não em período curto. É bom deixar claro. Hahahahah

Embora tenha aprendido muito, esse processo me machucou bastante. O resultado foi positivo, vendo agora, após um tempo. Mas enquanto as coisas estavam acontecendo, eu não soube lidar com a maioria das coisas que aconteceram, no momento em que aconteciam pareciam socos no meu estômago.

Mas, eu faria tudo de forma diferente, se fosse uma nova coisa. Eu focaria no texto, na transparência, as aulas ficariam pro final, depois que tudo estivesse redondo.

No fim… o resultado me deixou bastante feliz e o processo me trouxe muita coisa ruim, mas aprendizados importantes pra lidar com essas coisas no futuro.

Pra vocês, como espectadores, como foi tudo isso? Eu adoraria saber.

Mal sabia eu… ↩︎
Obviamente, essa opinião é compartilhada pelo total de zero pessoas, mas vive latejante na minha mente. ↩︎
Quanta ingenuidade… deus… ↩︎
Como se dois anos de espera não tivessem sido o suficiente… ↩︎

O que andei lendo...

mail@dunossauro.com (dunossauro) — Wed, 27 Aug 2025 12:09:36 -0300

Recentemente adentrei em mais um pedacinho do fediverso, o bookwyrm, uma rede social de leitura e reviews de livros. Confesso que, embora seja um leito regular, eu nunca tive interesse nessas redes. Mas, sempre me perguntam o que ando lendo por aí e eu raramente consigo lembrar de pronto o que andei lendo nos últimos meses.

Decidi criar uma conta só para lembrar do que li recentemente sem fazer grande esforço. Mas, como criei agora, resolvi nesse post relembrar algumas leituras que fiz nesses últimos dois/três meses. Não vou dar spoilers de nada, quiçá contar a história. A ideia é somente listar as leituras.

Meu perfil no bookwyrm, caso queira fazer amizades por lá :)

# “O homem sem talento”, por Yoshiraru Tsuge

Mangá clássico do watakushi que reúne histórias autobiográficas do Tsuge.

Confesso que tentei ler esse mangá uns dois anos atrás, mas o tom “ode ao fracasso” me fez abandonar por não estar no melhor momento também. É uma obra densa, triste, mas de certa forma libertadora. Machuca…

open library

# “Dois irmãos”, por Fábio Moon e Gabriel Bá

Quadrinho brasileiro que adapta a obra de Milton Hatoum. Retrata a história de uma família de imigrantes libaneses vivendo em Manaus-AM na década de 40.

Leitura bastante interessante, ganhei esse quadrinho da organização da Python Brasil em Manaus, confesso que demorei bastante para ler. Mas é uma história muito gostosa de ler, o quadrinho é lindo. Após a leitura, descobri que o livro original agora é tema da Fuvest (boa sorte na prova, se você chegou até esse link por conta disso :))

open library

# “O apanhador no campo de centeio”, por J. D. Salinger

Tenho uma relação estranha com esse livro. Tem algo no Holden que me cativa. Essa deve ser a quarta vez que eu pego esse livro pra reler e eu o adoro.

open library

# “O estrangeiro”, por Albert Camus

Absurdismo do começo ao fim. Fiquei bastante frustrado com a minha edição que dava o plot da história logo na orelha do livro…

Depois da leitura, nas pesquisas sobre o livro, descobri que o pensado pelo Camus era que o Sísifo fosse lido antes. Bom… vai ser lido depois em algum momento xD

open library

# “Relato de um náufrago”, por Gabriel Garcia Marquez

Publicações de jornal de 1955 sobre o acidente da marinha colombiana narrados por Luis Alexandra Valesco e escritas por Gabo. Essas publicações foram um dos motivos do Gabo ser exilado da Colômbia.

open library

Daqui pra frente vou tentar manter meu perfil no bookwyrm atualizado. Vamos ver se consigo :)

Lembranças preciosas

mail@dunossauro.com (dunossauro) — Tue, 08 Jul 2025 15:18:49 -0300

Há alguns dias, estava conversando com as pessoas em uma live na Twitch do tempo que fui voluntário em um projeto que ensinava informática básica para a terceira idade e o quanto isso me marcou de diversas formas, o que pode ser assunto para outro blog post. Mas, quando saí da live, isso me despertou uma lembrança da minha avó paterna.

Morei uma temporada da vida com meus avós, onde adquiri diversos hábitos que conservo até hoje. Às vezes me pego pensando nessas coisas e me emociono, outras vezes caio em gargalhadas.

Minha avó não teve muita oportunidade de estudar, era uma católica devota, daquelas que ia à capela rezar o terço todos os fins de tarde. Era dócil e rabugenta, acredito que como todas as avós.

Como estava no contexto de falar sobre educação durante a live. Me lembrei de várias tardes em que sentava ao lado da minha vó, na mesa da cozinha, tomando um iogurte caseiro que ela fazia, sem açúcar, pois era diabética, mas nós claramente colocávamos açúcar refinado na hora de comer, sem que ninguém nos visse. Ou então outra coisa maluca que comíamos, alface com açúcar.

Durante essas tardes acontecia uma coisa que levei anos para entender. Minha vó estava fazendo lição de casa. Ela estava tendo o básico de uma educação formal em um supletivo. Tinha um caderno de caligrafia exemplar. Ela tinha tanto orgulho desse caderno, guardava-o em uma gaveta separada do móvel, onde não tinham outros cadernos, mas sim alguns cacarecos acumulados durante a vida. Fantasio hoje, depois de tantos anos, que ali deveriam estar algumas das coisas mais preciosas de sua vida. Lembro de um álbum de fotografias, alguns monóculos antigos também de fotos, algumas outras coisas pequenas das quais não consigo me lembrar agora.

Uma vez na semana, ela se reunia com outras senhoras da igreja para bordar e pintar panos de prato. Que vendiam no bazar da igreja. Lembro terem sempre frutas pintadas e alguma mensagem, às vezes algo genérico, às vezes alguma passagem que consideravam belas, nas escrituras sagradas. Uma utilidade prática daquelas longas horas treinando caligrafia.

Lembro de ir buscar minha avó na escola com meu vô em um Chevette prata, que era o xodó dele. Comíamos biscoito de polvilho enquanto esperávamos ela sair, sempre ao som de um bom pagode. Silêncio absoluto ouvindo as aventuras narradas por Tonico e Tinoco. Quando minha avó era avistada pelo meu avô, começavam os resmungos, uma cena digna de coragem, o cão covarde. Meu avô era o próprio Eustacio, enquanto minha avó era uma Muriel por completo. Íamos para casa ao som de uma viola chorando aqui, um resmungo ali.

Experimentando o Lima (Linux Machines)

mail@dunossauro.com (dunossauro) — Wed, 30 Apr 2025 10:40:35 -0300

Grande parte do meu trabalho, fora dos streams e vídeos, é dar suporte pra a comunidade. Eu tô sempre por ai, nos grupos da comunidade de python/emacs/GNU/linux, tentando ajudar da melhor maneira possível.

Esse post estava no meu draft desde 2023. Não tinha absolutamente nada de interessante que fazia ele valer a pena para ser postado, depois desse toot achei que deveria postar!

# Meu problema de sempre

Uma das coisas mais complicadas pra mim é tentar reproduzir o ambiente de desenvolvimento de outras pessoas. “Ah… mas temos docker”, faz um tempo que tenho evitado usar docker por conta das licenças absurdas que eles veem impondo aos usuários. Você poderia me dizer que temos o podman então… E você pode ter razão.

O meu grande problema com essas ferramentas é que elas não substituem uma máquina virtual. Bom… pra 99% das coisas, sim. Tirando que tenho que escrever um arquivo pra produzir um container. Mas, o problema começa quando preciso reproduzir o ambiente onde a pessoa executa o container. Fazer DinD ou PiC não é a coisa mais simples do mundo, principalmente com o fato de que pra isso tenho que escrever um novo Dockerfile. Em tem várias imagens, portas… Definitivamente, isso não é prático.

Em vários momentos, opto por ter uma máquina virtual pra tentar executar essas coisas. Simplifica um pouco o contexto. Aí lá vou eu usar outra plataforma proprietária, como o vagrant cloud pra procurar a distribuição que a pessoa usa. Aí dá aquele frio na espinha e você vê que mesmo no bento a imagem não está disponível pra libvirt. Legal, a gente vai de Virtualbox mesmo… (imagine a minha cara agora…). Faço o download da imagem, inicio, compartilho os arquivos com a VM, tenho que habilitar o guest, copia-e-cola unidirecional, montagem do path… Sim, isso dá MUITO trabalho e ocupa bastante espaço (o que às vezes eu não tenho).

# Lima

Após algumas buscas na interwebs em 2023, acabei conhecendo o Lima [LInux MAchines] é uma ferramenta de linha de comando para criar sandboxes usando máquinas virtuais via CLI e com suporte a templates. Uma ferramenta bastante promissora, atualmente em estágio de sandbox da cncf e com licença apache 2.0

Por baixo dos panos ele cria VMs QEMU [no linux, BSDs…], VZ no MacOS e com WSL2 no Windows.

Com um simples comando (e se necessário um arquivo yaml), temos uma VM funcional de diversas distribuições, SSH aberto, sistema de arquivos compartilhado (read-only por default) e redirecionamento de portas.

## Instalação

Para instalar, você pode ir ao guia de instalação oficial, mas um simples curl é o suficiente:

VERSION=$(curl -fsSL https://api.github.com/repos/lima-vm/lima/releases/latest | jq -r .tag_name)
curl -fsSL "https://github.com/lima-vm/lima/releases/download/${VERSION}/lima-${VERSION:1}-$(uname -s)-$(uname -m).tar.gz" | tar Cxzvm /usr/local

Como estou no arch, o pacote está disponível no AUR. O que torna tudo mais simples:

paru -S lima

## Mostando a magia da linha de comando

Bom… Falamos, falamos… Como funciona?

$ limactl start default

? Creating an instance "default" [Use arrows to move, type to filter]
> Proceed with the current configuration
 Open an editor to review or modify the current configuration
 Choose another template (docker, podman, archlinux, fedora, ...)
 Exit

default é um template base rodando ubuntu. Já vem com suporte a conteinerd/nerdctl e LXD

Um enter e temos a VM rodando via QEMU.

### Foi isso que me prometeram, mas não funcionou ;)

caso o seu tenha, pule para Usando o lima

O erro:

FATA[0030] exiting, status={Running:false Degraded:false Exiting:true Errors:[] SSHLocalPort:0} (hint: see "/home/dunossauro/.lima/default/ha.stderr.log")

Lendo o arquivo /home/dunossauro/.lima/default/ha.stderr.log, podemos ver o que aconteceu:

{
 "level":"fatal",
 "msg":"could not find firmware for \"/usr/bin/qemu-system-x86_64\" (hint: try setting `firmware.legacyBIOS` to `true`)",
 "time":"2025-04-24T02:48:57-03:00"
}

Como tenho a bios em modo legacy e isso não combina com a configuração padrão do lima para o qemu, a configuração pode ser alterada na opção de abrir o editor:

$ limactl edit default # abre seu editor de texto

A única alteração que precisa ser feita, é adicionar dizer que legacyBIOS é true:

firmware:
- legacyBIOS: none
+ legacyBIOS: true

Salvando o arquivo, temos isso:

WARN[0000] treating lima version "d218ece" from "/home/dunossauro/.lima/default/lima-version" as very latest release
INFO[0022] Instance "default" configuration edited
? Do you want to start the instance now? (Y/n)

Damos Y e vamos adiante:

## Usando o lima

Após alguns segundos…

# ...
INFO[0107] [hostagent] Starting QEMU
INFO[0108] SSH Local Port: 60022
# ...
INFO[0149] READY. Run `lima` to open the shell.

YAY, agora temos a VM do QEMU funcionando!

Usar o lima é bastante simples, só digitar lima e estamos conectados via SSH na VM:

$ lima
dunossauro@lima-default:/home/dunossauro$

Como estamos usando o template default, a VM é um ubuntu com o containerd e o nerdctl instalado:

dunossauro@lima-default:/home/dunossauro$ nerdctl run -d -p 8080:80 --name nginx nginx:alpine

Pronto, temos um container do NGINX rodando!

Podemos sair do SSH (exit) e também executar os comandos direto pelo lima. Como um update simples:

lima sudo apt update
Hit:1 http://archive.ubuntu.com/ubuntu oracular InRelease
Hit:2 http://security.ubuntu.com/ubuntu oracular-security InRelease
Hit:3 http://archive.ubuntu.com/ubuntu oracular-updates InRelease
Hit:4 http://archive.ubuntu.com/ubuntu oracular-backports InRelease
152 packages can be upgraded. Run 'apt list --upgradable' to see them.

# Templates

Uma das coisas legais do lima é o fato de poder usar diferentes configurações de maneira bastante objetiva. Preciso de uma vm do fedora?

limactl create template://fedora

Ou então usado outras formas de containers?

limactl create template://docker
limactl create template://podman

A lista completa pode ser vista aqui https://lima-vm.io/docs/templates/

# Considerações finais

Achei bastante simples e intuitivo usar o Lima, resolve grande parte dos meus problemas pra simular ambientes e me dá um sandbox mais simples pra poder brincar com coisas quando preciso. Muito mais simples de criar VMs e também pode ajudar a simular deploys em VPSs pra mim.

Talvez eu o use em alguns materiais de aulas no futuro. Por ser agnóstico de plataforma, pode ser uma boa ideia!

Possua seus dados (e pensamentos também...)

mail@dunossauro.com (dunossauro) — Sat, 19 Apr 2025 00:12:54 -0300

[Esse post é o lado inverso deste]

Um dos grandes problemas de viver nos silos, pelo menos para mim, é ter de pensar no que vai em cada silo. Como toda pessoa, também sou multifacetado. Penso em coisas diferentes, com formas diferentes, e gosto de falar sobre elas. Mas parece que nem todo silo é adaptado e tem receptividade para comportar tudo que eu penso. Quer exemplos de pensamentos?

“Já ouviu o último disco do umnavio?”
“Amicu?”
“Chapéu de nazista é marreta!”
“Mano, a pior coisa que eu fiz na vida foi tentar afinar um sintetizador analógico”
“A inclusão do eglot emacs foi a melhor coisa que o editor já recebeu”
“Quer enganar o cliente?”
“Se usa JSON não é REST”
“Caralho, esse primeiro episódio da 7a temporada de black mirror foi sinistro”
“Pega todo esse seu código feito por ia e enfia no cu!”
“Hoje é dia de Live de #Python \o/”
“Annie Ernaux, por que me machucas?”
“Apenas escute o Tecnocracia dessa semana!”
“Glups moglods, dica da lora”

Pegue qualquer “rede social” e se imagine dizendo todos os tipos de coisas que você pensa…

Os silos, além de me transparecer unidimensionalmente aos outros, fazem com que eu tenha que “me comportar”, usando regras de etiqueta do local onde minha publicação pertence. Pra, no final das contas, exercerem o controle de como, via regras algorítmicas, as pessoas vão interagir comigo e claro lucrarem com o meu conteúdo.

Ao fim, eu acabo perdendo um pouco de tudo, inclusive a posse dos meus dados.

# Logando a porra toda

Quando me refiro a logs, eu penso em qualquer coisa que eu posto, qualquer forma de compartilhamento de mim para o outro. Como microblog (o que postaríamos no mastodon, bluesky, threads, xwitter), fotologs (pixelfed, instagram). Até mesmo esse blog que vos fala.

Para quem é mais jovem:

Blog é uma contração de weblog.

Dito isso, o primeiro princípio da inideweb, a casa de quem está tentando viver fora dos muros da web corporativa, é ser dono dos próprios dados.

Construir seu cantinho na internet, seu próprio jardim digital, é uma boa solução. Você rega aos poucos, planta novas ideias, experimenta novas coisas, decora com a sua própria estética e chama as amizades pra frequentar.

Quem sabe até disponibilizar um feed, uma forma de dizer a quem te acompanha que você postou algo novo. Sem depender da despersonificação dos silos, você pode compartilhar da forma que quiser e o que quiser, sem censura. Afinal, na sua casa, você fala o que quiser!

# Censura

Quando digo censura, você já pode estar imaginando cyberpunks¹ vazando documentos da NSA, softporn em redes sociais, venda de drogas online… Mas não… Não é isso!

A pior parte da censura é a (%&)(&\Y@! (%*#&!#!&

Eu tô falando de “termos de serviço”, principalmente os ambulantes. Aquele que, quando você começa a construir seu castelo nele (no silo do outro), as regras mudam, aí você passa a ser um “fora da lei” do condado eletrônico. E o silo vai te penalizar por isso. É claro… Você não leu o TOS, leu?

Pra te ajudar nisso, porque tudo é TL;DR (to long, don’t read) e cheio de juridiquês, temos o TOSDR que mostra os pontos mais críticos dos termos.

Mas, basicamente, o que é aceitável hoje… Amanhã pode não ser mais. Tudo aquilo que, foi feito ali pode não existir mais. Existem casos de monte sobre essas coisas e você pode procurar.

Na sua casa, quem faz o TOS é sua ética, as coisas são feitas pra durar (o nono princípio da indieweb).

# POSSE

O grande problema de estar de fora do silo é que embora tudo seja liberado, por mais incrível que você seja no argumento, não vai conseguir ficar de fora dele. Por uma razão incrivelmente simples. Suas amizades vão estar lá, sua família vai estar lá… Isso não quer dizer que você não possa convidar as pessoas a se juntar aos jardins da internet (um dos objetivos dessa postagem). Mas é diminuir a sua dependência do cercadinho pra simplesmente ser “você” e parar de pensar no seu conteúdo para um cercadinho específico. É aí que um conceito importante entra: POSSE.

Como disse o Guilherme em crie a porra de um blog:

“POSSE é um acrônimo muito do xexelento em inglês. Significa Post to your Own Site, Syndicate Everywhere, algo como “poste no seu site, distribua em todo canto”.”

O segundo S é ponto aqui. Sindique seu conteúdo. Poste no seu jardim e distribua nas redes:

flowchart TD
S[Seu site] --> Distribui
Distribui --> A
Distribui --> B
subgraph A["No lado bom da web"]
Mastodon
Pixelfed
Pleroma
end
subgraph B["No lado mal web"]
Xwitter
Instagram
Facebook
end

Se suas publicações tiverem links permanentes, você pode simplesmente enviar eles nas redes e falar “Olha aqui…”, assim você fica perto das pessoas e mantém seu conteúdo sob o seu domínio. Inclusive, você poderia “reproduzir” o conteúdo e deixar uma referência. Algo como “Postei originalmente aqui [seu link]”.

No início, claro, você pode copiar seu link e sair colando por aí, no silo que faça sentido. Sem nenhum problema. Depois, no futuro, quem sabe alguma automação?

~Estou trabalhando nas minhas automações aqui. Caso você tenha interesse.~

Dessa forma, você se afasta dos silos, dos algorítimos, sem se afastar das pessoas.

# Tá, mas que merda eu faço agora?

Tudo muito legal, tudo bem… Mas tem uma coisa que eu ainda não entendi. Um detalhezinho assim… Qual é o peixe que eu tô tentando vender aqui?

É simples… CRIE A PORRA DE UM BLOG, compartilhe suas notas mentais em uma página com a gente, possua seus links, dissolva seu conteúdo na internet, compartilhe suas fotos não aesthetic que não dariam likes… Tire suas ideias das mãos dos milionários da tecnologia.

Ah… Mas ninguém vai ler o que eu posto

Como disse o Guites: Eu vou ler seu blog. Bota ele aqui nos comentários… Me manda por e-mail. Eu quero ler o que você escreve! Quero conhecer o seu jardim digital, virar um frequentador dele! Conhecer suas facetas – aquelas coisas que você não vai postar no linkedin pro seu empregador não ler, aquilo que você tem de mais “você” por aí. Aquelas coisas que só desconhecidos da internet sabem sobre você. E, por favor, deixa eu ser um deles.

Leitura recomendadíssima ↩︎

Automatizando postagens no pixelfed

mail@dunossauro.com (dunossauro) — Sat, 12 Apr 2025 16:36:28 -0300

Tenho trabalhado nos últimos tempos em uma forma de postar meus conteúdos na minha página e sindicar o conteúdo nas redes sociais (POSSE). Nessa experiência, tenho desenvolvido em vagarosidade glacial o sociopyta.

Na grande maioria dos casos, fazer postagens em redes sociais (silos) não oferece um grande desafio, temos documentação de APIs ou bibliotecas prontas para fazer isso. No caso do pixelfed, não temos nem documentação, nem bibliotecas :)

Esse post é sobre um “trabalho investigativo” em código-fonte alheio. Você pode pular para # solução e ver como fazer a automação dos seus posts ;)

# Iniciando a jornada

Então lá fui eu desbravar o código-fonte em PHP do servidor do pixelfed, mesmo que meu conhecimento em PHP seja… Vamos dizer… Pífio.

O fonte do controller da API do pixelfed pode ser encontrado aqui.

Ao iniciar a minha jornada, procurei por algo que criasse uma postagem. Acabei encontrando statusCreate.

Nesse endpoint fica evidente que deve ser feito um post para /api/v1/statuses usando json com algumas opções no corpo. Vou destacar as que me interessam, você pode ver as outras no código-fonte:

status: O texto que acompanhará a publicação das fotos
media_ids: Os IDs das fotos/vídeos que já foram enviados ao servidor
- Sim… Isso precisa ser feito antes!
e mais …

O que nos daria um request parecido com esse (vou usar curl por considerar “universal”, mas no final vou fazer tudo usando httpx):

curl -X POST "{sua-instancia}/api/v1/statuses" \
 -H "Accept: application/json" \
 -F "status={seu-texto}" \
 -F "media_ids[]={media-id-1}" \
 -F "media_ids[]={media-id-2}" \
 # adicione mais `-F "media_ids[]={...}"` conforme necessário

Ok… Temos um ponto de partida.

Agora precisamos descobrir como enviar as fotos. Encontrei uma função chamada mediaUpload. Provavelmente é esse… hahaha

O endpoint é /api/v1/media que recebe também um json. Com o field file junto com os bytes do arquivo de média. O que nos dá algo parecido com isso:

curl -X POST "{sua-instancia}/api/v1/media" \
 -H "Accept: application/json" \
 -F "file=@{caminho-do-arquivo}"

Beleza. Se tudo der certo, vamos conseguir fazer o upload de uma midia agora e depois criar a postagem, certo?

ERRADO!

## PAT

Para enviar essas requisições, você vai precisar de um token de acesso. O que pixelfed chama de PAT (Personal Access Tokens). Para gerar um PAT você deve ir em:

https://{sua-instancia}/settings/applications

Existem duas sessões. Vá em Personal Access Tokens, clique em Create New Token, dê um nome para esse token e dê acesso de write. Isso irá gerar um token enorme. Salve ele, ele nunca mais vai ser visível!

## Uma nova tentativa

Agora podemos tentar de novo:

curl -X POST "{sua-instancia}/api/v1/media" \
 -H "Authorization: Bearer {PAT}" \
 -H "Accept: application/json" \
 -F "file=@{caminho-do-arquivo}"

YAY! Temos nossa media no servidor. O json de resposta em um field chamada id. Ele é o que devemos usar para criar a postagem.

Se você, assim como eu, for nerd de HTTP vai perceber que a resposta é 200 OK e não 201 CREATED e está tudo certo… 200 é que deu certo… Supere!

Agora que temos o id, podemos criar a postagem:

curl -X POST "{sua-instancia}/api/v1/statuses" \
 -H "Accept: application/json" \
 -H "Authorization: Bearer {PAT}" \
 -F "status={seu-texto}" \
 -F "media_ids[]={media-id}"

YAY! [2]. Temos nossa postagem no pixelfed. O field uri é o link da nossa postagem. Com isso, a nossa jornada investigativa termina.

Novamente, 200, meu coração chora. Mas, vou superar.

# Solução

Embora tenha sido chato ler código-fonte, a solução que eu queria para o sociopyta é bastante simples… Após pegar o PAT precisamos somente fazer uma requisição para cada imagem e um para criar a postagem:

from pathlib import Path

import httpx


def post(text: str, images: list[Path], config) -> tuple[str, str]:
 base_url = config.pixelfed.api_base_url
 access_token = config.pixelfed.access_token

 post_url = f'{base_url}/api/v1/statuses'
 headers = {
 'Authorization': f'Bearer {access_token}',
 'Accept': 'application/json',
 }

 data = {
 'status': text,
 'media_ids[]': [
 upload_media(image, base_url, access_token) for image in images
 ],
 }

 response = httpx.post(post_url, headers=headers, data=data)
 return 'pixelfed', response.json()['uri']


def upload_media(media: Path, instance: str, pat: str) -> str:
 media_url = f'{instance}/api/v1/media'
 headers = {'Authorization': f'Bearer {pat}', 'Accept': 'application/json'}
 response = httpx.post(
 media_url,
 headers=headers,
 files={'file': media.read_bytes()}
 )

 return response.json()['id']

Agora, o que você vai fazer com essas funções é muito particular. Essas duas funções fazem somente o post, agora dentro do seu contexto de automação você deve chamá-las…

Descentralização de consumo na internet

mail@dunossauro.com (dunossauro) — Tue, 08 Apr 2025 18:56:49 -0300

[Esse post é o lado inverso deste]

Eu tentei ser o menos sarcástico que consegui nessa postagem. Mas, o estado atual da internet me emputesse e eu perco o controle…

Me sinto cada vez mais fatigado da internet, sei que não sou só eu que me sinto assim, então acredito que precisamos conversar…

Grande parte do nosso consumo na rede vem por meio de algorítimos… Você pode até pensar que esse é um papo da “nossa década”, mas, na verdade, esse problema é um pouco maior e mais complicado do que isso. O consumo algoritmo está na raiz de tudo que consumimos!

Já se perguntou como você procura por qualquer coisa na internet? Hoje, em 2025, temos três opções:

Um oráculo, como um bom “ancião da internet” você sabe usar um buscador. Google…?. Ele faz tracking de toda a sua vida na plataforma e exibe o “melhor resultado”, não do que você está procurando, mas o melhor baseado nos trackings que ele fez de você.
Em um cercadinho, como um bom “jovem” você sabe que vai encontrar alguém falando sobre o que você quer saber em qualquer rede social. Claro, ela também fez tracking de tudo que você já consumiu antes e vai te dar uma boa resposta enviesada.
Em papagaio estocástico, um modelo de linguagem que te entrega os resultados baseados não no seu tracking, mas no viés de todas as pessoas que o treinaram.

Claro, existe uma quarta forma, mas acho que nenhum boomer que recebe informações pelo zap está lendo esse texto agora…

Perceba que existe um padrão aqui. Não consumimos a internet descentralizada que nos venderam como a grande “revolução”.

Ficou tenso, né? Calma, relaxe assistindo essa série “Achamos que você vai amar isso” e quando der play “antes de assistir, assista esse trailer”… Ah, você desistiu? Por quê?

Já sei, você cansou, vai ouvir sua playlist Feito para [nome de usuário]. Quem sabe sua supermix. Não é possível…

É melhor ir comer. Toma aqui esse cupom de entrega grátis para os “Famosos no ifood”…

pausa para o anúncio da plataforma

Oi, meu nome é Betina, tenho 22 anos 1.042.000, de patrimônio acumulado (5 segundos [pular])

Deu pra sacar o problema? Vou te ajudar a resolver isso… Link do meu linktree (com tracking + UTM) na bio, cupom de 15% de desconto do meu curso “desfodendo a web” na alura… Corra, por tempo limitado…

Achou que a propaganda era só da plataforma? E o anunciante que me contratou?

# É preciso descentralizar…

Imagine se houvesse uma forma de me comunicar diretamente com a fonte da informação e saber exatamente quando ela foi atualizada? Sem intermédio, sem sistemas de notificação, sem dependência algorítmica, sem propaganda, sem poluição visual, somente você e o conteúdo…

Espera… Isso me parece uma tecnologia antiga… Meu deus… Isso já existe? Desde 1995? Os Homo erectus da internet já sindicavam conteúdo sem intermédio de redes sociais? Isso não deve ser possível, já evoluímos, tando dizem…

Como diz meu amigo Pokemao “o futuro da web é o passado”. Emburrecemos, não sabemos nos comunicar diretamente com a fonte de informação.

# feeds

Quase todo lugar na internet, pelo menos os que nós queremos estar, disponibiliza um arquivo de resumo com data e hora de publicação. Os chamados feeds. Existem diversos formatos como RSS (Really Simple Syndication), Atom e json feed.

Basicamente, os sites separam um arquivo no próprio site que contém o conteúdo que queremos consumir.

Sei que feeds soam como “consumo de blogs” da década passada, mas basicamente você pode acompanhar tudo que quiser. Inclusive os blogs.

Se você, como eu, tem gostos peculiares a respeito de música e gosta de conhecer bandas independentes, o bandcamp mantém um feed específico sobre cenas undergrounds do mundo inteiro:

https://daily.bandcamp.com/

Tudo bem, esse é o link das postagens, mas e o feed?

Basta colocar /feed e temos isso:

https://daily.bandcamp.com/feed

O que deve retornar um XML como esse:

...
 <item>
 <title>The Raw, Rebellious Sound of Chile’s New Rock Underground</title>
 <link>https://daily.bandcamp.com/scene-report/chile-rock-emo-punk-scene-report</link>
 <description><![CDATA[<p><a href="https://daily.bandcamp.com/scene-report/chile-rock-emo-punk-scene-report"><img src="https://f4.bcbits.com/img/0039244968_10.jpg"></a></p>

<p>A new wave of Chilean rock, emo, punk, and folk bands channel unrest into bracing songs.</p>
<p>Read full story on the <a href="https://daily.bandcamp.com/scene-report/chile-rock-emo-punk-scene-report">Bandcamp Daily</a>.</p>
]]></description>
 <category>Scene Report</category>
 <pubDate>Mon, 07 Apr 2025 17:59:47 -0000</pubDate>
 <guid isPermaLink="false">182365</guid>
 <dc:creator>Richard Villegas, Maria Contreras</dc:creator>
 <dc:date>2025-04-07T17:59:47Z</dc:date>
 </item>
...

Sim, esse é o tão amado feed! Tem o título, a data, a categoria, o link, quem escreveu, etc…

“Ah… Eduardo… Que papo troncho, quer só pagar de diferentão…”

OK, OK… Jornal? Você lê notícias, não? Todos os jornais que eu conheço tem feeds… Vamos pegar a folha de são Paulo como exemplo

https://www1.folha.uol.com.br/feed/

Você pode seguir qualquer editorial que te agrade!

“Ah… Seu conformista, lendo mídia burguesa…”

OK, o feed da Boi tempo te agrada então?

https://blogdaboitempo.com.br/feed

“Ah… Eu não interesso por música, notícias me deprimem e eu não sou um comunista safado…”

OK, isentão, você é dev né? Sempre é… Você pode seguir releases dos software/bibliotecas/frameworks. Aqui o exemplo das releases do ruff, pq se você é isentão não se importa com dinheiro de VC fazendo open source:

https://github.com/astral-sh/ruff/releases.atom

Troque o user/repo e você terá literalmente o feed de qualquer repositório no github…

“Tá, eu entendi… Mas sou apenas um camponês nesse vasto mundo da internet, consumo coisas normais… Sabe… Tipo YouTube? Um podcast às vezes…”

Vou te contar um segredo, mas não espalha… sabia que feeds podem ser usados pra isso também, né?

https://www.youtube.com/feeds/videos.xml?channel_id=UCAaKeg-BocRqphErdtIUFFw

Esse é o feed (UCAaKeg-BocRqphErdtIUFFw) do meu canal no YouTube, troque o id e acompanhe o canal que você gosta…

Pra podcasts também funciona…

https://feeds.simplecast.com/hwQVm5gy

Esse é o feed do naruhodo, meu podcast preferido… O seu podcast com certeza tem um feed também…

Se você estiver procurando por feeds de coisas diferentes, o OpenRSS tem algumas opções bem diferentes, até mesmo de lives na twitch. Mas, chega de exemplos, CHEGA… Você já entendeu…

# Centralizando a descentralização

Se você não me mandou tomar no cu ainda, sinta-se à vontade. Pode falar “eu tenho cara de quem lê XML com a mente? Ainda mais ficar dando F5 nessa porra o dia todo?”

Calma, floco de neve… Agora você precisa de um leitor de feeds. Um software que vai fazer esse serviço repetitivo de merda de dar F5 a cada delta de tempo e mostrar as novidades. Além de, claro, organizar a bagunça e tornar esse XML legível pra você…

Existem VÁRIOS softwares pra fazer isso. No Android, eu uso o capy reader. Software livre e ainda tem uma capivara no logo. Sem mais explicações da escolha…

Depois de cadastrar seus feeds, você pode ter uma visão parecida com essa. Somente o que você quer ver e em ordem cronológica:

Meu feed no celular

É bom ter um leitor de feeds no celular. Aquele momento de paz, que você pararia por 1 minuto, entraria no xwitter pra ler uma merda que vai te deixar igual ao meme da facada mal dada e dar engajamento pra quem só quer farmar seu rage. Você poderia ler alguma coisa que te interesse e não dar audiência pra babaca… Sua terapia agradece…

Facada mal dada da porra

No PC eu costumo usar o gfeeds com o mesmo feed que eu tenho no celular, afinal… O que não me falta é 1 minuto pra me revoltar nas redes sociais…

O que deve ter uma cara bem parecida com a leitura no celular, mas maior :)

Meu feed no pc

“Ah… Mas eu uso iPhone… Eu uso windows.”

Cada um tem seus defeitos… Não é mesmo… Tenho certeza de que alguém vai te saber recomendar um bom leitor nos comentários desse post.

# OPML

“Eu vou ter que entrar em link por link no celular e depois de perder 1 semana da minha vida, eu vou ter que fazer isso no PC também? Tá me tirando?”

É aí que entra o OPML. Um arquivo que condensa todos os seus feeds em um único XML, você pode ajustar as categorias dos feeds, compartilhar com amizades, exportar para backup, importa em outro gerenciador pra testar em outro programa. Assim, você pode testar o que te deixar mais feliz…

As entradas são bastante simples e o arquivo é lido fácilmente:

<outline text="Balanço e Fúria" title="Balanço e Fúria" description="" type="rss" version="RSS" htmlUrl="" xmlUrl="https://anchor.fm/s/3157c214/podcast/rss"/>

Esse é um exemplo de entrada do podcast “Balanço e Fúria” que eu adoro <3

# E atencão! Se liga ai, que é hora de revisão

Sites mantém uma lista de atualizações, você pode seguir as listas de todos os sites agregar em um gerenciador de feeds e não precisar dos algorítimos pra te mostrar o que você quer ver

flowchart TD
A["Blog X"] e1@--"feed RSS"--> AA[Agregador de feeds]
B["JORNAL"] e2@--"feed RSS"--> AA
C["Youtube"] e3@--"feed ATOM"--> AA
D["Site Y"] e4@--"feed RSS"--> AA
E["Site Z"] e5@--"feed JSON"--> AA
AA --"salva"--> DB
DB@{ shape: cyl, label: "Database" }
AA --"lendo tudo"--> VC["Você no centro!"]
e1@{ animate: true }
e2@{ animate: true }
e3@{ animate: true }
e4@{ animate: true }
e5@{ animate: true }
AA --"exporta"--> F[OPML]
F --"importa em outro"--> AA

Você pode compartilhar e salvar suas preferências usando OPML.

Se você quiser um lugar estranho pra começar… Pode usar o meu OPML pessoal… Aqui

“Ah… Mas eu gosto dos feeds algorítimos”

Entenda… Nem tudo na internet foi escrito pra você…

Golden Slumbers

mail@dunossauro.com (dunossauro) — Wed, 26 Mar 2025 04:25:46 -0300

Sentimentos complexos saem de mim em toneladas de referências, muitas vezes, incapazes de acompanhar.

É e cá estamos nós…

Esse momento me lembra muito o “velho safado”:

arranje uma grande máquina de escrever e assim como os passos que sobem e descem do lado de fora de sua janela

bata na máquina bata forte

faça disso um combate de pesos pesados

Uma das poucas coisas realmente importantes que aprendi com a terapia foi tentar lidar de forma ativa com as coisas que me incomodam e não deixar escondidas no peito. Fazia tempo que nada me doía tanto e eu não sei como escrever sobre esse assunto.

Recentemente, antes do turbilhão, li “O lugar” da Annie Ernaux e senti que ela conseguiu expressar de forma tão graciosa o que me afastava da minha família silenciosamente. Parei finalmente de me sentir culpado por não “estar” lá. Ou talvez eu tenha “passado um pincel de merda no passado”, como Marcus Kim disse a Sasha Tran.

Por escolha própria, ou como resposta traumática, eu vivo a 250km do lugar onde eu cresci. Sempre pronunciando com orgulho: “Longe o suficiente pra não ver todo dia, mas perto o suficiente pra não passar muito tempo”. Por falta de opções, ou talvez por uma teimosia aguda, ela vivia a quase 700km do lugar onde me criou. Como já de se esperar, não nos víamos muito. Não conversávamos muito. Sempre que nos falávamos era por iniciativa dela. Quem me conhece mais de perto sabe que eu tenho um problema crônico em responder mensagens.

Minha mãe era uma pessoa bastante expansiva, faladora. Era muito fácil encontrar ela em qualquer buteco tomando uma ou então em um roda de samba duvidosa. Esbanjava sorrisos, 200kg de sarcasmo a cada meia frase. No velório dela cantaram até um samba. Entre choros e risos, o coro. Andei vendo algumas fotos antigas, de festas, esses dias. Impossível achar uma foto sem um grande riso.

Eu, por estar de fora da festa, sempre soube que existia um abismo ali. Sempre senti que compartilhávamos um demônio obscuro, guardado a sete chaves. Algo que estava nas entrelinhas das frases, uma solidão… Aquele tipo de coisa que machuca na calada da noite. O sentimento de não pertencimento da realidade distorcida da vida.

Quando eu nasci, minha mãe tinha apenas 17 anos. Eu custei a entender isso. Não que isso não fosse um fato consumado e extremamente concreto. Eu custei a entender o que isso significava na existência dela. A fase do descobrimento daquilo que se é. A personalidade de uma mãe jovem é ser mãe. Hoje, com quase o dobro da ideia que ela tinha quando eu nasci, não sei se ainda entendo o significado e o peso que isso tem.

Depois que me tornei adulto, e na base de muita terapia, compreendo as ausências, “fica com o tio ai que eu já venho” e voltando com o sol já raiando. Por mais que esse comportamento ausente tenha custado a minha alma, no fundo, eu gosto de dizer que compreendo.

Nossas últimas conversas, como a maioria das outras, foram frívolas na superfície, mas com as entrelinhas pontilhadas, que ao percorrer sempre levaram ao mesmo lugar as primeiras verdades nobres: dor e sofrimento.

Nos amávamos à nossa maneira. Distantes, mas intimamente enraizados do quanto um carregava do outro.

Olá mundo!

mail@dunossauro.com (dunossauro) — Mon, 18 Dec 2023 03:01:28 -0300

Há muito tempo quero migrar meus posts do Medium para algum lugar. Tenho me recusado a escrever, pois não queria que as coisas fossem para lá. Mas, todas as outras vezes que me via no momento onde “olha, vou escrever um post hoje”. Eu lembrava que não havia feito alguma coisa. Que coisa era essa? Subir um blog. Inúmeras vezes comecei alguma configuração no pelican, mas me dava preguiça de terminar um tema personalizado, outras inúmeras me peguei escrevendo minha própria engine de blogs. Sem sucesso, claro. Decidi hoje que era hora de parar de encolar. Acabei subindo a configuração padrão do hugo para o netlify e começaremos por aqui!

Vou iniciar essa jornada de blog “libertando” todos meus posts antigos do medium e tirar aquele inferno de paywall!

Quem sabe nessa jornada não acabe escrevendo algo que valha a pena?

Eu Piro Quando Voce Passa

mail@dunossauro.com (dunossauro) — Fri, 07 Aug 2020 00:00:00 -0300

Em meados de 2011 eu fazia escola técnica na Etec e lembro de escutar essa música do Pablo Dominguez todos os dias no mesmo horário enquanto estava no ônibus.

Uma das coisas que mais demorei para me acostumar quando mudei para o interior de São Paulo foi o rádio. Sim, eu ouvia muito Nova Brasil FM. Um costume um pouco incomum que acabei adquirindo com a minha mãe. Sempre fui do Hard Core e ouvia muito punk rock também, mas toda vez que eu buscava um pouco de paz eu ligava na nova brasil. Inclusive, estou fazendo isso agora.

O que é um pouco estranho é que a programação não mudou muito nesses 7 anos longe de casa. Longe de eu achar isso ruim, claro, tem muitas coisas nessas músicas, nas vinhetas, que eu não saberia explicar o quão fundo elas tocam. Mas geralmente tenho feito isso nas madrugadas e escutar rádio de madrugada é uma coisa complicada. Claro, existem madrugadas e madrugadas, mas para quem tem insônia, as madrugadas costumam ser mais melancólicas que o normal. Esse simples ato de ouvir rádio me remete a uma infinidade de pensamentos diferentes. Lembro que, quando eu era mais novo, costumava ouvir rádio deitado na laje e ficava olhando as estrelas. Várias vezes eu me perguntava se alguém poderia estar fazendo a mesma coisa que eu. Caso estivessem, como elas estavam se sentindo ouvindo aquela mesma música que eu, vendo o mesmo céu que eu?

Quando eu era mais novo, eu adorava passar noites e mais noites em claro. Assistindo shop time, aqueles programas que mostram as mãos das pessoas vendendo joias, canal do boi. Não sei, mas alguma coisa na madrugada me chama atenção. Lembrei que fazia essas coisas comendo arroz com farofa. Um gosto bem peculiar, para ser bem sincero. Mas essa era minha vida. Eu escrevia muito no meu antigo fotolog nessa época. Uma pena que, quando o fotolog foi descontinuado, eu não quis fazer o backup deles. Mas tem dias que gostaria de lembrar o que estava sentindo. Perdi tudo :/. Mas confesso que só depois da terapia eu comecei a dar mais valor a tudo isso.

Eu deveria escrever mais, mas, ao mesmo tempo em que morro de medo de falar para as pessoas como eu me sinto. Me dá um caderno, um editor em branco, para ver se eu não saio escrevendo. Toda essa relação com textos, com o meu íntimo, sempre foi turbulenta. Morreria sete mortes antes de deixar ver algo sem sentido, como isso que estou escrevendo agora. Que fala sobre mim, sobre as minhas lembranças malucas e não dizem nada a ninguém. Mas o tempo passou tão depressa que não pude entender melhor essa fase da minha vida. Eu me jogava de um namoro em outro, com pessoas que foram muito importantes e das quais tenho boas memórias e grandes aprendizados. Que ficaram para trás como se não fossem nada hoje em dia. Engraçado, para não dizer outra coisa. Eu era um babaca, jovem, mas ainda assim babaca.

Isso me remete a um segredo íntimo, falei sobre isso com poucas pessoas, mas isso vem dessa época da minha vida. Eu lembro de passar semanas ouvindo “Maresia” na versão da Adriana Calcanhotto. “aaaahh se eu fosse marinheiro” e eu pensava em ser o marinheiro do asfalto. Tá, mas o que tem de segredo nisso? Acho que foi por isso que nunca tirei carteira de motorista. Lembro de uma frase do meu pai: “Um dia eu pego esse carro e vou até o fim da BR-116 pra ver onde acaba”. Isso ficou tão fixado na minha cabeça. A BR-116 ficava muito perto de casa. Eu cresci do lado da saída dela em direção a Curitiba.

E eu passei um tempo com essa ideia, arrumar um trabalho qualquer, juntar uma grana e só sumir. Ir até o Uruguai. Viajar só a noite ouvindo nova brasil FM. Sim, por anos eu só quis isso. Parar onde desse e seguir viagem. Mas pra quê? Qual o objetivo? Foi por isso que nunca tirei carteira de motorista. Eu tenho medo de mim mesmo. Quero fugir, mas tenho medo. Só não pensava que, ao fugir, eu ia ter que carregar o meu pior inimigo. Eu mesmo.

Com o tempo, nada mudou. Eu fugi para o interior, falo pouco ou quase nada com a minha família e amigos e vivo em um mundo paralelo de mim mesmo. Às vezes isso custa caro emocionalmente. Faz tempo que não vejo meu irmão, faz tempo que não vejo minha irmã. Meu primo, então, a pessoa que era minha melhor amiga, fez o mesmo. Porra Gabs, eu sinto sua falta às vezes. Mas sempre que penso no Gabriel, eu penso que todas as pessoas das quais eu fugi porque achava que a resposta era fugir.

Toda vez que eu fujo, deixo um buraco e toda vez que ligo o rádio de madrugada, eu passo horas pensando nesses buracos. Por que eu sempre vou embora e deixo tudo pra trás? Por que faço isso todas às vezes? Quando é que eu vou parar?

Por que raios eu liguei o rádio hoje mesmo?

meus sinceros pedidos de perdão

mail@dunossauro.com (dunossauro) — Sat, 08 Feb 2020 00:00:00 -0300

Eu não sou homem pra você. Talvez esse texto todo só precise de uma frase. Mas, talvez, eu precise ser bem mais prolixo, é de praxe, você sabe. Eu falo muito, não tem como você fingir que não sabe.

Não sei por que essas coisas acontecem comigo. Eu tenho um sentimento estúpido reprimido que me faz querer fugir das coisas. Meu histórico de relacionamentos é bem grande e maior do que esse tamanho, talvez seja a frustração que carrego deles junto comigo e vai chegando uma hora em que a gente tem que se olhar no espelho e parar com o “não deu certo” ou talvez o clássico “a gente era bem diferente”. Eu sou um boçal mesmo, mas meu terapeuta vai dizer que isso é uma construção do meu ego em relação ao quadro que me foi apresentado durante a infância. Maldito seja Freud. Talvez o fato de reconhecer tudo isso já seja um grande passo. Mas isso me dá a impressão de que a história não é tão “platônica” assim. Não existe um “ideal”, o cume da honestidade consigo. Eu tenho um certo tipo de inveja dessas pessoas que se conhecem, que se “controlam”. Eu nunca aprendi a ser assim. Na verdade, até um tempo atrás eu não sabia que existiam pessoas assim. Com objetivos, com honestidade em relação aos seus próprios pensamentos e sentimentos. Isso é um pouco novo pra mim. Geralmente, a gente “empurra com a barriga” e vai seguindo para ver o que acontece. Talvez meu terapeuta esteja mesmo certo. Até alguns poucos anos atrás, eu não tinha um emprego “de verdade” e nenhuma perspectiva de “futuro”. Na verdade, eu nunca me importei com isso. Seria meio clichê jovem dizer “não chego aos 30”? Já pensei bastante isso. Na real, eu nunca esperei muita coisa de nada. Nós que crescemos na periferia, em grande parte, compartilhamos um sentimento meio negativista da vida e também não é para menos. Quem de nós vai chegar em algum lugar? Vou me planejar para ter uma vida regada a trabalho braçal e mal remunerado? Não dá pra esperar nada, vai ser uma “bosta” de qualquer jeito.

Um tempo atrás, eu dei uma palestra sobre qualquer coisa e abri ela falando sobre “flow”. O fantástico estado da mente onde seus desafios e habilidades se cruzam. Me senti um vira-lata falando sobre aquilo. Como você avança na pirâmide das necessidades sem o básico? Toda vez que caminho até a terapia, eu penso nisso. Isso vem acompanhado com uma frase icônica e repetida infinitas vezes pelo meu pai. “Psicólogo é coisa de rico”. Se me permite incluir aqui também um “parafraseamento” do tapete vermelho: “Felicidade de pobre é um prato cheio”. Realmente, se usarmos Maslow como base, a estima está bem distante da fisiologia.

Se for seguir à risca tudo isso, talvez faça sentido a racionalização do ser “cuzão” com tudo. Não ter nenhuma perspectiva de futuro faz com que os sentimentos sejam deixados de lado durante a maior parte do tempo. Você acorda cedo e toma uma surra da cidade cinza no ônibus lotado e depois algum “empresario” vai te ordenhar até você não aguentar mais. Aí, é claro, tem a volta pra casa, que é pior que a ida. Em que momento a gente se conecta com o “eu” e faz grandes reflexões sobre nosso estado mental? Não vai rolar, talvez role, mas é babando na cama.

Ainda acompanhado desse sentimento vem a “meritocracia”, se eu trabalhar um pouco mais, acordar um pouco mais cedo, dormir um pouco mais tarde. Isso é um ciclo vicioso e eu fui criado nele. Nossa, dando razão ao meu terapeuta? Ele ficaria orgulhoso.

Bom, eu disse que ia ser prolixo ao ponto de me perder do rumo inicial. Mas é isso, eu nunca tive um momento como esse. Um momento em que pudesse parar para refletir em como tenho me comportado em relação a mim mesmo, aos meus objetivos e aos meus sentimentos. Mas tenho a impressão de estar justificando algo, racionalizando de mais ou até quem sabe vitimizando. Isso tudo, quando olho pra mim, é o que consigo pensar por trás dos sumiços, das mentiras, da distância, do excesso de drogas. Mas parece que esse texto é mais sobre a regência insubstancial do caráter na formação do sujeito. Parece dissimulação, mas na realidade eu ainda não sei. Eu nunca tive um tempo sóbrio para refletir sobre os meus sentimentos, como tenho agora. Parece meio “lacaniano” pensar em mim como o Outro do reflexo de mim mesmo. Mas parece que nessa viagem dentro de mim ainda tenho outros caminhos para percorrer, mais perspectivas para me olhar. Talvez quem sabe eu consiga achar justificativas melhores para esse caráter distorcido, esse medo que não passa de “me dar” para a vida, essa vontade incontrolável de contar pequenas mentiras para parecer mais “cool”.

A verdade com V maiúsculo desse texto é que eu estou tentando. Estou olhando mais pra mim, criando um certo “orgulho” do que construí até aqui. Tentando ter um pouco menos de vergonha da pessoa que eu sou. Tentando ser menos vira-lata. Estou tentando acreditar que existe uma perspectiva de futuro e que nesse futuro eu posso não estar sozinho. O problema é que isso leva um certo tempo e é um esforço grande para errar menos.

Estou tentado.

A Breve Historia Dos Mocks

mail@dunossauro.com (dunossauro) — Sun, 29 Dec 2019 00:00:00 -0300

Texto original postado por Steve Freeman Disponível em: http://www.mockobjects.com/2009/09/brief-history-of-mock-objects.html

# Introdução

As ideias e conceitos por trás de objetos simulados (mocks) não se materializaram em um único dia. Há uma longa história de experimentação, discussão e colaboração entre muitos desenvolvedores diferentes que pegaram a semente de uma ideia e a transformaram em algo mais profundo. O resultado final deve ajudá-lo a desenvolver software; mas a história de fundo da “Criação dos objetos simulados” também é interessante — e também é um testemunho da dedicação das pessoas envolvidas. Espero que revisitar essa história também o inspire a desafiar seus pensamentos sobre o que é possível e a experimentar novas práticas.

# Origens

A história começou em uma rotatória perto da estação Archway, em Londres, no final de 1999. Naquela noite, vários membros de um grupo de arquitetura de software com sede em Londres se reuniram para discutir questões de software. A discussão se voltou para experiências com desenvolvimento ágil e mencionei o impacto que a escrita de testes pareciam ter sobre o nosso código. Isso foi antes da publicação do primeiro livro Extreme Programming, e equipes como a nossa ainda estavam explorando como fazer o desenvolvimento orientado a testes (TDD) — incluindo o que constituía um bom teste. Em particular, notei uma tendência de adicionar o método “getter” a nossos objetos para facilitar o teste. Isso parecia errado, uma vez que poderia ser visto como uma violação dos princípios orientados a objetos, então eu estava interessado nos pensamentos dos outros membros. A conversa foi bastante animada — principalmente centrada na tensão entre o pragmatismo nos testes e o puro design orientado a objetos. Também tivemos um exemplo recente de uma colega, Oli Bye, que excluiu a API do Java Servlet para testar um aplicativo da Web sem um servidor.

Lembro-me particularmente daquela noite de um diagrama grosseiro de uma cebola e sua metáfora em relação as muitas camadas de software, junto com o mantra “Sem Getters! Ponto!” A discussão girou em torno de como descascar com segurança e testar as camadas dessa cebola sem afetar seu design. A solução foi focar na composição dos componentes de software (o grupo havia discutido as idéias de Brad Cox sobre componentes de software muitas vezes antes). Foi uma colisão interessante de opiniões, e a ênfase na composição — agora referida como injeção de dependência — nos deu uma técnica para eliminar os getters que estávamos “pragmaticamente” adicionando aos objetos para que pudéssemos escrever testes para eles.

No dia seguinte, nossa pequena equipe na Connextra começou a colocar a ideia em prática. Removemos os getters das seções do nosso código e usamos uma estratégia de composição adicionando construtores que pegavam os objetos que queríamos testar via getters como parâmetros. A princípio, isso parecia complicado, e nossos dois recrutas recém-formados não estavam convencidos. Eu, no entanto, tinha um histórico em Smalltalk, então para mim a idéia de composição e delegação parecia certa. A imposição de uma regra de “sem getters” parecia uma maneira de obter uma sensação mais orientada a objetos na linguagem Java que estávamos usando.

Ficamos presos por vários dias e começamos a ver alguns padrões surgindo. Muitas de nossas conversas eram sobre a expectativa de que as coisas acontecessem entre nossos objetos, e frequentemente tínhamos variáveis com nomes como expectURL (URLesperada) e expectativa de serviço em nossos objetos injetados. Por outro lado, quando nossos testes falharam, estávamos cansados de entrar em um depurador para ver o que deu errado. Começamos a adicionar variáveis com nomes como realURL (URLreal) e actualServiceName (NomeAtualdoServiço) para permitir que os objetos de teste injetados gerem exceções com mensagens úteis. Imprimir os valores esperados e reais lado a lado nos mostrou imediatamente qual era o problema.

Ao longo de várias semanas, refatoramos essas idéias em um grupo de classes: ExpectationValue (ValorEsperado) para valores únicos, ExpectationList (ListaEsperada) para vários valores em uma ordem específica e ExpectationSet (ConjuntoEsperado) para valores exclusivos em qualquer ordem. Mais tarde, Tung Mac também adicionou o ExpectationCounter (ContadorDeEsperados) para situações em que não queríamos especificar valores explícitos, mas apenas contar o número de chamadas. Começou a parecer que algo interessante estava acontecendo, mas me pareceu tão óbvio que não havia muito o que descrever. Uma tarde, Peter Marks decidiu que deveríamos criar um nome para o que estávamos fazendo — para que pudéssemos ao menos empacotar o código — e, depois de algumas sugestões, propusesse “mock” (simulação). Poderíamos usá-lo tanto como substantivo quanto como verbo, e refatorou muito bem em nosso código, então o adotamos.

# Divulgando a palavra

Nessa época, também iniciamos o London Extreme Tuesday Club (XTC) para compartilhar experiências de Extreme Programming com outras equipes. Durante uma reunião, descrevi nossas experiências de refatoração e expliquei que sentia que isso ajudava nossos desenvolvedores juniores a escrever melhor código orientado a objetos. Terminei a história dizendo: “Mas essa é uma técnica tão óbvia que, com certeza, a maioria das pessoas o faz de qualquer maneira.” Steve apontou que as coisas mais óbvias nem sempre são tão óbvias e geralmente são difíceis de descrever. Ele pensou que isso poderia ser um ótimo trabalho se pudéssemos separar a madeira das árvores, então decidimos colaborar com outro membro do XTC (Philip Craig) e escrever algo para a conferência XP2000. Se nada mais, queríamos ir para Sardenha.

Começamos a separar as ideias e dar a elas um conjunto consistente de nomes, estudando exemplos de códigos reais para entender a essência da técnica. Reportamos novos conceitos que descobrimos para a base de código original da Connextra para validar sua eficácia. Foi um momento emocionante e lembro-me de que demoramos muitas noites para refinar nossas ideias — embora ainda estivéssemos lutando para criar um “arremesso” preciso para objetos simulados. Sabíamos como era usá-los para gerar ótimos códigos, mas descrever essa experiência para outros desenvolvedores que não faziam parte do XTC ainda era um desafio.

O jornal XP2000 e a biblioteca inicial de objetos simulados (mocks) teve uma recepção mista — para alguns foi revolucionário, para outros foi desnecessário. Em retrospecto, o fato de o Java não ter um bom Reflection quando começamos significava que muitas das etapas eram manuais ou aumentadas com ferramentas de geração de código. Isso afastou as pessoas — elas não conseguiram separar a idéia da implementação.

# Outra Geração

A história continua quando Nat Pryce pegou as idéias e as implementou em Ruby. Ele explorou o reflection do Ruby para escrever o que era esperado diretamente nos blocos de teste. Influenciado pelo seu trabalho de doutorado em protocolos entre componentes, sua biblioteca mudou a ênfase de fazer asserts em valores de parâmetro para fazer assert em mensagens enviadas entre objetos. Nat então portou sua implementação para Java, usando o novo tipo de Proxy no Java 1.3 e definindo o resultado esperado com objetos “restritos”. Quando Nat nos mostrou esse trabalho, ele imediatamente deu um estalo em nossas mentes.

Ele doou sua biblioteca para o projeto de mocks e visitou os escritórios do Connextra, onde trabalhamos juntos para adicionar recursos necessários aos desenvolvedores do Connextra.

Com Nat no escritório onde mocks estavam sendo usados constantemente, fomos levados a usar suas melhorias para fornecer mensagens de falha mais descritivas. Tínhamos visto nossos desenvolvedores ficarem atolados quando o motivo de uma falha no teste não era óbvio o suficiente (mais tarde, observamos que isso geralmente indicava que um objeto tinha muitas responsabilidades). Agora, as restrições nos permitiram escrever testes mais expressivos e com melhores diagnósticos de falhas, pois os objetos de restrição podiam explicar o que havia de errado. Por exemplo, uma falha em uma restrição stringBegins (StringComeça) pode produzir uma mensagem como:

Expected a string parameter beginning with "http" but was called with a value of "ftp.domain.com"S

(tradução do erro)

Esperava-se um parâmetro de sequência começando com "http" mas foi chamado com um valor de "ftp.domain.com"

Lançamos a nova versão aprimorada da biblioteca de Nat sob o nome Dynamock.

À medida que aprimoramos a biblioteca, mais programadores começaram a usá-la, o que introduziu novos requisitos. Começamos a adicionar mais e mais opções à API até que, eventualmente, ficou muito difícil de manter — principalmente porque precisávamos oferecer suporte a várias versões do Java. Enquanto isso, Steve se cansava da duplicação na sintaxe necessária para configurar os valores esperados, então ele apresentou uma versão de chamadas em cascata em Smalltalk — várias chamadas para o mesmo objeto.

Então, Steve notou que em uma linguagem de tipo estaticamente como Java, uma cascata poderia retornar uma cadeia de interfaces para controlar quando os métodos são disponibilizados para quem os invocou — na verdade, poderíamos usar tipos para codificar um workflow. Steve também queria melhorar a experiência de programação, orientando a nova geração de IDEs para solicitar as opções “certas” de autocomplete.

Ao longo de um ano, Steve e Nat, com muita participação de todos nós, pressionaram bastante a ideia para produzir o jMock, uma API expressiva sobre a estrutura original do Dynamock. Isso também foi portado para C# como NMock. Em algum momento desse processo, eles perceberam que estavam realmente escrevendo uma linguagem em Java que poderia ser usada para descrever valores esperados; eles escreveram isso mais tarde em um artigo da OOPLSA

# Consolidação

Através da nossa experiência na Connextra e em outras empresas, e através de muitas apresentações, aprimoramos nosso entendimento e comunicação das ideias de objetos simulados. Steve (inspirado em alguns dos primeiros materiais de lean software) cunhou o termo “needs-driven development” (desenvolvimento orientado às necessidades) e Joe Walnes, outro colega, desenhou uma boa visualização das ilhas de objetos que se comunicavam. Joe também teve a ideia de usar objetos simulados para conduzir o design de interfaces entre objetos. Na época, estávamos lutando para promover a ideia de usar mocks como uma ferramenta de design; muitas pessoas (incluindo alguns autores) viram isso apenas como uma técnica para acelerar os testes de unidade. Joe cortou todas as barreiras conceituais com sua heurística simples de “Only mock types you own.” (Simule apenas os tipos que você possui).

Pegamos todas essas ideias e escrevemos um segundo documento da conferência, “Mock Roles not Objects” (simule papéis, não objetos). Nossa descrição inicial tinha se concentrado demais na implementação, enquanto a ideia crítica era que a técnica enfatizasse os papéis que os objetos desempenham um para o outro. Quando os desenvolvedores usam bem os objetos simulados, eu os observo desenhando diagramas do que eles querem testar ou usando cartões CRC para interpretar relacionamentos — eles se traduzem bem em objetos simulados e testes que conduzem o código necessário. Desde então, Nat e Steve reformularam o jMock para produzir o jMock2, e Joe extraiu restrições na biblioteca Hamcrest (agora adotada pela JUnit). Agora também há uma grande variedade de bibliotecas de mocks, em muitas linguagens diferentes.

Os resultados valeram o esforço. Acho que podemos finalmente dizer que agora existe uma técnica bem documentada e polida que ajuda você a escrever um software melhor. Desses humildes inícios, este livro resume anos de experiência de todos nós que colaboramos e adiciona os conhecimentos de programação de Steve e Nat e uma cuidadosa atenção aos detalhes para produzir algo que é maior que a soma de suas partes.

Chegou a hora de conversar sobre estupro

mail@dunossauro.com (dunossauro) — Tue, 03 Sep 2019 00:00:00 -0300

Essa semana completa um ano que comecei a fazer terapia. Decidi que em algum momento eu ia ter que colocar isso pra fora. Nunca é fácil falar sobre isso. Não é uma coisa que você joga na roda e debate com seus amigos. Não é uma coisa que você conversa com sua família ou mesmo que você fala na terapia. Simplesmente não existe um bom momento para falar sobre isso. Mas faz dias que não durmo e essa coisa me assombra. Não foi nada que vi em um filme de terror, não é nada que consigo conceber de maneira literal. É um sentimento, um sentimento que achei que ia passar com o tempo e não passou. Essas memórias vem a tona em momentos diversos, sabe? Uma vez eu estava no metrô e alguém me puxou pelo braço e a única reação que tive foi sentar no chão e chorar. Não dá pra explicar.

Essas coisas aconteceram entre 2005 e 2006. Eu tinha 11 anos, claramente eu não estava entendendo o que estava acontecendo. Vamos chamar de “brincadeira”. Um adulto me chamou para “brincar”. A brincadeira era assim: A gente fica pelado e pega um no brinquedo do outro. A primeira vez que brincamos ele pediu para eu colocar o brinquedo dele na boca e em uma sequência não muito longa de vais-e-vens ele ejaculou na minha boca. Ele me disse que essa brincadeira era secreta e que eu não deveria contar para mais ninguém sobre ela. Assim por algumas semanas.

Depois uma nova “brincadeira” foi estabelecida. O adulto começou com uma mania de assistir pessoas “brincando” na TV enquanto apalpava a minha retaguarda ou enquanto eu fazia uma “massagem com a boca” até o momento da ejaculação. Esse tipo de “brincadeira” durou uns 4 ou 5 dias. Até que um novo ciclo de “brincadeiras” foi estabelecido. Talvez me falte uma palavra para descrever com exatidão essa “brincadeira”. Acho que roçar possa ser o mais próximo da descrição sobre o movimento. Pense em um “brincadeira” heterossexual sem penetração. Ele “brincava” de roçar o seu brinquedo enquanto me deixava de costas e segurava meus braços para que não me afastasse. De maneira não muito agressiva ele aproximava seu rosto em minha nuca enquanto segurava meus braços e grunia de prazer.

Assim foram dois dias até a “brincadeira” de verdade começar. Eu andei de skate por anos e quebrei vários ossos, mas não lembro de ter sentido uma dor tão grande como senti aquele dia. Mas chorei calado. As lágrimas escorreram, mas não fiz absolutamente nenhum barulho. Eu não consigo me lembrar de nada da primeira vez. É um misto de um escuro absoluto e com muita dor. Até hoje ainda consigo “sentir” esse momento. Os meus braços sendo segurados com força e uma dor que nos dias de hoje eu não suportaria. “Entrou”, foi o que ouvi. Isso aconteceu mais uma vez, depois de um certo tempo e eu literalmente não tenho estômago para falar sobre isso.

…

Nunca tive uma proximidade grande com meus pais, caso você ainda não tenha se perguntado sobre isso. O adulto a qual me refiro era a pessoa em quem eu mais confiava quando criança, talvez a pessoa mais próxima de mim durante muitos anos. Não achava que tinha problemas em “brincar”, na realidade e nem sabia o que estava fazendo. O preço disso foi cobrado anos mais tarde, sim, levei anos para entender o que tinha acontecido naquele período.

Durante minha adolescência eu tentei cavar isso o mais fundo que pude, na verdade durante parte da minha fase adulta também. Mas isso tem me corroído, de tal formar que não sei explicar. Tem semanas em que não consigo por um dia sequer tirar essas memórias de dentro da minha cabeça. As vezes tenho movimentos involuntários quando vejo alguém que se parece o adulto da história. Eu tenho vontade de correr, de chorar. De fazer qualquer coisa para que eu possa desaparecer o mais rápido possível. Faz dias que não durmo pensando nisso. Talvez colocar pra fora me ajude. Talvez não, mais isso não faz diferença.

Fora toda essa frustração esse sentimento escroto que nunca desaparece, conforme o tempo vai passando eu vejo crianças. Filhos de amigos meus, meus irmãos, as crianças da minha família, crianças na rua e me faço uma série de questionamentos que não fazem sentido. É complicado entender uma mente doentia como a do adulto.

Antes que eu me rebaixe a dizer palavras de baixo calão, usar de um vocabulário sujo eu vou parar.

Força pra nós ❤

Estimando o custo total de desenvolvimento de uma distribuicao linux

mail@dunossauro.com (dunossauro) — Sat, 18 May 2019 00:00:00 -0300

Esse artigo é uma livre tradução de: https://www.linuxfoundation.org/events/2008/10/estimating-the-total-cost-of-a-linux-distribution/

Autores: Amanda McPherson, Brian Proffitt, and Ron Hale-Evans

O sistema operacional Linux é o projeto de código aberto mais bem-sucedido da história, mas o quanto vale o software em uma distribuição Linux? Em 2002, David A. Wheeler publicou um estudo bem conceituado que examinou as linhas de software de código presentes em uma distribuição típica do Linux. Suas descobertas? O custo total de desenvolvimento representado em uma distribuição típica do Linux foi de US $ 1,2 bilhão. Usamos suas ferramentas e métodos para atualizar essas descobertas. Usando as mesmas ferramentas, estimamos que seriam necessários aproximadamente US $ 10,8 bilhões para construir a distribuição do Fedora 9 em dólares atuais, com os custos atuais de desenvolvimento de software. Além disso, seriam necessários US $ 1,4 bilhão para desenvolver o kernel Linux sozinho. Este artigo descreve nossa técnica e destaca os custos mais recentes do desenvolvimento do Linux.

O sistema operacional Linux é o sistema operacional de código aberto mais popular da computação atual, representando um ecossistema de US $ 25 bilhões em 2008. Desde a sua criação em 1991, ela cresceu para se tornar uma força na computação, impulsionando tudo, desde a Bolsa de Nova York até telefones celulares, supercomputadores e dispositivos de consumo.

Como um sistema operacional aberto, o Linux é desenvolvido de forma colaborativa, o que significa que nenhuma empresa é a única responsável por seu desenvolvimento ou suporte contínuo. As empresas que participam da economia Linux compartilham os custos de pesquisa e desenvolvimento com seus parceiros e concorrentes. Essa disseminação da carga de desenvolvimento entre indivíduos e empresas resultou em um ecossistema grande e eficiente e em inovações de software não divulgadas.

Mais de 1.000 desenvolvedores, de pelo menos 100 empresas diferentes, contribuem para cada lançamento do kernel. Nos últimos dois anos, mais de 3.200 desenvolvedores de 200 empresas contribuíram para o kernel. É importante observar que o kernel é apenas uma pequena parte de uma distribuição do Linux. Uma distribuição é, na verdade, composta de vários componentes, incluindo o kernel, os ambientes de área de trabalho GNOME e KDE, os componentes GNU, o sistema de janelas X e muitos mais. O total de desenvolvedores individuais que contribuem para esses projetos certamente chega aos milhares.

Como o Linux foi desenvolvido coletivamente, não há uma única fonte de estimativas de custo de quanto foi necessário para desenvolver a tecnologia. Em 2002, David A. Wheeler publicou um estudo bem conceituado que examinou as linhas de software de código presentes em uma distribuição típica do Linux (Red Hat Linux 7.1) Ele concluiu — como fizemos — que as linhas de código de software são o método mais prático para determinar o valor do software de código aberto, uma vez que se concentra no resultado final e não nas estimativas por empresa ou por desenvolvedor. Usando as ferramentas padrão do setor que ele desenvolveu para contar e analisar o SLOC, ele determinou que custaria mais de US $ 1,2 bilhão para desenvolver uma distribuição Linux por meio de propriedade convencional nos EUA.

Isso foi há seis anos. Como o Linux está inovando e crescendo a uma taxa alta ano após ano, o número de US $ 1,2 bilhão precisou ser atualizado para refletir o verdadeiro valor do desenvolvimento refletido no Linux hoje (e o aumento do custo do próprio desenvolvimento de software). Para este documento, a Linux Foundation determinou o custo total de desenvolvimento representado em uma distribuição típica do Linux e atualizou o número de US $ 1,2 bilhão amplamente utilizado desde sua publicação em 2002.

Analisamos a distribuição do Fedora 9, que foi lançada em 13 de maio de 2008. É uma distribuição popular e bem usada e é a base para o Red Hat Enterprise Linux, que representa uma grande porcentagem do mercado de Linux. É também um descendente direto do software Red Hat Linux 7.1 analisado por Wheeler em seu artigo original.

Para este estudo, usamos a conhecida ferramenta SLOC de David A. Wheeler, SLOCCount. O SLOCCount utiliza o padrão COdstructive COst MOdel (COCOMO) padrão da indústria, um modelo algorítmico de estimativa de custos de software desenvolvido por Barry Boehm. O modelo usa uma fórmula básica de regressão, com parâmetros que são derivados de dados históricos de projetos e características atuais do projeto. Atualizamos seu estudo de 2002 para incluir a crescente base de código do kernel Linux e outros pacotes, bem como o maior salário anual de um desenvolvedor de software. (Mais detalhes sobre isso seguem na seção Abordagem do artigo.)

Usando essa abordagem, estimamos que seriam necessários US $ 10,8 bilhões para desenvolver a distribuição Linux do Fedora 9 por meios proprietários tradicionais no ano de 2008.

# Abordagem

Nossa abordagem básica era (Para aqueles que estão interessados em como instalamos e analisamos o código fonte, por favor, veja o Apêndice do artigo original):

Instale os arquivos de código-fonte no formato descompactado; isso requer baixar o código-fonte e instalá-lo corretamente em nossas máquinas de teste.
Conte o número de linhas de código de origem (SLOC); o que requer uma definição cuidadosa do SLOC.
Use um modelo de estimativa (com base nas práticas do COCOMO) para estimar o esforço e o custo de desenvolver o mesmo sistema de maneira proprietária.

Para atualizar o estudo de 2002, foi decidido que usaríamos o mesmo código base usado no estudo de 2002, o Fedora — a distribuição da comunidade que forma a base do Red Hat Enterprise Linux. Para nosso exame, decidimos usar o Fedora. Contamos todos os pacotes disponíveis do Fedora 9 que foram tornados públicos no arquivo espelho mirrors.kernel.org. Decidiu-se usar todos os pacotes porque não desejávamos usar uma definição arbitrária do sabor do Fedora 9 que mediríamos. O Fedora contém significativamente mais software do que a versão corporativa da Red Hat. Uma razão para isso é que uma comunidade diversificada está envolvida na construção do Fedora, não apenas em uma empresa. Usar o aplicativo SLOCCount é uma tarefa incrivelmente simples: é simplesmente uma questão de apontá-lo no diretório correto onde o código-fonte reside e deixá-lo rodar. Uma explicação detalhada de como o programa funciona e como usá-lo ainda está disponível no site da Wheeler9.

Para calcular os custos dessas distribuições, foi encontrado um salário-base para programadores de computador do Bureau of Labor Statistics dos EUA. De acordo com o BLS, o salário médio de um programador norte-americano em julho de 2008 foi de US $ 75.662,08. Este era o valor do salário usado em nossa execução no SLOCCount. (É claro que a maioria dos desenvolvimentos de software hoje em dia é global, portanto usar um número de salário apenas nos EUA é um tanto ilusório. Uma maneira de continuar explorando seria determinar um salário médio global a ser usado como base para os custos de produção).

Deve-se notar que o salário sozinho não é o único determinante dos custos de desenvolvimento de software. Em seus artigos, Wheeler observa a presença do parâmetro overhead dentro do SLOCCount. Isso leva em consideração os custos de testes, equipamentos, custos operacionais da empresa e remuneração total para o desenvolvedor. Esse parâmetro também é conhecido como taxa de quebra.

Como apenas um exemplo de como esses custos podem aumentar rapidamente, nos Estados Unidos, o percentual médio de remuneração (dias de doença, férias, benefícios de seguro) para um funcionário profissional é de 29,0% 11. Assim, o programador que faz o salário médio dos EUA de US $ 75.662,08 está realmente custando ao empregador US $ 97.604,08 em compensação sozinho. Esta é apenas uma parte da torta de taxa de envoltório total.

A própria estimativa de Wheeler do valor total da taxa de empacotamento é 2,4. Embora esse número varie claramente por empresa e região, pesquisas adicionais não mostraram nenhuma evidência significativa de que esse número precisaria de ajuste para nossos testes.

## Código-fonte e resultados de custos estimados

Finalmente, considerando todas as suposições mostradas anteriormente, o SLOC e os valores de produção estimados para o Fedora 9 são os seguintes.

Linhas de código fonte físicas totais (SLOC)

204,500,946

(Modelo básico COCOMO, Pessoa-meses = 2,4 * (KSLOC ** 1,05)) 59389.53 (712674.36)

Estimativa do cronograma, anos (meses) (Modelo básico de COCOMO, Meses = 2,5 * (pessoa-meses ** 0,38))

24.64 (295.68)

Custo total estimado para desenvolver

$10,784,484,309

Como um aparte: o valor do salário anual do SLOCCount original era de US $ 56.286 em dólares do ano 2000, então é interessante ver como os custos de hoje se traduzem nos mesmos custos do ano 2000. Para descobrir isso, multiplicamos o custo total para desenvolver o Fedora 9 em dólares de 2008 (US $ 10.784.484.309) em 0,744, que é a razão entre o salário do programador do ano 2000 normalmente usado pelo SLOCCount (US $ 56.286) e o salário de julho de 2008 que encontramos (US $ 75.662,08). O resultado é pouco mais de US $ 8 bilhões para desenvolver os custos do Fedora 9 em 2000. Isso dá ao leitor uma boa indicação de quanto código e funcionalidade foram adicionados a uma distribuição Linux nesses seis anos.

# Focando no Kernel Linux e no Modelo Intermediário

Como a pesquisa foi conduzida para este artigo, ficou rapidamente aparente que nem todos os componentes dentro de uma dada distribuição Linux precisavam ser tratados igualmente. Alguns projetos, por sua própria natureza e complexidade, precisam de consideração diferente no modelo COCOMO.

Em nenhum lugar isso ficou mais aparente do que no próprio artigo de 2002 de Wheeler, onde ele destacou a necessidade de um modelo de estimativa diferente para o próprio kernel Linux. Nesse novo artigo, Wheeler afirmou que, como o código do kernel é tipicamente mais complexa do que uma aplicação “média” — entre outras coisas — requer uma análise que vai além do modelo básico do COCOMO. Um aplicativo de espaço do usuário como o Mozilla, por exemplo, é muito mais fácil de codificar linha por linha, já que é abstraído em um nível muito mais alto e tem que lidar com muito menos tarefas. Um kernel de sistema operacional moderno e de classe empresarial é solicitado a fazer um grande número de coisas extremamente complexas, todas de uma vez.

Wheeler explica que, em vez de usar o método padrão usado para analisar todos os elementos de uma distribuição, deve-se usar o modelo COCOMO intermediário para contar apenas o kernel. O método intermediário tem mais variáveis para escolher e, portanto, deve ser mais preciso para analisar um software complexo por conta própria. No artigo de 2004, ele detalha suas estimativas para esses parâmetros, que têm o efeito líquido de ajustar o valor do fator de esforço geral no SLOCCount do padrão de 3 para um novo valor de 4.64607. Ao mesmo tempo, o valor expoente de — esforço também é alterado para 1,12, que é o valor atribuído a projetos de software semideminados no modelo intermediário de estimativa de software COCOMO.

Com esses novos parâmetros em mente, um teste separado foi executado no kernel Linux padrão que foi incluído no Fedora 9, linux-2.6.25.i686:

Linhas de código fonte físicas totais (SLOC)

6,772,902

(Modelo básico COCOMO, Pessoa-meses = 2,4 * (KSLOC ** 1,05))

7557.4 (90688.77)

Estimativa do cronograma, anos (meses) (Modelo básico de COCOMO, Meses = 2,5 * (pessoa-meses ** 0,38))

15.95 (191.34)

Número médio estimado de desenvolvedores (esforço / cronograma)

473.96

Custo total estimado para desenvolver

$1,372,340,206

# Limitações e vantagens para a abordagem deste estudo

Não existe uma maneira perfeita de estimar o valor de algo tão complexo e evolutivo quanto o Linux. Embora este método seja a melhor abordagem, ele provavelmente supera alguns aspectos de valor, enquanto subestima os outros. Aqui está um resumo dessas limitações:

O modelo COCOMO foi projetado a partir de pesquisas sobre desenvolvimento de software proprietário

Por causa disso, sentimos que isso subestima a complexidade de testes inerente a projetos de software de código aberto desenvolvidos colaborativamente como o Linux. Devido às grandes quantidades de mudanças, pequenas e grandes, e à natureza distribuída de desenvolvedores e projetos independentes, a carga de testes nos participantes do ecossistema Linux é em uma ordem de magnitude mais alta do que para empresas proprietárias autônomas.

Outra dificuldade em medir o valor de uma distribuição Linux é simplesmente determinar o que compreende uma distribuição Linux para começar

Incluímos todos os pacotes no repositório público de código fonte do Fedora. Mas certamente existem distribuições menores até mesmo do Fedora (a versão do LiveCD, por exemplo). Existem também distribuições maiores; O repositório do Debian GNU / Linux13 é maior que o do Fedora, por exemplo. Há também uma grande quantidade de software de código aberto que não é encontrado em nenhuma das distribuições. É um grande universo de código aberto, por isso tentamos confiar nos pacotes disponíveis de uma distribuição.

A maior fraqueza na análise de SLOC é seu foco em adições líquidas a projetos de software

Qualquer um que esteja familiarizado com o desenvolvimento do kernel, por exemplo, percebe que o maior custo de energia do homem em seu desenvolvimento é quando o código é excluído e modificado. A quantidade de esforço necessário para excluir e alterar o código, e não apenas adicioná-lo, não se reflete nos valores associados a essa estimativa. Como em um modelo de desenvolvimento colaborativo, o código é desenvolvido e, em seguida, alterado e excluído, o valor real é muito maior que a base de código existente. Basta pensar no processo: quando algumas linhas de código são adicionadas ao kernel, por exemplo, muitas outras precisam ser modificadas para serem compatíveis com essa mudança. O trabalho que envolve a compreensão das dependências e dos resultados e a alteração desse código não está bem representado neste estudo.

O desenvolvimento colaborativo significa que você geralmente terá vários indivíduos ou grupos trabalhando em diferentes abordagens para resolver o mesmo problema técnico com apenas uma dessas abordagens “ganhando” a inclusão na versão final

Como as abordagens “perdedoras” não estão comprometidas com o produto final, essa abordagem não leva em conta o esforço de desenvolvimento para essas abordagens.

Existem significativas linhas de software de diferenças de código entre distribuições e até diferentes versões de distribuições, por isso é enganoso considerar que uma análise é a estimativa canônica do valor de “Linux”

Existem muitas opções diferentes em que analisar e escolhemos apenas 1. Por essa razão, achamos que as estimativas de pacotes discretos que todas as distribuições compartilham (o kernel, por exemplo) são mais interessantes.

Infelizmente, esse método equivale a valor para quantidade

A comunidade Linux leva o “inchaço” muito a sério, mas ao mesmo tempo o Linux contém muito código — como drivers antigos — não usado com muita frequência. No entanto, a inclusão desse código é importante, pois tanto o código específico da arquitetura quanto os drivers são incluídos no Linux (ao contrário de outros sistemas operacionais). Como efeito disso, esse número seria maior do que em outros sistemas operacionais que não incluam esses componentes no próprio sistema operacional.

Este estudo pressupõe que todo o desenvolvimento ocorreria nos EUA, com o custo associado do trabalho dos EUA

A maior parte do desenvolvimento de software é de natureza global e seus custos de mão-de-obra variam de acordo.

Os números refletidos neste estudo representam quanto custaria desenvolver o software em uma distribuição Linux hoje, do zero

É importante notar que isso estima o custo, mas não o valor, para o ecossistema maior, já que a mudança de uma tecnologia tão amplamente utilizada teria um impacto econômico enorme e de longo alcance.

# Como o Linux cresceu?

Este estudo também não leva em conta os custos anuais de desenvolvimento para atualizar e aumentar a base de código Linux. Com base nesses números (ou na experiência direta de qualquer pessoa com uma distribuição do Linux), é fácil ver como a funcionalidade incluída em uma distribuição do Linux explodiu nos últimos seis anos.

Por exemplo, o Fedora Linux 9 inclui pouco mais de 204 milhões de linhas de código de origem física (SLOC), em comparação com 30 milhões de linhas no Red Hat Linux 7.1 (lançado em 2002) e mais de 17 milhões de linhas na versão 6.2. Assim, em apenas seis anos, a base de código cresceu em 174 milhões de linhas de código. Usando o modelo de custo COCOMO, estimamos que o Fedora 9 tenha requerido cerca de 60.000 pessoas-ano de tempo de desenvolvimento (em comparação a 8.000 pessoas-ano para o Red Hat 7.1 e 4.500 pessoas-ano para a versão 6.2). Assim, o Fedora 9 representa um aumento de aproximadamente 680% no tamanho, um aumento de 750% no esforço e um aumento de 900% nos custos de desenvolvimento tradicionais sobre o Red Hat Linux 7.1. Isso se deve a um aumento no número de programas de software livre / software livre maduros e maduros disponíveis em todo o mundo. Esse crescimento mostra que o Linux tem um grande impulso: a adição contínua de pacotes de software livre fortalece o conjunto de aplicativos disponíveis para usuários Linux e, por sua vez, torna o Linux muito mais atraente como plataforma de computação.

A natureza modular do Linux (em sua composição de uma distribuição) também é aparente pela varredura da lista dos dez principais pacotes incluídos em uma distribuição. Dado o tempo e o interesse, seria interessante, por exemplo, analisar os principais componentes de uma distribuição Linux embarcada e os custos de desenvolvimento associados a esse segmento da computação.

O impacto na inovação do Linux não é medido apenas em linhas adicionais. Como o recente artigo “Quem escreve o kernel Linux” afirma: “Ao longo destes lançamentos, a equipe do kernel tem uma taxa de crescimento muito constante de cerca de 10% ao ano, um número muito impressionante dado o tamanho da árvore de código. Mas o kernel não está apenas crescendo. A cada alteração feita na árvore de origem do kernel, as linhas são adicionadas, modificadas e excluídas para realizar as alterações necessárias ”.

Embora o kernel do Linux provavelmente tenha uma taxa de mudança maior do que a maioria dos outros componentes do Linux, nossos números refletem que, como um todo, o Linux está crescendo e mudando a cada ano em um ritmo constante. Como o kernel do Linux é apenas um pequeno (mas muito importante) componente de uma distribuição Linux, os custos de desenvolvimento iterativo despejados no Linux por ano são substanciais, mas não são examinados neste estudo.

# Conclusões

Então, nós sabemos agora o que vale a pena o Linux? Embora possa não ser uma pergunta capaz de ser respondida completamente, algumas coisas são muito claras: O verdadeiro valor do Linux surge da capacidade de reutilizá-lo e da tremenda flexibilidade que ele cria.

Imagine um mundo da computação em que Linus Torvalds não permitisse (na verdade forçar) os usuários do Linux a permitir que outras pessoas reutilizassem suas contribuições. Haveria um Google se eles não tivessem o uso gratuito do Linux e a capacidade de modificá-lo para atender às suas necessidades? Poderia haver uma nova categoria em expansão de PCs ultra-móveis de menos de US $ 350 sem o uso gratuito de um software de US $ 10,8 bilhões? A Amazon seria capaz de construir sua nova linha de dispositivos de leitura Kindle sem uma parte gratuita de US $ 1,4 bilhão em pesquisa e desenvolvimento? Mais do que apenas dinheiro, o software em uma distribuição Linux representa o tempo. A economia em cada um desses exemplos não teria sido possível se essas empresas tivessem sido forçadas a pagar taxas de licença por dispositivo ou por servidor a qualquer empresa ou tivessem que dedicar os milhares de pessoas-ano de tempo de desenvolvimento para criar esse software.

O que podemos aprender com este estudo? Os custos substanciais de desenvolvimento representados em uma distribuição Linux baseada na comunidade refletem seu crescente valor e importância no mundo da computação. As empresas e indivíduos que trabalham em projetos relacionados ao Linux e criam esse valor lucram compartilhando a carga de desenvolvimento com seus pares (e às vezes com concorrentes). Cada vez mais está ficando claro que assumir essa carga de pesquisa e desenvolvimento individualmente, como a Microsoft fez, é um abordagem cara à construção de software. Embora a posição de monopólio no passado tenha permitido que eles financiem esse enorme desenvolvimento, acreditamos que, na competição futura das forças colaborativas, essa posição isolada será insustentável.

Como podemos ver neste estudo e através da explosão do Linux em todas as áreas da computação, o desenvolvimento colaborativo cria um enorme valor econômico. Empresas como a IBM, a Intel, a HP, a Fujitsu, a NEC, a Hitachi, a Google, a Novell, a Oracle, a Red Hat e muitas outras participaram e lucraram com o enorme ecossistema criado por este modelo aberto de desenvolvimento de software. Mas não se engane: enquanto as empresas participam, os indivíduos são tão importantes na expansão deste software e seu valor. É assim que tudo começou depois de tudo.

— — — — — — — — — — — — — — —-

Os dados neste documento foram gerados pelo SLOCCount, Copyright © 2001–2004 David A. Wheeler O SLOCCount é Software de Código Aberto / Software Livre, licenciado sob a GNU GPL. SLOCCount vem com ABSOLUTAMENTE NENHUMA GARANTIA, e você está convidado a redistribuí-lo sob certas condições, conforme especificado pela licença GNU GPL; veja a documentação para detalhes.

— — — — — — — — — — — — — — — —

# Agradecimentos

Gostaríamos de agradecer às seguintes pessoas por revisar e fornecer feedback sobre este artigo: James Bottomley, Jon Corbet e David A. Wheeler.

Precisamos falar sobre a Live de python

mail@dunossauro.com (dunossauro) — Thu, 04 Apr 2019 00:00:00 -0300

Em maio desse ano, a live vai fazer 2 anos e o tempo que passou não me fez parar de acreditar que esse projeto é “tosco”. Não veja isso como um adjetivo ruim, o objetivo desse texto é explorar o “tosco”.

Já contei essa história milhares de vezes, mas isso nunca vai deixar de ser verdade. A live nasceu em um dia qualquer, uma quarta-feira, como uma ideia de “codar” online e me distrair da “mundana vida capitalista”. O objetivo era esse, aliviar o estresse fazendo a coisa que mais gosto de fazer: Programar. Dois anos se passaram e vejo que toda a metamorfose que rola na minha cabeça sobre os ideais que me motivam a continuar investindo todos meus domingos nesse projeto. Esse, “codar”, talvez seja o único que tenha se mantido intacto, embora ele não seja nem de longe tão “glamouroso” quanto “os ideais do software livre”, a “democratização do conhecimento”, “tentar atingir quem talvez não tenha ‘estrutura’ para chegar nesse conteúdo”, “fazer conteúdo em português”, etc.., etc…, etc…

Uns dias atrás, eu estava relembrando algumas conversas que tive com minha ex-namorada. Eu pincelei a ideia de estar tocando esse projeto e ela me disse uma coisa [palavras não literais] “você sempre soube que faria isso, mesmo que agisse de maneira contrária. Como se ensinar fosse uma opção pra você. Nunca foi, você é isso” e hoje as coisas estão dando piruetas na minha cabeça por pensar nessas coisas. Toda essa parada de DIY (Faça você mesmo) tem uma raiz muito forte dentro de mim. Essa sensação de “Vai lá e faz, mesmo que fique tosco”. Quando eu era adolescente, a gente tinha caixotes de feira e martelos e fazia “palquinhos” pra andar de skate. Hoje eu tenho internet e boa vontade e a gente faz “““Educação”””. E embora eu tenha um certo receio de pronunciar essa palavra: educação, Educação, EDUCAÇÃO. Tive que procurar no oráculo

No seu sentido mais amplo, educação significa o meio em que os hábitos, costumes e valores de uma comunidade são transferidos de uma geração para a geração seguinte.

Então, nesse caso, a gente pode usar essa palavra, embora eu ainda tenha um certo medo de toda “diplomacia” que essa palavra carrega. Isso é uma maneira de fazer repasse de informações para a “nova geração”. Essa coisa de não usar termos como “Aula” vai sempre continuar existindo dentro de mim. Foi então que hoje a tarde eu estava lembrando de um matemático um tanto quanto genial, Fermat. Ele ganhou o título de “Príncipe dos amadores”. Ele era bom, ele era incrível, mas não era profissional. Ele era o melhor amador, o príncipe deles. Tanto que todas as suas descobertas foram enviadas por carta, por anotações que ele mesmo fazia em seus livros. Nada é conclusivo, ele era um amador com estilo. Esse talvez seja o ponto chave de tudo que quero dizer com a palavra “tosco”. Voltamos ao oráculo

Tosco significa rude, desajeitado ou algo no seu estado bruto

Aceitaria usar a palavra que não deve ser dita, mas só se ela for dita com tosco junto. A live é uma forma “tosca de educação”. É uma didática tosca, uma aula tosca, um professor tosco. É uma maneira descompromissada, desajeitada, não profissional, sem recursos. Mas incrivelmente cheia de boas intenções. É um “vai lá e faz com o que você tem agora”.

Dito tudo isso, e entendendo que não há vergonha alguma em ser amador, inclusive me sinto mais livre para pairar sobre os outros ideais. Essa não é filosofia por trás do software livre? Compartilhar o máximo possível, desburocratizar o conhecimento, deixar acessível. É essa coisa que me atrai. Um(a) jovem feliz porque entendeu como fazer algo, que viu uma possibilidade nova em algo que não fazia parte do seu repertório. Uma galera que pode passar o pouco que “ensinei” para frente e que a galera que aprendeu passe pra frente em um ciclo infinito de iterações.

O objetivo é derrubar muros, deixar acessível, aberto. Quanto mais todos vocês aprenderem, mais vocês vão ensinar e um dia tudo isso volta e não só volta em formato de educação. Mas com amizades, empregos, estrutura, sorrisos e diversão.

Me sinto honrado em fazer parte disso.

Teu trampo não te define

mail@dunossauro.com (dunossauro) — Thu, 21 Feb 2019 00:00:00 -0300

Escrevo isso enquanto fumo mais do que devia e um horário em já deveria estar na cama. Mas eu simplesmente não consigo parar de pensar nisso. Sim, não vou corrigir gramática aqui.

Hoje eu estava ouvindo o primeiro ep. do podcast do @renzopro onde ele fez uma pergunta extremamente simples

O que você quer fazer?

Ao efeito disso, me tentei me colocar em algumas posições. A pergunta é simples e curta, mas ela é carregada de um sentimento introspectivo da parte de quem escuta. A pergunta pode parecer extremamente simples de ser respondida. MAAASSS, vamos parar por um minuto. Onde você está exatamente agora? Você está realmente feliz? O que você faz te satisfaz?

Apesar de existirem pessoas que vão responder, sim, a todas essas perguntas, algumas pessoas não. Isso me faz lembrar dos passos para alcançar paz de espírito em todas as decisões morais da sua vida.

Existem coisas que (Por Mario Sergio Cortella):

Você pode fazer
Você quer fazer
Você deve fazer

Agora vamos pensar que tudo isso é uma grande permutação e negativas dentro de um mesmo argumento. Existem coisas que você quer, pode, mas não deve. Coisas que você não quer, mas deve e pode. Coisas que você deve, mas não quer e não pode. E a paz de espírito está no “Quero, posso e devo” Mas o caso que mais me incomoda é o seguinte:

Existem coisas que você não quer, mas deve e pode

Muitas vezes a gente se encontra em um relacionamento abusivo que parte desse princípio. ~aqui estou me referindo a todos os tipos ~ Mas queria especialmente falar sobre trabalho. E sim, minha adolescência punk rock nunca vai me deixar falar de maneira positiva sobre isso, mas bem vindos ao capitalismo…

Você já pensou no que você quer realmente fazer da sua vida? Se sua resposta não foi algo parecido com “deitar na rede sentindo a brisa do vento da manhã” você ainda não pensou o suficiente. Mas pra fazer isso, você possivelmente deveria ter uma forma de sustento e que rendesse o suficiente para que não precisasse mais trabalhar. Sim, você pode começar a colocar parte do seu salário e juntar seu primeiro milhão em renda fixa e alcançar a “tão sonhada independência financeira”. Tá… Vamos voltar a realidade. Se esse for realmente seu objetivo, fica outra pergunta:

Como você está traçando seu caminho em direção rumo a paz de espírito?

Nisso vem a questão do objetivo. Vi alguns vídeos sobre uma galera que vendeu brigadeiros na rua para poder viajar o mundo. É sutil dizer que a paz não estava na venda de brigadeiros? Era o objetivo.

Nesses últimos tempos, venho pensando bastante nisso. O que estou fazendo agora é um passo pra chegar onde eu quero ou estou somente estagnado? É tudo meio aquela música do Belchior “Viver é melhor que sonhar…”. E tem gente que se conforma em andar na direção contrária. A vida é meio paradoxal, não é mesmo? O grande problema que vejo em relação a isso é o sofrimento. Porque se você não vai em direção ao objetivo, você nunca vai chegar. Mas se você já sabe onde ir também tem sofrimento. Partindo do ponto em que o que você faz é exatamente o que você não quer fazer e não existe outra saída.

Com isso vem todo o caso de sofrer, mas jovem, pense bem. Não é a insatisfação com o presente que gera um futuro ruim. Acredito exatamente no contrário. Se tu tá na merda emocional, não existe nada mais gratificante do que trabalhar para sair disso. E quando digo “trabalho” não estou me referindo a emprego. Trace suas metas. O seu problema atual, o seu emprego atual, a vida que você leva hoje não te define. As metas mostram que isso é só uma fase, vai passar. (Meu terapeuta ficaria surpreso ao ler esse parágrafo).

E se eu não souber pra onde ir? Se eu não tiver metas? (Não, você não pode dobrar elas). Se você não souber, tem todo o tempo pra descobrir, claro que quanto antes melhor, mas como disse o mestre Samuka “De vagar e sem pausa”. No fundo, não importa muito se você vende brigadeiros, se você programa uma linguagem que você não gosta, se você atende 1000 telefonemas por dia. Isso não faz diferença. Isso não define seu “eu”, e outra, o horário comercial acaba (felizmente) e quando você volta pra casa, tem todo o tempo do mundo pra ser você mesmo. Você pode descobrir sorrindo e sem se cobrar tanto. No fundo as coisas não exigem tanta pressa de quem não sabe onde vai, mas quando descobrir, corra. Quanto antes você chegar, mais tempo vai sobrar pra ser feliz.

O incentivo faz toda diferença

mail@dunossauro.com (dunossauro) — Sun, 20 Jan 2019 00:00:00 -0200

Essa semana eu tive uma série de conversas difíceis, das quais só tomando banho agora tive uma impressão de que todas elas foram as mesmas, só que vistas de ângulos diferentes. Mas a última teve uma frase espacial que, confesso, me fez chorar um pouco antes de dormir.

Como todo o “bum” dessa história vem dessa frase, vamos contextualizar. Eu estava conversando com a minha @ e contando um pouco de uma das piores fases da minha vida e ela disse:

“Pra mim foi bem mais fácil”

E agora eu preciso, necessariamente, dar um contexto as conversas. O problema é que toda vez que penso em falar disso eu penso “Nossa, olha que coitadinho, vítima da sociedade” com o tom mais irônico do mundo. Sempre me vem uma frase de uma banda de hardcore que eu gosto muito, chamada Lupe de Lupe, que diz: “Não sou um privilegiado que vai beber da fonte da pobreza/E depois gorfar só pra te agradar”

Eu venho de um bairro da periferia da cidade de São Paulo chamado Jd. das Palmas e de longe nunca achei lá um lugar perto de ser “perigoso”, “nossa, olha a criminalidade solta por ai” (ironia novamente). Na realidade, nunca tive muito do que reclamar. Nunca me faltou comida, sempre tive o que vestir, às vezes algumas contas atrasadas, mas de longe não considero uma condição ruim. Como é padrão, e de se esperar, minha figura, tanto paterna quanto materna, são meus avós, dado o fato de ter nascido quando minha mãe tinha 17 anos e meu pai 20. Hoje vejo que não dava pra esperar muita estrutura físico-emocional dos meus pais naquele momento. Tanto que talvez o fato que considere mais relevante na minha existência é ter 25 anos e não ter nenhum filho até hoje. (A maioria dos meus amigos de infância, os que chegaram a essa idade, não tiveram estrutura [ou “sorte”] para esperar o momento desejado pra isso). Uma outra constante um tanto quanto normal pra galera que cresceu comigo é não ter avós, pais, parentes próximos, que chegaram nem mesmo a entrar em uma (facul|universi)dade. Isso me remete a uma piada um pouco infame, mas que carrega um peso simbólico imenso, e que meu pai costuma contar:

Fiz 5 faculdades, na sexta o tijolo acabou

Nesse ambiente, de maneira geral, ninguém é incentivado a estudar. Claro, ninguém nunca diz: “Já te disse pra lagar a escola”. Alguns amigos meus largaram a escola porque precisavam trabalhar. Trabalhar pra COMER. É, eu disse que a minha situação de longe não era ruim. Alguns foram presos antes de completar o ensino médio, outros com uma estrutura um pouco melhor se formaram e tem alguns, como eu, que largaram a escola. Tudo isso começou em uma briga que arrumei por lá. Aqui cabe um parêntese pra você que é burguês e acha que uma “suspensão”, “chamar os pais” resolveria. As coisas funcionam basicamente assim. “Um dia, no alto da sua ingenuidade, você ofende alguém (claro, moleques tem boca suja, aquela que nenhum sabão resolveria), no outro dia a pessoa aparece com uns “parceiros” na saída e te dão uma surra, ou em casos mais extremos a pessoa a quem a ofensa é direciona aparece com uma arma e resolve o problema”. Felizmente, eu apanhei bastante.

Lembro que depois disso meu conhecimento das pistas de skate da cidade ficou bem maior, fora do centro “sujo” de São Paulo. Isso aconteceu no início do ano, não me lembro exatamente quando. Aquele dia talvez tenha sido um das últimas vezes que pisei em uma sala de aula “por obrigação”. Eu estava na 8ª serie e não queria mais voltar a estudar. Lembro de ter procurado algumas escolas com a minha mãe no ano seguinte até que me veio a genial ideia de “estudar longe”. Fui estudar na barra funda. Literalmente do outro lado da cidade.

Campo limpo -> Barra Funda

Claro, eu já estava perito em andar de ônibus pelo “centro”. Descobri nessa época que os horários de pico são um tanto quanto traiçoeiros. Se eu pegasse o ônibus para pinheiros as 5:10 eu chegava as 6:20 na porta da escola. Se perdesse esse e pegasse o das 5:20, eu chegava atrasado. O problema disso era o ônibus intermediário Pinheiros -> Barra funda. Nem sempre era possível entrar nesse ônibus. Tinham 15 pessoas querendo entrar nele no ponto, mas raramente 10 conseguiam e eu fiquei de fora muitas, mas MUITAS vezes. Com isso, não é preciso dizer que muitas vezes eu fiquei pro lado de fora da escola. Mas, uma coisa muito interessante que aprendi nessa escola é que também é possível pular o muro para entrar na escola, sim, você ouviu bem. ENTRAR. Eu realmente estava com vontade de entrar. Tomei incontáveis advertências, fui suspenso algumas vezes mais o ápice e talvez a coisa mais dolorosa que escutei nesse ano foi:

Se você não consegue chegar na minha aula no horário, por que você continua vindo?

Na época tinha ficado um tanto quanto magoado. Mas hoje entendo que o fato de um professor de história ter dito isso, torna as coisas um tanto quanto MAIS complicadas. Mas eu insisti um pouco mais e conheci talvez o lugar mais mágico da cidade de São Paulo pra mim, R. Amaral gurgel. Lá tem uma ladeira muito gostosa pra descer de skate e se fosse direto pro centro, pegando 1 ônibus só eu conseguia chegar mais cedo na escola indo de skate pelo centro. Fiz algumas amizades com os moradores do viaduto, conheci melhor o centro. Mas algumas críticas foram feitas a direção em relação ao fato de “levar o skate pra escola”. A alegação da diretora:

Skate é baderna e não é tolerada baderna na escola. Trate de acordar mais cedo e pegar dois ônibus

Esse foi o último dia em que fui pra aula. Mas, como ninguém podia saber disso, eu continuei indo dar uma volta de skate no centro. No meio do caminho tinha um Senai com cursos de informática. Acabei fazendo um curso de redes lá. Eu era o aluno mais jovem e mais suado da turma. A coisa mais legal é que eu entrava no prédio a hora que queria, se chegasse atrasado era um “desculpa professor” e estava tudo resolvido. No decorrer desse ano fiz 3 cursos de redes no Senai com o dinheiro que eu tinha pra almoçar e posso dizer que valeu CADA CENTAVO. Arrumei um emprego em uma “lojinha de computadores” do ex-chefe da minha mãe. E tudo estava indo bem, meu chefe sempre me cobrava para voltar pra escola. Sim, ele tinha feito faculdade, os filhos dele tinham feito faculdade. E ele disse que lá era muito legal. Mas eu nunca acreditei que a escola era um bom lugar para. Mas, mesmo assim, fui fazer supletivo. Tentei em outra escola no centro, mas acabei voltando pra uma escola próxima de casa. Meu pai entendeu a importância de voltar a estudar e pagou o supletivo pra mim, já que as escolas públicas só oferecem supletivo no período noturno. Fiz alguns amigos mais velhos, foi um momento muito legal da minha vida. Mas a história toda e motivo de contar todo esse percurso se resume a uma professora que tive nesse período. Professora Agnes. O que ela fez por mim está longe de eu conseguir explicar com palavras e pode ser que outras pessoas tenham tentado fazer isso comigo antes, mas nunca tão claramente assim. Ela era professora de matemática e depois de uma aula ela pediu pra eu ficar, que ela queria falar comigo. Não lembro exatamente o que ela disse e até hoje eu choro um pouco quando lembro disso, agora inclusive.

Ela me disse que eu era bom em matemática. Sério, ela disse que eu era bom em alguma coisa. Eu nunca tinha escutado isso na minha vida. Mas mais do que isso, ela fez a coisa mais inesperada do mundo. Ele quis me ajudar a crescer, ela queria me ensinar matemática. Ela me deu um CD com os problemas das olimpíadas de matemática e um DVD das aulas do IMPA (Instituto de Matemática Pura e Aplicada). Mas ela não me deu só o material, ela me deu incentivo pra aprender aquilo. Naquele momento ela fez uma coisa que nunca tinha visto na vida. Além de dizer que eu era capaz de aprender aquilo, ela queria me ajudar a aprender aquilo. Foi uma das coisas mais bonitas que eu lembro de terem acontecido. Me deu a faca, o queijo e um abraço.

Você pode pensar que isso não é uma grande coisa. Mas quando coloquei o CD no computador foi a primeira vez que tive consciência que existia uma “consciência intelectual”. Eu tinha 16 anos, na 8ª série (do supletivo) e só nessa determinada condição eu aprendi a pensar. Eu não tinha capacidade intelectual para compreender o que era um número maior do que cabia de dinheiro na minha carteira. E tava tudo lá, naquele DVD. O infinito de Hilbert, a aritmética modular de Galois. A geometria grega. Tudo a um click do meu mouse. Depois de semanas nesse ritmo e descobri que pra aprender mais daquilo eu tinha que passar por um muro e esse muro era maior do que o infinito de Hilbert. Eu descobri que existia uma palavra que nunca tinha escutado em toda a minha vida vestibular.

O problema do muro é que embora eu tenha conhecido ele neste ano, existiam outras crianças de 16 anos que sabiam dele a 16 anos. E como você deve ter notado, a única coisa que eu sabia do que caía no vestibular, era o que tinha do DVD do IMPA. Eu não sabia mais nada, absolutamente nada sobre gramática, geografia, química, biologia …

Mas, nesse ano eu conheci outra palavra que eu não conhecia. Se o vestibular era um muro grande, tinha um muro menor que a minha professora de história me apresentou. O vestibulinho. Nesse momento eu já tinha aprendido o valor de aprender alguma coisa. E quando você passa a dar valor as coisas que você aprende, você começa a dar valor para as pessoas que ensinam. E eu contei pra todo mundo que eu conhecia que eu ia fazer essa prova, pro professores também e eles me deram a maior moral de todos os tempos. Eu aprendi 16 anos em 6 meses graças aos meus professores. E eu passei. Sério, passei. Naquela época, eu não entendia muito bem o que era relação candidato/vaga. Mas como fui estudar na ETEC do Paraisópolis. Você pode entender que não era concorrido. Mas importante é que eu estava lá e eu acho que o grande presente que recebi lá não foi a parte técnica, mas foi outro professor. Gildarcio, um exemplo de humildade, ele sabia exatamente o que era estar ali. Não na frente dos alunos dando aula, ele sabia que todo mundo tinha passado por dificuldades pra estar ali. A galera trabalhava o dia todo e ele conseguiu arrumar um micro-ondas pra gente parar de comer comida fria antes da aula. Ele sabia das coisas. Ele entendia os alunos. Lembro que um dia fui em um final de semana lá na ETEC e ele dava aulas pra cursinhos pré-vestibular abertos pra comunidade no final de semana. Eu já tinha entendido a importância de ter um professor, mas ele me ensinou a importância de ser professor:

Ter fé no outro para construir um futuro melhor

Todo o resto dessa história é tão entediante quanto a de qualquer pessoa que tenha feito faculdade. Sim, eu passei por lá também, sou aluno especial no mestrado. Mas isso também é chato de contar. Embora por lá também tenha conhecido muitos outros mágicos da educação. Muitas pessoas inspiradoras, muitas pessoas que moldam o que sou hoje, que me ensinaram a pensar diferente. Mas existe um ponto, o limiar disso, é que, se não fosse uma ajuda totalmente despretensiosa de uma mulher que tinha fé no futuro, eu não sei onde estaria hoje. Sabe, eu conheci uma infinidade de pessoas que me inspiram todos os dias. Já falei de algumas delas em outro texto. Mas se não fosse esse momento simples, essa relação de aluno/professora não seria NADA, absolutamente NADA.

Isso me faz pensar na quantidade de pessoas que vem desse cenário, ou pior do que ele. Sabe, a molecada tá na rua, muitos deles só precisam de uma força. Mas, no fundo, eles nem sabem disso. Ninguém sabe a capacidade que tem até alguém mostrar isso.

A outra conversa que tive sobre isso essa semana foi com “seniorzão branco hétero de 40” que tem duas graduações e veio tentar diminuir um estagiário das quebradas de campinas que acorda 5 da manhã pra ir ao estágio. Nem de longe acho que ele tenha noção das coisas que disse, nem da profundidade do problema. Sabe, é social. Essa gente não conhece gente que se esforça, que sai do buraco.

Então, você Mina/Mano da quebrada que tem que lidar com esse tipo de gente, toca o foda-se. Jovem, você vale muito mais do que um engomadinho vai dizer sobre você. Eu sei que a gente quer se mostrar sempre capaz, responder à altura. Mas não importa. O importante de verdade é que você esteja sempre disponível pra estender o braço e dar aquela força pra quele ser humano que precisa de um incentivo. Pra cada boçal que você encontrar na vida, pra todo obstáculo diplomático que você tiver que enfrentar, lembra de duas coisas: 1) Tem sempre alguém que valha mais a pena investir seu tempo. 2) Você já venceu.

Manual para pessimistas convictos

mail@dunossauro.com (dunossauro) — Wed, 19 Sep 2018 00:00:00 -0300

Hoje me deparei com um pedido de ajuda de uma amiga “Acordei triste, me animem aí” e me fez pensar em todas as vezes que me senti triste nesses últimos tempos. Quem é mais próximo de mim sabe que não andei muito legal esses meses que se passaram, mas o foco aqui não é falar sobre a tristeza que não sinto pra chamar de “profundo”. Talvez seja um “Manual para pessimistas convictos”. Tá aí, um bom título pra esse texto. (embora não seja nada original)

A algumas semanas parei pra pensar de onde é que nasce o sentimento que vamos chamar de “tristeza”. Sendo bem “teóricozinho”, o que não gosto muito de ser, lembrei de um texto do Fabiano da Costa:

“A tristeza é um sentimento próprio do homem que provoca no indivíduo um estado de infelicidade perante algum fato, isto é, é uma consequência interna de causa externa.”

Fico um tanto quanto perplexo quando paro pra pensar na influência do externo, sim, somos seres sociais. Praticamente nos sentimos um reflexo do que nos dizem que somos e nos sentimos capazes de fazer, muitas vezes, somente o que nos dizem que somos capazes. Oscar Wilde nos contou que “o rio esperava Narciso para poder se enxergar pelos olhos do pobre garoto” (algo assim). O que me faz pensar que grande parte do problema de olhar pra si mesmo é que fica complicado entender o que se “é” quando não se pode se olhar de fora. E, como a vida é um baile de mascaras, você trata pessoas de momentos diferentes (trabalho, bar, escola, … ) de maneiras diferentes. Então ainda que eu tente me ver pelo reflexo do outro, qual “você” ele está mostrando?

Mas acho que as coisas partem de um certo nível de angústia. Aí voltamos novamente as definições

An-gus-tia sf: Grande ansiedade ou aflição; Ânsia, agonia

Acredito eu, e eu não sou ninguém (viu, isso sempre volta), que grande parte dessa “tristeza” cotidiana venha dessa ansiedade de querer “ser” algo. De provar pro mundo que somos capazes de algo. E o aspecto social volta sempre. A partir de que momento as coisas que eu faço são direcionadas para mim, pra minha própria existência, para minha própria necessidade? E pra mim chega a um ponto de questionamento de “quando tempo passo sendo eu para mim”?

Mas, sendo mais profundo em questionamentos, onde é que nasce esse descontentamento com a vida, com o viver? Acredito que seja nesse lugar que realmente nascem as “inseguranças”, em conjunto com a famosa crise do impostor. Onde eu realmente me considero não sendo bom o suficiente perante tudo aquilo que me disponho a fazer. O grande problema é que quando me disponho a pensar sobre “eu”, eu mesmo não me reconheço naquilo que me forma como “eu”. Não me conheço, somente passo tempo pensando na “minha humilde existência” quando estou “triste”. E se me olho só nesses momentos, é praticamente impossível chegar a um “decreto” de que faço algo de produtivo.

É difícil se achar “foda” quando você se olha no espelho e só enxerga “você”.

Pode sempre parecer ruim ficar sozinho, pois você não se considera uma boa companhia pra si mesmo. Por pior que esse momentos possam ser, se você só consegue conversar consigo nesses momentos, você tem que aproveitar ao máximo. Não, isso não é uma ode ao autoflagelamento, é você de frente com você. Carregando o próprio peso da “sua existência”. E se não existe uma fórmula mágica pra sair da pior, a única maneira de viver dentro de si talvez seja abraçar seu próprio vazio. Acredito que assumir aquilo que se “é” ou aquilo que se “pensa ser” já pode ser um bom caminho pra entender o que te destrói por dentro, o que gera essa ansiedade macabra que te frustra a cada momento.

Talvez passando mais tempo com você mesmo, sem máscaras, sem pudor, até sem roupa se for possível, fazendo aquela única coisa que você sabe que suporta fazer e aproveitar o silêncio do mundo, seja algo que possa te ajudar a ser capaz de acordar todos os dias e lembrar que embora existam todos outros por aí, com suas qualidades e defeitos, só você pode ser você. E se você não estiver disponível para seu próprio “eu” talvez ninguém esteja disponível, nunca.

E é isso, não tem catarse, não tem uma super lição de como me tornei mais feliz, nem uma super dica pra se apaixonar por si mesmo. Tem momentos, como esse, em que só conseguir suportar o peso de viver já faz com que sejamos capazes de dar um pequeno passo pra frente e entender que embora existam pessoas, exista um sistema, existam relacionamentos, a todo momento o vazio, o abstrato, a famigerada “bad” vai ter que ser carregada pelo (parafraseando Kafka) ser desconhecido que é você pra si mesmo.

E como diria David Foster Wallace: Desejo a vocês muito mais do que sorte

Python, 42 e vida adulta

mail@dunossauro.com (dunossauro) — Wed, 22 Aug 2018 00:00:00 -0300

Sério, você não precisa ler esse texto. Ele foi feito em maneira de desabafo sobre coisas que venho guardando a um certo tempo, meio que entaladas na minha garganta.

Bom… Não diga que não avisei depois.

faz um pouco mais de 5 anos que a minha faculdade entrou em greve e me sentei ao lado do grande mestre Luciano Ramalho quando ele me explicou algumas poucas, mas importantes, linhas de código no garoa hacker clube. A galera estava reunida pra escrever o Pingo. Confesso que eu já tinha tentado escrever algumas linhas de Python em casa, mas você sabe como são as pessoas. “Python? Você deveria estar aprendendo Java. Isso sim vai te dar um emprego”

Bom… Emprego? Eu nunca quis ter um emprego. Para você que ainda não está inserido nesse mundo, aqui vai uma breve explicação do que é um emprego na área de TI (embora essa papo vá ficar pra outra hora):

Pessoas tristes que não sentem tesão pelo que fazem e precisam pagar contas

Segui estudando Python… Sério, era mágico (ainda é). Parecia que tudo fluía, eu conseguia expressar minha ideias em formato de código. Não tinha que esperar nada compilar… era fail fast, errou o interpretador me avisava e eu ia lá e corrigia. Simples assim. Eu não entendia NADA sobre programação, mas eu achava que entendia. Hoje vejo tantas tardes que perdi no meu pentium III tentando fazer bashs imensos pra conectar na internet discada e sinto até frio na espinha. Mas parecia que com Python as coisas fluíam bem, bem até de mais. A minha vida tomou um rumo meio estranho depois de tudo isso. Eu passava 5/6 horas do dia estudando Python. Eu queria saber fazer TUDO. Realmente aprendi muita coisa, eu tinha tempo livre, vontade de automatizar tarefas, fazer tudo que me mandavam fazer na faculdade em 10 linhas porque era possível de fazer em Python. Me tornei realmente proficiente em Python. Eu não conseguia mais escrever uma linha de código que não fosse em Python. Sabe aquela aulas de OO que você tem que usar um Java feio e com classes totalmente monolíticas? Eu estava só esperando chegar em casa pra refazer tudo em Python…

Parece que toda vez que alguém falava de programação eu fazia questão de colocar Python no meio, eu estava completamente apaixonado. Isso melhorou minhas notas, fez parte da minha IC, estava no meu TCC. Sério, Python estava em todo lugar. Comecei a frequentar os meetups, ir em todo tipo de evento. Eu conheci MUITA gente. E sabe o que era mais legal em tudo isso? Todas as pessoas estava tão apaixonadas quanto eu. Todo mundo estava lá pra falar de Python, pra programar Python, todos viviam de Python. E isso só me motivou mais pra estudar 5/6 horas de programação todos os dias. Eu era de fato um programador na minha bolha. Lembro de poucas coisas na minha vida, claro que sou apenas um jovem ainda, que me impactaram tanto.

Com isso, várias mudanças foram acontecendo dentro de mim, positivamente, claro. Mas no meio disso tiveram algumas coisas que tiveram fizeram grande diferença. Vou contar algumas dessas experiências. Acho que a maior delas, talvez tão grande quanto conhecer o projeto GNU, foi quando reencontrei o Ramalho pela primeira vez. Estava eu lá, a pessoa pirilampa que sou em um meetup em São Paulo, essa foi a primeira vez que palestrei também, e fui falar com o Luciano e ele fui super gentil, como sempre, mas ele não me reconheceu. Segui a conversa como se fosse a primeira vez que tivéssemos nos encontrado. Afinal, pra mim era um grande prazer estar ao lado dele mais uma vez. Mas confesso que passei dias pensando nisso. Eu tinha ido vários dias aos encontros do Pingo e ele nem mesmo me reconheceu… Foi quando me caiu a ficha que muito pelo contrário, eu não era uma pessoa insignificante, ele teria sentado e ensinado Python pra qualquer outra pessoa. Eu entrei meio que êxtase. Tá aí, isso é a comunidade

Você para tudo que está fazendo e vai ajudar, aquilo pode mudar a vida das pessoas

Eu já falava sobre Python o dia todo, eu já escrevia código o dia todo, eu já estudava o dia todo. Qual seria o problema em compartilhar tudo aquilo que eu já sei? Isso foi em 2014/2015, não me lembro ao certo. Passei a ser mais ativo online e tento colaborar o máximo possível. Montamos um grupo de estudo de python e criptografia na faculdade, apaixonei outras pessoas e venho tentando fazer isso sempre que possível, isso virou meio que uma rotina. Qualquer dúvida, estou lá, pronto pra ajudar. As vezes eu também não sei a resposta, mas estou lá, sempre tentando dar uma moral. Tive ótimos momentos falando sobre Python em geral.

A segunda pancada veio em 2016 quando meu pai me disse que o “patrocínio” estava perto do fim. (Sério, eu não estava pensando em ter um emprego). Bom, não tinha problema, eu era um “programador iniciante mediano”. Não parecia ser tão complicado arrumar um emprego, afinal, “Área de tecnologia, sempre emergente”, como todo mundo diz. Só que eu queria programar PYTHON, eu me recusei a achar outras coisas. Burrice? hoje vejo que sim. Maaaaaaassssss, cidade pequena, do interior de SP, tinham várias vagas…. Suporte, Cobol, Delphi, Java… E o Python? Cadê? NADA. Foi quando pipocou uma vaga próximo a Campinas, teria que acordar 5am, mas Python é Python, então eu fui, me candidatei, eles me enviaram um teste, foi simples, por sinal. Algumas etapas a mais e eu estava dentro. E por dentro eu estava mais ou menos assim:

Vulgo: Quebrando tudo

Até chegar no primeiro dia e ter board, scrum, pessoas diferente e que não tinham 1/10 da paixão pela linguagem que eu tinha construído nos últimos anos. Sério, as pessoas que entram nos meetups por engano gostavam mais de Python do que as pessoas que trabalhavam comigo. Era um sistema legado, em python 2, com uma manutenibilidade de código abaixo de zero e complexidade ciclomática crescendo mais rápido que a velocidade da luz. Eu era, sou ainda, muito, mas MUITO teimoso. Nos primeiros dias eu só queria chorar. “Como pode essa galera com anos de experiência fazendo um código tão merda”, eu só conseguia pensar isso. Depois disso, eu fui entrando em estado de aceitação. Sério, eu estava tentando não chorar todo dia quando ia fumar um cigarro. Mas os dias foram passando e você passa mais tempo com as pessoas que trabalham com você do que passa com as que moram com você. Então, é inevitável fazer amizades. Se você não tem amigos no trabalho, você está fazendo algo errado, juro. Eles nunca tinha dado risada importando “antigravity”, eles nunca tinham assistido nem se quer um episódio de Monty python. Era um time legal, unido, eles só não era culturalmente pythonistas.

Juro que essa foi uma das fases mais legais do trabalho, eles me ensinavam sobre os produtos, sobre os processos e eu devolvia com “Pythonic style”. As semanas foram passando, muitas conversas com a minha chefe. Decidimos isolar algumas pessoas e começar tudo lindamente legal. Com Python 3, com código que semanticamente não parecia outra linguagem. Sério, ninguém mais estava aguentando ver aquele código legado depois de um tempo. Sabe, o time estava contente por estar tomando suas decisões de design, sobre as padronizações de código, sobre olhar a qualidade do código. Antes as pessoas só estavam ali, elas estavam carregando nas costas projetos que elas não começaram, com arquiteturas que ninguém tinha escolhido, com padronizações que não faziam sentido. Junto com o estilo pythonico veio a amizade, o sentimento de pertencimento, todo mundo estava fazendo o que tinha que fazer, do mesmo modo que antes, mas sentindo prazer e sabendo explicar por que determinadas coisas estavam assim e não assado. O time estava integrado, falando python, pensando python, vivendo Python. O pessoal nunca tinha ido a um evento, eles não tinham contato com a comunidade. Fizemos um meetup de python na empresa, fomos à Python Brasil.

Descobri depois de um tempo que todas aquelas coisas que eu não tinha aprendido na faculdade sobre desenvolvimento ágil, testes automatizados, processos, como se comportar em ambientes corporativos, valia pra todo time. A faculdade, o técnico, os cursos, eles tinham me ensinado muita coisa sobre como ser um “bom escrevedor de códigos”. Mas as coisas que aprendi com o senhor Ricardinho (Richard Stallman) e com a comunidade de software livre são mais importantes do que qualquer bloco ultra mega blaster elaborado de código. Vale relembrar o slogan das últimas Python Brasil

Pessoas > Tecnologia

Fiz amigos, mudei muitas das minhas ideias sobre trabalho. Mas realmente estava desgastante, eu só estava pensando em trabalho, claro, tudo estava legal de mais. Mas eu estava dedicando pouco tempo a “ensinar o que sei” fora de lá. No ano passado, em maio, eu estava “meio desocupado” em uma quarta feira e só queria falar de código, sem pensar em nada, eu não queria pensar em sprints, entregas, trabalho. As coisas estavam virando uma só, code=trabalho. Postei no facebook um simples “Que tal a gente fazer uma live falando sobre Python”, era uma quarta-feira, a galera abraçou. Não falamos de nada importante, nem necessariamente relevante. Mas combinamos de nos encontrar na quarta seguinte pra falar sobre um assunto específico e assim nasceu a Live de Python. Eu não tinha nada, além de vontade de falar sobre Python. O dia era meio ruim, mudamos pra segunda. E faz mais de um ano que fazemos live codes. Eu passo horas e mais horas pesquisando sobre o assunto, monto um material e a gente faz uma espécie de sala de aula online.

Eu nunca pensei que isso pudesse ter um impacto tão positivo na minha vida. As vezes eu fico puto, as vezes eu só quero procrastinar. Mas toda segunda tem live. Descobri uma coisa dentro de mim que eu já sabia. Eu gostava de ensinar. Claro, não tenho formação pra isso, mas tenho MUITA vontade de ensinar, as vezes eu aprendo os temas, só pra ensinar. E faz algum tempo que venho pensando nisso, mas talvez nunca tenha tentado explicar, vou tentar…

“Cara, olha o impacto que isso tem na vida das pessoas”. Um ambiente totalmente hostil, o mundo não é inclusivo, as pessoas querem cobrar por tudo, as pessoas não querem ajudar ninguém. Como uma live de programação pode ter impacto positivo sobre qualquer coisa? Lembrei de novo das pessoas, estamos nos conectando, falando sobre coisas que gostamos e todo mundo está aprendendo. Isso é meio que um hack, usar uma plataforma que só visa lucro pra ensinar de graça, propagar conhecimento distribuído, que você pode consumir como quiser, quando puder. Isso é totalmente o contrário do que “me ensinaram” a vida toda. Não é necessário um super diploma pra ensinar, não é preciso uma sala de aula pra aprender. Pô, a gente pode fazer isso tomando coca e rindo. A gente pode fazer piada, a gente é livre pra aprender o que quiser e pra chegar onde quiser. É tudo muito confuso dentro da minha cabeça quando penso nisso. Mas se não fosse um maluco (Guido) que tivesse a ideia de materializar tudo isso a um tempo atrás, não teríamos a comunidade que temos, nós não seriamos amigos, pelo que iríamos nos apaixonar? Quem nós seriamos hoje?

Parece que com o passar do tempo tomamos algumas decisões erradas, as coisas poderiam ser sim diferentes. Mas, quando paro pra pensar nas coisas, gostaria que elas fossem exatamente iguais.

E você, já se apaixonou por Python hoje?

Se você chegou até aqui, esse é só um punhado de ideias jogadas na internet, são pensamentos sobre a minha vida, o universo e tudo mais. Se precisar de um amigo, um abraço, uma ajudinha com código. Nós estamos sempre por aqui ❤

????????

mail@dunossauro.com (dunossauro) — Mon, 01 Jan 0001 00:00:00 +0000

Boas-vindas ao meu blogroll.

Aqui estão blogs, páginas, conteúdos, … Coisas que leio, que gosto, que recomendo e quem sabe você possa se interessar por eles.

## Blogs pessoais

Bruno Rocha 🇧🇷
bugelseif 🇧🇷
Caio Carrara 🇧🇷
claromes.com 🇧🇷
Cassio Botaro 🇧🇷
Eduardo Klosowski 🇧🇷
gmgall.net 🇧🇷
Helio Loureiro 🇧🇷
Ivan Santiago 🇧🇷
Jonatas Oliveira 🇧🇷
Masdivago 🇧🇷
Meme de Carbono 🇧🇷
osantana 🇧🇷
Renne Rocha 🇧🇷
ratamero.com 🇧🇷
Téo Me Why 🇧🇷

## Páginas não pessoais

Manual do Usuário 🇧🇷
LOW←TECH MAGAZINE English 🇬🇧
HTMX essays 🇬🇧
F-Droid 🇬🇧
Bandcamp Daily 🇬🇧

A lista completa de tudo que eu acompanho diariamente está no meu OPML, caso você queira descobrir mais coisas :)