Começando a estudar Inteligência Artificial recentemente por motivos de mestrado e pós-graduação, rapidamente percebi que frameworks como PyTorch e TensorFlow abstraem muita coisa — mas essa abstração cobra um preço. Sem entender a matemática por trás, você consegue rodar modelos, mas não consegue debugar, otimizar ou criar nada novo.

Este post é um mapa dos principais conceitos matemáticos que sustentam IA, Machine Learning e Deep Learning. Não é um curso completo de cada tópico, mas sim uma explicação de o que é, por que importa e onde aparece na prática.

Para tornar o conteúdo mais prático, o Claude me acompanha ao longo do post com sugestões de exercícios e referências para cada tópico.

1. Álgebra Linear

A álgebra linear é a linguagem fundamental da IA. Praticamente tudo — dados, pesos, transformações — é representado como vetores e matrizes.

Vetores e Matrizes

Um vetor é uma lista ordenada de números. Uma imagem 28x28 pixels pode ser representada como um vetor de 784 elementos. Uma matriz é uma tabela de números — os pesos de uma rede neural são armazenados em matrizes.

Onde aparece: representação de dados, embeddings de texto, imagens como tensores.

Multiplicação de Matrizes

A operação mais executada em redes neurais. Quando um input passa por uma camada, o que acontece é uma multiplicação de matrizes seguida de uma função de ativação.

output = activation(W · input + b)

Onde W é a matriz de pesos e b é o vetor de bias.

Onde aparece: forward pass de qualquer rede neural, camadas densas, convoluções.

Transposição e Inversão

Transpor uma matriz (trocar linhas por colunas) é usado constantemente em operações de gradiente. A inversão aparece em soluções analíticas como regressão linear.

Onde aparece: backpropagation, regressão linear, PCA.

Autovalores e Autovetores

Um autovetor de uma matriz é um vetor que, quando multiplicado pela matriz, muda apenas de escala (não de direção). O fator de escala é o autovalor.

Onde aparece: PCA (Principal Component Analysis), análise espectral, estabilidade de redes recorrentes.

Espaços Vetoriais e Transformações Lineares

Entender que dados vivem em espaços de alta dimensão e que redes neurais aplicam transformações sucessivas nesses espaços é fundamental para intuir como modelos “aprendem”.

Onde aparece: embeddings (Word2Vec, BERT), redução de dimensionalidade, atenção em Transformers.

2. Cálculo

O cálculo é o motor do aprendizado. Sem ele, não existe treinamento de modelos.

Derivadas

A derivada mede a taxa de mudança de uma função. No contexto de ML, ela responde: “se eu ajustar este peso um pouquinho, quanto a perda (loss) muda?”

Onde aparece: toda otimização de modelos.

Derivadas Parciais

Quando a função tem muitas variáveis (e um modelo pode ter bilhões), calculamos derivadas parciais — a derivada em relação a cada variável individualmente.

Onde aparece: cálculo de gradientes, backpropagation.

Regra da Cadeia

A regra da cadeia permite calcular a derivada de funções compostas. Uma rede neural é basicamente uma composição de funções, então a regra da cadeia é o que torna o backpropagation possível.

dL/dw = dL/dy · dy/dz · dz/dw

Onde aparece: backpropagation — é literalmente a base matemática de como redes neurais aprendem.

Gradiente

O gradiente é o vetor de todas as derivadas parciais. Ele aponta na direção de maior crescimento da função. Para minimizar o erro, andamos na direção oposta ao gradiente.

Onde aparece: gradient descent, SGD, Adam, e todos os otimizadores.

Integrais

Menos usadas diretamente no dia a dia de ML, mas essenciais para entender distribuições de probabilidade, funções de densidade e normalização.

Onde aparece: modelos probabilísticos, VAEs (Variational Autoencoders), teoria da informação.

3. Probabilidade e Estatística

Se álgebra linear é a linguagem e cálculo é o motor, probabilidade é a lógica da IA. Quase todo modelo lida com incerteza.

Probabilidade Básica

Onde aparece: classificadores, modelos generativos, qualquer predição com incerteza.

Teorema de Bayes

P(A|B) = P(B|A) · P(A) / P(B)

O teorema de Bayes permite atualizar crenças com base em evidências. É a base de classificadores Naive Bayes e de toda a inferência bayesiana.

Onde aparece: Naive Bayes, filtros de spam, redes bayesianas, inferência probabilística.

Distribuições de Probabilidade

As mais importantes para IA:

• Normal (Gaussiana): inicialização de pesos, ruído, normalização
• Bernoulli: classificação binária, dropout
• Categórica/Multinomial: classificação multiclasse, softmax
• Uniforme: inicialização, amostragem aleatória

Onde aparece: em praticamente tudo — de inicialização de pesos a modelos generativos.

Valor Esperado e Variância

O valor esperado é a “média ponderada” dos resultados possíveis. A variância mede o quanto os valores se dispersam. Controlar a variância dos gradientes é crucial para treinar modelos estáveis.

Onde aparece: funções de perda, normalização (batch norm, layer norm), análise de convergência.

Maximum Likelihood Estimation (MLE)

A ideia de encontrar os parâmetros que maximizam a probabilidade dos dados observados. É a justificativa teórica por trás de muitas funções de perda.

Onde aparece: regressão logística, cross-entropy loss, modelos de linguagem.

4. Otimização

O treinamento de qualquer modelo de ML é, no fundo, um problema de otimização: encontrar os parâmetros que minimizam uma função de erro.

Gradient Descent

O algoritmo mais fundamental de ML. A cada passo, calculamos o gradiente da função de perda e ajustamos os pesos na direção oposta.

w = w - learning_rate * gradiente

Onde aparece: treinamento de qualquer modelo.

Stochastic Gradient Descent (SGD)

Em vez de calcular o gradiente usando todos os dados, usamos mini-batches aleatórios. Isso torna o treinamento viável para datasets grandes e adiciona ruído que ajuda a escapar de mínimos locais.

Onde aparece: treinamento de redes neurais em escala.

Otimizadores Avançados (Adam, RMSprop, AdaGrad)

Variações do SGD que adaptam a taxa de aprendizado para cada parâmetro individualmente. Adam é o mais popular e combina momentum com taxas adaptativas.

Onde aparece: praticamente todo treinamento moderno de deep learning.

Funções de Perda (Loss Functions)

A função que o otimizador tenta minimizar. As mais comuns:

• MSE (Mean Squared Error): regressão
• Cross-Entropy: classificação
• Binary Cross-Entropy: classificação binária

Escolher a função de perda certa é tão importante quanto a arquitetura do modelo.

Convexidade e Mínimos Locais

Uma função convexa tem um único mínimo — fácil de otimizar. Redes neurais têm funções de perda não-convexas com muitos mínimos locais. Entender isso explica por que técnicas como momentum e learning rate scheduling existem.

Onde aparece: design de treinamento, debugging de convergência.

5. Teoria da Informação

Conceitos da teoria da informação aparecem em funções de perda, compressão de modelos e avaliação de qualidade.

Entropia

Mede a quantidade de “surpresa” ou incerteza em uma distribuição. Uma distribuição uniforme tem entropia máxima; uma distribuição concentrada em um valor tem entropia baixa.

Onde aparece: cross-entropy loss, árvores de decisão, avaliação de modelos de linguagem.

Cross-Entropy

Mede a diferença entre duas distribuições de probabilidade. Quando usamos como função de perda, estamos medindo o quão diferente a predição do modelo é da distribuição real.

Onde aparece: a função de perda mais usada em classificação e modelos de linguagem.

KL Divergence

Onde aparece: VAEs, destilação de modelos, RLHF (o fine-tuning por feedback humano).

6. Geometria e Topologia (noções)

Distâncias e Similaridade

• Distância Euclidiana: distância “em linha reta” entre dois pontos
• Similaridade do Cosseno: mede o ângulo entre dois vetores, ignorando magnitude
• Distância de Manhattan: soma das diferenças absolutas

Onde aparece: K-NN, clustering, busca por similaridade em embeddings, RAG.

Espaços de Alta Dimensão

A intuição humana falha em dimensões altas. Fenômenos como a “maldição da dimensionalidade” — onde os dados ficam esparsos e distâncias perdem significado — são reais e afetam o design de modelos.

Onde aparece: embeddings, redução de dimensionalidade, regularização.

Roteiro de estudo sugerido

Para quem quer construir uma base sólida, sugiro esta ordem:

1. Álgebra Linear — comece aqui. Vetores, matrizes, multiplicação
2. Cálculo — derivadas, regra da cadeia, gradientes
3. Probabilidade — distribuições, Bayes, MLE
4. Otimização — gradient descent e variações
5. Teoria da Informação — entropia, cross-entropy

Recursos recomendados

• Mathematics for Machine Learning (Deisenroth, Faisal, Ong) — livro gratuito online, cobre tudo com foco em ML
• 3Blue1Brown (YouTube) — as melhores visualizações de álgebra linear e cálculo que existem
• Khan Academy — para revisar fundamentos que ficaram enferrujados
• Deep Learning Book (Goodfellow, Bengio, Courville) — capítulos 2-4 cobrem a matemática essencial

Conclusão

Você não precisa ser matemático para trabalhar com IA, mas precisa ser amigo da matemática. Entender esses conceitos transforma a experiência de “usar frameworks como caixa preta” para “entender o que está acontecendo e por quê”.

No mestrado, percebi que a maioria dos papers e técnicas novas são variações criativas desses mesmos fundamentos. Quem domina a base matemática consegue ler papers, implementar arquiteturas novas e — mais importante — saber por que algo funciona ou não funciona.

Nos últimos meses, o Claude Code se tornou uma das ferramentas mais presentes no meu fluxo de trabalho como desenvolvedor. Diferente de assistentes que funcionam dentro de IDEs com autocomplete, o Claude Code roda direto no terminal — e isso muda completamente a forma como eu interajo com ele.

Neste post, vou compartilhar como está meu setup atual, quais plugins uso, como configurei permissões e a status line customizada que me ajuda a monitorar o contexto da conversa.

O que é o Claude Code?

O Claude Code é a CLI oficial da Anthropic para o Claude. Ele funciona como um agente de engenharia de software que pode:

• Ler, criar e editar arquivos no seu projeto
• Executar comandos no terminal
• Pesquisar na web e buscar documentação
• Navegar pelo codebase com ferramentas como Glob e Grep
• Criar commits, abrir PRs e interagir com o GitHub
• Lançar sub-agentes para tarefas paralelas

A versão que estou usando atualmente é a 2.1.61.

Minha configuração (settings.json)

O coração da configuração fica em ~/.claude/settings.json. Aqui está o meu:

{
  "env": {
    "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
  },
  "permissions": {
    "allow": [
      "Bash(bin/rails test:*)",
      "Bash(bin/rails db:migrate*)",
      "Bash(bundle exec rubocop*)",
      "Bash(bun:*)",
      "Bash(foreman start)",
      "Bash(git:*)",
      "WebSearch",
      "WebFetch(domain:api.stripe.com)",
      "WebFetch(domain:qbench.net)",
      "WebFetch(domain:github.com)"
    ]
  },
  "enabledPlugins": {
    "compound-engineering@every-marketplace": true,
    "ralph-loop@claude-plugins-official": true
  },
  "skipDangerousModePermissionPrompt": true
}

Permissões

Uma das partes mais importantes do setup são as permissões pré-aprovadas. Sem elas, o Claude Code pede confirmação para cada comando executado no terminal, o que pode ser bem lento no fluxo de trabalho. Eu configurei permissões para:

• Rails: rodar testes (bin/rails test:*) e migrações (bin/rails db:migrate*)
• Rubocop: executar o linter livremente
• Bun: gerenciamento de pacotes JavaScript
• Foreman: iniciar o servidor de desenvolvimento
• Git: todos os comandos git
• Web: pesquisa na web e fetch de domínios específicos (Stripe, GitHub)

Isso me dá um equilíbrio entre produtividade e segurança — o Claude pode executar comandos comuns sem pedir permissão, mas qualquer coisa fora desse escopo ainda precisa da minha aprovação.

Agent Teams (experimental)

A variável CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS habilita o recurso de times de agentes. Isso permite que o Claude Code lance múltiplos agentes que trabalham em paralelo, se comunicam entre si e dividem tarefas complexas. É útil para projetos maiores onde diferentes partes do trabalho podem ser feitas simultaneamente.

Agent Teams + tmux: paralelismo real

Uma das combinações mais poderosas que descobri é usar Agent Teams com tmux. A ideia é simples: em vez de rodar tudo em um único painel do terminal, eu abro uma sessão tmux com múltiplos painéis e deixo cada agente trabalhando de forma visível.

Na prática, o fluxo funciona assim:

1. Abro uma sessão tmux e divido a tela em painéis
2. No painel principal, inicio o Claude Code como líder do time
3. Quando ele lança sub-agentes, cada um aparece em seu próprio processo
4. Consigo acompanhar visualmente o que cada agente está fazendo em tempo real

# Criar sessão tmux com layout para agent teams
tmux new-session -s claude -d
tmux split-window -h
tmux split-window -v
tmux select-pane -t 0
tmux split-window -v
tmux attach -t claude

Com esse layout de 4 painéis, consigo monitorar o agente principal e até 3 sub-agentes simultaneamente. É como ter um time de desenvolvedores trabalhando na sua tela.

O que torna isso prático:

• Visibilidade: vejo exatamente o que cada agente está fazendo, sem precisar esperar o resultado final
• Controle: se um agente tomar um caminho errado, posso identificar rapidamente
• Produtividade: enquanto um agente pesquisa documentação, outro pode estar editando código e um terceiro rodando testes

Um exemplo real: ao importar e traduzir 20 posts para este blog, o Claude Code dividiu o trabalho entre 3 agentes — cada um traduziu um lote de posts em paralelo. O que levaria vários minutos sequencialmente foi resolvido em uma fração do tempo.

Para quem já usa tmux no dia a dia, a integração é natural. E para quem não usa, esse é um ótimo motivo para começar.

Plugins

Atualmente uso dois plugins:

Compound Engineering (Every Marketplace)

O plugin compound-engineering adiciona uma grande quantidade de agentes especializados e skills ao Claude Code. Alguns que uso com frequência:

• Agentes de review: revisão de código com diferentes perspectivas (Rails, segurança, performance, arquitetura)
• Design Iterator: para refinar interfaces iterativamente
• Framework Docs Researcher: busca documentação atualizada de libraries
• Context7: integração com documentação e code examples atualizados de qualquer library

Ralph Loop

O plugin ralph-loop permite criar loops autônomos onde o Claude Code continua trabalhando em uma tarefa sem precisar de input constante. Útil para tarefas mais longas.

Status Line customizada

Uma das customizações que mais gosto é a status line no terminal. Ela mostra em tempo real:

• O modelo sendo usado (Opus, Sonnet, Haiku)
• O diretório do projeto atual
• O branch do git ativo
• Uma barra de progresso do contexto utilizado
• O horário atual

A configuração fica no settings.json, na chave statusLine:

{
  "statusLine": {
    "type": "command",
    "command": "<conteúdo do script abaixo>"
  }
}

O comando em si é um shell script. Para facilitar a leitura, aqui está ele formatado:

input=$(cat)

# Extrai informações do JSON de input
model=$(echo "$input" | jq -r '.model.display_name')
cwd=$(echo "$input" | jq -r '.workspace.current_dir')
dir_name=$(basename "$cwd")

# Detecta branch do git
git_info=""
if git -C "$cwd" rev-parse --git-dir > /dev/null 2>&1; then
  branch=$(git -C "$cwd" --no-optional-locks branch --show-current 2>/dev/null || echo "detached")
  git_info=" - 🌿 ${branch}"
fi

# Monta barra de progresso do contexto
progress_bar=""
remaining=$(echo "$input" | jq -r '.context_window.remaining_percentage // empty')
if [ -n "$remaining" ]; then
  used=$(echo "$input" | jq -r '.context_window.used_percentage // 0')
  used_int=${used%.*}
  bar_length=20
  filled=$((used_int * bar_length / 100))
  empty=$((bar_length - filled))
  bar=""
  for ((i=0; i<filled; i++)); do bar="${bar}█"; done
  for ((i=0; i<empty; i++)); do bar="${bar}░"; done
  progress_bar=$(printf "[\033[32m%s\033[0m] %d%%" "$bar" "$used_int")
fi

time=$(date +%H:%M:%S)

# Output: linha 1 = modelo + diretório + branch
#         linha 2 = barra de contexto + horário
printf "%s - 📁 %s%s\n%s - %s" \
  "$model" "$dir_name" "$git_info" "$progress_bar" "$time"

O Claude Code passa um JSON via stdin com informações sobre o modelo, diretório e uso de contexto. O script lê esse JSON com jq, monta uma barra visual e exibe tudo na status line.

A barra de contexto é especialmente útil: conforme a conversa cresce, o Claude Code consome mais da janela de contexto. Quando a barra está quase cheia, sei que é hora de iniciar uma nova conversa ou comprimir o contexto.

Como uso no dia a dia

Meu fluxo típico com o Claude Code:

1. Abro o terminal no diretório do projeto e digito claude
2. Descrevo a tarefa em linguagem natural — pode ser em português ou inglês
3. Reviso as mudanças que ele propõe antes de aprovar
4. Peço commits e PRs quando estou satisfeito com o resultado
5. Uso /help quando preciso lembrar de funcionalidades

Dicas práticas

• Seja específico: quanto mais contexto você der, melhor o resultado
• Use o modo plan para tarefas complexas — ele analisa o codebase antes de fazer mudanças
• Aproveite os sub-agentes: para pesquisa ou tarefas paralelas, o Claude Code pode lançar agentes especializados
• Configure permissões: poupa muito tempo não ter que aprovar cada git status
• Monitore o contexto: conversas muito longas perdem qualidade. Comece uma nova quando necessário

Conclusão

O Claude Code mudou significativamente como eu trabalho. A combinação de acesso ao terminal, leitura do codebase e capacidade de executar comandos faz dele muito mais do que um chatbot — é um par de programação que realmente entende o projeto.

Se você é desenvolvedor e ainda não experimentou, recomendo fortemente. E se já usa, invista tempo configurando as permissões e a status line — faz toda a diferença na produtividade.

Estou criando alguns posts de estudos particulares com ajuda de IA e decidi começar a compartlhar um pouco do que tenho aprendido utilizando IA.

Processos, Threads, Fibers e ActiveSupport::CurrentAttributes

Quem trabalha com Rails há algum tempo inevitavelmente esbarra em conceitos como Current.user, concorrência, vazamento de contexto e comportamentos estranhos que só aparecem em produção. Muitas vezes esses problemas são atribuídos a “Rails magic”, quando na verdade eles nascem de um entendimento incompleto sobre como o código Rails é executado em tempo de execução.

Este texto tem um objetivo simples: explicar, de forma progressiva e conectada, como processos, threads e fibers se relacionam no Rails moderno e como o framework usa essa estrutura para compartilhar contexto com segurança através do ActiveSupport::CurrentAttributes.

Processos: o primeiro nível de isolamento

Um processo é a unidade mais isolada de execução fornecida pelo sistema operacional. Quando um processo é criado, ele recebe seu próprio espaço de memória, seu próprio identificador (PID) e não compartilha variáveis, objetos ou estado com outros processos.

No contexto de Rails, isso significa que cada worker de um servidor web em modo cluster (como Puma) ou cada processo do Sidekiq roda em um processo separado. Mesmo que dois processos estejam executando o mesmo código Rails, eles não enxergam a memória um do outro. Se um processo altera um objeto em memória, os demais processos não sabem que isso aconteceu.

Uma boa analogia é pensar no processo como uma casa: tudo o que está dentro dela pertence apenas àquela casa. Outras casas podem ser idênticas, mas não compartilham móveis.

Essa característica é o motivo pelo qual nenhum estado em memória — incluindo CurrentAttributes — pode atravessar processos. Se algo precisa ser compartilhado entre processos, ele precisa ser persistido em um banco, cache externo ou fila.

Threads: concorrência dentro do mesmo processo

Dentro de um processo, o sistema operacional permite a criação de threads. Uma thread é um fluxo de execução independente, mas que compartilha a mesma memória do processo que a criou.

No Rails, cada request é atribuído a uma thread do servidor web. Em um processo Puma com múltiplas threads, vários requests podem estar sendo processados simultaneamente, todos compartilhando as mesmas classes, constantes e heap de memória.

A grande diferença entre processo e thread é que threads compartilham memória, mas não compartilham execução. Cada thread tem sua própria stack, seu próprio contador de instruções e seu próprio Thread.current. Além disso, threads são preemptivas: o sistema operacional pode interromper uma thread a qualquer momento para dar espaço a outra.

Uma analogia útil é pensar na thread como pessoas andando dentro da mesma casa. Elas compartilham os mesmos móveis, mas cada uma tem sua própria linha de pensamento e pode ser interrompida no meio de uma ação.

Essa característica é essencial para entender por que o Rails não pode usar variáveis globais simples para armazenar dados como current_user. Em um ambiente multi-thread, isso causaria vazamento de dados entre requests.

Fibers: concorrência cooperativa e previsível

Fibers são frequentemente confundidas com threads, mas elas resolvem um problema diferente. Uma fiber é uma unidade leve de execução gerenciada pelo próprio Ruby, não pelo sistema operacional. Diferente das threads, fibers não são preemptivas: elas só pausam quando o código explicitamente permite.

Fibers vivem dentro de uma thread e nunca executam em paralelo. O que elas permitem é que múltiplas operações façam progresso enquanto aguardam I/O, sem bloquear a thread inteira. Isso é especialmente útil para servidores web e sistemas que lidam com muitas operações de rede.

No Rails moderno, fibers são usadas para suportar I/O assíncrono, ActionCable, Turbo Streams e outras formas de concorrência cooperativa. O modelo real de execução passa a ser: um processo contendo várias threads, e cada thread podendo alternar entre múltiplas fibers.

Uma boa analogia é imaginar uma thread como um trilho de trem e fibers como vagões. Apenas um vagão anda por vez, mas vários podem se revezar no mesmo trilho de forma organizada e previsível.

O ciclo de vida de um request no Rails

Sistema Operacional
 └── Processo (PID)
      ├── Thread 1
      ├── Thread 2
      ├── Thread 3
      └── ...

Com esses conceitos em mente, fica mais fácil entender o request lifecycle no Rails. Quando um request chega ao servidor web, ele é atribuído a uma thread específica. Todo o código do Rails — middlewares, controllers, models, services e callbacks — executa dentro dessa thread.

Durante a execução, o Rails pode suspender e retomar a execução usando fibers, especialmente quando há operações de I/O. Mesmo assim, o contexto do request permanece associado à execução correta.

Esse detalhe é fundamental: todo request Rails sempre tem uma thread associada, mesmo quando fibers entram em cena. Fibers não eliminam threads; elas apenas permitem um uso mais eficiente delas.

ActiveSupport::CurrentAttributes: contexto atrelado à execução

O ActiveSupport::CurrentAttributes existe para resolver um problema prático: como disponibilizar dados de contexto — como usuário atual, conta, fuso horário ou request ID — em qualquer camada da aplicação sem passar parâmetros por toda parte e sem usar variáveis globais perigosas?

A solução do Rails é tratar contexto como algo associado à execução, não a objetos específicos. Internamente, o Rails armazena esses dados em um storage ligado à thread e, no Rails moderno, também integrado ao contexto de fibers por meio do ActiveSupport::ExecutionContext.

Quando você define Current.user = current_user no início do request, esse valor fica disponível em qualquer ponto do código que esteja executando naquele mesmo contexto. Models, services e callbacks conseguem acessá-lo porque estão rodando dentro da mesma thread (e fibers associadas).

Esse contexto é automaticamente limpo ao final do request. Isso é essencial porque threads são reutilizadas. Sem esse reset, dados de um request poderiam vazar para o próximo.

Até onde vai o contexto

É importante entender os limites desse mecanismo. CurrentAttributes não atravessa processos. Ele também não sobrevive a background jobs, filas ou qualquer fronteira temporal. Quando um job começa, ele roda em outro processo ou thread, com um contexto completamente novo.

Por isso, qualquer dado necessário fora do request lifecycle deve ser passado explicitamente. O Current é uma ferramenta poderosa, mas apenas dentro do escopo correto.

Leituras

O ciclo de vida de uma request por exemplo vive dentro de uma thread. O contexto é preservado no Rails através de ExecutionContext

Conclusão

Entender processos, threads e fibers não é um detalhe acadêmico: é o que permite escrever aplicações Rails previsíveis, seguras e escaláveis. ActiveSupport::CurrentAttributes funciona porque o Rails trata contexto como parte do fluxo de execução, respeitando os limites impostos pelo sistema operacional e pelo Ruby.

Quando esses conceitos estão claros, desaparecem os mistérios do tipo “funciona local, quebra em produção”. O que sobra é arquitetura, concorrência e decisões conscientes — exatamente o tipo de entendimento que diferencia quem apenas usa Rails de quem realmente o domina.

Exploring Kamal (2) and how to deploy Ruby on Rails applications to DigitalOcean (or any other cloud service) using a managed database service, i started testing some configurations/deploy and my idea now is definitely create more posts about Kamal and share more information here in my personal blog about it.

What is Kamal?

The official Kamal website says:

“Kamal offers zero-downtime deploys, rolling restarts, asset bridging, remote builds, accessory service management, and everything else you need to deploy and manage your web app in production with Docker. Originally built for Rails apps, Kamal will work with any type of web app that can be containerized.”

Why i like this?

Honestly i used Capistrano for a long time and i liked that. When I first heard Kamal described as a Capistrano-like tool for deploying containerized applications, I got pretty excited about the idea. But in my view, that’s not the best way to define it. For me, Kamal is a great tool for anyone looking to deploy containerized apps without having to rely on Kubernetes—or who just doesn’t need it.

Things to start understanding Kamal before using it

Kamal is now in version 2, here are some things i think are very important to understand.

• Docker (Containers, Orchestration)
• SSH (SSHKit)
• Reverse proxies (Kamal used Traefik in version 1 but now it uses Kamal-proxy)
• Load balances
• YAML files syntax

Managed databases vs Database container

Using Kamal you can choose adding accessories (containers) or use a managed database service we can find in multiple cloud services like AWS, GCP or DigitalOcean which i’m using right now for my apps.

I actually choose a managed database service because it’s easier to create backups, setup connections and etc, it’s all handled by the cloud service you choose. That’s the reason for me and my small apps i’ve being creating.

The example

When using Ruby on Rails 8, Kamal is by default in your app and you can check some files to see how it works.

• config/deploy.yml
• .kamal/secrets
• .kamal/hooks
• Dockerfile
• bin/docker-entrypoint

And this is my current config/deploy.yml file to deploy an app to Digital Ocean using the Digital Ocean managed database service, off course you need to create the database and droplet first. I added some comments sou you can use the file and understand what’s happening out there.

# Name of the Project
service: nice_project

# Name of the image, by default it will use DockerHub
image: joseanchieta/nice_project

# IP Servers, you can set just one or how many you want
servers:
  web:
    - 192.168.0.1

# Your DockerHub/Other service username
registry:
  username: joseanchieta
  # You can find this variable inside .kamal/secrets
  password:
    - KAMAL_REGISTRY_PASSWORD

# Secrets come from .kamal/secrets.
env:
  secret:
    - RAILS_MASTER_KEY
    - PRODUCTION_DB_HOST
    - KAMAL_REGISTRY_PASSWORD
  clear:
    SOLID_QUEUE_IN_PUMA: true

    # IP or address of the database service, this is an example using
    # Digital Ocean
    # In database.yml >> production you should have something like this:
    # production:
    #   adapter: postgresql
    #   encoding: unicode
    #   pool: <%= ENV.fetch("RAILS_MAX_THREADS") { 5 } %>
    #   database: production_database_name
    #   url: <%= ENV["PRODUCTION_DB_HOST"] %>
    DB_HOST: db-postgresql-nyc3-something123.ondigitalocean.com

# These commands are helpful, you can type in your terminal:
# kamal console
# kamal shell
# kamal logs
aliases:
  console: app exec --interactive --reuse "bin/rails console"
  shell: app exec --interactive --reuse "bash"
  logs: app logs -f
  dbc: app exec --interactive --reuse "bin/rails dbconsole"

volumes:
  - "nice_project:/rails/storage"

asset_path: /rails/public/assets

builder:
  arch: amd64

Um novo horizonte para o que pode ser feito com Rails.

Desde o início dos anúncios sobre Hotwire e Turbo, venho acompanhando e formando minhas opiniões a respeito. Confesso que de primeira, fiquei cético e achei que seria apenas mais uma coisa de Javascript para aprender, eu estava terrivelmente enganado.

Após assistir as palestras do RailsWorld realizado em Berlim no mês passado, percebi de vez que a forma como vejo o ecossistema Rails, mudou muito. Hoje existe um horizonte de possibilidades para criação de aplicações web com Rails com um cardápio grande de opções: Esbuild, ImportMaps, Hotwire, Kamal e etc. Estou bem animado com todas as alternativas que temos e que teremos em breve no ecossistema Rails.

Turbo Native

Há a algum tempo, venho acompanhando o perfil no Twitter (X) do Joe Masilotti, The turbo native guy como ele se auto proclama. Esse era o ponto no qual eu mais duvidava, “aplicativos de celular com Rails?, não me parece uma boa ideia”. Esse pensamento surgiu em mim diante de tantas discussões a respeito de React Native e Flutter, parecem duas torcidas rivais e fervorosas para provar qual a melhor tecnologia.

O Joe foi um dos palestrantes do Rails World e na minha opinião, entregou uma das melhores palestras do evento. Este post basicamente replica e acrescenta algumas considerações ao que foi visto na palestra do Joe. Deixarei o link da palestra ao final deste post e o link para o Twitter do Joe também, vale bastante a pena segui-lo.

Como funciona isso e por que?

Bom, pra quem conhece o conceito de webview em aplicações mobile, não é nada revolucionário. Resumindo de forma muito simples, é um app mobile que exibe um app web. Ou seja, teremos uma aplicação web Rails sendo exibida dentro de um app mobile, neste caso específico iOS.

Já ouvi várias coisas negativas sobre a abordagem de webview, desde que ouvi pela primeira vez sobre ferramentas como Ionic lá em 2014. Concordo com grande parte dos pontos negativos que ouvi naquela época, porém temos de levar em consideração que não estamos mais em 2014 e os devices mudaram muito, principalmente em capacidade de processamento, memória e etc.

Tendo tudo isso em mente, tenho a impressão que estamos entrando em uma nova era do desenvolvimento de software em que as pessoas estão cada vez mais pragmáticas e simplistas, isso faz parte de um conjunto de teorias, pensamentos e opiniões que venho acompanhando e que faz sentido (para mim). Acredito que muito vem dos resultados falhos de overengineering que obtivemos nos últimos anos com separação de back e front, microservices e etc sem que haja de fato um motivo real para aderir a estas técnicas.

Joe cita na palestra um outro exemplo, empresas/pessoas criando apps nativos visando performance e extrair o máximo dos devices sem que haja a necessidade real disso, ou seja, grande parte dos apps mobile não precisam extrair o máximo do aparelho, elas precisam renderizar algumas views, realizar algumas operações de crud e etc. Mais uma vez, estou de acordo com isso e pra mim o uso do Turbo Native faz sentido neste momento.

Criando o projeto

Vamos começar criando um projeto simples em Rails, o intuito do post é criar um app rails e fazer com que o mesmo apareça em um iOS simulator (infelizmente apenas para usuários de Mac, mas sinta-se a vontade para fazer o mesmo para apps Android).

rails new iosapp -T -css tailwind

Vamos adicionar apenas um scaffold ao projeto para que possamos ver o resultado no simulador do iOS.

rails g scaffold Post title body:text

Execute as migrações:

rails db:migrate

Adicione um root_path (root_url) no arquivo routes.rb:

root "posts#index"

Execute o app:

./bin/dev

Agora acesse o seu browser em localhost:3000 e crie alguns posts.

Assim está o meu app no browser após adicionar alguns estilos utilizando Tailwind:

Criando o app iOS

Neste passo é necessário ter o XCode instalado e estar utilizando um Mac. Abra o XCode, no menu principal clique em File, New, Project.

Na caixa de seleção “Choose a template for your new project” selecione iOS » App e clique em Next. Aqui você terá algumas opções para preencher que são obrigatórias, no nosso caso pode desmarcar a opção Include Tests e na caixa de Interface, selecione StoryBoard.

Acrescentando o Turbo Native como dependência do projeto

Clique no menu File novamente, encontre a opção Add Package Dependecies, clique nesta opção e selecione o Turbo Native, caso o Turbo Native não apareça para você, digite a url do github no campo Enter Package URL.

URL: github.com/hotwired/turbo-ios

O único passo necessário por agora é alterar o arquivo swift SceneDelegate que se encontra na árvore de arquivos exibida no Xcode.

O código ficará da seguinte forma:

import Turbo
import WebKit
import UIKit

let rootUrl = URL(string: "http://127.0.0.1:3000/")!

class SceneDelegate: UIResponder, UIWindowSceneDelegate {

    var window: UIWindow?
    
    private let navigationController = UINavigationController()

    private lazy var session = {
        let config = WKWebViewConfiguration()
        config.applicationNameForUserAgent = "Turbo Native iOS"
        
       let session = Session(webViewConfiguration: config)
       session.delegate = self
       return session
    }()

    // When the app launches
    func scene(_ scene: UIScene, willConnectTo session: UISceneSession, options connectionOptions: UIScene.ConnectionOptions) {
        window?.rootViewController = navigationController
        
        let proposal = VisitProposal(url: rootUrl, options: VisitOptions())
        visit(proposal: proposal)
    }
    
    // 1. Create Screen
    // 2. Push the Screen
    // 3. Render the HTML
    private func visit(proposal: VisitProposal) {
        let visitable = VisitableViewController(url: proposal.url)
        navigationController.pushViewController(visitable, animated: true)
        session.visit(visitable, options: proposal.options)
    }
 }

extension SceneDelegate: SessionDelegate{
    // Web view dies
    func sessionWebViewProcessDidTerminate(_ session: Session) {
        session.reload()
    }
    
    // Link is clicked
    func session(_ session: Session, didProposeVisit proposal: VisitProposal){
        visit(proposal: proposal)
    }
    
    // Link fails
    func session(_ session: Session, didFailRequestForVisitable visitable: Visitable, error: Error){
        print("Failed to visit: \(error.localizedDescription)")
    }
    
}

Aqui, temos algumas coisas relacionadas a navegação do app (que ficam muito bem explicadas pelo Joe no vídeo na Palestra) e logo no começo é possível ver que estamos apontando para algo no endereço localhost:3000. Sim, é aqui que indicamos ao app iOS onde buscar o seu conteúdo.

Agora vamos executar o simulador, isso pode ser feito com o atalho: Command + R

E olha só que maravilha!

Nossa aplicação Rails sendo executada como um app mobile iOS. Sensacional!

Conclusão

Este foi um pequeno exemplo de como é rápido criar um app iOS rodando uma aplicação Rails e isso é só o começo, imagina que para algumas atualizações basta apenas atualizar a aplicação Rails e isso já será refletido no App.

Considerações

Como eu disse anteriormente, isso não é a solução para todos os problemas. Mas é uma boa solução para vários. Reitero que é importante assistir a palestra do Joe, onde ele passa mais detalhes e passa até outras coisas como upload de imagens.

É isso, espero que gostem!

Referências

Palestra: Joe Masilotti - Just enough Turbo Native to be dangerous - Rails World 2023

Link para o Workshop do Joe Masilotti: Workshop

Link para Post no blog do Joe: Masilotti

Essa é uma tradução e adaptação desse artigo.

Como apreciador das obras que inspiraram esse post e como uma pessoa que sempre está em busca de um melhor desempenho, gostei bastante desse artigo que cita inclusive algumas medidas que tomei em minha vida em busca de produtividade e resolvi traduzi-lo. Espero que gostem.

Como uma função bem escrita, prefiro parar de executar cedo se nenhuma condição for válida. Então, se você discorda dessas definições e suposições, agora é um bom momento para parar de ler.

• Produtividade sustentável: A taxa máxima de produção de trabalho de qualidade, sem prejuízo para o bem-estar do desenvolvedor.

• Trabalho de qualidade: software que atende aos requisitos, é valioso para os usuários, pode ser mantido e é o mais livre de bugs possível.

• Atenção: A capacidade mental limitada de se concentrar em uma tarefa.

• A produtividade sustentável é desejada.

• Atenção é essencial para a produtividade sustentável.

Meu fluxo mais produtivo de trabalho é mais ou menos assim: identificar o problema a ser resolvido; pense no problema e deixe as idéias se infiltrarem; pesquise, discuta e experimente essas idéias; implementar e testar a solução; entregar e manter a solução.

Este ciclo pode se repetir muitas vezes ao dia. Ou eu poderia passar dias preso em uma única etapa do ciclo. Cada etapa deste ciclo requer atenção. Quanto mais atenção posso dedicar, mais ciclos posso concluir e mais produtivo sou.

Por quanto tempo você pode se concentrar em uma tarefa varia de pessoa para pessoa. Algumas pessoas são muito boas logo de cara, outras nem tanto. Independente das suas características, acredito que o foco (o ato de priorizar sua atenção) é uma habilidade e, como qualquer habilidade, pode ser melhorada com a prática.

Então, como você pode aumentar suas reservas de atenção? O melhor retorno para seu investimento é organizar seu mundo exterior de forma que seja o mais livre possível de distrações. Depois de fazer isso, você terá mais tempo para praticar e, portanto, mais tempo para melhorar.

Construa força física. O dano causado por ficar sentado 8 horas ou mais por dia é subestimado. Você precisa encontrar uma maneira de compensar esses danos, especialmente se planeja trabalhar nessa área por décadas. Se você não fizer mais nada, faça levantamento de peso. Existem poucos movimentos mais primitivos do que pegar um objeto pesado do chão e levantá-lo. Você pode aprender a técnica correta em minutos. Eu gosto mais de levantamento de peso porque você pode fazê-los com segurança, com pesos elevados, até ficar cansado. Também gosto da força das mãos, das costas e do quadril que eles proporcionam, para dificultar ainda mais os danos ao sentar-se.

Torne o seu local de trabalho enfadonho e organizado. Meu escritório é um quarto extra. As paredes estão vazias. Não há TV. Há uma mesa, cadeira, laptop, suporte para laptop, teclado, mouse e mouse pad. Há uma janela que permite a entrada de luz suficiente para que eu não sinta que estou perdendo um dia lindo, mas não muita luz para causar brilho na tela. Se eu precisar trabalhar com papel, ele é imediatamente arquivado em algum lugar quando terminar. Como eu disse, chato e arrumado.

Deixe seu smartphone mudo. Meu telefone está com todas as notificações desabilitadas, exceto para chamadas e mensagens de texto. Bem, e alertas do National Hurricane Center, já que moro na Louisiana. A menos que você seja minha esposa, você sabe que eu não respondo a mensagens de texto imediatamente, é assim que as coisas são. Desativei minhas contas de mídia social há algum tempo. Mas, se você os tiver, desligar as notificações deve ajudar a diminuir o desejo de verificá-los compulsivamente.

Tenha um sistema operacional minimalista. Os aplicativos que uso com menos frequência estão a uma combinação de teclas de distância. Diante disso, meu dock tem apenas os aplicativos que uso diariamente:

• Sistema de arquivos
• Browser
• Terminal
• Editor de texto para código de front-end e notas
• IDE para código de back-end
• IDE para banco de dados
• Visualizador de diferenças em arquivos para controle de versão
• Cliente de email
• Cliente de mensagem instantânea

Minha área de trabalho alterna entre os estados limpo e sujo. Arquivos com os quais estou trabalhando no momento na área de trabalho. Em seguida, eles são arquivados em pastas adequadas quando concluídos.

Organize os favoritos do seu navegador. Quando leio algo útil que talvez precise consultar mais tarde, eu deixo arquivado em uma pasta geral. Em seguida, itens mais específicos obtêm suas próprias pastas. Os links acessados ​​com frequência ficam visíveis na minha barra de favoritos em sua própria pasta.

Minimize as reuniões. Olha, eu sei que algumas coisas fazem sentido discutir cara a cara, ou voz a voz. Mas se não, você não precisa de uma reunião. Um e-mail ou mensagem instantânea será suficiente.

Finalmente, use o Método Eisenhower para categorizar suas tarefas. Imagine 4 categorias:

• Importante e Urgente
• Importante e Não Urgente
• Não Importante e Urgente
• Não Importante e Não Urgente

Tarefas Importantes e Urgentes precisam ser tratadas. Para mim, esses são geralmente os principais problemas de produção.

Tarefas Importantes e não Urgentes devem absorver a maior parte do seu tempo. Para mim, este é o velho trabalho de desenvolvimento de implementar recursos, corrigir bugs e tornar o código existente mais fácil de manter e melhorar seu desempenho. Também estão incluídos a construção de relacionamentos com outras pessoas e o planejamento futuro.

Tarefas Não Importantes e Urgentes são ladrões de atenção desagradáveis. Eles gritam com você imediatamente, mas oferecem pouco valor em troca. Você deve saber do que estou falando. Para mim, essas são na maioria das vezes perguntas mal feitas por outras pessoas, que exigem mais trabalho para determinar o que está realmente sendo perguntado, em vez de descobrir qual deveria ser a resposta. Também estão incluídas reuniões de última hora e colegas de trabalho muito faladores.

As tarefas Não Importantes e Não Urgentes geralmente não são conhecidas por seus usuários. Ler atualizações da documentação de um projeto por exemplo. O fato é que eles são um investimento em você mesmo, o que significa um “você” mais produtivo no futuro. Portanto, não se esqueça de se dedicar a eles um pouco em seus momentos de folga.

Leitura adicional. Se você não sabe quem é Cal Newport, está perdendo. Ele tem um blog inteiro dedicado a esse tipo de coisa, e já escreveu livros como Deep Work e Digital Minimalism. Aqui estão alguns dos meus artigos favoritos dele:

• Have We Lost Our Tolerance For a Little Boredom?
• Is Allowing Your Child to Study While on Facebook Morally Irresponsible?
• Monday Master Class: How to Reduce Stress and Get More Done By Building an Autopilot Schedule
• Are Passions Serendipitously Discovered or Painstakingly Constructed?
• Jerry Seinfeld’s Closed Door

Em primeiro lugar, pensar no lado humano não é desencorajar a fazer code review, pelo contrário, estou apenas alertando para possíveis problemas causados pelo code review quando feito sem estar consciente de alguns fatores. Fatores estes que estão mais ligados a parte humana do que a parte técnica.

Algumas premissas do code review ficaram fixas na minha cabeça depois de passar por algumas equipes muito boas em fazer code review e outras nem tanto, de qualquer forma o meu objetivo em relação aos code reviews e várias outras coisas da vida é fugir da superficialidade e dar contexto ou um sentido para as minhas ações, então vamos a algumas lições que aprendi:

O principal objetivo e a razão

Algumas vezes podemos esquecer disso, mas o principal objetivo de um code review é manter a qualidade do código, consequentemente melhorando a qualidade/confiabilidade do projeto. Quando se está fixado na mente que o principal objetivo é a qualidade do projeto, cria-se uma missão em comum com os seus colegas de equipe, que gera companheirismo e empatia.

Sempre que for revisar o código de alguém, lembre-se desse objetivo, é comum o code review acabar virando apenas uma crítica sem um objetivo, ou seja, quando uma crítica é feita com uma razão forte, provavelmente, será melhor aceita, já quando feita apenas pensando em código e sem empatia alguma por quem fez, existe uma grande probabilidade que se torne uma coisa desagradável, até mesmo tenha um tom ríspido ou agressivo, o que não traz benefício algum para a equipe.

Assim penso, acima de code reviews e lutas de ego entre programadores, está o bom relacionamento e sintonia entre a equipe. Hoje tenho uma certeza, prefiro trabalhar em empresas que se importam mais com o bom relacionamento dos colaboradores do que com as críticas feitas nos code reviews, já que tenho uma impressão (quase certeza) de que esses ambientes acabam entregando melhores produtos aos seus clientes e são ambientes muito melhores para se trabalhar e crescer como pessoa, além de fazer com o que os colaboradores sintam vontade de permanecer por anos e anos nesses lugares.

Empatia, enviando a mensagem

A empatia é o elo que liga uma crítica a um ambiente cordial e respeitoso entre colegas de equipe. Tive companheiros de equipe que faziam críticas tão boas e de uma forma tão sutil que eu tinha vontade de recebe-las todos os dias (várias vezes aos dias), por sentir que aquilo estava me fazendo evoluir como programador e como pessoa. Ao ver a cordialidade embutida na crítica, aquilo acabava me contagiando e criando um efeito dominó, eu sentia vontade de tratar os meus colegas com toda aquela gentileza que recebi através de críticas. Isso não tem preço.

Por outro lado, quando a empatia não faz parte das peças do jogo, o mais comum é que se crie um ambiente de disputa, nada cordial e até agressivo. Não consigo enxergar de que forma isso traz benefícios para a equipe ou empresa, já que o maior patrimônio das empresas, são as pessoas e não o código. Se as pessoas não estão pensando no seu colega antes de fazer uma crítica, já existe um erro que deveria ser revisado antes mesmo do code review.

Foco no problema, recebendo a mensagem

Do outro lado da ponta está o receptor, quem recebe a mensagem precisa estar preparado e adaptado ao pensamento de que críticas construtivas te fazem evoluir, e isso é tão importante quanto a forma com a mensagem é enviada. Não adianta enviar uma mensagem cordial e gentil se do outro lado é entendida como um “jab de direita”. Focar sempre nos problemas e não em pessoas é um bom exercício para se tornar um expert em receber críticas e transforma-las em um degrau na sua evolução.

Conlusão

Sempre estou me fazendo algumas perguntas como:

• Estou fazendo o meu melhor?
• Estou pensando no meu colega?
• Estou usando as melhores palavras?
• Estou pensando em todo o contexto?

Essa auto-reflexão te deixa mais consciente para não enviar uma mensagem ou receber recebe-la de uma forma errada. Cautela sempre é bom, pensar no próximo é melhor ainda, esses são ingredientes de um bolo que sempre corre riscos de não ficar bom, porém se utilizar os ingredientes certos e fizer com carinho, a chance de dar errado diminui muito. Graças a minha esposa, aprendi isso.

Pra mim, a mesma coisa vale para code reviews, os ingredientes são bem conhecidos e são fáceis de encontrar, basta saber dosar e sempre jogar duas xícaras de chá cheias de empatia que o risco do bolo ficar murcho ou sem sabor, é bem menor.

É isso, dattebayo.

Já faz um tempo que minha curiosidade sobre linguagens funcionais vem aumentando, li a respeito e vi vários vídeos sobre Scala, OCaml, GO, Clojure e Elixir. Todas me parecem ter algum aspecto interessante e que vale a pena estudar, porém por vir do mundo Ruby o Elixir acabou vencendo na escala de interesse e curiosidade.

Tenho visto nas minhas newsletters várias vagas Ruby/Elixir e isso é uma vantagem por estar um pouco conectado com a minha rotina atual, então comprei alguns cursos na Udemy e comecei a assistir algumas aulas.

Em um dos cursos, tinha um projeto FizzBuzz (algorítmo conhecido em exercícios) usando Elixir e as primeiras impressões sobre a linguagem foram ótimas, algumas coisas como pattern matching e pipe operator chamam a atenção logo de cara.

Além disso a facilidade de criar projetos como esse utilizando o mix é bem interessante. Criando um projeto elixir usando o mix por padrão algumas coisas bem legais já estarão presentes como testes.

A possibilidade de replicação de funções para tratar casos diferentes é uma coisa que me deixou “com a orelha em pé”, ainda não decidi se acho isso bom ou ruim, mas ao menos é bem interessante.

Outra coisa muito boa da linguagem é o uso constante dos módulos e a aridade das funções, já percebi que são coisas que não se vive sem quando se está programando em Elixir.

Aqui está o código do mini-projeto FizzBuzz, sem dúvidas pretendo continuar meus estudos na linguagem e adiciona-la as minhas ferramentas, quem sabe até se tornar minha linguagem número 1, vejo muito potencial pra isso.

Cursos na Udemy

• Programação Funcional com Elixir - Jackson Pires
• Elixir e Phoenix do zero! Crie sua primeira API Phoenix. - Rafael F. Camarda

Uma das ultimas novidades acrescentadas ao ecossistema do Rails é o framework ActionText, e nesse post vou falar um pouco sobre o meu primeiro contato com essa nova ferramenta que trás uma boa alternativa na edição e criação de textos ricos, além de upload de conteúdo direto para o ActiveStorage no melhor estilo WYSIWYG. Nesse caso utilizando o Trix editor, ferramenta desenvolvida pela Basecamp, empresa do DHH.

Versões

• Ruby 2.7.1
• Rails 6

Novo Projeto Rails 6

rails new texts -T
cd texts
bundle install
rails db:create

Gerando um novo Posts scaffold

rails g scaffold Post title
rails db:migrate

Talvez soe estranho adicionar apenas o título aqui, mas o conteúdo do post virá através do ActionText que terá sua prṍpria estrutura de dados. Também vou definir a index/posts como rota padrão no arquivo routes.rb

Rails.application.routes.draw do
  resources :posts
  root "posts#index"
end

Instalando ActionText

rails action_text:install

Adicionando Rich Text aos posts

Depois de instalado o action_text, agora de volta ao código do projeto, basta adicionar a referência de um novo campo com “texto rico” ao models/post.rb, vou chamar esse campo de body, mas poderia ser content ou qualquer outro nome apropriado.

class Post < ApplicationRecord
  has_rich_text :body
end

Pra conseguir passar os valores do campo body é necessário permitir esse valor no controllers/posts_controller.rb

class PostsController < ApplicationController
  # implementation

  def post_params
    params.require(:post).permit(:title, :body)
  end
end

Consequentemente será necessário acrescentar o novo campo também no formulário dos posts em views/posts/_form.html.erb…

<div class="field">
  <%= form.label :body %>
  <%= form.rich_text_area :body %>
</div>

…e no arquivo views/posts/show.html.erb pra exibir o conteúdo do campo body.

<div class="body">
  <%= @post.body %>
</div>

Migrando

É necessária uma nova migração, já que o model Post agora terá um novo rich_text field.

rails db:migrate

Testando

rails server

Extra

Para fazer uploads de imagem pra dentro do editor, pode ser necessário instalar o Image Magick na sua máquina pra que tudo funcione corretamente.

Além disso, descomente a seguinte linha no seu Gemfile:

gem 'image_processing', '~> 1.2'

e depois instale a biblioteca caso ainda não tenha feito:

bundle install

That’s it!

Pra quem conheceu o Rails com aquela jogada de “Crie um blog em n minutos”, a introdução do ActionText dá a impressão que a ideia agora é criar um blog em segundos, rs.

Voltando a ler algumas coisas da época da faculdade e tentando aprender coisas novas sobre algoritmos e estruturas de dados, me deparo com um dos primeiros conceitos que vemos ao entrar na área de programação: Recursividade.

Traduzindo de uma forma bem grosseira e comum, Recursividade é quando uma função chama a si própria. Alguns exemplos bem comuns são os algoritmos da Sequência de Fibonacci e Cálculo Fatorial. Mas vai um pouco além disso, também é importante conhecer sobre a Pilha de chamada e como o computador aloca valores através das chamadas de funções na memória.

Particularmente, sempre vi Recursividade como um bom exercício para estudar algoritmos, mesmo que em alguns casos um simples loop seja suficiente pra resolver um problema, porém utilizando Recursividade uma nova carta na sua manga é adicionada ao entender bem esse conceito, pra isso vamos a alguns exemplos:

1 - Somar todos os números de um array utilizando Recursividade.

Dado um array de números inteiros, vamos somar todos os itens e retornar o valor da soma.

def soma_array(arr)
  if arr.size <= 1
    return arr[0]
  else
    return arr.slice!(0) + soma_array(arr)
  end
end

Aqui fiz apenas uma verificação pra saber se o tamanho do array recebido é menor ou igual a 1, caso seja, retorne o primeiro e único item do array. Caso o tamanho do array seja maior que 1, retorne uma soma do primeiro item do array mais uma nova chamada da função. Dessa forma, temos o nosso primeiro exemplo de recursividade.

Então, pra entender melhor, vamos analisar o que acontece aqui utilizando um exemplo de um array [1, 2].

arr = [1, 2]

soma_array(arr)

# => 3

Na primeira vez que a função for executada, o array possui 2 itens, 1 e 2. Então cai na condição do Else por ter mais de um item. Nessa condição eu executo um slice!(0), ou seja, removo o primeiro item do array, no caso o número 1 e chamo novamente a função soma_array, então algo como:

1 + soma_array([2])

E agora ao ser executada novamente o array possui apenas um item, então a função retorna o número 2, voltando ao contexto da primeira chamada da função:

1 + 2

# => 3

A mesma coisa acontece caso o array possua vários itens.

2 - Fatorial (n!)

Fatorial é um número natural inteiro positivo, o qual é representado por n!

O fatorial de um número é calculado pela multiplicação desse número por todos os seus antecessores até chegar ao número 1. Note que nesses produtos, o zero (0) é excluído.

O fatorial é representado por:

n! = n . (n – 1) . (n – 2) . (n – 3)!

Referência

Sabendo agora um pouco sobre fatorial, vamos escrever uma função que execute isso de forma recursiva.

def fatorial(number)
  if number == 1
    return 1
  else
    return number * fatorial(number - 1)
  end
end

Então se utilizarmos o número 3 como parâmetro, teremos o seguinte:

fatorial(3)

# => 6

Como nosso argumento é 3, faremos uma multiplicação 3 x (3-1) através da primeira chamada recursiva da função e em seguinda uma outra multiplicação na segunda chamada recursiva, ficando um cálculo parecido com esse na visão do computador:

(3 * (3-1)) * (2-1)

Lendo o livro Entendendo algoritmos, pude analisar as chamadas de uma função recursiva como uma pilha de caixas, conhecida como Pilha de chamadas. No caso a primeira chamada com o número 3 é guardada em memória, em seguida a chamada com o número 2 e por ultimo com o número 1, dessa forma as caixas vão sendo removidas até voltar ao contexto original da primeira chamada da função.

3 - Sequência de Fibonacci

Talvez o exemplo mais comum quando o assunto é recursividade, principalmente em faculdades.

Sequência de Fibonacci é a sequência numérica proposta pelo matemático Leonardo Pisa, mais conhecido como Fibonacci:

1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, …

Foi a partir de um problema criado por ele que o mesmo detectou a existência de uma regularidade matemática.

Trata-se do exemplo clássico dos coelhos, em que Fibonacci descreve o crescimento de uma população desses animais.

A sequência é definida mediante a seguinte fórmula:

Fn = Fn - 1 + Fn - 2

Referência

Então, vamos criar esse ultimo exemplo em Ruby, lembrando que existem várias maneiras de transformar esses conceitos em código.

def fib(number)
  number <= 1 ? number : fib(number - 1) + fib(number - 2)
end

Aqui decidi utilizar a praticidade do Ruby em retornar a ultima expressão de um escopo pra fazer a função fib. Podemos ver que a condicional analisa se o número recebido é menor ou igual a 1, caso seja retorne o número, caso não, faça uma soma utilizando a mesma função duas vezes, a primeira parte utilizando o number - 1 e a segunda o number - 2 como descrito na fórmula da sequência de Fibonnaci.

É isso, até a próxima.