Introducción

Existe una contradicción muy interesante. Cuando se desarrollan aplicaciones web separamos muy claramente las distintas partes del sistema (arquitectura multi-tier):

• Presentación,
• Lógica de aplicación,
• Almacenamiento de datos.

        TIER-1                  TIER-2                      TIER-3
  +--------------+         +--------------+             +----------+
  | Presentación |_________|   Lógica     |             | Base de  |
  | (navegador)  |         |(servidor web)|             |   Datos  |
  +--------------+         +-----+--------+             +----+-----+
                                 |                           |
                           +-----+--------+             +----+-----+
           MIDDLEWARE      |  PHP/Perl    |_____________| ODBC/PG/ |
                           |              |             | MySQL/DBI|
                           +--------------+             +----------+



                            ARQUITECTURA MULTI-TIER

Sin embargo  a la hora del desarrollo, muchos directores de tecnología o de proyecto pretenden hacerlo todo con una sola herramienta, normalmente Dreamweaver Developer, Delphi o FrontPage.

¿Porque hacemos esto? ¿Porque el diseñador de un sitio debe saber como están almacenados los datos o como funciona la lógica de la aplicación?

La separación es necesaria y nos dará muchas ventajas:

• Primera y más importante, evitamos hacer dependiente todo un sitio web (scripts, diseño gráfico y maquetación) de una sola tecnología o aplicación.
• El diseñador no tendrá que preocuparse de aspectos de programación o base de datos.
• Podemos usar cualquier software para el desarrollo del diseño de la página web. Normalmente los diseñadores tienen su herramienta preferida. Puede ser que dicha herramienta no permita trabajar con MySQL, Postgres o PHP, pero esto no debería significar ningún impedimento.
• Al permitir que un diseñador use su herramienta favorita, aumentaremos la productividad. Tampoco se puede pretender que el  diseñador (en su mayor parte free-lance) tengan que cambiar de software cada vez que se desarrolla un web sobre tecnologías distintas (hoy puede ser PHP y MySQL, mañana Python o Postgres).
• No se le puede exigir a los programadores que aprendan a usar un determinado software de diseño o maquetación, que normalmente están orientados a diseñadores y con una curva de aprendizaje bastante elevada.
• Si permitimos que el trabajo de los programadores sea lo más independiente del diseño posible, y además le dejamos que usen sus propias herramientas, aumentaremos considerablemente la productividad.
• Y la última y no menos importante, las herramientas de desarrollo están evolucionando muy rápidamente, lo que es bueno hoy, podría ser muy malo mañana.

El desarrollo de un sitio web tiene por lo menos cuatro fases distintas:

1. Diseño conceptual.
2. Diseño gráfico y árbol de navegación.
3. Desarrollo.
4. Producción.

El problema radica en que los grupos de desarrollo, sobre todos aquellos que trabajan con presupuestos limitados, no suelen tener las fase de desarrollo claramente divididas, ni una especificación de las herramientas de software que se usarán en cada una de dichas fases. Aquí radica una de las barreras para el desarrollo de sitios web con Linux: se justifica la decisión de usar Windows, ASP y SQL Server en el hecho de que existen mejores herramientas de integración.

Considero que es un gran error, no sólo les hace dependientes de tecnologías propietarias (y dominantes), sino que hacemos que todo el negocio dependa en realidad de 2 o 3 proveedores de software, ya que siempre tendremos que pagar para poder acceder a las últimas herramientas desarrolladas por esas empresas.

Es como si un usuario hogareño, para poder escuchar MP3, siempre tenga que estar actualizado a la última versión de Windows, que en 6 años a producido 6 versiones distintas, con precios que no bajan de las € 100 - € 150 por cada actualización. Llevado éstos a entorno empresariales o gubernamentales hace que los presupuestos se multipliquen enormemente.

Es un error intentar hacer cosas totalmente distintas con las mismos programas o herramientas: no existe la "bala de plata" (The Mythical Man Month, la Biblia de la ingeniería del software). Para evitarlo, lo que hay que hacer es separar las partes como ya se hace en el desarrollo de software modular o por tiers: la presentación, la lógica y la gestión de almacenamiento de datos. 

Los scripts en PHP, o en cualquier otro lenguaje, son parte de la lógica. No tienen que ser conocidos y modificados por la misma persona que hace el diseño (es el encargado de sólo una parte de la presentación), es un trabajo totalmente distinto y no puede producir los mismos resultados.

Tampoco se puede admitir que una herramienta que es apta para diseñadores con pocos conocimientos de programación sea apta para un programador experto. No es sólo aplicar el zapatero a tus zapatos, sino usar la herramienta adecuada para cada trabajo. Los pinceles y el óleo de los artistas son de poca ayuda para un relojero.

Metodología a seguir

Propongo a continuación cuatro pasos básicos a seguir para el desarrollo de un sitio web de forma independiente a las herramientas que usen los diseñadores gráficos. También pongo énfasis en la optimización de las estructuras de las tablas para dar mayor sensación de agilidad al usuario y como estimar y reducir los tiempos de descarga de la páginas.

Estos pasos fueron usados de manera estricta pero no formal en el desarrollo de varios sitios web complejos en los que he dirigido o participado. El más notable quizás sea el web de Última Hora (a mediados de 1998) ya que es un sitio con un diseño relativamente sofisticado, todo los datos están en una base de datos relacional, que además tiene una réplica en la red local de la empresa editora. Todo el web, inclusive la totalidad del diseño y maquetación,  fue desarrollado en menos de un mes y partiendo desde cero. 

A los 20 días ya estuvo on-line y a los 30 días ya estaba a disposición del todo el público. Desde esa época se ejecuta sobre el mismo servidor, con los mismos programas (CGIs y Perl) y hasta el día de hoy no ha fallado un sólo día. Aunque los diseñadores usaron Photoshop, Illustrator y Dreamweaver, todo el desarrollo de los programas y consultas a la base de datos se hicieron con editores de texto estándares de Linux (principalmente el vi).

1. Diseño conceptual

Se fijan las pautas con el cliente, como será el sitio, que datos tendrá, como se navegará, tipo de cliente al que irá orientado, etc. De esta fase se tiene una idea del diseño y la navegación que tendrá el sitio. El resultado ideal de esta fase es una prueba de concepto. La prueba de concepto puede tener dos partes:

1. Diseño gráfico del sitio. Esta parte es preparada por el diseñador principalmente, y suele bastar con los dibujos hechos en aplicaciones de diseño como el Illustrator, FreeHand, KIllustrator e inclusive con software de imágenes como el Gimp o Photoshop.
2. Consulta y carga de datos: Esta parte es preparada principalmente por los programadores y consistirá en unas páginas HTML sencillas generadas por los scripts y que accedan a un prototipo simplificado de la base de datos.

La prueba de concepto no sólo es una buena herramienta para negociar y convencer al cliente, sino también para detectar que información es la que hace falta para completar el diseño de la base de datos y aplicaciones, como así también detectar de antemano los problemas que nos encontraremos en el desarrollo.

2. Diseño gráfico y árboles de navegación

Se hace un diseño detallado de la diferentes páginas que tendrá el web, el diseño gráfico normalmente realizado en una aplicación de dibujo (como el Illustrator), y los árboles de navegación. Si es un sitio dinámico se necesitan tener las pautas y restricciones técnicas de consultas a la base de datos. Aquí es muy importante la discusión entre los diseñadores (gráficos y HTML) y los desarrolladores, los diseñadores no deberían conocer la lógica de la aplicación pero sí las restricciones que esta impone al diseño.

Por ejemplo, si una consulta a la base de datos pueden generar más de 30 o 40 resultados, debe preverse la paginación de la salida, lo que incluye el diseño y enlaces para cada página. También es importante que la longitud y formato de los datos de la base de datos sean adecuados para el diseño que se presenta. Si se generan textos largos, no se pueden poder los mismos en una columna muy angosta y de poca altura.

Lo más importante que hay que tener en cuenta a la hora del diseño conceptual de la parte gráfica y lógica del sitio es el tiempo que tardará el cliente para visualizar el resultado (tiempo de visualización). Hay muchos parámetros que influyen, por ejemplo:

• Tiempo de respuesta: cuanto tiempo tarda en servidor en empezar a devolver resultados al navegador. Este es el parámetro más importante que debe tener en cuenta el o los programadores. De él depende que se pueda ajustar el diseño para que los usuarios puedan empezar a visualizar la página lo más rápido posible. Si las primeras consultas a la base de datos son muy complejas o tenemos habilitado el buffering en el lado servidor (en PHP4 se hace con ob_start()), podemos afectar negativamente el resultado. Por el contrario, si el resultado se obtiene muy rápidamente el uso del buffering puede ayudar bastante al envío eficiente de los datos a través de la red. Para que la página de una sensación de agilidad, es importante que el tiempo de respuesta no supere los 2 o 3 segundos. 
• Tiempo de retorno: cuanto tiempo tarda el servidor en terminar de ejecutar los programas en el servidor y entregar todos los datos y será siempre superior al tiempo de respuesta (T_retorno > T_repuesta). El tiempo que tarde el programa en terminar de generar todos los datos no sólo influirá en la conexión con un usuario en particular, sino con el rendimiento de todo el sistema. A mayor tiempo de retorno, menor cantidad de conexiones simultáneas posibles y mayor carga de todo el sistema. Si el tiempo de retorno de un script es superior a un 1 segundo, hay que estudiarlo detenidamente. El primer estudio a hacer es el consumo de CPU. Si ésta es baja, tenemos problemas de latencia, posiblemente con la conexión a la base de datos. Si por el contrario el consumo es elevado, la lógica del programa es muy compleja o usamos muchas llamadas de sistema. En estos casos puede ayuda el uso de sistemas de cache de código.
• Tiempo de descarga: es el tiempo que tarda el cliente en bajarse todos los datos a su ordenador. Este tiempo es siempre mayor al tiempo de respuesta (T_descarga > T_retorno) y depende de la velocidad de conexión. 

Tiempo de visualización

El primer aspecto a tener en cuenta es la cantidad de código HTML que debe ser bajado para cada página. Esto depende del tipo de conexión que tendrán los visitantes del sitio. Un buen parámetro es que el tamaño máximo del HTML no debe superar los 30-40 KBytes por página genérica. En el caso de imágenes es un poco más flexible, ya que se puede acelerar la previsualización de la página indicando los tamaños en pixels de cada imagen. 

Las páginas de sitios dinámicos suelen tener una estructura bien definida:

1. Cabecera: aquí se suelen poner el logo de la empresa, menú de opciones de navegación, banners de publicidad.
2. Cuerpo: en estar parte se pone la parte principal de la página. También suele estar dividida en dos a tres columnas que sirven para un menú de navegación y otra para un índice de temas o artículos relacionados
3. Pié: aquí suele ir información para contactar a la empresa, direcciones, teléfonos y otros enlaces corporativos.

Un error común es poner esas tres partes anidadas es una sola tabla:

Diseño erróneo de una página con tres tablas anidadas

Este tipo de formato hace que el navegador no pueda generar la página hasta que se reciba el último byte (cercano al tiempo de descarga) que define a la tabla (normalmente el cierre de tabla: </table>). 

Supongamos que la página tiene 40KB de tamaño (en HTML) , que el tiempo de respuesta del servidor es de 0.5 segundos y que su tiempo de retorno es los suficientemente bajo para alimentar de datos continuamente. Si la conexión del clientes de es un RDSI (64 kbps =~ 7.5 KB/seg) y en condiciones ideales, el tiempo qua tardará el navegador en empezar a generar la página en pantalla será igual al tiempo de descarga:

T_vis = T_descarga = 0.5 seg + 40 KB/7.5KBseg = 0.5 seg + 5.33 seg =~ 6 segundos

Aunque este tiempo parezca razonable, no es aceptable, porque en la mayoría de las conexiones no tendremos los 64kbps sólo para bajar el HTML, sino también las imágenes, saturación de la red, etc., por lo que fácilmente dicho valor se duplica.

La forma de correcta de solucionar el problema es de intentar anidar la menor cantidad de tablas posibles, y evitar a toda costa tener una sola tabla principal que engloba a toda la página. Para ello lo mejor es hacer una división horizontal de las tablas:

Diseño correcto con tres tablas independientes

Con la forma de especificar las tablas en la figura anterior, se puede obtener los mismos resultados visuales con una mejora sustancial en el tiempo de visualización. Supongamos que la tabla CABECERA está definida por los primeros 3KB (más que suficiente en la mayoría de los casos), por lo tanto el tiempo que esperará el cliente para empezar a pre-visualizar la página será:

T_vis = 0.5 seg + 4 KB/7.5KBseg = 0.5 seg + 0.53 seg =~ 1 segundo

Como se puede ver, obtendríamos una mejora de casi un 700% con sólo estructurar mejora las tablas. Si la estructuras de la páginas son más complejas, conviene seguir con la técnica de sub-dividir horizontalmente a las tablas:

Diseño correcto con cuatro tablas independientes