Es día del amor y la amistad poco antes de la una de la mañana.
El dia de ayer, 13 me movi de un lado de la ciudad a otro. Primero para ver un cliente. Luego para recoger una documentacion para notario. Luego Inbursa a recoger los numeros confidenciales de la tarjeta de la empresa.
Después ir a la oficina, revisar que un proveedor/competidor de un cliente se esta haciendo tonto, y avisarle al cliente. Ya perdio 3 de 5 sitios web, a este paso pronto tengo los otros dos. Luego casa. Cotizar cambio de tickets, mandar correo a notario. Hablar con la gente de la sucursal que va a abrir en bajio la empresa que fundé en noviembre. Revisar estabilidad del cluster de clientes web y los respaldos previos a la actualización de Centos.
Casi es hora de dormir.
Me encuentro por una parte con sueño y por otra tengo en mi mente frameworks de java que tiene otro cliente. Es una sensación desagradable encontrar en tu mente lineas de node.js o jquery, cuando lo que deberías tener son detalles de una S3 para reparar las réplicas de archivo de un cliente que necesita alta disponiblidad y servir cinco imagenes de 400 mb a 300 personas. Y por otra parte soñar con interfaces que dan vista pero no funcionalidad, no es buena señal. Con un poco de suerte regresa aquella serie de sueños sobre YUI que tuve en el 2007 y que me llevaron a resolver de manera extraña el asunto de Monterrey y que tanto les gustó a los clientes de Monterrey. Pero soñar con node.js o jquery no es un sueño compatible con sistemas de bajo CPU y menos si usan explorer. Meter node.js cuando las personas no usan firefox siquiera no tiene caso, menos si usan explorer 6, y por seguridad resulta mejor en todo caso usar XML-RPC sea el browser que sea. Unos 20 dias mas y habré eliminado el node.js y estará en YUI bajo XML-RPC.
En cuanto al problema de los ISOS con las campañas publicitarias del otro cliente, como esta va a ser una necesidad «estable», Es muy probable que tenga que seguir el camino que encontre mas o menos cuando compre el disco duro, a traves del sistema cloud de un competidor de amazon, porque mediatemple y cloudflare son literalmente por un lado tomadura de pelo, y por otro placebo.
No se trata de un aviso de «el sitio esta fuera del aire», sino poder servir el mismo ISO desde cinco subredes clase a (supongo que el que firmó el contrato de disponibilidad se debe estar dando topes con la pared, y mas el que pensó que en México no se podía hacer eso, la llamada de la semana pasada para saber como lo estábamos haciendo fue muy buena), y lo malo es que aunque ya funciona que el ISO cambia cada 64 a 72 horas, cada dos dis y medio hay que subir muchísima información al bucket. Si lo cambio de proveedor al que estoy pensando quizá me pueda evitar el que el cliente use cyberduck y automatizarlo.
Pero sigo levantado porque tengo que estar a las cinco y media de la mañana, en cuatro horas, revisando que le paso al sistema SCADA de monitoreo del cliente principal. Estoy casi seguro que la interface que produce los xml por parte del distribuidor en mexico, esta detenido en el ciclo y no se si lo pueda arreglar desde teamviewer por la inestabilidad de ese server. Lo que me sigue sacando de onda es que mi proceso corre dos capas DESPUES del probable error, y que hay otra capa abajo del SCADA. Se supone que el que carga el SCADA crea un txt que el SCADA procesa y regresa un xml dando los tiempos y hashes. Luego se supone que ese dato es movido por un sistema legacy a otro server. Ese server que recibe tiene corriendo un script de bash mio, que jala un gem de ruby y despues a un php, para guardar en base de datos del sitio de cliente un pdf consolidado por hora,
El reporte de la falla lo dieron a las 18 y es… «no esta el reporte consolidado desde las doce», pero lo mas seguro es que se refiera a que no hay dato que consolidar por una falla de los pasos anteriores. Y como todos son intermediarios, menos el legacy interno , no me queda de otra que resignarme y cobrar porque la empresa detecte donde fue el fallo.
Al momento que yo recuerde, desde abril del año pasado han sido unos 10 a 20 consolidados que se han trabado y la única vez que el proceso falló de mi lado fue porque el ruby tronó porque el xml cambió de formato XSD al cambiar el firmware de una linea de producción y que nadie me avisó.