Blog do Camata

Passenger, Rails 3.2.6 (ou 3.1), rails_admin e URL relativa (prefixo)

Durante minha aventura de colocar uma aplicação Rails em produção em uma url com prefixo (www.sistemas.com/meu, por exemplo) quase tudo estava funcionando bem, até que eu visitei a interface gerada pelo rails_admin. Algumas imagens estavam perdidas, mas outras estavam no lugar, um verdadeiro pandemônio. Com uma verificada rápida no html, notei que algumas urls para imagens não estavam com o prefixo da url, mas por que outras estavam? Um detalhe importante: somente as imagens definidas via CSS estavam com a url errada, todas as outras estavam normais.

Googleada aqui, googleada lá… encontrei uma ask no Stack Overflow sobre tal problema no Rails 3.1. Não gostei muito do método utilizado pra resolver o problema, que era um bug na gem sass-rails e esperava que no 3.2 já estivesse resolvido. Atualizei minha versão do Rails para a 3.2.6, que era a 3.1 e nada. Aproveitei um link para a issue sobre este bug no projeto da gem. Nesta issue é explicado muito bem o que causa o problema e é disponibilizado um monkey patch pra resolver no Rails 3.1. Também tem um link para uma pull request que resolve o problema no Rails 3.2, mas adiciona um passo extra para fazer deploy da aplicação: definir na variável de ambiente RAILS_RELATIVE_URL_ROOT a url usada como prefixo antes de compilar os assets. Então, na hora de compilar os assets ficaria assim:

Quem usa o Capistrano para fazer deploy, como eu, basta adicionar esta linha em algum lugar do config/deploy.rb:

default_environment["RAILS_RELATIVE_URL_ROOT"] = "/meu_prefixo"

Se você usa Rails 3.1, além da variável da ambiente, você deverá criar um arquivo na pasta initializers (com o nome que quiser) e colocar o monkey patch nele:

module Sass
  module Rails
    module Helpers
      protected
      def public_path(asset, kind)
        resolver = options[:custom][:resolver]
        asset_paths = resolver.context.asset_paths
        path = resolver.public_path(asset, kind.pluralize)
        if !asset_paths.send(:has_request?) && ENV['RAILS_RELATIVE_URL_ROOT']
          path = ENV['RAILS_RELATIVE_URL_ROOT'] + path
        end
        path
      end
    end
  end
end

Criando banco de dados utf8 no PostgreSQL

Ao colocar minha primeira aplicação Rails + PostgreSQL em produção no Ubuntu Server 12.04, me deparei com um problema de encoding ao tentar rodar as migrations. Depois de muita luta, raiva, vontade de usar MySQL e uma pesquisada no Google encontrei a causa e a solução do problema.

Nas novas versões do Ubuntu, o PostgreSQL está ajustando o encoding dos bancos de dados de acordo com a locale do sistema. No meu caso, instalei com o idioma Português do Brasil e ele estava forçando o encoding para latin1, enquanto a aplicação queria usar utf8 e mesmo alterando na configuração de banco de dados da minha aplicação a coisa não deu certo. A solução que eu encontrei força o PostgreSQL a criar o cluster com um determinado locale, assim podemos forçar ele a usar utf8.

Suponhamos que a versão do PostgreSQL seja a 9.1, basta executar no terminal:

Se você quiser ver uma lista dos locales do seu sistema, execute:

Como trocar a senha do usuário padrão (ou qualquer outro) do PostgreSQL

Muitas vezes ao fazer uma instalação do PostgreSQL (principalmente em servidores de produção) nós precisamos mudar a senha do usuário padrão (postgres) e isso não é algo trivial. Para trocar a senha do usuário do banco de dados, precisamos inicialmente logar como o usuário postgres no computador. Como faremos isso se não temos a senha dele? Calma, amigo, não temos a senha dele mas temos o poder do SUDO.

O próximo passo é abrir o interpretador do PostgreSQL:

Agora basta executar uma simples instrução pgSQL: