Con la recien salida de Rails 3, se introdujeron bastantes cambios y obviamente actualizaciones de las gemas bases.Si instalamos Rails 3 (y sus dependencias) en la misma computadora en que tenemos aplicaciones corriendo bajo alguna versión anterior de Rails, probablemente tengamos problemas, con las aplicaciones viejas, por conflictos entre gemas (en caso que no hayamos utilizado Bundler o congelado la aplicación)

Para solucionar estos inconvenientes existe Ruby Version Manager (a partir de aquí simplemente RVM). La idea es que tengamos ambientes aislados en los que cada uno pueda tener su propia versión de Ruby y gemas instaladas, de esta manera podemos probar nuestra aplicación en varios escenarios y/o tener aplicaciones con requerimientos diferentes corriendo sin conflictos.

A Instalar RVM!

1. Instalar RVM

Primero, lo primero: La manera más práctica de instalarlo es mediante sus repositorios

mkdir -p ~/.rvm/src/ && cd ~/.rvm/src && rm -rf ./rvm/ && git clone --depth 1 git://github.com/wayneeseguin/rvm.git && cd rvm && ./install

Ya les dije que necesitamos tener git?, mmm si necesitamos git, y configurar algunas variables en el path. Algo como:

$ source ~/.rvm/scripts/rvm

O de manera definitiva modificando el  .bash_profile

[[ -s "$HOME/.rvm/scripts/rvm" ]] && . "$HOME/.rvm/scripts/rvm"  # This loads RVM into a shell session.

Para más información y solución de problemas sobre la instalación aquí la documentación oficial , tranquilo, esta es la parte más problemática luego todo va sobre rieles ;).

2. Instalar versión Ruby

Una vez que ya este corriendo RVM, vamos a instalar la versión de Ruby que queremos.
(Nota: Necesitamos openssl)

Si por ejemplo queremos instalar Rails 3 corriendo sobre Ruby 1.9.2, primero tenemos que instalar Ruby 1.9.2 (lógico? xD)

$ rvm install 1.9.2 --with-openssl-dir=/usr/local 

Esperamos que se descargue, se configure, compile, e  instale ….

3. Crear el sandbox de gemas

Ya tenemos el intérprete, ahora necesitamos las gemas. Por tal razón creamos un contenedor donde estarán aprisionadas y no podran salir!

rvm gemset create contenedor1

4. Iniciar en el intérprete y contenedor de gemas deseado

rvm 1.9.2@contenedor1

Listo, ya estamos corriendo ruby 1.9.2 en un contendor aislado. Verificando…

Todo bien, y solo falta instalar Rails:

gem install rails

6. Volver al modo normal

Si ya estamos aburridos de jugar con nuestra aplicación, o queremos volver a los programas instalados en nuestra computadora (fuera de todo contenedor) lo hacemos con:

rvm system

Cuando trabajamos con WordPress en localhost se almacenan referencias de imágenes y otras opciones de configuración; con nuestro dominio local (ej: http://localhost/sitiodeprueba) que posteriormente debemos actualizar para que direccionen a nuestro dominio real (ej: http://www.dominioreal.com).

Aquí hay un listado de consultas sql que puedes generar para corregir los registros y que dirijan al nuevo dominio. Sin embargo mi recomendación es que cuando inicies tu proyecto, configures el archivo hosts para que el dominio final del sitio este configurado con tu localhost, de esta manera una vez que publiques la página en el servidor de producción no tengas que cambiar las URLs  y GUID almacenados en la base de datos.

Para esto primero debes abrir el archivo hosts:
Si usas Windows este archivo debería esta en C:\Windows\System32\drivers\etc\hosts
En las distribuciones de Linux esta en /etc/hosts
Y en los  Mac OS en /private/etc/hosts

En el debes insertar en una linea nueva la correspondencia dominio-dirección IP. Como lo que queremos es que el dominio haga referencia a nuestro localhost quedaria algo como:

127.0.0.1      dominioreal.com
127.0.0.1       www.dominioreal.com

Guardamos y listo, ya podemos trabajar de manera local usando el dominio final. Recordemos que una vez configurados los DNS con nuestro proveedor deberemos eliminar esa directiva local para que veamos realmente los cambios en el sitio publicado en el servidor de producción.

Un tiempo atrás estaba buscando un WebService para obtener el tipo de cambio de dólar – córdoba, todos inexactos. Y el único lugar para encontrar el cambio oficial es en la página del Banco Central de Nicaragua sin embargo la única manera de obtenerlo era mediante una tabla horrible que actualizan mensualmente.

De esta manera construí un pequeño WebService para que cualquier persona que necesite estos datos en una aplicación, los pueda usar de manera transparente (y estándar). A continuación los detalles del WebService:

Tipo de WebService: REST

URL: http://www.elpueblopresidente.com/servicios/wsmoneda.php?

Parámetros:

dia: [Entero]

Número para identificar el día en que se quiere el tipo de cambio. Si no se pasa parámetros toma el dia actual.

mes: [Entero]

Número para identificar el mes que se quiere el tipo de cambio. Por defecto toma el mes actual

ano: [Entero]

Número para identificar el año que se quiere el tipo de cambio. Por defecto toma el año actual

formato: [Cadena] xml  / json / jsonvalido

Cadena para definir el formato de salida del servicio web, “xml” por defecto, “jsonvalido” para json válido, y “json” para salida json contenido entre paréntesis “( )”  *Necesario por algunos framework javascript.

limite: [Entero]

Número para definir la cantidad de registros consecutivos a partir la fecha especificada.

Ejemplos de uso:

http://www.elpueblopresidente.com/servicios/wsmoneda.php

http://www.elpueblopresidente.com/servicios/wsmoneda.php?dia

http://www.elpueblopresidente.com/servicios/wsmoneda.php?dia=15&mes=9&ano=2009

http://www.elpueblopresidente.com/servicios/wsmoneda.php?formato=json

http://www.elpueblopresidente.com/servicios/wsmoneda.php?formato=jsonvalido

http://www.elpueblopresidente.com/servicios/wsmoneda.php?limite=7

* El WebService no tiene una definición WSDL

** La información del WebService es obtenida a partir de la tabla de tipo de cambio que actualiza el www.bcn.gob.ni mensualmente,mediante un robot que parsea los datos y los ingresa una base de datos ( fuera de BCN )

Xampp es una herramienta muy práctica que nos permite instalar el típico entorno MySQL, Apache y PHP , suficiente para empezar proyectos web o revisar alguna aplicación  localmente. Ademas trae otros servicios como servidor de correos y servidor FTP.

La mayor ventaja de Xampp es que es muy fácil de instalar y las configuraciones son mínimas o inexistentes, lo cual nos ahorra bastante tiempo. Sin embargo hay ocasiones en que es mejor dejar atrás la comodidad:

1. No soporta MySQL desde la consola
   Xampp trae PhpMyAdmin para administrar las bases de datos de MySQL,  sin embargo para tareas más específicas es mejor utilizar la consola (linea de comandos) y Xampp no la soporta.
2. No se pueden actualizar individualmente  las versiones de los programas que instala
   Xampp trae las últimas versiones de las aplicaciones que instala, sin embargo cuando pasa el tiempo y salen nuevas versiones de las mismas, no queda otra salida que reinstalar todo Xampp. Que tal si por ejemplo sólo queremos actualizarnos a la última versión de PHP?
3. Dificultad para configurar aplicaciones de terceros
   Y si queremos instalar una aplicación para manejo de subversiones en nuestro servidor?. Si en Xampp se puede mediante algún método alternativo ( llamese hacks), pero resultan bastante engorrorsos y a veces inservibles.
4. y 5. Habian 2 razones más que tenía en mente , pero este post pasó tanto tiempo en borrador que se me olvidaron, asi que le dejo el espacio a los comentarios

Dejaré la instalacion de apache y php sobre  Unix para otro post ( o para una búsqueda en google), en general es bastante fácil, sobre todo si dispone de un manejador de paquetes. Ahora bien si utilizas Windows; les dejo par de guias de Sitepoint para instalar un entorno de servidor:

Instalar MySQL en Windows
Instalar Apache sobre Windows
Instalar PHP sobre Windows