El articulo está basado en un estudio de CA sobre el “Índice de estrés en el uso de aplicaciones web”. Porque sí, usar aplicaciones web -ojo respecto a la sutil diferencia con páginas web- produce estrés en los usuarios y nosotros, los malvados informáticos, yéndonos a dormir por las noches sin cargo de conciencia. Si ya el enfoque del estudio me puso en alerta, leer una reseña sobre la opinión de Kobi Korsah, director de Marketing de Productos de CA para la región EMEA, hizo que se dispararan todas las alarmas. Y es que, normalmente, poner a alguien de marketing a lidiar con técnica pura y dura es igual que poner a un mandril en celo a cuidar de tus hijos pequeños: puede salir bien, pero de casualidad.

El bueno de Kobi y su estudio nos comentan que el 73% de los trabajadores ahora dependen más de las aplicaciones web que hace dos años y casi todos los encuestados (un 97%) no podrían hacer su trabajo diario sin ellas. Bien, esto es bueno, sobre todo para los que programan aplicaciones web como es mi caso, pero ¿de verdad hacía falta encargar un estudio para saber esto? No soy un gurú, pero hace años que yo y cualquiera que esté en la industria del desarrollo de software sabe que todo tiende al mundo web. ¿Porque es más bonito? No. ¿Porque es más fácil de desarrollar? No. ¿Porque es más rápido? No, ¡pardiez no! Porque te permite acceder a tu aplicación desde cualquier sitio del mundo, hasta desde el teléfono de tu abuela y porque eso de instalar una aplicación en 300 ordenadores de una empresa y, sobre todo, mantenerla, suena un poco a Los Picapiedra ¿no?

Ahora podríamos entrar en el debate de ¿qué es rápido y qué es lento? ¿Es lento un proceso que te calcule los seguros sociales de 40 empleados y te genere un fichero para enviar a la Seguridad Social, un PDF de resumen y te muestre una traza por pantalla con todos los detalles del cálculo en menos de 5 segundos?  Algunos dirán que sí, otros dirán que no. Entre los usuarios de Kobi, por ejemplo, el 46% espera que la web le responda en menos de 10 segundos y, cito textualmente “a los 20 segundos, el 72% ha agotado la paciencia y ha pasado a otra web, y al minuto, el 90% de las personas se ha ido a otro sitio web“. Hombre… a lo mejor yo soy muy impaciente pero, en un minuto no me he ido a otro sitio web ¡me he ido a por un café corporativo y he vuelto!

Bueno, parece que entonces nuestro limite está en los 10 segundos y que todo lo que esté por debajo de ese tiempo de respuesta es rápido ¿no? Pues ni de coña. Una vez más, el estudio le ha fallado a Kobi y sus muchachos. Si yo le presento algo a mi jefe con un tiempo de respuesta medio, petición a petición, de 10 segundos; podría ver como en menos de esos 10 segundos le empieza a cambiar la cara hasta convertirse en algo parecido a esto:

Mi jefe, después de esperar 10 segundos para que una aplicación web acabe el proceso de login

Llegamos pues a la conclusión de que rápido o lento son conceptos relativos y completamente subjetivos, difíciles, muy difíciles de medir. Lo que sí sabemos, sin tener que encargar ningún estudio es que una aplicación web siempre será, por definición, más lenta que una aplicación cliente-servidor donde sólo viajan los datos de información, no los de presentación, y muuucho más lenta que una aplicación telnet, que se ejecuta en remoto, en el propio servidor donde está alojada la aplicación. Si a eso le añades lo que los veteranos denominan “esas tonterías” (sic) de los desarrolladores de aplicaciones de hoy en día, como esa terrible obstinación por separar todo en n capas o poner la base de datos en una máquina distinta del servidor de aplicaciones y las CAGADAS PURAS Y DURAS, como la tendencia a la sobrearquitectura, los macguffins y a poner 3 millones de imágenes, iconos y flash porque “el cliente dice que queda mas bonito”… pues sí, las aplicaciones web son mas lentas. Lentas de narices. Pero es que es lo que hay, el jamón es jamón y el chóped, chóped. Lo que no puedes  pretender es comer jamón a precio de chopped. Porque -si amigos- al final como casi siempre, todo es cuestión de pasta.

ENSEÑAME LA PASTA I

Es normal que los usuarios quieran una aplicación rápida. Yo también la quiero pero, para conseguirla necesito dinero, más dinero. Dinero para pagar a mis desarrolladores durante el tiempo que tarden en depurar y optimizar la aplicación o dinero para poder contratar a más progamadores que consigan desarrollar al mismo ritmo que lo hacemos ahora pero, además, consiguiendo optimizar el funcionamiento. Ojo, no quiero que esto se vea como una total y absoluta orgía de autocomplaciencia, pero, es cuestión de hacer autocrítica. Igual que reconozco haber encontrado auténticos TRUÑACOS en mi código y en el de mi equipo, como cosas que se hacen 2 o 3 veces sin saber porqué, también tengo que reconocer como me duele ver todos los días la caja sin abrir del Perfomasure que compramos hace dos años sin que nadie haya tenido tiempo de poder utilizarlo.

ENSEÑAME LA PASTA II

Gracias al informe de CA me entero de que mis pobres usuarios sufren de stress-web, provocado por mi inoperancia a la hora de desarrollar y, sobre todo, mi impotencia para cumplir sus expectativas. Y es que, parece ser que “cuando los clientes del sitio web se encuentran ante un problema o error, el 53% esperan que esté resuelto en 10 minutos; el 80% en una hora y el 99% esperan que esté resuelto en 24 horas. ¡Toma ya! ¡10 minutos!

A ver… no soy un genio de la gestión pero, para poder atender las incidencias en 10 minutos, o tengo a un desarrollador atado a una silla 24h, parado y quieto en plan bombero, listo para apagar un fuego cuando este se produzca o, no me salen las cuentas porque, si el mismo equipo de programación te arregla los errores sin haber completado el ciclo de desarrollo, ese ciclo se va a retrasar.

Cuando alguna vez alguien me pregunta si puedo garantizar la resolución de incidencias siempre les digo que SI pero, la sonrisa de satisfacción que ponen, se borra en cuanto les digo que le costaría unos 40.000 euros al año. Todo el mundo quiere el servicio pero nadie quiere pagarlo.

¿CONCLUSIONES?

Las aplicaciones web no son ni rápidas ni lentas. Las aplicaciones web son lo que son y es responsabilidad de todos que sean lo mas eficientes posibles; en primer lugar de los desarrolladores, que deberíamos demostrar un amor por el trabajo y un orgullo profesional que nos empujara a crear el mejor código posible mas allá de las dificultades; en segundo lugar, los gestores, que debemos obtener los recursos necesarios -técnicos, tiempo, dinero- para poder garantizar la calidad deseada; y, en tercer lugar, los usuarios, que deberían mostrar el interés apropiado por lo que son sus verdaderas herramientas de trabajo, en vez de limitarse a aprender lo justito para ir tirando y descolgar el teléfono de soporte y preguntar que hacer en cuanto les salé una botonera de Aceptar/Cancelar. No sé en que grupo estas tú pero, seguro que todos podemos conseguir que nuestras aplicaciones web sean, sino mas rápidas, si mejores.

Stickam

No es el primer servicio de streaming ni el mas conocido, incluso tenemos posibilidades locales mas que interesantes, como lo que ofrecen los chicos de StreamES, pero StreamAPI me ha gustado especialmente por varios motivos:

• Es barato, muy barato, y tienes la posibilidad de calcular el coste de servicio de forma sencilla antes incluso de evaluar el producto.
• Funciona como marca blanca y, de cara a los usuarios, ellos no existen
• Es tecnológicamente neutro, funciona con cualquier tipo de lenguaje de programación en servidor
• Su web es sencilla y esta perfectamente estructurada
• Tienen toneladas de documentación sobre su producto
• Proporciona un montón de estadísticas e informes sobre el streaming (de esas que les encantan a los jefes)
• Soporta alta definición
• Esta basado en una plataforma probada, robusta y segura.

Aunque a veces los informáticos no consigamos ver la conexión entre la tecnología y su aplicación en el mundo real, el hecho de trabajar en un grupo empresarial que crea y gestiona multitud de eventos públicos facilita bastante poder comprender las posibilidades del streaming.

Imaginemos que organizamos un evento publicitario, una fiesta -por ejemplo- y. como es normal, queremos obtener el mayor rendimiento de la misma, el mayor retorno de inversión. Hasta ahora, solo los asistentes a la misma recibían el impacto publicitario y el departamento de marketing hacia todo lo posible porque este impacto se multiplicara facilitando la aparición del evento en los medios pero, ¿y si tuviéramos vídeos del evento a disposición del publico y dichos medios de comunicación?. Imaginar que celebramos una fiesta y que los asistentes al evento pudieran decirle a sus amigos “búscame en el vídeo X”.

Algún gurú pensará “para eso ya tengo a youTube” y si, es cierto, puesto que youTube no es ni mas ni menos que un tipo de streaming pero ¿y si quisiéramos retransmitir nuestro evento en vivo? ¿y si quisiéramos retransmitirlo con mayor calidad que la pésima calidad estándar de youTube? ¿Y si quieres tener control sobre el streaming de tu video? ¿durante que horas quieres que sea visible y porque? ¿y si no quieres que nadie incruste publicidad externa, incuso de un competidor? ¿y si quieres empotrarlo en tu web mas allá que como la ventana típica de youtube?

Bueno, parece que youTube podría llegar a quedarse corto para todas las posibilidades de explotación de nuestro evento.

Por otro lado, hay mucho mas casos de posibilidades de uso para el streaming corporativo, desde la posibilidad de grabar e impartir formación online y bajo demanda a poder difundir en directo y a todos los empleados un comunicado como, por ejemplo, la felicitación de navidad del Presidente de nuestra compañía.

Con StreamAPI podemos aprovechar todas estas posibilidades de una forma barata y no intrusiva para nuestra web. Una herramienta mas para construir la web que todos queremos y nuestros clientes o usuarios necesitan. Bienvenidos.