Si una vez instalado Rails al arrancar el servidor te muestra un error openssl (RuntimeError) como en el ejemplo:

 => Booting Mongrel (use 'script/server webrick' to force WEBrick) 
 => Rails 2.1.0 application starting on http://0.0.0.0:3000 
 => Call with -d to detach 
 => Ctrl-C to shutdown server 
 ** Starting Mongrel listening at 0.0.0.0:3000 
 ** Starting Rails with development environment... 
 Exiting 
 /usr/local/lib/ruby/gems/1.8/gems/rails-2.1.0/lib/initializer.rb:225:in 
 `require_frameworks': no such file to load -- openssl (RuntimeError) 
 

Una de las soluciones posibles es instalar (o reinstalar) libopenssl-ruby con el comando siguiente.

 sudo apt-get install libopenssl-ruby 
 

A mí me ha funcionado!

Al crear una aplicación con Rails 2.0.2, te encontrarás que, por defecto, la base de datos es SQLite3. ¿Razón? Sencillez, según el equipo responsable de Rails.

Si estás acostumbrado a trabajar con MySQL, mediante el parámetro "-d mysql", puedes saltarte la versión por defecto tomar como base de datos MySQL.

 rails mi-aplicacion -d mysql
 

Fuente: Rails 2.0.2: Some new defaults and a few fixes

Es un problema típico: en tu máquina tienes en acceso a Ruby en una ubicación, por ejemplo en "/usr/local/bin/ruby" y en tu entorno de desarrollo en "/usr/local/bin/ruby".

Esta información es necesaria en la primera línea de los scripts o shebang, que es aquella que llamará a los ejecutables de Ruby.

¿Qué significa esto? Que para ejecutar scripts en Ruby deberías cambiar la primera línea de tus scripts para acomodarlo al entorno en el que vaya a funcionar la aplicación.

Solución

Mediante el parámetro "--ruby /ruta/a/ruby" puedes generar las aplicaciones con el shebang que introduzcas en el parámetro. En este caso, tras averiguar la ruta hacia Ruby el servidor de producción:

puedes predeterminar el shebang de una aplicación para que cuadre con la ruta en producción, mediante el parámetro --ruby

El shebang resultante sería:

Si el enlace a tu máquina de desarrollo no tiene acceso a Ruby en esa ubicación, puedes, mediante un enlace simbólico (symlink) crear un vínculo entre las rutas de tu entorno de desarrollo y la que has definido para producción en el paso anterior. De esta manera, la aplicación funcionaría en ambos entornos sin tener que tocar el shebang.

 # Enlazar la ubicación de Ruby en desarrollo con un symlink
 local$ sudo ln -s /opt/local/bin/ruby /usr/local/bin/ruby 
 local$ sudo ln -s /opt/local/bin/ruby /usr/bin/ruby 
 

Fuente: Deploying Rails Applications. A step by step guide. Ezra Zygmuntowicz

Si quieres comenzar o continuar con tu proceso de autoaprendizaje sobre programación con Ruby On Rails estás de suerte: la Comunidad Rails genera los mejores contenidos didacticos para aprender a programar. 

Un proyecto que empieza bajo unos requerimientos y alcance suele evolucionar: las cabezas piensan, las necesidades cambian y el mercado exige agilidad y adaptación. El desarrollo en cascada está bien... si eres vidente. Sino, más te vale o ser un férreo controlador de proyectos o tener capacidad de adaptación a requerimientos cambiantes.

Si no tienes videntes en tu equipo, échale un vistazo a este video de 28 minutos en el que Gregg Pollack te dejará claro porqué Rails es ideal para proyectos web.

Fuente Rails Envy

Uno de los problemas típicos cuando se ejecuta MySQL desde la consola es la imposibilidad de ver en el entorno local las bases de datos con las que queremos trabajar. Si ejecutamos el comando:

maquina:~ maquina$ mysql

Esto es lo que vemos:

 mysql> show databases;
 +--------------------+
 | Database |
 +--------------------+
 | information_schema | 
 | test | 
 +--------------------+
 2 rows in set (0.00 sec)
 

¿Dónde están nuestras bases de datos? ¿Porqué no aparecen? La respuesta es que posiblemente hayas accedido como un usuario anónimo y este perfil tiene el acceso limitado.

Compruébalo tecleando:

 mysql> SELECT user(), current_user();
 +---------------------+----------------+
 | user()              | current_user() |
 +---------------------+----------------+
 | yo@localhost | @localhost     | 
 +---------------------+----------------+
 1 row in set (0.26 sec)

Sal de MySQL y vuelve a entrar poniendo el parámetro -uroot

maquina:~ maquina$ mysql -uroot

Ahora el comando mysql> show databases; debería mostrarte las bases de datos que estabas buscando. Vaya susto, ¿eh?

El control de versiones es fundamental para el buen fin de un proyecto, sobre todo cuando trabajan varios programadores en un mismo código. Esto es algo independiente de la tecnología utilizada, sea Rails, PHP, Java... etc.

En este post, inspirado en éste otro post de Fernando Blat , vamos a ver lo más básico de Subversion , una herramienta de control de versiones.

Para utilizar subversion son necesarios un cliente (que puede utilizarse desde la línea de comandos, Zigversion o desde Textmate en el caso de MacOs, Tortoise para Windows) y un servidor en el que se creará un repositorio donde guardar el código de la aplicación en desarrollo.

Funcionamiento básico

Checkout o primera subida

Es la primera subida de la versión 1 al repositorio remotode subversion. Una vez subido el código, todos los cambios y evolución del trabajo se gestionarán de manera centralizada en el servidor subversion.

Comando: svn co url_del_repositorio -m "mensaje" -username "nombre del usuario"

La URL puede comenzar por svn:// o http:// dependiendo del sistema. Una vez hecho el primer checkout de la aplicación se puede eliminar del sistema local.

Descarga de la versión en local

Comando: svn update

Actualiza nuestra versión, por si algún compañero ha introducido algún cambio. Modificamos los ficheros necesarios, por ejemplo el fichero carpeta/index.html cuando hayamos terminado deberíamos volver a hacer un svn update, por si alguien ha modificado también el mismo fichero que nosotros

Subida al repositorio

Comando: svn commit -m "esto es lo que he hecho" carpeta/index.html

Subir al respositorio una modificación realizada indicando breve descripción de la misma.

Añadir ficheros al repositorio

Se hace desde la working copy, cuando hemos creado un archivo nuevo que queremos añadir al repositorio.

Comando: svn add

Sirve para añadir un fichero al repositorio, que se actualizará al siguiente commit.

Otros comandos útiles

Comando: svn status

Nos indica el estado de los ficheros en nuestro repositorio.

Comando: svn log fichero.html

Ver histórico de cambios en un fichero determinado. Si le añadimos el parámetro -m mostrará el mensaje.

Comando: svn export http://www.host.com/nombredelrepositorio

Crea una "imagen" del repositorio sin histórico de versiones, revisiones (sin directorios ocultos .svn). Esto es útil, cuando se quiere subir a producción una aplicación. En este caso, se debe hacer svn export y no svn checkout para evitar copiar los directorios ocultos .svn que en producción no nos serán útiles.

Más sobre Subversion en el blog Arejan.net.

De nuevo, gracias Fernando y comentaristas por el post!

Una vez instalado y configurado Ruby On Rails y Compañía (el servidor de bases de datos MySQL , básicamente) en tu equipo, crear una aplicación que no haga nada de nada es muy sencillo.

Entra en tu consola y teclea "rails mi_aplicacion". Automáticamente, verás cómo rails comienza a crear una carpeta "mi_aplicacion" y dentro de ella todo un sistema de archivos y directorios que corresponde a algo como lo que ves en el gráfico:

Rails crea una estructura de carpetas fija en la que reparte la funcionalidad entre dos áreas principales:

Directorio Public: como su nombre indica, es la parte de la aplicación que se expone al público. Por defecto, en ella se incluyen imágenes, hojas de estilo CSS, Javascript... etc. En general, todo aquello que no tiene que ser procesado.

Y dentro de esta carpeta Public, se encuentran los dispatchers, (dispactch.cgi, dispatch.fcgi y dispatch.rb) que son aquellos archivos responsables de agarrar por los pelos las peticiones del usuario y meterlas dentro de la aplicación para que los controllers apostados dentro del directorio App den cuenta de ellas.

Directorio App: que es donde reside la aplicación compuesta por los Modelos, Vistas y Controladores alojados en los directorios Models, Controllers, Views y Helpers siguiendo el esquema MVC de Rails.

También podrás encontrar el directorio Config, donde se almacenan los datos de configuración de la base de datos (servidor, usuario y contraseñas de los tres entornos de desarrollo, test y producción) y las rutas (o archivos dirigidos a mapear las peticiones del navegador hacia los controladores).

Conclusión: Rails te permite arrancar con un orden y te da las pautas para continuar con ese mismo orden. Este orden no es 100% rígido, ya que una vez que te pones, puedes repartir la funcionalidad entre diferentes áreas, crear nuevos directorios (por ejemplo, es habitual crear dentro de controllers un directorio denominado "admin" en el que se guardarán separadamente los controladores de administración del sitio), etc...