Después de un mes de agosto intenso, por fin, hace un par de semanas rezets.com se puso en marcha, de momento con más ilusión que otra cosa.

Aquellos que me conocen sabrán de sobra que era una idea que me rondaba la cabeza desde hace bastante tiempo, y después de algún intento de llevarlo a cabo, por fin, a finales de junio decidí ver que era capaz de hacer en una semana de vacaciones y un mes de jornada intensiva aprovechando al máximo las calurosas tardes de agosto.

Y después de pelearme mucho con rails, con apache, con passenger y con un millón de historias más, hace unas semanas decidí subir todo al servidor de producción, y es que una vez acabada la jornada intensiva el tiempo que le puedo dedicar a este proyecto se ha reducido considerablemente. Aún así me parecía una tontería guardar ese código en el cajón e hice de tripas corazón.

Soy consciente de que aún tiene un montón de defectos y carencias (algunas más evidentes que otras), pero creo que ya he conseguido un par de cosas de las que sentirme orgulloso, como por ejemplo un lomo de cerdo con salsa de cebolletas, y una paella espectaculares. :D

Por ahora la funcionalidad de la web es muy sencilla: crear recetas nuevas, y verlas clasificadas por categorías, pero creo que por ahora debo centrarme en esa funcionalidad hasta que haya conseguido algo que realmente mejore la forma más habitual en que la gente sube sus recetas a internet: los blogs. Por eso voy a mantener la web cerrada a las nuevas altas durante una temporada para poder ir mejorando la web poco a poco con unos pocos usuarios de confianza, pero atenderé cualquier solicitud de usuario nuevo con mucho gusto.

Finalmente me gustaría agradecer a toda la gente que se ha dado de alta, y que pacientemente ha ido subiendo recetas, y todos los consejos recibidos por todos ellos.

¡Muchas gracias a todos!

Todo sea porque no nos vuelva a pasar cosas como ésta

Una de las características de HTML 5 introducidas en el reciente Firefox 3.5 y que también se encuentra disponible en Safari 4 y Chrome 2 son los web workers.

Los workers proveen un mecanismo para poder ejecutar tareas que requieran mucho tiempo de ejecución en hilos directamente en el sistema operativo sin que bloqueen la interfaz del usuario. Una de sus utilidades principales es la de ejecutar tareas de entrada/salida de datos a través del objeto XMLHttpRequest.

Los web workers se comunican con el proceso principal a través del envío de mensajes a un manejador de eventos especificado por el desarrollador. Estos mensajes pueden contener desde una cadena de caracteres a un objeto complejo. Una característica importante es que no pueden manipular el DOM por lo que si se desea mostrar los datos resultantes de su ejecución es necesarios que estos sean pasados al manejador a través del paso de mensajes.

Para crear un worker lo único que es necesario es llamar al contructor pasándole como único argumento la URI del script que deberá ejecutar, y definir el manejador del evento onmessage que será el encargado de escribir el resultado en la página.

var worker = new Worker('worker.js');

worker.onmessage = function(event) {

     print("¡llamada ejecutada al finalizar el worker!\n");
}

y para detener su ejecución:

worker.terminate();

Posteriormente deberemos implementar lo que hará el worker durante su ejecución en el archivo worker.js de la siguiente manera:

onmessage = function(event) {
     var n = calcular();
     postMessage(n);
}

Al finalizar la ejecución del método calcular el worker enviará un mensaje con el resultado que será recogido por el manejador del evento onmessage definido anteriormente.

El método calcular podría estar definido en otro archivo e importando mediante la función global importScripts('calcular.js') la cuál descagará y traerá dicha función al ámbito del worker.

Además cada worker puede lanzar tantos otros workers como se desee, lo único a tener en cuenta es que la ruta a el fichero que se le pasa en el constructor se calcula dinámicamente dependiendo de la localización del padre. Esto es muy aconsejable sobre todo en el caso de que el usuario posea un microprocesador con más de un núcleo, ya que el sistema operativo podría repartir los hilos entre estos.

Referencias

• Web Workers
• Mozilla Developer Center: Using web workers
• Using Web Workers

Cuando preparas las preguntas que quieres incorporar a un formulario debes tener en cuenta una serie de reglas que harán que cada una de las piezas de las cuales está compuesto encajen perfectamente y mejoren la experiencia de uso drásticamente. Para ello debes seleccionar cuidadosamente cuál es el tipo de control que se ajusta perfectamente a cada pregunta.

radiobuttons

Sólo deben ser usados cuando existe una lista de opciones mutuamente excluyentes, es decir, cuándo sólo es posible seleccionar una opción y la opción más frecuente debe estar marcada por defecto. El número de opciones debe rondar las cinco, dependiendo de su longitud y complejidad. Es importante que en el enunciado de la pregunta quede claro que se trata de seleccionar una de las opciones.

checkboxes

En cambio, los checkboxes deben ser usados cuando pueda ser seleccionada más de una opción, una, o ninguna. El caso de un único checkbox es usado cuando se debe activar o no una opción del formulario.

combo boxes

Son usados cuando tenemos un gran número de opciones y sólo podemos seleccionar una, ya que evita que el tamaño del formulario crezca excesivamente. Sin embargo, las opciones que contenga deben ser más sencillas y claramente excluyentes que en el caso de los radiobuttons, para evitar que los usuarios no encuentren la opción que buscan.

Evita la utilización del multi-combos ya que los usuarios no suelen comprender inmediatamente que pueden seleccionar más de una opción.

campos de texto

Los campos de texto son usados cuando se desea que se pueda introducir texto libremente. Lo más importante que uno debe recordar es que el tamaño del campo debe ajustarse al tamaño de la respuesta esperada, ya que los usuarios tienden a pensar que si su respuesta no cabe probablemente no será correcta. Si el tamaño de la respuesta esperada es muy grande, por ejemplo mayor de una línea, deben usarse los textarea en su lugar.

Cuando se usen campos de texto para introducir datos que requieran algún tipo de formato, como una fecha o un teléfono, debe procurarse que el usuario pueda introducir la información en el mayor número de formatos posible, dejando el manejo de la información a la aplicación. En cualquier caso en conveniente poner algunos ejemplos de los formatos permitidos junto al campo para que el usuario pueda comprender cómo debe introducir la información.

otros puntos a recordar

• No olvides asociar los labels a su campo correspondiente para que el usuario pueda seleccionar el control al pulsar el label.
• Los radiobuttons y los checkboxes deben estar agrupados en un fieldset con un título o legend adecuado. Esto permitirá a los usuarios dividir el formulario en bloques lógicos que pueden abordar por separado.
• los radiobuttons y los checkboxes deben situarse antes de su label, y los combo, campos de texto y textarea después.
• Marca claramente los campos obligatorios y procura que estén al principio del formulario.

Referencias

• Sensible Forms: A Form Usability Checklist
• Controles de formularios en diseño web, radio buttons, check-boxes...
• Checkboxes vs. Radio Buttons
• Formularios usables: 60 directrices de usabilidad

La mejora progresiva (o progressive enhancement) es una estrategia de desarrollo web en la que se destaca la accesibilidad, el marcado semántico, y el uso de hojas de estilo y scripts enlazados externamente.

Nace en contraposición a la estrategia clásica conocida como degradación agraciada (o graceful degradation) en la que los desarrolladores web crean sus páginas para los navegadores más recientes y posteriormente prueban y adaptan a los navegadores menos avanzados tecnológicamente.

La mejora progresiva se basa en los siguientes principios:

• El contenido básico debe ser accesible a todos los navegadores.
• La funcionalidad básica debe ser accesible a todos los navegadores.
• Mínimo marcado (X)HTML semántico para todo el contenido.
• Las mejoras de diseño son proporcionadas por hojas de estilo externas.
• Las mejoras de comportamiento son proporcionadas por JavaScript no intrusivo enlazado externalmente.
• Las preferencias de los navegadores de los usuarios son respetadas.

Para ello propone centrarse en el contenido y comenzar creando el marcado (X)HTML semántico al cuál se le irán añadiendo capas que lo enriquezcan.

De esta manera conseguimos que aquellos usuarios que usen navegadores antiguos, dispositivos móviles o sintetizadores de voz obtendrán un mejor soporte. De hecho, como vimos, gracias a las ventajas del (X)HTML semántico se mejorará la indexación de la página por parte de los buscadores lo que es básico en una estratégia SEO.

La primera capa que se añade a nuestro marcado (X)HTML semántico es la de CSS la cual nos permitirá mejorar el aspecto de nuestra página y en la que deberemos poner cuidado en la forma en la que enlazamos cada una de las hojas de estilo y los tipos de medios para los cuales deben estar disponibles de forma que se aprovechen las características de los navegadores nuevos siempre teniendo en cuenta de que el contenido debe ser accesible para el resto de los navegadores.

Finalmente añadimos la capa de JavaScript, previamente ha debido ser programada la funcionalidad básica de la web en el lado del servidor de forma que se pueda ejecutar independientemente del soporte de JavaScript que tenga el usuario, para posteriormente ir añadiendo mejoras en la usabilidad por medio de la programación en en lado del cliente. Para ello es imprescindible la utilización de técnicas de JavaScript no intrusivo como enlazar los scripts desde archivos externos o la eliminación de los manejadores de eventos en linea.

Cómo se puede ver todo el flujo de trabajo está orientado a que el contenido de la página, la razón por la cual los usuarios te visitan, esté siempre accesible en cualquier circunstancia independientemente de los medios de los que dispongan, ya que en el peor de los casos tendrán acceso a la capa de (X)HTML de nuestra web, y por tanto, tendrán acceso a su contenido.

Referencias

• Progressive enhancement
• Understanding Progressive Enhancement
• Progressive Enhancement with CSS
• Progressive Enhancement with JavaScript
• Progressive enhancement using CSS
• Pragmatic progressive enhancement

En general el ambiente que se ha podido ver ha sido divertidisimo, muy bien organizado y con muchas charlas de gran interés.

Del primer día entre destacaría, por supuesto, la keynote de Matz en la que repasó la trayectoria que ha seguido ruby para convertirse en lo que es: hacer el desarrollo de aplicaciones más rápido, más complejo y más barato. También señalo el camino que se debe seguir para entrar por derecho propio en el mundo empresarial como el multi-threading o la computación en la nube. Divertidísima charla de Javier Ramírez sobre programación de videojuegos con Gosu en la que montó un verdadero espectáculo y se reveló como un autentico showman.

Del segundo día destacaría sobre todo la charla sobre Adhearsion, plataforma para el desarrollo de aplicaciones sobre Asterisk. Y la de Rhodes framework para el desarrollo de aplicaciones móviles, sin olvidarnos de la marcha que le dio a la euruko Pablo Formoso con su charla sobre archaeopteryx. Y finalmente la charla sobre Cucumber en la que se hizo un repaso de sus virtudes.

Por otro lado las charlas relámpago (lightning talks) se mostraron como un método muy ágil de dar entrada a charlas que por su extensión o temática no hubieran tenido cabida en el programa original.

Para finalizar la edición del 2009 se seleccionó como organizador euruko 2010 a Cracovia (Polonia).

Al final un buen recuerdo y un gustazo haber pasado el fin de semana en Barcelona.

Xavier Noria golpeando el gong en las lightning talks