uninitialized constant ApplicationController

A mi me ocurrió al pasar de Rails 2.2.2 a Rails 2.32. Por lo visto, han cambiado el nombre a una clase de Rails, por lo que es necesario actualizar el código fuente de la aplicación que Rails incluyó en la misma al crearla. El siguiente mandato hará el trabajo:

rake rails:update

Rápido y fácil, pero me dio unos cuantos quebraderos de cabeza al actualizarme a la última de Rails usando Apache y Passenger

Como me ha resultado un pelín farragoso, he decidido publicar los pasos por si alguien se ve en una situación parecida.

1. Instalando Ruby
2. Instalando Rubygems
3. Instalando Rails
4. Instalando SQLite y MySQL
5. Instalando Passenger

Instalando ruby

Personalmente, cuando trabajo con Rails (en realidad, con Ruby en general), prefiero tener una instalación basada en Rubygems en lugar de usar el sistema de paquetes de la distribución. Aunque a priori puede parecer peor, a la larga resulta más cómodo (puedes escoger la versión que necesitas y no dependes de que la gema esté disponible como paquete para tu distro, además de que te permite escoger la versión de Ruby, mientras que las gemas precompiladas sólo suelen estar para la versión estable) y más coherente (ya que, como no todas las gemas están disponibles como paquetes, acabas instalando algunas mediante gem y otras mediante el gestor de paquetes, en mi caso aptitude, siendo más complicado identificar qué tienes instalado.).

Por lo tanto, de momento sólo instalaremos el intérprete de ruby y los paquetes de documentación y la shell interactiva, es decir:

sudo aptitude install ruby ri1.8 rdoc1.8 irb1.8

Que en Debian 5 por defecto se traduce en la instalación de la versión 1.8 del intérprete (aunque la 1.9 también está disponible). Los siguientes enlaces simbólicos nos serán útiles si el paquete no los ha creado (para verlo, dpkg -L nombre_del_paquete):

cd /usr/local/bin
sudo ln -s /usr/bin/irb1.8 irb
sudo ln -s /usr/bin/rdoc1.8 rdoc
sudo ln -s /usr/bin/ri1.8 ri


Instalando rubygems

Debido a que el paquete rubygems tiene algunas restricciones en Debian que no te permiten usar todas las opciones, y la versión no es la más moderna, optaremos por una instalación a la vieja usanza . Aunque asuste, los pasos son realmente sencillos:

mkdir tmp
cd tmp
wget http://rubyforge.org/frs/download.php/38646/rubygems-1.2.0.tgz
tar zxvf rubygems-1.2.0.tgz
cd rubygems-1.2.0
sudo ruby setup.rb
sudo ln -s /usr/bin/gem1.8 /usr/local/bin/gem
gem --version


A continuación, nos aseguramos de que tenemos la última versión de rubygems (1), instalando la gema rubygems-update, que sirve para actualizar rubygems (mola ):

gem list -r | grep update
sudo gem install rubygems-update
sudo update-rubygems
gem --version

Como habréis observado, no me he preocupado del path a la hora de lanzar el mandato update-rubygems. Rubygems hace una cosa que bajo mi punto de vista es un gran error, pero que facilita el mantenimiento del path: copia los binarios de cada gema en /usr/bin (primer error, copiarlo a /usr/bin en vez de /usr/local/bin, ya que es una instalación local, segundo error, ¿¿porqué copiar en vez de enlazar simbólicamente??, supongo que la respuesta es que Ruby es multiplataforma y por defecto no permite enlaces simbólicos, como le pasa a Java, aunque quizá sea otra cosa).

A partir de aquí, al instalar algunas gemas (en el ejemplo, sqlite3-ruby), obtendremos un error del tipo

Building native extensions. This could take a while...
ERROR: Error installing sqlite3-ruby:
ERROR: Failed to build gem native extension.
/usr/bin/ruby1.8 extconf.rb
extconf.rb:1:in `require': no such file to load -- mkmf (LoadError)
from extconf.rb:1
Gem files will remain installed in /usr/lib/ruby/gems/1.8/gems/sqlite3-ruby-1.2.4 for inspection.
Results logged to /usr/lib/ruby/gems/1.8/gems/sqlite3-ruby-1.2.4/ext/sqlite3_api/gem_make.out

Esto es debido a que necesitamos las librerías de desarrollo de Ruby, ya que vamos a compilar cada gema. Por tanto, las instalamos como paquete, ya que el interprete también lo hemos instalado de esa manera:

sudo aptitude install ruby-dev

Instalando Rails

El siguiente paso es instalar Rails, con un sencillo gesto de dedos :

sudo gem install rails

Podéis especificar la versión que necesitáis, pero en mi caso he decido ir a por la que se instala por defecto, una moderna Rails 2.3.2.

Instalando MySQL y SQLite

Aunque existen otras posiblidades, MySQL y SQL suelen ser los gestores de base de datos usados para la persistencia en una aplicación Rails. Normalmente, SQLite se usa en el entorno de desarrollo y MySQL en el de producción, aunque estoy convencido de que la mayoría de aplicaciones (incluyendo la mía ) se apañarían con SQLite (que no pase hambre).

La instalación de ambas gemas es sencilla, aunque requieren instalar algunos paquetes adicionales. Aquí, lo más habitual es instalar todo lo que huela al paquete a instalar (empezaremos por SQLite), pero realmente no es necesario, y yo prefiero instalar lo mínimo necesario, sobretodo en un servidor de producción. El truco, valido también para cuando estamos compilando una aplicación Linux (con el clásico configure + make + make install), es instalar los paquetes del tipo libcosadelaquedependes y libcosadelaquedependes-dev, que contienen las librerías necesarias para la ejecución y compilación de otros programas o librerías que dependan de cosadelaquedependes.

Así, para SQLite, buscamos la gema que queremos instalar:

gem list -r | grep sqlite

y nos quedamos con la que tiene el nombre más prometedor, sqlite3-ruby . Si la intentamos instalar, posiblemente obtengamos un mensaje similar a:

gem install sqlite3-ruby
Building native extensions. This could take a while...
ERROR: Error installing sqlite3-ruby:
ERROR: Failed to build gem native extension.
/usr/bin/ruby1.8 extconf.rb
checking for fdatasync() in -lrt... yes
checking for sqlite3.h... no
make
make: *** No hay ninguna regla para construir el objetivo `ruby.h', necesario para `sqlite3_api_wrap.o'. Alto.
Gem files will remain installed in /usr/lib/ruby/gems/1.8/gems/sqlite3-ruby-1.2.4 for inspection.
Results logged to /usr/lib/ruby/gems/1.8/gems/sqlite3-ruby-1.2.4/ext/sqlite3_api/gem_make.out

Si os fijáis, le falta el fichero sqlite3.h, es decir, un fichero de cabeceras del lenguaje C. Por lo que procedemos a realizar el truco antes mencionado, comprobando antes y después si tenemos o no el fichero sqlite3.h:

dpkg -S sqlite3.h
sudo aptitude install libsqlite3-dev
dpkg -S sqlite3.h
gem install sqlite3-ruby


Tras esto, la gema SQLite debería instalarse sin problemas. Para MySQL, la instalación es análoga:

gem list -r | grep mysql
gem install mysql
Building native extensions. This could take a while...
ERROR: Error installing mysql:
ERROR: Failed to build gem native extension.
/usr/bin/ruby1.8 extconf.rb
checking for mysql_query() in -lmysqlclient... no
checking for main() in -lm... yes
checking for mysql_query() in -lmysqlclient... no
checking for main() in -lz... no
checking for mysql_query() in -lmysqlclient... no
checking for main() in -lsocket... no
checking for mysql_query() in -lmysqlclient... no
checking for main() in -lnsl... yes
checking for mysql_query() in -lmysqlclient... no
*** extconf.rb failed ***
Could not create Makefile due to some reason, probably lack of
necessary libraries and/or headers. Check the mkmf.log file for more
details.
Gem files will remain installed in /usr/lib/ruby/gems/1.8/gems/mysql-2.7 for inspection.
Results logged to /usr/lib/ruby/gems/1.8/gems/mysql-2.7/gem_make.out


Buscando e instalando la librería adecuada, no deberíamos tener ningún problema:

aptitude search mysql | grep lib | grep dev
aptitude install libmysql++-dev
gem install mysql


Instalando y configurando Passenger

La instalación de Passenger es trivial, aunque por defecto no se explica cómo configurarlo a la Debian, si no que se sólo se habla de Apache en general (lógico por otra parte). Necesitáis los siguientes mandatos:

sudo gem install passenger
sudo passenger-install-apache2-module

El primero de ellos instala la gema, mientras que el segundo compila el módulo para Apache. Es probable que no funcione a la primera y os pida que instaléis una serie de paquetes de Apache (algunas librerías de desarrollo y similar), pero con seguir las instrucciones no debería dar mayor problema. En mi caso fueron los siguientes paquetes:

aptitude install build-essential libopenssl-ruby apache2-prefork-dev libapr1-dev libaprutil1-dev

Una vez instalado, Passenger nos indicará cómo configurar una aplicación en un virtualhost, así como las líneas a añadir a la configuración de Apache. Sin embargo, ya que estamos, en Debian, lo mejor es hacerlo a la Debian y crearnos el fichero /etc/apache2/mods-available/passenger.load con la ruta al módulo de Apache que Passenger nos facilita al final de la instalación:

LoadModule passenger_module /usr/lib/ruby/gems/1.8/gems/passenger-2.2.4/ext/apache2/mod_passenger.so

y su correspondiente /etc/apache2/mods-available/passenger.conf con la configuración del módulo:

PassengerRoot /usr/lib/ruby/gems/1.8/gems/passenger-2.2.4
PassengerRuby /usr/bin/ruby1.8

El virtual host no tiene ningún misterio, en mi caso por ejemplo edito el fichero /etc/apache2/sites-available/mybestlap.com con el siguiente contenido:

ServerName mybestlap.com
DocumentRoot /opt/websites/mybestlap/public
ErrorLog /var/log/apache2/error_mybestlapcom.log
LogLevel warn
CustomLog /var/log/apache2/access_mybestlap.com.log combined


Depués sólo queda habilitar el módulo y el site, y reiniciar Apache

sudo a2enmod passenger
sudo a2ensite mybestlap.com
sudo /etc/init.d/apache2 restart

Y ya tenemos nuestra aplicación lista para salir a producción. Ahora queda lo más diver, implementarla :D. Happy coding!

(1) También se puede instalar directamente una versión más moderna de Rubygems, pero prefería cubrir el caso descrito, que es el que yo hice y que tenía algo más de miga.

La función link_to_remote proporciona la posibilidad de incluir un enlace que usa Javascript y XMLHttpRequest (es decir, Ajax ), pero si el navegador no dispone de Javascript o lo tiene desactivado, el enlace queda inútil, y no es lo más deseable sobretodo si ese enlace no tiene que usar Ajax por narices, aunque usarlo mejora la eficiencia y la experiencia del usuario.

Sin más preámbulos, os dejo un código de ejemplo de la función en la cuál se genera un enlace normal o uno tipo Ajax según la disponibilidad de Javascript en el navegador:

<%= link_to_remote _("login"), {
   :url => {:controller => "account", :action => "login", :layout => "false"}, # If JS
   :update => "content",
   :loading => "new Effect.Appear('loading_message', { duration: 0.5} ); ",
   :complete => "new Effect.Fade('loading_message', { duration: 0.3 }); " },
   :href  => url_for(:controller => "account", :action => "login") # If no JS
%>

Las líneas interesantes son la segunda y la última. La segunda especifica la acción para Javascript, mientras que la última especifica el destino del enlace cuando no existe Javascript. Ambas opciones ejecutan la acción login sobre el controlador account. La opción layout que se usa en caso de tener Javascript indica al método que no genere el HTML general que rodea al formulario (es decir, la cabecera de la página, el pié, etcétera) ya que sólo se va a recargar el contenido (como se ve en la opción :update). En el caso del enlace sin Javascript, sí necesitamos dicho HTML ya que se recargará la página completa.

Edito: Recomiendo encarecidamente que si has llegado hasta aquí usando Google leas esta entrada del blog Ruido Blanco que nos apunta su creador en un comentario. Tanto el contenido de la entrada como las posteriores aclaraciones de los comentarios me han ayudado muchísimo a comprender cómo funciona Rails y incluso el protocolo HTTP

Fuente (madrecita lo que me ha costado encontrarla ): Rails Track