Desarrollo on Marco Antonio Blanco

Video.js, reproductor de video HTML5 de licencia libre

Tue, 05 Feb 2013 10:08:04 +0000

Como comentaba en el artículo anterior, la reproducción de vídeos bajo HTML5 no es precisamente la panacea debido a que estábamos obligados a contar con tres versiones del mismo vídeo, una por cada códec soportado por los navegadores modernos, cuyos responsables no supieron (o no quisieron) ponerse de acuerdo cuando llegó el momento de estandarizar el soporte de la etiqueta video. Aunque estas tres versiones, junto con el JPG que hace las veces de póster, se consiguen fácilmente con el script del mencionado artículo, al final triplicamos el espacio necesario para alojar los vídeos y complicamos el código para la reproducción de los mismos.

Desgraciadamente no es el único problema. Otra dificultad que se nos presenta es cómo dar soporte a aquellos navegadores que no pueden mostrar vídeos en HTML5, lo cual generalmente se resuelve presentando un reproductor en Flash. Es decir, que una de las grandes ventajas de HTML5 (prescindir de Flash) la perdemos en estos casos.

El último problema que me he encontrado es el de que cada navegador muestra en pantalla un reproductor de vídeo diferente con un estilo estético distinto. Puede que esto no parezca tan importante, pero cuando uno ha invertido en un diseño y en ofrecer la mejor de las experiencias posibles para el usuario, esta diferencia de comportamiento puede suponer un quebradero de cabeza.

El camino que he tomado en el caso de la web que estamos migrando es el de utilizar Video.js, un reproductor de vídeo HTML5 de licencia libre que resuelve los problemas mencionados: se encarga de generar automáticamente el código para las tres versiones del vídeo, incluye un reproductor Flash para los navegadores antiguos y ofrece un aspecto estético común para todos los navegadores, pudiendo incluso utilizar temas para personalizar el diseño.

Para utilizar Video.js en un proyecto web no hace falta ni siquiera descargarlo, ya que enlazaremos con él desde nuestro código. No voy a repetir las instrucciones que aparecen en su sitio web oficial, pero básicamente consisten en incluir una serie de etiquetas en las secciones head y body de nuestra web.

Aún así, si estamos utilizando un CMS, suele ser más sencillo utilizar algún módulo, extensión o plugin propio que nos ofrezca esta funcionalidad. Por ejemplo, en el caso que nos ocupa, donde estamos utilizando TYPO3, hemos elegido la extensión html5videoplayer. Una vez instalada, basta con insertar el plugin en la página en la que queremos utilizarlo y configurarlo con los vídeos a mostrar, pudiendo reproducir uno sólo o un conjunto de ellos.

En definitiva, a pesar de las dificultades y los obstáculos, HTML5 es el camino a seguir. Con las herramientas adecuadas, este camino será mucho más sencillo y apacible. Espero vuestros comentarios y experiencias con Video.js.

Conversion de videos a HTML5 en Debian Wheezy

Mon, 28 Jan 2013 11:28:44 +0000

Estamos actualmente inmersos en un proyecto web consistente en la migración del actual motor al gestor de contenidos TYPO3. Se trata de una web con una importante carga de vídeos (unos 5 GB), los cuales están codificados como DivX, con la consiguiente complicación a la hora de asegurarse de que se visualizan correctamente en todas las plataformas de navegación actuales. Dado que existen algunas en las que esto ya no es posible (sobre todo en tablets y smartphones), la solución que planteamos era tirar de estándar y convertir toda la base audiovisual a HTML5, lo cual no es la panacea como comentaré más adelante, pero que al menos nos asegura que los vídeos podrán visualizarse adecuadamente de aquí a unos años.

Como estamos hablando de más de 150 vídeos, es evidente que la conversión no se podía hacer a mano, así que buscando por Google me encontré en un blog con una solución que podía automatizar el proceso, basada en la herramienta de línea de comandos ffmpeg, una verdadera navaja suiza para la codificación y conversión de material audiovisual.

Se trata de un script para Linux que toma como parámetro de entrada el vídeo a convertir y que produce como salida tres versiones del vídeo (una por cada codec soportado por la etiqueta video), una captura de pantalla en JPG para el parámetro poster y un pequeño código HTML para visualizarlo todo (que en TYPO3 no es necesario pero que no viene mal para otras situaciones). Sin embargo, el script no funcionaba bien del todo por varios motivos: algunos parámetros de invocación de ffmpeg estaban obsoletos, la visualización de los vídeos en las plataforma móviles de Apple no es correcta (como bien apuntaban en los comentarios del blog) y la generación del HTML para la visualización no funcionaba. Así que me puse manos a la obra y resolví los tres problemas (del segundo ya tenía la solución en los comentarios, como ya he dicho), obteniendo este script:

{code type=php}
#!/bin/bash

if [[ $1 ]]
then
filename=$(basename “$1”)
filename=${filename%.*}
directory=$(dirname “$1”)

duration=$(ffmpeg -i “$1” 2>&1 | grep Duration | awk ‘{print $2}’ | tr -d ,)
minutes=${duration%:*}
hours=${minutes%:*}
minutes=${minutes##*:}
seconds=${duration##*:}
seconds=${seconds%.*}

hours=$((hours*3600))
minutes=$((minutes*60))

total=$(expr $hours + $minutes + $seconds)
number=$RANDOM
let “number %= $total”

echo “Generating thumbnail”
ffmpeg -i “$1” -filter:v yadif -an -ss $number -t 00:00:01 -r 1 -y -vcodec mjpeg -f mjpeg “$directory/$filename.jpg” 2>&1
echo “Converting $filename to ogv”
ffmpeg -i “$1” -acodec libvorbis -ac 2 -ab 96k -ar 44100 -b:v 345k “$directory/$filename.ogv”
echo “Finished ogv”

echo “Converting $filename to webm”
ffmpeg -i “$1” -acodec libvorbis -ac 2 -ab 96k -ar 44100 -b:v 345k “$directory/$filename.webm”
echo “Finished webm”

echo “Converting $filename to h264”
ffmpeg -i “$1” -acodec aac -ab 160000 -vcodec libx264 -vpre ipod640 -b:v 345k -threads 0 -pix_fmt yuv420p -f mp4 -strict -2 “$directory/$filename.mp4”
echo “Finished h264”

echo “Writing HTML…”

echo "

" > "$directory/$filename.html"
 echo " " >> "$directory/$filename.html"
 echo " " >> "$directory/$filename.html"
 echo " " >> "$directory/$filename.html"
 echo " Sorry, your browser does not support HTML5 video" >> "$directory/$filename.html"
 echo "

" >> “$directory/$filename.html”

echo “All Done!”
else
echo “Usage: [filename]”
fi

{/code}

Basta con copiarlo y guardarlo en un fichero al que daremos un nombre descriptivo (por ejemplo, convertHTML5) y que deberemos almacenar en una ruta dentro de nuestro camino de ejecución. Personalmente, sugiero /usr/local/bin en base a las recomendaciones del estándar Linux para los sistemas de ficheros. Antes de proceder a su ejecución, debemos asegurarnos de que el script tiene los permisos adecuados:

# chmod 755 /usr/local/bin/convertHTML5

Igualmente, debemos asegurarnos de que las herramientas de apoyo que el script necesita están instaladas en nuestro sistema. En el caso de Debian, necesitamos al menos tener instalada Wheezy para asegurarnos de que las versiones de dichas herramientas son lo suficientemente actuales para que hagan su trabajo adecuadamente. Para ello además deberemos incluir el repositorio Debian Multimedia en nuestra lista en /etc/apt/sources.list:

deb http://oktan.ls.fi.upm.es/debian-multimedia/ wheezy main non-free

Tras actualizar la base de datos de paquetes:

# apt-get update

procedemos a instalar los paquetes necesarios:

# apt-get install ffmpeg x264 yasm lame libvpx1

Ya podemos proceder a convertir automáticamente todos nuestros vídeos, para lo cual lanzaremos un pequeño bucle:

# for i in *.{avi,AVI}; do convertHTML5 $i; done

Si tenemos vídeos en otros formatos diferentes a DivX, como WMV, MPG o MOV, basta con que añadamos sus extensiones a la lista dentro de las llaves en el bucle. ffmpeg es lo suficientemente inteligente para detectar el formato de entrada y actuar en consecuencia.

Como decía más arriba, este script da como salida tres versiones del vídeo original, uno en cada uno de los formatos (MP4, WEBM, OGV) que soporta la etiqueta video de HTML5. El motivo es que la conocida guerra de codecs se saldó con que cada navegador y plataforma soporta un formato diferente, lo que obliga a mantener una versión de cada uno para que todos los usuarios puedan disfrutar del material audiovisual sin importar cómo se conectan al sitio web. Lo único que ha provocado esta falta de entendimiento es que los desarrolladores tenemos que sufrir esta pesadilla y al menos duplicar el espacio dedicado a los audios y vídeos que queramos servir a través de HTML5. Entiendo que es muy positivo sustituir a Flash de una vez por todas, pero no a cualquier precio. De ahí mi comentario inicial de que esta solución no es precisamente una panacea.

En cualquier caso, este script nos está siendo de gran utilidad y por eso lo compartimos, esperando que también sea útil a nuestros lectores. Espero vuestros comentarios y posibles mejoras que se os puedan ocurrir.

Software libre y desarrollo web

Mon, 17 Dec 2012 11:39:21 +0000

Como el lector sabrá, en Activa Sistemas apostamos desde siempre por el Software Libre, por cuestiones filosóficas y prácticas. Este artículo viene a ser una especie de “canción de la victoria”, y ahora paso a explicar el por qué.

En el sector de las TIC y la informática en general existe mucha oferta en cuanto herramientas, entornos de desarrollo y frameworks en general. A veces, decidir entre una tecnología u otra, puede ser crucial para el desarrollo de un proyecto. La apuesta en general desde hace muchos años de Activa Sistemas ha sido el uso de tecnologías libres, y en el caso del desarrollo web, decidimos apostar por las siguientes tecnologías, hace ya muchos años.

Apache. La decisión de usar Apache no fué en su momento demasiado arriesgada, ya que este servidor web lleva muchos años siendo el más usado por los proveedores de servicios web. A día hoy, observamos una cuota del 64%.
**PHP. **Como lenguaje del lado del servidor, la elección fue PHP. Se trata de un lenguaje especialmente creado para hacer páginas web, es simple, fácil de aprender, muy cómodo para el tratamiento de datos XML y JSON, y con el tiempo ha ido madurando adquiriendo nuevas funcionalidades y características, como la programación orientada a objetos. Desde entonces, su uso se ha generalizado de manera brutal.
Linux y Debian. Sin ánimo de ofender al señor Stallman, Linux ha sido el buque insignia del Software Libre durante mucho tiempo. Nuestra apuesta con Linux, tanto en escritorio como en servidor ha sido fuerte. Linux/Unix es el sistema operativo más usado por los servidores web, siendo la distribución Debian -nuestra favorita - la más usada también.

No cuento con estadísticas sobre sistemas de gestión de base de datos, pero siendo el binomio Apache/PHP el más usado, probablemente nos encontremos con que MySQL se lleva el premio. Siempre teniendo en cuenta que estamos hablando de entorno web.

Personalmente, estos datos vienen a ser una confirmación de que las decisiones tomadas antaño fueron las adecuadas, lo cual produce una enorme satisfacción. Atrás quedan intensas discusiones con colegas de profesión (ahora entran ganas de llamarlos y soltarles el clásico te lo dije), y la defensa de que apostar por el Software Libre era una inversión rentable. Ahora estos datos hablan por si mismos.

Como bonus track, dejo un gráfico en el que se ve que del lado del cliente el navegador más usado es Google Chrome (si bien no es totalmente libre, su desarrollo base sí lo es con el proyecto Chromium). Firefox está un poco por debajo de Internet Explorer. Probablemente si este último no viniese preinstalado con Windows desde Windows 95, habría perdido esa posición hace mucho tiempo.

Problemas con el analizador de webs de Facebook

Thu, 15 Apr 2010 12:29:30 +0000

La semana pasada tuvimos una curiosa incidencia durante el desarrollo de unas mejoras en el portal web de un cliente, basado en Typo3. Entre estas mejoras se encontraba la implantación de una barra de botones para compartir noticias y otras informaciones periódicas del portal en las redes sociales más populares. En pleno desarrollo, al realizar las pruebas de funcionamiento pertinentes nos encontramos con un grave problema: al compartir una noticia en Facebook, sólo se recogía la URL de la noticia, ignorándose otros datos como el título y el contenido de la noticia, además sin motivo aparente.

El problema parecía provenir de una aparente incapacidad de Facebook de extraer del portal web del cliente la información necesaria para la publicación de la noticia a compartir, a pesar de haber utilizado el método estándar más sencillo para compartir una página web en Facebook. El siguiente paso fue seguir a rajatabla las instrucciones de Facebook, tanto para utilizar otros métodos para compartir información web como para facilitar la detección de dicha información, sin éxito.

Se nos ocurrió entonces que si el analizador de Facebook no podía encontrar la información deseada puede que fuera porque el código del portal tuviese algún problema. Aunque estábamos seguros de antemano de que dicho código era estándar, por si acaso pasamos el portal por el validador del W3C, que nos confirmó que el código XHTML que producía el motor de Typo3 era válido. Esto es algo que cuidamos mucho en nuestros proyectos web, buscando asegurar la visibilidad en la mayoría de navegadores, plataformas y sistemas operativos. En el caso de Typo3, esto lo conseguimos tanto a través de extensiones especializadas (para el contenido y funcionalidades estándares) como de una composición de código muy cuidadosa (en el caso de las personalizaciones que tengamos que llevar a cabo). Para los interesados, les recomiendo extensiones como cron_accessiblemenus, accessible_tables y qcom_htmlcleaner.

Lo siguiente fue investigar (vía Google, dónde si no) si había más gente con este problema. Desgraciadamente, esta incidencia es más común de lo deseable y se produce independientemente de la forma de gestionar y producir el código del portal, ya sea a mano o con un gestor de contenidos (Typo3, Drupal, Joomla, etc.). A pesar de que nadie encontraba una solución, al menos una que sirviese para todo el mundo, sí nos dimos cuenta de que había algo en común en todas las quejas: los responsables de dichos sitios web también tenían mucho cuidado con la validez y estandarización del código que producían. Eso nos llevó a pensar que quizás el problema estuviese ahí, algo en el código que impedía que el analizador de Facebook hiciese su trabajo. A estas alturas era evidente que la culpa era de Facebook y no de los centenares de desarrolladores web con el mismo problema en todo el mundo, pero eso no quitaba para buscar una solución para nuestro cliente.

En nuestro caso, analizando minuciosamente el código XHTML del portal, encontramos pronto un primer candidato a “culpable”. Todos nuestros portales Typo3 empiezan de la misma manera, con una línea como ésta:

<?xml version="1.0" encoding="utf-8"?>

A día de hoy, pocos navegadores, dispositivos y otros elementos de acceso a la web echan cuenta de la información contenida en esa línea, por muy estándar que sea, así que probamos a eliminarla y, ¡voilá!, problema resuelto. El analizador de Facebook era repentinamente capaz de capturar la información de las noticias que nuestro cliente quería compartir. En el caso de Typo3, basta con añadir la siguiente línea en la configuración de la plantilla:

config.xmlprologue = none

A pesar de producir código válido y estándar en el portal web y de haber seguido las instrucciones del propio Facebook al pie de la letra, su analizador era incapaz de realizar correctamente el trabajo para el que supuestamente está preparado, lo que no habla muy bien de la popular red social. Si para que funcione bien, encima hay que “disminuir” el nivel de estandarización de una web, apaga y vámonos. Este es precisamente el peligro de no respetar los estándares en la web: problemas, costes extra, usuarios excluidos y, en el caso de una empresa, clientes insatisfechos.

Proyectos ágiles con Typo3

Thu, 01 Apr 2010 12:31:56 +0000

En mi artículo anterior sobre Typo3, encuadré la gestión de proyectos web dentro de una metodología clásica en cascada. En este articulo pretendo mostrar no sólo cómo se aplicaría una metodología ágil a un proyecto basado en Typo3, sino también que la arquitectura interna de este CMS facilita y potencia el uso de estas metodologías.

Para ello, lo que voy a hacer es adaptar los pasos y tareas detallados en el otro artículo a Scrum, mi metodología favorita y la que utilizamos preferentemente en Activa Sistemas. El proyecto empieza definiendo el conjunto inicial de requerimientos y funcionalidades del nuevo entorno web y recogiendolo en el product backlog, que nos servirá de guía a lo largo del proyecto. A continuación pactamos con el cliente los objetivos de la primera iteración, con lo que estaremos en disposición de acometer las tareas que en el artículo anterior estaban dentro de la fase de Codificación de una metodología en cascada.

En la primera iteración se instala necesariamente el motor de Typo3 sobre el que desarrollaremos el proyecto y una plantilla estándar que nos permita visualizar desde el primer momento el resultado del trabajo. De este modo se cumple con una de las premisas fundamentales del desarrollo ágil: tener siempre disponible un producto publicable y en funcionamiento que el cliente puede revisar cuando quiera.

A partir de aquí podremos ir diseñando e integrando la plantilla visual, introduciendo el contenido estático, instalando las extensiones y codificando las personalizaciones en paralelo en las sucesivas iteraciones, en las que podremos implicar sin problemas al cliente y a los futuros usuarios.

Además, gracias a ciertas caracteristicas de Typo3, podremos incorporar al desarrollo del proyecto herramientas de otras metodologías ágiles como XP o TDD. Por ejemplo, incluye su propio sistema de control de versiones, lo que facilita la introducción controlada de pequeños cambios y posibilita la propiedad colectiva del código. Así mismo, la construcción de pruebas unitarias es relativamente sencilla, gracias tanto al propio framework PHP de Typo3 como a ciertas extensiones especializadas (PHPUnit, Cool).

Con esto espero haber dejado claro que es perfectamente posible gestionar de forma ágil un proyecto web en general y con Typo3 en particular. Sólo se trata de tener las ganas de hacerlo y las herramientas adecuadas para ello.

Por qué las metodologías ágiles no triunfan en Andalucía

Mon, 15 Mar 2010 21:32:34 +0000

Tras mi reciente artículo sobre la planificación de proyectos de desarrollo basados en el gestor de contenidos de licencia libre Typo3, recibí un mensaje a través de Twitter de un antiguo compañero de Universidad en el que me echaba en cara que no hablara de las metodologías ágiles de desarrollo de software. Es cierto que el contexto de dicho artículo era el de las metodologías clásicas en cascada y que puse de ejemplo la archiconocida METRICA v3, pero no es menos cierto que en Activa Sistemas llevamos ya años utilizando metodologías ágiles en la gestión de nuestros proyectos de desarrollo. Sin embargo, no podemos aplicarlas tanto como nos gustaría debido a tres obstáculos que voy a describir a continuación y que tienen sus raíces en la idiosincracia de la región en la que nuestra empresa tiene su sede principal: Andalucía.

El primer obstáculo es la Administración Pública local. A día de hoy es muy raro encontrar una licitación en la que no se pida utilizar METRICA v3 o una metodología clásica similar. De hecho, en una licitación a la que nos presentamos hace un par de años y que no conseguimos, se me llegó a argumentar que nos quedamos fuera por no proponer una metodología adecuada, cuando lo que planteamos fue precisamente una metodología basada en entrevistas, iteraciones, escenarios y maquetas. Solución: introducir de forma sutil (por no decir oculta) en las propuestas mecanismos ágiles en la relación con el cliente y utilizar herramientas ágiles en los procesos internos de desarrollo del proyecto, como la programación en parejas típica de XP o las mencionadas iteraciones de Scrum (dejando de lado al cliente).

El segundo obstáculo nace de las propias dimensiones de Andalucía. La distancia entre Ayamonte al oeste y Pulpí al este es de más de 600 kilómetros. Cuando uno tiene su sede en Sevilla y trabaja mucho en Almería, como nos pasa en Activa Sistemas, se producen inevitablemente unos costes extras de desplazamiento, manutención y estancia que no son precisamente despreciables. A pesar de que Internet ha recortado las distancias considerablemente, es indiscutible que sigue haciendo falta el contacto directo con el cliente, ya sea porque éste lo exige para creerse que “se está haciendo algo” o bien porque existen tareas en todo proyecto de desarrollo que necesitan de una actuación de campo. Si a esto le añadimos las iteraciones de un proyecto ágil, los costes logísticos se convierten en un gran obstáculo para ser competitivo frente a otras ofertas. Solución: minimizar los viajes, aprovecharlos para realizar varias tareas en paralelo, maximizar el contacto por Internet (utilizando desde el correo electrónico hasta la videoconferencia, pasando por la mensajería instantánea) y, a pesar de todo, calcular un presupuesto holgado para poder costear varios viajes.

El tercer y último obstáculo es uno que se menciona en un artículo sobre agilismo: los presupuestos cerrados. En dicho artículo, en la sección de “Estimaciones”, el autor dice que hay que intentar huir de proyectos a precio cerrado. Pues bien, a día de hoy estoy aún por ver un proyecto en el que el cliente me dé un cheque en blanco. Lo más parecido que me he encontrado es una bolsa de horas que se va gastando y cuyo consumo controla el cliente en todo momento. No sé en otros lugares de España, pero en Andalucía lo que se estila es el presupuesto cerrado, tanto en coste como en tiempo, lo que no evita que el cliente intente tomarse “barra libre”, como comenta el mencionado artículo, lo cual va a ocurrir independientemente de la metodología utilizada. Solución: presupuestos holgados (a la vez que competitivos) para tener margen de maniobra y poder satisfacer al cliente en los eventuales cambios que se produzcan en el desarrollo del proyecto (que seguro se van a dar).

Aplicando las soluciones comentadas hemos conseguido sortear estos duros obstáculos en diversos proyectos, los cuales han resultado ser los más satisfactorios tanto para el cliente como para nosotros mismos. Esperemos que la situación siga cambiando y que las metodologías ágiles vayan calando cada vez más en la sociedad andaluza.

Desarrollo web bajo Linux (y II)

Tue, 18 Nov 2008 20:43:53 +0000

En el artículo anterior analicé la situación del desarrollo web bajo Linux desde el punto de vista de la estación de trabajo. Ahora toca echar un vistazo a la otra mitad de la historia: los servidores web.

Es evidente que Linux ya ha triunfado en los servidores web. No se trata de una afirmación gratuita, sino basada en datos fiables y actuales, perfectamente consultables por cualquier usuario en sitios como NetCraft. El porqué de este éxito es fácil de dilucidar: estabilidad, seguridad, constante evolución y mejora, una amplia comunidad de usuarios y un extenso catálogo de potentes herramientas. Vamos a centrarnos en este aspecto, al igual que en la primera parte de este artículo.

Cuando hablamos de desarrollo web desde el punto de vista del servidor, nos encontramos con numerosas herramientas: lenguajes de programación (PHP, Python, JSP, Ruby), frameworks de desarrollo (Zope, Symfony, ASCore), gestores de contenido (Typo3, Joomla, Plone) y servidores de aplicaciones (Midgard, Enhydra). Así mismo, contamos con numerosas aplicaciones web listas para instalar y utilizar: desde plataformas de teleformación (Moodle, Dokeos) hasta blogs como éste (Wordpress), desde completas intranets (eGroupware) hasta plataformas de comercio electrónico (osCommerce). Para cada caso existen numerosas posibilidades, tanto de libre distribución como comerciales, que nos permiten obtener las herramientas y los recursos adecuados según el proyecto web en cuestión.

Finalmente, podemos recurrir a poderosos backends para nuestros desarrollos en forma de gestores de bases de datos potentes y populares, tanto libres como comerciales, como MySQL, PostgreSQL, Oracle, DB2 o Informix, por nombrar algunos. De este modo, es posible desarrollar aplicaciones web de cualquier calibre, incluyendo grandes proyectos corporativos.

La popularidad de estos entornos es tan grande que el “equipo” más utilizado para la implantación de proyectos web en la actualidad está compuesto por Linux + Apache + PHP + MySQL, conjunto más conocido por “plataforma LAMP”. Si proyectos de la importancia de Google, Slashdot o Amazon han confiado en Linux para sus plataformas web, por algo será.

¿Y tu sitio web? ¿Lo tienes alojado bajo un servidor Linux?

Desarrollo web bajo Linux (I)

Tue, 11 Nov 2008 21:13:05 +0000

Cuando Linux vió la luz en 1991, ya traía una vocación heredada de la familia en la que había nacido, es decir, Unix: la perfecta integración con las redes y su facilidad de acceso a las comunicaciones. En aquel momento en Internet, la Web era apenas un proyecto incipiente del CERN y los usuarios se comunicaban entre ellos principalmente mediante correo electrónico, los grupos de noticias #USENET y el sistema Gopher (antecesor de la Web).

Como es bien sabido, la aparición de la Web y la consiguiente popularización de Internet trajo consigo el nacimiento de una nueva disciplina, las Nuevas Tecnologías, que obligaron a todos y cada uno de los sistemas existentes a evolucionar si no querían quedarse fuera de la “revolución” (lo cual estuvo a punto de pasarle a Windows ante el rechazo de Internet como algo útil y con futuro por parte de Bill Gates).

Hoy día cualquier usuario final ve cumplidas sus expectativas de comunicaciones con los sistemas operativos más populares, ya sea Windows, Linux o Mac. Sin embargo, ¿qué ocurre con los profesionales del diseño web?

Linux disfruta en la actualidad tanto de editores de páginas web visuales (al estilo de Dreamweaver), como KompoZer como opción más destacada, como de entornos de desarrollo web completos, como Quanta o Bluefish, especializados en la composición manual de interfaces, la programación en los más diversos lenguajes y en la gestión de proyectos web.

A partir de aquí, Linux ofrece una enorme cantidad de aplicaciones para todos y cada uno de los aspectos del desarrollo web: herramientas de bases de datos, tratamiento gráfico, navegadores, comprobadores de enlaces, verificadores de estándares, etc. Basta con darse una vuelta por Freshmeat para darse cuenta de lo que podemos hacer con Linux a la hora de enfrentarnos con un proyecto web.

Por ello no puedo por menos que recomendar a todos los profesionales del diseño y el desarrollo web que le den una oportunidad a Linux (si no lo hayan hecho ya) y verán como no quedan decepcionados, ya que encontrarán herramientas para todo lo que necesiten, mayor estabilidad (se acabaron los “cuelgues” impredecibles) y una elevada compatibilidad con los estándares.