in web we trust Fernando Blat's blog, freelance web developer

Seguro que muchos ya conocéis este truco, pero para quien no, esta es una forma de comprobar diferentes valores para un mismo atributo en un test de unidad y comprobar que en todos los casos se cumple que es válido o no:

 def test_invalid_phone
   ['','abc','+341112233','123456789','123'].each do |phone|
     @m.phone = phone
     assert !@m.valid?     
     assert @m.errors.invalid?(:phone)
   end
 end

¿Tenéis algún truco más a la hora de realizar tests de unidad?

Yo sólo tengo que añadir que me gusta hacer dos tests por validación indicada en el modelo: una para casos positivos en el que es válido el atributo y otro para casos negativos, en los que se comprueban todos los valores que hacen el atributo no válido.

24 ways (to impress your friends) es una especie de recopilación con 24 trucos y tutoriales sobre desarrollo web muy actualizados, concretos y bien explicados. Si no recuerdo mal la actualización se realiza diariamente, por lo que día a día, hasta el 24 de diciembre vamos a ir viendo un nuevo post.

El proyecto surgió el año pasado y la verdad que la calidad de los artículos presentados a mí me sorprendió. Los podéis consultar en la edición 2005.

La sorpresa es que han hecho una edición 2006 y han empezado desde cero, con un artículo sobre cómo implementar un slider sobre párrafos de texto (podéis ver la demostración).

En resumen, mucho Javascript, Ajax y CSS para impresionar, no sólo a tus amigos sino a tí mismo.

Señor F:

if request.env['HTTP_X_FORWARDED_FOR']
   comment_IP = request.env['HTTP_X_FORWARDED_FOR']
 elsif request.env['HTTP_CLIENT_IP'] 
   comment_IP = request.env['HTTP_CLIENT_IP'] 
 else 
   comment_IP = request.env['REMOTE_ADDR'] 
 end

Señor S: "¿me dejas hacer un rubismo?"

Por cierto, el señor S da una charla en la Conferencia de Rails sobre la belleza de Ruby. Si asistís a la conferencia no os la perdáis, que hoy hemos visto el preestreno (con alfombra roja incluída) y promete.

Si alguna vez te sucede eso y te has leído las tres primeras páginas de resultados de Google y a pesar de eso no das con el problema quizá te interese este hack:

cd /usr/lib
 sudo ln -s mysql/libmysqlclient.so.15 

Firmado:
un afectado

Recientemente he desarrollado una pequeña aplicación web en Rails que he alojado en Dreamhost. Antes de lanzarme a utilizar Capistrano para actualizar el código utilicé un pequeño script de bash, ejecutándolo desde la propia máquina de Dreamhost.

Antes de mostrarlo, me gustaría comentar un par de asuntos.

Compartiendo datos releases

Imaginad que tenéis una carpeta en donde los usuarios suben ficheros. O queréis que el diseñador, que tiene conocimientos nulos de Subversion, pueda retocar la hoja de estilos sin que os tenga que avisar cada vez que hace una modificación para que subáis una nueva release.

A estas situaciones me refiero cuando hablo de compartir datos entre releases.

Una solución, que no la única, es crearse una carpeta shared, con los contenidos que queramos compartir en subcarpetas suyas.

Así, simplemente las versiones funcionales tendrán enlaces simbólicos a los datos compartidos en el directorio.

Por ejemplo: si tenemos la carpeta public/stylesheets y la queremos compartir, crearemos en el shared una carpeta shared/stylesheets y haremos un enlace simbólico de public/stylesheets a ésta.

La filosofía es muy sencilla.

Activación del entorno de producción

En Dreamhost no hay spawners ejecutando los FastCGIs, sino que estos se ejecutan tal y como vienen. Es decir, si queremos activar el modo production no hay más remedio que hacerlo en el config/environment.rb de nuestra aplicación.

Pero, claro, en local queremos modo desarrollo. Y además, no queremos que cada vez que subamos una nueva versión tengamos que modificar el config/environment.rb para descomentar la línea # ENV['RAILS_ENV'] ||= 'production'.

Así que lo que se puede hacer es dejarla descomentada y ejecutar el servidor local en modo desarrollo. Eso es tan fácil como indicar un parámetro adicional.

Tanto Mongrel como Webrick aceptan un parámetro -e con el nombre del entorno: mongral_rails start -e development

El script de andar por casa

El script es algo así:

#!/bin/bash
 
 date=`date -u +%Y%m%d%H%M00`
 svn export http://repository.url/app --force releases/$date
 rm current
 ln -s `pwd`/releases/$date current
 ln -s /home/user/app/shared/curriculumns current/public/curriculums
 ln -s /home/user/app/shared/stylesheets current/public/stylesheets
 ln -s /home/user/app/shared/vendor current/vendor
 touch current/public/dispatch.fcgi

Simplemente:

1. variable $date con la fecha y hora actuales
2. realizamos un export del repositorio en la carpeta releases/$date
3. eliminamos el antiguo current y enlazamos a la última versión
4. indiicamos todos los enlaces simbólicos de los datos compartidos
5. reiniciamos nuestros FastCGIs

En el próximo post sí que será ya una solución Capistrano.

He aquí un pequeño truco chapuzas para realizar una migración de datos entre una base de datos SQLite3 a una MySQL

Lo primero será hacer el dump de la base de datos SQLite:

 $ cd db/
 $ sqlite3 development.sqlite3
   SQLite version 3.3.5
   Enter ".help" for instructions
   sqlite> .output dump.sql
   sqlite> .dump
   sqlite> exit;
   sqlite> .exit
 

Lo que nos generará un fichero dump.sql el cuál debemos editar y:

1. eliminar cualquier referencia a TRANSACTION
2. sustituir cualquier comilla doble (") por una comilla escapada (`)

Y voilà, hagan el dump de ese fichero a su base de datos MySQL.

En un próximo post: ventajas de utilizar SQLite para desarrollar y testear en Ruby on Rails.

Esta es una pequeña función para saber si un plugin está cargado o no. Muy útil cuando compartes código entre varios proyectos y no en todos se van a cargar todos los plugins:

def plugin_loaded?(name)

   $LOAD_PATH.each do |p|

     if p =~ /#{name}/

 
       return true

     end

   end

   false

 
 end

 

$LOAD_PATH es una variable global de clase Array en la que se indican los diferentes directorios que se cargan en la ejecución de la aplicación. En dicha variable es en la que se van guardando las rutas a los diferentes plugins y que por tanto podemos utilizar y consultar para saber si está cargado o no.

Aquí un pequeño tip de los que siempre he tenido tener guardados y nunca lo he hecho.

Se trata de un script para generar exportar tu clave pública a otra máquina y no tener que introducir tu contraseña a la hora de acceder por SSH.

Lo primero, antes que nada es:

cd ~ && ssh-keygen -t dsa

Y decir que sí a todo e introducir una frase vacía , sin caracteres.

Hecho esto os podéis copiar este script (fuente) y modificar USERNAME por vuestro nombre de usuario.

 #!/bin/bash
 
 ## USAGE: add_to_server.sh remote_server
 
 ## This script will add your ssh dsa public key to remote_server's authorized_keys list, 
 ## assuming that everything is in it's default location
 
 set -v  # verbose output
 username="USERNAME"   # CHANGE ME!!!!
 remote_server=$1 # assigns the first commandline argument to $remote_server
 
 ## Pipe the public key to ssh, then remotely touch the file to make sure it will be there, and concat to the end of it.
 ## Might work without the touch?
 cat ~/.ssh/id_dsa.pub | ssh ${username}@${remote_server} "touch ~/.ssh/authorized_keys && cat - >> ~/.ssh/authorized_keys"
 
 exit 0
 

Hecho esto ya lo podéis utilizar con la siguiente sintaxis:

$ add_to_server.sh IP_de_host