Forem: Octavio Martinez

Un Bug en la Física: Cómo las Clases Abstractas me Ayudaron a Resolver una Paradoja Temporal

Octavio Martinez — Mon, 15 Dec 2025 23:33:30 +0000

Llevo 5 años escribiendo código en React, Node, TypeScript, Vue...
lo usual para un fullstack. Pero el 13 de diciembre de 2025 publiqué
algo que nunca imaginé: un paper de física teórica sobre dimensiones
temporales múltiples. Y no, no cambié de carrera. Esta es la historia
de cómo las habilidades de programación pueden aplicarse a problemas
de física fundamental.

El Problema Fascinante

Las dimensiones temporales múltiples, es una propuesta cuyo pionero es el doctor en fisica Itzhak Bars, que plantea la hipotetica idea de que nuestro Universo y en especial el tiempo que percibimos sea el resultado de un universo con dos tiempos fundamentales, un espacio de 4 dimensiones espaciales y 2 temporales.

Pero, esto es imposible en el papel. Los números dicen que nuestro pasado y presente se encontraria constantemente creando paradojas temporales al mejor estilo del Delorian.
Y por esta razón esta hipotesis tan genial que lograria resolver muchos problemas de la fisica moderna, no ha logrado agarrar tanta fuerza como otras; aun cuando el doctor Bars sigue trabajando en ella y ha encontrado soluciones magnificas a este problema.

Pero, un dia, mientras debia estar programando, leí un artículo y me pregunte: Y por qué tratan al tiempo como espacio?
Allí estaba el Bug, estaban tratando al tiempo como si fuera una dimension espacial más, aun cuando claramente no lo era, se trataba de un error de tipado.

Por Qué un Programador Puede Aportar

No soy genial por esta propuesta, solo hice lo que como programador estoy acostumbrado a hacer: mire el problema desde otra optica. Y mirar desde otra optica es facil cuando literalmente estas en otro campo.

Además un skill que debi usar mucho, y que uso mucho en programacion fue la abstracción. Si, la abstraccion, porque este problema implicaba observar las dimensiones espaciales y temporales, y por decirlo de una manera crear clases abstractas de ellas, y por encima de ellas una clase principal de la que heredaran sus principales atributos

Uno de esos atributos que las diferenciaba fue lo que termino convirtiendose en el Axioma de la Distinción Topológica. Una frikada que significa: a diferencia del espacio, el tiempo solo puede avanzar. Si amigo programador, hice un contract para especificar la unidirecionalidad del tiempo.

El Proceso

Aprendi a programar solo (ya lo he contado antes), a los 12 años hacia codigo en pascal escondido de mi familia. Pero antes de la programacion, la fisica me cautivo en alguna enciclopedia, de esas que nuestros papas compraban sin ningun proposito particular, solo porque el vendedor sabia hacer su trabajo. Asi que eso de andar leyendo por alli lo que nadie me mando se me hace natural.

Asi fue como me encontre con el trabajo de Bars, mirando cosas del espacio-tiempo, la cuantica y esas frikadas que todas las personas normales hacemos luego de un meeting con el jefe.

Y para mi en mi inocencia (ignorancia), me parecio facil decir: "pero el tiempo solo avanza". Asi que hable con mi colega de trabajo (el colega de todo buen dev), y le dije:
`

Yo: "Oye Gemini, por que este problema no lo resuelven así?"
Gem: "Octavio que buena intuicion, ya ese problema tiene una solucion pero lo que tu propones cambia el enfoque llegando al mismo resultado"
Yo: "Ya hablamos de esto, sube tu excepticismo al 50% y dime si realmente este enfoque es tan innovador"
Gem: "Perdon Octavio, me deje llevar. Pero efectivamente es innovador, no eres Einstein seguro, pero tu enfoque da una solucion estructural que simplifica las matematicas del mismo"

Luego de varias conversaciones con mi amigo Gem en excepticismo 100%, tome la decision de escribi un Paper, y alli descubri que como existen los Vibe Coding tambien existen los Vibe-Physics.
Luego de varias interacciones, conociendo los procedimientos comunes, los formalismos matematicos (aprendi que es un langriano), desarrollando ecuaciones, validandolas, corrigiendolas.
Y por supuesto, limpiando el contexto de Gemini una y otra vez para que dejara de delirar.

Una vez terminando el siguiente paso fue la publicacion, lo consulte mucho antes de hacerlo. Me daba miedo la idea de moverme fuera de mi area comun de trabajo. Pero alli llego el mejor consejo que alguna vez en la vida toda persona ha recibido: que tienes que perder?
Y asi, guiado por un cliche filosofico el viernes 12 de diciembre en la noche hice el deploy, y como todo buen deploy de viernes termine de publicar el sabado 13.

Lo Que Aprendí

En fisica si quieres decir algo debes decirlo con números, es su lenguaje de progranación.
Ya no renegare de documentar mi codigo, un papers es mas dificil.
No importa el campo, el impostor siempre aparece, y siempre se vence de la misma forma.
Pensar fuera de tu area de confort siempre es un camino de aprendizaje.

El Paper

Título: Emergent Causality in Multitemporal Manifolds: A Reformulation through Semigroup Restrictions in the Lagrangian
Link: https://zenodo.org/records/17919110

Este Pre-Print (para ser mas precisos), en pocas palabras dice que el tiempo al ser una variable de tipo Tiempo debe cumplir con la condicion de Solo Avanzar.
En el caso de Bars, esto implica que los dos tiempos pueden sumarse y al al hacerlo se eliminan asi las paradojas.
Como un toque adicional: la velocidad de la luz deja de ser fundamental, y viene dada por esta suma de vectores temporales.

¿Y Ahora Qué?

Aunque ya esta publicado en Zenodo, la ruta a seguir es publicarlo en arXiv, pero para eso necesito apadrinamiento, algun investigador que certifique como minimo que no estoy trolleando a la comunidad.

¿Físico leyendo esto? Tu feedback me interesa.
¿Programador curioso? El pensamiento abstracto que usas diario aplica a física.

Tu LLM es tu nuevo Dev Junior. Escríbele Tickets Perfectos con esta Estructura

Octavio Martinez — Fri, 29 Aug 2025 11:52:01 +0000

Todos hemos estado ahí. Le pides a una IA que genere un código y te devuelve un desastre: usa librerías obsoletas, ignora por completo el contexto de tu app o, peor aún, "alucina" una solución que parece plausible pero es fundamentalmente incorrecta.

El problema no es la IA. El problema es que la tratamos como a un oráculo mágico en lugar de lo que realmente es: un desarrollador junior increíblemente rápido, con acceso a todo Stack Overflow, pero sin una pizca de contexto sobre tu proyecto.

Si le das un ticket vago a un dev junior, obtienes resultados vagos. Si le das un ticket perfecto, obtienes código de calidad. Lo mismo pasa con los LLMs. Deja de improvisar y empieza a usar una estructura. Esta es la anatomía de un prompt que funciona.

La Anatomía de un Prompt de Nivel Profesional

Piensa en tu prompt como un ticket de Jira o una User Story. Necesita tener secciones claras para no dejar lugar a la ambigüedad.

1. Rol (Persona) 🎭

Qué es: Le dices al modelo quién debe ser.
Por qué funciona: Le das un "sombrero" que define su conocimiento, tono y estilo. No es lo mismo un "Experto en Ciberseguridad" que un "Creador de contenido viral".

Ejemplo para código:

"Actúa como un desarrollador full-stack senior con 10 años de experiencia, especializado en el stack MERN y en la optimización de rendimiento."

2. Contexto (Context) 背景

Qué es: El README.md de tu solicitud. La información de fondo que necesita para entender el panorama general.
Por qué funciona: Eliminas las suposiciones. Le das el stack tecnológico, el objetivo de negocio, el público, etc.

Ejemplo para código:

"Estoy construyendo el backend para una app de e-commerce con Node.js, Express y MongoDB. Estamos usando JWT para la autenticación."

3. Tarea (Task) 🎯

Qué es: El título del ticket. La acción específica y directa que debe realizar.
Por qué funciona: Va al grano. "Genera una función" es mucho mejor que "háblame sobre funciones".

Ejemplo para código:

"Crea una función middleware de Express.js llamada 'authenticateToken'."

4. Pasos / Instrucciones (Steps) 📝

Qué es: El desglose de la tarea, la lista de // TODO.
Por qué funciona: Obligas al modelo a seguir una lógica estructurada. Si el resultado es incorrecto, puedes depurar en qué paso falló.

Ejemplo para código:

"Sigue estos pasos:

Extrae el token JWT del header 'Authorization'.

Valida el token con la librería jsonwebtoken y una clave secreta.

Si es válido, adjunta el payload del usuario al objeto req y llama a next().

Si no es válido o no existe, responde con un error 401 o 403."

5. Formato de Salida (Output Format) 📄

Qué es: Cómo quieres que te entregue el "pull request". ¿JSON? ¿Markdown? ¿Solo el bloque de código?
Por qué funciona: Te ahorra el trabajo de limpiar la respuesta. Esencial para automatizar tareas.

Ejemplo para código:

"Formato de Salida: Proporciona únicamente el código JavaScript dentro de un bloque de código markdown. No incluyas explicaciones adicionales."

6. Restricciones (Constraints) ⛓️

Qué es: Las reglas del proyecto. El linter, las guías de estilo, las dependencias prohibidas.
Por qué funciona: Acota las posibles soluciones y asegura que el código se alinee con tus estándares.

Ejemplo para código:

"Restricciones: No uses librerías externas aparte de 'express' y 'jsonwebtoken'. El código debe seguir las guías de estilo de Airbnb para ES6+."

El Ingrediente Secreto: La Cláusula de Clarificación

Esta es la técnica que separa a los amateurs de los profesionales. Añade esto al final de tus prompts importantes:

"Si te falta información crítica para dar una respuesta precisa, no adivines. En su lugar, hazme las preguntas necesarias para obtener los detalles."

Esto transforma al LLM de un generador de código a un colaborador activo. En lugar de inventar el esquema de una base de datos, te preguntará por él. Esto te ahorra horas de depuración.

Poniéndolo todo junto: Lazy Prompt vs. Pro Prompt

Veamos la diferencia en la vida real.

❌ El Prompt Vago (y los resultados que te mereces):

"Hazme una función en JS que valide un email."

Probablemente obtendrás una función simple con una expresión regular que puede o no ser la mejor.

✅ El Prompt Profesional:

Rol: Actúa como un desarrollador backend senior enfocado en la seguridad y validación de datos.

Contexto: Estoy trabajando en un formulario de registro para una API en Node.js. La validación se realiza en el servidor antes de guardar los datos en la base de datos PostgreSQL.

Tarea: Crea una función llamada isValidEmail que valide de forma robusta una dirección de correo electrónico.

Instrucciones:

La función debe recibir un string como único argumento.

Debe devolver true si el email es válido y false en caso contrario.

La validación debe comprobar no solo el formato (usando una regex recomendada por OWASP o similar), sino también que el dominio no sea de un servicio de email temporal conocido (incluye una pequeña lista negra de ejemplo como ['temp-mail.org', '10minutemail.com']).

Restricciones: No uses librerías externas para la validación, solo código nativo de JavaScript.

Formato de Salida: Responde únicamente con la función de JavaScript en un bloque de código, incluyendo comentarios JSDoc.

Ves la diferencia, ¿verdad? El segundo prompt te dará una solución lista para producción.

No lo hagas cada vez

He creado una pequeña app que genera el prompt a partir de las caracteristicas que necesites, es de codigo abierto por lo que puedes usarla o crear tu propia version.

Web: https://prompt-builder-sandy.vercel.app
Github: https://github.com/zenx5/prompt-builder

Context Wrapper en React

Octavio Martinez — Fri, 17 Jan 2025 19:05:12 +0000

¡¡No dejes que tus componentes accedan al contexto de la aplicación!!

La idea del Componente en React es la de una pieza de UI que puede ser reutilizada, incluso en una aplicación diferente a aquella para la cual fue pensada. Las librerías de componentes son la máxima expresión de esto, en ocasiones con componentes que pueden ser personalizados hasta el último detalle.

Pero, sin llegar a ese punto, podemos crear componentes re-utilizables y que puedan moverse de una aplicación a otra sin mayor trauma, solo teniendo en consideración una estrategia de diseño que protege nuestros componentes de ser invadidos por el contexto y las reglas del negocio de nuestra aplicación.

Esta es, el Context Wrapper, que no es más que la idea de mantener el contexto un nivel por encima del componente que realmente necesita los datos del contexto, y proporcionar desde ese nivel superior los datos por medio de props.

Esto evita directamente los problemas frecuentes en la migración, donde normalmente nos veríamos obligados a modificar nuestro componente o el contexto de la aplicación receptora. Pero bajo esta forma de diseño, solo copiamos el componente y empezamos a usarlo inmediatamente proporcionando los props que necesite.

Claro, Context Wrapper no es tan limpio como pretende, pues da lugar a sub-clasificaciones de componentes que si no se tienen claras pueden complicar las cosas, pero eso va para otro artículo.

EGO y CRA

Octavio Martinez — Thu, 12 Dec 2024 20:40:15 +0000

El 22 de Junio abrí un issue en el proyecto de roadmap.sh el cual es de mis favoritos.

En el issue #5909 les comenté que Create React App (CRA) ya no era recomendado por React, además de esto proporcioné la evidencia en forma de links y screenshop. Haciendo referencia específicamente a la sección "can-i-use-react-without-a-framework". Esto, porque aun aparecía en la ruta de React en ese tiempo.

El 24 Junio recibí una respuesta que es la razón de este post. No por la respuesta como tal, sino por el EGO detrás de la respuesta.
La pregunta que me viene a la mente es ¿Cuan seguro puedes estar de tu superioridad para no tomarte el tiempo para considerar que quizás alguien más tenga la razón?

Finalmente los crack de roadmap terminaron cambiando la ruta de React, pero me hizo pensar mucho sobre el EGO del programador del que lamentablemente he oído hablar en la industria en los últimos 5 años.

Algo que trato de aplicar en el ambiente laboral es el dicho bíblico de "estimando cada uno a los demás como superiores a él mismo", sin caer en la falsa humildad, pero si considerando que soy un ser humano y que no siempre puedo tomar la razón.

Es mejor un "déjame comprobarlo", antes que un "te equivocas". Esto me ha permitido tener buenas relaciones laborales en las que he podido aprender y enseñar a otros, estableciendo vínculos laborales donde ninguna de las partes es descalificada a priori.

How to define the state?

Octavio Martinez — Sun, 10 Nov 2024 04:17:41 +0000

Let's explore 3 basic criteria to define what is and isn't part of the state. These criteria allow me to confidently decide on the "minimal but complete representation of the state" in my day-to-day as a React Lover.

Criterion 1: Expected to change.

Even though we know that state is immutable, it's usually tied to a part of the interface that is mutable. So, as a first criterion, we should evaluate if there's a part of the UI that's expected to change based on that value. If so, it's very likely that we're dealing with a candidate to be state, but before that, evaluate the following two criteria.

Criterion 2: Should not be inherited from any component.

If the value that defines the candidate to become state is received from another component, then it shouldn't be a state. It's possible that it's a state in the component that originally inherits it, but not the component that receives it.

Criterion 3: Should not be calculated from another state.

If the value must be calculated using another state as a base, then it's not a state, and its interaction in the interface should be shown based on the calculation of the original state.

¿Cómo definir el estado?

Octavio Martinez — Fri, 08 Nov 2024 15:10:54 +0000

Vamos a conocer 3 criterios básicos para definir que es parte del estado y que no lo es. Estos criterios me permiten decidir con total seguridad la "mínima pero completa representación del estado" en mi día a día como React Lover.

Criterio 1: Se espera que cambie.

Aun cuando sabemos que el estado es inmutable, normalmente está ligado a una parte de la interfaz que es mutable. Por lo que como primer criterio debemos evaluar si tenemos una parte de la UI que se espere cambie a partir de ese valor, es muy probable que estemos tratando con candidato a ser estado, pero antes evalúa los siguientes dos criterios.

Criterio 2: No debe ser heredado de algún componente

Si el valor que define el candidato a convertirse en estado es recibido desde otro componente entonces no debe ser un estado. Es posible que sea un estado en el componente que originalmente lo hereda pero no el componente que lo recibe.

Criterio 3: No debe ser calculado a partir de otro estado

Si el valor debe ser calculado usando como base otro estado entonces no es un estado, y su interacción en la interfaz debe mostrarse a partir del cálculo del estado original.