En las reuniones que hago desde 1992, de repente sale el tema de los alimentos.
En la segunda reunión de este mes comimos roast beef, sopa de codito con jamón y crema, papas con chorizo, alambre de res, arroz y no me acuerdo qué más.
Tiene sus razones.
Hay un lugar donde como regularmente, y el menú de hoy tenía como opción sopa de hueso. Como tienen una pollería, posiblemente era sopa de hueso de pollo. He comido también sopa de hueso de res en otras ocasiones.
Alto nivel de minerales, y no es caro. Algo parecido a lo que pasa con lugares de caldos de gallina, que a veces lo más nutritivo es el caldo.
Otra cosa que se come en mi casa es hígado de res; hasta nos hace precio el vendedor del mercado por ser clientes frecuentes.
Su principal ventaja no es, como dicen muchos, la B12. Para mí es la combinación de zinc, B6 y PABA (ácido paraminobenzoico).
Y no es caro.
Uno se queda pensando en que, como digo desde hace más de treinta años, tienes que comer proporcional a lo que haces. En Guadalajara, de joven, eran dos hamburguesas Búfalo grandes con mostaza a la miel. En mis años trabajando en Polanco, milanesa o pechuga Cordon Bleu. Los últimos años, por el cliente de los monolitos y no haber nada cerca, estaban mis proteínas entre tacos de arrachera, birria cerca de mi casa o hamburguesas caseras.
Por cierto, hoy me enteré por dos fuentes que parece que renunció una persona clave en el cliente de los monolitos, el que quedaba de los dos jefes de departamento oficiales. Todo por un asunto que supongo era la presión sobre las analistas que se quedaron después de la salida de la dama Margarita y ya sin mis sistemas.
Ya en 2022 la migración era difícil incluso con cuatro analistas capacitados; en 2026, con solo tres personas y procesos que regresaron a Excel, la situación es crítica. Una de ellas absorbió funciones que antes hacía otro sistema (Sistema Uno), ahora operadas manualmente, porque como no funcionaba en su propio servidor por falta de permisos y librerías de PHP, estaba alojado en un servidor que no me pagaron y que por lo mismo desapareció.
Ese sistema Uno generaba reportes de bonos para unas 15,000 personas, dos veces al año, con dos páginas cada uno. La base eran archivos Excel no uniformes entre las 30 sucursales, lo que resultaba en aproximadamente 60 archivos distintos por ciclo y unos 60 reportes sobre un total de 25,000 hojas estimadas antes de correcciones. No creo que pueda resolverse con inteligencia artificial tipo LLM, por el desastre de las entradas semestrales.
La analista me daba los excel, y me pedía el reporte.
Estamos hablando de un volumen enorme de datos desordenados, además de la tercera parte del trabajo que antes hacían cuatro personas. En este escenario, la migración no es solo técnica: es un riesgo operativo y fiscal que excede la capacidad de muchos equipos.
El formato físico del reporte cambia cada año y hay que hacer ajustes en código nada fáciles para márgenes, cabeceras y pie de página. Los cambios de proporciones en el papel requieren validación humana que implica luego ajustar todas las sucursales una por una. Abril no va a ser bonito. Y además hay casos extremos como que te salga alguien que en vez de siete renglones de datos tiene 42.
Además está el manejo de memoria. Sé cómo optimizar la memoria, pero ese sistema no puedes pasarlo a otro motor de PDF como fPDF, que tampoco corre, porque los cambios del reporte te tardarían una semana por el multicell. Aquí nos daban el nuevo formato en abril y el mismo día las diez o doce primeras sucursales querían el reporte ya.
No es solo un problema de migrar a PHP 8.x: el cuello de botella de ese sistema, que solo usaba una persona (yo) para generar los reportes, está en la memoria de mPDF y en la variabilidad de datos de entrada. Hay que normalizar y checar casos límite.
El otro sistema (Sistema dos), el principal, quedó inoperante por la falta de servidores secundarios (sistemas tres y cuatro), y migrarlo de 7.x a PHP 8.x excede la capacidad de muchos programadores, porque el nuevo motor php 8.x convierte warnings en errores fatales y cambia el manejo de cadenas y valores nulos. mPDF por si mismo es una bestia completamente diferente entre php7.x y php 8.x . El problema se agrava con librerías como mPDF, donde la generación de documentos depende de cadenas Unicode y fuentes embebidas: lo que antes era un warning silencioso ahora se convierte en un error fatal que detiene la ejecución. Como sus servidores están configurados para ocultar warnings, los problemas se vuelven invisibles hasta que rompen la generación de PDFs o reportes. En este escenario, la migración no es solo técnica: es un riesgo operativo no solo por el manejo de cadenas Unicode y de la librería de PDF, sino por las fuentes embebidas y su red inestable.
Ese sistema dos Literalmente era hacer malabares por lo que no estaba instalado y la importancia de la letra Ñ en todo el proceso. Además no podía quitar la Ñ por el histórico de los años anteriores y porque era parte integral del diagnóstico de los problemas. Yo, sabiendo lo que estaba haciendo, lo pasé en unas doce horas a un servidor mío de PHP 8.x para pruebas, pero es misión imposible hacerlo si no se controla todo en el servidor destino.
Literalmente creo que se van a quedar años con PHP 7.x porque migrarlo no lo puede hacer una LLM que espera un servidor estándar y que no puede leer a la vez los reportes históricos ni los casos de operación diaria. Y el que se fue era el jefe de esos analistas.
Así que el sistema principal (sistema dos)tiene problemas similares tanto por Unicode como porque no tiene reversa. Lo pasas a PHP 8.x y regresarlo a 7.x requiere mucho más de lo que muchos pueden hacer. El jQuery original que yo no hice pero simplifiqué truena en PHP 8.x y no dejé mi versión nueva (no compatible con 7.x porque además no estaban las librerías estándar de PHP 7.x), así que el punto principal de las analistas no funcionaría incluso antes de llegar a reportes.
Así que para empezar no solo es el sistema, sino el túnel de datos que tuve que hacer porque por el servidor todos los procesos estándar fallaban. Me tomó doce horas y eso en un servidor limpio que funcionara solo esa parte.
Y eso no arregla el otro problema. Su red No hay composer, permisos de root y la red muchas veces no encuentra google.com como dominio existente. Literalmente yo trabajaba por VPN a mi casa, y desde las sucursales veían el sistema pero desde dentro no, por la mala configuración de la red. Literalmente los analistas trabajaban más rápido en su casa que en las oficinas.
Y yo me siento bien comiendo avena y carne. Al rato, para complementar, probablemente cene en casa unas sincronizadas con jamón.
También tengo pendiente hacer o comer sopa turca.