Que no haya publicado más cosas hasta hoy, es sencillamente porque intento respetar la idea básica de este blog, que es una y muy sencilla, publicar únicamente cosas que creo me han sido útiles en mi trabajo, en mi vida "informática" y que quizás les puedan servir a otros compañeros, por eso, como la vida de un programador es programar cada día, en unas ocasiones mejor en otras peor, pero no siempre tenemos la suerte de desarrollar pequeñas joyas de código dignas de compartir o ni siquiera desarrollar, ir a buscar a google pequeñas joyas de código dignas de un buen copy/paste..... pues eso, que no siempre puedo escribir en el blog, porque buena parte de mi trabajo es mantener aplicaciones donde únicamente, al final, se precisan INSERT's, UPDATE's y DELETE's sobre la base de datos....jajajajajajajaja. Pero dos, tres, cuatro veces al año, estás metido en un proyecto nuevo y ahí sí, ahí podemos desarrollar (dentro de unos márgenes) toda nuestra capacidad e imaginación.
Este año, en mi empresa, tenemos muchos proyectos nuevos, cosa que después de unos años muy duros, la verdad es que se agradece, vamos, es como si hubiera entrado un bocanada de aire nuevo en el dpto. de informática. Algunos de estos proyectos son integrar varias pasarelas de pagos, actualizar la versión del sistema de business intelligence (inteligencia de negocio), remodelar el look & feel (lo que pintamos en el navegador....jajajajajajaja pero en el dpto. de Marketing lo llaman así.... jajajajajajajaja) de algunas webs que ya estaban bastante desfasadas, etc, etc, en definitiva, que nos vamos a divertir!!!!!, por supuesto, seguir dando mantenimiento a las aplicaciones que ya existen y de vez en cuando participar de forma intermitente en otros proyectos, que sin ser de mi departamento, le afectan en un 20, 25%.
Unos de esos proyecto de los que no es "mio" pero si que tengo que participar yo (me afecta en un 30% más o menos....jajajajajaja), es el famoso "desdoblamiento de la base de datos". Básicamente la historia comienza así. Me citan para una reunión con unas cuantas personas de la empresa, todas de informática y de distintos departamentos, desarrollo (el mio) y datacenter (sistemas) y en la charla, os la resumo, básicamente se me informa que por un problema de rendimiento, no de ahora, pero sí de futuro rendimiento de la base de datos actual, han decidido replicar cierta información a otra nueva base de datos, y que, yo estaba en esa reunión para darles soluciones a esta propuesta. Para que lo entendáis, la base de datos con la que yo trabajo, es una base de datos que únicamente se utilizaba para meter precios y que a través de nuestro B2B, B2C, Call Center, Integraciones XML y alguna cosas más, se consultaban y se hacían reservas, luego, todas esas reservas "viajaban" a los dos AS400 que teníamos y poco más. El año pasado, dejamos de trabajar con los AS y toda la gestión de la empresa se hace sobre "mi base de datos"....jajajajajajajaja. Como otro de los proyectos en los que estoy metido es el de las integraciones XML y para este proyecto, se espera un gran crecimiento, en base a esas estadísticas de crecimiento, la gente de sistemas dijo que no, que la base de datos actual, no iba a poder soportar la carga y que tendríamos que "desviar" las consultas gordas, las des disponibilidad y precio a otra base de datos y dejar la base de datos actual únicamente para grabar las reservas...... a lo que a mi respecta significa que, mi programa, tendría que consultar disponibilidad en una base de datos y grabar la reserva (si llega a grabarse) en otra, ufffff (sudores fríos.....).
Yo veo dos soluciones, la menos elegante, instalar un nuevo tomcat en el nuevo servidor de la nueva base de datos, desplegar mi aplicación en ese tomcat y nada más, simplemente decir a todos los clientes que a la hora de consultar precios ataquen a la url 1 y para grabar a la url 2..... cutre, pero funcionar, funcionará.... pero también presento otra más elegante, hacer que mi aplicación, sólo cambiando la configuración, para la consulta de precios se vaya a la base de datos nueva y para el resto de operaciones (login(), grabarReserva(), etc, etc.... ) se mantenga utilizando la que ya existe. Evidentemente yo les comento que aunque mi proyecto trabaja con Spring, Acegi, Ibatis, etc, etc... yo en la vida he tenido necesidad de tocar la configuración de base de datos, sí, aunque no lo creáis, tengo más cosas que hacer en el curro que estar mirando como se configura algo que nunca ha fallado y nunca he tenido necesidad de tocar!!!!....jajajajajaja les pido que me den un tiempo prudencial para ver como está montado el cotarro y ver si soy capaz de conseguir esto, es decir, una aplicación, dos bases de datos!!!!
Hasta hace relativamente poco tiempo, más o menos 2 años, no he tenido la necesidad de saber como como estaba montado mi proyecto, pero por necesidades de la empresa, me he tenido que meter a ello, siempre ayudándome de internet (en mi caso porque estaba más sólo que la una....), más de instinto que lamentablemente inteligencia (un día me gustaría hablar de instinto del programador....ajajajajajajajajaja). Claro, todo es ponerse, pero siempre pasa igual, ¿cuantos compañeros vuestros serían capaces de configurar Hibernate en el proyecto que trabajan? ¿cuantos cambiar la configuración para que acceda a un LDAP? por ejemplo, unos repondréis, todos!!!, tardarán lo que tarden en encontrar un manual en internet.....ajajajajajajaja eso, creo que, por experiencia es medianamente cierto!!!, otros respondereis que ¿para qué? más de la mitad de los programadores de un proyecto no necesitan saber eso... y también teneis parte de razón, pero el caso, que a mi me ha tocado, me ha tocado viajar a la entrañas de mi proyecto.
Termino, no os aburro más, en la segunda parte os explicaré técnicamente lo que he hecho y si al final, después de hacer las pruebas y todo ha funcionado realmente. Espero que esta introducción os haya gustado.Hasta la próxima!!!!
No hay comentarios:
Publicar un comentario