¡Hola!
Me cuelo de nuevo en el blog para contaros la experiencia que hemos tenido (muy satisfactoria) haciendo un proyecto de los que más nos molan y mejor se nos dan: un desarrollo web a medida.
Este trabajo ha tenido un poquito de todo:
- Un poquito de servidores.
- Otro tanto de programación a medida.
- Y todo combinado con buenas dotes de diseño, usabilidad…
¿El cliente? La Asociación Cultural y Deportiva (en adelante ACS) del Liceo Francés de Madrid (¡ahí es ná!).
¡Vamos allá!
¿De qué hablamos hoy?
Situación inicial y punto de partida
La ACS se puso en contacto con Ensalza por un contacto de un contacto de un contacto de un contacto con quien habíamos trabajado hace años.
Empiezo por este punto para decir un: olé equipo Ensalza, que pasan los años y seguimos estando en la mente de antiguos clientes, y eso es síntoma de un trabajo bien hecho. ¡Grande equipo! Ahora, dejando de mirarnos el ombligo, vamos a ver qué nos comenta la ACS.
El cliente viene a Ensalza con una página web en la que los padres de los alumnos del Liceo se registran CADA AÑO para solicitar plaza en las actividades extraescolares de sus hijos. ¡OJO! …se registran cada año… ¿Qué raro, no?, ¿por qué no guardar los datos de los padres de un año para otro? Por lo que descubrimos después lo hacían así por un problema con los datos. Pero con planificación y análisis previo era algo que podía salvarse.
La web estaba formada por dos partes, que además estaban en dos dominios separados:
- Una página web informativa para los padres sobre un dominio .net (no tengo todavía hoy claro dónde estaba hospedado).
- Otra parte de administración que incluía el área privada de padres (en este caso, hospedado sobre un servidor virtual con Windows 2000 y una base de datos SQL Server que era accesible desde otro dominio .org).
- Como extra, contaban con una página web ‘publicitaria’, montada sobre Wix, donde se podían consultar los detalles de las actividades.
Personalmente, me impactó que hubiera tantas URLs distintas entorno al mismo concepto y aunque mi primera idea fue unificarlo todo sobre el mismo dominio con subdominios, teníamos que analizar bien todo y reorganizarlo.
Sí queridos, aquí había tela que cortar y un desarrollo web a medida se empezaba a cocinar
Al entrar en la herramienta de administración observé una aplicación web con cierto abandono que, aunque funcionaba bien, daba un aspecto algo preocupante para ponerlo delante de los padres, que al fin y al cabo son los “clientes” de la asociación.
A decir verdad, es habitual encontrarse con sistemas de este tipo hoy en día: el paso del tiempo y evolución en las tecnologías y programación y el hecho de haber tenido distintos equipos de trabajo hacían de la aplicación web de la ACS una especie de Frankenstein parcheado.
Con todo esto nos ponemos manos a la obra:
- Preparamos un listado de tablas que maneja el sistema (alumnos, padres, actividades, horarios…)
- Elaboramos un listado de informes y cometido de cada uno de ellos para entender las necesidades y elaborar los nuevos informes sin perder funcionalidades.
La idea aquí era elaborar esta lista “tal como nosotros lo vemos y entendemos” para que nos dieran el enfoque “tal como ellos lo ven y lo necesitan”. Con esto lograríamos entender sus necesidades los posibles fallos que se habían estado dando en el sistema.
Y ahora sí, cogimos todo esto con una buena dosis de ilusión y ganas de currar para irnos a la primera reunión de toma de requisitos con el cliente.
¿Qué requisitos pedía el cliente?
Los requisitos que pedía el cliente no eran otros que rehacer el sistema pero con una cara más actual y fresca, efectiva y cómodo de utilizar. Veamos algunos de los aspectos en los que se hizo especial hincapié:
- El TPV debía funcionar. Nos sorprendió que esto fuera un requisito indispensable cuando dábamos por hecho que el TPV tenía que funcionar. Los TPVs no suelen fallar a no ser que haya algo excepcional o algún problema con el banco.
- Debía quedar registrado en el sistema la actividad de cada usuario para poder tener un control de lo hace cada uno en el backoffice. Tendríamos que guardar log por usuario.
- Se solicitó que los avisos por email a los proveedores cuando los padres inscriben a los alumnos llegasen solamente cuando se produjera un cambio. Básicamente avisar solo de lo que toca a quien toca y cuando toca.
- En definitiva, querían su aplicación FUN CIO NA SE y además fuera un poco más agradable a la vista.
En TODAS las tomas de requisitos aparecen nuevos entornos, como por arte de magia
Además, en este momento con el cliente apareció por arte de magia una nueva base de datos, esta vez en Access, cuyo cometido era hacer de interfaz gráfica para el administrador, conectándose al SQL server en el que corría la aplicación web para administrar ciertos parámetros. No se me habría ocurrido usar Access como interfaz de administración de otra base de datos. Yo no lo habría hecho así, pero como digo siempre… así estaba y llevaba funcionando años, así que no tengo nada que decir.
Propuesta Ensalza: desarrollo web a medida
Llega la hora de dar nuestro toque y aportar al cliente todas las ideas para mejorar los procesos de trabajo gracias a nuestra experiencia en otros proyectos.
¿Qué pensamos hacer para organizar este desarrollo web a medida? Lo primero, había que cambiar todo el sistema y montar uno nuevo, aprovechando la experiencia de las versiones anteriores y conociendo las necesidades actuales.
La plataforma de desarrollo: un entorno mixto con WordPress
Apoyándonos en la versatilidad que tiene WordPress planteamos una solución mixta, usando WordPress y Kematik (un framework PHP desarrollado al 100% por Ensalza) para este desarrollo web a medida.
Kematik sería el encargado de gestionar la base de datos desde donde ellos manejarían toda la información tanto del día (solicitudes, reservas, pagos, etc) como configuraciones más generales (horarios, precios, actividades). Además, se controlaría desde aquí también todo el motor de informes para manejar los datos de forma global.
WordPress, por su parte, se encargaría del frontend para la parte informativa de la web. Y además serviría de soporte para el área de padres, todo sobre un único dominio pero con los dos sistemas trabajando juntos en paralelo.
Utilizando WordPress en la parte pública en sustitución de Wix ganaríamos mucho en imagen y diseño: podíamos dar nuestro toque y hacerlo todo mucho más administrable. Así, la ACS podría gestionar los contenidos ‘sin necesitarnos’ y, ya que estamos se crea un sitio responsive ‘del tirón’.
Acceso de padres al área de gestión de actividades
Los padres se conectarían al WordPress al área privada usando usuario y contraseña para gestionar las inscripciones de sus hijos.
Aquí dejamos a WordPress trabajar de manera nativa: si ellos ya manejan a la perfección la gestión de usuarios, contraseñas, accesos y el famoso ‘olvidé mi contraseña’ todo en el mismo módulo, ¿porqué perder el tiempo en desarrollarlo de nuevo?
Simplemente optamos por implementarlo en la parte pública, en lugar de mandar a los padres al backend de WordPress.
En este punto solo faltaría sincronizar los usuarios registrados en la base de datos del WordPress con la nuestra de Kematik; nada que no se pudiera resolver metiendo mano a los hooks de WordPress que se disparan al registrar o actualizar los usuarios. Así, con nuestras funciones a medida podíamos mantener al día los 2 entornos de usuarios.
El área de padres: conexión entre los dos sistemas
La parte privada de WordPress (donde los padres estarían gran parte del tiempo), tenía que estar toda desarrollada a medida sobre WordPress porque mostraría en pantalla datos de nuestra base de datos, y no hay plugin comercial que haga este tipo de virguerías fácilmente. La solución no podía ser otra: programar a medida.
Para implementar el área privada primero maquetamos unas cuantas pantallas sobre WordPress a modo de «esqueleto». Y después programamos lo necesario para que se comunicaran con nuestra base de datos.
¿Cómo resolvimos esto? Desarrollamos un plugin a medida para WordPress que sirviera de pasarela intermedia entre esas pantallas y nuestro entorno a través de shortcodes. De esta forma se mantendría la lógica entre ambos sistemas debidamente separada y aplicaríamos de manera elegante la separación de conceptos.
Todo ello sería un desarrollo PHP7 + MySQL por lo que lo montaríamos sobre un servidor Linux y podríamos tener todo junto sin ninguna dificultad.
Generación de informes a medida
Una de las áreas más importantes en desarrollos webs de este tipo (sistemas de gestión interna, intranets, etc) es el área de informes.
Gracias a Kematik implementaríamos la gran mayoría de informes de manera nativa, a través de listados filtrables aplicando las condiciones de visualización de que nos especificaron. Además, todos informes permitirían su exportación a Excel y PDF. Así, algunos de los perfiles que utilizan la herramienta pueden trabajar offline con parte de los datos del sistema.
Además, tuvimos que crear un par de informes más específicos en los que era necesario aplicar fórmulas y cálculos de costes, liquidaciones, etc.
En lugar de montar un informe plano en PDF a medida, montaríamos una Excel partiendo de una plantilla XLSX con formulas y rellenando los datos de las filas desde programación PHP.
Con esta solución lo que se descarga el usuario es un informe con los datos actualizados “al momento”, pero siendo un informe “vivo” porque las formulas en el Excel recalculan automáticamente los valores. De esta forma el usuario puede trabajar con el informe calculando sumatorios adicionales, modificando algunos valores a mano o filtrando y agrupando a su gusto. Es decir el usuario tiene una herramienta adicional de trabajo más allá de un mero informe plano.
Importación de datos en Excel y registro de cambios
Para poder comunicar el sistema de la ACS con el del colegio Liceo Francés y el de otros proveedores, implementamos sistemas de carga automatizadas desde Excel para la importación o actualización de los alumnos y sus cursos.
Ellos aportan una hoja Excel con un formato específico y nuestro sistema lo importa incorporando los datos nuevos a la base de datos.
Además, aportamos un extra de seguridad de los datos: almacenamos un log filtrable para ver todo lo que ocurre en el sistema con cada elemento de la base de datos; registro de cada usuario, IP, fechas…
Implementando un registro de movimientos es mucho más fácil localizar errores y encontrar respuestas cuando algo no cuadre.
Envío de e-mails automatizados
Esta es otra de las soluciones de las que, os tengo que confesar, nos sentimos más orgullosos.
Implementamos un sistema de cola de envíos de e-mails automatizados que funciona francamente bien y evita muchos dolores de cabeza.
Cuando el sistema necesita enviar un email, no conecta directamente con el servidor SMTP para enviarlo como sería habitual. Si en un momento dado la conectividad entre ambas plataformas está rota o el servidor SMTP no está disponible el correo quedaría sin enviarse.
Para evitarlo, el sistema de cola de correos va almacenando todos los emails que quiere enviar, incluso estableciendo una fecha y hora concretas para que se envíen en el futuro. Entonces, mediante un proceso cron que se ejecuta todos los minutos se van procesando los correos y se va van lanzando poco a poco. Si se produce un problema, el correo sigue encolado a la espera de reintentarlo en el futuro.
Gracias a esta cola de correo se puede ver un listado todo lo que manda, cuándo se manda y no perder ni un solo envío.
Madre mía qué chorizo llevo ya… Pero es que cuando hay que ponerse serio y explicar cómo nos organizamos…
Puesta en producción
Una vez desarrolladas todas las herramientas, pusimos en marcha el servidor y se subieron ambos proyectos: Kematik y WordPress.
A veces, las fechas de puesta en producción no son negociables
He de reconocer que para mi gusto se implantó demasiado rápido porque había algunas áreas que no habían pasado las pruebas y tests (de funcionalidad y carga) que eran necesarias, pero los cursos en los colegios “empiezan cuando empiezan” y la fecha de arranque del proyecto tuvo que acelerarse para no perder un año completo.
Lo cierto es que fueron un par de meses algo densos de trabajo porque se generaba gran cantidad de datos al día de una forma muy rápida y cundía el pánico fácilmente cuando hablábamos de que un padre no puede pagar sus actividades o de que no cuadraban el nº de inscripciones con las plazas disponibles.
Cosas en apariencia graves, pero en general y echando horas, todo quedó resuelto y todo tuvo solución.
Los disturbios estuvieron controlados y no tuvimos que lamentar daños
Al final con empeño todo salió adelante y quedó fino.
Dificultades por el camino que pudimos superar
A pesar de que parecía que teníamos todo bajo control no contamos con una cosa: la oleada de padres entrando todos a la vez el mismo día a la misma hora.
El día que se abrieron las plazas la avalancha de padres fue brutal. Algunas actividades tienen las plazas contadas y se asignan según registro y llegada. Por tanto, el volumen de tráfico fue altísimo y toda la avalancha estaba concentrada en unas horas a primera hora del día, “aún con las sabanas marcadas en la cara”.
En este momento sí que recuerdo haberlo pasado mal por no haber dimensionado bien la envergadura de este pico de tráfico. Contaba con ello, pero no imaginaba que iba a ser tal.
Aunque habíamos estimado la carga de años anteriores, no contábamos con el factor boca a boca para este año. Parece que los padres, conscientes de que la plataforma no iba fina en años anteriores, optaban por hacer la contratación por otras vías.
Pero este año no.
Había una nueva plataforma y todos querían probarla (y que funcionara)
El problema de los plugins de caché y las llamadas AJAX en WordPress.
Resultó que los plugins de caché de WordPress no se podían activar en todo su esplendor porque cada padre debía ver los datos de sus hijos. Si se cachean estas páginas ‘todos verían al mismo hijo’ y los mismos horarios disponibles.
A veces, hay datos «vivos» que no pueden estar cacheados
Son páginas 100% dinámicas con acceso a base de datos, por lo que no se podían cachear y, con semejante avalancha, el servidor colapsó y quedó frito un par de horas.
Plan de emergencia: replanteamos en tiempo record un rediseño de la estructura de la parte de padres para que se accediese a las partes con datos dinámicos mediante Ajax en JSON, aislando estas pantallas de la carga de WordPress. Con esta estructura, ahora sí, pudimos activar las mejores cachés para WordPress que este mundo nos ha dado.
Una vez solucionadas las partes dinámicas, trabajamos la parte de caché de WordPress de nuevo con WP-Rocket, el plugin del que ya os hablamos hace unos meses cuando os contamos lo rápido que carga nuestra Divi.
Aún así, en momentos de carga del servidor las llamadas por AJAX de WordPress tendían a hacerse más y más lentas (con picos de 2s para resolver las peticiones).
Llegado ese punto decidimos reprogramar también las peticiones AJAX nativas en WordPress por otra petición simplificada en la que solo cargáramos lo esencial (en nuestro caso, el soporte para shortcodes y las funciones de usuarios registrados)
¿El resultado? Las peticiones que llegaban a 2 segundos de carga ahora no pasaban de 150-200ms.
Divide y vencerás
Ahora sí, con las cachés de WordPress activadas empezamos a fluir y por lo menos el servidor, aunque sería algo pesado y lento, no colapsaba, permitía entrar y hacer las inscripciones y los pagos.
La solución final vino cuando decidimos separar en dos servidores distintos la base de datos del servicio web. De esta manera ambos servicios disponen de todos los recursos de su servidor y ambos resuelven con mayor eficiencia su trabajo y están optimizados cada uno para su labor.
A partir de este momento todo funcionó con normalidad y con tiempos de respuesta realmente bajos, incluso en momentos de gran afluencia.
Resultado final
Mientras lees esto el personal de la ACS se autogestiona su web sin necesitarnos apenas; Salvo algún ticket con alguna incidencia o petición puntual, son 100% autosuficientes.
Estamos muy contentos con el desarrollo de este proyecto y, pecaremos al decirlo, pero creemos que la ACS y el Liceo Francés de Madrid también lo están.
Como decía al principio del post (hace ya mucho mucho tiempo en una línea muy muy lejana) este es uno de los proyectos más interesantes que ha pasado por Ensalza en los últimos años: WordPress, base de datos, creación de informes a medida, importaciones, exportaciones, plugins intermedios, pasarela de pago… ¡Completito señores!
Y este ha sido el motivo por el que he decidido animarme a escribir este post que, ni va a posicionar, ni va a resultar interesante para muchas personas, ni es ligerito de leer, pero cuando uno termina trabajos de este tipo a veces tiene la necesidad de contarle al mundo lo que ha hecho.
Como dije en mi anterior post: Los programadores también somos personas y creo que en artículos como este puede quedar un poco más clara esa afirmación.
Si no te ha aburrido mucho el post y quieres comentarme / criticarme / sugerirme lo que sea, ¡adelante!, te responderé encantado 😉
