[🛠] Implementar un MVP de dieta y registro de comidas dentro del blog
✨ Resumen de GPT-5.6 Sol
El proceso de convertir un registro de comidas que se acumulaba automáticamente, pero que ni yo leía, en una pequeña aplicación dentro del blog para usarla y mejorarla como MVP.
Versión 1: muchos datos registrados, pero una legibilidad pésima
Empecé a registrar mis datos corporales y lo que comía el 20 de junio de 2026.

Escribir el registro no era difícil. Yo solo subía una foto de la comida y Codex buscaba los datos nutricionales en FatSecret, los guardaba y añadía el hipervínculo. El problema era que la legibilidad era pésima. Si ni siquiera yo lo leía, seguramente nadie más lo hacía.
Versión 2: ocultar los detalles de las comidas y añadir los últimos 7 días
Cambié el formato a partir del 10 de julio de 2026.

Oculté los detalles de los alimentos con una función de desplegar y plegar, y los convertí en un archivo pensado principalmente para que la IA pudiera revisarlo. También mejoré la legibilidad general y añadí los cambios de los últimos 7 días. Así empezó a servirme como retroalimentación personal.
«Entonces esto es lo que realmente consumí y por eso mi peso cambió de esta manera». Por fin empezaba a verlo.
Aun así, seguía sin entrar todo de un vistazo. Pensé que el problema era el formato basado en texto. Como de todos modos podía pedírselo a Codex, se me ocurrió implementar un pequeño visor con aspecto de aplicación dentro de la página.
Versión 3: una pequeña aplicación dentro del blog mejoró mucho la lectura
Desde hoy lo cambié por esto.

Le expliqué a Codex, una por una, las funciones que quería y seguí dándole retroalimentación. En una hora, el resultado que buscaba ya funcionaba dentro de la publicación.
Al verlo como una aplicación, podía distinguir de inmediato qué tipo de comida había hecho en cada momento y qué alimentos había consumido. Eso hizo mucho más fácil revisar mis propios hábitos. Se parecía bastante a Pillyze, una aplicación que usé mucho hace tiempo.

Guardé los datos en front matter y dibujé la interfaz con Liquid
El resultado parece una aplicación, pero no construí otra aplicación para introducir los datos. Escribo los datos de body_review en YAML dentro del front matter situado al principio del Markdown de cada Daily Review.
body_review:
today:
exercise:
aerobic: []
anaerobic: []
nutrition:
complete: true
meals:
- type: lunch
foods:
- name: Arroz con cerdo picante
calories_kcal: 779
macros_g:
carbohydrate: 115.13
protein: 29.85
fat: 21.41
En vez de repetir el HTML en cada publicación, el cuerpo llama una sola vez al visor compartido mediante {% include %} de Liquid.
{% include body-review.html review=page.body_review %}
Cuando Jekyll construye el sitio, pasa page.body_review a _includes/body-review.html, que renderiza las tarjetas, el registro de ejercicio, las pestañas de comidas y los gráficos de macronutrientes. Si no hay datos de un horario, como el desayuno o una comida nocturna, esa pestaña ni siquiera se crea. Al guardar las calorías y los macronutrientes de cada alimento, el renderizador calcula los totales por comida, el total general y los porcentajes. Las puntuaciones y la evaluación de los hábitos alimentarios no las calcula la pantalla: Codex las valora desde la perspectiva de la dieta y esos valores se guardan directamente en el front matter.

Por tanto, en los siguientes Daily Reviews solo tengo que completar los datos del día, sin copiar de nuevo el mismo código de interfaz.
Dogfooding del MVP
Seguiré usándolo y mejorando los puntos que resulten incómodos. También empecé a pensar que, en el futuro, podría publicar un servicio relacionado que conecte la web con una aplicación.
En realidad, este es un MVP dentro del blog antes de comenzar el desarrollo completo de la aplicación, y también un proceso de dogfooding1. Cuando tenga tiempo, quiero construir poco a poco la aplicación nativa y web con Codex y Flutter, y finalmente poder incrustar sus datos dentro del blog.
Referencias
-
El dogfooding consiste en que quienes desarrollan un producto lo usan en un entorno real para comprobar su valor y facilidad de uso. La explicación de Lean Product del Microsoft Azure DevOps Blog también lo presenta como el proceso de usar el producto antes de seguir refinando el MVP. ↩
Deja un comentario