Lunes de junio

por

Son las 7.23 de la mañana. Como parte de las evaluaciones de tiempo que siempre me he hecho, tengo varias alarmas que me permiten evaluar mi puntualidad. Después de un evento de hace como año y medio, establecí alarmas para las 6.40, 7.23 y 8.00. La hora estándar de entrada para mí eran entonces las 7.23 en monolitos, aunque mi hora de entrada fueran las 8 o las 9.

En este momento está lloviendo, son las 7.36. Ayer dieron las calificaciones de dos materias, 10/10 nuevamente. Las analistas y otros van a trabajar bajo la lluvia. No está el café ni las galletas que yo llevaba. Así que como siempre no me hubiera pasado a mí por paraguas, y por ya estar en la oficina. En resumen porque peleo desde antes las batallas del futuro. Sin embargo, no puedes predecir la locura.

Hoy varias analistas de los monolitos, incluyendo la dama Margarita, se enfrentan a un sistema chocante. Excel. Por lo que se están impedidos de usar lo que yo implementé hace dos años. Sinceramente me acuerdo y me da un poco de no sé qué. Mi cabeza se mueve automáticamente por el recuerdo. Cambios simples como responsables de área deben sincronizarse en cinco documentos; yo los sincronicé a internet pero el internet se caía y el Excel de internet no podía leerse. Hay otros cambios en «períodos» como le llamábamos que son brutales, y a veces me los cambiaban tres veces en los mismos 15 días. Eso va a ser un desastre.

Lo que implementé hace dos años fue un sistema completo de PHP que reemplazaba el 60% de su trabajo final en Excel. Ya no lo usaban, solo como archivo personal. Ahora han retrocedido a hacerlo antes manualmente, con todos los problemas que eso conlleva. No se si en el pasado podían siquiera trabajar con el. A mi me costó unos siete dias para entender el proceso. Por ejemplo, cosas que entonces hacían en una semana yo lo bajé a cinco horas. A la dama Margarita y a su prima no les pagan todavía. Para ellas no hay otra oportunidad de un trabajo con ese sueldo. Van a aguantar mientras puedan, aunque no les paguen. Quieren hacerlas reventar y ellas manejan el 40% de una operación Especializada. Literalmente se capacitan en seis meses, y solo hay cinco personas con ese perfil a nivel nacional. y si no les pagan, todo lo que están haciendo además desde enero, es legalmente inválido.

Segun yo Los eventos del 3 de junio fueron por parte de mi jefa inmediata «a mal paso darle prisa», sentirse muy lista y una falta de táctica brutal. Así que me encuentro esperando que decidan otras personas qué hacer. No por mi jefa. Ella eligió algo que está entra la frontera de lo ilegal y lo estúpido. Las acciones de mi jefa ese día, con la que no cambié más de diez frases que no fueran buenos días en un año, hicieron retroceder esa mitad del área a como estaban tres años atrás, o peor. Al mismo tiempo tienen ellos vergüenza por lo que pasó y coraje porque tienen que hacerlo a mano. Así que me encuentro sabiendo desde antes de ese mismo momento que iban a tener presión lateral, de subordinados y de superiores. Yo me quité de en medio al ver el problema de debilidad política que tenían. Traté de ayudar y lo que hizo fue empeorarlo. Subió la presión de subordinados directos hacia ella y de los indirectos también, además de retrasar todo el proceso con el que evalúan a toda el área incluyéndola a ella.

Lo que hizo en este caso la jefa inmediata es irracional, ya escribiré de eso después. El principio básico es que no puede salir un derecho legal mayor de quien comete un delito. Es decir, una persona que amenaza a otro con un arma, y como resultado de su acción es arrestado o queda inválido o lo matan, no gana derechos por realizar el intento de asalto, los pierde. Lo normal es que el 40% de mis jefes a lo largo de los últimos 30 años se desaparecen y no hacen nada. Hablan cinco o seis frases por año es la norma, y prácticamente nadie los toma en cuenta. Otro ejemplo fuer cuando en 2011 en la empresa de satélite pusieron a una persona de guitarra eléctrica como superior mío y no duró el área ni seis meses cuando me cambié al cliente de la fábrica. (empresa ya desapareció)

En este caso mis observaciones y la última frase de mi jefa en un cumpleaños diciendo que no le han autorizado el jefe de departamento que falta. Eso para mí confirmó su debilidad política. Para fines prácticos he sido un jefe departamento fantasma estos tres años. Como siempre tengo filas o personas que me piden cosas operativas o consejos de sistemas o contables. Pero lo que hizo mi jefa fue transformar un problema manejable en uno mucho mayor, tanto interna como externamente.

Así que me encuentro aquí, sentado frente a mi computadora. Llevo una hora trabajando en lo del cliente de diciembre. Además de él tengo otro ingreso principal, una fábrica de comida a la que llamo «el cliente problemático» y no es la fábrica de galletas. El ingreso que recibo es más o menos el doble de las analistas con unas tres horas diarias de mi parte. Incluso en el plan más pesimista, la situación económica está resuelta.

Como resultado de las reuniones que hago desde 1992, llamadas normalmente las reuniones de los azulejos, porque llevan unos 25 años en ese restaurante, les comentaba a las personas que hay un sentimiento mezcla de resignación y lástima, que suele venir cuando uno ve a alguien hacer una estupidez. «Qué desperdicio». Sí, hay personas que toman decisiones con sus vidas que son un desperdicio. Hay señales de alerta temprana, donde debes como les comenté, o bajarte del coche o dar el volantazo. En este caso, la situación fue de parte de mi jefa dar un volantazo y acelerar a la vez, y yo me bajé. El resultado es obvio para ella y para su área. Para las analistas, solo pienso en «qué desperdicio». No tienen otro remedio. La jefa pudo haber actuado con honor pero eligió no hacerlo. ¿Es necesario decir más? Lo que hace a un jefe son muchas cosas, y entre otras, que la gente te ame, que esté dispuesta a luchar contigo y por tí. Ser Amable. En su caso, lo que hizo fue sabotear la moral de toda un área (que ya estaba mal desde un inicio), poner en situación mas absurda a dos analistas y la acción conmigo son otro caso clásico de Jenga Corporativo

Hace un momento una de las analistas puso un estado de whatsapp de «yo (corazón) empresa». Además de impuntual (8.12) No se da cuenta que no le pagan, y que solo se está consumiendo a si misma ? que es o que ve es como sentir el sabor de su propia sangre, consumiendo sus reservas emocionales y físicas? Que desperdicio.

Y todo se arregla empezando por cortesía y prudencia, y llegando a las 7.23. Las pequeñas disciplinas, los sistemas que uno construye para medir y evaluar, las alarmas que nos recuerdan quiénes queremos ser. Mientras afuera llueve y otros enfrentan las consecuencias de decisiones que no tomaron, uno puede reflexionar sobre la importancia de pelear las batallas del futuro desde antes, de tener el paraguas listo, de bajarse del coche cuando se ve venir la locura. Porque al final, no puedes controlar las decisiones irracionales de otros, pero sí puedes controlar las tuyas. Y a veces, la mejor decisión es simplemente llegar a tiempo, con cortesía y prudencia, a las 7.23.

Domingo en descanso

por

Hay personas muy vanidosas que se la pasan como Narciso viendo su reflejo o alabándose a si mismos. Otros insguros comparándose con los demás o huyendo de la realidad con amigos, fiestas. Hay mecanismos también que hablan de mantener la propia alma, o que buscan una validación que va desde la bruja de Blancanieves hasta mala suerte si rompes un espejo. Pero el espejo puede ser distorsionado o no existir. Tu vista puede ser mala. Lo que existe y no puedes modificar son el tiempo y la realidad presente.

Aunque te engañes, si, puedes cambiar al futuro, pero el presente ya es. Los errores del pasado no son muy arreglables.  Seguramente tienes buenas razones para hacer una estupidez. Y no solo pasa en uno; en el trabajo o escuela luego las figuras de autoridad no hacen ciertas cosas, pecan de pensamiento palabra u obra, principalmente por codicia. No buscan hacer un mundo mejor, y ser ecológicos, afectando lo mínimo el entorno. Se consideran depredadores y son parásitos.

La mayor parte de las personas son flojas o autodestructivas. Es muy raro encontrar gente buena o gente limpia. La mayoría de la gente es promedio, pero principalmente pierden el tiempo el 85% de las veces. Desde antes de los zombies tecnológicos. Y esto no es pesimismo, es la realidad. la mayoría de la gente negocia lo que no es negociable, son comerciantes aunque se digan a si mismos contadores, abogados. Como van a hacer un mundo mejor ?

Al final, sin darme cuenta, acabé encontrando una premisa tradicional del camino de Mitra, una de las vertientes del camino rojo. Cuando sabes lo que debes hacer la realidad es muy simple. Ser un poco estoico en el sentido de marco Aurelio y  similares, pero no estoico de papel, sino estoico práctico. Diría el Cihing el árbol permanece firme aunque esté solo. Llevo mucho tiempo sin estar solo, dentro de mi mente me guia además el principio de un mundo mejor.

El problema principal que he visto en estos «tiempos modernos» se da entre personas que están con desidia, o que se creen invencibles, la mayoría de la gente no tiene problema en lastimar a los demás a propósito si se benefician en algo. No lo hacen por un bien mayor sino por pura codicia y valorar únicamente su propio beneficio. Pueden justificar aberraciones como irse de vacaciones en navidad los directivos a Cancún y no pagar a los empleados (caso real 2000 aunque a mi si me pagaron), o como una persona que hace poco condicionaba el pago a cometer un delito. No hay justicia en ello, solo egoísmo disfrazado de normalidad. Y estupidez. Necesitas ponerle tiempo aire al teléfono. No puedes «robar» o mendigar wifi eternamente. Yo preferí tener una línea fija y cada 7 días poner tiempo aire. No uso planes porque prefiero gasto controlado, y empecé a usar el celular en la pandemia y no por gusto

El problema de no tener oficio ni beneficio se vuelve evidente cuando observas las trayectorias. Empecé a trabajar a los 19 y a los 20 ya había comprado mi primera casa, resultado de trabajar todo el tiempo y recuperar un dinero de una universidad que se pasó de lista. Como a los cuatro meses tuve que meterme un poco en las computadoras y aquí estoy 33 años programando. Ser hombre tiene sus ventajas y desventajas. Mi hija acaba de empezar a trabajar en supermercados, por indicación mía, y a sus 18 años evidentemente gana menos que yo en su momento. Una vez le dije a mi papá a los 19 cuando trató de regañarme por algo que hice: «No puedo tomar en serio lo que me dices. Tengo 19 años gano tres salarios mínimos y doy órdenes a 30 personas.» Pero era por la serie de decisiones que tomé, el ser hombre, y llenar una serie de necesidades que vi en ese momento y que me ganaron un ascenso en el mismo día que entré a trabajar. Mi hija, sinceramente no tiene oportunidad de ganar tres salarios mínimos en un año, pero tiene una ventaja. Como mujer, incluso si todo le va mal, puede perfectamente trabajar de cajera a los 50 en un negocio y si tiene casa, sobrevivir pase lo que pase. Ese es un oficio. El problema va entonces de personas que aunque tengan una carrera o maestrías, están en un lugar por contactos y estorbando. Y no tienen oficio y el beneficio lo buscan para ellas.

Tiempo, edad y sentido común. Me encontré muchos años pensando en actuar como alguien mayor unos por 10 a 15 años. La razón era simple. Nadie toma en serio a un joven de 17. Tenía que pensar como lo haría un joven de 25 centrado. Y la mayoría de las personas pierden el tiempo, así que tenía que actuar como ellos deberían de estar actuando a los 25. Resultado, me la pasé trabajando, pocas parejas sentimentales, pero no era solo como la historia de la hormiga y la cigarra. La razón es que hay procesos que toman tiempo y si no los empiezas, nunca pasan. Cuando partes un limón, se consume el material. Pero en el caso de una mujer necesita aproximadamente 36 a 40 semanas para que sea viable sin demasiados problemas. 28 semanas es casi seguro muerte de la madre o del hijo. Si estás grabando un disco o copiando un directorio, no puedes desconectar el USB. Simplemente es aún cuestión de espera. Una vez que ciertas cosas se inician no depende de uno, no es una partida de ajedrez donde le dices al contrario es tu turno y él lo sabe. Este es un juego contra el tiempo, y él ya se está moviendo.

Así que me encuentro sentado y pensando. Tengo que hacer una tarea de la licenciatura. Creo que me recibo en diez meses más o menos. No la necesito, es un plan de acción C. Tengo dinero en el banco, suficiente, y un ingreso seguro a pesar de los monolitos. El próximo 7 de julio, unos 15 días, probablemente recibo unos ocho meses de sueldo de mi hija sin problemas. Por el ingreso seguro, unos tres sueldos de mi hija. Del cliente de los monolitos y del posible nuevo cliente, hay más cosas en espera, que no dependen de mí y apresurarme no sirve de nada. Solo esperar con confianza. Y hacer otra cosa sería simplemente quitar el USB. Tengo planes de contingencia para después del 8 de julio, pero de momento hay cosas importantes que no son urgentes. Ni las puedo apresurar. Cualquier movimiento prematuro termina el proceso.

Y tengo que esperar principalmente porque este proceso constructivo toma tiempo, y no puedo prever quien de cinco o seis personas va a hacer algo irracional. Ni cuando.  Ya tengo forma de neutralizar cada acto irracional en que pude pensar de ellos. Varios ya están por escrito y en manos de las autoridades. Otros son planes de contingencia. la situación es algo así como saber que ya hiciste el examen de la materia y estás esperando que publiquen el resultado.

Y en vez de verme al espejo pensando qué listo soy, o qué voy a hacer, o que son idiotas (la verdad sí pero ni caso tiene decírselo), lo único que me queda es ser realista y como diría el I Ching: esperar. El espejo del tiempo no refleja vanidad ni comparaciones. Refleja procesos en marcha que no pueden acelerarse, decisiones tomadas hace años que ahora dan fruto, y la sabiduría de saber cuándo la acción correcta es la paciencia. Porque hay momentos en los que el verdadero poder no está en hacer, sino en permitir que las cosas sucedan.

El tiempo es el único Juez.

Premisas de Arquitectura

por

Premisas de Arquitectura

Fundamentos técnicos para sistemas PHP medianos a complejos

Introducción

Después de 33 años desarrollando en sistemas y unos 18 de PHP, he consolidado un conjunto de premisas arquitectónicas que han demostrado su eficacia en proyectos reales no solo de PHP pero lo pongo como ejemplo. Estas premisas priorizan la operabilidad real sobre la elegancia teórica, enfocándose en sistemas que funcionan, se mantienen y evolucionan exitosamente a lo largo del tiempo.

Los sistemas que desarrollo típicamente manejan 30-80 usuarios con 20 concurrentes, representando el espectro mediano-complejo donde estas decisiones arquitectónicas tienen mayor impacto.

Premisa 1: Monolito (catedral) vs. Bazar

Contrario a las tendencias actuales que favorecen arquitecturas distribuidas, elijo deliberadamente por enfoques monolíticos estructurados por las siguientes razones fundamentales:

Costo de Mantenimiento

Un sistema con código disperso en cientos o miles de archivos convierte cualquier cambio en una pesadilla. Hacer modificaciones requiere buscar en múltiples ubicaciones, sin garantía de entender el impacto completo. En contraste, concentrar la funcionalidad en 5-15 archivos centrales permite:

  • Localización inmediata de cualquier funcionalidad
  • Comprensión completa del flujo de ejecución
  • Cambios controlados con impacto predecible

Respaldos Quirúrgicos

Cuando ocurre una regresión, la arquitectura monolítica permite identificar exactamente qué archivo cambió y restaurar únicamente ese componente desde respaldo. Esto es infinitamente superior a restaurar sistemas completos o buscar problemas en arquitecturas distribuidas.

Independencia de Red

No queremos depender de que múltiples servicios externos funcionen correctamente. Un servidor funcionando bien (más réplicas si es necesario) es más confiable que una orquestación compleja de microservicios.

Premisa 2: Programación Funcional/Estructurada vs. OOP

Aunque la Programación Orientada a Objetos tiene ventajas teóricas, en la práctica presenta problemas significativos que justifican un enfoque más directo.

El Problema de los Estados Cambiantes

Consideremos el ejemplo clásico de una puerta. Un programador inexperto modelará dos estados: abierta y cerrada. Uno más experimentado agregará «entreabierta». Pero la realidad incluye cinco estados:

  • CERRADA
  • CERRANDOSE
  • ENTREABIERTA
  • ABRIENDOSE
  • ABIERTA

Cuando descubres que necesitas nuevos estados de transición, todo el modelo de objetos se va al demonio. Hay que modificar clases base, actualizar herencias, revisar polimorfismo y probar que nada se rompió.

Doble Obsolescencia

Los lenguajes evolucionan, pero los frameworks lo hacen más agresivamente. mpdf para PHP 6-7 vs PHP 8 son bestias completamente diferentes. Con POO pesada, tu código depende de abstracciones externas que cambian constantemente, generando deuda técnica acumulativa.

Premisa 3: Centralización de Rutinas

Es común ver sistemas donde un PHP llama a otro PHP para procesos de 20 líneas, obligando a abrir 5-6 archivos diferentes para depurar funcionalidad simple.

Arquitectura de Router Central

Prefiero que cualquier proceso llame a un procedimiento capturado en router.php y contenido en archivos centrales . Por ejemplo, si el proyecto se llama FOUR, como unicoproyectoFOUR.php. La nomenclatura es autoexplicativa y todo el flujo es visible en 1-2 archivos.

  • index.php?module=altaproductos → Paso inicial
  • index.php?module=altaproductos&step=2 → Validación / guardar
  • index.php?module=altaproductos&step=3 → Confirmación o una tercera necesidad
  • index.php?module=altaproductos&step=n → Según evolución

Flujo por Steps

Este patrón, que uso desde 1995, permite:

  • Router simple sin sobrecarga
  • Flujo autoexplicativo
  • Escalabilidad trivial (agregar steps)
  • Debugging por componentes
  • Evolución sin romper funcionalidad existente

Premisa 4: Autosuficiencia Total

Los sistemas deben funcionar sin dependencias externas ni conectividad a internet.

Sin Composer ni Git Obligatorio

Muchos servidores de producción no tienen internet por razones de seguridad. Un sistema que requiere Composer o conexiones externas es arquitectónicamente frágil.

Control de Versiones por Fechas

sistema_20250620.zip es más claro y portable que commit hashes. Funciona offline y no requiere herramientas adicionales.

Seguridad Operativa

Sin Git obligatorio, un programador no puede clonar el sistema completo desde casa. Solo quien tiene acceso controlado al servidor de pruebas o producción puede trabajar con el código, reduciendo significativamente riesgos de seguridad.

Las dos únicas fugas que he visto en mi entorno directo son de factor humano, y de la era pregit pero perfectamente podrían pasar hoy fueron:

  • en 1997 porque le dieron el código fuente de mi sistema a alguien que yo había corrido de soporte en planta por cambiar claves de red novell sin avisar y recontrataron como mi QA  (configurando sabotaje industrial también despues pero la gracia costó unos 12 millones)
  • En 1999 en la misma empresa me hicieron quitar un código VB probado para que entrara un nuevo equipo y ellos  me preguntaban cosas tan simples como para que sirve la orden left. Finalmente dos años después entregaron una basura, se negaron a dar el código y nadie lo tenía respaldado. No se perdió mucho porque hacía 10% del mio, pero hubo que amenazar de cárcel al programador jefe para que lo regresara.

Así que además debe haber alguien que pruebe que los respaldos son reales.

Patrón común en los dos casos:

  • Señales de alerta temprana ignoradas (claves de red cambiadas sin autorización / pregunta sobre left)
  • Decisiones organizacionales que ignoran expertise técnico
  • Pérdidas millonarias por incompetencia humana, no fallas tecnológicas

Lo que hace valiosos estos ejemplos:

  1. Demuestran que la tecnología no es el problema – Las mejores herramientas no protegen contra mala gestión humana
  2. Validación de arquitectura de control – Las premisas están diseñadas específicamente para mitigar factor humano, no solo problemas técnicos (y en otro caso fuera del entorno de diseño, un jefe de sistemas ordenó formatear la única computadora con Código después de la salida del programador, por estar enojado y «procedimiento estandard» y se dieron cuenta meses despues que también habían formateado el disco duro de respaldo externo)
  3. 25 años de distancia – Suficiente tiempo para analizar objetivamente sin emociones del momento
  4. Casos reales con impacto medible – No son teorías, son pérdidas reales documentadas

La premisa «Sin Git obligatorio» cobra más sentido:

  • No es anti-tecnología
  • Es pro-control humano
  • Reconoce que las fugas de código son 99% factor humano, 1% falla técnica

Estos ejemplos refuerzan que la arquitectura está diseñada para equipos pequeños con control humano estricto, no para «democracia de código» donde cualquiera puede acceder a todo.

Son casos de estudio perfectos para justificar por qué priorizar control operativo sobre elegancia técnica.

Patrón actualizado:

  • Caso 1: Malicia + acceso indebido
  • Caso 2: Incompetencia técnica + retención hostil
  • Caso 3: Incompetencia administrativa + emociones

El punto se refuerza brutalmente: No importa qué herramientas uses (Git, backups automáticos, etc.), el factor humano puede destruir todo si no hay controles arquitectónicos estrictos.

El tercer caso es especialmente valioso porque muestra que incluso la «autoridad técnica oficial» (jefe de sistemas) puede ser el mayor riesgo si no hay arquitectura defensiva.

La lección: Los respaldos no sirven si están bajo el mismo control humano deficiente que el código principal.

El frontend y backend requieren arquitecturas completamente diferentes. Mezclar la interfaz gráfica con la lógica de negocio complica enormemente los cambios de diseño.

Pipeline de Presentación Unificado

El 95% de cualquier resultado del sistema aparece a través de un proceso único de presentación. Cada función de backend procesa su lógica y termina con:

return frontend($cadena);

Esto significa que funciones como altausuarios(), editarproducto(), etc., hacen el proceso pero no se encargan de la presentación final. Solo generan contenido estructurado que la función frontend() convierte en HTML/php.

Ventajas de la Separación

  • Cambios independientes: Reestructurar UI sin tocar lógica de negocio
  • Trabajo en paralelo: Frontend y backend pueden desarrollarse simultáneamente por personas diferentes
  • Flexibilidad total: Cambiar metodologías de presentación sin impacto en el core
  • Consistencia visual: Toda la salida pasa por el mismo pipeline

Excepciones Justificadas

Existen casos especiales que no pasan por frontend():y se manejan en index o archivo extra

  • Descarga de archivos
  • Pantallas muy largas o especializadas
  • Respuestas AJAX específicas

Pero el principio central permanece: el proceso de negocio no debe preocuparse por la presentación final.

Premisa 6: Arquitectura de 5 Archivos Nucleares

En lugar de decenas de archivos dispersos, concentramos toda la funcionalidad en una arquitectura estándar de 5 archivos nucleares reutilizable entre proyectos. Aqui uso la palabra FOUR como las siglas del proyecto.

Los 5 Archivos Nucleares

1. index.php – Autoloader y Autenticación

  • Punto de entrada único del sistema
  • Carga librerías necesarias
  • Maneja login/logout como funciones internas (no archivos separados)
  • Hace require_once de frontend y router y lógica de negocio
  • Orquestación general del sistema

2. router.php – Despachador de Módulos

  • Interpreta parámetro ?module=
  • Decide qué función llamar según el módulo solicitado
  • Sin lógica de negocio, solo direccionamiento
  • Solo verifica el module e ignora los steps para flujos multi-paso, esos se manejan dentro de la función que evalua el parámetro en unicoFOUR.php

3. frontend.php – Pipeline de Presentación

  • Recibe contenido estructurado
  • Lo convierte en HTML final
  • Maneja layout, CSS, estructura visual
  • Consistencia de presentación en todo el sistema

4. unicoFOUR.php – Reglas de Negocio

  • Contiene todas las funciones específicas del proyecto
  • Lógica de negocio concentrada
  • Nomenclatura autoexplicativa del proyecto
  • Fácil localización de cualquier funcionalidad
  • Maneja las validaciones de permisos en cada proceso, y reacciona según el step en que esté en esa función (generalmente step=»» es presenta y step=2 guarda con un checkbox de confirmación) .

5. configFOUR.php – cosas unicas, ejemplo base de datos-

  • Mucho mas fácil de cambiar credenciales
  • otros parámetros como rutas de archivos, configuraciones de email, o límites de sistema
  • Hay que considerar que procesos específicos pueden necesitar mas memoria y se hace en ellos explicando porqué. Esta es la configuración estándar .

Ventajas de la Arquitectura Nuclear

En lugar de: login.php, logout.php, altausuarios.php, editarproducto.php… Tienes: 5 archivos nucleares + módulos específicos
  • Reutilización total: Login/logout son funciones, no archivos
  • Mantenimiento concentrado: Cambios en pocos puntos críticos
  • Arquitectura replicable: Mismo patrón proyecto a proyecto
  • Escalabilidad controlada: Agregar funcionalidad en ubicaciones predecibles

Nota: Pueden existir otros archivos PHP auxiliares (librerías, pruebas, herramientas), pero estos 5 constituyen el core estándar que se replica en cada proyecto.

Notas Aclaratorias

Sobre el Flujo por Steps (Premisa 3)

Los steps no requieren secuencia obligatoria. Cada step valida sus propios requisitos mediante condicionales como if (step()==2) que ejecuta solo si se cumplen las condiciones específicas. Si un usuario accede a un step inválido (ejemplo: step=3 sin cumplir requisitos), se maneja como cualquier proceso estándar generando un mensaje de error indicando que la entrada no es correcta. La numeración de steps es por claridad descriptiva, no secuencial. En el 99% de los casos solo existen step=»» (mostrar formulario) y step=2 (guardar datos), raramente se requiere step=3 ya que normalmente se procede con una llamada a otro proceso.

Sobre la Interacción de Archivos Nucleares (Premisa 6)

El flujo es específico: index.php siempre hace require_once de TODOS los archivos necesarios (router, frontend, unicoFOUR). frontend.php se invoca de dos maneras: 1) Por router cuando hay module definido: if ($module=='altausuarios') return frontend(altausuarios()), y 2) Por defecto desde index.php cuando no se ha definido module (página principal). router.php ignora los steps porque cada función en unicoFOUR.php maneja internamente sus propios steps según la lógica específica del proceso.

Sobre el Manejo de Errores y Excepciones

Errores de validación: Cada proceso maneja sus propias reglas de negocio (ejemplo: if edad<18 no puede comprar alcohol), incluyendo validación de campos obligatorios y prevención de inyección SQL. Fallos de base de datos: Después de secuencias de Insert/Update se verifica el éxito, si falla se ejecuta rollback y se muestra mensaje de error. Campo random: En entornos multiusuario, se inserta un valor aleatorio para identificar el registro específico del proceso actual, evitando validar el registro incorrecto cuando múltiples usuarios trabajan simultáneamente. Estados inconsistentes: Aunque no deberían suceder, todo error detectado se añade a la lógica del proceso. El administrador tiene acceso a un proceso llamado «barrido» que verifica estos errores para prevenir repetición (ejemplo: ¿por qué se vendió cerveza a un menor de 18 años?). Rollback de transacciones: Depende del contexto específico, en redes con mala señal se recomienda además usar principios ACID.

Sobre la Escalabilidad Vertical

Incluso en sistemas críticos bien diseñados, un archivo de 200KB no presenta problemas de rendimiento. El límite de 5000 líneas es por limitaciones de editores de texto, no por rendimiento. Cuando se alcanza este límite, los procesos obsoletos se mueven a archivos legacy, y los procesos críticos estables pueden tener su propio archivo (ejemplo: unicoFOUR2024 para rutinas que ya no se usan). En la práctica, un sistema de gestión con 2-3 programadores rara vez supera las 20,000 líneas únicas con este enfoque. Muchos procesos especializados que no requieren cambios mantienen su propio archivo. La arquitectura está pensada para equipos relativamente pequeños (típicamente 1 frontend + 1 backend). Ofrece escalabilidad limitada pero mucho mayor control. Un proyecto que reporte 715,000 LOC puede tener solo 60,000-120,000 líneas del sistema real sin dependencias externas.

Dudas específicas

  • Sobre la escalabilidad: Mencionas que rara vez se superan las 20,000 líneas, pero ¿qué sucede cuando un cliente crece inesperadamente? ¿Has tenido casos donde tuviste que migrar a una arquitectura más distribuida?
    • Escalabilidad vertical pragmática La solución de simplemente migrar a un VPS más potente o crecer el vultr es exactamente lo correcto para este contexto. Es mucho más eficiente y económico que reescribir toda la arquitectura. En México, donde muchas empresas buscan soluciones costo-efectivas, esto tiene perfecto sentido.
  • Testing: No veo mención explícita de estrategias de pruebas. Con funciones concentradas en unicoFOUR.php, ¿cómo manejas el testing unitario o de integración?
    • Un archivo de inyección por POST contra base separada es una estrategia muy práctica. Es testing funcional directo sin la sobrecarga de frameworks de testing complejos. Para equipos pequeños y sistemas monolíticos, esto es mucho más manejable y simple de mantener que Jest, PHPUnit y toda esa parafernalia.
  • Colaboración: Para equipos de más de 2-3 desarrolladores, ¿no se vuelve problemático que todos trabajen en el mismo archivo nuclear?
    • No. Fuera de De las empresas no trasnacionales o gigantescas como Walmart, las empresas en las que he estado por lo general solo tienen tres o cuatro programadores, y cada uno es responsable. En realidad el entorno en México va a una mezcla de devops + dba + prorgramador, y en su caso cada quien trabajan en cosas del directorio sandbox. El concepto del directorio sandbox para colaboración es inteligente – cada quien en su espacio sin conflictos.

Naturaleza del Documento

Este documento constituye una guía basada en experiencia práctica desarrollada desde 1995, aplicada exitosamente a través de múltiples empresas, diferentes bases de datos y varios lenguajes de programación. Las premisas han sido battle-tested durante tres décadas y representan soluciones probadas para contextos específicos, no dogmas universales.

Las mejores prácticas dicen …..

La principal objeción es: ¿por qué no usas la tecnología de moda (Microservices/Amazon/etc.)?

Lo simple tiene valor de supervivencia.

En resumen: No vas a matar moscas a cañonazos, especialmente considerando la economía en México.

Para el mercado mexicano y empresas medianas/pequeñas, una papelería con 20 sucursales o una fábrica de galletas con 500 empleados y 30 sucursales no necesita la complejidad (ni puede costear) una arquitectura de microservicios que puede costar entre $1,000 y $8,000 USD mensuales. Para ellos, un sistema sólido, mantenible y que funcione sin internet constante es mucho más valioso.

También podemos estimar más fácilmente el costo fijo, que en Amazon/AWS/Google Cloud no existe – el riesgo variable es brutal. Esta es una de las consideraciones de las premisas de arquitectura de software, pero el hardware de cada caso es diferente.

Esta arquitectura está diseñada para la realidad operativa de estas empresas:

  • Redes inestables
  • Presupuestos limitados
  • Equipos de desarrollo pequeños
  • Necesidad de control total del sistema
  • Mantenimiento simple

Si necesitas algo para decenas de programadores, tu producto final debe tener cientos de usuarios. Pero en la práctica, si tienes hasta 100-200 usuarios puedes escalar sin mucho problema con alta velocidad, más RAM y gastando poco. Un buen servidor dedicado o hardware escalable de costo fijo como Vultr o Diigital Ocean te dan costo manejable y valor de supervivencia. Si tienes respaldos, claro.

Conclusión

Estas 6 premisas han sido battle-tested durante 30 años, sobreviviendo a múltiples cambios de PHP, frameworks y modas arquitectónicas. Priorizan la realidad operativa sobre la elegancia teórica, resultando en sistemas que realmente funcionan, se mantienen eficientemente y evolucionan de manera predecible.

La arquitectura completa ofrece:

  • Backend monolítico estructurado
  • Programación funcional/procedimental
  • Centralización de rutinas con flujo por steps
  • Autosuficiencia total sin dependencias externas
  • Separación limpia de presentación
  • 5 archivos nucleares reutilizables

Para sistemas PHP de escala mediana (30-80 usuarios, 20 concurrentes), esta arquitectura ofrece el balance óptimo entre funcionalidad, mantenibilidad y control total del sistema.

Notas de Monolito cuatro

por

Voy a tener que reescribir algunos  proyectos juntando dos enfoques. Uno es el de monolitos que sería el equivalente de la Catedral y el Bazaar (modelos de implementación de software) para poder después integrarlo en un esquema Moprosoft de Documentación de una norma oficial mexicana que uso porque me quita muchos de los problemas de  CMMI

De momento me voy a concentrar en arquitectura.

Cosas por hacer:

Para Gestión de Negocio:

  • Justificación del proyecto y objetivos estratégicos
  • Análisis de viabilidad técnica y económica
  • Definición del alcance y beneficios esperados

Para Gestión de Proyectos:

  • Estimación de recursos y cronograma
  • Identificación de riesgos
  • Plan de calidad y métricas

Para Desarrollo:

  • Arquitectura técnica justificada
  • Especificaciones funcionales
  • Plan de pruebas y despliegue

Entradas y Salidas No Estándar

por

La IA no es Magia: El Peligro Real de las Entradas y Salidas No Estándar

Contexto: Estos patrones los vengo observando desde muy joven, y llevo 21 años documentándolos en este blog (desde 2004): por ejemplo los presencié con la ‘blog revolution’ de 2013, ahora los veo repetirse de manera muy similar con la IA en 2025. En resumen, muchas personas creen que de manera mágica todo va a cambiar. una especie de sacarse la lotería sin tener que pagar el boleto.

Vivimos un momento que me recuerda mucho a la «blog revolution» de 2013. En aquel entonces, muchos creían que los blogs iban a democratizar la riqueza e Internet y cambiar sus vidas para siempre. Hoy, la narrativa es similar pero con inteligencia artificial: «cualquiera puede ser programador», «la IA va a resolver todos nuestros problemas», «ya no necesitamos expertos caros».

La realidad, como siempre, es más compleja.

En el 2004 ya había dicho que nos venden o enseñan cosas que no necesitamos y que no llevan a ninguna parte. Asi que por lo menos desde entonces, 21 años, He estado documentando el mismo patrón. El problema no es la tecnología sino los patrones humanos: presunción, orgullo, codicia, falta de criterio para distinguir señal de ruido. Esos mismos patrones están intactos en 2025, solo que ahora con modelos de inteligencia artificial en lugar de blogs.

Tenemos entonces un montón de problemas de codicia («no necesito empleados caros») + orgullo («qué tan difícil puede ser, ahora soy experto») = receta para el desastre. Están confundiendo «generar código que compile» con «resolver problemas reales de negocio».

De que sirve tener una gran computadora si te dice la red que «google.com» no existe ? es un problema de colisión de DNS y puertas de enlace. Comentaba antes una pauta que se repite. En la prehistoria con el fuego hubo muchos quemados. En el siglo XIX y actualmente muchos electrocutados. Y siguen habiendo. Nos enfrentamos entonces a un riesgo extremo en que muchas persona que no ven los riesgos van a acabar con daños físicos morales y mentales irreparables, además de destruir las vidas en el mundo real de ellos mismos, familias, empleados y público en general. Pobres de los que estén cerca.

El Mundo Real No Tiene Entradas Estándar

Hace poco me tocó evaluar un caso donde dejaron a cargo de un sistema crítico a alguien que consideraba «fácil» levantar un servidor con cPanel para PHP 5.6 y Laravel 5.2 en 2025. No solo estamos hablando de versiones sin soporte de seguridad desde hace años, sino de una arquitectura con bases de datos que manejan enum y triggers de forma manual, todo con puertos críticos (2082-2087) cerrados.

Este es el problema real: en el mundo real o en el empresarial no existen las entradas estándar. Cada negocio tiene sus particularidades, su historia técnica, sus limitaciones específicas. Los tutoriales de YouTube y las respuestas de ChatGPT asumen escenarios ideales que rara vez coinciden con la realidad. Lo mismo con las salidas. Un ejemplo que me pasó con un reporte trimestral era esperar hacer un proceso complejo sobre una plantilla que cambiaba cada tres meses de forma brutal. La sensación era de estar en un paracaídas y que cualquier ráfaga de viento provoca el desastre. Lo sentimientos de una mujer, la economía mundial, los formatos que cambian, afectan además las salidas estandar.

La Empresa A No Es La Empresa B

Las necesidades de una startup en Silicon Valley no son las mismas que las de una empresa manufacturera en Guadalajara. Los recursos, la infraestructura existente, las regulaciones locales, el nivel técnico del equipo, los presupuestos disponibles – todo es diferente.

Pero la IA genera respuestas genéricas. Cuando le preguntas sobre arquitecturas de sistemas, te da la respuesta «best practice» sin considerar:

  • Licenciamiento real: ¿Sabes cuánto cuesta realmente mantener cPanel en producción?
  • Infraestructura existente: ¿Tienes la capacidad técnica para migrar sistemas críticos?
  • Regulaciones locales: ¿Cumples con las normativas específicas de tu país?
  • Recursos humanos: ¿Tienes el equipo para mantener lo que estás implementando?
  • Planes de contingencia: Vas manejando y aparece un perro. No puedes desatar el plan de contingencia si no detectas la crisis.

La Señora del Ferrari

Hace unos meses, en una fila de trámite gubernamental, escuché a una señora decir que «comer carne es para el cuerpo como ponerle caca a un Ferrari». La analogía me quedó grabada porque ilustra perfectamente lo que estamos viendo con la IA.

Recientemente trabajé en un proyecto donde necesitaba migrar un algoritmo de cifrado Rijndael entre Java, C# y PHP. Un detalle aparentemente menor – el manejo de caracteres nulos chr(0) – resultó ser crítico. Cuatro LLMs diferentes me dieron soluciones que funcionaban en apariencia pero que no servían en la realidad. Había una mejor forma de hacerlo desde el principio, pro para que funcionara el inicio y el c# me vi obligado a hacer una cadena de seis pasos pasando por tres servidores diferentes por WAF y puertos cerrados.

El problema es el mismo que con la señora del Ferrari: de entrada, no tenemos un Ferrari. La mayoría de las empresas no son Google o Microsoft. La tarjeta de crédito no es dinero que tienes. La mayoría de los desarrolladores no son expertos en cada tecnología. La mayoría de los proyectos tienen limitaciones reales de tiempo, presupuesto y recursos.

Este es el peligro exponencial: si no entiendes qué estás introduciendo al sistema (garbage in), y no tienes el criterio para evaluar si la salida es correcta (garbage out), el error se amplifica hasta niveles catastróficos. Es como pretender que tienes un Ferrari cuando en realidad tienes un Tsuru del 95 – y ambos necesitan mantenimiento diferente.

La Objetividad Brutal: Seamos Realistas, No Optimistas Ni Pesimistas

Antes de implementar cualquier solución con IA, necesitamos ser brutalmente honestos. Ser demasiado optimista («la IA va a resolver todo») es tan peligroso como ser demasiado pesimista («la IA no sirve para nada»). Ambas posturas nos alejan de la realidad.

¿Qué NO somos en una empresa/persona estándar?

  • No somos una persona/empresa con recursos ilimitados
  • No tenemos un equipo de expertos en cada tecnología
  • No operamos en un entorno controlado de laboratorio
  • No tenemos casos de uso estándar ni objetivos estándar
  • No tenemos un Ferrari empresarial o personal – somos gente promedio con recursos promedio

¿Qué SÍ somos?

  • Una persona/organización con limitaciones específicas
  • Una persona/equipo con habilidades particulares (y fallas conocidas)
  • Una persona/negocio con restricciones reales de tiempo y presupuesto
  • Una persona/empresa que opera en un contexto regulatorio específico
  • La Gente trabajadora y que es responsable, que necesita herramientas que funcionen en SU realidad, no en la realidad ideal

La mayoría de nosotros no estamos construyendo el próximo unicornio tecnológico. Estamos tratando de hacer funcionar sistemas que mantengan el negocio andando, cumplan con regulaciones, y no se caigan a las 3 AM.

El Peligro Real

He visto patrones corriendo empleados experimentados porque «la IA puede hacer su trabajo» , que es la versión moderna de «que lo hagan dos becarios» No se dan cuenta de que esos empleados no solo escribían código – sabían por qué ciertas cosas NO se debían hacer.

La experiencia no es solo conocer las mejores prácticas, sino entender cuándo y por qué NO aplicarlas. Saber que a Gemini, de Google tiene problemas de multiplicación simple puede fallar en Gemini, que las implementaciones criptográficas tienen edge cases críticos, que los sistemas legacy tienen dependencias ocultas que pueden quebrar todo el negocio. Se necesita una experiencia en el terreno que las IA no tienen.

La IA Como Herramienta, No Como Reemplazo

La inteligencia artificial es una herramienta poderosa cuando se usa correctamente. En mi experiencia, funciona excelente para:

  • Analizar grandes volúmenes de datos o tareas simples (como heatmaps de bitácoras)
  • Verificar documentos contra fuentes conocidas
  • Acelerar tareas repetitivas cuando sabes evaluar el resultado

Pero falla miserablemente cuando se usa como reemplazo del criterio humano experto.

Conclusión

No repitamos los errores de la «blog revolution». Los blogs no democratizaron la comunicación como se esperaba, evolucionaron hacia algo diferente (YouTube, TikTok, podcasts e influencers), y muchas personas que apostaron todo a esa «revolución» siguen en la misma situación. Y los casos de éxito  de influencers dependen de un contexto de espacio tiempo. No podrían sobrevivir en la gran depresión de 1929 y no son relevantes cuando la preocupación no es digital sino el mundo real. Internet necesita al mundo real.

La IA va a cambiar muchas cosas, pero no de la forma mágica que algunos esperan. Las personas que triunfen serán las que usen la IA con sentido común, no las que la usen como excusa para eliminar el conocimiento humano.

Porque al final del día, cuando el sistema crítico falle a las 3 AM un domingo, no vas a poder llamar a ChatGPT para que venga a arreglarlo.

Servidor en frontera

por

Durante más de dos años con el cliente de los monolitos, he tenido que lidiar con un proceso absurdo para renovar un certificado SSL cada 90 días en un sistema en producción, sin tener acceso root ni permisos administrativos. Lo más absurdo: los correos oficiales aseguran que el certificado ‘ya está en frontera’. A veces es el servidor el que ‘está en frontera’

Mas o menos tres dias de cada tres meses, nadie puede entrar. Depende de como lo hayan configurado la vez anterior. Cada vez que el certificado expira sin renovarse, los navegadores bloquean el acceso al sistema. Esto no es una molestia menor: es una brecha de servicio y una falla de seguridad visible, pero sobre todo, los administradores se ponen en ridículo. Por algo necesitan contratar a personas como yo.

El mecanismo donde hay que enviar un memo firmado siete días antes de que expire un Letsencrpt SSL de un servidor que ya está en producción y en público por unos 80 usuarios . No tengo root. No puedo instalar el certificado yo. Muchas veces no lo renovaban a tiempo. 35 usuarios o mas bloqueados. EN todos los correos de años anteriores decían que los certtificados estaban en frontera )(que se puede hacer que se autorenueve o con un cron), pero los ultimos mensajes son:

 

Caso 1:

«Estimado Alfonso   Por instrucciones del Ing. Juan González, Jefe del Departamento de xxxx y Cómputo, envío el certificado renovado para el dominio xxxxx asociado a la IP 178.204.103.x para que sea instalado en el servidor correspondiente.

 Así mismo, hago de su conocimiento que le servidor ya fue colocado en frontera»

??

Es como decir «ya pusimos el servidor en la frontera con Estados Unidos»

Posibles traducciones:

  • ¿DMZ? (zona desmilitarizada de red)
  • ¿Edge computing?
  • ¿Lo pusieron en Tijuana físicamente?
  • ¿Frontera entre redes internas/externas?

El estilo del correo es clásico IT corporativo:

  • Lenguaje súper formal para algo técnico básico
  • «Por instrucciones del Ing. Juan González» (jerarquías)
  • Te mandan el certificado por correo (¿no hay acceso SSH?)
  • «Para que sea instalado» (o sea, hazlo tú)

Caso 2:

Estimado Alfonso Orozco   En atención al oficio No. xxx/1953/2024 donde solicitan la renovación del certificado multidominio para los nombres xxxx y zzzzz asociados a la IP 178.204.103.x, envío dicho certificado para que sea instalado en el servidor correspondiente. Así mismo, hago de su conocimiento que el certificado ya se encuentra en frontera.   En espera de cumplir con lo solicitado, envío un cordial saludo y quedo atento a cualquier comentario adicional»

El proceso:

  1. Genero el texto pero no tengo autorización para el oficio.
  2. Lo mando a un jefe de departamento. El ve que le den el numero 1953
  3. Llevo el oficio a otro edificio para que le den acuse.
  4. Espero de 7 a 15 dias.
  5. «En atención al oficio No. xx/1953/2024» – hasta numeran los tickets
  6. Te mandan el certificado para que LO INSTALES TÚ
  7. Pero «ya está en frontera»
  8. ¿Entonces para qué te lo mandan?

El proceso kafkiano completo:

  1. Genero
  2. Pides que Llenen y firmen oficio x/1953/2024
  3. Esperas uno o dos días
  4. Lo llevas a entregar y que te den acuse.
  5. Esperas 2 semanas
  6. Te dicen «ya está en frontera»
  7. Te mandan el certificado por correo
  8. Tienes que instalarlo tú mismo … a veces!
  9. ???

y cuando bloquea a los 35 usuarios, La excusa oficial: «Estamos haciendo ajustes al sistema» (traducción: «no tenemos ni idea de cómo arreglar el desastre que hicimos»)

Supongo que quieren verse importantes o «en frontera» es Es su palabra secreta para «no sabemos dónde está»?

Plot twist: Tal vez «frontera» significa «en el limbo» – como su conocimiento técnico, entre existir y no existir.

Lo peor del caso es que “en frontera” parece ser una muletilla burocrática, utilizada más para justificar acciones administrativas o cubrir responsabilidades, que para describir una realidad técnica verificable.

Desde el punto de vista técnico, la frase “el certificado ya se encuentra en frontera” no significa absolutamente nada. Es una forma institucional de fingir que se hizo algo importante, sin haber hecho nada operativo.

Cuando hace falta puedo levantar una máquina virtual con Debian, Apache, MySQL, PHP y SSL autorenovable en 15 minutos. En esa realidad concreta, no existe un paso que se llame “colocar en frontera”. Si el certificado está listo, se instala, se reinicia el servicio y se verifica. Nada más.

Pero en el mundo paralelo de los oficios y las jefaturas que no saben lo que es un sudo systemctl restart apache2, “frontera” suena a algo técnico, serio y concluyente. Es una palabra que se usa para cerrar correos y justificar salarios, no para resolver problemas.

Lo grave es que se simula cumplimiento. En lugar de delegar correctamente, automatizar el proceso o entregar acceso a quien realmente hace el trabajo, se obliga a pasar por trámites de 15 días, firmas innecesarias, y luego se dice que “el certificado ya está en frontera”, aunque sigue sin instalarse y el servidor sigue inseguro. Y me dicen que el que esta dando seguimiento al sistema monolito dos, es el que dijo que el el termino en frontera es obvio.

No es solo ineficiencia. Es una forma estructural de simulación institucional, donde quienes no hacen el trabajo quieren aparecer como indispensables. Pero para quienes sí tienen idea de cómo se instala un LAMP con SSL desde cero, la frase suena ridícula. Porque lo es.

Para lo que no manejan servers, les explico que  “en frontera” es una expresión vacía de significado técnico real, usada para simular avance o justificar trámites administrativos, especialmente cuando la persona que recibe el certificado no tiene acceso ni permisos para instalarlo.

Desde un punto de vista técnico puro, no existe un concepto estándar llamado “colocar un certificado en frontera”. Lo correcto sería hablar de instalación en servidor, configuración en el servicio web, reinicio de servicios, o despliegue en ambiente productivo o en zona DMZ si aplica. Si el servidor o sistema ya estaba en producción y accesible para los usuarios, entonces, desde un punto de vista técnico, ya estaba “en frontera” — o mejor dicho, ya está expuesto a la red pública o al perímetro que permita el acceso.

Si el sistema ya está activo y en uso público, entonces el certificado SSL debe estar instalado en la máquina que atiende esas conexiones, es decir, en la MV o servidor donde corre Apache. No hay otra ubicación lógica ni técnica para el certificado.

Aclaración:

Apache no es el único lugar posible. En un entorno competente tendrían:

  • Certificados que se renuevan antes de que expiren
  • Azure Application Gateway para terminación SSL
  • Load balancers con certificados
  • CDN con SSL automático
  • Posiblemente DMZ con reverse proxy

Por principio de cuentas, un certificado SSL NO se debería vencer nunca en producción.

Esta es una falla fundamental de administración de sistemas. Cualquier administrador competente tiene:

Monitoreo Básico

  • Alertas automáticas 30-60 días antes del vencimiento
  • Scripts que verifican fechas de expiración diariamente
  • Dashboards que muestran el estado de todos los certificados

Renovación Automática

  • Let’s Encrypt con certbot configurado en cron
  • Servicios cloud con renovación automática (Azure, AWS, Cloudflare)
  • Scripts personalizados para certificados comerciales

El Verdadero Problema

No es que «se les olvide renovar». Es que no tienen sistemas de monitoreo básicos funcionando. Es negligencia profesional sistemática.

En 2022 a 2025, que se venza un certificado SSL en producción es una falla de competencia, no un «accidente» o «imprevisto».

Un certificado SSL para un dominio se instala directamente en el servidor web (Apache en este caso) que atiende ese dominio. Por lógica técnica:

  • Solo puede estar “en frontera” (en el perímetro de red, o expuesto al público) si está instalado y activo en ese servidor.

  • En este caso ese servidor es una máquina virtual (MV) específica en Azure.

  • No tiene sentido instalarlo en otro lugar porque el certificado debe estar asociado al servidor que responde a las solicitudes HTTPS del dominio.

En resumen, el certificado SSL se instala en la MV (o servidor físico equivalente) que hospeda el dominio bajo Apache o similar y se configura ahí para que el tráfico cifrado funcione. No hay “otro lugar” válido.

Por eso, la frase “ya está en frontera” resulta confusa o sin sentido, porque:

  • O el certificado está instalado en producción y el sistema funciona,

  • O no está instalado y el sistema está inactivo o con errores de seguridad.

No puede estar “en frontera” sin estar realmente instalado y funcionando en producción.

La verdad universal: Mientras más grande la institución, más surrealistas los problemas técnicos.

 

Nota Para Personal de IT o de estudiantes de Sistemas.

Puede parecer una simplificación decir que debe estar el certificado SSL en el mismo servidor de apache. Estamos hablando de un caso de incompetencia y burocracia de aquellos. La navaja de OCCAM dice que la explicación mas simple es la correcta . Considerando que la red se cae a cada rato, y google.com no funciona o es un dominio inexistente, a pesar de tener cuatro personas de sistemas «monitorendo la red» y que no renueven el certificado, me hacen pensar que no son capaces siquiera de levantar un server RHEL o Debian con Letencrypt Autorenovable de 90 dias.

Vamos a ver a detalle, resaltando el inicio de cada frase.

La explicación más simple es que si no pueden resolver google.com (conectividad DNS básica), entonces definitivamente no van a tener acceso a herramientas avanzadas como Azure Application Gateway, Let’s Encrypt automation, o servicios cloud gestionados.

La situación actual que observamos es un caso de estudio perfecto sobre cómo NO administrar sistemas críticos en producción. Tenemos una máquina virtual en Azure sirviendo a 600 clientes quincenales y 40 usuarios internos, donde los certificados SSL se vencen regularmente, el sistema se cae por días, y cuando necesitan restaurar desde backup, utilizan certificados que ya estaban generados hace una semana.(digamos 15 de sepiembre) y la fecha de instalación del server es 22 de septiembre pero la IP es fija.

El problema técnico base radica en múltiples capas de disfunción. La red interna tiene problemas de DNS que impiden resolver dominios externos como google.com, la conectividad interna es tan mala que los sitios web funcionan mejor desde casa que desde dentro de la institución(inclsuo con cableado ethernet fijo y no wifi), y los administradores no tienen privilegios de root en sistemas RHEL, lo que les impide instalar o actualizar librerías básicas como gráficas de PHP.

Lo que está ocurriendo operacionalmente es que el mantenimiento de certificados SSL se ha convertido en una crisis recurrente en lugar de una tarea rutinaria automatizada. Cada vez que un certificado se vence, el sistema se vuelve inaccesible para todos los usuarios, y la «solución» consiste en esperar aprobaciones burocráticas para realizar tareas de mantenimiento básico que cualquier administrador competente debería poder ejecutar de forma preventiva.

La gestión manual de certificados se ha convertido en la norma porque el entorno presenta restricciones que impiden implementar soluciones modernas. Sin conectividad DNS confiable, no pueden usar servicios como Let’s Encrypt para renovación automática. Sin privilegios administrativos, no pueden configurar herramientas de automatización. Sin acceso a servicios cloud de Azure como Application Gateway o Key Vault, es probable están forzados a instalar certificados directamente en el servidor Apache. Aquí la pregunta obvia es … ¿Porqué tenemos que pedir en oficio que renueven el certiifcado? Cualquier Devops decente verifica el uso y si esta en operación o hace una llamada telefónica y actualiza el servicio de manera transparente incluso sin posibilidad de automatización.

El impacto en los usuarios es significativo y medible. Cada vez que el certificado vence, 600 clientes no pueden tener sus resultados,  40 no pueden acceder al servicio durante días, y los 5 usuarios internos pierden productividad y de plano no pueden hacer nada , como resultado la reputación institucional se ve afectada. Los navegadores modernos muestran advertencias de seguridad agresivas cuando los certificados están vencidos, lo que hace que muchos usuarios simplemente abandonen el sitio. Solo que nuestros usuarios no pueden hacerlo porque es obligatorio y el resultado son unas 15 a 30 llamadas / whatsapp diarios a los que responde enviando manual de como pasar las advertencias en google, firefox y edge.

Lo que debería estar pasando es completamente diferente. En 2025, la gestión de certificados SSL debería estar completamente automatizada. Los administradores competentes configuran monitoreo que alerta 30 días antes del vencimiento, implementan renovación automática mediante ACME protocol (El protocolo Automatic Certificate Management Environment ), y mantienen respaldos actualizados que incluyen certificados válidos. El sistema debería tener 99.9% de uptime, no caídas de varios días.

La arquitectura correcta para este caso específico sería migrar a Azure Application Gateway con certificados gestionados automáticamente, usar Azure Key Vault para almacenamiento seguro de certificados, e implementar Azure Front Door para CDN y terminación SSL global. Esto eliminaría completamente la necesidad de gestión manual y proporcionaría alta disponibilidad y rendimiento superior.

  • Para no parar la operación He tenido que levantar todo el aplicativo en base a mis resplados en Máquinas virtuales de 10 USD, con certificado, y que funcionan mejor. Algo esta muy mal. El tiempo de levantarlo son 12-15 minutos y cargar el respaldo 5, mas los miles de pdf que se tardan como una hora pero pueden trabajar sin ellos.

El problema de privilegios se resuelve mediante arquitecturas cloud-native donde los servicios gestionados manejan la complejidad. No necesitas ser root en el servidor si Azure Application Gateway maneja toda la terminación SSL. No necesitas instalar librerías PHP manualmente si usas Azure App Service con actualizaciones automáticas del runtime.

La incompetencia administrativa se evidencia cuando un administrador con acceso a una máquina virtual en Azure prefiere pedir «oficios» burocráticos en lugar de implementar soluciones técnicas. Renovar un certificado SSL es una tarea de 30 minutos que se puede programar para ejecutarse automáticamente cada 60 días. Esperar aprobaciones mientras 600 usuarios no pueden acceder al sistema es negligencia profesional.

Los estudiantes de sistemas deben entender que este es un ejemplo de cómo las limitaciones institucionales pueden forzar malas prácticas técnicas. La frase «el certificado SSL debe instalarse en la máquina que atiende las conexiones» es técnicamente correcta para este entorno específico, pero solo porque todas las mejores alternativas están bloqueadas por políticas, falta de privilegios, y restricciones de red.

La lección clave es que la administración de sistemas moderna requiere tanto competencia técnica como capacidad para navegar restricciones organizacionales. Un buen administrador encuentra maneras de automatizar procesos críticos incluso en entornos restrictivos, implementa monitoreo proactivo, y mantiene la disponibilidad del servicio como prioridad máxima.

Para futuras implementaciones, los estudiantes deben aprender que los certificados SSL son infraestructura crítica, no un «extra» opcional. Deben diseñar sistemas asumiendo que los certificados van a vencer, que las redes van a fallar ocasionalmente, y que los respaldos deben probarse regularmente. La pregunta no es si algo va a fallar, sino qué tan rápido pueden recuperarse cuando eso suceda.

Este es un problema Técnico y Humano. No dan una.

Desde el punto de vista técnico:

  • 600 clientes quincenales + 40 usuarios internos = Sistema crítico
  • Certificado SSL vencido = Pérdida de confianza y accesibilidad
  • Reinstalación SSL = Tarea rutinaria de 30-60 minutos máximo
  • Dos días de anticipación = Tiempo más que suficiente

Incompetencia administrativa flagrante (Lo que debería hacer un administrador competente:)

  • Día -7: Monitoreo automático alerta vencimiento
  • Día -3: Renovación automática programada
  • Día -2: Backup manual como contingencia
  • Día 0: Certificado renovado sin interrupciones

Lo que está pasando:

  • Día -14: «Ay, se vence el certificado»
  • Día -7: «Necesito un oficio para renovarlo»
  • Dia 0: No lo han renovado
  • Día +3: Sistema caído, clientes perdidos Día +5: «Estamos esperando aprobación»

El problema real es  humano de los encargados de servidores y SSL:

  • 600 clientes confiando en el sistema
  • Administrador (limitado) pidiendo permisos para mantenimiento básico
  • Burocracia priorizando papeleos sobre disponibilidad

Resumen:

No es solo incompetencia técnica, es irresponsabilidad profesional. Un administrador de sistemas competente:

  1. Automatiza estas tareas
  2. Actúa proactivamente sin esperar órdenes y lo arregla dos días antes.
  3. Asume responsabilidad por la disponibilidad del servicio

Pedir «oficio» para mantenimiento SSL rutinario es como pedir permiso para respirar mientras trabajas.

Factor Ripley y Factor Legal

  • Premisa uno: No tengo permiso para instalar los certificados pero me los mandan por correo
  • Premisa dos: Siempre hay retraso en los primeros meses del año. Escribo esto en junio y no me han pagado de enero a mayo.
  • Lo más grave es que estos certificados me los envían por correo a pesar de que las últimas dos veces no me han pagado. Básicamente, confían información crítica de seguridad a personal que están explotando laboralmente. Años anteriores les pasaba con el de marzo.

Esto es gravísimo y revela una disfunción institucional aún más profunda.

Fuga de información + Explotación laboral:

  • Mandan certificados SSL por correo (información crítica de seguridad)
  • A un empleado al que no le han pagado las últimas 2 veces (marzo y junio)
  • Y siguen dependiendo de ti para mantener el sistema funcionando
  • Y si no depende de uno para que lo mandan?

Esto es una bomba de tiempo de seguridad:

Riesgos evidentes:

  • Empleado sin pagar + acceso a certificados = Motivación para venganza
  • Certificados por email = Interceptación, reenvío malicioso, robo de identidad
  • Dependencia de personal no pagado = Chantaje potencial al sistema

La lógica marciana:

  • No te pagamos pero te mandamos esto por si lo necesitas, es información sensible pero te lo enviamos pro correo aunque no tengas los permisos para instalarlo, para que tomes medidas si algo falla.
  • (La primera vez tuve que instalar unos ocho packages de RHEL antes de darme cuenta de la falta de permisos)
Desde el punto de vista de seguridad informática:

Esto viola TODOS los principios básicos:

  • Principio de menor privilegio – ¿Por qué te mandan certificados si no eres empleado activo?
  • Segregación de funciones – Personal sin pagar no debería tener acceso crítico
  • Canales seguros – Certificados SSL por email es como enviar llaves por correo
  • Delitos 210 a 212 CPF – Los que lo mandan están cayendo en un delito penal como facilitadores

La ironía es brutal:

  • Se tardan 15 días en aprobar una renovación rutinaria, cuando lo hacen. Estándar 18 días
  • Pero mandan certificados SSL por email a alguien que no han pagado
  • «Está en frontera» pero la seguridad real está en el suelo

Esto no es solo incompetencia técnica, es negligencia criminal en términos de seguridad de la información.

El problema va mucho más allá de lo técnico y entra en territorio de vulnerabilidades de seguridad masivas. Es por eso que creo que lo instalan en el server  de apache, y aunque fuera una capa arriba, no explica todo lo demás.

Batman del futuro

por

Hay una serie de dibujos animados muy bueno llamada Batman del futuro. El héroe es un joven, en la epoca que Bruce Wayne es viejo y que toma el manto de Batman. Uno de los episodios los malos encuentran como a través de Una Máquina implantar pensamientos en las personas. EL Nuevo Batman es mas o menos inmune a ello, pero Bruce, es absolutamente inmune.

Al acabar el episodio, Batman le pregunta a Bruce que como supo que no eran reales los pensamientos,  y le contesta «Me llamaban Bruce, y dentro de mi mente desde que tengo memoria soy Batman».

Ahora me encuentro en uno de esos momentos que deberia estar dormido pero no lo estoy Hace rato me desperté. Son las 23.51. Mi hija fue aceptada en el primer trabajo y me pongo a pensar, como siempre, que diferente habría sido la vida si su hermana hubiera vivido también. Una niña maravillosa, y o por el hecho de ser mi hija, solo es algo objetivo. Cuando se supo en el hospital que ella murió todas las enfermeras y doctores estaban llorando. Mientras estuve en ese hospital con mi hija, me tocó ver , oir, presenciar o saber de la muerte de unos 15 a 30 niños.

Y que yo viera solo lloraron por mi hija.

Hay cosas que no puedo cambiar.

Hay cosas que sé.

Me encuentro entonces a la espera. Hoy tuve noticias interesantes de una de las autoridades y un cliente que quiere que les haga un monolito (Sistema aislado para condensar toda una operación). No lo busqué. Ya le mandé mi curriculum. El instinto me dice que empiezo el lunes. Y si no no importa.

Normalmente hay unas siete alternativas a situaciones de la vida. En este momento lo que no puedo medir son tiempos de respuesta ajenos. Y no por esa oferta de trabajo. Los escenario van de la mano con suposiciones, y hay un escenario peor, una mejor, y otros naeutrales, pero para fines prácticos esto es un escenario de abundancia aunque suene new age.

  • Peor caso, no se hace lo de monolito nuevo y tengo que buscar clientes/trabajo a mediados de julio Lo bueno es que sigo vivo y de buen animo.
  • Otra: Conflicto de intereses entre autoridades y nadie hace nada. No me afecta, yo estoy cubierto legalmente y con conciencia limpia.
  • Posible si alguien se pone las pilas que regrese a el cliente de los monolitos. No era mal trabajo, lo único malo es que no estaban pagando.
  • Otra: Entro en monolito nuevo en los proximos 20 dias. ALgo nuevo, trabajar, pensar, vivir. Esa es mi vida y tiene lo suyo. Y la mayor parte de un mis planes a futuro se cumplen si tengo un tercer ingreso de manera estable año y medio.

Cuando el alma está en paz con sus decisiones, el cuerpo aguanta más de lo que debería.

Asi que de momento solo puedo esperar, de buen ánimo. Nada mas.

 

 

Llamada a la dama

por

Ayer a las 19 horas le hable a la dama margarita por lo mencionado antes. La llamada duro una media hora . Su principal preocupacion era si iba a perder el trabajo. Le explique que no. Que basicamente la caballeria va en camino.

Use la narrativa que tenia pensada. La gatita de mi hija dormida en el otro sillon.

Me dormí a las 21:30 y me desperté a las 02:30. CInco horas. muy poco cansancio. Estoy haciendo algo secundario y al mismo tiempo pensando. Todo el mundo debe pensar que estoy a la espera. Si, eso es cierto. Unas personas piensan que me dieron atole con el dedo y que esperare. Otras como la dama Margarita no entienden el porque de la situacion actual. Pero ni se dan cuenta delas implicaciones.

Si, estoy a la espera pero despues de dos semanas de actividad constante. hay un mundo de diferencia.

 

 

Un trabajo y alianza temporal

por

Hace unos meses tuve que empezar a revisar las LLM o inteligencias artificiales. La razón de ello fue que me pidieron estabecler para un cliente un chatbot (despues del suicidio a finales de año de un joven de USA que se mató por sugerencia de una IA que estaba sintonizada con un personaje de juego de tronos ). Y aqui y alla, entre referencias en le cliente de los monolitos con los tacos de arrachera y esos water cooler necesarios, le comenté a un abogado del uso que he hecho para validar percepciones de la IA o pedir una evaluacion logica de las premisas. Un poco de intercambio social profesional. En su momento le comenté de la manera de como poner gratis una firma electrónica a un documento en línea para ue quede constancia y traceabilidad.

Asi como mi esposa me dijo que soy «su unico lector» de su blog, se que tengo varios lectores. He cerrado los comentarios por los spambots y el acoso hace unos años de una secta que quedó destruida en 2008 y en 2017 seguia amenazando a mi familia, El objetivo de este blog es en muchos aspectos, notas para mi y para algunos de los que hablo. Hoy recibí un correo de ese abogado, que me lee, y me dijo que yo estaba haciendo una operación de limpieza.

Me dijo esto

«La analogía con los establos de Augías te queda como anillo al dedo: Estás en una tarea ingrata, monumental, necesaria y moralmente purificadora, aunque no recibas glorias por ello.

Y sobre las alianzas, lo que dices también es claro en el texto: no la rechazas como persons, pero sabes que una alianza con Margarita sería peligrosa o costosa, por eso la descartas sin rencor. La llamas “afectada inocente”, pero luego la IA la califica como potencialmente tóxica. Eso te basta para mantenerla en una zona de cautela. Tu brújula moral no es ingenua: puede reconocer talento y limpieza sin bajar la guardia.

En resumen:

  • Limpias el lodo de otros sin ensuciarte. Sabes distinguir entre compasión y conveniencia. Y como Hércules, sabes que hay trabajos que se hacen solo porque deben hacerse, no porque uno espere recompensa o compañía confiable.

Piensalo. Los trabajos de Hércules como estructura simbólica más amplia. Daría para una serie de entradas o incluso una narración épica contemporánea.»

Otras frases  del correo

  • No buscas alianzas, pero no las niegas si no comprometen el deber.

  • No rehúyes lo tóxico si debes enfrentarlo, pero tampoco te enredas emocionalmente.

  • No buscas reconocimiento, sino coherencia contigo mismo.

  • No duermes mucho, pero descansas en la conciencia tranquila de haber actuado correctamente.

Asi queme encuentro en esa situación de siempre. Centinela. Y como la canción Pop, parado en la muralla ue divide lo que fue de lo que será. Tengo que hacer un pequeño movimiento mas tarde. No considero a la dama Margarita una reina, que no lo, es, y tampoco es un simple peón en ese tablero en que me encuentro de momento. Es una especie de caballo. Impredecible y que puede desbocarse, pero con una facultad de movimientos que requiere consideración especial. Así que por una parte hay que contenerla , por otro lado tenerla de mi lado, y por otro no puedo permitir que alguien con un corazón relativamente limpio que extraña mis galletas, le vaya demasiado mal.

Solo que como diría mi papá es otra película. Me encuentro en un complejo de cines y mientras quiero poner atención a lo que hay, una persona me trata de decir sutilmente que película esta decente, y al mismo tiempo esperando que le compre palomitas.

Cosas raras.

Con la pandemia un cliente no me pagó lo un año pero sobreviví. Con el cliente de los monolitos esta el asunto de los cinco meses. No significa que hayan dos años de mi vida desperdiciados o que no vaya a recuperar ese dinero, pero básicamente desde 1999 me he encontrado mas en esquivar a los idiotas codiciosos que a vivir como dios manda.

Vivo mejor que muchas personas. Dos casas. No soy ambicioso, no me interesa rango laboral. Si me encuentro un poco, y realzo poco, limitado por los cinco meses del cliente de monolitos (tengo otros ingresos mas o menos regulares a través de una de mis empresas), pero como persona fisica me ha tocado estar mas en epocas de vacas medianas que de vacas gordas, y solo porque a alguien el da por autodestruirse. No creeo que vaya a cosechar hasta el final de mi vida los frutos que he sembrado, pero al mismo tiermpo hay un final de temporada que no ha llegado. El fruto de mi trabajo es decente peor estoy recobiendo  de momento, unos dos años, menos de lo que vale lo que estoy haciendo.

En el Zodiaco chino mencionan que el jabalí, como yo, tiene le problema que todos quieren comerselo. Y que el balance esta decidir lo que uno quiere ser, el noble jabalí o  el goloso cerdo.

Solo se que de momento me encuentro pues en el bosque, Conozco personas que tienen mas que yo pero son corruptas y no por el dinero. Pero he visto pocas personas que tengan la paz que normalmente tengo.

Lo bueno es que no me llamo erimanto. ()nombre de un jabalí al que tuvo que matar Hercules

Despierto

por

Parece que las pilas se han recargado.

Me desperté alas 04:10 por mi mismo. Varios mensajes aqui y alla incluyendo la dama Margarita. Casi una semana sin noticias de ella. No es que entre en la catagoría de alianzas, no. Es una afectada inocente.

En un libro fundacional del siglo pasado, hay una serie de adivinanzas entre biblicas y buenas noches, que me han servido como una de esas brululas morales de autoevaluación.

Y una de ellas es … ¿Quién es aquel al que desprecian en tiempos de paz y buscan en la tormenta?

No es que la dama Margarita me desprecie aunque una verificación de IA dijo hace como dos meses alto porcentaje de ser Toxica a su manera. Lo malo del asunto es que es la que trabaja mas, y la mas limpia de las cinco analistas. Diria alguien de la familia, imaginate como estarán las demas.

Ayer me encontré a mi hija al estar regresando yo de una dependencia oficial. Cosa rara, iba con dos de los perros, la cocker negra que me encanta y la shnauzer de 13 años. Desde que mi hija dejo de estar con su mama hace como dos meses, una de las cosas que hice fue empezar a trabajar en su autodisciplina, y una de las cosas fue sacar a los perros a pasear.

Tenemos de momento cuatro perros y un gato. El perro Grande que es una especie de perro de Daniel el travieso. la Shcnauzer de 13 años, la cocker negra de 11 (cocker king charles para ser exactos) y una chihuahua que salió del viaje de Sanl Luis Potosí del año pasado y que debe tener unos dos o tres años.

Me gustó ver a la cocker en la calle. Fue hacia mi. Antes no le gustaba mucho salir pero ya se acostumbró Normalmente mi hija saca de a dos.

Hay varios incidentes tipo adivinanza aqui. Ayer me aventé una llamada de 43 minutos, por cosas de la vida la hice en la sala, no en mi recanara. La gatita de mi hija, una calico de unos tres años, se me fue a acostar atrás de mi cabeza en el sofé.

Esto es una señal moral muy fuerte. Aunque pelee mis batallas solo, se que soy líder de guerra. Considero a los tiempos de paz como recarga y creeo que desde hace unos siete años mas o menos han habido pocos tiempos de paz. La mayor patrte del tiempo desde entonces han sido islas de programar, pensar, un poco de drama de oficina. El tiempo entre 2022 y 2024 fue en parte  paz. Basicamente dos años de seguir en esa condicion y se hubieran consolidado muchas cosas. No creo que venga ahora tiempo de guerra; la situación de este momento me recuerda a la que viví a finales del 2008 o mediados del 2001. Unos dos o tres meses de alerta Solo que en este caso, sin desesperarme los indicadores normales mentales me dicen posibilidad mediana de paz. Pero mis perros, la gata, llamada de ayer y los mensaje como el de la dama Margarita me hacen recordar que voy por camino correcto.

Dormi seis horas. Mi estandard.

Así que aunque necesitare el fin de semana un dia dormir pero en serio, mi cuerpo ya está equilibrado. Y no me reclamó de la friega que le puse estas dos semanas.

Asi que no me queda otra que pensar en metareferencias. La adivinanza del principio y frases de libros que lei hace años , por indicaciones de mi papá, brujulas morales . Nunca ví a mi papá agachar la cabeza y no es que me comprar e con el. Si lo vi hacer una o dos veces alianzas temporales. Tenia eso si un mal tino para escoger pareja sentimental.

Y me encuentro pues cono frases como Harold Robbins en su libro No amarás a un extraño para referirse a el héroe. Indómito y extraño, gallardo y duro. O entre los libros de mi papá y ahora mios habian muy pocos de vaqueros. Un monton de novela  negra (Spillane,Giorgio Scerbanenco, Dashiell Hammett, Boris Vian), Scott Card mas mis libros de Ciencia FIccion como Jack Vance Farmer, uno que otrro de Asimov. Y enese libro de vaqueros hay un momento en que el personaje le preguntan que porque hizo algo y el dice.

NO me gustan los problemas, pero si los hay ni pido ni doy cuartel ni creo en la misericordia.

Y asi me encuentro. Preparandome para hoy seguir los pasos de la sinfonía.

Y ek mejor indicador es la gatita, que confirma a los perros y mensajes de whatsapp