Quatro dias atrás, 5 de abril de 2026, meu blog completou 20 anos. Eu sei, eu atrasei o post comemorativo. Mas tem um motivo, e esse motivo é o assunto desse texto.

Eu comecei em 2006 no Blogspot do Google, como a maioria fazia na época. Depois migrei pra um CMS em Rails 2.0 que já existia, passei pelo Typo3, e lá em 2012 fiz minha própria engine do zero em ActiveAdmin, que fui arrastando de Rails 3 até Rails 7. Só recentemente, em setembro de 2025, finalmente larguei essa engine própria e fui pro Hugo com o tema Hextra, que é onde esse post está rodando agora. Vinte anos carregando os mesmos posts de Textile, migrando de Less pra Sass, trocando Liquid por Markdown, e removendo lixo obsoleto ao longo do caminho.

Duas décadas, cinco eras

Uma coisa que poucos programadores param pra refletir é o quanto o mundo de tecnologia muda em 20 anos. Eu já falei sobre isso no Akitando #37 - A Dimensão do Tempo. Quando eu abri esse blog em abril de 2006, eu já tinha 10 anos de experiência. Já tinha visto a bolha da internet subir e explodir em 2000. E desde então ainda vi mais umas quantas: a ascensão das redes sociais (Orkut, Facebook, Twitter), a revolução do smartphone e do app móvel em 2008, a crise econômica de 2008, o nascimento do Bitcoin em 2009, a era da nuvem e do SaaS, agora a era da IA generativa.

Eu vi essas ondas estourarem na prática. Cada uma delas mudou completamente como a gente trabalha e quem sobrevive profissionalmente. Esse tipo de coisa a gente só enxerga olhando de longe, depois de acumular umas quantas viradas.

Minha carreira em si passou por viradas drásticas. Contei em detalhe nos Primeiros 5 Anos (1990-1995), mas resumindo: comecei em agências de multimídia, migrei pra consultoria enterprise trabalhando com SAP, abandonei tudo em 2006 pra entrar em Ruby on Rails e open source, passei uma década organizando evento, principalmente a Rubyconf Brasil de 2007 até 2018, depois fechei a porta do evento e comecei o canal Akitando no YouTube, que cresceu pra mais de 500 mil inscritos. No meio disso teve a pandemia que reorganizou a vida de todo mundo. E agora, desde o começo de 2025, virei pesquisador e usuário em tempo integral de IA, rodando modelos localmente e quebrando coisas com Claude Code até elas funcionarem.

Olhando pra tag /tags/ai, eu escrevi 51 posts relacionados a IA só entre 2025 e 2026 — 19 em 2025 e mais 32 em 2026, que mal começou. Antes de 2025, entre 2018 e 2024, o blog basicamente virou o arquivo dos transcripts dos vídeos do Akitando. Eu filmava o vídeo, fazia o transcript, jogava no blog, e as pessoas liam lá. Mas desde que eu voltei a escrever ativamente, notei que tinha uma audiência leal que nunca foi embora, mesmo nos anos quietos. E foi esse feedback que me fez começar The M.Akita Chronicles, uma série mais pessoal contando os bastidores de projetos recentes.

O problema que eu nunca resolvi

Durante esses 20 anos, uma coisa me incomodava. Como o conteúdo é todo em português, fica inacessível pra todo mundo que não lê a língua. E faz uns bons anos que eu venho recebendo mensagens de leitores brasileiros morando fora (Portugal, Estados Unidos, Japão, Alemanha, Canadá) pedindo alguma versão em inglês pra compartilhar com colegas gringos. Coisa tipo “olha, eu mostraria esse texto pro meu time, mas só tá em português.”

Eu sempre disse “um dia eu traduzo.” E nunca traduzi. Por quê? Porque são centenas de posts. Passei os últimos dois dias olhando os números: 727 arquivos index.md em português no repositório. Traduzir tudo à mão, um por um, ia tomar semanas se não meses de trabalho dedicado. Eu nunca ia ter fôlego pra isso. E a cada ano que passava, mais posts se acumulavam pra traduzir.

A ironia é que alguns posts do blog nasceram em inglês. Durante 2017 e 2018 eu tinha decidido escrever primeiro em inglês pra tentar alcançar audiência internacional. Uma série inteira de entrevistas, as “chatting-with” com gente tipo Hal Fulton, Scott Hanselman, Chris Wanstrath (do GitHub), Blaine Cook (ex-Twitter), Adam Jacob (Chef), nasceram em inglês e ficaram lá. Faltava o inverso: pegar os posts em português e traduzir pro outro lado.

O fim de semana que consertou 20 anos de dívida técnica

Na segunda passada eu abri o Claude Code dentro do diretório do blog. E pedi pra ele traduzir tudo pra inglês. Foi literalmente isso.

Começou na segunda-feira, dia 6 de abril, por volta das 18:30h. Eu deixei rodar. Fui dormir. Acordei terça, continuei rodando. Dormi de novo. Quarta de manhã cedo ele terminou. Contando o tempo total do primeiro commit de tradução até o último, foi algo como 39 horas. Mas não foi contínuo, teve noites, almoços, uma roda de café. Na prática, um fim de semana estendido de trabalho.

O resultado tá no repositório git, em commits que qualquer um pode inspecionar no repositório público do blog. Olhando rapidamente o log, dá pra ver a cadência: lote de posts de 2008 QCon. Lote de 2009 RailsConf. Lote de 2011 Objective-C. 2012 completo. 2015 série Elixir. 2016, 2017, 2018 completos. Lote depois de lote, organizados por ano e por série. Mais de 80 commits marcados como i18n: ou EN translation: entre o começo da noite do dia 6 e a manhã do dia 8. No final desse post, abri 354 arquivos index.en.md contra os 727 index.md originais. Quase metade do blog inteiro traduzido de um só golpe.

E olha, noventa por cento foi tranquilo. A tradução ficou boa, natural, fiel à minha voz no original — eu não imaginava que ia funcionar tão bem. Claude Code respeita o tom do texto se você der instruções boas de voz e estilo, e mostra respeito por ideias técnicas sem “corrigir” nada do que você escreveu. No pior caso, revisa alguns parágrafos. No melhor caso, a versão em inglês soa como se você tivesse escrito direto na outra língua.

Um parênteses sobre o custo do lado Claude. Eu sou assinante do plano Max 20x da Anthropic, que é o tier de uso pesado feito pra quem abusa do Claude Code o dia inteiro. Nunca tinha batido no teto dele antes, nem nas minhas sessões mais intensas de vibe coding. Esse fim de semana de tradução foi a primeira vez que eu realmente estourei o limite do Max 20x e continuei usando já no modo de “uso extra” (a Anthropic cobra por consumo acima do teto do plano mensal).

Pra ter uma ideia do estrago, esse é o painel da minha conta agora de manhã:

91% da quota semanal “all models” consumida, já pra dentro do modo de uso extra, R$280,88 (uns $50 USD) gastos em cima da mensalidade fixa, e ainda falta um bom pedaço do ciclo. Faz sentido: ler o post inteiro, gerar a tradução, aplicar o humanizer em cima, repetir centenas de vezes seguidas. A quantidade de tokens envolvida é massiva. E hoje, enquanto eu escrevo esse texto, o Claude Code tá me dando com frequência crescente o erro API Error: Request rejected (429) · Rate limited, o que também faz sentido: deve ser um combo de quota do meu plano e do Anthropic aplicando backpressure geral, porque eu não devo ser o único fazendo loucura esses dias. Ok, normal. É o preço de ter usado a ferramenta pesado quando fazia diferença.

Os outros dez por cento foram uma história separada.

Quando os LLMs comerciais dizem “não”

Meia dúzia de posts antigos se recusaram a ser traduzidos. Tanto Claude quanto GPT, pela API, caíam num erro 400 com mensagem de política de conteúdo. Tentei várias vezes, em sessões frescas, com contexto limpo. Nada.

A hipótese é simples: esses posts tocavam em tópicos sensíveis pra content moderation automatizado. Um post de 2009 sobre o discurso do Steve Jobs em Stanford de 2005 (que menciona câncer, já que o Jobs estava falando do diagnóstico terminal que ele tinha recebido). Dois capítulos antigos da Ayn Rand, traduzidos por mim anos atrás, sobre direitos do homem e argumentação. Um post anti-nazista que ironicamente foi bloqueado provavelmente só porque a palavra “nazi” aparecia lá, mesmo com o contexto sendo crítico. Um post sobre o discurso do dinheiro do Atlas Shrugged. E um ensaio sobre democracia e ética que travava sistematicamente todas as tentativas.

A ironia dessa parte é que o único jeito de conseguir traduzir esses posts foi usando um modelo open source. Carreguei o Qwen 3.5 35B no llama-swap, rodando localmente, sem filtros de política corporativa. O modelo leu, entendeu o contexto, e traduziu tudo sem drama. É o mesmo modelo que eu tinha testado extensivamente no meu último benchmark de LLMs, e que eu avalio como um dos melhores open source disponíveis hoje.

Ou seja: um modelo chinês conseguiu traduzir posts que modelos ocidentais recusaram. Eu não consigo deixar de achar isso levemente hilário. Ah, claro, e não posso falar mal da China (sarcasmo). LLMs comerciais vão sempre ter o problema de política corporativa e censura preventiva aplicada com régua meio grossa. É um trade-off real pra quem quer usar eles em produção: você ganha fluência e capacidade de raciocínio, perde controle quando o tópico resvala no que a empresa decidiu que é sensível.

O caso inverso: 2017-2018 traduzido pro português

Enquanto eu estava ajustando o Claude Code pra gerar o conteúdo em inglês, aproveitei pra resolver o problema simétrico. Os posts que eu tinha escrito originalmente em inglês durante 2017 e 2018, mais a série inteira de entrevistas “chatting-with” de 2008, estavam parados lá sem versão em português. Claude Code rodou o reverso: leu o inglês, gerou o português. Então se você não leu os originais em inglês (porque a maioria do meu público é brasileiro mesmo), agora você tem acesso também. Dá uma olhada na seção Off-Topic pra ver o que apareceu de novidade.

Junto disso, o Claude Code também atualizou o script generate_index.rb pra entender a estrutura bilíngue do blog e gerar dois índices separados, um em português e outro em inglês. O seletor PT/EN no rodapé de cada post aparece automaticamente quando existe o arquivo index.en.md irmão. Tudo bem integrado ao Hugo, seguindo o padrão nativo de multilíngue dele.

O ponto mais amplo

Aqui tá o recado que eu queria deixar nesse post de aniversário. Tradução em escala, centenas de artigos, conteúdo seu, na sua voz, respeitando o tom do original, era um problema caro e chato. Agora é um problema de fim de semana. Isso já tá no ar, você tá lendo o resultado. A barreira que existia pra alcançar audiência fora do Brasil virou algo barato o suficiente pra eu não ter mais desculpa.

Então, vamos lá, recapitulando o aniversário. 20 anos. 727 posts em português, construídos ao longo de cinco eras diferentes de tecnologia. 354 novos posts em inglês gerados num fim de semana. Metade do blog agora é bilíngue. E o resto vai indo. Os que faltam são principalmente posts antigos de ActiveAdmin, Rails 2 e dicas obsoletas que já faz sentido deletar ou não traduzir de propósito.

Se você tem amigo gringo que já cansou de ver você postando link em português e precisa de uma desculpa pra mandar alguma coisa minha, manda. Os posts principais sobre IA, os Chronicles, benchmarks, rants e boa parte do arquivo histórico já tão disponíveis em inglês no mesmo domínio, é só trocar o toggle no rodapé. Obrigado a todo mundo que acompanhou esse blog por esses vinte anos. Tem leitores aqui que me conhecem desde o Blogspot. Vocês sabem quem são.

Vamos pra mais um ano.

(e sim, tem tema dark, link no rodapé do site)

O BLOG PERFEITO NÃO EXISTE

Eu acho importante que todo programador tente escrever. Não pra virar influencer nem nada disso. O primeiro objetivo é escrever pra você mesmo. Eu uso meu blog primariamente como um “backup” do meu cérebro (assim como foi meu canal do YouTube).

Notem como os últimos posts de Linux não sou eu tentando te vender nada, mas sim coisas que fiz de verdade no meu PC ou home server, e anoto passo a passo. Caso daqui 3 anos eu queira refazer, tenho tudo anotado.

Segundo: programadores são péssimos comunicadores. Nós falamos somente pra nós mesmos e não pensamos se a pessoa ouvindo está nos entendendo. E quando vemos que não entende a reação é “ah, porque ela é burra e eu sou inteligente.”

Falei sobre isso no artigo Programadores são Péssimos Comunicadores. Mesmo se só uma pessoa ler seu post, mas te der um comentário, esse feedback é importante. É como um teste rodando que falha: agora você sabe onde tem que corrigir. E vai corrigindo, um passo de cada vez.

Portanto, escrever blog post, não importa se tem zero visitantes, é um exercício de prática pra se tornar um comunicador melhor, por isso recomendo.

Blog Engines

Eu comecei postando no Google Blogspot em 2006. Depois fiz meu próprio blog num projeto que já existia em Ruby on Rails 2.0, passei por vários, como o Typo3 na época. Até que em 2012 eu fiz o meu próprio engine do zero usando ActiveAdmin e é esse projeto que eu vim atualizando de Rails 3 até Rails 6 ou 7 recentemente. Meu primeiro post continua no blog:

Muita coisa mudou nesse período, Less foi substituído por Sass. Textile e Liquid foram substituídos por Markdown, surgiu Twitter Bootstrap, etc. Por isso dezenas de artigos que escrevi estavam em Textile. E como sempre tive preguiça de converter em Markdown, demorei pra sair dessa minha engine velha.

Pra um blog pessoal, não precisa de nada complicado, como banco de dados ou coisas assim, mas acabou vindo como legado da época. Eu já conhecia jekyll pra fazer blogs com páginas estáticas, mas ainda tinha os posts velhos em Textile que tava com preguiça de lidar.

Ao longo do tempo também vim apagando vários posts. Coisas que ficaram obsoletas mesmo como “dicas pra Ruby 2.0” ou “novidades no Rails 3.0”. Ler isso hoje não faria sentido. Fui mantendo somente os posts que se ler hoje, ainda faz sentido. Isso veio a me ajudar quando resolvi converter os posts velhos.

Outro motivo de continuar no meu engine era que meu ActiveAdmin tinha o suporte pra fazer upload de imagens no meu bucket da AWS S3, então era uma conveniência extra que não tava com vontade de ter que resolver de outra forma.

Finalmente, em 2025, resolvi que estava de saco cheio de ficar atualizando versões de Rails, fazendo deploy no Heroku, lidar com backup de banco de dados, além do front-end estar feio e quebrado.

Hextra/Hugo

Depois de Jekyll, surgiram geradores de sites estáticos em dezenas de linguagens. De fato, é o jeito mais prático pra um programador escrever um blog: só criar um arquivo texto localmente, escrever tudo em markdown, rodar um script e subir um site estático que não precisa de nenhuma configuração, banco de dados ou qualquer outro componente mais complicado. Dá pra subir até como GitHub Pages e hospedar lá grátis.

Por isso eu sabia que, se fosse fazer um novo engine, teria que ser site estático. Já tinha ouvido falar do tal projeto Hugo, que é feito em Go e tem tudo que eu precisava: markdown, suporte a tags, etc. Mas tinha um problema: eu odeio fazer front-end e eu nunca fui um bom web designer, ou designer no geral.

Foi quando esbarrei no Hextra, que é basicamente o Hugo mas com vários temas pré-prontos. E diferente de vários outros projetos com temas gratuitos que costumam ser muito feios e muito mal feitos, os do Hextra me pareceram minimamente bem feitos. Fucei um pouco, achei um tema padrão minimalista que é legível pra textos com código e decidi que seria agora.

Desta vez não vou dar passo a passo de tudo que eu fiz porque seria maçante, mas é só ler a documentação do Hugo pra saber o que fazer. Na prática:

# novo projeto
hugo new

# reconstruir o site
hugo build

# subir o servidor local (porta 1313)
hugo server --buildDrafts --disableFastRender

No meu caso, eu comecei com o Hextra Starter Template do que começar do Hugo zerado. Acho que vale a pena checar. Ele também explica como fazer deploy pra GitHub Pages e Netlify.

Código Aberto

A vantagem de usar um gerador de site estático é que posso me livrar do banco de dados Postgres que usei por anos e converter todos os artigos em arquivos texto individuais. Feito isso, basta subir tudo num repositório no GitHub. E como são textos publicamente disponíveis de qualquer forma, não tem porque não deixar aberto. Dessa forma, qualquer um pode contribuir (e muitos já contribuíram - obrigado pela ajuda!)

Se quiser contribuir ou só fuçar acesse o repositório no GitHub e faça um fork. Note como o nome do projeto é akitaonrails.github.io porque, originalmente, eu pretendia fazer deploy no GitHub Pages, mas mudei de idéia e já falo disso.

Até agora já tive 8 Pull Requests mergeadas. Alguns realmente se deram ao trabalho de caçar erros, typos, bugs e mandaram correções muito boas. O blog está melhor graças a eles. Às vezes eu posso demorar um pouco pra checar os PRs, mas eventualmente eu chego e costumo mergear tudo.

Um dos PRs inclusive foi pra adicionar suporte a Docker Compose pra facilitar pra quem quiser contribuir. Outro PR foi pra melhorar a documentação na página de README. Então tá bem fácil de entender o que fazer.

Outra contribuição importante foi adicionar tag pra fazer embed de video do YouTube. Eu só preciso fazer:

Do jeito antigo eu ia no YouTube, clicava em “Share”, “Embed” e copiava o bloco de iframe. Mas isso quebra em mobile.

Eu particularmente não uso o workflow de Docker, logo abaixo tem o workflow pra instalação local. São tão poucos componentes que não acho que valha a pena lidar com Docker pra isso.

Digamos que eu queira escrever este artigo. Ele está salvo em content/09/10/meu-novo-blog-como-eu-fiz/index.md que significa mês 09 (setembro), dia 10, seguido do slug como sub-diretório e dentro só um index.md que é markdown. As primeiras linhas do artigo tem este cabeçalho:

---
title: Meu Novo Blog - Como Eu Fiz
date: "2025-09-10T15:00:00-03:00"
slug: meu-novo-blog-como-eu-fiz
tags:
  - blog
  - hugo
  - hextra
  - ruby
draft: false
---
....

E segue o artigo escrito em Markdown. Feito isso, do diretório do projeto tenho que fazer:

cd content
ruby generate_index.rb
cd ..

Isso atualiza a página principal com o link pro novo artigo no topo. Pra garantir que está tudo certo, posso checar subindo o servidor local:

❯ hugo server --buildDrafts --disableFastRender
Watching for changes in /home/akitaonrails/Projects/akitaonrails-hugo/{content,i18n,layouts}
Watching for config changes in /home/akitaonrails/Projects/akitaonrails-hugo/hugo.yaml, /home/akitaonrails/Projects/akitaonrails-hugo/go.mod
Start building sites …
hugo v0.149.1+extended+withdeploy linux/amd64 BuildDate=unknown


                  │  EN
──────────────────┼──────
 Pages            │ 3374
 Paginator pages  │    0
 Non-page files   │  131
 Static files     │   11
 Processed images │    0
 Aliases          │    0
 Cleaned          │    0

Built in 8799 ms
Environment: "development"
Serving pages from disk
Web Server is available at http://localhost:1313/ (bind address 127.0.0.1)
Press Ctrl+C to stop

Agora posso acessar no navegador em http://localhost:1313:

Finalmente, basta deployar:

git add .
git commit -m "adding new blog article"
git push origin master

E é só isso!

Deploy

Falei que pretendia fazer deploy no GitHub Pages, mas na última hora resolvi que queria fazer deploy na [Netlify]

Por que? Porque eu nunca tinha usado, então resolvi que queria ver como era. Basicamente isso. Eu achei barato, tem as funcionalidades que precisava, então, por que não?

A única coisa que precisei fazer de diferente, foi configurar o deploy linkando com meu repositório do Github:

E, no GitHub, criar uma Action assim:

# Sample workflow for building and deploying a Hugo site to GitHub Pages
name: Deploy Hugo site to Pages

on:
  # Runs on pushes targeting the default branch
  push:
    branches: ["master"]

  # Allows you to run this workflow manually from the Actions tab
  workflow_dispatch:

# Sets permissions of the GITHUB_TOKEN to allow deployment to GitHub Pages
permissions:
  contents: read
  pages: write
  id-token: write

# Allow only one concurrent deployment, skipping runs queued between the run in-progress and latest queued.
# However, do NOT cancel in-progress runs as we want to allow these production deployments to complete.
concurrency:
  group: "pages"
  cancel-in-progress: false

# Default to bash
defaults:
  run:
    shell: bash

jobs:
  # Build job
  build:
    runs-on: ubuntu-latest
    env:
      HUGO_VERSION: 0.145.0
    steps:
      - name: Checkout
        uses: actions/checkout@v4
        with:
          fetch-depth: 0  # fetch all history for .GitInfo and .Lastmod
          submodules: recursive
      - name: Setup Go
        uses: actions/setup-go@v5
        with:
          go-version: '1.24'
      - name: Setup Pages
        id: pages
        uses: actions/configure-pages@v4
      - name: Setup Hugo
        run: |
          wget -O ${{ runner.temp }}/hugo.deb https://github.com/gohugoio/hugo/releases/download/v${HUGO_VERSION}/hugo_extended_${HUGO_VERSION}_linux-amd64.deb \
          && sudo dpkg -i ${{ runner.temp }}/hugo.deb
      - name: Build with Hugo
        env:
          # For maximum backward compatibility with Hugo modules
          HUGO_ENVIRONMENT: production
          HUGO_ENV: production
        run: |
          hugo \
            --gc --minify \
          --baseURL "https://${{ github.repository_owner }}.github.io/"
      - name: Upload artifact
        uses: actions/upload-pages-artifact@v3
        with:
          path: ./public

  # Deployment job
  deploy:
    environment:
      name: github-pages
      url: ${{ steps.deployment.outputs.page_url }}
    runs-on: ubuntu-latest
    needs: build
    steps:
      - name: Deploy to GitHub Pages
        id: deployment
        uses: actions/deploy-pages@v4

Com isso, toda vez que faço git push, vai rodar esse job, gerar o site e mandar pro Netlify direto. Tudo automatizado, como Deus sempre quis 🤣:

Aliás, eu falei que o Netlify era “barato”, na verdade eu quis dizer que é gratuito. Pra sites pequenos como o meu, não custa literalmente nada:

Pago zero dólares e ainda aprendi algo novo. Por isso essas coisas são divertidas.

Scripts

Pra converter os artigos do meu blog antigo pro Hugo, acabei fazendo alguns scripts de correção. Eles ainda estão no repositório como content/fix_*.rb. Não precisa saber pra que eles servem, mas estão lá caso queiram fuçar. O mais importante era manter as URIs iguais eram no blog anterior pro Google continuar achando corretamente.

O único que realmente interessa é o generate_index.rb:

require 'yaml'
require 'find'
require 'date'

def escape_markdown(text)
  text.to_s.gsub('[', '\\[').gsub(']', '\\]')
end

entries = []

Find.find('.') do |path|
  next unless path.end_with?('index.md')
  next if path == './index.md' || path == './_index.md'

  begin
    lines = File.readlines(path)
    if lines.first&.strip == '---'
      fm_lines = []
      i = 1
      while i < lines.size && lines[i].strip != '---'
        fm_lines << lines[i]
        i += 1
      end
      if lines[i]&.strip == '---'
        front = YAML.safe_load(fm_lines.join)
        if front && front['title'] && front['date']
          date = Date.parse(front['date'].to_s) rescue nil
          if date
            url = path.sub('./', '').sub('/index.md', '/')
            entries << { 'title' => front['title'], 'url' => url, 'date' => date }
          end
        end
      end
    end
  rescue => e
    warn "YAML error in #{path}: #{e.message}"
  end
end

# Sort newest first
entries.sort_by! { |e| e['date'] }.reverse!

# Group by year and month
grouped = entries.group_by { |e| [e['date'].year, e['date'].month] }

# Sort year-month pairs descending
sorted_keys = grouped.keys.sort.reverse

File.open('_index.md', 'w') do |f|
  f.puts "---"
  f.puts "title: AkitaOnRails's Blog"
  f.puts "---"
  f.puts

  sorted_keys.each do |(year, month)|
    month_name = Date::MONTHNAMES[month] # "May", "June", etc
    f.puts "## #{year} - #{month_name}\n\n"
    grouped[[year, month]].each do |post|
      f.puts "- [#{escape_markdown(post['title'])}](#{post['url']})"
    end
    f.puts
  end
end

puts "Generated _index.md with posts grouped by year & month."

Esse script tem um pequeno bug: ele ordena os artigos a partir do diretório de mês e dia, mas significa que se eu postar várias vezes durante o dia, vai sair fora de ordem, ordenado pelo título do artigo. Veja: sorted_keys.each do |(year, month)|

O certo seria abrir o artigo e pegar o metadado de timestamp, mas fiquei com preguiça. Se alguém quiser corrigir e mandar um PR, será bem vindo.

Por que fiz em Ruby e não em Python ou Bash?? Porque foi como eu quis 🤣, não perturba.

Imagens no S3

Como contei antes, uma das conveniências do meu antigo engine feito em Rails, é que eu tinha feito o ActiveAdmin com suporte a fazer uploads pro meu bucket de S3. E era um setup complicado porque ainda adicionava AWS CloudFront na frente pra fazer cache dessas imagens em CDN e tudo mais.

Mas meu site é ultra-pequeno, não precisa da complexidade de CloudFront, então tirei e agora faço links direto pro bucket, por exemplo: https://new-uploads-akitaonrails.s3.us-east-2.amazonaws.com/screenshot-2025-09-10_00-35-57.png

Significa que meu workflow consiste em tirar screenshots, depois abrir o site de console do meu AWS, e manualmente fazer upload no bucket, via interface web, copiar o link gerado e colar no Markdown do artigo. Não é complicado, mas é um BEM chatinho.

Cheguei a fazer um script besta usando aws-cli mas isso exigia manter um terminal aberto no diretório de screenshots e, manualmente fazer algo como upload-s3 screenshot-2025-09-10_00-35-57.png, o que não é exatamente conveniente também. Aliás, se não sabia disso, você pode automatizar muita coisa da AWS só usando essa ferramenta.

Enquanto estava pensando em escrever este artigo, resolvi consertar esse problema de uma vez. Como sabem, estou usando Omarchy, e o File Explorer padrão dele é o bom e velho Nautilus do GNOME. Gosto dele, parece muito com o Finder de MacOS. Gosto mais dele do que um Dolphin ou Thunar, que parecem mais com o Windows Explorer. E eu nunca gostei de Windows Explorer.

“E se eu pudesse só clicar com o botão direito do mouse em cima do arquivo de screenshot e selecionar ’enviar pro s3’ no menu de contexto e já ganhar a URL copiada no meu clipboard? 🤔”

Que tal assim?

Nautilus suporta scripts de usuário, então fiz o seguinte:

mkdir -p ~/.local/share/nautilus/scripts
nvim ~/.local/share/nautilus/scripts/Send\ to\ AWS\ S3

E eis o script:

#!/usr/bin/env bash
#set -euo pipefail

# ---------- config ----------
BUCKET="new-uploads-akitaonrails" # name only
PREFIX=""                         # e.g., "uploads/"
AWS_PROFILE="${AWS_PROFILE:-default}"

# URL_MODE: presign | public | cloudfront
URL_MODE="public"
PRESIGN_TTL=604800
CLOUDFRONT_DOMAIN=""
MAKE_PUBLIC_ACL=false # keep false unless your bucket denies public reads
# ----------------------------

require() { command -v "$1" >/dev/null 2>&1; }

# clipboard: wl-copy > xclip > none
CLIP_CMD=""
if require wl-copy; then
  CLIP_CMD="wl-copy"
elif require xclip; then
  CLIP_CMD="xclip -selection clipboard"
fi

region() {
  local r
  r="$(aws --profile "$AWS_PROFILE" s3api get-bucket-location --bucket "$BUCKET" \
    --query 'LocationConstraint' --output text 2>/dev/null || echo "None")"
  [[ "$r" == "None" || "$r" == "null" ]] && echo "us-east-1" || echo "$r"
}

public_url() {
  local key="$1" r="$2"
  if [[ -n "$CLOUDFRONT_DOMAIN" && "$URL_MODE" == "cloudfront" ]]; then
    printf 'https://%s/%s\n' "$CLOUDFRONT_DOMAIN" "$key"
  else
    if [[ "$r" == "us-east-1" ]]; then
      printf 'https://%s.s3.amazonaws.com/%s\n' "$BUCKET" "$key"
    else
      printf 'https://%s.s3.%s.amazonaws.com/%s\n' "$BUCKET" "$r" "$key"
    fi
  fi
}

presign_url() {
  local key="$1"
  aws --profile "$AWS_PROFILE" s3 presign "s3://$BUCKET/$key" --expires-in "$PRESIGN_TTL"
}

upload_one() {
  local src="$1" key="$2" args=(--only-show-errors --follow-symlinks)
  if [[ "$URL_MODE" == "public" && "$MAKE_PUBLIC_ACL" == "true" ]]; then
    args+=(--acl public-read)
  fi
  aws --profile "$AWS_PROFILE" s3 cp "${args[@]}" "$src" "s3://$BUCKET/$key"
}

# allow running from terminal with paths as args
if [[ $# -gt 0 ]]; then
  NAUTILUS_SCRIPT_SELECTED_FILE_PATHS="$(printf '%s\n' "$@")"
fi

SEL="${NAUTILUS_SCRIPT_SELECTED_FILE_PATHS:-}"
[[ -n "$SEL" ]] || {
  notify-send "S3 upload" "No selection"
  exit 0
}

R="$(region)"
urls=()
ok=0
fail=0
errs=()

while IFS= read -r path; do
  [[ -e "$path" ]] || {
    errs+=("Missing: $path")
    ((fail++))
    continue
  }

  if [[ -d "$path" ]]; then
    base="$(basename "$path")"
    while IFS= read -r -d '' f; do
      rel="${f#"$path"/}"
      key="${PREFIX}${base}/${rel}"
      if upload_one "$f" "$key"; then
        case "$URL_MODE" in
        presign) urls+=("$(presign_url "$key")") ;;
        public | cloudfront) urls+=("$(public_url "$key" "$R")") ;;
        esac
        ((ok++))
      else
        errs+=("Failed: $f")
        ((fail++))
      fi
    done < <(find "$path" -type f -print0)
  else
    ts="$(date +%Y%m%d%H%M%S)"
    filename="$(basename "$path")"
    key="${PREFIX}${ts}_${filename}"
    if upload_one "$path" "$key"; then
      case "$URL_MODE" in
      presign) urls+=("$(presign_url "$key")") ;;
      public | cloudfront) urls+=("$(public_url "$key" "$R")") ;;
      esac
      ((ok++))
    else
      errs+=("Failed: $path")
      ((fail++))
    fi
  fi
done <<<"$SEL"

out="$(printf '%s\n' "${urls[@]}")"

# --- relax only for UX bits ---
set +e
if [[ -n "$out" ]]; then
  printf '%s' "$out" | wl-copy -n || true # or xclip fallback
fi
if command -v notify-send >/dev/null 2>&1; then
  if ((fail == 0)); then
    notify-send "S3 upload: ${ok} ok" "$(printf '%s\n' "${urls[@]:0:5}")" || true
  else
    notify-send -u critical "S3 upload: ${ok} ok, ${fail} failed" \
      "$(printf '%s\n' "${errs[@]}" | head -n 10)" || true
  fi
fi
set -e
# --- end relax ---

printf '%s\n' "$out"
((fail == 0)) || exit 1

Obviamente troque o BUCKET pelo seu bucket. Se tiver múltiplos buckets, depois reorganize esse script e faça source em múltiplos scripts como Send To Bucket XYZ e Send to Bucket ABC ou algo assim no diretório de nautilus/scripts.

Se quiser testar do terminal, só fazer assim:

# single file
NAUTILUS_SCRIPT_SELECTED_FILE_PATHS="$(printf '%s\n' '/full/path/to/image.png')" \
bash -x ~/.local/share/nautilus/scripts/Send\ to\ AWS\ S3

Notem que comentei o set -e do Bash porque ou o wl-copy ou o notify-send está retornando algum warning ou erro e isso está quebrando o script. Sem isso, termina corretamente e copia a URL do upload no clipboard. Daí posso colar direto no editor de textos.

Bônus: Screenshots em Omarchy

Inclusive, dica bônus de Omarchy: do nada o script de screenshot começou a falhar pra mim. Vamos consertar.

Primeiro, eu queria que os screenshots fossem pro diretório Pictures/Screenshots, segundo, depois de uma atualização, sei lá porque o comando hyprshot parou de funcionar com o satty. Sem paciência durante a madrugada eu editei o script de screenshot do Omarchy, que fica em ~/.local/share/omarchy/bin/omarchy-cmd-screenshot (fucem lá), e substituí por isto:

#!/bin/bash
set -euo pipefail

[[ -f ~/.config/user-dirs.dirs ]] && source ~/.config/user-dirs.dirs
OUT="${OMARCHY_SCREENSHOT_DIR:-${XDG_PICTURES_DIR:-$HOME/Pictures}}/Screenshots"
mkdir -p "$OUT"

satty --filename - \
  --output-filename "$OUT/screenshot-$(date +'%Y-%m-%d_%H-%M-%S').png" \
  --early-exit \
  --actions-on-enter save-to-clipboard \
  --save-after-copy \
  --copy-command 'wl-copy' \
  < <(slurp | grim -g - -)

Na prática, troquei o hyprshot pelo grim, que permite capturar foto de tela de Wayland (cuidado que tem várias ferramentas que só funcionam em X11, Omarchy é Hyprland, portanto, Wayland).

Além disso o Omarchy não tem opção pra tirar foto de tela com timer. Isso é útil quando quero tirar foto de um menu aberto com item selecionado. Se usar o jeito normal com tecla Print-Screen ou usando o menu do Omarchy, o menu que eu tinha aberto pode fechar antes de conseguir a foto de tela. A solução é um timer.

E com grim é fácil, via linha de comando mesmo posso fazer:

sleep 10 && grim -g "2813,948 2560x1440" ~/Pictures/Screenshots/image-01.png

Em Wayland, dois monitores são como se fossem uma única tela gigante, então precisa dar a geometria correta de onde quero tirar a foto. ChatGPT ajuda pra isso se passar o seu .config/hypr/monitors.conf pra ele.

Agora tenho uma forma simples de tirar fotos de tela e enviar direto pro S3, direto do Nautilus, e conseguindo tirar uma foto de tela como esta:

E o programa que eu uso, pra fazer coisas simples como um crop de alguma foto de tela, é o Pinta

Conclusão

Isso é o que lembrei de importante sobre meu novo blog. Acho que ficou muito mais simples de dar manutenção e, mais importante, muito mais simples de escrever artigos: só abrir um editor de textos e pronto. Nenhum deploy mais complicado, tudo automatizado, tudo integrado com meu Omarchy.

Meu blog já tem mais de 20 anos e durante esse tempo eu migrei de engine de blog várias vezes, uma meia dúzia de vezes. Por isso é um esforço inútil achar que você vai acertar logo de primeira e gastar semanas ou meses tentando fazer o engine ideal: você vai fracassar.

No final, a única coisa que interessa é O CONTEÚDO. O exercício de escrever, de escrever o mínimo possível pra comunicar o máximo de informação relevante, de escrever uma história que engaja do começo ao fim, de não virar formato de TCC ou página de Wiki de documentação. Escrever uma documentação é diferente de escrever um post de blog.

É mais importante escrever de uma forma que você mesmo goste de ler depois do que em qualquer linguagem vai fazer sua engine.

DESCRIÇÃO

Andei pensando em como ligar a monetização no canal, porque o YouTube já enfia ads mesmo eu não querendo, e ainda assim manter a confiança de que meus videos não vão ser influenciados por causa disso.

Então hoje vou explicar mais ou menos como funciona a lógica de monetização do YouTube e o que eu pretendo fazer com isso.

SCRIPT

Olá pessoal, Fabio Akita

Pra variar um pouco este vai ser um meta-episódio, um episódio pra falar sobre o canal em si. A última vez que fiz um desses acho que foi um ano atrás, no primeiro aniversário do canal. E hoje quero falar sobre monetização de videos.

Todo mundo sabe que eu não monetizo os vídeos, e tem três motivos pra isso. O primeiro é que eu não gosto de ser interrompido quando tô falando e ads aparecendo no meio dos meus videos me desagrada, tipo, muito. Quer me deixar irritado é me interromper. O segundo é que o canal não foi feito pra ser meu sustento. Eu já tenho meu sustento na minha empresa, que vai muito bem, obrigado. E o terceiro motivo é só uma consequência lógica: eu tenho liberdade pra falar o que bem entender sem me preocupar em perder público e diminuir monetização, ou seja, eu não tenho nenhum incentivo financeiro pra fazer clickbait e discurso puxa saco pra agradar ninguém.

Porém, alguns de vocês devem estar coçando a cabeça e pensando “ué, mas eu tenho visto ads nos videos do Akita”. Pois é, isso me fez repensar no assunto e por isso resolvi explicar o que tá acontecendo e dizer o que vou fazer a respeito.

(…)

Eu nem tinha me ligado disso mas já faz alguns dias que algumas pessoas têm me mandado DMs no Insta perguntando porque estão vendo ads nos meus videos. Pra tirar a dúvida eu fiz uma enquete no Twitter e na aba de comunidade do próprio YouTube. Tive mais de 700 votos no Twitter, mais de 6 mil no YouTube e a conclusão nos dois foi a mesma: pelo menos um em cada três de vocês me assistindo passaram por propaganda pra ver o vídeo. Ou seja, dizer que não quer monetizar o video não é a mesma coisa que garantir que não vai ter propaganda, só quer dizer que eu estou abrindo mão de receber por isso.

Quando comecei o canal uns 2 anos atrás, vi todas as boas práticas que todo mundo repetia, tipo fazer videos curtos, de uns dez minutos, fazer pelo menos um video toda semana e todo esse bla bla bla. E ao longo do tempo eu fui testando essas premissas e vendo que não faz nenhuma diferença pra mim. Como eu imaginava a única coisa que importa é conteúdo de qualidade que engaja e faz as pessoas voltarem. Todo o resto é bullshit. É o famoso, não adianta passar batom num porco, por baixo continua sendo um porco. Não interessa se você tem a melhor câmera 8K se não tem nada de interessante pra filmar com ela.

Se o conteúdo é meia boca, você é obrigado a ficar usando técnicas de clickbait pra atrair novas pessoas. Quando pessoas minimamente inteligentes vêem que era clickbait, elas vão embora e não voltam. O problema é quem fica. Começa a acumular o pior tipo de público, os haters, incels, neets, exatamente o oposto do que eu quero. Por isso eu comecei o canal focando em conteúdo que agrada o usuário mais exigente de todos, eu mesmo. O canal é feito pra mim e depois pros outros. E todos os videos que eu faço podem ser assistidos a qualquer momento, porque ele não é dependo da época em que foi feito. Por isso o canal é bom pra maratonar. Depois do primeiro ano eu diminui a frequência de videos, ao mesmo tempo também comecei a aumentar o tempo dos videos até chegar a absurdos 60 minutos num único video. E mesmo fazendo isso eu continuei crescendo.

Vou abrir meus analytics aqui pra vocês verem como anda o crescimento. Em 2020, até outubro tivemos quase 4 milhões de visualizações. Isso deu mais de 800 mil horas assistidas. E dos cento e setenta mil inscritos, mais de cento e vinte vieram só este ano. No fim do ano passado eu lembro que ainda não estava com 60 mil. A grande virada veio com a dupla de videos sobre o Covid-19 e logo na sequência o Guia Definitivo de Aprendendo a Aprender. Somados, esses dois deram quase um milhão de visualizações. Também deu pra ver que mesmo ficando um período grande sem postar vídeos, mais de um mês aqui entre julho e agosto, não diminuiu a audiência, o que é uma boa notícia pra mim. Meus videos não dependem tanto de muita gente nova e sim de manter as pessoas que já acompanham. E isso se faz com bom conteúdo.

Mas tem uma coisa que eu ainda não testei. Dizem que o YouTube tem menos incentivo de impulsionar e recomendar videos se eles forem desmonetizados. E isso faz sentido. O site tem espaços limitados como a coluna da direita, a página de tendências, os cards de recomendação quando os videos terminam e assim por diante. Se o espaço é limitado então o algoritmo precisa escolher quais videos quer impulsionar e obviamente faz sentido só recomendar aqueles que tenham chance de dar mais dinheiro. E o meu certamente tá no fim da fila porque dá menos dinheiro.

Imagino que essa seja uma das razões de porque eu não sou elegível pra ter a placa de 100 mil assinantes mesmo já estando quase nos duzentos mil. Porque meu canal dá pouco dinheiro pro YouTube. Aliás, muita gente não sabe disso, a placa não é automático pra todo mundo que chega num determinado número de seguidores. O YouTube tem critérios secretos pra escolher, e ele só manda pra quem ele gosta. Obviamente ele não gosta muito de mim, mas tudo bem, o sentimento é mútuo. Se eu fosse funcionário do YouTube, também ficaria com receio de mandar pra esse japonês doido porque vai que ele quebra a placa em público?

Ou seja, mesmo com o YouTube não querendo ajudar muito porque meus videos não dão muito dinheiro, chegamos a mais de cento e setenta mil assinantes e média de cinquenta mil views por video em dois anos. Isso me deixa pensando, quanto mais poderia chegar se meus videos dessem mais dinheiro pro Youtube? E o YouTube sorrateiramente já dá um jeito de conseguir uns trocados com meus videos, inserindo uns ads aqui e ali mesmo que eu não queira. Então acho que é hora de fazer o YouTube trabalhar um pouco mais a meu favor, pra variar.

Por isso eu decidi ligar a monetização de todos os videos a partir de hoje. Pra quem não gosta de ads, calma, continuem vendo até o fim! Como eu já disse, não tenho interesse em ganhar dinheiro com YouTube. Eu também continuo não aceitando ações patrocinadas porque não quero poluir meus videos com propaganda permanente neles. Fora que o que oferecem de pagamento literalmente não vale meu tempo pra responder.

Antes de mais nada, deixa eu mostrar a minha página de analytics de faturamento. Como podem ver, nos dois anos que eu tenho o canal, só tem um bleep ali de teste onde eu arrecadei um centavo. Teoricamente, se eu ligar a monetização na configuração mais minimalista possível, sem nenhuma propaganda que não pode pular e coisas assim, acho que eu devo conseguir faturar algo em torno de mil reais.

Não é grande coisa, mas é alguma coisa. Dependendo de quanto dinheiro der, todo mês ou a cada dois meses eu quero doar cem porcento do arrecadado pra projetos de alguma entidade de ensino confiável. Isso mesmo, não vai ser uma ação de marketing como muita gente faz de doar uma parte ou um valor fixo. Estou falando de tudo mesmo. Antes de vocês irem correndo nos comentários, deixa eu explicar em mais detalhes.

No video da semana passada mesmo, que falei do documentário do Dilema das Redes, eu concluí dizendo que o problema real que o documentário omite é que a grande culpada por manter as pessoas sem ferramentas pra reagir a fake news e comportamento tóxico em grupos de redes sociais é a baixa qualidade do nosso sistema de educação. E regulamentar coisas como redes sociais é um tapa buraco por não ter feito o trabalho direito antes. E claro, eu sozinho não vou chegar nem perto de consertar esse problema.

Com o canal e todo material que eu sempre fiz, talvez ajude algumas pessoas. Já é alguma coisa. E agora eu quero colocar meu dinheiro onde está minha boca. Só ficar latindo “as coisas estão ruins” é coisa de preguiçoso querendo ganhar biscoito fazendo sinalização virtuosa. É o mínimo, porque se nem você acredita na causa o suficiente pra colocar seu próprio dinheiro, porque você acha que alguém deveria colocar o dinheiro deles?

Mas eu já prevejo que vai ter gente pau no cú dizendo: Ah Akita, mas isso é fácil, você não tirou dinheiro do seu bolso, só doou o que foi gerado pelas “minhas” visualizações. Calma, eu ainda não terminei de falar. Como eu disse antes, meu canal ainda é bem pequeno e eu acho que se ligar a monetização, chuto que fique na faixa de mil reais. Então, por alguns meses, eu vou cobrir minha própria aposta.

Pra cada real arrecadado de visualizações eu vou colocar mais um real do meu bolso. Na realidade do bolso da minha empresa, a CodeMiner 42. A missão da CodeMiner é justamente formar profissionais melhores que o mercado médio consegue oferecer. Por isso eu já tinha explicado no video de Aprendendo a Aprender que damos chance pra recém-formados começarem a ganhar experiência por exemplo. De qualquer forma, se o canal arrecadar mil reais, a CodeMiner coloca mais mil. Se arrecadar dez mil reais, colocamos mais 10 mil do nosso bolso. Até chegar num volume de arrecadação expressivo que eu não precise mais cobrir. Depois decido quanto é esse limite.

Aí vem outro ponto que gera controvérsia. Quem vai receber esses fundos? E não é pra ter controvérsia. Eu estou tirando dinheiro do meu bolso, então quem escolhe sou eu. O foco vão ser projetos em universidades públicas. As privadas não precisam do meu dinheiro. A prioridade vai primeiro entre as doze cidades onde tenho escritórios, mas não estou limitando e pode ser de qualquer lugar do país. Ainda não tenho nenhuma regra escrita em pedra a não ser que precisa ser projetos ligados à educação, e vou precisar da ajuda de vocês. Se tiverem ou souberem de projetos, que tem apoio de corpo docente da faculdade, especialmente focado em software livre, mande a proposta pro email que está aqui embaixo: akitando@codeminer42.com

E nem percam tempo se estiverem procurando seed money pra algum empreendimento particular ou startup porque não é esse o objetivo. Falar em dar dinheiro sempre é um problema porque quem não recebe se sente pessoalmente atingido em vez de pensar que alguém que realmente precisava está recebendo. É assim que a maioria das pessoas sempre pensa, que a “causa” delas é sempre mais importante que dos outros. Não seja mesquinho. Às vezes não é que você não mereceu e sim que eu só vou ajudar um por mês, então muitos vão esperar na fila mesmo.

E como vocês vão ficar sabendo quanto arrecadou e que projeto foi beneficiado? Eu não vou fazer video todo mês reportando porque eu acho um tédio fazer relatório. Não vou fazer. Quem tiver interesse em acompanhar, sigam o Twitter da CodeMiner que sempre vamos publicar um screenshot da página de faturamento do meu analytics do YouTube e que projeto foi escolhido. Mas não fiquem fazendo spam de mensagens diretas no twitter, insta, aqui nos comentários ou tudo que é lugar. O único lugar que vou aceitar propostas de projetos é no email que eu falei. Não é quem grita mais alto que ganha, é que proposta eu acho melhor.

“Tudo bem Akita, tudo isso é legal e tals, mas eu continuo odiando ver ads, como fica?” Olha, é mentira se você disser que só assiste meu canal porque ele não tem ads. Porque todos os outros canais tem ads. Se você realmente odeia ads já paga Premium como eu ou dá um jeito pra bloquear ads. Não é meu canal que faz diferença pra você. Todo mundo que disser que vai deixar de ver meu canal porque agora tem que ver ads está dizendo um enorme bullshit. Eu não sou contra bloquear ads, aliás, quem me acompanha no Twitter sabe que em casa eu tenho um Raspberry Pi com Pi-Hole instalado pra filtrar chamadas de DNS. Por cima disso eu tenho o Adblocker Ultimate quando uso Chrome ou Edge. Eu bloqueio a maioria dos ads que dá.

Pelos comentários que recebi nas enquetes, é bom ver que uma boa parte de vocês já faz a mesma coisa ou usa navegadores como Opera ou Brave que nativamente tem funcionalidades de bloquear ads. Como o YouTube aleatoriamente já adiciona ads em qualquer lugar, milhares de vocês já tem esse problema hoje, quer eu ligue a monetização ou não. Pelo menos ligando eu acho que vou ter a opção de minimizar a quantidade de ads, porque pelos screenshots que alguns de vocês me mandaram, tem videos meus que o YouTube enfiou meia dúzia de ads no meio dos videos, que é exatamente o que eu odeio.

Então a conclusão que chegamos é simples. Não ligar monetização não impede ads, só vai fazer o YouTube ganhar mais dinheiro em cima nas minhas costas. Quem tem problema com ads eu recomendo que use navegadores como Brave ou pelo menos instale extensions como Adblocker. Mais do que isso, se você quer bloquear em celulares android ou Smart TVs que usam Android existem dois forks do app do YouTube que foram modificados pra melhorar funcionalidades e também bloquear ads. Um deles é o Smart YouTube TV pra instalar em Smart TVs e tem o YouTube Vanced pra instalar em smartphones.

Claro, são apks que você vai instalar de fora do Google Play Store, então vai ser obrigado a confiar num terceiro te dando um binário, o que não costuma ser uma coisa segura de se fazer. Eu recomendo que vocês pesquisem bem a respeito antes de instalar apks desconhecidos por fora da Play Store. Normalmente eles tem projetos abertos no GitHub pra você mesmo gerar seus próprios apks e garantir que não tem malwares embutidos. Pra quem é programador, pode ser um bom exercício. Nem me peçam pra fazer videos detalhando essas coisas porque é o tipo de conteúdo que já tem de dúzias por aqui e eu não vou ficar fazendo tutorialzinho de coisa que se acha em 2 minutos pesquisando no Google.

Acho que meu público já é esperto o suficiente pra saber o que fazer. Por outro lado, se você não se incomodar com alguns poucos ads, também pode ficar sossegado porque o dinheiro é pouco e insuficiente pra me enviesar. Fora que vai tudo pra projetos de educação. E de novo, quero a ajuda de vocês. Se conhecerem professores de universidades particulares, ou colegas trabalhando em projetos de pesquisa ou qualquer coisa assim, não deixe de compartilhar esse video. E não sejam mesquinhos nos comentários. Obviamente eu não posso ajudar todo mundo, então não se sintam mal se seu projeto não foi escolhido dessa vez por exemplo.

O que vocês acham? Parece justo? Se curtiram mandem um joinha, assinem o canal, não deixem de clicar no sininho pra não perder os próximos episódios. E sempre ajude o canal compartilhando o video com seus amigos. Aliás, o dinheiro não é um motivador pra mim, mas gente assistindo é, então realmente compartilhem. É o que mais ajuda o canal. Por hoje é isso aí, a gente se vê, até mais.

Finalmente!! Chegamos a 1 ANO do Canal Akitando!

Foi uma jornada incrível, absolutamente difícil, eu praticamente me coloquei na missão de fazer o equivalente a 1 palestra completa, densa e detalhada, TODA SEMANA ao longo de 1 ano inteiro!

Quero compartilhar com vocês um pouco de como eu pensei no conceito do canal, como eu produzo os vídeos e um pouquinho de bastidores.

O vídeo de hoje não tem nenhuma grande missão a não ser comemorar! Obrigado a todos vocês que acompanham o canal e espero que continuem compartilhando os vídeos pra que esse acumulado de informações consiga chegar a mais pessoas.

Continuem compartilhando os videos pra ajudar o conteúdo a chegar a mais pessoas!

== Links:

• Instagram: nova lente Canon 50mm (https://www.instagram.com/p/BopuVbIlDmy/)

• Instagram: teleprompter quebrado (https://www.instagram.com/p/BnSlwbLFKvu/)

• Instagram: Tascam audio recorder (https://www.instagram.com/p/BnNSxYflB_c/)

• Instagram: Softbox (https://www.instagram.com/p/BnCmByVFn-A/)

• Instagram: lente 50mm chinesa - hórrível (https://www.instagram.com/p/Bmt1wlxlQhr/)

• Instagram: Canon Rebel EOS T7i (https://www.instagram.com/p/Bmg9hrClWIE/)

• Instagram: Meu 1o setup (https://www.instagram.com/p/Bmb6pr7FEm5/)

• Workstation Rocketz (https://rocketz.com.br/workstation)

• AkitaOnRails: Transcripts dos episódios (https://www.akitaonrails.com/akitando)

=== Script

Olá pessoal, Fabio Akita

Se eu não errei minhas contas, o canal completa um ano esta semana. Eu tinha algumas metas na minha cabeça quando comecei o canal e hoje é o dia de falar dos bastidores. Acho que a meta mais interessante é a quantidade de inscritos, no momento que estou gravando este video o canal está com mais de 26 mil inscritos. Ainda tá longe de eu ganhar uma plaquinha, mas quando comecei o canal eu tinha na cabeça que se eu conseguisse chegar em 10 mil assinantes depois de um ano, já seria suficiente. Então eu diria que mais do que o dobro da minha meta não é nada mal. Obrigado a todos vocês pela ajuda e espero que continuem compartilhando os videos pra ajudar a levar o conteúdo pra mais gente.

Este canal não é a primeira vez que eu busco canais diferentes pra compartilhar meu conhecimento. Quem me acompanha faz tempo já leu os posts do meu blog, já deve ter ouvido o podcast de Ruby on Rails que eu fazia com o Carlos Brando ou minhas participações no Grok Podcast do camarada Rafael Rosa, os screncasts de Git e Vim que soltei em 2011, o primeiro livro de Ruby on Rails em 2007, enfim, é meio que uma obsessão pessoal documentar as coisas que aprendi de alguma forma. Eu acho um desperdício ter aprendido um monte de coisas que até hoje não são tão óbvias e esse conhecimento acabar em mim quando eu morrer.

Todo mundo já deve ter tido vontade de escrever um livro. Se você assistiu meu episódio sobre o Diário de Henry Jones, já sabe que eu sempre quis. Nos anos 2010 a mídia é video, e o canal é YouTube, então o objetivo foi começar a dar um dump do meu cérebro em forma de video. Vocês já devem saber que os videos não são monetizados e nunca foi objetivo eu tirar meu sustento do canal no futuro nem nada disso. Inclusive vocês vão notar que eu sequer uso pra fazer propaganda das minhas próprias empresas, porque eu quero que os videos sejam atemporais, que se você assistir em 2030 eles continuem valendo. Espero que o YouTube dure até 2030. Por isso também já recusei algumas propostas de patrocínio. Agradeço a quem teve interesse mas eu não quero colocar coisas no video que se tornem obsoletas com o tempo, como anúncios.

Na realidade o objetivo original do canal é que um dia eu termine. Ainda não tenho certeza de como as coisas vão andar, mas se for conforme eu visualizei um ano atrás, em breve vai acabar as coisas que eu tenho a dizer, e quando escrevi o primeiro episódio meio que comecei um rascunho do que seria o último capítulo também. Mas vou dizer que quanto mais gente aparece pra assistir menos me dá vontade de terminar o canal, então vamos ver.

(…)

Todo mundo quando pensa em bastidores de video começa imaginando um Adobe Premiere, ou Final Cut X e eu editando os diversos clips. Como eu já disse no episódio sobre os problemas que tive com o Premiere um mês atrás, a parte da edição na realidade é a mais fácil. A parte difícil começa antes. Quando eu sei o que eu quero escrever eu simplesmente sento na frente do computador, abro o Google Docs, e começo a escrever como se não houvesse amanhã. Se for um dia que eu estou na zona de concentração, eu consigo escrever 20 páginas de word de uma só vez. É a melhor sensação do mundo. Em particular, estou escrevendo os episódios 56, 57 e 58 tudo de uma só vez, meio porque eu já sabia o que queria falar.

O problema são as semanas que eu não tenho tanta certeza sobre o que dizer. Eu assisto dezenas de canais do YouTube e achei engraçado quando vi um no canal do Gigguk que fala de animes. Assim como eu, ele também escreve scripts antes e o processo dele é muito parecido com o meu, então olhem como a gente faz pra escrever scripts:

(…. video gigguk ….)

Pois é, a parte mais chata é escrever os episódios. Muitos episódios eu escrevo e reescrevo múltiplas vezes. Eu estou na página 6 ou mais, e resolvo que tudo que eu escrevi tá uma droga, apago tudo e começo tudo de novo. Vários episódios foram assim. No começo do canal eu ainda não tinha idéia de quanto tempo os videos deveriam ser. Algum lugar alguém falava que o ideal eram vídeos de não muito mais que 10 minutos, ou 15 minutos no máximo. Isso são umas 6 páginas de Word. Por isso vocês vão ver que meus primeiros vídeos são curtos.

Eu também odeio, odeio o formato de vlogs ou simplesmente videos que o autor dilui o conteúdo demais. Sério, tem videos por aí que entre apresentação, introdução, propaganda, leva uns 5 minutos pra chegar no assunto do vídeo, daí esse assunto é super simples e dava pra resumir em um slide de 30 segundos, mas aí ele dilui mais ainda esse conteúdo pra mais 5 minutos e finalmente leva outros 5 minutos fazendo gracinha e piada sem graça. E assim foram 15 minutos jogados fora. Horrível, fora o pacing lento, ritmo irregular, dicção ruim, áudio não normalizado que fica saltando o volume toda hora. Horror, horror.

Se eu ia fazer um video de 15 minutos eu faço questão que no mínimo 14 minutos sejam de conteúdo, e não mais que 1 minuto pra apresentação, intro e finalização. Eu como consumidor de conteúdo prefiro esse formato então é assim que eu ia fazer.

O nome do canal veio numa conversa com o povo do escritório. Eu ia gravar no meu quarto, como gravo até hoje, então num momento cheguei a pensar em “No quarto com o Akita” …. Éee eu sei! Felizmente camarada Harry deu a idéia de fazer o nome como um verbo e virou Akitando. Com o nome definido eu procurei algumas intros pré-prontas de After Effects, comprei, editei e assim você tem a intro que aparece em todos os videos. E o formato seria um Olá pessoal logo no começo e direto ao assunto. E no final eu queria parodiar fazendo a mesma coisa que todo YouTuber faz que é pedir o joinha e pra assinar o canal, e no final acabou ficando no formato também.

Os primeiros videos foram bem experimentais. Eu queria aproveitar que tinha acabado de começar uma peregrinação pelo mundo de blockchain, tinha acabado de lançar minha própria exchange de criptomoedas e comecei fazendo um vídeo sobre minha viagem pra Coréia do Sul. Assisti alguns tutoriais de Premiere, achei um site de teleprompter que é o easyprompter e coloquei no monitor. Como câmera eu tinha uma DJI Osmo que serve como estabilizador mas como eu não tinha uma câmera de verdade e nem tripé pro celular, acabei usando esse DJI como câmera, por isso a composição e foco são bem diferentes dos videos de hoje. Eu coloquei o DJI na frente do monitor e ficava lento o monitor atrás dele.

Os primeiros videos foram feitos assim, a camera na frente do monitor e lendo. Foi horrível fazer assim porque obviamente a camera uma hora ficava na frente do texto passando atrás. Mas eu ainda nem sabia se ia continuar com o canal mesmo ou não. Apesar de eu já ter estabelecido o conceito que eu não ia monetizar o canal e que não importava quantas pessoas assistissem, eu só queria tentar gravar alguma coisa, mesmo assim publicar o video e não ter mais que algumas pessoas assistindo, dói um pouco. Porque pra fazer cada video demora algumas horas de trabalho. Todo canal começa do zero, zero pessoas, zero views, zero interesse. Inscritos, visualizações e likes são métricas de vaidade, eles não são e não devem ser o objetivo, mas todo mundo gosta de ter um pouco mais de visualizações.

Enfim, independente disso, com zero views ou não, o processo de fazer um video realmente era divertido. Mas com o equipamento que eu tinha até então tava difícil. Foi quando decidi investir em comprar uma câmera de verdade, nada super fancy, só uma Canon EOS Rebel T7i e um teleprompter de verdade. No 6o video só que comecei a usar o novo equipamento, e já melhorou um pouco a qualidade mas a lente padrão que vem na câmera era bem ruinzinha. Então comprei uma lente 50mm chinesa via mercado livre que usei em alguns vídeos, mas vocês vão ver que a qualidade da imagem era uma droga. Acho que foi só no video do Diário de Henry Jones que comecei a usar a lente 50mm original da Canon e o auto foco é ordens de grandeza melhor. Daí venho usando a mesma configuração de câmera desde então.

Um bom video de conteúdo deve ser feito com um teleprompter, a menos que seja show ao vivo, claro. Todo bom YouTuber profissional deve planejar o conteúdo antes de apresentar. Eu acho um desrespeito sair filmando de qualquer jeito e ficar só enchendo linguiça. Eu não gosto de perder tempo e também não quero que quem assista meus vídeos perca tempo. Por isso eu gasto tempo escrevendo e refinando os scripts e depois uso um teleprompter. A dificuldade foi acertar a velocidade do prompter. Os primeiros videos ficaram mais lentos do que eu gostaria, levou alguns videos pra achar a velocidade certa, que na verdade é a velocidade máxima que eu consigo falar e manter a dicção correta sem mastigar palavras. Eu gosto de pessoas que falam corretamente, então o mínimo que eu devo fazer é falar o mais corretamente possível pra que todos possam entender.

O problema de usar um teleprompter é que ele é um sistema de espelhos e uma câmara escura. A gente coloca o tablet deitado, tem um espelho em 45 graus que vai refletir o que tem no ipad pra que eu possa ver mas não reflete pra dentro que é onde a câmera está posicionada, dentro de uma câmara escura. O segredo de uma boa imagem em qualquer câmera é dar a ela o máximo de luz possível e esse setup na realidade reduz a quantidade de luz que chega na câmera.

Eu também prefiro filmar de noite, depois das 20h pra garantir que tem menos movimento no prédio, nos vizinhos, na rua. Meu apartamento felizmente é bem vedado contra som, mas mesmo assim dá pra ouvir alguma coisa. Eu odeio barulho de fundo, então só me resta gravar de noite mas não tão tarde que eu fico com sono. Já notei que quando eu filmo com sono minha dicção piora bastante, daí eu sou obrigado a repetir vários trechos do texto, várias vezes e demora bem mais pra gravar.

Somando o prompter e filmar de noite, significa que eu preciso de luz artificial, muita luz artificial. Eu comecei com um ring light mas ele é muito fraco e só depois eu entendi que esse ring light é pra pessoas que querem aparecer com os olhos brilhantes. Mas como eu uso óculos isso nem ia funcionar. Finalmente comprei um bom soft box, que é um difusor de luz, e testei vários tipos de lâmpadas frias e finalmente consegui uma configuração de uns 4 mil lumens, que é o mínimo que meu ambiente precisa pra câmera conseguir captar boas imagens. O ideal seria ter mais um softbox com a mesma potência, mas por enquanto eu estou usando o ring light do meu lado esquerdo fora do frame pra criar edge light, que é uma delineação de luz no meu rosto de um lado.

(apagar ring light)

Falando no ambiente, meu quarto é um quarto normal, branco, tédio. Aos poucos fui colocando alguns elementos pra tentar criar camadas na composição. Vocês já devem ter visto meu lava lamp que não funciona no fundo. Eu quebrei o primeiro e comprei um segundo que não funciona. E falando em quebrar coisas, já quebrei um ou dois teleprompters na real. Eles ficam num tripé e são pesados em cima, então gravar com sono a noite tem outro problema além da qualidade: você esbarra nas coisas e quebra, pois é.

Recentemente eu resolvi comprar leds pra colorizar o fundo. Eu já tava de saco cheio do fundo branco. Outro erro que cometi aprendendo a editar foi errar no color grading, eu queria tentar deixar a imagem um pouco mais quente e exagerei em alguns videos que vocês podem ver que são um pouco demais alanranjados ou avermelhados. Só alguns meses atrás que eu finalmente acertei o color grading pra algo mais neutro, com mais saturação. Veja a diferença do que a câmera grava e de como fica quando eu coloco a correção de cores. Até aqui você está vendo com correção, agora vamos remover a correção …… e …. Colocar de volta, viram a diferença?

Ah sim, e vocês devem ter visto meus amiguinhos de pixel art que eu sempre deixo no fundo. Finalmente vou mostrar em maior qualidade. Eu comprei eles na Comic Con do ano passado, que aliás é onde eu comprei todas as camisetas que eu uso no canal. Todo mundo me pergunta onde comprei, e foi em lojas como Piticas, Geek, Riachuelo, e outras marcas que não lembro agora, e alguns eram exclusivos pra Comic Con então não se acha fácil. Além disso eu tinha comprado algumas em galerias da Liberdade também, como no Sogo. Este ano eu vou na BGS e na Comic Con de novo então vou acabar comprando mais camisetas suficientes pros videos do ano que vem.

Com o tempo também eu fui acertando a posição da câmera. Antes aparecia uma parte da minha cama, eu preciso jogar ela pro fundo do quarto pra dar distância pra câmera. Com o tempo eu achei uma composição que não preciso mais mostrar a cama. E com as luzes de fundo fica algo um pouco mais abstrato e com texturas. Não sei se todo mundo gosta, mas eu acho que pelo menos cria uma identidade diferente do que só um fundo branco. Eu particularmente não gosto de fundo verde e chromakey feito com câmeras como a minha. Eu só usaria chromakey num ambiente maior, onde eu posso jogar spots de luz no fundo verde pra tirar as sombras e mais softbox na minha frente com uma câmera 4K de verdade onde posso ajustar melhor a separação. Um dia eu vou tentar fazer isso mas não vai ser com esse equipamento e nem no meu quarto. Se um dia eu mudar pra um estúdio aí sim. Não tem nada pior que um chromakey amador, que fica cheio de aliasing nas bordas tipo cabelo, acho horroroso e jamais faria com o equipamento atual.

Uma coisa que realmente dá trabalho na edição é ficar toda hora pesquisando google images e outros bancos de imagens e mesmo capturar algum clipe de video pra colocar do meu lado no video. Eu sempre escrevo os textos já assumindo alguma ajuda visual pra reforçar algumas partes do que estou falando e dar referências pra quem está assistindo. E é um dos motivos de porque eu não transformo meus vídeos em podcasts. Muita gente pediu esse formato, mas eu não pretendo fazer agora porque eu escrevi todos os scripts assumindo a midia de video. Sem isso só o audio fica incompleto. Eu teria que reescrever os scripts considerando uma midia só audio e realmente não tenho tempo pra fazer isso agora.

A mesma coisa é sobre gravar uma versão em inglês. Seria o dobro de trabalho, e eu realmente não tenho tempo pra fazer isso agora. Uma coisa que pretendo fazer a partir de agora é começar a liberar os textos dos scripts no meu blog. Estou protelando isso faz algum tempo, mas é mais preguiça do que qualquer outra coisa. Daí se alguém se interessar em contribuir, poderia adicionar legendas em inglês por exemplo, eu ia achar bem da hora se alguém tivesse tempo pra fazer isso.

A gravação é feita em etapas, em clipes de no máximo 30 minutos porque as câmeras fotograficas como a Canon que eu uso, pra poder ser considerada uma câmera de fotos na Europa, não pode gravar clipes de video maiores que 30 minutos. É mais uma dessas regulamentações que a Europa adora inventar. O que eu faço é deixar meu celular conectado na câmera e me mostrando o que a câmera está vendo e aí eu fico monitorando o tempo e páro antes dos 30 minutos. O problema era quando eu gravava com sono como eu falei e esquecia de verificar o tempo. Várias vezes eu ficava falando que nem um idiota achando que tava gravando mas a câmera tinha batido nos 30 minutos e parou de gravar… Quando eu via que não gravou os 20 minutos que eu fiquei falando a mais, dá aquela vontade de pegar a câmera e jogar no teto.

Eu cheguei a comprar um capturador da Elgato pra ligar a câmera diretamente no computador e capturar o feed, que é o que os streamers de Twitch fazem. Mas eu nunca confiei muito nesse setup, fora que meu computador ligado faz barulho e eu preferia não ter que editar o barulho depois, então ainda estou gravando direto na câmera só. Outra coisa que eu faço é usar um gravador de áudio bom, no caso eu tenho esse Tascan que eu ligo um microfone de lapela simples da Sony. A câmera grava o áudio ambiente mas é um áudio porcaria que não dá pra usar, mas serve como referência pra sincronizar com o áudio melhor. Áudio é extremamente importante, uma imagem ruim é até perdoável, mas se o áudio for ruim todo mundo pára de ouvir. Por isso eu acho o equipamento de áudio e a acústica do ambiente muito mais importante do que a câmera. Felizmente tenho pouco eco no meu quarto então não precisei colocar placas pra cortar eco.

No geral, se eu estou inspirado, um script leva entre 4 a 8 horas pra ficar pronto. Algo na média de 20 páginas de word revisados. Depois eu levo algo entre 1 hora a 1 hora e meia pra gravar. Finalmente mais umas 5 a 8 horas pra editar o video. Primeiro eu sincronizo o video da câmera com o áudio do Tascan. Coloco um adjustment layer pra adicionar a correção e graduação de cores, e agora vou cortando fora os trechos que eu errei e toda pausa entre parágrafos pra ficar o mais compacto e linear possível. Depois do rough cut eu começo a assistir e vou adicionando os elementos visuais e efeitos especiais se precisar. E só no final eu escolho uma trilha sonora pro começo e pro fim do video. Antes, quando os videos eram mais curtos, eu tentava manter uma música tocando em background pelo video inteiro, mas eu já percebi que sou muito ruim pra acertar a música e o volume em todo episódio, teve vezes que acertei, teve vezes que errei, mas no fim já vi que não é necessário ter música pela maior parte do video, por isso reduzi.

Aqui entra também o workstation que eu comprei pra editar. Faz muita diferença. Eu noto uma diferença clara na responsividade do Premiere se rodar nesse workstation ou se rodar no meu notebook, que não é fraco, sendo um Thinkpad X1 Extreme. Um vídeo de uma hora no meu workstation leva tempo real ou menos pra renderizar, ou seja no máximo uma hora. Mas no meu Thinkpad o mesmo video pode levar quase 2 horas. E quando você está terminando de editar 1 hora da manhã, essa 1 hora faz muito diferença, especialmente se você erra e precisa renderizar de novo. Eles não me patrocinam mas eu comprei a workstation online na Rocketz, que tem configurações muito boas pra quem mexe com edição de video ou renderização 3D profissionalmente e precisa de uma máquina decente. Fiquei surpreso quando depois de comprar recebi um e-mail do dono da Rocketz dizendo que já lia meu blog. O mundo é mesmo bem pequeno!

Finalmente, eu escolho um frame do video e uso em cima de um template de thumbnail que eu fiz no Photoshop. Escolho uma cor diferente por video, só no final eu decido qual vai ser o título, e daí a última coisa a fazer, normalmente 2 horas da manhã é subir o video pro YouTube, subir o thumbnail, descrições, cards e é isso aí, tudo pronto!

Todo mundo diz que é fácil começar a ser YouTuber, que basta pegar seu smartphone, gravar de qualquer jeito e subir. E de fato, se você for algum desses com carisma natural, talento de presença de câmera e tempo de comédia ou algo assim, talvez consiga mesmo atrair audiência mesmo com baixa qualidade técnica. Mas isso é exceção, não é regra. Dá pra começar barato, mas precisa investir o quanto antes se quer levar isso a sério. E não espere ganhar a vida fazendo YouTube, isso é super raro de acontecer e eu não recomendo como carreira. Se eu tivesse aberto monetização eu ainda não estaria ganhando mais que alguns poucos reais por video, e não estou nem falando centenas de reais, eu diria que seria menos que isso. No meu caso eu já disse que não tenho expectativa nenhuma de ganhar a vida no YouTube. Eu estou usando o YouTube pra hostear meus videos e só, meu único objetivo é fazer meus videos do jeito que eu quero fazer, independente se vai atrair muita gente ou não, porque pra mim é como se eu estivesse escrevendo um tipo de biografia, com começo, meio e eventualmente um fim.

A vantagem do jeito que eu estou fazendo é que eu já tenho mais de 40 anos, eu já tenho uma carreira que está ótima, eu economizei, acumulei recursos e finalmente tenho tempo pra poder contar sobre experiências e pesquisas de verdade. Como eu falei nos meus videos, tudo tem seu tempo. Eu não vejo nenhuma vantagem de falar sobre programação quando eu ainda nem tinha anos de experiência suficiente. Eu gosto de ver gente que tem experiência falando. Se for pra ver tutoriais básicos, eu leio um post de blog ou a documentação oficial, não precisa de video pra isso. Por isso eu quis falar sobre coisas que não se encontra facilmente por aí.

E também por isso chegou uma hora lá no começo que eu estava fazendo 2 videos de 15 minutos por semana, resolvi fazer um video semanal de 30 minutos. Quando eu vi que ninguém reclamou, fui subindo, 40 minutos, 45 minutos, 50 minutos e alguns batendo uma hora. O video de Ubuntu tem uma hora e vinte quase e é o segundo video mais assistido do canal nos últimos tempos. Portanto eu vou fazer os videos do tamanho que eu quiser mesmo. Na prática, quem prefere videos mais curtos pode simplesmente pausar e continuar depois. Se eu fosse obrigado a manter os videos no tamanho de 15 minutos o de Ubuntu teria levado umas 5 semanas pra todo mundo ver tudo. Isso é muito devagar! A série de Começando aos 40 que levou mais de 10 semanas pra ficar pronto teria levado 30 ou 40 semanas pra publicar tudo, eu teria ficado o ano inteiro falando só disso. É muito tedioso! Eu quero falar de outras coisas rápido.

E tudo isso é uma faca de dois gumes. Porque num formato longo eu me vejo na obrigação de quase escrever papers em cada script. Eu não queria só dizer “é assim que as coisas são e pronto” eu quero explicar em detalhes o processo de como se chega nessa conclusão, e aí os scripts vão ficando mais e mais complicados. O da semana passada por exemplo compila num único script argumentos que saíram de mais de meia dúzia de livros diferentes. E eu escrevi tudo em 2 dias. Pensa a dificuldade de lidar com esse tipo de densidade de informações de uma só vez. Por isso mesmo eu acho que nesse design, uma hora essa série vai ter um último capítulo.

No começo do canal eu tentei falar de outros assuntos como filmes, mas acho que eu não tenho vocação pra falar desse tipo de conteúdo, então vou me focar nos temas que eu me sinto mais a vontade falando, que são os videos que vocês viram durante este ano. E se você ainda não assistiu todos eu recomendo que veja, eu estou fazendo de um jeito que sejam complementares uns aos outros, especialmente todos a partir de janeiro de 2019. Se você assistir em sequência eles vão fazer mais sentido.

E é isso aí, é assim que eu penso sobre meus videos e como eu produzo. Espero que tenha satisfeito a curiosidade de vocês e, claro, se ficaram com dúvidas não deixem de mandar nos comentários abaixo, se curtiram o video mandem um joinha, assinem o canal e não deixem de clicar no sininho pra não perder os próximos episódios especialmente porque vou tirar uma pausa de 2 semanas este mês por conta do evento The Conf e outras palestras, mas eu volto em breve. Aproveitem pra assistir os videos do canal que ainda não assistiram e compartilhem com seus amigos pra ajudar o canal. A gente se vê, até mais!

Essa é uma pergunta clássica e capciosa usada em entrevistas. E se você assistiu ao magnífico “O Lobo de Wall Street” do Scorsese, vai se lembrar dessa frase na hora.

Mas quantos de vocês pararam pra pensar de verdade no que essa pergunta implica?

Introdução

Existem inúmeras formas de tentar me vender uma caneta. Você pode falar sobre a tradição da marca fabricante. Pode exaltar a suavidade excepcional com que ela escreve. Pode tentar me convencer pela variedade de cores e tamanhos disponíveis. Pode até desviar o foco da caneta em si e começar a se gabar de quantas centenas de canetas já vendeu, o seu currículo de guerra.

Meu argumento é que você pode fazer tudo isso e ainda assim perder o ponto. E na maioria das vezes não vai vender a caneta.

Já vi isso acontecer muitas vezes. A maioria das palestras técnicas que assisti, por exemplo, segue esse roteiro:

1. Quem é o vendedor palestrante. Realizações. Currículo de guerra.
2. O que está sendo vendido. A Caneta.
3. Como a Caneta é boa ou como é fácil de usar.
4. “Compre.” Fim da história.

Não há nada de errado com esses pontos em si. Às vezes o palestrante vai além e faz coisas “chamativas” e “espetaculosas”. Uma sessão de live coding para demonstrar o quanto ele é bom (não a caneta). Uma demo técnica mostrando o que a caneta faz. Fogos de artifício e rojões. Mas tudo isso se dissipa rapidamente, e ninguém fala sobre aquilo depois. Não gruda.

E você não vende a caneta.

Às vezes a força bruta sozinha, o peso da marca por trás de você, é suficiente para persuadir muita gente. Mas não a maioria. Em vez de vender a caneta, o palestrante vende a big brand, Microsoft, Google, Facebook. Era “ninguém foi demitido por comprar IBM” nos anos 60. O famoso F.U.D. (a trifeta de “Medo, Incerteza, Dúvida”). Hoje é “ninguém, geralmente, é demitido por escolher Facebook ou Google”.

De novo, você não está vendendo a caneta.

Desenvolvimento

Como qualquer bom vendedor vai te dizer, você está perdendo o ponto mais importante da sequência acima, entre os itens 3 e 4. Você desperdiçou uma quantidade absurda de tempo descrevendo o “O Quê”. A maioria dos palestrantes técnicos passa um tempo enorme explicando o “Como”, com exemplos de código, live coding, tentando te convencer de como aquilo pode ser fácil.

Mas eles frequentemente esquecem de fazer a pergunta: “POR QUE essa caneta pode ser importante pra VOCÊ”. O “VOCÊ” sendo a audiência. Você não está conectando. Falta empatia. Você está apenas dizendo pra eles, em vez de persuadir. Dizer e persuadir são coisas completamente diferentes.

O POR QUE é o que mais importa. E a parte difícil com audiências grandes é que cada pessoa tem um “POR QUE” diferente que precisa de uma boa resposta.

Sempre que vejo um palestrante/escritor/evangelista dedicando tempo demais a coisas imateriais como “benchmarks”, “performance”, “arquiteturas hiper-modulares”, vejo alguém perdendo uma fatia enorme da audiência. Essas pessoas têm motivos legítimos para se preocupar com esses pontos, porque vivenciaram isso dentro de Unicórnios como Netflix, Facebook ou Twitter. Só que mais de 95% do público nunca vai ter esses problemas.

Portanto, você está tentando empurrar uma Lamborghini pra pessoas que não só não podem pagar por ela, mas que, mesmo que pudessem, ela não estaria nem perto do topo das prioridades. Sim, a Lamborghini é obviamente um carro rápido e bonito. Mas POR QUE eu preciso dela? POR QUE você está tentando me empurrar isso? POR QUE essa caneta sequer é relevante pra mim?

Sua prioridade não é a minha prioridade!

Vejo uma entrevista como uma palestra para uma audiência de uma pessoa. E vejo um post de blog como uma palestra para uma audiência que não consigo ver. A estrutura é exatamente a mesma.

Mas numa entrevista individual temos uma vantagem extra muito importante: você pode fazer perguntas diretas! Você percebe o quanto isso é valioso? Numa palestra com audiência você precisa fazer suposições sobre o que as pessoas querem ouvir. Numa entrevista você pode perguntar diretamente e dar respostas objetivas, eliminando o espaço das suposições.

A ironia é que a maioria das pessoas não faz perguntas em entrevistas. É muito mais fácil assumir: “todo mundo quer ouvir o que eu gosto de ouvir, porque eu entendo mais do assunto”. Isso é a falta de empatia no seu nível máximo.

Imagine que você é um engenheiro top trabalhando com tecnologia sensível a performance na sua startup unicórnio. Você tentou tudo e decidiu escrever componentes críticos de tempo real próximos ao metal, em C. E agora você dá palestras sobre como é fundamental que todo mundo comece tudo em C.

Comunicação é uma arte. Exige pesquisa, estudo, prática. Você precisa dominar muito bem sua língua nativa, a gramática, as muitas construções de frase que melhor transmitem a mensagem.

Existem vários “padrões de design” quando se trata de Teoria da Argumentação, muitas armadilhas bem conhecidas, falácias que você quer evitar. Tudo isso para criar uma linha de raciocínio sólida como rocha, simples de entender e difícil de refutar.

Você não quer ser facilmente derrubado. Então cada frase que você entrega é como um movimento de xadrez: você precisa antecipar 10 formas diferentes de ser refutado e ter respostas para cada uma.

Por isso você precisa praticar. Escreva, fale o máximo possível, independente do evento. O ponto é a oportunidade de se expor a um público com pouco risco, independente do tamanho da audiência ou do seu ego. Só enfrente uma audiência grande quando estiver confiante de que pode defender seus argumentos.

Calibre suas armas antes de usá-las. Quando você começa a tocar nos POR QUÊs, pode estar provocando feridas abertas na audiência, então é melhor estar preparado.

Mas se você não for atrás dos POR QUÊs, é muito pior: você se torna ESQUECÍVEL. Você recebe aplausos no final, e uma hora depois ninguém lembra seu nome. Qual é o propósito de um palestrante que ninguém lembra depois? Ou de um palestrante que é engraçado e as pessoas lembram das piadas, mas não lembram o conteúdo da palestra?

As pessoas simpatizam com o palestrante, mas a mensagem é irrelevante. Se você quer ser ator ou comediante, ótimo. Mas se você quer convencer pessoas de um ponto de vista, isso é fracasso.

O mesmo vale para a escrita. Você deveria ter aprendido isso na escola. Se você passou pela faculdade e teve que defender uma dissertação, DEVERIA SABER que ela PRECISA ser dividida em pelo menos 3 seções: Introdução, Desenvolvimento e Argumentação, e Conclusão. Essas são as partes do O QUÊ, COMO e POR QUÊ.

No mesmo tema, se você tem afinidade com técnicas Ágeis. Você se lembra da clássica estrutura de User Story? A maioria das pessoas acha isso super irritante. Toda ferramenta no estilo Kanban esquece disso: simplesmente te dizem “escreva aqui o que você quer”. E a maioria das pessoas só quer escrever o O QUÊ. Às vezes escrevem o COMO. Mas têm preguiça de pensar no POR QUÊ.

Como X, eu quero Y, para que Z.

A 3ª seção é elusiva, mas é a ÚNICA seção que importa. É o POR QUÊ. Por que VOCÊ quer AQUELA funcionalidade específica? O POR QUÊ é o critério de aceitação. O Critério de Conclusão. A única coisa que você deveria estar buscando. Escrevemos o que ACHAMOS que queremos, não o que realmente PRECISA ser feito. A estrutura de User Story é mais uma ferramenta para forçar o seu cérebro reptiliano a usar um pouco mais da sua matéria cinzenta mais moderna.

Conclusão

Meu objetivo é chamar atenção para um ponto que muitos palestrantes e blogueiros não estão fazendo: vocês estão se concentrando demais no O QUÊ e no COMO e deixando de explorar a verdadeira preocupação da audiência: o POR QUÊ!

De novo, sempre que você ver aquele tema barato de “minha linguagem é melhor que a sua” e o argumento é: “porque nos benchmarks podemos ver claramente que é 50% mais rápida” ou “podemos ver claramente que usa 50% menos memória” ou “podemos ver claramente que consegue rodar mais processos concorrentes ao mesmo tempo”. Todos esses pontos estão perdendo o alvo.

Isso é o COMO. Tudo bem.

Mas 95% da sua audiência raramente vai se identificar com esses pontos. Eles vão concordar num nível consciente, mas o subconsciente vai lhes dizer a verdade: “você não tem esse problema.” Na maioria das vezes os servidores deles estão ociosos, sem fazer nada. De que adianta um ganho de performance de 50% ou 200% pra eles? Não adianta nada.

É uma falta grave de empatia quando um programador, trabalhando numa empresa grande, com muitos times diferentes colidindo com monólitos enormes e código legado, decide que microsserviços é o caminho. E agora ele “sabe” que se é bom pra ele, deve ser bom pra todo mundo, certo? Portanto, qualquer um fazendo diferente é um idiota.

Não é. A maioria dos outros times no mundo pode ser de 3 a 5 pessoas com projetos que ainda nem chegaram à luz do dia. E aí está: tentando implementar sua super-arquitetura mirabolante, sem obter nenhum valor de volta, porque isso atrasa o tempo de lançamento no mercado.

Ah, a concorrência os alcançou, lançou primeiro, eles perderam o timing, e tudo porque confiaram na sua opinião de visão estreita, na sua falta de empatia com sua audiência. E isso no caso em que eles te ouviram. A maioria já esqueceu o que você disse, porque nunca tocou nas preocupações reais deles de qualquer forma.

E eu também sou culpado, faço isso às vezes. No começo da minha carreira fazia mais, e quanto mais velho fico, mais cuidadoso me torno com a forma como construo o que quero dizer. É muito difícil enxergar além das nossas pequenas rotinas. É difícil se comunicar com uma audiência maior e diversa. Mas se esse é o papel que escolhemos perseguir, precisamos fazer melhor.

Espero que isso tenha dado a vocês alguma perspectiva sobre como estruturar seu pitch em palestras pequenas ou grandes, entrevistas individuais ou posts de blog. É tudo a mesma coisa: O QUÊ, COMO, e por último mas não menos importante, o POR QUÊ!

Meu problema com este blog é fazer com que os leitores novos consigam encontrar conteúdo que publiquei no passado (desde 2006!) que ainda seja relevante hoje.

Com isso em mente eu repassei manualmente por todos os 1025 posts que já publiquei até hoje e refiz os tags de todos eles, um por um! Com isso consegui marcar tudo que certamente já não é mais relevante hoje com a tag “obsolete”. E isso deu uma contagem de 613 posts.

Significa que ainda existem nada menos que 412 posts que podem ser lidos ainda hoje! O que está listado na homepage é 100% dos posts não-obsoletos.

Procure pelas seguintes tags:

• off-topic - são meus famosos posts “gigantes” com diversos assuntos, não só programação
• rails - são os posts especificamente para programadores Ruby on Rails
• career - são off-topics mais focados na carreira de um programador
• management - são os off-topic mais focados em gerenciamento de projetos em geral

Ultimamente, em diversas discussões online que participei a resposta tem sido eu copiar e colar o link de algum post que eu já escrevi. Muita coisa em discussão hoje eu já discuti em detalhe no passado, então explore. Para facilitar eu removi paginação deste site, então dos links acima e, principalmente da homepage, você tem acesso de uma vez só a todos os 412 posts, desde 2006 até hoje!

Também queria uma tipografia mais confortável e pra isso escolhi o Typeplate. Não sei se é realmente tão boa quanto dizem mas gostei da aparência até agora. Com o tempo vou começar a limpar erros, links quebrados, imagens quebradas, meus posts mais antigos, se quiserem colaborar não deixem de comentar aqui para facilitar.

O conceito é “bare-essentials”. Por exemplo, porque um sistema de busca se um simples “Find” do próprio navegador é suficiente se eu listar tudo na própria homepage? Qualquer coisa mais complexa de procura todo mundo acaba usando o Google de qualquer forma. Além disso, listar tudo na homepage faz o tamanho do HTML ficar em meros 250kb, então coisas como paginação ou – eca – scroll infinito são inúteis. Não precisa de botões de redes sociais, no fim eu mesmo já posto e todo mundo só retwita de qualquer forma e isso elimina um monte de javascript desnecessário. No fim é somente o extremamente essência: texto.

Enjoy!

Além disso coincidiu com a primeira palestra que farei numa Rubyconf Brasil desde 2010.

Muitos dizem que não acreditam em coincidências, eu por outro lado, acredito em providência. Alguém se lembra do que escrevi no meu Primeiro Post, em 2006?

E recentemente nosso grande camarada Rafael Rosa Fu do GrokPodcast - que aliás, também lançou o último episódio da minha conversa com George Guimarães, Carlos Brando sobre os 10 anos de Ruby on Rails - começou uma iniciativa no Twitter com a hashtag #ClubeDosPosts. Tantos grandes e talentosos desenvolvedores despontaram nos últimos 8 anos de Rails no Brasil e gostaríamos muito que eles compartilhassem seu conhecimento e experiência com todos nós. Ajude-nos a incentivá-los!

Diferente do que eu faria, desta vez resolvi escrever pouco e pela primeira vez também no meu blog, pedi ao Rafael Rosa para escrever em suas palavras sobre este assunto. Assim, o resto do artigo são as palavras não alteradas do Rafael.

Obrigado a todos por me acompanharem por tanto tempo, espero chegar no post 10.000 um dia!

Convidado: Rafael Rosa Fu

É engraçado como a maior parte do que aprendemos sobre TI hoje em dia começa com uma pesquisa no Google e/ou StackOverflow, mas raramente nos questionamos sobre o que está por trás do conteúdo que eles indexam e frequentemente salvam nossa pele. Por quê alguém “perdeu tempo” escrevendo-os? Esses são alguns dos motivos que conheço:

• Aprendizado - praticar novas habilidades é importante para fixá-las, ao escrever sobre o que aprendemos estamos reforçando e expandindo nosso conhecimento ao sermos “forçados” a explicá-lo de forma que possa ser consumido por outras pessoas

• Memória - não sei você, mas minha memória é igual a de um peixinho dourado, e tenho certeza que não sou exceção. Escreva sobre aquele conceito complicado ou deixe a receita para o procedimento esporádico e quando precisar se lembrar dele abra seu blog ou procure no Google e vai encontrar suas próprias palavras para lembrá-lo.

• Portfólio - especialmente útil para quem está começando na carreira, blog posts são úteis como parte de um portfólio de conhecimento que pode ser encontrado por um possível empregador ou usado como referência durante uma entrevista, agindo como um complemento ao tempo de carreira, além de ser um bom gancho para conversas durante entevistas.

• Visibilidade - quando queremos trocar de emprego ou alavancar um novo negócio, ter uma audiência cativa é um ótimo negócio, ela nos provê uma rede de contatos útil, possíveis clientes e ajudam a espalhar nossas mensagens. Gerar conteúdo é um ótimo modo de conseguir essa audiência e o custo é quase zero. Não importa o motivo, o(a) autor(a) só tem a ganhar, e instantaneamente se diferencia da maioria esmagadora do mercado, que nunca criou conteúdo algum. As comunidades a sua volta também se beneficiam, pois ganham conteúdo que irá ajudar a expandi-las e divulgá-las, e quanto mais forte a comunidade mais valorizado é o/a profissional, criando um círculo virtuoso.

Se você está convencido que gerar conteúdo é uma boa idéia, peço que não perca tempo e comece agora. Não deixe que a preguiça ou desculpas impeçam seu avanço, você não precisa de um novo site, nem de um domínio especial, nem mesmo de uma blog engine, tudo isso é secundário e pode ser melhorado ao longo do tempo, crie um Gist e publique o link nas suas redes sociais quando estiver pronto, começar a escrever é a parte importante.

Outra desculpa comum é falta de assunto, mas isso não é verdade, tenho certeza que você aprendeu alguma coisa nova ou teve algum problema recentemente, basta usar isso como desculpa para escrever. Seus posts não precisam ser respostas precisas, na verdade eles podem ser apenas perguntas e dúvidas, escreva o que você sabe e coloque links para o que você acha que pode ser útil, alguém certamente irá se encontrar numa situação semelhante e, no mínimo, se sentir mais feliz por saber que não é a única pessoa com essa dúvida.

Não quer escrever um post? Grave um podcast ou um screencast, faça um slide deck, desenhe um cartoon, crie uma biblioteca open source, invente alguma outra coisa, o formato pouco importa, o importante é fazer alguma coisa. Precisa de um apoio? Converse com um amigo, crie o conteúdo em conjunto, vá à um encontro da sua comunidade, mande uma mensagem nas redes sociais, envie um e-mail para uma lista de discussão, só não fique parado, o importante é fazer alguma coisa.

Você já deve ter ouvido o provérbio chinês “uma jornada de 1000 milhas começa com um primeiro passo”, mas tenho certeza que muitos profissionais de TI poderiam dizer que “uma carreira de sucesso começa com o primeiro post”. Você vai começar sua jornada hoje?

People who followed my blog over those 7 years had the chance to read most of these articles. But what about the newcomers? It’s very hard to explore the good old articles buried in a pool of almost 900.

Every blog still follows the same structure. Posts are sorted by date in descending order and show up one at a time in a long stream. Only new posts, or the ones I manually pick, sit at the top. As soon as I publish a new article, the previous one becomes less relevant.

If the blog is paginated, last month’s posts get buried in previous pages. Most people never navigate to those pages, and they rarely dig through tags, which only help so far. People looking for something specific can search through Google, or an internal search if I ever build one.

A blog is structured so that old posts must stay less relevant and harder to find. That works well enough for a news feed. For columns, opinions, research, timeless material in general, it’s a horrible structure.

We’ve seen a plethora of blog engines over the years and they are all the same. A post has many comments, new posts go first in the feed, old posts go to hidden pages under a precarious pagination system.

Several things have been tried already and none of them solved this. Tags, featured articles, hierarchical categories, random showcases of old posts on the front page. None of them crack the discoverability of old, still-relevant posts for new readers.

Maybe this is an unsolvable problem, and I don’t have a good idea to move past this structure. So I want to know if anyone else has tackled it from a different angle, or if new approaches are emerging. Please comment below if you’ve seen fresh ideas coming out.

Post.order(“created_at DESC”).page(params[:page]) is history. What’s next?

• Dr. Nic
• Geoffrey Grosenbach
• Chad Fowler
• David Black
• Ola Bini
• Carl Youngblood
• Jamis Buck
• John Lam
• Avi Bryant
• Avi Bryant
• Adrian Holovaty
• Peter Cooper
• Hal Fulton
• Evan Phoenix

O Ruby Inside é um dos maiores websites de Ruby/Rails disponível e uma grande fonte de notícias. Seu criador é o empreendedor britânico Peter Cooper, também autor do livro recentemente publicado Beginning Ruby, from Novice to Professional, uma excelente fonte para qualquer um querendo aprender a linguagem Ruby.

Peter fala sobre Ruby on Rails, negócios, iniciantes e, como um exclusivo de última hora, ele comenta o recente episódio nuclear do Zed que chocou muitas pessoas da comunidade. Apenas para deixar claro, Peter respondeu minhas perguntas antes do Ano Novo, é somente a última pergunta que foi adicionada depois.

AkitaOnRails: Para a comunidade Ruby Peter Cooper significa Ruby Inside. Eu pessoalmente gosto de ler seu website já que ele acumula a maioria dos websites importantes de Ruby e Rails por aí. Deixe-me agradecer novamente por adicionar meu blog à lista do seu site. Mas como ele começou? O que você acha que foram os passos mais importante que tomou para construir sua boa reputação?

Peter Cooper: Ruby Inside começou como um veículo para promover meu livro (já lançado) “Beginning Ruby.” O nome mesmo veio de um comentário feito numa entrevista para o podcast de Rails por Geoffrey Grosenbach onde alguém adaptou Ruby no velho slogan “Intel Inside”, que soou como um grande nome para um blog cobrindo coisas de Ruby. Inicialmente, o blog foi simplesmente para promover o livro, mas rapidamente se tornou um resumo de notícias de toda a comunidade Ruby. Acho que a chave de seu sucesso foram os grandes blogs Ruby da época, o blog de Ruby da O’Reilly sendo um bom exemplo, estavam postando cada vez mesmo uma vez que seus escritores estavam pegando mais e mais trabalhos de Ruby. Ruby Inside preencheu o buraco de fornecer notícias altamente digeridas de toda a comunidade Ruby, com apenas um ou dois posts por dia, permitindo desenvolvedores Ruby se manter atualizados com as coisas, mas sem precisar assinar centenas de blogs.

AkitaOnRails: Olhando seu perfil no LinkedIn vejo que esteve bastante envolvido com negócios de internet nos últimos 10 anos. Você também se descrever como um ‘empreendedor serial’. Empreendedorismo é algo muito, muito difícil aqui no Brasil, principalmente por causa da economia e da quantidade absurda de burocracia envolvida. Quão difícil é na Inglaterra para ter seu próprio negócio?

Peter: É muito fácil começar um negócio na Inglaterra. Dependendo do que quer fazer, pode apenas dizer que é um negócio logo de cara, sem preencher nenhum documento (embora você precise contactar o departamento tributário para que eles saibam!), e operar como um sole trader. Registrar um negócio oficialmente, entretanto, é razoavelmente fácil também e lhe dá várias proteções legais e uma imagem mais profissional. Receber investimento e tal não é particularmente fácil aqui, comparado com os Estados Unidos, mas se estiver disposto a começar, então o Reino Unido é muito bom por bancos fáceis, comunicação rápida e negócios com o resto do mundo. Com a vantagem natural da linguagem inglesa, o mercado americano é fácil de mirar do Reino Unido.

AkitaOnRails: Seus outros produtos bem conhecidos devem ser Code Snippets e Feed Digest. Poderia apresentar ambos aos brasileiros que podem não conhecê-los? Como a idéia lhe ocorreu? Foi algo como “coçar a própria coceira” ou foi algo totalmente não relacionado e talvez seguindo alguma tendência que identificou? Que ferramentas usou para construí-las? Muitas pessoas tem interesse em saber o que é necessário para construir um produto de sucesso. O que acha que é necessário para ser um bom empreendedor na internet?

Peter: Code Snippets foi o primeiro repositório de trechos de código “tagueados” no estilo del.icio.us. De fato, acho que foi a primeira aplicação Rails a usar tags, já que eu escrevi o código inicial que foi apropriado em várias bibliotecas de taggings. O site foi lançado no começo de 2005 e eu o vendi em fevereiro de 2007 para a DZone. Feed Digest é um serviço para mashing, processamento e republicação de feeds RSS e Atom para outros formatos, como HTML, Javascript, Flash, imagens e assim por diante. Eu vendi a uma empresa russa no verão de 2007.

Ambos os negócios / sites foram resultado de “coçar a própria coceira” como disse. Eu precisava de um sistema para armazenar trechos de código com tags, e del.icio.us não servia para isso, então Code Snippets saiu depois de uma maratona de 24 horas, foi lançada publicamente, e então cresceu para milhares de usuários com o tempo. Feed Digest evoluiu de um serviço inicial chamado RSS Digest que eu criei para coçar outra coceira, republicar meus links del.icio.us para o cabeçalho do meu blog. Ele cresceu para bem mais que isso, e agora tem mais de 25 mil usuários e serve talvez meio bilhão de requests todo mês. Eu não possuo nem tenho interesse direto em nenhum desses projetos agora, mas eu devo estar indo bem na lista de pessoas vendendo aplicações Rails!

AkitaOnRails: Eu o parabenizo pelo livro recentemente publicado, pela Apress, Beginning Ruby, from Novice to Professional. Como Larry Wright diz em seu review, ele está certo que o Pickaxe é um bom livro de referência, mas você toma um caminho diferente sendo mais cuidadoso sobre o aspecto ‘didático’ do ambiente. Ele preenche um vazio já que há cada vez mais pessoas interessadas em aprender Rails mas não tem um livro introdutório para aprender o próprio Ruby. Por favor, descreva seu livro para nossa audiência já que acho que muitos brasileiros ainda não conhecem seu livro. Qual é seu público-alvo? Do que você fala?

Peter: O livro atualmente está disponível apenas em inglês, infelizmente, então os Estados Unidos foram definitivamente o maior mercado alvo até agora. Sobre o conteúdo, o livro é muito remanescente dos livros “clássicos” de ensino de programação que eu tinha nos anos 80. Ele é bem passo-a-passo, com a instalação do Ruby vindo primeiro, seguindo por um passo-a-passo dos conceitos principais sobre orientação-a-objetos, sintaxe do Ruby, e a idéia básica de tipos de dados. Eventualmente, pelo final do livro, o leitor passou por operações em arquivos, uso de banco de dados (há até uma introdução a SQL), desenvolveu um jogo de aventura em texto, construiu uma simples aplicação Rails e assim por diante. É realmente um livro para iniciantes, do começo ao fim, e então ele pode ir para livros mais avançados como o Pickaxe ou The Ruby Way. Quem sabe não vemos o livro em português um dia!

AkitaOnRails: E falando em iniciantes, novamente eu acho engraçado ler seu perfil no LinkedIn: “‘Larguei a escola aos 16’ conta? Se sim, estou dentro. Educação é boa pra maioria, mas superestimado se você for um autônomo…” Eu também larguei a faculdade para trabalhar na bolha da internet (embora não como empreendedor, o que eu me arrependo). Eu não recomendo que as pessoas larguem a faculdade como eu fiz, claro, é uma escolha pessoal e todos devem tomar decisões conscientes sobre seu próprio futuro. Mas existem muitas pessoas – pelo menos aqui no Brasil – que se orgulham de certificações e diplomas mais do que experiência. Claro, existem grandes desenvolvedores certificados, mas há mais maus desenvolvedores que realmente ‘acreditam’ em seus próprios certificados como garantia de competência! Eu não vejo nenhuma correlação entre diplomas e bons desenvolvedores. Qual sua opinião sobre isso?

Peter: Tenho muito respeito por pessoas que seguem a rota acadêmica, e acho que no geral eles se tornam melhores no trabalho do que as menos educadas. Uma das desvantagens de ser doutrinado pela academia, entretanto, é que pessoas com muitos graus, certificações e diplomas normalmente agem como autômatos tecnológicos, somente entendendo um caminho de ação, sem capacidade de pensar dinamicamente em tempo real, e incapazes de tentar novas direções radicais. Há muito espaço no mundo para pessoas assim, mas por outro lado precisamos muito de pessoas “loucas” que tentam coisas que inicialmente parecem idiotas ou radicais.

O outro problema com pessoas que exibem suas certificações é que em muitos casos eles estão apenas provando que conseguiram passar um teste. Passar um teste e ter muito conhecimento não significa necessariamente que você desenvolve boa capacidade de resolução de problemas ou consegue trabalhar como um verdadeiro desenvolvedor, arquitetando soluções do zero. Por exemplo, um peão pode ser excelente construindo casas, mas ele provavelmente é muito ruim em realmente desenhar construções, que é o trabalho de um arquiteto. Em TI, especialmente em empresas pequenas, normalmente é necessário que os desenvolvedores usar ambos chapéu de arquiteto e desenvolvedor, e muitas pessoas com certificação, mas pouca experiência real, penam com desenho de sistemas.

AkitaOnRails: Somos ambos evangelistas de Ruby e Rails, claro, mas como eu, não o vejo como um desenvolvedor ‘cego’, quer dizer, do tipo que precisa fazer todo o resto parecer ruim para justificar colocar Ruby num pedestal. Eu realmente acredito na ‘ferramenta certa para cada trabalho’. Nem mesmo DHH afirma que Rails é a solução para todos os casos de uso. Isso dito, acho que Rails é o melhor para um nicho de desenvolvimento web. Recentemente eu me envolvi – e me arrependo disso – contra um troll defensor de .NET. Não desgosto de .NET, longe disso. De qualquer forma, você se vê envolvido em discussões como essa? Ou você tenta evitá-los totalmente? Qual sua opinião sobre esse tipo de discussão ‘X vs Y’?

Peter: Acho que é possível ter jogos políticos interessantes em qualquer situação. Como um ser humano normal eu tenho, claro, minhas preferências, mas é importante reconhecê-los pelo que são e ainda ser capaz de enxergar o quadro completo. Acredito em tentar usar a ferramenta certa para o trabalho (ou, mais especificamente, a ferramenta mais eficiente para o trabalho – eu não vou aprender uma linguagem nova para resolver apenas um problema), então o Ruby Inside roda em WordPress , uma plataforma de weblog em PHP. Em termos de predisposição, eu certamente sou meio anti-Microsoft, embora precise admitir que para desenvolvimento de aplicações GUI eles estejam anos-luz à frente de todo mundo.

Eu não tenho evitar me meter em discussões do tipo X vs Y, embora eu tende a ser meio advogado-do-diabo nesses casos. É importante se manter o mais científico e objetivo quanto possível nessas situações, mas eu certamente deixarei um pouco de predisposição se mostrar de tempos em tempos, como qualquer humano faria. Por exemplo, eu (e estou longe de ser o único nisso, embora muitos não queiram atirar pedras publicamente) particularmente não sou muito chegado na proteção excessiva do David Heinemeir Hansson dos termos Ruby e Ruby on Rails, e especialmente o logotipo Rails ao ponto de rejeitar seu uso em livros em que ele não trabalhou pessoalmente. Não tenho medo de mostrar alguma predisposição e problemas de referência como essa de tempos em tempos.

AkitaOnRails: Isso nos leva à outra questão: todos os dias as pessoas aqui me perguntam “Por que eu deveria escolher Ruby on Rails em vez de X?” Pessoalmente, acho que não há resposta clara para isso. Sendo experiente em muitas plataformas como ASP.NET, Java, PHP, Perl, eu fiz minha escolha baseado não apenas em performance bruta (que Ruby não tem, por enquanto), nem mesmo um conjunto maduro de bibliotecas (que está evoluindo depressa). Algumas razões foram baseadas unicamente em eu estar feliz com esta plataforma. Acredito que Ruby me permite escrever mais código ‘bonito’ como Marcel Molina Jr. explica. Mas “a beleza está nos olhos de quem vê.” Qual sua opinião? Sendo um programador experiente em outras plataformas, por que escolheu Rails?

Peter: Eu era um desenvolvedor Perl antes de cruzar com Ruby e Rails, e quando vi Rails, a primeira coisa que fiz foi tentar cloná-lo em Perl. Infelizmente, eu definitivamente não estou entre na elite de programadores, nem de longe, então minha tentativa foi bagunçada. Tentei usar Rails diretamente, meio relutante, com uma promessa a mim mesmo de não me deixar envolver e aprender uma nova linguagem, mas meramente para desenvolver o que eu precisava na época. Claro, o resto é história e eu me converti inteiramente a Ruby, pela sua consistência, facilidade de uso, e pela forma como ela parece uma linguagem “natural”.

Em 2004, a biblioteca Ruby era pobre, RubyGems não era popular, e não haviam muitos livros disponíveis, então parecia uma escolha ruim, mas essas coisas mudaram muito rápido, e eu diria que a biblioteca Ruby em 2007 compete muito fortemente com, digamos, Python, e mesmo estando atrás em quantidade numérica ao CPAN do Perl, a qualidade e modernidade das bibliotecas Ruby superam isso. Ruby é agora uma forte escolha.

AkitaOnRails: Eu preciso estender esse tema porque acho que é relevante já que vemos mais e mais pessoas mudando para Rails. Eu vejo 2 tipos de desenvolvedores vindo à bordo: o primeiro sendo programadores experientes que não estão satisfeitos com seus trabalhos atuais e ferramentas e querem tentar algo novo e renovador. O segundo sendo desenvolvedores iniciantes que acham que Java ou .NET tem uma curva de aprendizado muito mais alta do que Rails. Eles me preocupam um pouco porque tendem a pensar que Rails é fácil demais para ser considerado profissionalmente e outros se frustram em descobrir que Ruby não é Basic, e você precisa se esforçar para aprender seus caminhos. Você faz treinamentos também, qual sua experiência lidando com iniciantes?

Peter: Nunca lidei com alguém que seja completamente novo à desenvolvimento de aplicações Web, então não posso dar uma resposta concreta. Entretanto, eu certamente não acho que as pessoas estejam escolhendo aprender Ruby ou Rails porque são percebidas como “fáceis”. De fato, acho que são os desenvolvedores mais experientes que consideram Rails fácil, e é por isso que estão a estão experimentando. Iniciantes tendem a ir com seja lá que esteja na moda no momento ou o que é mais popular. Não há falta de iniciantes para todas as maiores linguagens agora, é somente que Ruby está finalmente recebendo sua fatia.

AkitaOnRails: 3 anos atrás a maioria dos desenvolvedores previram a “queda” do Rails como uma alternativa viável. Hoje vemos Rails 2.0 saindo e a comunidade Rails crescendo depressa e mais forte a cada dia. Agora as pessoas acham que Rails é o competidor a derrotar. Acho que é algo bom porque nós tendemos a correr mais rápido (desenvolver mais gems, inovar mais) quando estamos sobre pressão. Você acha que as pessoas estão aceitando Rails mais ou ainda vê barreiras para a adoção do Rails, pelo menos aí na Inglaterra ou Europa em geral?

Peter: Não concordo que 3 anos atrás a maioria dos desenvolvedores previam a queda do Rails. Acho que haviam apenas muitos programadores defensivos escolhendo ignorá-la. Não acho que a maioria dos desenvolvedores de outras plataformas vejam Rails como algo a se derrotar. Na realidade há muita cegueira nos galhos da comunidade de programação para os esforços feitos em outros galhos. A maioria dos programadores .NET não se importam, e muito provavelmente nem ouviram falar disso, Ruby on Rails. Desenvolvedores em plataformas que estão morrendo, como Cold Fusion, estão mais familiarizados com Rails, simplesmente porque eles tem procurado alternativas, mas Java e .NET ainda estão tomando os novos desenvolvedores a uma taxa muito maior que Ruby e Rails. Existe uma grande diferença no que os blogs e a mídia online quer relatar e o que realmente está acontecendo por aí.

AkitaOnRails: Existem muitas coisas que o Ruby ainda não tem e agora estamos vendo Ruby 1.9 sendo lançado. Ainda não é um 2.0 estável mas é um sinal claro que a linguagem está evoluindo depressa como uma plataforma madura. Performance de graça sempre é bem vinda, mas este lançamento quebrará muitas coisas. Já está usando 1.9 ou sente que ele ainda não está pronto para começar?

Peter: Eu brinquei com Ruby 1.9 um pouco, mas não uso rotineiramente. Eu não me considero um programador no sentido acadêmico. Gosto de saber e brincar brevemente com tecnologias extremas, mas não sou um desses super-programadores que fazem download digamos, de Erlang ou Haskell e tentam aprendê-los num fim de semana. Ruby 1.8 definitivamente continuará sendo meu interpretador Ruby por pelo menos mais alguns meses.

AkitaOnRails: Nossa comunidade brasileira ainda é muito jovem e pequena, eu normalmente a descrevo como a comunidade americana em 2004 ~ 2005. Ainda não atingimos massa crítica. Como estão as coisas por aí na Inglaterra ou Europa? Sua comunidade já é grande o suficiente o suficiente para o mercado já demandar profissionais relacionados a Rails?

Peter: O mercado no Reino Unido ainda é muito pequeno. Não houve literalmente nada em 2005 mas as coisas cresceram rapidamente nos últimos anos, embora ainda seja talvez um milionésimo do tamanho do mercado para serviços de Java ou .NET. Existe normalmente alguns trabalhos relacionados a Rails flutuando por aí, mas até agora descobri que Rails é uma tecnologia que agências estão usando para seus clientes por trás das cenas, em vez de ser algo sendo ativamente demandado. Não estou diretamente envolvido na comunidade britânica de Ruby ou Rails, entretanto, então não posso dar muitos detalhes disso.

AkitaOnRails: Isso é só pela brincadeira: se você fosse DHH ou Matz o que gostaria de mudar no Rails ou Ruby? Ou talvez, para onde vê os dois indo?

Peter: Se eu fosse o DHH, provavelmente Rails não existiria, simplesmente porque eu acho que muito muito do seu excelente evangelismo de Rails é dirigido por uma ponta de vontade de fama. Por um lado mais prático, eu faria Rails menos ‘opinionated’ (de opinião) e mais customizável, simplesmente porque muitas das opiniões são muito rígidas para serem práticas no mundo real. A opinião inicial de depender do banco de dados para dar informações sobre a estrutura do Model foi legal, mas então vieram as migrations … e de repente estamos definindo layout de tabelas no código afinal, normalmente em muitas dezenas de arquivos! Por que não colocar os atributos diretamente no Model e deixar Rails tomar conta das mudanças de schema transparentemente? DataMapper faz isso, e ActiveRecord está começando a ficar para trás em comparação com esse estilo bizarro.

Do lado do Ruby, acho que Matz fez um excelente trabalho tecnicamente, embora apesar do DHH pontuar mais alto na escala de Relações Públicas, Matz parece relutante em promover o Ruby. Acho que ambos é um pouco de modéstia ser uma coisa honrável na cultura japonesa, mas também porque Ruby é algo que ele desenvolveu para coçar uma coceira, e outros milhão de desenvolvedores usando a linguagem não o beneficiaria significantemente. Ele é um grande cara, mas falta a loucura de um Larry Wall (Perl) e a autoridade de Guido van Rossum (Python) e tem muita sorte que pode depender de uma comunidade muito forte e vocal para promover Ruby. Um dos benefícios do jeito mão-na-massa do Matz é que as pessoas sentem que podem ter autoridade sobre várias áreas da linguagem e comunidade para si sem ter que perguntar à uma autoridade maior.

Do lado técnico, a única coisa que eu talvez faria se estivesse em controle do desenvolvimento da linguagem Ruby seria fazer investidas mais fortes em direção a construções mais funcionais. JavaScript e Perl 6 estão andando bastante no mundo da programação funcional, e Ruby precisa seguir. Eu também consideraria concorrência muito fortemente e tornar isso um foco principal para desenvolvimento de novas funcionalidades na linguagem.

AkitaOnRails: Qual seria sua recomendação para iniciantes em Rails aqui no Brasil? Quero dizer, para aqueles que querem aprender tanto Ruby e Rails mas podem precisar de alguma guia no começo?

Peter: Bem, se você consegue falar inglês, então naturalmente eu sugeriria meu livro “Beginning Ruby” publicado pela Apress! Infelizmente não tenho familiaridade com recursos em português para aprender Ruby ou Rails, embora tenho certeza que você tenha! Um recurso grátis que eu definitivamente recomendaria a novos desenvolvedores é o “Aprenda a Programar” de Chris Pine. Está disponível como livro, mas tem uma versão mais crú disponível para ler grátis online.

AkitaOnRails: Agora, falando em informação, tivemos um começo de ano bem explosivo. Zed Shaw literalmente explodiu em reclamações, ofensas e toda forma de comunicação agressiva. Como eu disse num artigo anterior, eu me choquei no começo, mas lendo até o fim – tentando filtrar todo o ódio e maneirismos não civilizados – e realmente há alguma informação enterrada lá. Qual sua opinião sobre esse episódio?

Peter: Pessoalmente, acho que o Zed acertou em cheio. Não gosto do jeito que ele especialmente ataca algumas pessoas (Kevin Clark, por exemplo) por causa de pequenas infrações. Sua linguagem é severa, e ele claramente tem muito ácido. Por trás de todas as palavras de ofensas e bater no peito, entretanto, há muita verdade. Eu simpatizo com seus argumentos principais, especialmente aqueles levantados na atualização do “Round 2” publicado em 3 de janeiro.

Zed toca na maneira como as pessoas se formam em gangues elitistas e dirigidas pelo ego, como o Rails Core e o caboo.se. Eu me envolvi com o caboo.se por um tempo, e tenho muito respeito por muitos membros (Courtenay Gasking e Amy Hoy, por examplo), mas a coisa tanto fedia muito elitismo para mim, e eu me distanciei de toda essa socialização online relacionada a Rails. Eu me lembro de alguns incidentes condescendentes patéticos de membros dessas comunidades, mas ao contrário de Zed eu deixei quieto. Acho que uma das maiores causas dessa tensão, formação de gangues e infantilidade generalizada é que muitas das pessoas envolvidas com essas gangues não tem vida social fora dessa comunidade. Isso provavelmente explica esses joguinhos medievais como Werewolf (Máfia) e bobagenzinhas em geral são tão populares nas conferências, em vez de, digamos, realmente revolucionar a área.

Por fim, Zed acertou em cheio com seus comentários sobre o livro “Programming Ruby” mais comumente conhecido como o “Pickaxe.” Eu tendo a me manter politicamente correto nesse assunto, especialmente porque tenho um livro concorrente, mas o Pickaxe realmente é incrível na sua mediocridade. Ele vende bem porque tem a vantagem de ter sido o primeiro com nome reconhecido, e ninguém se incomodou em escrever um livro de referência melhor (The Ruby Way é excelente, mas não é um livro de referência). Por ter o único livro de referência de Ruby impresso, Dave Thomas merece crédito, mas ainda assim é medíocre.

AkitaOnRails: Para o bem ou para o mal, tenho sentimentos misturados sobre esse episódio. Não vou julgar ninguém ainda. Vejamos como isso se desenrola. E claro, eu realmente agradeço a paciência do Peter Cooper comigo, gentilmente respondendo todas as minhas perguntas. Muito obrigado!

Eu sei que ando meio ausente da comunidade e até mesmo do meu blog (!) Mas realmente o trabalho anda consumindo todo meu tempo (até o livre!). Espero poder voltar às atividades logo. O Ronie também parece estar no mesmo ritmo, ele publicou minha coluna do mês passado um pouco atrasado, mas é totalmente compreensível, dado que eu também estou atrasado com a finalização da revisão da tradução do Getting Real.

Aliás, é exatamente esse o assunto desta coluna. Achei interessante documentar o inside story sobre essa tradução. Dêem uma olhada aqui.

De qualquer forma, o post no blog Signal vs Noise mostra o status das traduções de outros países. Tenho o orgulho de dizer que estamos MUITO na frente: a maioria ainda está no primeiro capítulo. Já terminamos a tradução dos 16 capítulos e estamos na metade da revisão.

Aliás, é por isso que chamei de “Release Candidate 2”. O RC1 foi um lançamento restrito, o RC2 está público e em alguns dias vamos tentar liberar a versão final!

Agradecimentos aos tradutores: Herval Freire, Juraci Krohling Costa, Marcello Rocha, Diogo Bispo, Adriano Mitre, Ricardo Augusto, Rodrigo K.

E também aos revisores: Mateus Del Bianco, Diogo Bispo, Davis Zanetti Cabral, Gustavo Cardoso, Ricardo Augusto.

(Espero não ter esquecido de ninguém :-)