Mi familia tiene una finca en Ugarteche. Nogales viejos —algunos tienen más de 40 años. Por ende hay actividades que se repiten cada temporada: poda, cosecha, fumigación, riego, análisis de suelo.
Cuando empezamos a buscar software de gestión agrícola para llevar un registro, todos los sistemas que encontramos tenían el mismo problema: los cultivos estaban hardcodeados. Podías registrar maíz, soja, trigo, girasol. Si querías registrar nogales en producción desde hace cuatro décadas, el sistema no sabía cómo manejarlos. ¿En qué "etapa de crecimiento" está un nogal adulto? ¿Cuántas semanas faltan para la cosecha de un árbol que lleva 40 años produciendo?
Eso me llevó a construir CampoLog. Está en desarrollo activo —lo uso en la finca, pero todavía no es algo que recomendaría poner en producción sin conocer el código.
El modelo de datos que no asume nada
La decisión de diseño más importante es que los cultivos no tienen etapas. Una implantación (parcela + cultivo + fecha de inicio) existe o no existe. Las actividades son libres: vos definís los tipos de actividad para tu establecimiento.
Los tipos de actividad pueden tener reglas de movimiento de inventario asociadas: "cuando registro una fumigación, descuenta X litros del producto Y del inventario". Lo configurás una vez y después cada vez que registrás una fumigación, el movimiento se genera automáticamente. El sistema nunca te dice "ese cultivo no está soportado".
La PWA de inventario para el campo
El módulo de inventario tiene una Progressive Web App separada (/campoLog/app/) diseñada para usarse desde el celular mientras recorrés la finca. Los movimientos se encolan localmente si no hay señal y se sincronizan automáticamente cuando volvés a zona de cobertura.
Las fotos de los productos se suben a Backblaze B2 —no al hosting compartido, que tiene límites de almacenamiento molestos. Una foto típica son 100-200 KB; con 300 productos, estamos en ~50 MB, dentro del plan gratuito de B2.
El error que casi borra 6 meses de inventario
Durante una migración de esquema, un ALTER TABLE para agregar una columna falló silenciosamente en el hosting porque la tabla ya existía de una migración parcial abortada. El script asumía que si llegaba a ese punto era porque nunca se había ejecutado antes.
El resultado fue que los nuevos movimientos tenían el campo nuevo como NULL cuando deberían tener un valor. No borré datos, pero el historial quedó incompleto para 3 semanas de registros. Tuve que reconstruirlos manualmente a partir de los logs.
Ahora todas las migraciones son idempotentes: verifican primero si la columna existe antes de intentar crearla. Aprendizaje caro pero definitivo.
CampoLog está desplegado pero por ahora es de uso interno —acceso por login, repo privado. Si alguna vez lo libero, va a ser acá. Mientras tanto, si te tenes mismo problema o alguna idea, dejame un comentario.
Comentarios (1)
Dejá tu comentario
Los comentarios son moderados antes de publicarse.