Entradas con la etiqueta “Desarrollo”

FOSDEM 2010: más open source, más diversión :)

21 de febrero, 2010 - por | | Open Source

En 2009 Grosshat estuvo en el FOSDEM y lo disfrutó mucho. Como comentamos entonces, Fin de semana en el FOSDEM, el ambiente de esta reunión europea de desarrolladores y simpatizantes del open source es realmente positivo y divertido, y su visita siempre te reporta un montón de información y te da un poco el tono de por dónde están yendo las cosas en líneas generales.

En 2009 nos parecía que lo más preponderante había sido todo el tema de dispositivos embebidos, para los cuales distintas distribuciones populares y otras tantas menos conocidas tenían ya preparados un montón de recursos tanto en forma de software como de hardware. Por su parte, en 2010 hemos vuelto con una impresión bastante fuerte de que las alternativas a los motores SQL son ya una realidad, y que los temas de escalabilidad en la web ya están convirtiéndose en un tema frecuente a raíz de la aparición y consolidación de portales (ala Facebook) que han llevado las cifras de visitas y uso a cotas difícilmente pensables hace unos años.

El reparto de charlas ha reflejado muy bien el peso de esos 2 temas principales; por un lado, dentro de los llamados “Main Tracks” se creo uno dedicado completamente a la escalabilidad; por otro lado, en las “Developer Rooms” se organizaron más de una docena de charlas sobre el tema NoSQL. Al mismo tiempo, hubo bastantes referencias cruzadas entre ambos espacios, lo que reforzó aún más la intuición de que algunos de sus problemas tienen al menos un origen común. Ésto se vio perfectamente en la magnífica charla que dio la gente de Facebook, donde los temas de escalabilidad y las soluciones NoSQL fueron las alusiones más habituales.

Un año más ha sido una experiencia genial y una oportunidad perfecta para conocer Bruselas y disfrutar de la ciudad, con todos los encantos que tiene, incluidad la cerveza. ;)

Si no has podido ir, pero piensas que podrías animarte a ir el próximo año, échale un vistazo a los siguientes enlaces, donde recopilamos fotos, videos y presentaciones de todo el fin de semana.

Mi maquinita tatuada con Facebook

máquina de iñigo con la pegatina de facebook

Colecciones de fotos

Colecciones de vídeos

Presentaciones

  • en slideshare se han reunido muchas de las charlas

Bases para el desarrollo web

2 de diciembre, 2008 - por | | Análisis

Cualquier persona que ha participado de alguna forma en un proyecto web, conoce la enorme incertidumbre con la que se trabaja, a causa de las numerosas opciones que se barajan. Tomar una decisión sobre cualquier aspecto conlleva la necesidad -o la sensación de tenerla- de informarse y evaluar las distintas alternativas, a menudo sólo apoyándose en una metodología cualitativa difícil de formular conscientemente.

En todo ésto hay una parte, para mí, asumible de forma natural, que tiene que ver básicamente con el esfuerzo constante por innovar. Las tecnologías nacen para tener versiones, mejoras e incluso ser sustituidas por otras, con lo que los cambios -estructurales o por meras modas- son algo inevitable. Algunas personas piensan, además, que es positivo; y, por supuesto, hay otras que opinan justo lo contrario. La incertidumbre a la que me refería se mueve básicamente en esta parte.

Ahora bien, hay todo otro conjunto de cosas que, en mi opinión, son de naturaleza arquitectónica, y que por eso mismo no deberían verse comprometidas por las otras. Desgraciadamente, muchas veces son las partes más descuidadas de los proyectos, y los problemas que traen consigo suelen convertirse en críticos.

La primera cosa que suele descuidarse es el marcado HTML. Este descuido tiene consecuencias a todos los niveles, puesto que la web se apoya, intrínsecamente, en las estructuras de los documentos. Existe todavía una actitud bastante generalizada que concede poca importancia a este aspecto, produciendo una base de conocimiento muy pobre y poco rigurosa. Recientemente, Opera hacía públicos algunos datos recogidos a través de su herramienta MAMA, que cifraban en tan sólo un 4,13% los documentos existentes en la red validados correctamente. En este tipo de datos lo interesante no está tanto en las cifras, cuanto en la actitud que éstas reflejan.

El descuido en el marcado produce una reacción en cadena de descuidos que, en conjunto, afectan sustancialmente al documento.

Por un lado, existe un riesgo mayor de que estructura y presentación no se comporten como partes estancas, con lo que se incrementa la probabilidad de restringir y/o dificultar el acceso al documento (documentos más pesados, documentos no válidos para algunos dispositivos, etc.), así como de ofrecer un contenido menos significativo.

Por otro lado, aumenta la dificultad de incorporar comportamientos relacionados con el navegador, puesto que éstos se benefician de una estructura bien organizada y limpia de estilos. Ésto, a su vez, incrementa la posibilidad de restringir el acceso a causa de problemas con los dispositivos.

Asimismo, al disponer de un contenido menos significativo, disminuirá la capacidad de acceder a éste mediante búsquedas de patrones y/o semánticas. Lo que repercutirá, nuevamente, en restricción de acceso.

Más importante aún que todo ésto es que este tipo de actitud va en aumento según se desarrolla un proyecto, de forma que las pocas consideraciones que se tenían en el momento 0, han disminuido en el momento 5, y empiezan a considerarse como un problema en el momento 10. A partir de ahí se habrá invertido lo que debería ser el orden natural del proyecto, de forma que la web habrá pasado a considerarse un corsé demasiado pobre que necesariamente hay que forzar.

En ese punto penetrarán todos esos aspectos de la primera parte (tecnologías cambiantes, modas, etc.) desbordando sus límites naturales. En la historia de la web -que escribimos cada día- hay ejemplos de todo ésto -que todos vivimos diariamente- y se puede decir que prácticamente nadie está a salvo, y que es un ejercicio diario hacer el esfuerzo por mantener cada cosa en su sitio.

Merece la pena, puesto que ayuda a gestionar la incertidumbre que se mencionaba al principio, poniéndole límites, y evita la generación gratuita y progresiva de problemas y restricciones a todos los niveles.

Desarrollo con estándares web 2

2 de diciembre, 2008 - por | | Desarrollo, Estándares

Segunda parte de la traducción al español del texto de Roger Johansson: Developing With Web Standards – Recommendations and best practices.

¿Aún no leíste la primera parte?


3. Estándares web

¿Qué son los estándares web?

Los estándares web son tecnologías, establecidas por el W3C y otras instituciones de estándares, que son utilizadas para crear e interpretar contenido web. Dichas tecnologías están diseñadas para documentos-tipo futuros publicados en la web, y para hacer dichos documentos accesibles al mayor número de personas y dispositivos posibles.

Lenguajes para estructurar

Lenguajes de presentación

Modelos

Lenguajes de scripting

Este documento se centra en HTML 4.01 Strict para la estructura, CSS Nivel 1 y Nivel 2 para la presentación, y JavaScript para el scripting (aunque no se ofrecen muchos ejemplos de scripting).

Cuando se dice que un documento se adhiere a los estándares web, quiere decir que el documento además de hacer uso de las tecnologías referidas antes:

  • consiste en HTML o XHTML válido
  • utiliza CSS en vez de tablas para el layout
  • está propiamente estructurado y semánticamente marcado
  • funciona en cualquier navegador web

“Funciona en cualquier navegador web” no quiere decir “se ve igual en cualquier navegador web”. Hacer que un documento se muestre de forma idéntica a través de navegadores web y plataformas es prácticamente imposible. Incluso utilizando sólo imágenes tampoco se conseguirá que se muestre de forma idéntica en cualquier sitio.

Los documentos que son publicados en la web son consultados por una amplia variedad de dispositivos en diferentes sistemas operativos, con monitores de diferente resolución y calidad (o sin monitor, incluso), así como por usuarios que pueden haber cambiado el tamaño de fuente por defecto del navegador, así como otras preferencias.

Darse cuenta de ésto y aceptar que simplemente no puedes tener el control absoluto de la apariencia visual de un sitio web en los navegadores de tus usuarios hace que tu vida sea mucho menos frustrante. Cualquiera que crea sitios web necesita entender que existen prerequisitos técnicos a considerar, de la misma forma que aquellos que publican sobre papel o hacen películas o televisión tienen otros prerequisitos que considerar.

¿Necesita un sitio web comportarse exactamente igual en todos los navegadores?

¿Por qué utilizar estándares web?

Algunos desarrolladores y diseñadores web tienen resistencia respecto del uso de estándares web. Argumentos comunes son los de “…es demasiado difícil”, “…funciona en cualquier caso”, y “…los programas generan código inválido”.

Es fácil reaccionar emocionalmente y construir una resistencia hacia el aprendizaje de algo nuevo, que requiere que abandones técnicas que conoces y con las que te sientes cómodo. Sin embargo, si contemplas la situación de una forma lógica verás que hay muchos beneficios para aprender y utilizar estándares web. He aquí unos pocos:

  • desarrollo y mantenimiento más fáciles: Utilizar HTML más semántico y má estructurado hace mucho más fácil y rápido entender el código creado por cualquiera. Agradecerás, asimismo, cuando tengas que cambiar algo en tu propio código meses o años después de la primera vez que lo escribiste
  • compatibilidad con futuros navegadores web: cuando utilizas estándares definidos y código válido tus documentos pasan la prueba del futuro, reduciendo el riesgo de que futuros navegadores web no sean capaces de entender el código utilizado
  • descarga y renderización más rápidas de las páginas: utilizar CSS para la presentación tiende a aligerar los documentos HTML, lo que significa descargas más rápidas para los usuarios
  • mejor accesibilidad: HTML semántico, donde la estructura está separada de la presentación, hace más fácil para lectores de pantalla y dispositivos de navegación alternativos interpretar correctamente el contenido
  • mejor posicionamiento en los buscadores: la separación de contenido y presentación hace que el contenido represente una mayor parte del tamaño total del fichero. Combinado con marcado semántico ésto generalmente mejora el posicionamiento en los motores de búsqueda
  • adaptación más sencilla: un documento semánticamente marcado puede ser fácilmente adaptado para imprimir, así como para dispositivos de navegación alternativos, como dispositivos de mano y teléfonos móviles, simplemente enlazando a distintos ficheros CSS. Puedes, asimismo, hacer cambios que afectan a todo el sitio web editando un único fichero

El uso de estándares web ahorra tiempo y dinero para los creadores de sitios web, y en general aporta una mejor experiencia del usuario del sitio web.

Validación

Validación es el proceso de controlar que un documento se adhiere a las reglas del lenguaje de programación utilizado en el documento. Puedes compararlo chequeando un texto que has escrito para ver errores de “spelling”.

Asegurar la calidad a través de la validación es una importante parte del desarrollo web. Muchos errores que son difíciles de descubrir manualmente, son descubiertos durante la validación. Un error puede ser tan trivial como un error de escritura, o tan serio como un elemento o un atributo utilizados de un modo incorrecto. Puede no tener ningún efecto en la forma en que el documento es renderizado en un navegador web o desfigurarlo completamente.

Desgraciadamente, mucha gente no valida sus documentos. Algunas personas puede que no tengan conocimiento de la validación, otras llegan a olvidarlo, y hay otros que intencionadamente evitan la validación. Creo que esta situación se puede atribuir a las compañías de navegadores web. La mayoría de los navegadores web intentan interpretar HTML inválido de la mejor forma que pueden e intentan averiguar cuál es la intención del creador en vez de mostrar un mensaje de error. Es comprensible que los navegadores web quieran hacer tal cosa, pero esta tolerancia de errores es sin duda la principal razón para el (sloppy) marcado que es comúnactualmente.

¿Por qué no queremos ayudarte? es una explicación excelente de Mark Pilgrim sobre las ventajas de la validación. El artículo también explica por qué puede resultar más difícil conseguir ayuda de la gente en foros de discusión y listas de correo si no has validado tus documentos antes de preguntar.

Algunos editores HTML disponen de herramientas de validación ya listas o utilizan los servicios de validación del W3C, disponibles onlne. Puede utilizar los servicios de validación manualmente:

Otra herramienta excelente para chequear la validez del HTML que creas es la extensión HTML Validator para Firefox.

Comprender los mensajes de error generados por los validadores puede resultar un poco difícil. Un error inicial en un documento puede causar numerosos errores adicionales. Corrigiendo el primero y revalidando conseguirás reducir sustancialmente el número de errores.

Es importante tener en cuenta que la validez por sí sola no significa que el documento es accesible. Tampoco unos pocos de errores de validación hacen que necesariamente tu documento sea innaccesible o incompatible. Dicho ésto, deberías intentar siempre tener un código plenamente válido y tener una buena razón (tal como mejorar accesibilidad para la gente con discapacidades) para cualquier error que decidas dejar. Si las herramientas (editores de código, frameworks, editores WYSIWYG, sistemas de gestión de contenidos) que utilizas generan marcado inválido, son herramientas rotas que necesitan ser corregidas.

Para seguir leyendo

Desarrollo con estándares web 1

26 de noviembre, 2008 - por | | Desarrollo, Estándares

Roger Johansson mantiene actualizada una introducción, ya clásica, al desarrollo con estándares web en su sitio 456bereastreet.com: Developing With Web Standards – Recommendations and best practices. Con el tiempo se han ido haciendo numerosas traducciones a otros idiomas, aunque todavía no contamos con una en español. Así que voy a ir publicando aquí, en diferentes entradas, una traducción completa que, finalmente, también se encontrará en la sección de traducciones de su sitio.

Por cierto, siempre es un placer colaborar con personas tan profesionales y generosas como Roger.


Desarrollando con estándares web. Recomendaciones y buenas prácticas

1. Introducción

Este documento intenta explicar cómo y por qué el uso de estándares web te permitirá construir sitios web de un modo tal que el desarrollador ahorre tiempo y dinero, y el usuario tenga una mejor experiencia. Se discuten, también, otros métodos, guías y buenas prácticas que ayudarán a producir sitios web de alta calidad, accesibles y usables para el mayor número de personas y dispositivos posibles.

2. Historia

Cuando Internet y la Web se popularizaron en la segunda mitad de los 90, las compañías de navegadores web no habían implementado aún CSS (Cascading Style Sheets) de forma suficiente como para que los desarrolladores web tuviesen la capacidad de usarlas para controlar la presentación de un documento HTML. La falta de implementación es en cierto modo comprensible, teniendo en cuenta que la especificación para CSS Nivel 1 fue publicada en 1996, y que la correspondiente al Nivel 2 fue publicada en 1998.

La falta de soporte para CSS en los navegadores web, combinada con las demanda de los diseñadores gráficos en relación con el nivel de control que es posible cuando se trabaja con material impreso, condujeron al abuso de HTML hacia una forma de controlar la presentación visual de una página web.

Un ejemplo de ésto es la “fuga” que se produjo cuando los diseñadores descubrieron que mediante el uso del atributo border="0" para ocultar los bordes de una tabla HTML, fue creada una celda invisible que podía usarse para controlar el layout. Otro ejemplo es el uso de imágenes transparentes, por tanto invisibles, llamadas “spacer GIFs” para el control de los espaciados y los márgenes.

Puesto que HTML nunca fue ideado para controlar la presentación de un documento, fueron, y siguen siendo, utilizados hacks, código inválido y elementos y atributos específicos de algunas compañías. La validación era algo que muy poco conocían o utilizaban. Este tipo de código HTML suele denominarse sopa de tags.

A medida que se fueron publicando nuevas versiones de navegadores web, el soporte para CSS mejoró y se extendió, pero no en la proporción que debería. Sin embargo, aunque las compañías de navegadores son lentas en la implementación correcta de CSS, hemos alcanzado un punto donde los navegadores web con buen soporte para CSS están siendo utilizados por tantas personas que ya no hay razón para no utilizar el HTML en la forma en que debe ser usado: para describir la estructura y el contenido de un documento, y no su presentación. Para eso, podemos actualmente utilizar CSS, que fueron diseñadas específicamente para tal propósito.