O problema é que coletar dados de redes sociais é trabalho braçal. Abrir Instagram, YouTube, X, olhar números, comparar com concorrentes, checar calendário de eventos, monitorar patrocinadores, ler comentários, calcular engajamento, decidir preço de publi. Tudo manual, tudo repetitivo, tudo consumindo tempo que deveria ir pra criação de conteúdo.

Fiz o que qualquer programador namorado faria: construí um sistema de data mining completo, com coleta automatizada, análise via LLM, e um chatbot no Discord onde ela conversa com os dados em linguagem natural.

Este artigo não é sobre o código em si (o projeto não será open source). É sobre o processo de construção, as decisões que só aparecem depois que você começa, os truques técnicos que salvaram o projeto, e por que um documento de desejos da sua usuária vale mais que qualquer spec funcional.

Comece Pelo Desejo, Não Pela Arquitetura

A primeira coisa que fiz foi sentar com ela e pedir que falasse livremente o que queria. Sem linguagem técnica, sem formulário, sem user stories. As próprias palavras dela. Gravei num documento IDEA.md que virou o norte do projeto inteiro.

O que saiu dali:

“Maior dificuldade hoje é saber qual tipo de conteúdo criar que pode dar muito certo e por que deram certo, o que fez dar o resultado que deu. Tem que ler comentários dos vídeos pra entender motivos gerais.”

“Quanto deveria/poderia cobrar por uma publicidade, baseado na pesquisa de engajamento, concorrência, patrocinadores, eventos.”

“Como fazer uma publicidade que não parece publicidade, conteúdo pago que traz engajamento sem parecer só propaganda de venda.”

Ela não pediu um dashboard. Não pediu gráficos. Não pediu relatórios em PDF. Pediu respostas pra problemas concretos do dia a dia dela. Isso mudou completamente a forma como eu abordei a arquitetura.

Se eu tivesse começado pela spec técnica, teria construído uma plataforma de analytics com charts bonitos e exports em CSV. O sistema que ela realmente precisava era algo mais parecido com uma assistente que conhece os dados e responde perguntas em português.

O IDEA.md também listava concorrentes e patrocinadores iniciais. Marcas com as quais ela poderia trabalhar (restaurantes temáticos, lojas de figures, Crunchyroll, Piticas, Fanlab). Perfis de referência no Instagram. Tudo isso virou dados de seed. O documento não era um spec — era uma conversa que virou requisito orgânico.

58 Commits em 3 Dias

O projeto foi construído em 3 dias. Não 3 semanas, não 3 meses. 58 commits, 3 fases distintas:

Dia 1 — O Motor de Dados. 12 commits. Scaffold Rails 8, modelos, coletores pra YouTube/Instagram/X, integração com LLM. Pipeline de discovery pra encontrar novos perfis automaticamente. Scoring de performance por post. Análise de sentimento de comentários via Claude. No final do dia, o sistema coletava dados das 3 plataformas e classificava cada post como viral, acima da média, na média, abaixo ou flop.

Dia 2 — O Cérebro e a Voz. 35 commits. O dia mais intenso. Dois sistemas grandes apareceram: o “Oracle” (rastreamento de eventos, convenções, lançamentos de jogos/filmes/anime, notícias) e o chatbot Discord com tool calling via RubyLLM. Também hardening pra produção, Docker, guia de deploy. E uma pivotada grande: troquei o relatório semanal por email por 5 digests diários via Discord.

Dia 3 — Entretenimento e Resiliência. 11 commits. Steam games (Store API + SteamSpy), AniList pra tracking de animes da temporada, analytics de crescimento, geração de imagens via Gemini, sistema de auto-healing pra URLs quebradas.

Os números finais:

Esses números não são mérito meu. Claude fez boa parte do código. Mas a direção, as decisões arquiteturais, e principalmente a validação de cada step foram humanas. Claude não sabe o que uma influencer brasileira de cosplay precisa. Eu também não sabia — mas ela me disse.

A Arquitetura que Emergiu

O sistema final é um Rails 8 headless. Zero interface web. Sem views, sem controllers de verdade (só o /up pra health check). Toda funcionalidade é entregue via background jobs, rake tasks, e o chatbot Discord.

A stack:

• Rails 8.1 com Solid Queue (jobs) e Solid Cache
• SQLite3 em produção (WAL mode, bind mount entre containers)
• RubyLLM pra integração com Claude Sonnet via OpenRouter e Grok
• Ferrum pra scraping com headless Chrome
• Discordrb pro chatbot
• Docker Compose com 4 serviços

O docker-compose.yml ficou enxuto:

x-app: &app
  build: .
  env_file: .env
  restart: unless-stopped
  volumes:
    - ./data/storage:/rails/storage

services:
  app:
    <<: *app
    ports:
      - "127.0.0.1:3000:80"
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:80/up"]
    deploy:
      resources:
        limits:
          memory: 512M

  jobs:
    <<: *app
    command: bundle exec rake solid_queue:start
    depends_on:
      app:
        condition: service_healthy
    deploy:
      resources:
        limits:
          memory: 1G

  discord:
    <<: *app
    command: bundle exec rake discord:start
    depends_on:
      app:
        condition: service_healthy

  chrome:
    image: chromedp/headless-shell:stable
    deploy:
      resources:
        limits:
          memory: 1G

4 containers: app (Puma, basicamente só o health check), jobs (Solid Queue rodando 25+ jobs scheduled), discord (o bot), e chrome (headless browser pra scraping). Todo o estado fica em SQLite via bind mount no host. Sem Redis, sem Postgres, sem infraestrutura extra.

Idempotência Acima de Tudo

Se eu tivesse que escolher um conceito pra resumir o projeto, seria idempotência. Todo job pode rodar duas vezes seguidas sem criar duplicatas, sem corromper dados, sem efeitos colaterais.

O pattern base:

module Collection
  class BaseCollectorJob < ApplicationJob
    SNAPSHOT_DEDUP_WINDOW = 1.hour

    retry_on StandardError, wait: :polynomially_longer, attempts: 3

    def perform(profile_id: nil)
      scope = profile_id ? SocialProfile.where(id: profile_id) : profiles_to_collect
      scope.find_each do |profile|
        log = find_or_create_log(profile)
        begin
          items = collect_for_profile(profile)
          profile.touch(:last_collected_at)
          log.update!(status: :completed, items_collected: items || 0)
        rescue => e
          log.update!(status: :failed, error_message: "#{e.class}: #{e.message}")
          raise if should_raise?(e)
        end
      end
    end

    def upsert_post(profile, attrs)
      post = profile.social_posts.find_or_initialize_by(
        platform_post_id: attrs[:platform_post_id]
      )
      post.assign_attributes(attrs.except(:platform_post_id))
      post.save!
      post
    end

    def record_snapshot(profile, metrics)
      return if profile.profile_snapshots
        .where("captured_at > ?", SNAPSHOT_DEDUP_WINDOW.ago).exists?
      profile.profile_snapshots.create!(captured_at: Time.current, **metrics)
    end
  end
end

Dois mecanismos de proteção: find_or_initialize_by(platform_post_id) pra posts (upsert, não insert), e SNAPSHOT_DEDUP_WINDOW pra snapshots (ignora se já coletou na última hora). Se o job crashear no meio e o Solid Queue reenfileirar, nada duplica.

Erros de scraping (BlockedError, RateLimitError) são engolidos silenciosamente — o retry não ajuda, o rate limit precisa esfriar, e ser bloqueado é esperado. Erros de verdade (banco, rede, bugs) sobem pro retry com backoff polinomial.

Essa decisão de “engolir certos erros” parece errada até você rodar o sistema por uma semana e ver que o Instagram bloqueia uma em cada 5 coletas. Se cada bloqueio gerasse 3 retries com backoff exponencial, o sistema ficaria perpetuamente atrasado.

nil vs Zero

Esse é um daqueles bugs conceituais que você só descobre com dados reais. Quando o Instagram não retorna o número de compartilhamentos de um post (porque a API simplesmente não fornece esse dado), o valor deveria ser nil ou 0?

A diferença importa. nil significa “não temos esse dado”. Zero significa “temos o dado e ele é zero”. Se você trata nil como zero, a análise de LLM conclui que ninguém compartilha posts no Instagram — o que é falso. A API simplesmente não expõe essa métrica.

Criei um snippet de prompt reutilizável só pra isso:

Quando um campo é null: Não diga “0 likes” — diga “dado não disponível para esta plataforma”. Quando comparar plataformas, avise que certas métricas não são comparáveis. Quando é zero: Reporte normalmente — o dado é real e confirmado pela API.

Esse snippet é incluído em todo prompt que lida com dados numéricos. Sem ele, o LLM mistura alegremente “não coletado” com “zero de verdade” e tira conclusões erradas.

O Truque do Chrome Headless: Host Header Bypass

O projeto usa chromedp/headless-shell num container separado pra scraping. Funciona perfeitamente. Até você tentar conectar o Ferrum (a gem Ruby de automação de Chrome) nele via Docker networking.

O problema: chromedp/headless-shell usa um proxy socat na porta 9222 que rejeita qualquer request cujo header Host não seja localhost ou um IP. Quando o Ferrum tenta conectar em http://chrome:9222, o Host header vai como chrome:9222, e o socat recusa.

A solução foi descobrir a URL do WebSocket manualmente, forjando o header:

def discover_ws_url(chrome_url)
  uri = URI.parse("#{chrome_url}/json/version")
  req = Net::HTTP::Get.new(uri)
  req["Host"] = "localhost"  # bypass

  response = Net::HTTP.start(uri.hostname, uri.port) { |http| http.request(req) }
  data = JSON.parse(response.body)

  ws_url = data["webSocketDebuggerUrl"]
  return nil unless ws_url

  # WS URL aponta pra 127.0.0.1 dentro do container — troca pelo hostname acessível
  remote_uri = URI.parse(chrome_url)
  ws_url.sub(%r{://[^/]+}, "://#{remote_uri.host}:#{remote_uri.port}")
end

Faço o GET em /json/version com Host: localhost pra passar pelo socat. Recebo a URL de WebSocket (que aponta pra 127.0.0.1 — inútil fora do container). Reescrevo o hostname pra chrome:9222 (o nome do serviço no Docker Compose). Passo a ws_url direto pro Ferrum, que abre o WebSocket sem passar pelo HTTP do socat.

Esse tipo de coisa não vem à cabeça no começo. Você descobre depois de 1 hora de connection refused e leitura do código fonte do chromedp/headless-shell.

Tool Calling: O Bot que Consulta o Banco Sozinho

A parte mais legal do projeto é o chatbot no Discord. Ela digita uma pergunta em português (“como foram meus posts essa semana?”) e o bot chama as ferramentas certas, consulta o banco, e responde com dados reais.

O segredo é o tool calling do RubyLLM. Cada ferramenta é uma classe Ruby com description e params:

class PostPerformanceTool < RubyLLM::Tool
  description "Retorna estatísticas de performance dos posts: baseline, " \
              "breakdown por tipo de conteúdo, melhores horários, melhores hashtags."

  param :username, type: :string, desc: "Username do perfil (ex: milaoliveira.png)"
  param :analysis, type: :string,
    desc: "Tipo: baseline, content_types, timing, hashtags",
    required: false

  def execute(username:, analysis: "baseline")
    profile = SocialProfile.find_by(username: username.to_s.strip)
    return "Perfil '#{username}' não encontrado." unless profile

    case analysis.to_s.strip.downcase
    when "baseline"
      baseline = PostPerformance.compute_baseline(profile)
      {
        username: profile.username,
        post_count: baseline[:post_count],
        mean_views: baseline[:mean_views].round(0),
        stddev_views: baseline[:stddev_views].round(0),
        mean_engagement: baseline[:mean_engagement].round(2)
      }
    when "timing"
      PostPerformance.timing_breakdown(profile).first(10).map do |entry|
        { day: days[entry[:day]], hour: "%02d:00" % entry[:hour],
          avg_percentile: entry[:avg_percentile].round(1) }
      end
    # ...
    end
  end
end

O LLM recebe a lista de 40+ ferramentas com suas descrições, decide quais chamar com quais parâmetros, recebe os resultados, e formula a resposta. O bot no Discord mostra status em tempo real enquanto processa: “Consultando métricas de perfis… Verificando crescimento… Analisando desempenho de posts… (3 consultas)”.

O truque foi fazer cada tool retornar dados estruturados (Hashes e Arrays), não texto formatado. O LLM é muito melhor formatando dados brutos em resposta conversacional do que tentando parsear texto semi-estruturado.

Outro detalhe que só apareceu no uso real: clamping de parâmetros. Quando o LLM pede limit: 999 num parâmetro que aceita no máximo 50, ao invés de retornar erro, faço [[val.to_i, 1].max, 50].min. O LLM erra parâmetros mais do que você imagina. Cada erro gera um round-trip de correção que custa tokens e tempo.

Composable Prompts: YAML > Strings Hardcoded

Todos os prompts do sistema vivem em YAML no config/prompts/. Cada um tem um system (instruções fixas), um template (com interpolação de dados), e opcionalmente includes (snippets reutilizáveis):

module Llm
  class PromptBuilder
    PROMPTS_DIR = Rails.root.join("config", "prompts")

    class << self
      def build(name, data = {})
        prompt = load_prompt(name)
        base = load_prompt(:_base_context)

        includes = resolve_includes(prompt["includes"])
        system_parts = [base["system"], includes, prompt["system"]]
          .compact.reject(&:blank?)
        system_message = system_parts.join("\n\n")
        user_message = interpolate(prompt["template"], data)

        { system: system_message, user: user_message }
      end
    end
  end
end

O _base_context.yml tem informações que todo prompt precisa (quem é a influencer, nichos, público, diretrizes gerais). Os snippets em config/prompts/snippets/ resolvem problemas recorrentes:

• null_vs_zero.yml — a distinção nil/zero explicada acima
• never_invent.yml — “NUNCA invente dados, analise só o que está presente”
• json_only.yml — “responda SOMENTE em JSON válido”

Quando um prompt precisa de qualquer combinação desses, basta listar nos includes. Sem duplicação, sem risco de instruções conflitantes entre prompts.

Essa decisão veio de um bug real: dois prompts diferentes davam instruções contraditórias sobre como tratar valores nulos. Um dizia “use 0”, outro dizia “use null”. O LLM obedecia um ou outro dependendo do dia. Centralizar em snippets eliminou a classe inteira de inconsistência.

Discovery Pipeline: Mineração Autônoma de Perfis

O sistema inicial partiu de uma lista manual de concorrentes e patrocinadores. Mas a influencer vive num ecossistema dinâmico — novos creators aparecem toda semana, marcas surgem e somem. O discovery pipeline automatiza isso.

Roda toda sexta-feira às 2 da manhã. Começa minerando dados que já temos no banco: quem tá sendo @mencionado nos posts, quem comenta com frequência e alto engagement, que perfis aparecem em links de bio, quem usa hashtags de marca (#publi, #parceria), que links de Linktree apontam pra outros criadores. Tudo puro SQL, sem API calls, sem risco de rate limit.

Os candidatos que saem daí são validados contra as APIs das plataformas (o Instagram existe? O canal do YouTube é real?), depois enriquecidos com conexões cross-platform (se validamos um Instagram, procuramos o YouTube e X do mesmo criador).

Uma chamada de LLM em batch avalia todos os candidatos, classifica como concorrente, patrocinador potencial ou irrelevante, e dá scores de relevância e fit com o nicho. Os top 3 viram perfis rastreados de verdade — o sistema começa a coletar dados deles automaticamente.

Depois, agrupa tudo em entidades Creator. A influencer é profundidade 0. Concorrentes diretos, profundidade 1. Menções de concorrentes, profundidade 2. Limite máximo de 3 graus de separação, pra evitar cascata infinita.

De Relatório Semanal pra Digests Diários: Ouvindo a Usuária

O plano original era um relatório semanal por email com 9 seções. Mas no meio do caminho decidi que seria mais dinâmico não sair do Discord mesmo e ter essa informação sempre disponível.

Pivotei pra 5 digests diários no Discord:

• Segunda — Recap de Performance (seguidores, crescimento, top posts)
• Terça — Radar de Concorrentes (snapshot, notícias, estratégias)
• Quarta — Playbook de Conteúdo (agenda, tendências, hashtags)
• Quinta — Oportunidades e Preços (marcas, pricing, pacotes)
• Sexta — Semana que Vem (eventos, ações prioritárias)

Cada digest tem itens numerados com botões de feedback. Ela marca o que achou útil e o que não achou. Esse feedback alimenta as análises futuras — o sistema aprende quais tipos de insight ela valoriza.

Essa mudança, que não estava em nenhum plano, provavelmente foi a que mais melhorou a experiência dela. Toda manhã às 9h ela abre o Discord e tem um resumo fresco, digerível, acionável. O email semanal ficou como backup, comentado no recurring.yml.

O Oracle: Contexto que o Algoritmo Não Vê

Dados de redes sociais sem contexto externo são meio inúteis. “Esse post teve 3x mais views que a média” é um fato. “Esse post teve 3x mais views porque saiu no dia do trailer do novo Sonic” é uma insight.

O Oracle é o subsistema que fornece esse contexto.

A parte mais crítica é o rastreamento de convenções: CCXP, Anime Friends, BGS, e dezenas de outros eventos do calendário geek. Datas, preços, venues, links de ingresso, contas de Instagram/X do evento. Monitora diariamente por mudanças (data alterada, cancelamento, anúncio de convidado). A influencer planeja o calendário inteiro em torno de convenções. Se a CCXP muda de data, ela precisa saber no dia, não na semana seguinte.

Também rastreia lançamentos de filmes/séries via TMDB, jogos via IGDB (com OAuth do Twitch), animes via AniList — tudo filtrado pra conteúdo geek, janela de 90 dias pra frente. Aniversários de franquias (usando TMDB, IGDB, AniList, Wikimedia) e feriados brasileiros com cálculo de datas móveis. Sim, tem um calculador de Páscoa no código baseado no algoritmo computus. E notícias via scraping de RSS e X/Twitter a cada 6 horas, classificadas por relevância ao nicho.

O evento tracker scrapa sites de convenção com Chrome headless e usa LLM com temperatura 0.1 pra extrair metadados estruturados (data, preço, venue). Tem fallback com regex pra datas no formato brasileiro (“15 de março de 2026”). Deduplicação por fuzzy matching de nome + proximidade de data — porque “CCXP 2026”, “CCXP São Paulo 2026” e “CCXP SP” são o mesmo evento.

SQLite em Produção: Sim, Funciona

SQLite3 em produção. Com WAL mode, um único writer por vez é suficiente porque o sistema tem um padrão previsível de escrita (jobs sequenciais, nunca concorrentes no mesmo segundo). Os dados ficam num bind mount do Docker (./data/storage:/rails/storage) e backup é cp data/storage/*.db backups/.

Rails 8 trata SQLite como cidadão de primeira classe. Solid Queue e Solid Cache rodam em SQLite sem problemas. O overhead de um Postgres pra um sistema que serve uma pessoa não se justifica.

25+ Jobs Agendados

O config/recurring.yml tem 25+ jobs com horários distribuídos pra não sobrecarregar a máquina:

production:
  youtube_collection:
    class: Collection::YoutubeCollectorJob
    schedule: every day at 3am

  instagram_collection:
    class: Collection::InstagramCollectorJob
    schedule: every day at 4am

  x_collection:
    class: Collection::XCollectorJob
    schedule: every 2 days at 5am

  oracle_events:
    class: Oracle::EventTrackerJob
    schedule: every Monday at 2am

  convention_monitor:
    class: Oracle::ConventionMonitorJob
    schedule: every day at 5am

  discovery_pipeline:
    class: Discovery::OrchestratorJob
    schedule: every Friday at 2am

  comment_sentiment:
    class: Analysis::CommentSentimentJob
    schedule: every Sunday at 5am

  weekly_analysis:
    class: Analysis::WeeklyAnalysisJob
    schedule: every Sunday at 6am

Coleta roda de madrugada (3am-5am). Oracle de inteligência começa na segunda às 2am. Discovery na sexta às 2am. Análise pesada (sentimento, estratégia) no domingo quando não tem digest pra entregar. Digests de segunda a sexta às 9am, cada dia com tema diferente. Manutenção (limpeza de jobs terminados, health check de URLs, agregação de dados antigos) nos intervalos.

O padrão é intencional: nenhum job pesado compete com os digests da manhã. Se a análise semanal atrasar, o digest de segunda ainda entrega porque usa dados da coleta de sábado, não da análise de domingo.

O Que Não Dá Pra Prever Sem Rodar

Algumas coisas que só descobri depois que o sistema tava rodando em produção.

O Instagram bloqueia scraping aleatoriamente. Não importa quão stealth seu browser é. A configuração inicial era só scraping via Ferrum. De cara, resolvi adicionar o Apify como fonte primária (API paga, mais confiável) e o scraping virou fallback.

LLMs alucinam timestamps. Pedi pro bot criar um lembrete pra “amanhã às 15h” e ele calculou uma data em 2024. A solução foi injetar current_datetime em todo prompt que lida com tempo e instruir explicitamente: “calcule baseado em current_datetime, converta pra ISO 8601 com UTC-3”.

O Discord tem limite de 2000 caracteres por mensagem, o que parece óbvio até seu bot mandar uma análise de 4000 chars e o Discord simplesmente truncar. Implementei split automático que quebra no último \n antes do limite.

Os tool calls falham com frequência em parâmetros, o que me surpreendeu. O LLM pede limit: 100 quando o máximo é 50, ou manda o username sem o @ quando deveria ter. Clamping silencioso ([[val.to_i, 1].max, 50].min) e normalização de input (.strip, .delete("@")) em toda tool eliminaram uma categoria inteira de erros que estavam consumindo tokens em loops de retry.

Convenções mudam de data mais do que eu imaginava. Adicionei um sistema de announcements que acompanha cada mudança (data, venue, preço, cancelamento) com timestamp. O evento tracker roda toda segunda, mas o convention monitor roda DIÁRIO porque a última coisa que a influencer quer é descobrir que uma convenção mudou de data depois de já ter reservado hotel.

O Bot Como Interface

A decisão mais acertada do projeto foi não fazer interface web. O Discord já é onde a influencer passa o dia. O bot vive ali, disponível a qualquer momento. Ela digita “o que eu deveria postar essa semana?” e recebe uma resposta contextualizada com dados dos seus posts, dos concorrentes, do calendário de eventos, das tendências de hashtag, e dos animes/games da temporada.

O chatbot combina múltiplas tools numa resposta. Se ela pergunta sobre estratégia de conteúdo, o LLM chama: digest de conteúdo + calendário de eventos + tendências de hashtag + animes da temporada + jogos da Steam. Cinco consultas ao banco, tudo costurado numa resposta conversacional em português.

Tem até um modo de “pensamento profundo” que ativa quando detecta palavras como “pesquise”, “analise”, “investigue”. Nesse modo, o bot usa TODAS as ferramentas relevantes, faz múltiplas consultas, cruza dados entre fontes.

Conclusão

O projeto inteiro saiu em 3 dias, de zero a produção, coletando dados reais, mandando digests toda manhã. Sem Jira, sem sprint planning, sem 6 meses de discovery phase. Um IDEA.md com os desejos da usuária nas palavras dela, desenvolvimento iterativo commit a commit, e validação contínua com quem vai usar de verdade.

Se eu tivesse começado pela arquitetura, teria passado semanas projetando um dashboard que ela não ia abrir. Começando pelo desejo, o sistema acabou sendo um chatbot no Discord que ela usa todo dia. Jobs assíncronos que não são idempotentes são bombas-relógio — o rate limit vai estourar, o scraping vai falhar, o container vai reiniciar, e se o job não sobrevive a isso sem duplicar dados, o sistema não funciona.

No final das contas, a medida de sucesso do projeto não é a quantidade de linhas de código, nem o número de testes passando, nem a arquitetura elegante. É a influencer abrindo o Discord segunda de manhã e tendo o que precisa pra planejar a semana.

Então fiz o que qualquer programador faria: sentei, escrevi um documento de especificação, e com ajuda do Claude Code (Claude Opus 4.6), construí o FrankMega, um clone simplificado do Mega, self-hosted, em Rails 8, em um único dia de trabalho. 21 commits, 3 horas de desenvolvimento ativo, 210 testes, zero dependência externa além do SQLite.

E antes que apareça o esperto nos comentários: “ah, mas Vibe Coding é só prompt engineering, qualquer um faz” – calma. Esse post é justamente pra mostrar que não é.

Da Ideia ao Código: o IDEA.md

Todo projeto começa com um documento. O meu foi o docs/IDEA.md – 56 linhas descrevendo o que eu queria:

• Upload de arquivo único, com link compartilhável
• Contador de downloads (padrão 5, configurável)
• Expiração automática em até 24 horas
• Autenticação completa: senha + 2FA + passkeys
• Sem página de registro público – convites only
• Admin cria convites, gerencia usuários, bane abusadores
• Rate limiting agressivo, IP banning automático
• Deploy via Docker + Cloudflare Tunnel no meu home server
• Stack: Rails 8, SQLite, Tailwind CSS, Hotwire/Stimulus

Eu deliberadamente incluí no final: “Sugira features importantes que possam ser relevantes pra um serviço assim.” Porque eu sei que um documento de spec nunca cobre tudo. E é aí que começa a parte interessante.

O Big Bang: Commit #1

O primeiro commit (e277226) às 12:17 entregou 207 arquivos, 6.901 linhas de código. Num único commit. Sim, eu sei que é controverso, mas quando se está construindo do zero com AI, o primeiro commit é necessariamente grande.

O que veio nesse commit inicial:

• Autenticação completa com has_secure_password (bcrypt), TOTP via rotp, passkeys via webauthn
• Sistema de convites com códigos únicos e expiração
• Admin panel completo (Users, Invitations, Files, MIME Types)
• Upload com Active Storage + drag-and-drop via Stimulus
• Links de download com hashes de 24 bytes (SecureRandom.urlsafe_base64(24))
• Rate limiting via Rack::Attack em todos os endpoints públicos
• IP banning automático com modelo Ban e job assíncrono
• Tema dark/light com Tailwind CSS inspirado no Mega.nz
• 73 testes (Minitest + FactoryBot)
• Docker configuration com Puma + Thruster
• Solid Queue/Cache/Cable – zero Redis

Entenderam? Tudo isso no commit #1. O IDEA.md virou código funcional numa tacada. Mas o ponto é esse: o primeiro commit não era production-ready. Nem de longe.

A Realidade: 20 Commits de Iteração

Depois do Big Bang vieram 20 commits ao longo de 3 horas. E é aqui que mora a verdade sobre desenvolvimento de software que nenhum tutorial de “Vibe Coding” vai te contar.

Fase 1: “Funciona na minha máquina” (12:40 - 12:46)

Quatro commits em 6 minutos. Sabe o que aconteceu? Fui buildar o Docker e quebrou. Faltava libssl-dev. Consertei. Daí o CSP (Content Security Policy) do secure_headers conflitava com os inline scripts do importmap do Rails. Consertei. Mudei a porta de 3000 pra 3100 pra não conflitar com outros serviços no meu server.

Olha o commit 389ebe8:

# CSP agora é feito pelo Rails built-in, não pelo secure_headers
# Porque secure_headers não suporta nonces pra importmap inline scripts
config.csp = SecureHeaders::OPT_OUT

Esse tipo de incompatibilidade entre gems você só descobre na hora. Nenhum LLM vai te avisar disso de antemão porque é uma combinação específica de versões.

Fase 2: O Commit de Segurança – 22 Falhas Corrigidas (13:10)

Esse é o commit mais importante do projeto inteiro: 4a854a6. 35 arquivos, 612 linhas, 22 issues de segurança corrigidas. Vou detalhar porque é aqui que se separa código de brinquedo de código de produção.

O que o commit inicial fazia de errado:

CRÍTICO – Chaves de criptografia com fallback hardcoded:

# ANTES (perigoso):
config.active_record.encryption.primary_key = ENV.fetch("KEY", "test-primary-key")

# DEPOIS (fail-fast):
if Rails.env.production?
  config.active_record.encryption.primary_key = ENV.fetch("ACTIVE_RECORD_ENCRYPTION_PRIMARY_KEY")
end

Se o ENV var não existisse em produção, a app rodava feliz com a chave hardcoded. Qualquer pessoa que lesse o código-fonte conseguiria decriptar os segredos OTP de todos os usuários. Agora em produção, se faltar a variável, a app crasheia no boot. É o comportamento correto.

CRÍTICO – Replay Attack no OTP:

# ANTES:
def verify_otp(code)
  totp = ROTP::TOTP.new(otp_secret)
  totp.verify(code, drift_behind: 30, drift_ahead: 30).present?
end

# DEPOIS:
def verify_otp(code)
  totp = ROTP::TOTP.new(otp_secret)
  timestamp = totp.verify(code, drift_behind: 30, drift_ahead: 30)
  return false unless timestamp

  # Previne replay: rejeita se o timestamp desse código já foi usado
  if last_otp_at.present? && Time.at(timestamp) <= last_otp_at
    return false
  end

  update_column(:last_otp_at, Time.at(timestamp))
  true
end

Todo tutorial de TOTP que você encontra na internet mostra o verify(code).present? e para aí. O problema: um código TOTP é válido por 30 segundos. Se eu interceptar seu código (shoulder surfing, câmera, clipboard), posso usá-lo múltiplas vezes nessa janela. O last_otp_at garante one-time use real.

ALTO – Race Condition no Download Counter:

# ANTES (race condition):
def increment_download!
  increment!(:download_count)
end

# DEPOIS (atômico):
def increment_download!
  self.class.where(id: id)
      .where("download_count < max_downloads")
      .where("expires_at > ?", Time.current)
      .update_all("download_count = download_count + 1") == 1
end

O increment! faz: (1) lê o valor, (2) soma 1 em Ruby, (3) escreve de volta. Duas requisições simultâneas podem ler 4, ambas escreverem 5, e o usuário ganha dois downloads quando só tinha um. O UPDATE ... WHERE atômico no SQL garante que só uma requisição vence. E o == 1 retorna sucesso/falha numa única operação, sem lock.

Isso é o clássico bug TOCTOU (Time of Check, Time of Use). Você nunca vai ver isso no desenvolvimento local com um browser. Só aparece em produção com requisições concorrentes.

ALTO – Open Redirect após login:

# DEPOIS:
def safe_redirect_url?(url)
  uri = URI.parse(url)
  uri.host.nil? || uri.host == request.host
rescue URI::InvalidURIError
  false
end

Sem isso, um atacante podia enviar um link tipo frankmega.com/session?return_to=https://evil.com e após login o usuário seria redirecionado pro site malicioso.

MÉDIO – Nonce do CSP previsível:

# ANTES:
config.content_security_policy_nonce_generator = ->(request) { request.session.id.to_s }

# DEPOIS:
config.content_security_policy_nonce_generator = ->(_request) { SecureRandom.base64(16) }

Session ID não muda entre requests. Se o nonce é previsível, um atacante pode injetar scripts com o nonce correto. Tem que ser aleatório por request.

E mais: IPv6 do Cloudflare adicionado aos trusted proxies, mínimo de 12 caracteres pra senha, MIME detection server-side via Marcel, verificação de file size pelo tempfile (não pelo header do client que pode ser forjado), proteção contra deletar/banir/rebaixar o último admin.

O total de testes pulou de 73 pra 109 com esse único commit.

Como Rails Facilita Segurança

Rails torna MUITO mais fácil implementar segurança do que fazer do zero. Olha a comparação:

O Rails 8 em particular trouxe o rate_limit built-in no controller:

class SessionsController < ApplicationController
  rate_limit to: 10, within: 3.minutes, only: :create,
    with: -> { redirect_to new_session_path, alert: t("flash.sessions.create.rate_limit") }
end

E a autenticação? Rails 8 agora vem com um authentication generator built-in. Não precisa mais do Devise pra coisas básicas. O app/controllers/concerns/authentication.rb do FrankMega é baseado nisso e estende com 2FA, passkeys e invitation-only registration.

File Sharing Não É Só Download

Uma coisa que muita gente não percebe: um serviço de file sharing tem uma superfície de ataque enorme. Não é só “salvar arquivo, gerar link”. Olha tudo que precisa ser considerado:

Sanitização de Filename

def sanitize_filename(name, content_type = nil)
  sanitized = File.basename(name.to_s)                          # Strip path traversal
  sanitized = sanitized.encode("UTF-8", invalid: :replace,      # Handle invalid UTF-8
                                undef: :replace, replace: "")
  sanitized = sanitized.gsub(/[\x00-\x1f\x7f\/\\:*?"<>|]/, "") # Control chars + unsafe chars
  sanitized = sanitized.sub(/\A\.+/, "")                        # Leading dots (hidden files)
  sanitized = sanitized.gsub(/\s+/, " ").strip                  # Collapse whitespace

  # Windows reserved device names
  base_without_ext = sanitized.sub(/\.[^.]*\z/, "")
  if base_without_ext.match?(/\A(CON|PRN|AUX|NUL|COM[1-9]|LPT[1-9])\z/i)
    sanitized = "_#{sanitized}"
  end

  sanitized = strip_extension_junk(sanitized, content_type)
  sanitized = truncate_filename(sanitized, 255)
  sanitized.presence || "unnamed_file"
end

Cada linha existe por um motivo:

• File.basename impede path traversal (../../etc/passwd vira passwd)
• Strip de control chars impede null byte injection e terminal escape injection
• Nomes reservados do Windows (CON, NUL, AUX, LPT1-9) causam problemas se o storage for acessado de um Windows
• Truncamento pra 255 bytes (não caracteres!) preservando a extensão – um emoji de 4 bytes conta como 4 pro limite do ext4/NTFS
• strip_extension_junk trata nomes que vêm de URLs com parâmetros grudados: photo.jpg_1280x720+quality=80 vira photo.jpg

E isso é server-side. Tem validação client-side também no Stimulus controller pra rejeitar antes do upload:

isInvalidFilename(name) {
  if (new Blob([name]).size > 255) return true
  if (/[\x00-\x1f\x7f/:*?"<>|\\]/.test(name)) return true
  return false
}

MIME Type Detection Server-Side

@shared_file.content_type = Marcel::MimeType.for(uploaded.tempfile, name: uploaded.original_filename)
@shared_file.file_size = uploaded.tempfile.size

Não confia no Content-Type que o browser envia. O Marcel inspeciona os magic bytes do arquivo pra determinar o tipo real. E o file size vem do tempfile no disco, não do header Content-Length que pode ser forjado.

Quotas e Disk Usage

Cada usuário tem uma quota de disco (5 GB default, admin pode customizar):

def can_upload?(file_size)
  grace = Rails.application.config.x.security.disk_quota_grace_bytes
  (storage_used + file_size) <= (disk_quota + grace)
end

Sem quota, um único usuário malicioso enche o disco do servidor. Com o grace buffer de 10%, um upload que passa um pouco do limite é aceito pra não frustrar o usuário no edge case.

Cleanup Automático

class CleanupExpiredFilesJob < ApplicationJob
  queue_as :default

  def perform
    SharedFile.inactive.find_each do |shared_file|
      shared_file.file.purge if shared_file.file.attached?
      shared_file.destroy
    end
  end
end

Roda a cada 15 minutos via Solid Queue. Se ninguém baixou em 24 horas, sumiu. Se bateu o limite de downloads, sumiu. Sem isso, disco do servidor enche e o serviço morre.

IP Banning Automático

class InvalidHashAccessJob < ApplicationJob
  queue_as :default

  def perform(ip_address)
    security = Rails.application.config.x.security
    return unless security.enable_banning

    cache_key = "invalid_hash:#{ip_address}"
    count = Rails.cache.increment(cache_key, 1, expires_in: 1.hour) || 1

    if count >= security.max_invalid_hash_attempts
      Ban.ban!(ip_address, reason: "Repeated invalid download hash access",
               duration: security.ban_duration)
      Rails.cache.delete(cache_key)
    end
  end
end

Tentou 3 hashes inválidos? Banido por 1 hora. Isso impede enumeração de hashes. Com 24 bytes de entropia (192 bits, 2^192 possibilidades), brute force é computacionalmente inviável, mas a proteção extra não custa nada.

Rate Limiting em Camadas

O Rack::Attack opera na camada de middleware (antes do Rails processar):

# Login: 5 tentativas por minuto por IP
Rack::Attack.throttle("logins/ip", limit: 5, period: 1.minute) do |req|
  req.ip if req.path == "/session" && req.post?
end

# Login: 5 tentativas por minuto por email
Rack::Attack.throttle("logins/email", limit: 5, period: 1.minute) do |req|
  if req.path == "/session" && req.post?
    req.params.dig("email_address")&.to_s&.downcase&.strip
  end
end

# Downloads: 60 views e 30 downloads por minuto
Rack::Attack.throttle("downloads_get/ip", limit: 60, period: 1.minute) do |req|
  req.ip if req.path.start_with?("/d/") && req.get?
end

# Geral: 300 requests por 5 minutos (exceto assets)
Rack::Attack.throttle("requests/ip", limit: 300, period: 5.minutes) do |req|
  req.ip unless req.path.start_with?("/assets")
end

Sete throttles diferentes pra cenários específicos. Mais o rate_limit do Rails 8 nos controllers. IPs banidos nem chegam ao Rails – são rejeitados na blocklist do middleware com status 403.

E os limites são configuráveis: em produção é 1x, em desenvolvimento é 10x pra não se trancar durante testes. Tudo centralizado no config/initializers/security.rb.

A Saga do Download: 5 Commits em 21 Minutos

Essa parte é divertida porque mostra debugging real. Entre 14:44 e 15:05, eu fiz 5 commits tentando fazer o download funcionar com Turbo Drive:

1. cc3c23d – Adicionei data-turbo=false no botão de download. Não funcionou.
2. 5224ed2 – Movi data-turbo=false pro <form>. Não funcionou.
3. 98b0d4f – Abandonei o redirect_to rails_blob_path e usei send_file direto. Parcialmente funcionou.
4. 1fdf5f9 – Troquei de POST pra GET link. Funcionou mas… bots podem consumir downloads com GET.
5. 4c74b27 – Voltei pra POST. Adicionei cleanup de URL artifacts nos filenames.

O root cause: o Turbo Drive intercepta navegação agressivamente, e download de arquivo via redirect_to (que gera uma cadeia de 302 redirects do Active Storage) confunde o Turbo. A solução final: send_file direto do disco com disposition: "attachment" via POST com data: { turbo: false } no form.

Esse tipo de problema um LLM não resolve sozinho. Precisa testar no browser real, ver o que acontece, tentar, falhar, ajustar. É desenvolvimento iterativo puro.

O Gap entre a Ideia e o Produto Final

Olha o que o IDEA.md não mencionava e que emergiu durante o desenvolvimento:

1. Per-user disk quotas – sem isso um usuário enche o disco do server
2. I18n completo (EN + PT-BR) – 66 arquivos, ~250 strings extraídas
3. Terms of Service com aceite obrigatório
4. User self-deletion – requisito de privacidade
5. Blocked downloads de usuários banidos – seus links retornam 410 Gone
6. Client-side upload validation – verifica size, quota e filename antes do upload
7. Inline file previews – imagens, vídeo e áudio no download page sem consumir downloads
8. Styled error pages – em vez de plain text “Not Found”, páginas branded com i18n

O IDEA.md dizia “use activeadmin ou administrate”. Na prática construí um admin panel custom com Tailwind porque o administrate tinha problemas de compatibilidade com Rails 8.1. O IDEA.md falava em “progress bar se possível”. Na prática usei drag-and-drop com preview de arquivo via Stimulus, que é melhor que progress bar.

Ninguém consegue prever todas as features no dia 1. Você descobre requisitos conforme constrói. E cada feature nova traz edge cases que precisam ser tratados.

Os Números

Ao final do projeto:

• 21 commits em uma sessão de ~3 horas
• 210 testes (Minitest + FactoryBot), 513 assertions, zero failures
• ~3.100 linhas de código de aplicação (models, controllers, views, JS, CSS, configs)
• ~1.965 linhas de testes (incluindo testes de segurança dedicados)
• 9 models, 20 controllers, 36 views, 9 Stimulus controllers
• 24 medidas de segurança distintas em 7 camadas
• CI: SimpleCov, RuboCop (zero offenses), Brakeman (zero warnings), bundler-audit (zero vulnerabilities)
• Zero dependências externas além do SQLite. Sem Redis, sem PostgreSQL, sem serviço de fila externo

O Invitation-Only Server

O FrankMega não tem cadastro público. O fluxo é:

1. Na primeira execução, sem nenhum usuário, aparece a tela de setup pra criar o admin
2. A rota /setup só existe enquanto User.count.zero? – depois some completamente:

constraints(->(request) { User.count.zero? }) do
  get "setup", to: "setup#new"
  post "setup", to: "setup#create"
end

3. O admin cria convites no painel admin (com expiração)
4. Cada convite gera um código único de 16 bytes
5. Cada código só pode ser usado uma vez (with_lock + transaction pra impedir race condition)
6. Após cadastrar, o convite é marcado como “used”

Isso é perfeito pra um serviço pessoal/familiar. Controle total de quem acessa.

Deploy: Docker + Cloudflare Tunnel

Pra fechar, o tutorial de deploy, caso queira rodar no seu próprio Home Server Docker. Não é complicado mas tem detalhes que importam.

O Dockerfile

Multi-stage build em 3 estágios:

# Stage 1: Base (runtime)
FROM ruby:3.4.8-slim AS base
RUN apt-get install -y curl libjemalloc2 libvips sqlite3
# jemalloc pra melhor gerenciamento de memória

# Stage 2: Build (throwaway)
FROM base AS build
RUN apt-get install -y build-essential git libssl-dev
# Bundle install + asset precompilation com dummy env vars

# Stage 3: Final
# Copia gems e app, roda como user não-root (rails:rails, UID 1000)
CMD ["./bin/thrust", "./bin/rails", "server"]

O bin/thrust é o Thruster (do Basecamp) – um proxy HTTP na frente do Puma que faz: gzip/brotli compression, asset caching, X-Sendfile acceleration. Escuta na porta 80, proxeia pro Puma na 3000.

O entrypoint roda db:prepare e db:seed automaticamente no boot:

#!/bin/bash -e
if [ "${@: -2:1}" == "./bin/rails" ] && [ "${@: -1:1}" == "server" ]; then
  ./bin/rails db:prepare
  ./bin/rails db:seed
fi
exec "${@}"

docker-compose.yml

Dois serviços:

services:
  web:
    image: akitaonrails/frankmega:latest
    ports:
      - "3100:80"
    volumes:
      - /home/seuuser/frankmega/uploads:/rails/storage/uploads
      - /home/seuuser/frankmega/db:/rails/storage
    environment:
      SECRET_KEY_BASE: ${SECRET_KEY_BASE}
      HOST: ${HOST}
      # ... mais ~15 variáveis
    restart: unless-stopped

  tunnel:
    image: cloudflare/cloudflared:latest
    command: tunnel run
    environment:
      - TUNNEL_TOKEN=${TUNNEL_TOKEN}
    depends_on:
      - web
    restart: unless-stopped

O sidecar cloudflare/cloudflared cria um túnel outbound pra edge do Cloudflare. Não precisa abrir portas no firewall do home server. O Cloudflare faz SSL termination, DDoS protection, e roteia o tráfego pro container.

Passo a Passo

1. Crie o Tunnel no Cloudflare:

• Cloudflare Zero Trust Dashboard > Networks > Tunnels > Create
• Tipo: Cloudflared
• Copie o TUNNEL_TOKEN
• Configure o hostname: frankmega.seudominio.com apontando pra http://web:80

2. Gere os segredos:

# SECRET_KEY_BASE
openssl rand -hex 64

# Chaves de criptografia (3 valores separados)
openssl rand -hex 32  # PRIMARY_KEY
openssl rand -hex 32  # DETERMINISTIC_KEY
openssl rand -hex 32  # KEY_DERIVATION_SALT

3. Configure o .env:

SECRET_KEY_BASE=<gerado acima>
RAILS_MASTER_KEY=<do config/master.key>
HOST=frankmega.seudominio.com
WEBAUTHN_ORIGIN=https://frankmega.seudominio.com
WEBAUTHN_RP_ID=frankmega.seudominio.com
ACTIVE_RECORD_ENCRYPTION_PRIMARY_KEY=<gerado>
ACTIVE_RECORD_ENCRYPTION_DETERMINISTIC_KEY=<gerado>
ACTIVE_RECORD_ENCRYPTION_KEY_DERIVATION_SALT=<gerado>
TUNNEL_TOKEN=<do Cloudflare>
FORCE_SSL=true
APP_LOCALE=pt-BR

4. Suba:

docker compose pull
docker compose up -d

5. Acesse https://frankmega.seudominio.com, crie a conta admin, comece a usar.

Cuidados Importantes

• FORCE_SSL=false pra testar localmente em http://localhost:3100 sem Cloudflare na frente, senão entra em redirect loop
• WebAuthn origin precisa bater exatamente, incluindo o https://. Se errar, passkeys silenciosamente não funcionam
• IPs do Cloudflare são hardcoded no initializer (porque o gem cloudflare-rails não é compatível com Rails 8.1). Se o Cloudflare mudar os ranges, precisa rebuildar a imagem
• Chaves de criptografia são permanentes. Se trocar depois que usuários configuraram 2FA, os segredos OTP ficam ilegíveis e eles perdem acesso
• Cloudflare free tem limite de 100 MB de upload. Pro plano grátis, arquivos acima disso não passam pelo tunnel. A app permite até 1 GB mas o Cloudflare é o gargalo
• O container roda como UID 1000. Se usar bind mounts ao invés de named volumes, o diretório precisa ser owned pelo UID 1000
• São 4 bancos SQLite separados em produção (app, cache, queue, cable), todos no volume db_data. Backup é copiar o volume inteiro

O Verdadeiro Ponto Sobre “Vibe Coding”

O Claude Code é absurdamente produtivo. Eu não teria feito tudo isso em 3 horas sem ele. Lembra de antigamente que você dava murro em ponta de faca por 1 semana só pra fazer um login funcionar? Pois é.

O commit de I18n sozinho (66 arquivos, ~250 strings extraídas pra dois idiomas) levaria um dia inteiro manualmente.

Mas o ponto que ninguém quer ouvir: o LLM não tomou as decisões de segurança. Eu pedi pra ele fazer um audit e ele encontrou os problemas, mas eu precisei saber pedir. E precisei saber quais perguntas fazer. “Revise a segurança” é uma instrução vaga. “Verifique se tem race condition no increment do download counter” é uma instrução que só quem sabe o que é TOCTOU consegue dar.

Aquelas 56 linhas do IDEA.md carregam décadas de experiência em desenvolvimento web. Eu sabia pedir rate limiting porque já vi serviços derrubados por bots. Sabia pedir IP banning porque já lidei com abuse. Sabia pedir download counter atômico porque entendo concorrência.

Se um iniciante escrevesse o mesmo IDEA.md, provavelmente não teria metade dessas preocupações. E o LLM não iria sugerir espontaneamente. O resultado seria um serviço funcional, bonito, e completamente inseguro.

O valor do programador experiente no Vibe Coding não é escrever código. É saber o que pedir e revisar o que foi gerado. A experiência é o filtro entre “funciona” e “funciona em produção”.

Os 210 testes e 24 medidas de segurança não vieram de prompt engineering. Vieram de saber o que testar e por quê.

O código é open source sob AGPL-3.0: github.com/akitaonrails/frank_mega. Deploy no seu server, fucem o código, aprendam com os commits. E se acharem mais falhas de segurança, me avisem.

Lembrem-se:

A IA é o espelho da sua própria competência.

E não deixe de assinar minha nova newsletter The M.Akita Chronicles!

–

Se eu te dissesse que dá pra rodar uma aplicação Rails completa em produção — com banco de dados, fila de jobs, cache — num único VPS de $12/mês sem instalar PostgreSQL, Redis, ou qualquer outro serviço externo, você acreditaria?

Pois é. Esse é o Rails 8 com SQLite e Kamal.

SQLite no Rails 8: agora é pra valer

O Rails 8 trouxe o SQLite como opção real de produção, não como brinquedo de desenvolvimento. E quando digo “real”, quero dizer que o rails new gera tudo pronto: banco principal em SQLite, SolidQueue (jobs) em SQLite, SolidCache (cache) em SQLite, SolidCable (WebSocket) em SQLite.

Quatro serviços que antes precisavam de PostgreSQL + Redis + Memcached agora são arquivos .sqlite3 no disco.

O WAL mode (Write-Ahead Logging) habilita leituras concorrentes enquanto uma escrita acontece. Pra aplicações com dezenas de milhares de requisições por dia — que é a imensa maioria das aplicações Rails no mundo — SQLite é mais que suficiente. E a latência de leitura é medida em microsegundos, não milissegundos. É acesso a disco local, não round-trip de rede.

# database.yml — produção com SQLite
production:
  primary:
    <<: *default
    database: storage/production.sqlite3
  queue:
    <<: *default
    database: storage/production_queue.sqlite3
    migrations_paths: db/queue_migrate
  cache:
    <<: *default
    database: storage/production_cache.sqlite3
    migrations_paths: db/cache_migrate

Três arquivos. Sem conexão TCP. Sem pooling. Sem “o PostgreSQL tá aceitando conexões?”. Backup é um VACUUM INTO e pronto — um comando SQL que produz uma cópia atômica. Restore? Cola o arquivo de volta. Tenta fazer isso com um dump de PostgreSQL de 2GB.

Kamal: Docker Deploy Sem Kubernetes

O Kamal é o deployer do Rails 8. Pensa nele como “SSH + Docker, mas inteligente”. Sem Kubernetes. Sem Helm charts. Sem YAML de 300 linhas descrevendo um Ingress Controller.

A configuração inteira cabe em um arquivo:

# config/deploy.yml
service: minha-app
image: meuregistry/minha-app

servers:
  web:
    hosts:
      - 107.170.70.49
    options:
      network: minha-network
    volumes:
      - minha-app-storage:/rails/storage
      - minha-app-content:/rails/content

proxy:
  ssl: true
  host: app.meudominio.com

builder:
  arch: amd64

env:
  clear:
    RAILS_LOG_LEVEL: info
  secret:
    - RAILS_MASTER_KEY
    - DATABASE_URL

O que o Kamal faz quando você roda kamal deploy:

1. Builda a imagem Docker localmente (ou em CI)
2. Pusha pro registry
3. SSH no servidor
4. Puxa a nova imagem
5. Roda migrations
6. Reinicia o container com zero downtime via kamal-proxy

O kamal-proxy é o segredo: ele funciona como reverse proxy na frente dos seus containers. Quando o deploy acontece, ele sobe o novo container, espera ele ficar healthy, redireciona o tráfego, e depois derruba o antigo. Seus usuários não percebem nada.

Volumes Docker: O Segredo do SQLite em Produção

O ponto crítico de SQLite em Docker é: os dados não podem morrer com o container. Docker volumes resolvem isso:

volumes:
  - minha-app-storage:/rails/storage

O diretório storage/ contém todos os bancos SQLite. Com o volume Docker, eles persistem entre deploys. O container é efêmero; os dados são permanentes.

Mas tem um detalhe que pega muita gente: se você roda dois serviços diferentes que compartilham dados via arquivos (não banco), precisa de um volume compartilhado:

# Serviço A escreve conteúdo
volumes:
  - content-compartilhado:/rails/content

# Serviço B lê conteúdo
volumes:
  - content-compartilhado:/rails/content

O mesmo volume Docker montado em dois containers. Simples, funciona, e não precisa de NFS, S3, ou qualquer coisa sofisticada. É um diretório no disco do servidor.

Múltiplos Serviços no Mesmo VPS

Uma vantagem pouco discutida do Kamal: você pode rodar múltiplas aplicações no mesmo servidor. O kamal-proxy roteia por hostname:

app.meudominio.com    → container-app
bot.meudominio.com    → container-bot

Cada serviço tem seu próprio deploy.yml, sua própria imagem Docker, seu próprio ciclo de deploy. Mas todos rodam no mesmo VPS, compartilhando a mesma rede Docker para comunicação interna.

O SSL é automático via Let’s Encrypt — o kamal-proxy cuida disso. Cada hostname ganha seu certificado sem você configurar nada.

Hooks: Automação no Deploy

O Kamal suporta hooks em vários pontos do ciclo de deploy. O mais útil é o pre-deploy, que roda antes do container novo substituir o antigo:

# .kamal/hooks/pre-deploy
#!/bin/sh
# Roda migrations antes do container ficar ativo
ssh root@$KAMAL_HOSTS \
  "docker exec minha-app-web bin/rails db:migrate"

Outros hooks úteis:

• post-deploy — notificar equipe, limpar cache
• pre-connect — verificar saúde do servidor
• docker-setup — instalar dependências no host

O Dockerfile que o Rails Gera

O Rails 8 gera um Dockerfile otimizado de produção. Alguns destaques:

# Multi-stage build: build stage grande, runtime stage mínima
FROM ruby:3.3-slim AS base

# Instala apenas dependências de runtime
RUN apt-get install -y libsqlite3-0

FROM base AS build
# Aqui instala tudo pra compilar gems nativas
RUN apt-get install -y build-essential libsqlite3-dev

# Copia e instala gems
COPY Gemfile* ./
RUN bundle install --without development test

# Stage final: só o necessário pra rodar
FROM base
COPY --from=build /usr/local/bundle /usr/local/bundle
COPY . .
RUN bundle exec bootsnap precompile --gemfile app/ lib/

Multi-stage build significa que a imagem final não tem compiladores, headers de desenvolvimento, ou qualquer coisa desnecessária. A imagem de produção fica enxuta.

Secrets: Sem .env em Produção

O Kamal tem um sistema de secrets que lê de um arquivo local (.kamal/secrets) e injeta como variáveis de ambiente no container. Esse arquivo nunca vai pro git:

# .kamal/secrets (gitignored)
RAILS_MASTER_KEY=abc123...
AWS_ACCESS_KEY_ID=AKIA...

No deploy.yml, você referencia:

env:
  secret:
    - RAILS_MASTER_KEY
    - AWS_ACCESS_KEY_ID

O Kamal lê do arquivo local e configura no servidor. Simples, seguro, sem HashiCorp Vault ou AWS Secrets Manager (a menos que você queira — Kamal suporta adaptadores).

Backup de SQLite: Absurdamente Simples (Se Fizer Certo)

Quer backup? Um comando SQL:

VACUUM INTO '/tmp/backup/newsletter.sqlite3';

O VACUUM INTO é atômico — produz uma cópia consistente e desfragmentada do banco, mesmo com escritas acontecendo. Roda enquanto a aplicação está servindo requests normalmente. E a cópia resultante é um banco SQLite completo e funcional — abre, consulta, restaura.

Atenção: copiar o arquivo .sqlite3 diretamente (cp, tar, rsync) de um banco em uso pode corromper o backup. Se uma escrita estiver em andamento no momento da cópia, você fica com um arquivo meio-escrito. O SQLite tem WAL (Write-Ahead Log) e journaling que protegem o banco ativo — mas a cópia crua não herda essa proteção.

Na prática, automatizei isso com um job Rails que roda a cada hora:

class BackupDatabaseJob < ApplicationJob
  def perform
    backup_dir = File.join(Rails.configuration.content_dir, "backups")
    FileUtils.mkdir_p(backup_dir)
    dest = File.join(backup_dir, "newsletter.sqlite3")
    ActiveRecord::Base.connection.execute("VACUUM INTO '#{dest}'")
  end
end

O backup vai pro diretório compartilhado de conteúdo — o mesmo que já é sincronizado com rsync pra máquina local. Sem agente de backup extra, sem serviço externo, sem snapshot de volume. Um SQL, um arquivo, um rsync.

Compara isso com pg_dump de um banco PostgreSQL de produção com dezenas de tabelas e constraints. O SQLite backup é um comando que produz um arquivo funcional. Restaurar? Copia de volta e reinicia.

Quando NÃO Usar SQLite

Vou ser honesto: SQLite não é pra tudo.

• Múltiplos servidores web escrevendo no mesmo banco? Não. SQLite é single-writer. Se você precisa de horizontal scaling com múltiplos nós, vai de PostgreSQL.
• Datasets massivos (centenas de GB)? PostgreSQL tem melhor query planning e paralelismo.
• Replicação e alta disponibilidade? PostgreSQL com streaming replication.

Mas a pergunta honesta é: quantas aplicações realmente precisam disso? A vasta maioria roda num único servidor e nunca vai precisar de mais. E pra essas, SQLite + Kamal é a combinação mais produtiva que existe hoje.

O Custo Real

Vamos fazer a conta:

E o custo cognitivo? Ao invés de debugar “por que o Redis perdeu meus jobs?”, “por que o PostgreSQL tá rejeitando conexões?”, “por que o cert expirou?”, você foca no que importa: o produto.

Conclusão

SQLite + Kamal não é downgrade. É que a maioria das aplicações nunca precisou da complexidade que a gente achava que precisava. O Rails 8 abraçou isso e entregou uma experiência de deploy que é, sem exagero, a mais simples que já existiu no ecossistema Ruby.

Um VPS. Um comando. Zero serviços externos. E uma aplicação que roda tão rápido quanto qualquer setup enterprise com 15 serviços no docker-compose.

E não deixe de assinar minha nova newsletter The M.Akita Chronicles!

–

Vou ser direto: a maioria dos desenvolvedores trata background jobs como se fossem scripts que rodam uma vez e pronto. “Ah, coloca num Sidekiq e tá bom.” Não, não tá bom. Jobs que processam coisas importantes — enviar emails, publicar conteúdo, chamar APIs externas — precisam ser tratados como cidadãos de primeira classe na sua arquitetura.

Neste post vou mostrar como o Rails 8 com ActiveJob e SolidQueue mudou minha perspectiva sobre processamento assíncrono. Não é teoria — são padrões que emergiram de um sistema real rodando em produção toda semana.

O Problema: Jobs São Frágeis por Natureza

Pense no cenário: você tem um job que monta uma newsletter, publica num blog via API do GitHub, espera um podcast ficar pronto, e depois dispara emails para centenas de assinantes. Qualquer passo pode falhar. A API pode dar timeout. O podcast pode demorar mais que o esperado. O servidor pode reiniciar no meio do envio.

Se você tratar isso como um script linear, vai sofrer. A pergunta certa não é “como faço esse job rodar?” — é “como faço esse job se recuperar quando algo der errado?”

Padrão 1: retry_on Com Exceções Específicas

O retry_on do ActiveJob é absurdamente poderoso, mas a maioria usa errado. Olha o anti-padrão clássico:

class MeuJob < ApplicationJob
  retry_on StandardError, wait: 5.seconds, attempts: 3
end

Isso re-tenta qualquer erro 3 vezes e desiste. Serve pra quase nada no mundo real. O padrão que funciona é criar exceções específicas para estados transitórios:

class PodcastNotReady < StandardError; end

class PublishAndSendJob < ApplicationJob
  retry_on PodcastNotReady, wait: 15.minutes, attempts: 16

  def perform(newsletter_id)
    metadata = check_podcast_metadata(newsletter_id)
    raise PodcastNotReady, "Aguardando podcast" unless metadata
    # continua o trabalho...
  end
end

Percebe o que está acontecendo? O job espera até 4 horas (15min × 16) pelo podcast ficar pronto, fazendo polling a cada 15 minutos. Não é um loop infinito — tem um limite claro. E quando estoura esse limite, você trata o timeout explicitamente:

rescue PodcastNotReady => e
  if executions >= 16
    # Publica sem podcast e avisa a equipe
    publish_without_podcast(newsletter)
    notify_team("Podcast não ficou pronto a tempo")
  else
    raise # re-raise pra SolidQueue agendar o próximo retry
  end
end

Isso é degradação graciosa. O sistema não para porque um componente falhou — ele se adapta e continua.

Padrão 2: Locks Distribuídos

Quando você tem múltiplos caminhos que podem disparar o mesmo job (um cron de segurança, um trigger manual, uma API), precisa garantir que só uma instância roda por vez.

O conceito é simples: um lock baseado em arquivo (ou banco) que expira automaticamente:

class DeployLock
  LOCK_DIR = Rails.root.join("tmp/locks")
  DEFAULT_TTL = 30.minutes

  def self.with_lock(name, ttl: DEFAULT_TTL)
    acquire!(name, ttl: ttl)
    yield
  ensure
    release(name)
  end
end

Com SQLite, isso é trivial — sem Redis, sem coordenação externa. O lock tem TTL pra não travar se o processo morrer. E o ensure garante que libera mesmo se o bloco levantar exceção.

Padrão 3: Envio Atômico de Emails

Aqui é onde a maioria dos sistemas de newsletter falha espetacularmente. O cenário: você está enviando 500 emails e o servidor reinicia no email 247. O que acontece quando o job re-executa?

Se você só iterou uma lista, vai reenviar os primeiros 247. Seus assinantes vão adorar receber a newsletter duas vezes.

A solução é claiming atômico por destinatário:

# Antes de enviar, cria um registro por assinante
subscribers.each do |sub|
  EmailDelivery.create!(
    newsletter: newsletter,
    subscriber: sub,
    status: "pending"
  )
end

# Na hora de enviar, faz claim atômico
delivery = EmailDelivery
  .where(status: ["pending", "failed"])
  .lock
  .first

delivery.update!(status: "sending")
send_email(delivery)
delivery.update!(status: "sent")

Se o servidor morrer entre sending e sent, o registro fica como “sending” — e um job de recuperação (RecoverStaleDeliveriesJob) periodicamente move esses registros para “unknown” depois de um timeout, pra que nunca sejam automaticamente reenviados. Emails ambíguos nunca são reenviados automaticamente. Esse é o tipo de detalhe que separa um sistema hobby de um sistema de produção.

Padrão 4: Jobs Orquestradores

Um erro comum é colocar lógica demais num único job. O padrão que funciona é ter jobs orquestradores que delegam para jobs especializados:

PublishAndSendJob (orquestrador)
  ├── Espera podcast (retry_on PodcastNotReady)
  ├── PublishToBlogJob.publish(newsletter)
  └── SendNewsletterJob.perform_now(newsletter.id)
        └── SendSingleEmailJob (por assinante)

O orquestrador coordena a sequência. Cada job especializado sabe fazer exatamente uma coisa e pode ser re-executado independentemente. Se o envio de emails falhar, você pode re-disparar só o SendNewsletterJob sem republicar o blog.

Padrão 5: Safety Nets com Cron

Não confie em uma única cadeia de execução. O cron do SolidQueue (config/recurring.yml) serve como rede de segurança:

send_newsletter:
  class: SendNewsletterJob
  schedule: "0 12 * * 1"  # Segunda 9h BRT (UTC-3)

Se o PublishAndSendJob das 7h falhou catastroficamente, o cron das 9h dispara o SendNewsletterJob como fallback. O job verifica se a newsletter já foi enviada e faz no-op se sim. Idempotência é a palavra-chave aqui — o job pode rodar quantas vezes quiser e o resultado é sempre o mesmo.

Mas cuidado com o inverso: um job que se reagenda infinitamente quando não encontra trabalho é uma bomba-relógio. Se o job não encontra newsletter pronta, ele simplesmente retorna. O cron cuida de tentar de novo na próxima semana.

Padrão 6: Notificações de Status

Todo job de longa duração deve comunicar seu progresso. Um concern simples resolve:

module DiscordStatus
  extend ActiveSupport::Concern

  def notify_start(message)
    DiscordNotifier.send(channel: status_channel, text: "▶️ #{message}")
  end

  def notify_done(message)
    DiscordNotifier.send(channel: status_channel, text: "✅ #{message}")
  end

  def notify_error(message)
    DiscordNotifier.send(channel: status_channel, text: "❌ #{message}")
  end
end

Cada job inclui o concern e chama notify_start no início, notify_done no sucesso, notify_error no rescue. Quando algo dá errado às 3 da manhã, você acorda e vê exatamente onde parou — sem precisar cavar logs.

SolidQueue: O Fim da Dependência de Redis

Uma nota sobre SolidQueue, que veio como padrão no Rails 8: usar o mesmo banco SQLite para jobs e dados da aplicação simplifica drasticamente a operação. Não precisa de Redis rodando separado. Não precisa se preocupar com o Redis reiniciar e perder jobs que estavam na memória.

Os jobs ficam persistidos no banco. Se o servidor reiniciar, eles estão lá esperando. O retry state é preservado. É absurdamente mais simples que a alternativa, e pra 99% dos casos, a performance é mais que suficiente.

Conclusão

O Rails 8 com ActiveJob e SolidQueue não inventou nada revolucionário. O que ele fez foi deixar ridiculamente fácil de implementar padrões que antes precisavam de infraestrutura pesada:

• retry_on com exceções específicas e limites claros
• Locks distribuídos com TTL automático
• Claiming atômico pra operações que não podem duplicar
• Jobs orquestradores que delegam e se recuperam
• Crons de segurança como fallback
• Notificações pra visibilidade operacional

Nenhum desses padrões é complicado sozinho. Mas juntos, é o que faz a diferença entre um sistema que quebra na primeira falha e um que aguenta o tranco em produção — e te deixa dormir tranquilo na segunda-feira.

15 anos atrás Ruby on Rails é lançado, e todo mundo tinha certeza que logo desapareceria.

Ruby on Rails 6.0 acabou de ser lançado.

Why, The Lucky Stiff sumiu faz 10 anos.

Estou iniciando o 2o ano do meu canal e acho que agora é uma boa hora para contar essa história.

Esta é a história que eu queria ter contado logo que comecei o canal, 1 ano atrás. Mas eu precisava explicar muitas outras histórias antes para dar contexto. Minha própria carreira inicial. A história da computação e da Web nos anos 90 a 2000. Conceitos como Agilidade e Startups.

Agora que contei boa parte do que queria, se vocês assistiram os vídeos do último ano, devem estar equipados pra entender esta parte da história. Neste episódio vou compilar 8 anos de história, de onde veio Ruby on Rails, e porque ele estava destinado a dar certo mesmo que todos os “experts” achassem que não daria.

Se quiser aprender mais, entre no grupo de Rails do Facebook: https://www.facebook.com/groups/rubyonrailsbrasil/

É o maior e melhor grupo que eu conheço e eles estão sempre compartilhando dicas, materiais e cursos, fora ofertas de emprego.

Disclaimer:

Esta história é contada sob meu ponto de vista pessoal tendo participado ativamente de muitos eventos. Posso ter esquecido alguns momentos e nomes importantes, então mande nos comentários se eu perdi alguma coisa.

Logo de cara, só depois que terminei de subir o video notei que esqueci de mencionar o pessoal do Rio Grande do Sul, do antigo Mailee e que fez o Catarse, o Kickstarter brasileiro!! Perdoem-me por ter esquecido.

Links:

• 15 Minute Blog Demo 2005 (https://www.youtube.com/watch?v=Gzj723LkRJY)

• Ten Years Of Test Driven Development (http://wiki.c2.com/?TenYearsOfTestDrivenDevelopment)

• The history of testing framework in Ruby (http://rubykaigi.org/2015/presentations/kou/)

• Why’s Poignant Guide to Ruby (https://poignant.guide)

• Why The Lucky Stiff Documentary (https://www.youtube.com/watch?v=64anPPVUw5U)

• Ruby Koans (http://rubykoans.com)

• Ruby Quiz (http://rubyquiz.com)

• RailsCasts (http://railscasts.com)

• RubyTapas (www.rubytapas.com/)

• CodeSchool: Rails for Zombies (https://www.pluralsight.com/courses/code-school-rails-for-zombies)

• Blog Igvita (https://www.igvita.com)

• Rails and Merb Merge (https://yehudakatz.com/2008/12/23/rails-and-merb-merge/)

• RailsEnvy videos (https://www.youtube.com/watch?v=YZeZsZEEpno&list=PLfBoZfyUGYQZ--h9B4e_tmyob8tbqOTKd)

• The Decision to Leave Code School (https://www.greggpollack.com/the-decision-to-leave-code-school/)

• Travis CI joins the Idera family (https://blog.travis-ci.com/2019-01-23-travis-ci-joins-idera-inc)

• Reia (https://github.com/tarcieri/reia)

• 11 types of apps you can build with Ruby on Rails (https://naturaily.com/blog/ruby-on-rails-apps)

• Who gives a F*** about Rails in 2019? (https://naturaily.com/blog/who-gives-f-about-rails?utm_source=linkedin&utm_medium=post)

• Why should you choose Ruby on Rails for your MVP? (https://prograils.com/posts/why-should-you-choose-ruby-on-rails-for-your-mvp?utm_source=rubydaily&utm_medium=referral&utm_campaign=rails-mvp-1)

• AkitaOnRails: Retrospectiva on Rails - 10 Anos e Muito Mais! (http://www.akitaonrails.com/2014/08/26/retrospectiva-on-rails-10-anos-e-muito-mais)

• AkitaOnRails: Entrevistas (https://www.akitaonrails.com/interview)

• AkitaOnRails: _Why, Ruby Dramas, and Dynamiting Courtlandt (http://www.akitaonrails.com/2016/09/26/os-proximos-10-anos)

• AkitaOnRails: The Next 10 Years (http://www.akitaonrails.com/2016/09/26/os-proximos-10-anos)

R.I.P.:

• Remembering Jason Seifer (https://www.greggpollack.com/remembering-jason-seifer/)
• EZRA ZYGMUNTOWICZ: IN MEMORIAM (https://www.engineyard.com/blog/ezra-zygmuntowicz-in-memorium)
• REMEMBERING JIM WEIRICH (https://lithespeed.com/remembering-jim-weirich/)
• Remembering James Golick (https://medium.com/@benkaufman/remembering-james-golick-23c1dc3ab920)
• GIVING OPEN-SOURCE PROJECTS LIFE AFTER A DEVELOPER’S DEATH (https://www.wired.com/story/giving-open-source-projects-life-after-a-developers-death/)

=== Script

Olá pessoal, Fabio Akita

Finalmente! Finalmente, decidi fazer um episódio sobre Ruby on Rails. Muita gente que me conhece nas interwebs como AkitaOnRails começou a me acompanhar quando eu comecei a evangelizar Rails mais de 12 anos atrás. Quando comecei o canal talvez muitos pensariam que a coisa mais óbvia é que eu ia continuar falando de Rails, mas até hoje ainda não fiz nenhum video a respeito. Esse é o episódio que eu queria ter feito 1 ano atrás mas que precisei publicar 58 vídeos antes pra dar o contexto. Exagerando um pouco eu diria que todos os videos que eu fiz até agora foram um prólogo pra esse. Também é apropriado que estou oficialmente iniciando o 2o ano do canal exatamente com esse tema. Quem acompanha o canal já me viu mencionando alguns eventos históricos de Ruby on Rails como nesse episódio da série Começando aos 40 (episodio 1 de backend)

Se alguém me perguntar hoje: é essencial usar Rails? Honestamente não, embora eu diria que você se daria melhor usando Rails, sem dúvida. Em 2019 temos muitas outras opções se, e somente se, você souber o que está fazendo. Eu ainda considero Rails o melhor framework de ponta a ponta e o melhor ecossistema pra maioria dos casos, o pacote completo. Os princípios e fundamentos que tornaram Rails especial em 2004 continuam valendo hoje. Mesmo que você não use Ruby, você provavelmente está “On Rails” e não sabe disso. A história do Rails é um caso único e eu não vejo ele se repetindo de novo tão cedo.

A idéia do video de hoje não é ser a história totalmente completa, mas sim a história pelo meu ponto de vista enquanto personagem nessa história, então vai ter alguns eventos talvez importantes que eu talvez pule. Enquanto escrevia eu via as páginas aumentando, 10 páginas, 20 páginas, 30 … e resolvi que não vou cortar em múltiplos video, pra variar. Vai tudo numa tacada só (… respira …), então vão pegar a pipoca, a água, vão no banheiro antes, e senta aí que lá vem história.

(…)

Como é o jeito “certo” de desenvolver um software médio web hoje em dia? Simples, começa criando um novo projeto no GitHub ou GitLab. Daí roda o generator do seu framework pra criar o esqueleto. Faz o primeiro commit e dá push pro repositório e agora abre acesso pros seus colegas de trabalho. Vamos organizar o trabalho da equipe num backlog e cada um vai fazendo uma pequena feature. Cada feature você abre um novo Pull Request ou Merge Request, dependendo se for GitHub ou GitLab.

Agora vamos criar os specs e fazer o código pra passar. Ou se você não é adepto de test-first development ou TDD como Eu também não sou sempre, pode ser o bom e velho test-after, importante é subir seu código com um mínimo de testes. Alguém insistiu em tentar subir código sem testes? git reset –hard nele! Junta os commits dos testes, do seu código, manda pro branch do pull request. Finalizou? Pede pros colegas darem aquela revisada marota. Agora que tem algum código já seria bom automatizar a execução dos testes, então vamos configurar um Travis-CI ou Circle-CI ou o CI integrado do próprio GitLab.

Agora a gente vai subindo novos códigos, vendo os testes de todo mundo da equipe rodando e passando. E depois de alguns pull requests mergeados, temos uma primeira versão que já dá pra pro usuário brincar. Hora de subir num ambiente de staging pra mandar pros usuários testarem. Então bora criar um projeto no Heroku, definir os recursos extras como banco de dados que vamos precisar e git push heroku.

Sucesso! Aplicativo funcionando! E pra facilitar a vida, vamos criar um continuous deployment ligado ao CI pra toda vez que subir código novo e os testes passarem, ele já subir a versão nova pro ar. Ou então pra cada pull request ainda não aprovado subir um ambiente de testes no Heroku em paralelo também. Assim a vida dos testers e QA vai ficar mais fácil.

Além disso podemos conectar serviços como CodeClimate pra constantemente avaliar a saúde do nosso código, ver se não estamos acumulando muito débito técnico. Avaliar se não estamos deixando de atualizar bibliotecas com bugs de segurança. Se quisermos adicionar recursos mais avançados como WebSockets, pra criar um chat ou fazer push notifications, devemos usar serviços como o bom e velho Pusher. Pra maioria de nós não é necessário usar Node.js ou Go ou algo assim. E podemos habilitar o New Relic RPM no Heroku pra monitorar o uso da nossa aplicação e avaliar possíveis gargalos que precisamos ir otimizando. Ah, é bom viver nessa era de Software as a Service.

Tudo isso que eu acabei de explicar em 2 minutos é o dia a dia de qualquer projeto web comum, ou pelo menos deveria ser caso você ainda esteja numa empresa que não segue esse tipo de fluxo de trabalho. Eu diria que mesmo quem não segue, sente uma certa inveja e gostaria de estar trabalhando assim. Porém lembre-se do que eu venho falando em todos os meus vídeos: essa é uma realidade hoje pra muitos, em 2019. Isso não era verdade em 2004. E esta é a história de como a comunidade Ruby on Rails criou essa realidade.

Eu já contei parte disso no episódio do Diário de Henry Jones, mas em 2004 eu ainda era um consultor Java e SAP, lidando com o peso e burocracia de projetos enterprise desenhados em centenas de páginas de casos de uso e diagramas UML, usando coisas como IBM WebSphere ou BEA WebLogic. Mundo open source não era algo que programadores enterprise discutiam muito, porque não parecia muito “profissional”, era coisa de “agência de php pra sitezinho de sobrinho”. Profissionais usavam JSP, com algum framework proprietário da IBM ou da Oracle.

Pensem em um ambiente onde gerenciar banco de dados era um troço difícil, nenhum programador gostava de fazer ou mesmo podia fazer se quisesse. Pra isso existiam DBAs. Subir aplicativo web em produção era um saco, ninguém queria fazer, por isso existia gente de infra só pra subir versão nova em produção. Gerenciar versionamento de software era um saco! Ninguém queria fazer! Eu juro que existia emprego pra uma posição chamada “Gerente de Configuração” pra ferramentas da Rational tipo Clearcase, que é literalmente alguém cujo job description era fazer commit do código! (mindblown!)

O que havia de mais avançado no mundo open source naquela época era poder desenvolver apps em Apache Struts ou o novíssimo Spring na era do Java 1.4 pra 1.5, subir num tomcat ou glassfish local pra testar e num JBoss pra subir em produção. Usar Subversion era um troço meio subversivo ainda. Povo preferia usar Clearcase ou Microsoft SourceSafe. E mesmo usar Subversion era sofrido, tenta fazer merge de branches pra subir no trunk. E desenvolver fora da rede offline não dava porque Subversion precisava estar online já que commit é o equivalente a commit mais push num Git de hoje. Windows XP ainda era mais do que normal, com um tanto de antivirus tipo McAfee (video) pesando e mesmo assim com aquela sensação que ligar o XP na internet era que nem fazer sexo sem proteção. Acho que eu formatava e reinstalava meu sistema com certa frequência só pra garantir. Eram tempos difíceis …

Então em 2005 a gente esbarra num video com o chamativo título de “Blog em 15 minutos” de um moleque desconhecido com cara de cagador de regra … não, não, não era eu, era esse dinamarquês chamado David Heinemeir Hansson que a gente se acostumou a chamar só de DHH. Pff … em 15 minutos meu Eclipse com os plugins de Websphere nem carregou tudo ainda. Esse video aliás, tem quase 15 anos, e eu acho que vale a pena incorporar ele aqui. Lembrem-se, eu sei que 15 anos atrás muitos de vocês assistindo tinham uns 10, talvez 15 anos de idade, mas tente assistir assumindo que Nada que vocês usam hoje existia naquela época.

(… blog 15 minutos)

A gente chamava esse video também de “video do oops”. O David foi convidado pra vir pro FISL de 2005, o Forum Internacional de Software Livre que acontece em Porto Alegre, todo ano. Um dos organizadores naquele ano foi meu camarada Rodrigo Kochenburger que hoje mora em São Francisco e é um dos melhores programadores que eu já conheci. Antes de mim, pessoas como ele já estavam engajados nessa comunidade de nicho que era Ruby. Agora, entenda que literalmente ninguém usava Ruby fora do Japão e mesmo lá era só um pequeno grupo. Quando o DHH veio apresentar o Rails no FISL a platéia eram basicamente pythonistas e outros que tavam nos corredores. Se tinha meia dúzia de rubistas, no FISL inteiro, era muito.

Pra dar uma noção, tirando pessoas como o Rodrigo não tinha quase nenhum rubista na ativa em 2005. Tinha o Caffo que é outro Rodrigo, o Rodrigo Franco que tinha começado a primeira mailing list brasileira de Rails, a Rails-BR. Tinha o Adriano Dadario e o Ronie Uliana que mantinham o antigo site/forum RubyBR. Tinha o mestre Eustáquio Rangel que publicou o primeiro livro de Ruby no Brasil, e o Ronaldo Ferraz que publicou o primeiro tutorial de Rails em português. Ainda ia levar algum tempo pra aparecer outros blogs que viraram referência aqui no Brasil como o Simples Ideias do Nando Vieira. Aliás, eu provavelmente vou esquecer muitos nomes do começo da história, me perdoem e quem se lembrar da galera das antigas pode mandar nos comentários abaixo.

Naquela época o Vinicius Teles do Rio de Janeiro já tinha publicado seu livro sobre Extreme Programming e estava começando a aplicar em projetos Rails. E outros nomes começaram a surgir como o Manoel Lemos, que hoje virou venture capitalist na Redpoint mas na época desenvolveu o BlogBlogs em 2006, antes de entrar pra Editora Abril. A ótima equipe que de alguma forma o Marco Gomes conseguiu juntar foi quem construiu o famoso Boo-Box em 2007. Na época existia os e-mail do UOL e tinha um produto paralelo que era o BOL ou Brasil Online, que foi feito em Rails lá por 2006 ou 2007 também.

Como falei em outros episódios eu acredito em ciclos de mercado. É muito difícil identificar o começo de um ciclo, normalmente você se dá conta que tá dentro de um quando já passou da fase de early adopters. Mas em 2005 eu sabia que Ruby on Rails, principalmente no Brasil, estava ainda começando o dia 1 desse ciclo. É muito raro conseguir enxergar o dia 1 de alguma coisa que vai conseguir completar o ciclo de 10 anos e embarcar nele no começo. Em 2005 eu tinha já uns 10 anos de carreira, e eu lembro que senti esse frio na espinha quando relembrei de 1995, ano que tivemos alguns dos lançamentos mais históricos até então, o Java 1.0, o Delphi 1.0, o Netscape 1.0 com Javascript 1.0, o Windows 95 inaugurando a era 32-bits. E ali estava eu, 10 anos depois, sentindo que um novo ciclo de 10 anos estava iniciando no mundo de programação. Eu não podia imaginar o que viria pela frente, só agora em retrospectiva dá pra ligar os pontos.

Eu achei o David Hansson, o DHH, um cara muito inteligente, diferente da maioria puramente técnica. Ele criou um produto que ninguém tinha feito igual até então. E não estou dizendo só em criatividade técnica. Estou falando em produto como um todo mesmo. Aliás, ninguém se referia a sites como “produtos” nessa época. Algumas coisas eram geniais só de bater o olho e algumas coisas a gente sabia que seria genial mas faltava ainda tempo pra se provar.

Vamos começar do básico. Naquela época dentre algumas das linguagens mais usadas estava Basic, tanto do Visual Basic, quanto VBScript de ASP e plugins de Office, e no novo .NET, daí C#, Java, PHP, ColdFusion, lembram de ColdFusion?? Lembrando que estamos falando de C# acho que 2, Java 1.5, PHP 3 ou 4. Javascript ainda era não mais que um brinquedo pra soltar box de alert nas páginas. ActionScript que era baseado em Javascript só existia no mundo Flash. Nenhuma das novas linguagens que você conhece hoje tinham sido inventados ainda como Scala, Elixir, Go, Rust, Clojure, Swift, Kotlin. Objective-C ou Erlang já existiam mas ninguém nunca tinha ouvido falar neles no mercado em geral.

Falando em Objective-C a gente tava entrando no final do ciclo de hype de orientação a objetos. Nos anos 70 principalmente a discussão sobre o que era a melhor forma de descrever e programar objetos foi tema de inúmeras discussões, livros, eventos e eu argumentaria que a melhor linguagem orientada a objetos de todos os tempos foi Smalltalk. Porém as empresas que mantinham as versões comerciais de Smalltalk como ParcPlace-Digitalk, ObjectShare, acho que tiveram ingerências ou azar mesmo, e começaram a desaparecer nos anos 80. E o aparecimento de coisas como Visual Basic e depois Java meio que foi o tiro de misericórdia. Smalltalk desapareceu quase totalmente nos anos 90, ninguém mais ouvia falar. Hoje se você procurar ainda acha a Cincom ou a Gemstone e versões open source como o Squeak e Pharo. Só alguns nichos ainda carregavam a herança de Smalltalk em linguagens como Objective-C que a NEXT de Steve Jobs estava usando e essa linguagem obscura do Japão chamada Ruby, que é uma das únicas que se assemelha ao estilo do Smalltalk e Objective-C, mesmo hoje.

Escolher Ruby foi um acerto improvável. Muitos poderiam criticar o fato do DHH não ter escolhido algo como Python que também é uma linguagem interpretada, orientada a objetos e com tipagem dinâmica, mas teria sido a escolha errada. Eu nem sei se o DHH chegou a pensar tão longe assim, eu acho que foi mais sorte mesmo, mas ainda bem que ele escolheu Ruby no lugar. Apesar da linguagem em si ter características excepcionais de ser super flexível, expressiva e agradável de trabalhar comparado com Java, ele tinha Uma coisa que ninguém mais tinha: … ninguém usava, não tinha um ecossistema estabelecido. É como você encontrar ouro e acumular, anos antes do mundo determinar que ele tinha valor.

O DHH começou como um freelancer, trabalhando da Dinamarca que é o país dele, pra agência chamada 37signals, de Chicago, que foi fundado por Jason Fried. Ele já tinha trabalhado um pouco com Java, um pouco com PHP, e assim como todos nós naquela época, já estava de saco cheio da burocracia do Java ou dos bugs e cultura de “quick and dirty” do PHP e Perl do fim dos anos 90. Então por 2003 ou 2004 a agência começou a migrar pra virar uma empresa de produtos, e o DHH resolveu dar uma chance pra esse tal de Ruby. Assim ele desenvolveu o lendário Basecamp que é uma ferramenta colaborativa pra organizar pequenos projetos, e em 2004 ele extraiu o framework Ruby on Rails. Aliás, primeira dica, nunca acredite num framework que não foi extraído de um aplicativo de verdade.

(musica de suspense) Agora aqui entra a minha análise pessoal. O fato do DHH ter se aliado a Jason Fried e o DNA da 37signals ser de design, especialmente numa época onde o design da Apple estava começando a despontar, foi extremamente importante. Muito da linguagem minimalista do design da escola alemã de Bauhaus se misturou ao estilo de código, produto e filosofia do DHH. Naquela época o normal pra um arquiteto enterprise era criar frameworks o mais flexível possível, tudo explícito, tudo configurável, com o maior número de abstrações e indireções pra suportar projetos corporativos de qualquer tamanho e qualquer escala, e de preferência via comitê, com consenso de gente que nem de fato vai usar. Era a filosofia de “e se amanhã eu precisar?”. O DHH preferiu fazer o caminho inverso, que na época era muito inédito: criar um produto de verdade primeiro, que realmente funciona com usuários de verdade, e depois extrair as peças da fundação pra montar um framework. Ironicamente era assim que antes empresas como IBM e Oracle extraíam seus produtos: depois de implementar primeiro num grande cliente, como o governo ou os militares.

(comercial java)

Pouca gente fazia isso nos anos 2000. Arquitetos corporativos eram esnobes demais pra ir pra ralé e, deus me livre, fazer alguma coisa que funciona de verdade. (excerpt) No mundo PHP o pessoal fazia produtos inteiros, vide Joomla, vide Drupal, vide Wordpress. Mas eles raramente extraíam as partes comuns pra reusar em outro projeto, e a comunidade ficava fragmentada em ilhas. O estilo de código quick and dirty macarrônico, muita otimização prematura, porque o PHP não era exatamente a coisa mais performática do mundo também, e diferente de Ruby o PHP de fato tomou muita porrada de verdade. Em vez de “perder tempo” fazendo frameworks, eles ficavam cada um na sua ilha de produto e não se preocupavam muito em reuso. O máximo eram as tentativas de imitar o mundo Java, e imitar justamente a parte ruim: fazendo frameworks gigantes demais como o Zend e criando monstrinhos como o primeiro Magento.

“Vamos ficar masturbando diagramas abstratos como se fosse arte barroca o dia inteiro”.

(comercial php)

Comparativamente o framework Ruby on Rails era muito pequeno. Quando eu escrevi o primeiro livro de Rails eu também não sabia tudo de Rails ainda, então eu escrevi meu livro, capítulo a capítulo lendo o código fonte de cada parte. O código naquela época era pequeno o suficiente pra dar pra ler de ponta a ponta. Mais importante: o código que eu como desenvolvedor de uma app usando Rails precisava escrever era surpreendentemente pouco. Vindo de J2EE a gente tinha que fazer um trilhão de boilerplates; exatamente porque o framework exigia tudo explícito.

Por exemplo, quero fazer um Entity Bean em 2000. Precisava fazer um arquivo que é a interface, outro que é a implementação em si, outro que é um stub pra acesso remoto e por aí vai. Cada coisa que você fazia num J2EE precisava de uns 3 ou 4 arquivos de boilerplate pra ligar as coisas no framework. Não seria exagero dizer que se o projeto tinha 100 arquivos, só uns 20 era código de verdade com regra de negócio e tudo. Por isso a gente precisava usar Eclipse com plugins: pra ele gerar e atualizar essas classes extras pra gente. Era que nem os JavaBean antigos, se eu precisasse programar 10 propriedades, precisava implementar 20 métodos: 10 getters e 10 setters e, de novo, o Eclipse gerava isso automaticamente pra gente. Sério, era um saco programar com as primeiras versões de J2EE. (abaixa a cabeça)

Mas aí eu vi que no Rails não precisava fazer nada disso. Tinha quase zero boilerplates, era uma heresia! Ele apresentou esse conceito de Convention over Configuration e DRY ou Don’t Repeat Yourself, que é um pensamento meio óbvio hoje - ou pelo menos deveria ser - mas não era em 2004. Toda entidade vai ter os mesmos 3 ou 4 arquivos de boilerplate que não serve pra nada, então pra que gerar? Faça o framework inferir o que precisa gerar em tempo de execução e não gere nenhum arquivo que não seja absolutamente necessário. E, mais do que isso, o pouco que eu preciso gerar, não precisa de um plugin numa IDE: roda um script na linha de comando e boom, gera tudo pra mim! Isso era revolucionário! Daí é facil ver como um projeto que deveria ter 100 arquivos, em Rails tinha só uns 20 ou menos.

Justiça seja feita, o J2EE foi quem introduziu o modelo de MVC ou Model View Controller ou mais corretamente o Model 2 da Sun para o mundo em geral. Só que era tão complicado de entender que fazia sentido você precisar de certificação de arquiteto Java só pra conseguir entender esse tal de MVC. O Rails foi quem tornou MVC e conceitos como thin-controllers algo finalmente acessível pro público em geral.

O gerador do Rails sempre gera o esqueleto do projeto. Você sempre sabe que controllers vai nessa pasta, models vão nessa pasta, e views vão nessa outra pasta. Sem XMLs complicados pra configurar e duas dúzias de boilerplates que você nunca sabe onde colocar. Daí todo projeto Rails tem mais ou menos a mesma estrutura e era fácil pular de projeto e saber onde ficam as coisas. E a idéia se pagou porque 15 anos depois, a estrutura do Rails 5 de hoje é muito parecida com a do Rails 1. Mais do que Convention over Configuration, desde o começo Rails era o que gente chamava de opinionated, ou seja, seguia as opiniões do DHH. Isso é controverso até hoje, mas ele bateu o pé e insistiu em integridade conceitual.

Isso Não é uma democracia e Rails era um framework sem consenso e sem comitê. Já não era sem tempo, consenso em mundo técnico é só o mínimo denominador comum dos membros. Em vez de tentar abraçar o mundo e criar um framework que poderia ser pra qualquer coisa ele focou pra ser bom pra fazer apps similares ao Basecamp. Tem gente que odeia isso, mas haters gonna hate. Você pode trocar alguns componentes com alguma facilidade, mas quanto mais diferente você tentar ficar do Rails original, mais complicado vai ficar pra manter o projeto no futuro.

E aqui vemos a influência da Apple. Macbooks bem que poderiam ter mais portas de expansão, ser mais fácil de trocar peças e assim por diante. Mas aí ele seria igual um Dell ou Lenovo. O que torna o Macbook um Macbook é a forma. Sempre vai existir a discussão de forma contra função mas qualquer coisa diferente só pra conseguir consenso com algum nicho destrói sua integridade conceitual. Minimalismo parte do princípio que quem faz o design tem uma opinião muito forte sobre o que é esse mínimo. DHH não é nenhum Jobs, mas ambos certamente tinham muita opinião e não seriam dobrados com facilidade, e ambos foram provados corretos ao longo da década. Não é difícil de argumentar que se hoje Macs são dominantes no mundo de tech startups, foi por causa de Ruby on Rails. Sim, a culpa é nossa. Vejam este vídeo de 2007 que foi feito em parceria com a Apple Education:

(apple video)

Um dos aspectos que vinham ligados por padrão era segurança. Numa época onde era super comum sites sendo lançados em produção com erros primários como cross site request forgery, cross site scripting, sql injection, session hijacking, tudo isso já era travado por padrão no Rails. De novo um efeito de Convention over Configuration, ou seja, porque ter que ligar coisas manualmente que já deveriam estar ligadas por padrão? Você precisava manualmente desligar as proteções se quisesse, e aí fica por sua conta. Por isso apps Rails por muitos anos sempre estiveram entre alguns dos mais seguros por padrão. Todo framework que te vende “flexibilidade” porque você mesmo pode escolher quais componentes por adicionar, sempre vai ser pior porque a grande maioria vai sempre escolher errado.

E se isso não fosse suficiente, nesse esqueleto que ele gera igual pra todo projeto ainda havia outra coisa Completamente diferente: um diretório chamado test. E todo gerador de models, ou controllers ou views também gerava arquivos correspondentes de testes vazios nesse diretório. Lembrem-se era 2004, o manifesto ágil de software tinha saído só 3 anos antes. Vamos lembrar uma coisa, Gerry Weinberg fez testes pela primeira vez em cartões perfurados em 1989. Kent Beck, um dos criadores de Extreme Programming começa a experimentar essa ideia e cria SUnit em 1994 inaugurando a idéia da gramática de testes como test cases, asserts, e vai fazendo pesquisa e escrevendo a respeito até finalmente consolidar a idéia de test driven development e lançar o JUnit no ano 2000. Ou seja, a idéia de TDD não tinha ainda 4 anos desde que o mercado começou a ouvir falar.

Os mundos de desenvolvimento tradicionais, sejam .NET, Java, PHP, não estavam assim muuuuito empolgados em adotar, só alguns pequenos nichos. Então nesse ponto era muito frustrante querer que os programadores fizessem testes, se você tentasse provavelmente todo mundo ia tirar sarro de você na melhor das hipóteses ou você podia ser demitido mesmo, por ser improdutivo fazendo código irrelevante pro projeto! Éee eu sei! De novo, aqui temos outro insight: é muito difícil implementar mudanças radicais como um TDD num ecossistema gigante que já existe e é resistente a mudanças. Não vai acontecer tão fácil, mas existem estratégias. Lembram que eu falei antes que um dos acertos improváveis do DHH foi ter escolhido Ruby, uma linguagem que ninguém usava? Eis o motivo de porque deu certo: porque ele precisava introduzir um novo paradigma mas sem ter que gastar tempo convencendo antigos usuários de Ruby e migrando projetos inteiros pro novo paradigma, por isso dava pra se mover muito rápido.

No ano 2001 o mundo Ruby começou a se interessar com a idéia de testes no estilo de xUnit, surgiram bibliotecas como testsup, depois Lapidary, finalmente RubyUnit e Test::Unit que seguia o estilo xUnit do Kent Beck. E isso foi adotado no Rails do DHH, como padrão! Não algo que você tinha que adicionar depois, mas algo que o framework obrigava você a manualmente tirar se não quisesse. Junte a isso que alguns agilistas como Ward Cunningham e acho que Martin Fowler já estavam com um olho no Ruby porque ele lembra o Smalltalk que eles já gostavam como a verdadeira orientação a objetos, um estilo que ficou perdido nos anos 80.

Aliás, o primeiro livro de Ruby em inglês saiu em 2001, apelidado de Pickaxe por causa da capa, foi escrito por dois signatários do Manifesto Ágil, Dave Thomas e Andy Hunt. Portanto você imagina que além de tudo essa comunidade ocidental de Ruby, começando do zero já iniciaria com Extreme Programming e The Pragmatic Programmer como filosofias de fundação. Finalmente uma comunidade de software que estava começando do zero do jeito certo, ou seja, o jeito verdadeiramente Ágil de desenvolvimento.

Mais do que isso, o tipo de desenvolvedor que virava rubista era muito estranho. O exemplo mais notável foi o lendário Why, the Lucky Stiff, que escreveu naquela mesma época o lendário livro que muitos usaram pra aprender Ruby: The Poignant Guide to Ruby. Sério, olha algumas páginas desse livro (video).

Why era um pseudônimo, e ele nunca quis revelar seu nome ou qualquer detalhe da sua vida, e quando algumas pessoas começaram a fuçar e começar expor sua vida pessoal, inclusive revelando seu nome verdadeiro como sendo Jonathan Gilette, ele fez uma coisa que admiro até hoje. Ele resolveu sumir do mapa em 2009, sem deixar vestígios. Aliás, em 18 de agosto de 2019 faz 10 anos desde que Why apagou todos os seus repositórios e sites e desapareceu.

Ele era um artista que usava código pra se expressar, e ao contrário de um Python ou Java com seu estilo de engenharia de ter só um jeito certo pra se fazer as coisas, e tudo deve ter consenso em comitê, o Ruby era o oposto: manipule a linguagem como você quiser. Ele tinha a liberdade do Lisp com a expressividade do Smalltalk. Nenhuma outra linguagem da época permitiria algo como o que Why fazia. Why the Lucky Stiff que inclusive é um nome que aparece citado uma única vez no romance The Fountainhead, de Ayn Rand. Outra coincidência que eu achei muito providencial dado que Why fez a mesma coisa que o fim do livro A Nascente.

(video acabando com chunky bacon)

Se você nunca ouviu a expressão “Chunky Bacon”, você ainda não aprendeu Ruby do jeito certo (risos). Ruby começou sendo ferramenta de artistas. A primeira geração de rubistas é um grupo que não se via igual talvez desde os anos 60 ou 70. E o que eu falei que Ruby atraía desenvolvedores estranhos é porque eram pessoas que gostavam de expressar suas décadas de experiência com código. Entrar num grupo gigante é fácil, é só ser um seguidor. Mas pra entrar num grupo com zero pessoas, você precisa ser um criador. Por isso a primeira geração de rubistas trouxe gente como Chad Fowler, Rich Kilmer, David Black, o falecido e adorado Jim Weirich, depois agilistas como Dave Thomas ou Martin Fowler ou Uncle Bob. Não deixem de assistir o documentário sobre o Why que eu co-apresentei na Rubyconf Brasil de 2014 com Kevin Triplett e meus artigos sobre ele que vou deixar nas descrições abaixo.

Então vamos recapitular nossa sopa primordial: uma linguagem obscura, que resgata o espírito de Smalltalk e Lisp, a orientação a objetos original, que implementa corretamente os princípios ágeis, e até mesmo outras noções como yagni ou you ain’t gonna need it, que é o jeito minimalista que o DHH aprendeu na renascença da nova Apple de Steve Jobs, numa comunidade de misfits e artistas wannabe, de desenvolvedores experientes dos anos 70 a 90 que queriam voltar a se expressar com código. Claro que isso atraiu a atenção de muitos agilistas da época, incluindo metade dos signatários do manifesto. E mais do que isso: chegamos ao fim da depressão do crash das ponto coms em 2001, estava na hora de recomeçar a criar produtos e o Basecamp e o estilo Getting Real da 37signals se tornou o exemplo de como fazer isso. Aliás, o Getting Real que aqui no Brasil chegamos a fazer uma tradução oficial em português também e que se tornou o manifesto da nova geração de empreendedores de produtos de tech startups, muito antes do surgimento de Lean Startup.

E claro, todo mundo deu risada de Ruby on Rails, um framework não-enterprise, que não era infinitamente configurável, que vinha com defaults estranhos como MySQL em vez de suportar Oracle, que não tinha suporte pra Windows, que te obrigava a apagar os arquivos de testes, porque ninguém queria fazer testes no mundo Java, e ainda usando Macs??? Profissionais usam Windows XP, lógico! E ainda usando essa linguagem bizarra chamada Ruby que diz que é orientada a objetos mas não tem tipos estáticos como toda linguagem profissional como Java ou C#. Lógico que ia ser um fracasso. (gandhi)

Ah, e você não gosta do Jira hoje? Imagina como o Jira era mil vezes pior em 2004, e como todo mundo ria que algo no estilo Basecamp nunca seria usado no mundo enterprise. Se ainda não entendeu a gravidade da situação da época foi em 2003, 1 a 2 anos antes que o Java Server Faces, o JSF tinha acabado de ser lançado e todo mundo estava adotando aquele lixo, que era um ASP.NET WebForms piorado pra Java! Ah sim, pra quem gosta de falar em frameworks baseados em componentes e orientados a eventos, ASP.NET e JSF. (joinha)

A partir de agora, apertem os cintos, vamos fazer uma longa timeline, de uns 7 anos! Eu não vou por temas e sim em ordem cronológica. Vocês assistiram os demais videos do meu canal né? Porque agora muita coisa que eu disse neles vai se encaixar.

2004 foi um ano especial. Em 1o de Abril o Gmail foi lançado, demonstrando um dos primeiros single page applications e o poder de tecnologias como Ajax. Em 24 de julho saiu o primeiro beta público do Ruby on Rails versão 0.5. Em 2 de Outubro o DHH apresenta o Rails pela primeira vez numa RubyConf, que na época estima-se que tinha umas 60 pessoas na platéia. Três dias depois a O’Reilly promove a conferência Web 2.0 onde o termo foi cunhado pela primeira vez. Em 10 de dezembro o Google lança aquela funcionalidade que você usa todo dia e nem pensa muito, o Google Suggest, que vai te dando sugestões à medida que você vai digitando os termos de pesquisa, usando XMLHTTP e de novo demonstrando o poder do AJAX e comunicação assíncrona em tempo real. Todo mundo queria fazer a mesma coisa.

2005 não ia ficar pra trás. Logo no 1o dia do ano, a Robot Co-op lança o 43 Things; o site é um early adopter de Ruby on Rails. Em 8 de fevereiro o Google Maps lança pra Internet Explorer e Firefox, redefinindo o nível de interação possível em um web browser. Essa era a época que o Google tava literalmente on-fire lançando um app atrás do outro. E alguns dias depois, em 15 de Fevereiro, Jesse James Garrett cunha o termo Ajax para descrever as novas aplicações web ricas como Flickr, Google Suggest, ou Google Maps. No dia seguinte o Rodrigo Caffo cria a primeira mailing list brasileira de Rails, a Rails-BR.

Em março o britânico Peter Cooper começaria o blog Ruby Inside, o melhor blog pra se manter atualizado no mundo Ruby e Rails e que daria origem anos depois ao conjunto de mailing lists como JavaScript Weekly, Ruby Weekly, RubyFlow, Frontend Focus, Node Weekly, Golang Weekly e vários outros que centenas de milhares de desenvolvedores usam até hoje e se mantém com um dos melhores canais pra se manter atualizado. Em 7 de Abril tivemos outra revolução, o Lançamento inicial do sistema de controle de versão distribuída git. E na sequência, em 2 de Julho, o DHH grava o demo do blog de 15 minutos, demonstrando a velocidade do desenvolvimento rápido com Rails. Esse video se torna viral e todos os sites de todas as linguagens começam a notar a presença desse alien.

E não demorou muito, também por volta de julho tivemos o lançamento inicial do Groovy on Grails, um framework inspirado no Rails pra recém lançada linguagem Groovy que roda na JVM. Foi o primeiro de muitos clones de Rails que apareceriam nos próximos anos. Daí ainda em julho, no dia 7, é lançada a biblioteca javascript script.aculo.us 1.0.0 que possibilita um novo nível de interação em páginas web, tornando fácil adicionar os efeitos de estilo Web 2.0 nas suas aplicações. No dia 21 de Julho, o framework Django é lançado depois de ficar em desenvolvimento por mais de 2 anos. Em 4 de Agosto o livro Agile Web Development with Rails, primeira edição foi publicado pela PragProg, novamente escrito pelos agilitas Dave Thomas e Andy Hunt. E foi em outubro de 2005 que o indiano Satish Talim inaugurou o curso online pra iniciantes RubyLearning que está ativo até hoje e foi importante naquela época.

De curiosidade, em 3 de Dezembro teve a Conferência Snakes and Rubies que levou os criadores do Django e do Rails (video) pra discutir sobre frameworks web e os caminhos diferentes que eles tomaram. Naquela época ainda não estava claro quem ia ganhar, mas os motivos que eu já citei antes devem deixar claro porque um foi muito diferente do outro apesar de terem começado parecido. 10 dias depois o Rails 1.0 é lançado. (…) Nós tínhamos alguns dos melhores escritores de blog daquela geração, um dos melhores sempre foi o Ilya Grigorik do blog Igvita e que hoje é engenheiro de web performance do Google. Seus artigos sobre performance no Ruby e Web em geral influenciaram toda a nossa geração e vale a pena reler ainda hoje. Seu primeiro blog post foi ao ar em 28 de dezembro. E assim acaba 2005!

As coisas começam a esquentar em 2006. Primeiro, em março, Jamis Buck que entrou pra equipe Core do Rails renomeia seu projeto SwitchTower pra se tornar o que conhecemos como Capistrano e a forma inédita de automatizar deployment de projetos em máquinas de produção orquestrando via SSH, e essa ferramenta inspiraria diversas outras como o Fabric e Ansible de Python que vieram depois dele. Ainda em março, no dia 21 o Jack Dorsey posta o primeiro tweet: “just setting up my twttr”. 2 dias depois o Eustáquio Rangel lança o primeiro livro de Ruby no Brasil e um mês depois em 5 de Abril eu escrevo meu primeiro post no que viria depois a se tornar o blog AkitaOnRails.com.

Em 22 de Junho acontece a primeira RailsConf em Chicago. E já em 30 de Junho o rubista Hamptom Caitlin sobe o primeiro commit do SASS e inicia uma nova era de meta-linguagens pra tornar possível ser capaz de codar decentemente em linguagens chatas como CSS. Também já em 5 de Julho surge o JRuby 0.9, uma versão de Ruby que roda em cima da JVM e já consegue rodar Rails. Charles Nutter e Tom Enebo continuam firmes e fortes mantendo a linguagem até hoje.

Muito antes de termos a onda de cursos online que temos hoje, a comunidade Ruby on Rails foi pioneira em mostrar como cursos de qualidade poderiam ser feitos e foi Geoffrey Grosenbach que iniciou isso com seu Peepcode, que anos depois seria adquirida pela Pluralsight. Muita gente, incluindo eu, aprendemos muito nos cursos do Geoffrey.

Pra continuar os lançamentos revolucionários, em 25 de Agosto a Amazon Web Services, ou AWS, lança o Elastic Compute Cloud (EC2) e inicia de fato a Era do “Cloud Computing” como conhecemos hoje. No dia seguinte, em 26 de Agosto o John Resig lança o então adorado e hoje denegrido jQuery. Pouco mais de um mês depois em 6 de Outubro meu primeiro livro “Repensando a Web com Rails” saiu da gráfica, o primeiro de Rails publicado no Brasil. Três dias depois em 9 de Outubro, o Ronaldo Ferraz lança o primeiro tutorial de Rails no Brasil. E ainda em Outubro surge o primeiro framework concorrente de Rails escrito em Ruby, o Merb 0.03 que significa (“Mongrel+Erb”).

(video jobs iphone)

E falando em 2007, logo no começo do ano em 9 de Janeiro o mundo da tecnologia recebe um novo marco: o lançamento do primeiro iPhone. Poucos dias depois em 18 de Janeiro é lançado o Rails 1.2 lançado com o lendário RESTful resources e o mundo finalmente aprendeu que HTTP não é só GET e POST e finalmente os outros verbos ganharam uso. Foi neste ponto que mundo Web começou a proliferar a idéia de APIs REST como Roy Fielding publicou no ano 2000 definindo REST. Ruby on Rails se tornou o gold standard em APIs. Em 20 de Fevereiro o Christian Neukirchen define a interface Rack, inspirado pelo Web Service Gateway Interface ou WSGI de Python que foi definido na famosa PEP 333 de 7 de dezembro de 2003.

Em 4 de março o saudoso Ryan Bates lançou o primeiro episódio do videocast chamado Railscasts. Assim como Geoffrey da Peepcode ele criou dezenas de videos curtos sensacionais e muito bem produzidos e editados. Novamente mostrando como videos de programação poderiam ser bem feitos e ensinando toda uma geração de Railers, incluindo eu mesmo. Infelizmente ele parou por volta de 2013. Eu diria que o sucessor espiritual do Ryan hoje é o Avdi Grimm com seu também excelente RubyTapas, cujo primeiro episódio foi ao ar em 24 de setembro de 2012, então ele realmente é quase uma continuação do Railscasts só que voltado ao Ruby em si. Eu recomendo que vocês assinem.

Na renascença das tech startups, começaram a surgir as famigeradas redes sociais, a versão moderna do muro das lamentações. Na melhor fase tivemos Orkut, Friendster e MySpace que já estavam saturados mas o público pedia por mais. Facebook estava só começando a aparecer, não lembro se nesse ano já tinha aberto no Brasil. De repente um grupo que tinha crescido no mundo de blogs com a Odeo resolveu criar um modelo experimental de micro-blogging, que você podia enviar posts via SMS, e por isso tinha o limite de 140 caracteres. E eles resolveram batizar esses micro-posts de tweets, inaugurando também a era de nomes bizarros pra startups. E, mais importante, escolheram Ruby on Rails pra implementar. Claro, ser inspirado pelo framework do blog de 15 minutos pra fazer uma plataforma de micro-blogging fazia todo sentido. Eu abri minha conta em 2007 se não me engano.

Agora, em Abril de 2007 inicia-se a maior infâmia da história até então, a famigerada controvérsia do “Rails não Escala” iniciada por uma comunicação mal feita do Alex Payne, do próprio Twitter. Lembram que eu expliquei que Twitter foi criado como uma plataforma de micro-blogging? Pensa se o Twitter tivesse sido programado em cima do Wordpress. Só que 2 anos depois ele deu certo e milhões de pessoas começaram a usar, só que o uso mudou. Em vez de ser micro blog posts, a plataforma começou a ser usada como um sistema de comunicação, ou seja, de broadcast de mensagens. Claro que nem Ruby, nem PHP, nem Python, aguentariam isso. O problema nunca foi a linguagem, foi a arquitetura.

Só existia uma arquitetura conhecida na época que suportaria o broadcast massivo de mensagens, e se chamava Erlang. Mas ninguém queria ter que usar a sintaxe do Erlang, e por sorte o Odersky tinha acabado de lançar o Scala, com o framework Akka, que copia a arquitetura de atores do Erlang e possibilita usar esse sistema em cima da JVM. Ou seja, o Scala era a coisa mais próxima do Erlang que se tinha e, claro, fazia sentido mudar essa parte do back-end. Não é que o Rails não escala, nenhum outro framework em nenhuma outra linguagem ia escalar. Hoje em dia, pra esse cenário seria Elixir. Essa controvérsia seguiria o Rails por anos (e finalmente nos livramos disso, afinal se você acha que o Rails não escala, olhe pro GitHub, até hoje feito em Rails e usando a última versão)

Em 18 de Maio de 2007 o mundo de testes nunca mais seria o mesmo. Já expliquei sobre a importância de desenvolvimento com testes e como isso foi um gancho importante pra ganhar o apoio dos agilistas ao Rails, mas foi neste dia que o lendário RSpec foi lançado, baseado nas experiências de Steven Baker desde 2005 e com a ajuda de Dave Astels, Aslak Hellesøy que depois criaria o Cucumber, iniciando a era de Behavior Driven Development, e claro o simpático David Chelimsky que a comunidade brasileira adorou conhecer quando eu trouxe nas duas primeiras Rails Summit Latin America em 2008 e 2009. Todos os frameworks de teste na maioria das linguagens modernas que você conhece hoje como o Chai do Javascript é descendente direto do RSpec.

Seguindo na linha dos clones de Rails, ainda em maio de 2007 surge o Framework Play para Java. Em 16 de Maio eu iniciei meu primeiro emprego oficial como Railer full-time na Surgeworks, uma pequena consultoria de Utah. Mais pro fim vou falar da pessoa que se arriscou em contratar um brasileiro numa época em que isso era muito raro. Eu trabalhei remoto por um ano mais ou menos, onde eu finalmente comecei a programar em Rails profissionalmente, aos 30 anos. Só pra relembrar: eu deixei de ser sênior de Java e SAP e voltei a ser júnior e ganhar como júnior.

Por volta de Julho outro nome importante apareceu, o grupo do RailsEnvy com Gregg Pollack e Jason Seifer que contribuíram muito no estilo diferentão dos hipsters de Rails dessa época. Eles aproveitaram a campanha Get a Mac que a Apple agressivamente publicou como comerciais de TV entre 2006 e 2009, no auge da dominância da Apple do Zeitgeist, os famosos comerciais “Hello I’m a Mac ….

(comercial mac vs pc)

Então em 2007 Gregg e Jason fizeram diversos clones desses videos com o mesmo princípio com Rails pra tornar mais divertido a forma como a gente via as demais tecnologias diferentes de Rails que até aquele momento ainda estavam vivendo no passado. E eles fizeram vários videos começando com o famoso Hi, I’m Ruby on Rails … (comercial)

Vocês podem ver os videos no canal de YouTube do Gregg Pollack que vou deixar linkado abaixo. Com o tempo o Gregg e Jason acabaram se separando, o Gregg montou a consultoria EnvyLabs e em paralelo, seguindo nos passos de Geoffrey Grosenbach e Ryan Bates montou o famoso Code School, com uma grade mais estruturada pra ensinar Ruby on Rails e outras novas tecnologias. E foram eles que criaram o conceito de Rails for Zombies que depois outras comunidades, como Python, copiaram também. Não existia comunidade que gerava mais conteúdo técnico do que a de Rails naquela época. O Rails for Zombies foi o primeiro curso do Code School que foi lançado em 2010. E o negócio foi vendido em 2015 também pra PluralSight onde vocês ainda podem achar os cursos.

Em 4 de Outubro tivemos o lançamento inicial do microframework Sinatra, também escrito em Ruby mas que não tinha o objetivo de competir com o Rails, ele era mais focado em micro-aplicações ou mesmo pra ser micro-serviço de APIs; ele é largamente copiado em outras linguagens até hoje. Ainda em outubro, no dia 19 finalmente os rubistas Chris Wanstrath e Tom Preston-Werner começam a trabalhar no GitHub, literalmente de um Starbucks. O Chris tinha o blog Err the Blog e começou criando bibliotecas de Ruby que conseguiam interfacear com Git.

Também em outubro, no dia 22 foi a primeira vez que eu organizei um evento, em São Paulo, o RejectConf SP que teve muitos dos nomes do Ruby brasileiro que você reconhece até hoje como Carlos Brando (CTO do Enjoei), Danilo Sato (ThoughtWorks), Fabio Kung (que foi do Heroku por muitos anos e agora está no Netflix), Vinicius Teles (da HE:Labs), Carlos Villela (que foi da ThoughtWorks por muitos anos e foi pra DigitalOcean), George Guimarães (Plataformatec) e mais. A Caelum do Paulo Silveira estava lá também ajudando com o coffee-break da galera. Vocês estão vendo como as coisas estão acontecendo muito rápido, todo mês, às vezes toda semana estava saindo alguma coisa que influenciaria o mercado pelos próximos anos. Como eu disse no começo, 2004 marcou o início de uma nova era pra Web.

(2008) E pra não quebrar a tradição do ano iniciar com alguma coisa, já no primeiro dia de 2008 tivemos nosso primeiro grande RubyDrama. Era engraçado que antigamente não existia dramas em nenhum lugar, com frequência. Era tão raro na real que quando acontecia a gente chamava de RubyDrama. Notem que dramas só começaram a acontecer com frequência com o surgimento de plataformas como o Twitter. No caso do Ruby em 2008, Zed Shaw, o criador do Mongrel que foi o primeiro servidor de aplicações pra Rails, fez uma declaração bombástica de sua saída, chamando a comunidade Ruby de ghetto. Isso reverberou por um algum tempo. E ele não estava totalmente errado, só que ele não sabia jogar o jogo, o Zed é o tipo de cara tecnicamente excepcional mas de cabeça quente. Mas, todo drama que parece tão importante pra você hoje, alguns anos depois, ninguém mais nem se lembra, e o Mongrel foi rapidamente substituído por outros servidores de aplicação como o Thin, Passenger, Unicorn e depois o Puma que usamos hoje.

Mais importante do que isso, nesse mesmo dia 1o de Janeiro de 2008 foi quando o Heroku recebeu seu primeiro investimento seed de USD 20 mil da Y/Combinator. Esse foi o mesmo ano que eu participei da minha primeira Railsconf nos Estados Unidos. Lá eu conheci o James Lindenbaum um dos fundadores do Heroku. Eles estavam com um estande no evento e ninguém mais se lembra disso mas a primeira versão do Heroku era pra ser uma IDE Web pra desenvolvimento de software. Só que eles viram que isso não ia rolar naquela época. Pense que 10 anos atrás ainda era muito difícil imaginar coisas como o Electron que usamos hoje, o Google ainda não tinha começado a otimizar o Javascript, acho que nem tinha o V8 ainda. Então eles tiraram essa idéia mas ficaram com a segunda parte que era onde os apps iam rodar, a infraestrutura de containers que surgiria muito antes do Docker e que inaugura o primeiro PaaS ou Platform as a Service. Aliás, é disso que nasce as boas práticas do Doze Fatores ou 12 factors pra escalabilidade em 2007, escrito por Adam Wiggins que foi co-fundador do Heroku também. E, claro, Ruby on Rails foi o primeiro framework que estava compatível com os Doze Fatores.

Se você é de Elixir, pra efeitos históricos vale relembrar o projeto Reia de Tony Arcieri, que eu recomendo que vocês sigam porque ele manja muito sobre segurança e hoje em dia Rust. Pra dar perspectiva, o primeiro commit do Elixir do José Valim foi em 9 de Janeiro de 2011. O primeiro commit do Reia é de 21 de março de 2008 e ele é basicamente o Elixir uns três anos antes: uma nova linguagem muito mais próxima de Ruby que compila em bytecodes que executam na VM Beam do Erlang. No fim o Tony perdeu o interesse no projeto e foi fazer outras coisas como a biblioteca Celluloid pra Ruby que hoje é usado pra abstração de concorrência, seja de threads ou I/O assíncrono, inclusive hoje é dependência no Rails.

Já em 2 de Abril o desenvolvimento do Rails sai de Subversion e move seus repositórios pro GitHub, dando credibilidade pra essa ferramenta chamada Git que quase ninguém tinha ouvido falar fora dos grupos de Linux e desenvolvimento do kernel. Por muito tempo 90% dos repositórios que tinha no GitHub eram projetos Ruby e Rails, e todo mundo de fora começou a ficar interessado em testar. Alguns dias depois, em 10 de Abril o GitHub sai do beta e lança publicamente. Hoje em dia vocês nem pensam e basicamente adotam Git, mas nessa época além de Subversion, no mundo open source ainda tinha gente que usava CVS mesmo, e a nova geração ainda estava entre coisas como Mercurial ou Bazaar. Em 14 de Abril foi quando José Valim mandou seu primeiro commit pro Rails, foi o começo de 2 anos de trabalho que o tornou membro do grupo Rails Core em 2010.

Nesse ano eu estava tendo que me virar. Em Junho eu tinha saído da Surgeworks e entrei na Locaweb. Embarquei pra Portland, no Oregon, pra Railsconf com a missão de conseguir integrar com a comunidade de lá e organizar o primeiro grande evento de Rails no Brasil, na América Latina na real. Com cerca de 3 meses só pra organizar tudo do zero, em 15 de Outubro tivemos o Rails Summit Latin America 2008, no Auditório Elis Regina do Anhembi em São Paulo. Deu bastante trabalho mas os nomes que eu consegui trazer muitos vão reconhecer até hoje como Chad Fowler, um dos rubistas originais no Ocidente, fundador da Rubyconf, meus amigos Ninh Bui e Hongli Lai da Phusion que desenvolveram o Passenger, um dos servidores de aplicação tipo o Puma de hoje, o David Chelimsky que contribuía no projeto RSpec e Cucumber, o Chris Wanstrath, fundador do GitHub, o Dr. Nic, o Obie Fernandez e mais. Ninguém achava a) que um evento desses fosse possível, nem b) que ele seria consistente e duraria quase 10 anos! Nessa primeira edição acho que já conseguimos juntar mais de 400 pessoas.

Outro acontecimento que vale lembrar nesse ano foi em 2 de setembro quando o Google finalmente lança o venerado e hoje temido navegador Chrome junto com a engine de Javascript mais importante de todos os tempos, o controverso V8, que vai dar início ao atual ecossistema Javascript. Pare um instante pra considerar isso se você for iniciante. A Apple se inspirou no Konqueror do KDE, fez fork e transformou o componente KHTML no WebKit. Daí o Google tinha contratado engenheiros do Firefox alguns anos antes mas eles nunca se acharam na posição de empurrar um novo navegador, mas chegaram num ponto que fez sentido começar com o WebKit como fundação e, no melhor estilo Google, fazer um deles parecido a partir de um fork em 2013.

Pra fechar bem o ano, em 23 de Dezembro tivemos o merge dos projetos Rails e Merb e a equipe do Merb se junta ao Rails core team. Lembram o RubyDrama do começo do ano do Zed Shaw? Ele tinha meia razão, sempre existiu um grupo fechado pra discutir o desenvolvimento do Ruby on Rails, e isso não é nenhum problema, o DHH sempre quis ser como um Steve Jobs, ele controla o Rails com mãos de ferro, e não só o código mas tudo relacionado ao “produto” Ruby on Rails, como a marca, o nome, os eventos e tudo mais. Certo ou errado, ele owna as decisões em vez de se esconder atrás de um comitê. Isso é integridade conceitual que todo projeto precisa: um ditador benevolente. Gostem ou odeiem, foi o que manteve o Rails intacto até hoje.

Mas deixa eu explicar esse episódio, só pra ter registrado. Durante essa bolha de interesse explosivo em cima de Ruby on Rails, alguma empresas foram fundadas pra suportar a infraestrutura de startups que cresciam do nada como Twitter ou GitHub, especialmente depois da famigerada controvérsia do Rails não escala do Alex Payne. Uma dessas foi a Engine Yard, que estava competindo com a AWS e Rackspace. Pense que em 2008 a AWS só existia fazia 2 anos e nem todo mundo ainda tinha entendido essa idéia de máquinas virtuais voláteis cobradas por uso. Ainda dava pra pensar em competir com a AWS. A Engine Yard foi fundada por pessoas excepcionais, em particular o EZRA ZYGMUNTOWICZ, super gente boa que eu conheci em 2008 também. Ele era genial, tanto como programador, como quanto infra.

Por exemplo, na época ele criou um sistema de deployment em máquinas físicas usando o protocolo Jabber que se usa em instant messager. Pensa você abrir faz de conta, um whatsapp de hoje em dia, e falar com sua infraestrutura e mandar ordens como atualizar as máquinas ou deployar apps, em 2008! Além disso ele foi o único que enxergou como fazer um concorrente de verdade pro Ruby on Rails, dado sua experiência com hardware e otimização de Linux, ele começou fazendo patches no Rails e no Mongrel e eventualmente criou o Mongrel ERB, um software que tira o Rails da equação. Em vez de fazer só mais um micro-framework, ele resolveu competir pau a pau e fez um Rails que muitos argumentariam que era melhor, esse foi o Merb.

A equipe que a Engine Yard montou contou com programadores como o Yehuda Katz e Carl Lerche pra acelerar o desenvolvimento do Merb. Tudo isso enquanto ele estava montando um data center, carregando servidores nas costas, montando rede, e ajudando outras tech startups a escalarem seus projetos em Rails. Então eles rapidamente criaram uma excelente reputação. Eles eram um dos maiores patrocinadores da Railsconf. Só que o erro foi que eles começaram a evangelizar o Merb agressivamente demais. Tipo, eles iam nas Railsconf falar mal do Rails e ofereciam o Merb como opção. Eu disse que o DHH queria ser o Steve Jobs? Saibam que a Railsconf só pode acontecer com o aval dele, porque a marca Ruby on Rails é trademark do DHH e o evento também. Imagina se na Macworld aparecesse um palestrante falando que Mac é um lixo, na frente do Steve Jobs. …. Pois é, o DHH ficou furioso com isso e eu soube de uma conversa dele com o Tom Mornini, um dos co-fundadores e na época CTO da Engine Yard. Eu estava online pouco depois que isso aconteceu falando com o Matt Aimonetti, outro core developer do Merb na época e o autor do post de reconciliação anunciando que o Merb seria mergeado no Rails.

Eu não estava fisicamente na sala ouvindo, então não me citem, mas do que eu ouvi foi um ultimato do DHH pro Tom Mornini. Ou vocês páram com essa palhaçada de falar mal do Rails, na Railsconf, que inclusive é o seu sustento já que vocês atendem clientes de Rails, ou vamos “ter problemas”. Isso seria péssimo problema de relações públicas num estágio onde eles provavelmente ainda estavam no vermelho, procurando mais investidores e mais clientes. Então no final a Engine Yard cedeu à pressão e anunciou parar o Merb. Foi assim que o Yehuda Katz, Carl Lerche e Matt Aimonetti entraram pro grupo Rails Core Team e foi assim que o Merb morreu e nasceu o Rails 3.0. ufffff

(2009) Com toda essa controvérsia “resolvida” por enquanto, podemos começar o próximo ano, 2009 em 16 de Março com o lançamento do Rails 2.3; agora sendo uma aplicação Rack. Finalmente, só agora, 7 anos depois do lançamento do framework baseado em I/O assíncrono Twisted do Python, em 27 de Maio temos o lançamento inicial do Node.js graças ao V8 lançado um ano antes. Ela permite que programadores escrevam Javascript client side e server side, pela primeira vez desde o falecido Netscape Livescript nos anos 90. E só pra colocar um pé do Rails até nisso, Ryan Dahl mesmo disse que foi inspirado pelo parser do Mongrel de Zed Shaw pra fazer o Node.js.

Em 13 de Dezembro, Jeremy Ashkenas sobe o primeiro commit do Coffeescript, um dos primeiros transpilers pra tentar tornar programar em Javascript algo mais agradável. Lembrando que nesta época ainda não tínhamos nem sinais do ES6 e Javascript pré-ES6 era um pesadelo de se usar. Na época o Coffeescript era excelente pra se trabalhar, ele inventou o conceito de fat arrows pra funções anônimas, interpolação de strings e muito mais que hoje você tem no ES6, então é muito fácil odiar o Coffee hoje sem saber como era em 2009. O Coffeescript serviu seu propósito em ajudar a evoluir o Javascript.

Virando mais um ano, por volta de abril de 2010 Steve Jobs publica o prego no caixão do Adobe Flash com o artigo Thoughts on Flash e sedimenta o caminho para HTML 5 + CSS 3 + Javascript não só em dispositivos móveis mas também em desktops. O Flash se tornou um morto-vivo desde então. A intenção original de Jobs era empurrar o então melhor navegador com o então melhor engine Javascript que era o Safari no Mac e agora no iPhone como uma plataforma para criar aplicações web. Eu diria que foi Jobs que sem querer tornou mainstream o conceito de Single Page Apps e o primeiro framework javascript a oferecer isso foi o hoje defunto SproutCore que deixou descendente na forma do atual Ember, que foi criado pelo mesmo Yehuda Katz que trabalhou no Merb da Engine Yard e também no Rails 3.0 e resolveu o problema de dependências do Ruby com a introdução do Bundler, que se tornaria referência pra todas as ferramentas de gerenciamento que vieram depois dele como Hex do Elixir, Cargo do Rust, Npm e Yarn no Javascript e assim por diante.

Esse negócio de dois frameworks se unificarem e só sobrar um, como o próprio Yehuda lembrou na época, já tinha acontecido outras vezes. No mundo Java o Struts 2 foi um merge com outro framework, o WebWork que se vendia como “Struts feito direito”. Em 1o de agosto de 2010 é lançado o Rails 3.0 com contribuições do Merb core team; um ano desde o lançamento do Rails 2.3. O que sobrou da comunidade Merb viu as promessas de um caminho de migração e a idéia de que o Rails se tornaria mais próximo das idéias do Merb se esvair. E esse foi o fim dessa história.

2011 foi outro ano interessante, em 12 de Julho o Criador do Ruby, Yukihiro Matsumoto (Matz) e outros membros do Ruby Core, são contratados pelo Heroku. Em 31 de Agosto o Rails 3.1 é lançado e o jQuery substitui o antigo Prototype como padrão. E em 19 de Setembro eu anunciei a criação da minha primeira empresa de desenvolvimento de software própria, a Codeminer 42. Aqui se iniciaria uns 4 anos de pesadelo na minha vida, vocês não tem idéia de como doeu criar uma empresa do zero, bootstrapped, sem investimento externo, pra crescer de forma sustentável e ser lucrativa. Felizmente já faz uns 3 ou 4 anos que as coisas tão super bem, graças a de … graças aos esforços incessantes de quem trabalhou nesses últimos anos na empresa.

Finalmente, em Novembro de 2011 outro produto importante foi lançado, o Travis-CI, fundado por rubistas como Josh Kalderimis, Konstantin Haase, Sven Fuchs e outros, em Berlin, na Alemanha. Eles conseguiram finalmente produtificar o conceito de integração contínua. Não só isso como ofereceram um serviço gratuito pra projetos open source que se integra diretamente no GitHub e pela primeira vez projetos de software livre tinham a opção de demonstrar seu nível de testes diretamente na primeira página dos repositórios. Vocês podem ver que nós rubistas originais levávamos testes realmente a sério.

Só de bônus, foi também em 2011 mas não achei a data que Bryan Helmkamp criou o CodeClimate pra automatizar ferramentas de análise de código como Rubocop, Flay, Brakeman e outros, se integrando ao GitHub pra demonstrar como anda a saúde de nosso código. A partir desse ponto fomos refinando mais e mais nosso cinto de utilidades de qualidade de código Ruby e demos o exemplo pra todas as outras comunidades. Nenhum até hoje conseguiu chegar no mesmo nível obsessivo de qualidade que nós das primeiras gerações de Railers quisemos alcançar.

Vou parar a cronologia por aqui, veja que estou parando 8 anos atrás, mas acho que vocês podem ver como os acontecimentos do mercado em geral e do Ruby on Rails a esta altura já tinham mudado o mundo de desenvolvimento de software. Novas linguagens começaram a surgir, muitos influenciados por Ruby. Novos frameworks começaram a surgir, muitos influenciados por Ruby on Rails. O fluxo de trabalho havia sido já fundamentalmente mudado graças à adoção das práticas ágeis de extreme programming, Os conceitos de produtos Web 2.0, adoção de SaaS, PaaS, mundo cloud e tudo mais derivou dessa geração de Ruby on Rails entre 2004 e 2011. E em 2011 ainda estamos 2 anos antes do Docker ser lançado pela primeira vez, essa história é longa.

Lá no começo, em 2008 eu comecei a entrevistar diversos rubistas e outros desenvolvedores e publiquei no meu blog. Se você é de Microsoft vai saber quem é Scott Hanselman, leia a entrevista no blog. Adrian Holovaty o criador do Django de Python? Tá no blog também. Criadores de conteúdo como Geoffrey Grosenbach que na época tocava o Peepcode e o Peter Cooper que na época tocava o Ruby Inside? Tão no blog também. Depois da controvérsia que o Alex Payne do Twitter causou com o Rails não Escala eu entrevistei um dos primeiros engenheiros do Twitter, o Blaine Cook, confira no blog. Membros fundadores do Ruby Central e os primeiros rubistas, Chad Fowler, David Black depois Evan Phoenix do projeto Rubinius e Ruby Specs, tão no blog. Rails Core Team Alumni como Jamis Buck e Josh Peek, também tão lá no blog. Enfim, vou deixar a página com as entrevistas linkadas nas descrições abaixo.

Durante esse período entre 2008 e 2016 eu tive a oportunidade de trazer muitos dos principais nomes pra cá incluindo os fundadores do Ruby Central como Chad Fowler, David Black e Rich Kilmer, depois Evan Phoenix. Trouxe gente do Rails Core da época como Matt Aimonetti, Aaron Petterson que é o Tenderlove. Fundador do GitHub Chris Wanstrath, depois Scott Chacon. O Konstantin Haase do Sinatra e Travis-CI. E na última tivemos gente do Ruby Core Team do Japão com a presença de Akira Matsuda. E falando em última, foi no dia 25 de setembro de 2016, que depois de 10 anos organizando eventos de Ruby, eu decidi pendurar as chuteiras.

Como tudo que eu faço fora do meu trabalho principal, eu nunca lucrei nada com os eventos. Vamos dizer que como gerador de conteúdo eu dou um péssimo empresário, porque meu primeiro livro de Rails eu escrevi sem ganhar um centavo porque abri mão dos royalties pra baratear o custo, o objetivo era fomentar o mercado. O blog eu até experimentei colocar ads por um tempo mas era muito feio então desisti e nunca monetizei. Os podcasts que eu fazia com Carlos Brando ou o Rosa nunca monetizei. A Rubyconf eu nunca tive nenhuma compensação financeira. E agora fazendo videos, eu também não monetizo.

Faz mais de 10 anos que eu gero conteúdo de graça e espero poder continuar fazendo isso. E eu não faço isso porque eu sou um cara legal, pelo bem disso ou pelo bem daquilo. Eu só faço assim porque eu quero. O dia que eu não puder, eu páro. Na minha cabeça eu sempre tive uma noção que se meu conteúdo fosse atrelado a um incentivo financeiro, isso ia me comprometer demais. Isso já aconteceu antes, quando tinha patrocinador ou grupos externos envolvidos. E não tem nada que me irrita mais do que eu não poder falar alguma coisa porque certos grupos não iam gostar. Por isso eu prefiro pagar as coisas do meu bolso pra nunca ser usado como plataforma pros outros.

Quando anunciei minha aposentadoria da Rubyconf Brasil, eu achava que finalmente ia conseguir passar um ano sem ter que pensar em eventos… ledo engano. Em dezembro de 2016 uma idéia apareceu do nada na minha cabeça, eu juro que tentei tirar essa idéia da cabeça, mas aí eu e meu sócio começamos a montar a conferência experimental The Conf, mas isso é história pra outro dia. Agora em 2019 estamos na 3a edição da The Conf, crescendo um passo de cada vez, como aconteceu com a Rubyconf Brasil. Um dia eu juro que páro de fazer eventos. E, de novo, eu quero que o evento seja o mais independente possível, basicamente eu e meus sócios pagamos praticamente tudo.

Essa história pra mim começou numa quarta-feita a noite em abril de 2006 quando eu me dei conta que quase ninguém no Brasil inteiro tava dando a mínima pra Ruby on Rails ou sequer sabia o que era isso. Eu nunca tinha visto algo assim antes: a tecnologia certa, com os conceitos certos, tudo pronto, e todo mundo ignorando. Eu tinha duas escolhas, me mudar pra São Francisco e tentar a vida em tech startup de Rails, ou tentar começar do absoluto zero no Brasil. Obviamente escolhi a segunda opção e foi assim que eu comecei, com zero seguidores, zero views, zero empresas e zero emprego.

Preciso agradecer muito meu primeiro chefe de Rails, o Carl Youngblood que achou meu blog lá no começo e me mandou uma oferta de trabalho remoto pra Surgeworks. A coincidência é que o Carl foi missionário no Brasil. Ele é mórmom de Utah. E ele fala português brasileiro quase perfeito, com sotaque brasileiro e tudo, foi muito bizarro ver um gringo falar melhor português do que eu falo inglês. E foi assim que me tornei o primeiro brasileiro da equipe e pra onde eu levei diversos nomes que você deve conhecer hoje como Carlos Brando, o Rodrigo Kochenburger que mencionei no começo, o Marcos Tapajós do Rio de Janeiro, o Renato Carvalho de Brasília que depois fundou a Startaê e vários outros.

Com a missão de evangelizar Ruby e Rails no Brasil eu embarquei numa jornada de palestras por todo o Brasil, fui pra Natal, Teresina, Brasilia, Fortaleza, Campos no Rio, Xanxerê, Londrina, Porto Alegre, Curitiba, Salvador, Rio de Janeiro, São Carlos, Campo Grande, além de ter tido a oportunidade de fazer amigos como o Nihn e Hongli da Phusion na Railsconf de Portland em 2008, ter ido pra Las Vegas pela primeira vez na RailsConf 2009, ter conseguido palestrar pela primeira vez num evento internacional na RailsConf 2010, onde eu conversei pela primeira vez com o DHH, com o Bob Martin e muitos outros, e de lá fui palestrar em Buenos Aires na Locos x Rails, em Moscow, em Amsterdam, em Tel Aviv em Israel que certamente foi um dos países mais fascinantes que eu já conheci, e finalmente em Tokyo em 2011 onde eu pude conhecer o grupo por trás do desenvolvimento do Ruby, incluindo seu criador, o Matz, que assistiu minha palestra sobre como a comunidade de Ruby cresceu no Brasil. Ao longo de 10 anos eu devo ter dado umas 200 palestras no Brasil e no mundo, foi uma jornada absurda que eu não imaginava que pudesse acontecer naquela quarta feira a noite em 2006.

Não podia deixar de relembrar os rubistas que nós perdemos. O Jason Seifer, que foi parceiro de Gregg Pollack no RailsEnvy nos deixou em abril de 2017. O excelente blogueiro de Ruby e criador de bibliotecas como o resource controller original, anterior ao inherited resources nos deixou 3 dias antes de acabar 2014. Ezra Zygmuntowicz nos deixou em Dezembro de 2014. O simpático e saudoso Jim Weirich que inspirou toda uma geração a se importar com testes nos deixou também em 2014, em fevereiro. 2014 foi um ano ruim onde, por diversas razões, perdemos excelente pessoas na nossa comunidade.

Falando em Jim Weinrich se você gosta da linguagem Ruby devia se exercitar num de seus legados, o site Ruby Koans com diversos exercícios diferentes do que vocês está acostumado e que vai te fazer pensar bastante. E na mesma linha temos o Ruby Quiz do James Edward Grey II com mais dezenas de exercícios. São excelentes opções pra você que quer juntar seus amigos pra aprender Ruby, como desenvolver com TDD, no formato de Dojo.

Ruby on Rails já completou 15 anos. Foi uma década e meia de mercado e até hoje ainda temos um mercado enorme, onde rubistas ainda estão entre os desenvolvedores mais bem pagos do mercado e onde o framework ainda é o pacote mais completo, tanto do ponto de vista do framework em si e do ecossistema que se formou ao redor. É o pacote mais pragmático pra montar uma tech startup, salvo raras exceções em componentes especiais que podem ser feitos em Elixir ou Go. Mas se você não quer ter dores de cabeça, você ainda escolhe Ruby on Rails. E se precisa de exemplos, não precisa ir muito longe, o GitHub que você talvez já use todo dia é Ruby on Rails, o gigante Shopify foi um dos primeiros a usar Rails e usa até hoje, o AirBnb é Rails, Kickstater é Rails, a Bloomberg ainda usa Rails, o Twitch usa Rails, Zendesk é Rails, Hulu que foi adquirida primeiro pela Fox e agora pela Disney é Rails.

Uma das coisas que muita gente critica é que Ruby on Rails é um framework que se tornou quase um monopólio dentro da comunidade Ruby, temos alguns micro-frameworks como Sinatra e outros menores que tem seu lugar, mas depois do incidente do Merb, nunca mais outro framework chegou perto de competir. Muita gente usa isso pra dizer como em Java, PHP, Javascript tem muito mais opção. Só que isso é um problema na verdade, porque todo mundo pega uma escolha diferente e isso fragmenta a comunidade. Agora você como desenvolvedor muda de empresa, vai encontrar um projeto com bibliotecas e estruturas e estilos completamente diferentes. Toda vez você tem uma curva de aprendizado maior e você nunca realmente domina, é o caso de virar um Jack of all trades, master of none. Como em Ruby, todo projeto em Rails é parecido, quando você muda de empresa, encontra o mesmo ambiente e já é produtivo imediatamente. Por isso andamos tão rápido em tão pouco tempo, porque além disso todo o ecossistema de bibliotecas, produtos e soluções só precisava focar num único framework e com isso nasceu Heroku, Travis, CodeClimate, New Relic.

Levou anos pras outras comunidades começarem a entender um pouco disso e agora no Python meio que Django é a escolha padrão, em PHP o Laravel é a escolha padrão, em Elixir o Phoenix é o padrão, em Crystal o Lucky ou Kemal são padrão, no Java não tenho certeza se Play ou Spring é mais usado, no Go não tenho idéia de qual é padrão mas acho que não tem, são várias opções, em Javascript nem me pergunta, não quero nem pensar nessa zona.

A única outra comunidade na época que pôde usufruir desse fator, pelo bem ou pelo mal, foi o ASP.NET da Microsoft. A diferença é que o ASP.NET original era baseado nos paradigmas que tínhamos no J2EE do fim dos anos 90 e que foi justamente o que o Rails veio combater em 2004. E em 2004 nenhuma outra linguagem tinha opção parecida. Levou anos e anos até finalmente chegarmos no estágio de hoje, onde todo mundo finalmente está trabalhando mais ou menos “on Rails” que quer dizer com foco em qualidade, em entregar valor, em usar as práticas ágeis, usando essa geração de SaaS e IaaS com bons repositórios de código como GitHub ou GitLab, bons gerenciadores de projeto especialmente os derivados do Pivotal Tracker, embora os derivados de Trello também quebrem o galho, boas soluções de deployment de Heroku a soluções da AWS. E até a Microsoft cedeu e com o ASP.NET MVC ele se aproximou dos paradigmas do Ruby on Rails também.

O modelo de desenvolvimento de software se divide em antes e depois de 2004. E tudo que construímos nos 10 anos seguintes até 2014 é o que usamos até hoje em 2019 como o estado da arte. Eu queria falar dos últimos 8 anos desde 2011 mas vou parar por aqui e quem sabe retomar num próximo episódio, mas o objetivo de hoje era registrar o que eu lembro que foi importante pra mim no começo da história e qual foi a importância do surgimento do Ruby on Rails e porque vai ser muito difícil algo parecido acontecer de novo: o DHH teve a sorte de lançar o produto certo na hora certa, com diversos acontecimentos por todo o mercado convergindo no tipo de solução que ele apresentou. O produto certo, feito com os princípios corretos, escolhendo as tecnologias e paradigmas que mais tinham chance, e conseguindo convencer o grupo certo de pessoas, inspiradas pela vontade de se expressar com código em vez de só seguir patterns chatos corporativos e fazer produtos enterprise que ninguém ligava.

Mas sendo muito honesto eu acredito que a influência do Ruby on Rails foi até mais ou menos 2012. Depois disso finalmente as demais comunidades adotaram práticas similares e apareceu uma nova classe de problemas pra resolver. O tipo de coisa que você precisa pra ter um Whatsapp, Discord, Hangouts, Facebook Messenger. Eu diria que é onde o problema original do Twitter finalmente atingiu o mainstream e realmente passamos a resgatar o modelo do Erlang em outras linguagens como Clojure, Go, Elixir, e o meio tapa buraco que foi Node.js pra esses casos. Depois de 2012 que as linguagens mobile se modernizaram com Swift e Kotlin. E também foi depois de 2012 que o Docker apareceu e a conversa sobre devops ganhou um level up culminando com o surgimento de ferramentas e plataformas como Terraform e Kubernetes.

Com tudo isso dito, missão cumprida! Por hoje eu fico por aqui. Se ficaram com dúvidas mande nos comentários abaixo, se curtiram mandem um joinha, não deixem de assinar o canal e clicar no sininho pra não perder os próximos episódios. A gente se vê semana que vem, até mais!

TL;DR: O Google está fazendo um trabalho razoavelmente bom como contrapeso para a AWS não se acomodar. Se você já sabe tudo sobre AWS, eu te encorajo a testar o Google Cloud. Provavelmente por memória muscular, eu ainda me sentisse mais confortável com a AWS, mas agora que me forcei a passar pelo processo de aprendizado, estou bastante confiante com Google Cloud e Kubernetes para a maioria dos meus cenários.

Aviso completo: não sou especialista, então leve o que digo com um grão de sal. É um daqueles assuntos que tenho muita vontade de falar, mas também sou muito cuidadoso com a escolha das palavras para você não ter uma ideia errada sobre as soluções propostas.

O objetivo desse exercício é principalmente guardar alguns trechos e pensamentos para consulta futura. Então tenha em mente que isso também não é um tutorial passo a passo. Minha primeira intenção foi ir por esse caminho, mas aí percebi que seria quase como escrever um livro inteiro, então não dessa vez.

Para ter sucesso com algo como Google Cloud e Kubernetes, você precisa ter experiência em infraestrutura. Se você nunca instalou boxes Linux de nível servidor do zero, se nunca fez otimizações de servidor, se não está confortável com componentes bare-metal do lado do servidor, não tente um deploy real em produção. Sua aposta mais segura ainda é algo como o Heroku.

Você tem que ser o tipo de pessoa que gosta de fuçar nas coisas (como provavelmente você já me leu fazendo em posts anteriores do blog).

Não sei tudo, mas sei o suficiente. Então só precisei descobrir quais peças se encaixariam melhor nas minhas necessidades. Você precisa definir suas necessidades antes de tentar escrever seu primeiro arquivo YAML. Planejamento é crucial.

Antes de tudo, isso é o que eu queria/precisava:

• Camada de aplicação web escalável, onde eu pudesse fazer tanto rolling updates (para atualizações com zero downtime) quanto escalamento horizontal automático e manual dos servidores.
• Storage persistente montável com snapshots/backups automáticos.
• Banco de dados robusto gerenciado (Postgresql) com backups automáticos e replicação fácil para instâncias somente leitura.
• Solução gerenciada para armazenar secrets (como o suporte a ENV do Heroku). Nunca armazene configuração de produção no código-fonte.
• Suporte a imagens Docker sem precisar construir infraestrutura customizada para deploy.
• Endereços IP externos estáticos para integrações que exigiam IP fixo.
• Terminação SSL para poder conectar ao CloudFlare (CDN é obrigatório, mas não suficiente — em 2018 precisamos de algum nível de proteção contra DDoS).
• Segurança suficiente por padrão, para que tudo fique — em teoria — bloqueado a menos que eu decida abrir.
• Alta disponibilidade em diferentes regiões e zonas de data center.

É fácil fazer deploy de uma aplicação web demo simples. Mas eu não queria uma demo, queria uma solução de nível produção para o longo prazo. Melhorias na minha implementação são muito bem-vindas, então fique à vontade para comentar abaixo.

Alguns dos problemas para quem está começando:

• A documentação é muito extensa, e você vai encontrar quase tudo — se souber o que está procurando. Também tenha em mente que Azure e AWS também implementam Kubernetes com algumas diferenças, então parte da documentação não se aplica ao Google Cloud e vice-versa.
• Existem muitos recursos em estágios alpha, beta e stable. A documentação acompanha bem, mas a maioria dos tutoriais com alguns meses pode não funcionar mais como esperado (esse aqui incluído — estou assumindo Kubernetes 1.8.4-gke).
• Existe um conjunto de palavras que se aplicam a conceitos que você já conhece mas têm nomes diferentes. Se acostumar com o vocabulário pode atrapalhar no começo.
• Parece que você está brincando com Lego. Muitas peças que você pode misturar e combinar. É fácil de bagunçar. Isso significa que você pode construir uma configuração adaptada às suas necessidades. Mas se você só copiar e colar de tutoriais, você vai ficar preso.
• Você pode fazer quase tudo através de arquivos YAML e linha de comando, mas não é trivial reutilizar a configuração (para ambientes de produção e staging, por exemplo). Existem ferramentas de terceiros que lidam com bits YAML parametrizáveis e reutilizáveis, mas eu faria tudo à mão primeiro. Nunca, jamais, tente templates automatizados em infraestrutura sem saber exatamente o que eles fazem.
• Você tem 2 ferramentas de linha de comando pesadas: gcloud e kubectl, e a parte confusa é que elas nomeiam algumas coisas de forma diferente mesmo sendo as mesmas “coisas”. Pelo menos, kubectl é próximo do docker, se você estiver familiarizado com ele.

Mais uma vez, isso NÃO é um tutorial passo a passo. Vou anotar alguns passos mas não tudo.

Camada Web Escalável (a própria aplicação web)

A primeira coisa que você precisa ter é uma aplicação web totalmente compatível com os 12 fatores.

Seja Ruby on Rails, Django, Laravel, Node.js ou o que for. Deve ser uma aplicação totalmente shared-nothing, que não depende de escrever nada no sistema de arquivos local. Uma que você possa facilmente desligar e iniciar instâncias independentemente. Sem sessão no estilo antigo em memória local ou em arquivos locais (prefiro evitar session affinity). Sem uploads para o sistema de arquivos local (se for necessário, você terá que montar um storage persistente externo) — sempre prefira enviar streams binários para serviços de storage gerenciados.

Você precisa ter um pipeline adequado que produza cache-busting através de fingerprinting de assets (e gostando ou não, o Rails ainda tem a melhor solução out-of-the-box no seu Asset Pipeline). Você não quer se preocupar com invalidar caches em CDNs manualmente.

Instrumente sua aplicação, adicione o New Relic RPM, adicione o Rollbar.

De novo, isso é 2018 — você não quer fazer deploy de código ingênuo com injeção de SQL (ou qualquer outro tipo de input), sem eval sem verificação no seu código, sem brecha para CSRF ou XSS, etc. Vá em frente, compre a licença do Brakeman Pro e adicione ao seu pipeline de CI. Posso esperar…

Como isso não é um tutorial, vou assumir que você é mais do que capaz de se cadastrar no Google Cloud e encontrar seu caminho para configurar um projeto, configurar sua região e zona.

Demorei um pouco para entender a estrutura inicial no Google Cloud:

• Você começa com um Projeto, que é o guarda-chuva para tudo que sua aplicação precisa.
• Em seguida você cria “clusters”. Você pode ter um cluster de produção ou staging, por exemplo. Ou um cluster web e um cluster de serviços separado para coisas não-web, e assim por diante.
• Um cluster tem um “cluster-master”, que é o controlador de tudo o mais (os comandos gcloud e kubectl falam com suas APIs).
• Um cluster tem muitas “node instances”, as “máquinas” propriamente ditas (ou, mais precisamente, instâncias de VM).
• Cada cluster também tem pelo menos um “node pool” (o “default-pool”), que é um conjunto de node instances com a mesma configuração, o mesmo “machine-type”.
• Por fim, cada node instance executa um ou mais “pods” que são containers leves como LXC. É aqui que sua aplicação realmente vive.

Este é um exemplo de criação de cluster:

gcloud container clusters create my-web-production \
--enable-cloud-logging \
--enable-cloud-monitoring \
--machine-type n1-standard-4 \
--enable-autoupgrade \
--enable-autoscaling --max-nodes=5 --min-nodes=2 \
--num-nodes 2

Como mencionei, ele também cria um default-pool com um machine-type de n1-standard-4. Escolha qual combinação de CPU/RAM você vai precisar para sua aplicação específica com antecedência. O tipo que escolhi tem 4 vCPUs e 15GB de RAM.

Por padrão ele começa com 3 nodes, então escolhi 2 inicialmente mas com auto-scaling até 5 (você pode atualizar isso depois se precisar, mas garanta que tem espaço para crescimento inicial). E você pode continuar adicionando node-pools extras para node instances de tamanhos diferentes — digamos, para workers do Sidekiq fazerem processamento pesado em background. Então você deve criar um Node Pool separado com um machine-type diferente para seu conjunto de node instances, por exemplo:

gcloud container node-pools create large-pool \
--cluster=my-web-production \
--node-labels=pool=large \
--machine-type=n1-highcpu-8 \
--num-nodes 1

Esse outro pool controla 1 node do tipo n1-highcpu-8 que tem 8 vCPUs com 7,2 GB de RAM. Mais CPUs, menos memória. Existe uma categoria highmem que tem menos CPUs com muito mais memória. De novo, saiba o que você quer com antecedência.

A parte importante aqui é o --node-labels — é assim que vou mapear o deployment para escolher entre Node Pools (neste caso, entre o default-pool e o large-pool).

Após criar um cluster, você precisa executar o seguinte comando para buscar suas credenciais:

gcloud container clusters get-credentials my-web-production

Isso configura o comando kubectl também. Se você tiver mais de um cluster (digamos, um my-web-production e my-web-staging), precisa ter muito cuidado de sempre fazer get-credentials para o cluster correto primeiro, caso contrário pode acabar executando um deploy de staging no cluster de produção.

Como isso é confuso, modifiquei meu ZSH PROMPT para sempre mostrar com qual cluster estou lidando. Adaptei do zsh-kubectl-prompt:

Como você acabará tendo múltiplos clusters em uma aplicação grande, recomendo fortemente adicionar esse PROMPT ao seu shell.

Agora, como você faz deploy da sua aplicação nos pods dentro dessas node instances?

Você precisa ter um Dockerfile no repositório do seu projeto de aplicação para gerar uma imagem Docker. Este é um exemplo para uma aplicação Ruby on Rails:

FROM ruby:2.4.3
ENV RAILS_ENV production
ENV SECRET_KEY_BASE xpto
RUN curl -sL https://deb.nodesource.com/setup_8.x | bash -
RUN apt-get update && apt-get install -y nodejs postgresql-client cron htop vim
ADD Gemfile* /app/
WORKDIR /app
RUN gem update bundler --pre
RUN bundle install --without development test
RUN npm install
ADD . /app
RUN cp config/database.yml.prod.example config/database.yml && cp config/application.yml.example config/application.yml
RUN RAILS_GROUPS=assets bundle exec rake assets:precompile

No Google Cloud Web Console, você encontrará um “Container Registry”, que é um Registry Docker Privado.

Você precisa adicionar a URL remota à sua configuração local assim:

git remote add gcloud https://source.developers.google.com/p/my-project/r/my-app

Agora você pode fazer git push gcloud master. Recomendo também adicionar triggers para taggear suas imagens. Adiciono 2 triggers: um para taggeá-la com latest e outro para taggeá-la com um número de versão aleatório. Você vai precisar deles mais tarde.

Depois de adicionar o repositório do registry como um remote na sua configuração git (git remote add) e fazer push nele, ele deve começar a construir sua imagem Docker com as tags adequadas que você configurou com os triggers.

Certifique-se de que sua aplicação Ruby on Rails não tem nada nos initializers que exija uma conexão com o banco de dados, pois ele não está disponível. Isso é algo com que você pode travar quando seu build Docker falha por causa da tarefa assets:precompile que carregou um initializer que acidentalmente chama um Model — e isso dispara o ActiveRecord::Base tentando se conectar.

Além disso, certifique-se de que a versão do Ruby no Dockerfile corresponde à do Gemfile, caso contrário também vai falhar.

Reparou no estranho config/application.yml acima? Esse é do figaro. Também recomendo usar algo para facilitar a configuração de variáveis ENV no seu sistema. Não gosto dos secrets do Rails, e ele não é exatamente amigável para a maioria dos sistemas de deploy depois que o Heroku popularizou as ENV vars. Fique com ENV vars. O Kubernetes também vai agradecer por isso.

Agora, você pode sobrescrever qualquer variável ENV do arquivo YAML de Deployment do Kubernetes. Agora é uma boa hora para mostrar um exemplo disso. Você pode nomeá-lo deploy/web.yml ou como preferir e — claro — comitá-lo no seu repositório de código-fonte.

kind: Deployment
apiVersion: apps/v1beta1
metadata:
  name: web
spec:
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 1
  minReadySeconds: 10
  replicas: 2
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
        - image: gcr.io/my-project/my-app:latest
          name: my-app
          imagePullPolicy: Always
          ports:
          - containerPort: 4001
          command: ["passenger", "start", "-p", "4001", "-e", "production",
          "--max-pool-size", "2", "--min-instances", "2", "--no-friendly-error-pages"
          "--max-request-queue-time", "10", "--max-request-time", "10",
          "--pool-idle-time", "0", "--memory-limit", "300"]
          env:
            - name: "RAILS_LOG_TO_STDOUT"
              value: "true"
            - name: "RAILS_ENV"
              value: "production"
            # ... obviamente reduzi as muitas ENV vars por brevidade
            - name: "REDIS_URL"
              valueFrom:
                secretKeyRef:
                  name: my-env
                  key: REDIS_URL
            - name: "SMTP_USERNAME"
              valueFrom:
                secretKeyRef:
                  name: my-env
                  key: SMTP_USERNAME
            - name: "SMTP_PASSWORD"
              valueFrom:
                secretKeyRef:
                  name: my-env
                  key: SMTP_PASSWORD
            # ... esta parte abaixo é obrigatória para Cloud SQL
            - name: DB_HOST
              value: 127.0.0.1
            - name: DB_PASSWORD
              valueFrom:
                secretKeyRef:
                  name: cloudsql-db-credentials
                  key: password
            - name: DB_USER
              valueFrom:
                secretKeyRef:
                  name: cloudsql-db-credentials
                  key: username

        - image: gcr.io/cloudsql-docker/gce-proxy:latest
          name: cloudsql-proxy
          command: ["/cloud_sql_proxy", "--dir=/cloudsql",
                    "-instances=my-project:us-west1:my-db=tcp:5432",
                    "-credential_file=/secrets/cloudsql/credentials.json"]
          volumeMounts:
            - name: cloudsql-instance-credentials
              mountPath: /secrets/cloudsql
              readOnly: true
            - name: ssl-certs
              mountPath: /etc/ssl/certs
            - name: cloudsql
              mountPath: /cloudsql
      volumes:
        - name: cloudsql-instance-credentials
          secret:
            secretName: cloudsql-instance-credentials
        - name: ssl-certs
          hostPath:
            path: /etc/ssl/certs
        - name: cloudsql
          emptyDir:

Tem muita coisa acontecendo aqui. Então deixa eu quebrar um pouco:

• O kind e o apiVersion são importantes — você precisa ficar de olho na documentação se eles mudarem. Isso é o que chamamos de Deployment. Antigamente existia um Replication Controller (você encontrará em tutoriais antigos), mas não está mais em uso. A recomendação é usar um ReplicaSet.
• Nomeie as coisas corretamente — aqui você tem metadata:name com web. Preste muita atenção também ao spec:template:metadata:labels onde estou rotulando cada pod com um label de app: web, você vai precisar disso para poder selecionar esses pods mais tarde na seção Service abaixo.
• Em seguida tenho o spec:strategy onde configuramos o Rolling Update, então se você tem 10 pods, ele vai terminar um, inicializar o novo e continuar fazendo isso, sem nunca derrubar tudo de uma vez.
• spec:replicas declara quantos Pods quero de uma vez. Você terá que calcular manualmente o machine-type do node-pool e então dividir quantos CPUs/RAM totais você tem pelo quanto precisa para cada instância de aplicação.
• Lembra da imagem Docker que geramos acima com a tag ’latest’? Você a referencia em spec:template:spec:containers:image
• Estou usando o Passenger com configuração de produção (confira a documentação do Phusion, não copie isso só assim).
• Na seção spec:template:spec:containers:env posso sobrescrever as ENV vars com os secrets reais de produção. E você vai notar que posso hard-codar valores ou usar essa estranha construção:

- name: "SMTP_USERNAME"
  valueFrom:
    secretKeyRef:
      name: my-env
      key: SMTP_USERNAME

Aqui está referenciando um armazenamento de “Secret” que nomeei “my-env”. E é assim que você cria o seu:

kubectl create secret generic my-env \
--from-literal=REDIS_URL=redis://foo.com:18821 \
--from-literal=SMTP_USERNAME=foobar

Leia a documentação pois você pode carregar arquivos de texto em vez de declarar tudo pela linha de comando.

Como disse antes, prefiro usar um serviço gerenciado para o banco de dados. Você pode definitivamente carregar sua própria imagem Docker, mas realmente não recomendo. O mesmo vale para outros serviços similares a banco de dados como Redis, Mongo. Se você vem da AWS, o Google Cloud SQL é como o RDS.

Após criar sua instância PostgreSQL você não consegue acessá-la diretamente da aplicação web. No final, você tem um boilerplate para uma segunda imagem Docker, um “CloudSQL Proxy”.

Para isso funcionar você precisa primeiro criar uma Service Account:

gcloud sql users create proxyuser host --instance=my-db --password=abcd1234

Após criar a instância PostgreSQL ela vai pedir para você baixar uma credencial JSON, então tenha cuidado e salve-a em algum lugar seguro. Não preciso dizer que você também deve gerar uma senha forte e segura. Em seguida precisa criar secrets extras:

kubectl create secret generic cloudsql-instance-credentials \
--from-file=credentials.json=/home/myself/downloads/my-db-12345.json

kubectl create secret generic cloudsql-db-credentials \
--from-literal=username=proxyuser --from-literal=password=abcd1234

Esses são referenciados nesta parte do Deployment:

- image: gcr.io/cloudsql-docker/gce-proxy:latest
  name: cloudsql-proxy
  command: ["/cloud_sql_proxy", "--dir=/cloudsql",
            "-instances=my-project:us-west1:my-db=tcp:5432",
            "-credential_file=/secrets/cloudsql/credentials.json"]
  volumeMounts:
    - name: cloudsql-instance-credentials
      mountPath: /secrets/cloudsql
      readOnly: true
    - name: ssl-certs
      mountPath: /etc/ssl/certs
    - name: cloudsql
      mountPath: /cloudsql
volumes:
- name: cloudsql-instance-credentials
  secret:
    secretName: cloudsql-instance-credentials
- name: ssl-certs
  hostPath:
    path: /etc/ssl/certs
- name: cloudsql
  emptyDir:

Veja que você precisa adicionar o nome do banco de dados (“my-db” neste exemplo) na cláusula -instance no comando.

A propósito, o gce-proxy:latest se referia à versão 1.09 na época em que esse post foi publicado. Mas já havia uma versão 1.11. Essa me deu dores de cabeça, derrubando conexões e adicionando um timeout super longo. Então voltei para a 1.09 (latest) e tudo funcionou como esperado. Fique atento! Nem tudo que é novinho é bom. Em infraestrutura, você quer ficar com o que é estável.

Você também pode querer a opção de carregar uma instância CloudSQL separada em vez de tê-la em cada pod, para que os pods pudessem se conectar a apenas um proxy. Pode ser interessante ler essa thread sobre o assunto.

Parece que nada é exposto a nada a menos que você diga explicitamente. Então precisamos expor esses pods através do que chamamos de Node Port Service. Vamos criar um arquivo deploy/web-svc.yaml também:

apiVersion: v1
kind: Service
metadata:
  name: web-svc
spec:
  sessionAffinity: None
  ports:
  - port: 80
    targetPort: 4001
    protocol: TCP
  type: NodePort
  selector:
    app: web

É por isso que destaquei a importância do spec:template:metadata:labels, para que possamos usá-lo aqui no spec:selector para selecionar os pods corretos.

Agora podemos fazer deploy desses 2 assim:

kubectl create -f deploy/web.yml
kubectl create -f deploy/web-svc.yml

E você pode ver os pods sendo criados com kubectl get pods --watch.

O Load Balancer

Muitos tutoriais vão expor esses pods diretamente através de um Service diferente, chamado Load Balancer. Não tenho tanta certeza sobre como isso se comporta sob pressão e se tem terminação SSL, etc. Então decidi ir com tudo com um Ingress Load Balancer usando o NGINX Controller.

Primeiro de tudo, decidi criar um node-pool separado para ele, por exemplo, assim:

gcloud container node-pools create web-load-balancer \
--cluster=my-web-production \
--node-labels=role=load-balancer \
--machine-type=g1-small \
--num-nodes 1 \
--max-nodes 3 --min-nodes=1 \
--enable-autoscaling 

Assim como quando criamos o exemplo de large-pool, aqui você precisa cuidar de adicionar --node-labels para que o controller seja instalado aqui em vez do default-pool. Você vai precisar saber o nome da node instance, podemos fazer isso assim:

$ gcloud compute instances list
NAME                                             ZONE        MACHINE_TYPE   PREEMPTIBLE  INTERNAL_IP  EXTERNAL_IP      STATUS
gke-my-web-production-default-pool-123-123       us-west1-a  n1-standard-4               10.128.0.1   123.123.123.12   RUNNING
gke-my-web-production-large-pool-123-123         us-west1-a  n1-highcpu-8                10.128.0.2   50.50.50.50      RUNNING
gke-my-web-production-web-load-balancer-123-123  us-west1-a  g1-small                    10.128.0.3   70.70.70.70      RUNNING

Vamos salvar assim por enquanto:

export LB_INSTANCE_NAME=gke-my-web-production-web-load-balancer-123-123

Você pode reservar manualmente um IP externo e dar um nome a ele assim:

gcloud compute addresses create ip-web-production \
        --ip-version=IPV4 \
        --global

Para fins de exemplo, digamos que ele gerou um IP reservado “111.111.111.111”. Então vamos buscá-lo e salvá-lo por enquanto assim:

export LB_ADDRESS_IP=$(gcloud compute addresses list | grep "ip-web-production" | awk '{print $3}')

Por fim, vamos vincular esse endereço à node instance do load balancer:

export LB_INSTANCE_NAT=$(gcloud compute instances describe $LB_INSTANCE_NAME | grep -A3 networkInterfaces: | tail -n1 | awk -F': ' '{print $2}')
gcloud compute instances delete-access-config $LB_INSTANCE_NAME \
    --access-config-name "$LB_INSTANCE_NAT"
gcloud compute instances add-access-config $LB_INSTANCE_NAME \
    --access-config-name "$LB_INSTANCE_NAT" --address $LB_ADDRESS_IP

Feito isso, podemos adicionar o resto da configuração de Deployment do Ingress. Vai ser um pouco longo, mas é basicamente boilerplate. Vamos começar definindo outra aplicação web que chamaremos de default-http-backend, usada para responder a requisições HTTP caso nossos pods web não estejam disponíveis por algum motivo. Vamos chamá-la de deploy/default-web.yml:

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: default-http-backend
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: default-http-backend
    spec:
      terminationGracePeriodSeconds: 60
      containers:
      - name: default-http-backend
        # Any image is permissable as long as:
        # 1. It serves a 404 page at /
        # 2. It serves 200 on a /healthz endpoint
        image: gcr.io/google_containers/defaultbackend:1.0
        livenessProbe:
          httpGet:
            path: /healthz
            port: 8080
            scheme: HTTP
          initialDelaySeconds: 30
          timeoutSeconds: 5
        ports:
        - containerPort: 8080
        resources:
          limits:
            cpu: 10m
            memory: 20Mi
          requests:
            cpu: 10m
            memory: 20Mi

Não precisa mudar nada aqui — e a essa altura você já deve estar familiarizado com o template de Deployment. Você já sabe que precisa expô-lo através de um NodePort, então vamos adicionar um deploy/default-web-svc.yml:

kind: Service
apiVersion: v1
metadata:
  name: default-http-backend
spec:
  selector:
    app: default-http-backend
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080
  type: NodePort

De novo, não precisa mudar nada. Os próximos 3 arquivos são as partes importantes. Primeiro, criaremos um NGINX Load Balancer — vamos chamá-lo de deploy/nginx.yml:

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: nginx-ingress-controller
spec:
  replicas: 1
  template:
    metadata:
      labels:
        k8s-app: nginx-ingress-lb
    spec:
      # hostNetwork makes it possible to use ipv6 and to preserve the source IP correctly regardless of docker configuration
      # however, it is not a hard dependency of the nginx-ingress-controller itself and it may cause issues if port 10254 already is taken on the host
      # that said, since hostPort is broken on CNI (https://github.com/kubernetes/kubernetes/issues/31307) we have to use hostNetwork where CNI is used
      hostNetwork: true
      terminationGracePeriodSeconds: 60
      nodeSelector:
        role: load-balancer
      containers:
        - args:
            - /nginx-ingress-controller
            - "--default-backend-service=$(POD_NAMESPACE)/default-http-backend"
            - "--default-ssl-certificate=$(POD_NAMESPACE)/cloudflare-secret"
          env:
            - name: POD_NAME
              valueFrom:
                fieldRef:
                  fieldPath: metadata.name
            - name: POD_NAMESPACE
              valueFrom:
                fieldRef:
                  fieldPath: metadata.namespace
          image: "gcr.io/google_containers/nginx-ingress-controller:0.9.0-beta.5"
          imagePullPolicy: Always
          livenessProbe:
            httpGet:
              path: /healthz
              port: 10254
              scheme: HTTP
            initialDelaySeconds: 10
            timeoutSeconds: 5
          name: nginx-ingress-controller
          ports:
            - containerPort: 80
              name: http
              protocol: TCP
            - containerPort: 443
              name: https
              protocol: TCP
          volumeMounts:
            - mountPath: /etc/nginx-ssl/dhparam
              name: tls-dhparam-vol
      volumes:
        - name: tls-dhparam-vol
          secret:
            secretName: tls-dhparam

Preste atenção ao nodeSelector para usar o node label que adicionamos ao criar o novo node-pool.

Você pode querer mexer nos labels, no número de réplicas se precisar. Mas aqui você vai notar que ele monta um volume que nomeei como tls-dhparam-vol. Esses são os Parâmetros Efêmeros Diffie Hellman. É assim que geramos:

sudo openssl dhparam -out ~/documents/dhparam.pem 2048

kubectl create secret generic tls-dhparam --from-file=/home/myself/documents/dhparam.pem

kubectl create secret generic tls-dhparam --from-file=/home/myself/documents/dhparam.pem

Note também que estou usando a versão “0.9.0-beta_5” para a imagem do controller. Funciona bem, sem problemas até agora. Mas fique de olho nas release notes para versões mais novas e faça seus próprios testes.

De novo, vamos expor esse controller Ingress através do Load Balancer Service. Vamos chamá-lo de deploy/nginx-svc.yml:

apiVersion: v1
kind: Service
metadata:
  name: nginx-ingress
spec:
  type: LoadBalancer
  loadBalancerIP: 111.111.111.111
  ports:
  - name: http
    port: 80
    targetPort: http
  - name: https
    port: 443
    targetPort: https
  selector:
    k8s-app: nginx-ingress-lb

Lembra do IP externo estático que reservamos acima e salvamos na ENV var LB_INGRESS_IP? Esse é o que precisa colocar na seção spec:loadBalancerIP. Esse também é o IP que você vai adicionar como “registro A” no seu serviço DNS (digamos, mapeando seu “www.my-app.com.br” no CloudFlare).

Por fim, podemos criar a configuração do Ingress em si — vamos criar um deploy/ingress.yml assim:

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: ingress
  annotations:
    kubernetes.io/ingress.class: "nginx"
    nginx.org/ssl-services: "web-svc"
    kubernetes.io/ingress.global-static-ip-name: ip-web-production
    ingress.kubernetes.io/ssl-redirect: "true"
    ingress.kubernetes.io/rewrite-target: /
spec:
  tls:
    - hosts:
      - www.my-app.com.br
      secretName: cloudflare-secret
  rules:
    - host: www.my-app.com.br
      http:
        paths:
        - path: /
          backend:
            serviceName: web-svc
            servicePort: 80

Cuidado com as annotations acima que conectam tudo. Ele vincula o serviço NodePort que criamos para os pods web com o nginx ingress controller e adiciona terminação SSL através daquele spec:tls:secretName. Como você cria isso? Primeiro precisa comprar um certificado SSL — usando o CloudFlare como exemplo novamente.

Quando terminar a compra, o provedor deve te dar os arquivos secretos para download (guarde-os em segurança! uma pasta pública do Dropbox não é segura!). Então precisa adicioná-los à infraestrutura assim:

kubectl create secret tls cloudflare-secret \
--key ~/downloads/private.pem \
--cert ~/downloads/fullchain.pem

Agora que editamos um monte de arquivos, podemos fazer deploy de todo o stack do load balancer:

kubectl create -f deploy/default-web.yml
kubectl create -f deploy/default-web-svc.yml
kubectl create -f deploy/nginx.yml
kubectl create -f deploy/nginx-svc.yml
kubectl create -f deploy/ingress.yml

Essa configuração do NGINX Ingress é baseada no post do blog do Zihao Zhang. Existem também exemplos no repositório kubernetes incubator. Vale a pena conferir também.

Se você fez tudo certo até aqui, https://www.my-app-com.br deve carregar sua aplicação web. Pode ser interessante verificar o Time to First-Byte (TTFB). Você pode fazer isso passando pelo CloudFlare assim:

curl -vso /dev/null -w "Connect: %{time_connect} \n TTFB: %{time_starttransfer} \n Total time: %{time_total} \n" https://www.my-app.com.br

Ou, se estiver com TTFB lento, pode contornar o CloudFlare fazendo isso:

curl --resolve www.my-app.com.br:443:111.111.111.111 https://www.my-app.com.br -svo /dev/null -k -w "Connect: %{time_connect} \n TTFB: %{time_starttransfer} \n Total time: %{time_total} \n"

O TTFB deve ficar em torno de 1 segundo ou menos. Qualquer coisa muito acima disso pode indicar um problema na sua aplicação. Verifique os machine types da sua node instance, o número de workers carregados por pod, a versão do CloudSQL proxy, a versão do NGINX controller e assim por diante. Isso é um processo de tentativa e erro, pelo que sei. Cadastre-se em serviços como Loader ou mesmo Web Page Test para ter insights.

Rolling Updates

Agora, com tudo funcionando, como realizamos o Rolling Update que mencionei no início? Primeiro você faz git push para o repositório do Container Registry e aguarda a construção da imagem Docker.

Lembra que disse para deixar um trigger tagear a imagem com um número de versão aleatório? Vamos usá-lo (você pode ver isso na lista de Build History no Container Registry, no console do Google Cloud):

kubectl set image deployment web my-app=gcr.io/my-project/my-app:1238471234g123f534f543541gf5 --record

Você deve usar o mesmo nome e imagem declarados no deploy/web.yml acima. Isso vai começar a fazer rollout da atualização adicionando um novo pod, então encerrando um pod e assim por diante, sem downtime para seus usuários.

Rolling updates precisam ser executados com cuidado. Por exemplo, se seu novo deploy exige uma migração de banco de dados, você precisa adicionar uma janela de manutenção (ou seja: faça isso quando houver pouco ou nenhum tráfego, como de madrugada). Então você pode executar o comando migrate assim:

kubectl get pods # para obter o nome de um pod

kubectl exec -it my-web-12324-121312 /app/bin/rails db:migrate

# você também pode entrar em bash em um pod assim, mas lembre que este é um container efêmero, então arquivos que você editar e escrever ali desaparecem no próximo restart:

kubectl exec -it my-web-12324-121312 bash

Para fazer redeploy de tudo sem recorrer ao rolling update, você precisa fazer isso:

kubectl delete -f deploy/web.yml && kubectl apply -f deploy/web.yml

Você encontrará uma explicação mais completa no blog do Ta-Ching.

Bônus: Auto Snapshots

Um item que tinha na minha lista de “queria/precisava” no início é a capacidade de ter storage persistente montável com backups/snapshots automáticos. O Google Cloud fornece metade disso por enquanto. Você pode criar discos persistentes para montar nos seus pods, mas não tem um recurso para fazer backup automático dele. Pelo menos tem APIs para criar snapshots manualmente.

Para este exemplo, vamos criar um novo disco SSD e formatá-lo primeiro:

gcloud compute disks create --size 500GB my-data --type pd-ssd

gcloud compute instances list

O último comando é para copiarmos o nome de uma node instance. Digamos que seja gke-my-web-app-default-pool-123-123. Vamos anexar o disco my-data a ela:

gcloud compute instances attach-disk gke-my-web-app-default-pool-123-123 --disk my-data --device-name my-data

gcloud compute ssh gke-my-web-app-default-pool-123-123

O último comando faz SSH na instância. Podemos listar os discos anexados com sudo lsblk e você verá o disco de 500GB, provavelmente como /dev/sdb, mas certifique-se de que está correto porque vamos formatá-lo!

sudo mkfs.ext4 -m 0 -F -E lazy_itable_init=0,lazy_journal_init=0,discard /dev/sdb

Agora podemos sair da sessão SSH e desanexar o disco:

gcloud compute instances detach-disk gke-my-web-app-default-pool-123-123 --disk my-data

Você pode montar esse disco nos seus pods adicionando o seguinte ao seu yaml de deployment:

spec:
  containers:
    - image: ...
      name: my-app
      volumeMounts:
        - name: my-data
          mountPath: /data
          # readOnly: true
   # ...
   volumes:
     - name: my-data
       gcePersistentDisk:
         pdName: my-data
         fsType: ext4

Agora, vamos criar um arquivo de deployment CronJob como deploy/auto-snapshot.yml:

apiVersion: batch/v1beta1
kind: CronJob
metadata:
  name: auto-snapshot
spec:
  schedule: "0 4 * * *"
  concurrencyPolicy: Forbid
  jobTemplate:
    spec:
      template:
        spec:
          restartPolicy: OnFailure
          containers:
          - name: auto-snapshot
            image: grugnog/google-cloud-auto-snapshot
            command: ["/opt/entrypoint.sh"]
            env:
            - name: "GOOGLE_CLOUD_PROJECT"
              value: "my-project"
            - name: "GOOGLE_APPLICATION_CREDENTIALS"
              value: "/credential/credential.json"
            volumeMounts:
              - mountPath: /credential
                name: editor-credential
          volumes:
            - name: editor-credential
              secret:
                secretName: editor-credential

Como já fizemos antes, você precisará criar outra Service Account com permissões de editor na seção “IAM & admin” do console do Google Cloud, depois baixar a credencial JSON e, por fim, fazer upload dela assim:

kubectl create secret generic editor-credential \
--from-file=credential.json=/home/myself/download/my-project-1212121.json

Note também que, como um cron job normal, existe um parâmetro de schedule que você pode querer alterar. No exemplo, “0 4 * * *” significa que o snapshot vai rodar todo dia às 4h da manhã.

Confira o repositório original dessa solução para mais detalhes.

E por agora é isso!

Como disse no início, este não é um procedimento completo, apenas destaques de algumas das partes importantes. Se você é novo no Kubernetes, acabou de ler sobre Deployment, Service, Ingress, mas ainda tem ReplicaSet, DaemonSet e muito mais para explorar.

Acho que já está longo demais para adicionar uma explicação de configuração de Alta Disponibilidade multi-região, então vamos deixar por aqui.

Correções ou sugestões são muito bem-vindas, pois ainda estou no processo de aprendizado, e tem um monte de coisas que eu mesmo ainda não sei.

Só que o WebKit é famoso por ser muito complicado de lidar. Então dá pra imaginar o pesadelo que é manter o PhantomJS, que é basicamente manter um browser completo como Chrome ou Safari.

Não é de espantar que, quando o time do Chrome anunciou a disponibilidade do Chrome Driver, o mantenedor do PhantomJS decidiu se afastar do projeto.

Se você conhece os contribuidores do PhantomJS, agradeça a eles — o projeto nos ajudou a construir funcionalidades de usuário mais sólidas por anos.

Dito isso, não precisa se preocupar. É perfeitamente possível substituir Poltergeist/PhantomJS por Selenium WebDriver/Chrome Driver no seu setup de RSpec/Capybara.

Meu amigo Lucas Caton escreveu sobre isso em junho deste ano. Vale acompanhar o blog dele também.

Se você usa Linux com o browser Chromium, não precisa instalar nada — o Chrome Driver já vem com o Chromium. Caso contrário, instale os pacotes adequados para o seu sistema operacional. Por exemplo: brew install chromedriver no OS X, ou pacaur -S chromedriver no Arch Linux se preferir não ter o Chromium instalado. No Ubuntu, talvez seja necessário ajustar seu PATH.

Regra geral: instale o Chromium.

No meu caso, as mudanças foram as seguintes:

# Gemfile
- gem "poltergeist"
+ gem "selenium-webdriver"
+ gem "rspec-retry"

Depois, na configuração do Capybara:

Capybara.server = :puma # Até o setup funcionar
Capybara.server = :puma, { Silent: true } # Para limpar o output dos testes

- Capybara.register_driver :poltergeist do |app|
-   options = {
-     timeout: 3.minutes,
-     phantomjs_options: [
-       '--proxy-type=none',
-       '--load-images=no',
-       '--ignore-ssl-errors=yes',
-       '--ssl-protocol=any',
-       '--web-security=false'
-     ]
-   }
-   Capybara::Poltergeist::Driver.new(app, options)
- end
- Capybara.javascript_driver = :poltergeist

+ Capybara.register_driver :chrome do |app|
+   capabilities = Selenium::WebDriver::Remote::Capabilities.chrome(
+     chromeOptions: {
+       args: %w[ no-sandbox headless disable-popup-blocking disable-gpu window-size=1280,1024]
+     }
+   )
+ 
+   Capybara::Selenium::Driver.new(app, browser: :chrome, desired_capabilities: capabilities)
+ end
+ 
+ Capybara::Screenshot.register_driver :chrome do |driver, path|
+   driver.save_screenshot(path)
+ end
+ 
+ Capybara.javascript_driver = :chrome

Capybara.default_max_wait_time = 5 # aumente esse timeout se sua aplicação for pesada para carregar