Actualización: Actualizo la fecha de modificación de este artículo porque he recibido el flame más largo de Bulma (aunque luego pensé que quizás sea un troll). Como se ha tomado el trabajo de escribir un comentario largo (con lo difícil que es en el navegador) se merece unos días de portada, es el comentario 9. Podéis ver típico lenguage comercial, poniendo a parir al que critica (yo) su tecnología. Digamos que es un FUD “respondón” 😉

Por favor, espere unos instantes mientras se tramita su pedido...

Se ha producido un error en la conexión con nuestro servidor, por lo que su petición no ha podido ser atendida. Por favor, inténtelo de nuevo en otro momento 

No, no no. No es ningún error de nuestro servidor, sino algo a que
acostumbrarse si compras en supermercado.elcorteingles.es.
Por supuesto no es Apache ni PHP, ni JSP. Es ASP sobre un Windows NT4.0 e IIS4.
Es una vergüenza que una empresa como El Corte Inglés tenga montado un sistema
donde el tiempo mínimo de respuesta sea de 30 segundos… a las 23:30 de la
noche. Demuestran lo poco en serio que se toman la satisfacción del cliente en su departamento de desarrollo.

Desde que uso Internet para hacer las compras del súper, siempre he
criticado lo mal programado que está el sistema de El Corte Inglés:

• mala navegación,
• enlaces incorrectos,
• tiempos de espera infinitos.

Ahora han cambiado totalmente, pero para peor. 
Cuando me conecto hoy para hacer una nueva compra veo que habían cambiado
totalmente el diseño y la navegación del sitio. Ostras!!! pensé, lo han
arreglado, parece mas intuitivo. Un desplegable a la izquierda para seleccionar
sección, otro en el centro para seleccionar familia y uno a la derecha para
lista de artículos, sencillo, y claro, sin necsidad de estar recargando
páginas. Además abajo una lista de las ofertas del día. Pintaba muy bien…
Empieza la batalla
Todo comienza cuando seleccionas una sección (por ejemplo Bebidas, Ultramarinos,
etc.), bien, cuando la seleccionas, y sin ningún tipo de mensaje, tarda unos 15
segundos en montarse el desplegable del centro para seleccionar familia. Otros
20 segundos para que se visualice el desplegable de selección de artículos.
Cuando seleccionas los artículos, y sin que medie ni si siquiera un mensaje de
“espera que nuestro NT está largando humo”, tienes que esperar como mínimo
30 segundos para que te aparezca la lista de artículos.
Y eso no queda allí… ves la lista de artículos con un pequeño espacio
para poner cantidad y un icono de “cesta”. Vale, pones la cantidad,
presionas sobre el icono… y empezarás a entender porque a tu madre o
hermanito pequeño no le gustan navegar por Internet. No hay mensajes, no se
mueve nada, el icono del Navegador no se mueve (porque son frames y llamadas con
JavaScript), parece que todo está muerto, después de unas cuantas decenas
de segundos se actualiza el frame de la izquierda donde aparece el listado
de la cesta.
Los tiempos de respuesta
Aunque también es criticable la forma en que presentan los artículos:

• ¿Porque los melocotones en almíbar están en “Legumbres en
  conserva”?
• ¿Porque las Quelitas están en “Galletas para desayuno” si yo
  las como todo el día?

Lo peor de todo son los tiempos de respuesta totalmente inaceptables para
el web. Si se leyesen cualquier libro de Interfaz de Usuario, o inclusive
cualquier web más o menos respetable (como el de Jakob
Nielsen), se darían cuenta que los tiempos de respuesta para una
aplicación interactiva no debe superar los pocos segundos: 1, 2 o 3, pero
nunca 30 segundos que es lo más rápido que se obtiene en este sitio.
Esta gente tampoco se entera de los incontables benchmarks pare medir
la cantidad de transacciones por segundo que soportan las distintas bases de
datos sobre los distintos sistemas operativos y middleware. Es como si
ellos todavía estuviesen en el viejo (prehistórico, de X25, terminales IBM o
Unisys y el Amadeus que se caía cada rato) escenario de un empleado de Iberia,
que cuando ibas a reservar un billete tardaba como 2 minutos en poder empezar a
leer un listado críptico de vuelos disponibles.
Señores, lo que es aceptable para un empleado de la casa (30 segundos de
espera para que la pantalla se mueva), que le pagan para que haga eso,  no
es aceptable para los clientes que acceden desde casa, con sus propios
ordenadores y al que se le intenta vender.
El tiro de gracia
Vale, como ya no tenía ni azúcar en casa y no podía ir al otro día, hice
de tripas el corazón y continué con el ejercicio masoquista de comprar por
Internet en las respetabilísima empresa líder española (que hasta cuenta con
un centro de I+D). 
 Después de hora y pico para poder gastar 16.980 Ptas. y comprarme los
víveres necesario para sobrevivir (sin ir al bar de la esquina), selecciono la
opción “Tramitar pedido”. Dios mío, calamitoso…. Me aparece el
mensaje:

Por favor, espere unos instantes mientras se tramita su pedido…

después de 30 segundos (os prometo, cronometrado), me aparece lo siguiente:

Se ha producido un error en la conexión con nuestro servidor, por lo que su petición no ha podido ser atendida. Por favor, inténtelo de nuevo en otro momento
.
 
NOTA: si ve un enlace roto en la imagen, tampoco es error nuestro, es que
esa imagen, a la hora de hacer mi pedido no existía en el servidor.

Por supuesto que pueden ocurrir errores de conexión… vale. Pero no había
ningún botoncito o enlace que haya dicho “reintentar”. Sin embargo
ellos me pedían que lo reintente nuevamente.
Quedé mirando la pantalla un par de minutos intentando adivinar que podía
hacer. ¿Se habrá hecho mi pedido? ¿Como hago para no perderlo? Fueron más de
60 minutos de nervios para poder hacerlo. Después de largas divagaciones,
razonamientos y relecturas a los 5 frames que tenía en la pantalla, decidí que
lo mejor era picar nuevamente sobre en enlace de “Tramitar pedido”. Y
se me bajó la presión a niveles alarmantes. La pantalla decía:

La cesta de su pedido está
vacía.

&%@#$ y varios improperios después se me ocurre probar el botón
“Back”. Por supuesto, me daba el error “La página ha
caducado…”.
Final Feliz
Finalmente, vencido y resignado a ir al viejo Pryca de siempre y pelearme con
los carritos dejados en el medio del pasillo o estresarme en las colas de la
caja cuando la señora de adelante lleva 48 braguitas a las que hay que sacar
los “anti-robos” con una parsimonia de joyero, decido empezar a
escribir este artículo, cuando se me ocurre mirar la opción “Pedidos
anteriores”. Oh venerable Santa Tecla!!!,
has escuchado mis clicks. El pedido está hecho.
¿Que pasa?
El sistema de “El Corte Inglés” es un ejemplo palpable de cómo no
se debe montar un sitio de comercio electrónico. Y no creo que haya sido por
falta de presupuesto. Pueden pasar varias cosas:

Que todo el mundo mundial compre en “El Corte Inglés” (más que
en Amazon) y está padeciendo de éxito.

Que esté fatalmente implementado.

Personalmente me inclino por la segunda opción, ya que nunca han tenido un
web de comercio bien montado. Inclusive para las compras de informática da
miedo (listan por marca en vez de productos… como si todos supiésemos de
memoria las cientos/miles de marcas que hay en informática). Evidentemente el
sistema que han montado, como dije antes sobre Windows NT4 y ASP (según
Netcraft), tiene algunos (o todos) los siguientes problemas

• Consultas a la base de datos mal diseñadas: tienen un problema
  grave de gestión de transacciones y consultas de productos. Porque no creo
  que tengan más de unas pocas decenas de miles de productos, y cualquier
  base de datos mediana daría buenos tiempos de respuesta.
• No pensado/diseñado para web: los tiempos de respuesta no son
  aceptables para web. Tampoco dan ningún feedback al usuario de que se está
  procesando algo. En su empeño de ocultar sus operaciones en el navegador
  (con JavaScript y frames), se han olvidado del usuario.
• Mal escalado: seguramente es el mayor problema. Tendrán un (unos?)
  ordenadores, que junto con la tecnología que usan de ASP (y ¿ODBC? ¿ADO?)
  no son
  capaces de generar las páginas con tiempos razonables. Y es muy curioso,
  porque empresas pequeñas, con mucho menor presupuesto que El Corte Inglés,
  están soportando mucho más tráfico y consultas a bases de datos. Léase Slashdot,
  PHP-Nuke, Barrapunto,
  que no usan ningún tipo de tecnología de cache de páginas para
  descargar al servidor de base de datos.

Soluciones
En pleno siglo 21, ya hay muchas soluciones posibles (y libres y/o gratuitas):

Balanceo de cargas: se trata de descargar los servidores, pueden ser
servidores web, a los que se descargan balanceando la carga entre varios
servidores mediante DNS round-robin o redirectors, o servidores de base de
datos, para los cual es mejor replicarlas o directamente distribuirlas.

Replicación de base de datos: es una técnica muy común y sencilla, y
muy usada en MySQL. Inclusive no hay que hacer prácticamente ningún cambio
en los programas, sólo escoger un back-end de una lista. Para las
actualizaciones se puede usar sólo uno de los servidores o usar técnicas
de replicación bi-direccional (soportadas por MySQL).

Y por supuesto, yo les recomendaría que miren algo de Apache y PHP o JSP,
porque evidentemente la solución, propietaria, que tienen ahora les funciona de
pena.
Larga vida al Apache, PHP y MySQL 😉

—

Ricardo Galli

http://m3d.uib.es/~gallir/

Este post ha sido traido de forma automatica desde https://web.archive.org/web/20140625063149/http:/bulma.net/body.phtml?nIdNoticia=685 por un robot nigromante, si crees que puede mejorarse, por favor, contactanos.