Con este post no os voy a descubrir nada nuevo a muchos pero aquí quedará para la posteridad.

Ahora que tenemos gemcutter el “awesome gem hosting” (tal como se describen ellos mismos) debemos hacer que nuestro origen principal de gemas sea este.

Esto lo hacemos de manera muy simple y en 3 pasos.

1. Actualizamos Rubygems a la última version:

$ sudo gem update –system

2. Instalamos la gema gemcutter:

$ sudo gem install gemcutter

3. Cambiamos el origen de las gemas con el comando:

$ sudo gem tumble

Esto es todo

Actualización:

Parece que eso no era todo.

Diego, un programador cualquiera , me ha recordado de que os avise que la orden para actualizar Rubygems(paso 1) se usan 2 guiones que Wordpress se ha emperrado en poner como si fuese uno largo.

La mayor parte de la documentación que hay por ahí sobre como configurar Apache para poder usar la tarea de Capistrano deploy:web:disable es usar la directiva RewriteRule para ver si existe la página de mantenimiento.

Aparentemente está bien, pero no es así porque no cambia el código de la respuesta. Los clientes recibirán un 200 OK, indicando de que el servidor está funcionando como debe. El código de estado correcto debiera ser 503 Service Unavailable. Con un 503, conseguiremos prevenir que los motores de búsqueda indexen nuestra página de mantenimiento, a los que usan nuestra API les haremos la vida mas fácil, las peticiones AJAX pueden ser tratadas correctamente cuando el site se ha caído, etc.

La configuración de apache para realizar esto es la siguiente:

Leer más…

Siempre que se hace un formulario de contacto tengo la misma necesidad, validarlo. ¿Teniendo las validaciones de AR para qué quiero reinventar la rueda?

El otro día encontré una solución en un blog que me pareció interesante pero solo funcionaba con rails 2.2 aparentemente. Digo aparentemente porque el primer comentario me indicaba como apañarlo para rails 2.3.

Leer más…