Fernando Espinosa - Ferdev

Cambiar el idioma a selenium

Sat Aug 14 00:00:00 +0200 2010

Ayer me encontré con un problema haciendo tests para un pet-project que estoy haciendo con Rails3 3.0.0.rc. Parece ser que a partir de la versión 1.0.0.beta.9 de bundler, culerity lanza un error a la hora de crear el browser con celerity. Mientras investigo el problema, no quería dejar el desarrollo parado, así que decidí cambiar el driver de capybara a selenium. Pero el firefox que trae el driver de selenium integrado se me ejecutaba en castellano, y yo tengo los tests escritos en inglés, por lo que fallaban. Tras twittear buscando ayuda, @pacoguzman me pasó un link(gracias!) de la gente de Teambox que tenía la clave para solucionarlo.

Lo solución consiste en extraer el profile del driver de selenium, pasarle la nueva clave del idioma, y volver a asignar el profile al driver de selenium. La clave que había que pasar era ‘intl.accept_languages’ (sacado de hacer un about:config en mi Firefox y buscar un poco) junto con el lenguaje que quieras usarlo, en mi caso ‘en’. Como yo estoy usando Steak para mis test de aceptación, incorporé el código en el archivo de configuración ‘spec/acceptance/acceptance_helper.rb’:

Capybara::Driver::Selenium.class_eval do
  class << self
    def driver
      @driver ||= begin
        profile = Selenium::WebDriver::Firefox::Profile.new 
        profile['intl.accept_languages'] = 'en'
        driver = Selenium::WebDriver.for :firefox, :profile => profile
        at_exit { driver.quit }
        driver
      end
    end
  end
end

Y listo, selenium en inglés y todos los tests pasando!

Blog migrado a Jekyll

Mon Jul 05 00:00:00 +0200 2010

La semana pasada me lié la manta a la cabeza y me puse a migrar todo el blog de Wordpress a Jekyll. Los motivos que me han llevado a moverlo a Jekyll son dos: velocidad y sencillez. Jekyll es un generador de sitios web estáticos programado en ruby. Jekyll genera a partir de plantillas y ficheros markdown o textile, ficheros html y xml (entre otras cosas). Al ser contenido estático, pierdes algunas cosas como el sistema de comentarios. Pero con Disqus o IntenseDebate queda solucionado el problema.

De paso he aprovechado para hacer un pequeño rediseño, y ahora tengo todo el contenido de la web en el mismo html, y mediante un pequeño javascript se realiza el scroll entre las diferentes secciones. Simplemente obtiene el atributo ‘href’ del enlace, obtiene el elemento al que referencia y su offset vertical, y anima el desplazamiento del cursor principal hasta esa posición. Además degrada bien si el usuario no tiene el javascript activado.

$('#menu li a').live('click', function(evt){
  evt.preventDefault();
  var 
    destination_id = $(this).attr('href'),
    scrollTo       = $(destination_id).offset().top;
  $('html,body').animate({scrollTop: scrollTo}, 2000, 'easeInOutExpo');
});

He publicado el código fuente del blog por si queréis echarle un vistazo (aunque no tiene gran cosa que ver). Todavía no está terminado, faltan algunas cosas como la paginación de posts y algunos retoques más, pero como ya es funcional me he decidido a publicarlo.

RightJS, un framework javascript muy interesante

Mon May 10 00:00:00 +0200 2010

Llevaba tiempo queriendo escribir acerca de este framework javascript, uno de los más interesantes del momento. Quizá no sea tan conocido como jQuery o MooTools, pero en mi opinión merece estar tan arriba como ellos. Además, ciertos elementos de su sintaxis resultarán familiares a los rubistas. Más adelante explicaré cuales.

La mejor manera de hablar de RightJS es comentar sus características principales:

Sintaxis sencilla y curva de aprendizaje baja. Si ya conoces otro framework como jQuery o Prototype, te costará muy poco aprender RightJS.
Posiblemente, el más rápido de todos los frameworks JavaScript. Difícil de demostrar, pero diversos tests parecen corroborarlo. No sé si el más rápido, pero desde luego es rapidísimo.
Llamadas a funciones por nombre. Muchas veces tenemos el típico callback para acceder a un método del propio objeto. Con RightJS no necesitaremos dicho callback, símplemente pasaremos el nombre de la función como string.

// Modo habitual
$('element').onClick(function() {
  this.hide();
});

// Usando llamadas por nombre
$('element').onClick('hide');

Soporte en navegadores más antiguos de la última especificación JavaScript/ECMAScript. Por ejemplo:

Array#filter:

var strings = ['anny', 'manny', 'banny', 'bob'];

strings.filter(function(string, i) {
  return string.length > (i+1);
});
// -> ['anny', 'manny', 'banny'];

strings.filter('match', /[a-z]ann/);
// -> ['manny', 'banny']

Array#map:

var strings = ['anny', 'banny', 'manny'];

strings.map(function(string, i) {
  return (i+1)+'. '+string;
});

// -> ['1. anny', '2. banny', '3. manny'];

strings.map('capitalize');

// -> ['Anny', 'Banny', 'Manny'];

strings.map('replace', 'nn', 'b');

// -> ['aby', 'baby', 'maby'];

String#trim:

' asdf '.trim(); // -> 'asdf'

Extensión del core de JavaScript con algunos métodos que sonarán a muchos rubistas:

Array#compact:

[null, 0, undefined, 1, 2, 3, null].compact();

// -> [0, 1, 2, 3];

String#endsWith:

'image.gif'.endsWith('.gif');       // -> true

'image.gif'.endsWith('.GIF');       // -> false
'image.gif'.endsWith('.GIF', true); // -> true

Manejo de números simplificado.

// Conversión de string a number
'123'.toInt();   // -> 123
'1.3'.toFloat(); // -> 1.3

// Manejo de números
1.4.floor(); // -> 1
1.4.ceil();  // -> 2
1.4.round(); // -> 1

Aunque JavaScript ya es un lenguaje orientado a objetos, la clase Class hace más sencilla la herencia, implementación de interfaces, etc.

var Klass = new Class(AnotherClass, {
  include: Module1,
  extend:  Module2,

  initialize: function() {
    //....
  }
});

Y también: envío simplificado de formularios, uso de spinners automáticos en peticiones AJAX, manejo unificado de eventos y opciones de métodos, arquitectura abierta, soporte para plugins, y una gema para facilitar la integración con Rails (soporta Rails3).

Como véis, es un framework al que merece la pena echarle un vistazo. Sobre todo si eres un desarrollador de back que no te sientes muy cómodo con la parte front (está orientado principalmente a desarrolladores Rails, como se puede ver). Creo que bien merece uno de vuestros PetProjects ;-)

Rediseño del blog y freelanceo

Tue Mar 23 00:00:00 +0100 2010

La semana pasada he estado dándole un pequeño rediseño al blog. El diseño que había era el resultante de haber hecho unas cuantas pruebas, y al final por falta de tiempo no había podido cambiarlo. Quería algo minimalista, con buena legibilidad, y con el menor número de imágenes posible.

De hecho, la única imagen es el nuevo logo (a excepción de los iconos de social media, que son de Komodo Media). Y he creado un logo porque me embarco en la aventura del desarrollo freelance, y éste será mi nueva identidad visual. Últimamente estoy viendo mucha gente que se dedica a ello y me he decidido a dar el salto. Así que si alguien necesita un desarrollador Ruby on Rails, javascript, php, java o .NET, aquí me tenéis!

Testing AjaxUpload con Capybara + Culerity

Wed Mar 10 00:00:00 +0100 2010

Llevo unos días probando Capybara después de los comentarios tan buenos que había escuchado de él en twitter últimamente, especialmente de su integración con Culerity. Los hados además trataban de decirme algo porque la última charla de madridrb que dio @porras versaba sobre esto mismo (y Steak, que también estoy probando y me está gustando mucho). Por cierto que debería haber ido a la charla (pero no pude :-() porque seguro que me hubiese ahorrado muchos de los problemas que me encontré.

Los primeros vinieron con la instalación. Culerity es un recubrimiento (que poco me gusta esta palabra) de Celerity, que a su vez es otro recubrimiento de HtmlUnit, un navegador web sin interfaz gráfico programado en Java. Y debido a esto, necesitas Jruby para instalar la gema de Celerity. Pues bien, rvm y todo este tinglado no se llevan demasiado bien. Y aunque hay un hack para salir al paso, a mi no me valía del todo (a parte que no me gustaba mucho que digamos) porque yo no estaba usando Cucumber sino Steak (requisito para que funcione el Hack). Al final conseguí hacerlo funcionar instalando Jruby mediante Macports. No sé si me dará problemas en el futuro, pero hasta que Culerity y rvm se lleven mejor, me gusta más esta solución que andar cambiando variables de entorno en cada test.

La aplicación con la que estaba haciendo las pruebas tiene una carga de javascript muy alta, y los primeros problemas que me dieron los tests lo achacaba a esto. “Demasiado javascript”, pensaba para mis adentros cuando al testear una petición ajax me daba un error con la respuesta en formato JSON. Dándole vueltas y más vueltas, a punto de desinstalarlo todo porque no conseguía solucionarlo, di con la solución no recuerdo muy bien dónde: la última versión de Celerity (0.7.9) usaba una versión de HtmlUnit con algunos bugs, y recomendaban instalar la versión 0.7.4. Pues mano de santo oiga :-)

Y llegamos al quid de la cuestión: probar AjaxUpload con Capybara + Culerity. Me ha costado un par de días hacerlo funcionar, y en realidad ha sido una tontería. No hacía falta más que detenerse un poco a pensar como funciona AjaxUpload por dentro.

AjaxUpload es un hack para simular una subida asíncrona de un archivo al servidor de nuestra página web. Para ello, se vale de los siguientes pasos:

Se asocia al elemento de la página web que tú hayas definido (un enlace o un botón, por ejemplo).
Cuando se dispara el evento “mouseover” sobre ese elemento, crea un div transparente de las mismas dimensiones que el elemento y lo sitúa por encima de él. Cuando el usuario intente pulsar el elemento, será este div en realidad el que se vea pulsado.
Cuando el usuario hace click en el div, se genera el elemento input file y se abre el diálogo de selección de archivo.
En cuanto el usuario selecciona el fichero, AjaxUpload crea un formulario, le agrega el input file del paso anterior, y crea un iframe. Este iframe, será el “target” del formulario recien creado.
AjaxUpload envía el formulario (que hará la subida del fichero a través del iframe) y fin del proceso.

Mi problema venía con el diálogo de selección. No veía cómo conseguir seleccionar el archivo y pulsar el botón “Aceptar” del diálogo de selección. Sabía que la clase Celerity::FileField contaba con el método Set, con el que podía pasarle la ruta de un archivo… Pero no sé por qué me dio por pensar que si el diálogo estaba abierto, no funcionaría. Hasta que lo probé, y me di cuenta que Celerity establece la ruta del archivo y cierra la ventana de diálogo él solito. Así que, problema resuelto.

Aquí va un pequeño trozo de código de como quedaría montado. He sacado los selectores principales a variables para que se entienda mejor. Ah! También decir que yo tengo configurado Capybara para que por defecto use selectores css :-)

# selector del botón asociado a AjaxUpload
button_selector = 'button#upload'
# selector del div que contendrá al input file. Se posicionará justo encima de button_selector
div_selector = 'div.ajaxupload_container'
# selector del input file
input_selector = 'div.ajaxupload_container input.ajaxupload'
# ruta al archivo a subir
file_path = 'image.jpg'

# Simulamos el evento 'mouseover' sobre el botón original asociado a AjaxUpload
find(button_selector).trigger(:mouseover)

# Comprobamos que se haya creado el div de AjaxUpload
page.should have_css(div_selector)

# Hacemos click en el div para disparar la creación del input file
find(div_selector).click

# El input file debería haberse creado
page.should have_css(input_selector)

# Le pasamos la ruta de archivo al input file
find(input_selector).set(file_path)

Y ya está! Una aclaración: he modificado AjaxUpload para que asigne una clase al div y al input file que crea y sea más sencillo seleccionarlos, ya que por defecto no les asigna identificador ni clases de ningún tipo.

Plugin jQuery para obtener dimensiones de un objeto

Sat Oct 31 00:00:00 +0100 2009

Hola!

Hace mucho que no escribo por aquí, no dispongo de demasiado tiempo… Como podéis ver, cuando saco unos minutos voy haciendo pruebas de diseño con el blog. Tengo intención de pasarlo a HTML5, usar CSS3 al máximo e intentar usar el menor número de imágenes posibles, a ver si lo consigo :D Bueno, al grano.

Trabajando en un proyecto me surgió la necesidad una vez de conocer las dimensiones (alto y ancho) de unos objetos ocultos que luego estaba agregando a otros elementos del DOM de mi página. El problema es que por diversas razones, necesitaba conocer su tamaño antes de agregarlos al objeto DOM, y jQuery, aunque cuenta con unos maravillosos métodos para obtener el tamaño de cualquier objeto (tanto tamaño exterior, contando el ancho de los bordes y demás, como el tamaño interior del objeto, sin bordes ni nada). El problema, es que si el objeto está oculto (display: none), jQuery no puede calcular el tamaño y te devolverá cero.

Hay una solución muy sencilla para esto. Agregas el objeto con el tamaño a calcular a una capa que tendremos posicionada en modo “absolute” y fuera de la vista del usuario (fuera del viewport del navegador), dándole una posición “left: -1000px” (por ejemplo). Así, el objeto no es necesario que esté oculto, jQuery podrá calcular sus dimensiones y no lo tendrás dentro del flujo de la página, por lo que no te descolocará nada.

Aquí os dejo el código del plugin, tal y como lo vengo usando en mi proyecto. Espero que os sea útil!

;(function($){
$.fn.objectSize = function(){

    function calculateSize(domNode){
        var divSizer = $(document.createElement("div"))
        .attr("id", "sizer")
        .css({           
            width: '100%',
            height: '100%',
            position: 'absolute',
            left: '-10000px' 
        }).appendTo('body'),
        size = {width: 0, height: 0};
    
        divSizer.append(domNode);
        size.width = parseInt(domNode.outerWidth());
        size.height = parseInt(domNode.outerHeight());
        divSizer.remove();
        delete divSizer;
        return size;
    }

    return calculateSize($(this[0]));
};
})(jQuery);

SWFUpload, Rails y los 406

Tue Oct 06 00:00:00 +0200 2009

En una aplicación que tenía funcionando en Snow Leopard con SWFUpload para subir imágenes al servidor, y RoR en el lado del servidor, me estaba dando problemas al realizar los uploads desde Internet Explorer 8. En concreto, el servidor me devolvía un error 406 tras haber guardado la imagen y justo antes de realizar la respuesta al navegador(en formato json). El error 406 se produce cuando desde el servidor se está respondiendo a una solicitud con un tipo MIME que no está soportado dentro de la cabecera ACCEPT que envió el navegador. El servidor no sabe qué hacer con la solicitud, y lanza ese error.

Bien, pues se produce en concreto con IE8 en Windows XP porque SWFUpload envía como único tipo MIME en su cabecera ACCEPT el tipo “text/”. Imagino que es un problema con el plugin de Flash de Windows (Flash 10 estaba usando), y que si lo pruebo con otro navegador en Windows sucederá lo mismo, no lo he probado.

Para solucionarlo, en primer lugar deberemos añadir un nuevo tipo MIME al environment.rb de nuestro proyecto:

Mime::Type.register "text/*", :all_text

Luego, en la acción en la que estemos guardando la imagen, tenemos que añadir un nuevo manejador de este tipo de peticiones:

respond_to do |format|
	format.all_text{ render :text => text_to_render }
end

Y eso es todo, con esto Internet Explorer 8 debería estar recibiendo el resultado de la subida de una imagen con SWFUpload.

Registro progresivo en paginas web

Tue May 26 00:00:00 +0200 2009

Como no he tenido mucho tiempo últimamente de cambiar el diseño del blog, pero sí lo tengo para escribir algunos artículos, cambio el tema de wordpress por uno más vistoso hasta que pueda modificar el genérico.

Comienzo hablando de un tema que en mi opinión es muy interesante (y útil), y que no he visto implementado en ningún sitio aún. De hecho aunque los habrá, yo no he visto ninguno. Se trata del registro progresivo de datos en formularios.

¿En qué consiste? Es un patrón de desarrollo, por tanto es aplicable a cualquier tipo de tecnología web, no está atado a ningún framework o lenguaje. Va muy de la mano de la gestión de las cookies, y de un modelo de datos organizado y pensado desde un principio para soportar esta técnica. El objetivo principal de este patrón de desarrollo es evitar una de las barreras de entrada más colosales de cualquier sitio web: el registro de usuarios en un sistema para permitir la interacción del éstos con el mismo. ¿Cuantas veces hemos reculado al entrar a un sitio y ver que tenemos que registrarnos para realizar la acción más sencilla, como comprar en una tienda on-line? Estoy seguro que los sitios con esta barrera de entrada tienen una gran pérdida de usuarios (igual a dinero) por este motivo. Voy a tratar de describir en líneas generales el proceso a seguir para implementarlo y sus desventajas (que las tiene, claro).

Básicamente, el proceso consiste en registrar en algún motor de persistencia (una base de datos en el mayor de los casos) los datos que un usuario no registrado va introduciendo en el mismo a lo largo del tiempo y sus sucesivas visitas. Es decir, un día un usuario entra a la web, introduce su dirección para una cosa, otro día vuelve a entrar e introduce su fecha de nacimiento, y así sucesivamente. La clave del patrón está en registrar esa información y tenerla disponible para el usuario para que, en caso de que algún día se decida a formalizar su registro en la web, ofrecerle toda esa información que el usuario ha ido acumulando en su interacción con el sitio. De este modo, el usuario llegado a ese punto, sólo tiene que introducir los datos obligatorios para realizar el registro (por ejemplo, email y contraseña) y automáticamente su perfil queda creado junto con los datos que el usuario fue introduciendo. Es una ventaja para la página web, porque cuenta con un conjunto de datos de los usuarios no registrados que de otra forma no tendría, y una ventaja para el usuario porque facilita enormemente su interacción con el sitio.

Pero, todo hay que decirlo, esta técnica tiene sus inconvenientes, y parte de algunas premisas que no se pueden dar en todos los sistemas. En primer lugar, para poder hacer uso de esta técnica, el navegador del usuario que se conecta debe tener las cookies habilitadas. Sin esta primera condición es imposible montarlo. O mejor dicho, yo no sabría cómo hacerlo. Se podría hacer registrando la dirección IP del usuario que se conecta, pero teniendo en cuenta que en España la gran mayoría de los usuarios utilizan ADSL’s con ip dinámica, no veo esta opción factible. Por otro lado, el uso de cookies es la principal debilidad de esta técnica. Las cookies tienen una fecha de caducidad. E incluso antes de que se consuma esta fecha, el usuario puede perfectamente hacer una limpieza de sus cookies, con lo que perdemos el enlace del usuario con los datos que ha ido almacenando en el sitio. Y este problema nos lleva al siguiente: cuando un usuario borra o pierde su cookie del sitio web, y se nos quedan todos sus datos huérfanos, están ocupando un espacio valiosísimo en el motor de persistencia, que habrá que borrar de alguna manera.

A pesar de los problemas, me parece una técnica muy interesante como para dejarla de lado. ¿Qué porcentaje de usuarios tiene las cookies desactivadas en su navegador? No sé cual es la estadística, pero estoy seguro que no es muy elevada. Además, ¿qué problema hay si el usuario no las tiene? Símplemente no podrá usar esta funcionalidad, y por otro lado tendríamos una gran cantidad de usuarios (los que sí tienen las cookies activadas) haciendo uso de ella. Se le podría aconsejar que las active llegados a ese punto si así lo creyesen necesario los desarrolladores. Y respecto al borrado de los datos huérfanos… Tampoco es problema llevar un registro de las cookies que llevan más tiempo sin usarse y hacer una limpieza de datos cada X tiempo. Cuestión de sopesar los pros y los contras.

Entrando más en detalle de susodicha técnica, creo que lo mejor es poner un ejemplo que es como mejor se entienden las cosas. Pongamos como ídem una tienda de comercio electrónico, con su carrito de la compra y su formulario de registro final. Sin emplear este patrón, el proceso de compra para el usuario sería:

El usuario agrega un producto al carrito, y pulsa en “formalizar compra” para proceder a su pago.
El sitio web necesita saber a quién y a dónde enviar el producto, por lo que le muestra dos formularios (generalmente) según el caso:
1. Formulario sin registro: el usuario introduce sus datos y su dirección ya que no está registrado, y así el sistema obtiene sus datos.
2. Formulario con registro: el usuario ya está registrado en el sitio, introduce su usuario y password, y el sistema ya tiene sus datos para realizar la compra.
Ya con los datos del usuario, la web muestra el formulario de pago y la compra finaliza (el usuario a pesar de la crisis tiene mucha pasta, y finaliza la compra sin problemas:D).

Ahora, empleando el nuevo patron:

Un usuario entra al sitio web. Se busca una cookie en la cual hemos guardado su identificador de usuario.
1. Si no encontramos la cookie, creamos un usuario nuevo en la base de datos, vacío, pero con una clave primaria única. Con esta clave primaria única, creamos una nueva cookie y guardaremos este identificador en ella.
2. Si encontramos la cookie, buscamos en la base de datos el identificador de usuario almacenado en la misma. De este modo hemos recuperado los datos de un usuario de la base de datos.
El usuario navega por la tienda, y decide añadir un producto al carrito. Luego le da a “formalizar compra” porque no quiere nada más, que está la vida muy cara.
Le presentamos el formulario de contacto al usuario, y aquí es donde entran en juego las bondades de esta técnica.
1. El usuario es asiduo comprador de nuestra tienda, ha realizado otras compras y tenemos todos los datos que ha introducido anteriormente en la base de datos. Como hemos recuperado la instancia del usuario en el primer paso, se los mostramos por si quiere validarlos o corregir algo. Al usuario símplemente le queda introducir sus datos de pago si es necesario, y el proceso ha finalizado.
2. El usuario no había comprado nunca, por lo que rellena los datos del formulario necesarios para poder realizar el pedido. Estos datos, se guardan en la base de datos contra el usuario que hemos recuperado en el paso uno. Si el usuario vuelve a entrar alguna vez a la tienda y su cookie sigue existiendo (lo más probable, en mi humilde opinión), podremos recuperar su identificador de usuario y mostrarle sus datos.
El usuario sin registrar vuelve al cabo de los dias, hace otra compra y decide registrarse en la tienda (para beneficiarse de unos vales de descuento disponibles sólo para usuarios registrados, por ejemplo). Nada más tendrá que introducir su email y contraseña (o los datos que sean necesarios para el registro) y quedará registrado.

Quizá se pueda poner un ejemplo más correcto del uso de esta técnica, pero creo que la idea se capta. En mi opinión es para tenerla en consideración, y si además la complementamos con algún sistema de identificación como OAuth o Facebook Connect, creo que puede llegar a ser una herramienta muy poderosa.

Más adelante escribiré un post sobre su implementación en una web desarrollada con Ruby on Rails.

Paso 1: wordpress instalado

Fri May 08 00:00:00 +0200 2009

Empiezo las andanzas en el mundo “blogueril” personal. Me llamo Fer, y en este blog intentaré transmitir lo mejor que pueda los conocimientos que he ido adquiriendo a lo largo de mi vida en el mundo del desarrollo de software (y un poquito de diseño también, pero poco, que no es lo mío).

Como primer paso he conseguido un dominio, un servidor y la última versión de wordpress 2.7.1.

Poco a poco, iré implementando mi propio tema de wordpress. Para ello, parto de la base del tema Carrington Jam, tema especialmente pensado para modificarlo a gusto del consumidor. Para realizar este tema, principalmente utilizaré el framework javascript jQuery 1.3.2, mi favorito de entre todos los actuales.

Falta algún plugin, publicidad para sobrellevar la crisis, añadir mi cuenta de twitter… Poco a poco iré actualizando.

Bienvenidos :-)