La comunicación en los Proyectos

Últimamente he leído varios artículos sobre metodologías de trabajo en proyectos de desarrollo software o de ingeniería en general. Existen dos grandes familias de alternativas: las metodologías tradicionales y las metodologías ágiles. Unas se caracterizan por basarse en procesos de desarrollo (creación de documentación, ciclos de prueba, etc.) y las otras por el desarrollo rápido y de forma adaptable sin preocuparse en principio por aspectos como el costo o la mantenibilidad.

¿Por qué necesitamos una metodología de trabajo?

Usamos metodologías de trabajo porque tenemos miedo. Miedo a a desarrollar un mal producto de mala calidad, miedo a los retrasos...

dice Robert Martin

Normalmente, cada empresa tiene su propia metodología de trabajo basada en alguna más estandarizada, intentando adaptarla al funcionamiento interno. Por lo tanto, existen múltiples variantes y tipos de formas de trabajo. Sin embargo, existe una cosa común a todas que es la mayor causa de fracaso en los proyectos: la comunicación.

Comunicación:
¿Por qué es común la comunicación en todas las metodologías de trabajo? Obviamente porque los proyectos se desarrollan por personas independientes, cada una con su perfil y sus cualidades. Independientemente de cómo trabajemos (tradicionales, XP, FDD,...) el equipo de trabajo estará compuesto por múltiples personas que trabajarán en partes del proyecto, tendremos uno o varios clientes, jefes de proyecto, entendidos de la materia, jefes técnicos, desarrolladores, testeadores, etc. y todos deben ir en la misma dirección.

De todas formas, hablando se entiende la gente, dicen. Sí, pero siempre que hablen el mismo idioma. El problema reside en que lo que el cliente necesita debe ser implementado por el desarrollador, pero en medio de ellos existe mucha gente por la que el mensaje se cambia y al final el cliente no obtiene lo que necesita. Pero vamos a ir paso a paso en la cadena de comunicación:

La cadena de comunicación:
Lo normal que tengamos en un proyecto son los siguientes perfiles:

• Cliente: es el destinatario final del producto, normalmente sabe lo que quiere, o tiene una idea aproximada, pero no suele saber comunicarlo en lenguaje técnico y hay que interpretarlo.
• Jefe de Proyecto: es el encargado de hablar con el cliente, interpretar lo que quiere, evaluar lo que conviene hacer y lo que no (a su libre albedrío normalmente) y comunicarle lo que se va a hacer al Jefe Técnico.
• Jefe Técnico: es el que debe traducir el lenguaje no técnico con el que le habla el Jefe de Proyecto de lo que le ha contado el Cliente al lenguaje técnico que entienden los desarrolladores o técnicos. En medio también mete una criba de lo que se debe hacer por "dificultades técnicas".
• Desarrollador: hace lo que le ha dicho el Jefe Técnico y se lleva los marrones cuando el cliente ve que lo que le han hecho no es lo que él quería.
  

Consecuencias de la mala comunicación:

Aparte del posible fracaso de un proyecto, se deriva una consecuencia, si cabe peor: la desmotivación del equipo de trabajo. Un jefe sin el apoyo de los empleados no tiene poder para sacar ningún trabajo, por lo que un equipo de trabajo desmotivado que no trabajo con ilusión es la perdición de un responsable y su ruina. En cambio, un equipo de trabajo motivado, ilusionado con sus trabajo y partícipe del diseño y desarrollo de las soluciones podrá superar las expectativas del cliente y obtener un producto de calidad. Se mejorará la comunicación entre las diferentes partes (al haber mayor confianza) y se aportarán más ideas (enriqueciendo el producto final).

Espero que os haya gustado este artículo y que se reflexione sobre él para intentar mejorar la comunicación y la confianza dentro de los proyectos.

Tiras de Dilbert

Se ha incluido una nueva sección en el blog para poner cada semana una tira cómica de la serie Dilbert. Todos los lunes actualizaremos la tira, la cual creo que refleja de una forma muy sarcástica el trabajo dentro de una empresa (siendo algunas situaciones bastante reales...).

Espero que os guste esta nueva sección.

La paradoja del software "libre"

Este artículo se sale un poco de la temática de este blog puesto que no es técnico sino más bien una reflexión propia que me hago.

Antes de nada, me gustaría aclarar que en este artículo me refiero a una parte del movimiento software libre y no a todo. Hay muchas personas que ponen su esfuerzo y trabajo a nuestro alcance de una forma altruista y desinteresada intentando que el resultado sea útil a toda la sociedad, independientemente de su nivel de conocimiento tecnológico y de su nivel salarial. A todas esas personas, gracias.

Sin embargo, hay dos actitudes dentro del software libre que desvirtúan ese movimiento: aquellos que intentan que se convierta en propiedad o que esté bajo el mandato de una élite exclusiva de personas que discriminan cualquier iniciativa que no cumpla con sus reglas y aquellos que se aprovechan del movimiento para obtener beneficios económicos (no tengo nada en contra de aquellos que sin tapujos y con fines económicos distribuyen versiones de demo, prueba o sucedáneos). Sobre ellos va este artículo

Empecemos

Desde hace tiempo, vengo dándole vueltas a la expresión “software libre”, término asociado a múltiples programas, aplicaciones, sistemas operativos y demás que se distribuyen de manera libre y que son estandarte de un movimiento social a nivel tecnológico. Ejemplos de software libre serían, por ejemplo, Ubuntu como sistema operativo, Apache como servidor web, JBoss como servidor de aplicaciones, Java como lenguaje de programación (igual que .net de Microsoft), OpenOffice como entorno ofimático y múltiples aplicaciones más desarrolladas en Java o cualquier otra cosa que no sea Microsoft y sobre Linux (los que desarrollan en Java sobre Windows son menos “libres”).

Sin embargo, después de probar Ubuntu y Kubuntu (de Fedora no comento), haber montado un par de servidores Apache, unos cuantos JBoss, viendo como un compañero sudaba tinta china para montar un servidor Nagios, me di cuenta que el software libre es libre sólo para unos cuantos, para aquellos que saben de informática y que tienen tiempo de enfrascarse en foros, chats, blogs y demás utilidades de Internet. El software libre no está orientado para el usuario real de a pie para el que el ordenador no es un fin sino una herramienta. Pero, vayamos paso a paso y explicando:

Ubuntu (por poner un ejemplo)

Una persona normal con los conocimientos básicos de informática, es decir, encender, apagar el ordenador, ver el correo y navegar por Internet, decide cambiarse a Ubuntu porque le han comentado que está muy bien y que es gratuito. Esta persona se descarga la distribución del sitio web de Ubuntu, la monta en un CD y lo arranca. Hasta aquí todo muy bien, la instalación es muy fácil con unas instrucciones muy bien puestas. Una vez finalizada la instalación, arranca el ordenador y lo primero que se encuentra (si sabe…) es que tiene que actualizar los repositorios y modificarlos para acceder a los que de verdad tienen las aplicaciones. Empieza a entrar en foros (si sabe…) y empieza a leer que tiene que entrar en no se qué directorio, utilizar algo llamado vi y teclear una serie de instrucciones en la pantalla desde algo que se llama “shell” (qué será eso). A medio camino se le queda colgado el OpenOffice (muy común) y el ordenador se queda tostado (no sé como no sabría entrar en el “shell” y hacer un “kill” del proceso del OpenOffice, hay que ver). Finalmente, nuestro usuario desesperado desinstala el Ubuntu y sigue con su Windows que por lo menos todo viene mascado y sale en ventanas.

El Círculo Interno de los Ficheros

Tengo la certeza de que para que un software sea “libre” debe de tener un montón de ficheros de configuración, de definición, de variables, en el path de un sitio, en el path de otro, y por supuesto, ninguna ventana de administración (y ninguna ayuda). Yo creo que es porque en inglés ventana se dice Windows y a los del software libre les da yuyu. Por otro lado, el mantener los ficheros y no hacer aplicaciones orientadas al usuario final es porque debe existir un Consejo de malvados o Circulo Interno de los Ficheros que otorgan el título de software libre (o software que mola) que realmente no quieren que el usuario normal (es decir, el usuario no gurú ni friky de la informática ni programador de algo) tenga el conocimiento total, siempre se guardan esa sabiduría de cómo configurar una aplicación (porque es software libre).

La hipocresía del software social

Como todo en esta vida, el software libre no deja de ser una tapadera de una serie de personas que tienen fines lucrativos. Esta serie de malvados no quieren que los mortales sepan utilizar al 100% sus herramientas porque ofrecen sus servicios (cobrando por supuesto) para enseñar a utilizarlas. Para conseguir esto se hace lo siguiente:

1. Hágase una herramienta en Java. Por qué en Java? Porque funciona en Linux y en Windows (agggg he dicho la palabra prohibida) No mola lo mismo que sólo funcione en Linux que lo utilizan muy pocos y no tienen dinero, tiene que funcionar también en Windows (agggg, otra vez…)
2. La herramienta debe de tener un montón de ficheros de configuración que solamente tú sabes manejar. Por supuesto el código no debe estar comentado para que nadie te pille por donde va el tema.
3. Habla con un par de gurús de los foros para que digan que tu aplicación mola y que es muy libre y que tú vas contra sistema.
4. Deja unos meses que la gente utilice tu herramienta gratis dándoles asesoramiento y respondiendo a sus dudas.
5. Al pasar los meses, saca una versión Lite (que no vale un pimiento), saca una versión Professional (por la que cobras un dinerillo para sustentar la causa, siempre gusta) y empieza a cobrar por servicios y a cobrar por las respuestas.
6. Ya tienes montado tu negocio de software libre.

Fin del Discurso

El software libre es libre hasta que se mete el dinero por medio y pienso que el dinero lleva metido mucho tiempo provocando que los intereses de unos pocos manejen a muchos. Pero en fin, viva Microsoft y abajo el monopolio…. digo…viva Linux y arriba el monopolio…. en fin, ya no se lo que me digo.

Servicios de directorio. El caso de NIS

• Propósito general e introducción a los Sistemas de Directorio
  

El propósito general de los servicios de directorio es la compartición de información, muy necesaria en las redes de ordenadores.
Un ejemplo de un servicio sería el de la correspondencia nombre de máquina-dirección IP, que presta el servicio de DNS, y que se crea precisamente con el objetivo de resolver un problema de compartición de información muy grande que se planteó en la por aquel entonces incipiente Internet. El problema derivaba del sistema anterior empleado para asignar biunívocamente nombre de máquina y dirección IP, que consistía en un fichero "hosts.txt" (de ahí las raíces del fichero local de sistemas Linux /etc/hosts) que se ofrecía a través de la red al resto de equipos. Las máquinas conectadas a Internet se sincronizaban cada cierto periodo de tiempo con un servidor que servía este fichero "hosts.txt" con la nueva asignación de nombres-IPs. Como se puede imaginar, este sistema funcionaba a la perfección con una Internet poco poblada, pero era inviable para el futuro, sobre todo teniendo en cuenta el increíble aumento de hosts en internet (boom de las punto com...). La solución fue idear una base de datos jerarquizada y distribuída, creando dominios que contuvieran la información de las máquinas en su interior, y que supieran alcanzar a otras máquinas en caso de que la asignación máquina-IP solicitada no estuviese en sus manos.
El otro ejemplo, del que nos ocupamos un poco más aquí es el de NIS. Desarrollado por Sun Microsystems en los 80, se ideó con el fin de solucionar la gestión de nombres, usuarios y grupos en redes con gran número de nodos. La idea era crear un sistema cliente-servidor que permitiese almacenar determinada información de configuración en un servidor y que los clientes se pudiesen conectar a él para averiguarla. De esta manera se evitaba tener que hacer tantas actualizaciones como máquinas hubiese en una red después de cada cambio.
En sus primeras versiones se llamaba "Yellow Pages" (Páginas Amarillas), pero esto llevó a toda una serie de demandas por parte de British Telecom que tenía la propiedad de dicha marca, con lo cual después de algunos trajines entre tribunales, acabó por llamarse NIS (Network Information Service). Los restos de su antiguo nombre todavía pueden intuirse en el nombre de los diferentes demonios y scripts que NIS utiliza (ej: ypbind, ypserv...).
Con la evolución de las necesidades de este tipo de servicios, los nuevos requerimientos condujeron a la aparición de un NIS mejorado (NIS+) que permite la administración jerárquica (al estilo de DNS), soporte para un nivel de seguridad mayor (tipos de acceso diferentes en función de la confidencialidad de los datos), sistema de verificación del servidor para los clientes, mejora del proceso de actualización de datos...

• El Directorio Standard X.500

A la par que DNS y NIS se estaban definiendo se hizo un esfuerzo especial para estandarizar la estructura de directorios de información, resultando en X.500. Un ejemplo de cómo almacenaría X.500 un dominio n-idea.alcala.com sería
{ Country = ES, Organization = N-Idea. Nuevas Ideas, Organization Unit = Empresa, Location = Alcala la Real }.
El etiquetado de los diferentes niveles de jerarquía aporta la posibilidad de realizar búsquedas inteligentes de información en el servidor.

• El Protocolo LDAP

LDAP surge como solución a la adaptación de DAP a las redes TCP/IP.
Cuando se definió el estándar de X.500 se creó un protocolo, que se llamó DAP para permitir el acceso a la base de datos a los clientes, pero este protocolo se ideó asumiendo que acabaría reinando la distribución OSI de los niveles de transporte y red y que TCP/IP acabaría desapareciendo. La realidad demostró todo lo contrario, por lo que se hizo imprescindible la adaptación de DAP a los niveles TCP/IP.

• ¿Y cómo funciona NIS?

NIS basa su actividad en una estructura cliente-servidor. El servidor (que puede ser maestro o esclavo) contiene unos ficheros de datos (llamados mapas) que el cliente va a buscar. La versión última de la base de datos la posee el servidor maestro y la distribuye a los servidores esclavos de forma perfectamente configurable, tanto al iniciar como al producirse un cambio. Los servidores esclavos sirven información pero no permiten la modificación de ésta.

Un nodo NIS puede ser:
- Cliente: Para minimizar el trabajo de configuración y facilitar la administración del sistema, se procurará maximizar la información distribuída por NIS.
- Servidor: Tiene los mapas, responde a peticiones de clientes, pero su propia configuración local no la obtiene por NIS (Sólo es útil cuando el equipo es servidor únicamente de NIS).
- Cliente y Servidor: La misma máquina, además de responder a las peticiones de los clientes y funcionar como servidor, es cliente de sí mismo, de forma que el tiempo de configuración del servidor también se minimiza.

Como antes dijimos, NIS copió de DNS lo referente a la distribución en dominios, por lo que NIS define también dominios de NIS que permiten que no exista una única información a distribuir a todas las estaciones, sino que se puedan definir zonas para distribuir cada información. Así, un dominio se convierte en un conjunto de mapas de NIS, lo que obliga a un cliente a especificar tanto el dominio como mapa requeridos.

• Vale y eso...¿cómo **** se hace?

Aquí viene la parte divertida. Para instalar un servicio de NIS tendremos que hacer los siguiente:
- Del lado del servidor:

1. Instalar la aplicación NIS tanto maestro como esclavo en los servidores.
2. Crear la base de datos con los ficheros a distribuir.
3. Arrancar el demonio "ypserv" que procesará las peticiones de los clientes.
4. Añadir (si procede) los servidores esclavos.

- Del lado del cliente:

1. Instalar la aplicación cliente de NIS.
2. Modificar los ficheros de configuración para que las peticiones de información se hagan a través de NIS.
3. Arrancar el demonio "ypbind" que realizará las peticiones a los servidores.
   

---

Vamos a ponernos a la tarea del lado servidor.
Lo primero es elegir el servidor maestro. Lo que tenemos que tener en cuenta es que ha de ser un equipo con gran estabilidad, capacidad de cálculo y ancho de banda. Dado que distribuye información de configuración vital para los equipos, una parada larga del servidor maestro supondría la parada de toda la red...cosa que no es muy deseable, sobre todo si algún puesto de trabajo depende de ello :). Además, el servidor debe soportar accesos concurrentes a la base de datos.

Instalación del maestro

Primero nos aseguramos de estar corriendo el portmap de RPC (Remote Procedure Call), ya que NIS es un protocolo montado sobre RPC. Normalmente en /etc/init.d/portmap, que podremos hacer que se arranque automáticamente con el inicio del sistema estableciendo un link simbólico en el runlevel 3 de nuestro sistema. (cd /etc/rc3.d en Ubuntu o cd /etc/rc.d/rc3.d en Redhat y luego ln -s ../init.d/portmap S60portmap). Si la posición 60 estuviese ocupada se pueden utilizar las siguientes.
Definimos el dominio de NIS a utilizar mediante el comando domainname (man domainname para más ayuda), que se suele incluir entre los scripts de arranque (/etc/init.d en sistemas Debian). Si existen múltples dominios, se repite la operación para cada dominio.
A continuación instalamos el servidor con el comando ypinit -m (normalmente /usr/lib/yp/ypinit -m). ypinit funciona mediante la invocación a la aplicación make, y en el fichero /var/yp/Makefile se pueden definir y modificar las variables que parametrizan el funcionamiento del servidor maestro.
Una vez parametrizado nuestro servidor maestro, al hacer ypinit -m se nos preguntará por los servidores esclavos. No es necesario que estén configurados mientras instalamos el maestro así que se introducen sin miedo (serán almacenados en el fichero /var/yp/ypservers).
Una vez tenemos el servidor instalado como maestro tenemos que decirle que también sea cliente de sí mismo. Para ello, empezaremos modificando el fichero /etc/nsswitch.conf cambiando el orden en que se consultarán las fuentes dependiendo de qué ficheros queramos que se obtengan por NIS. Un ejemplo podría quedar más o menos así:

"...
passwd: files nis
group: files nis
shadow: files nis
hosts: files dns
networks: files
protocols: db files
services: db files
ethers: db files
rpc: db files
netgroup: nis
.."

A continuación incluiremos en el fichero /etc/hosts las direcciones IP de todos los servidores esclavos para un funcionamiento robusto.
Bien, llegó el momento de arrancar nuestro servidor maestro.
Como queremos que el servidor se arranque siempre con la máquina sin necesidad de hacerlo manualmente, lo incluiremos en el runlevel 3 de la máquina (nótese que ypserv e yppasswdd ya se hallan en /etc/init.d). Lo único que tenemos que hacer es situarnos en la carpeta correspondiente al runlevel 3 (cd /etc/rc3.d en el caso de Ubuntu o cd /etc/rc.d/rc3.d en el caso de Redhat) y desde ahí establecer un link simbólico a los demonios ypserv e yppasswdd (ln -s ../init.d/ypserv S61ypserv y ln -s ../init.d/yppasswdd S62yppasswdd). Nótese que he usado los números 61 y 62, pero que en caso de estar ocupados por las llamadas a otros scripts pueden utilizarse los números siguientes.
La forma manual de arrancar estos demonios sería /etc/init.d/ypserv start y /etc/init.d/yppasswdd start.
Los demonios ypserv e yppasswdd se encargan respectivamente de atender las peticiones NIS de los clientes y de permitir el cambio de contraseña de los clientes NIS.

Instalación de los esclavos

Si el sistema lo requiere, y el número de clientes crece suficientemente o bien queremos repartir carga y evitar que cuando se caiga el maestro nuestra red esté "en bragas", instalaremos también al menos un servidor esclavo. Para hacerlo procederemos de forma similar a la seguida con el maestro.
Primero usamos el comando domainname para definir el dominio.
Hemos de tener claro que el servidor esclavo sólo procesa la información que le llega del maestro y en ningún caso incorpora su información local a los mapas que distribuye.
Lo siguiente a realizar es configurarlo como cliente de NIS (ver más adelante Instalación de los clientes).
A continuación instalamos el servidor como esclavo con el comando ypinit -s maestro siendo maestro el nombre del servidor maestro (normalmente la ruta será /usr/lib/yp/ypinit -s maestro).

Si llegado a este punto obtenemos un error tipo "Trying ypxfrd ... not running", es que no hemos arrancado en el maestro el demonio de transferencia de mapas de NIS (rpc.ypxfrd). Lo hacemos y punto. Es tan fácil como ir al Makefile del maestro, descomentar o poner directamente la siguiente línea NOPUSH="false" y luego ejecutar en el maestro cd /var/yp; make all (que reconstruirá los mapas de NIS)

Ahora, si queremos rizar el rizo sería una buena idea automatizar la tarea de solicitar al maestro que nos actualice los mapas de NIS mediante cron.
Hacemos que cron abra nuestro editor preferido con crontab -e en el servidor esclavo e introducimos las siguientes líneas:

30 *      * * *  /usr/lib/yp/ypxfr_1perhour
0 5      * * *  /usr/lib/yp/ypxfr_1perday
0 6,18   * * *  /usr/lib/yp/ypxfr_2perday

La configuración de este fichero de cron es bastante intuitiva (man crontab). Los dígitos significan por orden de izquierda a derecha: minutos, horas, día(s) del mes, mes(es), día(s) de la semana, orden a ejecutar.
De esta manera estaremos siempre seguros de que nuestros servidores esclavos están al día incluso si un esclavo estuviese caído durante el tiempo en que el maestro servía los mapas.

Instalación de los clientes

La instalación de un cliente de NIS es más fácil que la del servidor.
Primero nos aseguramos de que estamos corriendo el portmap de RPC y que tenemos instalados los paquetes de ypbind e yp-tools de nuestra distribución.
Ahora usaremos el comando domainname para definir el dominio de NIS que está sirviendo el servidor de NIS que hemos configurado previamente.
Acto seguido crearemos el fichero /var/yp en caso de que no exista.
Lo siguiente que tendremos que hacer es modificar el fichero /etc/nsswitch.conf para indicar el orden de las fuentes de las que se extraerán los distintos ficheros de configuración, para luego modificar el fichero /etc/yp.conf indicando los servidores del dominio NIS que se usarán.
Vamos a ver un ejemplo de cómo podría quedar el fichero /etc/yp.conf

# /etc/yp.conf - fichero de configuración de ypbind
#
domain nidea server maquinadelmanolo.n-idea.es
# Usa el servidor maquinadelmanolo.n-idea.es para el dominio nidea
#
domain nideacurreles broadcast
# Hace broadcast en la red local para el dominio nideacurreles
#

Finalmente, sólo nos quedará arrancar el demonio ypbind que realizará las funciones del cliente. Como ya hicimos con el portmap y con las funciones de los servidores, introduciremos la llamada a ypbind en el arranque del sistema (si lo que queremos por el momento es sólo probar, la orden para arrancarlo sería /etc/init.d/ypbind start en sistemas Debian o /etc/rc.d/init.d/ypbind start en sistemas Redhat). Para incluir el demonio en el arranque procedemos como siempre:
- cd /etc/rc3.d (Debian) o cd /etc/rc.d/rc3.d (Redhat).
- ln -s ../init.d/ypbind S61ypbind.

¡Y yastá coleguitas! Vamos a usar las yp-tools del cliente para comprobar que todo está way vaya a ser...que luego tó se sabe.

ypcat passwd (sería el equivalente a cat passwd solo que ypcat busca la información servida por NIS y no la local).

Si el resultado es el fichero passwd que sirve el servidor de NIS (siempre que en nsswitch.conf hayáis definido que el fichero passwd se obtiene por NIS con mayor prioridad que de ficheros locales), entonces ya podéis decir por ahí que sois los mejores administrando con 4 toqueteos de teclado la configuración de cuentas de usuarios, host, rutas, y todos estos tinglaos de toda la red de forma centralizada con un servicio de directorio montado sobre RPC. ¡Ale! ¡a chulear pues!

---

• Notas finales

A modo de pequeña reseña voy a enumerar los demonios y aplicaciones principales de NIS, así como algunas de las fundamentales yp-tools:

Demonios:
- ypbind -> demonio del cliente que atiende al servidor.
- ypserv -> demonio del servidor que atiende al cliente.
- yppasswd -> demonio del servidor que permite el cambio de contraseña del cliente.
- ypxfrd -> demonio del servidor maestro que sirve los mapas de NIS a los servidores esclavos.

Aplicaciones:
- ypxfr -> aplicación que ejecuta el servidor esclavo y que contacta con el servidor maestro para bajarse los mapas de NIS.
- yppush -> aplicación del servidor maestro que notifica a los servidores esclavos para que se descarguen los mapas.
- yptools -> herramientas de comunicación NIS de cliente.

yptools:
- ypdomainame -> selecciona el nombre de dominio compartido entre todos.
- yppaswd -> cambia la clave de un usuario (requiere de ypbind y portmapper).
- ypwhich -> muestra el servidor NIS al que está conectado el ypbind.
- ypset -> cambia el servidor NIS al que está conectado ypbind.
- yppoll -> devuelve la versión y servidor maestro de un mapa de NIS.
- yptest -> llama a varias funciones de NIS para comprobar si que configuración es correcta y el sistema funciona como se espera.

SMIL: HTML + TIME

En este artículo vamos a comentar brevemente la posibilidad de extender el HTML con líneas temporales, de forma que podamos definir acciones y movimientos dentro de una escala temporal. Esta técnica de programación permite una experiencia mucho más rica de nuestras aplicaciones o páginas web.

SMIL (Synchronized Multimedia Integration Language) es un lenguaje similar al HTML para implementar presentaciones audiovisuales. Empezó en 1997, estando actualmente en la versión 2.1 de su desarrollo. Es una recomendación del comité W3C aunque, inexplicablemente, no ha sido acogida por Firefox y si por Internet Explorer desde la versión 5.5.

¿Qué se puede hacer con SMIL?
Según W3C, las posibilidades de SMIL abarcan los siguientes items:

• Creación de presentaciones para internet e intranets.
• Creación de presentaciones tipo "slideshow"
• Se ha descrito SMIL como la respuesta a PowerPoint en internet
• Las presentaciones SMIL pueden mostrar múltiples tipos de ficheros (texto, video, audio,...)
• Las presentaciones pueden mostrar múltiples ficheros al mismo tiempo.
• Las presentaciones pueden mostrar ficheros de múltiples servidores web.
• Las presentaciones pueden contener enlaces a otras presentaciones
• Las presentaciones pueden tener botones de control (iniciar, parar, siguiente,...)
• Se pueden definir secuencias y duración de acciones en el tiempo
• Se puede definir la posición y visibilidad de los elementos

Realmente se pueden definir múltiples acciones de una manera fácil y sencilla mediante SMIL. El siguiente es un código de ejemplo de una acción sencilla realizada en SMIL:

Como se puede observar, el código está realizado en XML y es fácilmente entendible:

• Todo el código se mete dentro de la etiqueta "smil"
• Se le añade un "body" a la acción (como si fuera HTML)
• La etiqueta define una secuencia que se repetirá indefinidamente "seq" (repeatCount="indefinite")
• La secuencia se compone de dos imágenes que irán apareciendo, primero image1.jpg durante 3 segundos y después image2.jpg durante otros 3 segundos.

¿Cómo reproducir código SMIL?
El código SMIL se reproduce o ejecuta en visualizadores SMIL preparados para ello. Existen múltiples de ellos en internet, siendo los más destacados:

• Ambulant Player: reproductor open-source que soporta la versión 2.1
• RealOne: de RealNetworks
• Grins: de Oratrix
• Internet Explorer

Sin embargo, una de las posibilidades que más potencia nos da SMIL es la capacidad de integrarse con el HTML permitiendo definir líneas de tiempo para los elementos de las páginas.

HTML + TIME
Esta opción sólo está disponible para Internet Explorer puesto que es el único que sigue la recomendación del W3C. Al integrar el código SMIL junto con el HTML, podemos ampliar las propiedades de los elementos HTML con el tiempo. Al incluirles el factor del tiempo podemos realizar cambios en su visibilidad, movimiento, apariencia, comportamiento dependiendo del momento en el que nos encontremos.

Para habilitar esta función deberemos declarar lo siguiente:








Una vez importado el espacio de nombres, podremos incluirle la opción del tiempo a cualquier elemento que queramos en nuestra página. El siguiente código realiza una acción básica integrándose con HTML:








En este caso, definimos una secuencia temporal que se repetirá indefinidamente apareciendo una imagen y después otra. Es el mismo ejemplo que pusimos antes pero con HTML.

También podemos actuar sobre el inicio y el fin de las secuencias mediante la acción del usuario. En el siguiente ejemplo, la acción empezará 2 segundos después de que el usuario pulse sobre el botón "boton1" y terminará cuando el usuario pulse sobre el botón "boton2":

















En este código también se introduce la posibilidad de realizar acciones en paralelo. Ejecutamos la reproducción de un sonido en paralelo con la secuencia de dos imágenes.

Transiciones:
SMIL2.0 introduce la posibilidad de realizar transiciones entre elementos o en un elemento. De esta manera se introduce una mayor riqueza visual. Para incluir transiciones sólo tendremos que definirlas de esta manera:













Las transiciones posibles son:

• Fade
• barnDoorWipe
• barWipe
• clockWipe
• ellipseWipe
• fanWipe
• irisWipe
• pushWipe
• slideWipe
• snakeWipe
• starWipe

Elementos Audiovisuales:
Los tags que definen elementos audiovisuales que se pueden manejar mediante SMIL en HTML son:

• "animation"
• "audio"
• "brush"
• "img"
• "param"
• "ref"
• "text"
• "textstream"
• "video"

Conclusión:
SMIL nos ofrece una posibilidad muy buena de incluir animaciones y efectos en nuestras páginas web interactuando con los componentes HTML de una manera estándar.No necesitamos instalarnos ningún plugin ni herramienta de terceros y permite una interacción mayor con el usuario.