Ruby on Rails 8 chegou trazendo uma série de melhorias e novidades que prometem tornar o desenvolvimento web ainda mais eficiente e produtivo. Neste artigo, exploraremos as principais mudanças introduzidas nesta nova versão e forneceremos dicas valiosas para ajudar você a atualizar seus sistemas antigos para o Rails 8.

Sumário

1. Introdução
2. Principais Novidades do Rails 8
   • Active Support
   • Active Model
   • Active Record
   • Action View
   • Action Pack
   • Active Job
   • Railties
3. Dicas para Atualizar Sistemas Antigos para o Rails 8
4. Conclusão

Introdução

Ruby on Rails é um dos frameworks web mais populares, conhecido por sua filosofia de "convenção sobre configuração" e por acelerar o processo de desenvolvimento. A versão 8 do Rails traz aprimoramentos significativos em diversas áreas, desde melhorias de desempenho até a introdução de novos recursos que facilitam a vida dos desenvolvedores.

Neste artigo, vamos nos aprofundar nas principais novidades do Rails 8 e oferecer orientações práticas para atualizar aplicações existentes, garantindo uma transição suave para esta nova versão.

Principais Novidades do Rails 8

Active Support

1. Remoção de Funcionalidades Obsoletas

• Arrays em ActiveSupport::Deprecation#warn: O suporte a passagem de um array de strings para ActiveSupport::Deprecation#warn foi removido, incentivando o uso de mensagens de depreciação mais claras.
• Formato de Nomeação de Atributos Internos: O suporte a attr_internal_naming_format com prefixo @ foi eliminado, padronizando a forma como os atributos internos são nomeados.
• ActiveSupport::ProxyObject: Esta classe foi removida, simplificando a hierarquia de objetos proxy.

2. Otimizações de Desempenho

• Watcher de I18n: O watcher de internacionalização não é mais executado durante o boot da aplicação, o que melhora o tempo de inicialização, especialmente em aplicações com muitas traduções.
• HashWithIndifferentAccess: O método stringify_keys agora converte todas as chaves em strings, não apenas símbolos, corrigindo comportamentos inesperados.

3. Melhorias em Instrumentação e Logging

• Instrumentação de Cache: Os métodos delete e delete_multi de ActiveSupport::Cache::Store agora incluem opções ao serem instrumentados, fornecendo mais contexto durante o monitoramento.
• Exibição de Nomes de Testes: Ao executar testes com rails test -v em modo paralelo, os nomes dos testes são exibidos, facilitando a identificação.

Active Model

1. Novas Opções de Validação

• Token Padrão para Reset de Senha: A introdução de um gerador de token padrão facilita a implementação de funcionalidades de reset de senha usando has_secure_password.

:except_on: Agora é possível usar :except_on em validações para especificar contextos nos quais a validação deve ser ignorada. Por exemplo:

class User < ApplicationRecord
  validates :birthday, presence: { except_on: :admin }
end

Active Record

1. Melhorias em Migrações e Esquemas

• Carregamento de Seeds: O task db:prepare não carrega mais seeds ao criar um banco de dados não primário, evitando perda potencial de dados em ambientes existentes.

Suporte a Várias Tabelas em drop_table: Agora é possível passar um array de nomes para drop_table, permitindo a remoção de múltiplas tabelas em uma única chamada.

ActiveRecord::Base.connection.drop_table(:users, :posts)

2. Novas Funcionalidades em Consultas

• Otimizações em in_order_of: Adicionada a opção de filtro para priorizar certos valores na ordenação sem filtrar os resultados.
• Suporte a Hashes em pluck: pluck agora aceita argumentos de hash com valores de símbolos e strings, aumentando a flexibilidade nas consultas.

3. Melhorias em Tipos e Colunas

• Distinção entre float4 e float8 no PostgreSQL: Agora o Active Record distingue corretamente entre os tipos de ponto flutuante do PostgreSQL.
• Depreciação de Métodos: Os métodos unsigned_float e unsigned_decimal foram depreciados, seguindo as mudanças no MySQL 8.0.17.

Action View

1. Renomeação de Métodos

• text_area para textarea: Os métodos text_area foram renomeados para textarea para alinhar com as convenções HTML. Os nomes antigos ainda estão disponíveis como aliases.
• check_box para checkbox: Similarmente, os métodos check_box foram renomeados para checkbox.

2. Melhorias no DependencyTracker

• Renderização com Interpolação: O DependencyTracker agora avalia corretamente renders com interpolação, garantindo que todas as dependências sejam rastreadas.

Action Pack

1. Atualizações em Rotas

• Correção em Rotas com ::: Problemas em rotas contendo :: foram corrigidos, permitindo rotas mais complexas.
• Argumentos Inválidos em Recursos: Agora, passar opções inválidas como :only ou :except em resource e resources gera um ArgumentError, ajudando a identificar erros de configuração.

2. Novos Métodos de Parâmetros

params#expect: Introduzido um método mais seguro e explícito para manipulação de parâmetros, substituindo params.require e params.permit.

params.expect(person: [:name, :age, pets: [[:name]]])

3. Melhorias em Testes

• Atualização de Cookies em Requisições Não-GET: Correção em ActionController::TestCase para garantir que cookies sejam atualizados corretamente em requisições de outros métodos HTTP.

Active Job

1. Atualizações em Adaptadores

• Depreciação do sucker_punch: O adaptador sucker_punch foi depreciado. Recomenda-se o uso de adapter: async para funcionalidade semelhante.
• Uso de RAILS_MAX_THREADS: O ActiveJob::AsyncAdapter agora utiliza RAILS_MAX_THREADS, com valor padrão de 5 se não definido.

Railties

1. Novos Geradores e Configurações

Script Generator: Adicionada uma pasta script e um gerador de scripts para facilitar a criação de scripts únicos ou de propósito geral.

bin/rails generate script my_script

Gerador de Autenticação: Um novo gerador para iniciar um sistema básico de autenticação usando sessões e reset de senha.

bin/rails generate authentication

2. Alterações em Configurações Padrão

• Uso do Solid Cable e Solid Queue: O Rails 8 agora usa o Solid Cable como adaptador padrão do Action Cable e o Solid Queue como backend padrão do Active Job, ambos configurados para melhorar o desempenho sem depender de Redis.

3. Melhorias em Desempenho

• Deferimento de Rotas: O carregamento das rotas é adiado para a primeira requisição ou quando url_helpers são chamados, melhorando o tempo de boot em aplicações maiores.

Dicas para Atualizar Sistemas Antigos para o Rails 8

Atualizar uma aplicação existente para uma nova versão do Rails pode ser desafiador. Aqui estão algumas dicas para facilitar esse processo:

1. Leia as Notas de Versão: Antes de iniciar, leia cuidadosamente as notas de versão do Rails 8 para entender todas as mudanças e depreciações.
2. Atualize Gradualmente: Se sua aplicação está em uma versão muito antiga, considere atualizar para versões intermediárias primeiro (por exemplo, do Rails 5 para o 6, depois para o 7, e finalmente para o 8).
3. Teste Extensivamente: Utilize uma suíte de testes abrangente para garantir que as funcionalidades existentes continuem operando conforme esperado após a atualização.
4. Revise Depreciações: Procure por avisos de depreciação ao executar sua aplicação e atualize o código conforme necessário.
5. Atualize Dependências: Certifique-se de que todas as gemas e bibliotecas externas sejam compatíveis com o Rails 8, atualizando-as para versões mais recentes quando necessário.
6. Verifique Configurações Personalizadas: Se você personalizou configurações ou utilizou APIs internas, revise essas áreas cuidadosamente, pois elas podem ter mudado.
7. Considere as Novas Funcionalidades: Aproveite a atualização para refatorar partes da aplicação que podem se beneficiar das novas funcionalidades introduzidas no Rails 8.
8. Planeje Tempo Adequado: Reserve tempo suficiente para a atualização, testes e possíveis correções de bugs que possam surgir.
9. Colabore com a Equipe: Envolva outros desenvolvedores do seu time no processo de atualização para compartilhar conhecimentos e agilizar a resolução de problemas.
10. Faça Backup: Sempre faça backup do banco de dados e do código antes de iniciar o processo de atualização.

Conclusão

O Ruby on Rails 8 traz avanços significativos que podem melhorar a eficiência e a produtividade no desenvolvimento web. Com novas funcionalidades, otimizações de desempenho e melhorias na segurança, é uma atualização que vale a pena considerar.

Ao planejar e executar cuidadosamente a atualização de sistemas antigos, você pode aproveitar ao máximo os benefícios desta nova versão, garantindo que sua aplicação permaneça moderna, segura e eficiente.

Esperamos que este artigo tenha fornecido insights valiosos sobre as novidades do Rails 8 e orientações úteis para facilitar o processo de atualização. Mantenha-se sempre atualizado com as últimas tendências e boas práticas para continuar desenvolvendo aplicações web de alta qualidade.

Aqui estão alguns passos e notas para a atualização de uma configuração de servidor único do Kamal para o novo Kamal 2.

1. Atualizar para o Kamal 1.9.x

Primeiro, atualize para o Kamal 1.9 e confirme se ainda consegue realizar o deploy:

$ gem install kamal --version 1.9.0
$ kamal config
$ kamal deploy

2. Atualizar para o Kamal 2

Atualize novamente a versão do Kamal para um lançamento 2.x:

$ gem install kamal --version 2.1.0

Não realize o deploy ainda.

3. Remover referências ao Traefik

Remova a seção Traefik de config/deploy.yml:

traefik:
  options:
    publish:
      - "443:443"
    volume:
      - "/letsencrypt/acme.json:/letsencrypt/acme.json"
    network: "private"
  ...

E remova qualquer outra referência ao proxy, como rótulos traefik.* em qualquer lugar.

4. Remover a seção de verificação de saúde (healthcheck)

Remova as configurações antigas de healthcheck de config/deploy.yml:

healthcheck:
  # path: /up
  # port: 3000
  interval: 5s

5. Atualizar a configuração do builder

Remova a opção multiarch e especifique uma ou mais arquiteturas com arch (as opções são amd64 e arm64):

builder:
  arch: 
    - amd64
    - arm64

Você provavelmente usará amd64. Pode manter as configurações de cache.

Consulte o guia oficial para builders remotos.

6. Adicionar as novas configurações de proxy

Adicione configurações semelhantes de Kamal Proxy de acordo com suas necessidades:

proxy:
  ssl: true
  host: tubeandchill.com
  app_port: 3000
  healthcheck:
    path: /up
    interval: 3
    timeout: 30

Se você estava emitindo certificados TLS com o Traefik, agora pode substituí-lo definindo ssl como true e especificando seu host. Caso contrário, pode pular esta etapa.

O caminho de healthcheck permaneceu o mesmo em /up, mas você pode precisar removê-lo das verificações de SSL ou hostname:

# Ignora redirecionamento de http para https para o endpoint padrão de healthcheck.
config.ssl_options = { redirect: { exclude: ->(request) { request.path == "/up" } } }

# Ignora proteção de reatribuição de DNS para o endpoint padrão de healthcheck.
config.host_authorization = { exclude: ->(request) { request.path == "/up" } }

A porta da aplicação agora está definida para 80 (era 3000). Altere-a de volta para 3000 ou atualize seu Dockerfile para usar a porta 80.

7. Criar novo arquivo de secrets

O Kamal mudou a forma como os secrets funcionam. Antes de explorar as novas opções de secrets, você pode simplesmente mover os antigos:

$ cp .env .kamal/secrets

Isso significa que .kamal/secrets também não pode ser incluído no controle de versão, então adicione-o ao .gitignore.

Você pode explorar os novos secrets em mais detalhes na documentação.

Observe que não há mais conversão de .env.erb ou kamal push env. Todos foram removidos.

8. Verificar novamente sua configuração

Verifique sua nova configuração executando o comando kamal config:

$ kamal config

Se você estava usando redes Docker personalizadas para comunicação de acessórios, não as remova ainda. Somente se você as nomeou como kamal, remova-as da configuração para evitar conflitos.

9. Executar a atualização in-place

Faça o primeiro deploy do Kamal 2 executando uma atualização:

$ kamal upgrade

Isso fará várias coisas, como remover o Traefik, criar a rede Docker do Kamal, alternar para o Kamal Proxy, reiniciar a aplicação e, finalmente, reiniciar os acessórios.

10. Remover redes Docker personalizadas

Agora você pode remover sua rede Docker personalizada, pois tudo pode ser executado com a nova rede do Kamal.

Você pode reiniciar sua aplicação e acessórios para aplicar essa última mudança:

$ kamal deploy
$ kamal accessory reboot [ACCESSORY]

11. Corrigir falhas na atualização

Lembre-se de que, se a atualização substituir o proxy, mas falhar posteriormente, você pode corrigir o problema subjacente e continuar fazendo o redeploy da aplicação ou reiniciando os acessórios.

O Git é uma ferramenta essencial de controle de versão para desenvolvedores. Embora ferramentas GUI possam simplificar algumas tarefas, dominar a linha de comando do Git oferece um controle mais profundo, flexibilidade e velocidade. Aqui estão 20 truques de linha de comando do Git que todo desenvolvedor deve conhecer para otimizar seu fluxo de trabalho.

Resetar um Arquivo para o Último Commit
Descarte as alterações locais em um arquivo específico.

git checkout -- path/to/file

Responsabilizar uma Linha de Código
Descubra quem escreveu uma linha específica em um arquivo.

git blame path/to/file

Buscar Apenas Metadados
Quer evitar baixar todo o repositório?

git fetch --dry-run

Isso permite ver o que seria buscado sem realmente baixar os dados.

Reverter um Commit Já Enviado
Desfaça as alterações de um commit específico sem alterar o histórico.

git revert <commit-hash>

Editar o .gitignore Após Fazer Commit
Se esqueceu de ignorar certos arquivos, atualize o .gitignore.

echo "node_modules/" >> .gitignore
git rm -r --cached node_modules/
git commit -m "Atualizar .gitignore"

Visualizar o Arquivo em um Commit Específico
Veja o estado de um arquivo em um commit específico.

git show <commit-hash>:path/to/file

Combinar Commits com Rebase Interativo
Combine vários commits em um só.

git rebase -i HEAD~n  # Substitua 'n' pelo número de commits

Rastrear um Branch Upstream
Mantenha seu branch local em sincronização com um branch remoto.

git branch --set-upstream-to=origin/main

Limpar Arquivos e Diretórios Não Rastreáveis
Remova rapidamente arquivos indesejados que não são rastreados pelo Git.

git clean -fd

💡 Use -n para uma simulação antes de remover de fato.

Listar Todos os Branches (Locais e Remotos)
Veja quais branches estão disponíveis.

git branch -a

Cherry-Pick de Commits Específicos
Quer trazer um commit específico de outro branch?

git cherry-pick <commit-hash>

Rebase para um Histórico de Commits Limpo
O rebase reescreve o histórico de commits para maior clareza.

git rebase -i HEAD~3

Isso permite editar, combinar ou reordenar seus últimos 3 commits.

Encontrar um Bug com Bisect
Use git bisect para encontrar o commit que introduziu um bug.

git bisect start
git bisect bad  # O commit atual está com problema
git bisect good <commit-hash>  # Um commit conhecido como bom

O Git percorrerá o histórico de commits para identificar o commit problemático.

Verificar Diferenças nas Alterações em Estágio
Use git diff para comparar arquivos em diferentes estágios.

git diff --staged

Isso mostra as alterações que estão em estágio, mas ainda não foram commitadas.

Alterar o Autor do Commit
Mude o autor do último commit.

git commit --amend --author="Novo Autor <novautor@exemplo.com>"

Visualizar o Histórico de Commits Graficamente
Visualizar o histórico de commits facilita entender o estado do projeto.

git log --graph --oneline --all

Guardar Alterações Não Cometidas
Precisa mudar rapidamente de branch sem fazer commit?

git stash

💡 Recupere o stash mais tarde com:

git stash pop

Emendar o Último Commit
Esqueceu de incluir uma alteração ou deseja atualizar a mensagem do commit?

git add .
git commit --amend -m "Mensagem de commit atualizada"

Isso atualiza o commit anterior sem criar um novo.

Desfazer o Último Commit (sem perder alterações)
Se você cometeu um erro no último commit, pode desfazê-lo.

git reset --soft HEAD~1

Isso deixa suas alterações em estágio, permitindo emendar o commit ou corrigir o problema.

Configurar Configuração Global
Garanta que seus commits estejam vinculados à identidade correta.

git config --global user.name "Seu Nome"
git config --global user.email "voce@exemplo.com"

💡 Dica: Use --local em vez de --global para definir configurações específicas do projeto.

Esses 20 truques de linha de comando do Git podem tornar seu processo de desenvolvimento mais suave, seja você trabalhando sozinho ou em equipe. Embora ferramentas GUI ofereçam conveniência, dominar a linha de comando do Git proporciona mais controle sobre seus fluxos de trabalho. Experimente esses comandos e aprimore suas habilidades no Git!

No desenvolvimento com Ruby on Rails, frequentemente precisamos buscar dados específicos diretamente do banco de dados. Dois métodos comuns usados para isso são pick e pluck. Embora ambos sejam úteis para extrair dados, eles servem a propósitos diferentes, e é importante saber quando usar cada um para otimizar o desempenho da sua aplicação.

pluck: Extraindo Múltiplos Valores

O método pluck é ideal quando você deseja extrair os valores de um ou mais atributos de todos os registros que correspondem a uma consulta. Ele constrói uma consulta SQL que retorna apenas os campos especificados, o que pode melhorar o desempenho ao evitar o carregamento de objetos ActiveRecord desnecessários.

Exemplo de Uso:

# Extraindo os nomes de todos os usuários
User.pluck(:name)
# Isso retornará algo como:
# ["Alice", "Bob", "Charlie"]

No exemplo acima, pluck retorna um array contendo os valores do atributo name de todos os usuários na tabela.

pick: Buscando o Valor da Primeira Linha

O método pick é mais adequado quando você precisa apenas do valor de um único atributo da primeira linha que corresponde a uma consulta. Usar pick é mais eficiente do que usar pluck seguido de first, pois pick executa uma consulta SQL que retorna diretamente o valor desejado sem a necessidade de carregar objetos adicionais na memória.

Exemplo de Uso:

# Buscando o nome do primeiro usuário ativo encontrado
User.where(active: true).pick(:name)
# Isso retornará algo como:
# "Alice"

Por Que pick é Melhor que pluck.first?

Considere uma situação onde você precisa do valor do primeiro registro. A abordagem comum poderia ser:

# Usando pluck seguido de first
User.where(active: true).pluck(:name).first

Embora isso funcione, ele executa duas operações: primeiro, extrai todos os nomes dos usuários ativos, e depois pega o primeiro valor do array resultante. Isso significa que você está potencialmente carregando muito mais dados do que precisa, especialmente se houver muitos usuários ativos.

Por outro lado, com pick, você faz isso de forma mais direta e eficiente:

# Usando pick para obter o nome do primeiro usuário ativo
User.where(active: true).pick(:name)

Aqui, a consulta SQL retornará apenas o valor do atributo name do primeiro usuário ativo encontrado, sem carregar dados adicionais.

Resumo

• pluck: Use para extrair os valores de um ou mais atributos de todos os registros que correspondem a uma consulta.
• pick: Use para obter o valor de um único atributo da primeira linha encontrada pela consulta.

Benefícios de Usar pick:

• Eficiência: Executa uma única consulta SQL retornando apenas o valor necessário.
• Desempenho: Evita o carregamento de objetos ActiveRecord desnecessários na memória.
• Simplicidade: Código mais limpo e direto para buscar o valor da primeira linha.

Ao entender as diferenças e saber quando usar cada método, você pode melhorar significativamente o desempenho e a eficiência das suas consultas no Rails. Aproveite o poder desses métodos para construir aplicações mais rápidas e otimizadas!

O Rails 8.0 introduz um recurso poderoso chamado allow_browser, que permite aos desenvolvedores especificar versões mínimas de navegadores para suas aplicações. Essa funcionalidade oferece várias vantagens significativas que valem a pena considerar.

Ao impor versões mínimas de navegadores, você mitiga vulnerabilidades de segurança não resolvidas, melhora a eficiência operacional e garante compatibilidade contínua com as funcionalidades modernas da web. Essa abordagem protege os dados dos usuários com patches de segurança atualizados, otimiza o desempenho e promove uma experiência unificada para todos os usuários da sua aplicação. Além disso, ao especificar uma versão mínima de navegador, os desenvolvedores podem priorizar o uso de tecnologias modernas, simplificando o fluxo de trabalho de desenvolvimento e minimizando as tarefas de manutenção contínua.

Implementando allow_browser no Rails 8.0

Com o Rails 8.0, definir as versões mínimas de navegadores é simples, utilizando o método allow_browser no ApplicationController. Veja como implementá-lo:

Configuração Básica

Para especificar as versões mínimas de navegadores suportadas, inclua o método allow_browser no seu ApplicationController:

class ApplicationController < ActionController::Base
  allow_browser versions: :modern
end

Usar a configuração :modern garante a compatibilidade apenas com navegadores que possuem suporte embutido para recursos como imagens webp, notificações web push, badges, import maps, nesting CSS e o seletor CSS :has.

Configuração Personalizada

Se preferir especificar versões mínimas para navegadores individuais, você pode personalizá-la da seguinte maneira:

class ApplicationController < ActionController::Base
  allow_browser versions: { edge: 88, chrome: 90, opera: 75 }
end

Essa configuração permite todas as versões de Safari e Firefox, mas restringe o suporte ao Edge 88+, Chrome 90+ e Opera 75+.

Desativando Navegadores Específicos

Você também pode desativar o suporte para determinados navegadores, se necessário. Por exemplo, para desativar o Firefox:

class ApplicationController < ActionController::Base
  allow_browser versions: { safari: 20, firefox: false, ie: 9 }
end

Adicionar allow_browser ao ApplicationController aplica essa configuração globalmente a todas as ações. No entanto, você pode restringi-la a ações específicas usando as opções only ou except.

Restringindo a Ações Específicas

Para aplicar essa configuração a ações específicas do controlador, use:

class ChatController < ApplicationController
  allow_browser versions: { chrome: 85, opera: false, ie: 9 }, only: :show
end

Nesse exemplo, a ação show do ChatController verifica se a versão do Chrome é pelo menos 85 e se a versão do Opera é pelo menos 9. A ação show não oferece suporte ao Opera.

Página Personalizada para Navegadores Não Suportados

Navegadores não suportados serão redirecionados para uma página personalizada (426.html) que explica a necessidade de atualizar o navegador. O código de status HTTP será 426 Upgrade Required.

Conclusão

O uso do allow_browser no Rails 8.0 facilita a definição de versões mínimas de navegadores, permitindo que sua aplicação funcione com segurança e eficiência nas plataformas mais modernas, enquanto reduz a carga de manutenção e oferece uma experiência de usuário mais consistente.

O ActiveRecord, a camada ORM (Object-Relational Mapping) do Ruby on Rails, fornece vários métodos para consultar seu banco de dados. Entre esses métodos estão any?, exists? e present?, cada um com suas nuances e casos de uso específicos. Compreender as diferenças entre esses métodos pode ajudar você a escrever um código mais eficiente e legível. Neste post, vamos explorar esses métodos, suas diferenças e fornecer exemplos para ilustrar como funcionam no nível do banco de dados.

any?

O método any? verifica se há registros em uma coleção que satisfaçam uma determinada condição. Ele dispara uma consulta SQL para determinar se há registros, mas não carrega os registros na memória.

Exemplo:

Vamos considerar um modelo User para ilustrar o any?:

# Verificando se há usuários no banco de dados
User.any?
# SQL Query:
# SELECT 1 AS one FROM users LIMIT 1;

# Verificando se há usuários com mais de 18 anos
User.where('age > 18').any?
# SQL Query:
# SELECT 1 AS one FROM users WHERE (age > 18) LIMIT 1;

Detalhes no Nível do Banco de Dados:

O uso de any? sem um bloco gera uma consulta SQL com LIMIT 1 para verificar se pelo menos um registro existe. Isso é eficiente porque não carrega todos os registros na memória.

exists?

O método exists? verifica se existe algum registro que corresponda a uma condição dada. Esse método é eficiente porque executa uma consulta SELECT 1 AS one, que é rápida e não carrega os registros reais na memória.

Exemplo:

Usando novamente o modelo User para ilustrar o exists?:

# Verificando se existe algum usuário no banco de dados
User.exists?
# SQL Query:
# SELECT 1 AS one FROM users LIMIT 1;

# Verificando se existe algum usuário com o nome "John"
User.exists?(name: 'John')
# SQL Query:
# SELECT 1 AS one FROM users WHERE users.name = 'John' LIMIT 1;

Detalhes no Nível do Banco de Dados:

O método exists? executa uma consulta leve, verificando apenas a existência de registros, e não carrega todas as colunas do registro, apenas um valor para determinar a existência.

present?

O método present? não é específico do ActiveRecord; é uma extensão do Rails disponível para todos os objetos. Ele retorna true se o objeto não for blank?. Para coleções, isso significa que ele verifica se a coleção não está vazia.

Exemplo:

Usando o modelo User para ilustrar o present?:

# Verificando se a coleção de todos os usuários está presente (ou seja, não vazia)
User.all.present?
# SQL Query:
# SELECT users.* FROM users;
# O Ruby carrega todos os registros e verifica se a coleção não está vazia

# Buscando usuários com mais de 18 anos e verificando se o resultado está presente
users = User.where('age > 18')
users.present?
# SQL Query:
# SELECT users.* FROM users WHERE (age > 18);
# O Ruby carrega os registros correspondentes e verifica se a coleção não está vazia

Detalhes no Nível do Banco de Dados:

Usar present? após uma consulta carregará os registros correspondentes na memória e depois verificará se a coleção não está vazia. Isso pode ser menos eficiente se você só precisar verificar a presença de registros, pois todos os registros correspondentes serão carregados.

Diferenças-Chave

Desempenho:

• any? e exists? realizam consultas leves, mas exists? é geralmente preferido para verificar a existência sem carregar registros.
• present? verifica se uma coleção não está vazia, mas carrega todos os registros na memória após uma consulta.

Casos de Uso:

• Use any? quando precisar verificar se há algum registro existente em um escopo.
• Use exists? para uma verificação rápida se algum registro corresponde a uma condição.
• Use present? para verificar se uma coleção ou resultado de consulta não está vazio.

Resumo

Compreender quando e como usar any?, exists? e present? pode impactar significativamente o desempenho e a legibilidade de suas aplicações Rails. Ao escolher o método certo para o cenário correto, você pode garantir que seu código seja tanto eficiente quanto expressivo.

Aqui está um resumo rápido dos exemplos para cada método, mostrando suas consultas SQL correspondentes:

any?:

User.any?
# SQL: SELECT 1 AS one FROM users LIMIT 1;
  
User.where('age > 18').any?
# SQL: SELECT 1 AS one FROM users WHERE (age > 18) LIMIT 1;

exists?:

User.exists?
# SQL: SELECT 1 AS one FROM users LIMIT 1;
  
User.exists?(name: 'John')
# SQL: SELECT 1 AS one FROM users WHERE users.name = 'John' LIMIT 1;

present?:

User.all.present?
# SQL: SELECT users.* FROM users;
  
users = User.where('age > 18')
users.present?
# SQL: SELECT users.* FROM users WHERE (age > 18);

Usando esses métodos de forma apropriada, você pode tornar suas aplicações Rails mais eficientes e seu código mais legível.

O Rails 7 traz uma série de novos recursos e melhorias, tornando ainda mais fácil construir aplicações web robustas e de fácil manutenção. Um dos recursos poderosos disponíveis no Rails é a capacidade de criar colunas virtuais (ou computadas/geradas) nas tabelas do banco de dados. Neste post, exploraremos como criar uma coluna virtual no Rails 7, com explicações detalhadas e exemplos.

O que são Colunas Virtuais?

Colunas virtuais são colunas do banco de dados que não são diretamente armazenadas, mas sim calculadas com base em expressões que envolvem outras colunas. Elas podem ser particularmente úteis para dados derivados, como concatenações, cálculos ou transformações que precisam estar sempre consistentes com os dados de origem.

Exemplo de Cenário

Suponha que temos uma tabela PersonalDocuments e queremos adicionar uma coluna full_name que armazena o nome completo de uma pessoa, além de uma coluna virtual full_name_length que calcula o comprimento do nome completo.

Criando a Migration

Para criar a tabela PersonalDocuments com as colunas necessárias, usaremos o método de migration create_table. Veja como fazer isso:

Migration

class CreatePersonalDocuments < ActiveRecord::Migration[7.0]
  def change
    create_table :personal_documents do |t|
      t.string :full_name
      t.virtual :full_name_length, type: :integer, as: "length(full_name)", stored: true

      t.timestamps
    end
  end
end

Explicando o código:

• create_table :personal_documents: Cria uma nova tabela chamada personal_documents.
• t.string :full_name: Adiciona uma coluna full_name à tabela.
• t.virtual :full_name_length, type: :integer, as: "length(full_name)", stored: true: Adiciona uma coluna virtual full_name_length que calcula o comprimento da coluna full_name.
• A opção stored: true garante que o valor de full_name_length seja calculado quando a linha for inserida ou atualizada, sendo armazenado no banco de dados. Isso torna as consultas mais eficientes, pois o valor não precisa ser recalculado toda vez que for acessado.

Atualizando o Modelo

No seu modelo PersonalDocument, não é necessária nenhuma configuração especial para a coluna virtual. Ela estará disponível como um atributo de leitura.

Modelo

class PersonalDocument < ApplicationRecord
  # Qualquer outra lógica do modelo
end

Usando a Coluna Virtual

Agora você pode usar a coluna virtual full_name_length como qualquer outro atributo. Aqui está um exemplo de como criar um registro e acessar a coluna virtual:

Exemplo de Uso

personal_document = PersonalDocument.create(full_name: "John Doe")
puts personal_document.full_name_length  # Saída: 8

Considerações Importantes

• Armazenado vs. Virtual: A opção stored: true faz com que a coluna seja uma "coluna gerada armazenada", o que significa que seu valor é calculado quando a linha é inserida ou atualizada, e armazenado no banco de dados. Se você quiser que o valor seja recalculado sempre que for acessado, pode usar stored: false (embora o suporte para isso varie entre os bancos de dados).

Verificando a Configuração

Após rodar a migration, você pode verificar as colunas com os seguintes comandos no console do Rails:

rails db:migrate
rails console
personal_document = PersonalDocument.create(full_name: "Jane Doe")
puts personal_document.full_name_length  # Deve exibir: 8

Essa configuração garante que, sempre que o full_name for atualizado, a coluna virtual full_name_length seja recalculada automaticamente e armazenada.

Conclusão

As colunas virtuais no Rails 7 oferecem uma maneira eficiente de manter dados derivados consistentes, eliminando a necessidade de cálculos redundantes e melhorando o desempenho em consultas. Utilizar colunas virtuais com a opção stored: true pode otimizar a sua aplicação, especialmente em cenários onde os dados derivados são frequentemente acessados e precisam ser mantidos em sincronia com outras colunas.

Implementar um índice personalizado no banco de dados através de uma migration no Rails é uma maneira poderosa de otimizar consultas e melhorar o desempenho da aplicação. Índices podem acelerar significativamente as operações de recuperação de dados, permitindo que o banco de dados encontre linhas de maneira mais eficiente.

Aqui está um guia passo a passo de como implementar um índice personalizado em uma migration no Rails, juntamente com alguns exemplos e boas práticas.

Passo 1: Gerar uma Migration

Primeiro, gere um novo arquivo de migration usando o gerador do Rails. Você pode fazer isso rodando o seguinte comando:

rails generate migration AddCustomIndexToTableName

Isso criará um arquivo de migration no diretório db/migrate.

Passo 2: Adicionar o Índice na Migration

Abra o arquivo de migration gerado e use o método add_index para adicionar um índice personalizado à sua tabela. Aqui estão alguns exemplos de diferentes tipos de índices que você pode criar:

Índice Básico

Para adicionar um índice simples em uma única coluna:

class AddCustomIndexToTableName < ActiveRecord::Migration[6.0]
  def change
    add_index :table_name, :column_name
  end
end

Índice Composto

Para adicionar um índice em múltiplas colunas (um índice composto), você pode fazer o seguinte:

class AddCompositeIndexToTableName < ActiveRecord::Migration[6.0]
  def change
    add_index :table_name, [:column1, :column2]
  end
end

Esse tipo de índice é útil quando você faz consultas com base em uma combinação de colunas.

Índice Único

Para garantir que os valores em uma coluna ou em uma combinação de colunas sejam únicos, você pode adicionar um índice único:

class AddUniqueIndexToTableName < ActiveRecord::Migration[6.0]
  def change
    add_index :table_name, :column_name, unique: true
  end
end

Índice com Opções

Você pode personalizar os índices com opções adicionais, como nome, ordem, comprimento, etc.

Nome Personalizado para o Índice

class AddCustomNamedIndexToTableName < ActiveRecord::Migration[6.0]
  def change
    add_index :table_name, :column_name, name: 'custom_index_name'
  end
end

Índice com Ordem Específica

Alguns bancos de dados suportam índices ordenados, onde você pode especificar a ordem de classificação do índice:

class AddOrderedIndexToTableName < ActiveRecord::Migration[6.0]
  def change
    add_index :table_name, :column_name, order: { column_name: :desc }
  end
end

Índice com Limitação de Comprimento

Essa opção é útil para indexar colunas de texto ou string em bancos de dados como o MySQL, que limitam os tamanhos de índices:

class AddLengthLimitedIndexToTableName < ActiveRecord::Migration[6.0]
  def change
    add_index :table_name, :column_name, length: 10
  end
end

Passo 3: Rodar a Migration

Depois de definir o índice no arquivo de migration, execute a migration para aplicar as mudanças no seu banco de dados:

rails db:migrate

Passo 4: Verificar o Índice

Você pode verificar se o índice foi criado conferindo o schema do banco de dados ou usando comandos específicos do banco de dados.

Por exemplo, no PostgreSQL, você pode usar:

\d+ table_name

No MySQL, você pode usar:

SHOW INDEX FROM table_name;

Exemplo: Adicionando um Índice para Otimizar uma Consulta

Considere uma aplicação Rails com uma tabela users onde você frequentemente faz consultas pelo campo email. Adicionar um índice na coluna email pode melhorar significativamente o desempenho:

class AddIndexToUsersEmail < ActiveRecord::Migration[6.0]
  def change
    add_index :users, :email, unique: true
  end
end

Boas Práticas para o Uso de Índices

• Analise os Padrões de Consulta: Adicione índices apenas às colunas que são frequentemente usadas em condições de consulta ou como chaves de junção (joins).
• Evite o Excesso de Índices: Embora os índices melhorem o desempenho de leitura, eles podem degradar o desempenho de escrita (inserções, atualizações, exclusões) devido à sobrecarga adicional de manutenção do índice. Use-os com moderação.
• Considere Índices Compostos: Se você frequentemente faz consultas por múltiplas colunas, um índice composto pode ser mais eficiente do que vários índices de coluna única.
• Use Índices Únicos para Restrições de Unicidade: Se uma coluna ou combinação de colunas deve ser única, imponha isso com um índice único.
• Monitore o Uso dos Índices: Use ferramentas de monitoramento do banco de dados para identificar índices não utilizados ou de baixo desempenho.
• Fique Atento ao Tamanho do Índice: Índices grandes podem consumir muito espaço em disco. Considere limitações de comprimento para grandes campos de texto.
• Reconstrua Índices Quando Necessário: Ocasionalmente, pode ser necessário reconstruir índices para otimizar o desempenho, especialmente após grandes modificações de dados.

Conclusão

Os índices personalizados no Rails são uma ferramenta essencial para otimizar consultas e melhorar o desempenho da aplicação. Seguindo boas práticas e entendendo os padrões de consulta da sua aplicação, você pode garantir que seus índices sejam eficientes e bem gerenciados, evitando o excesso de índices que podem prejudicar o desempenho de gravação.

O Ruby 3.0 introduziu um novo método no seu coletor de lixo chamado GC.compact, que oferece uma maneira poderosa de gerenciar memória ao reduzir a fragmentação em aplicações de longa duração. Esse recurso pode gerar melhorias significativas no uso da memória e no desempenho geral da aplicação, especialmente em cenários onde a fragmentação da memória se torna um gargalo.

Entendendo o GC.compact

A coleta de lixo (Garbage Collection, ou GC) é um processo crítico no Ruby, responsável por liberar memória ao limpar objetos que não estão mais em uso. No entanto, com o tempo, especialmente em aplicações que rodam continuamente, pode ocorrer fragmentação de memória. Isso acontece quando a memória é alocada e desalocada de tal forma que pequenos espaços de memória não utilizados ficam para trás. Esses espaços vazios podem levar a um uso ineficiente da memória e degradar o desempenho, pois o GC tem que trabalhar mais para gerenciar a memória fragmentada.

O método GC.compact aborda esse problema compactando o heap (onde o Ruby armazena seus objetos). Quando você chama GC.compact, o coletor de lixo do Ruby reorganiza os objetos na memória, movendo-os para mais perto uns dos outros e reduzindo os espaços vazios. Esse layout de memória compactado pode ajudar a reduzir o uso de memória e melhorar a eficiência do processo de coleta de lixo.

Como o GC.compact Funciona

Quando o GC.compact é invocado, ele:

• Reorganiza Objetos: Move os objetos na memória para reduzir os espaços vazios e criar blocos contíguos de memória.
• Otimiza o Layout de Memória: Ao agrupar os objetos, ele reduz a fragmentação e potencialmente melhora a localidade de cache, levando a tempos de acesso mais rápidos para objetos frequentemente usados.
• Reduz Sobrecarga do GC: Com um layout de memória mais compacto, o GC pode operar de forma mais eficiente, gastando menos tempo procurando por espaços fragmentados na memória.

Estudo de Caso: Usando GC.compact em uma Aplicação Web

Vamos considerar um exemplo real de uso do GC.compact em uma aplicação web Ruby on Rails que lida com um alto volume de tráfego. Esta aplicação é uma parte crítica de uma grande plataforma de e-commerce, onde uptime e desempenho são essenciais.

Problema: Com o tempo, o uso de memória da aplicação estava aumentando gradualmente, e, apesar das coletas regulares de lixo, a fragmentação de memória estava causando degradação no desempenho da aplicação. A equipe notou que, após vários dias de operação contínua, o consumo de memória estava muito acima do esperado, levando a lentidões frequentes e, em alguns casos, a travamentos.

Solução: A equipe de desenvolvimento decidiu experimentar o GC.compact para resolver o problema de fragmentação de memória. Eles adicionaram uma tarefa periódica à aplicação, acionando o GC.compact durante horários de menor movimento, quando a carga no servidor era mais baixa.

Implementação:

# Agenda o GC.compact para rodar durante horários de menor movimento
Rails.application.config.after_initialize do
  Thread.new do
    loop do
      sleep 6.hours # Aguarda por 6 horas
      GC.compact # Compacta a memória
      Rails.logger.info("Memória compactada pelo GC.compact")
    end
  end
end

Resultados: Após implementar o GC.compact, a equipe observou uma redução significativa no uso de memória ao longo do tempo. O footprint de memória da aplicação tornou-se mais estável, e a frequência das pausas do GC diminuiu. O layout de memória compactado resultou em menos gargalos de desempenho, levando a tempos de resposta mais rápidos e uma maior confiabilidade.

A principal conclusão deste estudo de caso é que o GC.compact pode ser uma ferramenta valiosa para gerenciar memória em aplicações Ruby que rodam por períodos prolongados. Ao reduzir a fragmentação, ele ajuda a garantir que a aplicação permaneça eficiente e confiável, mesmo sob carga pesada.

Quando Usar o GC.compact

Embora o GC.compact possa ser altamente eficaz, é importante usá-lo com cautela. Compactar a memória pode ser uma operação custosa, então é geralmente mais adequado para cenários onde a fragmentação é um problema conhecido. Ele é particularmente útil em:

• Aplicações de longa duração: Servidores, jobs em background ou serviços que rodam continuamente e são propensos à fragmentação de memória.
• Aplicações com grande uso de memória: Aplicações com grandes footprints de memória, onde a gestão da memória é crucial para manter o desempenho.

Conclusão

O GC.compact é uma adição poderosa ao conjunto de ferramentas de coleta de lixo do Ruby, oferecendo uma maneira de reduzir a fragmentação de memória e otimizar o desempenho em aplicações de longa duração. Ao entender como e quando usar este método, você pode garantir que suas aplicações Ruby permaneçam eficientes e responsivas, mesmo sob alta carga. Seja lidando com uma aplicação web de alto tráfego ou um serviço de recursos intensivos, o GC.compact pode ser uma parte valiosa de sua estratégia de otimização.

Utilizando essa abordagem, você estará garantindo que suas aplicações continuem a funcionar de maneira eficiente e sem interrupções, mesmo em cenários mais exigentes.

Manipular parâmetros em Ruby on Rails é uma tarefa comum, especialmente ao trabalhar com formulários e parâmetros fortes (strong parameters). Um método poderoso, mas menos conhecido, que pode simplificar esse processo é o with_defaults. Esse método permite fornecer valores padrão para quaisquer chaves ausentes em um hash, tornando o código mais limpo e eficiente. Vamos explorar como o with_defaults funciona e como você pode utilizá-lo de maneira eficaz com parâmetros fortes.

O que é with_defaults?

with_defaults é um alias para o método reverse_merge no Rails. Ele permite mesclar dois hashes, onde os valores do hash fornecido só são aplicados se não existirem no hash receptor. É particularmente útil quando você deseja garantir que certas chaves tenham valores padrão, sem sobrescrever os valores já existentes.

Um Exemplo Prático

Vamos analisar um exemplo prático envolvendo parâmetros fortes em um controller Rails. Imagine que você está desenvolvendo uma aplicação de blog e deseja garantir que cada novo post seja associado ao usuário atual, mas também quer permitir flexibilidade para casos especiais.

Normalmente, você definiria seu método post_params assim:

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

Mas e se você quiser garantir que todo novo post seja automaticamente associado ao current_user? Você pode adicionar um valor padrão para o atributo user usando o with_defaults:

def post_params
  params.require(:post).permit(:title).with_defaults(user: current_user)
end

Com esse código, se os parâmetros do post não incluírem um atributo user, o current_user será usado como padrão. Essa é uma maneira limpa e concisa de garantir que cada post esteja vinculado ao usuário que o criou, sem precisar definir esse valor manualmente em vários lugares.

Por Que Usar with_defaults?

• Simplifica o Código: Você pode evitar verificações adicionais e lógica condicional ao usar with_defaults para fornecer valores de fallback.
• Previne Erros: Garantir que valores padrão sejam definidos reduz o risco de dados faltantes ou incompletos.
• Mantém o Código DRY: Evita repetir a lógica de definir valores padrão por todo o código.

Um Exemplo Mais Complexo

Considere um cenário em que sua aplicação precisa permitir que certos usuários administradores especifiquem um autor diferente para um post, enquanto usuários comuns só devem ser capazes de criar posts para si mesmos. Você pode ajustar os parâmetros condicionalmente desta forma:

def post_params
  permitted_params = params.require(:post).permit(:title)
  
  # Define o usuário padrão como current_user se não for fornecido e o usuário não for admin
  unless current_user.admin?
    permitted_params = permitted_params.with_defaults(user: current_user)
  end

  permitted_params
end

Neste exemplo, usuários comuns só podem criar posts para si mesmos, mas administradores podem definir o parâmetro user para outra pessoa. Isso mantém a lógica do seu controller limpa e o manuseio dos parâmetros robusto.

Conclusão

O with_defaults é uma ferramenta poderosa em Rails que permite fornecer valores padrão para parâmetros de forma eficiente e limpa. Ao utilizá-lo, você pode simplificar sua lógica, prevenir erros e manter seu código DRY, evitando duplicações desnecessárias. Em aplicações onde parâmetros dinâmicos ou permissões diferentes são necessárias, como em nosso exemplo com administradores e usuários comuns, with_defaults oferece uma solução prática e elegante.

Ao dominar esse método, você estará adicionando mais uma ferramenta valiosa ao seu arsenal de desenvolvimento Rails, ajudando a criar aplicações mais robustas e fáceis de manter.

Na programação orientada a objetos (OOP), aderir a princípios que promovem baixo acoplamento e encapsulamento é essencial para construir sistemas escaláveis e de fácil manutenção. Um desses princípios é a Lei de Demeter, também conhecida como o Princípio do Menor Conhecimento. Esse princípio ajuda a evitar que objetos saibam demais sobre o funcionamento interno de outros objetos, um problema comum na OOP.

Neste post, vamos explorar a Lei de Demeter e demonstrar como aplicá-la em uma aplicação Ruby on Rails. Ao final, você entenderá como esse princípio pode simplificar seu código e tornar sua aplicação mais fácil de manter.

O que é a Lei de Demeter na Programação Orientada a Objetos?

Na programação orientada a objetos, a Lei de Demeter (LoD) pode ser resumida com a seguinte regra: "Um objeto deve se comunicar apenas com seus amigos imediatos e não com estranhos."

Para ser mais claro, um objeto deve invocar métodos apenas em:

• Ele mesmo.
• Suas dependências diretas (campos ou variáveis de instância).
• Objetos passados como argumentos.
• Objetos que ele cria.

Essa regra reduz as dependências entre objetos, tornando o código menos frágil e mais fácil de manter. Quando um objeto "atravessa" outro para acessar o método de um terceiro objeto (ex.: pedido.cliente.endereco.cidade), cria-se um acoplamento forte. Esse tipo de código é mais difícil de testar, estender e depurar.

O Problema: Quebrando a Lei de Demeter

Vamos analisar um exemplo comum em uma aplicação Rails onde a Lei de Demeter é violada. Suponha que temos três modelos: Pedido, Cliente e Endereco. Um Pedido pertence a um Cliente, e um Cliente possui um Endereço. No código abaixo, o Pedido calcula um preço de envio com desconto baseado no endereço do cliente.

class Pedido
  def preco_envio_com_desconto(codigo_desconto)
    cupom = Cupom.new(codigo_desconto)
    cupom.desconto(cliente.endereco.preco_envio)
  end
end

Essa implementação viola a Lei de Demeter. O objeto Pedido está acessando Cliente para chegar a Endereco e buscar o preco_envio. Isso leva a uma situação em que Pedido sabe demais sobre a estrutura interna de Cliente e Endereco, resultando em um forte acoplamento entre esses objetos.

Refatoração: Aplicando a Lei de Demeter

Para corrigir isso, podemos mover a responsabilidade de calcular o preço de envio com desconto para o modelo Cliente. Dessa forma, Pedido interage apenas com seu colaborador direto, Cliente, enquanto Cliente gerencia sua relação com Endereco.

Aqui está o código refatorado:

class Pedido
  def preco_envio_com_desconto(codigo_desconto)
    cliente.preco_envio_com_desconto(codigo_desconto)
  end
end

class Cliente
  def preco_envio_com_desconto(codigo_desconto)
    cupom = Cupom.new(codigo_desconto)
    cupom.desconto(endereco.preco_envio)
  end
end

Agora, a classe Pedido não acessa diretamente Endereco. Em vez disso, delega o cálculo ao objeto Cliente, o que reduz o acoplamento e torna o sistema mais fácil de manter.

Usando delegate para um Código Ainda Mais Limpo

Podemos levar essa refatoração um passo adiante usando o método delegate do Rails. O método delegate permite encaminhar chamadas de métodos automaticamente de um objeto para outro, tornando o código mais limpo e fácil de ler.

Veja como podemos refatorar o exemplo anterior usando delegate:

class Pedido
  belongs_to :cliente

  # Delegar preco_envio_com_desconto ao cliente
  delegate :preco_envio_com_desconto, to: :cliente
end

class Cliente
  has_one :endereco

  def preco_envio_com_desconto(codigo_desconto)
    cupom = Cupom.new(codigo_desconto)
    cupom.desconto(endereco.preco_envio)
  end
end

Como Isso Funciona?

• Em Pedido: A linha delegate :preco_envio_com_desconto, to: :cliente permite que Pedido delegue a chamada para Cliente sem precisar definir o método manualmente.
• Em Cliente: O método preco_envio_com_desconto gerencia a interação com Endereco e aplica a lógica de desconto.

Essa refatoração torna o código mais limpo, ao mesmo tempo em que respeita a Lei de Demeter.

Por Que Seguir a Lei de Demeter?

1. Baixo Acoplamento
   Seguindo a Lei de Demeter, os objetos não precisam conhecer os detalhes internos de outros objetos. Isso reduz a probabilidade de que uma mudança em uma parte do sistema quebre outra parte. Por exemplo, se alterarmos a estrutura de Endereco, Pedido não precisará ser modificado.
2. Encapsulamento
   Cada classe é responsável por sua própria lógica. No nosso exemplo, a classe Cliente é responsável por gerenciar o endereço e o preço de envio, enquanto Pedido foca nos detalhes do pedido. Essa clara separação de responsabilidades torna o código mais fácil de entender e manter.
3. Melhor Manutenibilidade
   Menos conhecimento sobre as estruturas de outros objetos significa menos dependências. Isso torna o código mais flexível e mais fácil de refatorar no futuro. Se a lógica de negócios em torno do envio mudar, você só precisará atualizar o modelo Cliente, sem impactar Pedido.

Conclusão

A Lei de Demeter é um princípio chave na programação orientada a objetos que ajuda a reduzir o acoplamento e a promover uma melhor organização do código. Em aplicações Rails, aderir a esse princípio resulta em sistemas mais escaláveis e fáceis de manter. Refatorar seu código para delegar responsabilidades e limitar o conhecimento de um objeto sobre os outros cria uma arquitetura de aplicação mais limpa e robusta.

No nosso exemplo com Pedido, Cliente e Endereco, vimos como é fácil quebrar a Lei de Demeter e como o uso do método delegate do Rails pode ajudar a corrigir isso. À medida que sua aplicação Rails cresce, aplicar a Lei de Demeter garantirá que sua base de código permaneça limpa, fácil de manter e extensível.

Principais Conclusões:

• A Lei de Demeter incentiva que objetos se comuniquem apenas com seus colaboradores imediatos, reduzindo as dependências.
• Violar essa lei resulta em código fortemente acoplado, que é mais difícil de manter.
• Usar o método delegate do Rails facilita a aplicação desse princípio, resultando em um código mais limpo e modular.

O Ruby é conhecido por sua sintaxe elegante e flexibilidade, permitindo que os desenvolvedores criem códigos concisos e legíveis. Um dos recursos menos conhecidos, mas poderosos no Ruby, é o Struct, uma classe embutida que oferece uma maneira simples de agrupar atributos relacionados sem a sobrecarga de definir uma classe completa. Embora não seja tão comumente utilizado quanto os modelos ActiveRecord ou POROs (Plain Old Ruby Objects), o Struct pode ser extremamente útil em aplicações Rails em certos cenários.

O que é Struct?

Struct em Ruby é um atalho para definir classes simples que agrupam alguns atributos, fornecendo métodos getters e setters para esses atributos automaticamente. Ele cria uma nova classe que se comporta como um objeto leve, com os atributos que você define ao inicializar.

Por exemplo, digamos que você queira criar um objeto simples para representar um ponto em um espaço 2D com coordenadas x e y. Você pode fazer isso da seguinte forma:

Point = Struct.new(:x, :y)

point = Point.new(10, 20)
puts point.x  # Saída: 10
puts point.y  # Saída: 20

Aqui, Struct.new gera uma classe Point com os atributos x e y, além de métodos para obter e definir esses valores. Nesse caso, o Struct economiza o trabalho de definir explicitamente uma classe com um inicializador e acessores para esses atributos.

Quando Usar Struct no Rails

Embora você trabalhe principalmente com modelos ActiveRecord e objetos de serviço no Rails, o Struct tem seu lugar para objetos simples e leves que não precisam das capacidades completas de um modelo. Aqui estão alguns casos onde o Struct pode ser útil:

1. Armazenamento Temporário de Dados

Quando você precisa armazenar dados temporariamente, mas não deseja criar um modelo ou classe completa, o Struct é ideal. Isso é especialmente verdadeiro quando os dados não precisam persistir no banco de dados, existindo apenas durante uma requisição ou sessão.

Exemplo: Imagine que você está trabalhando em um sistema de reservas e deseja criar um objeto de resumo de viagem sem salvá-lo no banco de dados.

TripSummary = Struct.new(:destination, :duration, :price)

summary = TripSummary.new("Havaí", "7 dias", 1500)
puts summary.destination  # Saída: Havaí
puts summary.price        # Saída: 1500

2. Respostas de API

Se a sua aplicação Rails interage com APIs externas, você pode receber respostas JSON que se mapeiam para dados estruturados. Você pode facilmente envolver essas respostas em um Struct para tornar o manuseio delas mais organizado e legível.

Exemplo: Suponha que você esteja trabalhando com uma API que retorna dados climáticos:

WeatherData = Struct.new(:temperature, :humidity, :wind_speed)

response = { temperature: 75, humidity: 65, wind_speed: 10 }
weather = WeatherData.new(response[:temperature], response[:humidity], response[:wind_speed])

puts weather.temperature  # Saída: 75
puts weather.humidity     # Saída: 65

Usar Struct aqui ajuda a encapsular a resposta em um objeto claro e específico para o domínio.

3. Objetos de Formulário

No Rails, objetos de formulário são frequentemente usados para lidar com formulários complexos que envolvem múltiplos modelos ou atributos que não são do banco de dados. Em vez de criar uma classe nova para cada formulário, você pode usar Struct para reunir atributos temporariamente.

Exemplo: Suponha que você esteja construindo um processo de inscrição com várias etapas. Em uma etapa, você precisa coletar informações pessoais:

PersonalInfo = Struct.new(:first_name, :last_name, :email)

info = PersonalInfo.new("John", "Doe", "john.doe@example.com")

Com isso, você pode passar o objeto PersonalInfo, tornando o processo do formulário mais gerenciável.

Melhorando o Struct com Métodos Personalizados

Uma das grandes vantagens do Struct é que ele se comporta como uma classe Ruby regular, então você pode adicionar métodos personalizados a ele. Isso permite encapsular lógica relacionada ao seu objeto Struct.

Exemplo: Vamos melhorar o exemplo do TripSummary adicionando um método para calcular o custo total com impostos.

TripSummary = Struct.new(:destination, :duration, :price) do
  def total_cost_with_tax(tax_rate)
    price + (price * tax_rate)
  end
end

summary = TripSummary.new("Havaí", "7 dias", 1500)
puts summary.total_cost_with_tax(0.10)  # Saída: 1650

Isso permite manter a lógica relacionada dentro do objeto, assim como faria com uma classe completa.

Comparando Struct com POROs e Modelos

Embora o Struct seja uma ferramenta útil, é importante saber quando não usá-lo. Aqui está uma comparação rápida entre Struct e outros objetos comuns no Rails:

O Struct em Ruby on Rails é uma maneira versátil e eficiente de lidar com estruturas de dados simples sem a necessidade de classes completas ou modelos ActiveRecord. É perfeito para tarefas leves, como armazenamento temporário de dados, manipulação de respostas de API ou encapsulamento de atributos de formulário. Usando Struct no contexto certo, você pode simplificar seu código e torná-lo mais legível, evitando complexidade desnecessária.

Os problemas de N+1 queries em Ruby on Rails ocorrem quando sua aplicação faz um número excessivo de consultas ao banco de dados devido ao carregamento das associações entre modelos. Isso pode causar uma degradação significativa no desempenho, especialmente conforme o volume de dados aumenta.

Neste post, vamos abordar quatro maneiras eficazes de resolver o problema de N+1 queries em Rails, tornando sua aplicação mais rápida e eficiente.

1. Use includes para Eager Loading

A solução mais comum para problemas de N+1 é o uso de includes. Esse método permite carregar registros associados em uma única consulta, em vez de consultar o banco de dados cada vez que uma associação é acessada.

Sem includes (Problema de N+1):

posts = Post.all
posts.each do |post|
  post.comments.each do |comment|
    puts comment.body
  end
end

Neste exemplo, para cada post, o Rails executará uma consulta separada para buscar os comentários associados. Isso pode resultar rapidamente em dezenas ou até centenas de consultas à medida que o número de posts cresce.

Com includes (Resolvendo N+1):

posts = Post.includes(:comments).all
posts.each do |post|
  post.comments.each do |comment|
    puts comment.body
  end
end

Ao usar includes(:comments), o Rails carregará os posts e seus comentários associados em uma única consulta, evitando o problema de N+1.

2. Use joins para Eficiência nas Consultas

Se você não precisa carregar os registros associados na memória e só precisa deles para filtros ou condições, o uso de joins é uma solução mais eficiente. Enquanto includes carrega os registros associados, joins utiliza SQL para combinar os dados sem buscar todos os registros relacionados.

Exemplo:

Post.joins(:comments).where(comments: { approved: true })

Neste caso, joins cria um INNER JOIN em SQL entre as tabelas de posts e comentários, permitindo que você filtre os posts com comentários aprovados sem carregar todos os dados dos comentários na memória.

3. Considere preload ou eager_load em Casos Específicos

Tanto preload quanto eager_load são variações de eager loading no Rails, mas funcionam de maneira um pouco diferente de includes.

• preload: Carrega os registros associados em consultas separadas, em vez de usar um join. Isso pode ser útil quando você não quer lidar com joins, mas ainda precisa evitar o problema de N+1.
• eager_load: Força o Rails a usar um LEFT OUTER JOIN para carregar tanto os registros primários quanto os associados em uma única consulta.

Quando usá-los:

• Use preload se você estiver lidando com um grande conjunto de dados e quiser evitar joins complexos.
• Use eager_load quando quiser garantir que todas as associações sejam carregadas em uma única consulta.

Exemplo:

Post.preload(:comments).all # Consultas separadas para posts e comentários
Post.eager_load(:comments).all # Uma única consulta com LEFT OUTER JOIN

4. Selecione Apenas os Dados Necessários

Outra maneira de otimizar suas consultas é selecionar apenas as colunas que você precisa do banco de dados. Por padrão, o Rails carrega todas as colunas das tabelas associadas, mas muitas vezes você não precisa de todas elas.

Você pode usar select para carregar apenas os dados relevantes:

posts = Post.select(:id, :title).includes(:comments).all
posts.each do |post|
  puts post.title
end

Neste caso, em vez de carregar todas as colunas da tabela de posts, estamos selecionando apenas as colunas id e title, reduzindo a quantidade de dados sendo buscados no banco de dados.

Com essas quatro dicas, você pode melhorar significativamente o desempenho da sua aplicação Rails, evitando o problema de N+1 queries e tornando suas consultas ao banco de dados mais eficientes.

No cenário atual de desenvolvimento de software, especialmente para dispositivos móveis, as demandas por agilidade, eficiência e simplicidade no processo de criação de aplicativos são maiores do que nunca. Tradicionalmente, o desenvolvimento de aplicativos móveis exige que equipes construam separadamente para as plataformas iOS e Android, resultando em trabalho duplicado e aumento de custos e tempo. Porém, uma nova solução tem ganhado destaque no mercado, oferecendo uma abordagem inovadora e poderosa: Hotwire Native.

Lançado como um framework web-first, o Hotwire Native promete revolucionar a maneira como desenvolvemos aplicativos móveis nativos, permitindo que desenvolvedores construam aplicativos móveis reutilizando suas interfaces web já existentes, integrando-as perfeitamente com funcionalidades nativas dos dispositivos. Neste artigo, vamos explorar o que é o Hotwire Native, como ele funciona, seus benefícios e como ele pode ser o futuro do desenvolvimento mobile.

O Que é o Hotwire Native?

O Hotwire Native é uma extensão da família Hotwire (HTML Over The Wire), que oferece uma abordagem inovadora para o desenvolvimento de aplicativos móveis nativos. Ao invés de desenvolver aplicativos separadamente para cada plataforma (Android e iOS), o Hotwire Native permite que desenvolvedores reutilizem suas interfaces web já existentes, utilizando HTML, CSS e outras tecnologias web, para criar experiências móveis nativas e fluidas.

O Hotwire Native permite que os desenvolvedores mantenham uma base de código web-first e ainda assim aproveitem as transições e comportamentos nativos dos sistemas operacionais móveis. Isso significa que, ao construir uma aplicação web, você pode estender seu uso para dispositivos móveis sem a necessidade de construir do zero ou manter bases de código completamente distintas.

Como Funciona o Hotwire Native?

A base do Hotwire Native está no conceito de Turbo, que é uma das principais bibliotecas da família Hotwire. O Turbo é responsável por carregar rapidamente as páginas HTML e fornecer transições fluidas entre as diferentes seções do aplicativo, sem a necessidade de recarregar completamente a página. O Turbo Native, que faz parte dessa tecnologia, permite que essas transições ocorram de forma nativa nos aplicativos móveis, criando uma experiência rápida e responsiva para os usuários.

Principais Componentes:

1. Turbo Frames e Turbo Streams: Esses são os blocos de construção que permitem que partes da página sejam atualizadas dinamicamente sem a necessidade de recarregar a página inteira. Eles oferecem uma maneira de manter uma única fonte de verdade para os dados, tornando a sincronização entre a web e o app nativo mais eficiente.
2. Reutilização de HTML: Uma das maiores vantagens do Hotwire Native é a possibilidade de reutilizar as mesmas views HTML da web para os apps móveis. Isso significa que se você já possui uma aplicação web, pode adaptá-la para o mobile sem a necessidade de escrever código nativo ou duplicar o esforço de desenvolvimento.
3. Integração com APIs Nativas: Embora as interfaces sejam baseadas em HTML, o Hotwire Native oferece a capacidade de integrar com as APIs nativas dos dispositivos, como geolocalização, câmera, notificações push, entre outras. Isso permite que o desenvolvedor tenha o melhor dos dois mundos: simplicidade no desenvolvimento com HTML e CSS e acesso a funcionalidades poderosas dos dispositivos móveis.

Vantagens do Hotwire Native

O Hotwire Native vem com uma série de vantagens que podem beneficiar desde pequenas startups até grandes empresas que precisam otimizar seus fluxos de trabalho de desenvolvimento. Algumas das principais vantagens incluem:

1. Desenvolvimento Acelerado

A maior vantagem do Hotwire Native é a capacidade de reutilizar grande parte do código já existente de uma aplicação web para construir um app móvel. Isso economiza tempo e esforço, permitindo que equipes pequenas e ágeis lancem aplicativos nativos de alta qualidade sem a necessidade de contratar equipes especializadas em iOS e Android.

2. Manutenção Simplificada

Manter múltiplos aplicativos em diferentes plataformas pode ser uma dor de cabeça para equipes de desenvolvimento. Com o Hotwire Native, você pode manter uma única base de código web que será utilizada tanto para a versão desktop quanto para os aplicativos móveis. Isso simplifica a manutenção, reduz erros e diminui o custo de longo prazo, já que atualizações e correções são implementadas uma vez e aplicadas em todas as plataformas.

3. Experiência Nativa

Apesar de reutilizar HTML e CSS, o Hotwire Native garante que os aplicativos móveis ofereçam uma experiência nativa para os usuários. Isso é possível graças ao Turbo Native, que proporciona transições rápidas e integradas com o sistema operacional, garantindo que o aplicativo pareça e se comporte como qualquer outro app nativo. Além disso, o acesso a APIs nativas permite que o desenvolvedor crie funcionalidades avançadas com facilidade.

4. Agilidade em Startups

Para startups que precisam lançar rapidamente um produto no mercado, a agilidade no desenvolvimento é crucial. O Hotwire Native permite que pequenas equipes lancem aplicativos para múltiplas plataformas em um curto período de tempo. Isso é especialmente útil em ambientes onde o tempo é um fator essencial para garantir a competitividade no mercado.

5. Redução de Custos

O desenvolvimento de aplicativos nativos para iOS e Android pode ser caro, especialmente se exigirem equipes separadas ou terceirizadas. Com o Hotwire Native, a reutilização de código e a simplificação do processo de desenvolvimento resultam em uma redução significativa de custos, tornando-o uma opção atraente para empresas que buscam eficiência financeira.

Desafios e Considerações

Embora o Hotwire Native ofereça muitas vantagens, é importante considerar que essa abordagem não é adequada para todos os casos de uso. Em alguns cenários, como aplicativos com demandas gráficas pesadas (jogos, por exemplo), o uso de HTML e CSS pode não ser suficiente para proporcionar a performance necessária. Além disso, a integração com APIs nativas pode requerer algum esforço adicional em comparação com frameworks totalmente nativos como Swift ou Kotlin.

Outro ponto importante a considerar é que, embora o Hotwire Native ofereça uma excelente solução para muitos tipos de aplicativos, ele ainda está em desenvolvimento ativo e pode não oferecer suporte a todas as funcionalidades e casos de uso avançados que frameworks nativos oferecem.

Conclusão: O Futuro do Desenvolvimento Mobile

O Hotwire Native apresenta uma nova abordagem para o desenvolvimento de aplicativos móveis, permitindo que desenvolvedores reutilizem grande parte de seu código web e ainda assim ofereçam experiências móveis rápidas e nativas. Com sua integração com o Turbo e o foco em uma abordagem web-first, ele tem o potencial de transformar a maneira como os aplicativos móveis são construídos, especialmente para startups e empresas que buscam agilidade e eficiência.

Se você está considerando uma nova solução para desenvolver seu próximo aplicativo, o Hotwire Native certamente vale a pena explorar. Com a promessa de acelerar o desenvolvimento, reduzir custos e simplificar a manutenção, ele pode ser o futuro para equipes ágeis que desejam maximizar seus recursos sem sacrificar a qualidade da experiência do usuário.

Para mais informações sobre o Hotwire Native, acesse o site oficial.

Imagine que você está em uma festa pós-conferência de tecnologia. Em um canto, há uma desenvolvedora listando uma série de linguagens nas quais é proficiente – de Python a Rust, React a Kotlin. Em outro canto, há um cara mergulhado nas complexidades da computação quântica, perdido em um mundo de qubits e superposição.

Duas espécies diferentes no ecossistema tecnológico. Uma é um canivete suíço, pronta para lidar com qualquer problema que apareça. A outra é um laser, focada em resolver um desafio específico e complexo.

Isso não é apenas uma cena em uma festa – é um retrato de um debate que vem acontecendo no mundo da tecnologia desde que as primeiras linhas de código foram escritas. Você deve espalhar suas habilidades ou aprofundá-las?

Essa não é apenas uma questão abstrata. Sua resposta pode moldar toda a sua trajetória profissional, influenciar as empresas nas quais você prosperará e até mesmo determinar como você enfrentará as tempestades em constante mudança do cenário tecnológico.

O Generalista: O Canivete Suíço da Tecnologia

Generalistas em tecnologia são os adaptadores supremos. Eles se sentem à vontade discutindo UI/UX com designers, debatendo arquitetura com desenvolvedores de backend e traduzindo o jargão técnico para a equipe de marketing.

Em startups, os generalistas muitas vezes são os heróis. Eles podem prototipar novas ideias rapidamente, pivotar quando necessário e preencher lacunas em toda a organização. São aqueles que conseguem ver como todas as peças se encaixam e frequentemente acabam em cargos de liderança.

Mas ser um generalista não é apenas saber um pouco de tudo. É ser capaz de sintetizar conhecimentos de diferentes domínios e aplicá-los de novas maneiras. É sobre enxergar padrões e conexões que outros deixam passar.

O Especialista: O Mergulhador Profundo da Tecnologia

Especialistas são aqueles que empurram os limites do que é possível. São eles que fazem avanços em IA, revolucionam a tecnologia de banco de dados ou criam novos paradigmas de programação.

Em grandes empresas de tecnologia, especialistas frequentemente lideram a inovação em áreas específicas. São as pessoas de referência quando há um problema complexo que precisa ser resolvido. Eles podem mergulhar fundo em questões que deixariam generalistas coçando a cabeça.

Mas especialização em tecnologia não é apenas saber uma coisa muito bem. É estar na vanguarda do seu campo, antecipar para onde ele está indo e, às vezes, até mesmo direcionar o caminho.

O Impacto na Indústria

Essa divisão molda mais do que carreiras individuais – ela influencia como empresas inteiras operam.

Considere a Apple e o Google. A Apple, conhecida por sua abordagem integrada, muitas vezes prefere generalistas que possam trabalhar em diferentes aspectos de um produto. O Google, por outro lado, tem a reputação de contratar especialistas profundos, especialmente em áreas como IA e algoritmos de busca.

E há a Amazon, que parece ter encontrado um equilíbrio. Eles precisam de generalistas para gerenciar seu vasto ecossistema interconectado, mas também contam com especialistas para otimizar sistemas críticos, como seus algoritmos de recomendação ou infraestrutura de nuvem.

O Cenário em Transformação

Estamos vendo a ascensão do que alguns chamam de profissionais em forma de "T" – pessoas com conhecimento amplo em várias áreas (a barra horizontal do T) e expertise profunda em uma ou duas áreas (a barra vertical).

Profissionais em forma de T são canivetes suíços com um laser secreto e poderoso anexado.

Na prática, isso pode parecer com um desenvolvedor backend que conhece profundamente Java, mas também é capaz de discutir sobre UI/UX, arquitetura de nuvem ou análise de dados. Ela não está presa em uma única área – consegue ver o panorama geral e ainda se concentrar nos detalhes quando necessário.

Enquanto profissionais em formato T são valorizados, algumas empresas agora estão buscando funcionários em formato de "V". Mas o que exatamente isso significa?

Diferente dos profissionais em T, que têm profundidade em uma área e abrangência em várias, os profissionais em forma de V têm profundidade significativa em dois domínios diferentes.

A Pergunta de Um Milhão de Dólares

Então, você deve ser um generalista ou um especialista?

Não há uma resposta única para todos. Depende dos seus interesses, das suas forças e de onde você enxerga a indústria caminhando.

Se você prospera com variedade e adora ver o quadro geral, o caminho do generalista pode ser para você. Talvez você acabe como CTO, gerente de produto ou um desenvolvedor versátil que pode enfrentar qualquer projeto.

Os especialistas são aqueles que ultrapassam os limites do possível, que transformam ficção científica em realidade. Eles são os que fazem os carros autônomos navegarem pelas ruas da cidade, que criam vacinas usando modelos computacionais, que ajudam telescópios a espiar os confins mais distantes do universo.

Quando você se especializa, não está apenas aprendendo uma habilidade – está embarcando em uma jornada. Está dizendo: “Este é o meu Everest, e eu vou escalá-lo.” Não é sempre um caminho fácil, mas para aqueles que amam a emoção da descoberta, que sentem adrenalina ao resolver problemas aparentemente impossíveis, é uma aventura como nenhuma outra.

Então, se você se vê obcecado pelas minúcias da computação quântica, ou perdendo o sono pensando em como tornar a IA mais ética, ou esboçando ideias para a próxima geração de arquitetura de nuvem – mergulhe nisso. Essa paixão pode ser seu superpoder, seu bilhete para deixar uma marca duradoura no mundo da tecnologia.