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:
- Diseño conceptual.
- Diseño gráfico y árbol de navegación.
- Desarrollo.
- 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:
- 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.
- 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 (Tretorno >
Trepuesta). 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
(Tdescarga > Tretorno) 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:
- Cabecera: aquí se
suelen poner el logo de la empresa, menú de opciones
de navegación, banners de publicidad.
- 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
- 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:
Tvis = Tdescarga =
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á:
Tvis = 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 |