En Febrero del año pasado, con intención de aprender la API de facebook y meterme en el mundillo del desarrollo de aplicaciones, creé junto a Tabi, una aplicación de la que ya he hablado en este Blog, La Porra

La temporada del 2007-2008, acabó con 841 usuarios registrados, que hicieron 2534 apuestas.

Esta temporada, la 2008-2009, el número de visitas a crecido mucho más. Ha habido más de 8000 usuarios registrados, que han hecho más de 16.000 apuestas en más de 100.000 visitas y han dejado más de 500 comentarios.

Además, durante esta temporada se nos ha unido Pello, y nos han llamado de varias empresas para ofrecernos colaboración, que puede que el año que viene haga crecer más a nuestra pequeña.

Cualquier idea que se os ocurra para hacer mejorara la aplicación, siempre es bien venida…

Compártelo

Pero a lo que iba, que me surgió la oportunidad de dar el curso, y acepté. Ha sido el primer curso que he impartido para 30 personas (universitarios), y la experiencia ha sido impresionante. No me acordaba de lo que era la universidad y estas 2 semanas lo he recordado.

Han sido 30 horas de curso, 6 de teoría de redes sociales que impartió Txarly, y 24 técnicas (programación) que he impartido yo. Los asistentes, no tenían el nivel de programación que esperaba, y el temario ha sido más escaso de lo que yo pensaba, pero creo que todos hemos salido satisfechos de las clases.

Empecé impartiendo un pequeño curso de desarrollo web con XHTML, CSS, PHP, MySQL, que tuve que alargar más de lo debido, pero después de las bases, desarrollamos una serie de mini-aplicaciones que creo les gustó bastante. Aquí es donde podéis poner vuestros comentarios si no es así .

Para finalizar el curso, por grupos, han tenido que desarrollar una aplicación, y la verdad es que todos se lo han tomado muy en serio y con muchas ganas. El viernes veremos que es lo que han conseguido, pero desde luego, todos se ganaron un punto cuando en el último descanso del curso, ni siquiera salieron de la clase, se quedaron dándole duro a la aplicación. La verdad es que eso, a mi, me hizo mucha ilusión…

En fin, un placer impartir este curso, y con ganas de repetir algún otro por ahí.

Compártelo

class noticia {
  public $id;
  public $nombre;
  public function get_id() {
    return $this->id;
  }
  public function set_id($id) {
    $this->id = $id;
  }
  public function get_nombre() {
    return $this->nombre;
  }
  public function set_nombre($nombre) {
    $this->nombre = $nombre;
  }
  [...]
}

Esto, cuando tienes muchos atributos ( =campos en la tabla), se hace un poco tedioso y absurdo.
Hoy, leyendo la documentación de PHP5, me he dado cuenta que existe un método mágico (la sobrecarga) para no tener que hacer eso así. A ver si lo puedo explicar con un ejemplo:

class noticia {
  private $id;
  private $nombre;

  public function dame_nombre() {
  //   return $this->nombre;
    return $this->__get('nombre');
  }

  private function __get($atrb) {
    switch ($atrb) {
      case '':
          return '';
      case 'nombre':
          return 'Nombre: '.$this->nombre;
      default:
        return $this->$atrb;
    }
  }

  private function __set($atrb, $val) {
    switch ($atrb) {
      case '':
          return '';
      default:
        $this->$atrb = $val;
    }
  }

  private function __isset($atrb) {
    return isset($atrb);
  }

  private function __unset($atrb) {
    unset($this->$atrb);
  }

}

De esta manera, cada vez que accedemos desde fuera de la clase a los atributos “id” o “nombre”, pasarán por las funciones especiales __get o __set dependiendo de si estamos leyendolo o escribiéndolo. Y podemos poner todos los atributos que queramos sin tener que escribir nuevas funciones get y set para cada uno.
Esto me va a ahorrar mucho tiempo de ahora en adelante…

OJO: si accedemos desde dentro de la clase al atributo directamente, no pasará por la función mágica, pero podemos forzarlo haciendo $this->__get(’nombre’);

Compártelo

El servidor que uso es un Solaris, creo (Joyent me lo dio gratis y configurado), y no sabía como cambiar la hora del sistema ni el idioma. Como no quería andar haciendo pruebas en el servidor de producción y no quería andar reiniciándolo, pensé en cambiar las configuraciones de PHP y MySQL. Aquí os dejo como lo he hecho:

En Bilbao, usamos el uso horario CET ([bilbainada*] y el resto de centro Europa nos copia[/bilbainada]) en invierno y CEST en Verano.
CET: Central European Time (GMT+2) (30 de Marzo – 26 de Octubre)
CEST: Central European Summer Time (GMT+1) (26 de Octubre – 30 de Marzo)
En el listado de usos horarios standar suele llamarse “Europe/Madrid”.

Pues bien, para cambiar el uso horario en PHP, en tiempo de ejecución, podemos hacerlo con date_default_timezone_set:

date_default_timezone_set('CET');//o 'Europe/Madrid', pero yo no lo he conseguido hacer funcionar así, a ver que pasa cuando cambie el uso...

Y para cambiar el idioma en que se escribe la fecha, usamos setlocale:

setlocale(LC_ALL,'es_ES.UTF-8); //es_ES.UTF-8 tiene que estar en el sistema.

Cuando hemos cambiado setlocale, para que nos escriba Martes en vez de Tuesday, tenemos que usar la función strftime():

// %A - nombre completo del día de la semana de acuerdo a la localidad actual
// %B - nombre completo del mes de acuerdo a la localidad actual
// %d - día del mes como un número decimal (rango 01 a 31)
// %g - como %G, pero sin la centuria.
// %G - El año de 4-dígitos correspondiente al número de semana ISO (vea %V). Éste tiene el mismo formato y valor que %Y, con la excepción de que si el número de semana ISO pertenece al año siguiente o previo, ese año es usado en su lugar.
// %H - hora como un número decimal usando un reloj de 24 horas (rango 00 a 23)
// %I - hora como número decimal usando un reloj de 12 horas (rango 01 a 12)
// %j - dúa del año como un número decimal (rango 001 a 366)
// %m - mes como un número decimal (rango 01 a 12)
// %M - minuto como un número decimal
// %S - segundo como un número decimal
// %u - día de la semana como un número decimal [1,7], en donde 1 representa Lunes
// 'l, d \d\e F H:i'  ==>  '%A, %d de %B %H:%M'
echo strftime('%A, %d de %B %H:%M',$tiempo); //donde tiempo es un UNIX-TIMESTAMP
// Escribirá: sábado, 30 de agosto 14:45

Con eso, ya he podido ver la fecha-hora que aparece en pantalla en castellano, además de que la hora actual esté en la hora de aquí. Pero si en MySQL hago “now()” me sigue saliendo la hora del sistema. Para cambiar eso:

SET GLOBAL time_zone = 'Europe/Madrid';

(Puede que haya que reiniciar MySQL, o por lo menos salir y entrar de nuevo) Para ver si lo hemos cambiado bien:

SELECT @@global.time_zone, @@session.time_zone;

Donde pongo “Europe/Madrid”, se pueden poner otros time-zones cargados en Mysql.
Cuando yo hice esto, no funcionó a la primera porque MySQL no tenía cargados los timezones, por lo que tuve que cargarlos desde el sistema, con un comando de MSQL:

mysql_tzinfo_to_sql "directorio_de_tz" | mysql -u root -p mysql

["directorio_de_tz" en mi caso era: "/usr/share/lib/zoneinfo"]
Mas información sobre MySQL y este tema en la documentación de MySQL (9.7. MySQL Server Time Zone Support).


¿conocéis otra manera de hacer esto? ¿tendré problemas más adelante? ¿que pasará cuando cambie el horario de verano? Iré actualizando este POST, tranquilos…

Una bilbainada, a parte de un género musical, es cualquier frase/acción ligeramente exagerada que sólo puede decir/hacer uno de Bilbao. Por ejemplo: Guggenheim Bilbao, Metro Bilbao, Una auténtica Bilbainada, Bilbainadas o no, Y no es una bilbainada y Bilbainada Gastronómica.

Compártelo

Este es un artículo que forma parte de un grupo de artículos para aprender a configurar un servidor web que te pueden interesar.

Artículos seguidos para realizar este articulo:

• http://articles.slicehost.com/2008/4/25/ubuntu-hardy-setup-page-1
• http://articles.slicehost.com/2008/4/25/ubuntu-hardy-setup-page-2
• http://articles.slicehost.com/2008/4/30/ubuntu-hardy-ruby-on-rails
• http://articles.slicehost.com/2008/5/9/ubuntu-hardy-mongrel-and-mongrel-clusters
• http://articles.slicehost.com/2008/4/25/ubuntu-hardy-installing-apache-and-php5
• http://articles.slicehost.com/2008/5/9/ubuntu-hardy-apache-rails-and-mongrels
• http://articles.slicehost.com/2007/9/5/introduction-to-svnserve
• http://articles.slicehost.com/2007/9/5/using-ssh-with-svnserve
• http://articles.slicehost.com/2007/9/6/multiple-projects-and-subversion
• http://articles.slicehost.com/2007/9/6/multiple-repositories-and-subversion

Otros Artículos de ayuda:

Para aprender la configuración de Apache2 (a2dissite, a2ensite, a2dismod, a2enmod):

• http://articles.slicehost.com/2008/4/28/ubuntu-hardy-apache-config-layout

Para configurar Apache2 de manera más optima:

• http://articles.slicehost.com/2008/4/28/ubuntu-hardy-apache-configuration-1
• http://articles.slicehost.com/2008/4/28/ubuntu-hardy-apache-configuration-2

Virtual Hosts en Apache:

• http://articles.slicehost.com/2008/4/29/ubuntu-hardy-apache-virtual-hosts-1
• http://articles.slicehost.com/2008/4/29/ubuntu-hardy-apache-virtual-hosts-2

Conceptos sobre como funcionan las llamadas cliente servidor, y como tener multiples dominios (vhosts):

• http://articles.slicehost.com/2008/5/28/how-to-serve-multiple-domains

Copias de seguridad:

• http://articles.slicehost.com/2007/10/11/automating-a-daily-rsync-backup
• http://articles.slicehost.com/2007/10/10/rsync-exclude-files-and-folders
• http://articles.slicehost.com/2007/10/9/backing-up-your-files-with-rsync

Subversion:

• http://articles.slicehost.com/subversion

Capistrano:

• http://articles.slicehost.com/2008/1/17/capistrano-series-local-setup-and-capistrano

Capítulo anterior: Capitulo VII: Capistrano el “deployador”
Resumen: Configurar un servidor web

Compártelo

Este es un artículo que forma parte de un grupo de artículos para aprender a configurar un servidor web que te pueden interesar.

Vamos a por el siguiente paso, el que nos ayuda a “deployar”: Capistrano
Antes de nada, creamos la app Rails en nuestro proyecto:

rails project1 -c

La opción “-c”, añade todos los ficheros a subversion (pero sin hacer commit)

Ok, ahora, vamos a decirle a Subversion que ignore algunos ficheros que no queremos que gestione en las versiones:

cd project1
svn commit -m "Initial commit of project"
svn propset svn:ignore "*" log/
svn propset svn:ignore "*" tmp/
svn commit -m "added ignore to tmp and log"

Vale, tenemos el Proyecto preparado, ahora, instala Capistrano:

sudo gem install capistrano

Para ver la versión de Capistrano instalada:

cap -V

Capistrano v2.1.0

Lo primero que hay que hacer es decirle al proyecto que use Capistrano, ¿o a Capistrano que gestione el proyecto?, es lo mismo, “capifiar” el proyecto: (desde el root de tu aplicación)

capify .

Esto genera dos archivos en nuestro proyecto, que tenemos que añadir a Subversion:

svn status

?      Capfile
?      config/deploy.rb

svn add Capfile
A         Capfile

svn add config/deploy.rb
A         config/deploy.rb

svn commit -m "yay, I capified it..."

Vamos a preparar el archivo de configuración de capistrano “config/deploy.rb”
Por defecto es más o menos así:

set :application, "set your application name here"
set :repository,  "set your repository location here"

# If you aren't deploying to /u/apps/#{application} on the target
# servers (which is the default), you can specify the actual location
# via the :deploy_to variable:
# set :deploy_to, "/var/www/#{application}"

# If you aren't using Subversion to manage your source code, specify
# your SCM below:
# set :scm, :subversion

role :app, "your app-server here"
role :web, "your web-server here"
role :db,  "your db-server here", :primary => true

Tenemos que rellenarlo con nuestros datos de servidor:

set :application, "domain.com"
set :user, "demo"
set :repository,  "svn+project1ssh://123.45.67.890/home/demo/repository/project1"
set :port, 30000
set :deploy_to, "/home/demo/public_html/#{application}"
set :location, "domain2.com"
role :app, location
role :web, location
role :db,  location, :primary => true

Suficiente, vamos a probarlo, cruza los dedos y escribe:

cap deploy:setup

Si todo ha ido bien, tendremos una carpeta nueva en nuestro public_html del servidor, preparada para servir. Dentro de esa carpeta hay dos subcarpetas; “releases” donde se guardara la versión de producción (y las copias de seguridad de cada deploy) y “shared” donde se guardan los ficheros que no cambian (logs, pids y informaciones de systema).
Ya que nuestro repositorio está en el mismo servidor que el Apache, vamos a poner las cosas un poco más simples: (cambia esto en el deploy.rb)

set :deploy_via, :copy

Y si quieres que el usuario encargado de parar y reiniciar los Mongrels sea diferente:

set :runner, user

Pero todavía nos queda explicarle como iniciar los Mongrel: (desde nuestro PC)

touch script/spin
svn propset svn:executable on script/spin

En el fichero creado ay que escribir lo siguiente:

/home/demo/public_html/domain.com/current/script/process/spawner -p 8000 -i 2 -e production

Y subirlo:

svn add script/spin
svn commit -m "added script/spin"

Todo preparado para el primer deploy:

cap deploy:cold

Jur jur… Si todo va bien, este comando ha hecho lo siguiente:

• Descarga la última versión del repositorio
• La comprime en un archivo temporal
• La sube al servidor
• La descomprime
• Copia el código donde debe y crea algunos enlaces simbólicos y demás. (lo prepara)
• Inicia los Mongrels definidos en “script/spin”

Recuerda hacer un vhost, que tenga las siguientes URLs:

access_log --> /home/demo/public_html/domain.com/shared/log/access.log;
error_log --> /home/demo/public_html/domain.com/shared/log/error.log;
root --> /home/demo/public_html/domain.com/current/public/

Capítulo anterior: Capitulo VI: Gestión de versiones con Subversion
Siguiente capítulo: Capitulo VIII: Resumen y listado de artículos de ayuda

Compártelo

Este es un artículo que forma parte de un grupo de artículos para aprender a configurar un servidor web que te pueden interesar.

Empecemos con el gestor de versiones: Subversion:

sudo aptitude install subversion

vamos a poner el repositorio en el mismo servidor:

mkdir /home/txurdi/repositorio
svnadmin create /home/txurdi/repositorio/project1

Esto ya lo expliqué en otro POST, por ahora lo enlazo, y cuando tenga tiempo lo edito y lo personalizo más:
Que es eso de los repositorsios SVN?
Usar SVN en una aplicación web (RoR)

Ahora, desde tu PC, puedes descargarte el código y empezar a trabajar:

svn co svn+project1ssh://123.45.67.890/home/txurdi/repository/project1

Capítulo anterior: Capitulo V: Apache y PHP
Siguiente capítulo: Capitulo VII: Capistrano el “deployador”

Compártelo

Este es un artículo que forma parte de un grupo de artículos para aprender a configurar un servidor web que te pueden interesar.

Ahora, instalemos Apache:

sudo aptitude install apache2 apache2.2-common apache2-mpm-prefork apache2-utils libexpat1 ssl-cert

En la instalación, dará una pequeña advertencia:

apache2: Could not reliably determine the server's fully qualified domain name,
using 127.0.0.1 for ServerName

No te preocupes, vamos a solucionarlo. Abre el archivo de configuración de Apache:

sudo nano /etc/apache2/apache2.conf

Y al final del archivo escribe lo siguiente:

ServerName txurdi

Guarda el fichero y reinicia apache (reiniciando de esta manera no mata posibles conexiones abiertas)

sudo apache2ctl graceful

Ya está, si pones tu IP (http://123.45.67.890) en Internet Explorer tu navegador favorito (firefox o safari), podrás ver la página por defecto de Apache.
Breve inciso para instalar postfix:

sudo aptitude install postfix -y

Vamos a instalar también PHP (si no necesitas saltate este paso)

sudo aptitude install libapache2-mod-php5 php5 php5-common php5-curl php5-dev php5-gd \
php5-imagick php5-mcrypt php5-memcache php5-mhash php5-mysql php5-pspell php5-snmp \
php5-sqlite php5-xmlrpc php5-xsl

Hemos instalado unos cuantos módulos que igual no necesitas, quitalos a tu antojo.
Recargamos Apache:

sudo /etc/init.d/apache2 reload

OK, vamos a probar con una nueva aplicación de RoR:

cd ~/public_html
rails railsapp

Vamos a aprobechar ahora para activar algunos módulos de Apache que suelen ser útiles:

sudo a2enmod proxy
sudo a2enmod proxy_balancer
sudo a2enmod proxy_http
sudo a2enmod rewrite

y reiniciamos Apache:

sudo /etc/init.d/apache2 force-reload

Vamos a crear un cluster (como hemos aprendido antes)

cd ~/public_html/railsapp
mongrel_rails cluster::configure -e production -p 5000 -N 3 -c /home/txurdi/public_html/railsapp -a 127.0.0.1

Si miramos el archivo “config/mongrel_cluster.yml”:

cwd: /home/txurdi/public_html/railsapp
log_file: log/mongrel.log
port: "5000"
environment: production
address: 127.0.0.1
pid_file: tmp/pids/mongrel.pid
servers: 3

Creamos el enlace simbólico para que se lance al reiniciar y lo lanzamos nosotros manualmente ahora:

sudo ln -s /home/txurdi/public_html/railsapp/config/mongrel_cluster.yml /etc/mongrel_cluster/railsapp.yml
mongrel_cluster_ctl start

Y vamos a crear un Virtual Host en Apache:

sudo nano /etc/apache2/sites-available/txurdi.net

Escribimos lo siguiente (+o-):

  ServerName txurdi.ner
  ServerAlias www.txurdi.net

  DocumentRoot /home/txurdi/public_html/railsapp/public

  RewriteEngine On

    BalancerMember http://127.0.0.1:5000
    BalancerMember http://127.0.0.1:5001
    BalancerMember http://127.0.0.1:5002
  

  # Redirect all non-static requests to thin
  RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_FILENAME} !-f
  RewriteRule ^/(.*)$ balancer://mongrel1%{REQUEST_URI} [P,QSA,L]

  ProxyPass / balancer://mongrel1/
  ProxyPassReverse / balancer://mongrel1/
  ProxyPreserveHost on

    Order deny,allow
    Allow from all
  

  # Custom log file locations
  ErrorLog  /home/txurdi/public_html/railsapp/log/error.log
  CustomLog /home/txurdi/public_html/railsapp/log/access.log combined

Activamos el Virtual Host que acabamos de crear y recargamos Apache para que lo conozca:

sudo a2ensite txurdi.net
sudo /etc/init.d/apache2 reload

Si ahora accedes via navegador a tu dominio (en nuestro caso era txurdi.net), verás la página por defecto de Rails

Ok, ya tenemos el server funcionando, pero ¿como hacemos modificaciones en la página? Puf, vaya liada, conectarnos por SSH y cambiar directamente con Vim o Nano. O también podríamos montarnos la carpeta principal en nuestro PC… No, no, no… eso no sería muy prudente. Vamos a ver otras posibilidades: Subversion y Capistrano.

Capítulo anterior: Capitulo IV: Mongrel
Siguiente capítulo: Capitulo VI: Gestión de versiones con Subversion

Compártelo

Este es un artículo que forma parte de un grupo de artículos para aprender a configurar un servidor web que te pueden interesar.

Instalemos Mongrel [Web oficial de Mongrel] (que es una gema, osea que simple):

sudo gem instal mongrel

Nos instalará alguna otra gema necesaria si no la tenemos ya instalada.
Mongrel tiene 3 instrucciones básicas (start, stop y restart), pero se puede combinar con muchos parámetros; por ejemplo, si queremos lanzar un Mongrel escuchando en el puerto 6000, y que esté en el entorno de producción:

mongrel_rails start -e production -p 6000 -d

El “-d” del final es para lanzarlo como demonio, vamos que se queda como un proceso que no te molesta en tu terminal, y que no se muere cuando cierras el terminal.

El comando hay que lanzarlo desde la raiz de tu aplicación, “rails directory”.

Vamos a ir un poco más lejos instalando un cluster de Mongrels, que son un grupo de Mongrels que funcionan en común.
Primero instalamos:

sudo gem install mongrel_cluster

Para lanzar un cluster de 2 Mongrels empezando en el puerto 8000, sería algo así:

mongrel_rails cluster::configure -e production -p 8000 -N 2 -c /home/demo/public_html/testapp -a 127.0.0.1

OJO: La ruta completa y si queréis mas ayuda “mongrel_rails cluster::configure -h”

El comando genera un archivo en formato YAML, que puedes configurar a tu gusto si no quieres lanzarlo otra vez. El fichero queda algo como esto:

cwd: /home/demo/public_html/testapp
log_file: log/mongrel.log
port: "8000"
environment: production
address: 127.0.0.1
pid_file: tmp/pids/mongrel.pid
servers: 2

Para iniciar, parar o reiniciar el cluster, desde la raiz de la aplicación:

mongrel_rails cluster::start
...  o ...
mongrel_rails cluster::restart
...  o ...
mongrel_rails cluster::stop

Vamos a crear un script de inicio para que se lance el cluster cuando reiniciamos el servidor:
Primero, creamos un enlace: (uno por cada aplicación que tengamos instalada)

sudo mkdir /etc/mongrel_cluster
sudo ln -s /home/demo/public_html/testapp/config/mongrel_cluster.yml /etc/mongrel_cluster/testapp.yml

Ahora, copiamos el script de inicio de la gema en init.d, lo hacemos ejecutable y le aplicamos el runlevel:

sudo cp /usr/lib/ruby/gems/1.8/gems/mongrel_cluster-1.0.5/resources/mongrel_cluster /etc/init.d/
sudo chmod +x /etc/init.d/mongrel_cluster
sudo /usr/sbin/update-rc.d -f mongrel_cluster defaults

Debe ser más fácil con “thin” o “mod_rails”, pero los tengo en mi lista de TO-DO
Entonces, ahora, para iniciar, parar o reiniciar:

mongrel_cluster_ctl start
...
mongrel_cluster_ctl stop
...
mongrel_cluster_ctl restart

Y para ver si está todo ok:

mongrel_cluster_ctl status

Lo que nos da algo como:

Checking all mongrel_clusters...
mongrel_rails cluster::status -C testapp.yml
found pid_file: tmp/pids/mongrel.8000.pid
found mongrel_rails: port 8000, pid 2343

found pid_file: tmp/pids/mongrel.8001.pid
found mongrel_rails: port 8001, pid 2346

Capítulo anterior: Capitulo III: Instalar Ruby on Rails
Siguiente capítulo: Capitulo V: Apache y PHP

Compártelo

Este es un artículo que forma parte de un grupo de artículos para aprender a configurar un servidor web que te pueden interesar.

Instalemos ruby y sqlite:

sudo aptitude install ruby1.8-dev ruby1.8 ri1.8 rdoc1.8 irb1.8 libreadline-ruby1.8 libruby1.8 libopenssl-ruby sqlite3 libsqlite3-ruby1.8

Necesitamos crear algunos simlinks:

sudo ln -s /usr/bin/ruby1.8 /usr/bin/ruby
sudo ln -s /usr/bin/ri1.8 /usr/bin/ri
sudo ln -s /usr/bin/rdoc1.8 /usr/bin/rdoc
sudo ln -s /usr/bin/irb1.8 /usr/bin/irb

Veamos que version de ruby tenemos:

ruby -v
...
ruby 1.8.6 (2007-09-24 patchlevel 111) [x86_64-linux]

Vamos a instalar rubygems desde el codigo fuente, porque es importante tener la última versión estable (y porque lo dice en el manual que traduzco

mkdir ~/sources
cd ~/sources

Descargamos la última versión (en el momento que escribo esto, dicen que la 1.1.0).
Y desempaquetamos:

wget http://rubyforge.org/frs/download.php/34638/rubygems-1.1.0.tgz
tar xzvf rubygems-1.1.0.tgz
cd  rubygems-1.1.0

Compilamos y creamos un enlace simbólico:

sudo ruby setup.rb
...
sudo ln -s /usr/bin/gem1.8 /usr/bin/gem

Para ver la versión de gemas que acabamos de intalar:

gem -v
...
1.1.0

Actualizamos un poco:

sudo gem update

OJO, si tenéis un slice de poca memoria, no hagáis un “sudo gem update –system”, porque actualizaría a la 1.1.1 que os va a dar problemillas de memoria…
Bueno, para ahorrar memoria, al instalar RAILS, lo vamos a hacer sin instalar la documentación:

sudo gem install rails --no-rdoc --no-ri

Podemos ver la lista de gemas instaladas así:

sudo gem list

Comprobemos que está todo bien:

irb
#irb(main):001:0>
require 'sqlite3'
=> true
#irb(main):002:0> exit

Si no dice “true”, la has pifiado, vuelve para arriba…
Si dice true, perfecto, ya está Ruby on Rails funcionando!!

Capítulo anterior: Capitulo II: Actualizacion del SO y ponerlo bonito
Siguiente capítulo: Capitulo IV: Mongrel

Compártelo