Para el que pueda interesarle dejo aquí las transparencias que hice:

Y el vídeo de la charla grabado por Madrid.rb:

Making code tastier through refactoring from Madrid.rb on Vimeo.

Algunos libros que se pueden consultar sobre el tema son:

• Refactoring to Patterns - Joshua Kerievsky
• Clean Code - Robert C. Martin
• Design Patterns in Ruby - Russ Olsen
• Source Making

Y algunas herramientas interesantes:

• Reek - Code Smell Detector for ruby
• Rails Best Practices
• Code Climate
• Ruby Refactoring Tool for Vim

Si estuviste allí por favor puntúa esta charla:

La primera edición de la Conferencia Internacional de JavaScript, Spain.js, tendrá lugar los días 5, 6 y 7 de Julio en Madrid.

En ella podremos disfrutar de desarrolladores tan destacados como Jeremy Ashkenas (creador de CoffeeScript y Backbone.js), Alex MacCaw (creador de Spine.js), Vicent Martí (Github) y Karolina Szczur (Nodejistsu) entre otros muchos.

El objetivo del evento es dar un empuje a un lenguaje que siempre ha tenido una consideración menor para los programadores, pero que cada vez está más presente en nuestro día a día.

¡Espero veros allí!

Otro año más se vuelve a celebrar en Madrid la Conferencia Rails, encuentro anual de desarrolladores y empresas alrededor de Ruby on Rails, y este año vuelve más internacional que nunca con speakers tan destacados como Sven Fuchs, Paolo Perrota, Simon Tokumine, Nicolás Sanguinetti,.. y viejos conocidos como Javier Ramírez o Sergio Gil.

Si estás interesados en temas como la programación web, la integración continua, programación para dispositivos móviles, Node.js, Backbone.js, CoffeeScript... Te esperamos del 13 al 15 de Julio en el Retiro.

• Less features
• Less options/preferences
• Less people and corporate structure
• Less meetings and abstractions
• Less promises

37 Signals - Getting Real: Build Less

Las metodologías ágiles se basan en 4 principios fundamentales recogidos en el manifiesto ágil.

• Individuos e interacciones sobre procesos y herramientas.
• Software funcionando sobre documentación extensiva.
• Colaboración con el cliente sobre negociación contractual.
• Respuesta ante el cambio sobre seguir un plan.

Scrum toma esos principios y propone los siguiente:

• Divide las tareas en pequeños incrementos con una planificación mínima.
• Estos incrementos son llamados Sprints y suelen durar entre 2 semanas y 1 mes.
• Pone énfasis en la comunicación cara a cara.
• Los equipos son multidisciplinares y auto-organizados de entre 5 y 9 personas.
• El software funcional es la primera medida de progreso.
• Se realizan periódicamente entregas del producto, lo que permite:
  • Evaluar el trabajo realizado.
  • Advertir sobre problemas que se detecten.
  • Sugerir mejoras.

Existen 2 tipos de roles: cerdos y gallinas.

Los cerdos son aquellos roles que están comprometidos directamente en el desarrollo del producto:

1. Product Manager: Representa a la voz de cliente. Escribe y prioriza las historias de usuario.
2. Scrum Master: Su trabajo es eliminar los problemas que impiden que el equipo alcance el objetivo del Sprint.
3. Scrum Team: Responsables de la entrega del producto. El equipo debe reunir todas las habilidades necesarias para el éxito del proyecto.

Las gallinas son todos aquellos que aunque están involucrados en el desarrollo del proyecto, no está comprometidos, es decir, no forman parte directa del scrum. Este grupo está formado por usuarios, clientes y managers.

Por otro lado, scrum propone una serie de artefactos que nos permiten gestionar las tareas y tener más control sobre lo que está pasando en cada momento del Sprint.

Product Backlog Es una lista de requisitos priorizados, con estimaciones que son recogidos por el Product Manager en colaboración con el cliente. Normalmente estos requisitos son escritos en forma de historias de usuarios y deben ser lo más detalladas posibles para ayudar en la medida de lo posible ha realizar las estimaciones. Esta lista debe ser revisada con frecuencia con objeto de ajustar prioridades, estimaciones y re-priorizar las historias de usuarios.

Sprint Backlog El Sprint Backlog agrupa las tareas que se han seleccionado al inicio de la iteración del Product Backlog para ser desarrolladas durante la siguiente iteración. Las tareas deben ser más detalladas y las estimaciones más aproximadas. Ninguna tarea debe durar más de dos jornadas de trabajo, en ese caso debe dividirse en varias tareas más concretas.

Burn Down Es una gráfica que muestra el avance del equipo en el desarrollo de la iteración. En el eje Y se encuentras los puntos de historia a realizar durante la iteración, y el eje X los días disponibles. Cada día se va trazando una línea desde arriba a la izquierda hasta abajo a la derecha donde se podrá ver el trabajo restante. Un ejemplo de burn down lo podemos ver en la wikipedia.

Tablón de Scrum Es un poster, normalmente dividido en 3 o 4 columnas que nos permite de un simple vistazo saber en qué estado se encuentra la iteración. En la primera columna (ToDo) se agrupan las tareas que quedan por hacer, En la segunda las que se están desarrollando en ese momento (WIP: Work In Progress) y en la tercera las tareas terminadas (Done). En la cuarta podemos poner nuestro Burn down y las tareas imprevistas o impedimentos.

Finalmente, para reforzar la comunicación cara a cara del equipo, scrum propone 4 tipos de reuniones o ceremonias.

Planificación de Scrum Esta reunión se realiza al comienzo de una iteración y en ella el equipo debe seleccionar del Product Backlog las tareas que se realizaran en el siguiente Sprint y añadirlas al Sprint Backlog. Las tareas deben seleccionarse en función de su prioridad y el valor que aporten al negocio y posteriomente estimarlas para intentar predecir cuanto trabajo será posible sacar adelante en la siguiente iteración.

Daily Scrum Se realiza todos los días a la misma hora en el mismo lugar y todos los miembros del equipo deben permanecer de pie durante el tiempo que dure la reunión que no debe sobre pasar los 15 min. Pueden asistir todas las personas involucradas pero sólo pueden hablar los cerdos. Durante la reunión el Scrum Master pregunta a cada miembro del equipo qué hizo durante el día anterior, qué va a hacer ese día y si ha tenido algún impedimento para alcanzar su objetivo.

Revisión de Sprint En las reuniones de revisión de Sprint se revisa el trabajo planificado y se presenta a los interesados en forma de demo.

Retrospectiva Al final de cada iteración el equipo de trabajo se reúnen para discutir sus impresiones sobre el Sprint anterior y para proponer mejoras que puedan aumentar el rendimiento del equipo.

Además de todo lo anterior existen otra serie de herramientas que un equipo de desarrollo ágil pueden incorporar para mejorar su productividad. Las habituales suelen ser:

• Test Driven Development.
• Test de aceptación.
• Integración Continua.
• Refactoring.
• Pair Programming.

Al final lo más importante es encontrar la metodología con la que el equipo se encuentre más cómodo y que les permita ser más productivos, realizar el máximo número de tareas posible y ser capaces de corregir errores e incorporar cambios durante el desarrollo del producto, para que finalmente el cliente obtenga el producto que mejor se ajuste a sus necesidades.

La idea fundamental de lo que pretendía conseguir es la siguiente:

Todo esto usando para ello un helper de FormBuilder para que el objeto concreto quede implícito y que el código resultante (en haml) nos quede como el siguiente:

= form_for @user do |form|
   .field
      = form.label :name
      = form.error :p, :name
      = form.text:field :name

El primer parámetro indica el tag html que queremos usar como contenedor del error, y el segundo en atributo del modelo que debemos comprobar. Además, al tag contenedor le añadiremos la clase "error" de css para luego poder darle algunos estilos.

Tras dar algunas vueltas googleando me dí cuenta de que crear un nuevo helper no era tarea demasiado complicada, así que le eché un ojo a FormHelper y observé que está dividido en tres partes principales:

1. El modulo FormHelper, que encapsula a todos los helpers de formularios.
2. La clase FormBuilder, que es el resultado de usar el helper form_for y que contiene una instancia del objeto al que se refiere el formulario. Tiene métodos internos con el mismo nombre que los helpers que hacen uso de estos.
3. La clase InstanceTag, que  es la encargada de generar el código para cada uno de los tags html. Es llamada desde los helpers.

Finalmente, adaptando un poco el código de otros helpers en el mismo fichero, el resultado fue:

module ActionView
  module Helpers
    module FormHelper
      def error(object_name, tag_name, method, options = {})
        InstanceTag.new(object_name, method, self, options.delete(:object)).to_error_tag(tag_name)
      end
    end

    class InstanceTag
      def to_error_tag(tag_name)
        unless @object.errors[@method_name].blank?
          content_tag tag_name, @object.errors[@method_name].first, :class => :error
        end
      end
    end

    class FormBuilder
      def error(tag_name, method, options = {})
        @template.error(@object_name, tag_name, method, objectify_options(options))
      end
    end
  end
end

Que también se puede ver en su gist correspondiente.

Actualización 22 de Marzo de 2011:

Otra forma de personalizar los mensajes de error de los formularios en rails, que acabo de ver en la guía de rails y que ya no recordaba, es usando ActionView::Base.field_error_proc. Simplemente se necesita asignarle un nuevo Proc que reciba el tag html y una instancia del modelo y listo. Podemos devolver lo que deseemos.

HTML5 and CSS3 de Brian P. Hogan hace un recorrido por el nuevo estándar dando para cada caso ejemplos de uso y soluciones alternativas (normalmente basadas en jQuery) que nos permitan usarlas en navegadores que actualmente no tienen suporte para ellas.

Haciendo un repaso rápido de los temas que se tocan en el libro y que forman parte de HTML5:

Nuevos elementos estructurales: Para hacer nuestros documentos más semánticos se han incorporado muchas etiquetas nuevas y se han eliminado muchas otras que aún seguían haciendo referencia a presentación. Algunas de estas nuevas etiquetas son header, footer, nav, section, article.

Web forms: Una de mis partes preferidas son los nuevos campos para formularios que nos van a ahorrar gran cantidad de javascript y nos va a permitir crear formularios muy complejos de una manera muy sencilla. Algunos de los nuevos elementos son: email, search, slider(type=range), date, color, number. Además se han añadido attributos muy interesantes como placeholder, autofocus y contenteditable.

CSS3: Para permitirnos mejorar visualmente nuestras webs sin necesidad de añadir clases o ids a cada elemento se han añadido montones de selectores y pseudo-selectores, entre ellos destacaría :nth-child(n) que nos permite crear tablas cebreadas sin necesidad de añadir las típicas clases odd y even.

Canvas: Nos permite crear imágenes complejas o gráficos programaticamente con javascript y sin necesidad de liberías externas como Flash.

Audio y video: Una de las características más conocidas es la inclusión de las etiquetas para audio y video que nos darán soporte nativo en el navegador, después, por supuesto, de que se resuelva la batalla sobre formatos que hay abierta entre los distintos navegadores.

Eye Candy (border-radius, shadows, gradients y transformations): Por supuesto, también se hablan de las nuevas propiedades de CSS que nos va a permitir crear bordes redondeados, sombras, gradientes y mucho más sin necesidad de añadir imágenes como fondos.

Por otro lado, se encuentran algunas API's javascript que aunque no pertenecen directamente al estándar, está asociadas al él y que habrá que tener en cuenta en el futuro. Las más destacadas son:

Local Storage: Que nos permite guardar cosas como la configuración de la aplicación sin necesidad de usar para ello cookies.

Session Storage: Que permite guardar datos en el navegador que se borran automáticamente al cerrar la sesión.

Web SQL databases: Bases de datos relacionales asociadas a un dominio y persistente entre sesiones.

Offline applications: Permite definir archivos que deben ser cacheados para que la aplicación pueda ejecutarse sin necesidad de conexión a internet.

History: Permite manejar el historial del navegador.

Cross-documents messages: Nos da la posibilidad de enviar mensajes entre ventanas con contenido cargado desde diferentes dominios.

Websockets: Crean una conexión con estado entre un navegador y un servidor.

Geolocation: Permite obtener la latitud y la longitud de un navegador web.

Por otro lado, existen otro montón de tecnologías que aún no se encuentran suficientemente maduras para usar en ningún navegador y por las cuales todavía tendremos que esperar un tiempo. Entre ellas se encuentran las siguientes:

CSS3 Transitions: Animaciones sobre interacciones directamente en CSS.

WebWorkers: Ejecución de javascript en segundo plano.

3D canvas con WebGL: Creación de imágenes 3D sobre el objeto canvas.

IndexedDB: Bases de datos de tipo clave/valor en el navegador similares a las NoSQL.

Drag & Drop: Api para arrastrar y soltar elementos entre el sistema operativo y el navegador.

Client-side form validations: Validaciones de formularios en el navegador sin usar javascript.

En resumen, nos esperan unos años muy prometedores en lo que ha desarrollo web se refiere con montones de tecnologías nuevas que vienen a facilitarnos el trabajo y a abrirnos un montón de posibilidades nuevas. Creo que es importante que comencemos a usar esas tecnologías desde ya para que los usuarios más avanzados puedan comenzar a beneficiarse de ellas, sin dejar de lado a los usuarios de navegadores sin soporte, y para que cuando llegue el resto de usuarios todas esas tecnologías se encuentren maduras y todos podamos disfrutar de una web mejor.

adoptador precoz / adaptador veloz: Instinto para probar nuevas tecnologías y técnicas, y para adaptarlas rápidamente al resto de su conocimiento.

inquisitivo: Tendencia a preguntarse cómo funcionan las cosas, lo que puede afectar a sus decisiones futuras.

pensador crítico: Siempre se pregunta por qué las cosas se hacen cómo se hacen y rara vez se conforma con aceptarlas tal cual.

realista: Intenta entender la naturaleza de cada problema al que se enfrenta, lo que le permite afrontar los problemas sabiendo cómo de dificiles y cuánto tiempo pueden tomar.

hombre orquesta: Se interesa por un amplio espectro de tecnologías, y aunque su trabajo requiera ser un especialista, siempre será capaz de afrontar nuevos retos.

Todas estas características no serían nada sin la más importante.

Piensa en tu trabajo

Para completar la lista dejo la guía para programadores pragmáticos que se encuentra al final del libro Referencia rápida para desarrolladores pragmaticos.

El libro está dividido en 5 partes fundamentales.

En primer lugar un ejemplo práctico de uso de RSpec y Cucumber en el que se desarrolla un pequeño juego llamado Codebreaker, donde el usuario debe adivinar un número secreto, y que nos familiariza con el ciclo básico del BDD: red, green, refactor.

La segunda parte está dedicada exclusivamente al BDD, y se centra en explicar por qué los proyectos tradicionales fallan y qué aporta dicha metodología para evitar esos errores.

La tercera parte nos introduce en RSpec y da un repaso completo a la librería: cómo definer expects, el uso de mocks y stubs para aislar cada test y por último cómo extenderla a través de macros o custom matchers entre otros.

La cuarta parte se centra en Cucumber y en cómo escribir requisitos usando Gherkin, cómo definir escenarios y cómo implementar cada uno de los pasos. Sin embargo, he de confesar que este apartado me lo leí un poco más por encima ya que en Qoolife hemos reemplazado Cucumber por Steak para hacer los test de aceptación. La razón fundamental es que ya que el producto lo estamos desarrollando en casa, y que todos los que vamos a escribir / leer las historias de usuarios conocemos ruby, eliminamos la capa de definición de los requisitos en lenguaje natural y pasamos directamente a implementarlas usando RSpec y Capybara.

En la quinta y última parte se hace un repaso a la integración con rails, desde la definición de features, pasando por distintas opciones que existe para simular el navegador usando Webrat y Selenium y acabando en cada una de las capas del MVC: vista, controlador y finalmente los modelos.

En resumen, un libro muy recomendable para todos aquellos interesados en ponerse al día en lo que a Behaviour Driven Development se refiere, y para los que deseen utilizar RSpec y/o Cucumber como herramienta de testing en particular.

Ayer publicaron su versión 3.0 y entre las novedades más destacadas se encuentran la actualización de la plataforma a la versión 3.0 de Ruby On Rails, lo que les permitirá usar los desarrollos más novedosos de la vibrante comunidad rails; y la renovación de la navegación de la aplicación que toma más protagonismo situándose a la derecha de la pantalla.

Muchas felicidades al equipo de Teambox y gracias por esta gran aplicación.

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

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

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

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

Pero, ¿para qué es necesario que el HTML sea semántico? ¿No es suficiente con que se vea correctamente en todos los navegadores?

Cuando usas las etiquetas HTML correctamente estás proporcionando al navegador, sea del tipo que sea, información sobre qué es el contenido que está leyendo, por lo tanto podrá identificarlo y usarlo más eficientemente. Esto tiene diferentes tipos de ventajas.

Accesibilidad

El HTML semántico es más fácil de interpretar para los agentes de usuario lo que permite que sea mostrado mejor en diferentes tipos de soportes como móviles, PDA's, navegadores por voz, etc lo que permite acceder a los contenidos incluso a personas que tengan algún tipo de discapacidad aumentando tu público objetivo.

SEO

Los motores de búsquedas necesitan entender el contenido de la página para ser capaces de evaluarlo y clasificarlo. Por medio del uso de HTML semántico, los motores de búsqueda, son capaces de entender mejor la estructura del documento y el significado de su contenido lo que mejora su posición en los resultados de búsqueda.

Crossbrowser

Ya que estamos usando las etiquetas HTML para el propósito para el cual fueron diseñadas, los navegadores tendrán más información sobre el contenido de esas etiquetas por lo que mejoraras la forma en la que se visualizan, e interactuan con el navegador, además de asegurar que la mayoría de los navegadores traten a ese contenido de la misma manera.

Mantenimiento

Ante todo, cuando escribimos HTML semántico estamos escribiendo HTML bien estructurado, lo cual facilita la lectura y edición del marcado. Por lo tanto, estaremos ahorrando tiempo y dinero cuando otras personas tengan que editar nuestro documento.

Ya que no contiene etiquetas que definen su aspecto, sólo aquellas que definen su significado, es más fácil de cambiar su aspecto intercambiando las hojas de estilo para cada tipo de agente de usuario.

Además, al usar únicamente las etiquetas que son semánticamente necesarias, nuestro documento HTML será más pequeño, más rápido de descargar, y más rápido de leer para los agentes de usuario.

Cómo escribir HTML semántico

No hay una manera automática de comprobar si el HTML de tu página es semántico,  ya que no es suficiente con que sea válido según el estándar. Para ello es necesario:

1. Eliminar cualquier etiqueta que haga referencia al aspecto que tendrá el contenido como las etiquetas font, center o align.
2. Asegurarse de que las etiquetas que estamos usando describen su contenido y que hemos dejado la presentación en manos de las hojas de estilo, para ello puedes desactivar las hojas de estilo de tu navegador o usar uno sin soporte para hojas de estilo como lynx. Si puedes seguir leyendo el contenido probablemente tu HTML sea semánticamente correcto.

Ese es el título de la acción promovida por los chicos de hacktivistas que pretende combatir la nueva campaña del ministerio de cultura en donde se llega a afirmar que el intercambio entre usuarios de material cultural sujeto a copyright es delito, aún no existiendo animo de lucro. También denuncian una campaña de los lobbies de la industria cultural para especular con la era digital, y citan a todo el que quiera asistir a interacambiar material protegido por la Ley de Propiedad Intelectual sin animo de lucro, frente a la sede del PSOE en Madrid, C/ Ferraz 70 el próximo sábado 20 de Diciembre a las 12h.

Desde aquí todo mi apoyo a esta campaña.

Se puede consultar el número en formato flash y pdf , y la licencia de distribución es copyleft de tipo Reconocimiento-No comercial-Compartir bajo la misma licencia.

Mucha suerte a todos los implicados en el proyecto.

wikipedia.es

En otra versión del teorema, un mono infinito podría llegar a escribir, por ejemplo, el kernel de linux.

Sin entrar en inocuos debates matemáticos sobre la validez de dicho teorema, la idea de que un mono, por muy infinito que sea, pueda a llegar a escribir una pieza de software tan compleja como el kernel de linux me inquieta.

De echo, si tenemos en cuenta la media de líneas de código diarias que puede escribir un programador al final de un proyecto es difícil de afirmar cuál de los dos es el mono infinito y cuál el programador.

¿Quizás sería mejor reemplazar a los programadores por monos infinitos? de momento, y gracias a la madre naturaleza, los programadores tenemos tiempo para hacernos valer, pero es sólo cuestión de tiempo.

Mejor que no nos despistemos...

XFN es un microformato que representa estas relaciones utilizando para ello el atributo rel de los enlaces, al que se le asignan unos valores que las representen.

Un ejemplo de ello sería los valores para las relaciones de amistad.

• contact: Alguien con la quién sabes como llegar a él. Suele ser una relación simétrica.
• acquaintanc: Alguien con quién has intercambiado saludos y has mantenido una o dos conversaciones cortas. También simétrico.
• friend: Alguien de quien eres amigo. Un compatriota, un colega, que tu conoces. A menudo simétrico.

Por lo que para construir un enlace a la ficha de un amigo podríamos hacer: <a href="http://11870.com/manueltxo" rel="friend met co-worker">manu</a>

donde met nos indica que se conoce a esa persona fisicamente, y co-worker que es compañero de trabajo.

De esta manera podemos usar los estilos para diferenciar visualmente cada tipo de relación. a[rel~="friend"] {font-weight: bold;} a[rel~="co-worker"] {text-decoration: underline;} a[rel~="acquaintance"] {font-style: italic;}

Se pueden ver como funciona XFN 1.1 utilizando la herramienta visual creador de XFN 1.1 para practicar.

Pero más allá de unos simples estilos, nos permitiría tener un sitio centralizado en donde definir nuestras relaciones (como orkut o Linkedin) a partir de la cual otras puedan obtener esos datos y nos eviten tener que reintroducirlos cada vez que nos demos de alta en un nuevo servicio.