Este fin de semana me la pasé con gripa, enviando correos y definiendo los detalles de la nueva razón social.

El sábado recibí un correo de un cliente de desarrollo que previamente me había pedido un sistema que creara códigos de barras en pdf enviados a correo. El problema era que yo usé el estandard code 39 y el quería usar el code 32, que fue un estandard usado por farmacias italianas, creo. A final de cuentas me tomó dos horas presentar code 128, y también lo podía leer.

Creo que ese software tiene buen futuro, pero lo que no me esperaba es la actitud de la agencia de relaciones públicas de la automotriz que patrocina todo. Ni modo de esperar seis meses para algo urgente.

Por otra parte, creo que es el momento de empezar el conjunto de experimentos sobre grandes volumenes de datos, no por nube sino por cuestiones de extracción de datos para graficado. El problema que veo, es que en el lugar de comunicaciones via sat{elite manejaban solamente 12 gb de datos y eso daba problemas de respaldo por sus limitaciones.

Unos años antes (2001), con el volumen de datos de Clariant sobre el PH de la pintura de las revolvedoras, manejaba casi 20 gb diarios. Si bien ese proyecto por su definición presenta un detalle bidimensional o tridimensional cuando mucho, en una sola tabla, simular ese sistema no resulta práctico para generar ejemplos ( patito ) y detectar los problemas de respaldo masivos de datos ( ando pensando en un volumen estimado de 6 terabytes sobre doce tablas ), y como los discos de arriba de dos terabytes andan medio caros, creo que la prueba la debo hacer con algo que genere un volumen diario de unos 30 a 60 gb maximo, y manejar histórico para hacer un simulado de datos de ese volumen.

Para muestras específicas siempre puedo referirme al volumen de un día.

Creo que ya encontré un conjunto de datos disponible, que anda por ese volumen y se puede descargar por XML o JSON, además trae timestamp