Redireccionar todas las peticiones a un puerto hacia localhost

El proyecto en el trabajo actualmente utiliza subdominios del dominio principal, y limita las capacidades o redirige a otro dominio en función del punto de entrada o del usuario, por lo que cuando desarrollo en local necesito que mi ordenador responda las peticiones a todos esos dominios como si fuera al localhost.

La solución rápida con la que he estado trabajando hasta ahora es modificar el fichero /etc/hosts y añadir tantos nombres a la IP 127.0.0.1 como dominios necesito. Algo como esto:

127.0.0.1 myproject.com www.myproject.com company1.myproject.com

Como digo, es la solución rápida, pero no la más cómoda, ya que para cada dominio nuevo que necesite tengo que modificar el fichero hosts, reiniciar el navegador (supongo que habría que limpiar la cache de DNS en lugar de hacer esto) y volver a probar.

Cansado de tener que hacerlo cada dos por tres (si repito algo más de 3 veces, siempre busco una solución para no tener que hacerlo más), he estado buscando una forma de agilizar el proceso, pero no daba con la solución.

En primer lugar intenté ver si con un proxy local me podía valer, pero no encontré ninguno que me permitiera cambiar la dirección IP destino en función del dominio. Por lo que me fui al tema de servidores de DNS locales, y ahí encontré una solución intermedia con Dnsmasq, mediante el cual podía tener dominios “*.myproject.dev” que se redirigían al servidor local, pero que no acababa de convencerme.

Al fin, Alex me dio la solución: usar iptables. La idea es que todas las URLs que vayan a un puerto determinado, en lugar de ir al destino original, acaben en mi ordenador. Por ejemplo, si escribo http://www.google.com:3000 en la barra de direcciones, en lugar de ir a google, se hará una petición a mi ordenador en el puerto 3000. Mola.

La solución es ejecutar  la siguiente linea:

sudo iptables -t nat -I OUTPUT -p tcp 
      --dport 3000 -j DNAT --to-destination 127.0.0.1

et voila!. Todas las peticiones salientes al puerto 3000 se reencaminarán a mi ordenador.

Si en lugar de redirigir todas las peticiones, sólo quisiéramos redirigir las de un servidor determinado, se le puede indicar mediante la IP. Por ejemplo, con la siguiente línea redirigiría todas las peticiones al puerto 3000 de www.google.es a mi ordenador:

sudo iptables -t nat -I OUTPUT -p tcp -d 216.239.59.104 
      --dport 3000 -j DNAT --to-destination 127.0.0.1

Actualizando un rails congelado bajo subversion

Últimamente estoy actualizando algunos proyectos que tienen rails congelado bajo el directorio vendor -que es lo habitual cuando tienes varios proyectos en una máquina y no quieres estar pendiente de actualizar la aplicación cada vez que rails se actualiza en la máquina-, y lo primero que estoy haciendo es actualizar la versión de rails.

A primera vista, la actualización parece algo trivial:

rake rails:freeze:gems
rake rails:update

Pero cuando tienes el proyecto bajo subversion, en seguida te das cuenta del error: la tarea de rake lo primero que hace es

rm -rf vendor/rails
mkdir -p vendor/rails

con lo que se ha cargado el directorio .svn con toda la información que subversion almacena allí. En cuanto intentas hacer algo con subversion, te encuentras con problemas:

$ svn st
~       rails
$ svn add rails/
svn: warning: 'rails' is already under version control
$ svn commit rails/
svn: '/home/frsantos/project/vendor/rails' is not a working copy
$ svn del rails/
svn: Directory 'rails/.svn' containing working copy admin area is missing

con lo que te toca volver a la versión anterior y volver a empezar:

rm -rv vendor/rails/
svn up vendor

Lo sencillo en este caso es hacer svn delete, svn commit y hacer el freeze de nuevo, pero con esto estamos introduciendo una versión en el repositorio que no es consistente. Para la gente, como yo, a los que les gusta hacer un commit atómico con todos los ficheros que se han modificado para una funcionalidad, he preparado un script de shell que actualiza el directorio rails con los cambios de la última versión rails.

[dm]1[/dm]

Además, tiene el extra añadido de que crea un changelist con todos los ficheros modificados en ese directorio, por lo que si usas un entorno gráfico como RubyMine, te saldrá automáticamente en la pestaña de Changes el changelist con el nombre apropiado con todos los ficheros modificados (si usas este entorno, un consejo: crea un changelist y márcalo como el changelist por defecto. Cuando acabe el proceso, todos los ficheros modificados que no se hayan marcado con un changelist en subversion irán automáticamente a ese sitio).

Usando múltiples Rubies con RVM

Lo primero que hice, incluso antes de empezar a trabajar en la empresa, fue instalarme Ruby 1.8.7 en mi Ubuntu, junto con Rails 2.3.5 y algunas gemas como mongrel. Para ello, seguí los howtos que fui encontrando por internet, como este de Hakido. Tras dejarlo todo configurado, al arrancar Eclipse te configura algunas gemas más como linecache, ruby-debug-ide y ruby-debug-base, con lo que ya tenía todo configurado para empezar a trabajar.

Sin embargo, en seguida te das cuenta de que si vas a tener que trabajar en varios proyectos, cada uno iniciado en un momento distinto con distintas versiones de Ruby y/o Rails, entonces cambiar de proyecto se puede hacer algo incómodo. La solución para ello, por supuesto, ya está pensada y es RVM (Ruby Version Manager).

RVM te permite tener distintas versiones de Ruby funcionando al mismo tiempo, con sus gemas particulares, y lo que es mejor, puedes tener todas las combinaciones de ruby/gemas que quieras. De esta forma, podemos tener un Ruby 1.8.6 con Rails 2.3.4, otro 1.8.6-2.3.5, otro 1.8.7-2.3.5 y otro 1.9.2-3.0.0. Simplemente cambias de configuración con un solo comando y a trabajar.

Al final, he desinstalado todo lo que tenía instalado de ruby en el sistema y lo he vuelto a instalar con RVM de la siguiente forma:

En primer lugar, instalamos las dependencias necesarias:

sudo apt-get install git-core curl zlib1g-dev libreadline5-dev

Después instalamos RMV. Como por ahora no hay un paquete .deb para ubuntu, lo bajamos desde Github:

mkdir -p ~/.rvm/src/rvm/
cd ~/.rvm/src
git clone http://github.com/wayneeseguin/rvm.git
cd rvm
./install

Ahora hay que añadir la siguiente línea en los ficheros ~/.bashrc y ~/.bash_profile

if [[ -s ~/.rvm/scripts/rvm ]] ; then source ~/.rvm/scripts/rvm ; fi

Cerramos y volvemos a abrir la shell para que nos pille los cambios, y ya estamos listos para instalar las versiones de ruby que necesitemos. Por ejemplo, si queremos instalar las versiones 1.8.7, 1.9.1 y jruby, haremos lo siguiente:

rvm install 1.8.7,1.9.1,jruby

Lo cual tardará un rato, pues debe descargar y compilar todas las versiones que les hemos dicho. Para seleccionar una versión en concreto:

rvm use 1.8.7

Y para hacer que una versión en concreto esté seleccionada siempre por defecto:

rvm use 1.8.7 --default

Ahora ya podemos instalar las gemas que necesitemos en esta versión de ruby, como rails, mongrel, …

gem install rails mongrel linecache ruby-debug-base ruby-debug-ide

que se instalarán sólo en la versión de ruby que esté actualmente activa.

Eclipse, sin embargo, tiene problemas para pillar el entorno de desarrollo correcto, por lo que tenemos que modificar el script de arranque y poner algo como esto para arrancar eclipse con la versión por defecto de ruby (podemos sustituir default por una versión concreta si queremos):

bash -cl "rvm default; eclipse"

Jornadas de formación interna en ASPGems

Aprovechando que tengo un par de semanas de vacaciones entre mi anterior trabajo en Utende y el nuevo en ASPGems, ayer me acerqué a la sede de Madrid On Rails para asistir a una de las charlas de formación interna que hace ASPGems, en este caso,
Lecciones aprendidas desarrollando “webs un poco grandes” con Rails, impartida por Diego. La charla en sí estuvo bastante interesante, y siempre viene bien conocer los problemas de rendimiento que han tenido otros en sus webs para cuando te tengas que pelear con la misma situación. Claro que a algunas de las optimizaciones que afectaban a Rails no les saqué todo el jugo posible, porque mi conocimiento de Rails está todavía un poco verde, así que tendré que revisarme la presentación en unos meses, cuando me haya puesto las pilas.

Aparte de la charla, ese día tocaban varias reuniones de empresa, a las que me sumé para conocer el equipo con el que voy a trabajar en breve. A muchos de ellos ya los conocía de mis tiempos de Qarana e incluso de Utende (Javi y yo fuimos cofundadores, entre otros) por lo que sé cómo piensa Agustín y no me sorprendió demasiado su forma de trabajar o la transparencia de la empresa -de hecho, esas han sido algunas de las razones que hicieron que me cambiara de trabajo-. Pero lo que sí me ha sorprendido, y mucho, es lo online que han llegado a estar.

Acostumbrado a trabajar durante 5 años para la SGAE en sus oficinas, donde todo está alojado en sus servidores, es un soplo de aire fresco comprobar que en mi nueva empresa muchas cosas las hacen online, como por ejemplo el correo y los documentos en Gmail, el tracker en Pivotal Tracker, la participación interna con Yammer…, aparte, por supuesto, de usar Twitter, messengers, blog personales… Si ahora mismo, antes de conocer a fondo a ASPGems me pidieran que la definiera con una palabra, esa sería online

Hello world!

Aunque hacer un “¡Hola Mundo!” en WordPress ha resultado facilito (sudo aptitude install wordpress), el ponerle unos colorines que me gustasen ha echo que mi propósito de año nuevo de tener un blog público se haya quedado en agua de borrajas. Pero como no es serio tener el blog en construcción durante 2 semanas, al final me he forzado a elegir el tema y poner en funcionamiento el blog. Et voila!

Lo dicho, ¡Hola Mundo!