Estoy cansado de escuchar o leer que el desarrollo de páginas web no es cosa de informáticos. A veces, en especial en el ámbito universitario, lo pintan como "trabajo basura" que hacen los informáticos que no tienen otra cosa que hacer. Otras veces directamente tachan de "intrusistas" y "estafadores" a los informáticos que han optado por dedicarse al mundo de la web. (Un ejemplo lo tenéis en http://legolas.ei.uvigo.es/ebarreiro/?p=112)

En realidad no hay nada más lejos de la realidad. En cuanto a la parte de diseño que toda web tiene, hace tiempo que busco a un diseñador gráfico con capacidades reales de maquetación. Normalmente los diseñadores gráficos entregan lo que se denomina un "mockup", es decir, una "foto" de la página tal y como debería de verse. Durante todo el proceso se le pueden consultar cosas, van a desarrollar más imágenes, a decidir el aspecto de determinadas partes de la web que inicialmente no estaban consideradas (formularios, textos largos, imágenes dentro de textos, títulos, subtítulos, color de los enlaces, aspecto de las listas...) pero en ningún caso van a darte el código HTML correspondiente, y menos un código utilizable.

Los pocos que consiguen hacer maquetación suelen entregar un solo fichero HTML que contiene todo y que no está nada modularizado -por ejemplo no hace separación de presentación y contenido, introduciendo el aspecto dentro de las propias etiquetas HTML.

Si se quiere conseguir un buen acabado, un producto flexible, extensible y mantenible, que cumpla los estándares web (XHTML, CSS, normativa WAI de accesibilidad, etc) y que se visualice correctamente en un número significativo de navegadores (distintas versiones del odiado Internet Explorer que no se pueden dejar de lado todavía, Mozilla Firefox, Safari, Opera...) entonces se necesita a un maquetador profesional que normalmente vendrá del lado de la informática, ya que estamos hablando de escribir código usando lenguajes informáticos y no de utilizar paquetes ofimáticos.

Por otro lado hay que tener en cuenta que las web actuales no son para nada web estáticas. La mayoría cuentan con un sistema de gestión de contenidos, con módulos que dan distintas funcionalidades (desde publicación de entradas hasta sistemas de foros, pasando por comercio electrónico, sistemas de seguimiento del estado de un pedido, gestión de usuarios, etc) que requieren altas dosis de análisis, diseño e implementación que solo deberían ser asumidas por profesionales experimentados (en general Ingenieros o Ingenieros Técnicos en Informática).

Hasta aquí queda más que justificada la necesidad de los informáticos en la web: la web es cosa de informáticos. Pero me gustaría también dar una dimensión más avanzada al tipo de trabajo que se realiza en torno a la web y de éste modo intentar mejorar su imagen entre los informáticos. El desarrollo de páginas web no es el "trabajo basura" de los informáticos. Por supuesto, hay que picar código. Igual que se hace en el desarrollo de aplicaciones de escritorio o en el desarrollo de sistemas embebidos en tiempo real para el control de misiones autopilotadas en los aviones del ejército.

En el campo de la web hay mucho más que picar código. Nosotros hemos desarrollado sistemas que tienen que utilizar semáforos (sí, semáforos, esos queridos amigos de Programación Concurrente), hemos programado sistemas de cacheado e indexación para acelerar las cargas de la página, hemos implementado protocolos de comunicación existentes para comunicarse con todo tipo de servidores (por ejemplo servidores SSH o FTP), hemos definido nuevos protocolos de comunicación, con sistemas de paso de mensajes entre distintos servidores que deben sincronizarse automáticamente y en los que la comunicación debe estar asegurada a nivel criptográfico tanto para validar el origen (firma) como para impedir que otro salvo el destinatario pueda leerla (codificación), hemos trabajado sobre múltiples SGBD, hemos escrito parsers y lexers para procesar lenguajes existentes o que hemos inventado nosotros, hemos desarrollado elementos de Programación Orientada a Aspectos sobre lenguajes interpretados que no disponían de dichas funcionalidades, hemos definido procesos de ingeniería para el software orientado a web (Desarrollo Orientado a Interfaces)... y un sinfín más de cosas. Y todo ello lo hemos hecho en el ámbito del desarrollo web, utilizando lenguajes de programación orientadas a web (PHP, JavaScript) y lenguajes de definición de hipertexto y presentación de naturaleza cien por cien web (XHTML, CSS).

¿De verdad sigue alguien pensando que la web es cosa de diseñadores? ¿De verdad sigue alguien creyendo que en web no se está continuamente investigando, innovando y en la cresta de la hola? ¿De verdad alguien se atreve a decir todavía que lo de las páginas web es el "trabajo basura" de los informáticos?

Espero que no.

Muchas veces estamos reinventando la rueda debido a la falta de información, o simplemente a la vagueza de buscar dicha información. Otras veces la reinventamos porque aunque la arquitectura teórica existe, no somos capaces de ver qué arquitectura existente le viene mejor a nuestro problema.

En este documento voy a intentar mostrar un ejemplo práctico de reutilización, parametrización y patrones de diseño. Lo voy a orientar a crear aplicaciones con cualquier interfaz de comunicación, pero me centraré un poco más en las interfaces web

Aquí os pongo el enlace al documento completo: Reutilización, parametrización y patrones de diseño

En vuestros diseños de software:

• ¿Soleis separar claramente la capa de presentación de la capa de lógica de negocio?
• ¿Seríais capaces de cambiar la presentación de vuestra aplicación sin tener que tocar nada de la lógica de la aplicación? (con cambiar la presentación no me refiero al estilo, sino un cambio radical, pasar de aplicación de escritorio a aplicación web o de aplicacion web a servicio web)
• ¿Y seríais capaces de añadir más presentaciones manteniendo las anteriores sin tener que tirar la mayor parte de la aplicación a la basura?

Pues ahí van unas preguntas que sería interesante que las meditaseis y respondais para que entre todos veamos un poco lo que la gente suele hacer, y como podríamos mejorarlo.

Hasta pronto

Jose Carlos Calvo Tudela

En esta primera parte de Arquitecturas Web 2.0, voy a defender el porqué de estas arquitecturas y en que se diferencian de las arquitecturas de aplicaciones de escritorio. En las siguientes entregas comentaré una a una las arquitecturas que creo que son mas interesantes.

Crear Web 2.0 no es cuestión de tecnologías ni de interfaz de usuario unicamente como ya se discute en otras entradas de este blog, la diferencia la marca una arquitectura de la aplicación Web que nada tiene que envidiar a otras arquitecturas de aplicaciones de escritorio.

Hace un tiempo, los ingenieros se dedicaban a trabajar en empresas en las que podían participar en proyectos de aplicaciones de escritorio para poder ejercer de ingeniero y diseñar arquitecturas potentes. Las páginas Web, conste que no he dicho aplicaciones Web, se dejaba que lo hiciese cualquier persona a la que le gustara y se le diera bien el diseño gráfico, ya que servían para eso, es decir, para publicidad.

Desde que las nuevas tecnologías tanto para banda ancha como lenguajes de programación y servidores Web permiten hacer y pensar en cosas que antes no se planteaban, empezaron a surgir aplicaciones Web, ya el fin no es la publicidad, sino la funcionalidad. Desde ese momento el mundo de las aplicaciones Web capta más y más ingenieros, debajo de cada aplicacion Web hay una arquitectura software y hardware en algunoscasos que no difiere mucho de una aplicación de escritorio.

Ahora con el boom del Web 2.0 las arquitecturas de las aplicaciones se disparan en potencia mucho más arriba de las arquitecturas de una aplicacion de escritorio, para ver esto pongamos un ejemplo,

Tenemos que hacer una aplicación para almacenar información de los CDs que tenemos en una estantería, una cosa muy simple y que no merecería la pena perder mucho tiempo en crear grandes arquitecturas, pero como es un ejemplo, lo vamos a hacer. Si lo hacemos con una aplicación de escritorio pues haciendo una buena arquitectura podríamos hacer un modelo MVC o un modelo de capas, y en cuanto a conexiones, pues con tener conexión con la BD ya estaría todo. Esta aplicación de escritorio parece apetecible para un ingeniero ya que hay cosas interesantes que hacer.

Supongamos ahora que lo hacemos en aplicacion Web, entonces igualmente en nuestro servidor Web podríamos montar una arquitectura MVC o de capas con conexión a BD, esto sería lo que hace una aplicacion Web que no sea Web 2.0 ya que en base a unos parametros de entrada, ejecuta todo su modelo interno y genera un XHTML de salida. Entonces hasta este punto no hay mucha diferencia con una aplicación de escritorio, pero si introducimos el concepto Web 2.0 las cosas cambian, nuestra arquitectura de servidor que ya hemos pensado nos puede seguir valiendo ya que es bastante potente, lo único que hay que cambiar es la vista para que genere por ejemplo XML (este cambio es en cuanto a la arquitectura, queda claro que cambiarían
todos los servicios que ofrece el servidor, pero como estamos en fas ede diseño, pues no lo tengo en cuenta). Además de este servidor ahora tenemos que diseñar el cliente Web, este cliente puede tener una arquitectura MVC o de capas al igual que el servidor, javascript permite hacer esto con orientación a objetos, herencia, polimorfismo, etc. si utilizamos plataformas como dojo, prototype, etc. Entonces podemos decir que tenemos una arquitectura potente en servidor, una arquitectura potente en cliente y además tenemos conexión entre el cliente y el servidor, esto significa un protocolo de comunicación, y en el mundo de las arquitecturas esto significa un modelo cliente-servidor.

Todo sabemos que una aplicación Web es cliente-servidor, pero si implementamos aplicaciones Web tradicionales, ese mecanismo queda transparente al desarrollador y programador. Con aplicaciones Web 2.0 podemos conseguir diseñar un gran cliente-servidor y a la vez tener una arquitectura potente en cliente y otra en servidor. Parece mucho más interesante de desarrollar, y lo es.

Una ventaja que no suele comentarse de estas aplicaciones Web 2.0, es que si por ejemplo como hemos visto el servidor genera XML, entonces no solo es una aplicacion Web, sino que es un servidor orientado a los servicios, esto significa que construimos el servidor, despues el cliente que utiliza los servicios que ofrece el servidor, pero la utilidad del servidor no queda ahí, cualquier otra aplicación posterior o cualquier otra empresa que necesite utilizar nuestros servicios, refiriendome a los datos, es decir, el XML, para integrarlo en sus aplicaciones, lo harán sin tener que modificar nuestra aplicación lo más mínimo. Esta ventaja sería imposible de conseguir con una aplicación de escritorio y es una ventaja muy interesante en este mundo en el que se evoluciona hacia la globalización de la información, ¿no creeis?

Jose Carlos Calvo Tudela

Los que, como yo, estudiamos Ingeniería del Software con temarios anticuados, no llegamos mucho más allá de los modelos clásicos de desarrollo y, por supuesto, nunca oímos hablar de metodologías ágiles.

En el desarrollo de software hay, a mi juicio, dos parámetros relacionados entre sí y que son de vital importancia: El tamaño del proyecto y lo exhaustivo del proceso de ingeniería a desarrollar. La relación entre ambos debe ser una constante, y el valor óptimo de la misma depende de una multitud de factores, tales como el equipo de ingenieros que trabajen en el proyecto, la ventana temporal para el mismo, etc. En cualquier caso siempre se puede establecer un rango para esta relación: No tendría por ejemplo sentido realizar un intenso proceso de ingeniería para construir un "Hello World", del mismo modo que para afrontar la informatización de una entidad bancaria sin que el proyecto se hunda, sería necesario aplicar la Ingeniería del Software de forma estricta.

Se deduce de lo anterior que hay un punto en el tamaño del proyecto en que la Ingeniería del Software parece no ser útil o, al menos, supone un coste mayor que el beneficio que aporta. Sin embargo incluso en pequeños proyectos en los que la aplicación de un proceso de Ingeniería parece tener más costes que beneficios, son necesarios como mínimo una serie de aspectos de la misma, como por ejemplo los relacionados con el trato con el cliente.

En este punto es en el que me he encontrado en varias ocasiones sin saber muy bien como atajar el problema. Finalmente he alcanzado una solución de un modo más o menos intuitivo, es decir, trabajando con el cliente y aprendiendo en cierto modo por prueba y error. Con el tiempo, y sin saber si estas técnicas han sido descritas o usadas anteriormente por otra persona, he optado por llamarlo "desarrollo orientado a interfaces". Este texto no pretende ser una descripción detallada de un modelo de desarrollo, ya que en ningún momento he trabajado para crear dicho modelo. Simplemente pretendo enunciar una idea y dar unas ligeras pinceladas para explicar esta metodología de trabajo.

El desarrollo orientado a interfaces (DOI) no es en realidad más que un conjunto de reglas básicas, un proceso de ingeniería abreviado, con un bajo coste y con una clara intención de extraer el máximo partido de cada fase del proceso. La idea es bien sencilla: empezar la casa por el tejado. En efecto puede parecer un absurdo este modo de proceder, pero si lo miramos desde el punto de vista del software, no se trata más que de desarrollar software empezando por la interfaz de usuario.

El primer paso es, naturalmente, la entrevista con el cliente. Una vez tenemos idea de los requerimientos funcionales del software a desarrollar, podemos comenzar a trabajar sobre la interfaz. En un primer momento no será necesario más que un esbozo en papel de las interfaces de usuario de nuestra aplicación. Este esbozo debe desarrollarse de cara al cliente, esto es, de modo que él lo entienda. En este sentido el resultado se asemejaría bastante a un manual de instrucciones del programa en el que las capturas de pantalla son sustituidas por dibujos. Del tamaño del proyecto y de la relevancia de este primer documento depende el nivel de detalle que se quiera reflejar en el mismo. Así, si el proyecto es pequeño, no se compite con otras empresas o ingenieros para adjudicarse el trabajo, y no es necesario recurrir a este documento como contrato, podemos simplemente dibujar las interfaces explicando al cliente como trabajaría la aplicación y realizando sobre la marcha las modificaciones oportunas.

Con este primer paso logramos una multitud de objetivos, y según lo importante de los mismos dedicaremos más o menos esfuerzo a esta primera fase, en particular en lo que a la elaboración de un documento se refiere. En concreto lograremos, si lo necesitamos, los siguientes objetivos:

• Obtener una lista de requerimientos funcionales, cada uno de ellos especificados detalladamente.
  
• Obtener un documento que puede servir como contrato con el cliente.
• Minimizar el riesgo de una mala interpretación de algún requerimiento funcional, ya que la comunicación con el cliente es más clara y concreta mediante ejemplos gráficos.
• Adelantar trabajo en el diseño de la interfaz de usuario.
  
• Adelantar trabajo sobre el manual de usuario de nuestra aplicación.

Una vez se han esbozado las interfaces, y nuevamente dependiendo del tamaño del proyecto y de sus características concretas, podemos valorar la opción de desarrollar en primer lugar todas las interfaces de usuario (es decir, formularios e informes) sin dotarlas de funcionalidad y completándolas, a lo sumo, con datos ficticios y estáticos de ejemplo. En este caso podremos presentar al cliente en un tiempo excepcional un primer prototipo no funcional de la aplicación, que puede servirnos para detectar posibles errores en el análisis de requerimientos.

Podemos en cualquier caso prescindir de este primer prototipo y abordar directamente el desarrollo de la aplicación. Durante las siguientes fases podremos modelar los datos y sus relaciones. Para ello nos apoyaremos en el diseño de la interfaz con el que contamos, pues la mayoría de los datos deben aparecer en la propia interfaz a modo de campo de entrada o salida y, de no hacerlo, deben quedar reflejados de algún modo en la descripción del funcionamiento de la aplicación. A partir de aquí, y en general, el proceso de desarrollo continuaría de un modo más o menos tradicional, sin existir diferencias fundamentales que merezca la pena detallar, pero manteniendo siempre la idea de realizar solo aquello que aporte un verdadero beneficio e intentar cubrir con cada tarea el máximo número de objetivos posibles.

En conclusión la idea es simple: Aprovechar el diseño de las interfaces como mecanismo de comunicación con el cliente, obtención de requerimientos funcionales, elaboración de un contrato y obtención rápida de un prototipo.

Cabe ahora preguntarse ¿en que casos es conveniente aplicar esta idea?. Naturalmente hay una serie de factores que aumentan las ventajas de la aplicación del DOI:

• La aplicación descansa fundamentalmente sobre las interfaces de usuario y las bases de datos.
• Toda o la mayor parte de la actividad de la aplicación es disparada por el usuario al trabajar con la interfaz.
• El cliente tiene conocimientos de informática a nivel usuario.
• El cliente ha usado aplicaciones similares para las que necesita un reemplazo o una mejora.

En mi experiencia el DOI ha demostrado ser especialmente útil en las aplicaciones web. Esto está motivado probablemente por el hecho de que en este tipo de aplicaciones la ejecución de código en el servidor está normalmente condicionada al disparo de un evento por el usuario.

Cada vez están más de moda en ingeniería del software los procesos de desarrollo llamados "ágiles", como la programación extrema (XP) frente a otros modelos más pesados como RUP. Estos están cobrando especial importancia en el desarrollo Web ya que las aplicaciones suelen ser fácilmente divisibles en pequeñas partes sencillas.

Los puntos más interesantes de la XP son:

• Desarrollo iterativo e incremental
• Pruebas unitarias continuas, frecuentemente repetidas y automáticas
• Programación por parejas
• Frecuente interacción del equipo de programación con el cliente o usuario.
• Corrección de todos los errores antes de añadir nueva funcionalidad.
• Hacer entregas frecuentes.
• Refactorización del código
• Propiedad del código compartida: promueve el que todo el personal pueda corregir y extender cualquier parte del proyecto.
• Simplicidad en el código

El problema está en que hasta hace relativamente poco tiempo, no se disponían de herramientas para aplicar estas metodologías al desarrollo web. Afortunadamente con la aparición de frameworks como Ruby on Rails (RoR) o django, que promueven la arquitectura MVC, estas metodologías se vuelven extremadamente útiles y fáciles de aplicar.

Ambos, RoR y django, disponen de herramientas que facilitan el desarrollo rápido de prototipos de forma que el cliente puede ver resultados pronto, sugerir modificaciones y participar en lo que en XP se conoce como "El juego de la planificación", un proceso en el cual se ponen sobre la mesa el conjunto de tareas (o historias en terminología XP) y el cliente y los desarrolladores se ponen de acuerdo para decidir cual interesa obtener primero de forma que aporten el máximo valor posible al negocio.